August 2016 - Devel - libvirt List Archives

[libvirt] [PATCH 0/7]
by Nikolay Shirokovskiy 18 Aug '16

18 Aug '16

filesystem pools inception Filesystem pools is a facility to manage filesystems resources similar to how storage pools manages volume resources. Furthermore new API follows storage API closely where it makes sense. Uploading/downloading operations are not defined yet as it is not obvious how to make it properly. I guess we can use some kind of tar to make a stream from a filesystem. Please share you thoughts on this particular issue. The patchset provides 'dir' backend which simply expose directories in some directory in host filesystem. The virsh commands are provided too. So it is ready to play with, just replace 'pool' in xml descriptions and virsh commands to 'fspool' and 'volume' to 'item'. Olga Krishtal (7): fspool: introduce filesystem pools API fspool: usual driver based implementation of filesystem pools API fspools: configuration and internal representation fspools: acl support for filesystem pools remote: filesystem pools driver implementation fspool: default implementation of filesystem pools virsh: filesystem pools commands configure.ac | 33 + daemon/Makefile.am | 4 + daemon/libvirtd.c | 10 + daemon/remote.c | 35 + include/libvirt/libvirt-fs.h | 273 +++++ include/libvirt/libvirt.h | 1 + include/libvirt/virterror.h | 8 + po/POTFILES.in | 6 + src/Makefile.am | 46 + src/access/viraccessdriver.h | 12 + src/access/viraccessdrivernop.c | 19 + src/access/viraccessdriverpolkit.c | 47 + src/access/viraccessdriverstack.c | 49 + src/access/viraccessmanager.c | 31 + src/access/viraccessmanager.h | 11 + src/access/viraccessperm.c | 15 +- src/access/viraccessperm.h | 124 +++ src/conf/fs_conf.c | 1624 +++++++++++++++++++++++++++ src/conf/fs_conf.h | 310 ++++++ src/datatypes.c | 154 +++ src/datatypes.h | 94 ++ src/driver-fs.h | 210 ++++ src/driver.h | 3 + src/fs/fs_backend.h | 85 ++ src/fs/fs_backend_dir.c | 334 ++++++ src/fs/fs_backend_dir.h | 8 + src/fs/fs_driver.c | 2164 ++++++++++++++++++++++++++++++++++++ src/fs/fs_driver.h | 10 + src/libvirt-fs.c | 1715 ++++++++++++++++++++++++++++ src/libvirt.c | 28 + src/libvirt_private.syms | 53 + src/libvirt_public.syms | 46 + src/remote/remote_driver.c | 72 +- src/remote/remote_protocol.x | 522 ++++++++- src/rpc/gendispatch.pl | 19 +- src/util/virerror.c | 37 + tools/Makefile.am | 4 + tools/virsh-fspool.c | 1728 ++++++++++++++++++++++++++++ tools/virsh-fspool.h | 36 + tools/virsh-item.c | 1274 +++++++++++++++++++++ tools/virsh-item.h | 37 + tools/virsh.c | 4 + tools/virsh.h | 9 + 43 files changed, 11294 insertions(+), 10 deletions(-) create mode 100644 include/libvirt/libvirt-fs.h create mode 100644 src/conf/fs_conf.c create mode 100644 src/conf/fs_conf.h create mode 100644 src/driver-fs.h create mode 100644 src/fs/fs_backend.h create mode 100644 src/fs/fs_backend_dir.c create mode 100644 src/fs/fs_backend_dir.h create mode 100644 src/fs/fs_driver.c create mode 100644 src/fs/fs_driver.h create mode 100644 src/libvirt-fs.c create mode 100644 tools/virsh-fspool.c create mode 100644 tools/virsh-fspool.h create mode 100644 tools/virsh-item.c create mode 100644 tools/virsh-item.h -- 1.8.3.1

2 8

[libvirt] [PATCH v1 00/19] Implementation of QEMU vhost-scsi
by Eric Farman 17 Aug '16

17 Aug '16

This patch series provides a libvirt implementation of the vhost-scsi interface in QEMU. As near as I can see, this was discussed upstream in July 2014[1], and ended in a desire to replace a vhost-scsi controller in favor of a hostdev element instead[2]. There is no capability check in this series for vhost-scsi in the underlying QEMU. Using a recent QEMU built with --disable-vhost-scsi fails with "not a valid device model name." Host Filesystem Example: # ls /sys/kernel/config/target/vhost/ discovery_auth naa.5001405df3e54061 version # ls /sys/kernel/config/target/vhost/naa.5001405df3e54061/tpgt_1/lun/ lun_0 QEMU Example (snippet): -device vhost-scsi-ccw,wwpn=naa.5001405df3e54061,devno=fe.0.1000 Libvirt Example (snippet): <hostdev mode='subsystem' type='scsi'> <source protocol='vhost' wwpn='naa.5001405df3e54061'/> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x1000'/> </hostdev> Guest Viewpoint: # lsscsi [1:0:1:0] disk LIO-ORG disk0 4.0 /dev/sda # dmesg | grep 1: [ 6.065735] scsi host1: Virtio SCSI HBA [ 6.093892] scsi 1:0:1:0: Direct-Access LIO-ORG disk0 4.0 PQ: 0 ANSI: 5 [ 6.313615] sd 1:0:1:0: Attached scsi generic sg0 type 0 [ 6.314981] sd 1:0:1:0: [sda] 29360128 512-byte logical blocks: (15.0 GB/14.0 GiB) [ 6.317290] sd 1:0:1:0: [sda] Write Protect is off [ 6.317566] sd 1:0:1:0: [sda] Mode Sense: 43 00 10 08 [ 6.317853] sd 1:0:1:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [ 6.352722] sd 1:0:1:0: [sda] Attached SCSI disk [1] http://www.redhat.com/archives/libvir-list/2014-July/msg01235.html [2] http://www.redhat.com/archives/libvir-list/2014-July/msg01390.html Eric Farman (19): conf: Add definitions for "vhost" protocol in hostdev tags util: Allow a vhost protocol for scsi hostdev security: Allow a vhost protocol for scsi hostdev qemu: Refactor qemuIsSharedHostdev for readability/extendability qemu: Allow a vhost protocol for scsi hostdev conf: Parse vhost-scsi XML tag conf: Prevent use of shareable on vhost-scsi devices qemu: Introduce vhost-scsi capability qemu: Refactor qemuBuildHostdevCommandLine for non-vhost devices qemu: Add vhost-scsi string for -device parameter qemu: Add vhost-scsi to hostdev schema docs: Add vhost-scsi to documentation qemu: Refactor hotplug in preparation for vhost-scsi qemu: Allow hotplug of vhost-scsi device conf: Create vhost-scsi hostdev protocol in dumpxml conf: Set up vhost-scsi hostdev to self-close source tag tests: Introduce basic vhost-scsi test conf: Do not create a virtio-scsi controller for vhost-scsi hostdev qemu: Allow the specification of a vhost-scsi devno docs/formatdomain.html.in | 16 +++ docs/schemas/domaincommon.rng | 12 +++ src/conf/domain_conf.c | 94 ++++++++++++++-- src/conf/domain_conf.h | 8 ++ src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_cgroup.c | 5 + src/qemu/qemu_command.c | 120 +++++++++++++++++++-- src/qemu/qemu_command.h | 6 ++ src/qemu/qemu_conf.c | 21 +++- src/qemu/qemu_domain_address.c | 10 ++ src/qemu/qemu_hotplug.c | 76 +++++++++---- src/qemu/qemu_monitor.c | 21 ++++ src/qemu/qemu_monitor.h | 4 + src/security/security_apparmor.c | 5 +- src/security/security_dac.c | 10 +- src/security/security_selinux.c | 10 +- src/util/virhostdev.c | 13 ++- src/util/virscsi.c | 26 +++++ src/util/virscsi.h | 1 + tests/qemucapabilitiesdata/caps_1.5.3.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_1.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_1.7.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 1 + .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + .../qemuxml2argv-hostdev-scsi-vhost-scsi.args | 24 +++++ .../qemuxml2argv-hostdev-scsi-vhost-scsi.xml | 33 ++++++ tests/qemuxml2argvmock.c | 12 +++ tests/qemuxml2argvtest.c | 3 + 35 files changed, 486 insertions(+), 58 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-vhost-scsi.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-hostdev-scsi-vhost-scsi.xml -- 1.9.1

3 42

[libvirt] [PATCHv3 00/11] qemu: allow disabling certain virtio revisions
by Ján Tomko 17 Aug '16

17 Aug '16

https://bugzilla.redhat.com/show_bug.cgi?id=1227354 v1: https://www.redhat.com/archives/libvir-list/2016-July/msg01235.html v2: https://www.redhat.com/archives/libvir-list/2016-August/msg00412.html * probe for the qemu capability * add the attribute to virtio1-only devices such as virtio-gpu and virtio-input devices * allow multiple revisions to be specified v3: * touch up documentation * rename the capability from "virtio-revision" to "virtio-disable-legacy" * move the formatting in qemuBuildNicDevStr after the address and only do it for virtio * get rid of novelty enum names I left the bitmap usage intact, since enforcing both revision makes sense according to the discussion under: [PATCH 0/6] Use more PCIe, less legacy PCI slots and I considered specifying both features in the XML nicer than adding a new value. Ján Tomko (11): Use separate buffer for <input> subelements Add virtio revision attribute to memballoon Add virtio revision attribute to disks Add virtio revision attribute to controllers Add virtio revision attribute to filesystems Add virtio revision attribute to interfaces Add virtio revision to rng devices Add virtio revision attribute to video Add virtio revision attribute to input devices Introduce QEMU_CAPS_VIRTIO_DISABLE_LEGACY qemu: format options for enforcing virtio revisions docs/formatdomain.html.in | 69 ++++++++++ docs/schemas/domaincommon.rng | 37 ++++++ src/conf/domain_conf.c | 148 +++++++++++++++++++-- src/conf/domain_conf.h | 16 +++ src/qemu/qemu_capabilities.c | 6 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 56 ++++++++ tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 1 + .../caps_2.6.0-gicv2.aarch64.xml | 1 + .../caps_2.6.0-gicv3.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 1 + tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 1 + .../qemuxml2argv-virtio-revision.args | 62 +++++++++ .../qemuxml2argv-virtio-revision.xml | 113 ++++++++++++++++ tests/qemuxml2argvtest.c | 11 ++ .../qemuxml2xmlout-virtio-revision.xml | 113 ++++++++++++++++ tests/qemuxml2xmltest.c | 2 + 19 files changed, 630 insertions(+), 11 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-revision.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-virtio-revision.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-virtio-revision.xml -- 2.7.3

6 27

[libvirt] Fixing backwards migration with usb-ccid devices
by Ján Tomko 17 Aug '16

17 Aug '16

Dear list, my USB address assignment code (released in 2.1.0) incorrectly assumed that older libvirt allows specifying USB addresses for all usb devices: https://bugzilla.redhat.com/show_bug.cgi?id=1360963 For usb-ccid devices, this is only possible since commit 2dabe2e0 (Released in libvirt 1.3.3 this April). Before that, we required either a PCI address or no address for all controllers, a USB address will be rejected by the XML parser. The only reliable way to fix this that I could think of is: not to assign addresses to domains which might need to be migrated backwards. This is doable downstream where we can make assumptions on the version of libvirt based on the machine type, but that won't work upstream. I have considered dropping just the USB address of the CCID controller from the XML if we do not know that we are migrating to a new enough libvirt (that would be 2.2.0 since it would need a new driver flag and migration flag), but that would only fix it for cases where the address generated by libvirt matches the one that QEMU will give it. But if it does not, migration to libvirt 1.3.3 to 2.1.0 will be broken. Do you have any ideas how this might be fixed (other than reverting the assignment), or is this something that downstreams have to deal with? Jan

1 0

[libvirt] [PATCH v2] qemu: Fix crash hot plugging luks volume
by John Ferlan 17 Aug '16

17 Aug '16

https://bugzilla.redhat.com/show_bug.cgi?id=1367259 Crash occurs because 'secrets' is being dereferenced in call: if (qemuDomainSecretSetup(conn, priv, secinfo, disk->info.alias, VIR_SECRET_USAGE_TYPE_VOLUME, NULL, &src->encryption->secrets[0]->seclookupdef, true) < 0) (gdb) p *src->encryption $1 = {format = 2, nsecrets = 0, secrets = 0x0, encinfo = {cipher_size = 0, cipher_name = 0x0, cipher_mode = 0x0, cipher_hash = 0x0, ivgen_name = 0x0, ivgen_hash = 0x0}} (gdb) bt priv=priv@entry=0x7fffc03be160, disk=disk@entry=0x7fffb4002ae0) at qemu/qemu_domain.c:1087 disk=0x7fffb4002ae0, vm=0x7fffc03a2580, driver=0x7fffc02ca390, conn=0x7fffb00009a0) at qemu/qemu_hotplug.c:355 Upon entry to qemuDomainAttachVirtioDiskDevice, src->encryption points at a valid 'secret' buffer w/ nsecrets == 1; however, the call to qemuDomainDetermineDiskChain will call virStorageFileGetMetadata and eventually virStorageFileGetMetadataInternal where the src->encryption was overwritten when probing the volume. Commit id 'a48c7141' added code to virStorageFileGetMetadataInternal to determine if the disk/volume would use/need encryption and allocated a meta->encryption. This overwrote an existing encryption buffer already provided by the XML This patch adds a check for meta->encryption already present before just allocating and overwriting an existing buffer. It then checks the existing encryption data to ensure the XML provided format for the disk matches the expected format read from the disk and errors if there is a mismatch. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- v1: http://www.redhat.com/archives/libvir-list/2016-August/msg00805.html Tested w/ delete luks volume, create luks volume, dump luks volume, attach to guest, detach from guest, and repeat... src/util/virstoragefile.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 471aa1f..feeb061 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -950,10 +950,21 @@ virStorageFileGetMetadataInternal(virStorageSourcePtr meta, for (i = 0; fileTypeInfo[meta->format].cryptInfo[i].format != 0; i++) { if (virStorageFileHasEncryptionFormat(&fileTypeInfo[meta->format].cryptInfo[i], buf, len)) { - if (VIR_ALLOC(meta->encryption) < 0) - goto cleanup; - - meta->encryption->format = fileTypeInfo[meta->format].cryptInfo[i].format; + int expt_fmt = fileTypeInfo[meta->format].cryptInfo[i].format; + if (!meta->encryption) { + if (VIR_ALLOC(meta->encryption) < 0) + goto cleanup; + + meta->encryption->format = expt_fmt; + } else { + if (meta->encryption->format != expt_fmt) { + virReportError(VIR_ERR_XML_ERROR, + _("encryption format %d doesn't match " + "expected format %d"), + meta->encryption->format, expt_fmt); + goto cleanup; + } + } } } } -- 2.7.4

1 0

[libvirt] [PATCH] qemu: Fix crash hot plugging luks volume
by John Ferlan 17 Aug '16

17 Aug '16

https://bugzilla.redhat.com/show_bug.cgi?id=1367259 Crash occurs because 'secrets' is being dereferenced in call: if (qemuDomainSecretSetup(conn, priv, secinfo, disk->info.alias, VIR_SECRET_USAGE_TYPE_VOLUME, NULL, &src->encryption->secrets[0]->seclookupdef, true) < 0) (gdb) p *src->encryption $1 = {format = 2, nsecrets = 0, secrets = 0x0, encinfo = {cipher_size = 0, cipher_name = 0x0, cipher_mode = 0x0, cipher_hash = 0x0, ivgen_name = 0x0, ivgen_hash = 0x0}} (gdb) bt priv=priv@entry=0x7fffc03be160, disk=disk@entry=0x7fffb4002ae0) at qemu/qemu_domain.c:1087 disk=0x7fffb4002ae0, vm=0x7fffc03a2580, driver=0x7fffc02ca390, conn=0x7fffb00009a0) at qemu/qemu_hotplug.c:355 Upon entry to qemuDomainAttachVirtioDiskDevice, src->encryption points at a valid 'secret' buffer w/ nsecrets == 1; however, the call to qemuDomainDetermineDiskChain will call virStorageFileGetMetadata and eventually virStorageFileGetMetadataInternal where the src->encryption was overwritten when probing the volume. Commit id 'a48c7141' added code to virStorageFileGetMetadataInternal to determine if the disk/volume would use/need encryption and allocated a meta->encryption. This overwrote an existing encryption buffer already provided by the XML This patch adds an argument to virStorageFileGetMetadataInternal in order to avoid the encryption probe of the volume. This will only be be set to true for the storage volume buffer/fd parsing. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- NB: This I believe the bare bones that could be done. If desired, I could also modify virStorageFileGetMetadata[Recurse] and all the callers in order to specifically add a 'probe_encryption' variable there as well. For this path, the "root" callers would add the 'false', hence the reason I chose to just modify the *Recurse function to pass 'false'. I have tested creating a luks volume and of course hot plugging with this patch... src/storage/storage_driver.c | 2 +- src/util/virstoragefile.c | 8 +++++--- src/util/virstoragefile.h | 3 ++- 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 6f1e372..fe0e164 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -3239,7 +3239,7 @@ virStorageFileGetMetadataRecurse(virStorageSourcePtr src, &buf)) < 0) goto cleanup; - if (virStorageFileGetMetadataInternal(src, buf, headerLen, + if (virStorageFileGetMetadataInternal(src, buf, headerLen, false, &backingFormat) < 0) goto cleanup; diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 471aa1f..4b6bde3 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -928,6 +928,7 @@ int virStorageFileGetMetadataInternal(virStorageSourcePtr meta, char *buf, size_t len, + bool probe_encryption, int *backingFormat) { int ret = -1; @@ -946,7 +947,7 @@ virStorageFileGetMetadataInternal(virStorageSourcePtr meta, goto cleanup; } - if (fileTypeInfo[meta->format].cryptInfo != NULL) { + if (probe_encryption && fileTypeInfo[meta->format].cryptInfo != NULL) { for (i = 0; fileTypeInfo[meta->format].cryptInfo[i].format != 0; i++) { if (virStorageFileHasEncryptionFormat(&fileTypeInfo[meta->format].cryptInfo[i], buf, len)) { @@ -1129,7 +1130,7 @@ virStorageFileGetMetadataFromBuf(const char *path, if (!(ret = virStorageFileMetadataNew(path, format))) return NULL; - if (virStorageFileGetMetadataInternal(ret, buf, len, + if (virStorageFileGetMetadataInternal(ret, buf, len, true, backingFormat) < 0) { virStorageSourceFree(ret); return NULL; @@ -1200,7 +1201,8 @@ virStorageFileGetMetadataFromFD(const char *path, goto cleanup; } - if (virStorageFileGetMetadataInternal(meta, buf, len, backingFormat) < 0) + if (virStorageFileGetMetadataInternal(meta, buf, len, true, + backingFormat) < 0) goto cleanup; if (S_ISREG(sb.st_mode)) diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h index 3d09468..bb71372 100644 --- a/src/util/virstoragefile.h +++ b/src/util/virstoragefile.h @@ -289,8 +289,9 @@ int virStorageFileProbeFormatFromBuf(const char *path, int virStorageFileGetMetadataInternal(virStorageSourcePtr meta, char *buf, size_t len, + bool probe_encryption, int *backingFormat) - ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(4); + ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(2) ATTRIBUTE_NONNULL(5); virStorageSourcePtr virStorageFileGetMetadataFromFD(const char *path, int fd, -- 2.7.4

2 3

[libvirt] [PATCH v2 0/4] Use more PCIe, less legacy PCI slots
by Laine Stump 17 Aug '16

17 Aug '16

Due to its unpopularity, I've removed the "hotpluggable" attribute that was in V1 of this patchset, and also auto-assign *all* devices (except primary video and USB2 for historical reasons) to hotpluggable slots only (rather than assigning devices to the non-hotpluggable pcie-root if libvirt doesn't currently allow hotplugging those devices). So these patches have *NO* new configuration - they are just correcting bad (or at least suboptimal) behavior, and should thus be reasonably uncontroversial :-) The first patch corrects an error in where pci-bridge can be plugged in, which isn't really about using more PCI, but *is* about getting devices plugged into the right kind of slots. (tl;dr - a pci-bridge works when plugged into pcie-root, but people who know about PCI tell me that it's "not proper" to do so, so now we don't unless specifically told to). Patch 2 puts virtio devices into PCIe slots when they support it, patch 3 puts the new e1000e network device (which is a PCIe version of the Intel e1000) into a PCIe slot (as long as the machine has PCIe), and patch 3 does the same for the NEC xhci USB3 controller - all of these devices present as PCie devices when in a PCIe slot, and as PCI devices otherwise, and there is no doubt that preferring PCIe is desirable (legacy PCI controllers only exist on Q35 and other PCIe-capable machinetypes as a crutch to use when you have to use a device that is legacy-PCI-only). One exception that isn't handled in this series is that when a virtio device has --disable-modern=on, it will always be a PCI device. Since Jan's patches to support setting that option aren't in yet, I don't do anything about it. Another caveat - since the auto-adding of PCI controllers will currently only add pci-bridge devices, in order for these patches to be useful, you'll need to manually add a <controller type='pci' model='pcie-root-port'/> for each device. Before pushing these patches, I plan to add another patch that auto-adds pcie-*-port as needed, but wanted to post what I have now to get a head start on reviews (especially since many reviewers will be at KVM Forum next week). Finally, if you want to try out these patches, you'll need to apply them on top of jtomko's patch "Introduce QEMU_CAPS_VIRTIO_PCI_DISABLE_LEGACY", from the most recent version of his virtio version patches. Laine Stump (4): conf: restrict what type of buses will accept a pci-bridge qemu: assign virtio devices to PCIe slot when appropriate qemu: assign e1000e network devices to PCIe controllers when appropriate qemu: assign nec-xhci (USB3) controller to a PCIe address when appropriate src/conf/domain_addr.c | 29 +++- src/conf/domain_addr.h | 4 +- src/qemu/qemu_domain_address.c | 69 ++++++++-- tests/qemuxml2argvdata/qemuxml2argv-autoindex.args | 10 +- tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args | 58 ++++++++ tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml | 67 +++++++++ .../qemuxml2argv-q35-virtio-pci.args | 58 ++++++++ .../qemuxml2argv-q35-virtio-pci.xml | 67 +++++++++ .../qemuxml2argv-q35-virtio-pcie.args | 56 ++++++++ tests/qemuxml2argvtest.c | 45 +++++- .../qemuxml2xmlout-autoindex.xml | 10 +- .../qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml | 152 +++++++++++++++++++++ .../qemuxml2xmlout-q35-virtio-pci.xml | 152 +++++++++++++++++++++ tests/qemuxml2xmltest.c | 40 ++++++ 14 files changed, 788 insertions(+), 29 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-pcie.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pci.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-q35-virtio-pcie.args create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-pcie.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-q35-virtio-pci.xml -- 2.7.4

2 10

[libvirt] [PATCH 00/27] qemu: add support for modern vcpu hotplug and unplug
by Peter Krempa 17 Aug '16

17 Aug '16

This adds support for vcpu hotplug and unplug using device_add and device_del. Patches 1 and 2 are already mostly acked. Peter Krempa (27): qemu: monitor: Return structures from qemuMonitorGetCPUInfo qemu: monitor: Return struct from qemuMonitor(Text|Json)QueryCPUs qemu: caps: Add capability for query-hotpluggable-cpus command qemu: Forbid config when topology based cpu count doesn't match the config qemu: capabilities: Extract availability of new cpu hotplug for machine types qemu: monitor: Extract QOM path from query-cpus reply qemu: monitor: Add support for calling query-hotpluggable-cpus qemu: monitor: Add algorithm for combining query-(hotpluggable-)-cpus data tests: Add test infrastructure for qemuMonitorGetCPUInfo tests: cpu-hotplug: Add data for ppc64 platform including hotplug tests: cpu-hotplug: Add data for ppc64 out-of-order hotplug tests: cpu-hotplug: Add data for ppc64 without threads enabled qemu: domain: Extract cpu-hotplug related data qemu: domain: Prepare for VCPUs vanishing while libvirt is not running qemu: setcpus: Report better errors qemu: setcpus: Move NUMA setup code into the block checking live def qemu: setvcpus: Extract setting of maximum vcpu count util: Extract and rename qemuDomainDelCgroupForThread to virCgroupDelThread conf: Add XML for individual vCPU hotplug qemu: migration: Prepare for non-contiguous vcpu configurations qemu: command: Add helper to convert vcpu definition to JSON props qemu: process: Copy final vcpu order information into the vcpu definition qemu: command: Add support for sparse vcpu topologies qemu: Use mondern vcpu hotplug approach if possible qemu: hotplug: Allow marking unplugged devices by alias qemu: hotplug: Add support for VCPU unplug RFC: qemu: hotplug: Add DEVICE_(ADDED|DELETED) events for vcpus docs/formatdomain.html.in | 18 ++ docs/schemas/domaincommon.rng | 25 ++ src/conf/domain_conf.c | 151 ++++++++- src/conf/domain_conf.h | 6 + src/libvirt_private.syms | 1 + src/qemu/qemu_capabilities.c | 31 +- src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 50 ++- src/qemu/qemu_command.h | 3 + src/qemu/qemu_domain.c | 303 ++++++++++++++---- src/qemu/qemu_domain.h | 19 +- src/qemu/qemu_driver.c | 354 +++++++++++++-------- src/qemu/qemu_hotplug.c | 134 +++++++- src/qemu/qemu_hotplug.h | 7 + src/qemu/qemu_migration.c | 16 +- src/qemu/qemu_monitor.c | 260 ++++++++++++++- src/qemu/qemu_monitor.h | 58 +++- src/qemu/qemu_monitor_json.c | 266 +++++++++++++--- src/qemu/qemu_monitor_json.h | 8 +- src/qemu/qemu_monitor_text.c | 39 ++- src/qemu/qemu_monitor_text.h | 3 +- src/qemu/qemu_process.c | 182 ++++++++++- src/util/vircgroup.c | 20 ++ src/util/vircgroup.h | 4 + .../generic-vcpus-individual.xml | 23 ++ tests/genericxml2xmltest.c | 2 + tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 55 ++-- .../qemumonitorjson-cpuinfo-ppc64-basic-cpus.json | 77 +++++ ...emumonitorjson-cpuinfo-ppc64-basic-hotplug.json | 27 ++ .../qemumonitorjson-cpuinfo-ppc64-basic.data | 40 +++ ...mumonitorjson-cpuinfo-ppc64-hotplug-1-cpus.json | 149 +++++++++ ...onitorjson-cpuinfo-ppc64-hotplug-1-hotplug.json | 28 ++ .../qemumonitorjson-cpuinfo-ppc64-hotplug-1.data | 51 +++ ...mumonitorjson-cpuinfo-ppc64-hotplug-2-cpus.json | 221 +++++++++++++ ...onitorjson-cpuinfo-ppc64-hotplug-2-hotplug.json | 29 ++ .../qemumonitorjson-cpuinfo-ppc64-hotplug-2.data | 62 ++++ ...mumonitorjson-cpuinfo-ppc64-hotplug-3-cpus.json | 149 +++++++++ ...onitorjson-cpuinfo-ppc64-hotplug-3-hotplug.json | 28 ++ .../qemumonitorjson-cpuinfo-ppc64-hotplug-3.data | 51 +++ ...mumonitorjson-cpuinfo-ppc64-hotplug-4-cpus.json | 221 +++++++++++++ ...onitorjson-cpuinfo-ppc64-hotplug-4-hotplug.json | 29 ++ .../qemumonitorjson-cpuinfo-ppc64-hotplug-4.data | 62 ++++ ...umonitorjson-cpuinfo-ppc64-no-threads-cpus.json | 77 +++++ ...nitorjson-cpuinfo-ppc64-no-threads-hotplug.json | 125 ++++++++ .../qemumonitorjson-cpuinfo-ppc64-no-threads.data | 72 +++++ ...nitorjson-cpuinfo-x86-basic-pluggable-cpus.json | 50 +++ ...orjson-cpuinfo-x86-basic-pluggable-hotplug.json | 82 +++++ ...emumonitorjson-cpuinfo-x86-basic-pluggable.data | 39 +++ tests/qemumonitorjsontest.c | 183 ++++++++++- .../qemuxml2argv-cpu-hotplug-startup.args | 20 ++ .../qemuxml2argv-cpu-hotplug-startup.xml | 29 ++ tests/qemuxml2argvtest.c | 2 + tests/testutils.c | 4 +- 53 files changed, 3638 insertions(+), 310 deletions(-) create mode 100644 tests/genericxml2xmlindata/generic-vcpus-individual.xml create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-basic-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-basic-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-basic.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-1-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-1-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-1.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-2-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-2-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-2.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-3-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-3-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-3.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-hotplug-4.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-no-threads-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-no-threads-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-ppc64-no-threads.data create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable-cpus.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable-hotplug.json create mode 100644 tests/qemumonitorjsondata/qemumonitorjson-cpuinfo-x86-basic-pluggable.data create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-hotplug-startup.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-hotplug-startup.xml -- 2.9.2

4 53

[libvirt] [PATCH] qemu: Fix the command line generation for rbd auth using aes secrets
by John Ferlan 17 Aug '16

17 Aug '16

https://bugzilla.redhat.com/show_bug.cgi?id=1182074 Since libvirt still uses a legacy qemu arg format to add a disk, the manner in which the 'password-secret' argument is passed to qemu needs to change to prepend a 'file.' If in the future, usage of the more modern disk format, then the prepended 'file.' can be removed. Fix based on Jim Fehlig <jfehlig(a)suse.com> posting and subsequent upstream list followups, see: http://www.redhat.com/archives/libvir-list/2016-August/msg00777.html for details. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- Jim - if you want me to change the authorship, just let me know. NB: Rather than waiting for a new bz, I've reused the bz that was used for the original patches/support. src/qemu/qemu_command.c | 7 ++++++- .../qemuxml2argv-disk-drive-network-rbd-auth-AES.args | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index ebedaef..a6dea6a 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -1287,7 +1287,12 @@ qemuBuildDriveSourceStr(virDomainDiskDefPtr disk, virBufferAddLit(buf, ","); if (secinfo && secinfo->type == VIR_DOMAIN_SECRET_INFO_TYPE_AES) { - virBufferAsprintf(buf, "password-secret=%s,", + /* NB: If libvirt starts using the more modern option based + * syntax to build the command line (e.g., "-drive driver=rbd, + * filename=%s,...") instead of the legacy model (e.g."-drive + * file=%s,..."), then the "file." prefix can be removed + */ + virBufferAsprintf(buf, "file.password-secret=%s,", secinfo->s.aes.alias); } diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-auth-AES.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-auth-AES.args index 5034bb7..07d01b6 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-auth-AES.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-network-rbd-auth-AES.args @@ -26,7 +26,7 @@ data=9eao5F8qtkGt+seB1HYivWIxbtwUu6MQtg1zpj/oDtUsPr1q8wBYM91uEHCn6j/1,\ keyid=masterKey0,iv=AAECAwQFBgcICQoLDA0ODw==,format=base64 \ -drive 'file=rbd:pool/image:id=myname:auth_supported=cephx\;none:\ mon_host=mon1.example.org\:6321\;mon2.example.org\:6322\;mon3.example.org\:\ -6322,password-secret=virtio-disk0-secret0,format=raw,if=none,\ +6322,file.password-secret=virtio-disk0-secret0,format=raw,if=none,\ id=drive-virtio-disk0' \ -device virtio-blk-pci,bus=pci.0,addr=0x3,drive=drive-virtio-disk0,\ id=virtio-disk0 -- 2.7.4

2 2

[libvirt] [PATCH] qemu_driver: update comments for qemuDomainSaveInternal
by Chen Hanxiao 17 Aug '16

17 Aug '16

From: Chen Hanxiao <chenhanxiao(a)gmail.com> s/libvirt.c/libvirt-domain.c Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- src/qemu/qemu_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 5a7733c..54e2770 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -3177,7 +3177,7 @@ qemuDomainSaveInternal(virQEMUDriverPtr driver, virDomainPtr dom, } } - /* libvirt.c already guaranteed these two flags are exclusive. */ + /* libvirt-domain.c already guaranteed these two flags are exclusive. */ if (flags & VIR_DOMAIN_SAVE_RUNNING) was_running = true; else if (flags & VIR_DOMAIN_SAVE_PAUSED) -- 1.8.3.1

2 1