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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
