Re: [libvirt] [PATCH v2 06/15] qemu: Defer capability check to command line generation time
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