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

---	Log	opened Thu Jan 04 00:00:51 2007
01:51	\|-\|	mastermind [~mastermin@mastermind.kaltenbrunner.cc] has quit [Quit: Client exiting]
02:23	\|-\|	WorkMonk [~Pirato@off.spillgroup.com] has joined #xen
02:23	<WorkMonk>	Hi
02:23	<WorkMonk>	I know that Hardware Virtualization needs to be supported to Run Windows natively in dom0
02:23	<WorkMonk>	however, in DomU, could i install windows?
02:31	<WorkMonk>	I run XenServer on Dom0, i install another Guest Xen machine and on that machine i install Windows
02:43	<perlmonkee>	Hardware virtualization needs to be supported to run windows of any kind in any capacity.
02:44	<perlmonkee>	and last I checked windows can't run as Dom0 at all - but I could be somehow mistaken.
02:50	<WorkMonk>	okey
02:50	<WorkMonk>	thanks
03:39	\|-\|	athomas [~athomas@host86-134-167-36.range86-134.btcentralplus.com] has joined #xen
04:16	\|-\|	buggs [~noidentd@shadow.splashground.de] has quit [Read error: Connection reset by peer]
04:17	\|-\|	buggs [~noidentd@shadow.splashground.de] has joined #xen
04:26	\|-\|	cableman [~cableman@3e6b7156.rev.stofanet.dk] has joined #xen
04:41	\|-\|	pvanhoof [~pvanhoof@d54C0EE14.access.telenet.be] has joined #xen
05:43	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has joined #xen
05:51	\|-\|	cableman [~cableman@3e6b7156.rev.stofanet.dk] has quit [Quit: Leaving]
05:52	\|-\|	cableman [~cableman@3e6b7156.rev.stofanet.dk] has joined #xen
05:57	\|-\|	danp1 [~berrange@pool-72-93-175-181.bstnma.east.verizon.net] has joined #xen
06:21	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has quit [Remote host closed the connection]
06:35	\|-\|	bernarde [~bernarde@201.72.60.80] has joined #xen
06:35	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has joined #xen
06:52	\|-\|	mday_away changed nick to mdday
07:52	<danp1>	anyone happen to know offhand if Solaris 10 x86 works under Xen 3.0.3 / 3.0.4 fully-virt ( HVM) ?
07:54	\|-\|	mdday [~mdday@cpe-024-163-122-235.nc.res.rr.com] has quit [Quit: Ex-Chat]
08:12	\|-\|	msinhore [~msinhore@mail.samurai.com.br] has joined #xen
08:27	\|-\|	bernarde [~bernarde@201.72.60.80] has quit [Read error: Connection reset by peer]
08:27	\|-\|	bernarde [~bernarde@201.72.60.80] has joined #xen
08:44	\|-\|	mdday [~mdday@bi01p1.nc.us.ibm.com] has joined #xen
08:45	\|-\|	mdday [~mdday@bi01p1.nc.us.ibm.com] has quit []
08:45	\|-\|	mdday [~mdday@bi01p1.nc.us.ibm.com] has joined #xen
09:00	\|-\|	mdday [~mdday@bi01p1.nc.us.ibm.com] has quit [Quit: mdday]
09:02	\|-\|	mdday [~mdday@bi01p1.nc.us.ibm.com] has joined #xen
09:10	\|-\|	jimix [~jimix@c-67-189-187-152.hsd1.ny.comcast.net] has joined #xen
09:21	\|-\|	rharper [~rharper@r74-193-70-77.pfvlcmta01.grtntx.tl.dh.suddenlink.net] has joined #xen
09:32	<icblenke>	danp1: Running now 32bit, I don't know about 64bit.
09:33	<icblenke>	I know that 32bit OpenSolaris can run PV under vanilla Xen, and I'm not sure if 3.0.4 fixes whatever shadow changes Sun has in their Xen tree that allowed 64bit PV operation.
09:33	<icblenke>	but, HVM, yes it works (though you need to do some driver updates).
09:34	<danp1>	icblenke: you doing HVM solaris under 3.0.3 or 3.0.4 ?
09:34	<icblenke>	I'm running HVM solaris 10 under 32bit 3.0.4 in a box in the lab now.
09:34	<icblenke>	it should work the same under 3.0.3.
09:34	<icblenke>	couldn't get SMP working though.
09:34	<danp1>	icblenke: not neccessarily really
09:34	<icblenke>	well, in theory ;)
09:35	<danp1>	there's been lots of HVM improvements between 3.0.3 & 3.0.4 which make many more OS work
09:35	<icblenke>	ah.
09:35	<icblenke>	I could revert to 3.0.3 and test.
09:35	<icblenke>	but, again, it would be only 32bit.
09:37	<danp1>	icblenke: na, its not important - i was just after a general idea of whether people have had it working
09:38	<danp1>	the fact that it works on 3.0.4 is enough info
10:02	\|-\|	mdday [~mdday@bi01p1.nc.us.ibm.com] has quit [Quit: mdday]
10:05	\|-\|	agrif_away changed nick to agriffis
10:10	\|-\|	mdday [~mdday@bi01p1.nc.us.ibm.com] has joined #xen
10:10	<tomaso>	hi, I'd like to send a small patch for libxc, is there a special mailinglist to discuss it or everything goes to xen-devel?
10:10	<muli>	xen-devel
10:10	<icblenke>	did you remove __thread from xc_private.c? ;)
10:14	<@MarkW>	Wooo! I just discovered I have SVM support on my machine. I hadn't realised ;-D
10:14	<danp1>	icblenke: that would be an incredibly bad idea given that xend is multi-threaded
10:14	<danp1>	and so needs __thread to ensure per-thread error reporting
10:16	<movement>	anyone good with the xmlrpc stuff? we're trying 3.0.4 and xm won't talk over it after a while
10:16	<movement>	(the legacy api)
10:16	<movement>	xend is getting EAGAIN somewhere in the xmlrpc code
10:17	<tomaso>	icblenke: no I just want to use xc_translate_foreign_address with cr3 provided by me (from outside) so I added additional func with one more parameter
10:17	\|-\|	hollisb [~hollisb@bi01p1.co.us.ibm.com] has joined #xen
10:18	\|-\|	mastermind [~mastermin@mastermind.kaltenbrunner.cc] has joined #xen
10:20	\|-\|	ahs3_away changed nick to ahs3
10:34	\|-\|	Netsplit osmosis.oftc.net <-> electron.oftc.net quits: tonyb
10:42	<@MarkW>	Anybody here got experience configuring HVM?
10:43	<@MarkW>	I'm having trouble geting the VNC display to export, but I really don't know why...
10:43	<icblenke>	sure. what do you mean by "export"? do you have a TCP listener on 5900+ ?
10:43	<danp1>	MarkW: yeah, what issue in particular ?
10:43	<danp1>	the vnc display will only bind to 127.0.0.1 by default
10:44	\|-\|	agriffis changed nick to agrif_away
10:44	<icblenke>	with 3.0.3, yes. 3.0.4 listens on INADDR_ANY, doesn't it?
10:44	<@MarkW>	I can start an HVM guest, I've changed the setting to bind to 0.0.0.0 by default
10:44	<@MarkW>	and guest guest appears to start. But there isn't a vnc port open...
10:44	<@MarkW>	scratches head
10:45	<icblenke>	netstat/lsof shows no 5900+ port listening? then qemu-dm isn't getting passed the right arguments, somehow.
10:45	<danp1>	you'd typically need something like:
10:45	\|-\|	zwane_work [~zwane@S0106001217d33fa6.vc.shawcable.net] has quit [Remote host closed the connection]
10:45	<danp1>	vnc=1
10:45	<danp1>	vncunused=1
10:45	<danp1>	vnclisten="0.0.0.0"
10:45	<danp1>	vncpasswd="123456"
10:46	<danp1>	which'll turn on VNC, tell it to allocate first unused port about 5900, listen on 0.0.0.0 and authenticate with password
10:46	<aliguori>	danp1: i sent a patch to qemu-devel recently to have the vnc server listen on a unix domain socket
10:46	<aliguori>	which was my answer to vncunused
10:46	<aliguori>	which i think is a pretty awkward way of solving the problem :-)
10:47	<@MarkW>	Hmmm.
10:47	<danp1>	aliguori: what i really need for qemu, is a monitor command to find out what port/path its listening for VNC on
10:47	<@MarkW>	I've tweaked the config to include sdl=1 instead.
10:48	<aliguori>	danp1: that's in my patch queue actually
10:48	<@MarkW>	And I just get a big white screen...
10:48	<aliguori>	http://hg.codemonkey.ws/qemu-pq
10:48	<danp1>	ah, cool
10:48	<aliguori>	i've got a bunch of management-related patches
10:48	<@MarkW>	I can switch to the monitor, etc, as usual. I just don't get any guest output...
10:48	<@MarkW>	Any ideas?
10:48	<aliguori>	danp1: one of my goals is to eliminate the need for a daemon btw
10:49	<icblenke>	MarkW: Is this with a PV with framebuffer? That's entirely new to me as well. No clue how that works.
10:49	<@MarkW>	Nah, this is HVM
10:49	<@MarkW>	I got PV with framebuffer working a couple of days ago
10:49	<danp1>	aliguori: how do you enumerate active & inactive domains ?
10:50	<aliguori>	danp1: i added a -gui option which introduces a number of conventions
10:50	<aliguori>	the monitor becomes unix:~/.qemu/$name/monitor.sock
10:50	<aliguori>	plus, you get a pidfile in the same path
10:50	<aliguori>	to enumerate domains, you simple enumerate ~/.qemu/* and try connecting to each monitor
10:51	<aliguori>	i've got another patch in the queue that makes reconnecting to the monitor deterministic
10:51	<danp1>	what about determining the qemu config ?
10:51	<danp1>	(to make it possible to generate a libvirt style XML description)
10:51	<aliguori>	danp1: plan is to make all that stuff enumerable from the monitor
10:55	<danp1>	MarkW: hmm, something seems rather badly wrong if neither the VNC or SDL displays are working
11:02	<@MarkW>	danpb: Yep :-)
11:02	\|-\|	aliguori [~anthony@cpe-70-112-17-156.austin.res.rr.com] has quit [Quit: Leaving]
11:03	\|-\|	rpg [~rpg@bi01p1.co.us.ibm.com] has joined #xen
11:03	<@MarkW>	I'm hoping maybe I missed some firmware out of the build... will build the tools and cross fingers.
11:05	<icblenke>	MarkW: regarding our netloop chat yesterday: if I don't use bridging, but I do allow domUs to use services directly on my dom0 using only a vif backend from the dom0 and a veth frontend in the domU, I am still facing the same DoS condition, right?
11:05	<@MarkW>	icblenke: I think so, yes. That's my understanding.
11:05	<icblenke>	wonderful. thanks.
11:07	<icblenke>	does 3.0.4's QEMU have the lba48 fixes yet? (for "drives" larger than 160G?)
11:07	<@MarkW>	icblenke: not sure...
11:11	<icblenke>	I'm working up a "Xen limitations" blog post, for the n00b questions that continue to manifest themselves in the "other" ##xen channel on freenode)
11:12	\|-\|	mdday [~mdday@bi01p1.nc.us.ibm.com] has quit [Quit: mdday]
11:13	<riel>	what is that DoS again?
11:13	<riel>	something to do with the guest not freeing up the ring buffers for the device?
11:13	<@MarkW>	riel: If grant mapped pages represent packets going to dom0
11:14	<danp1>	riel: yeah, its the guest being able to pin pages in dom0 indefinitely
11:14	<@MarkW>	then if they're not consumed and disposed of quickly enough
11:14	<icblenke>	there is a limited shared pool of pages between dom0 and a domU. as the frames are shuttled over the page-flipping using grants, those frames are referred to directly inside both kernel's skbs, shared until the dom0 releases it.
11:14	<@MarkW>	there's a resource crunch in dom0. I think it probably runs out of VM space to map other packets, but I haven't checked
11:14	<@MarkW>	riel: as long as packets are going out over the wire it's fine, if they're going to dom0 they need copying.
11:15	<icblenke>	meaning, if your dom0 is servicing the packets in userspace for whatever reason (a daemon service or whatever), you really should be using a netloop vif0.0/veth0 to offload those frames entirely into dom0.
11:16	\|-\|	aliguori [~anthony@bi01p1.co.us.ibm.com] has joined #xen
11:18	<icblenke>	which I think means you really need to use a bridge.
11:21	<@MarkW>	Gah! I've got a feeling I'm doing some reaaaaaaaaaaaally stupid.
11:21	<@MarkW>	But I don't know what it is...
11:22	<aliguori>	MarkW: what happens again?
11:23	<@MarkW>	aliguori: I can start an HVM domain, and xm list says it's running
11:23	<aliguori>	MarkW: is the qemu-dm process around?
11:23	<aliguori>	is it zombied?
11:23	<@MarkW>	aliguori: but if I use the vnc server, no display is ever exported, and if I use the sdl display the guest output is blank (the monitor appears, etc)
11:23	<@MarkW>	qemu-dm is running, afaics
11:23	<aliguori>	MarkW: my guess is that qemu-dm is crashing
11:24	<aliguori>	what's the guest and what's the version of xen (32b or 64b)?
11:24	<aliguori>	our qemu-dm patches are super frail
11:24	<@MarkW>	aliguori: Well, the SDL window responds to interaction, anyhow.
11:24	<@MarkW>	The Guest is a CentOS 4.4 I installed under Qemu
11:24	<aliguori>	MarkW: no matter what, you should at least see output from the BIOS
11:24	<@MarkW>	This is 32bit Xen on AMD64
11:24	<@MarkW>	aliguori: Exactly!
11:24	<aliguori>	is you aren't seeing that, it suggests things are pretty hosed
11:24	<@MarkW>	No BIOS output at all.
11:24	<@MarkW>	Yep.
11:24	<aliguori>	do you perhaps have a bad config?
11:25	<danp1>	MarkW: another possiblity is that qemu-dm is sitting there waiting for some xenbus event
11:25	<@MarkW>	hosed like a big hose thing
11:25	<aliguori>	an older one that doesn't point to hvmloader?
11:25	<danp1>	to complete before it carries on doing useful work
11:25	<@MarkW>	no, hvm loader is specified in there
11:25	<@MarkW>	danp1: that's a thought...
11:25	<aliguori>	MarkW: you know svm's been broken for some time?
11:25	<danp1>	might want to try getting a stack trace out of it with gdb to see if its wedged somewhere interesting
11:26	<aliguori>	I don't know if it works yet on unstable
11:26	<aliguori>	but it's even hosed in xenenterprise
11:26	<@MarkW>	I didn't know that...
11:26	<@MarkW>	What broke it?
11:26	<aliguori>	i don't kno
11:26	<aliguori>	w
11:26	<@MarkW>	And any idea when? :-)
11:26	<danp1>	aliguori: surely it was working in 3.0.4 which was only a couple of weeks ago
11:26	<aliguori>	i don't know if it works today or when it broke
11:26	<@MarkW>	hrmmmmm.
11:26	<aliguori>	danp1: is that because you tested it?
11:26	<aliguori>	or b/c you assume a certain amount of QA is being done :-)
11:27	<danp1>	the latter ;-)
11:27	<@MarkW>	well...
11:27	<@MarkW>	that's messed up!
11:27	<danp1>	XS do at least have some basic regression tests run on the tree everynight on a variety of hardware
11:27	<aliguori>	MarkW: are you on -unstable?
11:27	<@MarkW>	yep, taken just after the 3.0.4 release
11:28	<@MarkW>	Was there any discussion about this breakage on the mailing list?
11:28	<aliguori>	danp1: yes, I've been told that too, and I'm not sure I believe it's all that rigorous :-)
11:28	<@MarkW>	did I miss it?
11:29	<aliguori>	AMD-V (SVM) support in xen-unstable (11/13)
11:29	<aliguori>	I think a lot of the VT related changes tend to break SVM. And since there aren't a lot of folks working on SVM...
11:30	<@MarkW>	Gnarrrrrrrrrrrr
11:30	<icblenke>	aww. and here I am with nothing but SVM boxen.
11:30	<@MarkW>	I just lost the will to live!
11:31	<@MarkW>	Worlds first xen-related head implosion?
11:31	<@MarkW>	Probably not!
11:31	<aliguori>	hehe
11:31	<aliguori>	icblenke: kvm works happily with SVM :-)
11:31	<@MarkW>	aliguori: doesn't that use xen-derived code?
11:31	<aliguori>	not really
11:31	<aliguori>	it only uses x86_emulate.c
11:31	<icblenke>	if lhype were more mature, I'd consider an lhype + kvm solution to replace xen.
11:32	<@MarkW>	Seriously though, you'd think we'd at least make sure our code didn't create major full-on breakages...
11:33	<@MarkW>	I guess that's naive of me.
11:33	<@MarkW>	I'll downgrade to 3.0.2 and see if that works...
11:33	<@MarkW>	But I'm not sure the issues I'm seeing are the same as those described on the list.
11:35	<riel>	icblenke: want to place a rant on virt.kernelnewbies.org? :)
11:36	[~]	riel is planning a nice article with the benefits and disadvantages of using a hypervisor instead of linux as the host
11:37	\|-\|	zwane_work [~zwane@h70-68-160-192.sbm.shawcable.net] has joined #xen
11:37	\|-\|	zwane_work [~zwane@h70-68-160-192.sbm.shawcable.net] has quit []
11:41	<icblenke>	riel: I'll just rant on my blog for the time being, though the wiki really should be updated with proper documentation.
11:45	\|-\|	Basic_py [~Basic@warden.real-time.com] has quit [Quit: Leaving]
11:46	\|-\|	mdday [~mdday@cpe-024-163-122-235.nc.res.rr.com] has joined #xen
11:48	\|-\|	athomas [~athomas@host86-134-167-36.range86-134.btcentralplus.com] has quit [Quit: Leaving]
11:50	<tab>	hey
11:50	<tab>	can I join the ranting party ? ;)
11:51	[~]	tab got problems starting any type of domains with 3.0.4
11:52	<danp1>	3.0.4 was working pretty nicely for me when i tried it
11:53	<danp1>	i managed to get both PV & HVM guests running, and got it working with libvirt with minimal trouble
11:53	<danp1>	and the number of patches in our fedora xen RPMs dropped to single figures at last
11:53	<tab>	I'm using a very different userspace :)
11:56	<movement>	I'm having a 3.0.4 nightmare
12:02	\|-\|	agrif_away changed nick to agriffis
12:02	<@MarkW>	tab: yay, ranting party!
12:02	<@MarkW>	movement: welcome to the ranting party! Did you bring drinks? ;-)
12:02	<tab>	hey MarkW, long time no see :)
12:03	<@MarkW>	movement: more problems with the API weirdness? That handle thing was completely weird!
12:03	<@MarkW>	tab: yo, ca va?
12:03	<tab>	;)
12:03	<tab>	bien et toi ? :)
12:03	<@MarkW>	bof
12:03	<tab>	I see you made good progress in french ;)
12:04	<@MarkW>	bof is my favourite word ;-)
12:04	<tab>	yeah, you can use it quite often everywhere
12:04	<@MarkW>	Yep :-)
12:06	<@MarkW>	tab: you using the proprietary tools by any chance?
12:06	<@MarkW>	tab: Everything works fine for me on 3.0.4ish, except for HVM which is dead as a doornail
12:06	<tab>	MarkW: 32 or 64 ?
12:07	<@MarkW>	Everything 32-bit on an Athlon64
12:07	<@MarkW>	I was quite happy when I thought I didn't have HVM support on this hardware. Very happy.
12:07	<movement>	MarkW: xmlrpc is randomly getting back EAGAIN from recv()
12:07	<@MarkW>	But now that I know that I do, I won't be happy unless it works :-(
12:07	<tab>	hm :P
12:07	<@MarkW>	movement: Ah, I remember you were having problems with it.
12:07	<tab>	try kvm it works in SVM :p
12:08	<@MarkW>	tab: Indeed!
12:08	<@MarkW>	movement: Is it just behaving differently on Solaris, or have you needed any tools changes that could have perturbed it?
12:11	<movement>	MarkW: I can't see what we could have changed
12:11	<movement>	trying to debug it but not getting very far
12:13	<@MarkW>	movement: I know that feeling.
12:13	<@MarkW>	Is the failure you're seeing on client-side or Xend-side?
12:14	\|-\|	KriP [kp@yancey.unixworld.dk] has joined #xen
12:25	<icblenke>	http://ian.blenke.com/xen/
12:30	<riel>	icblenke: I'm working on the "restore wants maxmem" thing
12:31	<riel>	not because I want to, but because it's a prerequisite to the project I do want to work on :)
12:33	<movement>	MarkW: xend it appears
12:33	<movement>	xm gets EPIPE from send(), xend gets EAGAIN from recv()
12:34	<movement>	riel: you mean restoring in a ballooned-down state?
12:34	<riel>	movement: yeah
12:34	<danp1>	icblenke: i submitted patches to fix all the 2TB disk limits in Xen 3.0.3
12:35	<danp1>	so it should all work fine in 3.0.4 (well, the limits are now determined by your guest OS instead of the HV/xen drivers)
12:36	<riel>	icblenke: the LBA48 limit is 137GB IIRC
12:36	<danp1>	i've succesfully mapped 8 PB disk to a 64-bit linux guest, for example
12:37	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has joined #xen
12:37	<danp1>	icblenke: also, wrt to xen being on 2.6.16 - that's only really true of upstream xen - all the major distributuons (debian, ubuntu, suse, fedora, rhel) have forward ported xen to sensible recent kernel versions
12:37	<movement>	riel: neat
12:38	<riel>	I'm still reading xc_linux_save.c though
12:38	<riel>	to figure out the save format and the things that get saved
12:38	<danp1>	and arguably these forwarded ported kernels get more testing than upstream xen 2.6.16 do, because people actually run distro kernels in the real world
12:38	<riel>	specifically, how pages without p2m mapping are represented
12:40	<movement>	blank pages
12:41	<icblenke>	blank page?
12:41	<movement>	it'd be nice to not save them too but it'd involve a format change afaik. another thing for the Great Format Change
12:42	<icblenke>	danp1: on the flip side of that, you also have things like debian's botched 2.6.17.2 kernel with xen that would spontaneously reset after starting 2 domUs.
12:42	<@MarkW>	movement: they're gzipped, though, right? They ought to compress well, at least...
12:44	<murb>	icblenke: was that due to taking random fedora patches and applying them in a more or less random fashion?
12:44	<icblenke>	No idea. Probably. Still, distribution specific.
12:45	[~]	murb wonders if when we'll be able to use xen with paravirt_ops
12:45	<murb>	i already have working lhype here
12:46	\|-\|	ns [~niv@bi01p1.co.us.ibm.com] has joined #xen
12:46	<aliguori>	aka rustyvisor :-)
12:46	<murb>	indeed :-)
12:48	<murb>	being able to boot as a normal kernel is a big win.
12:51	<aliguori>	yeah
13:14	<movement>	danp1: there?
13:15	<danp1>	movement: yeah
13:15	<movement>	so I booted a domain that crashed and tried to dump core. it failed because the domU frame list wasn't built (we have the previously discussed patch so core dumps aren't broken)
13:15	<movement>	now xm list is giving:
13:16	<movement>	xm list
13:16	<movement>	Error: Failed to dump core: (1, 'Internal error', "Couldn't map p2m_frame_list (22 = Invalid argument)")
13:16	<movement>	Usage: xm list [options] [Domain, ...]
13:16	<movement>	is there a clear error missing somewhere or something?
13:16	<danp1>	hmm, yeah, certainly looks like there is
13:16	<aliguori>	hehe
13:16	<aliguori>	awesome
13:16	<danp1>	or at least, xm list really is failing
13:17	<danp1>	but its picking up the old error message
13:17	\|-\|	bernarde [~bernarde@201.72.60.80] has quit [Remote host closed the connection]
13:17	<danp1>	or even a combination of both
13:17	<aliguori>	this is why storing error messages is a bad idea :-)
13:17	<movement>	hrm
13:18	<danp1>	i've had lots of trouble with xm list failing in past, with a domain got into a half-dead fubar state
13:20	<movement>	ok this is weird
13:20	<movement>	ah
13:20	<movement>	it seems to be noticing it's crashed again and again and trying to dump core each time
13:20	<danp1>	nice, dumping core forever then ?
13:21	<movement>	no only in response to xm list
13:22	<movement>	(what kind of brokenness has xm list as anything but getting info? sigh)
13:22	<movement>	I guess something's calling update() with refresh = True
13:24	<movement>	I think I see the patch
13:24	<movement>	path
13:24	<movement>	XendDomain:list() -> _refresh() -> XendDomainInfo:update()
13:25	<movement>	this probably explains why xm list can hang for ages sometimes if a domain crashes at the wrong time
13:25	<movement>	I'll send mail to the list
13:27	\|-\|	kapat [~me@66.158.65.164] has joined #xen
13:31	<kapat>	I apologize if this is an obvious question, but its not in the faq (I did look). In general, is it (or will it) be possible to mix-n-match arches?
13:32	<kapat>	For instance, is it possible to run a virtualized i686 linux under an x86_64 dom0?
13:34	<icblenke>	with HVM, sure. http://ian.blenke.com/xen/limitations/
13:36	<murb>	kapat: someone at novell was writting support for 32 on 64b
13:36	<kapat>	icblenke: Ok, but otherwise arches have to match.
13:36	<kapat>	Thanks
13:42	<kapat>	Huh, so an x86 dom0 can't handle x86_64 HVM domU's?
13:42	<icblenke>	no.
13:44	<kapat>	I guess that makes sens somehow.
13:45	\|-\|	rpg [~rpg@bi01p1.co.us.ibm.com] has quit [Remote host closed the connection]
13:55	<@MarkW>	Hmmm.
13:55	<@MarkW>	Still not having any luck with HVM.
13:55	<@MarkW>	I really should be able to make this work!
13:55	<@MarkW>	I've only been working with Xen for the past 3 years...
13:56	<@MarkW>	I think it's possible to spot the developers on here by how much they complain about stuff not working :-)
13:56	<icblenke>	hehe. you're what we would call and "expert". god help us if you can't make it go.
13:56	<kapat>	I managed to get it working, and I am certainly not an "expert"... :)
13:57	<@MarkW>	icblenke: To be fair, I do almost everything using self-compiled (and sometimes patch) versionsof xen-unstable
13:57	<kapat>	It took a while however.
13:57	<icblenke>	granted, you are using xen-unstable.
13:57	<icblenke>	right.
13:57	<murb>	icblenke: it is supposed to be hard so xensource can sell their enterprise manglement stuff which will make it all work at teh click of a mouse :p
13:57	<@MarkW>	So it's not quite as bad as it sounds...
13:57	<kapat>	lol
13:57	<@MarkW>	but I'm not even trying to do anything weird here!
13:57	<@MarkW>	Every so often I feel like a complete noob at Xen
13:58	<kapat>	MarkW: I'd call that progress. I pretty much feel like that all the time.
13:58	<@MarkW>	kapat: people keep writing new features when I'm working on other stuff
13:58	<tab>	if keir wasn't doing some cleanup everytime, it should be more interface stable at least ;p
13:58	<@MarkW>	kapat: It's confusing :-) This is the first time I've had an HVM machine to try Xen on though
13:59	<kapat>	MarkW: I guess you could just use vmware. ;-)
13:59	<@MarkW>	tab: I guess we have maintained an interface (the Xen 3.0) one for a record length of time now though.
13:59	<@MarkW>	kapat: shhhhhhhh ;-)
13:59	<@MarkW>	or Virtual Iron :-)
13:59	<tab>	MarkW: it keeps changing internally though
13:59	<@MarkW>	Keep meaning to try their stuff out but never get around to it.
14:00	<icblenke>	ditto. might be forced to soon.
14:00	<icblenke>	I like how they have NEXBUS instead of XENBUS.
14:00	<tab>	MarkW: 218000 lines of changes in 3.0.3 -> 3.0.4
14:01	<@MarkW>	tab: in the whole repository?
14:01	<tab>	yes
14:01	<@MarkW>	icblenke: NEXBUS?
14:01	<@MarkW>	cute
14:01	<icblenke>	I thought so.
14:01	<tab>	funny
14:01	<@MarkW>	Forced to by what? Xen problems?
14:02	<icblenke>	no clue.
14:02	<aliguori>	tab: how much of that is kernel changes though (going from .29 to .33)?
14:02	<mulix>	aliguori, I was going to ask the same thing :-)
14:02	<mulix>	I'm guessing most of it
14:03	<aliguori>	yeah, 200k is too much even for xen :-)
14:03	<kapat>	Are they planning on sticking with 2.16.x for a while?
14:03	<tab>	aliguori: only the patch directory
14:04	<aliguori>	tab do you know how much of the 200k is from the patch dir though?
14:04	<tab>	around 6K it seems
14:05	<@MarkW>	Does anybody have a known-good HVM-on-AMD changset they could recommend?
14:05	<tab>	82K for xen/
14:05	<@MarkW>	This is driving me bonkers.
14:06	<@MarkW>	tab: whoa...
14:06	<tab>	3.0.3 ? :)
14:06	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has quit [Ping timeout: 480 seconds]
14:06	<aliguori>	tab: i imagine quite a bit of it is xend right?
14:07	<@MarkW>	tab: I'll give it a whirl...
14:07	<tab>	a bunch of update for xenapi
14:07	<tab>	random xc stuffs
14:07	<@MarkW>	tab: is some of it merges, etc.?
14:08	<tab>	MarkW: seems bunch of stuffs are merged for ia64 and powerpc
14:08	<tab>	also 10K for a .tex file
14:09	<@MarkW>	tab: errrrm!?
14:09	<tab>	it's autogenerated though
14:09	<@MarkW>	OK
14:14	[~]	MarkW registers to download XenExpress
14:15	<@MarkW>	Company Name: XenSource
14:15	<@MarkW>	That'll mess with them :-)
14:15	<@MarkW>	It's true, too!
14:16	<icblenke>	you can use the XenSource PV drivers for Windows with Xen 3.0.3/4, though you end up needing an IDE "stub" to boot to a SCSI disk.
14:16	<icblenke>	I've done it.
14:17	<@MarkW>	icblenke: Cool!
14:17	<@MarkW>	Where do you get them from?
14:18	<icblenke>	you can pull the drivers out of XenExpress.
14:18	<@MarkW>	Nifty.
14:19	<@MarkW>	I'm not entirely surprised it works.
14:19	<icblenke>	I _would_ be suprised if Virtual Iron's work though.
14:19	<@MarkW>	But it's nice to have confirmation that our interfaces really are compatible between products.
14:19	<@MarkW>	icblenke: Well, it'd be nice if they did... we'll see I guess,
14:19	<@MarkW>	How does this IDE stub business work?
14:20	<@MarkW>	Do you have to have the bootloader on an emulated drive or something?
14:20	<icblenke>	the current Xen BIOS doesn't grok the SCSI device (no int13 stub)
14:20	<icblenke>	you get to do the ntbootdd.sys/ntldr/boot.ini thing on a tiny IDE drive and then have it bootstrap the the SCSI system disk.
14:20	<@MarkW>	Hmmm, OK.
14:21	<@MarkW>	and the SCSI device is the paravirtual drive?
14:21	<icblenke>	yep.
14:21	<@MarkW>	I'm not surprised the BIOS can't see that...
14:21	<@MarkW>	should be possible to make it see it though... maybe.
14:21	<@MarkW>	And then maybe you could boot direct from a paravirt drive. That'd be cool.
14:21	<icblenke>	which is kind of weird, in that there's no way to say "this drive is PV, this drive is ioemu", Windows sees _both_
14:21	<@MarkW>	It'd require some slightly grungy hacking.
14:21	<@MarkW>	As in it sees two images of the same drive?
14:22	<icblenke>	aye. and mounts them both at the same time.
14:22	<@MarkW>	Gross
14:22	<@MarkW>	:-)
14:22	<icblenke>	which breaks things.
14:22	<icblenke>	bad.
14:23	<@MarkW>	OTOH it can be quite amusing to see the kind of reactions that sort of thing provokes in a guest OS
14:23	<@MarkW>	See how confused it gets :-)
14:23	<@MarkW>	How are you actually meant to deal with it? Can you have it unmap the emulated drive by default?
14:24	<icblenke>	how XenSource does it in their XenExpress/XenEnteprise stuff is beyond me. I haven't installed their stuff entirely yet either.
14:24	<@MarkW>	And also, how are you exporting a SCSI drive in the first place?
14:24	<@MarkW>	I didn't think the device model supported SCSI...
14:25	<@MarkW>	for an emulated device, that is.
14:25	<icblenke>	the PV driver is the SCSI driver.
14:25	<icblenke>	meaning, to the Xen backend it's just a vbd block device.
14:25	<@MarkW>	And the same SCSI drive also appears as an IDE drive at the same time?
14:25	<icblenke>	there is need to emulate a SCSI chipset.
14:26	<icblenke>	the "SCSI Driver" is a PV driver for the vbd frontend that emulates a SCSI drive from Window's perspective.
14:26	<@MarkW>	Sure. But the same drive is concurrently being exported as IDE using the device emulator?
14:26	<icblenke>	yes.
14:26	<@MarkW>	Haha, that's quite endearingly bonkers :-)
14:27	<icblenke>	qemu-dm merrily exports an intel ide chipset which windows happily uses.
14:27	<@MarkW>	In principle, the BIOS could be taught to talk the PV protocol itself, I guess.
14:27	<icblenke>	and my guess is that's what they've done in the XenSource products.
14:28	<icblenke>	that, and probably added a flag that says "this disk is SCSI, don't emulate it in qemu-dm"
14:28	<@MarkW>	But that might bloat it somewhat! Maybe there could be some sort of bootstrap PV protocol.
14:28	<icblenke>	kinda like how we have hdc:cdrom now.
14:28	<@MarkW>	We used to have flags that specified what should be emulated and what shouldn't.
14:28	<movement>	big joy for how control-C of xm can totally trash everything
14:28	<icblenke>	what I didn't try is xvda.
14:28	<@MarkW>	I'm not entirely sure why they went... maybe because they're not necessary due to the dual-exporting.
14:28	<icblenke>	damn. why didn't I think of that?
14:29	<icblenke>	(which would only remove qemu-dm's emulation of the IDE chipset on the SCSI disk)
14:29	<icblenke>	I'd still have the tiny bootstrap IDE disk visible as a SCSI disk as well when windows booted.
14:30	<icblenke>	but if it's marked readonly, no big deal.
14:31	<tab>	MarkW: the IDE one is closed by the PV drivers
14:32	<@MarkW>	tab: So it's no longer accessible once the PV drivers are in use?
14:33	<aliguori>	the PV drivers are proprietary, so who cares anyway :-)
14:34	<icblenke>	tab: that wasn't my experience, unless there's some mechanism that I missed.
14:35	<tab>	MarkW: icblenke: the IDE one should be Closed in xenstored
14:35	<@MarkW>	tab: interesting.
14:35	<@MarkW>	tab: slightly less terrifying :-)
14:36	<icblenke>	so there's some feedback mechanism there that isn't in the opensource Xen.
14:36	<@MarkW>	aliguori: true, although when you're running on windows already.... ;-)
14:36	<icblenke>	I like IO fencing when doing things like that, virtual or otherwise ;)
14:36	<tab>	I don't think it's legal to use the xenexpress driver with the opensource ;p
14:36	<icblenke>	legal schmegal. it works.
14:36	<aliguori>	MarkW: if you are okay with closed source, there is no reason to not just use vmware
14:36	<aliguori>	for full virtualization
14:37	<icblenke>	if you're going to run windows anyway, does it fscking matter?
14:37	<tab>	it should not works AFAIK
14:37	<@MarkW>	aliguori: True. Although say I want PV guests for performance, and I don't want to pay for my virtualisation software because I'm a poor student
14:37	<aliguori>	MarkW: vmware server is free
14:37	<tab>	the driver is suppose to look for a string in xenstored with lots of (TM) in it
14:37	<@MarkW>	aliguori: Then it makes sense pragmatically and I'm not too worried about introducing a little extra proprietary code into Windows.
14:37	<icblenke>	tab: it works, though you have to jump through hoops for the ide/scsi duality thing.
14:38	<@MarkW>	aliguori: True, but no paravirt.
14:38	<aliguori>	MarkW: not true. the newest version supports VMI
14:38	<aliguori>	:-)
14:38	<icblenke>	tab: trust me, I've done it.
14:38	<tab>	icblenke: I'm pretty sure it doesn't
14:38	<tab>	not totally at least
14:38	<@MarkW>	aliguori: But does my Linux distro?
14:38	<icblenke>	"worked for me".
14:38	<tab>	I remember having steve talk about IO corruption
14:39	<icblenke>	oh, that's entirely possible. I didn't exactly beat up that test box.
14:39	<@MarkW>	aliguori: In practice, my Linux distro doesn't work with Xen anyhow :-) It's just that I think if one were entirely idealistic about free software one wouldn't be running Windows anyhow ;-)
14:39	<aliguori>	MarkW: i guess there's a small convenience factor there.. but that seems like a fringe use case to me :-)
14:39	<aliguori>	MarkW: I just honestly don't like the whole "mixed source"
14:39	<icblenke>	tab: it's also not like I'm running anything more than a test instance with that setup. no way I'd go production with that.
14:40	<aliguori>	having a commercial userspace is troubling to me
14:40	<aliguori>	and commercial paravirt drivers
14:40	<icblenke>	you're running operating systems like windows.
14:40	<icblenke>	hello?
14:40	<@MarkW>	aliguori: Well, either Xen has a usecase beyond ideology, in which case adding a little commerical code to Windows seems fine
14:40	<aliguori>	where's the incentive to develop high performance unmodified drivers?
14:40	<@MarkW>	aliguori: or it's a case of just not wanting to use closed software in which case windows isn't necessary.
14:41	<icblenke>	honestly, I see no incentive for any opensource development of PV high-performance drivers for HVM guests that aren't also opensource.
14:41	<@MarkW>	aliguori: Are the linux HVM PV drivers open source? I thought they were, right?
14:41	<aliguori>	MarkW: yes
14:41	<murb>	is there any reason the windows pv driver source can't be published?
14:41	<@MarkW>	But yeah, it would be nice to have better performance in native IO emulation.
14:41	<murb>	other than commerical?
14:41	<aliguori>	icblenke: there doesn't have to be any incentive other than the fact that software should be free
14:41	<icblenke>	exactly. windows may never see opensource pv drivers for xen. and I don't see anything wrong with that.
14:41	<@MarkW>	murb: maybe it incorporates code from MS SDK?
14:41	<icblenke>	you're writing a windows driver.
14:41	<tab>	MarkW: I think it does
14:41	<icblenke>	windows isn't exactly free.
14:42	<@MarkW>	tab: It would make sense really: Windows drivers are supposed to be pretty hard to write from scratch, so you'd want to use the examples!
14:42	<danp1>	icblenke: it all comes down to a question fo supportability
14:42	<icblenke>	aligouri: I'd much rather never have to deal with any non-free Operating System, but here we are discussing that very case.
14:42	<danp1>	if you're a distro who wants to support people using PV drivers in guest, then the more of the stack thats open source the better
14:42	<aliguori>	danp1 is right. what happens when there's a bug in the windows paravirt drivers? how does RH support their customer there
14:43	<@MarkW>	That's true enough. It would be nice to be able to fix any bugs in the Windows drivers.
14:43	<murb>	aliguori: they call xensource or whoever wrote them and microsoft.
14:43	<danp1>	we can't do anything about Windows itself, but we can damn well make sure Xen PV drivers for Windows are fully open
14:43	<aliguori>	MarkW: even if there is GPL issues, they could still be BSD (and strip out the MS code)
14:43	<danp1>	so customers don't get locked into a closed source 3rd party vendor
14:43	<@MarkW>	Although, again, same goes for anything in Windows. It's just a shame to be making the problem worse
14:43	<aliguori>	murb: and that's where you have problems with vendor lock in and all the other wonderful stuff that makes customers come to OS in the first place
14:43	<danp1>	aliguori: the Windows DDK legal issues are trivially worked around
14:44	<icblenke>	good luck with vista there.
14:44	<danp1>	by applying the standard chinese wall approach
14:44	<@MarkW>	OTOH, you do eliminate a whole slew of proprietary drivers for whatever random hardware you have on your real machines
14:44	<aliguori>	danp1: that's what I would expect. I know there are OS windows drivers out there
14:44	<icblenke>	you know, with all of those DRM signed drivers and all.
14:44	<danp1>	where one person reads the DDK & writes a spec, the other person doesn't touch the DDK & simply implements based on the spec
14:44	<tab>	everything not really simple I think
14:45	<aliguori>	danp1: and the paravirt windows drivers aren't nearly as bad as the commercial dom0 userspace...
14:45	<icblenke>	who is going to drive the process of getting Microsoft to sign some opensource drivers for virtually hosting its operating system on a non-microsoft virtualization platform?
14:45	<aliguori>	icblenke: that sounds like a good job for the various distros
14:45	<@MarkW>	aliguori: It really bothers me that there's an actual fork of the userspace used by the commercial side.
14:45	<danp1>	MarkW: yeah, me too :-(
14:46	<icblenke>	me three.
14:46	<tab>	me too :p
14:46	<aliguori>	MarkW: right
14:46	<danp1>	i was very depressed to discover XenEnterprise has a closed source control daemon
14:46	<@MarkW>	I could understand building on top of the existing userspace with nicer management layers. But making a whole new stack, whilst continuing to develop the old one...
14:46	<@MarkW>	...that's just bonkers.
14:46	<aliguori>	the worst part is that no other company can legally do that
14:46	<danp1>	while the community has to fight with XenD :-(
14:46	<aliguori>	and still call it Xen
14:46	<tab>	danp1: and xend not really up to the fight ..
14:46	<icblenke>	how else can you force people to pay "by port"?
14:46	<@MarkW>	Thing is, Xend works OK these days for most people
14:46	<aliguori>	MarkW: by some definition of OK
14:47	<tab>	I certainly wish to opensource more of the commercial stuff, and I try to push in this direction
14:47	<danp1>	MarkW: yeah, but we could have been much further along, along time ago....
14:47	<@MarkW>	And even if it needed work, it'd be better to collaborate on the base layers and put value-add on top
14:47	<tab>	but I'm far from beeing a manager
14:47	<aliguori>	tab: the future of Xen is at stake here though.. this is only going to drive people to other options (like KVM)
14:47	<@MarkW>	Duplicating the entire stack isn't exactly value add...
14:47	<icblenke>	and l-hype/paravirtops
14:47	<tab>	aliguori: I certainly agree
14:47	<danp1>	aliguori: yeah, that's the crux of the matter
14:48	<tab>	I'm just a tiny voice at xensource unfortunately
14:48	<aliguori>	tab: yeah, I know the feeling :-)
14:48	<tab>	I'm very worried with KVM
14:48	<tab>	but yet nobody really is worried at XenSource
14:48	<danp1>	with KVM being soo new & shiny & already merged upstream, Xen really needs to get on recent kernel & merged asap to avoid loosing mindshare
14:48	<@MarkW>	It's OK to be concerned with proprietary market-related stuff
14:48	<icblenke>	tab: they should be.
14:48	<tab>	icblenke: I agree
14:49	<icblenke>	the fact that Xen isn't in the upstream linux kernel yet is a death-blow for Xen.
14:49	<icblenke>	long term.
14:49	<@MarkW>	But I wish Xen could be a bit further along with upstream...
14:49	<icblenke>	unless you believe OpenSolaris is the direction Xen is heading?
14:49	<aliguori>	tab: the scary thing is that some big name kernel folks are interested in it (like mingo)
14:49	<danp1>	icblenke: not even long term - i'd say medium-to-short term
14:49	<@MarkW>	In fairness, the Xen patches have generated a lot more discord than KVM, etc, because they modify an arch rather than just adding a driver.
14:49	<aliguori>	it won't be long before it's out performing xen
14:50	<danp1>	icblenke: the moment a handful of mainstream distros ship with a kernel including KVM
14:50	<danp1>	then the pressure & desire to keep maintaining out-of-tree Xen patches dissappears :-(
14:51	<@MarkW>	danp1: on that score, at least RedHat and SuSE have jumped on the Xen bandwagon
14:51	<danp1>	hopefully the paravirt_ops impl for Xen will get incorporated soon
14:51	<aliguori>	danp1: I'm not all that hopeful for 2.6.21
14:51	<@MarkW>	I would imagine that with their longterm support contracts for RHEL and SLES, there'll be a lot of inertia against switching to another virtualisation platform for future releases
14:51	<@MarkW>	Even if they have a technical motivation for doing so, it'll break existing users...
14:52	<icblenke>	and that might very well be enough to pull Xen into the mainstream kernel.
14:52	<aliguori>	MarkW: that's easier to work around than you'd expect. you just need a migration path
14:52	<danp1>	MarkW: don't rely on that.... the reason we started libvirt for management is so that management tools on RHEL are not locked into Xen
14:52	<hollisb>	MarkW: are you saying XenSource can be even more complacent? :)
14:52	<aliguori>	for HVM, it's quite easy
14:53	<riel>	MarkW: if Xen was in the upstream kernel, _then_ there would be momentum
14:53	<icblenke>	we're moving from user-mode-linux VMMs to Xen VMMs.. I can just as easily add a virt layer for our farm to migrate to l-hype/kvm in the long term.
14:53	<@MarkW>	danp1: True enough!
14:53	<riel>	MarkW: "it's there anyway, so we might as well switch it on"
14:53	<riel>	but once it becomes "we need to have an engineer working full-time just to keep Xen running on a current kernel", the momentum is against Xen
14:54	<riel>	especially with KVM already being upstream
14:54	\|-\|	cableman [~cableman@3e6b7156.rev.stofanet.dk] has left #xen [Leaving]
14:55	<riel>	KVM (and other FV solutions) has two great shortcomings compared to paravirt
14:55	<riel>	1) timing
14:55	<riel>	2) memory resizing
14:55	<hollisb>	riel: what about timing?
14:55	<aliguori>	riel: timing's pretty easy to address actually
14:55	<icblenke>	I'd hate to see the KVM folks develop their own "PV drivers" for whatever mechanism they expose to shortcut the QEMU hardware emulation in their own way. so sad, that.
14:55	<riel>	aliguori: exactly
14:55	<aliguori>	in fact, it requires no new linux code if you have a VMI enabled kernel :-)
14:56	<riel>	hollisb: (1) no tick on idle (2) use the HV clock instead of a variable speed internal clock (3) steal time accounting, etc
14:56	<danp1>	aliguori: once you address it, its not really FV anymore though - its a PV-FV half-breed :-)
14:56	<icblenke>	what the heck is VMI?
14:56	<aliguori>	riel: do you think of memory overcommit is enough to replace ballooning? or do you need full blow hotplug
14:56	<aliguori>	danp1: yeah, I think that's a good thing :-)
14:56	<danp1>	icblenke: VMWare's paravirt_ops interface
14:56	<riel>	aliguori: overcommit - maybe
14:56	<riel>	aliguori: as long as there's cooperation between guest and host
14:56	<icblenke>	ah. gotcha.
14:57	<riel>	to prevent double swapping
14:57	<riel>	no need for full blown hotplug
14:57	<aliguori>	riel: yeah
14:57	<riel>	the third big item is paravirt device drivers, but those already exist for FV
14:58	<riel>	so I wouldn't want anybody at XenSource to become complacent :)))
14:58	<@MarkW>	Aha!
14:58	<@MarkW>	HVM works!
14:58	<murb>	XenSource is saved!
14:58	<icblenke>	what was it?
14:58	<@MarkW>	For Xen 3.0.3, that is.
14:59	<@MarkW>	I've no idea, I just switched to 3.0.3-testing and it worked.
14:59	<icblenke>	so, VMI.. this is a patch to be expected soon for Xen or kvm? or both?
14:59	<aliguori>	icblenke: no, this is for vmware. there's some talk of supporting it in kvm
15:00	<aliguori>	icblenke: cambridge has full heartedly rejected it even though vmware did the work of getting xen to work with it :-)
15:00	<icblenke>	oh? really?!
15:01	<riel>	given that Ingo appears to be involved in KVM, they ought to be more nervous than ever
15:01	<icblenke>	but they didn't opensource it, I'll guess? (googling like mad for this now)
15:01	<danp1>	icblenke: ultimately it doesn't really matter
15:01	<danp1>	because with paravirt_ops a single Linux kernel can now boot bare-metal, VMI, Xen, etc - automagically detecting on-the-fly
15:02	<danp1>	although, it would be desirable keep a reasonably low number of paravirt-ops implementations for support reasons :-)
15:02	<riel>	silly ADSL modem, it looks like it's not always able to keep up with the speed of the signal :)
15:02	<murb>	well xen stuff can work though the vmi layer as well can't it?
15:02	<danp1>	icblenke: yes, vmware provided the VMI firmware under GPL
15:03	<aliguori>	the nice thing about VMI is that it reduces the combinatorial problem associated with paravirtualization
15:03	<icblenke>	now I'm starting to understand what this implies. I was completely unaware.
15:03	<