[Libvir] PATCH: Allow Xen HVM kernel+initrd booting
Daniel Veillard
veillard at redhat.com
Mon Feb 4 14:44:12 UTC 2008
On Sun, Feb 03, 2008 at 06:47:18PM +0000, Daniel P. Berrange wrote:
> The latest xen-unstable tree has support for booting HVM guests using an
> explicit kernel+initrd+cmdline, as an alternative to the traditional BIOS
> boot from harddisk/cdrom/network. This gives Xen HVM parity with KVM in
> terms of boot methods. The current libvirt Xen driver though assumes that
> Xen paravirt is always kernel+initrd or bootloader based, while Xen HVM
> is always BIOS based.
>
> This patch re-factors the Xen driver so that it allows kernel+initrd for
> both Xen paravirt and HVM guests.
>
> NB, Xen HVM previously abused the 'kernel' parameter in the SEXPR to refer
> to the HVM guest firmware (ie /usr/lib/xen/boot/hvmloader). With the new
> support for booting kernel+initrd in HVM guests, the firmware can now be
> specified using an explicit 'loader' parameter - for backwards compatability
> you can still use the old 'kernel' parameter too if doing a BIOS boot.
>
> Second, it is also now possible for a paravirt guest to provide an explicit
> patch to a QEMU device model, aka the <emulator> tag in libvirt, so this
> pach also enables that functionality for paravirt guests.
So basically Xen PV, Xen FV and KVM <os> blocks should now share the
same set of functionalities, sharight the same syntax, right ? And the
refactoring comes from the 3 being able to share more code, if yes that
sounds excellent :-)
> Finally, since the paravirt framebuffer is tied up in all this code too, I
> also include John's patch to make us deal with <graphics> properly in legacy
> guests and old XenD.
okay
> Thankfully we have a large test suite of SEXPR/XML files, so while this is
> a pretty major refactoring of code, I'm fairly confident we won't cause bad
> regressions.
>
> A couple of the existing test cases needed their sample SEXPR tweaked since
> we now generate a couple of (...) bits in a different order, the result is
> functionally the same though.
okay, that should not be a problem.
> Finally as an example, we can create a HVM guest on xen-unstable using this
> XML snippet - note how we can now pass parameters to the installer for HVM
> too !
Looks like unification of the description, great !
> <domain type='xen'>
> <name>kernel</name>
> <uuid>06ed00fe-1162-4fc4-b5d8-11993ee4a8b9</uuid>
> <os>
> <type>hvm</type>
> <loader>/usr/lib/xen/boot/hvmloader</loader>
> <kernel>/root/vmlinuz.f864</kernel>
> <initrd>/root/initrd.img.f864</initrd>
> <cmdline>console=ttyS0 console=tty0</cmdline>
> </os>
> <memory>540672</memory>
> <currentMemory>531456</currentMemory>
> <vcpu>1</vcpu>
> <on_poweroff>preserve</on_poweroff>
> <on_reboot>preserve</on_reboot>
> <on_crash>preserve</on_crash>
> <features>
> <acpi/>
> <apic/>
> <pae/>
> </features>
> <devices>
> <emulator>/usr/lib64/xen/bin/qemu-dm</emulator>
> <interface type='bridge'>
> <source bridge='xenbr0'/>
> <mac address='00:16:3e:0e:e8:b7'/>
> <script path='vif-bridge'/>
> </interface>
> <disk type='file' device='disk'>
> <driver name='file'/>
> <source file='/root/kernel.img'/>
> <target dev='hda'/>
> </disk>
> <input type='mouse' bus='ps2'/>
> <graphics type='vnc' port='-1' listen='0.0.0.0'/>
> <console tty='pty'/>
> </devices>
> </domain>
If we were to switch that domain to PV, the change would basically
to remove os/loader and devices/emulator, change os/type to be linux,
and then get kernel and initrd to point to the PV versions, right ?
> Dan.
>
> Index: src/xend_internal.c
> ===================================================================
> RCS file: /data/cvs/libvirt/src/xend_internal.c,v
> retrieving revision 1.165
> diff -u -p -r1.165 xend_internal.c
> --- src/xend_internal.c 30 Jan 2008 16:38:18 -0000 1.165
> +++ src/xend_internal.c 3 Feb 2008 18:37:17 -0000
> @@ -1280,65 +1280,84 @@ xend_log(virConnectPtr xend, char *buffe
> static int
> xend_parse_sexp_desc_os(virConnectPtr xend, struct sexpr *node, virBufferPtr buf, int hvm, int bootloader)
> {
> - const char *tmp;
> + const char *loader = NULL;
> + const char *kernel = NULL;
> + const char *initrd = NULL;
> + const char *cmdline = NULL;
> + const char *root = NULL;
>
> if (node == NULL || buf == NULL) {
> return(-1);
> }
>
> virBufferAdd(buf, " <os>\n", 7);
> + if (hvm)
> + virBufferAdd(buf, " <type>hvm</type>\n", -1);
> + else
> + virBufferAdd(buf, " <type>linux</type>\n", -1);
> +
okay, unification, great !
> - * Parse the OS part of the XML description for an HVM domain and add it to
> - * the S-Expr in buf. This is a temporary interface as the S-Expr interface
> - * will be replaced by XML-RPC in the future. However the XML format should
> - * stay valid over time.
> + * Parse the OS part of the XML description for a HVM domain
> + * and add it to the S-Expr in buf.
Hum :-)
> + /*
> + * Originally XenD abused the 'kernel' parameter for the HVM
> + * firmware. New XenD allows HVM guests to boot from a kernel
> + * and if this is enabled, the HVM firmware must use the new
> + * 'loader' parameter
> + */
> + if (hasKernel) {
> + virBufferVSprintf(buf, "(loader '%s')", (const char *) loader);
> } else {
> virBufferVSprintf(buf, "(kernel '%s')", (const char *) loader);
> }
What happen if someone uses libvirt-0.4.1 with an old xend and an HVM
with kernel XML description is given ? I suppose (kernel) gets ignored
but it fails because the loader is not proper.
> RCS file: /data/cvs/libvirt/tests/xml2sexprdata/xml2sexpr-fv-localtime.sexpr,v
> retrieving revision 1.2
> diff -u -p -r1.2 xml2sexpr-fv-localtime.sexpr
> --- tests/xml2sexprdata/xml2sexpr-fv-localtime.sexpr 18 Jul 2007 21:08:22 -0000 1.2
> +++ tests/xml2sexprdata/xml2sexpr-fv-localtime.sexpr 3 Feb 2008 18:37:17 -0000
> @@ -1 +1 @@
> -(vm (name 'fvtest')(memory 400)(maxmem 400)(vcpus 1)(uuid 'b5d70dd275cdaca517769660b059d8bc')(on_poweroff 'destroy')(on_reboot 'restart')(on_crash 'restart')(image (hvm (kernel '/usr/lib/xen/boot/hvmloader')(device_model '/usr/lib64/xen/bin/qemu-dm')(vcpus 1)(boot c)(cdrom '/root/boot.iso')(acpi 1)(usb 1)(vnc 1)(localtime 1)))(device (vbd (dev 'ioemu:hda')(uname 'file:/root/foo.img')(mode 'w')))(device (vif (mac '00:16:3e:1b:b1:47')(bridge 'xenbr0')(script 'vif-bridge')(type ioemu))))
> \ No newline at end of file
> +(vm (name 'fvtest')(memory 400)(maxmem 400)(vcpus 1)(uuid 'b5d70dd275cdaca517769660b059d8bc')(on_poweroff 'destroy')(on_reboot 'restart')(on_crash 'restart')(image (hvm (kernel '/usr/lib/xen/boot/hvmloader')(vcpus 1)(boot c)(cdrom '/root/boot.iso')(acpi 1)(usb 1)(localtime 1)(device_model '/usr/lib64/xen/bin/qemu-dm')(vnc 1)))(device (vbd (dev 'ioemu:hda')(uname 'file:/root/foo.img')(mode 'w')))(device (vif (mac '00:16:3e:1b:b1:47')(bridge 'xenbr0')(script 'vif-bridge')(type ioemu))))
Humpf maybe we should add a indenting flag for sexpr2string and use it for
regression tests, that's hard to read and near impossible to debug,
> \ No newline at end of file
and would avoid that EOL mess...
Looks good to me, +1
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
More information about the libvir-list
mailing list