--- Day changed

--- Log opened Mon Apr 11 23:59:02 2005
00:42 -!- niv [~Nivedita_@c-67-171-167-143.hsd1.or.comcast.net] has joined #xen
02:21 -!- [e]num [~enum@cpe-24-175-6-109.houston.res.rr.com] has joined #xen
02:22 < [e]num> hey.. anyone noticed files starting to come up missing in any of thier domUs'?
02:23 < [e]num> I am running an apache host on a domU.  Uploaded a template.. and today some of the template files are missing.. css, image files
02:23 < [e]num> especially image files
02:31 < [e]num> ha.. dom0 disk was full
02:36 -!- matta-lt [~matta@69.93.28.254] has joined #xen
02:41 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has joined #xen
03:23 -!- cfreak [cfreak@dsl-084-056-098-175.arcor-ip.net] has joined #xen
03:24 < cfreak> good morning
03:24 < cfreak> Apr 12 09:24:00 test kernel: printk: 4 messages suppressed.
03:24 < cfreak> Apr 12 09:24:00 test kernel: Memory squeeze in netback driver.
03:24 < cfreak> Apr 12 09:24:05 test kernel: printk: 4 messages suppressed.
03:24 < cfreak> Apr 12 09:24:05 test kernel: Memory squeeze in netback driver.
03:25 < cfreak> xen-testing-src
03:35 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has quit [Ping timeout: 480 seconds]
03:44 -!- jesse_ [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has joined #xen
03:44 -!- jesse_ is now known as wenchien
04:36 -!- tierra [~tierra@c-24-10-173-249.hsd1.ut.comcast.net] has joined #xen
04:53 -!- athomas [~athomas@ppp-0-173.lond-b-1.access.uk.tiscali.com] has joined #xen
05:10 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- niv [~Nivedita_@c-67-171-167-143.hsd1.or.comcast.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- soffi [~soffi@proxy.du.vdsl.is] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- nextime [~nextime@213-140-22-64.fastres.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- Tv [~Tv@hq.inoi.fi] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- caker [~caker@ns.theshore.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- cfreak [cfreak@dsl-084-056-098-175.arcor-ip.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- muli [muli@alhambra.mulix.org] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- Robot101 [robot101@light.bluelinux.co.uk] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- cf0989b8 [~cf0989b8@ns.372broadway.com] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- mael [~mael@194.214.199.130] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- murb [~murbix@soapstone.yuri.org.uk] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- eigood [~adam@brown.brainfood.com] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- mikegrb [~michael@mikegrb.netop.oftc.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- JViz [Anomaly@cpe-024-167-184-225.triad.res.rr.com] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- buggs [~noidentd@n80-237-228-135.cnet.hosteurope.de] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- anticw [cw@adsl-68-120-153-162.dsl.snfc21.pacbell.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- lilo [~lilo@lilo.usercloak.oftc.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- knewt [~jmb@zeus.pimb.org] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- Fidget007 [~rpage@adsl-214-106-36.gnv.bellsouth.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- demon [demon@newcastle.devrandom.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- surriel [~riel@imladris.surriel.com] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- schweeb [~chris@schweeb.org] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.hsd1.tx.comcast.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- athomas [~athomas@ppp-0-173.lond-b-1.access.uk.tiscali.com] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- tierra [~tierra@c-24-10-173-249.hsd1.ut.comcast.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- [e]num [~enum@cpe-24-175-6-109.houston.res.rr.com] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- aliguori-hm [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- DEac- [~deac@xdsl-84-44-151-215.netcologne.de] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- matta [~matta@69.93.28.254] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- unriel [~riel@nat-pool-bos.redhat.com] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- drbyte [~byte@c210-49-121-44.eburwd3.vic.optusnet.com.au] has quit [kinetic.oftc.net uranium.oftc.net]
05:10 -!- sunny [sunny@opencurve.org] has quit [kinetic.oftc.net uranium.oftc.net]
--- Log closed Tue Apr 12 07:16:12 2005

--- Log opened Tue Apr 12 07:16:18 2005
07:16 -!- mode/#xen [+nt] by kinetic.oftc.net
07:16 -!- muli_ [~muli@nesher3.haifa.il.ibm.com] has joined #xen
--- Log closed Tue Apr 12 07:23:15 2005

--- Log opened Tue Apr 12 07:23:20 2005
07:23 -!- mode/#xen [+nt] by kinetic.oftc.net
07:23 -!- mode/#xen [-o VS_ChanLog   ] by uranium.oftc.net
07:23 -!- mode/#xen [-t ] by uranium.oftc.net
07:23 -!- plars [~plars@pixpat.austin.ibm.com] has joined #xen
07:23 -!- joink [~joink@186.80-202-132.nextgentel.com] has joined #xen
07:23 -!- matta-lt [~matta@69.93.28.254] has joined #xen
07:23 -!- Arnald [~Arnald@81-86-116-102.dsl.pipex.com] has joined #xen
07:23 -!- tab [~tab@darwin.snarc.org] has joined #xen
07:23 -!- dst [~dst@p4b23e3d4.np.schlund.de] has joined #xen
07:23 -!- cfreak [cfreak@84.56.98.175] has joined #xen
07:23 -!- Tv [~Tv@hq.inoi.fi] has joined #xen
07:23 -!- caker [~caker@ns.theshore.net] has joined #xen
07:23 -!- mikegrb [~michael@mikegrb.netop.oftc.net] has joined #xen
07:23 -!- eigood [~adam@brown.brainfood.com] has joined #xen
07:23 -!- murb [~murbix@soapstone.yuri.org.uk] has joined #xen
07:23 -!- mael [~mael@194.214.199.130] has joined #xen
07:23 -!- cf0989b8 [~cf0989b8@ns.372broadway.com] has joined #xen
07:23 -!- Robot101 [robot101@light.bluelinux.co.uk] has joined #xen
07:23 -!- muli [muli@alhambra.mulix.org] has joined #xen
07:23 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has joined #xen
07:23 -!- athomas [~athomas@ppp-0-173.lond-b-1.access.uk.tiscali.com] has joined #xen
07:23 -!- tierra [~tierra@c-24-10-173-249.hsd1.ut.comcast.net] has joined #xen
07:23 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has joined #xen
07:23 -!- [e]num [~enum@cpe-24-175-6-109.houston.res.rr.com] has joined #xen
07:23 -!- aliguori-hm [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
07:23 -!- DEac- [~deac@xdsl-84-44-151-215.netcologne.de] has joined #xen
07:23 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has joined #xen
07:23 -!- soffi [~soffi@proxy.du.vdsl.is] has joined #xen
07:23 -!- Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has joined #xen
07:23 -!- matta [~matta@69.93.28.254] has joined #xen
07:23 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
07:23 -!- unriel [~riel@nat-pool-bos.redhat.com] has joined #xen
07:23 -!- nextime [~nextime@213-140-22-64.fastres.net] has joined #xen
07:23 -!- drbyte [~byte@c210-49-121-44.eburwd3.vic.optusnet.com.au] has joined #xen
07:23 -!- sunny [sunny@opencurve.org] has joined #xen
07:23 -!- JViz [Anomaly@cpe-024-167-184-225.triad.res.rr.com] has joined #xen
07:23 -!- Fidget007 [~rpage@adsl-214-106-36.gnv.bellsouth.net] has joined #xen
07:23 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has joined #xen
07:23 -!- buggs [~noidentd@n80-237-228-135.cnet.hosteurope.de] has joined #xen
07:23 -!- anticw [cw@adsl-68-120-153-162.dsl.snfc21.pacbell.net] has joined #xen
07:23 -!- lilo [~lilo@lilo.usercloak.oftc.net] has joined #xen
07:23 -!- knewt [~jmb@zeus.pimb.org] has joined #xen
07:23 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.hsd1.tx.comcast.net] has joined #xen
07:23 -!- demon [demon@newcastle.devrandom.net] has joined #xen
07:23 -!- surriel [~riel@imladris.surriel.com] has joined #xen
07:23 -!- schweeb [~chris@schweeb.org] has joined #xen
07:23 -!- mode/#xen [+ooo anticw Sir_Ahzz surriel ] by uranium.oftc.net
07:23 -!- kinetic.oftc.net changed the topic of #xen to: Xen Homepage->  http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html || Xen Wiki -> http://wiki.xensource.com || vm-tools : http://www.cs.utexas.edu/users/aliguori/vm-tools/
--- Log closed Tue Apr 12 07:23:23 2005

--- Log opened Tue Apr 12 07:23:29 2005
07:23 -!- mode/#xen [+nt] by kinetic.oftc.net
07:23 -!- mode/#xen [-o VS_ChanLog   ] by uranium.oftc.net
07:23 -!- mode/#xen [-t ] by uranium.oftc.net
07:23 -!- plars [~plars@pixpat.austin.ibm.com] has joined #xen
07:23 -!- joink [~joink@186.80-202-132.nextgentel.com] has joined #xen
07:23 -!- matta-lt [~matta@69.93.28.254] has joined #xen
07:23 -!- Arnald [~Arnald@81-86-116-102.dsl.pipex.com] has joined #xen
07:23 -!- tab [~tab@darwin.snarc.org] has joined #xen
07:23 -!- dst [~dst@p4b23e3d4.np.schlund.de] has joined #xen
07:23 -!- cfreak [cfreak@84.56.98.175] has joined #xen
07:23 -!- Tv [~Tv@hq.inoi.fi] has joined #xen
07:23 -!- caker [~caker@ns.theshore.net] has joined #xen
07:23 -!- mikegrb [~michael@mikegrb.netop.oftc.net] has joined #xen
07:23 -!- eigood [~adam@brown.brainfood.com] has joined #xen
07:23 -!- murb [~murbix@soapstone.yuri.org.uk] has joined #xen
07:23 -!- mael [~mael@194.214.199.130] has joined #xen
07:23 -!- cf0989b8 [~cf0989b8@ns.372broadway.com] has joined #xen
07:23 -!- Robot101 [robot101@light.bluelinux.co.uk] has joined #xen
07:23 -!- muli [muli@alhambra.mulix.org] has joined #xen
07:23 -!- wenchien [~wenchien@221-169-69-23.adsl.static.seed.net.tw] has joined #xen
07:23 -!- athomas [~athomas@ppp-0-173.lond-b-1.access.uk.tiscali.com] has joined #xen
07:23 -!- tierra [~tierra@c-24-10-173-249.hsd1.ut.comcast.net] has joined #xen
07:23 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has joined #xen
07:23 -!- [e]num [~enum@cpe-24-175-6-109.houston.res.rr.com] has joined #xen
07:23 -!- aliguori-hm [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
07:23 -!- DEac- [~deac@xdsl-84-44-151-215.netcologne.de] has joined #xen
07:23 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has joined #xen
07:23 -!- soffi [~soffi@proxy.du.vdsl.is] has joined #xen
07:23 -!- Nigelenki [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has joined #xen
07:23 -!- matta [~matta@69.93.28.254] has joined #xen
07:23 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
07:23 -!- unriel [~riel@nat-pool-bos.redhat.com] has joined #xen
07:23 -!- nextime [~nextime@213-140-22-64.fastres.net] has joined #xen
07:23 -!- drbyte [~byte@c210-49-121-44.eburwd3.vic.optusnet.com.au] has joined #xen
07:23 -!- sunny [sunny@opencurve.org] has joined #xen
07:23 -!- JViz [Anomaly@cpe-024-167-184-225.triad.res.rr.com] has joined #xen
07:23 -!- Fidget007 [~rpage@adsl-214-106-36.gnv.bellsouth.net] has joined #xen
07:23 -!- jonmason [~jonmason@pixpat.austin.ibm.com] has joined #xen
07:23 -!- buggs [~noidentd@n80-237-228-135.cnet.hosteurope.de] has joined #xen
07:23 -!- anticw [cw@adsl-68-120-153-162.dsl.snfc21.pacbell.net] has joined #xen
07:23 -!- lilo [~lilo@lilo.usercloak.oftc.net] has joined #xen
07:23 -!- knewt [~jmb@zeus.pimb.org] has joined #xen
07:23 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.hsd1.tx.comcast.net] has joined #xen
07:23 -!- demon [demon@newcastle.devrandom.net] has joined #xen
07:23 -!- surriel [~riel@imladris.surriel.com] has joined #xen
07:23 -!- schweeb [~chris@schweeb.org] has joined #xen
07:23 -!- mode/#xen [+ooo anticw Sir_Ahzz surriel ] by uranium.oftc.net
07:23 -!- kinetic.oftc.net changed the topic of #xen to: Xen Homepage->  http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html || Xen Wiki -> http://wiki.xensource.com || vm-tools : http://www.cs.utexas.edu/users/aliguori/vm-tools/
07:23 -!- muli_ [~muli@nesher3.haifa.il.ibm.com] has joined #xen
07:38 -!- jimix [~jimix@ip13.194.susc.suscom.net] has joined #xen
08:27 -!- cfreak [cfreak@84.56.98.175] has quit [Quit: .]
08:27 -!- cfreak [cfreak@dsl-084-056-098-175.arcor-ip.net] has joined #xen
08:30 -!- cfreak| [cfreak@dsl-084-056-098-175.arcor-ip.net] has joined #xen
08:30 -!- cfreak| [cfreak@dsl-084-056-098-175.arcor-ip.net] has quit [Quit: ]
08:58 -!- harry [~harry@blueice4n1.uk.ibm.com] has joined #xen
09:02 -!- harry [~harry@blueice4n1.uk.ibm.com] has quit [Read error: Connection reset by peer]
09:12 -!- ville- [~user@dsl-kpogw4a72.dial.inet.fi] has joined #xen
09:15 -!- mdday [~mdday@bi01p1.nc.us.ibm.com] has joined #xen
09:24 -!- jimix [~jimix@ip13.194.susc.suscom.net] has quit [Read error: Connection reset by peer]
09:35 -!- unriel is now known as riel
09:45 -!- DEac- [~deac@xdsl-84-44-151-215.netcologne.de] has quit [Read error: Operation timed out]
09:47 -!- hebutterworth [~harry@blueice4n1.uk.ibm.com] has joined #xen
09:56 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
09:58 -!- DEac- [~deac@xdsl-213-196-198-171.netcologne.de] has joined #xen
10:23 -!- pbenner [~pbenner@gate.emlix.com] has joined #xen
10:23 < pbenner> hi
10:23 -!- pbenner is now known as philipp
10:25 < philipp> Eterm:  Error:  grantpt(4) failed:  No such file or directory
10:25 < philipp> Eterm:  Error:  Can't open pseudo-tty -- No such file or directory
10:25 < philipp> Eterm:  Error:  Unable to run sub-command.
10:25 < philipp> how can I create some?
10:26 < philipp> xterm: Error 32, errno 2: No such file or directory
10:26 < philipp> Reason: get_pty: not enough ptys
10:37 < philipp> ah, had to mount devpts
10:37 -!- philipp [~pbenner@gate.emlix.com] has quit [Quit: leaving]
10:50 -!- aliguori-hm [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Read error: Operation timed out]
11:00 -!- soffi_ [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has joined #xen
11:16 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
11:21 -!- monrad [~monrad@213083190130.sonofon.dk] has joined #xen
11:24 -!- jeroney [~jeroney@pixpat.austin.ibm.com] has joined #xen
11:35 < soffi_> allright some dude is gonna upload me some Ubuntu and FreeBSD domU images
11:35 < mael> cool
11:35 < mael> :)
11:35 < mael> btw you didn't de-compress the top level archive :)
11:38 < soffi_> what?
11:38 < soffi_> I just woke up please talk slowly
11:38 < mael> hehe
11:38 < mael> there's a top level tar.gz
11:38 < soffi_> please point
11:38 < mael> containing 2 archives (one tar.gz, one tar.bz2, a README and a md5sums file)
11:38 < soffi_> My eyes are sore
11:39 < soffi_> ahhhhhh xenzoo
11:39 < mael> yep :)
11:39 < soffi_> uno momento senjor
11:40 < murb> I have a nearly working kfreebsd image
11:40 < soffi_> ok It's decompressed now senjor
11:43 < soffi_> murb: cool
11:43 -!- hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
11:43 < soffi_> mael: I wonder how subversion handles big tarballs ;)
11:43 < mael> very badly I guess
11:43 < soffi_> ghehe
11:44 < mael> is there any cambridge based guy on the chan at the moment?
11:44  * mael need hostelling advices in Cambridge
11:48 < soffi_> Cambridge, MA ?
11:48 < mael> Cambridge UK
11:48 < soffi_> ah
11:49 < mael> It seems that am.ac.uk might be in Cambridge :)
12:20 < soffi_> mael: have you worked with iscsi or drbd ?
12:21 < mael> a friend of mine has worked out a cluster with a drdb raid 1 volume
12:22 < mael> But I have no operationnal knowledge of drdb nor iscsi
12:23 < soffi_> yeah.. I'm looking into iscsi on two storage servers.. so one of them can fail and nothing goes havoc
12:24 < mael> mmh
12:24 < mael> not sure of what you mean
12:24 < mael> but if you want to share a volume on a server with iscsi, if it fails, it fails
12:24 < soffi_> Two storage servers, both serving as iscsi targets, replication between them
12:25 < soffi_> only one is used at a time but the other one has up to the millisecond replicas of the primary one
12:26 < mael> k then it's an active/passive cluster configuration
12:27 < soffi_> yep
12:27 < soffi_> just not sure how to do the replication thingie
12:27 < mael> it's what my friend had done with drbd
12:28 < mael> heartbeat and drbd more precisely
12:29 < soffi_> So I could you drdb to replicate the two, and put iscsi on top ?
12:29 < soffi_> or am I smoking crack
12:30 < mael> you can throw you iscsi stuff :)
12:30 < mael> *and* the crack
12:30 < mael> :)
12:30 < soffi_> hehe
12:31 < soffi_> but iscsi is so cool
12:31 < mael> mmh
12:31 < mael> if you say so
12:31 < mael> encapsulation overhead seems a killer for me
12:32 < soffi_> yeah but iscsi is so interoperable
12:32 < soffi_> and you can always shell out for an offloading adapter
12:32 < mael> and I don't like the idea of mixing data network and access network
12:33 < soffi_> No i would but it on a different subnet
12:33 < mael> I like the protocol barrier in fibre channel
12:34 < mael> I feel more confortable with the idea of cleanly separating public access (internet clients for instance) and the precious data backend
12:35 < soffi_> yeah.. with seperate NICs and switches :)
12:35 < mael> there's no mistake possible such as a bad route, wrong firewall rules and so on, allowing everyone to read/write your vital data
12:35 < mael> it's still the same protocols
12:35 < mael> mistakes are always possible
12:36 < mael> it gets even worse when you have a lot of clients dedicated networks
12:36 < mael> then firewall rules and routing turn into a nightmare
12:37 < soffi_> hehehe youre making this too complex :)
12:38 < mael> well I used to work for a company where stuff had to be separated very efficiently
12:38 < soffi_> hehe
12:38 < mael> and in the same time we had to change architecture very often to adapt to user/client demand
12:38 < mael> iscsi would have been a nightmare over ther
12:39 < mael> +e
12:39 < mael> nfs was already
12:50 -!- _MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has joined #xen
12:54 < mael> hi _MarkW 
12:54 < _MarkW> mael: Hi
12:54 < _MarkW> What's up?
12:54 < mael> I was waiting for you :)
12:54 < mael> well one of you more precisely
12:55 < _MarkW> Ah :-)
12:55 < _MarkW> It's usually me
12:55 < mael> do you know Cambridge well enough to recommand so cheap accomodation there?
12:55 < mael> s/so/some/
12:55 < _MarkW> errm not exactly
12:56 < mael> you don't live there?
12:56 < _MarkW> Yes but I've never been a visitor here.
12:56 < mael> hehe yeah
12:56 < _MarkW> You here on business?
12:56 < mael> my GF had an interview for a job there next week
12:57 < mael> and we look for a place to stay
12:57 < _MarkW> Ah, I see.  Tried asking the company if they can recommend anywhere?
12:57 < mael> we found a youth hostel in Harlow but I tried to see if you guys had a better idea
12:57 < _MarkW> There are quite a lot of Bed and Breakfasts in Cambridge.
12:58 < mael> well I think we will book the YH then
12:58 < mael> yeah but hard to find when you're abroad
12:58 < mael> she's in Germany and me in France
12:58 < mael> it's not so easy :)
12:58 < _MarkW> sure
12:58 < _MarkW> seen this: http://www.touristnetuk.com/em/cambridge/accommodation/ac-serviced/index.htm ?
12:59 < _MarkW> google is your friend
12:59 < mael> hehe
12:59 < mael> on top of that we need a room for three
12:59 < _MarkW> the YH will likely be cheaper though but it'll be further away
12:59 < mael> yeah but we'll move to London on saturday anyway
12:59 < mael> so it's on the road
12:59 < _MarkW> ah, ok
13:00 < mael> and it's a not-so-expensive solution
13:00 < _MarkW> yup
13:01 < _MarkW> things that are actually in cambridge are almost undoubtedly going to be more expensive - property prices in cambridge are high, so everyone will be charging more
13:01 < mael> I guess so
13:02 < mael> it seems to be quite an expensive town
13:02 < mael> is the university in the city centre?
13:02 < soffi_> go to Hull, it's cheap ;)
13:02 < mael> I can offer you a drink if you don't mind a real chat :)
13:03 < _MarkW> mael: the university is spread out all over the town
13:03 < mael> uh
13:03 < mael> soffi: where's Hull?
13:03 < soffi_> on the Humberside
13:03 < _MarkW> the university *is* the town :-)
13:03 < mael> it's like oxford then?
13:03 < soffi_> on the northcoast of england :)
13:04 < _MarkW> mael: yeah, like oxford but smaller.
13:04 < _MarkW> much smaller.
13:04 < mael> I've never been in Cambridge but I visited oxford once
13:05 < _MarkW> OK, it'll be familiar then.  The university was founded by rebels who had run away from Oxford.
13:05 < _MarkW> So they did everything the same :-)
13:05 < mael> hehe
13:05 < mael> :)
13:06 < _MarkW> mael: btw, are you on the mailing list?  would i have seen you there?
13:07 < mael> I don't remember having posted anything
13:07 < mael> I'm in my "read all of the f*g manual first" period
13:08 < mael> I still have a hard time to figure out xen's architecture changes
13:08 < _MarkW> changes relative to what?
13:08 < mael> the frontend/backend part especially
13:09 < mael> schemas changed slightly in Ian's presentations
13:09 < _MarkW> which presentations are you looking at?
13:10 < mael> sorry I was not clear :)
13:10 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
13:10 < mael> OLS 2004 and LW 2005
13:10 < mael> on the first one there's a drawing showing vanilla drivers on the privileged domain
13:10 < _MarkW> OK
13:11 < mael> and frontend devices connecting straight to the vanilla driver
13:11 < mael> then on LW the frontend/backend/vanilla model appeared
13:11 < _MarkW> right.
13:11 < mael> I was not able to dig the change in the ML archives
13:11 < _MarkW> let me just look...
13:12 < mael> I guess this is all explained in the document i'm ready actually in my commuting time : the one related to safe hardware access
13:12 < _MarkW> ian's just missed out the backend drivers in the OLS presentation for clarity purposes
13:13 < mael> mmh ok
13:13 < _MarkW> backend drivers have been there ever 2.0.
13:13 < _MarkW> so the architecture hasn't changed in the timeframe you're looking at, just the diagrams ;-)
13:13 -!- athomas [~athomas@ppp-0-173.lond-b-1.access.uk.tiscali.com] has quit [Quit: Leaving]
13:13 < mael> fact is the presentations (text-less) are one of the only documents with xen architecture
13:14 < mael> I'm trying to figure out things, but as I'm not a native C-speaker, I read the documentation before the source code
13:14 < mael> (my C level is far beyond my english)
13:15 < _MarkW> mael:  sure.  the paper you're reading is also good material
13:15 < mael> you mean, apart from the fact you got your name on it? :))
13:16 < _MarkW>  yeah, apart from that :-)
13:17 < _MarkW> i worked on the driver isolation stuff for that paper
13:18 < mael> a prototype to prove the stuff?
13:19 < mael> I guess the prototype ended in xen production code anyway
13:19 < _MarkW> well, it all works - it's in the 2.0.x tree at the moment
13:19 < _MarkW> but it could do with being a bit more user friendly
13:19 < mael> there's something I don't get also
13:19 < _MarkW> most people prefer to run drivers in dom0, in which case you don't get any more isolation than vanilla linux
13:19 < _MarkW> oh?
13:20 < mael> uh? what do you call isolation in that case?
13:20 < mael> error trapping and the like?
13:20 < mael> stuff you're talking about in the paper?
13:20 < _MarkW> yup
13:21 < mael> ok I'll read it first then, and ask after :)
13:21 < _MarkW> making drivers less privileged so that driver bugs are less able to crash your machine
13:21 < _MarkW> cool :-)
13:21 < mael> hehe
13:23 < mael> yeah the other stuff was related to the changes needed in the hypervisor in order to support different hw architecture
13:24 < mael> x86-64 of course (the xen 3.0 summit talks about it), but also ia64
13:24 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
13:24 < mael> it seems that the hypervisor will need to be separated in multiple layers
13:25 < knewt> gah to people who send html-only emails. i wish the list would just reject such messages
13:25 < mael> one for arch specific treatments (to do strong VM separation), one for ressources access/scheduling and the like, and maybe some more I don't get
13:25 < _MarkW> mael: there's xen/common and xen/arch for splitting out this stuff
13:26 < _MarkW> the interfaces between the two are still evolving
13:26 < soffi_> hmmm ATA over Ethernet
13:26 < _MarkW> but there will be a lot of arch-dependent code - far higher proportion than in Linux
13:27 < mael> _MarkW:  yeah, this is what I'm thinking about
13:27 < mael> what would be an approx. percentage of common/relative code?
13:29 < mael> I fear this would be the usual 30/70
13:29 < mael> or even worse
13:29 < riel> well, the architecture dependant code would be very similar to the non-xen arch code
13:29 < eigood> AoE sucks
13:29 < eigood> very slow
13:30 < mael> riel: oh yeah?
13:31 < mael> you mean similar in volume or in design?
13:32 < mael> maybe both
13:32 < hollis> depends on what is done in dom0 and what isn't
13:32 < soffi_> eigood: how slow? :)
13:34 < eigood> 5MB/s on a 100M lan
13:34 < eigood> that's on native linux; athlon 2000 client, p2-2.4g server
13:34 < eigood> p4-2.4g
13:34 < riel> mael: lots of it would be similar in design
13:35 < riel> mael: in fact, it already is
13:35 < mael> for x86 you mean?
13:35 < riel> for x86-64 too
13:35 < mael> oh
13:35 < hollis> well, for IA64 they literally copy in great gobs of Linux code
13:35 < mael> ok
13:35 < mael> this is not such a waste then :)
13:36 < hollis> what isn't?
13:38 < mael> I feared the project was too x86-centric
13:38 < hollis> well it is :)
13:38 < soffi_> man that is slow
13:39 < mael> as for me the barriers xen's paravirtualisation solution where trying to break are x86 specific
13:39 < mael> at least this is what I understood
13:39 < riel> hollis: not necessarily a bad thing - x86 and x86-64 are 95% of the PC class computers ;)
13:39 < riel> with PPC being most of the other 5%
13:39 < hollis> riel: luckily for us, Linus took a different attitude towards architecture portability...
13:40 < hollis> mael: most architectures have very similar problems they need to solve
13:40 < riel> hollis: "portability" isn't the same as "focus on something non-common"
13:41 < mael> hollis:  ok
13:41 < hollis> sure, but there seems to be limited interest even in portability at the moment
13:41 < hollis> riel: I'm not asking anybody to make PPC work for me... :)
13:41 < mael> but even though they are similar, dealing with them may need a huge amount of effort to deal with the specificities
13:42 < soffi_> but one question.. will it ever be ported to Amiga?
13:42 < soffi_> :-P
13:42 < mael> ;)
13:43 < riel> just run multiple amiga emulators ;)
13:43 < hollis> mael: yes. but at the same time, there are some aspects of hypervisors (such as the virtual IO drivers, NUMA awareness, resource management, scheduling, console, ...) that can be shared across those disparate architectures
13:43 < soffi_> hehehe
13:43 < mael> hollis:  yup
13:43 < mael> but what is the relative amount of code/effort?
13:44 < mael> this is my concern in the first place
13:44 < hollis> relative to what?
13:44 < mael> let's say amount of code produced/modified
13:45 < mael> for both aspects
13:45 < hollis> lines of code? for what? I'm sorry, I'm not understanding your question...
13:45 < mael> sorry
13:45  * mael is trying to reformulate
13:46 < mael> how much of the code produced by xen project on x86 architecture will be usable when porting to another arch?
13:47 < riel> do you refer to code written specifically for xen, or also to x86-specific code that was slightly modified to accomodate xen ?
13:47 < mael> both
13:48 < riel> then you may want to rethink your question ;)
13:48 < mael> hehe
13:48 < riel> surely it would be easier to slightly modify eg. PPC code, instead of porting x86-specific code with Xen modifications over to PPC ?
13:48 < soffi_> I'll trade you 5 tons of snow for 5 minutes of sunshine
13:49 < mael> riel:  yeah sure but I was not trying to ask that :)
13:49  * mikegrb slightly modifies riel 
13:49 < riel> mael: then don't say "both" ;)
13:49 < mael> uh?
13:49 < mael> ok then
13:49 < hollis> mael: all of those things I listed before can be usable when porting to another architecture
13:50 < riel> it should be easy to "port" the non-x86 specific bits of Xen over to other architectures, since they are already non-arch-specific
13:50 < riel> maybe some generalisations will be needed, but certainly no port
13:50 < hollis> yeah
13:50 < mael> hollis:  yes and I guess this is what _MarkW was calling the xen/common stuff
13:51 < hollis> mael: yup
13:51  * _MarkW *grunts and wakes up*
13:51 < mael> but what about the xen/arch code?
13:51 < hollis> mael: the problem is that since those guys are writing both the common and arch code, the interface can get a little blurred sometimes
13:51 < mael> this is kind of wasted when you address arch specific problems, no?
13:52 < mael> ooh
13:52 < mael> okay
13:52 < hollis> right, I am not porting xen/arch/x86 to PPC, but rather creating a new xen/arch/ppc64
13:52 < mael> okay, then we're coming to my question :)
13:53 -!- matta-lt [~matta@69.93.28.254] has quit [Quit: Why is the alphabet in that order?  Is it because of that song?]
13:54 < mael> the code you produce for the xen/ppc64 arch will only be used for xen, right?
13:55 < hollis> yes, though some of it comes from Linux and some of it comes from rhype (IBM Research Hypervisor)
13:55 < _MarkW> mael: there common xen/arch stuff between x86 and x86_64.  common stuff in XenLinux for multiple archs should probably go in drivers/xen
13:55 < mael> _MarkW:  ok
13:56 < _MarkW> since arch/xen is getting pulled into arch/i386, there's nowhere else to put the common code :-)
13:57 < hollis> _MarkW: hang on, I was talking about the Xen core, not the Linux patches
13:57 < _MarkW> hollis:i thought we'd moved onto talking about Linux stuff now...  saw the phrase "arch/xen" and assumed
13:57 < hollis> mael: you were talking about the Xen core, yes?
13:58 < _MarkW> ok, so in Xen I guess the plan is to make the interfaces clean and maximise the amount of stuff in xen/common that the arch ports can use
13:58 < mael> mmmh I am very tempted to say "both", actually
13:58 < mael> :)
13:58 < _MarkW> in XenLinux, the plan is the similar but with common stuff going into drivers/xen instead
13:59 < _MarkW> in XenLinux, I think the plan is to incorporate Xen support into each Linux architecture tree (i386, ppc64, etc)
13:59 -!- soffi_ [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has quit [Read error: Connection reset by peer]
14:00 -!- soffi_ [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has joined #xen
14:00 < mael> what I meant in the first place was : is it a long/difficult process to paravirtualize (=adapt to xen hypervisor design) an arch? and if so, is it efficient to use xen then, instead of writing a new hypervisor from scratch?
14:00 < hollis> mael: PPC is a special case, because PPC Linux has run on IBM's hypervisors for years
14:00 < mael> I guess answears will be something like "that reinventing the wheel is always a waste"
14:01 < mael> hollis:  ok
14:01 < mael> -that
14:01 < hollis> in some sense you could see xen/ppc as "reinventing the wheel" I guess
14:02 < mael> well I guess it has other advantages
14:02 < mael> (I mean xen vs. ibm's hypervisors)
14:02 < riel> migration
14:02 < hollis> for example, IBM could never open source the "real" hypervisor found on pSeries
14:03 < riel> common management tools
14:03 < riel> being fully open source
14:03 < riel> there are probably more advantages
14:04 < mael> yeah, even though a "common vmm management interface specification" would have some of the advantages you spotted
14:04 < mael> but you're right
14:06 < mael> it's just things are not very clear for me sometimes
14:06 < hollis> then you are in good company I think :)
14:06 < mael> yeah :)
14:07 < mael> I was confused by the L4onLinux guy the other day
14:07 < _MarkW> mael:  sometimes things i've done aren't even clear to me - why did I write that line of code?  why did i put all my food?  that sort of thing.
14:08 < _MarkW> mael: which guy?
14:08 < mael> _MarkW:  hold on I'm trying to localize him in the logs :)
14:11 < mael> it was april the 07
14:13 < mael> his nick was rtc2 and he asked how xen to be compared to L4Linux
14:15 < mael> L4Linux is (from what I understood after a quick reading of their website) a porting of linux kernel on top of a L4 microkernel
14:15 < mael> website is http://os.inf.tu-dresden.de/L4/LinuxOnL4/
14:15 < hollis> it's a good question
14:15 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
14:21 < mael> since then I decided to try do have a more indepth look at xen arch, as I suspected most of the differences to be at the low level layers
14:21 < mael> even if from a non-technical user point of view things might appear somewhat similar
14:22 < hollis> if you don't know C it might be difficult to compare the two
14:23 < mael> well I don't think you have to read all the sources to figure out the differences in the concepts
14:24 < knewt> omfg. the US army now has WLAN-controlled landmines. and is going to be deploying them in iraq.
14:25 < mael> ouch! already 8:30pm...
14:25 < mael> time to read the safe hardware  access paper in the train!!
14:25 < mael> see you
14:26 < riel> knewt: interesting, the army's own computer safety guidelines basically prohibit WLAN on their equipment
14:27 < mael> riel:  they probably explode when you're around with your wlan equipment :)
14:27 < knewt> http://www.theregister.co.uk/2005/04/12/laptop_triggered_landmine/
14:32 -!- hebutterworth [~harry@blueice4n1.uk.ibm.com] has quit [Quit: Leaving]
14:37 -!- soffi_ [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has quit [Quit: Leaving]
14:48 < [e]num> yo.. when building xen, is it possible to force a --prefix?
14:48 < [e]num> since I know there is no ./configure script
14:51 -!- anticw is now known as cw
14:54 < knewt> [e]num: assuming you're talking about the tools bit, just specify a DESTDIR when doing the install step
14:55 < knewt> oh, wait, that probably won't do exactly what you want
14:55 < aliguori> [e]num: no, Xen assumes certain paths
15:02 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Quit: Quitting]
15:08 -!- cfreak [cfreak@dsl-084-056-098-175.arcor-ip.net] has quit [Quit: .]
15:13 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
15:15 -!- DEac- [~deac@xdsl-213-196-198-171.netcologne.de] has quit [Quit: Verlassend]
15:15 -!- DEac- [~deac@xdsl-213-196-198-171.netcologne.de] has joined #xen
15:16 < eigood> add a top-level Makefile.vars, have each makefile include it, then modify the paths to reference a $(prefix)
15:16 < eigood> then, you can just edit that file, specify a different prefix on the cmdline, or at some point if it ever gets a configure script, it can be generated
15:16 -!- DEac- [~deac@xdsl-213-196-198-171.netcologne.de] has quit [Quit: ]
15:20 -!- DEac- [~deac@xdsl-213-196-196-16.netcologne.de] has joined #xen
15:24 -!- DEac- [~deac@xdsl-213-196-196-16.netcologne.de] has quit [Quit: ]
15:30 < [e]num> yo.. I got this during boot
15:30 < [e]num>   ** WARNING: Currently emulating unsupported memory accesses  **
15:30 < [e]num>   **          in /lib/tls libraries.
15:30 < [e]num> I dont have a /lib/tls  any ideas?
15:30 < riel> that's ok
15:30 < riel> probably some other program trying to use TLS
15:30 < [e]num> ah
15:30 < riel> no need to worry since TLS emulation is correct
15:30 < riel> it's just a tad slow
15:30 < [e]num> dont know what would use it since I did an LFS.. but as long as it functions as it should
15:31 < riel> I only run with TLS
15:31 < riel> (since I want to verify that TLS emulation never breaks)
15:31 < [e]num> heh
15:31  * riel tries to stay as much on the leading edge as possible
15:31 < riel> if something breaks, I can fix it before users find out there was a problem
15:32 < eigood> it'd be cool if when xen detected that, it could ask what the dom# was doing at the time, so it could print out what program was running
15:34 -!- DEac- [~deac@xdsl-213-196-196-194.netcologne.de] has joined #xen
15:34 < riel> actually, I think the domain is already notified
15:34 < riel> chances are it's just one printk line extra to point out the program
15:34 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has quit [Ping timeout: 480 seconds]
15:35 < [e]num> hmm.. is there a way to get output from xend start
15:36 < [e]num> it seems to load, but when I run xm list it says it isnt running
15:36 < aliguori> [e]num: chances are you have to rm -rf /var/lib/xen/*
15:36 < jeroney> [e]num: check /var/log/xend-debug.log
15:37 < [e]num> OSError: [Errno 2] No such file or directory: '/var/lib/xen/xend-db/domain/'
15:38 < [e]num> that doesnt look too god
15:39 < [e]num> damn.. this thing is slow as hell
15:39 < [e]num> lsmod is taking more than a minute to run
16:23 -!- tierra|w_ [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
16:25 -!- tierra|w_ is now known as tierra|w
16:27 < [e]num> hmm.. okay this is interesting.. 
16:27 < [e]num> when I built xen it compiled both dom0 and domU kernels, and placed them in boot
16:28 < [e]num> I created a phys vbd, and attempted to boot the domU.  the boot goes up intul fsck, and fails saying it cannot find /dev/sda1
16:31 < [e]num> does CONFIG_SCSI_SATA have to be configured into the domU kernel?
16:43 < eigood> whatever device is being emulated in domU needs to be compiled in domU
16:44 < eigood> it's one of those poorly implemented things
17:06 -!- plars_ [~plars@pixpat.austin.ibm.com] has joined #xen
17:08 -!- plars [~plars@pixpat.austin.ibm.com] has quit [Killed (NickServ command used by plars_)]
17:08 -!- plars_ is now known as plars
17:13 -!- GvG [GvG@geldorp.xs4all.nl] has joined #xen
17:14 < _MarkW> eigood: [e]num i didn't think you had to compile in SCSI support to use SCSI drives in a domU
17:14 < _MarkW> the VBD driver doesn't talk to the SCSI layer anyhow, so I wouldn't have thought it mattered.
17:14 < _MarkW> [e]num: what if you export as /dev/hda1 ?
17:15 < _MarkW> mael: you still here?
17:16 < _MarkW> mael: L4 was designed from a microkernel mindset, so it provides abstractions that look like minimal kernel features
17:16 < _MarkW> e.g. "tasks", "address spaces", "inter process communication"
17:17 < _MarkW> Xen differs in that it provides an interface that's more hardware-like: you just get memory, event channels (much like interrupts) and the hypercalls (which are much like CPU privileged instructions)
17:19 < [e]num> _MarkW, I found out what it was.. LFS uses udev to populate the dev directory
17:20 < [e]num> so I turned udev off, and statically created sda1 with mknod
17:20 < [e]num> booted right up after that
17:24 -!- rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
17:30 < _MarkW> [e]num: udev should work fine anyhow
17:30 < _MarkW> [e]num: but it'll break if you don't use an initrd
17:33 < demon> well, only if you use FC3's udev setup, where it completely eliminates all real nodes in /dev
17:33 < demon> with at least some other distros, there are real nodes there so that the system can get off the ground
17:34 < _MarkW> demon: ok.  i don't know what LFS does - never used it.
17:35 < demon> ouch... LFS
17:35 < aliguori> yeah, gentoo actually saves the contents of /dev across reboots.. it's quite now
17:39 < _MarkW> ok.  i assumed everyone kept /dev empty like FC.
17:39 < _MarkW> i live and learn :-)
17:39 < aliguori> :-)
17:39 < aliguori> _MarkW: how's XenFS coming along?
17:40 < riel> _MarkW: btw you don't need an initrd
17:40 < aliguori> i've heard whispers that it might make 3.0 :-)
17:40 < _MarkW> riel: really?  what do you do instead?
17:40 < riel> _MarkW: if you just put 'null' and 'console' in the empty /dev directory (with udev not mounted), things will work fine
17:40 < riel> _MarkW: this is documented in the FedoraXenQuickstart page ;)
17:40 < _MarkW> riel: ah, ok.  that should probably go into the Xen FAQ too.  or at least we should link there - it seems to be a very common question.
17:41 < riel> yeah, you might want to link it ;)
17:41 < _MarkW> aliguori: might be in beta by 3.0 but i doubt it'll be production quality
17:41 < riel> unfortunately I'm not allowed to edit that page (or at least, I wasn't last I looked) or I would have added it already
17:41 < _MarkW> it's going OK
17:42 < _MarkW> riel: interesting...  well if you can't get there then i probably can't either!  i was supposed to acquire admin rights at some stage but i'm not sure that's happened yet
17:42 < eigood> it'd be better to include it, not link it
17:42 < eigood> I don't think it's best if xen pushes any particular distro
17:42 < riel> eigood: and be out of date next time the fedora page is changed ?
17:42 < eigood> also considering xen deals with more than just linux
17:42 < aliguori> yeah, it's kind of hard to figure out where to add stuff in the wiki as so many of the pages are read-only
17:43 < _MarkW> eigood: this is a specifically Linux issue though
17:43 < eigood> but not just redhat/fedora
17:43 < _MarkW> but I guess the same fix should work for other distros...
17:44 < _MarkW> eigood: exactly.  we should probably link to distro howtos somewhere but if other distros can make do with just /dev/null and /dev/console then that could go in the generic faq
17:44 < aliguori> correct me if i'm wrong riel, but this is not a Xen issue as much as it's a Fedora issue
17:44 < aliguori> you probably can't boot Fedora in general without an initrd (unless you had /dev/console and /dev/null)
17:45 < aliguori> unless Fedora has a patched kernel...
17:45 < _MarkW> riel: that's interesting - somebody has added it to the FAQ page in the Xen wiki...
17:46 < _MarkW> it wasn't there last time i looked
17:46 -!- jeroney [~jeroney@pixpat.austin.ibm.com] has quit [Quit: Leaving]
17:46  * _MarkW shrugs
17:52 < riel> cool
17:53 < riel> aliguori: the xenU kernel has ext3 built-in
17:53 < riel> aliguori: so you don't need the initrd
17:53 -!- jeroney [~jeroney@pixpat.austin.ibm.com] has joined #xen
17:53 < _MarkW> aliguori: re XenFS, I was going to implement it a stupid way first
17:54 < _MarkW> just to get it working quickly.  but i've decided that it's actually easier to implement it the cunning way straight off
17:54 < aliguori> _MarkW: have you changed your mind? :-)
17:54 -!- jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com] has joined #xen
17:55 < _MarkW> if i can get direct page sharing working then coherency is (relatively) trivial
17:55 < riel> how can you do direct page sharing when a domain migrates away ? ;)
17:56 < _MarkW> riel: that's a problem for later work ;-)
17:56 < riel> fair enough
17:56 < _MarkW> first step for XenFS is to optimise for sharing within one machine
17:57 < aliguori> _MarkW: what about between multiple domains?
17:57 -!- jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com] has left #xen [Leaving]
17:57 < _MarkW> exactly how migration will work isn't clear yes
17:57 < _MarkW> aliguori: that's what i'm interested in
17:57 < _MarkW> first off, coherent multiple writer sharing
17:58 < aliguori> how do you achieve that?
17:58 < _MarkW> (in fact as a side effect, shared memory between processes in different domains should Just Work(TM) by mmaping a file)
17:59 < aliguori> do you have multi-domains mutexes or something?  or do you guys have a clever lock-free mechanism :-)
17:59 < aliguori> _MarkW: neat!
18:00 < _MarkW> the fsfront / fsback drivers will do some gyrations to make the page frame backing a file page be the *same* page frame in every (participating) page cache
18:01 < aliguori> oh, but not for metadata right?  so if you use the control channels for metadata locking doesn't matter (assuming you can lock at the inode level)
18:01 < _MarkW> the plan is when one domain updates its page cache, the other domains will just see it there (there'll need to be some signalling to make sure changes are noticed and written out by the server)
18:01 < riel> _MarkW: http://wiki.xensource.com/xenwiki/WhosDoingWhat is an immutable page, too ;(
18:01 < riel> _MarkW: it would be useful if that page was editable by everybody with a login
18:01 < riel> oh wait -
18:01 < riel> my cookie expired ;)
18:02 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Quit: Quitting]
18:02 < cw> riel: /~ C is fo Cookie ~/
18:02 < hollis> in the UK do they call them biscuits? :)
18:02 < riel> J is for join, which nobody uses
18:03 < cw> yeah, and other places
18:03 < cw> nz, au, sg, probably a few others
18:03 < _MarkW> hollis: i suppose we should really
18:03 < _MarkW> mmmm food
18:03 < cw> I'm bummed they are making Cookie Monster more PC.  When I was a kid he was one of the cooler characters.
18:04 < aliguori> so what do they call a biscuit in the uk if a cookie is a biscuit?
18:04 < riel> cw: what?!  they're even taking the fun out of sesame street?
18:04  * riel wonders what this world is turning into
18:04 < cw> riel: cookies are bad, so the song and everything are being ruined
18:04 < aliguori> riel: yeah, he'll eat cookies in moderation
18:05 < cw> sigh, every kid gets a packet of cookies and pretends to be cookie monster at some point
18:05 < _MarkW> aliguori: biscuits are biscuits ;-)  cookies are a subclass of biscuits
18:05 < riel> throwing up is the best way to learn that cookies can be bad ;)
18:06 < _MarkW> riel: cookies are only bad in the same way that pizza is bad
18:06 < _MarkW> i like that kind of bad!
18:06 < aliguori> pizza is great!
18:06 < _MarkW> aliguori: exactly :-)
18:06 < aliguori> i have pizza 4-5 times a week.. and i'm not dead yet
18:06 < aliguori> so it's gotta be good :-)
18:06 < _MarkW> whoa!
18:07  * _MarkW humble bows to aliguori, the master of pizza
18:07 < aliguori> i even worked in a pizza place back in jersey :-) it's in my blood man :-)
18:08 < cw> oscar is cool too, i would so live in a garbage can too if i had to deal with everyone on Sesame Street
18:08 < _MarkW> how about living in the garbage can at the cookie factory?
18:09 < _MarkW> (if you had your pick of cans, that is)
18:12 < _MarkW> then you'd get tons of broken cookies that they couldn't package.  also, broken cookies have the calories leak out so they're more healthy.
18:12 < riel> you believe the "magic blue smoke" story, too ? ;)
18:12 < aliguori> _MarkW: you can also shake out more calories out of the cookie
18:13 < _MarkW> riel: that's right.  i often let the magic smoke out of things.
18:16 < _MarkW> sometimes i let virtual magic smoke out of my xen domains also
18:17 -!- mdday [~mdday@bi01p1.nc.us.ibm.com] has left #xen [/dev/stomach]
18:19 < hollis> :)
18:23 -!- jeroney [~jeroney@pixpat.austin.ibm.com] has quit [Quit: Leaving]
18:42 < knewt> what's the function tidyup_all() mentioned in grant-tables.txt?
18:43 -!- JViz [Anomaly@cpe-024-167-184-225.triad.res.rr.com] has quit [Quit: YES THEY DESERVE TO DIE, AND I HOPE THEY BURN IN HELL!]
18:45 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
18:46 -!- riel is now known as unriel
18:47 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [Quit: leaving]
18:56 < _MarkW> knewt: haven't seen it
18:56 < _MarkW> what's it suposed to be for?
18:57 < soffi> damn.. if I could get Grand Theft Auto to run on a xenU I could live-migrate it to and from work
18:57 -!- rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
18:58 < _MarkW> knewt: ah, it looks like a hypothetical function for cleaning up any grants that succeeded before one failed
18:58 < knewt> in the example code, after the hypervisor grant_table_op call, there's a loop through the mapped frames, and inside it does this:     if ( unlikely(aop[i].u.map_grant_ref.dev_bus_addr == 0) ) { tidyup_all(aop, i); goto panic; }
18:58 < _MarkW> implementation left to the reader :-)
18:58 < knewt> ah, ok
18:59 < _MarkW> it passes the pointer to the array of ops and the current counter, which is probably all you'd need
19:00 < knewt> so it just does another grant_table_op, but this time with GNTTABOP_unmap_grant_ref ?
19:00 < _MarkW> yeah probably.  alternatively it could panic or hire a hitman to shoot the programmer.
19:00 < _MarkW> your solution is probably the most useful
19:01 -!- GvG [GvG@geldorp.xs4all.nl] has quit [Quit: Goodnight]
19:05 -!- demon [demon@newcastle.devrandom.net] has quit [Ping timeout: 480 seconds]
19:19 < niv> anyone remember if there was an oops in zap_pmd_range recently on domU?
19:29 < _MarkW> niv: don't remember seeing one
19:29 < _MarkW> -unstable tree?
19:30 < niv> _MarkW: yep, but 0401 kernel
19:30 < _MarkW> 0401?
19:31 < niv> April 1 nightly snapshot
19:31 < _MarkW> Oh right, OK.
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel: Unable to handle kernel paging request at virtual address c6ec35e4
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel:  printing eip:
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel: c01434f6
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel: *pde = ma 7ff64067 pa 00019067
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel: *pte = ma 079aa063 pa 06ec3063
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c0143718>] zap_pmd_range+0x57/0x75
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c0143770>] zap_pud_range+0x3a/0x5e
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c0143808>] unmap_page_range+0x74/0x8b
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c014391c>] unmap_vmas+0xfd/0x223
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c01489b7>] exit_mmap+0x84/0x156
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c01158ee>] mmput+0x2b/0x94
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c015e899>] exec_mmap+0xcb/0x12b
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c015eaae>] flush_old_exec+0x123/0x9ca
19:31 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c015436b>] vfs_read+0xb9/0x129
19:32 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c015e7c5>] kernel_read+0x4a/0x53
19:32 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c017c627>] load_elf_binary+0x37d/0xc9a
19:32 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c013910e>] buffered_rmqueue+0x153/0x2ba
19:32 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c02016e9>] copy_from_user+0x3d/0x64
19:32 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c017c2aa>] load_elf_binary+0x0/0xc9a
19:32 < niv> Apr 12 15:29:48 nivdom1 kernel:  [<c015f5ee>] search_binary_handler+0xbb/0x2e9
19:32 < niv> brb..
19:32 < _MarkW> niv: don't thing i've heard of anything like that recently
19:32 < niv> ok..will be right back..thanks..
19:33 < _MarkW> ok, just prod me when you're back.  it doesn't look very good!  are you running anything strange like shadow mode, grant tables on, xens and linuxs built at different times?
19:57 -!- alex234 [new@pD9E1FCF0.dip.t-dialin.net] has joined #xen
20:02 < niv> _MarkW: no, nothing unusual - default config, compiled together, etc...
20:02 < _MarkW> that's a bit strange.  what were you doing with it?
20:03 < niv> it was idle!
20:03 < niv> wasn't at the machine, came back to find that on my screen
20:04 < niv> Had done a bunch of pings earlier..
20:04 < _MarkW> hrrrm, sounds like a gremlin!
20:05 < _MarkW> i guess reproducing will be tricky then...
20:06 < niv> Yep, can't think of what to try, but am giving it a go - just going to run random tests etc
20:06 < niv> anything that I can instrument?
20:06 < niv> or should be looking at?
20:07 < _MarkW> No idea!
20:07 < _MarkW> if you're not doing anything unusual then I really don't know what it could be
20:07 < niv> Well, someone else will run into it as well. I do have scsi disks, and running on an SMP
20:08 < _MarkW> I guess you could post to xen-devel, maybe one of the others will have a clue.
20:08 < _MarkW> SMP guest?
20:08 < niv> but not an SMP kernel, UP kernel, but SMP box - not that it should make a difference, but..
20:09 < _MarkW> it's good to be paranoid :-)
20:09 < niv> :)
20:12 -!- drbyte [~byte@c210-49-121-44.eburwd3.vic.optusnet.com.au] has quit [Read error: Connection reset by peer]
20:15 -!- drbyte [~byte@c210-49-121-44.eburwd3.vic.optusnet.com.au] has joined #xen
20:21 -!- soffi [~soffi@proxy.du.vdsl.is] has quit [Quit: Leaving]
20:47 -!- alex234 [new@pD9E1FCF0.dip.t-dialin.net] has quit [Read error: Connection reset by peer]
20:53 -!- alex234 [new@pD9E1FCF0.dip.t-dialin.net] has joined #xen
20:55 -!- demon [demon@newcastle.devrandom.net] has joined #xen
21:04 -!- alex234 [new@pD9E1FCF0.dip.t-dialin.net] has quit [Quit: Leaving]
21:30  * _MarkW yawns
21:30 < _MarkW> enough XenFS for tonight.  gnight all.
21:30 -!- _MarkW [~MarkWilli@hebble.cl.cam.ac.uk] has quit [Quit: Kopete 0.9.2 : http://kopete.kde.org]
21:31 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has quit [Read error: Connection reset by peer]
21:34 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has left #xen [Leaving]
21:59 -!- Gollum [~gollum@pcp01411681pcs.phnixv01.pa.comcast.net] has joined #xen
22:00 < Gollum> just wondering if there are any irq problems in the latest unstable build...
22:00 < Gollum> anyone know anything about that?
22:03 -!- hena [hena@hack.fi] has joined #xen
22:03 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
22:08 < rusty> aluguori: hi!
22:09 < Gollum> hello folks.  just wondering if there are any irq problems in the latest unstable build...
22:11 < rusty> Hello.
22:17 < rusty> aliguori: sorry, will try to spell right.
22:20 -!- tab [~tab@darwin.snarc.org] has quit [Ping timeout: 480 seconds]
22:21 -!- Gollum [~gollum@pcp01411681pcs.phnixv01.pa.comcast.net] has left #xen []
22:40 -!- JViz [Anomaly@cpe-024-167-184-225.triad.res.rr.com] has joined #xen
23:01 -!- tab [~tab@darwin.snarc.org] has joined #xen
23:11 -!- tierra|w [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit [Quit: Everybody wants to go to heaven, but nobody wants to die.]
23:13  * surriel wonders if /dev/random being low on bits is xen related
23:14 < mikegrb> surriel: in domu or dom0
23:14 < surriel> dom0
23:14 < mikegrb> oh odd
23:14 < mikegrb> was going to guess lack of harware interrupts
23:15 < mikegrb> well I'm not quite sure how those are handled in xen but I'd imagine they would be delivered to dom0 since it gets hardware access
23:15 < surriel> well, dom0 gets hardware access - but irqs come in via the hypervisor
23:15 < surriel> dunno if that makes a difference
23:15 < surriel> also, there may be hypervisor events suitable for input to the entropy pool ;)
23:20 < mikegrb> aye
23:20 < mikegrb> I know uml guests can have issues with entropy
23:44 -!- knewt [~jmb@zeus.pimb.org] has quit [Ping timeout: 480 seconds]
--- Log closed Tue Apr 12 23:59:00 2005