render / rpms / libvirt

Forked from rpms/libvirt 9 months ago
Clone
1b87cf
From fa7cff4e684ededd184976d4fdf217cc155825b8 Mon Sep 17 00:00:00 2001
1b87cf
Message-Id: <fa7cff4e684ededd184976d4fdf217cc155825b8@dist-git>
1b87cf
From: Michal Privoznik <mprivozn@redhat.com>
1b87cf
Date: Mon, 31 Jan 2022 12:55:47 +0100
1b87cf
Subject: [PATCH] qemu: Validate domain definition even on migration
1b87cf
1b87cf
When we are about to spawn QEMU, we validate the domain
1b87cf
definition against qemuCaps. Except when domain is/was already
1b87cf
running before (i.e. on incoming migration, snapshots, resume
1b87cf
from a file). However, especially on incoming migration it may
1b87cf
happen that the destination QEMU is different to the source
1b87cf
QEMU, e.g. the destination QEMU may have some devices disabled.
1b87cf
1b87cf
And we have a function that validates devices/features requested
1b87cf
in domain XML against the desired QEMU capabilities (aka
1b87cf
qemuCaps) - it's virDomainDefValidate() which calls
1b87cf
qemuValidateDomainDef() and qemuValidateDomainDeviceDef()
1b87cf
subsequently.
1b87cf
1b87cf
But the problem here is that the validation function is
1b87cf
explicitly skipped over in specific scenarios (like incoming
1b87cf
migration, restore from a snapshot or previously saved file).
1b87cf
1b87cf
This in turn means that we may spawn QEMU and request
1b87cf
device/features it doesn't support. When that happens QEMU fails
1b87cf
to load migration stream:
1b87cf
1b87cf
  qemu-kvm: ... 'virtio-mem-pci' is not a valid device model name
1b87cf
1b87cf
(NB, while the example shows one particular device, the problem
1b87cf
is paramount)
1b87cf
1b87cf
This problem is easier to run into since we are slowly moving
1b87cf
validation from qemu_command.c into said validation functions.
1b87cf
1b87cf
The solution is simple: do the validation in all cases. And while
1b87cf
it may happen that users would be unable to migrate/restore a
1b87cf
guest due to a bug in our validator, spawning QEMU without
1b87cf
validation is worse (especially when you consider that users can
1b87cf
supply their own XMLs for migrate/restore operations - these were
1b87cf
never validated).
1b87cf
1b87cf
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2048435
1b87cf
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
1b87cf
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
1b87cf
(cherry picked from commit 517b8c12b98d7ac0bb4d582e0b491d50d776eb6d)
1b87cf
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2050702
1b87cf
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
1b87cf
---
1b87cf
 src/qemu/qemu_process.c | 6 +-----
1b87cf
 1 file changed, 1 insertion(+), 5 deletions(-)
1b87cf
1b87cf
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
1b87cf
index 5c9ca0fe4f..5c6657a876 100644
1b87cf
--- a/src/qemu/qemu_process.c
1b87cf
+++ b/src/qemu/qemu_process.c
1b87cf
@@ -5411,11 +5411,7 @@ qemuProcessStartValidate(virQEMUDriver *driver,
1b87cf
 
1b87cf
     }
1b87cf
 
1b87cf
-    /* Checks below should not be executed when starting a qemu process for a
1b87cf
-     * VM that was running before (migration, snapshots, save). It's more
1b87cf
-     * important to start such VM than keep the configuration clean */
1b87cf
-    if ((flags & VIR_QEMU_PROCESS_START_NEW) &&
1b87cf
-        virDomainDefValidate(vm->def, 0, driver->xmlopt, qemuCaps) < 0)
1b87cf
+    if (virDomainDefValidate(vm->def, 0, driver->xmlopt, qemuCaps) < 0)
1b87cf
         return -1;
1b87cf
 
1b87cf
     if (qemuProcessStartValidateGraphics(vm) < 0)
1b87cf
-- 
1b87cf
2.35.1
1b87cf