September 2019 - Devel - libvirt List Archives

[libvirt] [PATCH v1] docs: Expand the "BIOS bootloader" documentation for domainCaps
by Kashyap Chamarthy 11 Sep '19

11 Sep '19

Rewrite some parts for clarity, elaborate the meaning of some of the XML attributes. And where necessary, distinguish that we're dealing with two different XML documents here: - the domainCapabilities XML, to detect the host "hypervisor" (QEMU/KVM) capabilities, and what libvirt knows about them. - the guest XML definition, i.e. what features a guest can use, based on the capabilities (of QEMU and libvirt and the host) reported in the domainCapabilities XML. Signed-off-by: Kashyap Chamarthy <kchamart(a)redhat.com> --- docs/formatdomaincaps.html.in | 53 ++++++++++++++++++++++------------- 1 file changed, 34 insertions(+), 19 deletions(-) diff --git a/docs/formatdomaincaps.html.in b/docs/formatdomaincaps.html.in index bc99d378567a553afe682bc522e7a753b2d805fc..a8d970934df2c0ce8c41eb4958c94fbdf96ef8e0 100644 --- a/docs/formatdomaincaps.html.in +++ b/docs/formatdomaincaps.html.in @@ -127,7 +127,7 @@ <value>/usr/share/OVMF/OVMF_CODE.fd</value> <enum name='type'> <value>rom</value> - <value>pflash</value> + <value>pflapsh</value> </enum> <enum name='readonly'> <value>yes</value> @@ -143,38 +143,53 @@ <domainCapabilities> </pre> - <p>The <code>firmware</code> enum corresponds to - <code>firmware</code> attribute of the <code>os</code> element. - Plain presence of this enum means that libvirt is capable of so - called firmware auto selection. The listed values then represent - accepted values for the domain attribute. Only values for which - there exists a firmware descriptor that matches machine type and - architecture are listed, i.e. those which won't cause a failure - on domain startup. + <p>The <code>firmware</code> enum corresponds to the + <code>firmware</code> attribute of the <code>os</code> element in + the domain XML. The presence of this enum means libvirt is capable + of the so-called firmware auto-selection feature. And the listed + firmware values represent the accepted input in the domain + XML. Note that the <code>firmware</code> enum reports only those + values for which a firmware "descriptor file" exists on the host + -- a small JSON document that describes details about a given UEFI + binary on the host, e.g. the fimware binary path, its + architecture, supported machine type, NVRAM template, etc. This + ensures that the reported values won't cause a failure on guest + boot. (The firmware "descriptor files" are typically shipped + Linux distribution as part of the firmware package, + e.g. EDK2/OVMF.) </p> <p>For the <code>loader</code> element, the following can occur:</p> <dl> <dt><code>value</code></dt> - <dd>List of known loader paths. Currently this is only used - to advertise known locations of OVMF binaries for qemu. Binaries - will only be listed if they actually exist on disk.</dd> + <dd>List of known firmware binary paths. Currently this is used + only to advertise the known location of OVMF binaries for + QEMU. OVMF binaries will only be listed if they actually exist on + host.</dd> <dt><code>type</code></dt> - <dd>Whether loader is a typical BIOS (<code>rom</code>) or - an UEFI binary (<code>pflash</code>). This refers to - <code>type</code> attribute of the <loader/> - element.</dd> + <dd>Whether the boot loader is a typical BIOS (<code>rom</code>) + or a UEFI firmware (<code>pflash</code>). Each <code>value</code> + sub-element under the <code>type</code> enum represents a possible + value for the <code>type</code> attribute for the <loader/> + element in the domain XML. E.g. the presence + of <code>pfalsh</code> under the <code>type</code> enum means that + a domain XML can use UEFI firmware via: <loader/> + type="pflash" ...>/path/to/the/firmware/binary/</loader>. + </dd> <dt><code>readonly</code></dt> <dd>Options for the <code>readonly</code> attribute of the - <loader/> element.</dd> + <loader/> element in the domain XML.</dd> <dt><code>secure</code></dt> <dd>Options for the <code>secure</code> attribute of the - <loader/> element. Note, that <code>yes</code> is listed - only if there is a firmware that supports it.</dd> + <loader/> element in the domain XML. Note that the + value <code>yes</code> is listed only if libvirt detects a + firmware descriptor file that has path to an OVMF binary that + supports Secure boot, and lists its architecture and supported + machine type.</dd> </dl> <h3><a id="elementsCPU">CPU configuration</a></h3> -- 2.21.0

2 3

[libvirt] [PATCH] libvirt.spec.in: Add the Secure Boot-variant OVMF binaries
by Kashyap Chamarthy 11 Sep '19

11 Sep '19

Currently the RPM spec doesn't add the 'secboot'-variant OVMF binaries (an unintentional omission, checking with Cole on #virt, OFTC) for 'x86_64' and 'ia32'. Add them. This way, getDomainCapabilities() will report all the OVMF binaries that are present on the system. E.g. on Fedora 29, if you only have the edk2-ovmf-20190308stable-1.fc29.noarch package installed, then running `virsh domcapabilities` will enumerate _both_ the OVMF binaries (instead of just the OVMF_CODE.fd): $> virsh getdomcapabilities ... <loader supported='yes'> <value>/usr/share/edk2/ovmf/OVMF_CODE.fd</value> <value>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</value> ... ( Learnt this from a discussion with Michal Privoznik in this bug, comment#2: https://bugzilla.redhat.com/show_bug.cgi?id=1733940 -- RFE: Report firmware (FW) paths in domainCapabilities based on FW descriptor files ) Signed-off-by: Kashyap Chamarthy <kchamart(a)redhat.com> --- I only did a cursory check on if I missed to add any other valid paths for other architectures. --- libvirt.spec.in | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index b13b863928..99950495a7 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1135,10 +1135,17 @@ exit 1 # Nightly edk2.git-arm LOADERS="$LOADERS:/usr/share/edk2.git/arm/QEMU_EFI-pflash.raw:/usr/share/edk2.git/arm/vars-template-pflash.raw" - # Fedora edk2-ovmf + # Fedora edk2-ovmf, x86_64 LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd" + # Fedora edk2-ovmf, x86_64, with Secure Boot + LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd" # Fedora edk2-ovmf-ia32 LOADERS="$LOADERS:/usr/share/edk2/ovmf-ia32/OVMF_CODE.fd:/usr/share/edk2/ovmf-ia32/OVMF_VARS.fd" + # Fedora edk2-ovmf-ia32, with Secure Boot. (NB: Unlike x86_64, for + # 'ia32', there is no secboot-variant "VARS" file (NVRAM template). + # So the NVRAM template for 'ovmf-ia32/OVMF_CODE.secboot.fd' is the + # same as the one for the non-secboot variant.) + LOADERS="$LOADERS:/usr/share/edk2/ovmf-ia32/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf-ia32/OVMF_VARS.fd" # Fedora edk2-aarch64 LOADERS="$LOADERS:/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2/aarch64/vars-template-pflash.raw" # Fedora edk2-arm -- 2.20.1

3 2

[libvirt] [PATCH] domain_conf: Drop ancient reservation of unit 7 in drive address
by Michal Privoznik 11 Sep '19

11 Sep '19

Introduced in v1.0.6~3, the idea was that unit 7 was reserved and couldn't be used by QEMU. Well, that limitation is long gone. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/conf/domain_conf.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index b7a342bb91..6a019490fd 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -4812,12 +4812,6 @@ bool virDomainSCSIDriveAddressIsUsed(const virDomainDef *def, const virDomainDeviceDriveAddress *addr) { - /* In current implementation, the maximum unit number of a controller - * is either 16 or 7 (narrow SCSI bus), and if the maximum unit number - * is 16, the controller itself is on unit 7 */ - if (addr->unit == 7) - return true; - if (virDomainDriveAddressIsUsedByDisk(def, VIR_DOMAIN_DISK_BUS_SCSI, addr) || virDomainDriveAddressIsUsedByHostdev(def, -- 2.21.0

3 4

[libvirt] [PATCH v4 0/2] snapshot: Store both config and live XML in the
by Maxiwell S. Garcia 11 Sep '19

11 Sep '19

This patchset store both config and live XML in the snapshot XML. To avoid nest 'config' XML one level deeper ('inactive/domain'), it was necessary to create a function that has a new rootname parameter. V4: - Create a new function to format the XML domain choosing the root name Maxiwell S. Garcia (2): qemu: formatting XML from domain def choosing the root name snapshot: Store both config and live XML in the snapshot domain src/conf/domain_conf.c | 35 ++++++++++++++++++++++++++--------- src/conf/domain_conf.h | 6 ++++++ src/conf/moment_conf.c | 1 + src/conf/moment_conf.h | 11 +++++++++++ src/conf/snapshot_conf.c | 22 ++++++++++++++++++++-- src/qemu/qemu_driver.c | 37 ++++++++++++++++++++++++++++--------- 6 files changed, 92 insertions(+), 20 deletions(-) -- 2.20.1

3 8

[libvirt] [PATCH] qemu: Don't leak domain def when RevertToSnapshot fails
by Jiri Denemark 11 Sep '19

11 Sep '19

Once we copy the domain definition from virDomainSnapshotDef, we either need to assign it to the domain object or free it to avoid memory leaks. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/qemu/qemu_driver.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index b28a26c3d6..a984b1e65c 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -16568,6 +16568,7 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, virCPUDefPtr origCPU = NULL; unsigned int start_flags = VIR_QEMU_PROCESS_START_GEN_VMID; qemuDomainAsyncJob jobType = QEMU_ASYNC_JOB_START; + bool defined = false; virCheckFlags(VIR_DOMAIN_SNAPSHOT_REVERT_RUNNING | VIR_DOMAIN_SNAPSHOT_REVERT_PAUSED | @@ -16779,6 +16780,8 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, virDomainObjAssignDef(vm, config, false, NULL); virCPUDefFree(priv->origCPU); VIR_STEAL_PTR(priv->origCPU, origCPU); + config = NULL; + defined = true; } if (cookie && !cookie->slirpHelper) @@ -16788,8 +16791,11 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, /* Transitions 2, 3 */ load: was_stopped = true; - if (config) + if (config) { virDomainObjAssignDef(vm, config, false, NULL); + config = NULL; + defined = true; + } /* No cookie means libvirt which saved the domain was too old to * mess up the CPU definitions. @@ -16875,8 +16881,11 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, qemuProcessEndJob(driver, vm); goto cleanup; } - if (config) + if (config) { virDomainObjAssignDef(vm, config, false, NULL); + config = NULL; + defined = true; + } if (flags & (VIR_DOMAIN_SNAPSHOT_REVERT_RUNNING | VIR_DOMAIN_SNAPSHOT_REVERT_PAUSED)) { @@ -16944,7 +16953,7 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, } else if (snap) { virDomainSnapshotSetCurrent(vm->snapshots, NULL); } - if (ret == 0 && config && vm->persistent && + if (ret == 0 && defined && vm->persistent && !(ret = virDomainSaveConfig(cfg->configDir, driver->caps, vm->newDef ? vm->newDef : vm->def))) { detail = VIR_DOMAIN_EVENT_DEFINED_FROM_SNAPSHOT; @@ -16960,6 +16969,7 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, virObjectUnref(cfg); virNWFilterUnlockFilterUpdates(); virCPUDefFree(origCPU); + virDomainDefFree(config); return ret; } -- 2.23.0

2 1

Re: [libvirt] [Libvirt-ci] Build failed in Jenkins: libosinfo-build » libvirt-fedora-rawhide #231
by Fabiano Fidêncio 10 Sep '19

10 Sep '19

[snip] > *** error: gettext infrastructure mismatch: using a Makefile.in.in from gettext version 0.19 but the autoconf macros are from gettext version 0.20 > gmake[2]: *** [Makefile:237: stamp-po] Error 1 > gmake[2]: Leaving directory '<https://ci.centos.org/job/libosinfo-build/systems=libvirt-fedora-rawhide/ws…'> > gmake[1]: *** [Makefile:587: all-recursive] Error 1 > gmake[1]: Leaving directory '<https://ci.centos.org/job/libosinfo-build/systems=libvirt-fedora-rawhide/ws…'> > gmake: *** [Makefile:473: all] Error 2 > Build step 'Execute shell' marked build as failure > JFTR: Instead of spending time trying to figure out what's going on here, let's just get meson patches merged to libosinfo as, with that, we'll get rid of this for free. Ci: https://gitlab.com/fidencio/libosinfo/pipelines/81396029

1 0

[libvirt] [PATCH v4 0/8] CPU Model Baseline and Comparison for s390x
by Collin Walling 10 Sep '19

10 Sep '19

Changelog: v3 - rebased on master v2 - numerous cleanups - removed "policy fix function" and now properly check for policy == -1 in the CPUDef -> JSON parser - resolved some memory leaks - added string arg to qemuMonitorJSONParseCPUModelData for error message to print out proper command name v1 - introduce baseline - split patches into small chunks - free'd lingering qemuMonitorCPUModelInfo pointer - when converting from virCPUDef -> virJSON, consider feature policy FORCED for enabled ___ To run these patches, execute the virsh hypervisor-cpu-compare or hypervisor-cpu-baseline commands and pass an XML file describing one or more CPU definition. You can use the definition from virsh domcapabilities or from a guest XML. There is no need extract it from the file and place it a new one, as the XML parser will look specifically for the CPU tags. ___ These patches hookup the virsh hypervisor-cpu-compare/baseline commands for the s390x architecture. They take an XML file describing some CPU definitions and passes the data to QEMU, where the actual CPU model comparison / baseline calculation is handled (available since QEMU 2.8.5). These calculations are compared against / baselined with the hypervisor CPU model, which can be observed via the virsh domcapabilities command for s390x. When baselining CPU models and the user appends the --features argument to the command, s390x will only report back features that supersede the base model definition. *NOTE* if the --features flag is intended to expand /ALL/ features available to a CPU model (such as the huge list of features reported by a full CPU model expansion), please let me know and I can resolve this. The first patch pulls some code out of the CPU Model Expansion JSON function so that it can be later used for the Comparison and Baseline JSON functions. The rest of the patches follow this sequence: - introduce JSON monitor functions - introduce capability and update test files - hook up monitor functions to virsh command Patch 7 pulls out some code from the CPUDef XML parser to be reused in the comparison hookup. Thanks. x86 and Power review by Daniel Henrique Barboza (thanks!) Collin Walling (8): qemu_monitor: helper functions for CPU models qemu_monitor: implement query-cpu-model-baseline qemu_capabilities: introduce QEMU_CAPS_QUERY_CPU_MODEL_BASELINE qemu_driver: hook up query-cpu-model-baseline qemu_monitor: implement query-cpu-model-comparison qemu_capabilities: introduce QEMU_CAPS_QUERY_CPU_MODEL_COMPARISON cpu_conf: xml to cpu definition parse helper qemu_driver: hook up query-cpu-model-comparison src/conf/cpu_conf.c | 30 +++ src/conf/cpu_conf.h | 6 + src/cpu/cpu.c | 14 +- src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 136 +++++++++++ src/qemu/qemu_capabilities.h | 18 ++ src/qemu/qemu_driver.c | 38 +++ src/qemu/qemu_monitor.c | 44 ++++ src/qemu/qemu_monitor.h | 18 ++ src/qemu/qemu_monitor_json.c | 297 ++++++++++++++++++++--- src/qemu/qemu_monitor_json.h | 20 ++ tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_3.0.0.s390x.xml | 2 + tests/qemucapabilitiesdata/caps_4.0.0.s390x.xml | 2 + 18 files changed, 587 insertions(+), 49 deletions(-) -- 2.7.4

4 35

[libvirt] [PATCH] qemu: Fix regression in snapshot-revert
by Eric Blake 10 Sep '19

10 Sep '19

Commit f10562799 introduced a regression: if reverting to a snapshot fails early (such as when we refuse to revert to an external snapshot), we lose track of the domain's current snapshot. See: https://bugzilla.redhat.com/1738747 Signed-off-by: Eric Blake <eblake(a)redhat.com> --- src/qemu/qemu_driver.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index b28a26c3d6..093b15f500 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -16941,8 +16941,6 @@ qemuDomainRevertToSnapshot(virDomainSnapshotPtr snapshot, virDomainSnapshotSetCurrent(vm->snapshots, NULL); ret = -1; } - } else if (snap) { - virDomainSnapshotSetCurrent(vm->snapshots, NULL); } if (ret == 0 && config && vm->persistent && !(ret = virDomainSaveConfig(cfg->configDir, driver->caps, -- 2.21.0

2 3

[libvirt] [PATCH 0/7] qemu_command: clean up more labels (virtio-fs epopee)
by Ján Tomko 10 Sep '19

10 Sep '19

Ján Tomko (7): qemuBuildHostNetStr: remove unused cfg qemuBuildHostNetStr: remove unused 'driver' argument qemuBuildHostNetStr: remove unnecessary cleanup label qemuBuildSoundCommandLine: reduce scope of codecstr qemuBuildMemoryBackendProps: remove useless cleanup label qemuBuildMemoryBackendProps: use 'rc' instead of ret. qemuBuildMemoryCellBackendStr: remove useless ret variable src/qemu/qemu_command.c | 87 ++++++++++++++++++----------------------- src/qemu/qemu_command.h | 1 - src/qemu/qemu_hotplug.c | 2 +- 3 files changed, 38 insertions(+), 52 deletions(-) -- 2.19.2

2 8

[libvirt] Error when creating VM with persistent memory
by Seema Pandit 10 Sep '19

10 Sep '19

I am trying to create a VM with added persistent memory using virsh. It fails when persistent memory namespace size is larger than available system memory. Please see error below, prealloc=yes is set in the command line. For dax type namespace, as I understand, prealloc should not be needed. Is this support to add persistent memory implemented in virsh? If so, how to set prealloc=no? Anything else needed to add in xml for persistent memory? Thanks. 1. dax namespace (400GB) which is larger than system memory. # ndctl create-namespace -t pmem -m devdax --align=4k -s 400G { "dev":"namespace1.0", "mode":"devdax", "map":"dev", "size":"393.75 GiB (422.78 GB)", "uuid":"00670b70-7871-4749-a901-9184b7a388d8", "raw_uuid":"a5a1d3f8-01e4-45a2-bad1-38fd09bf4672", "daxregion":{ "id":1, "size":"393.75 GiB (422.78 GB)", "align":4096, "devices":[ { "chardev":"dax1.0", "size":"393.75 GiB (422.78 GB)" } ] }, "numa_node":1 } 2. Relevant parts of xml <domain type='kvm'> <name>test</name> <uuid>02c49a19-ce9e-4320-9a6b-1ebf0913a10e</uuid> <maxMemory slots='16' unit='KiB'>459800576</maxMemory> <memory unit='KiB'>65536000</memory> <currentMemory unit='KiB'>65536000</currentMemory> <vcpu placement='static'>4</vcpu> <os> : : <cpu mode='custom' match='exact' check='partial'> <feature policy='require' name='hypervisor'/> <numa> <cell id='0' cpus='0-3' memory='65536000' unit='KiB'/> </numa> </cpu> : : <memory model='nvdimm'> <source> <path>/dev/dax1.0</path> </source> <target> <size unit='GiB'>376</size> <node>0</node> <label> <size unit='KiB'>128</size> </label> </target> <address type='dimm' slot='0'/> </memory> 3. Error: # virsh start test error: Failed to start domain test error: internal error: qemu unexpectedly closed the monitor: ftruncate: Invalid argument 2019-08-22T04:16:08.744402Z qemu-system-x86_64: -object memory-backend-file,id=memnvdimm0,prealloc=yes,mem-path=/dev/dax1.0,size=403726925824: unable to map backing store for guest RAM: Cannot allocate memory Virsh version 4.7.0, qemu version 3.0.0

4 8