[libvirt] [PATCH v2 06/15] qemu: Defer capability check to command line generation time

[Daniel P. Berrangé]

On Mon, Feb 19, 2018 at 02:13:14PM +0100, Peter Krempa wrote:
> On Mon, Feb 19, 2018 at 13:04:08 +0000, Daniel Berrange wrote:
> > On Mon, Feb 19, 2018 at 10:29:18AM +0100, 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 :)
> > 
> > Given that we increasingly fill in alot of information in the XML at define
> > time, we already have a general expectation that the QEMU binary will  be
> > present at define time. I think this is not unreasonable - we suggest apps
> > call virConnectGetCapabilities and/or virDomainGetCapabilities to understand
> > what is installed/available before creating an XML document to define. Those
> > APIs of course require binaries to be installed too.   So I don't think we
> > should really put effort into coping with defining XML for a time when the
> > QEMU binaries aren't installed.  Such a scenario is so unlikely to be hit
> > that any code trying to cope with that is going to be largely untested and
> > fragile, so it would be a disservice to pretend it'll be something worth
> > relying on.
> 
> The only situation when we should not fail if QEMU is not installed and
> you restart libvirtd. Making defined domains disappear is bad.

A long time back we did have a patch series somewhere that tried to
keep domain's loaded, but mark them as "broken" if the QEMU we needed
was missing. Can't remember why we never went further with it now...

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|