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

Richard W.M. Jones rjones at redhat.com
Mon Mar 12 14:29:11 UTC 2007


Daniel P. Berrange wrote:
> 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).

This is supported through the <domain_type> field.  It appears at the 
top level (inside <capabilities>) for most drivers, but for qemu it can 
also appear inside specific <guest_architecture>s, as in:

$ local/bin/virsh -c qemu:///session capabilities
<capabilities>
   <domain_type>qemu</domain_type>
   <guest_architectures>
     [...]
     <guest_architecture>
       <domain_type>kvm</domain_type>
       <model>x86_64</model>
       <features>
         <hvm/>
         <accelerated/>
       </features>
     </guest_architecture>

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

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

Specifically in virt-manager you select the operating system at a later 
step by providing the URL for the boot image.

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

Again, in the remote case, it cannot be guessed!  This is the whole 
point of adding capabilities.  The <bios_setting> is derived by doing 
exactly this heuristic.

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

Yup, that's all supported, where it can be determined (Xen: yes, qemu: 
not sure).

Rich.




More information about the libvir-list mailing list