On Thu, Apr 20, 2006 at 03:54:59PM -0700, Daniel Hiltgen wrote:

I just started experimenting with libvirt on FC5 and ran into something that doesn't seem quite right.

I've created a VM using the xenguest-install.py script. I've tried grabbing the XML from virsh using dumpxml, but the kernel and initrd paths are invalid. Specifically:

... <os> <type>linux</type> <kernel>/var/lib/xen/vmlinuz.276riA</kernel> <initrd>/var/lib/xen/initrd.z1bslj</initrd> <cmdline>ro root=/dev/VolGroup00/LogVol00 rhgb quiet</cmdline> </os> ...

(I see the same bogus paths in xm list --long)

Yes, that's a known problem when using a whole drive image, the boot arguments are extracted by a python script, and removed once the domain is launched though xm create. Adding the discovery part of pygrub to libvirt itself would be rather nasty, it sounds saner to add it on the domain launching side.

If I shut down the VM and attempt to power it back on using the API and this XML definition, it fails with:

libvir: Xen Daemon error : POST operation failed: No such domain guest1i Failed to get devices for domain guest1 error: Failed to create domain

If I boot up the VM, and copy the kernel and initrd image out of it's /boot partition onto the main filesystem, and tweak the XML to point to those paths, I can boot the system through libvirt, but the files are automatically deleted after I boot. Also, every time I boot using xm create, I get a different bogus kernel/initrd path.

yeah, this dynamic extraction of kernel and initrd on the Dom0 is a serious pain.

Is this expected behavior, or is there a bug/mismatch between libvirt and the underlying Xen modules in FC5?

The Xen creation requires kernel and initrd paths interpreted in Dom0 filesystem, while the actual kernel and initrd resources are ultimately available only in the DomU filesystem. You could save the paths statically for example in xenguest-install.py but this could break very easilly. Basically requiring the kernel and initrd files to be present in Dom0 for domain creation is a limitation of Xen paravirt current tools. It's a known mismatch when using xvda images. Fixing it purely in libvirt would force to add some rather hard to maintain code for boot sector and filesystem extraction. Ideally at least from my POV it should be fixed by the creation code when it sees a xvda image. Alternatively libvirt could upon detection of a bootloader argument in the description, try to use that bootloader to get the informations, but this may fail for example by lack of permissions. I don't know yet how to best attack the problem, Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/