TheGrebs.com:IRC Logs:#xen:2006:03:07

---	Log	opened Tue Mar 07 00:00:38 2006
00:01	\|-\|	praveenr [~praveen@proxy.iiit.ac.in] has joined #xen
00:02	\|-\|	praveenr [~praveen@proxy.iiit.ac.in] has quit [Quit: ]
00:02	\|-\|	praveenr [~praveen@proxy.iiit.ac.in] has joined #xen
00:54	\|-\|	rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Client exiting]
01:00	\|-\|	Calc [~Calc@mvil2.bb.netvision.net.il] has joined #xen
01:04	\|-\|	Calc [~Calc@mvil2.bb.netvision.net.il] has left #xen []
02:00	\|-\|	tonfa [~tonfa@arakou.residence.ens-lyon.fr] has quit [Read error: Connection reset by peer]
02:05	\|-\|	sonorous [skirr@iterum.attenuate.org] has joined #xen
02:18	\|-\|	franR [~franr@inextensia.net] has joined #xen
02:24	\|-\|	sdog [~sdog@62.58.98.210] has joined #xen
02:28	\|-\|	spb [~spb@pan.object4.net] has quit [Read error: Operation timed out]
02:28	\|-\|	spb [~spb@pan.object4.net] has joined #xen
02:30	\|-\|	sonorous_ [simon@iterum.attenuate.org] has joined #xen
02:33	\|-\|	sonorous [skirr@iterum.attenuate.org] has quit [Ping timeout: 480 seconds]
02:38	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
02:48	\|-\|	pdx6_ [~ballew@209.237.242.37] has joined #xen
02:49	\|-\|	pdx6 [~ballew@209.237.242.37] has quit [Remote host closed the connection]
03:05	\|-\|	pdx6 [~ballew@209.237.242.37] has joined #xen
03:05	\|-\|	pdx6_ [~ballew@209.237.242.37] has quit [Read error: Connection reset by peer]
03:06	\|-\|	Arnaud [~Arnaud@82.138.86.21] has joined #xen
03:09	\|-\|	pvanhoof [~pvanhoof@mailhost.newtec.be] has joined #xen
03:14	\|-\|	athomas [~athomas@host86-136-81-69.range86-136.btcentralplus.com] has joined #xen
03:50	\|-\|	ivan [~ikelly@83-71-74-95.b-ras1.lmk.limerick.eircom.net] has joined #xen
04:07	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has quit [Read error: Connection reset by peer]
04:07	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
04:28	\|-\|	horms [~horms@vagw.valinux.co.jp] has quit [Quit: Leaving]
04:34	\|-\|	pea [~pea@ppp-69-223-82-199.dsl.dytnoh.ameritech.net] has quit [Ping timeout: 480 seconds]
04:41	\|-\|	sonorous_ changed nick to sonorous
05:00	\|-\|	pvanhoof [~pvanhoof@mailhost.newtec.be] has quit [Remote host closed the connection]
05:30	\|-\|	horms [~horms@p2191-ipbf409marunouchi.tokyo.ocn.ne.jp] has joined #xen
05:48	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
05:54	\|-\|	michal` [~michal@www.rsbac.org] has quit [Read error: Connection reset by peer]
06:09	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
06:11	\|-\|	pvanhoof [~pvanhoof@mailhost.newtec.be] has joined #xen
06:44	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
06:58	\|-\|	cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has joined #xen
06:58	\|-\|	cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has left #xen []
07:10	\|-\|	bernarde [~bernarde@32.104.18.240] has joined #xen
07:22	\|-\|	horms [~horms@p2191-ipbf409marunouchi.tokyo.ocn.ne.jp] has quit [Quit: Leaving]
07:42	<hikenboot>	updates to the procedure -----> http://pastebin.ca/44743 <-----is this complete?
07:53	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has joined #xen
07:54	<hikenboot>	updates to the procedure -----> http://pastebin.ca/44743 <-----is this complete?
07:57	\|-\|	ygcheny [~ygcheny@gaia.lan2net.fr] has joined #xen
07:57	<ygcheny>	Hello !
07:58	<hikenboot>	Hello!
08:00	<hikenboot>	Hello all! this is the procude I have for compiling on Ubuntu...I need to know a couple steps in the middle and any other corrections can anyone help ( I will put this in a wiki) ---thanks in advance for your help----http://pastebin.ca/44771 <----- here it is
08:08	\|-\|	dykman [~dykman@bi-02pt1.bluebird.ibm.com] has joined #xen
08:18	\|-\|	dansmith [~dan@c-24-21-32-166.hsd1.or.comcast.net] has quit [Quit: Leaving]
08:21	\|-\|	ygcheny [~ygcheny@gaia.lan2net.fr] has quit [Quit: Leaving]
08:21	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Read error: Connection reset by peer]
08:25	\|-\|	hollisb [~hollisb@user-0vvde2g.cable.mindspring.com] has joined #xen
08:26	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
08:32	\|-\|	unriel changed nick to riel
08:33	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has joined #xen
08:55	\|-\|	hollisb [~hollisb@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
08:57	\|-\|	Basic_py [~Basic@warden.real-time.com] has quit [Quit: Leaving]
09:07	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has quit [Quit: Ex-Chat]
09:09	\|-\|	dansmith [~dan@129.33.1.37] has joined #xen
09:29	\|-\|	tonfa [~tonfa@arakou.residence.ens-lyon.fr] has joined #xen
09:44	\|-\|	aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
09:53	\|-\|	pea [~pea@ppp-70-227-53-62.dsl.dytnoh.ameritech.net] has joined #xen
09:58	\|-\|	hollisb [~hollisb@pixpat.austin.ibm.com] has joined #xen
10:02	\|-\|	jerone [~jerone@pixpat.austin.ibm.com] has joined #xen
10:04	\|-\|	rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
10:13	\|-\|	bweck [~k@ool-182e627d.dyn.optonline.net] has joined #xen
10:14	\|-\|	tab_ [~tab@darwin.snarc.org] has quit [Remote host closed the connection]
10:14	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has joined #xen
10:17	<bweck>	i'm experiencing this wierd issue where overnight, my dom0 stopped responding but all my domU's are working fine. It also seems outgoing connectivity from the dom0 is not working either. Any ideas?
10:18	<bweck>	I'm running Xen 3 (I believe the latest)
10:18	\|-\|	DV [~veillard@veillard.com] has quit [Ping timeout: 480 seconds]
10:25	\|-\|	DV [~veillard@veillard.com] has joined #xen
10:25	\|-\|	sdog [~sdog@62.58.98.210] has left #xen []
10:38	\|-\|	bweck [~k@ool-182e627d.dyn.optonline.net] has quit [Quit: ]
10:58	\|-\|	hollisb [~hollisb@pixpat.austin.ibm.com] has quit [Quit: leaving]
11:07	\|-\|	pvanhoof [~pvanhoof@mailhost.newtec.be] has quit [Remote host closed the connection]
11:07	\|-\|	jimix [~jimix@fw54.torolab.ibm.com] has joined #xen
11:10	\|-\|	stekloff [~stekloff@129.33.1.37] has joined #xen
11:11	\|-\|	itamarjp [~itamar@200-233-141-088.xd-dynamic.ctbcnetsuper.com.br] has joined #xen
11:24	\|-\|	athomas [~athomas@host86-136-81-69.range86-136.btcentralplus.com] has quit [Quit: Leaving]
11:24	\|-\|	aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Ex-Chat]
11:28	\|-\|	itamarjp [~itamar@200-233-141-088.xd-dynamic.ctbcnetsuper.com.br] has quit [Quit: ]
11:28	\|-\|	praveenr [~praveen@proxy.iiit.ac.in] has quit [Quit: Ex-Chat]
11:47	\|-\|	hollisb [~hollisb@user-0vvde2g.cable.mindspring.com] has joined #xen
12:06	\|-\|	pvanhoof [~pvanhoof@d54C0FBBD.access.telenet.be] has joined #xen
12:37	\|-\|	tab [~tab@darwin.snarc.org] has joined #xen
12:47	\|-\|	franR [~franr@inextensia.net] has quit [Quit: Error inopinée -10s, -9, -8... Unexpected error -10s, -9, -8,... Really ?]
12:48	\|-\|	jevere [~jevere@fmfwpr05.fm.intel.com] has joined #xen
12:48	<jevere>	hi guy
12:48	<jevere>	hi gurs
12:48	<jevere>	guys
12:48	<jevere>	sorry
12:48	<jevere>	I have a question:
12:48	<jevere>	is it possible to migrate a running guest from one CPU to another?
12:49	<jevere>	how can this be done?
12:50	<hikenboot>	yes you need to have a SAN or be using ISCSI or by using other transaction locking central storage
12:50	<hikenboot>	or even better ATA over ethernet
12:50	<hikenboot>	ATA over ethenet is simpler so i am told
12:55	\|-\|	aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
12:55	<hollisb>	do you mean CPU or do you mean system?
12:56	<hensema>	are there any ATAoE servers available apart from hardware devices?
12:57	<jevere>	just between CPUS in a SMP machine
12:58	<sdague>	jevere: man xm, look at the pin options
12:58	<jevere>	what is for the 'vcpus' option in the guest config file?
13:01	\|-\|	bestorga [~bestorga@63-230-161-130.ptld.qwest.net] has joined #xen
13:02	\|-\|	aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Ex-Chat]
13:03	\|-\|	wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has quit [Ping timeout: 480 seconds]
13:08	\|-\|	aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
13:44	\|-\|	jevere [~jevere@fmfwpr05.fm.intel.com] has quit [Quit: Leaving]
13:46	\|-\|	michal` [~michal@www.rsbac.org] has joined #xen
13:50	\|-\|	_MarkW [~MarkW@maw48.kings.cam.ac.uk] has joined #xen
13:54	<_MarkW>	hmmm is this working?
13:54	<_MarkW>	ah, that's better.
13:55	[~]	_MarkW is using Exceed under Windows to run his IRC client... It's a bit flakey sometimes.
13:55	<_MarkW>	aliguori: Yo, you around?
13:56	[~]	_MarkW wants somebody to rant to about sysfs attributes doing impossible things
14:02	<aliguori>	_MarkW, yeeeeeeeees
14:02	<aliguori>	_MarkW, define impossible :-)
14:03	\|-\|	bos31337 [~bos@nat-0.pathscale.com] has quit [Remote host closed the connection]
14:04	<hikenboot>	hensema ATA0E as far as I know is all software I dont think its been implemented in hardware at all
14:05	<hikenboot>	aliquori: can you tell me whats missing in my procedure between the dotted lines? ----->http://pastebin.ca/44743
14:06	<hollisb>	hikenboot: your irc client probably supports tab-completion. so type the first few chars of somebody's nick, then press tab
14:06	\|-\|	rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
14:06	<hollisb>	hikenboot: it's faster, and you don't have to worry about misspelling people
14:06	<hollisb>	's names
14:06	\|-\|	r_tothe_g [~rpg@cpe-70-113-92-193.austin.res.rr.com] has joined #xen
14:07	<hikenboot>	hollisb, good idea!
14:07	<hikenboot>	aliguori, can you tell me whats missing in my procedure between the dotted lines? ----->http://pastebin.ca/44743------P.S. sorry for the handle miss-spell
14:08	\|-\|	Shaun2222 [~ndci@ip68-5-63-223.oc.oc.cox.net] has joined #xen
14:12	<aliguori>	hikenboot, i've already said that compiling on your own is a bad idea. asking 5 times is not going to change that answer
14:13	<hikenboot>	ok thanks
14:14	\|-\|	jerone [~jerone@pixpat.austin.ibm.com] has quit [Read error: Connection reset by peer]
14:15	\|-\|	Shaun [~ndci@ip68-5-63-223.oc.oc.cox.net] has quit [Ping timeout: 480 seconds]
14:16	\|-\|	Shaun2222 changed nick to Shaun
14:17	<_MarkW>	aliguori: yo. i can't see what you just said because Exceed isn't letting me scroll back
14:17	<_MarkW>	yey for using Windows!
14:17	<aliguori>	_MarkW, lol!
14:17	<aliguori>	_MarkW, what are you doing on windows?!?
14:17	<aliguori>	_MarkW, so what impossible things are you trying to make sysfs do?
14:17	<_MarkW>	Working in a college computer room.
14:18	<_MarkW>	Well, I'm not trying to make sysfs do something impossible, it's just doing it.
14:18	<aliguori>	heh
14:20	<aliguori>	_MarkW, are you still working on xenfs btw?
14:20	<_MarkW>	I can trace the attempts to write to a sysfs attribute right the way down to the dcssblk driver
14:20	<aliguori>	ah, okay
14:21	<_MarkW>	But somehow, when the sysfs code calls into dcssblk the arguments mysteriously change
14:21	<aliguori>	heh
14:21	<aliguori>	like, at the actual point of invocation?
14:21	<_MarkW>	as in, before the function call they're correct, once the call occurs they're not. It wouldn't be so bad, except that I actually haven't done anything that evil to the code...
14:22	<aliguori>	are you compiling with different compiler settings?
14:22	<aliguori>	like, with an -fomit-frame-pointer somewhere
14:22	<aliguori>	or fast call
14:22	<_MarkW>	Well it's all standard settings from the vanilla Xen tree.
14:22	<aliguori>	interesting
14:22	<aliguori>	sounds like you've got stack corruption somewhere
14:23	<aliguori>	too bad you can't run valgrind on the kernel
14:23	<_MarkW>	It does indeed. Thing is, I don't see how it can happen, I know the function is called with the right arguments, but immediately it's executing they're no longer correct.
14:24	<aliguori>	that's very bizarre
14:24	<_MarkW>	And this is all in code _I didn't write_, so it really ought to work OK ;-)
14:24	<aliguori>	heh
14:24	<_MarkW>	Indeed. It's driving me mad. It's not even SMP, so there's no other CPU to corrupt that data either...
14:25	<aliguori>	yeah, maybe the printk is corrupting the stack?? that would be too weird though
14:25	<_MarkW>	spoink
14:25	<_MarkW>	a penny just dropped...
14:25	<tonfa>	any reason why dom0 directly reboots on panic ?
14:26	<aliguori>	tonfa, pass noreboot on the dom0 command line
14:26	\|-\|	jerone [~jerone@pixpat.austin.ibm.com] has joined #xen
14:26	<_MarkW>	tonfa: You can stop the system rebooting on panic by putting "noreboot" on Xen's commandline]
14:26	<tonfa>	ok, thanks
14:26	<_MarkW>	aliguori: I just figured it out. Now I feel dumb.
14:26	<aliguori>	or on xen's... _MarkW is probably right :-)
14:26	<aliguori>	_MarkW, what was it?
14:26	<_MarkW>	aliguori: I'm working on a snapshot of dcssblk from a month or two ago
14:27	<_MarkW>	aliguori: And in between then and now, the kernel devs thoughtfully changed the API for sysfs device attributes
14:27	<_MarkW>	doh! doh! doh!
14:27	<aliguori>	ahh :-)
14:27	<aliguori>	nice
14:27	<tonfa>	and blktap is not compiling in xen-unstable, but i suppose it is already known
14:28	<_MarkW>	tonfa: I think Andy Warfield is going to look at getting blktap to work a bit later. Right now there's nobody maintaining it.
14:28	<tonfa>	ok
14:28	<_MarkW>	aliguori: This explains why the stack looks dodgy - different number of arguments, of a different type. First time I've really been bitten by the incredibly fluid 2.6 APIs - the device model stuff seems to be really quite changeable.
14:29	<_MarkW>	But I got to use struct mutex for the first time today, which made me happy. It's nice to be developing on a bleeding-edge kernel for a change.
14:29	<aliguori>	_MarkW, yeah, passing the wrong number of arguments will definitely get you :-)
14:29	<aliguori>	heh
14:29	<_MarkW>	aliguori: semaphores are on their way out
14:30	<aliguori>	_MarkW, as they should be :-)
14:30	\|-\|	bestorga [~bestorga@63-230-161-130.ptld.qwest.net] has quit [Quit: Leaving]
14:30	<_MarkW>	the mutex patch is also another part of Ingo Molnar's realtime pre-emption patch
14:30	<_MarkW>	There seem to be lots of bits of it going in these days.
14:30	\|-\|	rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
14:30	<aliguori>	heh, realtime pre-emption seems like an oxymoron :-)
14:31	<_MarkW>	It does crazy stuff... like moving interrupt handlers into pre-emptable threads.
14:31	<_MarkW>	Making the BKL pre-emptible
14:31	<_MarkW>	Etc
14:32	<aliguori>	wiat
14:32	<_MarkW>	aliguori: eh?
14:32	<aliguori>	pre-empting an interrupt handler?
14:32	<aliguori>	that seems like a horribly bad thing to do
14:32	<_MarkW>	aliguori: yes, I know!!!
14:32	<hollisb>	heh
14:33	<_MarkW>	aliguori: it's a scary bit of code. I think it gives quite good predictability guarantees to realtime apps, though.
14:33	<hollisb>	hey, when you've got to go, you've got to go...
14:33	<_MarkW>	hollisb: :-)
14:33	<aliguori>	heh
14:35	<tonfa>	wha is the best way to pass data from xen to a domain ?
14:35	<tonfa>	shared page info + virq ?
14:35	<_MarkW>	tonfa: what kind of data?
14:35	<tonfa>	doing some kind of logging
14:35	<tonfa>	syscalls
14:35	<_MarkW>	tonfa: that's probably a good way of doing it
14:36	<tonfa>	ok, thanks
14:36	<_MarkW>	tonfa: logging domU syscalls in dom0?
14:36	<tonfa>	for example
14:36	<_MarkW>	tonfa: you might like to take a look at how the trace buffer works (xen/common/trace.c)
14:36	<_MarkW>	tonfa: Rob Gardner from HP is working on adding a VIRQ so that userspace can just block waiting for the buffer to fill up.
14:36	<tonfa>	nice
14:37	<_MarkW>	tonfa: he's currently blocked on some weird deadlock behaviour encountered whilst adding it. Hopefully we'll see a patch once he's cracked that problem.
14:47	\|-\|	hikenboot [~hikenboot@c-24-218-84-234.hsd1.ma.comcast.net] has quit [Remote host closed the connection]
14:47	<_MarkW>	yey!
14:48	<_MarkW>	I can talk to the DCSSBLK driver through sysfs under Xen, and it calls the Xen DCSS layer to get segment info...
14:48	<tonfa>	what is dcss ?
14:49	<_MarkW>	tonfa: It's an IBM mainframe feature that allows for big ramdisks to be accessed by multiple virtual machines
14:49	<tonfa>	ok
14:49	<_MarkW>	tonfa: Combined with their XIP (execute in place) patches, you can have multiple virtual machines sharing the ramdisk, and executing code directly from it, rather than copying it first.
14:50	<_MarkW>	tonfa: I'm making it work under Xen, partly because it has common stuff with my XenFS work, and partly because I want to write a paper about how XenFS is better ;-)
14:51	<tonfa>	is there paper about XenFS ?
14:52	<_MarkW>	tonfa: Not yet, I haven't finished enough of it ;-)
14:52	<_MarkW>	You can look at the XenFS page on the Xen Wiki, and on my homepage, for some details about it.
14:52	<_MarkW>	http://wiki.xensource.com/xenwiki/XenFS
14:52	<tonfa>	btw, i couldn't find performance comparison for xen3
14:52	<_MarkW>	http://www.cl.cam.ac.uk/~maw48/
14:53	<_MarkW>	There isn't a performance comparison for Xen 3, but it should in general be the same as Xen 2 unless we introduced any performance bugs.
14:53	<_MarkW>	Occasionally we spot performance regressions and work to track them down.
14:53	<tonfa>	i haven't tested xen2 but people told be IO was very
14:53	<tonfa>	and i couldn't see it in xen3
14:54	<_MarkW>	couldn't see what, sorry?
14:54	<tonfa>	a big performance loss compared to native linux
14:55	\|-\|	bernarde [~bernarde@32.104.18.240] has quit [Remote host closed the connection]
14:55	<tonfa>	(I just tried a simple 'dd')
14:55	<tonfa>	hum, i meant "IO was very bad"
14:55	<tonfa>	sorry
14:56	<_MarkW>	Disk IO in Xen 2, Xen 3, and native Linux should be pretty comparable
14:57	<_MarkW>	If disk IO degrades significantly, it's almost certainly a bug / quirk that you're seeing. Block devices have such high latency anyhow that the extra overhead of virtualising them shouldn't really matter.
14:57	<_MarkW>	Network IO virtualisation is harder, so you may see some degredation in that, depending on how powerful your CPU is and how pessimal your network load is.
14:58	<tonfa>	disk IO is faster in domU than in native linux :)
14:58	<tonfa>	(write)
14:59	<_MarkW>	tonfa: Yes, we found that. It's probably some weird interaction of domU and dom0 doing caching.
14:59	<_MarkW>	tonfa: We even found a substantial performance improvement in one application-level benchmark. But it really depends what you're doing with the machine, it's definitely not going to speed everything up.
15:00	<tonfa>	otherwise everybody would already use Xen
15:01	<_MarkW>	tonfa: Yeah :-)
15:01	<_MarkW>	Right, it's time for me to stop work. I'm still trying not to be nocturnal anymore.
15:01	<tonfa>	UTC ?
15:02	<_MarkW>	tonfa: Yep. (actually, I had to look that at, I'm used to thinking of it as GMT ;-)
15:03	<_MarkW>	Goodbye everyone. I'll be back soon. Well maybe tomorrow, anyhow.
15:03	\|-\|	_MarkW [~MarkW@maw48.kings.cam.ac.uk] has left #xen [Kopete 0.10.2 : http://kopete.kde.org]
15:04	\|-\|	rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
15:05	<DV>	aliguori: howdy
15:07	<aliguori>	DV: yo
15:09	<DV>	aliguori: you think you could commit your current state of xml-rpc or it's too early ?
15:09	<aliguori>	DV: working on it right now
15:10	<DV>	oh, sorry :-)
15:10	<aliguori>	will at least send a patch out today
15:10	<DV>	okay then I will probably look at it tomorrow morning
15:10	<DV>	I'm having a bit of fun with Qemu internals ATM :-)
15:11	<DV>	not very hard though
15:11	<aliguori>	oh
15:11	<aliguori>	what are you doing?
15:11	<aliguori>	DV, did you hack up an API on top of the monitor?
15:11	<DV>	just trying to get remote access to it
15:12	<DV>	trying to plug the monitor in unix/tcp sockets
15:12	<DV>	to allow a libvirt back-end
15:12	<aliguori>	DV: I see, I thought of that at one point but decided against it
15:13	<aliguori>	instead, i've just been connecting to the pty
15:14	<DV>	I asked Fabrice initially and he though it was a good idea at the time, so ...
15:14	<aliguori>	ah, well then there ya go :-)
15:14	<DV>	it's a French cabal ...
15:15	<DV>	err no there is no cabal of course
15:15	<aliguori>	hehe, that's right, you're both french :-)
15:15	<DV>	famous last words
15:15	<aliguori>	hehe
15:16	<hollisb>	heh
15:27	\|-\|	stekloff_ [~stekloff@bi01p1.co.us.ibm.com] has joined #xen
15:27	\|-\|	hbaum [~hbaum@bi01p1.co.us.ibm.com] has joined #xen
15:28	\|-\|	dansmith_ [~dan@bi01p1.co.us.ibm.com] has joined #xen
15:29	\|-\|	stekloff [~stekloff@129.33.1.37] has quit [Read error: Operation timed out]
15:29	\|-\|	hbaum_ [~hbaum@129.33.1.37] has quit [Read error: Operation timed out]
15:33	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has quit [Quit: Client exiting]
15:34	\|-\|	dansmith [~dan@129.33.1.37] has quit [Ping timeout: 480 seconds]
15:38	<tonfa>	any idea why xend does not work in xen-unstable ?
15:39	<tonfa>	there no socket in /var/lib/xend/
15:48	\|-\|	Bicster [~Bicster@ip195.planetfall.COM] has joined #xen
15:49	<Bicster>	hi aliguori
15:50	<aliguori>	howdy
15:59	\|-\|	hollisb [~hollisb@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
16:05	<sdague>	tonfa: does /var/lib/xenstore exist?
16:05	\|-\|	rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Client exiting]
16:05	<Bicster>	anyone care to speculate when unstable will be blessed as 3.0.2?
16:05	<Bicster>	1-2 weeks? longer?
16:06	<sdague>	probably after 2.6.16 releases as stable
16:06	<sdague>	doing a xen release based on an rc kernel level is something I wouldn't expect
16:06	<Bicster>	2.6.16 could happen any day
16:07	<sdague>	you could always ask on xen-devel ;)
16:07	<Bicster>	lol
16:07	<sdague>	I don't have any authoritative answers, only Ian and Kier know for sure
16:08	<sdague>	I also gave up trying to predict xen releases as long time ago ;)
16:10	<Bicster>	I would really like to know why vif devices are created with an fe:ff:ff:ff:ff:ff mac address. That was a major thorn in my side yesterday.
16:10	<DV>	Bicster: if I believe Murthy's law that's should be just after Fedora Core 5 got released
16:10	<Bicster>	If that Murthy guy is related to Murphy, we are all in trouble :P
16:10	<DV>	Murthy is clearly watching all of us and having lot of fun already
16:11	<DV>	yeah Murphy ...
16:12	<Bicster>	The other thorn in my side is that one of my Dell 380's refuses to work when both processor cores are enabled. I think it may actually have a faulty processor :-/
16:16	\|-\|	Bicster [~Bicster@ip195.planetfall.COM] has quit [Quit: Leaving]
16:16	\|-\|	Bicster [~Bicster@ip195.planetfall.com] has joined #xen
16:18	\|-\|	jimix [~jimix@fw54.torolab.ibm.com] has quit [Remote host closed the connection]
16:19	<tonfa>	sdague: i have '/var/lib/xenstored/tdb'
16:20	\|-\|	jimix [~jimix@fw54.torolab.ibm.com] has joined #xen
16:23	\|-\|	johnlev [~johnlev@nwkea-socks-1.sun.com] has quit [Ping timeout: 480 seconds]
16:23	\|-\|	johnlev [~johnlev@nwkea-socks-1.sun.com] has joined #xen
16:29	\|-\|	hollisb [~hollisb@pixpat.austin.ibm.com] has joined #xen
16:38	\|-\|	Bicster [~Bicster@ip195.planetfall.com] has quit [Quit: Leaving]
16:50	\|-\|	rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
17:08	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
17:20	\|-\|	riel changed nick to unriel
17:32	\|-\|	jerone [~jerone@pixpat.austin.ibm.com] has quit [Quit: Leaving]
17:38	\|-\|	aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Ex-Chat]
17:39	\|-\|	jimix [~jimix@fw54.torolab.ibm.com] has quit [Quit: jimix]
17:48	\|-\|	rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
17:49	\|-\|	hollisb [~hollisb@pixpat.austin.ibm.com] has quit [Quit: leaving]
17:57	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has joined #xen
18:03	\|-\|	dansmith_ [~dan@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
18:26	\|-\|	ivan [~ikelly@83-71-74-95.b-ras1.lmk.limerick.eircom.net] has quit [Quit: leaving]
18:26	\|-\|	dansmith [~dan@c-24-21-32-166.hsd1.or.comcast.net] has joined #xen
18:28	\|-\|	horms [~horms@vagw.valinux.co.jp] has joined #xen
18:31	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has quit [Quit: Leaving]
19:07	<johnlev>	anybody have an interesting opinion on a SCHEDOP_block_masked() that doesn't clear upcall_mask (and always unblocks regardless of pending when delivering event)
19:07	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has quit [Quit: Leaving]
19:10	\|-\|	stekloff_ [~stekloff@bi01p1.co.us.ibm.com] has left #xen [Leaving]
19:33	\|-\|	pvanhoof [~pvanhoof@d54C0FBBD.access.telenet.be] has quit [Remote host closed the connection]
19:47	\|-\|	bestorga [~bestorga@c-24-20-32-112.hsd1.or.comcast.net] has joined #xen
19:56	\|-\|	Bicster [~Bicster@ip195.planetfall.com] has joined #xen
20:07	\|-\|	bestorga [~bestorga@c-24-20-32-112.hsd1.or.comcast.net] has quit [Ping timeout: 480 seconds]
20:25	\|-\|	dansmith [~dan@c-24-21-32-166.hsd1.or.comcast.net] has quit [Quit: Leaving]
20:42	\|-\|	bestorga [~bestorga@c-24-20-32-112.hsd1.or.comcast.net] has joined #xen
21:01	\|-\|	bestorga [~bestorga@c-24-20-32-112.hsd1.or.comcast.net] has quit [Quit: Leaving]
21:14	\|-\|	Bicster [~Bicster@ip195.planetfall.com] has quit [Quit: Leaving]
21:28	\|-\|	iamlost [~jbrown105@jma-box.student.umd.edu] has quit [Remote host closed the connection]
21:29	\|-\|	iamlost [~jbrown105@jma-box.student.umd.edu] has joined #xen
21:44	\|-\|	horms [~horms@vagw.valinux.co.jp] has quit [Quit: Leaving]
21:54	\|-\|	r_tothe_g [~rpg@cpe-70-113-92-193.austin.res.rr.com] has quit [Remote host closed the connection]
22:10	\|-\|	perlbeginer [~perlbegin@61.246.224.226] has joined #xen
22:10	<perlbeginer>	Hello folks, i have a small issue with xen
22:11	<perlbeginer>	i have created domains and then it gets listed in the xm list command
22:11	<perlbeginer>	but the status is paused
22:11	<perlbeginer>	how do i make it running??
22:11	<perlbeginer>	domain0 is showing the status as running
22:14	\|-\|	pea [~pea@ppp-70-227-53-62.dsl.dytnoh.ameritech.net] has quit [Ping timeout: 480 seconds]
22:17	<aliguori>	perlbeginer, sounds like domain creation really failed.. and we're being stupid and didn't clean up the partially created domain
22:17	<aliguori>	perlbeginer, it's probably b/c you have a bad config
22:18	<aliguori>	perlbeginer, once you figure out what's wrong with your config, posting a bug in bugzilla would be a good idea
22:18	<aliguori>	perlbeginer, you can trouble shoot by looking at /var/log/xend.log and /var/log/xend-debug.log
22:19	<tonfa>	xm log
22:21	[~]	aliguori thinks xm log is just `cat /var/log/xend.log` right?
22:23	\|-\|	pea [~pea@ppp-70-227-53-62.dsl.dytnoh.ameritech.net] has joined #xen
22:24	<tonfa>	aliguori: i don't know but it could be that :)
22:24	<tonfa>	aliguori: what are you using instead of xm ?
22:25	<aliguori>	i still use xm
22:28	\|-\|	Basic_py [~Basic@fortress.tanners.org] has joined #xen
22:28	\|-\|	Basic_py [~Basic@fortress.tanners.org] has quit [Quit: ]
22:29	<perlbeginer>	i am using xen
22:29	<perlbeginer>	we are just tesing the performance and things like that
22:29	<aliguori>	perlbeginer, yeah, the error your seeing is probably a bad config file.. read above
22:29	\|-\|	Basic_py [~Basic@warden.real-time.com] has joined #xen
22:29	<perlbeginer>	may i know where exactly is the daemon that communicate between the domain0 and the gues domains
22:30	<perlbeginer>	ok
22:30	<perlbeginer>	<aliguori, there is no error in creation of the domains
22:30	<perlbeginer>	they are being created perfect
22:33	<aliguori>	perlbeginer, but they are paused?
22:33	<perlbeginer>	but i am not quite sure how i start the domains
22:33	<perlbeginer>	yes
22:33	<tonfa>	xm create -c <configfile>
22:33	<aliguori>	perlbeginer, there is an error, we're just not reporting it and not cleaning up after ourselves :-)
22:33	<aliguori>	it's a bug
22:33	<perlbeginer>	oh.. ok
22:33	<aliguori>	perlbeginer, this particular bug occurs often b/c it can happen for many different reasons.. we clearly haven't fixed all possible causes yet :-)
22:33	<perlbeginer>	oh.. ok
22:33	<aliguori>	so, the first thing to do is figure otu why your domain isn't starting properly
22:33	<perlbeginer>	doesnt the domain need its own fs for starting up?
22:33	<aliguori>	that is, check your config
22:33	<aliguori>	it needs a disk, yes
22:33	\|-\|	Basic_py [~Basic@warden.real-time.com] has quit [Quit: ]
22:33	<perlbeginer>	i have set the kernel for the domains as the same one that is being used by the xen
22:33	<perlbeginer>	:(
22:33	<perlbeginer>	is that something stupid from my end?
22:33	[~]	aliguori thinks for a moment
22:33	<aliguori>	yeah, that could be the problem
22:34	<aliguori>	i don't know if the xen0 kernel has the right frontend drivers
22:34	<perlbeginer>	ok
22:34	<perlbeginer>	[root@localhost ~][root@localhost ~]# xm create test vmid=11
22:34	<perlbeginer>	Using config file "test".
22:34	<perlbeginer>	Error: Device 2049 (vbd) could not be connected.
22:34	<perlbeginer>	Device /dev/sda18 is mounted in a guest domain,
22:34	<perlbeginer>	and so cannot be mounted now.
22:34	<perlbeginer>	this is the error
22:34	<perlbeginer>	but the domains are being created alright
22:35	<aliguori>	are you attempting to create multiple domains with /dev/sda18?
22:35	\|-\|	Basic_py [~Basic@warden.real-time.com] has joined #xen
22:36	<perlbeginer>	acutally i am using hdb
22:36	<perlbeginer>	and i have edited the conf files
22:36	<perlbeginer>	now the domains are being created
22:37	<perlbeginer>	# Kernel image file.
22:37	<perlbeginer>	kernel = "/boot/vmlinuz-2.6.12.6-xenU"
22:37	<perlbeginer>	this is the kernel variable
22:37	<aliguori>	ok
22:37	<perlbeginer>	i am using the same kernel variable as that used by xen
22:37	<perlbeginer>	i mean the same kernel image
22:38	<aliguori>	sorry, got to go
22:38	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has quit [Quit: Ex-Chat]
22:44	<perlbeginer>	Anyone else who has a considerable knowledge with xen?
22:44	<perlbeginer>	please help me
22:49	<tonfa>	you need a different disk for the domains
22:51	<perlbeginer>	yes, i have created a different image of fedora on the same server and mounted that to /mnt
22:52	<perlbeginer>	now can i use that partition as the root of this domain
22:52	<perlbeginer>	?
22:58	<tonfa>	no need to mount it
22:58	<tonfa>	just pass the image path as the disk
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:58	<perlbeginer>	do you have any idea how the communication between the domain0 and the guest domains work?
---	Log	closed Wed Mar 08 00:00:34 2006