Re: [Libvir] FC5 bug with kernel/initrd paths
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/