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