October 2018 - Devel - libvirt List Archives

[libvirt] [PATCH 0/3] qemu: don't duplicate suspended events and state changes
by Nikolay Shirokovskiy 07 Nov '18

07 Nov '18

This patch series is similar in implementation to [1] but the motivation is simply to avoid suspended event duplication. [1] https://www.redhat.com/archives/libvir-list/2018-September/msg01304.html Nikolay Shirokovskiy (3): qemu: pass stop reason from qemuProcessStopCPUs to stop handler qemu: map suspended state reason to suspended event detail qemu: don't duplicate suspended events and state changes src/qemu/qemu_domain.c | 34 ++++++++++++++++++++++++++++++++++ src/qemu/qemu_domain.h | 7 +++++++ src/qemu/qemu_driver.c | 26 +++----------------------- src/qemu/qemu_migration.c | 42 ++++++------------------------------------ src/qemu/qemu_migration.h | 4 ---- src/qemu/qemu_process.c | 37 +++++++++++++++++++++++++------------ 6 files changed, 75 insertions(+), 75 deletions(-) -- 1.8.3.1

2 12

[libvirt] [PATCH 0/2] conf: Forbid some nonsensical combinations under <memoryBackend>
by Michal Privoznik 07 Nov '18

07 Nov '18

*** BLURB HERE *** Michal Prívozník (2): conf: Forbid hugepages and <source type='file'/> conf: Forbid hugepages and <allocation mode="ondemand"/> src/conf/domain_conf.c | 25 +++++++++++++++++-- .../qemuxml2argvdata/hugepages-memaccess2.xml | 1 - 2 files changed, 23 insertions(+), 3 deletions(-) -- 2.18.1

3 5

[libvirt] [PATCH] qemu: snapshot: better error for active external readonly disk
by Nikolay Shirokovskiy 07 Nov '18

07 Nov '18

External snapshot of readonly disk of active domain is impossible but error message [1] is cryptic (it's source is qemu). Let's make error message more user friendly. The problem is libvirtd precreates snapshot image with no write permission which is not expected by qemu. [1] current error message error: internal error: unable to execute QEMU command 'transaction': Could not create file: Permission denied Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy(a)virtuozzo.com> --- By the way if domain is not active then snapshot is possible. However top image will have write permissions after snapshot. We can make snapshot work for active domain I guess if we precreate writable snapshot image, but then we end up running readonly disk on writable image. Also making snapshot of readonly disk is not that practical so let's just fix error message for now. src/qemu/qemu_driver.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index a52e249..e75931e 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -14683,6 +14683,14 @@ qemuDomainSnapshotPrepare(virDomainObjPtr vm, active, reuse) < 0) goto cleanup; + if (dom_disk->src->readonly && active) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("external snapshot for readonly disk %s " + "of active domain is not supported"), + disk->name); + goto cleanup; + } + external++; break; -- 1.8.3.1

2 1

[libvirt] [PATCH v2 0/8] Usb hub Cold(un)plug and hot(un)plug support
by Han Han 07 Nov '18

07 Nov '18

v1: https://www.redhat.com/archives/libvir-list/2018-October/msg00563.html Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1375423 Han Han (8): qemu: Allow coldplugging of hub device qemu: Allow coldunplugging of hub device qemu_alias: Refactor hub alias assignment for hotplug qemu_command: Make qemuBuildHubDevStr global private_syms: add virDomainHubDefFree to libvirt_private.syms qemu: implement usb hub device hotplug qemu: implement usb hub device hotunplug news: Cold(un)plug and hot(un)plug support for usb hub device docs/news.xml | 5 ++ src/conf/domain_conf.c | 30 +++++++++ src/conf/domain_conf.h | 3 + src/libvirt_private.syms | 2 + src/qemu/qemu_alias.c | 22 +++++-- src/qemu/qemu_alias.h | 4 ++ src/qemu/qemu_command.c | 2 +- src/qemu/qemu_command.h | 4 ++ src/qemu/qemu_driver.c | 30 +++++++-- src/qemu/qemu_hotplug.c | 132 ++++++++++++++++++++++++++++++++++++++- src/qemu/qemu_hotplug.h | 12 ++++ 11 files changed, 236 insertions(+), 10 deletions(-) -- 2.19.1

2 21

[libvirt] [PATCH v3 00/20] Incremental Backup API additions
by Eric Blake 07 Nov '18

07 Nov '18

The following is the latest version of my API proposal for incremental backups, and matches the demo I will be presenting as part of my KVM Forum 2018 talk tomorrow afternoon: https://kvmforum2018.sched.com/event/FzuB/facilitating-incremental-backup-e… The patches are also available via https://repo.or.cz/libvirt/ericb.git at the tag backup-v3. The qemu integration is still incomplete (I don't have push mode backups working, only pull mode; and there are still some things to fine-tune as I figure out how to better support external snapshots and block commit/stream), and I still haven't gotten any opinions on whether it is better to have: virDomainSnapshotCreateXML("<domainsnapshot>...") # existing virDomainBackupBegin("<domainbackup>...", "<domaincheckpoint>...") # this series virDomainSnapshotCheckpointCreateXML("<domainsnapshot>...", "<domaincheckpoint>...") # new or to make checkpoint creation part of the snapshot and backup XML, as in: virDomainSnapshotCreateXML("<domainsnapshot><domaincheckpoint>...</domainsnapshot>") # extension of existing virDomainBackupBegin("<domainbackup><domaincheckpoint>...</domainbackup>") # tweak to this series It's also obvious that we don't want to check in the qemu implementation until after Peter's blockdev work has landed AND qemu has gotten rid of the x- prefix in its QMP interactions, although the state of this series SHOULD be sufficient to prove that the proposed interface is at least flexible enough to adapt to whatever qemu tweaks land and whatever other hypervisors may support. Whether to accept the API now (to make backporting qemu support downstream across versions without rebasing to an even later date for the API) is a harder question; Jirka has already expressed distaste at the idea. There are probably still loads of things needing fixing in this version, I already know I did not address all of Peter's review comments on v2. My unit test coverage is not very complete on the XML parsing, and there are definitely some hacks in place to get things to the point of a working demo that need to be polished for robustness. Below is a diff since the v2 posting (patches 1-10 here, for later patches a comparison against the state of my tree at the time I posted v2): https://www.redhat.com/archives/libvir-list/2018-October/msg00700.html 001/20:[----] [--] 'snapshots: Avoid term 'checkpoint' for full system snapshot' 002/20:[----] [--] 'domain_conf: Expose virDomainStorageNetworkParseHost' 003/20:[down] 'qemu: Allow optional export name during NBD export' 004/20:[----] [--] 'backup: Document nuances between different state capture APIs' 005/20:[----] [--] 'backup: Introduce virDomainCheckpointPtr' 006/20:[0012] [FC] 'backup: Document new XML for backups' 007/20:[----] [--] 'backup: Introduce virDomainCheckpoint APIs' 008/20:[0024] [FC] 'backup: Introduce virDomainBackup APIs' 009/20:[----] [--] 'backup: Add new domain:checkpoint access control' 010/20:[0001] [FC] 'backup: Implement backup APIs for remote driver' 011/20:[0007] [FC] 'wip: backup: Parse and output checkpoint XML' 012/20:[0199] [FC] 'wip: backup: Parse and output backup XML' 013/20:[----] [--] 'backup: Implement virsh support for checkpoints' 014/20:[----] [--] 'wip: backup: virsh support for backup' 015/20:[0223] [FC] 'backup: Add new qemu monitor interactions' 016/20:[0123] [FC] 'backup: qemu: Implement metadata tracking for checkpoint APIs' 017/20:[down] 'wip: backup: Wire up qemu checkpoint commands over QMP' 018/20:[0072] [FC] 'wip: backup: qemu: Implement framework for backup job APIs' 019/20:[down] 'backup: Wire up qemu full pull backup commands over QMP' 020/20:[down] 'backup: implement qemu incremental pull backup' No direct dependency on this one, but included in my git tag: https://www.redhat.com/archives/libvir-list/2018-October/msg00899.html Eric Blake (20): snapshots: Avoid term 'checkpoint' for full system snapshot domain_conf: Expose virDomainStorageNetworkParseHost qemu: Allow optional export name during NBD export backup: Document nuances between different state capture APIs backup: Introduce virDomainCheckpointPtr backup: Document new XML for backups backup: Introduce virDomainCheckpoint APIs backup: Introduce virDomainBackup APIs backup: Add new domain:checkpoint access control backup: Implement backup APIs for remote driver wip: backup: Parse and output checkpoint XML wip: backup: Parse and output backup XML backup: Implement virsh support for checkpoints wip: backup: virsh support for backup backup: Add new qemu monitor interactions backup: qemu: Implement metadata tracking for checkpoint APIs wip: backup: Wire up qemu checkpoint commands over QMP wip: backup: qemu: Implement framework for backup job APIs backup: Wire up qemu full pull backup commands over QMP backup: implement qemu incremental pull backup include/libvirt/virterror.h | 6 +- src/util/virerror.c | 21 +- include/libvirt/libvirt-domain-checkpoint.h | 177 ++ include/libvirt/libvirt-domain-snapshot.h | 2 +- include/libvirt/libvirt-domain.h | 17 +- include/libvirt/libvirt.h | 3 +- src/access/viraccessperm.h | 8 +- src/conf/checkpoint_conf.h | 218 +++ src/conf/domain_conf.h | 16 +- src/datatypes.h | 31 +- src/driver-hypervisor.h | 74 +- src/qemu/qemu_conf.h | 2 + src/qemu/qemu_domain.h | 29 +- src/qemu/qemu_monitor.h | 17 + src/qemu/qemu_monitor_json.h | 19 + tools/virsh-checkpoint.h | 29 + tools/virsh-completer.h | 4 + tools/virsh-util.h | 3 + tools/virsh.h | 1 + docs/Makefile.am | 3 + docs/apibuild.py | 2 + docs/docs.html.in | 9 +- docs/domainstatecapture.html.in | 314 ++++ docs/format.html.in | 1 + docs/formatcheckpoint.html.in | 291 ++++ docs/formatsnapshot.html.in | 33 +- docs/index.html.in | 3 +- docs/schemas/domainbackup.rng | 185 ++ docs/schemas/domaincheckpoint.rng | 94 ++ examples/object-events/event-test.c | 3 + libvirt.spec.in | 3 + mingw-libvirt.spec.in | 6 + po/POTFILES | 3 + src/Makefile.am | 2 + src/access/viraccessperm.c | 5 +- src/conf/Makefile.inc.am | 2 + src/conf/checkpoint_conf.c | 1541 +++++++++++++++++ src/conf/domain_conf.c | 52 +- src/conf/snapshot_conf.c | 4 +- src/datatypes.c | 62 +- src/libvirt-domain-checkpoint.c | 925 ++++++++++ src/libvirt-domain-snapshot.c | 7 +- src/libvirt-domain.c | 8 +- src/libvirt_private.syms | 30 + src/libvirt_public.syms | 23 + src/qemu/qemu_conf.c | 5 + src/qemu/qemu_domain.c | 205 ++- src/qemu/qemu_driver.c | 1494 ++++++++++++++++- src/qemu/qemu_migration.c | 2 +- src/qemu/qemu_monitor.c | 73 +- src/qemu/qemu_monitor_json.c | 217 +++ src/qemu/qemu_process.c | 7 + src/remote/remote_daemon_dispatch.c | 15 + src/remote/remote_driver.c | 33 +- src/remote/remote_protocol.x | 239 ++- src/remote_protocol-structs | 129 ++ src/rpc/gendispatch.pl | 32 +- tests/Makefile.am | 15 +- tests/domainbackupxml2xmlin/backup-pull.xml | 9 + tests/domainbackupxml2xmlin/backup-push.xml | 9 + tests/domainbackupxml2xmlin/empty.xml | 1 + tests/domainbackupxml2xmlout/backup-pull.xml | 9 + tests/domainbackupxml2xmlout/backup-push.xml | 9 + tests/domainbackupxml2xmlout/empty.xml | 7 + tests/domaincheckpointxml2xmlin/empty.xml | 1 + tests/domaincheckpointxml2xmlin/sample.xml | 7 + tests/domaincheckpointxml2xmlout/empty.xml | 10 + tests/domaincheckpointxml2xmlout/sample.xml | 16 + tests/domaincheckpointxml2xmltest.c | 231 +++ tests/qemumonitorjsontest.c | 2 +- tests/virschematest.c | 4 + tools/Makefile.am | 3 +- tools/virsh-checkpoint.c | 1578 ++++++++++++++++++ tools/virsh-completer.c | 52 +- tools/virsh-domain.c | 6 +- tools/virsh-snapshot.c | 2 +- tools/virsh-util.c | 11 + tools/virsh.c | 2 + tools/virsh.pod | 14 +- 79 files changed, 8619 insertions(+), 118 deletions(-) create mode 100644 include/libvirt/libvirt-domain-checkpoint.h create mode 100644 src/conf/checkpoint_conf.h create mode 100644 tools/virsh-checkpoint.h create mode 100644 docs/domainstatecapture.html.in create mode 100644 docs/formatcheckpoint.html.in create mode 100644 docs/schemas/domainbackup.rng create mode 100644 docs/schemas/domaincheckpoint.rng create mode 100644 src/conf/checkpoint_conf.c create mode 100644 src/libvirt-domain-checkpoint.c create mode 100644 tests/domainbackupxml2xmlin/backup-pull.xml create mode 100644 tests/domainbackupxml2xmlin/backup-push.xml create mode 100644 tests/domainbackupxml2xmlin/empty.xml create mode 100644 tests/domainbackupxml2xmlout/backup-pull.xml create mode 100644 tests/domainbackupxml2xmlout/backup-push.xml create mode 100644 tests/domainbackupxml2xmlout/empty.xml create mode 100644 tests/domaincheckpointxml2xmlin/empty.xml create mode 100644 tests/domaincheckpointxml2xmlin/sample.xml create mode 100644 tests/domaincheckpointxml2xmlout/empty.xml create mode 100644 tests/domaincheckpointxml2xmlout/sample.xml create mode 100644 tests/domaincheckpointxml2xmltest.c create mode 100644 tools/virsh-checkpoint.c -- 2.17.2

3 23

[libvirt] [PATCH v4 0/2] Refactor virFileIsCDROM to check cdrom status
by Han Han 06 Nov '18

06 Nov '18

v3: https://www.redhat.com/archives/libvir-list/2018-July/msg00675.html v2: https://www.redhat.com/archives/libvir-list/2018-July/msg00655.html v1: https://www.redhat.com/archives/libvir-list/2018-July/msg00103.html Refactor virFileIsCDROM to virFileCheckCDROM and add new argument filled with cdrom status. Give more detailed when fail to read cdrom backend vol. Han Han (2): util: Refactor virFileIsCDROM to virFileCheckCDROM storage: Improve error handling on cdrom backend src/libvirt_private.syms | 2 +- src/qemu/qemu_domain.c | 4 ++-- src/storage/storage_util.c | 32 ++++++++++++++++++++++++++++++++ src/util/virfile.c | 36 +++++++++++++++++++++++++++++++----- src/util/virfile.h | 12 +++++++++++- 5 files changed, 77 insertions(+), 9 deletions(-) -- 2.19.1

2 4

[libvirt] [PATCH V2 0/3] libxl: add support for soft reset
by Jim Fehlig 06 Nov '18

06 Nov '18

Patches 1 and 2 are new to V2 and make slight improvements to libxlDomainShutdownThread. Patch 3 is adjusted to work with Xen 4.6. Jim Fehlig (3): libxl: remove redundant calls to virObjectEventStateQueue libxl: Remove some goto labels in libxlDomainShutdownThread libxl: add support for soft reset src/libxl/libxl_domain.c | 99 ++++++++++++++++++++++++++++------------ 1 file changed, 69 insertions(+), 30 deletions(-) -- 2.18.0

2 5

[libvirt] [PATCH v2] snapshot: Don't hose list on deletion failure
by Eric Blake 06 Nov '18

06 Nov '18

If qemuDomainSnapshotDiscard() fails for any reason (rare, but possible with an ill-timed ENOMEM or if qemuDomainSnapshotForEachQcow2() has problems talking to the qemu guest monitor), then an attempt to retry the snapshot deletion API will crash because we didn't undo the effects of virDomainSnapshotDropParent() temporarily rearranging the internal list structures, and the second attempt to drop parents will dereference NULL. Fix it by instead noting that there are only two callers to qemuDomainSnapshotDiscard(), and only one of the two callers wants the parent to be updated; thus we can move the call to virDomainSnapshotDropParent() into a code path that only gets executed on success. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- v2: avoid use-after-free --- src/qemu/qemu_domain.c | 6 ++++-- src/qemu/qemu_driver.c | 1 - 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index f00f1b3fdb..dd67be5e2a 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -8246,7 +8246,7 @@ int qemuDomainSnapshotDiscard(virQEMUDriverPtr driver, virDomainObjPtr vm, virDomainSnapshotObjPtr snap, - bool update_current, + bool update_parent, bool metadata_only) { char *snapFile = NULL; @@ -8275,7 +8275,7 @@ qemuDomainSnapshotDiscard(virQEMUDriverPtr driver, goto cleanup; if (snap == vm->current_snapshot) { - if (update_current && snap->def->parent) { + if (update_parent && snap->def->parent) { parentsnap = virDomainSnapshotFindByName(vm->snapshots, snap->def->parent); if (!parentsnap) { @@ -8298,6 +8298,8 @@ qemuDomainSnapshotDiscard(virQEMUDriverPtr driver, if (unlink(snapFile) < 0) VIR_WARN("Failed to unlink %s", snapFile); + if (update_parent) + virDomainSnapshotDropParent(snap); virDomainSnapshotObjListRemove(vm->snapshots, snap); ret = 0; diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index a52e2495d5..9f71641dfa 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -16526,7 +16526,6 @@ qemuDomainSnapshotDelete(virDomainSnapshotPtr snapshot, snap->first_child = NULL; ret = 0; } else { - virDomainSnapshotDropParent(snap); ret = qemuDomainSnapshotDiscard(driver, vm, snap, true, metadata_only); } -- 2.17.2

2 2

[libvirt] [PATCH v7 00/14] PCI passthrough support on s390
by Yi Min Zhao 06 Nov '18

06 Nov '18

Abstract ======== The PCI representation in QEMU has been extended for S390 allowing configuration of zPCI attributes like uid (user-defined identifier) and fid (PCI function identifier). The details can be found here: https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg07262.html To support the new zPCI feature of the S390 platform, a new element of PCI address is introduced. It has two optional attributes, @uid and @fid. For example: <hostdev mode='subsystem' type='pci'> <driver name='vfio'/> <source> <address domain='0x0001' bus='0x00' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'> <zpci uid='0x0003' fid='0x00000027'/> </address> </hostdev> If they are defined by the user, unique values within the guest domain must be used. If they are not specified and the architecture requires them, they are automatically generated with non-conflicting values. zPCI address as an extension of the PCI address are stored in a new structure 'virZPCIDeviceAddress' which is a member of common PCI Address structure. Additionally, two hashtables are used for assignment and reservation of zPCI uid/fid. In support of extending the PCI address, a new PCI address extension flag is introduced. This extension flag allows is not only dedicated for the S390 platform but also other architectures needing certain extensions to PCI address space. Code Base ========= commit in master: 3a1cdb06fd conf: Fix bug in finding alloc through matching vcpus Change Log ========== v6->v7: 1. Optimize some functions' names and code logic. 2. Fixup build error. 3. Add negative test case for patch 9. 4. Use virXMLFormatElement() in virDomainDeviceInfoFormat(). v5->v6: 1. Modify zPCI XML definition. 2. Optimize the logic of zPCI address assignment and reservation. 3. Add extension flag into PCI address structure. 4. Update commit messages. v4->v5: 1. Update the version number. 2. Fixup code style error. 3. Separate qemu code into single patch. 4. Rebase the patches to the new code of master branch. v3->v4: 1. Update docs. 2. Format code style. 3. Optimize zPCI support check. 4. Move the check of zPCI defined in xml but unsupported by Qemu to qemuDomainDeviceDefValidate(). 5. Change zpci address member of PCI address struct from pointer to instance. 6. Modify zpci address definition principle. Currently the user must either define both of uid and fid or not. v2->v3: 1. Revise code style. 2. Update test cases. 3. Introduce qemuDomainCollectPCIAddressExtension() to collect PCI extension addresses. 4. Introduce virDeviceInfoPCIAddressExtensionPresent() to check if zPCI address exists. 5. Optimize zPCI address check logic. 6. Optimize passed parameters of zPCI addr alloc/release/reserve functions. 7. Report enum range error in qemuDomainDeviceSupportZPCI(). 8. Update commit messages. v1->v2: 1. Separate test commit and merge testcases into corresponding commits that introduce the functionalities firstly. 2. Spare some checks for zpci device. 3. Add vsock and controller support. 4. Add uin32 type schema. 5. Rename zpciuid and zpcifid to zpci_uid and zpci_fid. 6. Always return multibus support on S390. Yi Min Zhao (14): conf: Add definitions for 'uid' and 'fid' PCI address attributes qemu: Introduce zPCI capability conf: Introduce a new PCI address extension flag qemu: Enable PCI multi bus for S390 guests qemu: Auto add pci-root for s390/s390x guests conf: Introduce address caching for PCI extensions conf: use virXMLFormatElement() in virDomainDeviceInfoFormat() conf: Introduce parser, formatter for uid and fid qemu: Add zPCI address definition check conf: Allocate/release 'uid' and 'fid' in PCI address qemu: Generate and use zPCI device in QEMU command line qemu: Add hotpluging support for PCI devices on S390 guests docs: Add 'uid' and 'fid' information news: Update news for PCI address extension attributes cfg.mk | 1 + docs/formatdomain.html.in | 10 +- docs/news.xml | 11 + docs/schemas/basictypes.rng | 27 ++ docs/schemas/domaincommon.rng | 1 + src/bhyve/bhyve_device.c | 3 +- src/conf/device_conf.c | 69 ++++ src/conf/device_conf.h | 7 + src/conf/domain_addr.c | 340 +++++++++++++++++- src/conf/domain_addr.h | 27 +- src/conf/domain_conf.c | 50 ++- src/libvirt_private.syms | 7 + src/qemu/qemu_capabilities.c | 6 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 104 ++++++ src/qemu/qemu_command.h | 2 + src/qemu/qemu_domain.c | 37 ++ src/qemu/qemu_domain_address.c | 205 ++++++++++- src/qemu/qemu_hotplug.c | 160 ++++++++- src/util/virpci.c | 26 ++ src/util/virpci.h | 15 + .../caps_2.10.0.s390x.xml | 1 + .../caps_2.11.0.s390x.xml | 1 + .../caps_2.12.0.s390x.xml | 1 + .../qemucapabilitiesdata/caps_2.7.0.s390x.xml | 1 + .../qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 + .../qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 + .../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 1 + .../disk-virtio-s390-zpci.args | 26 ++ .../disk-virtio-s390-zpci.xml | 19 + .../hostdev-vfio-zpci-autogenerate.args | 25 ++ .../hostdev-vfio-zpci-autogenerate.xml | 18 + .../hostdev-vfio-zpci-boundaries.args | 29 ++ .../hostdev-vfio-zpci-boundaries.xml | 30 ++ .../hostdev-vfio-zpci-multidomain-many.args | 39 ++ .../hostdev-vfio-zpci-multidomain-many.xml | 79 ++++ .../hostdev-vfio-zpci-wrong-arch.xml | 34 ++ tests/qemuxml2argvdata/hostdev-vfio-zpci.args | 25 ++ tests/qemuxml2argvdata/hostdev-vfio-zpci.xml | 21 ++ tests/qemuxml2argvtest.c | 22 ++ .../disk-virtio-s390-zpci.xml | 31 ++ .../hostdev-vfio-zpci-autogenerate.xml | 34 ++ .../hostdev-vfio-zpci-boundaries.xml | 48 +++ .../hostdev-vfio-zpci-multidomain-many.xml | 97 +++++ .../qemuxml2xmloutdata/hostdev-vfio-zpci.xml | 32 ++ tests/qemuxml2xmltest.c | 17 + 46 files changed, 1707 insertions(+), 35 deletions(-) create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.args create mode 100644 tests/qemuxml2argvdata/disk-virtio-s390-zpci.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-autogenerate.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-boundaries.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-multidomain-many.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci-wrong-arch.xml create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.args create mode 100644 tests/qemuxml2argvdata/hostdev-vfio-zpci.xml create mode 100644 tests/qemuxml2xmloutdata/disk-virtio-s390-zpci.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-autogenerate.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-boundaries.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci-multidomain-many.xml create mode 100644 tests/qemuxml2xmloutdata/hostdev-vfio-zpci.xml -- Yi Min

2 23

[libvirt] [PATCH v1 1/1] qemu_domain, qemu_process: maxCpus check to non-x86 guests
by Daniel Henrique Barboza 03 Nov '18

03 Nov '18

This patch makes two quality of life changes for non-x86 guests. The first one is a maxCpus validation at qemuDomainDefValidate. The check is made by the same function used to do that at qemuProcessStartValidateXML, qemuValidateCpuCount. This ensures that the user doesn't goes over the board with the maxCpus value when editing the XML, only to be faced with a runtime error when starting it. To do that, the following changes were made: - qemuValidateCpuCount was made public. It was renamed to qemuProcessValidateCpuCount to be compliant with the other public methods at qemu_process.h; - the method signature was slightly adapted to fit the const 'def' variable used in qemuDomainDefValidate. This change has no downside in in its original usage at qemuProcessStartValidateXML. The second QoL change is adding the maxCpus value in the error message of the now qemuProcessValidateCpuCount. This simple change allows the user to quickly edit the XML to comply with the acceptable limit without having to know QEMU internals. x86 guests, that might have been created prior to the x86 qemuDomainDefValidate maxCpus check code, will also benefit from this change. After this patch, this is the expect result running a Power 9 guest with a maxCpus of 40000: $ ./virsh start dhb error: Failed to start domain dhb error: unsupported configuration: Maximum CPUs greater than specified machine type limit 240 And this is the result when trying to edit maxCpus to an invalid value: $ ./virsh edit dhb error: unsupported configuration: Maximum CPUs greater than specified machine type limit 240 Failed. Try again? [y,n,i,f,?]: error: unsupported configuration: Maximum CPUs greater than specified machine type limit 240 Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com> --- src/qemu/qemu_domain.c | 5 +++++ src/qemu/qemu_process.c | 13 +++++++------ src/qemu/qemu_process.h | 3 +++ 3 files changed, 15 insertions(+), 6 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 939b2a3da2..5a39b11da7 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -4100,6 +4100,11 @@ qemuDomainDefValidate(const virDomainDef *def, } } + if (!ARCH_IS_X86(def->os.arch) && + qemuProcessValidateCpuCount(def, qemuCaps) < 0) { + goto cleanup; + } + if (def->nresctrls && def->virtType != VIR_DOMAIN_VIRT_KVM) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 29b0ba1590..0de5b503d6 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -3901,9 +3901,9 @@ qemuProcessSPICEAllocatePorts(virQEMUDriverPtr driver, } -static int -qemuValidateCpuCount(virDomainDefPtr def, - virQEMUCapsPtr qemuCaps) +int +qemuProcessValidateCpuCount(const virDomainDef *def, + virQEMUCapsPtr qemuCaps) { unsigned int maxCpus = virQEMUCapsGetMachineMaxCpus(qemuCaps, def->os.machine); @@ -3914,8 +3914,9 @@ qemuValidateCpuCount(virDomainDefPtr def, } if (maxCpus > 0 && virDomainDefGetVcpusMax(def) > maxCpus) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", - _("Maximum CPUs greater than specified machine type limit")); + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("Maximum CPUs greater than specified machine type limit %u"), + maxCpus); return -1; } @@ -5165,7 +5166,7 @@ qemuProcessStartValidateXML(virQEMUDriverPtr driver, * If back compat isn't a concern, XML validation should probably * be done at parse time. */ - if (qemuValidateCpuCount(vm->def, qemuCaps) < 0) + if (qemuProcessValidateCpuCount(vm->def, qemuCaps) < 0) return -1; /* checks below should not be executed when starting a qemu process for a diff --git a/src/qemu/qemu_process.h b/src/qemu/qemu_process.h index c2f7c2b5d2..1716230475 100644 --- a/src/qemu/qemu_process.h +++ b/src/qemu/qemu_process.h @@ -215,4 +215,7 @@ int qemuProcessStartManagedPRDaemon(virDomainObjPtr vm); void qemuProcessKillManagedPRDaemon(virDomainObjPtr vm); +int qemuProcessValidateCpuCount(const virDomainDef *def, + virQEMUCapsPtr qemuCaps); + #endif /* __QEMU_PROCESS_H__ */ -- 2.17.1

2 3