[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