[libvirt] [PATCH v2] qemu: Introduce caching whether /dev/kvm is accessible

[Daniel P. Berrangé]

On Mon, Nov 12, 2018 at 02:48:09PM +0100, Marc Hartmayer wrote:
> On Mon, Nov 12, 2018 at 01:30 PM +0100, Pavel Hrdina <phrdina at redhat.com> wrote:
> > On Mon, Nov 12, 2018 at 12:50:41PM +0100, Marc Hartmayer wrote:
> >> On Thu, Nov 01, 2018 at 09:31 AM +0100, Martin Kletzander <mkletzan at redhat.com> wrote:
> >
> > [...]
> >
> >> How can you run a machine/QEMU VM under a different user:group other
> >> than changing the user:group in qemu.conf and restart/reload libvirtd?
> >>
> >> As soon as a VM is running we have not to verify /dev/kvm access, no?
> >> (so there should be no problem when libvirtd tries to “reconnect” to
> >> already running VMs).
> >
> > You can add this into your domain XML:
> >
> >   <seclabel type='static' model='dac' relabel='yes'>
> >     <label>phrdina:phrdina</label>
> >   </seclabel>
> >
> > And it will run the qemu process under that user.
> 
> Interesting :) Actually, if we consider this then the QEMU caps caching
> is broken anyway since 'virQEMUCapsNewData' is calling
> 'virQEMUCapsNewForBinaryInternal(…, priv->runUid, priv->runGid, …)'.
> 
> And 'priv->runUid/runGid' is only set once in virQEMUCapsCacheNew.
> 
> Maybe I missed something.

I dont think it is really broken - it merely impacts error reporting.

When running 'virsh capabilities' we are trying to figure out if
KVM is usable on the host. This is always using the default uid/gid
so gives a fairly coarse answer, but the answer is correct for most
common usage.

When building command line ARGV for spawning a specific QEMU
instance, the KVM capability merely affect whether libvirt
reports an error  about the guest config. In the case where
the capability works with default uid/gid, but breaks with the
custom per-VM  uid/gid, libvirt will mistakenly thing KVM is
usable and so launch the guest. QEMU will then be unable to
access it and quit with some suitable error message.

So the "brokenness" about not using the per-VM uid/gid merely
delays the error reporting.  I don't think this is important
enough to worry about, using the default uid/gid is sufficient.

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 :|