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