December 2020 - Devel - libvirt List Archives

[libvirt][PATCH v1 0/1] support system default memory policy with numatune
by Luyao Zhong 02 Dec '20

02 Dec '20

Hi libvirt experts, ---------- what does this patch support ---------- This patch seeks the support of system default memory policy when numatune is configured. Before this patch, numatune only has three memory modes: static, interleave and prefered. These memory policies are ultimately set by mbind() system call. Memory policy could be 'hard coded' into the kernel, but none of above policies fit our requirment under this case. mbind() support default memory policy, but it requires a NULL nodemask. So obviously setting allowed memory nodes is cgroups' mission. That means if 'default' mode is specified in numatune, numatune config will be completely cgroups setting, which restricting the memory nodes allowed for each vcpu thread in different cells. <numatune> <memory mode="default" nodeset="1-4,^3" migratable="yes" /> <memnode cellid="0" mode="default" nodeset="1"/> <memnode cellid="2" mode="default" nodeset="2"/> </numatune> Above is current design, we introduce a new "migratable" attribute and a new option "default" for "mode" attribute in numatune. ---------- summary of discussion ---------- But at the beginning in RFC[1], Martin Kletzander and I got a consensus, just introducing a new "migratable" attribute to indicates that we rely on operating system to operate memory policy. <numatune> <memory mode="strict" nodeset="1-4,^3" migratable="yes" /> <memnode cellid="0" mode="strict" nodeset="1"/> <memnode cellid="2" mode="preferred" nodeset="2"/> </numatune> the mode will be ignored, and libvirt will not set those memory policy related configs in qemu command line. Then initial patch got Peter Krempa's comments[2], if I understood it correctly, that means config should not be ignored directly (I just stated in document it will be ignored), it should be rejected in code and output log to lead user correct the config. But when I updated the patch, I found I had to add a new option 'default' for mode attribute since its default value is "strict", if not setting mode it will still be formatted to "strict" at the end. So I sent a RFC[3] again, but unfortunately it sunk into the mail sea. (sorry for the RFC/PATCH title changing) [1] https://www.redhat.com/archives/libvir-list/2020-August/msg00960.html [2] https://www.redhat.com/archives/libvir-list/2020-October/msg00396.html [3] https://www.redhat.com/archives/libvir-list/2020-October/msg01033.html mbind(): https://man7.org/linux/man-pages/man2/mbind.2.html Though we have "migratable" in current implementation, actually we can support this feauture without it since we have "default" mode, so is "migratable" still neccessary? Thanks for your patience to read this. Appreciate if you could give comments. Regards, Luyao Luyao Zhong (1): support system default memory policy with numatune docs/formatdomain.rst | 12 ++++- docs/schemas/domaincommon.rng | 7 +++ include/libvirt/libvirt-domain.h | 1 + src/conf/numa_conf.c | 50 ++++++++++++++++++- src/conf/numa_conf.h | 2 + src/libvirt_private.syms | 1 + src/qemu/qemu_command.c | 7 ++- src/qemu/qemu_process.c | 25 ++++++++++ src/util/virnuma.c | 3 ++ .../numatune-memory-migratable.args | 34 +++++++++++++ ...atune-memory-migratable.x86_64-latest.args | 35 +++++++++++++ .../numatune-memory-migratable.xml | 33 ++++++++++++ tests/qemuxml2argvtest.c | 2 + ...matune-memory-migratable.x86_64-latest.xml | 40 +++++++++++++++ .../numatune-memory-migratable.xml | 39 +++++++++++++++ tests/qemuxml2xmltest.c | 1 + 16 files changed, 288 insertions(+), 4 deletions(-) create mode 100644 tests/qemuxml2argvdata/numatune-memory-migratable.args create mode 100644 tests/qemuxml2argvdata/numatune-memory-migratable.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/numatune-memory-migratable.xml create mode 100644 tests/qemuxml2xmloutdata/numatune-memory-migratable.x86_64-latest.xml create mode 100644 tests/qemuxml2xmloutdata/numatune-memory-migratable.xml -- 2.25.4

2 2

[PATCH v2] 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 commit 172b8304352b1945e328394e61290a24446280dd Author: Marc-André Lureau <marcandre.lureau(a)redhat.com> Date: Fri Nov 20 22:09:48 2020 +0400 virsh: add --disk informations to guestinfo command Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- In v2: also update docs and virsh docs/manpages/virsh.rst | 20 ++++++++++---------- src/libvirt-domain.c | 14 +++++++------- src/qemu/qemu_driver.c | 14 +++++++------- tools/virsh-domain.c | 6 +++--- 4 files changed, 27 insertions(+), 27 deletions(-) diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst index 9ef6b68422..aa54bc21ef 100644 --- a/docs/manpages/virsh.rst +++ b/docs/manpages/virsh.rst @@ -2679,7 +2679,7 @@ guestinfo :: guestinfo domain [--user] [--os] [--timezone] [--hostname] [--filesystem] - [--disks] + [--disk] Print information about the guest from the point of view of the guest agent. Note that this command requires a guest agent to be configured and running in @@ -2690,7 +2690,7 @@ are supported by the guest agent. You can limit the types of information that are returned by specifying one or more flags. If a requested information type is not supported, the processes will provide an exit code of 1. Available information types flags are *--user*, *--os*, -*--timezone*, *--hostname*, *--filesystem* and *--disks*. +*--timezone*, *--hostname*, *--filesystem* and *--disk*. Note that depending on the hypervisor type and the version of the guest agent running within the domain, not all of the following information may be @@ -2747,15 +2747,15 @@ returned: * ``fs.<num>.disk.<num>.serial`` - the serial number of disk <num> * ``fs.<num>.disk.<num>.device`` - the device node of disk <num> -*--disks* returns: +*--disk* returns: -* ``disks.count`` - the number of disks defined on this domain -* ``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 -* ``disks.<num>.dependencies.<num>.name`` - a dependency name -* ``disks.<num>.alias`` - the device alias of the disk (e.g. sda) -* ``disks.<num>.guest_alias`` - optional alias assigned to the disk +* ``disk.count`` - the number of disks defined on this domain +* ``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 +* ``disk.<num>.dependency.<num>.name`` - a dependency name +* ``disk.<num>.alias`` - the device alias of the disk (e.g. sda) +* ``disk.<num>.guest_alias`` - optional alias assigned to the disk guestvcpus 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; diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 655bac3315..349ea38ec3 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -14209,9 +14209,9 @@ static const vshCmdOptDef opts_guestinfo[] = { .type = VSH_OT_BOOL, .help = N_("report filesystem information"), }, - {.name = "disks", + {.name = "disk", .type = VSH_OT_BOOL, - .help = N_("report disks information"), + .help = N_("report disk information"), }, {.name = NULL} }; @@ -14236,7 +14236,7 @@ cmdGuestInfo(vshControl *ctl, const vshCmd *cmd) types |= VIR_DOMAIN_GUEST_INFO_HOSTNAME; if (vshCommandOptBool(cmd, "filesystem")) types |= VIR_DOMAIN_GUEST_INFO_FILESYSTEM; - if (vshCommandOptBool(cmd, "disks")) + if (vshCommandOptBool(cmd, "disk")) types |= VIR_DOMAIN_GUEST_INFO_DISKS; if (!(dom = virshCommandOptDomain(ctl, cmd, NULL))) -- 2.28.0

2 1

[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