[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Detecting of features of VMs



On Mon, Jan 27, 2020 at 06:56:26PM +0100, Peter Krempa wrote:
Hi,

I was asked by Nir and Eyal of the oVirt project on how to detect
whether a certain feature is supported by libvirt. As I thought it might
be better to document this publically rather than being lost in a
private thread I'm posting this to libvirt-users. The specific question
will be answered below.


It would also be nice to have it in either the documentation or our knowledge
base so next time someone is looking for the same answer it is not like looking
for a needle in a herbal garden (it might get lost in thyme on this list) ;-)

---

There are currently two interfaces which allow discovery of libvirts and
in turn qemu's capabilities. Both return an XML which describes various
aspects of the hosts or VMs capabilities.

virConnectGetCapabilities(conn)

https://libvirt.org/formatcaps.html

The XML returned by this API describes mostly the host itself, the CPU,
NUMA topology, security driver support, migration features but also
describes guests architectures supported by the guest.

In case of the qemu driver the guest section describes some of the
aspects and configurations supported by the default qemu binary, the
machine types and virtualization types it supports. Additionally the
<features> section describes support for some long-existing features
such as ACPI, APIC and disk snapshots. As these features are supported
for a long time, it can be assumed that they are present (at least in
case of the qemu driver) when the second API is present.

Now while the virConnectGetCapabilities API provides mostly useful
information about the host, the limitation of not being able to report
information about specific qemu binaries or machine types lead to
introduction.

virConnectGetDomainCapabilities(conn, emulator_binary_path, architecture,
                               machine_type, virt_type, flags)

https://libvirt.org/formatdomaincaps.html

The XML returned by this API describes the capabilities of an VM which
would be started using the parameters given to the API (note that if the
parameters are NULL a default is provided).

The <os> subelement describes supported OS loader types and firmware
binaries. <cpu> describes which CPU models are supported by the emulator
and also the CPU which would be used if 'host-model' is selected as the
CPU model.

The <devices> section describes models and some properties of devices
supported by the VM. The 'enum's reported in this XML map to supported
values of some of the fields we report the possible configurations for.
Note that these values are reported individually and all combinations
aren't necessarily supported.

The last section 'features' describes whether some high-level features
supported by such a VM. The features themselves are described in the
documentation above.

Note that the entries into 'features' are added arbitrarily depending on
whether a feature is deemed important enough to be exposed. So please
feel free to report if anything is missing or it would be helpful if we
reported any feature.

---

Now specifically to the question: I was asked on when it's safe to pass
VIR_DOMAIN_UNDEFINE_CHECKPOINTS_METADATA to virDomainUndefine.

In this case it's safe to pass it if <features> contains the <backup>
element regardless of the value of 'supported' attribute. I'll also
mention this in the documentation of the domain caps XML.


Attachment: signature.asc
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]