[Libvir] [PATCH] Add virConnectGetCapabilities call to return the capabilities of the driver / hypervisor

[Richard W.M. Jones]

Daniel P. Berrange wrote:
> Why have the <domain-type> at the top level at all then - its easier to
> have it all at the same place, rather than having to write two separate
> XPATH expressions to determine if a particular domain type is supported
> on a particular arch ? 

OK, point taken, I'll make this change.

>>> I'm not sure it is neccessary to list 'emulated' and 'accelerated'
>>> as attributes of the architecture as they're really implied by
>>> the domain type. eg QEMU is always emulated regardless of arch,
>>> and 'kvm' and 'kqemu' are both always accelerated - with an arch
>>> restriction.
>> It's the implications which I'm trying to get rid of though!  It's 
>> non-trivial for virt-manager to parse a remote URL to work out that it's 
>> really qemu at the other end.  It really is - you can't just look at the 
>> first 4 characters ...
> 
> This is what 'virConnectGetType()' is for though - no need to parse the
> URIs - this should return 'Xen' or 'QEMU' as appropriate for the driver.
> There are a few places in virt-manager where I do parse the URIs, but
> those are either a) bugs, or b) just to pretty-print the URI in the
> titlebar, not to determine functionality.

But you're still relying on implications.  For example currently 
virt-manager has code like this:

if self.connection.get_type() == "QEMU":
     [do something]
else:
     [do something else]
     if virtinst.util.is_hvm_capable():
         [do another thing]
     else:
         [etc]

It's not scalable to keep on adding cases throughout the code for all 
the possible types of backends, even assuming that the full list of 
libvirt drivers can be known.

The guy working on OpenVX support shouldn't need to change virt-manager 
and all other libvirt clients.  At least not in an ideal world.

>>>>  <host_features>
>>>>    <hvm>	Does the host CPU support HVM?
>>>>      <type>	Type of HVM (eg. "vmx")
>>>>      <bios_setting>   "enabled" or "disabled"
>>> For host features I think I'd talk in terms of OS types it supports.
>>> For Xen can we do OS types of 'linux' or 'hvm', for QEMU we can do
>>> 'hvm'.
>> Is this something the driver knows though?  AFAIK can't Xen run all 
>> sorts of different operating systems, including homebrew stuff written 
>> specifically to its paravirt interface?
> 
> I guess what we're really trying to represent is the type of virtualization
> paravirt, or fullyvirt. It gets a bit fuzzy because fully-virt can then 
> be emulated, or hardware assisted (hvm) or kernel accelerated (kqemu).

This is certainly a tricky area.  I guess it comes down to what we want 
virt-manager to present to the users.

If users just want to know "can I run Windows in a guest" (ie. does it 
do full-virt), and they don't care _how_ it does full-virt, then having 
just a <fullvirt/> flag might be sufficient.

On the other hand (and this is kind of what virt-manager does at the 
moment), users can be given a choice, either to run accelerated or not 
(the "kqemu" option in current virt-manager, although it's not called 
that) or even to choose the method, where that is possible.  I don't 
know if VMWare allows you to choose emulated vs. HVM (last time I looked 
it seemed to choose whichever it thought would be the fastest given your 
mix of hardware and architecture), but it's surely something that it 
might do.

This is complicated ...

I don't really have a good answer .....

> In the <guest_features> the XML has <hvm> <emulated> <accelerated> as a 
> flat list of, but no tag to indicate Xen paravirt support unless that's 
> just one you merely missed from the exmaple XML snippets ? 
> 
> I think I'd be inclined to have <host_features> to be about CPU flags,
> while <guest_features> would refer to the HV capabilities.  So this
> could simply be
> 
>    <host_features>
>      <cpu_flag>smx</cpu_flag>
>      <cpu_flag>vmx</cpu_flag>
>    </host_features>

Something along these lines would work.

Note another thing which you might not have picked up at first: 
<guest_architectures> returns a list of all possible combinations of 
supported guests (because that's what Xen provides us with in the 
capabilities file).  This is, of course, a Cartesian product so it might 
get very long, although at the moment it doesn't.  On the other hand I 
don't see a good way to avoid this because some combinations might not 
be available (eg. PAE cannot be independently controlled in QEMU -- I 
haven't determined if QEMU guests support PAE or not, but there is no 
way that I can see to toggle it).

I'll have a further think about this anyway.

Rich.

-- 
Emerging Technologies, Red Hat  http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF     Mobile: +44 7866 314 421
  "[Negative numbers] darken the very whole doctrines of the equations
  and make dark of the things which are in their nature excessively
  obvious and simple" (Francis Maseres FRS, mathematician, 1759)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070313/108d5cfa/attachment-0001.bin>