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