TheGrebs.com:IRC Logs:#xen:2007:01:05

---	Log	opened Fri Jan 05 00:00:56 2007
01:37	\|-\|	WorkMonk [~Pirato@off.spillgroup.com] has quit [Quit: www.axenet.org or /server irc.axenet.org) (MonkScript (debbie-final) - The Carbon based script form, descended from an ape.]
01:48	\|-\|	sdague_ [~sdague@user-12lc6iq.cable.mindspring.com] has joined #xen
01:48	\|-\|	mday_away [~mdday@cpe-024-163-122-235.nc.res.rr.com] has joined #xen
01:48	\|-\|	jwb_gone [~jwboyer@rchp4.rochester.ibm.com] has joined #xen
01:48	\|-\|	muli [~muli@nesher3.haifa.il.ibm.com] has joined #xen
01:48	\|-\|	hensema [~erik@scrat.hensema.net] has joined #xen
01:48	\|-\|	tomaso [tomas@twin.jikos.cz] has joined #xen
01:57	\|-\|	jimix [~jimix@c-67-189-187-152.hsd1.ny.comcast.net] has quit [Quit: jimix]
02:00	\|-\|	zwane_work [~zwane@S0106001217d33fa6.vc.shawcable.net] has joined #xen
02:00	\|-\|	cdub [~chrisw@cdub.netrep.oftc.net] has joined #xen
02:00	\|-\|	infernix [~nix@spirit.infernix.net] has joined #xen
02:00	\|-\|	matti [matti@acrux.romke.net] has joined #xen
02:06	\|-\|	mastermind [~mastermin@mastermind.kaltenbrunner.cc] has quit [Remote host closed the connection]
04:24	\|-\|	Netsplit charon.oftc.net <-> helium.oftc.net quits: demon, andy, schultmc, Shoragan, danpb, jforbes, dykman_, tony, devastor, Basic_py
04:24	\|-\|	tzafrir_home [~tzafrir@bzq-179-75-202.static.bezeqint.net] has joined #xen
04:25	\|-\|	Netsplit over, joins: demon, andy
04:25	\|-\|	Netsplit over, joins: schultmc
04:25	\|-\|	Netsplit over, joins: jforbes, tony, dykman_, devastor
04:25	\|-\|	Netsplit over, joins: Shoragan
04:25	\|-\|	Netsplit over, joins: danpb, Basic_py
04:26	\|-\|	icblenke [~icblenke@magic.skylab.org] has joined #xen
04:27	\|-\|	quintela [~quintela@cm50035.red.mundo-r.com] has joined #xen
04:28	\|-\|	athomas [~athomas@host86-134-167-36.range86-134.btcentralplus.com] has joined #xen
04:28	\|-\|	tonyb [~tony@pythia.bakeyournoodle.com] has joined #xen
04:41	\|-\|	SLot [~SLot___@gustavo.gruposim.com.br] has quit [Ping timeout: 480 seconds]
04:51	\|-\|	SLot [~SLot___@gustavo.gruposim.com.br] has joined #xen
05:21	\|-\|	bernarde [~bernarde@201.72.60.80] has joined #xen
05:36	\|-\|	cableman [~cableman@3e6b7156.rev.stofanet.dk] has joined #xen
05:36	\|-\|	pvanhoof [~pvanhoof@d54C0EE14.access.telenet.be] has joined #xen
05:44	\|-\|	cableman [~cableman@3e6b7156.rev.stofanet.dk] has quit [Remote host closed the connection]
05:53	\|-\|	cableman [~cableman@3e6b7156.rev.stofanet.dk] has joined #xen
06:20	\|-\|	bernarde [~bernarde@201.72.60.80] has quit [Ping timeout: 480 seconds]
06:21	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has joined #xen
06:38	\|-\|	cableman [~cableman@3e6b7156.rev.stofanet.dk] has quit [Quit: Leaving]
07:05	\|-\|	cableman [~cableman@3e6b7156.rev.stofanet.dk] has joined #xen
07:13	\|-\|	danp1 [~berrange@pool-72-93-175-181.bstnma.east.verizon.net] has joined #xen
07:20	\|-\|	mday_away changed nick to mdday
07:27	\|-\|	mastermind [~mastermin@mastermind.kaltenbrunner.cc] has joined #xen
07:29	\|-\|	bernarde [~bernarde@201.72.60.80] has joined #xen
08:00	\|-\|	riel changed nick to surriel
08:25	\|-\|	clalance [~clalance@nat-pool-bos.redhat.com] has joined #xen
08:25	\|-\|	danp1 [~berrange@pool-72-93-175-181.bstnma.east.verizon.net] has left #xen []
08:27	\|-\|	ivan [~ikelly@5ac1970d.bb.sky.com] has joined #xen
08:39	\|-\|	unriel changed nick to riel
08:45	\|-\|	sdague_ changed nick to sdague
08:54	\|-\|	hollisb [~hollisb@bi01p1.co.us.ibm.com] has joined #xen
08:54	\|-\|	gerrit [~gerrit@c-67-160-146-170.hsd1.or.comcast.net] has joined #xen
09:58	\|-\|	danp1 [~berrange@pool-72-93-175-181.bstnma.east.verizon.net] has joined #xen
09:58	\|-\|	danp1 [~berrange@pool-72-93-175-181.bstnma.east.verizon.net] has left #xen []
10:04	\|-\|	schultmc_ [~schultmc@zealot.progeny.com] has joined #xen
10:15	\|-\|	jimix [~jimix@c-67-189-187-152.hsd1.ma.comcast.net] has joined #xen
10:17	\|-\|	ahs3_away changed nick to ahs3
10:21	\|-\|	rharper [~rharper@bi01p1.co.us.ibm.com] has joined #xen
10:32	<hollisb>	jimix: btw, are you seeing any getty problems in dom0 right now? I am...
10:33	<jimix>	hollisb: no.. jerone and I found out that the firewall init script never returns and so init can't run getty
10:33	<jimix>	could that be your problem as well?
10:33	<hollisb>	hmmm
10:34	<jimix>	hollisb: but if it worked before then thats prolly not it
10:34	<hollisb>	I was "hung" after xinetd before, but right now it's after cron
10:34	<jimix>	can you ssh in?
10:34	<hollisb>	yeah
10:35	<jimix>	hollisb: ps -efw \|grep init.d
10:35	<jimix>	see if there are any init scripts still on
10:35	<jimix>	I have not updated in a while
10:35	<hollisb>	yup, firewall
10:36	<jimix>	yeah.. its no in our static config
10:36	<jimix>	I think jerone was gonna test a config with it and send a patch if it worked
10:37	<hollisb>	ok
10:39	\|-\|	jerone [~jerone@bi01p1.co.us.ibm.com] has joined #xen
10:41	<hollisb>	jerone: looks like domU starts fine without my patch
10:41	<hollisb>	jerone: although init gets hung instantly
10:41	<jerone>	hollisb: let me grab the latest source and see how that does
10:42	<jerone>	not sure how old the version I have is .. I don't think it's that old .. but if it works for you I've got something wrong here
10:42	<hollisb>	maybe I have a bad console
10:43	<hollisb>	cursed xencons=foo
10:43	\|-\|	rpg_ [~rpg@cpe-70-122-40-44.austin.res.rr.com] has joined #xen
10:44	\|-\|	rpg [~rpg@cpe-70-122-40-44.austin.res.rr.com] has quit [Ping timeout: 480 seconds]
10:46	\|-\|	schultmc_ [~schultmc@zealot.progeny.com] has quit [Quit: Client exiting]
10:52	\|-\|	zwane_work [~zwane@S0106001217d33fa6.vc.shawcable.net] has quit [Read error: Operation timed out]
11:02	\|-\|	stekloff [~stekloff@bi01p1.co.us.ibm.com] has joined #xen
11:06	\|-\|	Basic_py [~Basic@warden.real-time.com] has quit [Quit: Leaving]
11:06	\|-\|	cableman [~cableman@3e6b7156.rev.stofanet.dk] has quit [Quit: Leaving]
11:07	<jimix>	hollisb: I thought you prob was with dom0?
11:07	<hollisb>	jimix: I have many problems :(
11:11	\|-\|	ahs3 changed nick to ahs3_away
11:13	\|-\|	aliguori [~anthony@cpe-70-112-17-156.austin.res.rr.com] has quit [Quit: Leaving]
11:17	\|-\|	ahs3_away changed nick to ahs3
11:19	<jimix>	hollisb: this is with the latest merge?
11:20	<hollisb>	I did a merge a couple days ago and that has even more problems
11:20	<hollisb>	(haven't pushed it)
11:21	<hollisb>	xm destroy crashes the hypervisor
11:21	<hollisb>	sigh
11:21	<jimix>	BTW: http://xenbits.xensource.com/linux-2.6-xen.hg is way old.. is there a new one?
11:21	<@MarkW>	riel: By the way WinXP install worked on my post-3.0.4 xen-unstable.hg. You should try it - it's cute, I've been browsing the net with IE 6.
11:22	<jimix>	hollisb: crash or hang?
11:22	<hollisb>	jimix: hang actually
11:23	<@MarkW>	jimix: There must be a tree (or at least patches) for the paravirt_ops infrastructure somewhere, which would be newer than that tree.
11:23	<@MarkW>	jimix: But I can't see I can remember seeing them anywhere...
11:23	<jimix>	MarkW: I seem to recall that there would be a new tree
11:24	<@MarkW>	Mmmm.
11:25	<jimix>	ext/ is pretty old as well
11:26	<@MarkW>	jimix: I'm Googling... paravirt_ops patches are coming from somewhere
11:26	<jimix>	unless cdub is keep ing a git tree somewhere ohpleaseohpleaseohplease
11:26	<@MarkW>	so somebody definitely has a more up-to-date tree!
11:26	<icblenke>	hg'ing a git tree. think of it.
11:27	\|-\|	aliguori [~anthony@bi01p1.co.us.ibm.com] has joined #xen
11:27	<jimix>	icblenke: we do it all the time on kernel.org
11:27	<icblenke>	you put a git tree under management of another revision control system?
11:28	<@MarkW>	jimix: http://ozlabs.org/~rusty/paravirt/ seems to contain patches of a relevant nature
11:28	<hollisb>	icblenke: you can use tools to convert repositories from one format to another
11:28	<hollisb>	icblenke: such as tailor
11:28	<@MarkW>	Not quite sure how official they are, but rusty was (one of) the guy(s) who was working on the paravirt_ops implementation...
11:29	<icblenke>	I've imported my fair share of CVS to SVN, and I know how painful/limiting that can be. Converting from git to mercurial must be "interesting".
11:29	<jimix>	icblenke: ther are scripts that get kicked off by git-pushes that keep http://www.kernel.org/hg/linux-2.6/ in sync
11:29	<icblenke>	ah!
11:30	<jimix>	I dunno if it is on every push or some cron event, but its pretty reliable
11:31	<icblenke>	still, mapping a mercurial changeset into a git changeset.. not a trival action. a patch? sure. but that's different.
11:32	<jimix>	MarkW: dunno if I want to base a tree off rusty, I'd be surprised if he encouraged me to do so :)
11:37	\|-\|	jimix [~jimix@c-67-189-187-152.hsd1.ma.comcast.net] has quit [Quit: jimix]
11:37	\|-\|	jimix [~jimix@c-67-189-187-152.hsd1.ny.comcast.net] has joined #xen
11:41	\|-\|	zwane_work [~zwane@h70-68-160-192.sbm.shawcable.net] has joined #xen
11:50	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has joined #xen
12:01	<@MarkW>	jimix: True :-) I can imagine the way Rusty might phrase his response ;-)
12:02	<@MarkW>	icblenke: the hg code for conversion basically reads out all the changeset, applies them and then commits them to hg I think
12:02	<@MarkW>	icblenke: keeping a mapping of past git->hg changeset mappings, I think...
12:03	<@MarkW>	jimix: Couldn't find an actual hg tree for you. Maybe it's not public (!?). Might be best to ask on xen-devel
12:03	\|-\|	athomas [~athomas@host86-134-167-36.range86-134.btcentralplus.com] has quit [Quit: Leaving]
12:03	<jimix>	thanks MarkW
12:23	<icblenke>	anyone hear of fabric7 before?
12:28	\|-\|	ns [~niv@bi01p1.co.us.ibm.com] has joined #xen
12:29	<icblenke>	I'm trying to understand Virtual Iron's vnic and network assignment.. did they implement vnet, is a vnet nothing more than a vif, or is there another driver here. who knows.
12:46	<@MarkW>	icblenke: what's fabric7?
12:48	<icblenke>	some company that uses virtual iron to offer virtualized hardware solutions or something. stumbled upon them when googling.
12:48	<@MarkW>	icblenke: actually, virtualiron.com is announcing a partnership with them in frontpage news
12:49	<@MarkW>	must be good
12:50	<@MarkW>	Gah, virtual iron have an annoying website
12:50	<@MarkW>	Why would I have to register just to read about what their product is???
12:51	<riel>	maybe they just don't want customers?
12:52	<@MarkW>	riel: Yay!
12:52	<@MarkW>	That sounds like an excellent strategy :-)
12:54	<icblenke>	their forums are a joke.
12:54	<icblenke>	the "virtual ethernet switch" thing just posted to their blog sounds a lot like vnet (which was disabled earlier this year in Xen proper as "crufty, buggy, and orphaned").
12:56	<aliguori>	MarkW: the rusty's paravirt tree is only really applicable anymore for the Xen paravirt_ops implementation and lhype
12:56	<aliguori>	as paravirt_ops infrastructure and VMI's paravirt_ops implementation is in 2.6.20-rc2-mm
12:57	<mastermind>	icblenke: i heard about them a while ago - the are building real large Opteron based boxes
12:58	<@MarkW>	aliguori: I was assuming jimix was after something representing a reasonably current attempt at a mainline merge... I'm not sure if that's it, but it's more like it than anything else I could find!
12:58	<@MarkW>	aliguori: I thought paravirt_ops went into Linus' tree already?
12:58	<aliguori>	MarkW: yup
12:58	<aliguori>	i haven't checked to see if VMI is there yet
12:58	<aliguori>	i couldn't get at his git tree last night
12:59	<aliguori>	i didn't realize until last night that VMI was in -mm
12:59	<@MarkW>	aliguori: I hadn't heard of it being in there but hadn't thought to look
12:59	<@MarkW>	no, neither did I
12:59	<@MarkW>	kernel.org/git seems to be down a lot lately
12:59	<aliguori>	still can't get to his git tree :-(
12:59	<aliguori>	oh
12:59	<aliguori>	hg mirror
12:59	<aliguori>	let me check that
13:00	<aliguori>	i don't think i can get to kernel.org at all
13:00	<aliguori>	:-(
13:00	<aliguori>	there we go
13:01	\|-\|	jimix [~jimix@c-67-189-187-152.hsd1.ny.comcast.net] has quit [Quit: jimix]
13:02	[~]	MarkW is running 3 centos domUs, 1 netbsd domU, 1 centos HVM and 1 windows HVM
13:03	<@MarkW>	I'm enjoying this. Particularly since I only discovered I had SVM hardware yesterday during random grepping of boot output :-)
13:03	<@MarkW>	aliguori: Great job on the VNCable displays, by the way. Way cool.
13:04	<aliguori>	MarkW: thanks :-)
13:04	<@MarkW>	and really useful for getting at the OSes without being at my test machine keyboard.
13:04	<@MarkW>	btw, does / should / can VNC send some kind of resize event when the HVM guest resizes its display?
13:05	<aliguori>	MarkW: yup
13:05	<aliguori>	and it does
13:05	<aliguori>	you just are using a client that doesn't support it :-)
13:05	<@MarkW>	OK. My client is buggy, then :-)
13:05	<aliguori>	probably xtightvncviewer
13:05	<@MarkW>	I'm using krdc
13:05	<aliguori>	oh
13:05	<aliguori>	never heard of that one
13:05	<@MarkW>	KDE client
13:05	<aliguori>	the realvnc client works with DesktopResize
13:05	<@MarkW>	May well be xtightvncviewer underneath...
13:05	<@MarkW>	But it rather rocks in its own way.
13:05	<aliguori>	man, kernel.org is crawling
13:06	<@MarkW>	Can scale down windows really small and they still work... I don't know if you can do that on other clients.
13:06	<aliguori>	MarkW: it's a relatively new extension so any client based on the older vnc code will probably not have it
13:06	<@MarkW>	I have a 4" x 3" windows running in the top corner of my screen
13:07	<aliguori>	:-)
13:07	<aliguori>	okay, vmi is not yet in linus' tree
13:07	<@MarkW>	Actually, with always on top, could be quite nice for monitoring when installs are done
13:07	<@MarkW>	I wish there were such a thing as "multivncviewer" though
13:07	<aliguori>	?
13:07	<@MarkW>	Giving me live updated scaled views of a load of VNC displays
13:08	<hollisb>	aliguori writes vnc viewers in his sleep
13:08	<aliguori>	hehe
13:08	<@MarkW>	Down one side of the screen
13:08	<@MarkW>	Adn then click on one to get a fullsize console.
13:08	<aliguori>	well, my current vnc viewer doesn't do software scaling
13:08	<aliguori>	MarkW: yeah, I've thought of that. my old client did software scaling so I actually had implemented something like that
13:08	<@MarkW>	Doesn't sound too hard to do in principle (in fact, a KDE implementation could probably just embed loads of krdc inside other windows)
13:08	<aliguori>	scaling down that small though looks pretty crappy
13:08	<hollisb>	Apple can do it... :-P
13:09	<aliguori>	they use hardware scaling
13:09	<@MarkW>	Scaling here is actually looking not too bad...
13:09	[~]	MarkW navigates to a 1.5" tall slashdot
13:09	<aliguori>	i was using bilinear interpolation. that doesn't look too bad provided you stay in the 50%-200% window
13:09	<@MarkW>	It's like being in lilliput
13:09	<aliguori>	hehe
13:10	<@MarkW>	I can read the ads.
13:10	<hollisb>	:)
13:10	<@MarkW>	Hang on, I'll screenshot this for posterity :-)
13:10	<aliguori>	fast software scaling requires mmx foo which scares me
13:13	<@MarkW>	I assume the client I have just uses libraries of some kind...
13:13	<@MarkW>	It's really pretty good scaling
13:13	<@MarkW>	and I wouldn't have thought it was custom code for that app
13:13	<aliguori>	MarkW: you may be surprised. i know the gtk libs don't support scaling an image that updates only partial bits
13:14	<aliguori>	you end up with weird black edges around the updates
13:14	<aliguori>	b/c software scaling depends on pixels around the scaled pixel...
13:14	<aliguori>	so you have to consciously support scaling a subportion of an image to be displayed within the main image
13:14	<aliguori>	it turns out to be rather non-trivial
13:14	<aliguori>	they may just scale the whole image every time but that eats cpu
13:17	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has quit [Quit: Leaving]
13:20	<@MarkW>	http://www.cl.cam.ac.uk/~maw48/tiny-virtual-machines.png
13:20	<@MarkW>	Here we are
13:20	<@MarkW>	aliguori: Yes, that does some somewhat scary, hadn't thought of that.
13:21	<@MarkW>	The scaling I have running on here is OK for monitoring what VMs are doing via a thumbnail, or even for using them (if the scale isn't too tiny)
13:21	<@MarkW>	I browsed to /. on the Windows VM without scaling up, but it was slightly fiddly.
13:23	<aliguori>	:-)
13:25	<icblenke>	I haven't seen krdc's scaling in any other opensource vnc client.
13:25	<@MarkW>	This is why I use it
13:25	<@MarkW>	It's got a few other nice UI features, but that's the real winner
13:28	<icblenke>	makes for a great way to remote control the mac mini at 1920x1080 from my 1280x960 linux laptop in full screen. things are a bit blurry, but it works splendidly.
13:28	<@MarkW>	Aha, how about this?
13:28	<@MarkW>	http://www.alpha.co.jp/biz/rdg/multivnc/english/index.html
13:30	<icblenke>	hadn't tried that one.
13:31	<@MarkW>	I'm about to
13:31	<@MarkW>	Looks like it'd be good for virtual machine management...
13:35	<aliguori>	MarkW: if you ever get bored http://hg.codemonkey.ws/vnc-gui/
13:35	<aliguori>	it's a GTK VNC widget
13:35	<aliguori>	all properly asynchronous
13:35	<@MarkW>	aliguori: Thanks
13:35	<aliguori>	so you can have any number of them in their own gui
13:36	<aliguori>	plus, it supports my VNC virtualization extensions :-)
13:37	<@MarkW>	I've never programmed for GTK before
13:37	<@MarkW>	Maybe I should give it a go sometime
13:39	<riel>	resizing VNC is an awesome idea
13:39	<riel>	which program are you using for that?
13:40	<aliguori>	MarkW: it's got proper pygtk bindings too :-)
13:41	<@MarkW>	Sweet.
13:41	<@MarkW>	riel: In the screenshot above I'm using krdc, KDE client for RDP and RFB
13:41	<riel>	and it resizes? neat
13:42	<@MarkW>	Yep.
13:42	<@MarkW>	It also scales input events so you can still interact properly with it.
13:42	<@MarkW>	Tiny tiny Windows XP :-)
13:42	<@MarkW>	Hmmm
13:43	<@MarkW>	Am looking at multivnc. It looks clever, but the manual is in Japanese and I'm not entirely sure what I'm meant to be doing.
13:47	<@MarkW>	Even a tabbed viewer would be an improvement on normal vnc TBH. That ought to be easy to knock up in pygtk
13:47	<aliguori>	MarkW: yup. you could even use the xend API to figure out what ports to connect to
13:48	<aliguori>	although there's always virt-manager
13:48	<@MarkW>	That said... one we've done that, we've got something pretty much like virt-manager
13:48	<@MarkW>	Snap :-)
13:48	<@MarkW>	Can virt manager connect to a remote host?
13:48	<aliguori>	you'd have to ask danpb
13:49	<@MarkW>	danpb: Hi Dan... Could you tell me if virt-manager can connect to a remote host to manage?
13:52	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has joined #xen
14:17	\|-\|	cableman [~cableman@3e6b6dca.rev.stofanet.dk] has joined #xen
14:23	\|-\|	gerrit [~gerrit@c-67-160-146-170.hsd1.or.comcast.net] has quit [Ping timeout: 480 seconds]
14:42	[~]	aliguori kicks xen
14:43	<aliguori>	is anyone doing hvm domains with vt on unstable?
14:43	<aliguori>	i can't seem to boot my fc5 vm
14:43	<aliguori>	normally, that's b/c my tree's broken but in this case, i'm on stock unstable :-)
14:56	\|-\|	clalance [~clalance@nat-pool-bos.redhat.com] has quit [Quit: Leaving]
14:58	\|-\|	gerrit [~gerrit@bi01p1.co.us.ibm.com] has joined #xen
15:05	\|-\|	bernarde [~bernarde@201.72.60.80] has quit [Remote host closed the connection]
15:59	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has quit [Ping timeout: 480 seconds]
16:05	<riel>	aliguori: looks like we're too late
16:06	<aliguori>	riel: ?
16:06	<riel>	Ingo already implemented some of the paravirt functionality on KVM
16:06	<riel>	just posted it to lkml
16:06	<aliguori>	hehe
16:06	<aliguori>	I knew he'd do that :-)
16:06	<riel>	MarkW: if you're not scared yet, you're not paying enough attention :)
16:06	<aliguori>	I was planning on spending tomorrow working on that. I was just playing with virtbench to get some good benchmarks to use to validate
16:07	<riel>	damn, his task switching could well be faster than Xen now
16:09	<aliguori>	wow
16:09	<aliguori>	he's been busy
16:09	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has joined #xen
16:11	<icblenke>	http://lkml.org/lkml/2007/1/5/205
16:14	<aliguori>	i suspect fork/exec will still be slow
16:14	<aliguori>	fork is currently about 10% of native (as measured by virtbench)
16:15	<aliguori>	but doing pte batching shouldn't be that difficult
16:17	<aliguori>	riel: he's actually using the cr3 caching in VT. i don't think there's an equiv in SVM
16:19	<riel>	no doubt AMD will put it there if they think it's useful
16:21	<murb>	hmm no Xen in the benchmarks.
16:22	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has quit [Quit: Leaving]
16:22	<riel>	that's ok, it's not like Linus is considering merging Xen in its current state
16:22	<riel>	and even if he wanted to, he couldn't, because there is no xen against his latest tree
16:23	\|-\|	jwb_gone [~jwboyer@rchp4.rochester.ibm.com] has quit [Remote host closed the connection]
16:24	\|-\|	danp1 [~berrange@pool-72-93-175-181.bstnma.east.verizon.net] has joined #xen
16:25	[~]	murb hopes Xensource realise they have real competition now
16:26	<icblenke>	linux on linux is still the primary target of the kvm/paravirt stuff.
16:27	<danp1>	MarkW: sorry, you were talking to my other nick earlier which is in the office...while i'm at home :-)
16:28	<danp1>	MarkW: virt-manager can in theory connect to XenD remotely
16:28	<danp1>	but we don't enable that functionality because XenD has zero authentication or encryption
16:28	<murb>	icblenke: what else other than linux runs realiably on Xen without hvm?
16:28	<aliguori>	danp1: sure it does, xml-rpc over ssh
16:28	<icblenke>	murb: freebsd, solaris, netbsd?
16:29	<murb>	icblenke: reliably the last time i checked.
16:29	<murb>	s/reliably/not &/
16:29	\|-\|	cableman [~cableman@3e6b6dca.rev.stofanet.dk] has quit [Quit: Leaving]
16:31	<danp1>	well, ok if you want to mess around with ssh tunnels, sure, but not natively
16:32	<aliguori>	danp1: i added an xmlrpc transport that launches a special helper that does xml-rpc over stdio. the idea was that you'd use ssh to launch the helper and then do xml-rpc over stdio
16:32	<aliguori>	danp1: any other approach IMHO is flawed (including the current junk in the API)
16:32	<aliguori>	a client implementation is provided in xmlrpclib2
16:33	<aliguori>	but libvirt still doesn't support xml-rpc right? so it's not really an option
16:33	<danp1>	why not just run TLS over the TCP socket its already creating
16:34	<aliguori>	b/c TLS is a PITA, and you still have to tie into PAM
16:34	<danp1>	the GNU-TLS apis are pretty trivial to integrate with sockets
16:34	<aliguori>	quite a lot of projects just use ssh.. like mercurial
16:34	<danp1>	well, i'm not convinced you want to neccessarily integrate with PAM
16:34	<aliguori>	plus, you need no additional ports
16:34	<danp1>	(at least not as the only option)
16:35	<aliguori>	danp1: you certainly want it as an option
16:35	<aliguori>	any moderately large enterprise is going to have some sort of single sign on environment
16:35	<aliguori>	using pam to tie into that makes life a lot easier
16:36	<danp1>	yes, for many places its applicable, but do you neccessarily want your XenD management accounts mapped to your UNIX accounts
16:36	\|-\|	riel changed nick to unriel
16:37	<icblenke>	that's not necessarily required.
16:39	<icblenke>	meaning, you can still use PAM and have it completely independant of any other system auth.
16:40	<danp1>	icblenke: so you end up having to have 2 ssh daemons ?!?!
16:40	<danp1>	one for regular logins using system auth, and another using a different pam config for when you're tunnelling to XenD ?
16:41	\|-\|	clalance [~clalance@pool-151-203-37-10.bos.east.verizon.net] has joined #xen
16:41	<icblenke>	that would be a bit odd, but sure, you _could_ do that.
16:43	<icblenke>	you could also setup an SSL stunnel with client certs. or any number of other things.
16:43	<danp1>	i'd rather use TLS natively within the app for the wire encryption & connection setup, and then PAM to do auth rather than trying to rely on SSH
16:43	<icblenke>	add your own VNC extension.
16:43	<danp1>	icblenke: yeah, that's basically what using GNU TLS would be doing
16:44	<aliguori>	you know, i'm pretty sure that context switching under kvm would be faster than xen
16:44	<aliguori>	b/c setting cr3 always has to trap in xen
16:44	<aliguori>	but if you hit the cr3 cache provided by vt
16:45	<aliguori>	you don't have to trap at all
16:45	<icblenke>	again, only vt though.
16:45	<danp1>	aliguori: couldn't Xen be adapted to make use of the cr3 cache for paravirt too ?
16:46	<icblenke>	danp1: HVM would need paravirt first. Then the guest would need to be aware that it is VT instead of SVM, and work with Xen to setup that cr3 cache as appropriate.
16:47	<icblenke>	(if I'm understanding what you're saying)
16:48	<aliguori>	danp1: xen would have to be switched to running a guest in VT mode
16:48	<aliguori>	icblenke: yeah
16:48	<aliguori>	you could certainly do it to xen HVM...
16:48	<icblenke>	speaking of which, someone was talking about HVM paravirt ops at some point...
16:49	<aliguori>	yeah, it's been discussed a lot lately
16:49	<aliguori>	this is what ingo is doign
16:49	<aliguori>	but not with xen
16:50	<danp1>	getting paravirt_ops upstream has really let the virtualization genie out of the bottle
16:50	<danp1>	all sorts of fun and interesting developments are going on now...
16:50	<aliguori>	yeah, definitely
16:54	<danp1>	aliguori: BTW, what license are you putting your gtk-vnc client under ?
16:54	<danp1>	the HG repo doesn't have any license info
16:54	<aliguori>	danp1: oh, sorry, LGPL
16:54	<danp1>	and i was wondering if it was going to be GPL compatible
16:54	<danp1>	so i could try using it from virt-manager
16:54	<danp1>	ah, LGPL is great
16:54	\|-\|	Shaun2222 [~Shaun@ip68-4-212-221.oc.oc.cox.net] has joined #xen
16:55	<aliguori>	danp1: it probably needs a fair bit of testing but let me know if you it works for you and I can spend some time on it
16:56	<aliguori>	I really don't like the way it's structured now. I didn't really understand how to create gobjects at the time i wrote it. I'd love to spend some time rewriting the protocols bits to be a proper gobject
16:56	<Shaun2222>	how is support for 64bit+PAE? I know at one point it wasnt really all that supported very well.
16:57	<danp1>	aliguori: it seems to do all its I/O processing from a g_idle handler
16:57	<danp1>	aliguori: any reason you didn't just have a regular I/O watch instead ?
16:57	<icblenke>	64bit doesn't need PAE. what do you mean by that? running PVs? no. HVMs, yes. you can run a 32bit+pae under a 64bit hypervisor/dom0 with HVM.
16:58	<Shaun2222>	hmm, now that you said that i do recall hearing that 64bit doesnt need PAE.
16:58	<aliguori>	danp1: it's actually a fair bit trickier than that. it uses coroutines (think cooperative userspace threads) b/c writing a truly asynchronous vnc client is a nightmare
16:58	<aliguori>	and i strongly dislike preemptive threads
16:59	\|-\|	danp1 [~berrange@pool-72-93-175-181.bstnma.east.verizon.net] has quit [Remote host closed the connection]
16:59	<hollisb>	coroutines in C though: those aren't a nightmare :-P
17:00	<Shaun2222>	with a 64bit xen dom0/hv can i run both 32bit and 64bit guests?
17:01	\|-\|	danp1 [~berrange@pool-72-93-175-181.bstnma.east.verizon.net] has joined #xen
17:01	<icblenke>	yes.
17:03	<aliguori>	hollisb: i can send you a paper i wrote that suggests otherwise if you'd like :-)
17:04	<hollisb>	I think you already sent it to me :)
17:07	<aliguori>	hollisb: no, i can send out the full paper now :-) that was just the abstract
17:08	<hollisb>	oh good ;)
17:08	\|-\|	surriel changed nick to riel
17:09	\|-\|	aliguori [~anthony@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
17:12	\|-\|	mdday changed nick to mday_away
17:16	\|-\|	movement [~moz@81.168.41.234] has quit [Ping timeout: 480 seconds]
17:20	\|-\|	rharper [~rharper@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
17:25	\|-\|	movement [~moz@82.153.37.79] has joined #xen
17:38	\|-\|	aliguori [~anthony@cpe-70-112-17-156.austin.res.rr.com] has joined #xen
18:03	\|-\|	hollisb [~hollisb@bi01p1.co.us.ibm.com] has quit [Quit: leaving]
18:03	\|-\|	jerone [~jerone@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
18:06	\|-\|	stekloff [~stekloff@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
18:19	\|-\|	pvanhoof [~pvanhoof@d54C0EE14.access.telenet.be] has quit [Remote host closed the connection]
18:31	\|-\|	ns [~niv@bi01p1.co.us.ibm.com] has quit [Quit: .]
18:39	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has quit [Quit: Leaving]
18:52	\|-\|	gerrit [~gerrit@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
19:03	\|-\|	gerrit [~gerrit@bi01p1.co.us.ibm.com] has joined #xen
19:08	<@MarkW>	riel: Yes, I am worried :-)
19:09	<riel>	you should be :)
19:09	<riel>	I need to find a weekend or two to add steal time accounting to paravirt KVM
19:10	<@MarkW>	Well, hopefully the 2.6 merge process will keep shifting along and actually complete at some point!
19:11	<riel>	even then - Xen has trouble with ACPI, cpu frequency scaling, laptop suspend/resume and a few more details
19:11	<riel>	I'm not sure how those can be fixed without making Xen a loadable module
19:11	<@MarkW>	True, true.
19:14	\|-\|	gerrit [~gerrit@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
19:16	\|-\|	zwane_work [~zwane@h70-68-160-192.sbm.shawcable.net] has quit [Ping timeout: 480 seconds]
19:17	<@MarkW>	I dunno...
19:17	<@MarkW>	stubs in Xen should be able to deal with all those problems
19:17	<@MarkW>	It's just a question of whether that's a good direction in which to go.
19:17	<@MarkW>	There were good reasons for Xen being separate from Linux originally, but I think the number of such reasons is less now than it was then...
19:20	<riel>	64 bit address space has gotten rid of the main reason I can think of
19:21	<riel>	the loss of address space under 32 bit UML was a pain
19:23	<@MarkW>	Well, the hard scheduler guarantees from a hypervisor are part of the design
19:24	<@MarkW>	But that arguably was more important for the XenoServers project
19:24	<@MarkW>	Although still nice to have on a server...
19:26	<@MarkW>	Same for the fixed guarantees on memory by eliminating swapping
19:26	<@MarkW>	But that's also a mixed blessing.
19:50	<aliguori>	MarkW: this is really just the classic micro vs macro kernel debate
19:50	<aliguori>	and unfortunately, i fear that xen will lose just like microkernels have traditionally lost
19:51	<aliguori>	like microkernels, xen will continue to play a role but i don't think it will ever be pervasive
19:51	<riel>	well, you can give most those scheduling guarantees in Linux too
19:52	<riel>	and yes, the fixed guarantees to eliminate swapping are a good thing, but that can be duplicated with KVM too if we want
19:52	<riel>	eliminate swapping for cooperative OSes
19:52	<riel>	swap out uncooperative ones
19:56	\|-\|	danp1 [~berrange@pool-72-93-175-181.bstnma.east.verizon.net] has left #xen []
19:58	\|-\|	cdub [~chrisw@cdub.netrep.oftc.net] has quit [Read error: Operation timed out]
19:58	\|-\|	Basic_py [~Basic@warden.real-time.com] has joined #xen
19:59	\|-\|	zwane_work [~zwane@S0106001217d33fa6.vc.shawcable.net] has joined #xen
20:04	\|-\|	cdub [~chrisw@216-99-217-87.dsl.aracnet.com] has joined #xen
20:13	\|-\|	rpg_ [~rpg@cpe-70-122-40-44.austin.res.rr.com] has quit [Remote host closed the connection]
20:17	<@MarkW>	Well, it's not just micro vs macro
20:17	<@MarkW>	I think it's also mainstream OS vs niche OS
20:18	<@MarkW>	In that the main issues seem to be HW support and ease of installation - and both of those are pretty much solved if you get them from a mainstream OS like Linux
20:19	<@MarkW>	And otherwise you have to play catchup
20:22	<@MarkW>	It'd be nice if Xen could capitalise on it's not being in Linux a little more: e.g. handoff directly into a stub domain for the device models to avoid a full context switch on IO, which would maybe be harder to do in a Linux process.
20:24	<aliguori>	MarkW: actually, it's easier in linux :-/
20:24	<aliguori>	vmexit's go directly to the linux kernel, which goes directly to userspace
20:24	<@MarkW>	aliguori: How so?
20:24	<aliguori>	vmexits have to go to the hypervisor
20:24	<aliguori>	b/c of the nature of VT
20:24	<@MarkW>	Sure.
20:24	<aliguori>	so best case scenario, xen goes to a stub domain running in ring 1
20:24	<aliguori>	that handles the vmexit
20:24	<aliguori>	but that's still no better than linux
20:25	<@MarkW>	Yeah I guess not.
20:25	<aliguori>	and you've got the added complexity of dealing with a new os
20:25	<@MarkW>	Well, hang on...
20:25	<@MarkW>	where does the memory for the guest actually come from under KVM?
20:25	<@MarkW>	Is it process memory?
20:25	<aliguori>	MarkW: it's allocated by the kernel and mmap() by the process
20:26	<@MarkW>	Mmm OK.
20:26	<@MarkW>	So the process still has its own complete context available to switch back into.
20:26	<aliguori>	MarkW: yeah
20:26	<@MarkW>	Yeah, that is just as good.
20:26	<aliguori>	and the way KVM is structured, when the VMEXIT occurs, the process' memory space is still loaded
20:26	<aliguori>	so there's no tlb flushing beyond the world switch
20:27	<@MarkW>	As it should be
20:27	<@MarkW>	Nice
20:27	<aliguori>	turns out in Xen, everything has to go through both the Linux and Xen scheduler
20:27	<aliguori>	so VMEXIT handling in Xen is significantly more costly
20:27	<aliguori>	something like 60k additional cycles
20:27	<aliguori>	for something that only needs to take around 5k
20:28	<aliguori>	(or 30k depending on the age of the hardware you have)
20:28	<@MarkW>	wheh?
20:29	<aliguori>	we aren't 100% sure where that time is being spent but my guess is that it's split in the two schedulers
20:29	<aliguori>	we're doing profiling to try and figure it out
20:29	<aliguori>	should know soon
20:29	<@MarkW>	are we talking regarding userland device models now?
20:29	<aliguori>	yes
20:29	<@MarkW>	Yes.
20:29	<@MarkW>	I'm not surprised that's crappy.
20:30	<@MarkW>	It pretty much ought to be crappy.
20:30	<aliguori>	but my suspicion is that a good amount of that 60k is actually from Xen
20:30	<@MarkW>	stub domains for the win.
20:30	<aliguori>	not just the Linux kernel
20:30	<aliguori>	stub domain kills disk performance though
20:30	<@MarkW>	Well, having to reschedule at all to do IO is pants.
20:30	<@MarkW>	Why would it kill disk?
20:30	<aliguori>	ide can only handle one transaction at a time
20:30	<@MarkW>	I don't see how it could possibly be worse than what we have now...
20:30	<aliguori>	and since stub domain goes through blkback/blkfront, which is optimized for batching
20:31	<aliguori>	you get the new overhead of going through that driver without any benefit of batching
20:31	<aliguori>	since everything has to be serial
20:31	<@MarkW>	OK.
20:31	<@MarkW>	Surely not worse than doing the same but bouncing through userspace, though?
20:31	<aliguori>	we have numbers but i don't have them on hand. it's the only thing that really affects performance with a stub domain
20:31	\|-\|	gerrit [~gerrit@c-67-160-146-170.hsd1.or.comcast.net] has joined #xen
20:31	<aliguori>	MarkW: worse than being in dom0
20:32	<@MarkW>	Blimey.
20:32	<@MarkW>	That's quite a feat... how does it manage that?
20:32	<aliguori>	MarkW: we've got a prototype stub domain implementation. uses a full linux domain and runs the qemu-dm in that domain instead of dom0
20:32	<@MarkW>	Ah OK.
20:32	<@MarkW>	Well I can see why that would be worse!
20:32	<@MarkW>	I really meant stub domains qemu+minios
20:32	<aliguori>	i still contend that just pushing everything into minios won't make that much of a difference
20:33	<aliguori>	but i'll be able to prove that soon :-)
20:33	<@MarkW>	which obviously doesn't fix the batching but is less bad than bouncing into userspace
20:33	<@MarkW>	I'd be really surprised if stub domain fundamentally adds overhead relative to the current model
20:33	<aliguori>	MarkW: a context switch is pretty light (worse case, a few thousand cycles). literally nothing is running in the stub userspace so the scheduler shouldn't be involved
20:34	<aliguori>	just switching from the kernel to userspace in the stub domain can't possible cause 60k of overhead
20:34	<aliguori>	the variance is huge too
20:34	<aliguori>	like 20k cycles (standard deviation)
20:34	<@MarkW>	Maybe we should be looking at emulating a device with qemu that actually supports queuing.
20:35	<aliguori>	MarkW: yeah, we're on top of that too. qemu can do scsi emulation but we need to get the bios to actually support booting from it
20:35	<@MarkW>	Cool.
20:35	<@MarkW>	I still really can't think stub domains ought to be worse than what we have now (if done properly)
20:36	<@MarkW>	But I can believe they won't help much until the device model gets to use queuing.
20:36	<aliguori>	MarkW: "if done properly" is the key point :-) there's a lot of baggage in qemu-dm
20:37	<@MarkW>	Well, I was thinking we'd weed out anything too barking in the code (and this includes Xen if it's stuffing things up!)
20:37	<@MarkW>	Any latency we save by moving the emulator into a stub domain is, I suspect, unlikely to help performance
20:37	<@MarkW>	Since disks are high-latency anyway. Conversely, I'd imagine that using queuing but running the models in dom0 could still be a performance benefit
20:38	<aliguori>	MarkW: it's clear to me that we need some serious rearchitecting for HVM. it's hard to get folks on board with that though
20:38	<aliguori>	everyone wants to add S3 support, migration and save/restore
20:38	<aliguori>	no one wants to think about major refactorings
20:38	<@MarkW>	S3?
20:38	<aliguori>	they just want to keep adding crap
20:38	<aliguori>	software suspend
20:38	<@MarkW>	aliguori: I always feel somewhat upset when I see people are working on save/restore
20:38	<aliguori>	intel is working on it
20:38	<@MarkW>	for HVM
20:38	<@MarkW>	When if we had stub domains it would Just Work
20:39	<aliguori>	MarkW: right
20:39	<@MarkW>	As it is, most of that stuff will need to be thrown out if stub domains are ever put in place.
20:39	<@MarkW>	Vexing.
20:39	<aliguori>	MarkW: right
20:40	<@MarkW>	I agree completely with you there.
20:40	<aliguori>	but it's harder and harder to do it because the more features that get shoved into qemu-dm the harder is it to replace it without regressing feature
20:40	<aliguori>	and there are some forces that are going to fight hard against that...
20:40	<@MarkW>	Although there is the pragmatic concern that functionality is one of the major advantages that Xen has over other solutions at the moment
20:40	<@MarkW>	And hence rearchitecting might endanger that...
20:41	<@MarkW>	I'm sure that will have occurred to others, although nobody's said anything about that to me.
20:41	<aliguori>	it's tough
20:41	<aliguori>	HVM is in a tough spot right now
20:42	<@MarkW>	I have to say though
20:42	<@MarkW>	I'm quite impressed with what they've done - in that it all works.
20:42	<aliguori>	yeah
20:43	<@MarkW>	And it performs decently and it's reasonably nice to use.
20:43	<@MarkW>	I kinda wish people could have worked on stub domains instead of the save/restore in the current code
20:43	<aliguori>	yeah
20:43	<@MarkW>	as a means of achieving save/restore. But I guess that'd be harder and they didn't necessarily have the manpower...
20:44	<@MarkW>	But there all all sorts of reasons why stub domains just ought to happen
20:44	<aliguori>	one of the problems is that we don't tend to architect very well
20:44	<aliguori>	everybody kind of just works on things and when it's ready someone picks it up in the tree
20:44	<@MarkW>	And it''d probably be a good idea not to throw all the uses of stub domains into the mix together at once
20:44	<@MarkW>	aliguori: Architect? What's that?
20:44	<aliguori>	but there's no real agreed upon long term goals
20:44	<aliguori>	:-)
20:45	<@MarkW>	Indeed.
21:10	\|-\|	w3pog [~pgrace@aeneas.fierymoon.com] has joined #xen
21:11	<w3pog>	hello!
21:13	<w3pog>	anyone around who happens to be well-versed on having multiple dom0's on the same subnet? I have what I think is a pretty weird problem when I try to install a second dom0 in preparation for live migration
21:59	<aliguori>	danpb: btw, i meant to point you to http://hg.codemonkey.ws/gtk-vnc/ the other repo is old
22:01	\|-\|	gerrit [~gerrit@c-67-160-146-170.hsd1.or.comcast.net] has quit [Ping timeout: 480 seconds]
22:01	\|-\|	gerrit [~gerrit@c-67-160-146-170.hsd1.or.comcast.net] has joined #xen
22:09	\|-\|	zwane_work [~zwane@S0106001217d33fa6.vc.shawcable.net] has quit [Read error: Operation timed out]
22:30	\|-\|	ahs3 changed nick to ahs3_away
22:59	\|-\|	VS_ChanLog [~stats@ns.theshore.net] has left #xen [Rotating Logs]
22:59	\|-\|	VS_ChanLog [~stats@ns.theshore.net] has joined #xen
23:37	\|-\|	maxchock [~max@60.48.152.253] has joined #xen
23:37	<maxchock>	hi all
23:38	<maxchock>	i've problem using Xen, can someone help??
23:39	\|-\|	clalance [~clalance@pool-151-203-37-10.bos.east.verizon.net] has quit [Quit: Leaving]
23:40	<maxchock>	hello?? is someone here??
23:49	<maxchock>	??
23:54	<maxchock>	[root@gamesrv log][root@gamesrv log]# /usr/sbin/xm create -c vxp01
23:54	<maxchock>	Using config file "/etc/xen/vxp01".
23:54	<maxchock>	Started domain vxp01
23:54	<maxchock>	xenconsole: Could not read tty from store: No such file or directory
23:54	<maxchock>	i get the error mesg above when trying to run Xen
23:54	<maxchock>	anyone can help??
---	Log	closed Sat Jan 06 00:00:58 2007