On 02/19/2018 04:29 AM, Andrea Bolognani wrote: > On Mon, 2018-02-19 at 07:24 +0100, Peter Krempa wrote: >> On Fri, Feb 16, 2018 at 17:28:03 +0100, Andrea Bolognani wrote: >>> Validate time is a bit too early to check whether the required >>> capabilities are available, since the QEMU binary might have >>> been updated or replaced by the time we are asked to run the >>> guest. >> >> So are you having problem with the fact that the definition will be >> rejected right away and not just when you try to start it? >> >> Validate is re-run when starting the VM so a downgrade is handled >> properly. > > Right, but isn't checking for QEMU capabilities at validate time > unreasonably strict? A guest which uses eg. an invalid combination > of machine type and architecture will never become valid at a later > point, but a guest should not be considered invalid just because > the QEMU binary you happened to have installed at the time you > defined it lacked some features - the guest itself is perfectly > valid, it just can't be run :) > IIRC - the decision processing I used for moving the capability checking into Validation for controller options (PCI, SCSI, USB, SATA) was because at least qemuDomainDefValidateMemoryHotplug already had failure paths when capabilities weren't set. Undoing PCI would perhaps mean quite a few more places that need adjustment to get that bald yak. As for the question of "unreasonably strict" at Validation time - isn't a purpose of Validation to ensure certain combinations that were defined would work together properly? It just so happens that using certain combinations of options with a specific version of a binary could be that type of check. Although I do see your point. Personally I'd rather get something "right" when defining it rather than find out later - it's one of those - well why didn't you tell me that before type gripes. John -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
