[Libvir] XML format for QEMU / KVM driver

[Daniel Veillard]

On Wed, Jan 03, 2007 at 03:11:58PM +0000, Daniel P. Berrange wrote:
> QEMU is basically a fully-virt solution, so XML description for the <os>
> block would be superficically similar to Xen HVM support, in that it
> will typically try to boot the kernel found in the MBR of the first
> harddisk (unless you specify an alternate boot device). Unlike Xen HVM
> support, it can also have an explicit kernel, initrd  & arguments
> specified via command line. The other difference is that Xen has a 
> separater binary for the loader, vs device model - QEMU/KVM does it
> all in one binary.
> 
> So, my initial thoughts are:
> 
>   1. Use the  <type>  element within the <os> block to describe the
>      CPU accelerator to use, accepting the values 'qemu', 'kvm', 
>      'kqemu' or 'qvm86'.

   Hum, there is also the <domain type='...'> value on the root element.
I think it's relatively important to keep the differenciator early on.
Moreover since there is only a relatively limited set of values to pick from
it's good to have it on an attribute (it helps validation say if you're
using DTDs).
   The type in the <os> block to me indicate the type of os (say linux,
freebsd or hvm in case of full virt). To be consistent I would keep 
os/type to hvm because in any cases this is a full virtualization (or 
rather a cpu emulation).

>   2. For CPU architecture, there are a couple of choices
> 
>       a) Add an 'arch' attribute to the <type> element to select between
>          x86, ppc, sparc, etc.
>       b) Add an <arch> element within the <os> block to switch between
>          architectures.
>       c) Just use the <loader> element to point to the QEMU binary 
>          matching the desired architecture. 
>       d) Use the <emulator> element within the <devices> section to point 
>          to the QEMU binary  matching the desired architecture. 
>       e) Option a) and also allow use of <loader> to override the
>          default QEMU binary to use
>       f) Option b) and also allow use of <loader> to override the
>          default QEMU binary to use
>       g) Option a) and also allow use of <emulator> within the
>          <devices> block to override the default QEMU binary to use
>       h) Option b) and also allow use of <emulator> within the
>          <devices> block to override the default QEMU binary to use
> 
>      At this time, i'm leaning towards either option e). This would give
>      examples like

   Yes I like this too, this is consistent with previous uses (and then ease
validation), and again the arch is a limited list which can be enumerated
statically so having it as an attribute value is nice. IIRC though the 
qemu versus kqemu is not really noticeable at the command line level,
if QEmu was compiled with kqemu support it will be on by default (if the module
is loaded/loadable) and off by defaut otherwise, one can just disable it
if one want to avoid it when compiled in.

>       * Using  PPC with regular non-accelerated QEMU
> 
>         <os> 
>           <type arch="ppc">qemu</type>
>         </os>
> 
>       * Using non-accelerated QEMU, and guest architecture matching
>         the host
> 
>         <os> 
>           <type>qemu</type>
>         </os>
> 
>       * Using accelerated KVM
> 
>         <os> 
>           <type>kvm</type>
>         </os>
> 
>       * Using accelerated KVM, but with an alernate binary
> 
>         <os> 
>           <type>kvm</type>
>           <loader>/home/berrange/work/kvm-devel/qemu-kvm</loader>
>         </os>

  I assume that libvirt will have default compiled-in values for the
loaders of all supported types.

> 
>   3.  For machine type, again there are a couple of options:
> 
>        a) Add a 'machine'  attribute to the <type> element
>        b) Add a <machine> element within the <os> block
> 
>       For this I think we should just follow same scheme that we
>       use to specify architecture. So I'd lean towards a)
> 
>        * Using PPC with a Mac-99 machine:
> 
>         <os> 
>           <type arch="ppc" machine="mac99">qemu</type>
>         </os>
> 
>        * Using non-accelerated QEMU, and guest architecture matching
>          the host, and a non-PCI machine:
> 
>         <os> 
>           <type machine="isapc">qemu</type>
>         </os>

  yes except that I would expect the top level type attribute to define the
engine used, and have os/type be hvm (or so common emulation value), but
it's fine to have os/type/@arch and os/type/@machine as differentiators there

> All the other bits of XML like disk/network/console configuration are pretty
> straightforward, following very similar structure to Xen. So there isn't really
> much interesting stuff to discuss there.

  yeah, that should be fairly close, or easilly mappeable.

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/