--- Day changed

--- Log opened Wed May 25 23:59:02 2005
00:15 -!- tessier [~treed@222.253.77.23] has quit [Read error: Connection reset by peer]
00:34 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
01:07 -!- tessier [~treed@222.253.77.38] has joined #xen
01:08 < tessier> http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_7044,00.html
01:08 < tessier> Sweet!
01:08 < tessier> AMD's "Pacifica" docs.
01:24 -!- tessier_ [~treed@222.253.81.17] has joined #xen
02:58 -!- franR [~franr@82.239.212.117] has joined #xen
03:11 -!- DEac- [~deac@xdsl-213-196-200-205.netcologne.de] has quit [Ping timeout: 480 seconds]
03:16 -!- lilo [~lilo@lilo.usercloak.oftc.net] has quit [Remote host closed the connection]
03:20 -!- Shaun [ndci@68.111.70.41] has joined #xen
03:22 < tessier> Man...I am still completely unable to join the xen mailing lists.
03:22 < tessier> I never get the confirmation message.
03:22 -!- DEac- [~deac@xdsl-81-173-138-233.netcologne.de] has joined #xen
03:25 -!- lilo [~lilo@lilo.usercloak.oftc.net] has joined #xen
03:48 -!- tessier_ [~treed@222.253.81.17] has quit [Read error: Connection reset by peer]
04:04 -!- tessier_ [~treed@203.210.217.15] has joined #xen
04:13 < knewt> tessier_: do you have control over your email server? if not, maybe it's blocking the confirmation emails?
04:15 < tessier> I do have control. There is nothing in the config of my mail server that would block the emails. I do run spamassassin but I have checked the junk folder quite thoroughly.
04:24 < murble> moin
05:10 -!- athomas [~athomas@ppp-0-108.lond-b-3.access.uk.tiscali.com] has joined #xen
05:13 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has joined #xen
05:51 -!- Beaky [~chatzilla@ncg-adsl.demon.co.uk] has quit [Remote host closed the connection]
05:52 -!- muli [~muli@192.114.107.4] has joined #xen
05:53 -!- Beaky [~chatzilla@80.176.209.89] has joined #xen
06:19 -!- rusty [~rusty@ppp60-148.lns1.cbr1.internode.on.net] has joined #xen
06:31 -!- slow [slow2burn@h07.org] has joined #xen
06:31 < slow> hi
06:34 -!- doremifa [~bun@219.206.220.72] has joined #xen
06:50 -!- JViz [Anomaly@cpe-065-190-033-248.triad.res.rr.com] has quit [Ping timeout: 480 seconds]
07:06 -!- rusty [~rusty@ppp60-148.lns1.cbr1.internode.on.net] has quit [Quit: Client exiting]
07:24 -!- surriel [~riel@imladris.surriel.com] has quit [Ping timeout: 480 seconds]
07:38 -!- athomas [~athomas@ppp-0-108.lond-b-3.access.uk.tiscali.com] has quit [Read error: Connection reset by peer]
07:53 -!- athomas [~athomas@ppp-0-35.lond-b-4.access.uk.tiscali.com] has joined #xen
08:21 -!- jbailey [~jbailey@CPE000ded9d787c-CM014260028338.cpe.net.cable.rogers.com] has left #xen [Leaving]
08:43 -!- JViz [Anomaly@cpe-065-190-033-248.triad.res.rr.com] has joined #xen
08:59 < tessier_> Anyone here attend the nylug meeting last night?
09:00 < mael> nope
09:00 < mael> I wanted to go there but decided it was to far away at the last moment
09:25 -!- surriel [~riel@imladris.surriel.com] has joined #xen
09:28 < tessier_> hmm
09:29 < tessier_> What are the chances of Xen eventually evolving to the point where it constantly copies dirtied pages over to another node and some sort of heartbeat mechanism can make the second node live if the first one dies?
09:29 < tessier_> Sort of a stateful failover? Would be great for HA
09:30 < mael> tessier:  you'll have to ask for it
09:30 < tessier_> Not sure how possible that is without explicit hardware support.
09:30 < tessier_> I mean, you've got to lose some data I would think.
09:30 < mael> but I spoke with Keir Frazer and James Bulpin about that and they thought it would be technically possible
09:30 < tessier_> wow
09:31 < tessier_> I am director of software development at a small VOIP company and we could really use something like that for HA reasons.
09:31 < mael> implementation is left to the good will of the reader :)
09:31 < tessier_> Indeed. :)
09:31 < tessier_> All of the virtualization stuff makes me think of big iron and reliability.
09:32 < mael> but it would be really costly in terms of ressources
09:32 < tessier_> How so?
09:32 < mael> look at the migration stuff
09:32 < mael> this is the same thing you're thinking of
09:32 < tessier_> Right
09:32 < tessier_> What kind of resources are you talking about?
09:33 < mael> machine ressources
09:33 < tessier_> obviously...cpu? ram? network?
09:33 < mael> cpu cycles, network
09:34 < mael> look at the VM perfs while doing a migration
09:34 < mael> response time is altered
09:34 < mael> this is probably a problem for voip and embedded hardware
09:34 < tessier_> Yes but the part to look at is vm perf right at the end of a migration just before the actual switchover
09:34 < tessier_> Not a problem for voip
09:34 < tessier_> Worst thing that happens is you drop some packets.
09:34 < tessier_> The caller might hear a blurp in the sound but that is better than dropping the call or being down completely
09:35 < tessier_> And really, the packets don't usually go through our machines
09:35 < tessier_> They go phone to phone
09:36 < tessier_> Only the SIP signalling goes through us. That's only a few dozen packets for the entire phone conversation.
09:36 < mael> ok
09:36 < tessier_> So the only place that might affect us is on our rtp proxy which only handles a small percentage of callers.
09:36 < tessier_> But for everything else, sip proxies, databases, etc. it could be a big win.
09:37 < mael> it could
09:37 < tessier_> If the system were really smart it would look at how much memory and cpu a node was using and have the most appropriate backup node targeted for it and would be able to change this dynamically.
09:37 < mael> but think about scalability then...
09:39 < tessier_> As long as it does not require any more than 2x nodes to make everything redundant in this way, we wouldn't mind.
09:41 < mael> yeah probably in your particular situation
09:41 < mael> as you are a small business as you told me
09:42 < mael> and this solution will be also useful as a HA node in a bigger design
09:44 -!- unriel is now known as riel
09:52 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has joined #xen
10:43 -!- rharper [~rharper@192.35.232.241] has joined #xen
11:12 -!- knewt_ [~jmb@p213.54.73.173.tisdip.tiscali.de] has joined #xen
11:18 -!- knewt [~jmb@p213.54.77.37.tisdip.tiscali.de] has quit [Ping timeout: 480 seconds]
11:38 -!- hollis [~hollis@user-0vvde2g.cable.mindspring.com] has quit [Quit: leaving]
11:51 -!- Beaky [~chatzilla@80.176.209.89] has quit [Remote host closed the connection]
12:02 -!- hollis [~hollis@pixpat.austin.ibm.com] has joined #xen
12:14 -!- Tv [~Tv@hq.inoi.fi] has joined #xen
12:15 -!- aliguori [~anthony@pixpat.austin.ibm.com] has joined #xen
12:59 -!- antonio [~tony@216-99-217-196.dsl.aracnet.com] has joined #xen
13:03 < antonio> Is there some odd interaction between rebooting a domain and 'xm list'?  Whenever I reboot domain-1 it halts down to "Restarting system" and then sits there until on another window I run 'xm list' which after a second kicks off the reboot.   I have restart=onreboot.
13:03 -!- athomas [~athomas@ppp-0-35.lond-b-4.access.uk.tiscali.com] has quit [Quit: Leaving]
13:17 < demon> are you using 2.0.5, 2.0-testing or unstable?
13:17 < tab> 2.0-testing -> 2.0.6
13:19 < demon> well, it will _become_ 2.0.6, but it's not yet
13:21 < tab> 2.0.6 is out since this weekend
13:23 -!- yarihm [~yarihm@217-162-112-55.dclient.hispeed.ch] has joined #xen
13:36 < antonio> demon, was this Q for me?  I'm using whatever is in FC4 (2.6.11-1.1319_FC4xen0)
13:37 < antonio> I've had the same issue ever since I installed FC4,  I was hoping a couple of yum upgrades would suck in a fix but as of the latest, it still has the same issue
13:42  * demon pulls up the xen site
13:42 < demon> ... whoa, guess I'm a bit behind the times
13:43 < aliguori> demon: that's a problem that's been recently fixed
13:43 < demon> so is it currently recommended to use 2.0.6 or -testing? I know there were a bunch of blkdev performance enhancements in -testing
13:44 < aliguori> demon: i reckon it's fixed in the -testing branch but i only know for certain that it's fixed in the -unstable
13:49 -!- chrish01 [~chrish01@70.183.17.66] has joined #xen
13:53 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
14:00 -!- doremifa [~bun@219.206.220.72] has quit [Remote host closed the connection]
14:38 -!- chrish01 [~chrish01@70.183.17.66] has quit [Quit: Leaving]
14:45 -!- schweeb [~chris@schweeb.org] has joined #xen
14:46 -!- antonio [~tony@216-99-217-196.dsl.aracnet.com] has quit [Remote host closed the connection]
15:08 -!- franR [~franr@82.239.212.117] has quit [Quit: Error inopinée -10s, -9, -8...    Unexpected error -10s, -9, -8,... Really ?]
15:08 -!- tim_ [~tim@cpe-66-67-139-238.rochester.res.rr.com] has quit [Read error: Connection reset by peer]
15:22 -!- chrish01 [~chrish01@wsip-70-183-17-66.oc.oc.cox.net] has joined #xen
16:02 < chrish01> when is 3.0 the target for 3.0?
16:03 -!- DEac- [~deac@xdsl-81-173-138-233.netcologne.de] has quit [Ping timeout: 480 seconds]
16:11 < riel> chrish01: 3.0 has always been the 3.0 target
16:11 < riel> chrish01: or is that not what you wanted to know ? ;)
16:15 -!- DEac- [~deac@xdsl-213-196-200-46.netcologne.de] has joined #xen
16:45 -!- Tv [~Tv@hq.inoi.fi] has quit [Ping timeout: 480 seconds]
16:51 -!- nextime [~nextime@213-140-6-96.fastres.net] has quit [Ping timeout: 480 seconds]
16:51 -!- aliguori [~anthony@pixpat.austin.ibm.com] has quit [Ping timeout: 480 seconds]
16:52 < chrish01> oh wow, i should really retype the whole sentence =/
16:52 < chrish01> riel, when is the data for 3.0
16:54 < riel> dunno, when it's ready ;)
16:54 < riel> I think the feature freeze is planned for july
16:54 < riel> it'll probably take a few months to stabilize after that
16:56 < chrish01> ok, that sounds good
16:56 < jonmason> and then a few more months for redhat to polish it ;-)
16:56 < chrish01> im contemplating the benefits of using amd64 for getting more memory
16:56 < chrish01> cause we will very likely run into 4gb wall often
16:57 < chrish01> i wouldnt dream of deploying on redhat =/
16:57 < jonmason> x86-64 is still very unstable, but alot of people are working on it
16:58 < chrish01> it comes down to weighing the benefits of the additional memory over the disadvantages of 64bit cpu
16:58 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has joined #xen
16:58 < jonmason> give it a few more months
16:58 < jonmason> what are the disadvantages?
16:59 < chrish01> this runs commercial software which doesnt run on 64bit. which means chroot. so does the advantages of more memory outweight the extra cost and such of 64bit
16:59 < chrish01> without even getting the speed advantages of 64bit
17:01 < chrish01> if anyone is interested, i should have this functionally ready to release code tomorrow. what you dont see is the tabs with console and domain info which should be done today. http://people.mosaix.net/chris/images/xenmanager/
17:01 < jonmason> sounds like you have a very specific problem
17:01 < chrish01> nod
17:01 < chrish01> will have drag'n'drop migration and such
17:01 < jonmason> it's pretty
17:02 < chrish01> ah thanks
17:02 < aliguori> chrish01: are you going to use vte?
17:02 < aliguori> for the terminal?
17:02 < chrish01> aliguori, i am now, but i understand that vte doesnt work on win32
17:02 < aliguori> b/c the python bindings for it are pretty borked on most platforms
17:02 < aliguori> probably.. i wouldn't imagine that's a huge problem though
17:03 < chrish01> and ive made sure that i only use gtk widgets so that other os's might work
17:03 < chrish01> obviously im targeting linux though
17:03 < yosh> aliguori: huh, how are they borked?
17:04 < aliguori> yosh: trying running python and doing an "import vte"
17:04 < chrish01> i know vte doesnt even exist on win32 for example
17:04 < yosh> aliguori: been fixed for a while (I fixed it myself)
17:04 < yosh> aliguori: distros that drag their feet wrt updates is another matter
17:05 < chrish01> right now im just using the http xend api. i would like to in a later release support ssh port forwarding.
17:05 < aliguori> yosh: fedora core 3 doesn't have the fix and my gentoo systems don't either.. i've found a reasonable workaround is making a symlink to vte.so as _vte.so
17:05 < aliguori> and doing an import _vte as vte
17:05 < yosh> aliguori: they suck then
17:05 < yosh> surprising gentoo doesn't ship something more recent
17:05 < chrish01> also would like to consider using snmp to get cpu info for a gnome-system-monitor like cpu usage widget
17:05 < aliguori> yosh: what version of vte updated their bindings?
17:05 < yosh> or patch the two-lines that it entails
17:06 < chrish01> yosh, you know if debian is updated with the patch?
17:06 < yosh> 0.11.3
17:06 < aliguori> yosh: really?  because i have 0.11.11 installed
17:06 < yosh> chrish01: it works on debian, they patched it themselves for a while, even before upstream fixes
17:06 < chrish01> ah ok
17:06 < yosh> aliguori: I meant to type 0.11.13
17:06 < aliguori> and with python 2.3.4 it still doesn't work
17:06 < aliguori> oh, ok
17:06 < aliguori> :-)
17:07 < yosh> so, hooray for distro people not doing real QA and being laggards
17:07 < chrish01> this is my first python project, so trying to learn how to do things the py way can slow me down
17:08 < aliguori> yosh: yeah, it's obvious they have no regressions at all for pyvte..
17:25 < chrish01> is there a standard that people use for filenames when they save a xen domain to file?
17:25 < chrish01> id like to use that in the save dialog
17:25 < chrish01> as well as registering a mime type in gnome
17:28 < chrish01> ie: .xendomain
17:36 -!- riel is now known as unriel
17:37 -!- hollis [~hollis@pixpat.austin.ibm.com] has quit [Quit: leaving]
17:37 -!- chrish01 [~chrish01@wsip-70-183-17-66.oc.oc.cox.net] has quit [Quit: Leaving]
17:43 -!- chrish01 [~chrish01@wsip-70-183-17-66.oc.oc.cox.net] has joined #xen
18:01 -!- murble [~murble@81.168.3.221] has quit [Ping timeout: 480 seconds]
18:05 -!- monrad [~monrad@213083190130.sonofon.dk] has joined #xen
18:16 -!- murble [~murble@81.168.3.221] has joined #xen
18:18 -!- hbaum [~hbaum@bi01p1.co.us.ibm.com] has quit [Quit: Client exiting]
18:19 -!- aliguori [~anthony@cpe-70-112-81-91.austin.res.rr.com] has quit [Quit: Leaving]
18:34 -!- rharper [~rharper@192.35.232.241] has quit [Quit: Leaving]
18:43 -!- tessier_ [~treed@203.210.217.15] has quit [Ping timeout: 480 seconds]
18:56 -!- monrad [~monrad@213083190130.sonofon.dk] has quit [Ping timeout: 480 seconds]
19:04 -!- xai [~pasta@cpe-70-112-17-10.austin.res.rr.com] has joined #xen
19:07 -!- cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has quit [Remote host closed the connection]
19:11 -!- cilkay [~cilkay@CPE00d0b743a22f-CM0011ae01fcbe.cpe.net.cable.rogers.com] has joined #xen
19:17 -!- monrad [~monrad@0x535b06c0.ronxx3.adsl-dhcp.tele.dk] has joined #xen
19:19 -!- monrad [~monrad@0x535b06c0.ronxx3.adsl-dhcp.tele.dk] has quit [Quit: ]
20:15 -!- tessier_ [~treed@222.253.71.4] has joined #xen
20:25 -!- yarihm [~yarihm@217-162-112-55.dclient.hispeed.ch] has quit [Quit: Leaving]
20:28 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Quit: Quitting]
20:33 -!- tim [~tim@66.67.139.238] has joined #xen
20:44 -!- rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
21:20 -!- jimix [~jimix@216.45.194.13] has joined #xen
21:34 -!- jimix [~jimix@216.45.194.13] has quit [Quit: jimix]
22:24 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has joined #xen
22:27 -!- Shaun [ndci@68.111.70.41] has quit [Read error: Connection reset by peer]
22:42 -!- dwh [~sc@c-24-21-84-135.hsd1.or.comcast.net] has joined #xen
23:01 -!- niv [~nivedita@bi01p1.co.us.ibm.com] has quit [Quit: Quitting]
23:08 -!- tessier_ [~treed@222.253.71.4] has quit [Read error: Connection reset by peer]
23:24 -!- chrish01 [~chrish01@wsip-70-183-17-66.oc.oc.cox.net] has quit [Quit: Leaving]
23:40 -!- drbyte [~cc2@c210-49-121-44.eburwd3.vic.optusnet.com.au] has quit [Ping timeout: 480 seconds]
23:57 -!- tessier_ [~treed@222.253.72.37] has joined #xen
--- Log closed Thu May 26 23:59:00 2005