--- Day changed

--- Log opened Mon May 09 23:59:02 2005
00:06 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
00:08 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
00:15 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [Quit: bug, n: A son of a glitch.]
00:15 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Ping timeout: 480 seconds]
00:28 -!- rusty [~rusty@CPE-139-168-158-101.nsw.bigpond.net.au] has joined #xen
00:30 -!- soffi [~soffi@proxy.du.vdsl.is] has quit [Quit: This computer has gone to sleep]
00:42 -!- DEac- [~deac@xdsl-213-196-207-111.netcologne.de] has quit [Ping timeout: 480 seconds]
00:45 -!- Squink [~purple@S010600131077a67e.vc.shawcable.net] has quit [Read error: Connection reset by peer]
00:55 -!- DEac- [~deac@xdsl-195-14-200-54.netcologne.de] has joined #xen
02:22 -!- lilo [~lilo@lilo.usercloak.oftc.net] has quit [Quit: bbiab]
02:29 -!- andy [~andy@andy.netop.oftc.net] has joined #xen
02:34 -!- lilo [~lilo@lilo.usercloak.oftc.net] has joined #xen
02:35 < andy> does xen support freebsd for domain 0, yet?
02:40 -!- Squink [~purple@S010600131077a67e.vc.shawcable.net] has joined #xen
02:52 -!- rusty [~rusty@CPE-139-168-158-101.nsw.bigpond.net.au] has quit [Quit: Client exiting]
03:45 -!- soffi [~soffi@proxy.du.vdsl.is] has joined #xen
03:46 < mael> lo
03:57 -!- soffi [~soffi@proxy.du.vdsl.is] has quit [Quit: This computer has gone to sleep]
04:12 -!- heb_away is now known as heb
04:19 < heb> hi
04:43 -!- athomas [~athomas@ppp-0-19.lond-a-1.access.uk.tiscali.com] has joined #xen
04:50 -!- drbyte [~byte@c210-49-121-44.eburwd3.vic.optusnet.com.au] has joined #xen
04:53 -!- soffi [~soffi@proxy.du.vdsl.is] has joined #xen
05:05 -!- soffi [~soffi@proxy.du.vdsl.is] has quit [Quit: This computer has gone to sleep]
05:27 -!- soffi [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has joined #xen
06:27 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has joined #xen
07:27 -!- soffi [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has quit [Quit: Leaving]
07:40 -!- Sting [~sting@mvil2.bb.netvision.net.il] has joined #xen
07:41 -!- riel is now known as surriel
07:50 < Sting> Newbie question: 
07:50 < Sting> I work with xen-2.0-testing source. 
07:50 < Sting>  I tried to do a slight change under a file 
07:50 < Sting> under linux-2.6.11-xen0; now in order to build only the kernel of linux-2.6.11-xen0
07:50 < Sting> what should I do ? I of course don't want to do the whole process of "make world". 
07:50 < Sting> should I do make arch=xen from under linux-2.6.11-xen0  ? thanks
07:53 < surriel> make ARCH=xen vmlinuz modules
07:53 < Sting> thanks
07:57 < knewt> surriel: a simple make ARCH=xen should do it nowadays shouldn't it
07:58 < knewt> it certainly made both the vmlinuz and all the .ko files for me when i did that
08:03 -!- Sting [~sting@mvil2.bb.netvision.net.il] has quit [Quit: Client Exiting]
08:04 -!- sunny [sunny@opencurve.org] has joined #xen
08:10 < surriel> knewt: cool
08:11 < knewt> actually, since i had exported ARCH=xen into that shells environment to make life easier, it was just "make" :)
09:29 -!- franR [~franr@inextensia.net] has joined #xen
09:30 < franR> heya all
09:39 -!- unriel is now known as riel
09:46 -!- Sting [~sting@mvil2.bb.netvision.net.il] has joined #xen
09:47 -!- Sting [~sting@mvil2.bb.netvision.net.il] has quit [Quit: ]
09:47 -!- Sting [~sting@mvil2.bb.netvision.net.il] has joined #xen
09:51 -!- drbyte [~byte@c210-49-121-44.eburwd3.vic.optusnet.com.au] has quit [Ping timeout: 480 seconds]
09:55 -!- katzj [~katzj@c-66-30-206-55.hsd1.ma.comcast.net] has quit [Ping timeout: 480 seconds]
10:06 -!- drbyte [~byte@c210-49-121-44.eburwd3.vic.optusnet.com.au] has joined #xen
10:06 -!- rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
10:07 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
10:20 -!- homebaum [~michael@wbar1.sea1-4-5-031-104.sea1.dsl-verizon.net] has quit [Quit: Client exiting]
10:30 -!- sdog [~sdog@62.58.98.210] has joined #xen
10:33 < sdog> hmm.. does anyone know how to enable multiple xen-br(0..X) by default
10:33 < sdog>        at boottime ?
10:36 < sdog> anyone here ? 
10:36 < mael> pong
10:36 < knewt> xen-brN is/are just bridge(s), so either modify the xend network script to set more of them up, or just use your distro's method of setting up bridges at boot
10:37 < sdog> knewt: no problem there .. but I was wondering wether there was some kind of default mechanism that I'm failing to find ... 
10:37 < sdog> doing things " the standard way " makes it easier for upgrades/other collegues ..
10:38 < knewt> myself i just disable the xend network script and configure my bridge using /etc/network/interfaces (debian/ubuntu system)
10:39 -!- katzj [~katzj@wlanconf-nat-pool-bos.redhat.com] has joined #xen
10:40 < sdog> somehow somewher when you start xend it calls the network script with some parameters.. where does it get those ? :)
10:46 < knewt> vif-bridge and vif-antispoof in /etc/xen/xend-config.sxp
10:47 < knewt> they get passed as bridge='%s'  and  antispoof=yes or antispoof=no
10:49 < sdog> knewt: yep but they only take 1 valuy :(
10:50 < knewt> yep
10:51 < Sting> Hello does any know a URL (if there is one) where logs of this irc channel are kept?
10:53  * knewt points to the /whois of VS_ChanLog 
10:59 < Sting> I am a newbie in this: should I login into http://www.linode.com/irc/
11:02 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
11:05 < heb> Sting: use web browser, follow link to #xen channel logs, click on log :-)
11:06 < heb> Sting: i.e. cut and paste http://www.linode.com/irc/ into your browser bar.
11:11 < Sting> thnks!
11:18 -!- Sting [~sting@mvil2.bb.netvision.net.il] has quit [Quit: Client Exiting]
11:41 -!- athomas [~athomas@ppp-0-19.lond-a-1.access.uk.tiscali.com] has quit [Read error: Connection reset by peer]
11:42 -!- hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
11:49 -!- matta-lt [~matta@69.93.28.254] has joined #xen
11:51 -!- MarkW [~MarkWilli@maw48.kings.cam.ac.uk] has joined #xen
11:51 < sdog> right .. fixed it with my own scripts .. ugly but whatever :)
11:51 -!- sdog [~sdog@62.58.98.210] has quit [Quit: Oh shit, cops at my door!1!!@!!1!1!@!@@1!!]
11:59 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has quit [Remote host closed the connection]
12:06 -!- athomas [~athomas@ppp-0-65.lond-b-4.access.uk.tiscali.com] has joined #xen
12:29 -!- eigood [~adam@brown.brainfood.com] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- paavon [paavon@alpha.phnet.fi] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- knewt [~jmb@zeus.pimb.org] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- movement [~moz@82.153.105.134] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- cartel [~cartel@shinobi.thoughtcrime.org.nz] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- matta [~matta@69.93.28.254] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.hsd1.tx.comcast.net] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- DEac- [~deac@xdsl-195-14-200-54.netcologne.de] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- spike723 [~dyeske@24-159-107-193.cpe.ga.charter.com] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- grifferz [andy@laudanum.strugglers.net] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- tab [~tab@darwin.snarc.org] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- murble [~murble@debian.home.boughton.org.uk] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- Hunger [Hunger.hu@Hunger.hu] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- Robot101 [robot101@light.bluelinux.co.uk] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- athomas [~athomas@ppp-0-65.lond-b-4.access.uk.tiscali.com] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- MarkW [~MarkWilli@maw48.kings.cam.ac.uk] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- katzj [~katzj@wlanconf-nat-pool-bos.redhat.com] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- drbyte [~byte@c210-49-121-44.eburwd3.vic.optusnet.com.au] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- rharper [~rharper@pixpat.austin.ibm.com] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- franR [~franr@inextensia.net] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- Squink [~purple@S010600131077a67e.vc.shawcable.net] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- lilo [~lilo@lilo.usercloak.oftc.net] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- woody_ [~woody@bi01p1.co.us.ibm.com] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- heb [~harry@blueice1n1.uk.ibm.com] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- surriel [~riel@riel.netop.oftc.net] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- yosh [~manish@graft.XCF.Berkeley.EDU] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- HoraPe [~horape@200.69.230.10] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- demon [demon@newcastle.devrandom.net] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- caker [~caker@ns.theshore.net] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- riel [~riel@nat-pool-bos.redhat.com] has quit [oxygen.oftc.net jupiter.oftc.net]
12:29 -!- HoraPe [~horape@200.69.230.10] has joined #xen
12:29 -!- demon [demon@newcastle.devrandom.net] has joined #xen
12:29 -!- caker [~caker@ns.theshore.net] has joined #xen
12:29 -!- riel [~riel@nat-pool-bos.redhat.com] has joined #xen
12:29 -!- yosh [~manish@graft.XCF.Berkeley.EDU] has joined #xen
12:29 -!- Hunger [Hunger.hu@Hunger.hu] has joined #xen
12:29 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has joined #xen
12:29 -!- grifferz [andy@laudanum.strugglers.net] has joined #xen
12:29 -!- Robot101 [robot101@light.bluelinux.co.uk] has joined #xen
12:29 -!- tab [~tab@darwin.snarc.org] has joined #xen
12:29 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has joined #xen
12:29 -!- murble [~murble@debian.home.boughton.org.uk] has joined #xen
12:29 -!- athomas [~athomas@ppp-0-65.lond-b-4.access.uk.tiscali.com] has joined #xen
12:29 -!- MarkW [~MarkWilli@maw48.kings.cam.ac.uk] has joined #xen
12:29 -!- hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
12:29 -!- katzj [~katzj@wlanconf-nat-pool-bos.redhat.com] has joined #xen
12:29 -!- rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
12:29 -!- drbyte [~byte@c210-49-121-44.eburwd3.vic.optusnet.com.au] has joined #xen
12:29 -!- franR [~franr@inextensia.net] has joined #xen
12:29 -!- Squink [~purple@S010600131077a67e.vc.shawcable.net] has joined #xen
12:29 -!- lilo [~lilo@lilo.usercloak.oftc.net] has joined #xen
12:29 -!- woody_ [~woody@bi01p1.co.us.ibm.com] has joined #xen
12:29 -!- heb [~harry@blueice1n1.uk.ibm.com] has joined #xen
12:29 -!- surriel [~riel@riel.netop.oftc.net] has joined #xen
12:29 -!- movement [~moz@82.153.105.134] has joined #xen
12:29 -!- cartel [~cartel@shinobi.thoughtcrime.org.nz] has joined #xen
12:29 -!- knewt [~jmb@zeus.pimb.org] has joined #xen
12:29 -!- matta [~matta@69.93.28.254] has joined #xen
12:29 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.hsd1.tx.comcast.net] has joined #xen
12:29 -!- eigood [~adam@brown.brainfood.com] has joined #xen
12:29 -!- paavon [paavon@alpha.phnet.fi] has joined #xen
12:29 -!- mode/#xen [+o Sir_Ahzz   ] by arion.oftc.net
12:30 -!- franR [~franr@inextensia.net] has quit [Quit: Error inopinée -10s, -9, -8...    Unexpected error -10s, -9, -8,... Really ?]
12:30 -!- DEac- [~deac@xdsl-195-14-200-54.netcologne.de] has joined #xen
12:30 -!- spike723 [~dyeske@24-159-107-193.cpe.ga.charter.com] has joined #xen
12:46 < knewt> yaaay. sys-con has dumped mog
12:47 < MarkW> knewt: nurrrgh?
12:48 < knewt> mog == maureen o'gara
12:48 < hollis> that must be British slang for "I don't understand" ;)
12:48 < demon> hot
12:48 < katzj> about time
12:49 < MarkW> hollis: correctly translated :-)
12:49 < MarkW> knewt: I see,  Good!
12:50 < knewt> and pj has had to ask people to stop commenting on the Intimidation article, as at 1188 comments geeklog is having issues ;)
12:51 < hollis> I don't see why anybody cares. people write crazy stuff on the internet all the time
12:51 < MarkW> knewt: wow!
12:52 < knewt> it gathered comments at something like a post a minute from the moment it was posted
12:53 -!- athomas [~athomas@ppp-0-65.lond-b-4.access.uk.tiscali.com] has quit [Quit: Leaving]
13:07 -!- cfreak [cfreak@dsl-084-056-105-110.arcor-ip.net] has joined #xen
13:08 -!- stekloff [~stekloff@bi01p1.co.us.ibm.com] has joined #xen
13:30 -!- DEac- [~deac@xdsl-195-14-200-54.netcologne.de] has quit [Ping timeout: 480 seconds]
13:42 -!- DEac- [~deac@xdsl-81-173-163-48.netcologne.de] has joined #xen
13:51 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
14:09 -!- ap [~andre@adsl-63-201-59-77.dsl.snfc21.pacbell.net] has joined #xen
14:30 -!- ap [~andre@adsl-63-201-59-77.dsl.snfc21.pacbell.net] has left #xen []
14:53 -!- matta-lt [~matta@69.93.28.254] has quit [Quit: There are 3 kinds of people: those who can count & those who can't.]
15:30 < MarkW> hmmm, weird
15:30 < MarkW> System RAM doesn't show up on my Xen test box under /proc/iomem. I've got a feeling that's a bug!
15:31 < MarkW> Or maybe it's a "feature".  Hrrmmmmm.
15:31 -!- aap [~andre@adsl-63-201-59-77.dsl.snfc21.pacbell.net] has joined #xen
15:33 < hollis> hmm? RAM is not IO memory
15:33 < MarkW> hollis: no but under Vanilla Linux, /proc/iomem lists all kinds of memory
15:34 -!- jimix [~jimix@yktgi01e0-s4.watson.ibm.com] has joined #xen
15:34 < hollis> so it does. how odd.
15:34 < MarkW> ROMs, RAMs, as well as bona fide io memory
15:34 < MarkW> unfortunately the Kexec tools parse that file, so I'd quite like it to look what they're expecting
15:35 < MarkW> I will investigate...
15:36 -!- DEac- [~deac@xdsl-81-173-163-48.netcologne.de] has quit [Quit: Verlassend]
15:37 -!- DEac- [~deac@xdsl-81-173-163-48.netcologne.de] has joined #xen
16:11 -!- jeroney [~jeroney@pixpat.austin.ibm.com] has joined #xen
16:23 -!- cfreak [cfreak@dsl-084-056-105-110.arcor-ip.net] has quit [Quit: .]
16:27 -!- aap [~andre@adsl-63-201-59-77.dsl.snfc21.pacbell.net] has left #xen []
16:29 -!- jimix [~jimix@yktgi01e0-s4.watson.ibm.com] has quit [Quit: Leaving]
17:00 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has left #xen [bug, n: A son of a glitch.]
17:14 < Squink> If anyone can shine a light on this situation:
17:14 < Squink> I'm getting this on bootup; 
17:14 < Squink> kernel /boot/xen.gz dom0_me200704 console=vga
17:14 < Squink> Error 15: File not found..
17:14 < Squink> (which then leads to grub)
17:14 < Squink> however
17:14 < Squink> the file IS there
17:15 < Squink> and the grub conf is 
17:15 < Squink> title Xen 2.0 / XenLinux 2.6.9
17:15 < Squink>         kernel /boot/xen.gz dom0_mem=200704 console=vga
17:15 < Squink>         module /boot/vmlinuz-2.6.9-xen0 root=LABEL=/ ro console=tty0
17:16 < caker> Squink: remove /boot from those lines
17:16  * Squink <3 KVM hookup
17:18 < Squink> hmm
17:18 < Squink> http://523.org.uk/~squink/images/snapshot.png
17:18 < Squink> ^^ that's what it's doing now
17:19 < MarkW> Squink: please stick your whole grub.conf online so we can have a peek
17:19 < Squink> alright, logging back in
17:21 < Squink> http://pastebin.com/282364 <- grub.conf
17:21 -!- mael_ [~Mael@kali.tirnamban.org] has joined #xen
17:21 < mael_> hi
17:21 < mael_> MarkW:  are you there?
17:21 < MarkW> mael_: yup
17:22 < mael_> do you remember the qemu/kqemu problem I told you about yesterday? I tested without kqemu and it worked
17:23 < mael_> I posted on qemu-devel and will provide info to Fabrice Bellard about it
17:23 < knewt> does kqemu itself run /under/ xen btw?
17:23 < MarkW> mael_: thanks for that.  I saw the post, wondered if it was you
17:23 < mael_> it was
17:23 < MarkW> knewt: I doubt it
17:24 < mael_> knewt:  well Jim Provan of win4Lin seem to be willing to make that work
17:24 < MarkW> knewt: it uses cli / sti directly, although emulating those works in the unstable tree
17:24 < mael_> qemu/kqemu under domO
17:24 < MarkW> knewt: porting qvm86 (the open source accelerator) should work, though
17:24 < mael_> and he'd also like to make qemu/kqemu work under a domU
17:24 < knewt> i had a look at the sourcecode of vmmon. nasty assembly language, staying well away
17:25 < MarkW> mael_: now that would be really cool!
17:25 < MarkW> win4lin pro runs under a domU anyhow
17:26 < mael_> btw MarkW, Jim told me that his firm was "currently working with XenSource and [that he] can get answers for you"
17:26 < MarkW> Moshe has a video on his website.  It'd be much nicer to use the qemu accelerator.
17:26 < knewt> Squink: include the root (hd0,0) line as part of the Xen section
17:27 < mael_> well I think that dom0 or domU qemu/kqemu support will be needed for non-VT arch where you want to run a windows desktop
17:27 < knewt> Squink: also, unless you use an initrd, the LABEL syntax won't work. probably best to just change that to the actual device node being used
17:27 < mael_> corporate env for example
17:27 < mael_> I spoke with James and Keir about that a bit when I went to Cambridge in April
17:27 < knewt> i'd like to be able to run a windows vm on my current systems, certainly
17:27 < Squink> knewt: how would I find out the device node?
17:28 < MarkW> mael_: I agree
17:28 < Squink> actually im sure i saw a .img file for xen in the boot dir
17:28 < MarkW> mael_: I didn't know there had been contact with xensource bit if so then all the better!
17:29 < knewt> Squink: if you want to try that, supply it as a 2nd module line, after the kernel
17:29 < Squink> ah, nope, no .img file.
17:29 < mael_> MarkW:  from what I heard, having windows running on a VT system won't be a piece of cake
17:29 < mael_> it seems this won't be possible until post Xen 3.X
17:29 < MarkW> mael_: there's a lot of stuff to implement to make it work.
17:30 < MarkW> Yes, I'd heard that, although I think I also saw it as a "possible" for 3.x
17:30 < Squink> /dev/hda1 on /boot type ext3 (rw)
17:30 < Squink> I assume I should set grub to /dev/hda1, then
17:30 < mael_> MarkW:  you're the guy in charge with hardware drivers domain stuff, right? (among other things)
17:31 < mael_> what is needed to get AGP working on a domU?
17:31 < knewt> Squink: no, that's your /boot, you want the dev node for your /
17:32 < MarkW> mael_: I worked on the driver domains stuff when it was first developed but I'm on other stuff at the moment.
17:32 < mael_> XenFS I guess
17:32 < MarkW> mael_: Yeah, although this week I'm looking at kexec instead.
17:32 < MarkW> (got sick of the Linux VFS)
17:33 < knewt> Squink: try root=/dev/hda3
17:33 < mael_> to boot kernels from domU? (for virtual dedicated server environment)
17:33 < mael_> or is is something else?
17:34  * Squink reboots again
17:34 < MarkW> mael_: yes, primarily for untrusted domain boot loaders
17:34 < Squink> knewt: http://523.org.uk/~squink/images/snapshot.png <-- still does this
17:35 < MarkW> but also potentially if people want to run their own domU-internal crashdump
17:35 < MarkW> At some stage I think it'd be worth having kexec functionality in Xen itself but I'm not going to do that initially.
17:35 < mael_> MarkW:  will this feature be needed if you want to run a windows system on a VT cpu also?
17:35 < mael_> (to run the ntloader stuff)
17:36 < MarkW> mael_: no, for VT guests the native bootloader will (eventually) work fine
17:36 < knewt> Squink: you've still got root=LABEL=/ in there
17:36 < mael_> hum ok
17:36 < MarkW> mael_: but for paravirtualised guests, we need an untrusted path for the domain to say "now boot this kernel"
17:36 < MarkW> mael_: so mounting the domain filesystem in dom0 isn't acceptable
17:36 < mael_> I still have troubles figuring what will be needed for virtualized VT guests
17:36 < knewt> Squink: am i guessing right that you also didn't add the "root (hd0,0)" line above the kernel line in the Xen section?
17:37 < mael_> maybe only hardware emulation
17:37 < MarkW> mael_: initially just hardware emulation
17:37 < mael_> MarkW:  ok I see the picture for the booting stuff
17:37 < Squink> knewt: nah i did add that, but the screenshot was otherwise identical
17:37 < MarkW> mael_: later on, some extra paravirtualised hardware
17:37 < Squink> knewt: so i just used the previous one
17:37 < mael_> MarkW:  what for? to get better perfs or for concurrent access sake?
17:38 < MarkW> Squink: are you *sure* that vmlinux is there (and not, for instance a slightly different version number)
17:38 < MarkW> mael_: perfomance
17:38 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [Quit: leaving]
17:38 < MarkW> mael_: flexibility
17:38 < mael_> and will you be able to do pure hardware emulation or provide direct access to the underlying hardware?
17:39 < mael_> I mean if you have a modern machine with a high perf 3D graphic card (lets say its an AGP one as it seems to be more problematic than PCI E), you expect a VT guest Windows system to give you full perfs
17:40 < Squink> MarkW: good call :)
17:40 < Squink> MarkW: lemme check some stuff.
17:40 < mael_> and not the perfs of a GD5446
17:41 < MarkW> mael_: i doubt the emulated hardware will be very fast
17:41 < mael_> I fear so
17:41 < MarkW> we won't initially support 3D graphics hardware virtualisation at all
17:41 < mael_> and can't you dedicate hardware to a VM?
17:42 < MarkW> as an interim measure, a virtual FB has been discussed, which would give reasonably decent performance for 2D
17:42 < MarkW> yes, dedicating graphics cards to a VM is probably easier
17:42 < mael_> for instance the graphic card might not be needed for a server running "in the background" on a workstation
17:42 < MarkW> mael_: VT allows a guest to "poke through" to selected hardware devices if you set appropriate state
17:43 < mael_> so you could give full access to that device to a VM either virtualize or para-
17:43 < mael_> hum I'm not sure to understand what "poke through" stand for there :)
17:43 < MarkW> mael_: potentially.  The code isn't there for driver-domain style device access under VT but it appears to be possible.
17:43 < MarkW> :-)
17:44 < MarkW> "poke through", as in, reach through the virtualisation layer to the real machine
17:44 < mael_> ok
17:44 < mael_> that's great news
17:44 < mael_> without any overhead?
17:44 < mael_> (or a near 0 one)
17:45 < MarkW> I imagine the overhead would be pretty low but I haven't checked out the details.
17:45 < mael_> ok that would be great
17:45 < MarkW> it would be way cool :-)
17:45  * mael_ is still waiting for VT system to be available
17:45 < mael_> that's why I'm fumbling around with qemu/kqemu
17:45 < MarkW> sharing one screen with 3D graphics is *much* harder than giving a second graphics card to a guest
17:46 < MarkW> there's even one or two people trying to dedicate keyboard, mouse, gfx card to a Linux driver domain right now
17:46 < mael_> I tried to build a test system with a dom0 running windows on a qemu/kqemu running on fbcon using sdl
17:46 < mael_> with no luck
17:47 < mael_> I tried on a normal system also with no luck either
17:47 < mael_> (normal mean non-Xen)
17:47 < MarkW> hmmm.  hopefully if XenSource / Win4Lin are looking at this, it'll happen at some stage.
17:47 < mael_> seems I have fbcon access troubles
17:48 < mael_> I couldn't go any further as my server's power source burnt
17:48 < mael_> so now I was trying to get a xen system working on qemu :)
17:48 < Squink> hmm.
17:48 < mael_> hopefully I'll find a working combo somewhere
17:50 < mael_> MarkW:  is there more devs working for XenSource than you guys in Cambridge?
17:50 < mael_> (not to mention ppl from IBM/RH/HP/Intel/etc)
17:52 -!- yarihm [~yarihm@80-218-7-109.dclient.hispeed.ch] has joined #xen
17:59 -!- katzj [~katzj@wlanconf-nat-pool-bos.redhat.com] has quit [Read error: Connection reset by peer]
18:00 < demon> er... dom0 running windows?
18:01 < mael_> eurk, did I said that?
18:01 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
18:01 < demon> <mael_:#xen> I tried to build a test system with a dom0 running windows on a
18:01 < demon> +qemu/kqemu running on fbcon using sdl
18:02 < mael_> hum
18:02 < demon> oh, I see
18:02 < mael_> yeah
18:02 < demon> running windows under qemu
18:02 < riel> kqemu, even
18:02 < mael_> it's "sandboxed" in qemu
18:03 < MarkW> mael_: in cambridge there will be few non-university developers who are paid primarily by XenSource
18:04 < MarkW> mael_: currently there's only one (tab / vincent)
18:04 < mael_> ok
18:04 < MarkW> mael_: I don't know of XenSource developers anywhere else but they may exist also :-)
18:05  * mael_ has trouble to understand the nebulous world of Xen
18:05  * MarkW also has trouble understanding it
18:05 < mael_> :)
18:05 < MarkW> mael_: seriously, I try to keep on top of it but I keep getting surprised by developers I didn't know existed
18:05 < mael_> Keir and James explained some stuff I had trouble to figure out, but still...
18:06 < mael_> hehe
18:06 < mael_> really, this project in moving **fast**
18:06 < mael_> I don't know if someone really has a big picture of it
18:06 < mael_> Ian maybe
18:07 < MarkW> Yeah, Ian probably has the best idea what's going on.
18:07 < mael_> someone should do a "Kernel Traffic" kind of stuff for Xen dev ML
18:08 < mael_> it's becoming to hard to follow if you're not an expert
18:08 < hollis> mael_: I think I just heard you volunteer :)
18:08 < mael_> hum I wish I could
18:08 < MarkW> It'd be good to have something like that.
18:09 < mael_> but I'm not dev and I have only a very high level view of how a CPU from the real world really work
18:09 < MarkW> We need to find a victim^W volunteer
18:10 < mael_> I was graduated in Biology before I had a Master Degree in Computer Sciences...
18:10 < mael_> There's still stuff missing
18:10 -!- riel is now known as unriel
18:11 < mael_> but if hollis or riel work on a Xen dev digest, I'll be happy to do the french translation :)
18:11 < mael_> +ML
18:12 < MarkW> :-)
18:12  * MarkW puts on his invisibility hat
18:13 < MarkW> If only we had a volunteer...
18:13 < MarkW> ;-)
18:13 < mael_> I think the perfect candidate would be someone from Xensource :)
18:15 < hollis> yeah, they're probably not doing anything else anyways
18:15  * knewt surrounds himself with an SEP-field
18:16 < mael_> I recon knewt would be the perfect candidate
18:17 < mael_> this would of course mean that xensource hire you :)
18:20 < mael_> time to go
18:20 < MarkW> mael_: see ya
18:20 < mael_> bed is calling in my timezone :)
18:21 < MarkW> mael_: many many hours away in my timezone
18:21 < knewt> feck. i just ran out of disk space. this means that the entire ghc build process from bootstrap -> stage1 -> stage2 will run again. aarrrggghhh.
18:21 < MarkW> knewt: gak!
18:22 < knewt> it was a good way through stage2 already as well :(
18:22 -!- mael_ [~Mael@kali.tirnamban.org] has quit [Quit: letting mael eavesdropping while I'm sleeping]
18:52 < Squink> hmm
18:52 < Squink> I can get into it now, but I'm losing my swap and stuff
18:52 < Squink> which im guessing it because of my lack of initrd
18:53 < Squink> anyone know what im supposed to change in order to get swap etc back?
18:57 < knewt> i'd expect swap to configured in fstab, so i'm surprised that's not working
18:59 < Squink> well it is fedora...
19:00 -!- stekloff [~stekloff@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
19:01 -!- Arnald [~Arnald@81-86-116-102.dsl.pipex.com] has quit [Remote host closed the connection]
19:06 -!- rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
19:10 < Squink> ahh fixed it.
19:10 < Squink> made a new initrd file.
19:15 -!- Robot101 [robot101@light.bluelinux.co.uk] has quit [Ping timeout: 480 seconds]
19:23 -!- Robot101 [robot101@light.bluelinux.co.uk] has joined #xen
19:34 -!- yarihm [~yarihm@80-218-7-109.dclient.hispeed.ch] has quit [Quit: Leaving]
19:48 < Squink> hmm
19:48 -!- lilo [~lilo@lilo.usercloak.oftc.net] has quit [Quit: bbiab]
19:48 < Squink> I'm getting this when I try to boot a xend domain:
19:48 < Squink> Root-NFS: No NFS server available, giving up.
19:48 < Squink> VFS: Unable to mount root fs via NFS, trying floppy.
19:48 -!- rusty [~rusty@CPE-139-168-158-101.nsw.bigpond.net.au] has joined #xen
19:48 < Squink> and then it just sits, obviously.
19:48 < Squink> So what am I missing?
19:54 -!- lilo [~lilo@lilo.usercloak.oftc.net] has joined #xen
19:59 -!- dwh [~sc@bgp01386991bgs.brodwy01.nm.comcast.net] has joined #xen
20:01 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
20:02 < dwh> Is Daniel Stekloff in here, by any chance?
20:03 < dwh> I'm a summer intern... just wanted to take a moment to say 'hello' before going back to work on school-related projects.
20:03 < dwh> er, summer intern for IBM in Beaverton, that is.
20:04 < eigood> but it's not summer
20:05 < dwh> Meh, any time that does not involve waking up in the morning to go to classes I usually dislike is close enough to summer for me :)
20:05 < dwh> Even if it's winter break.
20:16 < MarkW> dwh: I remember waking up in the morning once
20:16 < MarkW> I didn't like it!
20:16 < MarkW> Squink: it's either that the domain can't find its root device or that it doesn't support the filesystem on it, can't remember which.=
20:16 < MarkW> Where are you putting the rootfs and what filesystem is it?
20:17 < Squink> MarkW: fixed it btw ;) My issue now is that it's saying the IP im trying to use is already in use!
20:17 < MarkW> Squink: ah, is it?
20:17 < Squink> it shouldnt be..
20:17 < MarkW> Squink: remember it's probably a bridged configuration
20:17 < Squink> It's the same one i was using for UML
20:18 < MarkW> so addresses won't be private to the machine unless you configure it like that
20:18 < Squink> well it's supposed to be attaching to 66.36.255.63 
20:22 -!- andy is now known as troll
20:22 -!- troll is now known as andy
20:30 -!- dwh [~sc@bgp01386991bgs.brodwy01.nm.comcast.net] has quit [Quit: Leaving]
20:34 < MarkW> Squink: you sure it's not used by any other systems at your hosting provider?
20:34 < MarkW> out of interest, can you ping that IP?  does there *seem* to be anything there?
20:42 < Squink> Well. I've just done ifconfig eth0:2 del 66.36.255.63
20:43 < Squink> of course, now the new problem is it's freaking out about something and not syncing, some im just rebooting the host
20:43 < Squink> I'm trying to figure out how to make the server internet-accessable, because as yet, i've not been able to connect to it.
20:44 < MarkW> not even dom0?
20:44 < Squink> dom0?
20:44 < MarkW> that's the virtual machine you first boot into, the one which controls the screen
20:44 < MarkW> you can get into that, right?
20:44 < Squink> you mean when you reboot, then it goes through xen, then boots into the original kernel
20:44 < Squink> ?
20:45 < MarkW> when you boot on a Xen enabled system, _everything_ is a virtual machine ("domain")
20:45 < Squink> right
20:45 < Squink> I'm still trying to get around the differences between xen and uml ;)
20:45 < MarkW> the Linux that comes up first is called "domain 0"
20:46 < MarkW> its virtual machine is privileged, so it gets to grab the screen, PCI devices, etc.  but fundamentally it's no different to the other virtual machines you run.
20:46 < Squink> clever :)
20:47 < MarkW> (side effect being that it's also possible to give other virtual machines control over individual real devices)
20:48 < Squink> MarkW: http://pastebin.com/282440 <- here's what it's doing/.
20:48 < MarkW> so, that being the case: can you get to dom0 over the network?
20:48 < MarkW> looking...
20:49 < Squink> yeah, dom0 is working perfectly
20:49 < Squink> which is nice :)
20:49 < MarkW> OK, it's not finding the root filesystem, so that suggests something wronge with your domain config
20:50 < MarkW> or more accurately, it's finding *a* filesystem, just not finding init in there...
20:50 < MarkW> Other than that it looks fine.  You can press ^] to exit a domain console by the way
20:51 < Squink> Config: http://pastebin.com/282443
20:51 < Squink> that's useful to know
20:52 < MarkW> the console behaves like a serial line, so you can always reconnect to it later
20:53 < MarkW> well the config looks ok
20:53 < Squink> Right. What should I look for in the .disk?
20:53 < MarkW> /sbin/init
20:53 < Squink> oh
20:53 < Squink> looks like the filesystem has been corrupted.
20:54  * Squink copies a new .disk over
20:54 < Squink> 2 secs
21:00 < Squink> alright
21:00 < Squink> I guess it should work this time.
21:00  * MarkW crosses his fingers
21:01 < Squink> fsck.ext3Possibly non-existent or swap device?
21:01 < Squink> : No such device or address while trying to open /dev/ubd0
21:01 < Squink> [FAILED]
21:01 < Squink> *** An error occurred during the file system check.
21:01 < Squink> ...
21:01 < MarkW> better
21:01 < MarkW> ish
21:01 < MarkW> the /dev/ubd0 error is OK and probably a good sign.
21:02 < MarkW> you'll need to change references to UML block devices to match with some hda or sda nodes
21:02 < MarkW> not sure what's giving you the filesystem error tho...
21:03 < Squink> right. Where should I change them?
21:03 < Squink> heh
21:04 < Squink> cause I've no idea where they might be :)
21:04 < Squink> oh wait
21:04 < Squink> there it is.
21:06 < MarkW> they'd be in the /etc/fstab
21:06 < MarkW> or at least that's all you'd need to change to boot properly
21:06 < Squink> right
21:06 < Squink> it's booting, hanging on atd init, which im guessing is due to lack of net access
21:07 < Squink> still erroring on the IP,which is a bit odd since i just free'd that up
21:07  * Squink tries again
21:08 < Squink> Bringing up interface eth0:  [  OK  ]
21:08 < Squink> yay.
21:08 < MarkW> woohoo!
21:08 < Squink> sorry not, atd, sendmail even.
21:09 < Squink> INIT: no more processes left in this runlevel
21:09 < Squink> woo.
21:09 < MarkW> nice
21:09 < Squink> now... how do i log in? heh
21:10  * Squink scratches head
21:11 < MarkW> you should have a terminal...
21:11 < MarkW> unless inittab is set up for some kind of weirdass UML terminal!
21:11 < MarkW> can you get in the filesystem and check /etc/inittab, see what it says?
21:11 < MarkW> (shutdown the domain first or you'll trash the filesystem, though)
21:13 < Squink> inittab > http://pastebin.com/282453
21:14 < MarkW> the first mingetty line looks weird to me
21:14 < MarkW> can you change it to say tty1 instead of tty0 and see if that works?
21:17 < Squink> eep
21:18 < surriel> yeah, tty0 is wrong
21:18 < Squink> http://pastebin.com/282456.
21:18 < Squink> http://pastebin.com/282456
21:18 < Squink> even
21:19 < MarkW> errrr that's a scary boot output...
21:19 < Squink> surely # root = "/dev/sda1 ro"  # should be w?
21:19 < MarkW> that's what most distros do, it should be fine
21:19 < surriel> nope, the initscripts should remount it rw after fsck
21:20 < Squink> ah
21:20 < Squink> well
21:20 < Squink> something went wrong.
21:20 < Squink> I guess I'll try just letting it go.
21:20 < MarkW> you weren't getting that before though, were you?
21:20 < Squink> nope
21:20 < Squink> I did forget to umount, though.
21:20 < MarkW> Squink: that'll be it
21:21 < MarkW> Linux *really* doesn't like shared mountable writes and it's quite easy to trash data that way
21:21 < Squink> http://pastebin.com/282457
21:21 < MarkW> The tools check for things like this but not when you're using file-backed VBDs :-(
21:22 < Squink> looks like i trashed it again
21:22 < MarkW> It seems likely there actually isn't an inittab anymore
21:22 < MarkW> Yeah, I'd start with a clean disk image.
21:22  * Squink copies a new disk image across
21:23 < Squink> alright so; 1. edit fstab, 2. change tty1 to tty0 ?
21:23 < surriel> yeah
21:24 < MarkW> change tty0 to tty1 :-p
21:25 < Squink> right :)
21:27 < Squink> Fedora Core release 1 (Yarrow)
21:27 < Squink> Kernel 2.6.10-xenU on an i686
21:27 < Squink> irreality login:
21:27 < Squink> \o/
21:27 < MarkW> yay!
21:27 < Squink> alright
21:27 < Squink> now we need to get it hooked up to the internet.
21:28 < Squink> also
21:28 < Squink> I got a lot of this:
21:28 < Squink> Finding module dependencies:  WARNING: Couldn't open directory /lib/modules/2.6.10-xenU: No such file or directory
21:28 < Squink> FATAL: Could not open /lib/modules/2.6.10-xenU/modules.dep.temp for writing: No such file or directory
21:28 < Squink> [FAILED]
21:28 < Squink> is that ignorable?
21:28 < MarkW> yep
21:28 < Squink> good.
21:28 < MarkW> if you install the modules in the domU it'll go away but you probably don't need them anyway
21:29 < Squink> indeed.
21:31 < Squink> Alright, here's what I was using for networking with UML; http://pastebin.com/282462
21:31 < Squink> that'd be on dom0
21:31 < Squink> but i noticed Xen has already set up some bridging and stuff... soo.
21:34 < MarkW> do you want to bridge guests directly onto the physical network?
21:34 < Squink> yep
21:34 < MarkW> ok, throw that script away ;-) and set the IP address in the domain config file
21:35 < Squink> alright.
21:36 < Squink> uh. what's the var for IP?
21:36 < MarkW> ummmm.  isn't there one in the example config?
21:36 < Squink> nope
21:37 < MarkW> it's probably ip="123.123.123.123", plus gateway="123.123.123.123" plus netmask="123.123.123.123"
21:37 < MarkW> check the manual, that lists all config file options
21:38 < Squink> heh
21:38 < Squink> it's not in the manual either =)
21:38 < Squink> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/readmes/user/user.html#SECTION03210000000000000000
21:38 < Squink> the ip is already set in the .disk, though, if that helps
21:39 < MarkW> oh, weird
21:40 < MarkW> yeah, you can ifup from inside the domain if you want
21:40 < MarkW> try that.  make sure the device in the domU is "eth0" and not some UML device, tho
21:41 < Squink> domU being the guest?
21:41 < MarkW> yup
21:41 < Squink> yep thats eth0
21:42 < MarkW> does it work?
21:43 < Squink> nope.
21:43 < Squink> From 66.36.255.63 icmp_seq=0 Destination Host Unreachable
21:44 < MarkW> what were you pinging to?
21:44 < Squink> 205.209.129.150
21:44 < MarkW> have you configured a gateway in the domain?
21:44 < Squink> in the config
21:45 < Squink> but, I'm gonna do this anyway:
21:45 < Squink> ifconfig eth0 66.36.255.63 broadcast 66.36.253.255 netmask 255.255.0.0 up
21:45 < Squink> route add default gw 66.36.230.1
21:45 < Squink> still doesnt work :)
21:46 < MarkW> can you ping the gateway now?
21:47 < Squink> nope
21:47 < MarkW> errrr, IP = 66.36.255.63 and gateway = 66.36.230.1
21:47 < MarkW> are you sure?
21:47 < MarkW> they're not on the same subnet...
21:49 < Squink> yep. 
21:50 < Squink> which is why the netmask is 255.255.0.0.
21:50 < Squink> caker and I ran into this problem when I was trying to get uml to run originally
21:51 < MarkW> oh, sorry I didn't read that properly ;-)
21:51 < MarkW> Well first thing to do is to figure out why it can't ping your gateway...  What is the gateway?  Another machine?  Or dom0 itself?
21:53 < Squink> some other machine
21:53 < Squink> dom0 is 66.36.253.97 / 66.36.231.201
21:53 -!- katzj [~katzj@c-66-30-206-55.hsd1.ma.comcast.net] has joined #xen
21:54 < MarkW> can you ping dom0?
21:54 < MarkW> can dom0 ping the domU?
21:54 < Squink> not with the netmask as it is
21:55 < Squink> See the thing i dont get it why that script worked with UML and this isnt..
21:58 < MarkW> eh?  what's the netmask in dom0?  I thought it had an IP in the same range as the domU
21:58 < MarkW> ?
21:58 < MarkW> you could try and arping things too
21:58 < Squink> wtb
21:59 < Squink> there's something new running on dom0
21:59 < Squink> vif9.0    Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF
21:59 < Squink>           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
21:59 < Squink> never seen /that/ before.
21:59 < MarkW> that's the virtual device at the other end Xen's virtual crossover cable
22:00 < MarkW> we don't use tun / tap.  it's just a virtual device, with a fast point to point link to the domU's eth0
22:00 < Squink> right
22:00 < Squink> k, im gonna paste something in pastebin.
22:02 < Squink> MarkW: http://pastebin.com/282471
22:03 < MarkW> ok...
22:05 < MarkW> nothing obviously wrong
22:05 < MarkW> I still don't get why you can't ping from the domU to dom0's address 66.36.231.201, tho
22:05 < MarkW> or vice versa
22:06 < Squink> Ah. me either really. I remember caker explaining it, but I've sort of forgotton now. I'm 95% sure it's something to do with the netmask
22:06 < MarkW> can you try it anyway?  it looked like it should work...
22:07 < Squink> --- 66.36.231.201 ping statistics ---
22:07 < Squink> 6 packets transmitted, 0 received, 100% packet loss, time 5010ms
22:07 < Squink> --- 66.36.253.97 ping statistics ---
22:07 < Squink> 3 packets transmitted, 0 received, 100% packet loss, time 2011ms
22:08 < Squink> and from dom0;
22:08 < Squink> --- 66.36.255.63 ping statistics ---
22:08 < Squink> 3 packets transmitted, 0 received, 100% packet loss, time 2013ms
22:08 < Squink> =/
22:09 < MarkW> oh dear :-(
22:11 < Squink> MarkW: http://pastebin.com/282474
22:11 < Squink> that's the original script
22:13 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
22:13 < MarkW> Squink: the end result looks kinda the same
22:14 < Squink> yeah, I was just about to say that actually =/
22:14 < MarkW> it's not obvious to me what's significantly different
22:14 < MarkW> and I *really* don't understand your subnet thing
22:15 < Squink> alright, what about arp?
22:15 < Squink> cause that's in the script; 
22:15 < Squink> /sbin/ifconfig eth0 0.0.0.0 arp promisc up
22:16 < MarkW> just enables use of arp on that interface
22:16 < MarkW> i'd hawe thought that was the default anyhow
22:18 < Squink> hum
22:18 < Squink> there must be a way to see what's going on
22:19 < MarkW> tcpdump is your friend
22:19 < MarkW> or ethereal if you prefer
22:20 < MarkW> run tcpdump on the vif device in dom0 and try to access the network from the guest
22:22 < Squink> [root@irreality home]# ping 205.209.129.150
22:22 < Squink> PING 205.209.129.150 (205.209.129.150) 56(84) bytes of data.
22:22 < Squink> From 66.36.255.63 icmp_seq=0 Destination Host Unreachable
22:22 < Squink> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
22:22 < Squink> listening on vif9.0, link-type EN10MB (Ethernet), capture size 96 bytes
22:22 < Squink> 19:22:11.362470 arp who-has c-vl101-gw.acc.dca2.hopone.net tell 66.36.255.63
22:22 < Squink> 19:22:12.362452 arp who-has c-vl101-gw.acc.dca2.hopone.net tell 66.36.255.63
22:22 < MarkW> that's the router it's arping for, right?
22:24 < Squink> looks like it
22:24 < MarkW> try tcpdump-ing xen-br0 and see if the traffic makes it onto there
22:24 < MarkW> then dump eth0 and see if it sees the traffic
22:25 < MarkW> we'll get there in the end!
22:25 < Squink> haha, we better otherwise my partner will kill me ;)
22:26 < Squink> --- 205.209.129.150 ping statistics ---
22:26 < Squink> 2 packets transmitted, 0 received, 100% packet loss, time 1013ms
22:26 < Squink> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
22:26 < Squink> listening on xen-br0, link-type EN10MB (Ethernet), capture size 96 bytes
22:26 < Squink> 19:26:24.942465 arp who-has c-vl101-gw.acc.dca2.hopone.net tell 66.36.255.63
22:26 < Squink> 19:26:25.942449 arp who-has c-vl101-gw.acc.dca2.hopone.net tell 66.36.255.63
22:27 < Squink> hmm
22:28 < Squink> well, this is beyond me.
22:29 < MarkW> try dumping eth0, that should tell us whether the arps are going out on the wire
22:30 < Squink> uh
22:30 < Squink> that could be a problem
22:31 < Squink> from 3 seconds of tcpdump;
22:31 < Squink> 1705 packets captured
22:31 < Squink> 1706 packets received by filter
22:32 < MarkW> pull up the man page for tcpdump and take a look at the filtering commands
22:32 < MarkW> you should be able to narrow it down to only packets involving the domU
22:32 < MarkW> or just grep the output from tcpdump ;-)
22:34 < Squink> root@quartz [~]# tcpdump -i eth0 | grep 66.36.255.63
22:34 < Squink> look about right to you?
22:34 < MarkW> seems reasonable
22:35 < MarkW> for sanity check, also try it against xen-br0 to make sure it does pick up the packets when they are there
22:35 < Squink> in that case, no, nothing is getting to eth0 :)
22:35 < Squink> k
22:35 < Squink> ok
22:35 < Squink> grep isnt working.
22:37 < MarkW> ok, you'll have to debug grep first, or use tcpdump's filtering
22:40 < Squink> root@quartz [~]# tcpdump -i xen-br0 host 66.36.255.63
22:40 < Squink> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
22:40 < Squink> listening on xen-br0, link-type EN10MB (Ethernet), capture size 96 bytes
22:40 < Squink> alright
22:40 < Squink> it's sane, and nothing is getting to eth0
22:41 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
22:42 < MarkW> but you are still seeing packets output from tcpdump for the bridge and the vif?
22:42 < Squink> yep
22:43 < MarkW> well then i suppose it's a matter of debugging what the linux bridging code thinks it's doing
22:45 -!- tierra_ [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
22:46 < Squink> hm
22:46 < Squink> alright, so packets are going from vif9.0 >> xen-br0
22:47 < Squink> and from there they're supposed to be going to eth0, right?
22:47 < Squink> so we could assume that it's a bridging issue rather than a xen issue
22:47 < MarkW> that's where they *need* to go and where I expect them to go
22:47 < MarkW> but apparently the bridge code thinks otherwise
22:48 < Squink> does xen have a bridge script somewhere?
22:48 < MarkW> Yes, this may be a purely bridge-related issue
22:48 < MarkW> Look it /etc/xen/scripts for network scripts
22:51 -!- tierra_ [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [Quit: bug, n: A son of a glitch.]
22:52 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [Read error: Operation timed out]
22:53 < Squink> well the scripts seem normal.
22:53 < MarkW> heh, right now I can't even start a domU on my system - your streets ahead of me
22:54 < aliguori> uh oh, is -unstable still hosed?
22:54 < MarkW> (nb: I'm not quite as incompetent as I sound)
22:54 < Squink> lol
22:54 < MarkW> aliguori: hosed?
22:54 < aliguori> MarkW: broken
22:54 < MarkW> no, I mean hosed how?
22:55 < MarkW> Is there some well-known breakage that I've missed...?
22:55 < Squink> oh hey.
22:55 < Squink> bridge name     bridge id               STP enabled     interfaces
22:55 < Squink> xen-br0         8000.feffffffffff       no              vif9.0
22:55 < Squink> shouldnt that have eth0 in it?
22:55 < MarkW> errr yep
22:55 < aliguori> oh, yesterday's build was panic'ing before dom0 startup... someone else was also experiencing the same
22:55 < MarkW> nope, not the problem I'm seeing
22:56 < aliguori> i'm about to update to the latest BK and try to recreate (now that I have access to a serial port)
22:56 < MarkW> it's domUs that are unhappy.  it seems rather like my install is inconsistent somehow but I've no idea where
22:56 < aliguori> MarkW: what makes the domUs unhappy?  do they just need a friend :-)
22:56 < Squink> brctl addif xen-br0 eth0
22:57 < Squink> who thinks this will lock me out? :)
22:57 < MarkW> Squink: i was just going to ask you to do that :-)
22:57 < MarkW> It might do...
22:57 < Squink> heh
22:57 < Squink> nothing a reboot can't solve
22:57 < MarkW> linux bridging is weird
22:57 < MarkW> aliguori: I think Xen is bullying them
22:57  * Squink gets ready to contact the reboot guys
22:57 < Squink> bridge name     bridge id               STP enabled     interfaces
22:57 < Squink> xen-br0         8000.000d619d364a       no              vif9.0
22:57 < Squink>                                                         eth0
22:57 < Squink> that's better.
22:58 < MarkW> so.... does it work?
22:58 < Squink> [root@irreality home]# ping 205.209.129.150
22:58 < Squink> PING 205.209.129.150 (205.209.129.150) 56(84) bytes of data.
22:58 < Squink> 64 bytes from 205.209.129.150: icmp_seq=1 ttl=56 time=76.2 ms
22:58 < Squink> 64 bytes from 205.209.129.150: icmp_seq=2 ttl=56 time=76.0 ms
22:58 < Squink> 64 bytes from 205.209.129.150: icmp_seq=3 ttl=56 time=76.1 ms
22:58 < Squink> \o/
22:58 < MarkW> wow!
22:58 < Squink> that's... amazing.
22:58 < MarkW> it's nice when things work!
22:58 < Squink> y'know
22:58 < MarkW> my guess is that the bridging scripts were upset by your eth0:1 alias
22:58 < Squink> I think that's the first time i've ever successfully fixed this thing.
22:58 < MarkW> so you'll need to fix the scripts for your setup or fix your setups for the scripts :-)
22:59 < MarkW> or just disable the scripts and set something up statically
22:59 < Squink> hey! ssh works! :D
22:59  * Squink goes into scripts
22:59 < MarkW> Squink: welcome to the nineties :-)
22:59 < Squink> oh.
22:59 < Squink> well it was working.
22:59 < MarkW> oh.
23:00 < Squink> somehow i've been disconnect from dom0
23:00 < MarkW> can you still get to the domU?
23:00 < Squink> yeah
23:00 < Squink> so uh. somethings wrong =)
23:00 < MarkW> that means the bridge stuffed up eth0
23:00 < MarkW> it does that :-(
23:01 < MarkW> if you transfer eth0's IP to the bridge (like you did for UML) it should work
23:01 < MarkW> still, you got your virtual machine on the network :-p
23:02 < Squink> hah
23:02 < Squink> good thing i still have KVM access :D
23:02 < MarkW> too bad the bridge code does that, it's really annoying.
23:02 < MarkW> KVM access should be good enough though.
23:02 < Squink> how do i pull up a login window after it says no more processes at this run level..
23:03 < Squink> or is this going to be a reboot..
23:03 < MarkW> in dom0?
23:03 < Squink> yeah
23:03 < MarkW> errr there should just be one
23:03 < Squink> nope heh
23:03 < MarkW> press return a few times
23:03 < Squink> nope, nothing
23:03 < Squink> k, reboot i spose.
23:03 < MarkW> oh bummer.
23:03 < MarkW> you can reboot it yourself
23:04 < Squink> well it's no major loss, i can at least watch it this way :)
23:04 < MarkW> at least ctrl+alt+del doesn't cost anything :-)
23:04 < Squink> yeah
23:04 < Squink> lol
23:05 < MarkW> waaah!  why won't my domU boot?  this has been bugging me for ages now...  i must be doing something utterly mad!
23:05 < Squink> heh
23:05 < MarkW> Hmmm.
23:06 < Squink> alright
23:06 < Squink> what should i add to xen-br0 this time?
23:06 < Squink> since i can't add eth0 without it dying.
23:07 < MarkW> do you have that old UML script lying around?
23:07 < MarkW> basically you want to remove eth0's IP address, give xen-br0 that IP, then add eth0 to xen-br0
23:07 < Squink> # bring down eth0
23:07 < Squink> /sbin/ifconfig eth0 down
23:07 < Squink> # add the eth0 interface to our bridge
23:07 < Squink> /usr/sbin/brctl addif br0 eth0
23:07 < Squink> # bring up eth0
23:07 < Squink> /sbin/ifconfig eth0 0.0.0.0 arp promisc up
23:07 < Squink> that could be modified, i think.
23:08 < MarkW> yeah, doing that with xen-br0 instead of br0 will probably work for you
23:09 < Squink> http://pastebin.com/282482
23:09 < Squink> so what'dya think - run this before xm create?
23:09 < MarkW> does pastebin get a measurable load spike when you're at work?
23:09 < Squink> haha
23:09 < Squink> it's better than spamming the channel ;)
23:10 < MarkW> I don't feel happy about the sethello line
23:10 < Squink> ok
23:10  * Squink comments out
23:10 < MarkW> hang on a sec...
23:10 < Squink> you know.
23:11 < Squink> next time someone says to me, "I want to learn how to use linux,but i have no idea where to start"
23:11 < MarkW> no, you don't want a hello time of 0, that'll beat your machine to death with an interrupt storm
23:11 < Squink> I'm going to give them a cd and say "install uml or xen"
23:11 < MarkW> heh :-)
23:11 < Squink> ok, any other lines to comment?
23:12 < MarkW> it looks sane
23:12 < MarkW> you may eventually want to engineer it to get run automatically on xend startup, as the current script does
23:14 < Squink> yeah, otherwise this script and xend throw 'bridge already created' errors at each other..
23:14 < Squink> right
23:14 < Squink> it booted in
23:14 < Squink> ping works
23:14 < Squink> i just ssh'd into dom0
23:15 < Squink> lets see if it cuts me out again
23:15 < MarkW> sounds good...
23:16 < Squink> hey!
23:16 < Squink> still connected :)
23:24 < MarkW> nice.  i think that's solved it then.
23:25  * Squink plays with startup scripts
23:25 < Squink> thanks for your help btw :)
23:25 < MarkW> no probs, glad it's working
23:25 < MarkW> another satisfied customer hopefully ;-)
23:27 < Squink> hopefully :)
23:27 < Squink> lets see what the mysql overhead is like ;D
23:29 < MarkW> when we tested postgresql we got a really large speedup over vanilla linux
23:29 < MarkW> we couldn't really understand why though :-)
23:30 < Squink> lol
23:30 < Squink> if i stick /home/xen/bridge.sh in my /etc/rc.d/rc.local
23:30 < Squink> what are the chances it'll break something
23:30 < MarkW> none, provided you also disable Xend's bridge script
23:31 < Squink> well
23:31 < MarkW> (just symlink it to /bin/true or something)
23:31 < Squink> what I've done is added a few lines in the bridge.sh to take the bridge down before the rest of the script runs
23:31 < Squink> it seemed to work perfectly just now
23:31 < MarkW> errr ok.
23:32 < MarkW> you can do that then
23:32 < Squink> i mean, what's the worst that could happen :)
23:32 < MarkW> hmmm bridges are so misunderstood, but to try it is to love it
23:34 -!- rusty [~rusty@CPE-139-168-158-101.nsw.bigpond.net.au] has quit [Ping timeout: 480 seconds]
23:36 -!- MarkW [~MarkWilli@maw48.kings.cam.ac.uk] has left #xen [Kopete 0.10 : http://kopete.kde.org]
23:37 -!- MarkW [~MarkWilli@maw48.kings.cam.ac.uk] has joined #xen
23:37 -!- mode/#xen [+o MarkW] by ChanServ
23:37 -!- cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has quit [Ping timeout: 480 seconds]
23:39 < Squink> oh hey
23:39 < Squink> it came back up
23:39 < Squink> and the script did what i wanted it to :)
23:41 < MarkW> excellent
23:41 < MarkW> get benchmarking :-)
23:42 < MarkW> ok, having spent several hours trying to figure out if I or the world was insane
23:42 < MarkW> I've decided the world is wrong
23:43 < MarkW> I intend to resolve this by going straight to bed, before the sun completely rises.  See yall later.
23:43 -!- MarkW [~MarkWilli@maw48.kings.cam.ac.uk] has left #xen [Kopete 0.10 : http://kopete.kde.org]
--- Log closed Tue May 10 23:59:00 2005