- Devel - libvirt List Archives

[libvirt] [PATCH 00/11] qemu: Add formatter for 'blockdev-create' JSON (blockdev-add saga)
by Peter Krempa 08 Jul '19

08 Jul '19

To allow using blockdev-create we need to be able to generate the properties for it, this series adds the necessary bits and also converts to use 'auto-read-only' instead of 'read-only'. Kevin, please look into the test data to see if there's something wrong with the semantic usage. The data is validated against the QMP schema. Format in 2/11 will be used as the 'backing-store' string via the json:// pseudo protocol for recording into new files for network use. 5/11 is the conversion to use auto-read-only. The test data in the patch covers stadard use with -blockdev/blockdev-add 11/11 is the format to be used with 'blockdev-create' Thanks. Peter Krempa (11): qemu: block: Allow skipping non-target related data when formating disk JSON tests: qemublock: Add testing of pure disk source specification JSON generator util: json: Introduce helper to prepend string into a virJSONValueObject qemu: block: Extract formating of 'driver' attribute from child formatters qemu: block: Use 'auto-read-only' instead of 'read-only' for backing chain qemu: block: Add generator for image format creation properties qemu: block: Add generator for creating storage with blockdev-create qemu: domain: Export qemuDomainPrepareStorageSourceBlockdev conf: snapshot: Export virDomainSnapshotDiskDefParseXML conf: snapshot: Provide a function to free virDomainSnapshotDiskDefPtr tests: qemublock: Add testing of 'blockdev-create' generators src/conf/snapshot_conf.c | 13 +- src/conf/snapshot_conf.h | 6 + src/libvirt_private.syms | 1 + src/qemu/qemu_block.c | 584 ++++++++++++++++-- src/qemu/qemu_block.h | 18 +- src/qemu/qemu_command.c | 4 +- src/qemu/qemu_domain.c | 9 +- src/qemu/qemu_domain.h | 5 + src/qemu/qemu_migration.c | 4 +- src/util/virjson.c | 50 +- src/util/virjson.h | 1 + tests/qemublocktest.c | 244 +++++++- .../imagecreate/luks-encopts.json | 19 + .../imagecreate/luks-encopts.xml | 16 + .../imagecreate/luks-noopts.json | 14 + .../imagecreate/luks-noopts.xml | 14 + .../imagecreate/network-gluster-qcow2.json | 28 + .../imagecreate/network-gluster-qcow2.xml | 13 + .../imagecreate/network-rbd-qcow2.json | 26 + .../imagecreate/network-rbd-qcow2.xml | 13 + .../imagecreate/network-sheepdog-qcow2.json | 20 + .../imagecreate/network-sheepdog-qcow2.xml | 12 + .../imagecreate/network-ssh-qcow2.json | 19 + .../imagecreate/network-ssh-qcow2.xml | 12 + .../imagecreate/qcow2-backing-luks.json | 15 + .../imagecreate/qcow2-backing-luks.xml | 1 + .../imagecreate/qcow2-backing-raw-nbd.json | 15 + .../imagecreate/qcow2-backing-raw-nbd.xml | 1 + .../imagecreate/qcow2-backing-raw.json | 15 + .../imagecreate/qcow2-backing-raw.xml | 1 + .../qcow2-luks-encopts-backing.json | 24 + .../qcow2-luks-encopts-backing.xml | 1 + .../imagecreate/qcow2-luks-encopts.json | 22 + .../imagecreate/qcow2-luks-encopts.xml | 16 + .../imagecreate/qcow2-luks-noopts.json | 17 + .../imagecreate/qcow2-luks-noopts.xml | 14 + .../qemublocktestdata/imagecreate/qcow2.json | 13 + tests/qemublocktestdata/imagecreate/qcow2.xml | 11 + .../imagecreate/raw-nbd.json | 4 + .../qemublocktestdata/imagecreate/raw-nbd.xml | 12 + tests/qemublocktestdata/imagecreate/raw.json | 9 + tests/qemublocktestdata/imagecreate/raw.xml | 11 + .../xml2json/block-raw-noopts-srconly.json | 4 + .../xml2json/block-raw-noopts.json | 2 +- .../block-raw-reservations-srconly.json | 4 + .../xml2json/block-raw-reservations.json | 2 +- .../xml2json/dir-fat-cache-srconly.json | 5 + .../xml2json/dir-fat-cache.json | 2 +- .../xml2json/dir-fat-floppy-srconly.json | 5 + .../xml2json/dir-fat-floppy.json | 2 +- .../xml2json/dir-fat-readonly-srconly.json | 5 + .../xml2json/dir-fat-readonly.json | 2 +- ...ile-backing_basic-aio_threads-srconly.json | 24 + .../file-backing_basic-aio_threads.json | 8 +- ...acking_basic-cache-directsync-srconly.json | 24 + .../file-backing_basic-cache-directsync.json | 8 +- ...file-backing_basic-cache-none-srconly.json | 24 + .../file-backing_basic-cache-none.json | 8 +- ...le-backing_basic-cache-unsafe-srconly.json | 24 + .../file-backing_basic-cache-unsafe.json | 8 +- ...backing_basic-cache-writeback-srconly.json | 24 + .../file-backing_basic-cache-writeback.json | 8 +- ...king_basic-cache-writethrough-srconly.json | 24 + ...file-backing_basic-cache-writethrough.json | 8 +- .../file-backing_basic-detect-srconly.json | 24 + .../xml2json/file-backing_basic-detect.json | 8 +- .../file-backing_basic-noopts-srconly.json | 16 + .../xml2json/file-backing_basic-noopts.json | 8 +- ...le-backing_basic-unmap-detect-srconly.json | 24 + .../file-backing_basic-unmap-detect.json | 8 +- ...le-backing_basic-unmap-ignore-srconly.json | 24 + .../file-backing_basic-unmap-ignore.json | 8 +- .../file-backing_basic-unmap-srconly.json | 24 + .../xml2json/file-backing_basic-unmap.json | 8 +- .../xml2json/file-bochs-noopts-srconly.json | 4 + .../xml2json/file-bochs-noopts.json | 2 +- .../xml2json/file-cloop-noopts-srconly.json | 4 + .../xml2json/file-cloop-noopts.json | 2 +- .../xml2json/file-dmg-noopts-srconly.json | 4 + .../xml2json/file-dmg-noopts.json | 2 +- .../xml2json/file-ploop-noopts-srconly.json | 4 + .../xml2json/file-ploop-noopts.json | 2 +- ...cow2-backing-chain-encryption-srconly.json | 8 + .../file-qcow2-backing-chain-encryption.json | 4 +- ...le-qcow2-backing-chain-noopts-srconly.json | 40 ++ .../file-qcow2-backing-chain-noopts.json | 20 +- ...w2-backing-chain-unterminated-srconly.json | 8 + ...file-qcow2-backing-chain-unterminated.json | 4 +- .../xml2json/file-raw-aio_native-srconly.json | 4 + .../xml2json/file-raw-aio_native.json | 2 +- .../xml2json/file-raw-luks-srconly.json | 4 + .../xml2json/file-raw-luks.json | 2 +- .../xml2json/file-raw-noopts-srconly.json | 4 + .../xml2json/file-raw-noopts.json | 2 +- .../xml2json/file-vdi-noopts-srconly.json | 4 + .../xml2json/file-vdi-noopts.json | 2 +- .../xml2json/file-vhd-noopts-srconly.json | 4 + .../xml2json/file-vhd-noopts.json | 2 +- .../xml2json/file-vpc-noopts-srconly.json | 4 + .../xml2json/file-vpc-noopts.json | 2 +- .../xml2json/network-nbd-tls-srconly.json | 8 + .../xml2json/network-nbd-tls.json | 2 +- ...w2-backing-chain-cache-unsafe-srconly.json | 22 + ...work-qcow2-backing-chain-cache-unsafe.json | 4 +- ...backing-chain-encryption_auth-srconly.json | 22 + ...k-qcow2-backing-chain-encryption_auth.json | 4 +- .../qemu-ns.x86_64-4.0.0.args | 2 +- .../qemu-ns.x86_64-latest.args | 2 +- 108 files changed, 1764 insertions(+), 170 deletions(-) create mode 100644 tests/qemublocktestdata/imagecreate/luks-encopts.json create mode 100644 tests/qemublocktestdata/imagecreate/luks-encopts.xml create mode 100644 tests/qemublocktestdata/imagecreate/luks-noopts.json create mode 100644 tests/qemublocktestdata/imagecreate/luks-noopts.xml create mode 100644 tests/qemublocktestdata/imagecreate/network-gluster-qcow2.json create mode 100644 tests/qemublocktestdata/imagecreate/network-gluster-qcow2.xml create mode 100644 tests/qemublocktestdata/imagecreate/network-rbd-qcow2.json create mode 100644 tests/qemublocktestdata/imagecreate/network-rbd-qcow2.xml create mode 100644 tests/qemublocktestdata/imagecreate/network-sheepdog-qcow2.json create mode 100644 tests/qemublocktestdata/imagecreate/network-sheepdog-qcow2.xml create mode 100644 tests/qemublocktestdata/imagecreate/network-ssh-qcow2.json create mode 100644 tests/qemublocktestdata/imagecreate/network-ssh-qcow2.xml create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-backing-luks.json create mode 120000 tests/qemublocktestdata/imagecreate/qcow2-backing-luks.xml create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-backing-raw-nbd.json create mode 120000 tests/qemublocktestdata/imagecreate/qcow2-backing-raw-nbd.xml create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-backing-raw.json create mode 120000 tests/qemublocktestdata/imagecreate/qcow2-backing-raw.xml create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-luks-encopts-backing.json create mode 120000 tests/qemublocktestdata/imagecreate/qcow2-luks-encopts-backing.xml create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-luks-encopts.json create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-luks-encopts.xml create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-luks-noopts.json create mode 100644 tests/qemublocktestdata/imagecreate/qcow2-luks-noopts.xml create mode 100644 tests/qemublocktestdata/imagecreate/qcow2.json create mode 100644 tests/qemublocktestdata/imagecreate/qcow2.xml create mode 100644 tests/qemublocktestdata/imagecreate/raw-nbd.json create mode 100644 tests/qemublocktestdata/imagecreate/raw-nbd.xml create mode 100644 tests/qemublocktestdata/imagecreate/raw.json create mode 100644 tests/qemublocktestdata/imagecreate/raw.xml create mode 100644 tests/qemublocktestdata/xml2json/block-raw-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/block-raw-reservations-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/dir-fat-cache-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/dir-fat-floppy-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/dir-fat-readonly-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-backing_basic-aio_threads-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-backing_basic-cache-directsync-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-backing_basic-cache-none-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-backing_basic-cache-unsafe-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-backing_basic-cache-writeback-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-backing_basic-cache-writethrough-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-backing_basic-detect-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-backing_basic-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-backing_basic-unmap-detect-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-backing_basic-unmap-ignore-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-backing_basic-unmap-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-bochs-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-cloop-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-dmg-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-ploop-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-qcow2-backing-chain-encryption-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-qcow2-backing-chain-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-qcow2-backing-chain-unterminated-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-raw-aio_native-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-raw-luks-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-raw-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-vdi-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-vhd-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/file-vpc-noopts-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/network-nbd-tls-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/network-qcow2-backing-chain-cache-unsafe-srconly.json create mode 100644 tests/qemublocktestdata/xml2json/network-qcow2-backing-chain-encryption_auth-srconly.json -- 2.21.0

2 22

[libvirt] [PATCH] m4: Fix check for yajl.pc
by Andrea Bolognani 08 Jul '19

08 Jul '19

Commit 44b8df4cb4b3 introduced a check for yajl.pc that is extremely similar to the one we already had in place for readline.pc - so similar, in fact, that it's still looking for readline.pc instead of yajl.pc :) Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- m4/virt-yajl.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/m4/virt-yajl.m4 b/m4/virt-yajl.m4 index 70cfb983e3..b602abd0a7 100644 --- a/m4/virt-yajl.m4 +++ b/m4/virt-yajl.m4 @@ -24,7 +24,7 @@ AC_DEFUN([LIBVIRT_ARG_YAJL],[ AC_DEFUN([LIBVIRT_CHECK_YAJL],[ dnl YAJL JSON library http://lloyd.github.com/yajl/ - PKG_CHECK_EXISTS([readline], [use_pkgconfig=1], [use_pkgconfig=0]) + PKG_CHECK_EXISTS([yajl], [use_pkgconfig=1], [use_pkgconfig=0]) if test $use_pkgconfig = 1; then dnl 2.0.3 was the version where the pkg-config file was first added -- 2.21.0

2 1

[libvirt] [PATCH 00/23] Use a slirp helper process
by marcandre.lureau＠redhat.com 08 Jul '19

08 Jul '19

From: Marc-André Lureau <marcandre.lureau(a)redhat.com> Hi, SLIRP networking can be running in a separate process. This allows for stricter security policies for QEMU & SLIRP, as SLIRP is notoriously not very safe (discussed on ML, various CVEs, and even the code says so explicitly in the comments), yet people rely on it for various reasons. With this series, for a network interface "user", libvirt will: - check the slirp-helper presence and capabilites (see [1]) - setup a socket pair between qemu and the helper - use -net socket - setup migration thanks to dbus-vmstate There are no changes required to domain configuration to benefit it. "guestfwd" isn't supported at this point, but it is known to be in a broken state with libvirt+qemu anyway. The dbus-vmstate is being proposed to QEMU. The libslirp-rs slirp-helper hasn't yet received a release, but I plan to make one soon, depending on the feedback. fwiw, I have been working on an alternative rust-only implementation of a slirp-helper that will also follow [1]. [1] https://gitlab.freedesktop.org/slirp/libslirp-rs/blob/master/src/bin/README… Marc-André Lureau (23): Add .editorconfig dbus: correctly build reply message qemu: replace logCtxt with qemuDomainLogAppendMessage() qemu: reset VM id after external devices stop qemu: add socket datagram capability qemu: add dbus-vmstate capability qemu-conf: add configurable dbus-daemon location qemu-conf: add dbusStateDir qemu-security: add qemuSecurityCommandRun() qemu: add a DBus daemon helper unit qemu: add dbus-vmstate helper migration support domain-conf: add network def private data qemu: add qemuDomainNetworkPrivate qemu-conf: add configurable slirp-helper location qemu: add slirp helper unit qemu-domain: save and restore slirp state qemu: add a flag to the cookie to prevent slirp-helper setup qemu-migration: prevent migration if slirp cannot be migrated qemu-extdevice: prepare, start and stop slirp-helper qemu-command: use -net socket,fd= with slirp-helper qemu-process: prepare slirp-helper qemu-hotplug: handle hotplugging of slirp-helper tests: add slirp-helper qemuxml2argv test .editorconfig | 21 + m4/virt-driver-qemu.m4 | 10 + src/conf/domain_conf.c | 21 +- src/conf/domain_conf.h | 6 + src/qemu/Makefile.inc.am | 6 + src/qemu/libvirtd_qemu.aug | 2 + src/qemu/qemu.conf | 6 + src/qemu/qemu_alias.c | 7 + src/qemu/qemu_alias.h | 2 + src/qemu/qemu_capabilities.c | 10 + src/qemu/qemu_capabilities.h | 4 + src/qemu/qemu_command.c | 100 ++++- src/qemu/qemu_command.h | 6 +- src/qemu/qemu_conf.c | 20 +- src/qemu/qemu_conf.h | 3 + src/qemu/qemu_dbus.c | 384 ++++++++++++++++ src/qemu/qemu_dbus.h | 44 ++ src/qemu/qemu_domain.c | 206 ++++++++- src/qemu/qemu_domain.h | 27 ++ src/qemu/qemu_driver.c | 11 +- src/qemu/qemu_extdevice.c | 82 ++-- src/qemu/qemu_extdevice.h | 10 +- src/qemu/qemu_hotplug.c | 118 ++++- src/qemu/qemu_hotplug.h | 8 + src/qemu/qemu_interface.c | 27 ++ src/qemu/qemu_interface.h | 4 + src/qemu/qemu_migration.c | 62 +++ src/qemu/qemu_monitor.c | 35 +- src/qemu/qemu_monitor.h | 6 +- src/qemu/qemu_monitor_json.c | 15 + src/qemu/qemu_monitor_json.h | 5 + src/qemu/qemu_process.c | 37 +- src/qemu/qemu_process.h | 1 + src/qemu/qemu_security.c | 22 + src/qemu/qemu_security.h | 6 + src/qemu/qemu_slirp.c | 412 ++++++++++++++++++ src/qemu/qemu_slirp.h | 78 ++++ src/qemu/qemu_tpm.c | 10 +- src/qemu/qemu_tpm.h | 5 +- src/qemu/test_libvirtd_qemu.aug.in | 2 + src/util/virdbus.c | 18 +- src/util/virdbus.h | 6 +- tests/Makefile.am | 1 + .../caps_4.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + .../caps_4.0.0.riscv32.xml | 1 + .../caps_4.0.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 + .../caps_4.0.0.x86_64.xml | 1 + .../caps_4.1.0.x86_64.xml | 1 + .../net-user.x86_64-4.0.0.args | 34 ++ tests/qemuxml2argvtest.c | 16 + tests/testutilsqemu.h | 1 + tests/virfirewalltest.c | 9 +- tests/virpolkittest.c | 3 +- 55 files changed, 1849 insertions(+), 87 deletions(-) create mode 100644 .editorconfig create mode 100644 src/qemu/qemu_dbus.c create mode 100644 src/qemu/qemu_dbus.h create mode 100644 src/qemu/qemu_slirp.c create mode 100644 src/qemu/qemu_slirp.h create mode 100644 tests/qemuxml2argvdata/net-user.x86_64-4.0.0.args -- 2.22.0.214.g8dca754b1e

1 23

[libvirt] [PATCH] libvirt: remove link to outdated mailing list post
by Daniel P. Berrangé 08 Jul '19

08 Jul '19

The virConnectGetType() method has an unfortunate signature, returning a static string that must not be freed by the caller. The remote driver, however, gets this string dynamically over an RPC call, which raised a design discussion on the mailing list. Eventually the problem was resolved by having the remote driver cache the returned string internally and free it when the connection was closed. The link to the mailing list is thus talking about a problem that does not actually exist in the final implementation, and at best serves to confuse the reader into thinking there might be a memory leak. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/libvirt-host.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/libvirt-host.c b/src/libvirt-host.c index 2978825d22..e5c4e5f72a 100644 --- a/src/libvirt-host.c +++ b/src/libvirt-host.c @@ -98,9 +98,6 @@ virConnectSupportsFeature(virConnectPtr conn, int feature) * hypervisor, use virConnectGetCapabilities(). * * Returns NULL in case of error, a static zero terminated string otherwise. - * - * See also: - * http://www.redhat.com/archives/libvir-list/2007-February/msg00096.html */ const char * virConnectGetType(virConnectPtr conn) -- 2.21.0

2 1

[libvirt] [PATCH v8 00/21] Incremental backups
by Eric Blake 07 Jul '19

07 Jul '19

The API is fairly stable, but there are still probably code cleanups worth adding to the qemu driver implementation. I've also seen a desire on the list to support all APIs in the test driver, so I'll try and whip that together for my next round of patches. If we are confident that the API is worth having in 5.3 (especially since the earlier part of this series already has positive reviews), then it's probably worth committing that part of the series now even while I still address review comments on the later patches. I've pushed a tag backup-v8 to both my libvirt.git and libvirt-python.git repos to match: https://repo.or.cz/libvirt/ericb.git/shortlog/refs/tags/backup-v8 https://repo.or.cz/libvirt-python/ericb.git/shortlog/refs/tags/backup-v8 Here's hoping we're happy enough with the API, including the fact that rudimentary operation of pull mode backups work with qemu 4.0-rc1, for this to make it into the 5.2 release. Notable diffs from v7: - address several review comments (although I didn't get to every comment later in the series) - actually support job id of 0 (it was documented but not working in v7) - add support for Unix socket pull mode backups - improve checkpoint XML handling (more tests, separate postparse actions out from initial parse) - rebase to master 001/21:[0044] [FC] 'backup: Document new XML for checkpoints' 002/21:[----] [--] 'backup: Document new XML for backups' 003/21:[0006] [FC] 'backup: Introduce virDomainCheckpoint APIs' 004/21:[0002] [FC] 'backup: Introduce virDomainBackup APIs' 005/21:[----] [--] 'backup: Document nuances between different state capture APIs' 006/21:[0304] [FC] 'backup: Parse and output checkpoint XML' 007/21:[0007] [FC] 'backup: Allow for lists of checkpoint objects' 008/21:[0004] [FC] 'backup: Add new domain:checkpoint access control' 009/21:[0043] [FC] 'backup: Implement backup APIs for remote driver' 010/21:[down] 'conf: Add parameter to virDomainDiskSourceFormat' 011/21:[0019] [FC] 'backup: Parse and output backup XML' 012/21:[0006] [FC] 'backup: Implement virsh support for checkpoints' 013/21:[0002] [FC] 'backup: Implement virsh support for backup' 014/21:[down] 'backup: Prepare for Unix sockets in QMP nbd-server-start' 015/21:[0008] [FC] 'backup: Add new qemu monitor interactions' 016/21:[0022] [FC] 'backup: qemu: Implement metadata tracking for checkpoint APIs' 017/21:[0004] [FC] 'backup: Wire up qemu checkpoint commands over QMP' 018/21:[0019] [FC] 'backup: qemu: Implement framework for backup job APIs' 019/21:[0042] [FC] 'backup: Wire up qemu full pull backup commands over QMP' 020/21:[----] [-C] 'backup: qemu: Wire up qemu full push backup commands over QMP' 021/21:[0003] [FC] 'backup: implement qemu incremental pull backup' Eric Blake (21): backup: Document new XML for checkpoints backup: Document new XML for backups backup: Introduce virDomainCheckpoint APIs backup: Introduce virDomainBackup APIs backup: Document nuances between different state capture APIs backup: Parse and output checkpoint XML backup: Allow for lists of checkpoint objects backup: Add new domain:checkpoint access control backup: Implement backup APIs for remote driver conf: Add parameter to virDomainDiskSourceFormat backup: Parse and output backup XML backup: Implement virsh support for checkpoints backup: Implement virsh support for backup backup: Prepare for Unix sockets in QMP nbd-server-start backup: Add new qemu monitor interactions backup: qemu: Implement metadata tracking for checkpoint APIs backup: Wire up qemu checkpoint commands over QMP backup: qemu: Implement framework for backup job APIs backup: Wire up qemu full pull backup commands over QMP backup: qemu: Wire up qemu full push backup commands over QMP backup: implement qemu incremental pull backup include/libvirt/libvirt-domain-checkpoint.h | 161 ++ include/libvirt/libvirt-domain-snapshot.h | 8 +- include/libvirt/libvirt-domain.h | 47 +- include/libvirt/libvirt.h | 5 +- src/access/viraccessperm.h | 6 + src/conf/backup_conf.h | 97 + src/conf/checkpoint_conf.h | 103 ++ src/conf/domain_conf.h | 3 + src/conf/virconftypes.h | 12 + src/conf/virdomaincheckpointobjlist.h | 74 + src/conf/virdomainmomentobjlist.h | 7 +- src/conf/virdomainobjlist.h | 7 +- src/driver-hypervisor.h | 79 + src/qemu/qemu_block.h | 3 + src/qemu/qemu_blockjob.h | 1 + src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_conf.h | 2 + src/qemu/qemu_domain.h | 19 + src/qemu/qemu_monitor.h | 27 +- src/qemu/qemu_monitor_json.h | 22 +- 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 | 10 +- docs/domainstatecapture.html.in | 315 ++++ docs/format.html.in | 2 + docs/formatbackup.html.in | 184 ++ docs/formatcheckpoint.html.in | 204 +++ docs/formatsnapshot.html.in | 2 + docs/index.html.in | 4 +- docs/schemas/domainbackup.rng | 219 +++ docs/schemas/domaincheckpoint.rng | 87 + 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 | 3 +- src/conf/Makefile.inc.am | 6 + src/conf/backup_conf.c | 538 ++++++ src/conf/checkpoint_conf.c | 636 +++++++ src/conf/domain_conf.c | 22 +- src/conf/snapshot_conf.c | 3 +- src/conf/virdomaincheckpointobjlist.c | 223 +++ src/conf/virdomainmomentobjlist.c | 40 +- src/conf/virdomainobjlist.c | 11 + src/conf/virdomainsnapshotobjlist.c | 2 +- src/libvirt-domain-checkpoint.c | 750 ++++++++ src/libvirt-domain-snapshot.c | 89 + src/libvirt-domain.c | 237 ++- src/libvirt_private.syms | 32 + src/libvirt_public.syms | 24 + src/qemu/qemu_block.c | 12 + src/qemu/qemu_capabilities.c | 4 + src/qemu/qemu_conf.c | 5 + src/qemu/qemu_domain.c | 221 ++- src/qemu/qemu_driver.c | 1577 +++++++++++++++++ src/qemu/qemu_migration.c | 9 +- src/qemu/qemu_monitor.c | 72 +- src/qemu/qemu_monitor_json.c | 222 ++- src/qemu/qemu_process.c | 9 + src/remote/remote_daemon_dispatch.c | 20 + src/remote/remote_driver.c | 32 +- src/remote/remote_protocol.x | 258 ++- src/remote_protocol-structs | 139 ++ src/rpc/gendispatch.pl | 32 +- tests/Makefile.am | 13 +- 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/domaincheckpointxml2xmlin/size.xml | 4 + tests/domaincheckpointxml2xmlout/empty.xml | 7 + .../internal-active-invalid.xml | 53 + .../internal-inactive-invalid.xml | 53 + tests/domaincheckpointxml2xmlout/redefine.xml | 63 + tests/domaincheckpointxml2xmlout/sample.xml | 12 + tests/domaincheckpointxml2xmlout/size.xml | 11 + tests/domaincheckpointxml2xmltest.c | 223 +++ tests/qemublocktest.c | 3 +- .../caps_4.0.0.riscv32.xml | 2 + .../caps_4.0.0.riscv64.xml | 2 + .../caps_4.0.0.x86_64.xml | 2 + tests/qemumonitorjsontest.c | 32 +- tests/virschematest.c | 4 + tests/virstoragetest.c | 2 +- tools/Makefile.am | 1 + tools/virsh-checkpoint.c | 1370 ++++++++++++++ tools/virsh-completer.c | 51 + tools/virsh-domain-monitor.c | 23 + tools/virsh-domain.c | 268 ++- tools/virsh-snapshot.c | 37 +- tools/virsh-util.c | 11 + tools/virsh.c | 2 + tools/virsh.pod | 302 +++- 102 files changed, 9502 insertions(+), 100 deletions(-) create mode 100644 include/libvirt/libvirt-domain-checkpoint.h create mode 100644 src/conf/backup_conf.h create mode 100644 src/conf/checkpoint_conf.h create mode 100644 src/conf/virdomaincheckpointobjlist.h create mode 100644 tools/virsh-checkpoint.h create mode 100644 docs/domainstatecapture.html.in create mode 100644 docs/formatbackup.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/backup_conf.c create mode 100644 src/conf/checkpoint_conf.c create mode 100644 src/conf/virdomaincheckpointobjlist.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/domaincheckpointxml2xmlin/size.xml create mode 100644 tests/domaincheckpointxml2xmlout/empty.xml create mode 100644 tests/domaincheckpointxml2xmlout/internal-active-invalid.xml create mode 100644 tests/domaincheckpointxml2xmlout/internal-inactive-invalid.xml create mode 100644 tests/domaincheckpointxml2xmlout/redefine.xml create mode 100644 tests/domaincheckpointxml2xmlout/sample.xml create mode 100644 tests/domaincheckpointxml2xmlout/size.xml create mode 100644 tests/domaincheckpointxml2xmltest.c create mode 100644 tools/virsh-checkpoint.c -- 2.20.1

2 46

[libvirt] [PATCH] docs: minor updates to to new API doc
by Jonathon Jongsma 05 Jul '19

05 Jul '19

Fix a filename and add a couple missing words. Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- docs/api_extension.html.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/api_extension.html.in b/docs/api_extension.html.in index d7fbbd6e90..3bbaf4893c 100644 --- a/docs/api_extension.html.in +++ b/docs/api_extension.html.in @@ -229,7 +229,7 @@ <h3><a name='rpcclient'>Implement the RPC client</a></h3> <p> - Implementing the uses the rpcgen generated .h files. The remote + Implementing the RPC client uses the rpcgen generated .h files. The remote method calls go in: </p> @@ -256,7 +256,7 @@ The server side dispatchers are implemented in: </p> - <p><code>src/remote/daemon_dispatch.c</code></p> + <p><code>src/remote/remote_daemon_dispatch.c</code></p> <p>Again, this step uses the .h files generated by make rpcgen.</p> -- 2.20.1

2 1

[libvirt] [PATCH] tests: fix mocking of virFileGetXAttrQuiet on FreeBSD
by Daniel P. Berrangé 05 Jul '19

05 Jul '19

The qemusecuritytest is failing on FreeBSD 11/12, reporting that files are not correctly restored. Debugging code printfs show that the virFileGetXAttrQuiet mock is returning 0, but the virFileGetXAttr function is seeing -1 as the return value. Essentially there appears to be some kind of optimization between the real virFileGetXAttrQuiet and the real virFileGetXAttr, which breaks when we mock virFileGetXAttrQuiet. Rather than trying to figure out how to avoid this, it is simpler to just mock virFileGetXAttr too since it is very short code. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Pushed as a CI build fix tests/qemusecuritymock.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/tests/qemusecuritymock.c b/tests/qemusecuritymock.c index 2a9095e1bf..a15eef29c9 100644 --- a/tests/qemusecuritymock.c +++ b/tests/qemusecuritymock.c @@ -156,6 +156,34 @@ virFileGetXAttrQuiet(const char *path, } +/* + * This may look redundant but is needed to work around an + * compiler quirk. The call from the real virFileGetXAttr + * to the real virFileGetXAttrQuiet has a quirk where the + * return value from virFileGetXAttrQuiet gets scrambled + * if we mock virFileGetXAttrQuiet, returning -1 instead + * of 0 despite succeeding. This happens on FreeBSD 11/12 + * hosts with CLang, and is suspected to be some kind of + * compiler optimization. By mocking this function too we + * can workaround it. + */ +int +virFileGetXAttr(const char *path, + const char *name, + char **value) +{ + int ret; + + if ((ret = virFileGetXAttrQuiet(path, name, value)) < 0) { + virReportSystemError(errno, + "Unable to get XATTR %s on %s", + name, path); + } + + return ret; +} + + int virFileSetXAttr(const char *path, const char *name, const char *value) -- 2.21.0

1 0

Re: [libvirt] [libvirt-users] UDP broadcasts vs. nat Masquerading issue
by Nikolai Zhubr 05 Jul '19

05 Jul '19

Hi Daniel and Laine, [...] >> -A POSTROUTING -o br0 -j MASQUERADE >> -A POSTROUTING -o enp0s25 -j MASQUERADE >> -A POSTROUTING -o virbr2_nic -j MASQUERADE >> -A POSTROUTING -o vnet0 -j MASQUERADE > > *None* of those rules were added by libvirt (unless your build of [...] > You can verify my "counter-claim" by running "virsh net-destroy" for all > of your libvirt networks, and seeing that the offending rules haven't > been removed. > > In short, you need to look elsewhere for the culprit. Yes, found it. You were both right, essentially. The offending rules were added by a firewall in response to new interfaces created by libvirt dynamically, due to some dubious relict settings left in the firewall. (Silly me.) So this it not an issue of libvirt indeed! Tons of thanks for the quick and precise hit! Regards, Nikolai >> >> Here, virbr2_nic and vnet0 are used by libvirt for arranging network >> configurations for VMs, ok. However, br0 is a main interface of this >> host with primary ip address, with enp0s25 being a physical nic of >> this host, and it is used for all sorts of regular (unrelated to >> virtualization) communications. Also, br0 is used for attaching >> bridged (as opposed to NATed) VMs managed by libvirt. >> >> Clearly, libvirt somehow chooses to set up masquerading for literally >> all existing network interfaces here (except lo), > > It's clear that the rules are there. It's not clear that they were added > by libvirt. > >> but I can't see a real reason for the first two rules in the list >> above. Furthermore, they corrupt UDP broadcats coming from outside and >> reaching this host (through enp0s25/br0) such that source address gets >> replaced by this hosts primary address (as per masquerading). I've >> verified this by arranging a hand-crafted UDP listener and printing >> the respective source addresses as seen by normal userspace. >> >> Now I've discovered that I can "eliminate" the problem by either: >> >> 1. Removing "-A POSTROUTING -o br0 -j MASQUERADE" (manually) >> 2. Inserting "-A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.255/32 -j >> ACCEPT" >> (Of course correcting rules by hand is not a solution, just a test) >> >> So question is, how the correct rules should ideally look like? And, >> is this issue known/fixed in most current libvirt? > > Except for putting the libvirt-added rules in their own private chains > (appearing in libvirt 5.1.0, released on Feb 1, 2019), the iptables > rules added by libvirt to support its virtual networks didn't materially > change in > 10 years. Your email is the first time I've ever seen such > rules attributed to libvirt so, as I said above, I think you need to > take a deeper dive into your host system's config. > > > Good luck! >

2 1

[libvirt] [PATCH 0/3] remote: misc cleanups to client driver
by Daniel P. Berrangé 05 Jul '19

05 Jul '19

A few bits of cleanup identified during work on the daemon splitting patches sent now since they are independent. Daniel P. Berrangé (3): remote: stop declaring variables in the middle of a function remote: use autofree for many string variables remote: conditionally declare tty variable for non-Win32 platforms src/remote/remote_driver.c | 61 ++++++++++++++------------------------ 1 file changed, 23 insertions(+), 38 deletions(-) -- 2.21.0

2 4

[libvirt] [PATCH rust 0/5] ci related plus some small updates
by Sahid Orentino Ferdjaoui 05 Jul '19

05 Jul '19

Hello Daniel, When you have a moment, can you please merge this serie. It fixes CI issue, switch to bionic, and updates the tested versions. Results: https://travis-ci.org/sahid/libvirt-rust/builds/554170698 Thanks, s. Sahid Orentino Ferdjaoui (5): fix bug integration test with rust multithreading make lookup_by_id() test more robust update tested versions from 2.5.0 to 5.5.0 switch to the last ubuntu lts bionic fix code formating in README .travis.yml | 10 +++++----- README.md | 6 +++++- tests/domain.rs | 19 +++++++++---------- tests/integration_qemu.rs | 15 +++++++++++---- tests/libvirtd.sasl | 2 ++ 5 files changed, 32 insertions(+), 20 deletions(-) create mode 100644 tests/libvirtd.sasl -- 2.20.1

2 14

[libvirt] [PATCH v2 0/4] test_driver: implement some DomainGetParametersAPIs
by Ilias Stamatis 04 Jul '19

04 Jul '19

Changes since v1: - undefine the macro introduced in 1/4 when done with it's usage - simplified 4/4 by using the virNetDevBandwidthRate struct Ilias Stamatis (4): test_driver: introduce TEST_SET_PARAM macro test_driver: implement virDomainGetMemoryParameters test_driver: implement virDomainGetNumaParameters test_driver: implement testDomainGetInterfaceParameters src/test/test_driver.c | 154 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 154 insertions(+) -- 2.22.0

2 7

[libvirt] [PATCH] test_driver: avoid using nerrors unitialized in testDomainGetDiskErrors
by Ilias Stamatis 04 Jul '19

04 Jul '19

Right now nerrors can be used unitialized in the last for loop causing a bug. Signed-off-by: Ilias Stamatis <stamatis.iliass(a)gmail.com> --- src/test/test_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index ce4ff1a582..2371581f51 100644 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -3275,7 +3275,7 @@ static int testDomainGetDiskErrors(virDomainPtr dom, virDomainObjPtr vm = NULL; int ret = -1; size_t i; - size_t nerrors; + size_t nerrors = 0; virCheckFlags(0, -1); -- 2.22.0

2 1

[libvirt] [PATCH] test: ensure nerrors variable is initialized
by Daniel P. Berrangé 04 Jul '19

04 Jul '19

There is an error path that jumps over the initialization of nerrors, and the jump target reads the variable contents. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Pushed as a build fix src/test/test_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index ce4ff1a582..2371581f51 100644 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -3275,7 +3275,7 @@ static int testDomainGetDiskErrors(virDomainPtr dom, virDomainObjPtr vm = NULL; int ret = -1; size_t i; - size_t nerrors; + size_t nerrors = 0; virCheckFlags(0, -1); -- 2.21.0

1 0

[libvirt] [PATCH] test_driver: sanitize user-provided array in testDomainGetDiskErrors
by Ilias Stamatis 04 Jul '19

04 Jul '19

Zero out the user provided memory in order to avoid passing random pointers to VIR_FREE later. Signed-off-by: Ilias Stamatis <stamatis.iliass(a)gmail.com> --- src/test/test_driver.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index 7c58d2c8ce..8ee1f0cad6 100644 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -3275,6 +3275,7 @@ static int testDomainGetDiskErrors(virDomainPtr dom, virDomainObjPtr vm = NULL; int ret = -1; size_t i; + size_t nerrors; virCheckFlags(0, -1); @@ -3284,8 +3285,13 @@ static int testDomainGetDiskErrors(virDomainPtr dom, if (virDomainObjCheckActive(vm) < 0) goto cleanup; + nerrors = MIN(vm->def->ndisks, maxerrors); + if (errors) { - for (i = 0; i < MIN(vm->def->ndisks, maxerrors); i++) { + /* sanitize input */ + memset(errors, 0, sizeof(virDomainDiskError) * nerrors); + + for (i = 0; i < nerrors; i++) { if (VIR_STRDUP(errors[i].disk, vm->def->disks[i]->dst) < 0) goto cleanup; errors[i].error = (i % (VIR_DOMAIN_DISK_ERROR_LAST - 1)) + 1; @@ -3297,7 +3303,7 @@ static int testDomainGetDiskErrors(virDomainPtr dom, cleanup: if (ret < 0) { - for (i = 0; i < MIN(vm->def->ndisks, maxerrors); i++) + for (i = 0; i < nerrors; i++) VIR_FREE(errors[i].disk); } virDomainObjEndAPI(&vm); -- 2.22.0

3 2

[libvirt] [PATCH] test_driver: Implement virDomainSetPerfEvents
by Ilias Stamatis 04 Jul '19

04 Jul '19

Signed-off-by: Ilias Stamatis <stamatis.iliass(a)gmail.com> --- src/test/test_driver.c | 64 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index 7c58d2c8ce..9974eba882 100644 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -3372,6 +3372,69 @@ testDomainGetFSInfo(virDomainPtr dom, } +static int +testDomainSetPerfEvents(virDomainPtr dom, + virTypedParameterPtr params, + int nparams, + unsigned int flags) +{ + virDomainObjPtr vm = NULL; + virDomainDefPtr def = NULL; + size_t i; + int ret = -1; + + virCheckFlags(VIR_DOMAIN_AFFECT_LIVE | + VIR_DOMAIN_AFFECT_CONFIG, -1); + + if (virTypedParamsValidate(params, nparams, + VIR_PERF_PARAM_CMT, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_MBMT, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_MBML, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_CPU_CYCLES, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_INSTRUCTIONS, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_CACHE_REFERENCES, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_CACHE_MISSES, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_BRANCH_INSTRUCTIONS, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_BRANCH_MISSES, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_BUS_CYCLES, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_STALLED_CYCLES_FRONTEND, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_STALLED_CYCLES_BACKEND, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_REF_CPU_CYCLES, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_CPU_CLOCK, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_TASK_CLOCK, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_PAGE_FAULTS, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_CONTEXT_SWITCHES, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_CPU_MIGRATIONS, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_PAGE_FAULTS_MIN, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_PAGE_FAULTS_MAJ, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_ALIGNMENT_FAULTS, VIR_TYPED_PARAM_BOOLEAN, + VIR_PERF_PARAM_EMULATION_FAULTS, VIR_TYPED_PARAM_BOOLEAN, + NULL) < 0) + return -1; + + if (!(vm = testDomObjFromDomain(dom))) + return -1; + + if (!(def = virDomainObjGetOneDef(vm, flags))) + goto cleanup; + + for (i = 0; i < nparams; i++) { + virTypedParameterPtr param = &params[i]; + virPerfEventType type = virPerfEventTypeFromString(param->field); + + if (param->value.b) + def->perf.events[type] = VIR_TRISTATE_BOOL_YES; + else + def->perf.events[type] = VIR_TRISTATE_BOOL_NO; + } + + ret = 0; + cleanup: + virDomainObjEndAPI(&vm); + return ret; +} + + static int testDomainGetPerfEvents(virDomainPtr dom, virTypedParameterPtr *params, @@ -7410,6 +7473,7 @@ static virHypervisorDriver testHypervisorDriver = { .domainSetAutostart = testDomainSetAutostart, /* 0.3.2 */ .domainGetDiskErrors = testDomainGetDiskErrors, /* 5.4.0 */ .domainGetFSInfo = testDomainGetFSInfo, /* 5.6.0 */ + .domainSetPerfEvents = testDomainSetPerfEvents, /* 5.6.0 */ .domainGetPerfEvents = testDomainGetPerfEvents, /* 5.6.0 */ .domainGetSchedulerType = testDomainGetSchedulerType, /* 0.3.2 */ .domainGetSchedulerParameters = testDomainGetSchedulerParameters, /* 0.3.2 */ -- 2.22.0

2 1

[libvirt] [PULL 0/4] Python queue, 2019-07-01
by Eduardo Habkost 04 Jul '19

04 Jul '19

The following changes since commit 7d0e02405fc02a181319b1ab8681d2f72246b7c6: Merge remote-tracking branch 'remotes/vivier2/tags/trivial-patches-pull-request' into staging (2019-07-01 17:40:32 +0100) are available in the Git repository at: git://github.com/ehabkost/qemu.git tags/python-next-pull-request for you to fetch changes up to e5abf59eae5990296c243202f95f801495c52e76: Deprecate Python 2 support (2019-07-01 19:02:10 -0300) ---------------------------------------------------------------- Python queue, 2019-07-01 * Deprecate Python 2 support (Eduardo Habkost) * qemu/__init__.py refactor (John Snow) * make qmp-shell work with python3 (Igor Mammedov) ---------------------------------------------------------------- Eduardo Habkost (1): Deprecate Python 2 support Igor Mammedov (1): qmp: make qmp-shell work with python3 John Snow (2): python/qemu: split QEMUMachine out from underneath __init__.py machine.py: minor delinting configure | 8 + scripts/render_block_graph.py | 2 +- python/qemu/__init__.py | 502 +------------------- python/qemu/machine.py | 531 ++++++++++++++++++++++ python/qemu/qtest.py | 2 +- qemu-deprecated.texi | 8 + scripts/device-crash-test | 2 +- scripts/qmp/qmp-shell | 5 +- tests/acceptance/avocado_qemu/__init__.py | 2 +- tests/acceptance/virtio_version.py | 2 +- tests/migration/guestperf/engine.py | 24 +- tests/qemu-iotests/235 | 2 +- tests/vm/basevm.py | 3 +- 13 files changed, 572 insertions(+), 521 deletions(-) create mode 100644 python/qemu/machine.py -- 2.18.0.rc1.1.g3f1ff2140

2 5

[libvirt] [RFC] test_driver: Thoughts on the implementation of some FS-related APIs
by Ilias Stamatis 04 Jul '19

04 Jul '19

Hello, I was thinking about how to implement the following APIs in the test driver: -virDomainFSFreeze -virDomainFSThaw -virDomainFSTrim The first two are conceptually paired. They both get a mountpoints argument. The QEMU driver (which is the only driver implementing this currently) ignores this completely. However, I thought that we can allow it and pretend that the only available mountpoints are "/" and "/boot" (like in a default Fedora installation). The following questions arise though: - Should we keep some kind of temporary or permanent state on the test driver about this? Because it makes sense for virDomainFSThaw to succeed only on mountpoints for which previously virDomainFSFreeze has been called. If so, *where* exactly should we keep this state? - In case a non-existing mountpoint is passed to either of the first 2 APIs. Should we fail? If so, a new error code should be introduced for this. Also for the cases above where e.g. Thaw is called on a fs that isn't frozen probably yet another different error code must be used. Should we add all these new error codes? Or maybe all the above is more complicated than necessary and it's fine if we ignore mountpoints completely like the QEMU driver does and make all 3 APIs above to always succeed no matter what in the test driver? Thanks, Ilias

2 3

[libvirt] [PATCH] remote: mention libssh in error message
by Pino Toscano 04 Jul '19

04 Jul '19

Mention libssh as possible transport in the error message of an unrecognized transport. https://bugzilla.redhat.com/show_bug.cgi?id=1727013 Signed-off-by: Pino Toscano <ptoscano(a)redhat.com> --- src/remote/remote_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index df58b23c8c..97d9d5fa88 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -825,7 +825,7 @@ doRemoteOpen(virConnectPtr conn, } else { virReportError(VIR_ERR_INVALID_ARG, "%s", _("remote_open: transport in URL not recognised " - "(should be tls|unix|ssh|ext|tcp|libssh2)")); + "(should be tls|unix|ssh|ext|tcp|libssh2|libssh)")); return VIR_DRV_OPEN_ERROR; } } -- 2.21.0

2 1

[libvirt] [PATCH] Revert "lxc: Try harder to stop/reboot containers"
by Daniel P. Berrangé 04 Jul '19

04 Jul '19

This reverts commit 14b6a1854fb4c02c5fb2f51679f8ff099f28f53c. If virLXCDomainSetRunlevel returns -1 this indicates a serious error / failure that must be propagated to the caller. We must not carry on with other shutdown methods in this case. If virLXCDomainSetRunlevel return 0, this indicates that no initctl was found and it is thus reasonable to fallback to sending SIGTERM. The commit being reverted is broken because it would fallback to SIGTERM when virLXCDomainSetRunlevel returns -1, and would not fallback when virLXCDomainSetRunlevel returns 0. ie it did the exact opposite of what was required. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/lxc/lxc_driver.c | 40 ++++++++++++++++++++++------------------ 1 file changed, 22 insertions(+), 18 deletions(-) diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c index 9db2a02dee..01af5f6db8 100644 --- a/src/lxc/lxc_driver.c +++ b/src/lxc/lxc_driver.c @@ -3262,7 +3262,7 @@ lxcDomainShutdownFlags(virDomainPtr dom, virLXCDomainObjPrivatePtr priv; virDomainObjPtr vm; int ret = -1; - int rc = -1; + int rc; virCheckFlags(VIR_DOMAIN_SHUTDOWN_INITCTL | VIR_DOMAIN_SHUTDOWN_SIGNAL, -1); @@ -3291,17 +3291,19 @@ lxcDomainShutdownFlags(virDomainPtr dom, (flags & VIR_DOMAIN_SHUTDOWN_INITCTL)) { int command = VIR_INITCTL_RUNLEVEL_POWEROFF; - if ((rc = virLXCDomainSetRunlevel(vm, command)) < 0) { - if (flags != 0 && - (flags & VIR_DOMAIN_SHUTDOWN_INITCTL)) { - virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", - _("Container does not provide an initctl pipe")); - goto endjob; - } + if ((rc = virLXCDomainSetRunlevel(vm, command)) < 0) + goto endjob; + if (rc == 0 && flags != 0 && + ((flags & ~VIR_DOMAIN_SHUTDOWN_INITCTL) == 0)) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("Container does not provide an initctl pipe")); + goto endjob; } + } else { + rc = 0; } - if (rc < 0 && + if (rc == 0 && (flags == 0 || (flags & VIR_DOMAIN_SHUTDOWN_SIGNAL))) { if (kill(priv->initpid, SIGTERM) < 0 && @@ -3338,7 +3340,7 @@ lxcDomainReboot(virDomainPtr dom, virLXCDomainObjPrivatePtr priv; virDomainObjPtr vm; int ret = -1; - int rc = -1; + int rc; virCheckFlags(VIR_DOMAIN_REBOOT_INITCTL | VIR_DOMAIN_REBOOT_SIGNAL, -1); @@ -3367,17 +3369,19 @@ lxcDomainReboot(virDomainPtr dom, (flags & VIR_DOMAIN_REBOOT_INITCTL)) { int command = VIR_INITCTL_RUNLEVEL_REBOOT; - if ((rc = virLXCDomainSetRunlevel(vm, command)) < 0) { - if (flags != 0 && - (flags & VIR_DOMAIN_REBOOT_INITCTL)) { - virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", - _("Container does not provide an initctl pipe")); - goto endjob; - } + if ((rc = virLXCDomainSetRunlevel(vm, command)) < 0) + goto endjob; + if (rc == 0 && flags != 0 && + ((flags & ~VIR_DOMAIN_SHUTDOWN_INITCTL) == 0)) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("Container does not provide an initctl pipe")); + goto endjob; } + } else { + rc = 0; } - if (rc < 0 && + if (rc == 0 && (flags == 0 || (flags & VIR_DOMAIN_REBOOT_SIGNAL))) { if (kill(priv->initpid, SIGHUP) < 0 && -- 2.21.0

1 0

[libvirt] [PATCH] lxc: Fix reboot via initctl
by Lubomir Rintel 04 Jul '19

04 Jul '19

virInitctlSetRunLevel() returns 0 only if ended up doing nothing, 1 if it actually succeeded. Let's check for the error condition. Without this, a successful reboot would be treated as a failure and the LXC driver will proceed sending a TERM signal instead, effectively cancelling the shutdown. Signed-off-by: Lubomir Rintel <lkundrak(a)v3.sk> --- src/lxc/lxc_domain.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/lxc/lxc_domain.c b/src/lxc/lxc_domain.c index 51a9fd36eb..1dc2d0d4cf 100644 --- a/src/lxc/lxc_domain.c +++ b/src/lxc/lxc_domain.c @@ -457,7 +457,9 @@ lxcDomainInitctlCallback(pid_t pid ATTRIBUTE_UNUSED, data->st[i].st_ino == cont_sb.st_ino) continue; - return virInitctlSetRunLevel(fifo, data->runlevel); + if (virInitctlSetRunLevel(fifo, data->runlevel) == -1) + return -1; + return 0; } /* If no usable fifo was found then declare success. Caller -- 2.21.0

2 1

[libvirt] UDP broadcasts vs. nat Masquerading issue
by Nikolai Zhubr 04 Jul '19

04 Jul '19

Hi all, I'm observing an issue that as soon as libvirt starts, UPD broadcasts flowing through physical network (and intended for other services, unrelated to any virtualization) get broken. Specifically, windows neighbourhood browsing through samba's nmbd starts suffering badly (Samba is running on this same box). At the moment I'm running a quite outdated version 1.2.9 of libvirt, but because other than this issue it does its job pretty well I'd first consider some patching/backporting rather than totally replacing it with a new one. Anyway, I first need to better understand what is going on and what is wrong with it. This could also be related somewhat to https://www.redhat.com/archives/libvir-list/2013-September/msg01311.html but I suppose it is not exactly that thing, and besides, my version does already include a fix for the broadcasts issue mentioned in the msg01311. I've already figured the source of trouble is anyway related to these rules added: -A POSTROUTING -o br0 -j MASQUERADE -A POSTROUTING -o enp0s25 -j MASQUERADE -A POSTROUTING -o virbr2_nic -j MASQUERADE -A POSTROUTING -o vnet0 -j MASQUERADE Here, virbr2_nic and vnet0 are used by libvirt for arranging NAT-mode network configurations for VMs, unrelated to normal network stuff, so it looks ok. However, br0 (with enp0s25 in it) is a main interface of this host with primary ip address. And enp0s25 is a physical nic of this host, and it is used for all sorts of regular (unrelated to virtualization) communications as well. Also, br0 is used for attaching some bridge-mode (as opposed to NAT-mode) VMs managed by libvirt, but bridge mode is not supposed to employ address translation anyway. So, clearly, libvirt somehow chooses to set up masquerading for literally all existing network interfaces here (except lo), but I can't see a reason for the first two rules in the list above. Furthermore, they corrupt UDP broadcats coming from outside and reaching this host (through enp0s25/br0) such that source address gets replaced by this hosts primary address (as per masquerading). I've verified this by arranging a hand-crafted UDP listener and printing the respective source addresses as seen by normal userspace. Obviously Samba server can not work correctly under such conditions. Now I've discovered that I can "eliminate" the problem by e.g.: 1. Removing "-A POSTROUTING -o br0 -j MASQUERADE" (manual brute force) 2. Inserting "-A POSTROUTING -s 192.168.0.0/24 -d 192.168.0.255/32 -j ACCEPT" (Of course correcting rules by hand is not a solution, just a test) So question is, how the correct rules should ideally look like? And, is this issue known/fixed in most current libvirt? Thank you, Regards, Nikolai

2 1

[libvirt] [PATCH] remote: remove the only use of LIBVIRTD_CONFIGURATION_FILE
by Fabiano Fidêncio 04 Jul '19

04 Jul '19

86fbce56f27e removed the constant, but didn't actually adjust the only place where the constant was used. Signed-off-by: Fabiano Fidêncio <fidencio(a)redhat.com> --- This patch fixes a build breakage. It's either this, or reverting 86fbce56f27e. --- src/remote/remote_daemon.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/src/remote/remote_daemon.c b/src/remote/remote_daemon.c index fdc9e4333a..3cd7b16163 100644 --- a/src/remote/remote_daemon.c +++ b/src/remote/remote_daemon.c @@ -899,9 +899,6 @@ daemonUsage(const char *argv0, bool privileged) _("\n" " Default paths:\n" "\n" - " Configuration file (unless overridden by -f):\n" - " %s\n" - "\n" " Sockets:\n" " %s\n" " %s\n" @@ -914,7 +911,6 @@ daemonUsage(const char *argv0, bool privileged) " PID file (unless overridden by -p):\n" " %s/run/libvirtd.pid\n" "\n"), - LIBVIRTD_CONFIGURATION_FILE, LIBVIRTD_PRIV_UNIX_SOCKET, LIBVIRTD_PRIV_UNIX_SOCKET_RO, LIBVIRT_CACERT, -- 2.21.0

5 5

[libvirt] [PATCH] Revert "remote: remove unused constant for libvirtd config file"
by Peter Krempa 04 Jul '19

04 Jul '19

The constant is not unused and breaks the build of the remote driver. This reverts commit 86fbce56f27e06b34d63879c9f634a58a1e0a04a. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- Pushed under the build-breaker rule. src/remote/remote_driver.h | 1 + 1 file changed, 1 insertion(+) diff --git a/src/remote/remote_driver.h b/src/remote/remote_driver.h index 132e478ef3..8c7da6b000 100644 --- a/src/remote/remote_driver.h +++ b/src/remote/remote_driver.h @@ -34,6 +34,7 @@ unsigned long remoteVersion(void); #define LIBVIRTD_PRIV_UNIX_SOCKET LOCALSTATEDIR "/run/libvirt/libvirt-sock" #define LIBVIRTD_PRIV_UNIX_SOCKET_RO LOCALSTATEDIR "/run/libvirt/libvirt-sock-ro" #define LIBVIRTD_USER_UNIX_SOCKET "libvirt-sock" +#define LIBVIRTD_CONFIGURATION_FILE SYSCONFDIR "/libvirt/libvirtd.conf" /* Defaults for PKI directory. */ #define LIBVIRT_PKI_DIR SYSCONFDIR "/pki" -- 2.21.0

2 1

[libvirt] [PATCH python 0/2] spec: fedora tweaks
by Cole Robinson 04 Jul '19

04 Jul '19

Some fedora version tweaks Cole Robinson (2): spec: Unconditionally build python2 on Fedora spec: Bump minimum supported Fedora version to 29 libvirt-python.spec.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 2.21.0

2 3

[libvirt] [PATCH] remote: remove unused constant for libvirtd config file
by Daniel P. Berrangé 04 Jul '19

04 Jul '19

The LIBVIRTD_CONFIGURATION_FILE constant was introduced in commit b7c42619e69acd8416be88b8aa3b4161bc813f8a Author: Richard W.M. Jones <rjones(a)redhat.com> Date: Mon Jun 11 11:43:41 2007 +0000 Mon Jun 11 12:41:00 BST 2007 Richard W.M. Jones <rjones(a)redhat.com> and then never used ! Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Pushed under the trivial rule src/remote/remote_driver.h | 1 - 1 file changed, 1 deletion(-) diff --git a/src/remote/remote_driver.h b/src/remote/remote_driver.h index 8c7da6b000..132e478ef3 100644 --- a/src/remote/remote_driver.h +++ b/src/remote/remote_driver.h @@ -34,7 +34,6 @@ unsigned long remoteVersion(void); #define LIBVIRTD_PRIV_UNIX_SOCKET LOCALSTATEDIR "/run/libvirt/libvirt-sock" #define LIBVIRTD_PRIV_UNIX_SOCKET_RO LOCALSTATEDIR "/run/libvirt/libvirt-sock-ro" #define LIBVIRTD_USER_UNIX_SOCKET "libvirt-sock" -#define LIBVIRTD_CONFIGURATION_FILE SYSCONFDIR "/libvirt/libvirtd.conf" /* Defaults for PKI directory. */ #define LIBVIRT_PKI_DIR SYSCONFDIR "/pki" -- 2.21.0

3 2

[libvirt] ANNOUNCE: virt-manager 2.2.1 released
by Cole Robinson 04 Jul '19

04 Jul '19

I'm happy to announce the release of virt-manager 2.2.1! virt-manager is a desktop application for managing KVM, Xen, and LXC virtualization via libvirt. The release can be downloaded from: http://virt-manager.org/download/ This release includes: - CVE-2019-10183: Replace --unattended user-password and admin-password with user-password-file and admin-password-file (Fabiano Fidêncio) - Consistent --memballoon default across non-x86 (Andrea Bolognani) - virt-install: add --numatune memnode.* (Athina Plaskasoviti) - Drop hard dep on gtksourceview4, gtksourceview3 is fine as well Thanks to everyone who has contributed to this release through testing, bug reporting, submitting patches, and otherwise sending in feedback! Thanks, Cole

1 0

[libvirt] [PATCH] mingw: distribute schemas/networkport.rng
by Cole Robinson 03 Jul '19

03 Jul '19

Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- Pushed as a build breaker. Anyone know why we list these explicitly rather than use a wildcard? libvirt.spec.in is the same mingw-libvirt.spec.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in index 280db4d1aa..ad6d6e952e 100644 --- a/mingw-libvirt.spec.in +++ b/mingw-libvirt.spec.in @@ -237,6 +237,7 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh %{mingw32_datadir}/libvirt/schemas/interface.rng %{mingw32_datadir}/libvirt/schemas/network.rng %{mingw32_datadir}/libvirt/schemas/networkcommon.rng +%{mingw32_datadir}/libvirt/schemas/networkport.rng %{mingw32_datadir}/libvirt/schemas/nodedev.rng %{mingw32_datadir}/libvirt/schemas/nwfilter.rng %{mingw32_datadir}/libvirt/schemas/nwfilter_params.rng @@ -325,6 +326,7 @@ rm -rf $RPM_BUILD_ROOT%{mingw64_libexecdir}/libvirt-guests.sh %{mingw64_datadir}/libvirt/schemas/interface.rng %{mingw64_datadir}/libvirt/schemas/network.rng %{mingw64_datadir}/libvirt/schemas/networkcommon.rng +%{mingw64_datadir}/libvirt/schemas/networkport.rng %{mingw64_datadir}/libvirt/schemas/nodedev.rng %{mingw64_datadir}/libvirt/schemas/nwfilter.rng %{mingw64_datadir}/libvirt/schemas/nwfilter_params.rng -- 2.21.0

2 1

[libvirt] [PATCH] Do not keep empty log files for deleted domains
by Jan Zerebecki 03 Jul '19

03 Jul '19

With logrotates copytruncate when e.g. domain1 doesn't exist anymore /var/log/libvirt/qemu/domain1.log will still exist after rotation even though it will never be written to. When new domain names keep getting used this leads to a lot of empty logfiles. This may lead to slowdown or lack of free disk space / inodes. Fix this by replacing copytruncate with the apropriate postrotate command to reopen log files. Thus after the apropriate time log files for deleted domains will be gone. This also has the advantage that the chance for loss of a few lines during copytruncate is gone. Signed-off-by: Jan Zerebecki <jan.suse(a)zerebecki.de> --- src/remote/libvirtd.libxl.logrotate.in | 4 +++- src/remote/libvirtd.logrotate.in | 4 +++- src/remote/libvirtd.lxc.logrotate.in | 4 +++- src/remote/libvirtd.qemu.logrotate.in | 4 +++- 4 files changed, 12 insertions(+), 4 deletions(-) diff --git a/src/remote/libvirtd.libxl.logrotate.in b/src/remote/libvirtd.libxl.logrotate.in index cb7f07d846..d4f25f8cab 100644 --- a/src/remote/libvirtd.libxl.logrotate.in +++ b/src/remote/libvirtd.libxl.logrotate.in @@ -4,5 +4,7 @@ rotate 4 compress delaycompress - copytruncate + postrotate + /usr/bin/killall -USR1 virtlogd + endscript } diff --git a/src/remote/libvirtd.logrotate.in b/src/remote/libvirtd.logrotate.in index 4e02510c8b..73dab7579f 100644 --- a/src/remote/libvirtd.logrotate.in +++ b/src/remote/libvirtd.logrotate.in @@ -4,6 +4,8 @@ rotate 4 compress delaycompress - copytruncate minsize 100k + postrotate + /usr/bin/killall -USR1 virtlogd + endscript } diff --git a/src/remote/libvirtd.lxc.logrotate.in b/src/remote/libvirtd.lxc.logrotate.in index 2bb9dfba12..eed47bb55f 100644 --- a/src/remote/libvirtd.lxc.logrotate.in +++ b/src/remote/libvirtd.lxc.logrotate.in @@ -4,5 +4,7 @@ rotate 4 compress delaycompress - copytruncate + postrotate + /usr/bin/killall -USR1 virtlogd + endscript } diff --git a/src/remote/libvirtd.qemu.logrotate.in b/src/remote/libvirtd.qemu.logrotate.in index cdb399ef23..95407cec1a 100644 --- a/src/remote/libvirtd.qemu.logrotate.in +++ b/src/remote/libvirtd.qemu.logrotate.in @@ -4,5 +4,7 @@ rotate 4 compress delaycompress - copytruncate + postrotate + /usr/bin/killall -USR1 virtlogd + endscript } -- 2.20.1

4 7

[libvirt] [PATCH] remote: remove obsolete rule for generating sysvinit script
by Daniel P. Berrangé 03 Jul '19

03 Jul '19

The sysvinit script was previously removed in commit 912fe2df9d8628b2f3d54485f1cb919cb124d07a Author: Andrea Bolognani <abologna(a)redhat.com> Date: Fri Mar 15 16:47:27 2019 +0100 Drop support for "Red Hat" init scripts A make rule was accidentally left behind. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/remote/Makefile.inc.am | 9 --------- 1 file changed, 9 deletions(-) diff --git a/src/remote/Makefile.inc.am b/src/remote/Makefile.inc.am index 013cd3e382..43ad53bedb 100644 --- a/src/remote/Makefile.inc.am +++ b/src/remote/Makefile.inc.am @@ -296,15 +296,6 @@ INSTALL_DATA_LOCAL += install-sasl UNINSTALL_LOCAL += uninstall-sasl endif WITH_SASL -libvirtd.init: remote/libvirtd.init.in $(top_builddir)/config.status - $(AM_V_GEN)sed \ - -e 's|[@]localstatedir[@]|$(localstatedir)|g' \ - -e 's|[@]sbindir[@]|$(sbindir)|g' \ - -e 's|[@]sysconfdir[@]|$(sysconfdir)|g' \ - < $< > $@-t && \ - chmod a+x $@-t && \ - mv $@-t $@ - libvirtd.service: remote/libvirtd.service.in $(top_builddir)/config.status $(AM_V_GEN)sed \ -e 's|[@]localstatedir[@]|$(localstatedir)|g' \ -- 2.21.0

2 2

[libvirt] [PATCH] remote: remove obsolete params from sysconf file
by Daniel P. Berrangé 03 Jul '19

03 Jul '19

The LIBVIRTD_CONFIG and LIBVIRTD_NOFILES_LIMIT parameters were only honoured when using the sysvinit scripts. This was removed already in commit 912fe2df9d8628b2f3d54485f1cb919cb124d07a Author: Andrea Bolognani <abologna(a)redhat.com> Date: Fri Mar 15 16:47:27 2019 +0100 Drop support for "Red Hat" init scripts so the parameters can safely be dropped. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/remote/libvirtd.sysconf | 18 +----------------- 1 file changed, 1 insertion(+), 17 deletions(-) diff --git a/src/remote/libvirtd.sysconf b/src/remote/libvirtd.sysconf index f15e5956eb..60a47c252f 100644 --- a/src/remote/libvirtd.sysconf +++ b/src/remote/libvirtd.sysconf @@ -1,8 +1,4 @@ -# Override the default config file -# NOTE: This setting is no longer honoured if using -# systemd. Set '--config /etc/libvirt/libvirtd.conf' -# in LIBVIRTD_ARGS instead. -#LIBVIRTD_CONFIG=/etc/libvirt/libvirtd.conf +# Customizations for the libvirtd.service systemd unit # Listen for TCP/IP connections # NB. must setup TLS/SSL keys prior to using this @@ -19,15 +15,3 @@ #QEMU_AUDIO_DRV=sdl # #SDL_AUDIODRIVER=pulse - -# Override the maximum number of opened files. -# This only works with traditional init scripts. -# In the systemd world, the limit can only be changed by overriding -# LimitNOFILE for libvirtd.service. To do that, just create a *.conf -# file in /etc/systemd/system/libvirtd.service.d/ (for example -# /etc/systemd/system/libvirtd.service.d/openfiles.conf) and write -# the following two lines in it: -# [Service] -# LimitNOFILE=2048 -# -#LIBVIRTD_NOFILES_LIMIT=2048 -- 2.21.0

2 3

[libvirt] [PATCH v2 0/4] tests: Add and use more DO_TEST_CAPS_*() macros
by Andrea Bolognani 03 Jul '19

03 Jul '19

Changes from [v1]: * split 1/2 into three separate patches for easier review. [v1] https://www.redhat.com/archives/libvir-list/2019-July/msg00069.html Andrea Bolognani (4): tests: Reorder DO_TEST_CAPS_*() macros tests: Add DO_TEST_CAPS_ARCH_VER_FULL() tests: Add more DO_TEST_CAPS_*() macros tests: Use the new DO_TEST_CAPS_*() macros tests/qemuxml2argvtest.c | 76 ++++++++++++++++++++-------------------- tests/qemuxml2xmltest.c | 32 +++++++++-------- 2 files changed, 55 insertions(+), 53 deletions(-) -- 2.21.0

2 7

[libvirt] [PATCH] qemu: De-duplicate some path definitions
by Michal Privoznik 03 Jul '19

03 Jul '19

There are some paths (e.g. /dev/vfio/vfio or /dev/mapper/control) which are defined in qemu_domain.c and then in qemu_cgroup.c again. This is suboptimal. Lets move paths into qemu_domain.h and drop duplicate definitions. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_cgroup.c | 13 ++++++------- src/qemu/qemu_domain.c | 30 +++++++++++------------------- src/qemu/qemu_domain.h | 7 +++++++ src/qemu/qemu_hostdev.c | 5 +++-- 4 files changed, 27 insertions(+), 28 deletions(-) diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c index ca76c4fdfa..19ca60905a 100644 --- a/src/qemu/qemu_cgroup.c +++ b/src/qemu/qemu_cgroup.c @@ -113,8 +113,6 @@ qemuSetupImagePathCgroup(virDomainObjPtr vm, } -#define DEVICE_MAPPER_CONTROL_PATH "/dev/mapper/control" - static int qemuSetupImageCgroupInternal(virDomainObjPtr vm, virStorageSourcePtr src, @@ -127,8 +125,8 @@ qemuSetupImageCgroupInternal(virDomainObjPtr vm, } if (virStoragePRDefIsManaged(src->pr) && - virFileExists(DEVICE_MAPPER_CONTROL_PATH) && - qemuSetupImagePathCgroup(vm, DEVICE_MAPPER_CONTROL_PATH, false) < 0) + virFileExists(QEMU_DEVICE_MAPPER_CONTROL_PATH) && + qemuSetupImagePathCgroup(vm, QEMU_DEVICE_MAPPER_CONTROL_PATH, false) < 0) return -1; return qemuSetupImagePathCgroup(vm, src->path, src->readonly || forceReadonly); @@ -162,7 +160,7 @@ qemuTeardownImageCgroup(virDomainObjPtr vm, return 0; } - if (virFileExists(DEVICE_MAPPER_CONTROL_PATH)) { + if (virFileExists(QEMU_DEVICE_MAPPER_CONTROL_PATH)) { for (i = 0; i < vm->def->ndisks; i++) { virStorageSourcePtr diskSrc = vm->def->disks[i]->src; @@ -176,9 +174,10 @@ qemuTeardownImageCgroup(virDomainObjPtr vm, if (i == vm->def->ndisks) { VIR_DEBUG("Disabling device mapper control"); ret = virCgroupDenyDevicePath(priv->cgroup, - DEVICE_MAPPER_CONTROL_PATH, perms, true); + QEMU_DEVICE_MAPPER_CONTROL_PATH, + perms, true); virDomainAuditCgroupPath(vm, priv->cgroup, "deny", - DEVICE_MAPPER_CONTROL_PATH, + QEMU_DEVICE_MAPPER_CONTROL_PATH, virCgroupGetDevicePermsString(perms), ret); if (ret < 0) return ret; diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 0f1335de9c..7e6a9764c5 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -117,14 +117,6 @@ VIR_ENUM_IMPL(qemuDomainNamespace, "mount", ); - -#define PROC_MOUNTS "/proc/mounts" -#define DEVPREFIX "/dev/" -#define DEV_VFIO "/dev/vfio/vfio" -#define DEVICE_MAPPER_CONTROL_PATH "/dev/mapper/control" -#define DEV_SEV "/dev/sev" - - struct _qemuDomainLogContext { virObject parent; @@ -11872,7 +11864,7 @@ qemuDomainGetHostdevPath(virDomainDefPtr def, tmpPerms[0] = perm; if (includeVFIO) { - if (VIR_STRDUP(tmpPaths[1], DEV_VFIO) < 0) + if (VIR_STRDUP(tmpPaths[1], QEMU_DEV_VFIO) < 0) goto cleanup; tmpPerms[1] = VIR_CGROUP_DEVICE_RW; } @@ -11919,7 +11911,7 @@ qemuDomainGetPreservedMountPath(virQEMUDriverConfigPtr cfg, { char *path = NULL; char *tmp; - const char *suffix = mountpoint + strlen(DEVPREFIX); + const char *suffix = mountpoint + strlen(QEMU_DEVPREFIX); char *domname = virDomainDefGetShortName(vm->def); size_t off; @@ -11974,7 +11966,7 @@ qemuDomainGetPreservedMounts(virQEMUDriverConfigPtr cfg, char **paths = NULL, **mounts = NULL; size_t i, j, nmounts; - if (virFileGetMountSubtree(PROC_MOUNTS, "/dev", + if (virFileGetMountSubtree(QEMU_PROC_MOUNTS, "/dev", &mounts, &nmounts) < 0) goto error; @@ -12099,7 +12091,7 @@ qemuDomainCreateDeviceRecursive(const char *device, * Otherwise we might get fooled with `/dev/../var/my_image'. * For now, lets hope callers play nice. */ - if (STRPREFIX(device, DEVPREFIX)) { + if (STRPREFIX(device, QEMU_DEVPREFIX)) { size_t i; for (i = 0; i < data->ndevMountsPath; i++) { @@ -12113,7 +12105,7 @@ qemuDomainCreateDeviceRecursive(const char *device, /* Okay, @device is in /dev but not in any mount point under /dev. * Create it. */ if (virAsprintf(&devicePath, "%s/%s", - data->path, device + strlen(DEVPREFIX)) < 0) + data->path, device + strlen(QEMU_DEVPREFIX)) < 0) goto cleanup; if (virFileMakeParentPath(devicePath) < 0) { @@ -12375,7 +12367,7 @@ qemuDomainSetupDisk(virQEMUDriverConfigPtr cfg ATTRIBUTE_UNUSED, /* qemu-pr-helper might require access to /dev/mapper/control. */ if (disk->src->pr && - qemuDomainCreateDevice(DEVICE_MAPPER_CONTROL_PATH, data, true) < 0) + qemuDomainCreateDevice(QEMU_DEVICE_MAPPER_CONTROL_PATH, data, true) < 0) goto cleanup; ret = 0; @@ -12707,7 +12699,7 @@ qemuDomainSetupLaunchSecurity(virQEMUDriverConfigPtr cfg ATTRIBUTE_UNUSED, VIR_DEBUG("Setting up launch security"); - if (qemuDomainCreateDevice(DEV_SEV, data, false) < 0) + if (qemuDomainCreateDevice(QEMU_DEV_SEV, data, false) < 0) return -1; VIR_DEBUG("Set up launch security"); @@ -13122,7 +13114,7 @@ qemuDomainAttachDeviceMknodRecursive(virQEMUDriverPtr driver, isReg = S_ISREG(data.sb.st_mode) || S_ISFIFO(data.sb.st_mode) || S_ISSOCK(data.sb.st_mode); isDir = S_ISDIR(data.sb.st_mode); - if ((isReg || isDir) && STRPREFIX(file, DEVPREFIX)) { + if ((isReg || isDir) && STRPREFIX(file, QEMU_DEVPREFIX)) { cfg = virQEMUDriverGetConfig(driver); if (!(target = qemuDomainGetPreservedMountPath(cfg, vm, file))) goto cleanup; @@ -13178,7 +13170,7 @@ qemuDomainAttachDeviceMknodRecursive(virQEMUDriverPtr driver, } # endif - if (STRPREFIX(file, DEVPREFIX)) { + if (STRPREFIX(file, QEMU_DEVPREFIX)) { size_t i; for (i = 0; i < ndevMountsPath; i++) { @@ -13287,7 +13279,7 @@ qemuDomainDetachDeviceUnlink(virQEMUDriverPtr driver ATTRIBUTE_UNUSED, int ret = -1; size_t i; - if (STRPREFIX(file, DEVPREFIX)) { + if (STRPREFIX(file, QEMU_DEVPREFIX)) { for (i = 0; i < ndevMountsPath; i++) { if (STREQ(devMountsPath[i], "/dev")) continue; @@ -13429,7 +13421,7 @@ qemuDomainNamespaceSetupDisk(virDomainObjPtr vm, /* qemu-pr-helper might require access to /dev/mapper/control. */ if (src->pr && - (VIR_STRDUP(dmPath, DEVICE_MAPPER_CONTROL_PATH) < 0 || + (VIR_STRDUP(dmPath, QEMU_DEVICE_MAPPER_CONTROL_PATH) < 0 || VIR_APPEND_ELEMENT_COPY(paths, npaths, dmPath) < 0)) goto cleanup; diff --git a/src/qemu/qemu_domain.h b/src/qemu/qemu_domain.h index 5cb4a32c0e..3eea8b0f96 100644 --- a/src/qemu/qemu_domain.h +++ b/src/qemu/qemu_domain.h @@ -223,6 +223,13 @@ struct _qemuDomainUnpluggingDevice { }; +#define QEMU_PROC_MOUNTS "/proc/mounts" +#define QEMU_DEVPREFIX "/dev/" +#define QEMU_DEV_VFIO "/dev/vfio/vfio" +#define QEMU_DEV_SEV "/dev/sev" +#define QEMU_DEVICE_MAPPER_CONTROL_PATH "/dev/mapper/control" + + typedef enum { QEMU_DOMAIN_NS_MOUNT = 0, QEMU_DOMAIN_NS_LAST diff --git a/src/qemu/qemu_hostdev.c b/src/qemu/qemu_hostdev.c index cc0a4574cd..efa4d62f1f 100644 --- a/src/qemu/qemu_hostdev.c +++ b/src/qemu/qemu_hostdev.c @@ -25,6 +25,7 @@ #include <sys/ioctl.h> #include "qemu_hostdev.h" +#include "qemu_domain.h" #include "virlog.h" #include "virerror.h" #include "viralloc.h" @@ -140,7 +141,7 @@ qemuHostdevHostSupportsPassthroughVFIO(void) return false; /* condition 2 - /dev/vfio/vfio exists */ - if (!virFileExists("/dev/vfio/vfio")) + if (!virFileExists(QEMU_DEV_VFIO)) return false; return true; @@ -343,7 +344,7 @@ qemuHostdevPrepareMediatedDevices(virQEMUDriverPtr driver, /* Checking for VFIO only is fine with mdev, as IOMMU isolation is achieved * by the physical parent device. */ - supportsVFIO = virFileExists("/dev/vfio/vfio"); + supportsVFIO = virFileExists(QEMU_DEV_VFIO); for (i = 0; i < nhostdevs; i++) { if (virHostdevIsMdevDevice(hostdevs[i])) { -- 2.21.0

3 2

[libvirt] [PATCH v3] docs: Provide documentation for SEV launch security
by Erik Skultety 03 Jul '19

03 Jul '19

Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- Since v2: - incorporated Brijesh's notes into the SEV description and fixed the info about SME docs/launch_security_sev.html.in | 521 +++++++++++++++++++++++++++++++ 1 file changed, 521 insertions(+) create mode 100644 docs/launch_security_sev.html.in diff --git a/docs/launch_security_sev.html.in b/docs/launch_security_sev.html.in new file mode 100644 index 0000000000..923bb52b25 --- /dev/null +++ b/docs/launch_security_sev.html.in @@ -0,0 +1,521 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Launch security with AMD SEV</h1> + + <ul id="toc"></ul> + + <p> + Storage encryption in modern public cloud computing is a common practice. + However, from the point of view of a user of these cloud workloads, a + significant amount of trust needs to be put in the cloud platform security as + well as integrity (was the hypervisor tampered?). For this reason there's ever + rising demand for securing data in use, i.e. memory encryption. + One of the solutions addressing this matter is AMD SEV. + </p> + + <h2>AMD SEV</h2> + <p> + SEV (Secure Encrypted Virtualization) is a feature extension of AMD's SME (Secure + Memory Encryption) intended for KVM virtual machines which is supported + primarily on AMD's EPYC CPU line. In contrast to SME, SEV uses a unique memory encryption + key for each VM. The whole encryption of memory pages is completely transparent + to the hypervisor and happens inside dedicated hardware in the on-die memory controller. + Each controller includes a high-performance Advanced Encryption Standard + (AES) engine that encrypts data when it is written to DRAM and decrypts it + when read. + + For more details about the technology itself, you can visit + <a href="https://developer.amd.com/sev/">AMD's developer portal</a>. + </p> + + <h2><a id="Host">Enabling SEV on the host</a></h2> + <p> + Before VMs can make use of the SEV feature you need to make sure your + AMD CPU does support SEV. You can check whether SEV is among the CPU + flags with: + </p> + + <pre> +$ cat /proc/cpuinfo | grep sev +... +sme ssbd sev ibpb</pre> + + <p> + Next step is to enable SEV in the kernel, because it is disabled by default. + This is done by putting the following onto the kernel command line: + </p> + + <pre> +mem_encrypt=on kvm_amd.sev=1 + </pre> + + <p> + To make the changes persistent, append the above to the variable holding + parameters of the kernel command line in + <code>/etc/default/grub</code> to preserve SEV settings across reboots + </p> + + <pre> +$ cat /etc/default/grub +... +GRUB_CMDLINE_LINUX="... mem_encrypt=on kvm_amd.sev=1" +$ grub2-mkconfig -o /boot/efi/EFI/<distro>/grub.cfg</pre> + + <p> + <code>mem_encrypt=on</code> turns on the SME memory encryption feature on + the host which protects against the physical attack on the hypervisor + memory. The <code>kvm_amd.sev</code> parameter actually enables SEV in + the kvm module. It can be set on the command line alongside + <code>mem_encrypt</code> like shown above, or it can be put into a + module config under <code>/etc/modprobe.d/</code> + </p> + + <pre> +$ cat /etc/modprobe.d/sev.conf +options kvm_amd sev=1 + </pre> + + <p> + After rebooting the host, you should see SEV being enabled in the kernel: + </p> + + <pre> +$ cat /sys/module/kvm_amd/parameters/sev +1 + </pre> + + <h2><a id="Virt">Checking SEV support in the virt stack</a></h2> + <p> + <b>Note: All of the commands bellow need to be run with root privileges.</b> + </p> + + <p> + First make sure you have the following packages in the specified versions: + </p> + + <ul> + <li> + libvirt >= 4.5.0 (>5.1.0 recommended due to additional SEV bugfixes) + </li> + <li> + QEMU >= 2.12.0 + </li> + </ul> + <p> + To confirm that the virtualization stack supports SEV, run the following: + </p> + + <pre> +# virsh domcapabilities +<domainCapabilities> +... + <features> + ... + <sev supported='yes'> + <cbitpos>47</cbitpos> + <reducedPhysBits>1</reducedPhysBits> + </sev> + ... + </features> +</domainCapabilities></pre> + <p> + Note that if libvirt was already installed and libvirtd running before enabling SEV in the kernel followed by the host reboot you need to force libvirtd + to re-probe both the host and QEMU capabilities. First stop libvirtd: + </p> + + <pre> +# systemctl stop libvirtd.service + </pre> + + <p> + Now you need to clean the capabilities cache: + </p> + + <pre> +# rm -f /var/cache/libvirt/qemu/capabilities/* + </pre> + + <p> + If you now restart libvirtd, it will re-probe the capabilities and if + you now run: + </p> + + <pre> +# virsh domcapabilities + </pre> + + <p> + SEV should be listed as supported. If you still see: + </p> + + <pre> +<sev supported='no'/> + </pre> + + <p> + it means one of two things: + <ol> + <li> + libvirt does support SEV, but either QEMU or the host does not + </li> + <li> + you have libvirt <=5.1.0 which suffered from getting a + <code>'Permission denied'</code> on <code>/dev/sev</code> because + of the default permissions on the character device which prevented + QEMU from opening it during capabilities probing - you can either + manually tweak the permissions so that QEMU has access to it or + preferably install libvirt 5.1.0 or higher + </li> + </ol> + </p> + + <h2><a id="Configuration">VM Configuration</a></h2> + <p> + SEV is enabled in the XML by specifying the + <a href="https://libvirt.org/formatdomain.html#launchSecurity"><launchSecurity> </a> element. However, specifying <code>launchSecurity</code> isn't + enough to boot an SEV VM. Further configuration requirements are discussed + below. + </p> + + <h3><a id="Machine">Machine type</a></h3> + <p> + Even though both Q35 and legacy PC machine types (for PC see also + "virtio") can be used with SEV, usage of the legacy PC machine type is + strongly discouraged, since depending on how your OVMF package was + built (e.g. including features like SecureBoot or SMM) Q35 may even be + required. + </p> + + <h5>Q35</h5> +<pre> +... +<os> + <type arch='x86_64' machine='pc-q35-3.0'>hvm</type> + ... +</os> +...</pre> + + <h5>i440fx (discouraged)</h5> + <pre> +... +<os> + <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type> + ... +</os> +... + </pre> + + <h3><a id="Boot">Boot loader</a></h3> + <p> + SEV is only going to work with OVMF (UEFI), so you'll need to point libvirt to + the correct OVMF binary. + </p> + <pre> +... +<os> + <type arch='x86_64' machine='pc-q35-3.0'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader> +</os> +...</pre> + + <h3><a id="Memory">Memory</a></h3> + <p> + Internally, SEV expects that the encrypted memory pages won't be swapped out or move + around so the VM memory needs to be pinned in physical RAM which will be + handled by QEMU. Apart from that, certain memory regions allocated by QEMU + itself (UEFI pflash, device ROMs, video RAM, etc.) have to be encrypted as + well. This causes a conflict in how libvirt tries to protect the host. + By default, libvirt enforces a memory hard limit on each VM's cgroup in order + to protect the host from malicious QEMU to allocate and lock all the available + memory. This limit corresponds to the total memory allocation for the VM given + by <code><currentMemory></code> element. However, trying to account for the additional + memory regions QEMU allocates when calculating the limit in an automated manner + is non-deterministic. One way to resolve this is to set the hard limit manually. + + <p> + Note: Figuring out the right number so that your guest boots and isn't killed is + challenging, but 256MiB extra memory over the total guest RAM should suffice for + most workloads and may serve as a good starting point. + + For example, a domain with 4GB memory with a 256MiB extra hard limit would look + like this: + </p> + </p> + + <pre> +# virsh edit <domain> +<domain> + ... + <currentMemory unit='KiB'>4194304</currentMemory> + <memtune> + <hard_limit unit='KiB'>4456448</hard_limit> + </memtune> + ... +</domain></pre> + <p> + There's another, preferred method of taking care of the limits by + using the<code><memoryBacking></code> element along with the + <code><locked/></code> subelement: + </p> + + <pre> +<domain> + ... + <memoryBacking> + <locked/> + </memoryBacking> + ... +</domain></pre> + + <p> + What that does is that it tells libvirt not to force any hard limit (well, + unlimited) upon the VM cgroup. The obvious advantage is that one doesn't need + to determine the hard limit for every single SEV-enabled VM. However, there is + a significant security-related drawback to this approach. Since no hard limit + is applied, a malicious QEMU could perform a DoS attack by locking all of the + host's available memory. The way to avoid this issue and to protect the host is + to enforce a bigger hard limit on the master cgroup containing all of the VMs + - on systemd this is <code>machine.slice</code>. + </p> + + <pre> +# systemctl set-property machine.slice MemoryHigh=<value></pre> + + <p> + To put even stricter measures in place which would involve the OOM killer, use + <pre> +# systemctl set-property machine.slice MemoryMax=<value></pre> + instead. Alternatively, you can create a systemd config (don't forget + to reload systemd configuration in this case): + <pre> +# cat << EOF > /etc/systemd/system.control/machine.slice.d/90-MemoryMax.conf +MemoryMax=<value> +EOF</pre> + The trade-off to keep in mind with the second approach is that the VMs + can still perform DoS on each other. + </p> + + <h3><a id="Virtio">Virtio</a></h3> + <p> + In order to make virtio devices work, we need to enable emulated IOMMU + on the devices so that virtual DMA can work. + </p> + + <pre> +# virsh edit <domain> +<domain> + ... + <controller type='virtio-serial' index='0'> + <driver iommu='on'/> + </controller> + <controller type='scsi' index='0' model='virtio-scsi'> + <driver iommu='on'/> + </controller> + ... + <memballoon model='virtio'> + <driver iommu='on'/> + </memballoon> + <rng model='virtio'> + <backend model='random'>/dev/urandom</backend> + <driver iommu='on'/> + </rng> + ... +<domain></pre> + + <p> + If you for some reason want to use the legacy PC machine type, further changes + to the virtio + configuration is required, because SEV will not work with Virtio <1.0. In + libvirt, this is handled by using the virtio-non-transitional device model + (libvirt >= 5.2.0 required). + + <p> + Note: some devices like video devices don't + support non-transitional model, which means that virtio GPU cannot be used. + </p> + </p> + + <pre> +<domain> + ... + <devices> + ... + <memballoon model='virtio-non-transitional'> + <driver iommu='on'/> + </memballoon> + </devices> + ... +</domain></pre> + + <h2><a id="Limitations">Limitations</a></h2> + <p> + Currently, the boot disk cannot be of type virtio-blk, instead, virtio-scsi + needs to be used if virtio is desired. This limitation is expected to be lifted + with future releases of kernel (the kernel used at the time of writing the + article is 5.0.14). + If you still cannot start an SEV VM, it could be because of wrong SELinux label on the <code>/dev/sev</code> device with selinux-policy <3.14.2.40 which prevents QEMU from touching the device. This can be resolved by upgrading the package, tuning the selinux policy rules manually to allow svirt_t to access the device (see <code>audit2allow</code> on how to do that) or putting SELinux into permissive mode (discouraged). + </p> + + <h2><a id="Examples">Full domain XML examples</a></h2> + + <h5>Q35 machine</h5> + <pre> +<domain type='kvm'> + <name>sev-dummy</name> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <memoryBacking> + <locked/> + </memoryBacking> + <vcpu placement='static'>4</vcpu> + <os> + <type arch='x86_64' machine='pc-q35-3.0'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/sev-dummy_VARS.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='host-model' check='partial'> + <model fallback='allow'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/sev-dummy.qcow2'/> + <target dev='sda' bus='scsi'/> + <boot order='1'/> + </disk> + <controller type='virtio-serial' index='0'> + <driver iommu='on'/> + </controller> + <controller type='scsi' index='0' model='virtio-scsi'> + <driver iommu='on'/> + </controller> + <interface type='network'> + <mac address='52:54:00:cc:56:90'/> + <source network='default'/> + <model type='virtio'/> + <driver iommu='on'/> + </interface> + <graphics type='spice' autoport='yes'> + <listen type='address'/> + <gl enable='no'/> + </graphics> + <video> + <model type='qxl'/> + </video> + <memballoon model='virtio'> + <driver iommu='on'/> + </memballoon> + <rng model='virtio'> + <driver iommu='on'/> + </rng> + </devices> + <launchSecurity type='sev'> + <cbitpos>47</cbitpos> + <reducedPhysBits>1</reducedPhysBits> + <policy>0x0003</policy> + </launchSecurity> +</domain></pre> + + <h5>PC-i440fx machine:</h5> + <pre> +<domain type='kvm'> + <name>sev-dummy-legacy</name> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <memtune> + <hard_limit unit='KiB'>5242880</hard_limit> + </memtune> + <vcpu placement='static'>4</vcpu> + <os> + <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/sev-dummy_VARS.fd</nvram> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='host-model' check='partial'> + <model fallback='allow'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/sev-dummy-seabios.qcow2'/> + <target dev='sda' bus='sata'/> + </disk> + <interface type='network'> + <mac address='52:54:00:d8:96:c8'/> + <source network='default'/> + <model type='virtio-non-transitional'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <input type='tablet' bus='usb'> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='spice' autoport='yes'> + <listen type='address'/> + <gl enable='no'/> + </graphics> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> + </video> + <memballoon model='virtio-non-transitional'> + <driver iommu='on'/> + </memballoon> + <rng model='virtio-non-transitional'> + <driver iommu='on'/> + </rng> + </devices> + <launchSecurity type='sev'> + <cbitpos>47</cbitpos> + <reducedPhysBits>1</reducedPhysBits> + <policy>0x0003</policy> + </launchSecurity> +</domain></pre> + </body> +</html> -- 2.21.0

2 2

[libvirt] Release of libvirt-5.5.0
by Daniel Veillard 02 Jul '19

02 Jul '19

It's there, only one day late :-) tagged in git as with signed tarball and source rpms uploaded to the usual place: https://libvirt.org/sources/ I also released the python bindings that you can find at: https://libvirt.org/sources/python/ This is a rich release with security fixes, new APIs, some deprecated features and as usual improvements and bug fixes ! Security: - api: Prevent access to several APIs over read-only connections Certain APIs give root-equivalent access to the host, and as such should be limited to privileged users. CVE-2019-10161, CVE-2019-10166, CVE-2019-10167, CVE-2019-10168. New features: - qemu: Support SMMUv3 IOMMU SMMUv3 is an IOMMU implementation for ARM virt guests. - network: Introduce the network port API This new public API can be used by virtualization drivers to manage network resources associated with guests, and is a further step towards splitting libvirtd into multiple daemons. Removed features: - qemu: Remove support for virDomainQemuAttach and virConnectDomainXMLFromNative APIs The qemu implementations for the APIs mentioned above were removed and the APIs now return an error. The implementation was stale for a long time and did not work with modern QEMU command lines, generated from libvirt or otherwise. - Stop supporting migration of config files from pre-XDG layout The new layout was introduced with libvirt 0.9.13 (Jul 2012). - Remove Avahi mDNS support This feature was never used outside of virt-manager, which has itself stopped using it a while ago. Improvements: - sysinfo: Report SMBIOS information on aarch64 While SMBIOS support has historically been limited to x86_64, modern aarch64 machines often offer access to the same information as well, and libvirt now exposes it to the user when that's the case. - test driver: Expand API coverage Even more APIs that were missing from the test driver have now been implemented. - virt-xml-validate: Allow input to be read from stdin - qemu: Validate spapr-vio addresses as 32-bit libvirt has always considered these addresses (used for pSeries guests) as 64-bit, but the sPAPR specification says that they're 32-bit instead. Bug fixes: - qemu: Set process affinity correctly when using <numatune> libvirt would mistakenly interpret the nodeset attribute as a list of CPUs instead of as a list of NUMA node, and the process affinity would be set incorrectly as a result; this has now been fixed. Thanks everybody for your help with this release, be that with bugs, fixes, reviews, documentation, localisation, etc ... Enjoy the release, Daniel -- Daniel Veillard | Red Hat Developers Tools http://developer.redhat.com/ veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] [PATCH 0/2] tests: Add and use more DO_TEST_CAPS_*() macros
by Andrea Bolognani 02 Jul '19

02 Jul '19

Andrea Bolognani (2): tests: Add more DO_TEST_CAPS_*() macros tests: Use the new DO_TEST_CAPS_*() macros tests/qemuxml2argvtest.c | 76 ++++++++++++++++++++-------------------- tests/qemuxml2xmltest.c | 32 +++++++++-------- 2 files changed, 55 insertions(+), 53 deletions(-) -- 2.21.0

1 3

[libvirt] [PATCH v2] docs: Provide documentation for SEV launch security
by Erik Skultety 02 Jul '19

02 Jul '19

Signed-off-by: Erik Skultety <eskultet(a)redhat.com> --- docs/launch_security_sev.html.in | 516 +++++++++++++++++++++++++++++++ 1 file changed, 516 insertions(+) create mode 100644 docs/launch_security_sev.html.in diff --git a/docs/launch_security_sev.html.in b/docs/launch_security_sev.html.in new file mode 100644 index 0000000000..2f0f89d714 --- /dev/null +++ b/docs/launch_security_sev.html.in @@ -0,0 +1,516 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + <h1>Launch security with AMD SEV</h1> + + <ul id="toc"></ul> + + <p> + Storage encryption in modern public cloud computing is a common practice. + However, from the point of view of a user of these cloud workloads, a + significant amount of trust needs to be put in the cloud platform security as + well as integrity (was the hypervisor tampered?). For this reason there's ever + rising demand for securing data in use, i.e. memory encryption. + One of the solutions addressing this matter is AMD SEV. + </p> + + <h2>AMD SEV</h2> + <p> + SEV (Secure Encrypted Virtualization) is a feature extension of AMD's SME (Secure + Memory Encryption) intended for KVM virtual machines which is supported + primarily on AMD's EPYC CPU line. In contrast to SME, SEV uses a unique memory encryption + key for each VM. The whole encryption of memory pages is completely transparent + to the hypervisor and happens in the AMD firmware. + For more details about the technology itself, you can visit + <a href="https://developer.amd.com/sev/">AMD's developer portal</a>. + </p> + + <h2><a id="Host">Enabling SEV on the host</a></h2> + <p> + Before VMs can make use of the SEV feature you need to make sure your + AMD CPU does support SEV. You can check whether SEV is among the CPU + flags with: + </p> + + <pre> +$ cat /proc/cpuinfo | grep sev +... +sme ssbd sev ibpb</pre> + + <p> + Next step is to enable SEV in the kernel, because it is disabled by default. + This is done by putting the following onto the kernel command line: + </p> + + <pre> +mem_encrypt=on kvm_amd.sev=1 + </pre> + + <p> + To make the changes persistent, append the above to the variable holding + parameters of the kernel command line in + <code>/etc/default/grub</code> to preserve SEV settings across reboots + </p> + + <pre> +$ cat /etc/default/grub +... +GRUB_CMDLINE_LINUX="... mem_encrypt=on kvm_amd.sev=1" +$ grub2-mkconfig -o /boot/efi/EFI/<distro>/grub.cfg</pre> + + <p> + <code>mem_encrypt=on</code> turns on the SME memory encryption feature on + the host which is required for SEV to work. The <code>kvm_amd.sev</code> + parameter actually enables SEV in the kvm module. It can be set on the + command line alongside <code>mem_encrypt</code> like shown above, or it + can be put into a module config under <code>/etc/modprobe.d/</code> + </p> + + <pre> +$ cat /etc/modprobe.d/sev.conf +options kvm_amd sev=1 + </pre> + + <p> + After rebooting the host, you should see SEV being enabled in the kernel: + </p> + + <pre> +$ cat /sys/module/kvm_amd/parameters/sev +1 + </pre> + + <h2><a id="Virt">Checking SEV support in the virt stack</a></h2> + <p> + <b>Note: All of the commands bellow need to be run with root privileges.</b> + </p> + + <p> + First make sure you have the following packages in the specified versions: + </p> + + <ul> + <li> + libvirt >= 4.5.0 (>5.1.0 recommended due to additional SEV bugfixes) + </li> + <li> + QEMU >= 2.12.0 + </li> + </ul> + <p> + To confirm that the virtualization stack supports SEV, run the following: + </p> + + <pre> +# virsh domcapabilities +<domainCapabilities> +... + <features> + ... + <sev supported='yes'> + <cbitpos>47</cbitpos> + <reducedPhysBits>1</reducedPhysBits> + </sev> + ... + </features> +</domainCapabilities></pre> + <p> + Note that if libvirt was already installed and libvirtd running before enabling SEV in the kernel followed by the host reboot you need to force libvirtd + to re-probe both the host and QEMU capabilities. First stop libvirtd: + </p> + + <pre> +# systemctl stop libvirtd.service + </pre> + + <p> + Now you need to clean the capabilities cache: + </p> + + <pre> +# rm -f /var/cache/libvirt/qemu/capabilities/* + </pre> + + <p> + If you now restart libvirtd, it will re-probe the capabilities and if + you now run: + </p> + + <pre> +# virsh domcapabilities + </pre> + + <p> + SEV should be listed as supported. If you still see: + </p> + + <pre> +<sev supported='no'/> + </pre> + + <p> + it means one of two things: + <ol> + <li> + libvirt does support SEV, but either QEMU or the host does not + </li> + <li> + you have libvirt <=5.1.0 which suffered from getting a + <code>'Permission denied'</code> on <code>/dev/sev</code> because + of the default permissions on the character device which prevented + QEMU from opening it during capabilities probing - you can either + manually tweak the permissions so that QEMU has access to it or + preferably install libvirt 5.1.0 or higher + </li> + </ol> + </p> + + <h2><a id="Configuration">VM Configuration</a></h2> + <p> + SEV is enabled in the XML by specifying the + <a href="https://libvirt.org/formatdomain.html#launchSecurity"><launchSecurity> </a> element. However, specifying <code>launchSecurity</code> isn't + enough to boot an SEV VM. Further configuration requirements are discussed + below. + </p> + + <h3><a id="Machine">Machine type</a></h3> + <p> + Even though both Q35 and legacy PC machine types (for PC see also + "virtio") can be used with SEV, usage of the legacy PC machine type is + strongly discouraged, since depending on how your OVMF package was + built (e.g. including features like SecureBoot or SMM) Q35 may even be + required. + </p> + + <h5>Q35</h5> +<pre> +... +<os> + <type arch='x86_64' machine='pc-q35-3.0'>hvm</type> + ... +</os> +...</pre> + + <h5>i440fx (discouraged)</h5> + <pre> +... +<os> + <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type> + ... +</os> +... + </pre> + + <h3><a id="Boot">Boot loader</a></h3> + <p> + SEV is only going to work with OVMF (UEFI), so you'll need to point libvirt to + the correct OVMF binary. + </p> + <pre> +... +<os> + <type arch='x86_64' machine='pc-q35-3.0'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader> +</os> +...</pre> + + <h3><a id="Memory">Memory</a></h3> + <p> + Internally, SEV expects that the encrypted memory pages won't be swapped out or move + around so the VM memory needs to be pinned in physical RAM which will be + handled by QEMU. Apart from that, certain memory regions allocated by QEMU + itself (UEFI pflash, device ROMs, video RAM, etc.) have to be encrypted as + well. This causes a conflict in how libvirt tries to protect the host. + By default, libvirt enforces a memory hard limit on each VM's cgroup in order + to protect the host from malicious QEMU to allocate and lock all the available + memory. This limit corresponds to the total memory allocation for the VM given + by <code><currentMemory></code> element. However, trying to account for the additional + memory regions QEMU allocates when calculating the limit in an automated manner + is non-deterministic. One way to resolve this is to set the hard limit manually. + + <p> + Note: Figuring out the right number so that your guest boots and isn't killed is + challenging, but 256MiB extra memory over the total guest RAM should suffice for + most workloads and may serve as a good starting point. + + For example, a domain with 4GB memory with a 256MiB extra hard limit would look + like this: + </p> + </p> + + <pre> +# virsh edit <domain> +<domain> + ... + <currentMemory unit='KiB'>4194304</currentMemory> + <memtune> + <hard_limit unit='KiB'>4456448</hard_limit> + </memtune> + ... +</domain></pre> + <p> + There's another, preferred method of taking care of the limits by + using the<code><memoryBacking></code> element along with the + <code><locked/></code> subelement: + </p> + + <pre> +<domain> + ... + <memoryBacking> + <locked/> + </memoryBacking> + ... +</domain></pre> + + <p> + What that does is that it tells libvirt not to force any hard limit (well, + unlimited) upon the VM cgroup. The obvious advantage is that one doesn't need + to determine the hard limit for every single SEV-enabled VM. However, there is + a significant security-related drawback to this approach. Since no hard limit + is applied, a malicious QEMU could perform a DoS attack by locking all of the + host's available memory. The way to avoid this issue and to protect the host is + to enforce a bigger hard limit on the master cgroup containing all of the VMs + - on systemd this is <code>machine.slice</code>. + </p> + + <pre> +# systemctl set-property machine.slice MemoryHigh=<value></pre> + + <p> + To put even stricter measures in place which would involve the OOM killer, use + <pre> +# systemctl set-property machine.slice MemoryMax=<value></pre> + instead. Alternatively, you can create a systemd config (don't forget + to reload systemd configuration in this case): + <pre> +# cat << EOF > /etc/systemd/system.control/machine.slice.d/90-MemoryMax.conf +MemoryMax=<value> +EOF</pre> + The trade-off to keep in mind with the second approach is that the VMs + can still perform DoS on each other. + </p> + + <h3><a id="Virtio">Virtio</a></h3> + <p> + In order to make virtio devices work, we need to enable emulated IOMMU + on the devices so that virtual DMA can work. + </p> + + <pre> +# virsh edit <domain> +<domain> + ... + <controller type='virtio-serial' index='0'> + <driver iommu='on'/> + </controller> + <controller type='scsi' index='0' model='virtio-scsi'> + <driver iommu='on'/> + </controller> + ... + <memballoon model='virtio'> + <driver iommu='on'/> + </memballoon> + <rng model='virtio'> + <backend model='random'>/dev/urandom</backend> + <driver iommu='on'/> + </rng> + ... +<domain></pre> + + <p> + If you for some reason want to use the legacy PC machine type, further changes + to the virtio + configuration is required, because SEV will not work with Virtio <1.0. In + libvirt, this is handled by using the virtio-non-transitional device model + (libvirt >= 5.2.0 required). + + <p> + Note: some devices like video devices don't + support non-transitional model, which means that virtio GPU cannot be used. + </p> + </p> + + <pre> +<domain> + ... + <devices> + ... + <memballoon model='virtio-non-transitional'> + <driver iommu='on'/> + </memballoon> + </devices> + ... +</domain></pre> + + <h2><a id="Limitations">Limitations</a></h2> + <p> + Currently, the boot disk cannot be of type virtio-blk, instead, virtio-scsi + needs to be used if virtio is desired. This limitation is expected to be lifted + with future releases of kernel (the kernel used at the time of writing the + article is 5.0.14). + If you still cannot start an SEV VM, it could be because of wrong SELinux label on the <code>/dev/sev</code> device with selinux-policy <3.14.2.40 which prevents QEMU from touching the device. This can be resolved by upgrading the package, tuning the selinux policy rules manually to allow svirt_t to access the device (see <code>audit2allow</code> on how to do that) or putting SELinux into permissive mode (discouraged). + </p> + + <h2><a id="Examples">Full domain XML examples</a></h2> + + <h5>Q35 machine</h5> + <pre> +<domain type='kvm'> + <name>sev-dummy</name> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <memoryBacking> + <locked/> + </memoryBacking> + <vcpu placement='static'>4</vcpu> + <os> + <type arch='x86_64' machine='pc-q35-3.0'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/sev-dummy_VARS.fd</nvram> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='host-model' check='partial'> + <model fallback='allow'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/sev-dummy.qcow2'/> + <target dev='sda' bus='scsi'/> + <boot order='1'/> + </disk> + <controller type='virtio-serial' index='0'> + <driver iommu='on'/> + </controller> + <controller type='scsi' index='0' model='virtio-scsi'> + <driver iommu='on'/> + </controller> + <interface type='network'> + <mac address='52:54:00:cc:56:90'/> + <source network='default'/> + <model type='virtio'/> + <driver iommu='on'/> + </interface> + <graphics type='spice' autoport='yes'> + <listen type='address'/> + <gl enable='no'/> + </graphics> + <video> + <model type='qxl'/> + </video> + <memballoon model='virtio'> + <driver iommu='on'/> + </memballoon> + <rng model='virtio'> + <driver iommu='on'/> + </rng> + </devices> + <launchSecurity type='sev'> + <cbitpos>47</cbitpos> + <reducedPhysBits>1</reducedPhysBits> + <policy>0x0003</policy> + </launchSecurity> +</domain></pre> + + <h5>PC-i440fx machine:</h5> + <pre> +<domain type='kvm'> + <name>sev-dummy-legacy</name> + <memory unit='KiB'>4194304</memory> + <currentMemory unit='KiB'>4194304</currentMemory> + <memtune> + <hard_limit unit='KiB'>5242880</hard_limit> + </memtune> + <vcpu placement='static'>4</vcpu> + <os> + <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type> + <loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader> + <nvram>/var/lib/libvirt/qemu/nvram/sev-dummy_VARS.fd</nvram> + <boot dev='hd'/> + </os> + <features> + <acpi/> + <apic/> + <vmport state='off'/> + </features> + <cpu mode='host-model' check='partial'> + <model fallback='allow'/> + </cpu> + <clock offset='utc'> + <timer name='rtc' tickpolicy='catchup'/> + <timer name='pit' tickpolicy='delay'/> + <timer name='hpet' present='no'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <pm> + <suspend-to-mem enabled='no'/> + <suspend-to-disk enabled='no'/> + </pm> + <devices> + <emulator>/usr/bin/qemu-kvm</emulator> + <disk type='file' device='disk'> + <driver name='qemu' type='qcow2'/> + <source file='/var/lib/libvirt/images/sev-dummy-seabios.qcow2'/> + <target dev='sda' bus='sata'/> + </disk> + <interface type='network'> + <mac address='52:54:00:d8:96:c8'/> + <source network='default'/> + <model type='virtio-non-transitional'/> + </interface> + <serial type='pty'> + <target type='isa-serial' port='0'> + <model name='isa-serial'/> + </target> + </serial> + <console type='pty'> + <target type='serial' port='0'/> + </console> + <input type='tablet' bus='usb'> + <address type='usb' bus='0' port='1'/> + </input> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <graphics type='spice' autoport='yes'> + <listen type='address'/> + <gl enable='no'/> + </graphics> + <video> + <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> + </video> + <memballoon model='virtio-non-transitional'> + <driver iommu='on'/> + </memballoon> + <rng model='virtio-non-transitional'> + <driver iommu='on'/> + </rng> + </devices> + <launchSecurity type='sev'> + <cbitpos>47</cbitpos> + <reducedPhysBits>1</reducedPhysBits> + <policy>0x0003</policy> + </launchSecurity> +</domain></pre> + </body> +</html> -- 2.21.0

2 1

[libvirt] [PATCH 0/4] test_driver: implement some DomainGetParametersAPIs
by Ilias Stamatis 02 Jul '19

02 Jul '19

Ilias Stamatis (4): test_driver: introduce TEST_SET_PARAM macro test_driver: implement virDomainGetMemoryParameters test_driver: implement virDomainGetNumaParameters test_driver: implement testDomainGetInterfaceParameters src/test/test_driver.c | 157 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 157 insertions(+) -- 2.22.0

3 7

[libvirt] [PATCH 0/2] test_driver: add a disk device and implement
by Ilias Stamatis 02 Jul '19

02 Jul '19

Ilias Stamatis (2): test_driver: add a disk device in the default config test_driver: implement virDomainGetFSInfo src/test/test_driver.c | 71 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) -- 2.22.0

2 6

[libvirt] [PATCH] test_driver: fix some bugs on testDomainGetDiskErrors
by Ilias Stamatis 02 Jul '19

02 Jul '19

The current implementation has the following bugs: - the vm variable is accessed after calling virDomainObjEndAPI on it - if VIR_STRDUP fails and we jump to the cleanup section, we're calling VIR_FREE on pointers for which we haven't allocated memory - the error type VIR_DOMAIN_DISK_ERROR_NONE is used which contradicts the documentation of the API that says that disks with no errors are not reported This patch fixes all of them and additionally reports errors only for every second disk (instead of reporting errors for all disks) which was the initial intention. Signed-off-by: Ilias Stamatis <stamatis.iliass(a)gmail.com> --- src/test/test_driver.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index 2a0ffbc6c5..a7e40112d1 100755 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -3246,6 +3246,7 @@ static int testDomainGetDiskErrors(virDomainPtr dom, unsigned int flags) { virDomainObjPtr vm = NULL; + int n = 0; int ret = -1; size_t i; @@ -3258,12 +3259,13 @@ static int testDomainGetDiskErrors(virDomainPtr dom, goto cleanup; if (errors) { - for (i = 0; i < MIN(vm->def->ndisks, maxerrors); i++) { - if (VIR_STRDUP(errors[i].disk, vm->def->disks[i]->dst) < 0) + for (i = 1; i < vm->def->ndisks && n < maxerrors; i += 2) { + if (VIR_STRDUP(errors[n].disk, vm->def->disks[i]->dst) < 0) goto cleanup; - errors[i].error = i % VIR_DOMAIN_DISK_ERROR_LAST; + errors[n].error = (n % (VIR_DOMAIN_DISK_ERROR_LAST - 1)) + 1; + n++; } - ret = i; + ret = n; } else { ret = vm->def->ndisks; } @@ -3271,7 +3273,7 @@ static int testDomainGetDiskErrors(virDomainPtr dom, cleanup: virDomainObjEndAPI(&vm); if (ret < 0) { - for (i = 0; i < MIN(vm->def->ndisks, maxerrors); i++) + for (i = 0; i < n; i++) VIR_FREE(errors[i].disk); } return ret; -- 2.22.0

2 3

[libvirt] Checking the expected behavior on dynamic image file ownership when live migrating
by Christian Ehrhardt 02 Jul '19

02 Jul '19

Hi, today I was debugging an issue that I found with qemu 4.0 and ended up puzzled about file ownership. I'm almost EOD now, but wanted to reach out here for a sanity check before I debug further. The case sumamrized is this: 1. start guest 1.1 image files are changed to libvirt-qemu:kvm (which matches Ubuntus user/group config) 2. live migrate the guest to a different node 2.1 image files go back to root:root which they initially had (ok) 3. migrate guest back to the original node x. image files stay root:root and are not changed back to libvirt-qemu:kvm That is odd/unexpected, but it seems the same applies to older versions and there it was never a problem so far. In my case I stumbled over it because the newer qemu --copy-storage-* options now want to re-open the file at some point and that fails with: error: internal error: unable to execute QEMU command 'drive-mirror': Could not reopen file: Permission denied If I e.g. shut down and start the guest on the source node (which fixes up the ownership at runtime) then migration with copy-storage works fine again. I'm mostly looking for hints if this is a known issue or being worked on to not waste time tomorrow. So hints are welcome. -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd

2 4

[libvirt] [PATCH v2] test_driver: implement virDomainGetMemoryParameters
by Ilias Stamatis 02 Jul '19

02 Jul '19

Signed-off-by: Ilias Stamatis <stamatis.iliass(a)gmail.com> --- Things changed since v1: - virDomainObjGetOneDef is used in order to get the appropriate def - the TEST_ASSIGN_MEM_PARAM macro got removed src/test/test_driver.c | 52 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index 4b1f2724a0..01b3ed88f3 100755 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -2514,6 +2514,57 @@ testDomainGetMaxVcpus(virDomainPtr domain) VIR_DOMAIN_VCPU_MAXIMUM)); } + +static int +testDomainGetMemoryParameters(virDomainPtr dom, + virTypedParameterPtr params, + int *nparams, + unsigned int flags) +{ + int ret = -1; + virDomainObjPtr vm = NULL; + virDomainDefPtr def = NULL; + + virCheckFlags(VIR_DOMAIN_AFFECT_LIVE | + VIR_DOMAIN_AFFECT_CONFIG | + VIR_TYPED_PARAM_STRING_OKAY, -1); + + if ((*nparams) == 0) { + *nparams = 3; + return 0; + } + + if (!(vm = testDomObjFromDomain(dom))) + goto cleanup; + + if (!(def = virDomainObjGetOneDef(vm, flags))) + goto cleanup; + + if (*nparams > 0 && + virTypedParameterAssign(&params[0], VIR_DOMAIN_MEMORY_HARD_LIMIT, + VIR_TYPED_PARAM_ULLONG, def->mem.hard_limit) < 0) + goto cleanup; + + if (*nparams > 1 && + virTypedParameterAssign(&params[1], VIR_DOMAIN_MEMORY_SOFT_LIMIT, + VIR_TYPED_PARAM_ULLONG, def->mem.soft_limit) < 0) + goto cleanup; + + if (*nparams > 2 && + virTypedParameterAssign(&params[2], VIR_DOMAIN_MEMORY_SWAP_HARD_LIMIT, + VIR_TYPED_PARAM_ULLONG, def->mem.swap_hard_limit) < 0) + goto cleanup; + + if (*nparams > 3) + *nparams = 3; + + ret = 0; + cleanup: + virDomainObjEndAPI(&vm); + return ret; +} + + static int testDomainSetVcpusFlags(virDomainPtr domain, unsigned int nrCpus, unsigned int flags) @@ -7275,6 +7326,7 @@ static virHypervisorDriver testHypervisorDriver = { .domainGetVcpus = testDomainGetVcpus, /* 0.7.3 */ .domainGetVcpuPinInfo = testDomainGetVcpuPinInfo, /* 1.2.18 */ .domainGetMaxVcpus = testDomainGetMaxVcpus, /* 0.7.3 */ + .domainGetMemoryParameters = testDomainGetMemoryParameters, /* 5.6.0 */ .domainGetXMLDesc = testDomainGetXMLDesc, /* 0.1.4 */ .connectListDefinedDomains = testConnectListDefinedDomains, /* 0.1.11 */ .connectNumOfDefinedDomains = testConnectNumOfDefinedDomains, /* 0.1.11 */ -- 2.22.0

2 4

[libvirt] [PATCH v2] test_driver: implement virDomainGetInterfaceParameters
by Ilias Stamatis 02 Jul '19

02 Jul '19

Signed-off-by: Ilias Stamatis <stamatis.iliass(a)gmail.com> --- The only thing changed since v1 is calling virDomainObjGetOneDef to get the appropriate def pointer. src/test/test_driver.c | 104 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index 4b1f2724a0..dd756ed8bd 100755 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -1964,6 +1964,109 @@ static int testDomainGetInfo(virDomainPtr domain, return ret; } + +static int +testDomainGetInterfaceParameters(virDomainPtr dom, + const char *device, + virTypedParameterPtr params, + int *nparams, + unsigned int flags) +{ + size_t i; + virDomainObjPtr vm = NULL; + virDomainDefPtr def = NULL; + virDomainNetDefPtr net = NULL; + int ret = -1; + + virCheckFlags(VIR_DOMAIN_AFFECT_LIVE | + VIR_DOMAIN_AFFECT_CONFIG | + VIR_TYPED_PARAM_STRING_OKAY, -1); + + if ((*nparams) == 0) { + *nparams = 7; + return 0; + } + + if (!(vm = testDomObjFromDomain(dom))) + return -1; + + if (!(def = virDomainObjGetOneDef(vm, flags))) + goto cleanup; + + if (!(net = virDomainNetFind(def, device))) + goto cleanup; + + for (i = 0; i < *nparams && i < 7; i++) { + switch (i) { + case 0: /* inbound.average */ + if (virTypedParameterAssign(&params[i], + VIR_DOMAIN_BANDWIDTH_IN_AVERAGE, + VIR_TYPED_PARAM_UINT, 0) < 0) + goto cleanup; + if (net->bandwidth && net->bandwidth->in) + params[i].value.ui = net->bandwidth->in->average; + break; + case 1: /* inbound.peak */ + if (virTypedParameterAssign(&params[i], + VIR_DOMAIN_BANDWIDTH_IN_PEAK, + VIR_TYPED_PARAM_UINT, 0) < 0) + goto cleanup; + if (net->bandwidth && net->bandwidth->in) + params[i].value.ui = net->bandwidth->in->peak; + break; + case 2: /* inbound.burst */ + if (virTypedParameterAssign(&params[i], + VIR_DOMAIN_BANDWIDTH_IN_BURST, + VIR_TYPED_PARAM_UINT, 0) < 0) + goto cleanup; + if (net->bandwidth && net->bandwidth->in) + params[i].value.ui = net->bandwidth->in->burst; + break; + case 3: /* inbound.floor */ + if (virTypedParameterAssign(&params[i], + VIR_DOMAIN_BANDWIDTH_IN_FLOOR, + VIR_TYPED_PARAM_UINT, 0) < 0) + goto cleanup; + if (net->bandwidth && net->bandwidth->in) + params[i].value.ui = net->bandwidth->in->floor; + break; + case 4: /* outbound.average */ + if (virTypedParameterAssign(&params[i], + VIR_DOMAIN_BANDWIDTH_OUT_AVERAGE, + VIR_TYPED_PARAM_UINT, 0) < 0) + goto cleanup; + if (net->bandwidth && net->bandwidth->out) + params[i].value.ui = net->bandwidth->out->average; + break; + case 5: /* outbound.peak */ + if (virTypedParameterAssign(&params[i], + VIR_DOMAIN_BANDWIDTH_OUT_PEAK, + VIR_TYPED_PARAM_UINT, 0) < 0) + goto cleanup; + if (net->bandwidth && net->bandwidth->out) + params[i].value.ui = net->bandwidth->out->peak; + break; + case 6: /* outbound.burst */ + if (virTypedParameterAssign(&params[i], + VIR_DOMAIN_BANDWIDTH_OUT_BURST, + VIR_TYPED_PARAM_UINT, 0) < 0) + goto cleanup; + if (net->bandwidth && net->bandwidth->out) + params[i].value.ui = net->bandwidth->out->burst; + break; + } + } + + if (*nparams > 7) + *nparams = 7; + + ret = 0; + cleanup: + virDomainObjEndAPI(&vm); + return ret; +} + + static int testDomainGetState(virDomainPtr domain, int *state, @@ -7258,6 +7361,7 @@ static virHypervisorDriver testHypervisorDriver = { .domainSetMemory = testDomainSetMemory, /* 0.1.4 */ .domainGetHostname = testDomainGetHostname, /* 5.5.0 */ .domainGetInfo = testDomainGetInfo, /* 0.1.1 */ + .domainGetInterfaceParameters = testDomainGetInterfaceParameters, /* 5.6.0 */ .domainGetState = testDomainGetState, /* 0.9.2 */ .domainGetTime = testDomainGetTime, /* 5.4.0 */ .domainSave = testDomainSave, /* 0.3.2 */ -- 2.22.0

2 3

[libvirt] [PATCH 0/2] Couple of test_driver fixes
by Michal Privoznik 02 Jul '19

02 Jul '19

I was too eager to minimize patch 89320788ac4 and did some mistakes. Here are the fixes. Michal Prívozník (2): test_driver: Don't access @vm after it was set to NULL test_driver: Don't report VIR_DOMAIN_DISK_ERROR_NONE src/test/test_driver.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.21.0

2 5

[libvirt] [PATCH v2 8/9] docs: Deprecate CPU model runnability guarantees
by Eduardo Habkost 02 Jul '19

02 Jul '19

Document that CPU model runnability guarantees won't apply to unversioned CPU models anymore. Signed-off-by: Eduardo Habkost <ehabkost(a)redhat.com> --- Changes v1 -> v2: * (none) Cc: libvir-list(a)redhat.com --- qemu-deprecated.texi | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi index 9cba82d5ec..18f85f70e1 100644 --- a/qemu-deprecated.texi +++ b/qemu-deprecated.texi @@ -276,3 +276,22 @@ Note that if you are exposing the export via /dev/nbd0, it is easier to just export the entire image and then mount only /dev/nbd0p1 than it is to reinvoke @command{qemu-nbd -c /dev/nbd0} limited to just a subset of the image. + +@section Backwards compatibility + +@subsection Runnability guarantee of CPU models (since 4.1.0) + +Previous versions of QEMU never changed existing CPU models in +ways that introduced additional host software or hardware +requirements to the VM. This allowed management software to +safely change the machine type of an existing VM without +introducing new requirements ("runnability guarantee"). This +prevented CPU models from being updated to include CPU +vulnerability mitigations, leaving guests vulnerable in the +default configuration. + +The CPU model runnability guarantee won't apply anymore to +existing CPU models. Management software that needs runnability +guarantees must resolve the CPU model aliases using te +``alias-of'' field returned by the ``query-cpu-definitions'' QMP +command. -- 2.18.0.rc1.1.g3f1ff2140

2 1

[libvirt] [PATCH] qemu: remove a redundant call from qemuDomainGetPerfEvents
by Ilias Stamatis 02 Jul '19

02 Jul '19

Calling virDomainObjUpdateModificationImpact directly inside the function body is redundant, since the same function call is embedded into virDomainObjGetOneDef. Signed-off-by: Ilias Stamatis <stamatis.iliass(a)gmail.com> --- src/qemu/qemu_driver.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index ef2e980216..6bfbc31c1c 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -10339,9 +10339,6 @@ qemuDomainGetPerfEvents(virDomainPtr dom, if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_QUERY) < 0) goto cleanup; - if (virDomainObjUpdateModificationImpact(vm, &flags) < 0) - goto endjob; - if (!(def = virDomainObjGetOneDef(vm, flags))) goto endjob; -- 2.22.0

2 1

[libvirt] mdevctl: A shoestring mediated device management and persistence utility
by Alex Williamson 01 Jul '19

01 Jul '19

Hi, Currently mediated device management, much like SR-IOV VF management, is largely left as an exercise for the user. This is an attempt to provide something and see where it goes. I doubt we'll solve everyone's needs on the first pass, but maybe we'll solve enough and provide helpers for the rest. Without further ado, I'll point to what I have so far: https://github.com/awilliam/mdevctl This is inspired by driverctl, which is also a bash utility. mdevctl uses udev and systemd to record and recreate mdev devices for persistence and provides a command line utility for querying, listing, starting, stopping, adding, and removing mdev devices. Currently, for better or worse, it considers anything created to be persistent. I can imagine a global configuration option that might disable this and perhaps an autostart flag per mdev device, such that mdevctl might simply "know" about some mdevs but not attempt to create them automatically. Clearly command line usage help, man pages, and packaging are lacking as well, release early, release often, plus this is a discussion starter to see if perhaps this is sufficient to meet some needs. Originally I thought about making a utility to manage both mdev and SR-IOV VFs all in one, but it seemed more natural to start here (besides, I couldn't think of a good name for the combined utility). If this seems useful, maybe I'll start on a vfctl for SR-IOV and we'll see whether they have enough synergy to become one. It would be really useful if s390 folks could help me understand whether it's possible to glean all the information necessary to recreate a ccw or ap mdev device from sysfs. I expect the file where we currently only store the mdev_type to evolve into something that includes more information to facilitate more complicated devices. For now I make no claims to maintaining compatibility of recorded mdev devices, it will absolutely change, but I didn't want to get bogged down in making sure I don't accidentally source a root kit hidden in an mdev config file. I'm also curious how or if libvirt or openstack might use this. If nothing else, it makes libvirt hook scripts easier to write, especially if we add an option not to autostart mdevs, or if users don't mind persistent mdevs, maybe there's nothing more to do. BTW, feel free to clean up by bash, I'm a brute force and ignorance shell coder ;) Thanks, Alex

7 50

[libvirt] [PATCH] rpc: Fix build error for virNetServerNew ATTRIBUTE_NONNULL values
by John Ferlan 01 Jul '19

01 Jul '19

Commit 5a148ce84 altered the virNetServerNew to remove a parameter but neglected to update the ATTRIBUTE_NONNULL's which causes a build failure for when checking is enabled such as when lv_cv_static_analysis is enabled. Signed-off-by: John Ferlan <jferlan(a)redhat.com> --- Pushing as build breaker/trivial src/rpc/virnetserver.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/rpc/virnetserver.h b/src/rpc/virnetserver.h index b47b71b4b2..6b2541588c 100644 --- a/src/rpc/virnetserver.h +++ b/src/rpc/virnetserver.h @@ -42,7 +42,7 @@ virNetServerPtr virNetServerNew(const char *name, virNetServerClientPrivPreExecRestart clientPrivPreExecRestart, virFreeCallback clientPrivFree, void *clientPrivOpaque) - ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(11) ATTRIBUTE_NONNULL(13); + ATTRIBUTE_NONNULL(1) ATTRIBUTE_NONNULL(10) ATTRIBUTE_NONNULL(12); virNetServerPtr virNetServerNewPostExecRestart(virJSONValuePtr object, const char *name, -- 2.20.1

1 0

[libvirt] [PATCH] tools: Fix permissions for virt-pki-validate.in
by Andrea Bolognani 01 Jul '19

01 Jul '19

While the script ultimately needs to be executable, the source file really shouldn't be. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed as trivial. tools/virt-pki-validate.in | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 tools/virt-pki-validate.in diff --git a/tools/virt-pki-validate.in b/tools/virt-pki-validate.in old mode 100755 new mode 100644 -- 2.21.0

1 0

[libvirt] [PATCH] test_driver: Fix permissions for test_driver.c
by Andrea Bolognani 01 Jul '19

01 Jul '19

Introduced in commit 4a6ee53581b3. Signed-off-by: Andrea Bolognani <abologna(a)redhat.com> --- Pushed as trivial. src/test/test_driver.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 src/test/test_driver.c diff --git a/src/test/test_driver.c b/src/test/test_driver.c old mode 100755 new mode 100644 -- 2.21.0

1 0

[libvirt] [PATCH v2] test_driver: implement virDomainGetNumaParameters
by Ilias Stamatis 01 Jul '19

01 Jul '19

Signed-off-by: Ilias Stamatis <stamatis.iliass(a)gmail.com> --- src/test/test_driver.c | 52 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) diff --git a/src/test/test_driver.c b/src/test/test_driver.c index 4b1f2724a0..dc6d3b078c 100755 --- a/src/test/test_driver.c +++ b/src/test/test_driver.c @@ -2405,6 +2405,57 @@ testDomainCoreDump(virDomainPtr domain, } +static int +testDomainGetNumaParameters(virDomainPtr dom, + virTypedParameterPtr params, + int *nparams, + unsigned int flags) +{ + virDomainObjPtr vm = NULL; + virDomainDefPtr def = NULL; + virDomainNumatuneMemMode mode = VIR_DOMAIN_NUMATUNE_MEM_STRICT; + VIR_AUTOFREE(char *) nodeset = NULL; + int ret = -1; + + virCheckFlags(VIR_DOMAIN_AFFECT_LIVE | + VIR_DOMAIN_AFFECT_CONFIG | + VIR_TYPED_PARAM_STRING_OKAY, -1); + + if ((*nparams) == 0) { + *nparams = 2; + return 0; + } + + if (!(vm = testDomObjFromDomain(dom))) + goto cleanup; + + if (!(def = virDomainObjGetOneDef(vm, flags))) + goto cleanup; + + ignore_value(virDomainNumatuneGetMode(def->numa, -1, &mode)); + if (*nparams > 0 && + virTypedParameterAssign(&params[0], VIR_DOMAIN_NUMA_MODE, VIR_TYPED_PARAM_INT, mode) < 0) + goto cleanup; + + nodeset = virDomainNumatuneFormatNodeset(def->numa, NULL, -1); + if (*nparams > 1 && (!nodeset || + virTypedParameterAssign(&params[1], + VIR_DOMAIN_NUMA_NODESET, + VIR_TYPED_PARAM_STRING, + nodeset) < 0)) + goto cleanup; + nodeset = NULL; + + if (*nparams > 2) + *nparams = 2; + + ret = 0; + cleanup: + virDomainObjEndAPI(&vm); + return ret; +} + + static char * testDomainGetOSType(virDomainPtr dom ATTRIBUTE_UNUSED) { @@ -7251,6 +7302,7 @@ static virHypervisorDriver testHypervisorDriver = { .domainReboot = testDomainReboot, /* 0.1.1 */ .domainDestroy = testDomainDestroy, /* 0.1.1 */ .domainDestroyFlags = testDomainDestroyFlags, /* 4.2.0 */ + .domainGetNumaParameters = testDomainGetNumaParameters, /* 5.6.0 */ .domainGetOSType = testDomainGetOSType, /* 0.1.9 */ .domainGetLaunchSecurityInfo = testDomainGetLaunchSecurityInfo, /* 5.5.0 */ .domainGetMaxMemory = testDomainGetMaxMemory, /* 0.1.4 */ -- 2.22.0

2 1