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.