On Mon, Nov 12, 2018 at 03:13 PM +0100, "Daniel P. Berrangé" <berrange@xxxxxxxxxx> 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@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. 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list