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.