[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libvir] PATCH: Allow Xen HVM kernel+initrd booting



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/


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]