On Nov 6, 2009, at 11:49 AM, Christopher Hunt wrote: [...] > [root at VMM03-XEN xen]# cat /etc/xen/guest02 > # Automatically generated xen config file > name = "guest02" > memory = "1024" > disk = [ 'phy:/dev/VMM01-KVMvg00/guest02,xvda,w', ] > vif = [ 'mac=00:16:3e:5c:f1:dd, bridge=xenbr0', ] > vfb = ["type=vnc,vncunused=1"] > #bootloader="/usr/bin/pygrub" > kernel = "/boot/vmlinuz-2.6.18-164.6.1.el5xen" > ramdisk = "/boot/initrd-2.6.18-164.6.1.el5xen.img" > vcpus=1 > on_reboot = 'restart' > on_crash = 'restart' > #root = "/dev/VMM01-KVMvg00/c5root00 ro" > #extra = "single selinux=0" > extra = "ro" [...] > [root at guest02 ~]# cat /etc/grub.conf > # grub.conf generated by anaconda > # > # Note that you do not have to rerun grub after making changes to > this file > # NOTICE: You have a /boot partition. This means that > # all kernel and initrd paths are relative to /boot/, eg. > # root (hd0,0) > # kernel /vmlinuz-version ro root=/dev/vg00/root divider=10 > notsc > # initrd /initrd-version.img > #boot=/dev/vda > default=0 > timeout=5 > splashimage=(hd0,0)/grub/splash.xpm.gz > hiddenmenu > title CentOS (2.6.18-164.el5) > root (hd0,0) > kernel /vmlinuz-2.6.18-164.el5 ro root=/dev/vg00/root > divider=10 notsc > initrd /initrd-2.6.18-164.el5.img Couple thoughts: /etc/grub.conf on the guest is actually irrelevant with the xen config you gave as you're not using pygrub, but are using a specified dom0 kernel/initrd (what pygrub does is use grub on the domU to use the domU's kernel/initrd). Now, this would be fine, but you'll likely run into issues with not having appropriate modules installed for that kernel; you might be able to boot without any modules (lots of errors certainly though) but it depends. My recommendation is usually to use pygrub along with installing the right domU kernel-xen. You might be able to do this, even if you do not have access to the KVM host any longer, by using "kpartx" to create a block device for the partition inside the lv, mounting it in the dom0, and then using some alternate install root for rpm/yum (not sure what the option is offhand). Lastly, to help with debugging: it's been a while since I had to dive into this, and I was using Gentoo at the time, but it use to be there was a difference between /dev/tty0 and /dev/console with Xen; you use to have to change your inittab to have the getty load on /dev/ console. Oh, actually, looking at my CentOS boxes now, it seems that kudzu rewrote /etc/inittab to start a getty on "xvc0" (see below). Anyhow, what I'm reasoning is that perhaps you're not seeing errors on "xm console" because you either need to pass/append "console=xvc0" on your kernel command line (xen config "extra" param I think) *or* update your getty line in /etc/inittab (again, by using kpartx if you don't have access to the old, running machine). Cheers, Eric --------- # Run gettys in standard runlevels co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav #1:2345:respawn:/sbin/mingetty tty1 #2:2345:respawn:/sbin/mingetty tty2 #3:2345:respawn:/sbin/mingetty tty3 #4:2345:respawn:/sbin/mingetty tty4 #5:2345:respawn:/sbin/mingetty tty5 #6:2345:respawn:/sbin/mingetty tty6