August 2021 - Devel - libvirt List Archives

RFC: revert to external snapshot API
by Nikolay Shirokovskiy 21 Sep '21

21 Sep '21

Hi, all. I want to implement reverting to external snapshot functionality. I've checked the mailing list history and found some previous attempts (not sure if this is a complete list of them). [1] was done in 2012 by the Redhat team itself. [2] and [3] was done in 2018. Looks like it was not clear how the API should look like. For example we have disk.qcow2 <- disk.snap1 chain <- disk.snap2 chain (after having snap1 and snap2 snapshots). Now we want to revert to snap1 snapshot. The snapshot state is held by disk.qcow2 image. We can run reverted domain on disk.qcow2 itself but then we lose snap1 (held by disk.qcow2) and snap2 (held by disk.snap1). So we definitely should run on some overlay over disk.qcow2. But then what name should be given to overlay? We should have an option for mgmt to specify this name like in case of snapshots itself. The [1] has some discussion on adding extra options to reverting functionality. Like for example if we revert back to snap2 then having the ability to run from state in disk.snap2 rather than disk.snap1. My opinion is there is no need to as if one wants to revert to the state of disk2.snap2 it can take a snapshot (some snap3). At the same time one needs to be aware that revert operation loses current state and later one can revert only to the states of snapshots. This is the way internal snapshots work and the way one expects external snapshots to work too. The [2] takes an approach of reusing current top image as overlay on revert so that in the above example disk.snap2 will be overlay over disk.qcow2 on reverting to snap1 snapshot. IMHO this is a confusing naming scheme. The [3] suggests a different scheme for naming images. For example after taking snapshot snap1 the chain should be disk.snap1 <- disk.qcow2 which looks very appealing to me. With this naming using the [2] approach is quite natural. Implementing this does not look hard even for a running domain but this is a big change to API and all mgmt need to be aware of (well it could be done safely using a new flag). Anyway we can go on with current image names. In order to specify overlay image name let's introduce new API: int virDomainRevertToSnapshotXML(virDomainSnapshotPtr snapshot, char *xmlDesc, unsigned int flags) with XML like: <domainsnapshotrevert> <disks> <disk name='vda'> <source file='/path/to/revert/overlay'/> </disk> </disks> </domainsnapshotrevert> Having an XML looks like a bit overkill right now but I could not find a better solution. If overlay name is omitted the generated name will be like disk.snap1-1 in the above example to be in alignment with creating a snapshot case. So that disk.snap1* images hold states derived from snap1 state. We can also support reverting to external snapshot thru existing virDomainRevertToSnapshot for those who rely on generated names using this naming scheme. [1] Re: [PATCHv4 4/4] snapshot: qemu: Implement reverting of external snapshots https://listman.redhat.com/archives/libvir-list/2012-November/msg00932.html [2] Re: [PATCH 1/5] snapshot: Implement reverting for external disk snapshots https://listman.redhat.com/archives/libvir-list/2018-November/msg00338.html [3] External disk snapshot paths and the revert operation https://listman.redhat.com/archives/libvir-list/2018-October/msg01110.html

3 6

[PATCH v2 0/3] qapi & doc: deprecate drive-backup
by Vladimir Sementsov-Ogievskiy 15 Sep '21

15 Sep '21

Hi all! See 03 commit message for details. 01-02 are preparation docs update. v2: add a lot of documentation changes v1 was "[PATCH] qapi: deprecate drive-backup" Supersedes: <20210423125900.3640-1-vsementsov(a)virtuozzo.com> Vladimir Sementsov-Ogievskiy (3): docs/block-replication: use blockdev-backup docs/interop/bitmaps: use blockdev-backup qapi: deprecate drive-backup docs/block-replication.txt | 4 +- docs/interop/bitmaps.rst | 285 +++++++++++++++++++------ docs/interop/live-block-operations.rst | 47 ++-- docs/system/deprecated.rst | 11 + qapi/block-core.json | 5 +- 5 files changed, 263 insertions(+), 89 deletions(-) -- 2.29.2

4 17

[PATCH 00/22] qemu: Fix mess with lifecycle actions and unbreak transient disks
by Peter Krempa 15 Sep '21

15 Sep '21

While investigating how to fix issue with transient disks breaking when -no-shutdown is not used I've ended up figuring out that lifecycle action handling in the qemu driver is very broken. Unbreak the handling by rejecting some actions which were never implemented, add support for 'set-action' qmp command and use it to update the 'reset' action in qemu and always use '-no-shutdown'. Peter Krempa (22): qemuMonitorJSONSetWatchdogAction: Use automatic memory clearing qemuDomainSetLifecycleAction: Add a note about argument range-check qemu: driver: Use 'qemuDomainSaveStatus' for saving status XML qemu: validate: Reformat header and purge unused includes qemu: Reject 'rename-restart' action for 'on_reboot'/'on_poweroff'/'on_crash' qemu: driver: Validate lifecycle actions in 'qemuDomainSetLifecycleAction' qemu: Reject 'preserve' action for 'on_reboot'/'on_poweroff'/'on_crash' qemu: Honor 'restart' action for 'on_poweroff' qemu: capablities: Detect presence of 'set-action' as QEMU_CAPS_SET_ACTION qemu: monitor: Implement monitor code for 'set-action' command qemuDomainAttachWatchdog: Use 'set-action' instead of 'watchdog-set-action' if supported qemuxml2argvtest: Add 'LATEST' version of 'misc-no-reboot' test case qemuDomainObjPrivate: Annotate 'allowReboot' field qemu: migration: Don't transfer 'allowReboot' flag qemu: domain: Remove qemuDomainIsUsingNoShutdown qemuDomainSetLifecycleAction: Forbid live update of 'on_reboot' qemuProcessHandleReset: Don't emulate lifecycle actions for RESET event qemuProcessLaunch: Setup handling of 'on_reboot' via QMP when starting the process qemu: command: Always use '-no-shutdown' qemu: process: Don't set 'allowReboot' when qemu supports 'set-action' qemuDomainSetLifecycleAction: Properly update 'onReboot' action in qemu qemu: process: Ignore 'RESET' event during startup docs/formatdomain.rst | 8 +- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 14 +- src/qemu/qemu_domain.c | 16 -- src/qemu/qemu_domain.h | 11 +- src/qemu/qemu_driver.c | 201 +++++++++++------- src/qemu/qemu_hotplug.c | 54 ++++- src/qemu/qemu_migration.c | 5 - src/qemu/qemu_migration_cookie.c | 22 -- src/qemu/qemu_migration_cookie.h | 4 - src/qemu/qemu_monitor.c | 16 ++ src/qemu/qemu_monitor.h | 49 +++++ src/qemu/qemu_monitor_json.c | 95 ++++++++- src/qemu/qemu_monitor_json.h | 7 + src/qemu/qemu_process.c | 85 +++++--- src/qemu/qemu_validate.c | 51 +++++ src/qemu/qemu_validate.h | 31 +-- .../caps_6.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + .../basic-xml2xml-out.xml | 1 - .../full-xml2xml-out.xml | 1 - .../modern-dom-out-dest.xml | 1 - .../modern-dom-out-source.xml | 1 - .../nbd-bitmaps-xml2xml-out.xml | 1 - tests/qemumonitorjsontest.c | 6 + .../misc-no-reboot.x86_64-latest.args | 35 +++ tests/qemuxml2argvtest.c | 1 + 30 files changed, 529 insertions(+), 194 deletions(-) create mode 100644 tests/qemuxml2argvdata/misc-no-reboot.x86_64-latest.args -- 2.31.1

4 27

question on vhost, limiting kernel threads and NPROC
by Mike Christie 14 Sep '21

14 Sep '21

Hi, The goal of this email is to try and figure how we want to track/limit the number of kernel threads created by vhost devices. Background: ----------- For vhost-scsi, we've hit a issue where the single vhost worker thread can't handle all IO the being sent from multiple queues. IOPs is stuck at around 500K. To fix this, we did this patchset: https://lore.kernel.org/linux-scsi/20210525180600.6349-1-michael.christie@o… which allows userspace to create N threads and map them to a dev's virtqueues. With this we can get around 1.4M IOPs. Problem: -------- While those patches were being reviewed, a concern about tracking all these new possible threads was raised here: https://lore.kernel.org/linux-scsi/YL45CfpHyzSEcAJv@stefanha-x1.localdomain/ To save you some time, the question is what does other kernel code using the kthread API do to track the number of kernel threads created on behalf of a userspace thread. The answer is they don't do anything so we will have to add that code. I started to do that here: https://lkml.org/lkml/2021/6/23/1233 where those patches would charge/check the vhost device owner's RLIMIT_NPROC value. But, the question of if we really want to do this has come up which is why I'm bugging lists like libvirt now. Question/Solution: ------------------ I'm bugging everyone so we can figure out: If we need to specifically track the number of kernel threads being made for the vhost kernel use case by the RLIMIT_NPROC limit? Or, is it ok to limit the number of devices with the RLIMIT_NOFILE limit. Then each device has a limit on the number of threads it can create.

4 4

[PATCH v4 for v7.6.0 00/14] Introduce virtio-mem <memory/> model
by Michal Privoznik 13 Sep '21

13 Sep '21

v4 of: https://listman.redhat.com/archives/libvir-list/2021-April/msg01138.html diff to v3: - Rebased code on the top of master - Tried to work in all Peter's review suggestions - Fixed a bug where adjusting <requested/> was viewed as hotplug of new <memory/> by XML validator and thus if <maxMemory/> was close enough to <currentMemory/> the validator reported an error (this was reported by David). You can also find these patches on my branch: https://gitlab.com/MichalPrivoznik/libvirt/-/tree/virtio_mem_v4 Michal Prívozník (14): virhostmem: Introduce virHostMemGetTHPSize() qemu_capabilities: Introduce QEMU_CAPS_DEVICE_VIRTIO_MEM_PCI conf: Introduce virtio-mem <memory/> model qemu: Build command line for virtio-mem qemu: Wire up <memory/> live update Introduce <actual/> property to virtio-mem conf: Introduce virDomainMemoryFindByDeviceAlias() qemu: Wire up MEMORY_DEVICE_SIZE_CHANGE event qemu: Refresh the actual size of virtio-mem on monitor reconnect qemu: Account for both memballoon and virtio-mem qemuDomainSetMemoryFlags: Take virtio-mem into consideration virsh: Introduce update-memory-device command news: document recent virtio memory addition kbase: Document virtio-mem NEWS.rst | 12 + docs/formatdomain.rst | 45 +++- docs/kbase/index.rst | 4 + docs/kbase/memorydevices.rst | 150 +++++++++++ docs/kbase/meson.build | 1 + docs/manpages/virsh.rst | 30 +++ docs/schemas/domaincommon.rng | 16 ++ examples/c/misc/event-test.c | 17 ++ include/libvirt/libvirt-domain.h | 23 ++ src/conf/domain_conf.c | 118 ++++++++- src/conf/domain_conf.h | 15 ++ src/conf/domain_event.c | 84 ++++++ src/conf/domain_event.h | 10 + src/conf/domain_validate.c | 39 +++ src/libvirt_private.syms | 5 + src/qemu/qemu_alias.c | 10 +- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 13 +- src/qemu/qemu_domain.c | 33 ++- src/qemu/qemu_domain.h | 1 + src/qemu/qemu_domain_address.c | 38 ++- src/qemu/qemu_driver.c | 240 +++++++++++++++++- src/qemu/qemu_hotplug.c | 18 ++ src/qemu/qemu_hotplug.h | 5 + src/qemu/qemu_monitor.c | 37 +++ src/qemu/qemu_monitor.h | 28 ++ src/qemu/qemu_monitor_json.c | 97 +++++-- src/qemu/qemu_monitor_json.h | 5 + src/qemu/qemu_process.c | 72 ++++++ src/qemu/qemu_validate.c | 8 + src/remote/remote_daemon_dispatch.c | 30 +++ src/remote/remote_driver.c | 32 +++ src/remote/remote_protocol.x | 14 +- src/remote_protocol-structs | 7 + src/security/security_apparmor.c | 1 + src/security/security_dac.c | 2 + src/security/security_selinux.c | 2 + src/util/virhostmem.c | 54 ++++ src/util/virhostmem.h | 3 + tests/domaincapsmock.c | 9 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + ...mory-hotplug-virtio-mem.x86_64-latest.args | 41 +++ .../memory-hotplug-virtio-mem.xml | 67 +++++ tests/qemuxml2argvtest.c | 1 + ...emory-hotplug-virtio-mem.x86_64-latest.xml | 1 + tests/qemuxml2xmltest.c | 1 + tools/virsh-domain.c | 169 ++++++++++++ 51 files changed, 1562 insertions(+), 53 deletions(-) create mode 100644 docs/kbase/memorydevices.rst create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-mem.x86_64-latest.args create mode 100644 tests/qemuxml2argvdata/memory-hotplug-virtio-mem.xml create mode 120000 tests/qemuxml2xmloutdata/memory-hotplug-virtio-mem.x86_64-latest.xml -- 2.31.1

4 21

[PATCH v2 0/4] Add support for two i386 pm options which control acpi hotplug
by Ani Sinha 12 Sep '21

12 Sep '21

Hi: I added some negative xml2argv tests as well as new xml2xml tests. In the process, I also fixed a bug where I had not added appropriate code to generate the output xml correctly. The patch series is sent again as v2. Kindly, please provide inputs and review them. [PATCH v2 1/4] pm/i386: add support for two options that controls [PATCH v2 2/4] tests: add positive xml2argv tests to exercize pm acpi [PATCH v2 3/4] tests: add negative xml2argv tests to exercize pm acpi [PATCH v2 4/4] tests: add xml2xml tests to exercize pm acpi hotplug

2 8

[PATCH 0/9] Fix image labels lost after migration with shared fs
by Peng Liang 10 Sep '21

10 Sep '21

When migrating using shared fs, the dst host will remember the image labels again before launching the VM and the src host will remove the image labels after migration. It leads to that the image labels lost after migration. Patch 7-9 are the real fix patches. Peng Liang (9): security: add virSecurityUpdateTimestampIfexists security: add virSecurityManagerUpdateImageLabel security: implement domainUpdateSecurityImageLabel for stack security: implement domainUpdateSecurityImageLabel for DAC qemu: add qemuSecurityUpdateImageLabel security: rename virSecurityDACSetImageLabelInternal to virSecurityDACSetImageLabelSingle migration: don't remember image labels when migrating with shared fs migration: don't remove image labels after migration migration: update image labels in dst after migration src/libvirt_private.syms | 1 + src/qemu/qemu_migration.c | 12 +++++++ src/qemu/qemu_process.c | 5 ++- src/qemu/qemu_security.c | 10 ++++++ src/qemu/qemu_security.h | 5 +++ src/security/security_dac.c | 58 +++++++++++++++++++++++++-------- src/security/security_driver.h | 5 +++ src/security/security_manager.c | 29 +++++++++++++++++ src/security/security_manager.h | 5 +++ src/security/security_stack.c | 20 ++++++++++++ src/security/security_util.c | 32 ++++++++++++++++++ src/security/security_util.h | 4 +++ 12 files changed, 172 insertions(+), 14 deletions(-) -- 2.31.1

2 18

[libvirt PATCH v3 0/7] Enable autostarting mediated devices
by Jonathon Jongsma 09 Sep '21

09 Sep '21

This first version of this series was reviewed quite a while ago and all patches were ACKed except the second one. I posted a second series with changes noted below but it was never ACKed and I dropped the ball for a little while. Subsequently there were questions about whether physical devices (e.g. pci, usb, etc) should return 'true' or 'false' for the GetAutostart()/IsPersistent() calls. I had initially marked them as persistent=true and autostart=true because they superficially act a bit like persistently-defined devices. But Boris convinced me that this is not a very accurate classification since if the physical device is unplugged, there will be no record of it left behind. So I've switched all non-mdev devices to be persistent=false and autostart=false. This is also imperfect, but it seems relatively harmless. Comments welcome. A reminder of what is included in this series: - new API consistent with existing libvirt objects: - virNodeDeviceGetAutostart() - virNodeDeviceSetAutostart() - virNodeDeviceIsPersistent() - virNodeDeviceIsActive - new virsh commands - nodedev-info - nodedev-autostart Changes in version 2: - Parse the autostart property from mdevctl output. Changes in version 3: - switch physical devices to autostart=false, persistent=false - rebase to upstream - update version numbers for new API, etc - fix accidental copy-paste error in virsh command descriptions Jonathon Jongsma (7): api: add virNodeDevice(Get|Set)Autostart() nodedev: implement virNodeDevice(Get|Set)Autostart() nodedev: Add tests for mdevctl autostart command virsh: add nodedev-autostart api: add virNodeDeviceIsPersistent()/IsActive() nodedev: Implement virNodeDeviceIsPersistent()/IsActive() virsh: add nodedev-info docs/manpages/virsh.rst | 27 +++ include/libvirt/libvirt-nodedev.h | 10 + src/conf/node_device_conf.h | 1 + src/conf/virnodedeviceobj.c | 16 ++ src/conf/virnodedeviceobj.h | 6 + src/driver-nodedev.h | 18 ++ src/libvirt-nodedev.c | 141 +++++++++++++ src/libvirt_private.syms | 2 + src/libvirt_public.syms | 4 + src/node_device/node_device_driver.c | 189 +++++++++++++++++- src/node_device/node_device_driver.h | 19 ++ src/node_device/node_device_udev.c | 22 +- src/remote/remote_driver.c | 6 +- src/remote/remote_protocol.x | 60 +++++- src/remote_protocol-structs | 26 +++ .../nodedevmdevctldata/mdevctl-autostart.argv | 8 + tests/nodedevmdevctltest.c | 55 +++++ tools/virsh-nodedev.c | 139 +++++++++++++ 18 files changed, 740 insertions(+), 9 deletions(-) create mode 100644 tests/nodedevmdevctldata/mdevctl-autostart.argv -- 2.31.1

2 9

[PATCH] qemu_driver:report guest interface informations
by scuzhanglei 09 Sep '21

09 Sep '21

Signed-off-by: scuzhanglei <greatzhanglei(a)gmail.com> --- NEWS.rst | 5 ++ include/libvirt/libvirt-domain.h | 1 + src/libvirt-domain.c | 12 +++++ src/qemu/qemu_agent.c | 9 ++-- src/qemu/qemu_agent.h | 3 +- src/qemu/qemu_driver.c | 88 +++++++++++++++++++++++++++++++- tests/qemuagenttest.c | 2 +- tools/virsh-domain.c | 2 + 8 files changed, 115 insertions(+), 7 deletions(-) diff --git a/NEWS.rst b/NEWS.rst index 21df0e1602..fde781b320 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -19,6 +19,11 @@ v7.7.0 (unreleased) * **Improvements** + * qemu: Report guest interfaces information in ``virDomainGetGuestInfo`` + + Libvirt is now able to report interfaces from the guest's + perspective (using guest agent). + * **Bug fixes** diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index 7ef8ac51e5..b088847725 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -5074,6 +5074,7 @@ typedef enum { VIR_DOMAIN_GUEST_INFO_HOSTNAME = (1 << 3), /* return hostname information */ VIR_DOMAIN_GUEST_INFO_FILESYSTEM = (1 << 4), /* return filesystem information */ VIR_DOMAIN_GUEST_INFO_DISKS = (1 << 5), /* return disks information */ + VIR_DOMAIN_GUEST_INFO_INTERFACES = (1 << 6), /* return interfaces information */ } virDomainGuestInfoTypes; int virDomainGetGuestInfo(virDomainPtr domain, diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c index a8a386e839..dfd84b4744 100644 --- a/src/libvirt-domain.c +++ b/src/libvirt-domain.c @@ -12586,6 +12586,18 @@ virDomainSetVcpu(virDomainPtr domain, * virTypedParamsFree to free memory returned in @params. * * Returns 0 on success, -1 on error. + * VIR_DOMAIN_GUEST_INFO_INTERFACES: + * Returns information about the interfaces within the domain. the typed + * parameter keys are in this format: + * + * "if.count" - the number of interfaces defined on this domain + * as an unsigned int + * "if.<num>.name" - interface name in the guest + * "if.<num>.hwaddr" - hardware address of interface + * "if.<num>.addr.count - the number of ip addresses of interface + * "if.<num>.addr.<num>.type" - the type of ip address(e.g. ipv4) + * "if.<num>.addr.<num>.addr" - the ip address + * "if.<num>.addr.<num>.prefix" - the number of bits of ip address prefix */ int virDomainGetGuestInfo(virDomainPtr domain, unsigned int types, diff --git a/src/qemu/qemu_agent.c b/src/qemu/qemu_agent.c index 5f421be6f6..a7f943e0dc 100644 --- a/src/qemu/qemu_agent.c +++ b/src/qemu/qemu_agent.c @@ -2245,17 +2245,20 @@ qemuAgentGetAllInterfaceAddresses(virDomainInterfacePtr **ifaces_ret, */ int qemuAgentGetInterfaces(qemuAgent *agent, - virDomainInterfacePtr **ifaces) + virDomainInterfacePtr **ifaces, + bool report_unsupported) { g_autoptr(virJSONValue) cmd = NULL; g_autoptr(virJSONValue) reply = NULL; virJSONValue *ret_array = NULL; + int rc; if (!(cmd = qemuAgentMakeCommand("guest-network-get-interfaces", NULL))) return -1; - if (qemuAgentCommand(agent, cmd, &reply, agent->timeout) < 0) - return -1; + if ((rc = qemuAgentCommandFull(agent, cmd, &reply, agent->timeout, + report_unsupported)) < 0) + return rc; if (!(ret_array = virJSONValueObjectGetArray(reply, "return"))) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", diff --git a/src/qemu/qemu_agent.h b/src/qemu/qemu_agent.h index 81b45b8e5d..94eab9de9f 100644 --- a/src/qemu/qemu_agent.h +++ b/src/qemu/qemu_agent.h @@ -151,7 +151,8 @@ int qemuAgentSetTime(qemuAgent *mon, bool sync); int qemuAgentGetInterfaces(qemuAgent *mon, - virDomainInterfacePtr **ifaces); + virDomainInterfacePtr **ifaces, + bool report_unsupported); int qemuAgentSetUserPassword(qemuAgent *mon, const char *user, diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index f1f961c51c..0b803c392b 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -18957,7 +18957,7 @@ qemuDomainInterfaceAddresses(virDomainPtr dom, goto endjob; agent = qemuDomainObjEnterAgent(vm); - ret = qemuAgentGetInterfaces(agent, ifaces); + ret = qemuAgentGetInterfaces(agent, ifaces, true); qemuDomainObjExitAgent(vm, agent); endjob: @@ -19903,7 +19903,8 @@ static const unsigned int qemuDomainGetGuestInfoSupportedTypes = VIR_DOMAIN_GUEST_INFO_TIMEZONE | VIR_DOMAIN_GUEST_INFO_HOSTNAME | VIR_DOMAIN_GUEST_INFO_FILESYSTEM | - VIR_DOMAIN_GUEST_INFO_DISKS; + VIR_DOMAIN_GUEST_INFO_DISKS | + VIR_DOMAIN_GUEST_INFO_INTERFACES; static int qemuDomainGetGuestInfoCheckSupport(unsigned int types, @@ -20102,6 +20103,69 @@ qemuAgentFSInfoFormatParams(qemuAgentFSInfo **fsinfo, } } +static void +virDomainInterfaceFormatParams(virDomainInterfacePtr *ifaces, +int nifaces, +virTypedParameterPtr *params, +int *nparams, int * maxparams) +{ + size_t i, j; + const char *type = NULL; + + if (virTypedParamsAddUInt(params, nparams, maxparams, + "if.count", nifaces) < 0) + return; + + for (i = 0; i < nifaces; i++) { + char param_name[VIR_TYPED_PARAM_FIELD_LENGTH]; + g_snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, + "if.%zu.name", i); + if (virTypedParamsAddString(params, nparams, maxparams, + param_name, ifaces[i]->name) < 0) + return; + + g_snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, + "if.%zu.hwaddr", i); + if (virTypedParamsAddString(params, nparams, maxparams, + param_name, ifaces[i]->hwaddr) < 0) + return; + + g_snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, + "if.%zu.addr.count", i); + if (virTypedParamsAddUInt(params, nparams, maxparams, + param_name, ifaces[i]->naddrs) < 0) + return; + + for (j = 0; j < ifaces[i]->naddrs; j++) { + switch (ifaces[i]->addrs[j].type) { + case VIR_IP_ADDR_TYPE_IPV4: + type = "ipv4"; + break; + case VIR_IP_ADDR_TYPE_IPV6: + type = "ipv6"; + break; + } + + g_snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, + "if.%zu.addr.%zu.type", i, j); + if (virTypedParamsAddString(params, nparams, maxparams, + param_name, type) < 0) + return; + + g_snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, + "if.%zu.addr.%zu.addr", i, j); + if (virTypedParamsAddString(params, nparams, maxparams, + param_name, ifaces[i]->addrs[j].addr) < 0) + return; + + g_snprintf(param_name, VIR_TYPED_PARAM_FIELD_LENGTH, + "if.%zu.addr.%zu.prefix", i, j); + if (virTypedParamsAddUInt(params, nparams, maxparams, + param_name, ifaces[i]->addrs[j].prefix) < 0) + return; + } + } +} static int qemuDomainGetGuestInfo(virDomainPtr dom, @@ -20123,6 +20187,8 @@ qemuDomainGetGuestInfo(virDomainPtr dom, qemuAgentFSInfo **agentfsinfo = NULL; size_t ndisks = 0; qemuAgentDiskInfo **agentdiskinfo = NULL; + virDomainInterfacePtr *ifaces = NULL; + size_t nifaces = 0; size_t i; virCheckFlags(0, -1); @@ -20188,6 +20254,15 @@ qemuDomainGetGuestInfo(virDomainPtr dom, } } + if (supportedTypes & VIR_DOMAIN_GUEST_INFO_INTERFACES) { + rc = qemuAgentGetInterfaces(agent, &ifaces, report_unsupported); + if (rc == -1) { + goto exitagent; + } else if (rc >= 0) { + nifaces = rc; + } + } + qemuDomainObjExitAgent(vm, agent); qemuDomainObjEndAgentJob(vm); @@ -20210,6 +20285,10 @@ qemuDomainGetGuestInfo(virDomainPtr dom, qemuDomainObjEndJob(driver, vm); } + if (nifaces > 0) { + virDomainInterfaceFormatParams(ifaces, nifaces, params, nparams, &maxparams); + } + ret = 0; cleanup: @@ -20219,6 +20298,11 @@ qemuDomainGetGuestInfo(virDomainPtr dom, for (i = 0; i < ndisks; i++) qemuAgentDiskInfoFree(agentdiskinfo[i]); g_free(agentdiskinfo); + if (ifaces && nifaces > 0) { + for (i = 0; i < nifaces; i++) + virDomainInterfaceFree(ifaces[i]); + } + g_free(ifaces); virDomainObjEndAPI(&vm); return ret; diff --git a/tests/qemuagenttest.c b/tests/qemuagenttest.c index a447c93494..e0b22c042a 100644 --- a/tests/qemuagenttest.c +++ b/tests/qemuagenttest.c @@ -920,7 +920,7 @@ testQemuAgentGetInterfaces(const void *data) goto cleanup; if ((ifaces_count = qemuAgentGetInterfaces(qemuMonitorTestGetAgent(test), - &ifaces)) < 0) + &ifaces, true)) < 0) goto cleanup; if (ifaces_count != 4) { diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index e5bd1fdd75..ea3ba58616 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -13854,6 +13854,8 @@ cmdGuestInfo(vshControl *ctl, const vshCmd *cmd) types |= VIR_DOMAIN_GUEST_INFO_FILESYSTEM; if (vshCommandOptBool(cmd, "disk")) types |= VIR_DOMAIN_GUEST_INFO_DISKS; + if (vshCommandOptBool(cmd, "interface")) + types |= VIR_DOMAIN_GUEST_INFO_INTERFACES; if (!(dom = virshCommandOptDomain(ctl, cmd, NULL))) return false; -- 2.31.1

2 2

[PATCH 0/1] qemu: add virtio-blk queue-size option
by Hiroki Narukawa 06 Sep '21

06 Sep '21

Hello, The option "queue-size" in virtio-blk was added in qemu-2.12.0, and default value increased from qemu-5.0.0. However, increasing this value may lead to drop of random access performance. This is configurable value, so we want to use it via libvirt. Sorry, my previous e-mail had wrong CC address that is rejected, please reply to this message and not previous one. Could you review this patch? Hiroki Narukawa (1): qemu: add virtio-blk queue-size option docs/schemas/domaincommon.rng | 5 +++ src/conf/domain_conf.c | 6 ++++ src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 5 +++ src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 3 ++ src/qemu/qemu_validate.c | 7 ++++ .../caps_2.12.0.aarch64.xml | 1 + .../caps_2.12.0.s390x.xml | 1 + .../qemucapabilitiesdata/caps_3.0.0.ppc64.xml | 1 + .../caps_3.0.0.riscv32.xml | 1 + .../caps_3.0.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_3.0.0.s390x.xml | 1 + .../caps_3.0.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_3.1.0.ppc64.xml | 1 + .../caps_3.1.0.x86_64.xml | 1 + .../caps_4.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1 + .../caps_4.0.0.riscv32.xml | 1 + .../caps_4.0.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_4.0.0.s390x.xml | 1 + .../caps_4.0.0.x86_64.xml | 1 + .../caps_4.1.0.x86_64.xml | 1 + .../caps_4.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1 + .../qemucapabilitiesdata/caps_4.2.0.s390x.xml | 1 + .../caps_4.2.0.x86_64.xml | 1 + .../caps_5.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1 + .../caps_5.0.0.riscv64.xml | 1 + .../caps_5.0.0.x86_64.xml | 1 + .../qemucapabilitiesdata/caps_5.1.0.sparc.xml | 1 + .../caps_5.1.0.x86_64.xml | 1 + .../caps_5.2.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.ppc64.xml | 1 + .../caps_5.2.0.riscv64.xml | 1 + .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 1 + .../caps_5.2.0.x86_64.xml | 1 + .../caps_6.0.0.aarch64.xml | 1 + .../qemucapabilitiesdata/caps_6.0.0.s390x.xml | 1 + .../caps_6.0.0.x86_64.xml | 1 + .../caps_6.1.0.x86_64.xml | 1 + .../disk-virtio-queue-size.args | 29 +++++++++++++++ .../disk-virtio-queue-size.xml | 35 +++++++++++++++++++ tests/qemuxml2argvtest.c | 2 ++ .../disk-virtio-queue-size.xml | 35 +++++++++++++++++++ tests/qemuxml2xmltest.c | 1 + 47 files changed, 165 insertions(+) create mode 100644 tests/qemuxml2argvdata/disk-virtio-queue-size.args create mode 100644 tests/qemuxml2argvdata/disk-virtio-queue-size.xml create mode 100644 tests/qemuxml2xmloutdata/disk-virtio-queue-size.xml -- 2.17.1

2 3