Univention Bugzilla – Bug 45886
libvirt-qemu local uid gid number depends on installation order
Last modified: 2019-10-29 10:55:48 CET
The local id of the group and user libvirt-qemu depends on the installation order of packages/the software components selected during the installation. So it is possible to end up with two kvm servers with different uid, gid numbers for libvirt-qemu and that is not good if the servers share a image pool and for live migration.
AFAIK libvirtd does the re-owning: /etc/libvirt/qemu.conf: dynamic_ownership = 1 As libvirtd runs as root, it has no problem opening the file (as long as a NFS-share is mounted with roor-squashing disabled) and handing the opened file descriptor to the QEMU process. This can even be seen as a security improvement, as a QEMU process from one PC is not able to access the same file as long as another QEMU process is running on another PC. (See Bug #45256) (There even is the idea to give each VM its own unique UID/GID, so one QEMU process cannot access things of any other QEMU process.) Sharing anything other than /var/lib/libvirt/images/ is not supported, as its system-local data. (We have an exception for /v/l/lv/qemu/napshots/, as we carry an ugly hack to allow migration of VMs with snapshots, which is not supported by upstream)
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844339> libvirt: use allocated uid/gid for libvirt-qemu <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843881> request uid and gid allocation for libvirt-qemu Fixed since Debian version libvirt/2.5.0-2 Since UCS-4.2 we have libvirt/3.0.0 <http://xen1.knut.univention.de:8000/packages/source/libvirt/?since=4.1-0> So for NEW installations there is nothing to do. We should document a way to convert old installations to those new static UID=GID=64055. We should write a diagnostics check to detect the discrepancy.
No code change required. (In reply to Philipp Hahn from comment #2) > We should document a way to convert old installations to those new static > UID=GID=64055. I've created the following help article to describe, how to fix the problem: <https://help.univention.com/t/uvmm-live-migration-over-nfs-fails-due-to-different-numeric-ids/13085> > We should write a diagnostics check to detect the discrepancy. PS: The Debian package `libvirt-daemon-system` already has a check `high libvirt-daemon-system/id_warning` for the UID changein `/var/lib/dpkg/info/libvirt-daemon-system.config`, but we silenced that check by using `DEBIAN_FRONTEND=noninteractive` :-(
As discussed no diagnose module since no other customers are known to be affected at the moment. New installations use 64055 as uid/gid -> OK Help article: https://help.univention.com/t/uvmm-live-migration-over-nfs-fails-due-to-different-numeric-ids/13085 -> OK -> Verified
Article is already online -> OK Nothing to release -> OK -> Closed