render / rpms / libvirt

Forked from rpms/libvirt 9 months ago
Clone
735c6b
From dd64ec40a29739464cfe886818588bb9946b8d8d Mon Sep 17 00:00:00 2001
735c6b
Message-Id: <dd64ec40a29739464cfe886818588bb9946b8d8d@dist-git>
735c6b
From: Michal Privoznik <mprivozn@redhat.com>
735c6b
Date: Fri, 27 Jan 2023 13:59:08 +0100
735c6b
Subject: [PATCH] qemuProcessLaunch: Tighten rules for external devices wrt
735c6b
 incoming migration
735c6b
MIME-Version: 1.0
735c6b
Content-Type: text/plain; charset=UTF-8
735c6b
Content-Transfer-Encoding: 8bit
735c6b
735c6b
When starting a guest, helper processes are started first. But
735c6b
they need a bit of special handling. Just consider a regular cold
735c6b
boot and an incoming migration. For instance, in case of swtpm
735c6b
with its state on a shared volume, we want to set label on the
735c6b
state for the cold boot case, but don't want to touch the label
735c6b
in case of incoming migration (because the source very
735c6b
specifically did not restore it either).
735c6b
735c6b
Until now, these two cases were differentiated by testing
735c6b
@incoming against NULL. And while that makes sense for other
735c6b
aspects of domain startup, for external devices we need a bit
735c6b
more, because a restore from a save file is also 'incoming
735c6b
migration'.
735c6b
735c6b
Now, there is a difference between regular migration and restore
735c6b
from a save file. In the former case we do not want to set
735c6b
seclabels in the save state. BUT, in the latter case we do need
735c6b
to set them, because the code that saves the machine restored
735c6b
seclabels.
735c6b
735c6b
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2161557
735c6b
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
735c6b
Reviewed-by: Ján Tomko <jtomko@redhat.com>
735c6b
(cherry picked from commit 5c4007ddc6c29632b5cc96ab4ef81ebb7797d1bb)
735c6b
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
735c6b
---
735c6b
 src/qemu/qemu_process.c | 9 ++++++++-
735c6b
 1 file changed, 8 insertions(+), 1 deletion(-)
735c6b
735c6b
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
735c6b
index 2de87211fb..1217fb1856 100644
735c6b
--- a/src/qemu/qemu_process.c
735c6b
+++ b/src/qemu/qemu_process.c
735c6b
@@ -7620,6 +7620,7 @@ qemuProcessLaunch(virConnectPtr conn,
735c6b
     size_t nnicindexes = 0;
735c6b
     g_autofree int *nicindexes = NULL;
735c6b
     unsigned long long maxMemLock = 0;
735c6b
+    bool incomingMigrationExtDevices = false;
735c6b
 
735c6b
     VIR_DEBUG("conn=%p driver=%p vm=%p name=%s id=%d asyncJob=%d "
735c6b
               "incoming.uri=%s "
735c6b
@@ -7674,7 +7675,13 @@ qemuProcessLaunch(virConnectPtr conn,
735c6b
     if (qemuDomainSchedCoreStart(cfg, vm) < 0)
735c6b
         goto cleanup;
735c6b
 
735c6b
-    if (qemuExtDevicesStart(driver, vm, incoming != NULL) < 0)
735c6b
+    /* For external devices the rules of incoming migration are a bit stricter,
735c6b
+     * than plain @incoming != NULL. They need to differentiate between
735c6b
+     * incoming migration and restore from a save file.  */
735c6b
+    incomingMigrationExtDevices = incoming &&
735c6b
+        vmop == VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_START;
735c6b
+
735c6b
+    if (qemuExtDevicesStart(driver, vm, incomingMigrationExtDevices) < 0)
735c6b
         goto cleanup;
735c6b
 
735c6b
     if (!(cmd = qemuBuildCommandLine(vm,
735c6b
-- 
735c6b
2.39.1
735c6b