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@xxxxxxxxxx> > --- 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@xxxxxxxxxx>
