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

---	Log	opened Tue Jan 02 00:00:14 2007
00:19	\|-\|	brianw [~ahzz@pool-71-170-81-199.dllstx.fios.verizon.net] has joined #xen
01:20	\|-\|	mastermind [~mastermin@mastermind.kaltenbrunner.cc] has quit [Quit: Client exiting]
01:49	\|-\|	mulix [~mulix@87.69.40.180] has quit [Remote host closed the connection]
02:12	\|-\|	danp1 [~berrange@kabutomushi1.demon.co.uk] has joined #xen
02:23	\|-\|	mejlholm\|uni [~mejlholm@bart.cs.aau.dk] has joined #xen
04:53	\|-\|	danp1 [~berrange@kabutomushi1.demon.co.uk] has left #xen []
05:06	\|-\|	bernarde [~bernarde@201-43-198-215.dsl.telesp.net.br] has joined #xen
05:44	\|-\|	athomas [~athomas@host86-134-167-36.range86-134.btcentralplus.com] has joined #xen
05:51	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has joined #xen
06:17	\|-\|	mdday [~mdday@cpe-024-163-122-235.nc.res.rr.com] has joined #xen
06:29	\|-\|	ag- [~ag@caladan.roxor.cx] has quit [Remote host closed the connection]
06:51	\|-\|	jwb [~jwboyer@rchp4.rochester.ibm.com] has joined #xen
06:51	\|-\|	Pinne [~pinne@a84-231-86-100.elisa-laajakaista.fi] has joined #xen
06:52	\|-\|	msinhore [~msinhore@correio.samurai.com.br] has joined #xen
07:10	\|-\|	athomas [~athomas@host86-134-167-36.range86-134.btcentralplus.com] has quit [Quit: Leaving]
07:14	\|-\|	athomas [~athomas@host86-134-167-36.range86-134.btcentralplus.com] has joined #xen
07:33	<Pinne>	I try to make configuration that dom0 is my desktop and it uses one nic with dhcp and first quest uses other physical nic and acts like bridge/firewall to other quests. I have googled but i just can't see configuration like that. Is there any keywords for that? It's look like that default network scripts are pretty fixed for that dom0 is used as that bridge.. how can i change that behavior?
08:08	\|-\|	SLot [~SLot___@gustavo.gruposim.com.br] has joined #xen
08:24	\|-\|	jdmason [~jonmason@cpe-67-9-183-161.austin.res.rr.com] has joined #xen
08:52	<hensema>	Pinne: afaik there are no direct network connections between the guests
08:54	\|-\|	cableman [~cableman@3e6b7156.rev.stofanet.dk] has joined #xen
08:55	\|-\|	SLot [~SLot___@gustavo.gruposim.com.br] has quit [Ping timeout: 480 seconds]
08:59	<icblenke>	you would need to bridge between guests for them to see each other, or have one domain provide a backend for another domain.
09:00	\|-\|	SLot [~SLot___@gustavo.gruposim.com.br] has joined #xen
09:09	<Pinne>	icblenke, i just found this page http://lists.xensource.com/archives/html/xen-users/2005-07/msg00558.html so keywords are netif=, and backend= ..i think.
09:13	<icblenke>	neat trick. that.
09:24	\|-\|	visik7 [~visi@host174-136-dynamic.58-82-r.retail.telecomitalia.it] has joined #xen
09:33	\|-\|	Pinne [~pinne@a84-231-86-100.elisa-laajakaista.fi] has quit [Ping timeout: 480 seconds]
09:38	\|-\|	mulix [~mulix@87.69.40.180] has joined #xen
09:42	\|-\|	aliguori [~anthony@cpe-70-112-17-156.austin.res.rr.com] has quit [Quit: Leaving]
09:45	\|-\|	hollisb [~hollisb@bi01p1.co.us.ibm.com] has joined #xen
09:46	\|-\|	ag- [~ag@caladan.roxor.cx] has joined #xen
09:52	\|-\|	rpg [~rpg@bi01p1.co.us.ibm.com] has joined #xen
10:06	\|-\|	KriP [kp@yancey.unixworld.dk] has joined #xen
10:06	\|-\|	rharper [~rharper@bi01p1.co.us.ibm.com] has joined #xen
10:11	\|-\|	rharper [~rharper@bi01p1.co.us.ibm.com] has quit [Remote host closed the connection]
10:15	\|-\|	aliguori [~anthony@bi01p1.co.us.ibm.com] has joined #xen
10:22	\|-\|	stekloff [~stekloff@bi01p1.co.us.ibm.com] has joined #xen
10:42	\|-\|	cdub [~chrisw@216-99-217-87.dsl.aracnet.com] has joined #xen
10:44	\|-\|	cdub [~chrisw@cdub.netrep.oftc.net] has quit []
10:44	\|-\|	cdub [~chrisw@cdub.netrep.oftc.net] has joined #xen
10:45	\|-\|	rharper [~rharper@bi01p1.co.us.ibm.com] has joined #xen
10:51	\|-\|	ns [~niv@bi01p1.co.us.ibm.com] has joined #xen
10:51	\|-\|	rharper [~rharper@bi01p1.co.us.ibm.com] has quit [Remote host closed the connection]
11:13	\|-\|	mastermind [~mastermin@mastermind.kaltenbrunner.cc] has joined #xen
11:23	<@MarkW>	Has anyone here tried Xen under RHEL 5?
11:24	<ns>	yes
11:24	<riel>	I'm running RHEL5 under Xen, too :)
11:24	<riel>	kernelnewbies.org runs on it, in fact
11:24	<@MarkW>	Cool
11:25	<@MarkW>	Does it support some means of installing on non-RHEL5 hosts, or do you need to use a special install-a-tron in dom0?
11:25	\|-\|	Basic_py [~Basic@warden.real-time.com] has quit [Quit: Leaving]
11:25	<icblenke>	I'm having some rather weird failure modes with xenconsoled and xenstored with 3.0.3 and 3.0.4 on a glibc 2.2.5 debian distro... something about daemonizing or keeping the darned sockets open between xenconsoled and xenstored.
11:26	<riel>	I'm running it on top of FC6
11:26	<@MarkW>	riel: Is there some way of wiring up the iso to a domU and having anaconda install that way?
11:26	\|-\|	rharper [~rharper@bi01p1.co.us.ibm.com] has joined #xen
11:26	<riel>	you don't need the install-a-tron (/usr/bin/virt-install) if you extract kernel and initrd from the installation image yourself
11:27	<@MarkW>	riel: Ahhhhhh.
11:27	<@MarkW>	riel: Nifty.
11:27	<riel>	anaconda is the usual way to install guests
11:27	<riel>	all virt-install does is grab kernel and initrd for you, and set up the virtual machine, etc... :)
11:27	<icblenke>	all quite easy to do manually.
11:27	<riel>	icblenke: yeah
11:28	<@MarkW>	I'm just taking a look at the RHEL 5 beta release now, but my dom0 would be CentOS 4 because I can't afford to buy an actual release version of RHEL
11:28	<@MarkW>	Feels like I ought to take a look at it though...
11:28	<riel>	RHEL5 Xen is working well enough now that I'm getting around to tracking down minor bugs, stuff like "restoring a ballooned guest wants all the memory the guest could ever have, and only frees up the rest later"
11:28	<riel>	we have RHEL4 Xen guest kernels available, too
11:28	<@MarkW>	riel: Have we still not fixed that ballooning thing? Grrrr, that breaks migration too under some circumstances.
11:29	<riel>	MarkW: exactly
11:29	<riel>	I'm reading xc_linux_save.c now
11:29	<riel>	will read the restore in a bit
11:29	<riel>	to figure out how these things work
11:29	<@MarkW>	riel: From what I've seen of the RHEL 5 Xen support, it looks really awesome.
11:30	<riel>	MarkW: virt-manager is neat, it shows me nice graphs of the cpu use of all my domains
11:30	<@MarkW>	RHEL seems like it's really become a bit of a one-stop-shop for advanced server stuff.
11:30	<icblenke>	xc_private.c has a reference to __thread storage for some private error message function, only apparently referenced by ia64, is it really necessary?
11:30	<riel>	small enough to fit in-between my gnome terms
11:30	<riel>	MarkW: that's one of our goals - stuff should just work, instead of requiring customers to puzzle together the bits and pieces themselves
11:30	<@MarkW>	riel: Yeah virt-manager looks great
11:31	<murb>	i like google, do you mean dirtmanager :-)
11:31	<@MarkW>	riel: The save / restore stuff is basically a bit stupid, IIRC, in that it tries to allocate whatever the domain's memory footprint is in the config data stored with the image
11:32	<riel>	we also did some stuff about stateless in RHEL5
11:32	<@MarkW>	riel: Rather than remembering what the domain actually expected. Mind you, I'm not sure what it does with that memory after it's been allocated, since (one hopes) it ought to at least be freed back to Xen at some stage.
11:32	<riel>	one of the benefits of virtualization is that people can run way more operating system images than they could before - this is also its biggest danger :)
11:32	<@MarkW>	murb: That's a good one :-)
11:32	<riel>	yeah, it does get freed back
11:33	<riel>	at home I went from 3 computers to 2
11:33	<@MarkW>	riel: I guess the correct fix would probably be to add a "mem-current" variable to the config data in the save image... and then use that instead, I guess.
11:33	<riel>	and from 3 operating system instances to 5
11:33	<@MarkW>	riel: Xen has caused me to run far more physical systems that I would without it :-) But that's true with any development platform I guess.
11:34	<riel>	yeah, at work I play with Xen
11:34	<riel>	at home I actually use it
11:34	<@MarkW>	riel: Since I obviously have to have separate test and development machines :-)
11:34	<@MarkW>	riel: I don't actually use Xen for anything at the moment, because I don't really have any servers I need to virtualise. So the stuff I do is either playing, or "work" (more complicated playing)
11:35	<@MarkW>	icblenke: xc_private.c ... /me looks
11:35	<riel>	processing 400,000 spams/day is heavy enough to require its own virtual machine
11:36	<riel>	the database is very I/O intensive, so it wants to be on a different spindle
11:36	<riel>	and the web server should not get slowed down by the other two, so that's another virtual machine :)
11:37	<@MarkW>	icblenke: What's the function in question?
11:38	<@MarkW>	riel: Wow, OK. I guess that's a fair usecase :-)
11:38	<riel>	before the RHEL4 Xen kernel existed, I used full virtualization
11:38	<riel>	oh, this is all x86-64
11:38	<riel>	this is how I found the hypervisor HVM stack overflow last summer
11:39	<@MarkW>	riel: I dream occasionally of migrating a "desktop" VM to work and back, and occasionally onto my laptop for going away.
11:39	<@MarkW>	riel: how are you finding the full virt? Does it work well? Do you use the paravirt IO drivers?
11:39	<riel>	I'm using only paravirt nowadays
11:39	<riel>	but full virt works pretty well
11:39	<@MarkW>	I run almost exclusively x86-32
11:39	<riel>	bah, 32 bit legacy stuff :)
11:39	<@MarkW>	I can do amd64 in theory, but haven't got around to it.
11:40	<@MarkW>	:-)
11:40	<@MarkW>	I didn't want to pay lots of money for my test box, so I didn't get HVM-capable...
11:40	<@MarkW>	But it is an Athlon 64 - ironic, as the only reason I bought it was that Intel Research Cambridge shut down and took my test machine with them!
11:40	<riel>	pentium-D is cheap
11:41	<@MarkW>	riel: true
11:41	<riel>	btw, using the machine as a desktop, with these 3 server guests running, is a good scheduler test too
11:42	<icblenke>	until HVM save/restore/migrate comes to 3.0.5, it's still a bit iffy. also, with PV, 64bit runs only 64bit, where HVM can run 32bit.. (granted, you can run 32bit on a 64bit kernel).
11:43	<icblenke>	Virtual Iron has HVM migration working, anyone know if 3.1 Enterprise Beta's HVM migration works?
11:51	<@MarkW>	icblenke: 32-on-64 is coming for PV at some point
11:52	<@MarkW>	icblenke: initially it'll be 32-bit PAE on 64-bit. I'm not quite clear on the restrictions though, I'm not sure that "legacy" 32-bit Xenified kernels will be able to run unmodified
12:04	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has joined #xen
12:04	<murb>	have any 32 on 64 patches been published?
12:04	<murb>	i've seen the new domain builder stuff, but that didn't seem to include it.
12:11	<@MarkW>	murb: I'm not sure
12:11	<@MarkW>	Jan Beulich was working on them I think
12:22	\|-\|	athomas [~athomas@host86-134-167-36.range86-134.btcentralplus.com] has quit [Quit: Leaving]
12:23	<icblenke>	the artificially low limit of 32 xenbake/xenmon domains is silly.
12:24	<@MarkW>	icblenke: mmm. can probably be fixed quite easily, presumably?
12:25	<icblenke>	very easily. by recompiling. I've helped at least 2 tortured souls so far that have hit that particular limit rather nastily and were blindsided by the 32 limit.
12:25	<@MarkW>	The obvious thing would be to make it dynamic...
12:25	<@MarkW>	I should think it just wasn't within the scope of what the authors were trying to do.
12:25	<@MarkW>	We'd take patches to improve the situation though :-)
12:26	<icblenke>	I'm working up an rrd patched version of xenmon to collect xenbake stats historically.
12:26	<riel>	MarkW: btw, the balloon-on-restore thing really bites some setups
12:26	<riel>	MarkW: imagine a system where the virtual machines get resized dynamically based on load :)
12:26	<@MarkW>	riel: Yes, I'm not surprised.
12:26	<riel>	and the sum of maximum memory for the domains (obviously) won't fit in memory
12:27	<riel>	this is yet another prerequisite to project goldilocks
12:27	<@MarkW>	riel: And dynamically resizing on load is an obvious thing to combine with dynamic migration according to load...
12:27	<@MarkW>	Project Goldilocks?
12:27	<riel>	yeah
12:27	<riel>	"this cache is too hot"
12:27	<riel>	"this cache is too cold"
12:27	<@MarkW>	lol :-)
12:27	<riel>	resizing happens
12:27	<@MarkW>	The later on a load of bears live migrate onto your server!
12:28	<riel>	I'm dealing with the bears now
12:28	<@MarkW>	"Somebody's been thrashing my cache!"
12:28	<riel>	yeah
12:28	<@MarkW>	we'll be wanting the xm runawayrunaway! command then :-)
12:28	<riel>	with the /proc/refaults stuff, we can measure it quite nicely
12:29	<@MarkW>	Sounds cool though. Are you reporting domU load stuff back to some control daemon?
12:29	<riel>	later on I can work on implementing clock-pro in the kernel again, to reduce the memory footprint of the domains further
12:29	<riel>	heh, I have not implemented any of the userspace stuff yet
12:29	<riel>	too many dependencies in xen and the xen tools to fix first
12:29	<riel>	like this issue
12:29	<@MarkW>	Yep, OK.
12:29	<riel>	and the "boot a domain with less than its maximum amount of memory", which glauber fixed last month
12:29	<riel>	etc...
12:30	<@MarkW>	Anyone who clears up some of our long list of things nobody really wants to fix
12:30	<@MarkW>	deserves some kind of medal
12:30	<icblenke>	where is this list? I'd love to add to it.
12:31	<riel>	icblenke: add to the list of stuff other people should do? :)
12:31	<icblenke>	:P
12:31	<@MarkW>	riel: me too me too!
12:31	<@MarkW>	icblenke: Well, I guess in principle it should be the bugzilla...
12:34	<@MarkW>	I've not looked at the bugzilla in ages though
12:37	\|-\|	agrif_away [~agriffis@156.153.254.66] has quit [Ping timeout: 480 seconds]
12:38	\|-\|	msinhore [~msinhore@correio.samurai.com.br] has quit [Ping timeout: 480 seconds]
12:38	\|-\|	msinhore [~msinhore@mail.samurai.com.br] has joined #xen
12:41	\|-\|	aliguori [~anthony@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
12:41	<icblenke>	neat. netif=1 and blkif=1 allow a domU to export backends (net and block)... I don't think there is a serialif= as that is an evtchn thing handled by the likes of xenconsoled.
12:43	<@MarkW>	icblenke: Yes, that's a nifty feature.
12:43	<@MarkW>	icblenke: You ought to be able to restart the backend domain and have the frontend domain recover access to the device, seamlessly.
12:44	\|-\|	aliguori [~anthony@bi01p1.co.us.ibm.com] has joined #xen
12:44	<@MarkW>	I'm not sure if it works these days, but it used to. We used it to allow us to run net and block drivers that could recover from crashes due to driver bugs. It was pretty cool, although we didn't actually try it with real world (or fake) driver bugs, just killed the driver domain and restarted.
12:48	<icblenke>	the 3 network device limit makes me sad.
12:50	<@MarkW>	icblenke: Mmm. Think it's fairly arbitrary
12:50	<@MarkW>	icblenke: Suspect more could be supported with a bit of hacking...
12:52	\|-\|	aliguori [~anthony@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
12:54	<icblenke>	it was a change in 3.0.3. 3.0.2 had no such limit.
12:54	<@MarkW>	I suspect it's to do with the page flipping
12:55	\|-\|	aliguori [~anthony@bi01p1.co.us.ibm.com] has joined #xen
12:55	<@MarkW>	either limits on how much memory can be allocated for page flipping, or limits on the number of active grants...
12:57	<icblenke>	apparently it has something to do with the size of a guest's grant table.
12:58	<icblenke>	there isn't a hypercall to allow a guest to extend the size of its grant table, or by allowing the allocation of grant table entries to a VIF as dynamic (the blkfront driver does this now?)
12:59	<icblenke>	that from a post by Iam Pratt: http://permalink.gmane.org/gmane.comp.emulators.xen.user/18410
13:05	\|-\|	bernarde [~bernarde@201-43-198-215.dsl.telesp.net.br] has quit [Remote host closed the connection]
13:07	<@MarkW>	icblenke: mmm, ok.
13:08	<@MarkW>	I'm not sure if the blkfront driver does anything like that but I suspect it doesn't need to because it only needs to do grants when there are actual IOs in progress
13:08	<@MarkW>	Whereas the net driver has to pre-emptively perform the grants for the page-flipping to work.
13:08	<@MarkW>	I was under the impression that page flipping itself would be going away at some point, though.
13:09	<icblenke>	so it was introduced in 3.0.3 and will be going away?
13:09	<icblenke>	shades of bvt/sedf.. credit is the one true way. all hail credit.
13:11	<@MarkW>	icblenke: page flipping has been around forever, it's just the hard limit of 3 vifs that seems to have been added in 3.0.3
13:11	<@MarkW>	in principle, page flipping gives performance benefits, but not under all circumstances.
13:12	<@MarkW>	When a vif starts up it allocates a load of memory and relinquishes its ownership of it, then creates a pool of transfer grants allowing the domU to receive new page frames from dom0
13:13	<@MarkW>	When dom0 receives network packets, it looks to see what domU they should go to, then simply reassigns ownership of that pageframe to that domU
13:13	<@MarkW>	This loss of pageframes from dom0 is compensated for by the pages that were reliquished by the domU.
13:13	<icblenke>	in a ring-buffer fashion.
13:14	<@MarkW>	The transfers happen out-of-band, and the ring buffer contains only the information the domains need to map the transferred pages.
13:14	<icblenke>	or is it a pool that can never be resized?
13:14	<@MarkW>	Well, the problem is probably something like this:
13:14	<@MarkW>	each vif wants to relinquish r frames and create r transfer grants
13:15	<@MarkW>	if you have n vifs, you'll relinquish n * r frames and create n * r grants
13:15	<@MarkW>	but the grant tables can accommodate at most G grants and the domU has at most M frames of memory.
13:16	<@MarkW>	if n (number of vifs) gets too big, you'll exhaust either G or M simply in initialising the vifs...
13:16	<icblenke>	ah. I see. so the initial static allocation was reduced in 3.0.3.
13:16	<@MarkW>	I suspect 3.0.3 limits n (number of vifs) such that n * r can't get absurdly huge.
13:16	<icblenke>	and cause other problems. I see.
13:17	<@MarkW>	Such as exhausting the number of grant table entries the domain has
13:17	<@MarkW>	You could support (almost) arbitrary numbers of vifs if the grants were handled differently, eg.:
13:17	<@MarkW>	a) provide a domain with a hypercall for enlarging the grant table each time it gets filled with vif-related grants (do the call when n*r = G)
13:18	<@MarkW>	or b) have the domain create R grants, which are shared amongst n vifs, no matter what size n is
13:18	<@MarkW>	if you have more vifs, then there'll be less grants in the pool available per vif, and the same total number of grants (so you can never overflow the grant table).
13:19	<@MarkW>	The limit is basically there to stop you shooting yourself in the foot by exceeding pre-existing implicit limits due to the vif implementation
13:19	<icblenke>	the best solution would be to dynamically size the grant pool on the fly.
13:24	<@MarkW>	icblenke: Yep, with a ceiling to stop things getting too ridiculous :-)
13:25	<@MarkW>	Although actually for my XenFS work I actually do want a great huge big grant table anyway, so it'd be quite nice to see the corresponding hypercall in place...
13:27	<icblenke>	With OCFS2/GFS and either DRBD 0.8 or an iSCSI/AoE SAN setup, XenFS really only makes sense if everything is on one xen machine.. spanning machines isn't in XenFS' scope, is it?
13:29	<icblenke>	XenFS would likely kick the pants off of OCFS2 and a shared ",w!" backend device though.
13:29	<@MarkW>	icblenke: you might want to use it to export that kind of device transparently to guests, so they don't have to be correctly configured to use it
13:30	<@MarkW>	so it could be complimentary
13:30	<@MarkW>	I also have a design for how it'd work to improve migration performance, which would be extremely cool if I could pull it off ;-)
13:34	<icblenke>	it would likewise be neat to find a cluster aware filesystem, ala dd-raid (http://sources.redhat.com/cluster/ddraid/)
13:36	<icblenke>	GPFS is a bit pricey, and the big network filesystems really aren't ideal for storing large block devices for virtual domains, though that's probably better left to a cluster aware volume manager (ADIC's StorNext / Apple Xsan, etc etc)
13:36	<icblenke>	when you grow beyond one hardware box, things become harder to provision/manage.
13:37	<@MarkW>	Yep
13:42	<icblenke>	OpenSSI has CFS to mirror roots across cluster members, OpenMosix has DFSA/MFS, Kerrighed has KerFS, granted those are single server images with unified cluster filesystem space.
13:43	<icblenke>	Xen is rather alone in its thinking. the "clusterability" of Xen is rather light so far, and primarily concerned with offering a service provisionable platform, not a service provisioning platform itself.
13:43	<icblenke>	but I guess that is where xen-host, libvirt, Amazon EC2, and others step in to fill the void.
13:47	<@MarkW>	Xen doesn't really try to solve the problem of unified storage... it's left up to user configuration
13:47	<@MarkW>	It'd be nice to have it work more out of the box though... presumably the integration with e.g. RHEL and perhaps the XenSource commercial tools will enable that sort of thing to work well
13:48	<icblenke>	here's to hoping.
13:51	\|-\|	Maxou [~max@edony.tuxfamily.net] has quit [Ping timeout: 480 seconds]
13:58	\|-\|	Maxou [~max@edony.tuxfamily.net] has joined #xen
14:00	\|-\|	aliguori [~anthony@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
14:25	<riel>	icblenke: we've got some integration between xen and our cluster suite now
14:30	\|-\|	aliguori [~anthony@bi01p1.co.us.ibm.com] has joined #xen
14:33	\|-\|	ivan [~ikelly@5ac19701.bb.sky.com] has joined #xen
15:17	\|-\|	cableman [~cableman@3e6b7156.rev.stofanet.dk] has quit [Quit: Leaving]
16:03	\|-\|	KriP [kp@yancey.unixworld.dk] has quit [Quit: Leaving]
16:05	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has quit [Quit: Leaving]
16:48	\|-\|	samy [~Samuel@d213-103-237-246.cust.tele2.fr] has joined #xen
16:48	<samy>	Hi,
16:49	<samy>	Are there plans to make it possible domUs to be fed with several ramdisk with command lines? (a bit like grub's "module" command)
16:50	<icblenke>	you mean like multiboot?
16:50	<samy>	yes
16:50	<icblenke>	pygrub might, mbootpack might
16:50	<icblenke>	are you talking about a PV or an HVM domU?
16:50	<@MarkW>	samy: you can't do that for PV domUs at the moment
16:51	<samy>	PV I guess (no particular hardware assist, that is)
16:51	<samy>	is there a strong reason for this ? I though it would just be a matter of boot_info conventions
16:51	<samy>	+t
16:52	<aliguori>	samy: no paravirtualized guest supports multiboot so why would you use this?
16:52	<aliguori>	linux can't boot from multiboot AFAIK
16:52	<samy>	I'm porting Mach to Xen
16:52	<samy>	and it needs multiboot-like modules
16:53	<samy>	for the moment I just can the modules and split + add command lines by hand
16:53	<samy>	which is kind of yucky :)
16:53	<samy>	s/can/cat
16:53	<@MarkW>	mmm.
16:53	<@MarkW>	Any specific apps you want to run on top of Mach?
16:53	<samy>	the Hurd
16:54	<@MarkW>	I thought as much. What happened to L4/Hurd btw?
16:54	<samy>	they realized that L4 was not exactly what they wanted
16:54	<samy>	hence looking for another µkernel
16:54	<@MarkW>	Really? What are they moving to now?
16:54	<samy>	but in the meanwhile Mach/Hurd works fine
16:54	<@MarkW>	But yeah... maybe some extension to the domain builder would do what you want.
16:54	<samy>	CoyotOS maybe
16:55	<samy>	MarkW: ok. Can I just submit a wish-bug and let people think about it ?
16:55	<@MarkW>	Maybe best to ask on xen-devel, that'll get things noticed.
16:55	<samy>	ok
16:56	<aliguori>	samy: you're porting mach to xen?
16:56	<aliguori>	really?
16:56	<samy>	yes
16:56	<samy>	it's already working
16:56	<@MarkW>	It would be good to maximise compatibility with the existing domain building process...
16:56	<samy>	didn't have the time to enable disk write though
16:56	<samy>	but translators etc work fine
16:57	<aliguori>	why not just port hurd directly to xen?
16:57	<@MarkW>	Guess we just need a well defined format for the builder to shove multiple ramdisks and arguments in there.
16:57	<samy>	aliguori: because xen doesn't provide kernel threads?
16:57	<aliguori>	ah
16:57	<@MarkW>	Mach does provide a lot of abstraction.
16:57	<hollisb>	it provides 5 differt kinds of IPC though, so that's cool right?
16:58	<samy>	MarkW: yup
16:58	<aliguori>	samy: does hurd rely on mach for scheduling?
16:58	<@MarkW>	hollisb: Hmmm not sure that's enough? ;-)
16:58	<aliguori>	sorry, i'm quite ignorant of hurd/mach
16:58	<samy>	currently yes
16:58	<samy>	(iirc)
16:58	<@MarkW>	Does it use Mach for device drivers?
16:58	<samy>	iirc, paging is userland-controlled, however
16:58	<samy>	yes
16:58	<samy>	except the text console and X
16:59	<aliguori>	I guess Mach is really pushing the whole microkernel definition there :-)
16:59	<samy>	but for the coming sound support, a user-level implementation is expected
16:59	<@MarkW>	samy: this is GNU Mach, right?
16:59	<samy>	yes
17:00	<@MarkW>	samy: any idea how far it is from the Mach used by Darwin? I'm just wondering if any of the code could be snatched by a darwin port if there was one...
17:00	<samy>	Machs have split quite a long time ago
17:00	<samy>	I don't know how far they are
17:00	<@MarkW>	aliguori: Mach ended up not even remotely Micro, I think :-) But the projects coming out of it were still more microkernel than most other full featured systems of the time.
17:00	<samy>	but I can have a look at Darwin's, if I find a URL :)
17:01	<@MarkW>	No idea where it'd be...
17:02	<@MarkW>	most obvious place is probably apple's darwin CVS (if it's up to date at the moment...)
17:02	<aliguori>	MarkW: no wonder i've heard so much criticism of mach from microkernel folks :-)
17:02	<@MarkW>	I don't think it's a separate project.
17:03	<samy>	I found the software source code dowload page, but no kerel
17:03	<@MarkW>	aliguori: I think it got more lean over time. And it did have some really cool features. But compared to Xen / L4 it's relatively ... macro :-) Provides much higher level primites.
17:03	<samy>	ah, it's Mach 3.0 - based
17:03	<samy>	GNU mach is too
17:04	<@MarkW>	samy: Cool.
17:04	<@MarkW>	I hope there's some commonality... maybe enough for device driver or platform initialisation code to be shared. Fingers crossed.
17:04	<@MarkW>	But that's for the future, anyhow - so far nobody has been brave enough to port Darwin
17:05	<samy>	ah, it's called xnu on the download page
17:05	<icblenke>	opendarwin is dead, isn't it?
17:05	<samy>	LOG IN
17:05	<samy>	grah
17:06	<@MarkW>	The OpenDarwin project is dead
17:06	<@MarkW>	There's GNU Darwin though...
17:07	<@MarkW>	On PPC you used to be able to build a darwin kernel and boot MacOS X with it. Sadly, I don't think you can do that on Mactels
17:07	\|-\|	ivan [~ikelly@5ac19701.bb.sky.com] has quit [Remote host closed the connection]
17:18	\|-\|	aliguori [~anthony@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
17:38	\|-\|	aliguori [~anthony@cpe-70-112-17-156.austin.res.rr.com] has joined #xen
17:42	\|-\|	rpg [~rpg@bi01p1.co.us.ibm.com] has quit [Remote host closed the connection]
17:49	\|-\|	samy [~Samuel@d213-103-237-246.cust.tele2.fr] has quit [Quit: Leaving.]
18:14	\|-\|	pvanhoof [~pvanhoof@d54C0EE14.access.telenet.be] has joined #xen
18:21	\|-\|	hollisb [~hollisb@bi01p1.co.us.ibm.com] has quit [Quit: leaving]
18:22	\|-\|	stekloff [~stekloff@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
18:24	\|-\|	rharper [~rharper@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
18:24	\|-\|	ns [~niv@bi01p1.co.us.ibm.com] has quit [Quit: .]
18:37	\|-\|	tschwinge [~user@l3.cip.ei.uni-stuttgart.de] has left #xen [ERC Version 5.0.4 $Revision: 1.726.2.21 $ (IRC client for Emacs)]
18:37	\|-\|	gerrit [~gerrit@bi01p1.co.us.ibm.com] has joined #xen
19:17	\|-\|	mdday [~mdday@cpe-024-163-122-235.nc.res.rr.com] has quit [Quit: Ex-Chat]
19:26	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has quit [Quit: Leaving]
19:28	\|-\|	slim [~akil@cust150-45.tvcabo.co.mz] has joined #xen
19:28	\|-\|	slim [~akil@cust150-45.tvcabo.co.mz] has left #xen []
19:47	\|-\|	gerrit [~gerrit@bi01p1.co.us.ibm.com] has quit [Quit: Client exiting]
20:35	\|-\|	pvanhoof [~pvanhoof@d54C0EE14.access.telenet.be] has quit [Remote host closed the connection]
20:37	<@MarkW>	riel: you about?
20:39	<riel>	yeah
20:41	<@MarkW>	Sorry to bug you. Just wondered what the status of Fedora installs in PV guests are...
20:41	<@MarkW>	Do I just do the same trick with pulling out the kernel and initrd?
20:42	<riel>	yeah, Fedora and RHEL use the same tricks
20:42	<@MarkW>	Sweet.
20:42	<@MarkW>	Do both support install using PV framebuffer?
20:43	<riel>	they do
20:43	<@MarkW>	Sweet :-D
20:43	<@MarkW>	Thanks very much, I'm going to play with this (and virt-manager)
20:44	<@MarkW>	All too easy to distract me from work. ;-) At the moment I'm doing some work for XenSource on fault injection
20:44	<riel>	neat
20:45	<@MarkW>	The idea is to perturb hypercall arguments (and eventually PTEs etc) and see if Xen catches them, or just explodes :-)
20:46	<@MarkW>	Hopefully not too many explosions, but it'd be nice to see a few for my effort!
21:07	<aliguori>	MarkW: I had written something like that a while ago
21:07	<aliguori>	a xencrashme
21:07	<@MarkW>	aliguori: Really? What kind of stuff did it do?
21:08	<aliguori>	it only did dom0_ops, but it would pass random arguments to each call but would statistically lean toward good arguments
21:08	<@MarkW>	Cool.
21:08	<@MarkW>	Is there any source code about?
21:08	<aliguori>	that way, you would get series of good calls but also random
21:08	<@MarkW>	I'm taking the approach of sometimes injecting faults into real calls made by running domains
21:08	<aliguori>	but since it's random, you get theoritical "full coverage". i basically stole the idea from tridge's new test suite for samba4
21:09	<@MarkW>	Actually, all of it is implemented in Xen itself, but before argument checking happens.
21:09	<aliguori>	MarkW: let me see if I still have it.. that was a long time ago
21:09	<@MarkW>	there'll just be a build flag to build "evil" versions of Xen :-)
21:09	<aliguori>	sorry, i don't see it in my web dir
21:09	<aliguori>	heh :-)
21:09	<aliguori>	make evil=y
21:13	\|-\|	SLot [~SLot___@gustavo.gruposim.com.br] has quit [Ping timeout: 480 seconds]
21:19	\|-\|	SLot [~SLot___@gustavo.gruposim.com.br] has joined #xen
21:32	<@MarkW>	riel: would it be feasible to persuade the install to run with a non-PAE kernel? I'm trying to avoid PAE on this system, although I can see why it makes more sense for RHEL...
21:33	<riel>	yeah, you'll have to compile a non-PAE xen kernel though
21:33	<@MarkW>	I tried my standard kernel and anaconda couldn't find any devices...
21:34	<@MarkW>	I'm assuming I need the RH patches in order for this to work sensibly?
21:34	<riel>	don't think so
21:34	<riel>	which kernel are you using?
21:35	<riel>	our xen bits are 3.0.3 w/ some fixes and improvements from 3.0.4
21:35	<@MarkW>	It's a kernel I built out of Xen unstable just after the 3.0.4 release...
21:36	<@MarkW>	I'm passing a virtual disk as hda, and the iso as hdc...
21:36	<riel>	don't use 2.6.16 :)
21:36	<@MarkW>	Is it missing bits?
21:37	<riel>	did you try xvda and xvdb ?
21:39	<@MarkW>	That doesn't seem to work either...
21:39	<@MarkW>	what's lacking in the 2.6.16 kernel?
21:40	<riel>	not sure
21:40	<riel>	is there anything in /sys on the kernel you're booting?
21:40	<@MarkW>	I get a "no driver found" out of anaconda...
21:40	<riel>	could be something is missing from your initrd?
21:41	<@MarkW>	I was trying to use the fedora install initrd, since the kernel has all the necessary drivers compiled in (I think)
21:42	<riel>	so you're trying to load PAE modules into a non-PAE kernel?
21:43	<@MarkW>	riel: Well, it shouldn't need to load any modules, since I compiled them statically...
21:43	<@MarkW>	But the fact that loading fails may be confusing anaconda anyway.
21:44	<@MarkW>	I guess...
21:45	<riel>	dunno
21:45	<@MarkW>	Oh well.
21:45	<@MarkW>	Thanks for your help anyway!
21:57	\|-\|	minemaz0 [~mine@ppps0271.kitakyushu01.bbiq.jp] has joined #xen
21:58	\|-\|	minemaz0 [~mine@ppps0271.kitakyushu01.bbiq.jp] has quit []
22:41	\|-\|	minemaz [~mine@ppps0271.kitakyushu01.bbiq.jp] has quit [Read error: Connection reset by peer]
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:21	\|-\|	brianw [~ahzz@pool-71-170-81-199.dllstx.fios.verizon.net] has quit [Remote host closed the connection]
---	Log	closed Wed Jan 03 00:00:20 2007