- Devel - libvirt List Archives

[libvirt] [RFC 0/4] add automatic cleanup functionality in some files
by Sukrit Bhatnagar 31 May '18

31 May '18

This series of patches aim at augmenting our discussion about the design for implementing the cleanup attribute. A set of macros have been added at the end of viralloc.h A few files have been modified to use the newly created macros. Sukrit Bhatnagar (4): add macros for implementing automatic cleanup functionality add automatic cleanup support in src/util/virarptable.c add automatic cleanup support in src/util/virauthconfig.c add automatic cleanup support in src/util/virauth.c src/util/viralloc.h | 69 ++++++++++++++++++++++++++++++++++++++++++++++++ src/util/virarptable.c | 9 ++----- src/util/virauth.c | 66 +++++++++++++++++---------------------------- src/util/virauthconfig.c | 34 +++++++++--------------- src/util/virauthconfig.h | 3 +++ 5 files changed, 110 insertions(+), 71 deletions(-) -- 1.8.3.1

3 10

[libvirt] ANNOUNCE: virt-bootstrap 1.1.0 released
by Cedric Bosdonnat 31 May '18

31 May '18

I'm happy to announce the release of virt-bootstrap 1.1.0! virt-bootstrap is a tool providing an easy way to setup the root file system for libvirt-based containers. The release can be downloaded from: http://virt-manager.org/download/ This release includes: - safe_untar: check for permissions to set attribs (Radostin Stoyanov) - docker source, support blobs without .tar extension (Radostin Stoyanov) - docker-source, preserve extended file attributes (Radostin Stoyanov) - docker-source, get list of layers without `--raw` (Radostin Stoyanov) - docker-source, void skopeo copy in cache (Radostin Stoyanov) - Show error when guestfs-python or skopeo is not installed (Radostin Stoyanov) - pylint cleanups (Radostin Stoyanov) Thanks to everyone who has contributed to this release through testing, bug reporting, submitting patches, and otherwise sending in feedback! Thanks, -- Cédric

1 0

[libvirt] [PATCH] testUpdateQEMUCaps: Don't leak host cpuData
by Michal Privoznik 31 May '18

31 May '18

When preparing qemuCaps for test cases the following is happening: qemuTestParseCapabilitiesArch() is called, which calls virQEMUCapsLoadCache() which in turn calls virQEMUCapsInitHostCPUModel() which sets qemuCaps->kvmCPU and qemuCaps->tcgCPU. But then the code tries to update the capabilities: testCompareXMLToArgv() calls testUpdateQEMUCaps() which calls virQEMUCapsInitHostCPUModel() again overwriting previously allocated memory. The solution is to free host cpuData in testUpdateQEMUCaps(). Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- Technically this is v2 of [1] but since it implements completely different approach I'm sending it as v1. 1: https://www.redhat.com/archives/libvir-list/2018-May/msg02260.html src/qemu/qemu_capabilities.c | 21 +++++++++++++++++++-- src/qemu/qemu_capspriv.h | 4 ++++ tests/qemuxml2argvtest.c | 3 +++ 3 files changed, 26 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index e2e76e4dd8..ea1ff520d8 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -1516,12 +1516,19 @@ virQEMUCapsHostCPUDataCopy(virQEMUCapsHostCPUDataPtr dst, static void -virQEMUCapsHostCPUDataClear(virQEMUCapsHostCPUDataPtr cpuData) +virQEMUCapsHostCPUDataClearHostCPU(virQEMUCapsHostCPUDataPtr cpuData) { - qemuMonitorCPUModelInfoFree(cpuData->info); virCPUDefFree(cpuData->reported); virCPUDefFree(cpuData->migratable); virCPUDefFree(cpuData->full); +} + + +static void +virQEMUCapsHostCPUDataClear(virQEMUCapsHostCPUDataPtr cpuData) +{ + qemuMonitorCPUModelInfoFree(cpuData->info); + virQEMUCapsHostCPUDataClearHostCPU(cpuData); memset(cpuData, 0, sizeof(*cpuData)); } @@ -2834,6 +2841,16 @@ virQEMUCapsNewHostCPUModel(void) } +void +virQEMUCapsFreeHostCPUModel(virQEMUCapsPtr qemuCaps, + virDomainVirtType type) +{ + virQEMUCapsHostCPUDataPtr cpuData = virQEMUCapsGetHostCPUData(qemuCaps, type); + + virQEMUCapsHostCPUDataClearHostCPU(cpuData); +} + + void virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps, virArch hostArch, diff --git a/src/qemu/qemu_capspriv.h b/src/qemu/qemu_capspriv.h index 0199501c93..fea039ef3a 100644 --- a/src/qemu/qemu_capspriv.h +++ b/src/qemu/qemu_capspriv.h @@ -56,6 +56,10 @@ void virQEMUCapsSetArch(virQEMUCapsPtr qemuCaps, virArch arch); +void +virQEMUCapsFreeHostCPUModel(virQEMUCapsPtr qemuCaps, + virDomainVirtType type); + void virQEMUCapsInitHostCPUModel(virQEMUCapsPtr qemuCaps, virArch hostArch, diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index a6a40e273e..61c7ae59aa 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -388,6 +388,9 @@ testUpdateQEMUCaps(const struct testInfo *info, if (testAddCPUModels(info->qemuCaps, info->skipLegacyCPUs) < 0) goto cleanup; + virQEMUCapsFreeHostCPUModel(info->qemuCaps, VIR_DOMAIN_VIRT_KVM); + virQEMUCapsFreeHostCPUModel(info->qemuCaps, VIR_DOMAIN_VIRT_QEMU); + virQEMUCapsInitHostCPUModel(info->qemuCaps, caps->host.arch, VIR_DOMAIN_VIRT_KVM); virQEMUCapsInitHostCPUModel(info->qemuCaps, caps->host.arch, -- 2.16.4

2 1

[libvirt] [PATCH v2 0/5] qemu: Forbid old qcow/qcow2 encryption
by Peter Krempa 31 May '18

31 May '18

The old qcow/qcow2 encryption format is so broken that qemu decided to drop it completely. This series forbids the use of such images even with qemus prior to this and removes all the cruft necessary to support it. v2: - fixed check to include the qcow format too - reworded the error message slightly - split second patch into two with proper justification for the user-alias test since checking LUKS there actually makes sense Peter Krempa (5): tests: qemuxml2argv: Drop disk encryption from 'interface-server' test tests: qemuxml2argv: Verify that disk secret alias is correct with user-aliases tests: qemublock: Switch to qcow2+luks in test files qemu: domain: Forbid storage with old QCOW2 encryption qemu: Remove code for setting up disk passphrases src/qemu/qemu_domain.c | 10 ++ src/qemu/qemu_monitor.c | 13 --- src/qemu/qemu_monitor.h | 4 - src/qemu/qemu_monitor_json.c | 28 ------ src/qemu/qemu_monitor_json.h | 4 - src/qemu/qemu_process.c | 103 --------------------- .../file-qcow2-backing-chain-encryption.json | 2 +- .../file-qcow2-backing-chain-encryption.xml | 2 +- ...etwork-qcow2-backing-chain-encryption_auth.json | 2 +- ...network-qcow2-backing-chain-encryption_auth.xml | 2 +- tests/qemumonitorjsontest.c | 2 - tests/qemuxml2argvdata/encrypted-disk-usage.args | 8 +- tests/qemuxml2argvdata/encrypted-disk-usage.xml | 2 +- tests/qemuxml2argvdata/encrypted-disk.args | 8 +- tests/qemuxml2argvdata/encrypted-disk.xml | 2 +- tests/qemuxml2argvdata/interface-server.xml | 3 - tests/qemuxml2argvdata/user-aliases.args | 8 +- tests/qemuxml2argvdata/user-aliases.xml | 2 +- tests/qemuxml2argvtest.c | 7 +- tests/qemuxml2xmloutdata/encrypted-disk.xml | 2 +- tests/qemuxml2xmloutdata/interface-server.xml | 3 - tests/qemuxml2xmltest.c | 6 +- 22 files changed, 46 insertions(+), 177 deletions(-) -- 2.16.2

3 14

[libvirt] [PATCH 00/38] qemu: Refactor secret/TLS setup and add TLS for nbd
by Peter Krempa 31 May '18

31 May '18

This series consists of the following changes: 1) refactors to handling of the TLS object and secret alias 2) storage of 'secret' object aliases in the status XML 3) fix of disk-unplug with TLS after libvirtd restart 4) Adding support for TLS for NBD disks (originally used to reproduce problem with detach of TLS object after libvirtd restart) Few parts could be considered separate but since the end of the series builds up on the various pieces it would be very unpleasant to post separately. Peter Krempa (38): qemu: domain: Add helper to check if encrypted secrets can be used with a VM qemu: domain: Reuse code when preparing hostdev auth secrets qemu: domain: Rename qemuDomainSecretDiskCapable qemu: domain: Rename and fix docs for qemuDomainSecretInfoNew qemu: domain: Add new function to set up encrypted secrets only qemu: domain: Setup disk encryption password secret via new helper qemu: domain: Use qemuDomainSecretInfoNewPlain only for unencrypted secrets qemu: domain: Add helpers for partially clearing qemuDomainSecretInfoPtr qemu: domain: Don't delete aliases of secret objects associated with disks qemu: Store and parse disk authentication and encryption secret alias tests: qemustatusxml2xml: Add test data for re-generating LUKS/auth aliases qemu: domain: Regenerate auth/enc secret aliases when restoring status XML qemu: hotplug: Don't try to infer secret object alias/presence qemu: hotplug: Use 'tlsAlias' to see whether to detach the disk qemu: domain: Store and restore TLS object alias of a disk qemu: domain: Regenerate alias for the TLS x509 credential object qemu: domain: Properly setup data relevant for top disk image qemu: domain: don't loop through images in qemuDomainPrepareDiskSourceChain qemu: domain: Split validation and setup of the virStorageSource qemu: domain: aggregate setup of disk drive options for -drive qemu: domain: Separate setup of TLS for VXHS disks from qemuDomainPrepareDiskSourceTLS qemu: domain: Use switch statement in qemuDomainPrepareDiskSourceTLS qemu: domain: Process only one object in qemuDomainPrepareDiskSourceTLS qemu: domain: Forbid TLS setup for disk protocols not supporting it conf: Don't encode matrix of storage protocols supporting TLS in the parser qemu: hotplug: Don't mandate passing of 'secAlias' in qemuDomainGetTLSObjects qemu: hotplug: Allow passing in NULL 'tlsAlias' to qemuDomainGetTLSObjects qemu: domain: Set up disk TLS alias when preparing TLS setup qemu: command: Don't generate alias for TLS private key password secret qemu: command: Pass in alias for TLS object to qemuBuildTLSx509CommandLine qemu: command: Always setup TLS environment if src->haveTLS is on qemu: migration: Don't pass around secAlias qemu: hotplug: Pass around existing secret object alias from qemuDomainAddChardevTLSObjects qemu: hotplug: Remove misleading comment in qemuDomainGetTLSObjects qemu: hotplug: Drop 'secAlias' output parameter from qemuDomainGetTLSObjects qemu: hotplug: Remove TLS alias generation from qemuDomainGetTLSObjects tests: qemu: Rename disk-drive-network-tlsx509-vxhs test qemu: domain: Add support for TLS for NBD with default TLS env docs/schemas/domaincommon.rng | 5 + src/conf/domain_conf.c | 14 +- src/qemu/qemu_command.c | 75 ++- src/qemu/qemu_domain.c | 658 +++++++++++++++------ src/qemu/qemu_domain.h | 20 +- src/qemu/qemu_hotplug.c | 95 ++- src/qemu/qemu_hotplug.h | 5 +- src/qemu/qemu_migration.c | 8 +- src/qemu/qemu_migration_params.c | 23 +- src/qemu/qemu_migration_params.h | 1 - tests/qemublocktest.c | 9 +- .../disk-secinfo-upgrade-in.xml | 517 ++++++++++++++++ .../disk-secinfo-upgrade-out.xml | 538 +++++++++++++++++ tests/qemustatusxml2xmldata/modern-in.xml | 5 + ...9-vxhs.args => disk-drive-network-tlsx509.args} | 9 +- ...509-vxhs.xml => disk-drive-network-tlsx509.xml} | 8 + tests/qemuxml2argvtest.c | 4 +- ...509-vxhs.xml => disk-drive-network-tlsx509.xml} | 8 + tests/qemuxml2xmltest.c | 3 +- 19 files changed, 1663 insertions(+), 342 deletions(-) create mode 100644 tests/qemustatusxml2xmldata/disk-secinfo-upgrade-in.xml create mode 100644 tests/qemustatusxml2xmldata/disk-secinfo-upgrade-out.xml rename tests/qemuxml2argvdata/{disk-drive-network-tlsx509-vxhs.args => disk-drive-network-tlsx509.args} (82%) rename tests/qemuxml2argvdata/{disk-drive-network-tlsx509-vxhs.xml => disk-drive-network-tlsx509.xml} (85%) rename tests/qemuxml2xmloutdata/{disk-drive-network-tlsx509-vxhs.xml => disk-drive-network-tlsx509.xml} (86%) -- 2.16.2

3 89

[libvirt] [PATCH] audit: Enforce enum switch type cast in virDomainAuditHostdev
by Erik Skultety 31 May '18

31 May '18

There was a missing enum for mdev causing a strange 'unknown device type' warning when hot-plugging mdev. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1583927 Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- src/conf/domain_audit.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/src/conf/domain_audit.c b/src/conf/domain_audit.c index 82868bca76..14138d93af 100644 --- a/src/conf/domain_audit.c +++ b/src/conf/domain_audit.c @@ -361,6 +361,7 @@ virDomainAuditHostdev(virDomainObjPtr vm, virDomainHostdevDefPtr hostdev, virDomainHostdevSubsysPCIPtr pcisrc = &hostdev->source.subsys.u.pci; virDomainHostdevSubsysSCSIPtr scsisrc = &hostdev->source.subsys.u.scsi; virDomainHostdevSubsysSCSIVHostPtr hostsrc = &hostdev->source.subsys.u.scsi_host; + virDomainHostdevSubsysMediatedDevPtr mdevsrc = &hostdev->source.subsys.u.mdev; virUUIDFormat(vm->def->uuid, uuidstr); if (!(vmname = virAuditEncode("vm", vm->def->name))) { @@ -373,9 +374,9 @@ virDomainAuditHostdev(virDomainObjPtr vm, virDomainHostdevDefPtr hostdev, virt = "?"; } - switch (hostdev->mode) { + switch ((virDomainHostdevMode) hostdev->mode) { case VIR_DOMAIN_HOSTDEV_MODE_SUBSYS: - switch (hostdev->source.subsys.type) { + switch ((virDomainHostdevSubsysType) hostdev->source.subsys.type) { case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI: if (virAsprintfQuiet(&address, "%.4x:%.2x:%.2x.%.1x", pcisrc->addr.domain, @@ -419,6 +420,13 @@ virDomainAuditHostdev(virDomainObjPtr vm, virDomainHostdevDefPtr hostdev, goto cleanup; } break; + case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV: + if (VIR_STRDUP_QUIET(address, mdevsrc->uuidstr) < 0) { + VIR_WARN("OOM while enconding audit message"); + goto cleanup; + } + break; + case VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_LAST: default: VIR_WARN("Unexpected hostdev type while encoding audit message: %d", hostdev->source.subsys.type); @@ -470,6 +478,7 @@ virDomainAuditHostdev(virDomainObjPtr vm, virDomainHostdevDefPtr hostdev, } break; + case VIR_DOMAIN_HOSTDEV_MODE_LAST: default: VIR_WARN("Unexpected hostdev mode while encoding audit message: %d", hostdev->mode); -- 2.14.3

3 5

[libvirt] [PATCH 1/1] conf: fixup USB input bus check
by Xiao Feng Ren 31 May '18

31 May '18

This patch fixes the USB input bus check, the bug was introduced by commit 317badb Signed-off-by: Xiao Feng Ren <renxiaof(a)linux.vnet.ibm.com> --- src/conf/domain_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 27e2bd50eb..e4d39c06e8 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -27878,7 +27878,7 @@ virDomainDeviceIsUSB(virDomainDeviceDefPtr dev) if ((t == VIR_DOMAIN_DEVICE_DISK && dev->data.disk->bus == VIR_DOMAIN_DISK_BUS_USB) || (t == VIR_DOMAIN_DEVICE_INPUT && - dev->data.input->type == VIR_DOMAIN_INPUT_BUS_USB) || + dev->data.input->bus == VIR_DOMAIN_INPUT_BUS_USB) || (t == VIR_DOMAIN_DEVICE_HOSTDEV && dev->data.hostdev->mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS && dev->data.hostdev->source.subsys.type == -- 2.16.3

2 1

[libvirt] [PATCH 0/3] Fix more memory leaks
by Michal Privoznik 31 May '18

31 May '18

Ideally, these would be merged before the release. But I don't have strong opinion on that. Michal Privoznik (3): virDomainDefParseXML: Free @tmp when parsing genid qemuxml2argvtest: Don't initialize qemuCaps twice virQEMUCapsSetHostModel: Free cpuData before setting it src/conf/domain_conf.c | 1 + src/qemu/qemu_capabilities.c | 4 ++++ tests/qemuxml2argvtest.c | 2 -- 3 files changed, 5 insertions(+), 2 deletions(-) -- 2.16.1

3 13

[libvirt] [PATCH 0/1] bug: fixup USB input bus check
by Xiao Feng Ren 31 May '18

31 May '18

There's one explicit bug(introduced in commit:317badb) when checking the bus of one input device is USB. Let's fix it. Xiao Feng Ren (1): Fixup USB input bus check src/conf/domain_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.16.3

2 3

[libvirt] What is the strategy to update the CPU Models in src/cpu/cpu_map.xml based on?
by Dou Liyang 31 May '18

31 May '18

Hi All, I am not sure about the update strategy of CPU models in libvirt. IMO, It's depend on the CPU model in qemu-kvm, if some CPU models were updated in qemu-kvm. Then, we should modify the src/cpu/cpu_map.xml of libvirt to synchronize? eg: commit cad8054ece28("cpu: Add cpu definition for Intel Sandy Bridge cpu type") in libvirt upstream. https://bugzilla.redhat.com/show_bug.cgi?id=761005 If it's right, I found this commit b3a4f0b1a072("target-i386: add VME to all CPUs") updated the VME feature in qemu upstream. But in the src/cpu /cpu_map.xml of libvirt, It didn't be updated. eg: For the SandyBridge CPU, - In QEmu, it has the 'vme' feature defined by CPUID_VME - In libvirt, it doesn't has the 'vme' in cpu_map.xml file. Why? Thanks, dou

3 9

Re: [libvirt] What is the strategy to update the CPU Models in src/cpu/cpu_map.xml based on?
by Peter Krempa 31 May '18

31 May '18

[re-adding libvir-list] On Wed, May 30, 2018 at 19:36:10 +0800, Dou Liyang wrote: > Hi Peter, > > Sorry to trouble you offline. Please keep conversations on the list, so that it does not get lost in private inboxes. > Recently, I forced on the PCID feature in CPU and > found the SandyBridge didn't include the PCID feature > in libvirt. > > commit cad8054ece285d1712880cd108e8a39f833f7e88 > Author: Peter Krempa <pkrempa(a)redhat.com> > Date: Wed Feb 8 12:43:07 2012 +0100 > > cpu: Add cpu definition for Intel Sandy Bridge cpu type > > I knew the SandyBridge CPU models in QEMU also > didn't include the PCID feature. > > I want to know: > > - If we can't make sure PCID was supported in all SandyBridge? > - If we avoided PCID definition intentionally ? > - If we forgot to add it, and need to be fixed? Qemu added it later than libvirt added the sandy-bridge cpu: commit 434acb817b8ae747f31e91ec152f9f47ac514433 Author: Mao, Junjie <junjie.mao(a)intel.com> Date: Fri Jul 20 07:08:21 2012 +0000 Recognize PCID feature This patch makes Qemu recognize the PCID feature specified from configuration or command line options. Jiri Denemark already covered why we can't/will not change existing models in cpu_map.xml > > Thanks, > dou

3 3

[libvirt] [PATCH 0/5] storage: implement a skeleton for volume events.
by Julio Faracco 31 May '18

31 May '18

The series add a skeleton for a lifecycle event (and other events in the future) for volumes to cover actions like create and delete. Others events can be added in the future, but the storage driver has some functions to support it. Related: https://bugzilla.redhat.com/show_bug.cgi?id=1578836 Julio Faracco (5): storage: adding a skeleton for libvirt volume events. driver: adding two new driver functions to support volume events. conf: implementing some functions to generate volume events. virsh: implementing 'vol-event' command. examples: adding volume events into event-test example. examples/object-events/event-test.c | 65 ++++++++++ include/libvirt/libvirt-storage.h | 86 +++++++++++++ src/conf/storage_event.c | 155 ++++++++++++++++++++++ src/conf/storage_event.h | 19 +++ src/driver-storage.h | 13 ++ src/libvirt-storage.c | 125 ++++++++++++++++++ src/libvirt_private.syms | 2 + src/libvirt_public.syms | 6 + tools/virsh-completer.c | 27 ++++ tools/virsh-completer.h | 4 + tools/virsh-volume.c | 192 ++++++++++++++++++++++++++++ tools/virsh-volume.h | 8 ++ 12 files changed, 702 insertions(+) -- 2.17.0

3 7

[libvirt] [PATCH 0/2] qemu: block: Add more tests and support for pr-manager
by Peter Krempa 30 May '18

30 May '18

Note that patch 1 can be applied only with the series adding TLS support for NBD. Patch 2 is independent. Peter Krempa (2): tests: qemublock: Test NBD with TLS qemu: block: Add support for 'pr-manager' in qemuBlockStorageSourceGetFileProps src/qemu/qemu_block.c | 5 +++++ tests/qemublocktest.c | 2 ++ .../xml2json/block-raw-reservations.json | 14 ++++++++++++++ .../xml2json/block-raw-reservations.xml | 14 ++++++++++++++ .../qemublocktestdata/xml2json/network-nbd-tls.json | 20 ++++++++++++++++++++ tests/qemublocktestdata/xml2json/network-nbd-tls.xml | 18 ++++++++++++++++++ 6 files changed, 73 insertions(+) create mode 100644 tests/qemublocktestdata/xml2json/block-raw-reservations.json create mode 100644 tests/qemublocktestdata/xml2json/block-raw-reservations.xml create mode 100644 tests/qemublocktestdata/xml2json/network-nbd-tls.json create mode 100644 tests/qemublocktestdata/xml2json/network-nbd-tls.xml -- 2.16.2

2 4

[libvirt] [PATCH 0/2] Trivial memory leak fixes
by Ján Tomko 30 May '18

30 May '18

Hopefully pushed as trivial by the time you're reading this message. Ján Tomko (2): qemu: free migEvent in qemuMigrationCapsCheck conf: fix vsock memory leaks src/conf/domain_conf.c | 2 ++ src/qemu/qemu_migration_params.c | 1 + 2 files changed, 3 insertions(+) -- 2.16.1

2 4

[libvirt] [PATCH] vmx: Remove check that numvcpus has to be an even number.
by Richard W.M. Jones 30 May '18

30 May '18

This patch removes what appears to be an unnecessary check in the VMX driver which is preventing us from importing guests that have an odd number of vCPUs with virt-v2v. Unfortunately to test this it seems you need a real VMware server somewhere (substitute for ‘example.com’ below). Download the VMX file attached to https://bugzilla.redhat.com/show_bug.cgi?id=1584091 $ virsh -c 'esx://example.com' domxml-from-native vmware-vmx window2016.vmx Enter root's password for example.com: error: internal error: Expecting VMX entry 'numvcpus' to be an unsigned integer (1 or a multiple of 2) but found 7 After applying the patch: $ ~/d/libvirt/run ~/d/libvirt/tools/virsh -c 'esx://example.com' domxml-from-native vmware-vmx window2016.vmx Enter root's password for example.com: <domain type='vmware'> ... <cpu> <topology sockets='1' cores='7' threads='1'/> ... Rich.

3 3

[libvirt] [PATCH] spec: Fix permissions of nwfilter XMLs
by Jiri Denemark 30 May '18

30 May '18

The nwfilter XMLs in /etc are defined as %ghost in the spec file, which means rpm will not install them, but it will record its existence and permissions in the database. During installation the files are copied in a %post scriptlet from /usr/share/libvirt/nwfilter, but once libvirtd is restarted, it will rewrite the files to add generated UUIDs. While RPM recorded 644 mode for the XMLs, libvirt saves them with 600 and thus any future attempt to verify the libvirt-daemon-config-nwfilter package would fail. We need to tell RPM the ghost files are supposed to have 600 permissions. https://bugzilla.redhat.com/show_bug.cgi?id=1559284 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- libvirt.spec.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libvirt.spec.in b/libvirt.spec.in index 5e1e1df3f0..17d5d4dff7 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -1369,6 +1369,8 @@ rm -f $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/qemu/networks/autostart/default.xml install -d -m 0755 $RPM_BUILD_ROOT%{_datadir}/libvirt/nwfilter/ cp -a $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/nwfilter/*.xml \ $RPM_BUILD_ROOT%{_datadir}/libvirt/nwfilter/ +# libvirt saves these files with mode 600 +chmod 600 $RPM_BUILD_ROOT%{_sysconfdir}/libvirt/nwfilter/*.xml # Strip auto-generated UUID - we need it generated per-install sed -i -e "/<uuid>/d" $RPM_BUILD_ROOT%{_datadir}/libvirt/networks/default.xml -- 2.17.0

2 1

[libvirt] [PATCH] tests: initialize some variables
by Ján Tomko 30 May '18

30 May '18

Found by cppcheck: [tests/metadatatest.c:284]: (error) Uninitialized variable: test [tests/objecteventtest.c:855]: (error) Uninitialized variable: test Signed-off-by: Ján Tomko <jtomko(a)redhat.com> --- tests/metadatatest.c | 2 +- tests/objecteventtest.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/metadatatest.c b/tests/metadatatest.c index d5a6f37119..b17a85c883 100644 --- a/tests/metadatatest.c +++ b/tests/metadatatest.c @@ -268,7 +268,7 @@ testTextMetadata(const void *data) static int mymain(void) { - struct metadataTest test; + struct metadataTest test = { 0 }; int ret = EXIT_SUCCESS; if (!(test.conn = virConnectOpen("test:///default"))) diff --git a/tests/objecteventtest.c b/tests/objecteventtest.c index 4b12572eb4..e6de11ec39 100644 --- a/tests/objecteventtest.c +++ b/tests/objecteventtest.c @@ -835,7 +835,7 @@ timeout(int id ATTRIBUTE_UNUSED, void *opaque ATTRIBUTE_UNUSED) static int mymain(void) { - objecteventTest test; + objecteventTest test = { 0 }; int ret = EXIT_SUCCESS; int timer; -- 2.16.1

2 1

[libvirt] [PATCH] storage: Add specific check for LUKS encryption support
by John Ferlan 30 May '18

30 May '18

Modify virStorageBackendLogicalLVCreate to ensure if encryption is requested that only type LUKS is supported; otherwise, error. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- src/storage/storage_backend_logical.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/storage/storage_backend_logical.c b/src/storage/storage_backend_logical.c index edd4971f1f..67ca7f514d 100644 --- a/src/storage/storage_backend_logical.c +++ b/src/storage/storage_backend_logical.c @@ -938,6 +938,13 @@ virStorageBackendLogicalLVCreate(virStorageVolDefPtr vol, unsigned long long capacity = vol->target.capacity; virCommandPtr cmd = NULL; + if (vol->target.encryption && + vol->target.encryption->format != VIR_STORAGE_ENCRYPTION_FORMAT_LUKS) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("storage pool only supports LUKS encrypted volumes")); + return -1; + } + cmd = virCommandNewArgList(LVCREATE, "--name", vol->name, NULL); @@ -953,8 +960,7 @@ virStorageBackendLogicalLVCreate(virStorageVolDefPtr vol, /* If we're going to encrypt using LUKS, then we could need up to * an extra 2MB for the LUKS header - so account for that now */ - if (vol->target.encryption && - vol->target.encryption->format == VIR_STORAGE_ENCRYPTION_FORMAT_LUKS) + if (vol->target.encryption) capacity += 2 * 1024 * 1024; virCommandAddArgFormat(cmd, "%lluK", VIR_DIV_UP(capacity, 1024)); -- 2.14.3

2 1

Re: [libvirt] [PATCH] vfio/pci: Default display option to "off"
by Alex Williamson 30 May '18

30 May '18

[Cc +Erik,libvirt] Sorry, should have cc'd libvirt with this initially since display support is under development. I think "off" is the better compatibility option, but perhaps the damage is done since it was the 2.12 default. Thanks, Alex On Tue, 29 May 2018 09:18:10 -0600 Alex Williamson <alex.williamson(a)redhat.com> wrote: > Commit a9994687cb9b ("vfio/display: core & wireup") added display > support to vfio-pci with the default being "auto", which breaks > existing VMs when the vGPU requires GL support but had no previous > requirement for a GL compatible configuration. "Off" is the safer > default as we impose no new requirements to VM configurations. > > Fixes: a9994687cb9b ("vfio/display: core & wireup") > Cc: qemu-stable(a)nongnu.org > Cc: Gerd Hoffmann <kraxel(a)redhat.com> > Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com> > --- > hw/vfio/pci.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c > index 84e27c7bb2d1..18c493b49ec1 100644 > --- a/hw/vfio/pci.c > +++ b/hw/vfio/pci.c > @@ -3160,7 +3160,7 @@ static Property vfio_pci_dev_properties[] = { > DEFINE_PROP_PCI_HOST_DEVADDR("host", VFIOPCIDevice, host), > DEFINE_PROP_STRING("sysfsdev", VFIOPCIDevice, vbasedev.sysfsdev), > DEFINE_PROP_ON_OFF_AUTO("display", VFIOPCIDevice, > - display, ON_OFF_AUTO_AUTO), > + display, ON_OFF_AUTO_OFF), > DEFINE_PROP_UINT32("x-intx-mmap-timeout-ms", VFIOPCIDevice, > intx.mmap_timeout, 1100), > DEFINE_PROP_BIT("x-vga", VFIOPCIDevice, features, >

2 1

Re: [libvirt] [PATCH] virtlockd: acquire locks on re-exec
by Matthew Richardson 30 May '18

30 May '18

> Locks held by virtlockd are dropped on re-exec. > > virtlockd 94306 POSIX 5.4G WRITE 0 0 0 /tmp/test.qcow2 > virtlockd 94306 POSIX 5B WRITE 0 0 0 /run/virtlockd.pid > virtlockd 94306 POSIX 5B WRITE 0 0 0 /run/virtlockd.pid > > Acquire locks in PostExecRestart code path. > > Signed-off-by: Jim Fehlig <jfehlig@xxxxxxxx> I've just encountered this same unexpected behaviour (currently on RHEL7 box running libvirt 3.2), and found this thread while searching for a bug report. Has this patch been accepted, or the issue fixed in a later release? I notice there was some confusion in the conversation following as to the cause of this issue/the fix for it. If not, is there a bug open against this which I can follow/comment on? Cheers, Matthew The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

2 1

[libvirt] [PATCH 00/22] New CPU related APIs
by Jiri Denemark 29 May '18

29 May '18

The current virConnectCompareCPU and virConnectBaselineCPU APIs are not very useful because they ignore what a hypervisor can do on the current host. This series adds two new APIs which are designed to work with capabilities of a specific hypervisor to provide usable results. The third CPU related API virConnectGetCPUModelNames is pretty useless too, but no new API with similar functionality is needed because domain capabilities XML already contains the relevant data. Jiri Denemark (22): virsh: Move cpu-{baseline,compare} commands virsh: Extract common code from cmdCPU{Compare,Baseline} virsh: Enhance documentation of cpu-compare command virsh: Enhance documentation of cpu-models command Improve documentation of virConnectGetCPUModelNames vshExtractCPUDefXML: Accept domain capabilities XML qemu_capabilities: Introduce virQEMUCapsCacheLookupDefault Introduce virConnectCompareHypervisorCPU public API remote: Implement virConnectCompareHypervisorCPU virsh: Introduce new hypervisor-cpu-compare command qemu: Implement virConnectCompareHypervisorCPU Introduce virConnectBaselineHypervisorCPU public API remote: Implement virConnectBaselineHypervisorCPU virsh: Introduce new hypervisor-cpu-baseline command cpu: Rename cpuBaseline as virCPUBaseline cpu_x86: Add support for passing guest CPUs to virCPUx86Baseline cpu: Add explicit arch parameter for virCPUBaseline cpu: Update style in virCPUBaseline cpu: Add optional list of allowed features to virCPUBaseline qemu_capabilities: Introduce virQEMUCapsGetCPUFeatures qemu: Implement virConnectBaselineHypervisorCPU news: Mention new CPU related APIs docs/news.xml | 9 + include/libvirt/libvirt-host.h | 15 ++ src/bhyve/bhyve_driver.c | 4 +- src/cpu/cpu.c | 34 ++- src/cpu/cpu.h | 21 +- src/cpu/cpu_arm.c | 11 +- src/cpu/cpu_ppc64.c | 5 +- src/cpu/cpu_x86.c | 35 ++- src/driver-hypervisor.h | 20 ++ src/libvirt-host.c | 161 +++++++++++- src/libvirt_private.syms | 2 +- src/libvirt_public.syms | 6 + src/libxl/libxl_driver.c | 4 +- src/qemu/qemu_capabilities.c | 170 +++++++++++++ src/qemu/qemu_capabilities.h | 12 + src/qemu/qemu_driver.c | 241 ++++++++++++------ src/remote/remote_driver.c | 4 +- src/remote/remote_protocol.x | 40 ++- src/remote_protocol-structs | 27 ++ src/test/test_driver.c | 2 +- src/vz/vz_driver.c | 2 +- tests/cputest.c | 6 +- tools/virsh-domain.c | 223 ----------------- tools/virsh-host.c | 441 +++++++++++++++++++++++++++++++++ tools/virsh.pod | 90 ++++++- 25 files changed, 1223 insertions(+), 362 deletions(-) -- 2.17.0

5 90

[libvirt] [PATCH 0/2] bhyve: add CPU topology support
by Roman Bogorodskiy 29 May '18

29 May '18

This series adds support for specifying CPU topology for bhyve guests. This also would need domxml-from-native support that I plan to add separately. I've updated docs to mention 4.4.0, but more probably it'll go to 4.5.0 as the freeze is close and I'm not sure I'll be able to turn around before it. Roman Bogorodskiy (2): bhyve: add CPU topology support docs: bhyve: document guest CPU topology feature docs/drvbhyve.html.in | 16 ++++++++++++ docs/news.xml | 9 +++++++ src/bhyve/bhyve_capabilities.c | 7 +++-- src/bhyve/bhyve_capabilities.h | 1 + src/bhyve/bhyve_command.c | 17 +++++++++++- .../bhyvexml2argv-cputopology.args | 9 +++++++ .../bhyvexml2argv-cputopology.ldargs | 3 +++ .../bhyvexml2argv-cputopology.xml | 26 +++++++++++++++++++ tests/bhyvexml2argvtest.c | 7 ++++- 9 files changed, 91 insertions(+), 4 deletions(-) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-cputopology.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-cputopology.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-cputopology.xml -- 2.17.0

2 4

[libvirt] [PATCH v2] storage: Add capability to use LUKS encryption for disk backend
by John Ferlan 29 May '18

29 May '18

https://bugzilla.redhat.com/show_bug.cgi?id=1560946 Similar to the the Logical backend, use qemu-img on the created disk partition device to set up for LUKS encryption. Secret mgmt for the device can be complicated by a reboot possibly changing the path to the device if the infrastructure changes. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- Changes in v2: Don't alter the result 'endOffset' of the DiskPartBoundaries, rather modify the input capacity value. Alteration of the value for the error path won't matter since the volume would be deleted anyway. The call to virStorageBackendDiskPartBoundaries was also slightly modified to check the return value vs -1 rather than != 0 so that the call is similar to other calls. Separating that into it's own patch could have been done, but just felt like too much "busy work" to be worth the trouble. src/storage/storage_backend_disk.c | 49 ++++++++++++++++++++++---------------- 1 file changed, 29 insertions(+), 20 deletions(-) diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c index 2e3d1e04a4..e9578d01d6 100644 --- a/src/storage/storage_backend_disk.c +++ b/src/storage/storage_backend_disk.c @@ -879,28 +879,26 @@ virStorageBackendDiskCreateVol(virStoragePoolObjPtr pool, char *partFormat = NULL; unsigned long long startOffset = 0, endOffset = 0; virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool); + virErrorPtr save_err; virCommandPtr cmd = virCommandNewArgList(PARTED, def->source.devices[0].path, "mkpart", "--script", NULL); - if (vol->target.encryption != NULL) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - "%s", _("storage pool does not support encrypted " - "volumes")); - goto cleanup; - } - if (virStorageBackendDiskPartFormat(pool, vol, &partFormat) != 0) goto cleanup; virCommandAddArg(cmd, partFormat); - if (virStorageBackendDiskPartBoundaries(pool, &startOffset, - &endOffset, - vol->target.capacity) != 0) { + /* If we're going to encrypt using LUKS, then we could need up to + * an extra 2MB for the LUKS header - so account for that now */ + if (vol->target.encryption && + vol->target.encryption->format == VIR_STORAGE_ENCRYPTION_FORMAT_LUKS) + vol->target.capacity += 2 * 1024 * 1024; + + if (virStorageBackendDiskPartBoundaries(pool, &startOffset, &endOffset, + vol->target.capacity) < 0) goto cleanup; - } virCommandAddArgFormat(cmd, "%lluB", startOffset); virCommandAddArgFormat(cmd, "%lluB", endOffset); @@ -919,15 +917,15 @@ virStorageBackendDiskCreateVol(virStoragePoolObjPtr pool, VIR_FREE(vol->target.path); /* Fetch actual extent info, generate key */ - if (virStorageBackendDiskReadPartitions(pool, vol) < 0) { - /* Best effort to remove the partition. Ignore any errors - * since we could be calling this with vol->target.path == NULL - */ - virErrorPtr save_err = virSaveLastError(); - ignore_value(virStorageBackendDiskDeleteVol(pool, vol, 0)); - virSetError(save_err); - virFreeError(save_err); - goto cleanup; + if (virStorageBackendDiskReadPartitions(pool, vol) < 0) + goto error; + + if (vol->target.encryption) { + /* Adjust the sizes to account for the LUKS header */ + vol->target.capacity -= 2 * 1024 * 1024; + vol->target.allocation -= 2 * 1024 * 1024; + if (virStorageBackendCreateVolUsingQemuImg(pool, vol, NULL, 0) < 0) + goto error; } res = 0; @@ -936,8 +934,19 @@ virStorageBackendDiskCreateVol(virStoragePoolObjPtr pool, VIR_FREE(partFormat); virCommandFree(cmd); return res; + + error: + /* Best effort to remove the partition. Ignore any errors + * since we could be calling this with vol->target.path == NULL + */ + save_err = virSaveLastError(); + ignore_value(virStorageBackendDiskDeleteVol(pool, vol, 0)); + virSetError(save_err); + virFreeError(save_err); + goto cleanup; } + static int virStorageBackendDiskBuildVolFrom(virStoragePoolObjPtr pool, virStorageVolDefPtr vol, -- 2.14.3

2 2

[libvirt] [PATCH 0/2] capabilities: Provide info about host IOMMU support
by Filip Alac 29 May '18

29 May '18

Provide information about host IOMMU support in capabilities XML. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=967231 Filip Alac (2): capabilities: Provide info about host IOMMU support docs: news: Add entry about iommu_support docs/news.xml | 8 ++++++++ docs/schemas/capability.rng | 11 +++++++++++ src/conf/capabilities.c | 8 ++++++++ src/conf/capabilities.h | 5 +++++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 4 ++++ src/util/virpci.c | 19 +++++++++++++++++++ src/util/virpci.h | 2 ++ 8 files changed, 58 insertions(+) -- 2.17.0

2 4

[libvirt] [PATCH] storage: Add capability to use LUKS encryption for disk backend
by John Ferlan 29 May '18

29 May '18

https://bugzilla.redhat.com/show_bug.cgi?id=1560946 Following the model of the Logical backend, use qemu-img on the created device to set up for LUKS encryption. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- works much better with the settle patch applied from: https://www.redhat.com/archives/libvir-list/2018-May/msg01847.html src/storage/storage_backend_disk.c | 43 ++++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 16 deletions(-) diff --git a/src/storage/storage_backend_disk.c b/src/storage/storage_backend_disk.c index 7b4549c34d..a3003fd0b5 100644 --- a/src/storage/storage_backend_disk.c +++ b/src/storage/storage_backend_disk.c @@ -870,19 +870,13 @@ virStorageBackendDiskCreateVol(virStoragePoolObjPtr pool, char *partFormat = NULL; unsigned long long startOffset = 0, endOffset = 0; virStoragePoolDefPtr def = virStoragePoolObjGetDef(pool); + virErrorPtr save_err; virCommandPtr cmd = virCommandNewArgList(PARTED, def->source.devices[0].path, "mkpart", "--script", NULL); - if (vol->target.encryption != NULL) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - "%s", _("storage pool does not support encrypted " - "volumes")); - goto cleanup; - } - if (virStorageBackendDiskPartFormat(pool, vol, &partFormat) != 0) goto cleanup; virCommandAddArg(cmd, partFormat); @@ -893,6 +887,12 @@ virStorageBackendDiskCreateVol(virStoragePoolObjPtr pool, goto cleanup; } + /* If we're going to encrypt using LUKS, then we could need up to + * an extra 2MB for the LUKS header - so account for that now */ + if (vol->target.encryption && + vol->target.encryption->format == VIR_STORAGE_ENCRYPTION_FORMAT_LUKS) + endOffset += 2 * 1024 * 1024; + virCommandAddArgFormat(cmd, "%lluB", startOffset); virCommandAddArgFormat(cmd, "%lluB", endOffset); @@ -910,15 +910,15 @@ virStorageBackendDiskCreateVol(virStoragePoolObjPtr pool, VIR_FREE(vol->target.path); /* Fetch actual extent info, generate key */ - if (virStorageBackendDiskReadPartitions(pool, vol) < 0) { - /* Best effort to remove the partition. Ignore any errors - * since we could be calling this with vol->target.path == NULL - */ - virErrorPtr save_err = virSaveLastError(); - ignore_value(virStorageBackendDiskDeleteVol(pool, vol, 0)); - virSetError(save_err); - virFreeError(save_err); - goto cleanup; + if (virStorageBackendDiskReadPartitions(pool, vol) < 0) + goto error; + + if (vol->target.encryption) { + /* Adjust the sizes to account for the LUKS header */ + vol->target.capacity -= 2 * 1024 * 1024; + vol->target.allocation -= 2 * 1024 * 1024; + if (virStorageBackendCreateVolUsingQemuImg(pool, vol, NULL, 0) < 0) + goto error; } res = 0; @@ -927,8 +927,19 @@ virStorageBackendDiskCreateVol(virStoragePoolObjPtr pool, VIR_FREE(partFormat); virCommandFree(cmd); return res; + + error: + /* Best effort to remove the partition. Ignore any errors + * since we could be calling this with vol->target.path == NULL + */ + save_err = virSaveLastError(); + ignore_value(virStorageBackendDiskDeleteVol(pool, vol, 0)); + virSetError(save_err); + virFreeError(save_err); + goto cleanup; } + static int virStorageBackendDiskBuildVolFrom(virStoragePoolObjPtr pool, virStorageVolDefPtr vol, -- 2.14.3

2 4