December 2020 - Devel - libvirt List Archives

[PATCH v2] qemu: Don't cache NUMA caps
by Michal Privoznik 02 Dec '20

02 Dec '20

In v6.0.0-rc1~439 (and friends) we tried to cache NUMA capabilities because we assumed they are immutable. And to some extent they are (NUMA hotplug is not a thing, is it). However, our capabilities contain also some runtime info that can change, e.g. hugepages pool allocation sizes or total amount of memory per node (host side memory hotplug might change the value). Because of the caching we might not be reporting the correct runtime info in 'virsh capabilities'. The NUMA caps are used in three places: 1) 'virsh capabilities' 2) domain startup, when parsing numad reply 3) parsing domain private data XML In cases 2) and 3) we need NUMA caps to construct list of physical CPUs that belong to NUMA nodes from numad reply. And while this may seem static, it's not really because of possible CPU hotplug on physical host. There are two possible approaches: 1) build a validation mechanism that would invalidate the cached NUMA caps, or 2) drop the caching and construct NUMA caps from scratch on each use. In this commit, the latter approach is implemented, because it's easier. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1819058 Fixes: 1a1d848694f6c2f1d98a371124928375bc3bb4a3 Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- v2 of: https://www.redhat.com/archives/libvir-list/2020-December/msg00023.html diff to v1: - instead of fixing cached capabilities, drop caching completely src/qemu/qemu_conf.c | 23 +---------------------- src/qemu/qemu_conf.h | 6 ------ src/qemu/qemu_domain.c | 7 +++---- src/qemu/qemu_driver.c | 1 - src/qemu/qemu_process.c | 7 +++---- 5 files changed, 7 insertions(+), 37 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index cbdde0c0dc..0ae86e5468 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -1289,27 +1289,6 @@ virQEMUDriverCreateXMLConf(virQEMUDriverPtr driver, } -virCapsHostNUMAPtr -virQEMUDriverGetHostNUMACaps(virQEMUDriverPtr driver) -{ - virCapsHostNUMAPtr hostnuma; - - qemuDriverLock(driver); - - if (!driver->hostnuma) - driver->hostnuma = virCapabilitiesHostNUMANewHost(); - - hostnuma = driver->hostnuma; - - qemuDriverUnlock(driver); - - if (hostnuma) - virCapabilitiesHostNUMARef(hostnuma); - - return hostnuma; -} - - virCPUDefPtr virQEMUDriverGetHostCPU(virQEMUDriverPtr driver) { @@ -1381,7 +1360,7 @@ virCapsPtr virQEMUDriverCreateCapabilities(virQEMUDriverPtr driver) "DOI \"%s\"", model, doi); } - caps->host.numa = virQEMUDriverGetHostNUMACaps(driver); + caps->host.numa = virCapabilitiesHostNUMANewHost(); caps->host.cpu = virQEMUDriverGetHostCPU(driver); return g_steal_pointer(&caps); } diff --git a/src/qemu/qemu_conf.h b/src/qemu/qemu_conf.h index 411d08db36..7025b5222e 100644 --- a/src/qemu/qemu_conf.h +++ b/src/qemu/qemu_conf.h @@ -270,11 +270,6 @@ struct _virQEMUDriver { */ virCapsPtr caps; - /* Lazy initialized on first use, immutable thereafter. - * Require lock to get the pointer & do optional initialization - */ - virCapsHostNUMAPtr hostnuma; - /* Lazy initialized on first use, immutable thereafter. * Require lock to get the pointer & do optional initialization */ @@ -337,7 +332,6 @@ virQEMUDriverConfigSetDefaults(virQEMUDriverConfigPtr cfg); virQEMUDriverConfigPtr virQEMUDriverGetConfig(virQEMUDriverPtr driver); -virCapsHostNUMAPtr virQEMUDriverGetHostNUMACaps(virQEMUDriverPtr driver); virCPUDefPtr virQEMUDriverGetHostCPU(virQEMUDriverPtr driver); virCapsPtr virQEMUDriverCreateCapabilities(virQEMUDriverPtr driver); virCapsPtr virQEMUDriverGetCapabilities(virQEMUDriverPtr driver, diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 663c0af867..8e9c0224e4 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -2498,8 +2498,7 @@ qemuDomainObjPrivateXMLParseVcpu(xmlNodePtr node, static int qemuDomainObjPrivateXMLParseAutomaticPlacement(xmlXPathContextPtr ctxt, - qemuDomainObjPrivatePtr priv, - virQEMUDriverPtr driver) + qemuDomainObjPrivatePtr priv) { g_autoptr(virCapsHostNUMA) caps = NULL; g_autofree char *nodeset = NULL; @@ -2513,7 +2512,7 @@ qemuDomainObjPrivateXMLParseAutomaticPlacement(xmlXPathContextPtr ctxt, if (!nodeset && !cpuset) return 0; - if (!(caps = virQEMUDriverGetHostNUMACaps(driver))) + if (!(caps = virCapabilitiesHostNUMANewHost())) return -1; /* Figure out how big the nodeset bitmap needs to be. @@ -3114,7 +3113,7 @@ qemuDomainObjPrivateXMLParse(xmlXPathContextPtr ctxt, } VIR_FREE(nodes); - if (qemuDomainObjPrivateXMLParseAutomaticPlacement(ctxt, priv, driver) < 0) + if (qemuDomainObjPrivateXMLParseAutomaticPlacement(ctxt, priv) < 0) goto error; if ((tmp = virXPathString("string(./libDir/@path)", ctxt))) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 8eaa3ce68f..d2077f8f16 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1136,7 +1136,6 @@ qemuStateCleanup(void) virObjectUnref(qemu_driver->qemuCapsCache); virObjectUnref(qemu_driver->xmlopt); virCPUDefFree(qemu_driver->hostcpu); - virCapabilitiesHostNUMAUnref(qemu_driver->hostnuma); virObjectUnref(qemu_driver->caps); ebtablesContextFree(qemu_driver->ebtables); VIR_FREE(qemu_driver->qemuImgBinary); diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 579b3c3713..49528f3dab 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -6197,8 +6197,7 @@ qemuProcessUpdateGuestCPU(virDomainDefPtr def, static int -qemuProcessPrepareDomainNUMAPlacement(virQEMUDriverPtr driver, - virDomainObjPtr vm) +qemuProcessPrepareDomainNUMAPlacement(virDomainObjPtr vm) { qemuDomainObjPrivatePtr priv = vm->privateData; g_autofree char *nodeset = NULL; @@ -6226,7 +6225,7 @@ qemuProcessPrepareDomainNUMAPlacement(virQEMUDriverPtr driver, if (virBitmapParse(nodeset, &numadNodeset, VIR_DOMAIN_CPUMASK_LEN) < 0) return -1; - if (!(caps = virQEMUDriverGetHostNUMACaps(driver))) + if (!(caps = virCapabilitiesHostNUMANewHost())) return -1; /* numad may return a nodeset that only contains cpus but cgroups don't play @@ -6428,7 +6427,7 @@ qemuProcessPrepareDomain(virQEMUDriverPtr driver, } virDomainAuditSecurityLabel(vm, true); - if (qemuProcessPrepareDomainNUMAPlacement(driver, vm) < 0) + if (qemuProcessPrepareDomainNUMAPlacement(vm) < 0) return -1; } -- 2.26.2

2 1

[PATCH v2 0/2] qemu: support some missing params on live attaching chardev
by Nikolay Shirokovskiy 02 Dec '20

02 Dec '20

Specifying chardev logfile and file backend append param is ignored yet. Diff from v1: - use existing virJSONValueObjectAdd instead of introducing virJSONValueObjectAppendBooleanTristate. Nikolay Shirokovskiy (2): qemu: support append param on live attaching file chardev qemu: support logfile on live attaching chardev src/qemu/qemu_monitor_json.c | 11 +++++++++++ 1 file changed, 11 insertions(+) -- 1.8.3.1

2 4

[libvirt PATCH] src: use singular form instead of plural, for guest disk info
by Daniel P. Berrangé 02 Dec '20

02 Dec '20

Existing practice with the filesystem fields reported for the virDomainGetGuestInfo API is to use the singular form for field names. Ensure the disk info follows this practice. Fixes commit 05a75ca2ce743bc0bb119fb8d532ff84646fafa3 Author: Marc-André Lureau <marcandre.lureau(a)redhat.com> Date: Fri Nov 20 22:09:46 2020 +0400 domain: add disk informations to virDomainGetGuestInfo commit 0cb2d9f05d00497a715352f6ea28cf8fb6921731 Author: Marc-André Lureau <marcandre.lureau(a)redhat.com> Date: Fri Nov 20 22:09:47 2020 +0400 qemu_driver: report guest disk informations Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- src/libvirt-domain.c | 14 +++++++------- src/qemu/qemu_driver.c | 14 +++++++------- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index 35e95e5395..f5cd43ecea 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -12345,17 +12345,17 @@ virDomainSetVcpu(virDomainPtr domain, * Returns information about the disks within the domain. The typed * parameter keys are in this format: * - * "disks.count" - the number of disks defined on this domain + * "disk.count" - the number of disks defined on this domain * as an unsigned int - * "disks.<num>.name" - device node (Linux) or device UNC (Windows) - * "disks.<num>.partition" - whether this is a partition or disk - * "disks.<num>.dependencies.count" - the number of device dependencies + * "disk.<num>.name" - device node (Linux) or device UNC (Windows) + * "disk.<num>.partition" - whether this is a partition or disk + * "disk.<num>.dependency.count" - the number of device dependencies * e.g. for LVs of the LVM this will * hold the list of PVs, for LUKS encrypted volume this will * contain the disk where the volume is placed. (Linux) - * "disks.<num>.dependencies.<num>.name" - a dependency - * "disks.<num>.alias" - the device alias of the disk (e.g. sda) - * "disks.<num>.guest_alias" - optional alias assigned to the disk, on Linux + * "disk.<num>.dependency.<num>.name" - a dependency + * "disk.<num>.alias" - the device alias of the disk (e.g. sda) + * "disk.<num>.guest_alias" - optional alias assigned to the disk, on Linux * this is a name assigned by device mapper * * VIR_DOMAIN_GUEST_INFO_HOSTNAME: diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 8eaa3ce68f..548df6ae68 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -19876,20 +19876,20 @@ qemuAgentDiskInfoFormatParams(qemuAgentDiskInfoPtr *info, size_t i, j, ndeps; if (virTypedParamsAddUInt(params, nparams, maxparams, - "disks.count", ndisks) < 0) + "disk.count", ndisks) < 0) return; for (i = 0; i < ndisks; i++) { char param_name[VIR_TYPED_PARAM_FIELD_LENGTH]; g_snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, - "disks.%zu.name", i); + "disk.%zu.name", i); if (virTypedParamsAddString(params, nparams, maxparams, param_name, info[i]->name) < 0) return; g_snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, - "disks.%zu.partition", i); + "disk.%zu.partition", i); if (virTypedParamsAddBoolean(params, nparams, maxparams, param_name, info[i]->partition) < 0) return; @@ -19897,14 +19897,14 @@ qemuAgentDiskInfoFormatParams(qemuAgentDiskInfoPtr *info, if (info[i]->dependencies) { ndeps = g_strv_length(info[i]->dependencies); g_snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, - "disks.%zu.dependencies.count", i); + "disk.%zu.dependency.count", i); if (ndeps && virTypedParamsAddUInt(params, nparams, maxparams, param_name, ndeps) < 0) return; for (j = 0; j < ndeps; j++) { g_snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, - "disks.%zu.dependencies.%zu.name", i, j); + "disk.%zu.dependency.%zu.name", i, j); if (virTypedParamsAddString(params, nparams, maxparams, param_name, info[i]->dependencies[j]) < 0) return; @@ -19922,7 +19922,7 @@ qemuAgentDiskInfoFormatParams(qemuAgentDiskInfoPtr *info, info[i]->address->unit); if (diskdef) { g_snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, - "disks.%zu.alias", i); + "disk.%zu.alias", i); if (diskdef->dst && virTypedParamsAddString(params, nparams, maxparams, param_name, diskdef->dst) < 0) @@ -19932,7 +19932,7 @@ qemuAgentDiskInfoFormatParams(qemuAgentDiskInfoPtr *info, if (info[i]->alias) { g_snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, - "disks.%zu.guest_alias", i); + "disk.%zu.guest_alias", i); if (virTypedParamsAddString(params, nparams, maxparams, param_name, info[i]->alias) < 0) return; -- 2.28.0

2 1

[libvirt PATCH] meson: add winsock2 library on windows builds
by Daniel P. Berrangé 02 Dec '20

02 Dec '20

If building for windows with curl disabled we get build failures due to missing ws2_32 library needed for winsock2. Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- meson.build | 2 ++ 1 file changed, 2 insertions(+) diff --git a/meson.build b/meson.build index 01e7fbd409..b280809a65 100644 --- a/meson.build +++ b/meson.build @@ -1368,10 +1368,12 @@ libutil_dep = cc.find_library('util', required: false) if host_machine.system() == 'windows' ole32_dep = cc.find_library('ole32') oleaut32_dep = cc.find_library('oleaut32') + winsock2_dep = cc.find_library('ws2_32') win32_dep = declare_dependency( dependencies: [ ole32_dep, oleaut32_dep, + winsock2_dep, ], ) if get_option('default_library') == 'static' -- 2.28.0

2 1

[PATCH 0/3] qemu: support some missing params on live attaching chardev
by Nikolay Shirokovskiy 02 Dec '20

02 Dec '20

Specifying chardev logfile and file backend append param is ignored yet. Nikolay Shirokovskiy (3): util: add virJSONValueObjectAppendBooleanTristate qemu: support append param on live attaching file chardev qemu: support logfile on live attaching chardev src/libvirt_private.syms | 1 + src/qemu/qemu_monitor_json.c | 12 ++++++++++++ src/util/virjson.c | 25 +++++++++++++++++++++++++ src/util/virjson.h | 1 + 4 files changed, 39 insertions(+) -- 1.8.3.1

2 4

[PATCH 0/2] Replace VIR_AUTOSTRINGLIST with GStrv
by Michal Privoznik 02 Dec '20

02 Dec '20

2 3

[PATCH v2] qemuDomainGetGuestInfo: Exit early if getting info fails
by Michal Privoznik 02 Dec '20

02 Dec '20

If there is an error getting info from guest agent, then the control on qemuDomainGetGuestInfo() jumps onto 'exitagent' label and subsequently continues on 'endagentjob'. Both labels are hit also in success case too. The control then continues by attempting to match fetched info (e.g. disk addresses) with domain def. But this is needless - the API will return error regardless. To return early from the function move both 'exitagent' and 'endagentjob' labels at the end of the function and jump straight onto 'cleanup' afterwards. This allows us to set 'ret = 0' later - only when we know we succeeded. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- v2 of: https://www.redhat.com/archives/libvir-list/2020-December/msg00020.html src/qemu/qemu_driver.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 8eaa3ce68f..bca1c84630 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -20116,12 +20116,7 @@ qemuDomainGetGuestInfo(virDomainPtr dom, } } - ret = 0; - - exitagent: qemuDomainObjExitAgent(vm, agent); - - endagentjob: qemuDomainObjEndAgentJob(vm); if (nfs > 0 || ndisks > 0) { @@ -20143,6 +20138,8 @@ qemuDomainGetGuestInfo(virDomainPtr dom, qemuDomainObjEndJob(driver, vm); } + ret = 0; + cleanup: for (i = 0; i < nfs; i++) qemuAgentFSInfoFree(agentfsinfo[i]); @@ -20153,6 +20150,13 @@ qemuDomainGetGuestInfo(virDomainPtr dom, virDomainObjEndAPI(&vm); return ret; + + exitagent: + qemuDomainObjExitAgent(vm, agent); + + endagentjob: + qemuDomainObjEndAgentJob(vm); + goto cleanup; } -- 2.26.2

2 1

[Call for Presentations] FOSDEM 2021: Virt & IaaS Devroom
by Kashyap Chamarthy 02 Dec '20

02 Dec '20

[Cross-posting to KVM, QEMU, and libvirt lists] The Call For Papers for FOSDEM's Virt & IaaS Devroom went out yesterday[1]. Here's the text (slightly formatted for readability): ======================================================================= We are excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2021, to be hosted virtually on February 6th 2021. This year will mark FOSDEM's 21th anniversary as one of the longest-running free and open source software developer events, attracting thousands of developers and users from all over the world. Due to Covid-19, FOSDEM will be held virtually this year on February 6th & 7th, 2021. Important Dates --------------- * Submission deadline: 20th of December * Acceptance notifications: 25th of December * Final schedule announcement: 31st of December * Recorded presentations upload deadline: 15th of January * Devroom: 6th February 2021 About the Devroom ----------------- The Virtualization & IaaS devroom will feature session topics such as open source hypervisors and virtual machine managers such as Xen Project, KVM, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, Foreman, OpenStack, oVirt, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at users or developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Submit Your Proposal -------------------- All submissions must be made via the Pentabarf event planning site[1]. If you have not used Pentabarf before, you will need to create an account. If you submitted proposals for FOSDEM in previous years, you can use your existing account. After creating the account, select Create Event to start the submission process. Make sure to select Virtualization and IaaS devroom from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines --------------------- We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will need to be pre-recorded and put into our system at least a couple of weeks before the event. The presentations should be uploaded by 15th of January and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend the virtual FOSDEM event for the Q&A. We will not consider proposals from prospective speakers who are unsure whether they will be able to attend the FOSDEM virtual event. If you are experiencing problems with Pentabarf, the proposal submission interface, or have other questions, you can email our devroom mailing list[2] and we will try to help you. Code of Conduct --------------- Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Call for Volunteers ------------------- We are also looking for volunteers to help run the devroom. We need assistance with helping speakers to record the presentation as well as helping with streaming and chat moderation for the devroom. Please contact devroom mailing list [2] for more information. Questions? ---------- If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] https://penta.fosdem.org/submission/FOSDEM21 [2] iaas-virt-devroom at lists.fosdem.org ======================================================================= [+] https://lists.fosdem.org/pipermail/fosdem/2020q4/003109.html -- /kashyap

1 0

[PATCH] coding-style: Document 80 chars limit for line length
by Michal Privoznik 02 Dec '20

02 Dec '20

The idea is to have it like a soft limit: if possible then break lines, if not then have a long line instead of some creative approach. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/coding-style.rst | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/docs/coding-style.rst b/docs/coding-style.rst index cfd7b16638..813128bfb6 100644 --- a/docs/coding-style.rst +++ b/docs/coding-style.rst @@ -131,7 +131,7 @@ around operators and keywords: indent-libvirt() { - indent -bad -bap -bbb -bli4 -br -ce -brs -cs -i4 -l75 -lc75 \ + indent -bad -bap -bbb -bli4 -br -ce -brs -cs -i4 -l80 -lc80 \ -sbi4 -psl -saf -sai -saw -sbi4 -ss -sc -cdw -cli4 -npcs -nbc \ --no-tabs "$@" } @@ -141,6 +141,18 @@ further, by piping it through ``expand -i``, since some leading TABs can get through. Usually they're in macro definitions or strings, and should be converted anyhow. +The recommended length for lines is 80 characters, but common sense +should prevail. It may get tricky around some names (because of how +Libvirt constructs names for functions/enums/etc.) + +:: + + foo( + arg1, arg2 + ); // Bad + foo(arg1, + arg2); // Good + Libvirt requires a C99 compiler for various reasons. However, most of the code base prefers to stick to C89 syntax unless there is a compelling reason otherwise. For example, it is preferable to use -- 2.26.2

3 3

regression in meson build, AC_PATH_PROG lost
by Olaf Hering 02 Dec '20

02 Dec '20

autoconf allows to specify the path to a runtime binary that is not required during build via an environment variable: AC_PATH_PROG([PARTED], [parted], [], [$LIBVIRT_SBIN_PATH]) meson lacks such essential feature. As a result the package build environment needs to have more packages than necessary installed. This excessive list also pushes libvirt closer to the end of the build dependency chain. Was this considered while the buildsystem was switched to meson? Since meson does not support environment variables it seems the only way to address this is to introduce an option in meson_options.txt for each runtime executable. Will such change be accepted? Olaf

6 23