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.


libvir-list mailing list

Reply via email to