Univention Bugzilla – Bug 22381
id des libvirt-qemu Benutzers NICHT gleich auf unterschiedlichen Nodes
Last modified: 2023-03-25 06:42:22 CET
xen13:~# more /etc/passwd| grep libvi libvirt-qemu:x:116:110:Libvirt Qemu,,,:/var/lib/libvirt:/bin/false xen12:~# more /etc/passwd| grep virt libvirt-qemu:x:118:110:Libvirt Qemu,,,:/var/lib/libvirt:/bin/false Ich hatte einen DVS Desktop auf xen12 gestartet. Nach einiger Zeit war konnte das Windows keine Daten mehr auf Platte schreiben, es gab diverse Fehlermeldungen. Nach einem Neustart ist die Instanz nun auch kaputt (Boot Meldung: NTLDR fehlt). Vermutlich liegt es daran, dass das qcow "backing file" nicht mehr gelesen werden konnte. Dies hatte folgende Berechtigungen -rw------- 1 haldaemon kvm auf xen12.
Wenn über DVS Desktops eine neue Instanz auf xen13 angelegt wird, wird auf xen13 ein chown auf das backing file unter "templates" gemacht, so dass der Besitzer wegen der Unterschiedlichen ID's auf xen12 nicht mehr "libvirt-qemu" ist. Wer aber die Permissions ändert, ist aber noch unklar. Bei meinem Versuch das Problem nachzustellen, sieht es auf xen12 so aus: -rw-r--r-- 1 haldaemon (backing file unter templates) Dies ist ja schon relativ unschön. Das eigentliche Problem wurde aber durch die 600 Permissions verursacht. Das bekomme ich aber durch das Anlegen eines DVS Desktop nicht reproduziert. Irgendjemand hat also auch noch die Permissions das backing_file auf 600 geändert.
Hier nochmal ein ls -al auf template Images (also die Vorlagen), die die "backing files" der DVS Desktop sind. xen12:/mnt/nfs# find templates/ -type f -exec ls -la {} \; -rw------- 1 libvirt-qemu kvm 4198694912 4. Mai 10:50 templates/2a4a7f24-ccd9-4821-b93b-573b992a70ad/winxp-x86-0.qcow2 -rw-r----- 1 root root 1757 1. Mai 19:50 templates/f182ca0c-5e29-4322-bc45-1b84bdef7858/description.pickle -rw------- 1 libvirt-qemu kvm 4211736576 1. Mai 19:50 templates/f182ca0c-5e29-4322-bc45-1b84bdef7858/winxp-x86-0.qcow2 -rw------- 1 root root 4295098368 2. Mai 16:03 templates/667c1427-eb73-4dc9-b10e-23661dabb3bc/winxp-x86-tim.qcow2 -rw-r----- 1 root root 1760 1. Mai 22:15 templates/75025379-4884-4292-85aa-ac9a082c388d/description.pickle -rw------- 1 haldaemon kvm 17858625536 1. Mai 22:15 templates/75025379-4884-4292-85aa-ac9a082c388d/win7-64-0.qcow2 -rw-r----- 1 root root 1759 1. Mai 22:08 templates/609b491e-9955-4429-b6e4-507fef8e3c2b/description.pickle -rw-r--r-- 1 libvirt-qemu kvm 7516651520 1. Mai 22:08 templates/609b491e-9955-4429-b6e4-507fef8e3c2b/ucd31-i386-1.qcow2 -rw-r----- 1 root root 1745 1. Mai 21:39 templates/46347c4e-057b-430c-9f81-d92ca87bc738/description.pickle -rw------- 1 libvirt-qemu kvm 4211146752 1. Mai 21:38 templates/46347c4e-057b-430c-9f81-d92ca87bc738/winxp-x86-0.qcow2 -rw-r----- 1 root root 1752 2. Mai 16:38 templates/02d9f100-3cac-48aa-9844-dce2785c861b/description.pickle -rw-r--r-- 1 libvirt-qemu kvm 4211933184 2. Mai 16:38 templates/02d9f100-3cac-48aa-9844-dce2785c861b/winxp-x86-0.qcow2 -rw-r----- 1 root root 1753 2. Mai 16:16 templates/e475e6f6-b942-43bd-9224-bb140e1fb2fc/description.pickle -rw------- 1 haldaemon kvm 4215341056 2. Mai 16:16 templates/e475e6f6-b942-43bd-9224-bb140e1fb2fc/winxp-x86-0.qcow2 -rw-r----- 1 root root 1756 2. Mai 15:05 templates/dffb48dd-6acb-48a4-9ba6-0996c070a206/description.pickle -rw------- 1 libvirt-qemu kvm 12708478976 2. Mai 15:05 templates/dffb48dd-6acb-48a4-9ba6-0996c070a206/win7-x86-0.qcow2 xen13:/mnt/nfs# find templates/ -type f -exec ls -la {} \; -rw------- 1 118 kvm 4198694912 4. Mai 10:50 templates/2a4a7f24-ccd9-4821-b93b-573b992a70ad/winxp-x86-0.qcow2 -rw-r----- 1 root root 1757 1. Mai 19:50 templates/f182ca0c-5e29-4322-bc45-1b84bdef7858/description.pickle -rw------- 1 118 kvm 4211736576 1. Mai 19:50 templates/f182ca0c-5e29-4322-bc45-1b84bdef7858/winxp-x86-0.qcow2 -rw------- 1 root root 4295098368 2. Mai 16:03 templates/667c1427-eb73-4dc9-b10e-23661dabb3bc/winxp-x86-tim.qcow2 -rw-r----- 1 root root 1760 1. Mai 22:15 templates/75025379-4884-4292-85aa-ac9a082c388d/description.pickle -rw------- 1 libvirt-qemu kvm 17858625536 1. Mai 22:15 templates/75025379-4884-4292-85aa-ac9a082c388d/win7-64-0.qcow2 -rw-r----- 1 root root 1759 1. Mai 22:08 templates/609b491e-9955-4429-b6e4-507fef8e3c2b/description.pickle -rw-r--r-- 1 118 kvm 7516651520 1. Mai 22:08 templates/609b491e-9955-4429-b6e4-507fef8e3c2b/ucd31-i386-1.qcow2 -rw-r----- 1 root root 1745 1. Mai 21:39 templates/46347c4e-057b-430c-9f81-d92ca87bc738/description.pickle -rw------- 1 118 kvm 4211146752 1. Mai 21:38 templates/46347c4e-057b-430c-9f81-d92ca87bc738/winxp-x86-0.qcow2 -rw-r----- 1 root root 1752 2. Mai 16:38 templates/02d9f100-3cac-48aa-9844-dce2785c861b/description.pickle -rw-r--r-- 1 118 kvm 4211933184 2. Mai 16:38 templates/02d9f100-3cac-48aa-9844-dce2785c861b/winxp-x86-0.qcow2 -rw-r----- 1 root root 1753 2. Mai 16:16 templates/e475e6f6-b942-43bd-9224-bb140e1fb2fc/description.pickle -rw------- 1 libvirt-qemu kvm 4215341056 2. Mai 16:16 templates/e475e6f6-b942-43bd-9224-bb140e1fb2fc/winxp-x86-0.qcow2 -rw-r----- 1 root root 1756 2. Mai 15:05 templates/dffb48dd-6acb-48a4-9ba6-0996c070a206/description.pickle -rw------- 1 118 kvm 12708478976 2. Mai 15:05 templates/dffb48dd-6acb-48a4-9ba6-0996c070a206/win7-x86-0.qcow2
Das ist gerade wieder in der Testumgebung (10.201.155.) mit einer frischen Vorlage aufgetreten, die ich selber erstellt habe. Originalinstanz: root@xen12:~# ls -l /mnt/nfs/images/winxp-x86-0.qcow2 -rw------- 1 root root 4198039552 1. Mai 19:39 /mnt/nfs/images/winxp-x86-0.qcow2 Vorlage daraus: root@xen12:~# ls -l /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 -rw------- 1 haldaemon kvm 4250599424 4. Mai 16:05 /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 root@xen13:~# ls -l /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 -rw------- 1 libvirt-qemu kvm 4250599424 4. Mai 16:05 /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 Abgeleitete Instanz: root@xen13:~# ls -l '/mnt/nfs/images/pmhahn-PMH 21281_0.qcow2' -rw-r--r-- 1 libvirt-qemu kvm 85786624 4. Mai 16:15 /mnt/nfs/images/pmhahn-PMH 21281_0.qcow2 Die Originalinstanz wir in Python per "shutil.copy2()" kopiert, was die Dateirechte mitkopiert. Deswegen hat die Vorlage dann die gleichen Berechtigungen wie das Original, weshalb die Berechtigungen dann ggf. nicht reichen. Ggf. sollte hier nach dem Abschluß des Wizards ein abschließendes chmod(0444, *) auf den Dateien ausgeführt werden.
Das scheint ein Bug in libvirt zu sein, vermutlich dort im Zusammenhang mit "dynamic ownership": /etc/libvirt/qemu.conf: # Whether libvirt should dynamically change file ownership # to match the configured user/group above. Defaults to 1. # Set to 0 to disable file ownership changes. #dynamic_ownership = 1 Nach dem Beenden der Instanz bleibt libvirt-qemu:kvm der Besitzer der Basis-Image-Datei, was dann nachfolgend zu den beobachteten Problemen führt. root@xen13:~# qemu-img info "/mnt/nfs/images/pmhahn-PMH 21281_0.qcow2" backing file: /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 Vor dem Start: # ls -l /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 "/mnt/nfs/images/pmhahn-PMH 21281_0.qcow2" -rw-r--r-- 1 root root 108331008 5. Mai 09:08 /mnt/nfs/images/pmhahn-PMH 21281_0.qcow2 -rw------- 1 libvirt-qemu kvm 4250599424 4. Mai 16:05 /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 # chmod 644 /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 # virsh start "pmhahn-vm" # ls -l /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 "/mnt/nfs/images/pmhahn-PMH 21281_0.qcow2" -rw-r--r-- 1 libvirt-qemu kvm 108331008 5. Mai 09:10 /mnt/nfs/images/pmhahn-PMH 21281_0.qcow2 -rw-r--r-- 1 libvirt-qemu kvm 4250599424 4. Mai 16:05 /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 Nach dem Start # virsh destroy "pmhahn-vm" # ls -l /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 "/mnt/nfs/images/pmhahn-PMH 21281_0.qcow2" -rw-r--r-- 1 root root 108331008 5. Mai 09:10 /mnt/nfs/images/pmhahn-PMH 21281_0.qcow2 -rw-r--r-- 1 libvirt-qemu kvm 4250599424 4. Mai 16:05 /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 Besitzer ändern: # chown 0:0 /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 # virsh start "pmhahn-vm" # ls -l /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 "/mnt/nfs/images/pmhahn-PMH 21281_0.qcow2" -rw-r--r-- 1 libvirt-qemu kvm 108331008 5. Mai 09:10 /mnt/nfs/images/pmhahn-PMH 21281_0.qcow2 -rw-r--r-- 1 libvirt-qemu kvm 4250599424 4. Mai 16:05 /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 # virsh destroy "pmhahn-vm" # ls -l /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 "/mnt/nfs/images/pmhahn-PMH 21281_0.qcow2" -rw-r--r-- 1 root root 108331008 5. Mai 09:10 /mnt/nfs/images/pmhahn-PMH 21281_0.qcow2 -rw-r--r-- 1 libvirt-qemu kvm 4250599424 4. Mai 16:05 /mnt/nfs/templates/359063ca-0323-4703-8729-14f42caa4bb2/winxp-x86-0.qcow2 Für DVS-1.0 setzen wir jetzt wenigstens die Permissions der Basis-Image-Dateien auf 0444.
Hier spielen mehrere Dinge zusammen: 1. der qemu-kvm-Prozeß braucht die Berechtigung /dev/kvm zu öffnen: Gruppe=kvm, Perm=g=rw 2. der qemu-kvm-Prozeß braucht die Berechtigung die Image-Dateien ro (Backing-File) bzw. rw (Overlay-File) zu öffnen. Das "dynamic_ownership=1" in der "/etc/libvirt/qemu.conf" sorgt dafür, das der libvirtd vor dem Starten den qemu-kvm-Prozesses den Owner und die Gruppe an den Image-Dateien auf "libvirt-qemu:kvm" anpasst, und danach (nur teilweise) wieder zurücksetzt. Der Benutzer "libvirt-qemu" und die Gruppe "kvm" werden jeweils lokal durch "/var/lib/dpkg/info/libvirt-bin.postinst" angelegt. Insbesondere die Gruppe "kvm" muß lokal sein, da sie innerhalb einer udev-Regel verwendet wird, wo noch kein Netzwerk und damit kein LDAP zur Verfügung steht. # cat /lib/udev/rules.d/60-qemu-kvm.rules KERNEL=="kvm", GROUP="kvm", MODE="0660" Variante 1: - dynamic_ownership abschalten - Image-Dateien einer LDAP-Gruppe geben - lokale Benutzer "libvirt-qemu" in diese Gruppe aufnehmen Variante 2: - globalen Benutzer im LDAP anlegen - diesem die Image-Dateien geben - diesen in "/etc/libvirt/qemu.conf" als "user" eintragen, unter dem der Qemu-kvm-Proze0 gestartet wird - diesem Benutzer jeweils über "/etc/group" in die lokale kvm-Gruppe stecken
> 2. der qemu-kvm-Prozeß braucht die Berechtigung die Image-Dateien ro > (Backing-File) bzw. rw (Overlay-File) zu öffnen. Da die Rechte der Overlay-Files im Moment 644 sind, könnte beim Migrieren einer VM ja ein ähnliches Problem auftreten, wenn man nicht den Benutzer einheitlich macht. Das spricht für Variante 2, die auch den Vorteil bietet, dass mit ihr das Problem unabhängig von DVS auf KVM-Ebene (im Join-Script von univention-virtual-machine-manager-node-kvm) lösen kann. Mir persönlich wäre es auch lieber, wenn man die Permissions der Overlay-Files und Backing-Files bei der Gelegenheit auf 640 einschränkt -- keine Ahnung, ob man dafür dann dynamic_ownership, damit das auch so bleibt.
Es gibt nun den LDAP-Benutzer "dvs-owner", der in der LDAP-Gruppe "DVS Nodes" und den jeweiligen lokalen "kvm"-Gruppen ist. dynamic_ownership=1 muss so bleiben, da ansonsten die ganzen Instanzen-Images von Hand entsprechende Rechte brauchen, damit sie gestartet werden können. svn24509, univention-dvs univention-dvs-node univention-dvs-sessionbroker
Die Anpassung reicht anscheinend noch nicht: Backend und Overlay werden beim Start der VM weiterhin dem lokalen Benutzer libvirt-qemu und der Gruppe kvm gegeben. Vermutlich müsste noch die UCR-Variable uvmm/kvm/qemu/user auf "dvs-owner" (oder besser noch auf seine UID?) gesetzt werden, damit das über die qemu.conf den libvirt anweist, den Prozess mit der Domänen-UID zu starten. -- (nebenbei: funktioniert das auch für nicht-qemu-Systeme / UCD ?) Was schon funktioniert ist: * Der Benutzer dvs-owner wird korrekt angelegt * Das UMC Modul DVS Templates gibt das Template diesem Benutzer * univention-create-desktop gibt das DVS-Image diesem Benutzer Das hat aber keinen bleibenden Effekt. Testprotokoll: Ich habe die Templates per chown dem Benutzer dvs-owner gegeben: -rw-r----- 1 root root 1757 1. Mai 19:50 /mnt/nfs/templates/f182ca0c-5e29-4322-bc45-1b84bdef7858/description.pickle -rw------- 1 dvs-owner DVS Nodes 4211736576 1. Mai 19:50 /mnt/nfs/templates/f182ca0c-5e29-4322-bc45-1b84bdef7858/winxp-x86-0.qcow2 Und dann dieses Template einem Benutzer zugewiesen, danach lie root@xen12:~# ls -l /mnt/nfs/images/umctest1-XP-Template1_0.qcow2 -rw-rw---- 1 libvirt-qemu kvm 39714816 26. Mai 17:57 /mnt/nfs/images/umctest1-XP-Template1_0.qcow2 root@xen12:~# ls -l /mnt/nfs/templates/f182ca0c-5e29-4322-bc45-1b84bdef7858/ insgesamt 4117052 -rw-r----- 1 root root 1757 1. Mai 19:50 description.pickle -rw------- 1 libvirt-qemu kvm 4211736576 1. Mai 19:50 winxp-x86-0.qcow2
(In reply to comment #8) > Die Anpassung reicht anscheinend noch nicht: Backend und Overlay werden beim > Start der VM weiterhin dem lokalen Benutzer libvirt-qemu und der Gruppe kvm > gegeben. Hier hat ein Restart des libvirtd gefehlt, der nur dann /etc/libvirtd/qemu.conf einliest. > Vermutlich müsste noch die UCR-Variable uvmm/kvm/qemu/user auf > "dvs-owner" Das wird bereits beim Joinen gemacht. > -- (nebenbei: funktioniert das auch für nicht-qemu-Systeme / UCD ?) Die Frage versteh ich nicht. svn24523, univention-dvs-node_2.0.29-2.84.201105270905
Ok, funktioniert jetzt.