[PATCH] qemu: Validate domain definition even on migration

[Peter Krempa]

On Mon, Jan 31, 2022 at 13:34:29 +0100, Michal Privoznik wrote:
> When we are about to spawn QEMU, we validate the domain
> definition against qemuCaps. Except when domain is/was already
> running before (i.e. on incoming migration, snapshots, resume
> from a file). However, especially on incoming migration it may
> happen that the destination QEMU is different to the source
> QEMU, e.g. the destination QEMU may have some devices disabled.
> 
> And we have a function that validates devices/features requested
> in domain XML against the desired QEMU capabilities (aka
> qemuCaps) - it's virDomainDefValidate() which calls
> qemuValidateDomainDef() and qemuValidateDomainDeviceDef()
> subsequently.
> 
> But the problem here is that the validation function is
> explicitly skipped over in specific scenarios (like incoming
> migration, restore from a snapshot or previously saved file).
> 
> This in turn means that we may spawn QEMU and request
> device/features it doesn't support. When that happens QEMU fails
> to load migration stream:
> 
>   qemu-kvm: ... 'virtio-mem-pci' is not a valid device model name
> 
> (NB, while the example shows one particular device, the problem
> is paramount)
> 
> This problem is easier to run into since we are slowly moving
> validation from qemu_command.c into said validation functions.
> 
> The solution is simple: do the validation in all cases. And while
> it may happen that users would be unable to migrate/restore a
> guest due to a bug in our validator, spawning QEMU without
> validation is worse (especially when you consider that users can
> supply their own XMLs for migrate/restore operations - these were
> never validated).
> 
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2048435
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---

IIRC the original idea was to be safe but at that point we didn't yet
move checks from the commandline generator, just from the parser.

Reviewed-by: Peter Krempa <pkrempa at redhat.com>