Back to Home / #xen / 2005 / 04 / Prev Day | Next Day
#xen IRC Logs for 2005-04-20

---Logopened Wed Apr 20 00:00:03 2005
00:36--- ---> JViz [Anomaly@cpe-024-163-002-218.triad.res.rr.com] has joined #xen
00:57--- <<-- aliguori- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit (Read error: Connection reset by peer)
01:26--- <<-- N [~ca4bc809@webuser.thegrebs.com] has quit (Quit: http://thegrebs.com/oftc/ (Session timeout))
02:09--- <<-- muli_ [~muli@nesher3.haifa.il.ibm.com] has quit (Read error: Connection reset by peer)
02:12--- ---> muli_ [~muli@nesher3.haifa.il.ibm.com] has joined #xen
02:23--- ---> N [~ca4bc809@webuser.thegrebs.com] has joined #xen
02:28--- <<-- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has quit (Ping timeout: 480 seconds)
02:31--- ---> Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has joined #xen
02:49--- <<-- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has quit (Ping timeout: 480 seconds)
03:00mael hi
03:01@cw howdy
03:11hebutterworth| hi
03:17--- <<-- cw [cw@adsl-67-124-119-21.dsl.snfc21.pacbell.net] has quit (Quit: better not oops :))
03:33--- ---> Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has joined #xen
03:43caker !skas-2.6?
03:43caker whoops, mcm
03:45--- ---> anticw [cw@adsl-67-124-119-21.dsl.snfc21.pacbell.net] has joined #xen
03:45--- Channel: mode/#xen [+o anticw] by ChanServ
03:45--- User: *** anticw is now known as cw
03:59--- ---> athomas [~athomas@hardpress.demon.co.uk] has joined #xen
04:03--- User: *** cw is now known as anticw
04:47--- <<-- deac [~deac@xdsl-84-44-215-62.netcologne.de] has quit (Read error: Operation timed out)
05:00--- ---> deac [~deac@xdsl-81-173-137-130.netcologne.de] has joined #xen
05:05--- <<-- athomas [~athomas@hardpress.demon.co.uk] has quit (Quit: Leaving)
05:52--- ---> soffi [~soffi@Tolvudeild-SC-gw.vv.simnet.is] has joined #xen
05:53--- ---> uriel [~binarydre@green.eye.binarydream.org] has joined #xen
07:05--- ---> yarihm [~yarihm@80-218-3-32.dclient.hispeed.ch] has joined #xen
08:38--- ---> hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
08:52--- ---> athomas [~athomas@hardpress.demon.co.uk] has joined #xen
08:52--- <<-- athomas [~athomas@hardpress.demon.co.uk] has quit (Quit: )
08:59--- User: *** unriel is now known as riel
09:13knewt anyone know if the move of ACPI into dom0 has happened in -unstable yet?
09:37--- <--- uriel [~binarydre@green.eye.binarydream.org] has left #xen ()
09:37--- <<-- Bluefox [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has quit (Quit: http://ubuntulinux.org/ | http://gentoo.org)
09:39--- ---> Bluefox [~bluefox@pcp484971pcs.whtmrs01.md.comcast.net] has joined #xen
09:47--- <<-- N [~ca4bc809@webuser.thegrebs.com] has quit (Quit: http://thegrebs.com/oftc/ (Session timeout))
09:48--- ---> rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
09:58--- ---> N [~ca4bc809@webuser.thegrebs.com] has joined #xen
10:15--- ---> aliguori- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
10:15aliguori- mornin'
10:18rharper aliguori: morning
10:19aliguori- rharper: you wouldn't happen to know ash scripting would you?
10:20rharper aliguori: I indeed am quite familiar with ash
10:20aliguori- you use some different shell contructs than I'm used to.. i wondering if you know if they're available on ash (like {})
10:20aliguori- awesome :-)
10:20rharper heh, no, arrays arent available in ash
10:20rharper =(
10:20rharper do we need to be ash compat ?
10:20aliguori- hmm, well, that's ok
10:21aliguori- well
10:21rharper I can respin
10:21rharper will be uglier
10:21aliguori- i want to be, but don't worry about it for now
10:21aliguori- i'm going to do an ash-compat pass at some point in the future
10:21aliguori- b/c i want to make sure vm runs under busybox :-)
10:22rharper so, ash supports things like ${foo}, thats just extra scoping, ash doesnt support foo=( `ls` ) , or ${foo[i]}
10:22rharper yeah, arrays have to come out for busybox
10:22aliguori- there's other stuff in vm right now that prevent that.. thought i had removed them but apparently i didn't check it in
10:22rharper I can rewrite for busybox sh
10:22riel ash is like bash, but with less richer syntax
10:22rharper and no arrays =(
10:22aliguori- yeah, and functions can't use the function keyword.
10:22rharper ugh, yes
10:22riel lack of arrays is annoying
10:23aliguori- i've never actually used shell arrays.. and here i thought i used obscure shell stuff :-)
10:23rharper aliguori: in my former job we abused arrays to no end, it was quite fun, almost perl-like in its obscurity
10:24rharper oh, IIRC, ash doesn do ${!p} either
10:24rharper so no function pointers
10:24* knewt played with them recently as a bit of fun in implementing perl "split" in pure bash shell script
10:24knewt :)
10:25rharper aliguori: no math in ash/bb, $((count+2))
10:25aliguori- rharper: i didn't even know you could do function pointers.. i probably would have just eval'd to simulate it
10:25rharper aliguori: yeah, thats what you have to do in ash
10:25--- ---> hbaum [~hbaum@bi01p1.co.us.ibm.com] has joined #xen
10:25aliguori- rharper: i have to check my root image and see if i've got bc in there
10:26rharper you can use let
10:26aliguori- nope.
10:26rharper let i=i+1
10:26aliguori- indeed. neat
10:52mael hi aliguori
10:53mael interesting conversation about DoS on xen lately
10:54mael it seems that ressources sharing is still not implemented on every aspect of xen architecture
10:55mael (I mean with quota/threshold/sharing algorithms and so on)
10:55--- <<-- aliguori- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit (Read error: Connection reset by peer)
10:57mael mmh either I'm a truly unlucky man or either I'm so boring they manage to get a tricky system to avoid my questions :)
10:57* mael had the same "reset by peer" error a few days ago with rusty
11:00mael well, time to go anyway
11:00--- <<-- mael [~mael@nat.inha.fr] has quit (Quit: see ya)
11:00--- ---> anthony [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
11:02rharper haha
11:03--- User: *** anthony is now known as aliguori-
11:06plars what's the config parameter for multiple cpus in xenU?
11:06plars config file that is, not kernel config
11:31plars ahh, vcpus
11:31plars rharper: did your cpumap stuff get in?
11:46rharper plars: not yet
11:46rharper grinding on some dom0 op interface details
12:16--- ---> cfreak [cfreak@dsl-084-056-099-111.arcor-ip.net] has joined #xen
12:26plars oh cool, vcpus > cpus works already, didn't know that was the case
12:27riel I've been using it for months ;)
12:30--- <<-- cfreak [cfreak@dsl-084-056-099-111.arcor-ip.net] has quit (Quit: .)
12:34--- ---> hebutterworth_ [~harry@195.212.29.91] has joined #xen
12:37--- <<-- hebutterworth [~harry@blueice1n1.uk.ibm.com] has quit (Ping timeout: 480 seconds)
12:39--- ---> tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
12:43cdub riel: what was the vdso issue?
12:45riel cdub: xen0 domain hangs with roland's latest vdso changes
12:45riel (which are upstream)
12:45cdub riel: did offset change? (i didn't look upstream yet, /me looks)
12:46riel good question
12:48cdub hmm, doesn't look like it (but i don't have most current tree ATM)
12:49--- ---> mael [~mael@kali.tirnamban.org] has joined #xen
12:49riel the vdso is mapped at a random offset
12:49riel in a real vma
12:49riel so it can work with execshield
12:50cdub hrm, sounds potentially problematic, how did you work around that?
12:51riel I don't have it working yet ;)
12:51cdub ahhh, I see ;-)
12:51cdub riel: I'm mucking in that area right now, hence the questions ;-)
12:52riel arghhhhhh
12:52* cdub ducks
12:52riel I need to use the i386 vsyscall.lds.S not the xen vsyscall.lds
12:52riel I think
12:52cdub riel: that's what I'm trying to fix right now
12:53cdub riel: xen needs proper offsets, rather than hardcoded vsyscall.lds (so the normal vsyscall.lds.S can work properly)
12:56eigood xen still suffers a bit from NIH
12:56riel *nod* (at cdub)
12:56eigood instead of writing their own scheduler, io, etc, they should just be pure linux in ring 0, and modify the linux scheduler to schedule ring1 apps, instead of userspace/ring3
12:57eigood including pipe support, for inter-domain communication
12:57riel eigood: sounds like a bad idea to me
12:57eigood why?
12:58riel there are advantages to having a small and simple hypervisor
12:58mael ring 1 and 2 disapeared on x86_64 arch, no?
12:58riel also, think about driver domains
12:58riel mael: but VT/Pacifica give back new rings ;)
12:58cdub heh, true
12:58mael well a 1/2 -1 ring at least
12:59* mael is still perplex on the vmx stuff
12:59mael fair scheduling seem very hard to manage with vmx
12:59eigood riel: driver domains is like root in normal linux accessing hardware directly
13:00mael eigood: in dom0 yes but not in unprivileged domains, if I understand correctly
13:00riel eigood: not with Pacifica
13:01riel eigood: domains can get access to only their own PCI devices and their own memory
13:01riel eigood: no DMAing over other people's memory, either
13:01mael riel: this is through the pci grant table of pacifica?
13:02riel I think so
13:02riel but I only saw the presentation at the xen summit ;)
13:02riel no other info
13:02eigood that sounds like IPC to me
13:02eigood or netlink
13:02mael ok I couldn't really understand the difference on the pacifica powerpoint presentation
13:02mael this is the only document I was able to find
13:02eigood driver domain uses netlink to the base xen/linux in ring0, to request access to resources
13:03mael but it is mainly a commercial/marketing stuff
13:03eigood driver domains and normal domains use IPC to send data
13:03cdub eigood: at the cost of extra context switching
13:03riel eigood: the point is that the device drivers run directly in the driver domain, not in dom0
13:03cdub eigood: e.g. with pacifica you let hardware protect you (iommu and dev exclusion vector or whatever it was called) once it's set up
13:04eigood riel: where I have said that wouldn't still be the same?
13:04eigood oh, wait, I did.
13:04mael cdub: so they implemented the kind of hardware Mark's paper told about?
13:04eigood well, if programming a pci device allows it to read/write to other memory, something has to filter said programming to validate it.
13:05cdub mael: sorry, which paper?
13:05riel eigood: the hardware filters that
13:05mael cdub: the one on safe hardware sharing
13:05eigood well, then pacifica allows things to be faster, and could be stubbed out on such systems
13:05eigood but there are going to be lots of machine for quite a while yet that don't have the tech
13:05mael I think the conclusion was that they missed a iommu stuff
13:06mael (but I'm far from a good comprehension :))
13:06cdub amd got that, it's intel that missed iommu
13:06riel eigood: but do you want to optimise not-yet-ready software for hardware that might be obsolete by the time all the software features are implemented ?
13:06mael uh ok
13:07mael riel: well what about arch different than x86? what about ppc ia64 and so on?
13:08mael do they have the same needed hardware? (the iommu stuff)
13:08riel mael: ppc has an existing hypervisor interface already, which xen is being ported to
13:08cdub ppc isn't so crippled ;-)
13:08mael hehe
13:08riel mael: I'm not sure about ia64, but to be honest I'm not very interested in ia64 either ;)
13:08riel I know an ia64 won't be price effective for me, ever ;)
13:08eigood riel: are you suggesting that xen will no longer support pre-pacifica in the near future?
13:08cdub ia64 has similar VT tech coming down the pipeline
13:08mael what do you call hypervisor interface? is it a vmx-like stuff or a wired-hypervisor?
13:09riel eigood: no, those will still be supported
13:09mael cdub: yeah right, vt-i/vt-x
13:09riel eigood: it's just that driver domains don't make much sense on those domains, since they could still DMA over any other domain
13:09eigood riel: then such support still requires xen to validate hardware programming requests, in addition to context switches when talking to other domains
13:09riel eigood: no, on such an architecture you just trust your device drivers
13:10eigood oh, if xen doesn't already do hardware programming verification, then remove that stmt I said
13:10riel if you're paranoid enough to not trust your device drivers, you can buy a newer computer
13:10eigood but inter-domain communication already requires upcalling into xen/ring0
13:10hollis mael: PPC has IOMMUs, and also has processor support for hypervisors
13:10mael riel: well linux device drivers at least may be critized, if you're in the real-time business for example
13:10eigood maybe not on every put/get from a ring buffer, of course
13:11hollis mael: if you think in terms of "rings", normal PPC has only two: user and supervisor
13:11mael hollis: ok
13:11mael this is a specialised instructon set then?
13:11hollis mael: some PPC processors have basically added a third ring, hypervisor mode
13:11riel IMHO, if you have old hardware xen should run - but if you want new fancy things, requiring hardware support isn't unreasonable
13:11hollis mael: there are almost no instruction set differences
13:12mael hollis: ok
13:13mael what are the ppc processors you're talking about?
13:13mael I guess my powerbook has only 2 rings :)
13:13hollis POWER4(+), POWER5, and 970
13:13hollis yup
13:13mael too bad :)
13:13hollis yeah
13:13hollis I agree :)
13:14mael shitty pile of aluminium! :)
13:14hollis hey now! :)
13:15mael so, pservers have the 3 rings ones?
13:15mael and the new apple bi-power5 machines also
13:15hollis yes, but not all pSeries. POWER3 and the RS64 processors do not have hypervisor mode
13:15hollis "bi-power5" ?
13:15mael ok
13:16mael hold on, browsing apple website :)
13:17mael hum
13:17mael are G5 cpu power5 cpu?
13:18hollis no. "G5" is a 970, which is based on the POWER4 but has some newer features (like from POWER5) as well
13:18hollis however
13:18hollis Apple has disabled 970 hypervisor mode in their firmware
13:18hollis much to our dismay
13:19mael what for?
13:19mael it seems stupid to me
13:19hollis they don't need/use it
13:19hollis so I guess they'd rather not deal with it
13:19hollis I don't really know why, just guessing
13:19mael and you can't enable it in OF?
13:20hollis no, you actually can't enable it from the 970 itself
13:20riel Apple might be convinced to turn it on in future systems, at least their higher-end ones
13:20hollis when I say "firmware", I mean another chip that initializes the 970
13:20mael ooh
13:20mael that's stupid, cos otherwiser Linus would have been very interested in porting xen mainstream :)
13:21mael as he has a bi-G5 from what I heard
13:21hollis he does, yeah
13:22mael mmh we'll get another way ;)
13:22mael and you're doing such a smart/quick job on xen that it'll be mainstream in no time
13:24* mael is counting on vt-x on desktop machines also
13:24mael this is going to bring a lot of ppl to virtualization I guess
13:24soffi whatsup guys
13:24mael lo soffi
13:25soffi I just got this amazing offer on managed hosting here in Iceland... It's just too tempting to rent and run some xenU's on it
13:26soffi would speed up making images all the time
13:26mael hehe
13:26mael did you had time to look over the document I sent you?
13:27soffi I thought renting hardware would be so expensive
13:27soffi Yeah I glazed at it, but out CEO is in usa and I'm doing all sorts of management as well for the next week
13:27soffi Lucky if I have time to eat
13:28mael ok
13:28soffi But I gotta go put some time into the images... at least the gentoo image... got all sorts of mails about it ;)
13:29soffi mostly unpleasant ones :)
13:29mael hehe
13:32@Sir_Ahzz so what's up guys?
13:32* Sir_Ahzz attempts to knock some drywall dust off himself. 8-P
13:33mael hi Sir_Ahzz
13:35soffi not much
13:37mael well, I'm sure you all already know that SuSe pro 9.3 is out and include xen?
13:37@Sir_Ahzz *nod*
13:38soffi did they include any tools with it ?
13:38soffi y'know ?
13:38mael well I don't know much
13:38mael only what the website says
13:38soffi I have yet to burn the live DVD iso
13:39mael but I don't think they'll have vm-tools yet
13:39soffi vm-tools ?
13:40mael aliguori could probably inform us better on that topic
13:40soffi am I dumb? what is that
13:40mael aliguori's C tools
13:40aliguori- soffi: vm-tools is an alterative toolchain
13:40mael is in the topic ;)
13:40aliguori- writting in C
13:40mael hehe hello aliguori
13:40aliguori- they don't (yet) support the 2.0.x tree
13:40aliguori- hi mael
13:40* Sir_Ahzz should get back to the drywalling soon since the client is paying him later today to continue work. 8-P
13:40aliguori- SuSE 9.3 is based on the 2.0.x tree IIRC
13:40mael mmh
13:41@Sir_Ahzz the toolchain definitly needs to be cluster centric IMO
13:41soffi ahh,, I am dumb, I don't even know what a toolchain is
13:41mael They're not very precise on that topic
13:41mael they say "the latest available version" or something like that
13:42mael it could be a 3.x snapshot
13:42mael aliguori : btw have you read what I wrote a few hours ago?
13:42aliguori- Sir_Ahzz: "cluster centric" is such a nebulus phrase
13:43aliguori- mael: probably not.. my machines been crashing frequently so i don't have much history
13:43@Sir_Ahzz it needs to be oriented from the perspective of managing a cluster, even if that cluster is just one machine.
13:43mael aliguori : ok
13:43@Sir_Ahzz not from the curent perspective of being a toolset for a single machine running xen domains.
13:43aliguori- Sir_Ahzz: but what's different between a cluster and a network
13:44aliguori- Sir_Ahzz: see, I have a slightly different approach. I think the most important thing is that they tie in well with *existing* management tools (such as cluster management suites)
13:45mael aliguori: btw I could'nt find the uclibc and busybox how to on the wiki :)
13:45@Sir_Ahzz I don't think any management tools really work well with the xen perspective.
13:45mael but I saw you talking about ash on the chan today :)
13:45aliguori- mael: of course not :-)
13:45aliguori- yeah, i keep pushing it off
13:45@Sir_Ahzz well i'm off get more mud on myself. 8-P
13:45aliguori- i'd like to wait until the next big release so that the info's up-to-date
13:45@Sir_Ahzz I should take pics of the closet and whatnot before it get's too far along.
13:46* Sir_Ahzz splits for now... laters.
13:46aliguori- last time i looked on the wiki, i wasn't sure where to actually put it either.. so many of the pages are read-only
13:46aliguori- Sir_Ahzz: there are tons of industry management tools that already manage hypervisors..
13:46aliguori- Xen is not the first hypervisor :-)
13:47mael aliguori yeah that's true the wiki is mostly read only
13:47mael and in the same time Ian keep on telling ppl to write stuff there ;)
13:47aliguori- so i didn't see any obvious place to put a busybox howto
13:48aliguori- yeah, i mean, all you can write to is the distro support page and who's doing what it seems
13:48aliguori- and the faq
13:48aliguori- i've never seen a wiki with so many read-only pages
13:48aliguori- even wikipedia only makes the front-page read only.
13:48mael well, I'll re-ask you questions related to the ressources management an other time
13:48eigood said industry management tools are not free tho, right?
13:49aliguori- eigood: define free
13:49mael it's almost time for me to leave
13:49eigood free software
13:49* mael is heading to cambridge, uk
13:49eigood DFSG
13:49aliguori- eigood: nope
13:49eigood mael: riding a pumpkin chucker?
13:49aliguori- but i wouldn't be surprised if you started to see some
13:49eigood uml has been around for a bit; now with uml, we can hope to see a standard emerge
13:50eigood s/with uml/with xen/
13:50aliguori- in the past, there's been no reason to has foss tools for properitary hardware :-)
14:04--- <<-- mael [~mael@kali.tirnamban.org] has quit (Quit: Leaving)
14:07hollis joining the conversation late... how is UML managed?
14:09--- ---> niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
14:12eigood there are some tools for it; we stopped using uml(and switched to xen, yay!) before we started looking at management tools for it
14:13hollis how about creating a UML "domain" (instance? what do you call it?)? starting it, stopping it, provisioning it?
14:13--- ---> alx_ [foobar@213-152-38-2.dsl.eclipse.net.uk] has joined #xen
14:14aliguori- hollis: uml is just a process in linux
14:15aliguori- you run it like a process and pass the configuration for it on the command line
14:15--- <<-- tab [~tab@darwin.snarc.org] has quit (Ping timeout: 480 seconds)
14:15aliguori- i guess you could nice it to do some resource control but i've never tried.
14:16aliguori- uml is kind of strange because it doesn't have a real scheduler. processes within a uml image are scheduled by the hosts scheduler
14:18eigood aliguori-: your wrong
14:18aliguori- eigood: about what?
14:18eigood it not having a scheduler
14:18eigood it's always had one
14:19--- ---> tab [~tab@darwin.snarc.org] has joined #xen
14:20eigood where is space and enter?
14:20caker next to the any key
14:21aliguori- eigood: my understand of uml is that each process in a uml guest is also a process in the host
14:22aliguori- eigood: uml decides which one goes next but the host decides when it goes next
14:22aliguori- so it's not a real scheduler
14:23aliguori- i'm having trouble finding a paper about it
14:23aliguori- i could be wrong
14:23eigood not quite
14:23caker SKAS mode works differently, but it's the same deal -- the host distributes CPU time to UML, and UML uses Linux's scheduler
14:23aliguori- i read the uml papers a few years ago
14:23eigood uml straces everything. so the host can only schedule the host-based process is not STOP'd waiting on uml to do it's magic
14:23eigood then, with skas, things are a bit more complex
14:24caker Jeff recently virtualized the Linux scheduler -> http://user-mode-linux.sourceforge.net/diary.html
14:25aliguori- ah, this is interesting
14:25aliguori- this solves the problem i was alluding to quite nicely
14:25aliguori- that resource control is difficult in uml.
14:26aliguori- i saw that someone is giving a talk at ols about extending uml to run in ring 0 with the vmx extensions
14:32eigood hmm, lots of cool stuff on that diary
16:17--- <<-- N [~ca4bc809@webuser.thegrebs.com] has quit (Quit: http://thegrebs.com/oftc/ (Session timeout))
16:43--- User: *** riel is now known as unriel
16:50--- <<-- niv [~nivedita@bi01p1.co.us.ibm.com] has quit (Quit: Quitting)
17:00--- <<-- deac [~deac@xdsl-81-173-137-130.netcologne.de] has quit (Ping timeout: 480 seconds)
17:04--- <<-- yarihm [~yarihm@80-218-3-32.dclient.hispeed.ch] has quit (Quit: Leaving)
17:12--- ---> deac [~deac@xdsl-84-44-214-81.netcologne.de] has joined #xen
17:26--- <<-- aliguori- [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit (Read error: Operation timed out)
17:28--- <<-- unriel [~riel@nat-pool-bos.redhat.com] has quit (Read error: Operation timed out)
17:36--- ---> yarihm [~yarihm@80-218-3-32.dclient.hispeed.ch] has joined #xen
18:09--- <<-- yarihm [~yarihm@80-218-3-32.dclient.hispeed.ch] has quit (Quit: Leaving)
18:17--- <<-- hollis [~hollis@pixpat.austin.ibm.com] has quit (Quit: leaving)
18:34--- <<-- rharper [~rharper@pixpat.austin.ibm.com] has quit (Quit: Leaving)
18:35--- ---> niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
19:16--- ---> tierra|w_ [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
19:16--- <<-- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit (Read error: Connection reset by peer)
19:17--- User: *** tierra|w_ is now known as tierra
19:21--- <<-- tab [~tab@darwin.snarc.org] has quit (Remote host closed the connection)
19:21--- ---> tab [~tab@81.56.210.228] has joined #xen
19:25--- <<-- niv [~nivedita@bi01p1.co.us.ibm.com] has quit (Quit: Quitting)
19:35--- <<-- tab [~tab@81.56.210.228] has quit (Ping timeout: 480 seconds)
19:40--- ---> tab [~tab@darwin.snarc.org] has joined #xen
20:21--- ---> joink_ [~joink@186.80-202-132.nextgentel.com] has joined #xen
20:23--- <<-- joink [~joink@186.80-202-132.nextgentel.com] has quit (Ping timeout: 480 seconds)
20:34--- <<-- knewt [~jmb@zeus.pimb.org] has quit (Ping timeout: 480 seconds)
20:44--- ---> drbyte [~byte@150.203.247.9] has joined #xen
20:45--- User: *** joink_ is now known as joink
20:55--- ---> hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
21:04--- ---> knewt [~jmb@zeus.pimb.org] has joined #xen
21:07--- <<-- drbyte [~byte@150.203.247.9] has quit (Quit: Leaving)
21:38--- <<-- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit (Quit: leaving)
21:49--- ---> drbyte [~byte@150.203.247.9] has joined #xen
21:50--- <<-- knewt [~jmb@zeus.pimb.org] has quit (Quit: hateful reboot)
21:51--- <<-- drbyte [~byte@150.203.247.9] has quit (Quit: )
21:52--- ---> drbyte [~byte@150.203.247.9] has joined #xen
22:18--- ---> monrad [~monrad@213083190130.sonofon.dk] has joined #xen
22:29--- ---> knewt [~jmb@zeus.pimb.org] has joined #xen
22:32--- <<-- knewt [~jmb@zeus.pimb.org] has quit (Remote host closed the connection)
22:32--- ---> knewt [~jmb@zeus.pimb.org] has joined #xen
22:47--- <<-- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has quit (Quit: Everybody wants to go to heaven, but nobody wants to die.)
22:59--- <--- VS_ChanLog [~stats@ns.theshore.net] has left #xen (Rotating Logs)
22:59--- ---> VS_ChanLog [~stats@ns.theshore.net] has joined #xen
23:01--- ---> cc [~byte@150.203.247.9] has joined #xen
23:08--- <<-- drbyte [~byte@150.203.247.9] has quit (Ping timeout: 480 seconds)
23:31--- ---> itamarjp [lualele@200-225-242-030-dynamic.idial.com.br] has joined #xen
---Logclosed Thu Apr 21 00:00:37 2005