- Devel - libvirt List Archives

[libvirt] [RFC PATCH 0/9] qemu: add vhost-vsock-pci support
by Ján Tomko 01 Jun '18

01 Jun '18

@Stefan, please take a look at the docs/ changes in patch 6 Add <interface type='vsock'>, mapping to vhost-vsock-pci Missing: hotplug support Similar to vhost-net, we cannot apply a SELinux label on the file descriptor, so an adjustment of the policy will probably be needed to make it work in enforcing mode. https://bugzilla.redhat.com/show_bug.cgi?id=1291851 Ján Tomko (9): conf: split interface target element condition qemu: prepare for missing interface model Introduce virDomainNetDefNew Add privateData to virDomainNetDef qemu: add private data for interfaces conf: add interface type vsock Introduce QEMU_CAPS_DEVICE_VHOST_VSOCK Introduce virNetDevVsockSetGuestCid qemu: implement vhost-vsock-pci support configure.ac | 8 ++ docs/formatdomain.html.in | 15 ++++ docs/schemas/domaincommon.rng | 14 ++++ src/bhyve/bhyve_parse_command.c | 2 +- src/conf/domain_conf.c | 85 ++++++++++++++++++---- src/conf/domain_conf.h | 8 ++ src/conf/netdev_bandwidth_conf.h | 1 + src/libvirt_private.syms | 2 + src/libxl/libxl_conf.c | 1 + src/lxc/lxc_controller.c | 1 + src/lxc/lxc_driver.c | 3 + src/lxc/lxc_process.c | 1 + src/openvz/openvz_conf.c | 4 +- src/qemu/qemu_capabilities.c | 3 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 43 +++++++++-- src/qemu/qemu_domain.c | 47 ++++++++++++ src/qemu/qemu_domain.h | 13 ++++ src/qemu/qemu_domain_address.c | 6 +- src/qemu/qemu_hotplug.c | 3 + src/qemu/qemu_interface.c | 33 +++++++++ src/qemu/qemu_interface.h | 4 + src/qemu/qemu_parse_command.c | 2 +- src/qemu/qemu_process.c | 6 ++ src/uml/uml_conf.c | 5 ++ src/util/virnetdev.c | 30 ++++++++ src/util/virnetdev.h | 4 + src/vbox/vbox_common.c | 2 +- src/vmx/vmx.c | 3 +- src/xenconfig/xen_common.c | 3 +- src/xenconfig/xen_sxpr.c | 3 +- tests/qemucapabilitiesdata/caps_2.10.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 1 + tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 1 + .../vhost-vsock.x86_64-latest.args | 32 ++++++++ tests/qemuxml2argvdata/vhost-vsock.xml | 36 +++++++++ tests/qemuxml2argvtest.c | 15 ++++ tests/qemuxml2xmloutdata/vhost-vsock.xml | 1 + tests/qemuxml2xmltest.c | 2 + tools/virsh-domain.c | 1 + 51 files changed, 425 insertions(+), 32 deletions(-) create mode 100644 tests/qemuxml2argvdata/vhost-vsock.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/vhost-vsock.xml create mode 120000 tests/qemuxml2xmloutdata/vhost-vsock.xml -- 2.16.1

2 12

[libvirt] [PATCH] util: storage: remove virStorageSource->tlsVerify
by Peter Krempa 01 Jun '18

01 Jun '18

Disks are client-only so we don't need to have this variable. We also always pass false for 'isListen' to qemuBuildTLSx509BackendProps for all disk-related code-paths. --- This applies on top of my branch collecting all ACKed postings of recent blockdev-related work. Current version can be fetched by: git fetch git://pipo.sk/pipo/libvirt.git blockdev-staging src/qemu/qemu_command.c | 2 +- src/qemu/qemu_domain.c | 2 -- src/qemu/qemu_hotplug.c | 3 +-- src/util/virstoragefile.c | 1 - src/util/virstoragefile.h | 1 - 5 files changed, 2 insertions(+), 7 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 26e61f26f4..c75595ca6d 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -774,7 +774,7 @@ qemuBuildDiskSrcTLSx509CommandLine(virCommandPtr cmd, return 0; return qemuBuildTLSx509CommandLine(cmd, src->tlsCertdir, - false, src->tlsVerify, + false, true, NULL, src->tlsAlias, qemuCaps); } diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 4368e9be35..873bcec50d 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -9928,8 +9928,6 @@ qemuProcessPrepareStorageSourceTLSVxhs(virStorageSourcePtr src, if (src->haveTLS == VIR_TRISTATE_BOOL_YES) { if (VIR_STRDUP(src->tlsCertdir, cfg->vxhsTLSx509certdir) < 0) return -1; - - src->tlsVerify = true; } return 0; diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index c656409eaa..2f76c048aa 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -164,8 +164,7 @@ qemuDomainAddDiskSrcTLSObject(virQEMUDriverPtr driver, if (qemuDomainGetTLSObjects(priv->qemuCaps, NULL, src->tlsCertdir, - false, - src->tlsVerify, + false, true, src->tlsAlias, &tlsProps, NULL) < 0) goto cleanup; diff --git a/src/util/virstoragefile.c b/src/util/virstoragefile.c index 54de2c1c30..10fe0f201a 100644 --- a/src/util/virstoragefile.c +++ b/src/util/virstoragefile.c @@ -2171,7 +2171,6 @@ virStorageSourceCopy(const virStorageSource *src, ret->shared = src->shared; ret->haveTLS = src->haveTLS; ret->tlsFromConfig = src->tlsFromConfig; - ret->tlsVerify = src->tlsVerify; ret->detected = src->detected; ret->debugLevel = src->debugLevel; ret->debug = src->debug; diff --git a/src/util/virstoragefile.h b/src/util/virstoragefile.h index 1631c4cf66..4591e6e213 100644 --- a/src/util/virstoragefile.h +++ b/src/util/virstoragefile.h @@ -310,7 +310,6 @@ struct _virStorageSource { * certificate directory with listen and verify bools. */ char *tlsAlias; char *tlsCertdir; - bool tlsVerify; bool detected; /* true if this entry was not provided by the user */ -- 2.16.2

2 1

[libvirt] [RFC PATCH 0/9] tests: Record commands used to gather capability replies
by Peter Krempa 01 Jun '18

01 Jun '18

De-confusify the 'replies' files for human usage by recording which commands were used for gathering given block. Additionally this tests that the commands emitted by libvirt are as recorded. This series is in RFC state, since it creates some churn in the capability files and also 'tests/qemucapsfixreplies' will no longer work. Patch 8 contains the changed files for ease of review and patch 9 contains the tool used to regenerate them from the current state. Peter Krempa (9): qemu: monitor: Add possibility to reset command sequence in tests tests: qemumonitor: Simplify handling of end of file in full file test tests: qemumonitor: Optimize control flow when concatenating replies tests: qemucapsprobemock: Simplify and extract skipping of empty lines tests: qemucapsprobemock: Fail if JSON reply from qemu can't be reformatted tests: qemucapsprobemock: Prepare 'qemucapsprobe' for the new format tests: qemucapabilities: Test commands used to query capabilities FIXUP: Tweak capability files to conform to the new approach DO_NOT_APPLY: HACK: Regenerate qemucapabilitiestest data fix-files.sh | 1 + src/qemu/qemu_monitor.c | 11 + src/qemu/qemu_monitor_priv.h | 31 + tests/Makefile.am | 1 + .../qemucapabilitiesdata/caps_1.5.3.x86_64.replies | 317 +++++- tests/qemucapabilitiesdata/caps_1.5.3.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_1.6.0.x86_64.replies | 317 +++++- tests/qemucapabilitiesdata/caps_1.6.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_1.7.0.x86_64.replies | 317 +++++- tests/qemucapabilitiesdata/caps_1.7.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.1.1.x86_64.replies | 317 +++++- tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml | 2 +- .../caps_2.10.0.aarch64.replies | 319 +++++- tests/qemucapabilitiesdata/caps_2.10.0.aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_2.10.0.ppc64.replies | 322 +++++- tests/qemucapabilitiesdata/caps_2.10.0.ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_2.10.0.s390x.replies | 342 +++++- tests/qemucapabilitiesdata/caps_2.10.0.s390x.xml | 2 +- .../caps_2.10.0.x86_64.replies | 1120 ++++++++++++++++++- tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.11.0.s390x.replies | 350 +++++- tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml | 2 +- .../caps_2.12.0.aarch64.replies | 328 +++++- tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_2.12.0.ppc64.replies | 331 +++++- tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_2.12.0.s390x.replies | 358 +++++- tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 2 +- .../caps_2.12.0.x86_64.replies | 1173 +++++++++++++++++++- tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.4.0.x86_64.replies | 341 +++++- tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.5.0.x86_64.replies | 346 +++++- tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 2 +- .../caps_2.6.0.aarch64.replies | 319 +++++- tests/qemucapabilitiesdata/caps_2.6.0.aarch64.xml | 2 +- .../qemucapabilitiesdata/caps_2.6.0.ppc64.replies | 322 +++++- tests/qemucapabilitiesdata/caps_2.6.0.ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_2.6.0.x86_64.replies | 346 +++++- tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.7.0.s390x.replies | 306 ++++- tests/qemucapabilitiesdata/caps_2.7.0.s390x.xml | 2 +- .../qemucapabilitiesdata/caps_2.7.0.x86_64.replies | 346 +++++- tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.8.0.s390x.replies | 342 +++++- tests/qemucapabilitiesdata/caps_2.8.0.s390x.xml | 2 +- .../qemucapabilitiesdata/caps_2.8.0.x86_64.replies | 346 +++++- tests/qemucapabilitiesdata/caps_2.8.0.x86_64.xml | 2 +- .../qemucapabilitiesdata/caps_2.9.0.ppc64.replies | 322 +++++- tests/qemucapabilitiesdata/caps_2.9.0.ppc64.xml | 2 +- .../qemucapabilitiesdata/caps_2.9.0.s390x.replies | 342 +++++- tests/qemucapabilitiesdata/caps_2.9.0.s390x.xml | 2 +- .../qemucapabilitiesdata/caps_2.9.0.x86_64.replies | 1120 ++++++++++++++++++- tests/qemucapabilitiesdata/caps_2.9.0.x86_64.xml | 2 +- tests/qemucapabilitiestest.c | 17 +- tests/qemucapsprobemock.c | 77 +- tests/qemumonitortestutils.c | 52 +- 57 files changed, 10564 insertions(+), 385 deletions(-) create mode 100755 fix-files.sh create mode 100644 src/qemu/qemu_monitor_priv.h -- 2.16.2

1 10

[libvirt] Why does vnc show blackscreen after using mstsc to connect to a windows vm with a nvidia gpu passtrough
by Wu Zongyong 01 Jun '18

01 Jun '18

Hi, As the title says, VNC inside a windows virtual machine doesn’t work after I try to use mstsc to access the vm with a gpu passthrough. It seems that the scenario is normal, but could someone tell me something deeply about the reason why vnc shows blackscreen? Thanks.

1 0

[libvirt] Question about using cpu mode "host-model" while providing a cpu model name
by Collin Walling 31 May '18

31 May '18

Hi I have noticed something that may be misconstrued regarding the libvirt domain xml format for defining a cpu model. There seems to be a misalignment where the libvirt documentation states something that is not supported, but libvirt itself gives no clear indication of such. This is regarding the cpu mode "host-model" and providing a cpu model name between the <model> tags. >From the libvirt docs under header "CPU model and topology" paragraph "cpu" subparagraph "host-model", the following rule is defined (bolded or between asterisks): "... The match attribute can't be used in this mode. *Specifying CPU model is not supported* either, but model's fallback attribute may still be used. ..." https://libvirt.org/formatdomain.html#elementsCPU The above rule reads as "if mode is 'host-model' (and the architecture is not PowerPC) then specifying a model name should not be allowed". However, this is not the observed behavior. For example, I can define and start a guest with the following xml snippet without any issues: <cpu mode='host-model'> <model>cpu-name</model> </cpu> Which seems to contradict what the documentation states. This issue was reported by a colleague of mine who was confused by the cpu features that were available to a guest when host-model and a model name are provided. Personally, I tend to err on the side of providing host-model and a cpu-model-name being mutually exclusive. I've attempted to find a solution to this problem myself by looking at virCPUDefParseXML, but the fact that PowerPC exists as an exception and we do not know the architecture when parsing a guest cpu xml makes minimal code changes challenging. If we want to make changes to the code, then I imagine that the ideal solution would revolve around only allowing <model>cpu-name</model> to be valid iff the cpu mode is set to "custom". Otherwise some clarity on the documentation would suffice. Something like "A CPU model specified in the domain xml will be ignored." Thoughts? Thank you for your time. -- Respectfully, - Collin Walling

5 6

[libvirt] [python PATCH] Add support for virConnectBaselineHypervisorCPU
by Jiri Denemark 31 May '18

31 May '18

The python bindings for this API cannot be generated because are generator is not capable of handling string arrays (char **) parameters. https://bugzilla.redhat.com/show_bug.cgi?id=1584676 Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- generator.py | 1 + libvirt-override-api.xml | 11 ++++++++ libvirt-override.c | 60 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 72 insertions(+) diff --git a/generator.py b/generator.py index a0fc720..b7d96a1 100755 --- a/generator.py +++ b/generator.py @@ -488,6 +488,7 @@ skip_impl = ( 'virDomainGetPerfEvents', 'virDomainSetPerfEvents', 'virDomainGetGuestVcpus', + 'virConnectBaselineHypervisorCPU', ) lxc_skip_impl = ( diff --git a/libvirt-override-api.xml b/libvirt-override-api.xml index b63a403..36d3577 100644 --- a/libvirt-override-api.xml +++ b/libvirt-override-api.xml @@ -717,5 +717,16 @@ <arg name='flags' type='unsigned int' info='extra flags; not used yet, so callers should always pass 0'/> <return type='int' info="dictionary of vcpu data returned by the guest agent"/> </function> + <function name='virConnectBaselineHypervisorCPU' file='python'> + <info>Computes the most feature-rich CPU which is compatible with all given CPUs and can be provided by the specified hypervisor.</info> + <return type='char *' info='XML description of the computed CPU or NULL on error.'/> + <arg name='conn' type='virConnectPtr' info='pointer to the hypervisor connection'/> + <arg name='emulator' type='const char *' info='path to the emulator binary'/> + <arg name='arch' type='const char *' info='CPU architecture'/> + <arg name='machine' type='const char *' info='machine type'/> + <arg name='virttype' type='const char *' info='virtualization type'/> + <arg name='xmlCPUs' type='const char **' info='array of XML descriptions of CPUs'/> + <arg name='flags' type='unsigned int' info='bitwise-OR of virConnectBaselineCPUFlags'/> + </function> </symbols> </api> diff --git a/libvirt-override.c b/libvirt-override.c index b4c1529..1c95c18 100644 --- a/libvirt-override.c +++ b/libvirt-override.c @@ -9708,6 +9708,63 @@ libvirt_virStreamRecvFlags(PyObject *self ATTRIBUTE_UNUSED, #endif /* LIBVIR_CHECK_VERSION(3, 4, 0) */ +#if LIBVIR_CHECK_VERSION(4, 4, 0) +static PyObject * +libvirt_virConnectBaselineHypervisorCPU(PyObject *self ATTRIBUTE_UNUSED, + PyObject *args) +{ + virConnectPtr conn; + PyObject *pyobj_conn; + char *emulator; + char *arch; + char *machine; + char *virttype; + PyObject *list; + unsigned int flags; + char **xmlCPUs = NULL; + int ncpus = 0; + size_t i; + char *cpu; + PyObject *ret = NULL; + + if (!PyArg_ParseTuple(args, (char *)"OzzzzOI:virConnectBaselineHypervisorCPU", + &pyobj_conn, &emulator, &arch, &machine, &virttype, + &list, &flags)) + return NULL; + + conn = (virConnectPtr) PyvirConnect_Get(pyobj_conn); + + if (PyList_Check(list)) { + ncpus = PyList_Size(list); + if (VIR_ALLOC_N(xmlCPUs, ncpus) < 0) + return PyErr_NoMemory(); + + for (i = 0; i < ncpus; i++) { + if (libvirt_charPtrUnwrap(PyList_GetItem(list, i), + &(xmlCPUs[i])) < 0 || + !xmlCPUs[i]) + goto cleanup; + } + } + + LIBVIRT_BEGIN_ALLOW_THREADS; + cpu = virConnectBaselineHypervisorCPU(conn, emulator, arch, machine, virttype, + (const char **)xmlCPUs, ncpus, flags); + LIBVIRT_END_ALLOW_THREADS; + + ret = libvirt_constcharPtrWrap(cpu); + + cleanup: + for (i = 0; i < ncpus; i++) + VIR_FREE(xmlCPUs[i]); + VIR_FREE(xmlCPUs); + VIR_FREE(cpu); + + return ret; +} +#endif /* LIBVIR_CHECK_VERSION(4, 4, 0) */ + + /************************************************************************ * * * The registration stuff * @@ -9941,6 +9998,9 @@ static PyMethodDef libvirtMethods[] = { {(char *) "virStreamSendHole", libvirt_virStreamSendHole, METH_VARARGS, NULL}, {(char *) "virStreamRecvFlags", libvirt_virStreamRecvFlags, METH_VARARGS, NULL}, #endif /* LIBVIR_CHECK_VERSION(3, 4, 0) */ +#if LIBVIR_CHECK_VERSION(4, 4, 0) + {(char *) "virConnectBaselineHypervisorCPU", libvirt_virConnectBaselineHypervisorCPU, METH_VARARGS, NULL}, +#endif /* LIBVIR_CHECK_VERSION(4, 4, 0) */ {NULL, NULL, 0, NULL} }; -- 2.17.0

2 1

[libvirt] [PATCH 00/13] qemu: Refactor how we handle 'object's on the monitor
by Peter Krempa 31 May '18

31 May '18

This applies on top of the tls/secret alias refactoring series I've posted earlier today: https://www.redhat.com/archives/libvir-list/2018-May/msg02174.html The main idea is to clarify the lifecycle of the objects used on the monitor and clean up the code using it. Peter Krempa (13): qemu: command: Fix name of qemuBuildMemoryBackendStr qemu: monitor: Rename qemuMonitorAddObject to qemuMonitorAddObjectType qemu: Rename virQEMUBuildObjectCommandlineFromJSON qemu: monitor: Add better APIs for adding of objects to qemu util: qemu: Introduce helper for formatting command line from new object props qemu: hotplug: Refactor PR props formatting to use qemuMonitorCreateObjectProps qemu: hotplug: Refactor RNG props formatting to use qemuMonitorCreateObjectProps qemu: hotplug: Refactor memory props formatting to qemuMonitorCreateObjectProps qemu: hotplug: Refactor shmem props formatting to qemuMonitorCreateObjectProps qemu: hotplug: Refactor tls-credential props formatting to qemuMonitorCreateObjectProps qemu: hotplug: Refactor 'secret' props formatting to qemuMonitorCreateObjectProps qemu: Convert iothread hotplug to qemuMonitorCreateObjectProps qemu: Delete old unused code for adding objects to qemu src/qemu/qemu_command.c | 300 +++++++++++++++++---------------------- src/qemu/qemu_command.h | 18 +-- src/qemu/qemu_driver.c | 14 +- src/qemu/qemu_hotplug.c | 148 +++++++------------ src/qemu/qemu_hotplug.h | 3 +- src/qemu/qemu_migration_params.c | 5 +- src/qemu/qemu_monitor.c | 98 +++++++++++-- src/qemu/qemu_monitor.h | 14 +- src/qemu/qemu_monitor_json.c | 15 +- src/qemu/qemu_monitor_json.h | 2 - src/util/virqemu.c | 40 ++++-- src/util/virqemu.h | 5 +- 12 files changed, 336 insertions(+), 326 deletions(-) -- 2.16.2

2 26

[libvirt] [PATCH v3 0/4] capabilities: Provide info about host IOMMU
by Filip Alac 31 May '18

31 May '18

Filip Alac (4): virutil: Introduce virHostHasIOMMU qemu: hostdev: Refactor code capabilities: Extend capabilities with iommu_support docs: news: Explain iommu_support improvement docs/news.xml | 8 +++++ docs/schemas/capability.rng | 13 +++++++++ src/conf/capabilities.c | 9 ++++++ src/conf/capabilities.h | 3 ++ src/libvirt_private.syms | 2 ++ src/qemu/qemu_capabilities.c | 3 ++ src/qemu/qemu_hostdev.c | 29 +++---------------- src/test/test_driver.c | 2 ++ src/util/virutil.c | 28 ++++++++++++++++++ src/util/virutil.h | 2 ++ tests/qemucaps2xmldata/all_1.6.0-1.xml | 1 + .../nodisksnapshot_1.6.0-1.xml | 1 + .../vircaps2xmldata/vircaps-aarch64-basic.xml | 1 + .../vircaps2xmldata/vircaps-x86_64-basic.xml | 1 + .../vircaps2xmldata/vircaps-x86_64-caches.xml | 1 + .../vircaps-x86_64-resctrl-cdp.xml | 1 + .../vircaps-x86_64-resctrl-skx-twocaches.xml | 1 + .../vircaps-x86_64-resctrl-skx.xml | 1 + .../vircaps-x86_64-resctrl.xml | 1 + 19 files changed, 83 insertions(+), 25 deletions(-) -- 2.17.0

2 7

[libvirt] [PATCH] qemu: hotplug: Fix detach of disk with managed persistent reservations
by Peter Krempa 31 May '18

31 May '18

In commit 8bebb2b735d I've refactored how the detach of disk with a managed persistent reservations object is handled. After the commit if any disk with a managed PR object would be removed libvirt would also attempt to remove the shared 'pr-manager-helper' object potentially used by other disks. Thankfully this should not have practical impact as qemu should reject deletion of the object if it was still used and the rest of the code is correct. Fix this by removing the disk from the definition earlier and checking if the shared/managed pr-manager-helper object is still needed. This basically splits the detach code for the managed PR object from the unmanaged ones. The same separation will follow for the attachment code as well as it greatly simplifies -blockdev support for this. Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- src/qemu/qemu_hotplug.c | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index b4bbe62c75..a14281203a 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -3839,6 +3839,8 @@ qemuDomainRemoveDiskDevice(virQEMUDriverPtr driver, char *drivestr; char *objAlias = NULL; char *encAlias = NULL; + bool prManaged = priv->prDaemonRunning; + bool prUsed = false; VIR_DEBUG("Removing disk %s from domain %p %s", disk->info.alias, vm, vm->def->name); @@ -3876,6 +3878,16 @@ qemuDomainRemoveDiskDevice(virQEMUDriverPtr driver, } } + for (i = 0; i < vm->def->ndisks; i++) { + if (vm->def->disks[i] == disk) { + virDomainDiskRemove(vm->def, i); + break; + } + } + + /* check if the last disk with managed PR was just removed */ + prUsed = virDomainDefHasManagedPR(vm->def); + qemuDomainObjEnterMonitor(driver, vm); qemuMonitorDriveDel(priv->mon, drivestr); @@ -3892,12 +3904,16 @@ qemuDomainRemoveDiskDevice(virQEMUDriverPtr driver, VIR_FREE(encAlias); /* If it fails, then so be it - it was a best shot */ - if (disk->src->pr) + if (disk->src->pr && + !virStoragePRDefIsManaged(disk->src->pr)) ignore_value(qemuMonitorDelObject(priv->mon, disk->src->pr->mgralias)); if (disk->src->haveTLS) ignore_value(qemuMonitorDelObject(priv->mon, disk->src->tlsAlias)); + if (prManaged && !prUsed) + ignore_value(qemuMonitorDelObject(priv->mon, qemuDomainGetManagedPRAlias())); + if (qemuDomainObjExitMonitor(driver, vm) < 0) return -1; @@ -3906,16 +3922,7 @@ qemuDomainRemoveDiskDevice(virQEMUDriverPtr driver, event = virDomainEventDeviceRemovedNewFromObj(vm, disk->info.alias); qemuDomainEventQueue(driver, event); - for (i = 0; i < vm->def->ndisks; i++) { - if (vm->def->disks[i] == disk) { - virDomainDiskRemove(vm->def, i); - break; - } - } - - /* check if the last disk with managed PR was just removed */ - if (priv->prDaemonRunning && - !virDomainDefHasManagedPR(vm->def)) + if (prManaged && !prUsed) qemuProcessKillManagedPRDaemon(vm); qemuDomainReleaseDeviceAddress(vm, &disk->info, src); -- 2.16.2

2 1

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

31 May '18

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

3 10