- Devel - libvirt List Archives

[PATCH v2 0/9] RFC: Add versioned CPUs to libvirt
by Jonathon Jongsma 08 Dec '23

08 Dec '23

For SEV-SNP support we will need to be able to specify versioned CPU models that are not yet available in libvirt. Rather than just adding a versioned CPU or two that would satisfy that immediate need, I decided to try to add versioned CPUs in a more standard way. This series generates CPU definitions for all cpu versions that are defined in upstream qemu (at least for recent Intel and AMD CPUs). libvirt already provides a select subset of these versions as configurable CPU models. But we only include the ones that have defined aliases in qemu, such as EPYC-IBPB. After this patchset, all verisioned cpu models supported by qemu will be available in libvirt. Note that I'm only adding versions that are not already available via their alias. For example, I am not adding an EPYC-v2 CPU model since it is already available as EPYC-IBPB. Changes in v2: - don't make any changes to existing CPU models - drop concept of aliases from libvirt and only provide new versioned models that aren't already available via their qemu alias. Jonathon Jongsma (9): cpu_map: update script to generate versioned CPUs cpu_map: Add versioned EPYC CPUs cpu_map: Add versioned Intel Skylake CPUs cpu_map: Add versioned Intel Cascadelake CPUs cpu_map: Add versioned Intel Icelake CPUs cpu_map: Add versioned Intel Cooperlake CPUs cpu_map: Add versioned Intel Snowridge CPUs cpu_map: Add versioned Intel SapphireRapids CPUs cpu_map: Add versioned Dhyana CPUs src/cpu_map/index.xml | 22 +++ src/cpu_map/meson.build | 22 +++ src/cpu_map/sync_qemu_models_i386.py | 44 ++++-- src/cpu_map/x86_Cascadelake-Server-v2.xml | 93 +++++++++++++ src/cpu_map/x86_Cascadelake-Server-v4.xml | 91 +++++++++++++ src/cpu_map/x86_Cascadelake-Server-v5.xml | 92 +++++++++++++ src/cpu_map/x86_Cooperlake-v2.xml | 98 ++++++++++++++ src/cpu_map/x86_Dhyana-v2.xml | 81 ++++++++++++ src/cpu_map/x86_EPYC-Milan-v2.xml | 108 +++++++++++++++ src/cpu_map/x86_EPYC-Rome-v2.xml | 93 +++++++++++++ src/cpu_map/x86_EPYC-Rome-v3.xml | 95 +++++++++++++ src/cpu_map/x86_EPYC-Rome-v4.xml | 94 +++++++++++++ src/cpu_map/x86_EPYC-v3.xml | 87 ++++++++++++ src/cpu_map/x86_EPYC-v4.xml | 88 ++++++++++++ src/cpu_map/x86_Icelake-Server-v3.xml | 103 +++++++++++++++ src/cpu_map/x86_Icelake-Server-v4.xml | 108 +++++++++++++++ src/cpu_map/x86_Icelake-Server-v5.xml | 109 +++++++++++++++ src/cpu_map/x86_Icelake-Server-v6.xml | 109 +++++++++++++++ src/cpu_map/x86_SapphireRapids-v2.xml | 125 ++++++++++++++++++ src/cpu_map/x86_Skylake-Client-v4.xml | 77 +++++++++++ src/cpu_map/x86_Skylake-Server-v4.xml | 83 ++++++++++++ src/cpu_map/x86_Skylake-Server-v5.xml | 85 ++++++++++++ src/cpu_map/x86_Snowridge-v2.xml | 78 +++++++++++ src/cpu_map/x86_Snowridge-v3.xml | 80 +++++++++++ src/cpu_map/x86_Snowridge-v4.xml | 78 +++++++++++ .../x86_64-cpuid-Atom-P5362-guest.xml | 3 +- .../x86_64-cpuid-Atom-P5362-json.xml | 3 +- .../x86_64-cpuid-Cooperlake-host.xml | 3 +- .../x86_64-cpuid-EPYC-7502-32-Core-host.xml | 5 +- .../x86_64-cpuid-EPYC-7601-32-Core-guest.xml | 9 +- ...6_64-cpuid-EPYC-7601-32-Core-ibpb-host.xml | 8 +- ..._64-cpuid-Hygon-C86-7185-32-core-guest.xml | 5 +- ...6_64-cpuid-Hygon-C86-7185-32-core-host.xml | 5 +- ...6_64-cpuid-Hygon-C86-7185-32-core-json.xml | 6 +- ...4-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-8268-guest.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-8268-host.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-9242-guest.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-9242-host.xml | 9 +- .../x86_64-cpuid-Xeon-Platinum-9242-json.xml | 9 +- ..._64-cpuid-baseline-Cascadelake+Icelake.xml | 9 +- ...-cpuid-baseline-Cooperlake+Cascadelake.xml | 9 +- ...6_64-cpuid-baseline-Cooperlake+Icelake.xml | 9 +- .../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 2 + .../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 2 + tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 2 + .../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 4 + .../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 4 + tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 4 + .../domaincapsdata/qemu_5.1.0-q35.x86_64.xml | 7 + .../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 7 + tests/domaincapsdata/qemu_5.1.0.x86_64.xml | 7 + .../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 7 + .../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 7 + tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 7 + .../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 8 ++ .../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 8 ++ tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 8 ++ .../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 15 +++ .../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 15 +++ tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 15 +++ .../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 16 +++ .../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 16 +++ tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 16 +++ .../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 17 +++ .../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 17 +++ tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 17 +++ .../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 17 +++ .../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 17 +++ tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 17 +++ .../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 17 +++ .../qemu_7.2.0-tcg.x86_64+hvf.xml | 17 +++ .../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 17 +++ tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 17 +++ .../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 17 +++ .../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 17 +++ tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 17 +++ .../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 27 +++- .../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 22 +++ tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 27 +++- .../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 27 +++- .../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 22 +++ tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 27 +++- ...-host-model-fallback-kvm.x86_64-8.1.0.args | 2 +- ...host-model-fallback-kvm.x86_64-latest.args | 2 +- .../cpu-host-model-kvm.x86_64-8.1.0.args | 2 +- .../cpu-host-model-kvm.x86_64-latest.args | 2 +- ...ost-model-nofallback-kvm.x86_64-8.1.0.args | 2 +- ...st-model-nofallback-kvm.x86_64-latest.args | 2 +- 89 files changed, 2710 insertions(+), 123 deletions(-) create mode 100644 src/cpu_map/x86_Cascadelake-Server-v2.xml create mode 100644 src/cpu_map/x86_Cascadelake-Server-v4.xml create mode 100644 src/cpu_map/x86_Cascadelake-Server-v5.xml create mode 100644 src/cpu_map/x86_Cooperlake-v2.xml create mode 100644 src/cpu_map/x86_Dhyana-v2.xml create mode 100644 src/cpu_map/x86_EPYC-Milan-v2.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v2.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v3.xml create mode 100644 src/cpu_map/x86_EPYC-Rome-v4.xml create mode 100644 src/cpu_map/x86_EPYC-v3.xml create mode 100644 src/cpu_map/x86_EPYC-v4.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v3.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v4.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v5.xml create mode 100644 src/cpu_map/x86_Icelake-Server-v6.xml create mode 100644 src/cpu_map/x86_SapphireRapids-v2.xml create mode 100644 src/cpu_map/x86_Skylake-Client-v4.xml create mode 100644 src/cpu_map/x86_Skylake-Server-v4.xml create mode 100644 src/cpu_map/x86_Skylake-Server-v5.xml create mode 100644 src/cpu_map/x86_Snowridge-v2.xml create mode 100644 src/cpu_map/x86_Snowridge-v3.xml create mode 100644 src/cpu_map/x86_Snowridge-v4.xml -- 2.41.0

2 11

[PATCH] remote: Fix cached hypervisor type
by Jim Fehlig 08 Dec '23

08 Dec '23

Commit 501825011c switched the remote driver to using g_auto, but missed one case of needing to steal a pointer holding the hypervisor type. Without it, memory is freed and the output of 'virsh version' has random output Compiled against library: libvirt 10.0.0 Using library: libvirt 10.0.0 Using API: ��%�U 10.0.0 Running hypervisor: ��U 8.1.3 Ths change also fixes random SIGABRT from perl processes running libvirt-tck tests. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/remote/remote_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index c4831db6cd..132d0194c6 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -1408,7 +1408,7 @@ remoteConnectGetType(virConnectPtr conn) return NULL; /* Stash. */ - return priv->type = ret.type; + return priv->type = g_steal_pointer(&ret.type); } static int remoteConnectIsSecure(virConnectPtr conn) -- 2.43.0

2 1

[PATCH 0/8] migration fixes for non-shared storage migration
by Peter Krempa 07 Dec '23

07 Dec '23

Peter Krempa (8): qemuMigrationDstPrecreateStorage: Improve error messages qemuMigrationDstPrecreateStorage: Refactor cleanup qemuMigrationDstPrecreateStorage: Fix and clarify logic qemu: migration: Improve handling of VIR_MIGRATE_PARAM_DEST_XML with VIR_MIGRATE_PERSIST_DEST qemuDomainStorageOpenStat: Remove unused 'driver' argument and untangle callers qemu: migration: Rename qemuMigrationDstPrecreateStorage to qemuMigrationDstPrepareStorage qemu: Move and export qemuDomainStorageUpdatePhysical and dependencies qemu: migration: Automatically fix non-shared-storage migration to bigger block devices src/qemu/qemu_domain.c | 114 +++++++++++++++++++++++++++++ src/qemu/qemu_domain.h | 16 ++++ src/qemu/qemu_driver.c | 149 ++++---------------------------------- src/qemu/qemu_migration.c | 146 +++++++++++++++++++++++++++---------- 4 files changed, 249 insertions(+), 176 deletions(-) -- 2.43.0

2 9

[PATCH 0/3] nodedev: Storage device size fixes
by Peter Krempa 07 Dec '23

07 Dec '23

Peter Krempa (3): virNodeDeviceCapStorageDefFormat: Don't check argument for virBufferEscapeString virNodeDeviceCapStorageDefFormat: Extract formatting of block size data virNodeDeviceCapStorageDefFormatBlocksize: Report sector size and count together src/conf/node_device_conf.c | 65 +++++++++++++++---------------------- 1 file changed, 27 insertions(+), 38 deletions(-) -- 2.43.0

2 4

[PATCH v1] qemu_driver: Don't handle the EOF event if monitor changed
by tugy＠chinatelecom.cn 07 Dec '23

07 Dec '23

From: Guoyi Tu <tugy(a)chinatelecom.cn> Currently, libvirt creates a thread pool with only on thread to handle all qemu monitor events for virtual machines, In the cases that if the thread gets stuck while handling a monitor EOF event, such as unable to kill the virtual machine process or release resources, the events of other virtual machine will be also blocked, which will lead to the abnormal behavior of other virtual machines. For instance, when another virtual machine completes a shutdown operation and the monitor EOF event has been queued but remains unprocessed, we immediately destroy and start the virtual machine again, at a later time when EOF event get processed, the processMonitorEOFEvent() will kill the virtual machine that just started. To address this issue, in the processMonitorEOFEvent(), we check whether the current virtual machine's monitor object matches the one at the time the event was generated. If they do not match, we immediately return. Signed-off-by: Guoyi Tu <tugy(a)chinatelecom.cn> Signed-off-by: dengpengcheng <dengpc12(a)chinatelecom.cn> --- src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_driver.c | 11 +++++++++-- src/qemu/qemu_process.c | 2 +- 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 953808fcfe..435ee621df 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -11470,7 +11470,6 @@ qemuProcessEventFree(struct qemuProcessEvent *event) case QEMU_PROCESS_EVENT_NETDEV_STREAM_DISCONNECTED: case QEMU_PROCESS_EVENT_NIC_RX_FILTER_CHANGED: case QEMU_PROCESS_EVENT_SERIAL_CHANGED: - case QEMU_PROCESS_EVENT_MONITOR_EOF: case QEMU_PROCESS_EVENT_GUEST_CRASHLOADED: g_free(event->data); break; @@ -11484,6 +11483,7 @@ qemuProcessEventFree(struct qemuProcessEvent *event) case QEMU_PROCESS_EVENT_UNATTENDED_MIGRATION: case QEMU_PROCESS_EVENT_RESET: case QEMU_PROCESS_EVENT_NBDKIT_EXITED: + case QEMU_PROCESS_EVENT_MONITOR_EOF: case QEMU_PROCESS_EVENT_LAST: break; } diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index d00d2a27c6..57acafb48b 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -3854,7 +3854,8 @@ processJobStatusChangeEvent(virDomainObj *vm, static void processMonitorEOFEvent(virQEMUDriver *driver, - virDomainObj *vm) + virDomainObj *vm, + qemuMonitor *mon) { qemuDomainObjPrivate *priv = vm->privateData; int eventReason = VIR_DOMAIN_EVENT_STOPPED_SHUTDOWN; @@ -3863,6 +3864,12 @@ processMonitorEOFEvent(virQEMUDriver *driver, unsigned int stopFlags = 0; virObjectEvent *event = NULL; + if (priv->mon != mon) { + VIR_DEBUG("Domain %p '%s' has been shutdown, ignoring EOF", + vm, vm->def->name); + return; + } + if (qemuProcessBeginStopJob(vm, VIR_JOB_DESTROY, true) < 0) return; @@ -4082,7 +4089,7 @@ static void qemuProcessEventHandler(void *data, void *opaque) processJobStatusChangeEvent(vm, processEvent->data); break; case QEMU_PROCESS_EVENT_MONITOR_EOF: - processMonitorEOFEvent(driver, vm); + processMonitorEOFEvent(driver, vm, processEvent->data); break; case QEMU_PROCESS_EVENT_PR_DISCONNECT: processPRDisconnectEvent(vm); diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index f32e82bbd1..ff54e947fe 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -316,7 +316,7 @@ qemuProcessHandleMonitorEOF(qemuMonitor *mon, } qemuProcessEventSubmit(vm, QEMU_PROCESS_EVENT_MONITOR_EOF, - 0, 0, NULL); + 0, 0, priv->mon); /* We don't want this EOF handler to be called over and over while the * thread is waiting for a job. -- 2.17.1

3 3

[PATCH] network: fix check in virNetworkLoadConfig
by Anastasia Belova 07 Dec '23

07 Dec '23

virFileLinkPointsTo return non-zero value on fail. This value may be positive or negative, so check should be != 0. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bddbda99df ("network: Introduce virnetworkobj") Signed-off-by: Anastasia Belova <abelova(a)astralinux.ru> --- src/conf/virnetworkobj.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/conf/virnetworkobj.c b/src/conf/virnetworkobj.c index 20ee8eb58a..47658986e8 100644 --- a/src/conf/virnetworkobj.c +++ b/src/conf/virnetworkobj.c @@ -945,7 +945,7 @@ virNetworkLoadConfig(virNetworkObjList *nets, if ((autostartLink = virNetworkConfigFile(autostartDir, name)) == NULL) return NULL; - if ((autostart = virFileLinkPointsTo(autostartLink, configFile)) < 0) + if ((autostart = virFileLinkPointsTo(autostartLink, configFile)) != 0) return NULL; if (!(def = virNetworkDefParse(NULL, configFile, xmlopt, false))) -- 2.30.2

3 3

[PATCH] security_util: fix log in virSecurityMoveRememberedLabel
by Anastasia Belova 07 Dec '23

07 Dec '23

Fix incorrect log message for timestamp value. Probably this line was copied from the check for attr. Found by Linux Verification Center (linuxtesting.org) Fixes: 7cfb7aab57 ("security_util: Remove stale XATTRs") Signed-off-by: Anastasia Belova <abelova(a)astralinux.ru> --- src/security/security_util.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/security/security_util.c b/src/security/security_util.c index a4e6687561..b96b4ccb1f 100644 --- a/src/security/security_util.c +++ b/src/security/security_util.c @@ -502,7 +502,7 @@ virSecurityMoveRememberedLabel(const char *name, } else if (errno != ENODATA) { virReportSystemError(errno, _("Unable to get XATTR %1$s on %2$s"), - attr_name, src); + timestamp_name, src); return -1; } } -- 2.30.2

2 1

[libvirt PATCH] test: remove redundant cpuTestGuestCPUID test
by Jonathon Jongsma 06 Dec '23

06 Dec '23

DO_TEST_CPUID(arch, host, json) is a multipart test. It consists of the following tests: - cpuTestHostCPUID() - cpuTestGuestCPUID(with JSON_* flag) - cpuTestCPUIDSignature() - DO_TEST_JSON(): - if json==JSON_MODELS: - cpuTestGuestCPUID(without JSON_* flag) - cpuTestJSONCPUID() - cputestJSONSignature() Notice that for tests with json==JSON_MODELS, cpuTestGuestCPUID() is actually called twice but with different arguments. The first one passes JSON_MODELS to the test function, while the second one passes 0. The main difference in behavior when calling cpuTestGuestCPUID() with or without the flag is that in the first case, it parses the captured qemu output from $ARCH-cpuid-$CPU.json. It extracts the cpu model list from that JSON, and uses that to filter out possible cpu models to match. In other words, it tries to match the cpu to a model that was supported by the qemu version that was used to generate this JSON file. When it finds a match, it generates a cpu definition and compares the xml form of that definition with the file $ARCH-cpuid-$CPU-guest.xml. When called without the JSON_MODELS flag, it simply attempts to match it against the full libvirt cpu map and doesn't attempt to filter out any matches based on the JSON qemu cpu model list. After it finds a match, it generates an xml definition for the cpu and compares it to the same file listed above. So if these two invocations disagree on the cpu match (e.g. because libvirt has added a cpu model to its cpu map that matches better than one that was supported by the version of qemu that generated the JSON file) the test will fail. This duplicate call to cpuTestGuestCPUID() was originally added in commit 49c945a6f5c885394507f88086cc2f9461df7c27. The original justification for that commit was to fix test failures when the Qemu driver was disabled. But since DO_TEST_JSON() is #defined empty when qemu is disabled, this particular invocation would not even be executed in this scenario, so it doesn't seem relevant. Signed-off-by: Jonathon Jongsma <jjongsma(a)redhat.com> --- tests/cputest.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/tests/cputest.c b/tests/cputest.c index b3253e3116..93cd0e12a7 100644 --- a/tests/cputest.c +++ b/tests/cputest.c @@ -993,10 +993,6 @@ mymain(void) #if WITH_QEMU # define DO_TEST_JSON(arch, host, json) \ do { \ - if (json == JSON_MODELS) { \ - DO_TEST(arch, cpuTestGuestCPUID, host, host, \ - NULL, NULL, 0, NULL, 0, 0); \ - } \ if (json != JSON_NONE) { \ DO_TEST(arch, cpuTestJSONCPUID, host, host, \ NULL, NULL, 0, NULL, json, 0); \ -- 2.41.0

2 1

[libvirt PATCH v2] rpc: don't try to spawn non-existant daemon
by Daniel P. Berrangé 06 Dec '23

06 Dec '23

If libvirt is built in client only mode, the libvirtd/virtqemud/etc daemons won't exist. If the client is told to connect to a local hypervisor, it'll see the socket doesn't exist, try to spawn the daemon and then re-try connecting to the socket for a few seconds. Ultimately this will fail because the daemon doesn't exist and the user gets an error message error: Failed to connect socket to '/run/user/1000/libvirt/virtqemud-sock': No such file or directory technically this is accurate, but it doesn't help identify the root cause. With this change it will now report error: binary 'virtqemud' does not exist in $PATH: No such file or directory and will skip all the socket connect retries Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com> --- Last time it was suggested that virCommandGetBinaryPath could be extended to always check whether the binary exists. I started doing that and realized it was a bad idea as this method runs in a context which might not have permission to access to the binary we are about to run, as we've not changed user/group ID yet. So I'm re-posting this targetted fix, with format string fixup. src/rpc/virnetsocket.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/src/rpc/virnetsocket.c b/src/rpc/virnetsocket.c index b58f7a6b8f..0215c99c73 100644 --- a/src/rpc/virnetsocket.c +++ b/src/rpc/virnetsocket.c @@ -123,9 +123,19 @@ VIR_ONCE_GLOBAL_INIT(virNetSocket); #ifndef WIN32 static int virNetSocketForkDaemon(const char *binary) { - g_autoptr(virCommand) cmd = virCommandNewArgList(binary, - "--timeout=120", - NULL); + g_autofree char *binarypath = virFindFileInPath(binary); + g_autoptr(virCommand) cmd = NULL; + + if (!binarypath) { + virReportSystemError(ENOENT, + _("binary '%1$s' does not exist in $PATH"), + binary); + return -1; + } + + cmd = virCommandNewArgList(binarypath, + "--timeout=120", + NULL); virCommandAddEnvPassCommon(cmd); virCommandAddEnvPass(cmd, "XDG_CACHE_HOME"); -- 2.41.0

2 1

[PATCH] virsh: migrate: Fix logic bug in interlock of --copy-storage-synchronous-writes flag
by Peter Krempa 06 Dec '23

06 Dec '23

As the error message states we want to check that one of '--copy-storage-all' or '--copy-storage-inc' is used, but the condition mentioned VIR_MIGRATE_NON_SHARED_DISK twice. Fixes: 1c2bd205edd Resolves: https://issues.redhat.com/browse/RHEL-17596 Signed-off-by: Peter Krempa <pkrempa(a)redhat.com> --- tools/virsh-domain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 66f933dead..f7784b46e9 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -11194,7 +11194,7 @@ doMigrate(void *opaque) } if (flags & VIR_MIGRATE_NON_SHARED_SYNCHRONOUS_WRITES && - !(flags & (VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHARED_DISK))) { + !(flags & (VIR_MIGRATE_NON_SHARED_DISK | VIR_MIGRATE_NON_SHARED_INC))) { vshError(ctl, "'--copy-storage-synchronous-writes' requires one of '--copy-storage-all', '--copy-storage-inc'"); goto out; } -- 2.43.0

2 1