--- Day changed

--- Log opened Mon Apr 25 23:59:02 2005
00:00 -!- jeroney [~jeroney@pixpat.austin.ibm.com] has quit [Ping timeout: 480 seconds]
00:07 < matta> aliguori: how's the next vm-tools version coming along? :)
00:08 < caker> aliguori: I'm using LVM root, yes
00:08 < matta> LVM for dom0 or domU ?
00:08 < caker> aliguori: http://www.theshore.net/~caker/initrd-build.tar.gz, universal initrd for LVM root goodness (dom0)
00:11 < aliguori> matta: lvm for dom0
00:12 < aliguori> caker: oh, thanks, let me give it a try
00:12 < aliguori> matta: good actually, I'm attempting to put out a "preview" release but I'm having trouble testing against the latest xen-unstable :-)
00:19 < aliguori> matta: i've got vm-tools working with -unstable and 2.0.x.. it's missing some a lot of polish and some device support but it's a big step in the right direction
00:19  * caker drools for a replacement for xend
00:20 < caker> http://www.theshore.net/~caker/xen/host27.linode.com-memory-week.png <-- my latest xend memory usage graph
00:21 < aliguori> caker: nuts
00:21 < caker> I'd move to -unstable, but at the moment it's too ... unstable
00:21 < aliguori> caker: what features of xend do you use?
00:22 < aliguori> what would vm-tools need to do (under 2.0.x) for you to switch?
00:22 < caker> aliguori: that causes the memory increase?  I poll xm info ..
00:22 -!- matta-lt [~matta@69.93.28.254] has joined #xen
00:22 < caker> aliguori: ahh -- just the basics, plus bvt tweaking and suspend
00:23 < aliguori> yeah, that's what i figure most users need.
00:23 < aliguori> caker: how much bvt tweaking do you do?
00:23 -!- schweeb [~chris@schweeb.org] has quit [Read error: Connection reset by peer]
00:23 -!- schweeb [~chris@schweeb.org] has joined #xen
00:24 < aliguori> we've been discussing internally how much to expose for modifying scheduler parameters..  i didn't think most people would do much more than adjust a simply weighting
00:24 < caker> aliguori: none, currently but was hoping to mess with it
00:24 < aliguori> ahh :-)
00:24 < matta> aliguori: I just use the very basics
00:24 < caker> aliguori: that's all I'm after .. basic weight tweaking
00:24 < matta> create, destroy, shutdown, list, info
00:25 < matta-lt> caker: you can read the lists, BVT tuning has came up many oftimes.
00:25 < aliguori> the cambridge guys are working on yet another scheduler
00:25 < matta-lt> it is the replacement for atropos right?
00:25 < matta-lt> i forget the name
00:26 < matta-lt> I think BVT works very well actually
00:26 < aliguori> i'd rather not have to explain how to tweak 3 different schedulers in the docs
00:26 < matta-lt> you just need to understand how it's arcaic settings are and what should be what
00:26 < aliguori> matta-lt: i thought it was a replaced for both atropos and bvt.. honestly, i don't know why you need atropos with a proper bvt scheduler
00:26 < matta-lt> aliguori: RR is easy, i'm pretty suring atropos is going away
00:26 < aliguori> bvt can do, at least the original paper claims, soft real time scheduling
00:26 < matta-lt> yeah
00:27 < aliguori> matta-lt: I don't consider RR to even be a choice :-)
00:27 < matta-lt> using my tuned BVT scheduler I can say nothing bad about it.
00:27 < aliguori> i don't know why it hasn't been removed
00:27 < matta-lt> it's for demonstration only
00:27 < matta-lt> sort of like a template on which to build on...
00:28 < matta-lt> Xen's QoS has really impressed me
00:28 < matta-lt> i've used Virtuozzo which is a commercial VM-type software
00:28 < matta-lt> whivch touts all kinds of QoS
00:28 < aliguori> matta-lt: QoS is what a hypervisor should be all about :-)
00:28 < matta-lt> and on my test server here .. i'd say xen handles more demanding loads gracefully
00:29 < matta-lt> that is tuning a lot though
00:29 < matta-lt> lots of benchmarks to see what performs best
00:29  * caker mumbles something about needing disk QoS
00:29 -!- sunny [sunny@opencurve.org] has joined #xen
00:29 -!- drbyte [~byte@intern146.lnk.telstra.net] has joined #xen
00:29 < matta-lt> caker: disk QoS works fine
00:29 < matta-lt> if anything setting separate priorities fro each VM rather than round robin would be nice
00:29 < aliguori> I'm quite impressed with BVT.. I think it works well.. I understand the new scheduler is more smp aware though
00:30 < matta-lt> but it's still way better than the disk I/O scheduler in virtuozzo
00:30 < matta-lt> that was where it lagged
00:30 < matta-lt> as far as CPU QoS Virtuozzo was definitely as good as xen
00:30 < caker> matta-lt: so what do you guys do why a node is thrashing like made without any ability compensate?
00:30 < caker> *mad
00:30 < aliguori> matta-lt: i think hardware is going to be the answer for I/O scheduling.. there's a lot of interesting IO virtualization hardware on the horizon
00:31 < matta-lt> have a disk sub-system that is capable of 100MB/s+ helps
00:31 -!- schweeb [~chris@schweeb.org] has quit [Read error: Operation timed out]
00:32 -!- schweeb [~chris@schweeb.org] has joined #xen
00:32 < matta-lt> aliguori: well, the linux kernels disk I/O schedulers seem to be useful
00:33 < matta-lt> caker: i can't really explain it... we have tons of VM's that are swapping like mad
00:33 < caker> hmm
00:33 < caker> matta-lt: and you just use LVM partitions fed into the domU's right?
00:33 < caker> matta-lt: how much memory to you allocate to dom0?
00:33 < matta-lt> most hosts run at a constant 5MB/s in and/r ut
00:33 < aliguori> matta-lt: do you have hyperthreading enabled?
00:34 < matta-lt> aliguori: I use Opteron's
00:34 < aliguori> oh
00:34 < aliguori> matta-lt: have you tried x86_64 yet? :-)
00:34 < matta-lt> aliguori: no.... am definitely looking forwar to it
00:35 < matta-lt> I guess you IBM guys ae pretty dead set on making sure 32-bit domU's run on a 64-bit xen
00:35 < aliguori> uh...  we've certainly discussed it :-)
00:35 < aliguori> there are some other core things that are probably more important though
00:35 < matta-lt> and that was my only thing I wanted, I just want xen 64-bit so I can address >4GB RAM
00:35 < aliguori> like pae
00:36 < matta-lt> aliguori: it was on a doc one of the ibm people sent out
00:36 < matta-lt> the IBM internal requirements or something
00:36 < matta-lt> yeah, PAE might even work out
00:36 < matta-lt> esp if it gets pushed into 2.x
00:36 < matta-lt> PAE has always been a hack though
00:36 < matta-lt> for xen it should work fine though
00:36 < aliguori> matta-lt: oh, mike day's requirements.. those actually weren't just ibm requirements.. the idea was for all the companies involved in xen to get together to develop common requirements
00:37 < matta-lt> my experience with8-16GB RAM ssytems was for oraclesevers
00:37 < aliguori> there was actually an initial requirements doc created by HP I believe a few months ago
00:37 < matta-lt> and PAE each process can only address 4GB RAM
00:37 < matta-lt> er, each process run on a system where PAE is enabled is better
00:38 < aliguori> well, as many have pointed out, there's a ton of PAE hardware out there
00:38 < aliguori> so it's one of those ugly requirements :-/
00:38 < matta-lt> yeah
00:38 < matta-lt> and for xen it would work out
00:38 < matta-lt> my largest VM's are only 512MB
00:38 < matta-lt> so evenif there was a requirement that each VM was limited to 4GB
00:38 < matta-lt> since in xen sense a domain is "sort of" like a process
00:39 < aliguori> initial pae support is going to probably require all domUs to be PAE aware
00:39 < matta-lt> oh
00:39 < aliguori> that kind of sucks, but it's a start
00:40 < aliguori> ideally, you want to shadow the guests so that if a domU uses < 4GB of memory, it doesn't have to be pae aware
00:40 < matta-lt> you'd like it to be less intrusive code?
00:40 < aliguori> well, it sucks to turn on pae if you don't actually use it
00:40 < matta-lt> oh
00:40 < matta-lt> i see
00:40 < matta-lt> so in the kernel config
00:40 < aliguori> yeah
00:40 < matta-lt> each would have to be set to 16GB or higher 
00:41 < matta-lt> for it's memory limit setting
00:41 < matta-lt> that doesn't sound too bad, having to change the source of the xenU kernel sucks since it is more to keep in sync with the linux kernel releases
00:42 < matta-lt> hrm, but I guess PAE support would reside entirely in arch
00:42 < aliguori> eh
00:42 < aliguori> xen doesn't separate arch stuff very well
00:42 < aliguori> pae support requires changes in arch, but then also changes in a bunch of the userspace stuff
00:43 < matta-lt> aliguori: how is vm-tools using the cpu_weight variable in the config files?
00:43 < matta-lt> same method?
00:43 < aliguori> matta-lt: as xend, yes
00:43 < aliguori> but that's changing.
00:43 < aliguori> :-)
00:43 < matta-lt> I have been maintaining my own patch...
00:44 < aliguori> yeah, unfortunately, we can't take patches... stupid lawyers.
00:44 < matta-lt> it's a very minor, perhaps just me
00:44 < aliguori> hopefully, we'll work things out and get vm-tools into the xen tree
00:44 < matta-lt> but I changed where CPU weight is calculated by the value / 10
00:44 < matta-lt> I canged 10 to 1000
00:44 < aliguori> huh
00:44 < matta-lt> when / 10 only values 1-10 are actually useful
00:44 < aliguori> i didn't even know it did that at all
00:45  * aliguori looks in cvs
00:45 < matta-lt> and the xm bvt command will only let you go as 'low' as 0
00:45 < matta-lt> whereas a weight of let's say 20
00:45 < matta-lt> would be bvt .5
00:45 < matta-lt> equiv in dom0
00:45 < matta-lt> and you always want dom0 to not be starved as it maintains the disks and network
00:46 < aliguori> oh, see, i don't think weight is the best thing for bvt
00:46 < aliguori> b/c you really want to assign two values
00:46 < matta-lt> well, that's what it is....
00:46 < aliguori> weight, and then responsiveness i guess
00:46 < matta-lt> that's why it warp
00:47 < aliguori> yeah
00:47 < matta-lt> tuning warp and it's vales are important
00:47 < matta-lt> as i've found
00:47 < aliguori> yup
00:47 < matta-lt> perhaps stuff like that is why I think Xen QoS rocks
00:47 < aliguori> :-)
00:47 < matta-lt> it took a lot of research to figure out what the hell those values all mean
00:48 < aliguori> yeah, xen is still in the early adopter phase :-)
00:48 < matta-lt> anyhow, changing to 1000 vs 10 basically makes values of 0 - 1000 useable
00:48 < aliguori> sure, makes sense
00:48 < matta-lt> and means you can give dom0 max weight with 0
00:49 < matta-lt> hrm, maybe that is 0-100 usable
00:49 < aliguori> i hope they put more info out about the new scheduler
00:49 < aliguori> let me try this initrd, brb
00:49 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Quit: Leaving]
00:53 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
00:53 < aliguori> :-/ no dice
00:54 < caker> aliguori: you tweaked the grub variables?
00:54 < caker> aliguori: you might need to make some dev nodes inside the initrd .. I think it currently only has hd*
00:54 < aliguori> stupid user error.. wrong kernel config
00:55 < aliguori> ramdisk too small.. xen's default config is pretty crappy
00:55 < caker> ahh
00:56 < aliguori> i have my own config but apparently i didn't cp it over after doing an mrproper
00:56 < caker> add ramdisk_size=10240 to your xeno module line
00:57 < caker> module /vmlinuz-testing root=/dev/ram0 lvm2root=/dev/vg1/root elevator=cfq ramdisk_size=10240
00:57 < aliguori> caker: i need to compile in support for my hardware anyway
00:57 < caker> for example
00:57 < aliguori> otherwise i'm gonna be using pio :-)
00:57 < caker> nod
00:57 < aliguori> which i don't really want :-)
00:57 < aliguori> caker: so do you use lvm for dom0?
00:57 < caker> aliguori: yup
00:57 < aliguori> i've been really happy with this setup.. i just wish i could get rid of the boot partition
00:58 < matta-lt> i don't quite see the benefit of LVM for dom0
00:58 < matta-lt> my dom0's are braindead... I just give 10GB and some swap and they're fine
00:58 < matta-lt> and use LVM for domU's
00:58 < aliguori> matta-lt: i have multiple dom0's that i develop on.. i've had to resize a few times already
00:59 < matta-lt> ahh....
00:59 < matta-lt> yeah, for development that makes sense
00:59 < aliguori> in production, yeah, i probably wouldn't use lvm for dom0
00:59 -!- lilo [~lilo@lilo.usercloak.oftc.net] has quit [Quit: brb]
01:02 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Quit: rebooting]
01:02 -!- sunny [sunny@opencurve.org] has quit [Quit: pop]
01:06 < rusty> aliguori: good
01:11 -!- tierra [~tierra@c-24-10-173-249.hsd1.ut.comcast.net] has joined #xen
01:32 -!- lilo [~lilo@lilo.usercloak.oftc.net] has joined #xen
01:46 -!- Hunger [Hunger.hu@Hunger.hu] has joined #xen
01:46 < Hunger> hi
02:05 -!- drbyte [~byte@intern146.lnk.telstra.net] has quit [Ping timeout: 480 seconds]
02:07 -!- drbyte [~byte@intern146.lnk.telstra.net] has joined #xen
02:14 -!- cdub [~chrisw@cdub.netrep.oftc.net] has quit [Ping timeout: 480 seconds]
03:25 -!- Tv [~Tv@hq.inoi.fi] has quit [Ping timeout: 480 seconds]
03:28 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has quit [Read error: Connection reset by peer]
03:34 -!- DEac- [~deac@xdsl-213-196-200-241.netcologne.de] has quit [Ping timeout: 480 seconds]
03:35 -!- tierra [~tierra@c-24-10-173-249.hsd1.ut.comcast.net] has quit [Ping timeout: 480 seconds]
03:36 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Client exiting]
03:46 -!- tierra [~tierra@c-24-10-173-249.hsd1.ut.comcast.net] has joined #xen
03:46 -!- DEac- [~deac@xdsl-213-196-202-21.netcologne.de] has joined #xen
04:04 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has joined #xen
04:11 < mael> hi
04:20 -!- sunny [sunny@opencurve.org] has joined #xen
04:39 -!- athomas [~athomas@ppp-0-20.lond-b-2.access.uk.tiscali.com] has joined #xen
04:43 -!- Robot101_ is now known as Robot101
05:29 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has joined #xen
05:30 -!- monrad [~monrad@213083190130.sonofon.dk] has joined #xen
05:40 -!- tierra [~tierra@c-24-10-173-249.hsd1.ut.comcast.net] has quit [Quit: Don't hate yourself in the morning -- sleep til noon.]
05:57 -!- monrad [~monrad@213083190130.sonofon.dk] has quit [Quit: Leaving]
06:01 -!- Tv [~Tv@hq.inoi.fi] has joined #xen
06:25 -!- drbyte [~byte@intern146.lnk.telstra.net] has quit [Ping timeout: 480 seconds]
07:08 -!- drbyte [~byte@intern146.lnk.telstra.net] has joined #xen
07:28 -!- DEac- [~deac@xdsl-213-196-202-21.netcologne.de] has quit [uranium.oftc.net arion.oftc.net]
07:28 -!- matta-lt [~matta@69.93.28.254] has quit [uranium.oftc.net arion.oftc.net]
07:28 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has quit [uranium.oftc.net arion.oftc.net]
07:28 -!- eigood [~adam@brown.brainfood.com] has quit [uranium.oftc.net arion.oftc.net]
07:28 -!- muli [~muli@alhambra.mulix.org] has quit [uranium.oftc.net arion.oftc.net]
07:28 -!- joink [~joink@186.80-202-132.nextgentel.com] has quit [uranium.oftc.net arion.oftc.net]
07:28 -!- paavon [paavon@alpha.phnet.fi] has quit [uranium.oftc.net arion.oftc.net]
07:28 -!- knewt [~jmb@zeus.pimb.org] has quit [uranium.oftc.net arion.oftc.net]
07:28 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.hsd1.tx.comcast.net] has quit [uranium.oftc.net arion.oftc.net]
07:33 -!- DEac- [~deac@xdsl-213-196-202-21.netcologne.de] has joined #xen
07:33 -!- matta-lt [~matta@69.93.28.254] has joined #xen
07:33 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has joined #xen
07:33 -!- eigood [~adam@brown.brainfood.com] has joined #xen
07:33 -!- muli [~muli@alhambra.mulix.org] has joined #xen
07:33 -!- Sir_Ahzz [~ahzz@c-24-0-215-3.hsd1.tx.comcast.net] has joined #xen
07:33 -!- knewt [~jmb@zeus.pimb.org] has joined #xen
07:33 -!- paavon [paavon@alpha.phnet.fi] has joined #xen
07:33 -!- joink [~joink@186.80-202-132.nextgentel.com] has joined #xen
07:33 -!- mode/#xen [+o Sir_Ahzz   ] by arion.oftc.net
08:35 -!- drbyte [~byte@intern146.lnk.telstra.net] has quit [Ping timeout: 480 seconds]
08:35 -!- amr [~d0ea01e1@64.132.135.17] has joined #xen
08:37 < amr> I'm setting up xen for the first time, and would like to get some feedback on the configuration of domain 0. Does domain 0 use the "root" filesystem on which the kernel is installed, or does a separate partiton have to be established for domain 0 and added to the configuration file?
08:40 < demon> no, domain 0 will use the root filesystem you already have set up
08:42 < demon> it's the first domain that's booted by the xen hyperkernel
08:51 < amr> thanks for confirming that.
09:30 -!- surriel is now known as riel
09:33 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
09:55 -!- rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
10:23 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
10:44 -!- hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
10:45 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has joined #xen
11:04 < Sir_Ahzz> mmmm.
11:19 -!- cfreak [cfreak@dsl-084-056-097-070.arcor-ip.net] has joined #xen
11:26 -!- monrad [~monrad@213083190130.sonofon.dk] has joined #xen
11:52 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has quit [Remote host closed the connection]
12:08 -!- yarihm [~yarihm@80-218-1-49.dclient.hispeed.ch] has joined #xen
12:10 -!- matta-lt [~matta@69.93.28.254] has quit [Quit: Apples  have  meant  trouble  since  eden.]
12:53 -!- athomas [~athomas@ppp-0-20.lond-b-2.access.uk.tiscali.com] has quit [Quit: Leaving]
13:01 -!- nDuff [~cduffy@64.128.31.220] has joined #xen
13:35 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has left #xen [Zneet Znatter Zneet]
13:46 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
13:52 -!- amr [~d0ea01e1@64.132.135.17] has quit [Quit: CGI:IRC 0.5.4 (2004/01/29)]
14:14 -!- Arnald [~Arnald@81-86-116-102.dsl.pipex.com] has joined #xen
15:08 < rharper> riel: did you ever track down which changeset caused that guest oops you posted about?  
15:09 < rharper> I have a nightly from the 21st that still works, so something between 21st and 24th 
15:10 < riel> rharper: haven't found it yet
15:10 < rharper> I don't have bk, and I didnt grab any snapshots over the weekend =(
15:10  * rharper adds that to his crontab 
15:27 < riel> mmm, so the 21st works
15:27 < riel> typical
15:28  * riel always seems to grab the non-working snapshots ;)
15:30 < rharper> you can get a nightly from the 23th, here http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads/xen-unstable-src.3.tgz
15:30 < rharper> I'm trying that one out right now 
15:31 -!- aliguori-work [~anthony@pixpat.austin.ibm.com] has joined #xen
15:35 < niv> rharper: please let me know if that works for you..
15:36 < rharper> niv: 23rd is still hosed 
15:36 < rharper> so, something commited on the 22nd 
15:38 < aliguori-work> is anyone using the most recent xen-unstable?
15:38 < aliguori-work> from last night?
15:39 < aliguori-work> i can no longer boot with lvm...
15:39 < rharper> aliguori-work: no, been talking about that
15:39 < rharper> last working snapshot for me is from the 21st 
15:39 < rharper> aliguori-work: more specifically,I can boot dom0, but domU creation fails 
15:39 < aliguori-work> rharper: where does it fail for you?
15:39 < aliguori-work> oh, i get hung up loading a module in my initrd.
15:40 -!- aliguori-work is now known as aliguori
15:40 < rharper> that may be something else 
15:40 < rharper> I dont use initrd 
15:40 < aliguori> i've used the same process to build the initrd for a long time now
15:40 < aliguori> and i've checked myself a half a dozen times...
15:40 < aliguori> so i'm reasonable sure it's not a stupid-user thing
15:41 < rharper> sure, I can push the nightly from the 21st to you if you want to check that 
15:42 < riel> aliguori: initrd + lvm works fine in the snapshot from sunday night
15:42 < aliguori> riel: lvm dom0?
15:42 < niv> rharper: thanks. grrrr...
15:42 < rharper> niv: np 
15:44 < riel> aliguori: yes
15:44 < aliguori> hmmm, maybe it's a devfs issue.
15:50 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has quit [Read error: Connection reset by peer]
15:51 -!- jeroney [~jeroney@pixpat.austin.ibm.com] has joined #xen
15:51 < caker> aliguori: that initrd work out for you?
15:54 < riel> aliguori: devfs?  what distro are you using ? ;)
15:54 < riel> udev seems to work fine
15:54 < aliguori> caker: nope
15:54 < aliguori> riel: gentoo
15:55 < aliguori> and it's a major pain-in-the-*ss
15:56 -!- cfreak [cfreak@dsl-084-056-097-070.arcor-ip.net] has quit [Quit: .]
15:56 < riel> ohhh I have an idea
15:56 < riel> I can catch when xend tries to map a bad page through the ioctl
15:57 < aliguori> riel: you could also just modify the xc.c bindings
15:57 < aliguori> that would be a heck of a lot easier :-)
16:03 < riel> xc_private.c ?
16:03 < aliguori> you could do that too
16:04 < aliguori> but i'd modify tools/python/xen/lowlevel/xc/xc.c
16:08 -!- yarihm [~yarihm@80-218-1-49.dclient.hispeed.ch] has quit [Ping timeout: 480 seconds]
16:08 < aliguori> riel: oh f, now it's in xcs :-)
16:09 -!- DEac- [~deac@xdsl-213-196-202-21.netcologne.de] has quit [Ping timeout: 480 seconds]
16:13 -!- Shaun [~ndci@ip68-111-70-41.oc.oc.cox.net] has joined #xen
16:14 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has joined #xen
16:20 -!- DEac- [~deac@xdsl-84-44-147-116.netcologne.de] has joined #xen
16:21 < aliguori> hmm, so it actually freezes trying to load a USB driver
16:21 < aliguori> interesting
16:22 < riel> thing is - how can I know from inside userspace what is and isn't a page inside our own domain ?
16:23 < aliguori> riel: modifying the ioctl is probably the simplier approach i guess
16:23 < riel> *nod*
16:23 < riel> I can just call page_valid or pfn_valid from inside the ioctl code ;)
16:24 < riel> and for FC4t3 I might code up an munmap workaround ;)
16:27 -!- tierra [~tierra@dsl093-225-126.slc1.dsl.speakeasy.net] has joined #xen
16:43 < jeroney> riel: we just learned about a new command "dmidecode" that gives info on the machine..out of the pure nature of curiocity do you have  fedoar domU up could you try running this command?
16:44 < jeroney> fedoar == fedora
16:44 < jeroney> riel: I would be machines are in bad development state really curious about this .. figured you would have a system with fedora domU just sitting around
16:46 < jeroney> riel: nevermind
16:46 < jeroney> rile: figured out what the program does ... it wouldn't work anyway
16:46 < riel> hehe
16:51 < nDuff> Is mlock() known to have issues on XenLinux? (OpenVPN is failing to initialize w/ the --mlock option enabled).
16:52 < riel> nDuff: no, there are no differences between xen and non-xen when it comes to mlock
16:58 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Remote host closed the connection]
17:02 < xai> Does anyone have a bare-metal rhel4 or fedora root filesystem available for dl?
17:03 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
18:14 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has quit [Quit: Client exiting]
18:18 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Quit: Leaving]
18:25 -!- jeroney [~jeroney@pixpat.austin.ibm.com] has quit [Quit: Leaving]
18:26 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [Quit: leaving]
19:22 -!- rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
19:32 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Quit: Quitting]
19:38 -!- nDuff [~cduffy@64.128.31.220] has quit [Remote host closed the connection]
19:45 -!- drbyte [~byte@intern146.lnk.telstra.net] has joined #xen
20:24 -!- sunny [sunny@opencurve.org] has quit [Quit: client restart]
20:24 -!- sunny [sunny@opencurve.org] has joined #xen
20:24 -!- sunny [sunny@opencurve.org] has quit [Quit: ]
20:25 -!- sunny [sunny@opencurve.org] has joined #xen
20:45 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
23:38 -!- drbyte [~byte@intern146.lnk.telstra.net] has quit [Ping timeout: 480 seconds]
--- Log closed Tue Apr 26 23:59:00 2005