August 2018 - Devel - libvirt List Archives

[libvirt] [PATCH 0/2] Add .domainGetHostname() support for QEMU driver.
by Julio Faracco 20 Aug '18

20 Aug '18

This serie adds a new function into QEMU Guest Agent handlers to use the QEMU command 'guest-get-host-name' to retrieve the domain hostname. This approach requires QEMU-GA running inside the guest, but it is the fastest and easiest way to get this info. Julio Faracco (2): qemu: implementing qemuAgentGetHostname() function. qemu: adding domainGetHostname support for QEMU. src/qemu/qemu_agent.c | 39 +++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_agent.h | 4 ++++ src/qemu/qemu_driver.c | 41 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 84 insertions(+) -- 2.17.1

3 5

[libvirt] FYI: libvirt package on Fedora RISC-V
by Richard W.M. Jones 20 Aug '18

20 Aug '18

http://fedora-riscv.tranquillity.se/koji/taskinfo?taskID=95457 There were some minor changes to the spec file: https://src.fedoraproject.org/rpms/libvirt/c/18f7b8c79c2876b2d3a6ebe2279fd6… Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW

2 3

[libvirt] [PATCH v2 0/4] Fix a SIGSEGV in libvirtd when querying AMD SEV info
by Erik Skultety 20 Aug '18

20 Aug '18

This series fixes the following BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1612009 TL;DR: We don't format SEV platform data (PDH, certificate chain,...) into our qemu caps cache which poses a problem after libvirtd restart when we restore from the cache and get a segfault upon issuing virNodeGetSEVInfo. Since v1: - reworked patch 3 so that qemuMonitorJSONGetSEVCapabilities returns more values in order to distinguish between error and whether SEV is actually supported - added the missing backtrace to patch 4 - no other patches were changed apart from patch 3 Erik Skultety (4): tests: sev: Test launch-security with specific QEMU version qemu: Define and use a auto cleanup function with virSEVCapability qemu: Fix probing of AMD SEV support qemu: caps: Format SEV platform data into qemuCaps cache src/conf/domain_capabilities.h | 4 + src/qemu/qemu_capabilities.c | 127 +++++++++++++++++++-- src/qemu/qemu_monitor_json.c | 31 +++-- tests/domaincapsschemadata/qemu_2.12.0.x86_64.xml | 5 +- tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 6 + tests/qemucapabilitiesdata/caps_3.0.0.x86_64.xml | 1 - ...args => launch-security-sev.x86_64-2.12.0.args} | 19 +-- tests/qemuxml2argvtest.c | 4 +- 8 files changed, 164 insertions(+), 33 deletions(-) rename tests/qemuxml2argvdata/{launch-security-sev.args => launch-security-sev.x86_64-2.12.0.args} (54%) -- 2.14.4

2 6

[libvirt] X86CPU "feature-words" property on QEMU (was Re: [PATCH v3 1/3] x86: Data structure changes to support MSR based) features
by Eduardo Habkost 17 Aug '18

17 Aug '18

On Fri, Aug 17, 2018 at 07:34:13PM +0200, Paolo Bonzini wrote: > On 17/08/2018 17:55, Eduardo Habkost wrote: > >> The names will be X86_CPU_FEATURE_WORD_TYPE_CPUID and > >> X86_CPU_FEATURE_WORD_TYPE_MSR. > > I wouldn't like to make this an external API unless really > > necessary. I would rather deprecate the "feature-words" property > > because nobody ended up using it. > > I think we should either remove it directly, or extend it to support MSR > features. Deprecating and only supporting CPUID features is the worst > of both worlds... So let's do what's necessary to remove it. But I don't think the removal of "feature-words" should block the inclusion of this series. Now, should QOM properties follow our feature deprecation policy, or they were never a supported external API and we can remove it immediately? CCing Jiri and libvir-list, because I just found that there's code on libvirt that uses it, but I don't know exactly it does with that info. -- Eduardo

2 2

[libvirt] [PATCHv2 00/11] BaselineHypervisorCPU using QEMU QMP exchanges
by Chris Venteicher 17 Aug '18

17 Aug '18

Some architectures (S390) depend on QEMU to compute baseline CPU model and expand a models feature set. Interacting with QEMU requires starting the QEMU process and completing one or more query-cpu-model-baseline QMP exchanges with QEMU in addition to a query-cpu-model-expansion QMP exchange to expand all features in the model. See "s390x CPU models: exposing features" patch set on Qemu-devel for discussion of QEMU aspects. This is part of resolution of: https://bugzilla.redhat.com/show_bug.cgi?id=1511999 Version 2 address all issues raised by Collin as well as all other issues identified with additional testing. Chris Venteicher (11): qemu_monitor_json: Introduce qemuMonitorCPUModelInfo / JSON conversion qemu_monitor: Introduce qemuMonitorGetCPUModelBaseline (query-cpu-model-baseline) qemu_monitor: Indicate when CPUModelInfo props report migratablity qemu_monitor: Introduce qemuMonitorCPUModelInfoInit and qemuMonitorCPUModelInfoFreeContents qemu_monitor: CPUModelExpansion on both model name and properties qemu_monitor: Introduce qemuMonitorCPUModelInfoRemovePropByBoolValue qemu_capabilities: Introduce virCPUDef / qemuMonitorCPUModelInfo conversions qemu_capabilities: QMPCommandPtr without maintaining shadow qmperr qemu_capabilities: Persist QEMU instance over multiple QMP Cmds qemu_capabilities: Introduce virQEMUCapsQMPBaselineCPUModel (baseline using QEMU) qemu_driver: BaselineHypervisorCPU supports S390 using QEMU/QMP src/qemu/qemu_capabilities.c | 349 +++++++++++++++++++++++++++++------ src/qemu/qemu_capabilities.h | 33 ++++ src/qemu/qemu_driver.c | 74 +++++++- src/qemu/qemu_monitor.c | 117 +++++++++++- src/qemu/qemu_monitor.h | 21 ++- src/qemu/qemu_monitor_json.c | 232 +++++++++++++++++++---- src/qemu/qemu_monitor_json.h | 14 +- tests/cputest.c | 7 +- 8 files changed, 724 insertions(+), 123 deletions(-) -- 2.17.1

4 41

[libvirt] [PATCH] storage: Don't hold storage pool locked during wipeVol
by Michal Privoznik 17 Aug '18

17 Aug '18

Currently the way virStorageVolWipe() works is it looks up pool containing given volume and hold it locked throughout while API execution. This is suboptimal because wiping a volume means writing data to it which can take ages. And if the whole pool is locked during that operation no other API can be issued (nor pool-list). Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/storage/storage_backend_iscsi_direct.c | 5 +++++ src/storage/storage_backend_rbd.c | 7 ++++++- src/storage/storage_util.c | 8 +++++++- 3 files changed, 18 insertions(+), 2 deletions(-) diff --git a/src/storage/storage_backend_iscsi_direct.c b/src/storage/storage_backend_iscsi_direct.c index 1624066e9c..58d25557f1 100644 --- a/src/storage/storage_backend_iscsi_direct.c +++ b/src/storage/storage_backend_iscsi_direct.c @@ -691,6 +691,9 @@ virStorageBackenISCSIDirectWipeVol(virStoragePoolObjPtr pool, if (!(iscsi = virStorageBackendISCSIDirectSetConnection(pool, NULL))) return -1; + vol->in_use++; + virObjectUnlock(pool); + switch ((virStorageVolWipeAlgorithm) algorithm) { case VIR_STORAGE_VOL_WIPE_ALG_ZERO: if (virStorageBackendISCSIDirectVolWipeZero(vol, iscsi) < 0) { @@ -719,6 +722,8 @@ virStorageBackenISCSIDirectWipeVol(virStoragePoolObjPtr pool, cleanup: virISCSIDirectDisconnect(iscsi); iscsi_destroy_context(iscsi); + virObjectLock(pool); + vol->in_use--; return ret; } diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index 642cacb673..30c94c109b 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -1212,7 +1212,10 @@ virStorageBackendRBDVolWipe(virStoragePoolObjPtr pool, VIR_DEBUG("Wiping RBD image %s/%s", def->source.name, vol->name); if (!(ptr = virStorageBackendRBDNewState(pool))) - goto cleanup; + return -1; + + vol->in_use++; + virObjectUnlock(pool); if ((r = rbd_open(ptr->ioctx, vol->name, &image, NULL)) < 0) { virReportSystemError(-r, _("failed to open the RBD image %s"), @@ -1271,6 +1274,8 @@ virStorageBackendRBDVolWipe(virStoragePoolObjPtr pool, rbd_close(image); virStorageBackendRBDFreeState(&ptr); + virObjectLock(pool); + vol->in_use--; return ret; } diff --git a/src/storage/storage_util.c b/src/storage/storage_util.c index 42a9b6abf0..5c1fb7b7d3 100644 --- a/src/storage/storage_util.c +++ b/src/storage/storage_util.c @@ -2750,7 +2750,7 @@ storageBackendVolWipePloop(virStorageVolDefPtr vol, int -virStorageBackendVolWipeLocal(virStoragePoolObjPtr pool ATTRIBUTE_UNUSED, +virStorageBackendVolWipeLocal(virStoragePoolObjPtr pool, virStorageVolDefPtr vol, unsigned int algorithm, unsigned int flags) @@ -2759,6 +2759,9 @@ virStorageBackendVolWipeLocal(virStoragePoolObjPtr pool ATTRIBUTE_UNUSED, virCheckFlags(0, -1); + vol->in_use++; + virObjectUnlock(pool); + VIR_DEBUG("Wiping volume with path '%s' and algorithm %u", vol->target.path, algorithm); @@ -2769,6 +2772,9 @@ virStorageBackendVolWipeLocal(virStoragePoolObjPtr pool ATTRIBUTE_UNUSED, vol->target.allocation, false); } + virObjectLock(pool); + vol->in_use--; + return ret; } -- 2.16.4

2 3

[libvirt] Investigation and possible fix of 1361592 - apparmor profiles do not include backing files
by Povilas Kanapickas 17 Aug '18

17 Aug '18

Hi, I've looked into why apparmor profiles do not contain exceptions for backing files of images which later leads to permission errors due to apparmor containment. As of newest libvirt git master, only the first level backing image is included, the subsequent images are omitted. Below is my investigation of why this issue happens. It is based on libvirt git master as of 2018-08-15 (e3e48d7cb82d58). The possible fix is easy, but I don't have the background how to write tests for it, so it's best that someone who knows the project well completes the fix In my case I have the following file hierarchy: - image-master.qcow2 (has backing file image-backing-1.qcow2) - image-backing-1.qcow2 (has backing file image-backing-2.qcow2 - image-backing-2.qcow2 The apparmor profiles are created by the virt-aa-helper tool. The get_files function (src/security/virt-aa-helper.c:949) creates a list of files that need to be accessed by the virtual machine. The call to virDomainDiskDefForeachPath() is responsible for creating the list of files required to access each disk given the disk metadata. The disk->src argument contains the source file. The expected file hierarchy would be this: disk->src->path == path/to/image-master.qcow2 disk->src->backingStore->path == path/to/image-backing-1.qcow2 disk->src->backingStore->backingStore->path == path/to/image-backing-2.qcow2 Unfortunately only the first two levels are present and disk->src->backingStore->backingStore points to a dummy object. The backing store details are filled in virStorageFileGetMetadata() call. It calls into virStorageFileGetMetadataRecurse (src/util/virstoragefile.c:4789) which will collect metadata for a single image and recurse into itself for backing files. For us, the following part of virStorageFileGetMetadataRecurse is important (simplified for brevity): ``` virStorageFileGetMetadataInternal(src, ..., &backingFormat); if (src->backingStoreRaw) { backingStore = ... if (backingFormat == VIR_STORAGE_FILE_AUTO) backingStore->format = VIR_STORAGE_FILE_RAW; [1] else if (backingFormat == VIR_STORAGE_FILE_AUTO_SAFE) backingStore->format = VIR_STORAGE_FILE_AUTO; else backingStore->format = backingFormat; virStorageFileGetMetadataRecurse(backingStore, ...) [2] } ``` The crux of the issue seems that the call to virStorageFileGetMetadataInternal() for the image-master.qcow2 image will set the `backingFormat` return value to VIR_STORAGE_FILE_AUTO. The code responsible is in qcowXGetBackingStore (src/util/virstoragefile.c:491) called via `fileTypeInfo[meta->format].getBackingStore(...)` at src/util/virstoragefile.c:1042. It backingFormat is then downgraded to VIR_STORAGE_FILE_RAW at src/util/virstoragefile.c:4854 ([1] above). This causes the next recurse call to virStorageFileGetMetadataRecurse() ([2] above) to not investigate the backing images at all in virStorageFileGetMetadataInternal() as fileTypeInfo[VIR_STORAGE_FILE_RAW].getBackingStore will be NULL. The possible solution is to return VIR_STORAGE_FILE_AUTO_SAFE from qcowXGetBackingStore. It probably does not make much sense to prevent probing of qcow2 backing images as we probe the first level of backing images anyway, so that return value only affect second and subsequent levels of backing images. Looking into the implementation of qcowXGetBackingStore it also does not seem that it performs any operations that are unsafe by design. Currently VIR_STORAGE_FILE_AUTO is used only in qedGetBackingStore and it does not seem that probing of qcow images is unsafe enough What do the developers think about this? Could someone complete the fix with tests or advise me about the testing frameworks if there's not enough time? Thanks a lot! Povilas

2 3

[libvirt] [PATCH] qemu: hotplug: Fix asynchronous unplug of 'shmem'
by Peter Krempa 17 Aug '18

17 Aug '18

commit 5c81c342a7 forgot to skip the detaching of the shmem backend when async unplug is requested which meant that we've tried to unplug the backend prior to delivery of the DEVICE_DELETED event. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1618622 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_hotplug.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 5b52fe9edc..fa490c53e1 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -5479,11 +5479,16 @@ qemuDomainDetachShmemDevice(virQEMUDriverPtr driver, if (qemuDomainObjExitMonitor(driver, vm) < 0) goto cleanup; - if ((ret = qemuDomainWaitForDeviceRemoval(vm)) == 1) - ret = qemuDomainRemoveShmemDevice(driver, vm, shmem); + if (async) { + ret = 0; + } else { + if ((ret = qemuDomainWaitForDeviceRemoval(vm)) == 1) + ret = qemuDomainRemoveShmemDevice(driver, vm, shmem); + } cleanup: - qemuDomainResetDeviceRemoval(vm); + if (!async) + qemuDomainResetDeviceRemoval(vm); return ret; } -- 2.16.2

2 1

[libvirt] [PATCH 0/3] conf: qemu: support new Hyper-V enlightenments
by Vitaly Kuznetsov 16 Aug '18

16 Aug '18

Several new Hyper-V enlightenments were recently added to Qemu: - hv-frequencies - hv-reenlightenment - hv-tlbflush Support these in libvirt. Vitaly Kuznetsov (3): conf: qemu: add support for Hyper-V frequency MSRs conf: qemu: add support for Hyper-V reenlightenment notifications conf: qemu: add support for Hyper-V PV TLB flush docs/formatdomain.html.in | 21 +++++++++++++++++++++ docs/schemas/domaincommon.rng | 15 +++++++++++++++ src/conf/domain_conf.c | 14 +++++++++++++- src/conf/domain_conf.h | 3 +++ src/cpu/cpu_x86.c | 9 +++++++++ src/cpu/cpu_x86_data.h | 3 +++ src/qemu/qemu_command.c | 3 +++ src/qemu/qemu_parse_command.c | 3 +++ src/qemu/qemu_process.c | 3 +++ tests/qemuxml2argvdata/hyperv-off.xml | 3 +++ tests/qemuxml2argvdata/hyperv.args | 3 ++- tests/qemuxml2argvdata/hyperv.xml | 3 +++ tests/qemuxml2xmloutdata/hyperv-off.xml | 3 +++ tests/qemuxml2xmloutdata/hyperv.xml | 3 +++ 14 files changed, 87 insertions(+), 2 deletions(-) -- 2.14.4

3 5

[libvirt] [PATCH 0/4] Fix a SIGSEGV in libvirtd when querying AMD SEV info
by Erik Skultety 16 Aug '18

16 Aug '18

This series fixes the following BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1612009 TL;DR: We don't format SEV platform data (PDH, certificate chain,...) into our qemu caps cache which poses a problem after libvirtd restart when we restore from the cache and get a segfault upon issuing virNodeGetSEVInfo. I performed some tests on an AMD machine, but CC'ing Brijesh, he might give it a test too. Erik Skultety (4): tests: sev: Test launch-security with specific QEMU version qemu: Define and use a auto cleanup function with virSEVCapability qemu: Fix probing of AMD SEV support qemu: caps: Format SEV platform data into qemuCaps cache src/conf/domain_capabilities.h | 4 + src/qemu/qemu_capabilities.c | 112 +++++++++++++++++++-- src/qemu/qemu_monitor_json.c | 20 ++-- tests/domaincapsschemadata/qemu_2.12.0.x86_64.xml | 5 +- tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 6 ++ tests/qemucapabilitiesdata/caps_3.0.0.x86_64.xml | 1 - ...args => launch-security-sev.x86_64-2.12.0.args} | 19 ++-- tests/qemuxml2argvtest.c | 4 +- 8 files changed, 142 insertions(+), 29 deletions(-) rename tests/qemuxml2argvdata/{launch-security-sev.args => launch-security-sev.x86_64-2.12.0.args} (54%) -- 2.14.4

3 12