[Libvir] [PATCH] Add virConnectGetCapabilities call to return the capabilities of the driver / hypervisor
Daniel P. Berrange
berrange at redhat.com
Mon Mar 12 15:39:45 UTC 2007
On Mon, Mar 12, 2007 at 02:29:11PM +0000, Richard W.M. Jones wrote:
> 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>
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 ?
> >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.
> >> <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).
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>
> >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.
I was meaning that you'd include <flag>vmx</flag> or equiv in the XML so
the hueristic would still work in the remote case. I don't think it is
useful to invent an explicit '<bios_setting>' flag because that is only
relevant on x86 architectures, and even then we are not actually able to
explicitly determine wheter it is truely the BIOS that has disable it in
or not. ie, if we have CPU flags in /proc, but don't have hvm listed in
/sys/hypervisor/properties/capabilities then it is *probably* the BIOS
which has disabled it, but it could also be the case that Xen itself is not
supporting it.
Thus I don't think we should declare an explicit <bios_setting>, because
we can't fill in yes/no with certainty. It is better to provide the raw
information that we do know with 100% certainty - ie the CPU flags, and
the capabilites of the HV. If apps so choose & they are on an appropriate
architecture, they can then infer from those two pieces of info that the
BIOS is /probably/ disabling.
> >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).
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 -=|
More information about the libvir-list
mailing list