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
