- Devel - libvirt List Archives

[libvirt] [PATCH 0/4] bhyve: model PCI ISA bridge
by Roman Bogorodskiy 11 Feb '19

11 Feb '19

This adds modeling of the pci-isa bridge device for bhyve to make it possible to assign specific PCI address for instead of the default PCI slot 0. I tried to keep the existing behaviour, i.e. the isa-bridge controller is automatically added to domain if it uses serial or video devices, or boot ROM. It also tries to assign pci slot 1 for it, that should not be a problem because previously that address was always reserved for the isa-bridge, so it definitely wasn't used by other devices. Now, however, it's not always reserved. For example, if there are no devices in the domain configuration that require isa-bridge, and users didn't explicitly add it (or added that on a different slot), then PCI slot 1 is available for allocation. This probably can be a problem for users when they figure out that they still need to add the isa-bridge device on slot 1, but it's already used, but I'm not sure if it's worth to always reserve slot 1 for that purpose. Roman Bogorodskiy (4): conf: add 'isa-bridge' PCI controller model bhyve: model PCI ISA bridge docs: bhyve: document isa-bridge addressing news: document bhyve isa-bridge changes docs/drvbhyve.html.in | 22 +++++++++ docs/news.xml | 10 ++++ docs/schemas/domaincommon.rng | 1 + src/bhyve/bhyve_command.c | 32 +++++-------- src/bhyve/bhyve_device.c | 47 ++++++++++++------- src/bhyve/bhyve_domain.c | 6 +++ src/conf/domain_addr.c | 10 ++++ src/conf/domain_addr.h | 4 +- src/conf/domain_conf.c | 2 + src/conf/domain_conf.h | 1 + src/qemu/qemu_command.c | 1 + src/qemu/qemu_domain.c | 9 ++++ src/qemu/qemu_domain_address.c | 2 + .../bhyvexml2argv-acpiapic.args | 2 +- ...xml2argv-addr-more-than-32-sata-disks.args | 6 +-- ...hyvexml2argv-addr-multiple-sata-disks.args | 4 +- ...vexml2argv-addr-multiple-virtio-disks.args | 6 +-- ...rgv-addr-no32devs-multiple-sata-disks.args | 6 +-- ...l2argv-addr-no32devs-single-sata-disk.args | 4 +- .../bhyvexml2argv-addr-single-sata-disk.args | 4 +- ...bhyvexml2argv-addr-single-virtio-disk.args | 2 +- ...vexml2argv-addr-slot-1-and-31-not-lpc.args | 10 ++++ ...xml2argv-addr-slot-1-and-31-not-lpc.ldargs | 3 ++ ...yvexml2argv-addr-slot-1-and-31-not-lpc.xml | 27 +++++++++++ .../bhyvexml2argv-addr-slot-1-not-lpc.args | 10 ++++ .../bhyvexml2argv-addr-slot-1-not-lpc.ldargs | 3 ++ .../bhyvexml2argv-addr-slot-1-not-lpc.xml | 27 +++++++++++ .../bhyvexml2argvdata/bhyvexml2argv-base.args | 2 +- .../bhyvexml2argv-bhyveload-bootorder.args | 2 +- .../bhyvexml2argv-bhyveload-bootorder1.args | 2 +- .../bhyvexml2argv-bhyveload-bootorder3.args | 2 +- .../bhyvexml2argv-bhyveload-explicitargs.args | 2 +- .../bhyvexml2argv-commandline.args | 2 +- .../bhyvexml2argv-console.args | 2 +- .../bhyvexml2argv-cputopology.args | 2 +- .../bhyvexml2argv-custom-loader.args | 2 +- .../bhyvexml2argv-disk-cdrom-grub.args | 2 +- .../bhyvexml2argv-disk-cdrom.args | 2 +- .../bhyvexml2argv-explicit-lpc.args | 10 ++++ .../bhyvexml2argv-explicit-lpc.ldargs | 3 ++ .../bhyvexml2argv-explicit-lpc.xml | 26 ++++++++++ .../bhyvexml2argv-grub-bootorder.args | 2 +- .../bhyvexml2argv-grub-bootorder2.args | 2 +- .../bhyvexml2argv-grub-defaults.args | 2 +- .../bhyvexml2argv-input-xhci-tablet.args | 4 +- .../bhyvexml2argv-localtime.args | 2 +- .../bhyvexml2argv-macaddr.args | 2 +- .../bhyvexml2argv-net-e1000.args | 2 +- .../bhyvexml2argv-serial-grub-nocons.args | 2 +- .../bhyvexml2argv-serial-grub.args | 2 +- .../bhyvexml2argv-serial.args | 2 +- .../bhyvexml2argvdata/bhyvexml2argv-uefi.args | 4 +- .../bhyvexml2argv-vnc-autoport.args | 4 +- .../bhyvexml2argv-vnc-vgaconf-io.args | 4 +- .../bhyvexml2argv-vnc-vgaconf-off.args | 4 +- .../bhyvexml2argv-vnc-vgaconf-on.args | 4 +- .../bhyvexml2argvdata/bhyvexml2argv-vnc.args | 4 +- .../bhyvexml2argv-wired.args | 2 +- tests/bhyvexml2argvtest.c | 3 ++ .../bhyvexml2xmlout-acpiapic.xml | 2 +- ...ml2xmlout-addr-more-than-32-sata-disks.xml | 6 +-- ...yvexml2xmlout-addr-multiple-sata-disks.xml | 4 +- ...exml2xmlout-addr-multiple-virtio-disks.xml | 6 +-- ...lout-addr-no32devs-multiple-sata-disks.xml | 8 ++-- ...2xmlout-addr-no32devs-single-sata-disk.xml | 4 +- .../bhyvexml2xmlout-addr-single-sata-disk.xml | 4 +- ...hyvexml2xmlout-addr-single-virtio-disk.xml | 2 +- ...exml2xmlout-addr-slot-1-and-31-not-lpc.xml | 36 ++++++++++++++ .../bhyvexml2xmlout-addr-slot-1-not-lpc.xml | 36 ++++++++++++++ .../bhyvexml2xmlout-base.xml | 2 +- .../bhyvexml2xmlout-bhyveload-bootorder.xml | 2 +- .../bhyvexml2xmlout-bhyveload-bootorder1.xml | 2 +- .../bhyvexml2xmlout-bhyveload-bootorder2.xml | 2 +- .../bhyvexml2xmlout-bhyveload-bootorder3.xml | 2 +- .../bhyvexml2xmlout-bhyveload-bootorder4.xml | 2 +- ...bhyvexml2xmlout-bhyveload-explicitargs.xml | 2 +- .../bhyvexml2xmlout-commandline.xml | 2 +- .../bhyvexml2xmlout-console.xml | 3 ++ .../bhyvexml2xmlout-custom-loader.xml | 2 +- .../bhyvexml2xmlout-disk-cdrom-grub.xml | 2 +- .../bhyvexml2xmlout-disk-cdrom.xml | 2 +- .../bhyvexml2xmlout-explicit-lpc.xml | 36 ++++++++++++++ .../bhyvexml2xmlout-grub-bootorder.xml | 2 +- .../bhyvexml2xmlout-grub-bootorder2.xml | 2 +- .../bhyvexml2xmlout-grub-defaults.xml | 2 +- .../bhyvexml2xmlout-input-xhci-tablet.xml | 4 +- .../bhyvexml2xmlout-localtime.xml | 2 +- .../bhyvexml2xmlout-macaddr.xml | 2 +- .../bhyvexml2xmlout-metadata.xml | 4 +- .../bhyvexml2xmlout-serial-grub-nocons.xml | 3 ++ .../bhyvexml2xmlout-serial-grub.xml | 3 ++ .../bhyvexml2xmlout-serial.xml | 3 ++ .../bhyvexml2xmlout-vnc-autoport.xml | 3 ++ .../bhyvexml2xmlout-vnc-vgaconf-io.xml | 3 ++ .../bhyvexml2xmlout-vnc-vgaconf-off.xml | 3 ++ .../bhyvexml2xmlout-vnc-vgaconf-on.xml | 3 ++ .../bhyvexml2xmlout-vnc.xml | 3 ++ .../bhyvexml2xmlout-wired.xml | 2 +- tests/bhyvexml2xmltest.c | 3 ++ 99 files changed, 461 insertions(+), 128 deletions(-) create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-addr-slot-1-and-31-not-lpc.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-addr-slot-1-and-31-not-lpc.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-addr-slot-1-and-31-not-lpc.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-addr-slot-1-not-lpc.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-addr-slot-1-not-lpc.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-addr-slot-1-not-lpc.xml create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-explicit-lpc.args create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-explicit-lpc.ldargs create mode 100644 tests/bhyvexml2argvdata/bhyvexml2argv-explicit-lpc.xml create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-addr-slot-1-and-31-not-lpc.xml create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-addr-slot-1-not-lpc.xml create mode 100644 tests/bhyvexml2xmloutdata/bhyvexml2xmlout-explicit-lpc.xml -- 2.20.1

3 6

[libvirt] [PATCH] virsh: fix return value in storage vol name completor
by Daniel P. Berrangé 11 Feb '19

11 Feb '19

The function must return a pointer, not a boolean. Fortunately 'false' is equivalent to 'NULL' so this bug no had ill effect previously. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- tools/virsh-completer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virsh-completer.c b/tools/virsh-completer.c index e62226fc13..7c68e2e832 100644 --- a/tools/virsh-completer.c +++ b/tools/virsh-completer.c @@ -287,7 +287,7 @@ virshStorageVolNameCompleter(vshControl *ctl, return NULL; if (!(pool = virshCommandOptPool(ctl, cmd, "pool", NULL))) - return false; + return NULL; if ((nvols = virStoragePoolListAllVolumes(pool, &vols, flags)) < 0) goto error; -- 2.20.1

2 1

[libvirt] [python PATCH v4 0/2] Python bindings for virDomainCheckpoint
by Eric Blake 11 Feb '19

11 Feb '19

Python counterpart to: https://www.redhat.com/archives/libvir-list/2019-February/msg00252.html I'll push patch 1 now as a trivial fix; patch 2 can't go in until the corresponding libvirt patches are accepted (which may in turn necessitate minor tweaks if I make any API changes there based on the review). But with this patch, it should be possible to test python bindings to all the proposed C changes. Eric Blake (2): generator.py: typo fix Add virDomainCheckpoint APIs HACKING | 2 + MANIFEST.in | 1 + generator.py | 36 ++++++++-- libvirt-override-api.xml | 12 ++++ libvirt-override-virDomain.py | 13 ++++ libvirt-override-virDomainCheckpoint.py | 19 +++++ libvirt-override.c | 96 +++++++++++++++++++++++++ sanitytest.py | 9 ++- typewrappers.c | 13 ++++ typewrappers.h | 10 +++ 10 files changed, 203 insertions(+), 8 deletions(-) create mode 100644 libvirt-override-virDomainCheckpoint.py -- 2.20.1

2 5

[libvirt] [PATCH v1 1/1] virhostcpu.c: consider empty NUMA nodes in topology validation
by Daniel Henrique Barboza 11 Feb '19

11 Feb '19

Some devices creates empty (= cpu-less) NUMA nodes to host its memory. This results in topologies where the following sanity rule does not apply as is: nodes * sockets * cores * threads = total_cpus As a result, a call to 'virsh nodeinfo' will return the default value (1) to nodes, sockets and threads, while cores defaults to the total_cpus value. For example, in a Power9 host that has 160 total cpus, 4 cpu-less NUMA nodes, 2 populated NUMA nodes, 1 socket per populated node, 20 cores per socket and 4 threads per socket: $ virsh nodeinfo CPU model: ppc64le CPU(s): 160 CPU frequency: 3783 MHz CPU socket(s): 1 Core(s) per socket: 160 Thread(s) per core: 1 NUMA cell(s): 1 Memory size: 535981376 KiB This patch adjusts virHostCPUGetInfoPopulateLinux to count the cpu-less NUMA nodes and discard them in the sanity rule, changing it to: (nodes - empty_nodes) * sockets * cores * threads = total_cpus And with this new rule, virsh nodeinfo will return the appropriate info for those topologies, without changing the behavior for any other scenario it was previously working. This is the resulting output of nodeinfo after this patch in the same Power9 host mentioned above: $ virsh nodeinfo CPU model: ppc64le CPU(s): 160 CPU frequency: 3783 MHz CPU socket(s): 1 Core(s) per socket: 20 Thread(s) per core: 4 NUMA cell(s): 6 Memory size: 535981376 KiB Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com> --- src/util/virhostcpu.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index 6514c3d765..4100cf0e8c 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -598,6 +598,7 @@ virHostCPUGetInfoPopulateLinux(FILE *cpuinfo, virBitmapPtr online_cpus_map = NULL; DIR *nodedir = NULL; struct dirent *nodedirent = NULL; + int emptynodes = 0; int nodecpus, nodecores, nodesockets, nodethreads, offline = 0; int threads_per_subcore = 0; unsigned int node; @@ -686,6 +687,8 @@ virHostCPUGetInfoPopulateLinux(FILE *cpuinfo, VIR_FREE(sysfs_cpudir); *cpus += nodecpus; + if (nodecpus == 0) + emptynodes++; if (nodesockets > *sockets) *sockets = nodesockets; @@ -747,7 +750,7 @@ virHostCPUGetInfoPopulateLinux(FILE *cpuinfo, * the nodeinfo structure isn't designed to carry the full topology so * we're going to lie about the detected topology to notify the user * to check the host capabilities for the actual topology. */ - if ((*nodes * + if (((*nodes - emptynodes) * *sockets * *cores * *threads) != (*cpus + offline)) { -- 2.20.1

3 4

[libvirt] [PATCH 00/15] Make use of autofree within storage code
by John Ferlan 11 Feb '19

11 Feb '19

A tedious series of patches that will make use of the autofree functionality within (many/most) storage modules. As part of the changes I've added a few new AUTOPTR's and made use of existing ones. The diffstat I think shows quite a bit of code removed - mostly in the goto cleanup/error handling that isn't necessary. I've run the series through the Coverity checker with no issues and I've run the Avocado pool and volume tests. The Avocado test did find a couple of issues that were fixed before posting this (assuming a virString on a char ** that was really a counted list managed by VIR_APPEND_ELEMENT - there's a golden egg comment in one module in the middle of the series). John Ferlan (15): util: Introduce VIR_DEFINE_AUTOPTR_FUNC for virStorageAuthDef conf: Introduce VIR_DEFINE_AUTOPTR_FUNC for virStoragePoolSource conf: Introduce VIR_DEFINE_AUTOPTR_FUNC for virStorageVolDef conf: Introduce VIR_DEFINE_AUTOPTR_FUNC for virStoragePoolDef storage: Use VIR_AUTOPTR(virString) storage: Use VIR_AUTOPTR(virCommand) storage: Use VIR_AUTOFREE for storage backends storage: Use VIR_AUTOFREE for storage driver storage: Use VIR_AUTOFREE for storage util conf: Use VIR_AUTOFREE for storage_conf util: Use VIR_AUTOFREE for virstoragefile test: Use VIR_AUTOFREE for test driver tests: Use VIR_AUTOFREE for various storage tests storage: Use VIR_AUTOCLOSE util: Introduce VIR_DEFINE_AUTOPTR_FUNC for virStorageSource src/conf/domain_conf.c | 35 +- src/conf/storage_conf.c | 335 +++++------ src/conf/storage_conf.h | 4 + src/conf/virstorageobj.c | 27 +- src/esx/esx_storage_backend_vmfs.c | 6 +- src/phyp/phyp_driver.c | 6 +- src/qemu/qemu_domain.c | 3 +- src/qemu/qemu_driver.c | 9 +- src/qemu/qemu_migration.c | 3 +- src/qemu/qemu_parse_command.c | 6 +- src/storage/storage_backend.c | 9 +- src/storage/storage_backend_disk.c | 147 ++--- src/storage/storage_backend_fs.c | 59 +- src/storage/storage_backend_gluster.c | 45 +- src/storage/storage_backend_iscsi.c | 76 +-- src/storage/storage_backend_iscsi_direct.c | 62 +-- src/storage/storage_backend_logical.c | 139 ++--- src/storage/storage_backend_mpath.c | 42 +- src/storage/storage_backend_rbd.c | 44 +- src/storage/storage_backend_scsi.c | 65 +-- src/storage/storage_backend_sheepdog.c | 98 ++-- src/storage/storage_backend_vstorage.c | 39 +- src/storage/storage_backend_zfs.c | 77 +-- src/storage/storage_driver.c | 93 ++-- src/storage/storage_file_fs.c | 15 +- src/storage/storage_file_gluster.c | 16 +- src/storage/storage_util.c | 553 +++++++----------- src/test/test_driver.c | 209 +++---- src/util/virstoragefile.c | 615 +++++++++------------ src/util/virstoragefile.h | 2 + src/vbox/vbox_storage.c | 3 +- tests/qemublocktest.c | 6 +- tests/storagebackendsheepdogtest.c | 59 +- tests/storagepoolxml2argvtest.c | 42 +- tests/storagepoolxml2xmltest.c | 36 +- tests/storagevolxml2argvtest.c | 69 +-- tests/storagevolxml2xmltest.c | 44 +- tests/virstoragetest.c | 111 ++-- tests/virstorageutiltest.c | 7 +- 39 files changed, 1189 insertions(+), 2027 deletions(-) -- 2.20.1

4 49

[libvirt] [PATCH 0/4] libxl: override HAVE_PVUSB in test suite
by Cole Robinson 11 Feb '19

11 Feb '19

There's two different domain capabilities test cases for libxl, depending on whether host libxl supports PVUSB or not. This causes pain when extending domain capabilities XML, because at least one file always needs to be updated by hand. This series adds a wrapper function for checking PVUSB, and adjusts the libxl driver to use it when building domaincapabilities output. We then mock the new function in the test suite to always return true, and ditch the !PVUSB test cases Cole Robinson (4): tests: Rename virmocklibxl.c -> libxlmock.c tests: Create a shared library with libxl driver libxl: Break out libxlCapsHasPVUSB tests: domcaps: Remove dependency on libxl PVUSB support src/libxl/libxl_capabilities.c | 16 +++- src/libxl/libxl_capabilities.h | 1 + tests/Makefile.am | 22 +++--- tests/domaincapsmock.c | 11 +++ .../domaincapsschemadata/libxl-xenfv-usb.xml | 78 ------------------- tests/domaincapsschemadata/libxl-xenfv.xml | 1 + .../domaincapsschemadata/libxl-xenpv-usb.xml | 68 ---------------- tests/domaincapsschemadata/libxl-xenpv.xml | 1 + tests/domaincapstest.c | 12 +-- tests/{virmocklibxl.c => libxlmock.c} | 2 +- tests/libxlxml2domconfigtest.c | 2 +- 11 files changed, 43 insertions(+), 171 deletions(-) delete mode 100644 tests/domaincapsschemadata/libxl-xenfv-usb.xml delete mode 100644 tests/domaincapsschemadata/libxl-xenpv-usb.xml rename tests/{virmocklibxl.c => libxlmock.c} (98%) -- 2.20.1

2 5

[libvirt] [PATCH 0/9] rpc: make client streams multi-thread safer
by Nikolay Shirokovskiy 11 Feb '19

11 Feb '19

Nikolay Shirokovskiy (9): rpc: fix race on stream abort/finish and server side abort rpc: use single function to send stream messages rpc: remove unused virNetClientSendNoReply rpc: fix propagation of errors from server rpc: add mising locking in virNetClientStreamRecvHole rpc: client: incapsulate error checks rpc: client: don't set incomingEOF on errors rpc: client stream: dispose private data on stream dispose rpc: client: stream: fix multi thread abort/finish src/datatypes.c | 2 + src/datatypes.h | 1 + src/libvirt_remote.syms | 6 +- src/remote/remote_driver.c | 27 ++------ src/rpc/gendispatch.pl | 3 +- src/rpc/virnetclient.c | 146 ++++++++++++++++++++++--------------------- src/rpc/virnetclient.h | 6 +- src/rpc/virnetclientstream.c | 110 ++++++++++++++++++++++++-------- src/rpc/virnetclientstream.h | 17 ++++- 9 files changed, 188 insertions(+), 130 deletions(-) -- 1.8.3.1

2 14

[libvirt] [PATCH 0/8] qemu: Add support for setting post-copy migration bandwidth
by Jiri Denemark 09 Feb '19

09 Feb '19

This series adds a new VIR_MIGRATE_PARAM_BANDWIDTH_POSTCOPY typed parameter for virDomainMigrate3 and virDomainMigrateToURI3 for setting maximum post-copy migration bandwidth. In case the initial VIR_MIGRATE_PARAM_BANDWIDTH_POSTCOPY value turns out to be suboptimal a new VIR_DOMAIN_MIGRATE_MAX_SPEED_POSTCOPY flag for virDomainMigrateSetMaxSpeed and virDomainMigrateGetMaxSpeed may be used to set/get the maximum post-copy migration bandwidth while migration is already running. Jiri Denemark (8): qemu: Use C99 initializers for qemuMigrationParamsTPMap qemu: Add optional unit to qemuMigrationParamsTPMapItem qemu: Rework qemuDomainMigrateSetMaxSpeed qemu: Make migration params usable outside migration Public API for post-copy migration bandwidth qemu: Implement VIR_MIGRATE_PARAM_BANDWIDTH_POSTCOPY qemu: Implement VIR_DOMAIN_MIGRATE_MAX_SPEED_POSTCOPY flag virsh: Add support for setting post-copy migration bandwidth include/libvirt/libvirt-domain.h | 15 ++++ src/libvirt-domain.c | 11 ++- src/qemu/qemu_driver.c | 118 +++++++++++++++++++++++------- src/qemu/qemu_migration.h | 1 + src/qemu/qemu_migration_params.c | 122 +++++++++++++++++++++++-------- src/qemu/qemu_migration_params.h | 10 +++ tools/virsh-domain.c | 33 ++++++++- tools/virsh.pod | 15 +++- 8 files changed, 260 insertions(+), 65 deletions(-) -- 2.20.1

3 19

[libvirt] [PATCH 0/2] A couple of capabilities related adjustments
by John Ferlan 08 Feb '19

08 Feb '19

Peeling the onion in my series to update the QEMU capabilites replies: https://www.redhat.com/archives/libvir-list/2019-January/msg00793.html resulted in consideration of a possible alternative to how the SEV capability checking "works". As it turns out, the initial changes "massaged" the .replies output to add a "fake" reply on an Intel CPU for what amounts to AMD specific output. This naturally resulted in a "problem" when the next batch of a capabilites was created and there was no sev output, so an adjustment was made to limit what was tested to one capabilities version. Since there isn't separate Intel/AMD x86_64 output, the first patch in the series will alter the return for virQEMUCapsProbeQMPSEVCapabilities so that 0 would "change" into 1 for the mocked environment and allow the sev-guest bit to be set which allows QEMU_CAPS_SEV_GUEST to be set for any x86_64 arch environment. This only affects how qemuxml2argvtest handles generation of DO_TEST_CAPS_LATEST for launch-security-sev. The XML generated isn't modified, nor is the reply output data since that's separate. The key is the "0" return meaning a GenericError which is assumed to be returned when compiled-in support for SEV isn't there, but *could* be if the underlying hardware arch supported it. For the test purpose we have, that doesn't matter unless someone wants to go through the trouble of separating the caps*.replies files into "Intel" and "AMD" specific output. So yes a "workaround" of sorts, but nonetheless an alternative to the current static checking of what's been deemed incorrect reply data. The second somewhat unrelated patch is fallout of the review discussion about having a consistent process. I suspect it's a "starting point" from which we can evolve to create a consistent/repeatable process to create caps*.replies. John Ferlan (2): tests: Add mocking for qemuMonitorJSONGetSEVCapabilities tests: Document procedure to build QEMU for *.replies generation tests/qemucapabilitiestest.c | 34 ++++++++++++- tests/qemucapsprobemock.c | 50 +++++++++++++++++++ ...=> launch-security-sev.x86_64-latest.args} | 0 tests/qemuxml2argvtest.c | 2 +- 4 files changed, 83 insertions(+), 3 deletions(-) rename tests/qemuxml2argvdata/{launch-security-sev.x86_64-2.12.0.args => launch-security-sev.x86_64-latest.args} (100%) -- 2.20.1

4 8

[libvirt] [PATCH] docs: storage: owner/group default to libvirtd UID/GID
by Cole Robinson 08 Feb '19

08 Feb '19

Commit fafcc818f changed the docs to say that when creating a pool directory or file volume with no owner/group specified, they will be inherited from the parent directory. This isn't correct now and doesn't seem to have ever been correct In reality default owner/group is whatever UID/GID libvirtd is running as Signed-off-by: Cole Robinson <crobinso(a)redhat.com> --- docs/formatstorage.html.in | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/formatstorage.html.in b/docs/formatstorage.html.in index 6ebd23549f..968651330f 100644 --- a/docs/formatstorage.html.in +++ b/docs/formatstorage.html.in @@ -478,8 +478,8 @@ The <code>owner</code> element contains the numeric user ID. The <code>group</code> element contains the numeric group ID. If <code>owner</code> or <code>group</code> aren't specified when - creating a directory, the values are inherited from the parent - directory. The <code>label</code> element contains the MAC (eg SELinux) + creating a directory, the UID and GID of the libvirtd process are used. + The <code>label</code> element contains the MAC (eg SELinux) label string. <span class="since">Since 0.4.1</span> For running directory or filesystem based pools, these fields @@ -776,8 +776,8 @@ The <code>owner</code> element contains the numeric user ID. The <code>group</code> element contains the numeric group ID. If <code>owner</code> or <code>group</code> aren't specified when - creating a supported volume, the values are inherited from the parent - directory. The <code>label</code> element contains the MAC (eg SELinux) + creating a supported volume, the UID and GID of the libvirtd process + are used. The <code>label</code> element contains the MAC (eg SELinux) label string. For existing directory or filesystem based volumes, these fields will be filled with the values used by the existing file. -- 2.20.1

2 1