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.

The good thing is that at that point all defaults should be already
filled in so it should not matter much whether capabilities are present.

Other than that, I agree. Checking stuff uprfront is usually better than
get to the situation when it fails to start.

Attachment: signature.asc
Description: PGP signature

libvir-list mailing list

Reply via email to