Anlegen von VMs mit UVMM nicht möglich

Hallo,

nach einigen Tests mit der UVMM und Windows 7 als Gast, wollte ich nach dem letzten Update UCs 4.04 nun Windows 7
dauerhaft als Gast einrichten.

Leider ist das in der UVMM nicht mehr möglich, als Auswahl steht nur noch Amazon EC2 zu Verfügung.

KVM und UVMM wurden von mir mehrfach über das Appcentern neu installiert.
Soweit ich sehen kann laufen alle Dienste, ein manueller Neustart der Dienste wurde ebenfalls durchgefüht.

Als Fehler in der libvirtd.log

Authentication Fehler:failed to verify peers certifcate… permission denied
(clientcert.pem)

In der UVMM ist physikalischer Server auch “durchgestrichen”.

Die Pfade zu den Certifikaten scheinen zu stimmen und sie sind nicht abgelaufen.Möglicherweise sind sie fehlerhaft ?
Da komme ich erstmal nicht weiter

Hilfe wäre jetzt nicht so schlecht

Danke

Hallo,

welche Dienste haben Sie denn neu gestartet? Relevant wären auch “univention-virtual-machine-manager-node-kvm” und “univention-virtual-machine-manager-daemon”.

Außer den Logs in /var/log/libvirt wären dann noch die aus /var/log/univention interessant.

Viele Grüße,

Dirk Ahrnke

Hallo Herr Ahrnke,

mittlerweile läuft UVMM wieder ,es lassen sich wieder VMs anlegen Win7 läuft als Gast.
Aber es könnte besser sein.

Als Fehler habe ich fehlende bzw. nach dem Update verschwundene UCS-Variabeln ausgemacht.

  1. uvmm/managers
    enthält keinen Eintrag (hier sollte der Servername stehen die Syntax ist mir jedoch nicht klar)
    Dieser wird in der libvirtd.conf von UCS in tls_allowed_dn_list =[] zugeordnet, er war aktiv und leer.
    Ich habe ihn auskommentiert, dadurch ist der physikalischer Server wieder aktiv und nicht mehr gesperrt.
    Anlegen von VMs ist damit wieder möglich

  2. Änderungen des pool Pfades führen zu falschen Berechtigungen am VM-Image.

Eine VM lies sich zwar anlegen aber nicht ausführen.
Fehlermeldung: Zugriff verweigert.
VMs Images werden mit root Rechten angelegt.
Beim ausführen der VM wechseln die Recht auf libvirt-qemu.
Das funktioniert nicht mit Verzeichnisse außerhalb des default pools, warum auch immer.

Entsprechend habe ich den Eintrag user ID in qemu.conf auf user = root gesetzt.

Mit diesen Änderungen läuft alles wieder.
Richtig scheint mir das aber nicht zu sein.
Ein Update könnte dies wieder rückgängig machen.

Hallo,

in uvmm/managers steht normalerweise der FQDN des Hosts auf dem die Managementkomponente (eben der UVMM) installiert ist. Wenn es mehrere gibt, werden die durch Leerzeichen separiert. Ich kann mich ehrlich gesagt nicht erinnern, das mal irgendwo manuell eingetragen zu haben und hätte erwartet, dass die Installationsroutine der App dies übernimmt.
Manuelle Änderungen in der libvirtd.conf sollte man möglichst vermeiden. Der Grund steht am Anfang der Datei.

Für den Poolpfad gibt es ebenfalls eine UCR-Variable “uvmm/pool/default/path”. Weiters Hinweise zum Thema auch in DOC: 15.5.2. Speicherbereiche.

Viele Grüße,
Dirk Ahrnke

Hallo,

Vor dem update war zumindest \uvmm\managers richtig gesetzt, KVM lief ja.
Da scheint was schief gelaufen zu sein, vieleicht wars auch der Admin in seinem Übermut.
Ich setzte die mal mit dem FQHN neu.

Danke

Pools
Ich bin ja auch nach der Anleitung vorgeganngen.
Anlegen von VMs im neuen pool waren damit möglich jedoch nicht das Starten der VM.
Wechselnde Rechte funktionieren nicht.

Ja das mit den Änderungen an den config Dateien würde ich mir auch gerne sparen, ist aber irgendwie "notwendig"um zum Ziel zu gelangen.

Vielen Dank

Hallo nochmal,

nach dem update auf 4.1 sind wieder die Berechtigungen falsch.

Pool wieder mit Hilfe von qemu.conf auf user = root gesetzt.
Läuft wieder.

Das führt eigentlich zu einer allgemeinen Frage.

Wie gehe ich mit manuellen Änderungen an UCS richtig um?

Da ja nicht alle config Dateien vollständig parametrisiert sind, ist dies sicher kein Einzelfall.
Änderungen an den templates führen nach updates auch zu Problemen mit dem update.
Manche templates sind auch nicht einfach zu editieren.

Eine einfache Frage hierzu.
Wie erzeuge ich aus einem template mit ucr commit, die config Datei um sie dann manuell neu zu bearbeiten oder zu vergleichen?
Das Problem sollten doch einige user haben, z.B mit postfix Dateien hier sind Anpassungen doch oft nötig.

Wie macht Ihr das?

Grüße

Hallo,

es kann durchaus sein, dass wir - obwohl wir UVMM schon ein paar Jahre produktiv und mit mehreren Pools (NFS) einsetzen - das Problem noch nicht gesehen haben, aber bislang war es hier noch nicht nötig, irgendwas an den Berechtigungen zu ändern oder die qemu.conf zu ändern.
Beim Starten der VMs wird die Ownership dynamisch geändert, das funktioniert auch mit mehreren Virtualisierungshosts. Im Bugzilla gibt es aber diverse Hinweise, dass in der Vergangenheit Anpassungen nötig waren (z.B. [bug]22381[/bug]).

Manuelle Änderungen an über UCR-Variablen und Templates gepflegten Konfigurationsdateien werden nie lange überleben. Ein “ucr commit”, welches alle Konfigurationen neu schreibt, ist bei einem Update normal.
Details dazu unter anderem in 8.3.3. Verwendung des Kommandozeilenfrontends

Grundsätzlich sollte man Templates nur dann anpassen, wenn es wirklich keinen anderen Weg gibt. Empfehlenswert ist, gleichzeitig den Bedarf über einen Enhancement-Bug kundzutun. Bei einigen Integrationen, wie z.B. Zarafa oder Open-Xchange gibt es auch schon keine statischen Templates mehr. Dort kann man einfach weitere UCR-Variablen für bestimmte Konfigurationsdateien definieren.

Viele Grüße,
Dirk Ahrnke

Mastodon