On Wed, Jan 03, 2007 at 04:06:29PM +0000, Daniel P. Berrange wrote:
> 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 problem is that they don't all share the qemu driver, even Xen HVM
uses qemu. To me the type in the top level domain element should be sufficient
to tell what virtualization technology is used. It's basically the big switch
telling what allowed or not inside the XML description. I really prefer to
have as complete information there as possible.
> > 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,
okay use another terminology there if you want.
> 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.
and 6 months from now people will start developping special paravirt drivers
and kernel for KVM (those kernel guys won't resist shaving 5% of performances
sooner or later :-) and then you will run a specific os type in a kvm
<domain type="kvm">
<os>
<type>linux</type>
will then be just fine. But if we override the os/type value now with something
which is not realated to the running os we will loose consistency later. Sorry
I'm still disagreeing, I really prefer to see
<domain type="qemu">
<domain type="kvm">
<domain type="kqemu">
and keep a generic value in <os> <type> as long as the actual OS is indifferent
but still have provision to indicate a specific one there later if needed.
> > 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.
:-)
> > 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.
okay
> > 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.
hum, the driver back-end is an internal mapping problem, we actually
have already 4 back-end for xen. I prefer to think of the XML in term
of user data rather than export of libvirt internals, which anyway have been
subject to many changes, and will continue, the key is preserving the sanity
of interface despite the changes, trying to be as consistant for the user as
possible, even if it messes up stull internallly a bit :-)
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/