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