10:06 a.m.
On Wed, Jan 03, 2007 at 10:35:47AM -0500, Daniel Veillard wrote:
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).
Yes, I forgot to mention I'd already assumed the 'type' attribute on the
top level <domain> tag would be 'qemu' to indicate the qemu driver.
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).
It just feels a little wrong to use 'hvm' (Hardware Virtual Machine) as
the term for qemu, in which only the kvm variant is actually hardware
accelerated, with all the others just being software emulated. As per my
other reply to Jeremy, I felt <type> to be refering to the virtualization
strategy for the backend, and so implementation specific. For Xen world
we have 'linux' or 'hvm', while for QEMU world we have the different
'qemu'
'kvm', 'kqemu' options.
> 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.
Well, yes you need to have '--no-kqemu' command line argument to turn off the
kqemu acceleration. We definitely need to support both having it on/off because
some OS' will crash badly with kqemu due to emulation bugs.
> * 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.
Yes, there'd either be a list of pre-define binaries for each architecture,
or we can generate binary names with some reasonable naming scheme, so
we'd only need the explicit <loader> option if you wanted to point to an
instance outside of standard /usr/bin, /bin, or $PATH locations.
> 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
I thought the top level 'type' attribute referred to the name of the libvirt
driver backend - so would always be 'qemu' in this case. Hence thought of using
the <type> element to specify acceleration method.
Regards,
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 -=|