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