[Libvir] XML format for QEMU / KVM driver

[Daniel P. Berrange]

Since KVM is the new "shiny thing" in the virtualization world for Linux I
figure its time to resurrect & finish the prototype QEMU backend I started
developing for libvirt. Thanks to the design of KVM, it ought to be possible
to support KVM & QEMU in a single driver with near-zero extra effort to add
the bits for KVM support.

There's a couple of interesting decisions wrt additions in the XML format
describing guests. 

 1. QEMU can be built with several different CPU accelerators, eg KQEMU,
    QVM86 or KVM. These are only available if the guest CPU matches the
    host CPU architecture though.

 2. QEMU can emulate many different CPU types. x86, x86_64, mips, sparc,
    ppc, arm, etc

 3. QEMU can emulate many different different 'machine' types, for each
    CPU type. eg for x86 cpus:

    $ qemu -M ?
    Supported machines are:
    pc         Standard PC (default)
    isapc      ISA-only PC

Some of these options are activated by specifying a particular command
line flag, eg -M for machine type. Others require you to use a different
qemu binary, eg 'qemu-system-arm', 'qemu-system-ppc' instead of 'qemu'.

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'.

  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

      * 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>


  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>

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.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|