On Mon, Feb 19, 2018 at 13:21:35 +0000, Daniel Berrange wrote:
> 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...

Well in the meanwhile I've made qemuCaps in the PostParse callbacks
optional and it's re-run in such case on startup of the VM. The
validation callbacks are not run when parsing status/config XMLs so it
should mostly work right now properly. (at least it fixed my case when
my binaries failed to exec due to broken deps)

Attachment: signature.asc
Description: PGP signature

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to