- Devel - libvirt List Archives

qemu no-shutdown feature in libvirt
by Luna Xu 03 Dec '20

03 Dec '20

Hi developers, Thanks for developing and maintaining such a great tool. I'm new and I'm trying to use the no-shutdown feature of qemu with libvirt. I've confirmed with the user list that currently there's no such feature in libvirt that supports what I want to do, so I'm posting here and see if anyone is aware of any existing project that can achieve this or anything under development to avoid re-implementing the wheel. Here is what I'm doing on qemu: When I start a VM with the qemu command I can specify the -no-shutdown flag so that my qemu process doesn't quit even if I shutdown the VM from the inside (issue shutdown or halt command inside VM). The VM is shutdown but the qemu process is not killed so that the jobs I submitted before for example backup (drive-backup) can continue to run even after VM gets shutdown by the user, and I'm able to check the status of the job through qmp commands (by communicating with the qemu process). Is anyone aware of any project that is currently implementing this functionality? Thanks for reading. Thanks, Luna

5 9

RFC: deprecating/obsoleting netcf package and libvirt virInterface*() APIs
by Laine Stump 03 Dec '20

03 Dec '20

netcf (the backend of libvirt's virInterface*() APIs) hasn't been modified in over 2 years, and the last time there was a change significant enough for an upstream release was in 2015 (!). It has never been possible to reliably translate back and forth between native and netcf/libvirt XML config for interfaces without losing some information, and impossible to keep up with new functionality being added to host network configuration in NetworkManager (especially since the modelling was slightly different - netcf is based on the idea of each physical interface having one configuration, while NetworkManager has potentially several different "Connections" for any given hardware interface, and at most one of these connections can be active at a time for the interface. Or something like that.) The libvirt virInterface*() API (and netcf behind it) originally arose out of a request from the oVirt project that we (libvirt) provide a way to provision the networking config on a compute node (I *think* this is the case - I started working on libvirt when they were in the middle of these discussions; netcf was originally implemented mostly by David Lutterkort, and then handed off to me when he moved on to other pastures). oVirt network provisioning usually meant adding a bridge, assigning it an IP address, and attaching an ethernet (or two via a bond) to that bridge. They wanted libvirt to provide this functionality because (I guess?) they wanted to have a single connection to the node that could perform all the setup they needed. Although netcf could do that, in the end it didn't provide exactly what they needed, so they "rolled their own" host network interface config and didn't use netcf. In the meantime, the idea of using a virtualization API to configure host network interfaces never took off (Who'da thunk?). netcf was designed so that a single C API + XML frontend could be compiled with multiple different backends, for different network configuration paradigms. A few other drivers were (partially) written (e.g. SuSE and Windows), but in the real world, the only backends that have been used have been the one that uses ifcfg files in Fedora/RHEL/CentOS, and the one that uses the /etc/network/interfaces file on debian/ubuntu. In both cases, the backend understands a subset of what is possible in those files, so some information from the config doesn't show up in the XML, and thus won't be preserved if netcf is used to modify (i.e. redefine) the interface. In addition, since a functionally identical configuration can be represented in multiple ways in both those formats, sometimes a config file is deemed unreadable by netcf, or it is read and interpreted correctly, but the modified config is written back using the "other" method. Since ovirt chose not to use it, the only users of its interface configuration capabilities that I've ever noticed in the wild were the occasional user wanting to use the "virsh iface-bridge" command to put a bridge behind their ethernet - certainly none of the higher level virtualization management applications (that I'm aware of) use any of the libvirt APIs that call to netcf (that means "anything starting with "virInterface"). The small part of the virInterface APIs that have been used with some regularity are just the functions that list current interfaces and get their current live status (i.e. based on sending/receiving netlink messages, not on the contents of the host network config files). Even on that front, the one commonly used example that I know know of is virt-manager, which had used virInterface*() to get a list of bridges/ethernets available for guest network connections, but that functionality was removed from virt-manager-3.0, which was released in September of this year. In spite of this sporadic use, there are occasional netcf BZes that get filed complaining about certain device options missing, or erroneous config resulting in a confusing error message. These are usually filed by Red Hat virt QE, simply because it's a part of their test plan (i.e. these reports generally don't reflect a failure on a production system). Because the "fix" wouldn't provide any gain in the real world, these BZes just sit in the queue and server only to make me (the netcf maintainer) feel like even more of a procrastinator that I actually am. (A sidebar: netcf was originally made into a separate library, rather than just a few files within libvirt itself, because there was at least shrugging verbal agreement that it would be used in places other than libvirt (and thus there would be a community benefit in eliminated duplicate code in the multiple projects); this also never materialized, so in the end, it is a separate library that is only consumed by libvirt, but because it's a separate library the "barrier to entry" for anyone to make any changes to it is very high, and so it (effectively) never sees any contributions from the outside.) Because of all the above, I've thought for quite awhile that we should deprecate netcf itself, along with all of libvirt's virInterface APIs *except* the one that lists interfaces (virConnectListAllInterfaces) and the one that outputs an XML dump of the current status of interfaces (virInterfaceGetXMLDesc). Since netcf is only used by libvirt anyway, the part of functionality that performs those two tasks could be moved into one or two C files within libvirt, removing the dependency on netcf and making updates easier and more accessible to 3rd parties. As a followup to this, we might provide another backend that would use NetworkManager APIs to retrieve all this information rather than netlink messages (which is what netcf currently does). Alternately, Cole suggested in a separate email that since libvirt's node device driver already reports various status information about devices on the host, we could just beef up the output of virNodeDeviceGetXMLDesc() for net_* devices to include more of the info that's visible in "ip link" and "ip addr". Or, we could just decide that it's okay for a management application (the main consumer of libvirt) to need to use other APIs to get that information (especially since that's what they already do anyway!) So, that's my piece to speak. I'm looking for opinions and ideas on a few different fronts: 1) Does this generally sound like a good direction? Or is there something I'm ignoring that renders my points moot? 2) If we are going to do it, how should we proceed? We obviously can't simply *remove* the virInterface API from libvirt (since that would destroy backward compatibility guarantees), but could immediately begin logging some sort of "this API is deprecated" message when any of the functions are called, and then in a later release change the APIs to return an error (while simultaneously removing netcf from the build and dependency lists). At the same time, we would need to decide if the "interface status" functionality needs to be maintained within appropriate virInterface*() APIs, reproduced in virNodeDeviceGetXMLDesc(), or just dropped altogether. On the netcf side, there are several small patches that have been sitting in git for a few years without being in any official release; it would probably be nice to make one final release before closing up shop. The mailing list could then be closed down, and some final message put in a README in the git repo (on pagure.io) before putting it into some archival state. After those things are done, the various distros could be notified of the newfound irrelevance of netcf, and given the opportunity to remove the package from their releases. Anything else?

5 4

[PATCH] qemu_conf: Fix double free problem for cfg->firmwares
by Tuguoyi 03 Dec '20

03 Dec '20

cfg->firmwares still points to the original memory address after being freed by virFirmwareFreeList(). As cfg get freed, it will be freed again even if cfg->nfirmwares=0 which eventually lead to crash. The patch fix it by setting cfg->firmwares to NULL explicitly after virFirmwareFreeList() returns Signed-off-by: Tuguoyi <tu.guoyi(a)h3c.com> --- src/qemu/qemu_conf.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index 83de26a..98593b5 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -832,6 +832,7 @@ virQEMUDriverConfigLoadNVRAMEntry(virQEMUDriverConfigPtr cfg, VIR_AUTOSTRINGLIST fwList = NULL; virFirmwareFreeList(cfg->firmwares, cfg->nfirmwares); + cfg->firmwares = NULL; if (qemuFirmwareFetchConfigs(&fwList, privileged) < 0) return -1; -- 2.7.4 -- Best regards, Guoyi

3 6

[PATCH 0/7] A few Coverity related issues
by John Ferlan 02 Dec '20

02 Dec '20

Fix some of the issues that have built up. Also a docs link fix that I tripped across at some point in time. Again as a reminder, I no longer have push access ;-) John Ferlan (7): util: Fix memory leak in virNetDevOpenvswitchInterfaceGetMaster util: Resolve resource leak in virExec error path docs: Fix link for virConnectGetStoragePoolCapabilities qemu: Fix resource leak and coding error in qemuDomainGetIOThreadsMon logging: Resolve mem leak in virLogDaemonPreExecRestart locking: Resolve mem leak in virLockDaemonPreExecRestart qemu: Fix some issues in virQEMUDriverConfigLoadNVRAMEntry docs/formatstoragecaps.html.in | 2 +- src/locking/lock_daemon.c | 7 +++---- src/logging/log_daemon.c | 7 +++---- src/qemu/qemu_conf.c | 5 ++--- src/qemu/qemu_driver.c | 19 +++++++++---------- src/util/vircommand.c | 2 ++ src/util/virnetdevopenvswitch.c | 2 +- 7 files changed, 21 insertions(+), 23 deletions(-) -- 2.28.0

2 15

[PATCH 00/11] virDomainCheckpointAlignDisks: Clean up similarly to virDomainSnapshotAlignDisks
by Peter Krempa 02 Dec '20

02 Dec '20

I've refactored virDomainSnapshotAlignDisks and virDomainCheckpointAlignDisks was heavily inspired by it. Clean it up too. Peter Krempa (11): virDomainCheckpointAlignDisks: Refactor cleanup virDomainCheckpointAlignDisks: Unbreak error message virDomainCheckpointAlignDisks: Use 'domdef' for domain definition virDomainCheckpointAlignDisks: rename 'def' to 'chkdef' virDomainCheckpointAlignDisks: Use 'chkdisk' instead of 'disk' virDomainCheckpointAlignDisks: Extract domain disk def pointer to 'domdisk' virDomainCheckpointAlignDisks: refactor extension to all disks virDomainCheckpointDiskDef: Remove unused 'idx' field virDomainDiskByName: Remove ternary operator virDomainCheckpointAlignDisks: Use virDomainDiskByName virDomainSnapshotAlignDisks: Use virDomainDiskByName src/conf/checkpoint_conf.c | 123 ++++++++++++++++--------------------- src/conf/checkpoint_conf.h | 1 - src/conf/domain_conf.c | 6 +- src/conf/snapshot_conf.c | 7 +-- 4 files changed, 61 insertions(+), 76 deletions(-) -- 2.28.0

2 12

[PATCH v2] coding-style: Document 100 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> --- v2 of: https://www.redhat.com/archives/libvir-list/2020-November/msg01600.html docs/coding-style.rst | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/coding-style.rst b/docs/coding-style.rst index cfd7b16638..b3ac070fac 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 -l100 -lc100 \ -sbi4 -psl -saf -sai -saw -sbi4 -ss -sc -cdw -cli4 -npcs -nbc \ --no-tabs "$@" } @@ -141,6 +141,9 @@ 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 maximum permitted line length is 100 characters, but lines +should aim to be approximately 80 characters. + 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

2 1

[PATCH] qemu: Drop qemuMonitorGetVirtType()
by Michal Privoznik 02 Dec '20

02 Dec '20

It's unused since v5.5.0-rc1~113. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- src/qemu/qemu_monitor.c | 10 ------- src/qemu/qemu_monitor.h | 2 -- src/qemu/qemu_monitor_json.c | 40 --------------------------- src/qemu/qemu_monitor_json.h | 2 -- tests/qemumonitorjsontest.c | 52 ------------------------------------ 5 files changed, 106 deletions(-) diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index c333fc1364..ce1a06c4c8 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -1964,16 +1964,6 @@ qemuMonitorSetLink(qemuMonitorPtr mon, } -int -qemuMonitorGetVirtType(qemuMonitorPtr mon, - virDomainVirtType *virtType) -{ - QEMU_CHECK_MONITOR(mon); - - return qemuMonitorJSONGetVirtType(mon, virtType); -} - - /** * Returns: 0 if balloon not supported, +1 if balloon query worked * or -1 on failure diff --git a/src/qemu/qemu_monitor.h b/src/qemu/qemu_monitor.h index 3dcceffef8..8bc092870b 100644 --- a/src/qemu/qemu_monitor.h +++ b/src/qemu/qemu_monitor.h @@ -656,8 +656,6 @@ virBitmapPtr qemuMonitorGetCpuHalted(qemuMonitorPtr mon, size_t maxvcpus, bool fast); -int qemuMonitorGetVirtType(qemuMonitorPtr mon, - virDomainVirtType *virtType); int qemuMonitorGetBalloonInfo(qemuMonitorPtr mon, unsigned long long *currmem); int qemuMonitorGetMemoryStats(qemuMonitorPtr mon, diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c index ab83abf6b3..5acc1a10aa 100644 --- a/src/qemu/qemu_monitor_json.c +++ b/src/qemu/qemu_monitor_json.c @@ -2052,46 +2052,6 @@ qemuMonitorJSONQueryCPUs(qemuMonitorPtr mon, } -int qemuMonitorJSONGetVirtType(qemuMonitorPtr mon, - virDomainVirtType *virtType) -{ - int ret = -1; - virJSONValuePtr cmd = qemuMonitorJSONMakeCommand("query-kvm", - NULL); - virJSONValuePtr reply = NULL; - virJSONValuePtr data; - bool val = false; - - *virtType = VIR_DOMAIN_VIRT_QEMU; - - if (!cmd) - return -1; - - if (qemuMonitorJSONCommand(mon, cmd, &reply) < 0) - goto cleanup; - - if (qemuMonitorJSONCheckReply(cmd, reply, VIR_JSON_TYPE_OBJECT) < 0) - goto cleanup; - - data = virJSONValueObjectGetObject(reply, "return"); - - if (virJSONValueObjectGetBoolean(data, "enabled", &val) < 0) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("info kvm reply missing 'enabled' field")); - goto cleanup; - } - - if (val) - *virtType = VIR_DOMAIN_VIRT_KVM; - - ret = 0; - cleanup: - virJSONValueFree(cmd); - virJSONValueFree(reply); - return ret; -} - - /** * Loads correct video memory size values from QEMU and update the video * definition. diff --git a/src/qemu/qemu_monitor_json.h b/src/qemu/qemu_monitor_json.h index da988f0d41..d2928b0ffc 100644 --- a/src/qemu/qemu_monitor_json.h +++ b/src/qemu/qemu_monitor_json.h @@ -57,8 +57,6 @@ int qemuMonitorJSONQueryCPUs(qemuMonitorPtr mon, size_t *nentries, bool force, bool fast); -int qemuMonitorJSONGetVirtType(qemuMonitorPtr mon, - virDomainVirtType *virtType); int qemuMonitorJSONUpdateVideoMemorySize(qemuMonitorPtr mon, virDomainVideoDefPtr video, char *path); diff --git a/tests/qemumonitorjsontest.c b/tests/qemumonitorjsontest.c index d22a92d3e1..79ef2a545e 100644 --- a/tests/qemumonitorjsontest.c +++ b/tests/qemumonitorjsontest.c @@ -1445,57 +1445,6 @@ testQemuMonitorJSONqemuMonitorJSONGetBalloonInfo(const void *opaque) return 0; } -static int -testQemuMonitorJSONqemuMonitorJSONGetVirtType(const void *opaque) -{ - const testGenericData *data = opaque; - virDomainXMLOptionPtr xmlopt = data->xmlopt; - virDomainVirtType virtType; - g_autoptr(qemuMonitorTest) test = NULL; - - if (!(test = qemuMonitorTestNewSchema(xmlopt, data->schema))) - return -1; - - if (qemuMonitorTestAddItem(test, "query-kvm", - "{" - " \"return\": {" - " \"enabled\": true," - " \"present\": true" - " }," - " \"id\": \"libvirt-8\"" - "}") < 0 || - qemuMonitorTestAddItem(test, "query-kvm", - "{" - " \"return\": {" - " \"enabled\": false," - " \"present\": true" - " }," - " \"id\": \"libvirt-7\"" - "}") < 0) - return -1; - - if (qemuMonitorJSONGetVirtType(qemuMonitorTestGetMonitor(test), &virtType) < 0) - return -1; - - if (virtType != VIR_DOMAIN_VIRT_KVM) { - virReportError(VIR_ERR_INTERNAL_ERROR, - "Unexpected virt type: %d, expecting %d", virtType, VIR_DOMAIN_VIRT_KVM); - return -1; - } - - if (qemuMonitorJSONGetVirtType(qemuMonitorTestGetMonitor(test), &virtType) < 0) - return -1; - - if (virtType != VIR_DOMAIN_VIRT_QEMU) { - virReportError(VIR_ERR_INTERNAL_ERROR, - "Unexpected virt type: %d, expecting %d", virtType, VIR_DOMAIN_VIRT_QEMU); - return -1; - } - - return 0; -} - - static void testQemuMonitorJSONGetBlockInfoPrint(const struct qemuDomainDiskInfo *d) { @@ -3205,7 +3154,6 @@ mymain(void) DO_TEST(qemuMonitorJSONGetMigrationCapabilities); DO_TEST(qemuMonitorJSONQueryCPUs); DO_TEST(qemuMonitorJSONQueryCPUsFast); - DO_TEST(qemuMonitorJSONGetVirtType); DO_TEST(qemuMonitorJSONSendKey); DO_TEST(qemuMonitorJSONGetDumpGuestMemoryCapability); DO_TEST(qemuMonitorJSONSendKeyHoldtime); -- 2.26.2

2 2

[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