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@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/