[libvirt PATCH] qemu: fixing auto-detecting binary in domain capabilities
Daniel P. Berrangé
berrange at redhat.com
Fri Jan 17 14:13:46 UTC 2020
On Fri, Jan 17, 2020 at 02:54:53PM +0100, Ján Tomko wrote:
> On Fri, Jan 17, 2020 at 01:29:36PM +0000, Daniel P. Berrangé wrote:
> > The virConnectGetDomainCapabilities API accepts either a binary path
> > to the emulator, or desired guest arch. If guest arch is not given,
> > then the host arch is assumed.
> >
> > In the case where the binary is not given, the code tried to find the
> > emulator binary in the existing list of cached emulator capabilities.
> > This is not valid since we switched to lazy population of the cache in:
> >
> > commit 3dd91af01f30c5bda6328454ef49f3afece755d6
> > Author: Daniel P. Berrangé <berrange at redhat.com>
> > Date: Mon Dec 2 13:04:26 2019 +0000
> >
> > qemu: stop creating capabilities at driver startup
> >
> > As a result of this change, if there are no persistent guests defined
> > using the requested guest architecture, virConnectGetDomainCapabilities
> > will fail to find an emulator binary.
> >
> > The solution is to stop relying on the cached capabilities to find the
> > binary and instead use the same logic we use to pick default a binary
> > per arch when populating capabilities.
> >
>
> This does fix the problem for machines with no persistent guests, but
> breaks domcapabilities for machines where there is no QEMU in the
> default location - before this patch I'd get domcapabilities for /usr/libexec/qemu-git
> (taken from the persistent config), after I get an error:
> error: failed to get emulator capabilities
> error: Cannot check QEMU binary /usr/libexec/qemu-kvm: No such file or directory
>
> Should we keep the cache lookup as a fallback or vice-versa?
Hmm, I think it is probably undesirable for the results of this
API to vary depending on whether you happened to have defined a
guest config. IOW, this difference is probably a good thing and
we should clarify that if no binary is passed, we're only looking
in the default location.
> > @@ -5299,31 +5301,25 @@ virQEMUCapsCacheLookupDefault(virFileCachePtr cache,
> > goto cleanup;
> > }
> >
> > - if (binary) {
> > - virArch arch_from_caps;
> > + if (!binary)
> > + binary = virQEMUCapsGetDefaultEmulator(hostarch, arch);
>
> virQEMUCapsGetDefaultEmulator returns an allocated string so it needs to
> be freed.
Opps, yes.
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 :|
More information about the libvir-list
mailing list