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

Marc Hartmayer mhartmay at linux.ibm.com
Mon Nov 12 14:50:03 UTC 2018


On Mon, Nov 12, 2018 at 03:13 PM +0100, "Daniel P. Berrangé" <berrange at redhat.com> wrote:
> 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.

Yep, you’re right. The use of “broken” was clearly exaggerated by me.

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

For this patch as well?

>
> 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 :|
>
--
Kind regards / Beste Grüße
   Marc Hartmayer

IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294





More information about the libvir-list mailing list