[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] Using Xen 3.3 with Debian Etch? PV domU troubles.


  • To: xen-users@xxxxxxxxxxxxxxxxxxx
  • From: Anton <anton.list@xxxxxxxxx>
  • Date: Tue, 23 Sep 2008 17:22:28 +1200
  • Delivery-date: Mon, 22 Sep 2008 22:23:05 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=icOzFmKKnt3h5BAyg52nlSWVYK5//1c8BaoS8/xQGl1mIjENaLjyCxN9+ef9rI0fKV yc0CrYYSelFKBt28EYxYent+E4dSgEZqJOaFNiDwenUEx1G5LUGqw0gJxw+RIVoyvtUZ U4XISMZCt3xtnroKX8tF8/fEzelTm2Zy5kzRY=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

Hi all,

I've built Xen 3.3 from source on a clean (ie no previous Xen install)
Debian Etch server (AMD64 with 8 Intel cores and 4GB RAM) and I'm
having some problems with the Xen supplied Linux domU kernels. The
problems are mainly getting PV Debian Etch domUs to boot. HVM Windows
domUs seem to work properly.

I'm pretty sure the hypervisor, xend, and the domU configs are all
good because when I use the standard Debian Etch Xen kernel
(linux-image-2.6-xen-amd64 which is currently 2.6.18-6) for the domUs
everything seems to work properly.

I've tried the 2.6-xen (combined dom0/domU) and 2.6-xenU kernels from
Xen (via downloaded via mercurial during the build process) and both
seem to not like booting PV Debian domUs.

I've tried both existing LVM based domUs and file backed domUs
downloaded from jailtime.org - neither works with a domU kernel from
Xen, but work OK with a Debian kernel and initrd.

The boot process looks like this:

xen:/etc/xen# xm create debian1.cfg -c
Using config file "./debian1.cfg".
Started domain debian1
NET: Registered protocol family 17
xen-vbd: registered block device major 202
blkfront: xvda1: barriers enabled
blkfront: xvda2: barriers enabled
XENBUS: Device with no driver: device/console/0
Freeing unused kernel memory: 128k freed
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
Adding 393208k swap on /dev/xvda2.  Priority:-1 extents:1 across:393208k
EXT3 FS on xvda1, internal journal

And that is where it stops (eg it doesn't get as far as init) - no
errors or kernel panics etc it just stops booting at that point. The
domain is still running and can be destroyed/shutdown ok.


The domU config file:

kernel = "/boot/vmlinuz-2.6.18.8-xenU"
ramdisk = "/boot/initrd-2.6.18.8-xenU.img"
memory = 256
name = "debian1"
vif = [ '' ]
disk = [
        'phy:/dev/guests/debian1-disk,xvda1,w',
        'phy:/dev/guests/debian1-swap,xvda2,w',
        ]
dhcp="dhcp"
root = "/dev/xvda1 ro"

Just changing the kernel and ramdisk to the Debian supplied ones gets
it booting properly. Changing xvda(n) to hda(n) made no difference
either. Switching to 2.6.18.8-xen (instead of the 2.6.18.8-xenU listed
above) makes no difference either even though they are vastly
different kernel configs - it only creates more module output before
stopping (so I suspect the initrd is loading ok).

I've looked through the kernel build configs for differences, but
couldn't see anything obviously important (to me at least). I don't
think the ramdisk is a problem - the 2.6-xen ramdisk will load the
correct kernel modules (eg for RAID etc) when used to boot dom0.


Ideally I (possibly mistakenly) would like to use some of the newer
features or fixes Xen has added to the kernel since those Etch kernels
were built. Are they useful enough, or should I just stick with the
old Etch kernels that date from the Xen 3.0.3 era?

Has anyone else got the Xen kernels working with Debian PV domUs? Have
I overlooked anything?

Any insights or even random comments appreciated :)

-- 
Cheers
Anton

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.