--- Day changed

--- Log opened Thu Mar 30 23:59:03 2006
00:06 -!- vodka_ [~knarf@ip-83-134-78-67.dsl.scarlet.be] has joined #linode-xenbeta
00:07 -!- vodka [~knarf@ip-81-11-226-166.dsl.scarlet.be] has quit [Ping timeout: 480 seconds]
01:25 -!- gpd [~gpd@70.85.16.173] has quit [Quit: leaving]
01:40 < fo0bar> HAHAHAHA
01:40 < caker> ???
01:40 < fo0bar> I now have finnix running inside UML running on finnix running inside xen
01:41 < fo0bar> [*] Running Linux kernel 2.6.15-um-finnix on i686
01:41 < fo0bar> [*] Host: Linux finnix 2.6.16-xenU-finnix-linode1 #1 SMP Thu Mar 30 17:40:27 EST 2006 i686
01:41 < caker> wow
01:41 < caker> skas0 ?
01:41 < caker> (I assume so)
01:41 < caker> awesome
01:42 < fo0bar> no, skas0 freezes up right before the initrd would take over
01:42 < fo0bar> I'm not sure why
01:42 < fo0bar> I had to use tt
01:43 < fo0bar> also, no networking since the xenU kernel has neither nat nor bridging
01:44 < caker> ahh, yeah, I turned off all the extra networking features, so no one would be tempted to run it full time
01:44 < fo0bar> heh
01:44 < caker> I left all the fs support, and other stuff that would be useful for recovery
01:45 < fo0bar> but the regular xenU has nat and bridging?
01:45 < caker> yes .. pretty sure nat, bridging is def a yes
01:45  * fo0bar starts a UML VPS provide inside his xenode
01:45 < caker> hehe
01:46 < fo0bar> finnix-uml checks to see if it's already running in UML and will refuse.  I'm glad I didn't put the same check in for xen, or I may have never tried this
01:47 < caker> There really isn't way to tell it's Xen, is there? (I haven't thought about this much)
01:47 < caker> I guess /proc/xen, but I can turn that off
01:47 < fo0bar> sure, just look for /proc/xen
01:47 < fo0bar> oh, I didn't know you could turn that off
01:48 < fo0bar> that's the basis for how finnix determines if it's running in uml, xen or normal cd bootup
01:48 < caker> huh .. maybe I'm wrong, and there's stuff in /sys/...
01:48 < caker> CONFIG_XEN_SYSFS=y
01:49 < caker> huh...
01:50 < caker> interesting .. just a bunch of version info in /sys/hypervisor
01:56 < fo0bar> so, you seem to know more about xen then I do...  how does the whole intel/vt/yonah stuff fit into this?
01:56 < fo0bar> do you just install xen like normal, and the hypervisor is more efficient on a yonah proc?
01:57 < caker> it can run any unmodified guest, but I imagine the environment and management tools work the same
01:57 < caker> the unmodified bit is the big win
01:57 < fo0bar> does that bit actually work yet?
01:58 < caker> yeah, it has for a while (long before the boards/procs were available to us, if they even are now)
01:58 < caker> from both camps (amd and intel)
01:58 < fo0bar> but you still have to run a dom0 on first bootup, right?
01:59 < fo0bar> err dom0-ized kernel
01:59 < caker> Well, first you need to boot into the hypervisor
01:59 < caker> and then you need a management domain
01:59 < fo0bar> oh
01:59 < caker> Not sure if that needs to be modified, but you'd need at least the backend drivers for network and disks, etc
02:00 < fo0bar> I was about to say...  if everything's done through the hypervisor, where does "xen" come into play? :)
02:00 < caker> Here's how I understand the new extentions to work:  Right now, there are four rings
02:01 < fo0bar> and I imagine you need a special EFI module to "enter the hypervisor"
02:01 < caker> Xen needs to trap when a guest kernel asks what ring it's in, and report back 0, even though it isn't
02:01 < caker> under the new hardware, there are multiple sets of the rings
02:01 < caker> the real ring, which xen and friends run, and then fake ring ranges, whewre unmodified guests run
02:01 < caker> funky, huh?
02:02 < fo0bar> oh, so you have ring 0 in virtual space 1, ring 0 in virtual space 2, etc
02:02 < caker> yes
02:03 < fo0bar> I may have to buy a yonah processor
02:03 < fo0bar> though my boss says to wait until the generation after yonah, which will have netburst architecture completely replaced
02:03 < fo0bar> and netburst is "teh suck" compared to the next generation according to him
02:04 < caker> http://wiki.xensource.com/xenwiki/IntelVT
02:04 < caker> wtf is netburst?
02:04  * caker googles
02:05 < fo0bar> http://en.wikipedia.org/wiki/Netburst
02:05 < fo0bar> The NetBurst architecture basically includes features such as "Hyper Pipelined Technology" and "Rapid Execution Engine" which are firsts in this particular microarchitecture. <-- I understand maybe 40% of the words in that sentence :)
02:05 < fo0bar> Intel has announced that it will replace NetBurst with the Intel Core Microarchitecture, to be released in July 2006.
02:05 < fo0bar> Presler, a core of Pentium D released in early 2006, is widely touted by analysts to be the last in the line of NetBurst. The new architecture core Conroe, an eighth generation microprocessor architecture chip, is also suggested to replace Presler.
02:06 < caker> that xensource page supposedly is maintained with the list of VT supporting mb/chipsets/procs
02:06 < caker> huh
02:08 < fo0bar> "As long as the motherboard supports the 65nm Presler Pentium D chips (check the BIOS update notes) - proper microcode in the BIOS - then it should work."
02:08 < caker> yeah
02:08 < fo0bar> supermicro has some 65nm-capable systems out now
02:09 < fo0bar> I accidentially ordered a 65nm P4 this month, and called Supermicro to see if it was possible to use it on the system I ordered (a standard 5014C-MT)
02:09 < fo0bar> the tech said no, but pointed me to the new systems
02:09 < caker> I think I'm going to stick with AMD systems for a bit
02:10 < caker> esp. after the cpu >=3 bugginess issues I've dealt with
02:10 < caker> though I'm going to try some bios upgrades, see if that fixes it
02:10 < fo0bar> cpu >=3?
02:11 < caker> http://www.theshore.net/~caker/hosts/host-bios-dates.txt 
02:11 < caker> ^-- host55 has never paniced
02:11 < caker> although a handful of the 01/21/2005 machines haven't either
02:11 < caker> cpu model 
02:11 < caker> grep model /proc/cpuinfo
02:11 < caker> those are the boxes that crash @ Linode
02:11 < fo0bar> BTW, an update on my xeon/9550sx problems
02:12 < fo0bar> I removed a CPU, it was fine for 3 days of testing
02:12 < fo0bar> swapped in the other CPU, fine for 3 days
02:12 < fo0bar> put the other CPU back in, but disabled HT, fine for 3 days
02:12 < fo0bar> now I'm trying again with HT back on (essentially back at square 1)
02:13 < fo0bar> I'm really hoping a CPU wasn't seated properly or something
02:13 < caker> with their dev driver?
02:13 < caker> huh
02:13 < fo0bar> yeah, but the dev driver didn't really affect anything
02:13 < fo0bar> the same problems happened before and after using it
02:13 < fo0bar> this is before I started swapping CPUs
02:14 < fo0bar> inez:/mnt/hda1/knx/finnix-87.0+extras# du -sh
02:14 < fo0bar> 841M    .
02:15 < fo0bar> CRAP
02:15 < fo0bar> oh wait, I have duplicate gentoo trees in there
02:16 < fo0bar> (/mnt/hda1/knx is a throwback from mid last year when "finnix" was just a remastered knoppix disc)
02:16 < caker> you replaced the ram, I assume?
02:16 < fo0bar> inez:/mnt/hda1/knx/finnix-87.0+extras# du -sh
02:16 < fo0bar> 577M    .
02:16 < fo0bar> much better
02:16 < fo0bar> caker: replaced everything but the CPUs
02:18 -!- gpd [~gpd@70.85.16.173] has joined #linode-xenbeta
02:32 < caker> heh
03:09 < alnr> caker: would it possible to migrate back to uml if there were a serious problem?
04:03 -!- dsoul [darksoul@vice.ii.uj.edu.pl] has joined #linode-xenbeta
08:26 -!- dsoul [darksoul@vice.ii.uj.edu.pl] has quit [jupiter.oftc.net neutron.oftc.net]
08:26 -!- valen2 [~valen@adsl-70-238-134-49.dsl.stlsmo.sbcglobal.net] has quit [jupiter.oftc.net neutron.oftc.net]
08:26 -!- phlaegel [~phlaegel@atdot.ca] has quit [jupiter.oftc.net neutron.oftc.net]
08:29 -!- dsoul [darksoul@vice.ii.uj.edu.pl] has joined #linode-xenbeta
08:29 -!- valen2 [~valen@adsl-70-238-134-49.dsl.stlsmo.sbcglobal.net] has joined #linode-xenbeta
08:29 -!- phlaegel [~phlaegel@atdot.ca] has joined #linode-xenbeta
12:19 -!- gpd [~gpd@70.85.16.173] has quit [Quit: leaving]
12:57 -!- gpd [~gpd@70.85.16.173] has joined #linode-xenbeta
13:16 < caker> alnr: yes, it is possible
13:28 -!- snorp [~snorp@CPE-65-28-73-215.kc.res.rr.com] has joined #linode-xenbeta
13:29 < snorp> so, before I migrate my linode
13:29 < snorp> it's recommended to resize the image
13:29 < snorp> how do I know how far I can go?
13:29 < caker> df -h
13:29 < snorp> oh
13:29  * snorp just shut down
13:29  * snorp boots
13:30 < caker> You might need to get in via Lish, since your IPs changed
13:30 < snorp> ah, yeah
14:45 < snorp> how long does it normally take a cross-datacenter migration to run?
14:45 < snorp> I guess it goes over the internet
14:45 < snorp> so...hours?
14:47 < mikegrb> how big are your disk images?
14:47 < snorp> like 2 gigs
14:47 < snorp> it just finished that one actually
14:47 < snorp> it's doing swap now woo
14:47 < mikegrb> !calc 2048 / 60
14:48 < linbot> mikegrb: 2,048 / 60 = 34.1333333
14:48 < snorp> yup
14:48 < snorp> it took like 30 minutes
14:48 < mikegrb> about a meg a minute
14:48 < snorp> well, 40
14:48 < mikegrb> er sec
14:48 < snorp> nod
17:46 -!- pclissold [~peter@sassenheim.clissold.nl] has joined #linode-xenbeta
17:57 -!- TheFirst [gaveup@your.friendly.neighborhood.hellmouth.info] has quit [Ping timeout: 480 seconds]
18:03 -!- TheFirst [gaveup@your.friendly.neighborhood.hellmouth.info] has joined #linode-xenbeta
18:17 -!- pclissold [~peter@sassenheim.clissold.nl] has left #linode-xenbeta [Leaving]
18:28 -!- snorp is now known as snorp|out
--- Log closed Fri Mar 31 23:59:01 2006