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

[Daniel P. Berrange]

On Fri, Mar 09, 2007 at 03:22:08PM +0000, Richard W.M. Jones wrote:
> This patch:
> 
> * Adds virConnectGetCapabilities which returns an XML description of the 
> capabilities of the driver or hypervisor under this connection (see 
> below for more about the XML format).
> 
> * Adds virsh capabilities command.
> 
> * Checks the Python binding works.

The APIs all look fine - I've few questions about XML structure below

> $ virsh -c qemu:///session capabilities | tidy -xml -i -q
> <capabilities>
>   <domain>
>     <type>qemu</type>
>   </domain>
>   <guest_architectures>
>     <guest_architecture>
>       <model>i686</model>
>       <bits>32</bits>
>       <features>
>         <emulated />
>       </features>
>     </guest_architecture>
>     <guest_architecture>
>       <model>x86_64</model>
>       <bits>64</bits>
>       <features>
>         <emulated />
>       </features>
>     </guest_architecture>
> [... other archs deleted ...]
>   </guest_architectures>
> </capabilities>

We need some form of correlation between domains types and
architectures I think. QEMU supports domain types of 'qemu', 'kvm',
'kqemu'. KVM /KQEMU only support the architecture which matches
the host architecture (currently).

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.

> XML format:
> 
> The <capabilities> node contains information about the host and a list 
> of supported architectures for guests.  About the host we return:
> 
>   <domain>
>     <type>	The default type acceptable when creating a domain.
> 
>   <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'.

And then separately list CPU flags like vmx / svm. There isn't a need
to represent 'bios setting' directly - it can be (guessed at) by looking
whether you have vmx/svm, but don't have support for HVM guest OS types.

Where it gets confusing is that each of these OS types can be supported
in various modes. On 32-bit, "linux" can be supported with 32-bit guests
(maybe PAE, or not depending on hypervisor), and 'hvm' can do 32-bit, or 
32-bit PAE guests. On 64-bit, "linux" can be supported with 64-bit guests, 
and 'hvm" can do 32-bit, 32-bit PAE or 64 bit. In the future, 'linux'
might also be able to do 32-bit PAE guests on 64-bit.

My head really hurts with all this so I've not got an alternative XML
structure to suggest yet...

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