Problem:
Bei der Installation eines Windows Betreibssystems unter VMWare oder VMWare Workstation kommt es zu folgendem Fehler:
Die Microsoft-Software-Lizenzbedinungen wurden nicht gefunden. Stellen Sie sicher, dass die Installationsquellen gültig sind, und starten Sie die Installation erneut.
Lösung:
Die Lösung ist einfach wie simpel. Windows scheint hier ein Problem mit dem Floppy zu haben. Entfernen Sie das Floppy-Laufwerk in der Hardwareliste der VM und führen Sie die Installation erneut durch. Diese wird nun fehlerfrei durchlaufen.
Problem
Nach der initialen Einrichtung des Netapp Simulators unter VMWare ESX oder VMWare Workstation scheint das ONTAP beim Starten stehen zu bleiben. Nach einigen Minuten ist der Node oder Cluster aber per SSH und HTTPS erreichbar.
Lösung
Leider handelt es sich hier um einen BUG, der nicht gefixt wird (weder VMWare noch Netapp).
Entweder man ignoriert das Verhalten, da der Cluster bzw. Node nach der Bootvorgang ganz normal erreichbar ist, oder man kann im VLOADER anpassen, damit die Anzeige korrekt ist. Das ist vor allem im Fehlerfall hilfreich!
Die Anpassung muss aber JEDES MAL gemacht werden und ist nicht persistent:
- Bootvorgang des Nodes am Anfang (Countdown) mit einer non-Enter-Taste unterbrechen.
- Der Prompt "VLOADER>" wird angezeigt
- Hier den Befehl "setenv screen.textmode 1" eingbene
- Bootvorgang mit dem Befehl "boot_ontap" starten
- Die Anzeige ist nun korrekt und der Bootvorgang wird vollständig angezeigt
Problem:
Wir wollten einen physikalischen Server inkl. Applikation auf einen virtuell Server umziehen und from scratch neu installieren (kein P2V). Hierzu mussten wir die originalen Installationsmedien des Herstellers verwenden, da es sich um eine ROK-Lizenzen gehandelt. Bei der Installation in einer VM unter VirtualBox kam der Hinweis, dass das installationsmedium Vendor branded ist und die Installation bricht ab.
Lösung:
Man kann der VM unter VirtualBox einen Vendor BIOS Tag mitgeben, damit die Installation funktioniert. Das konnten wir bei Fujitsu und HP sauber abbilden.
Folgende Befehle haben hier den Vendor im BIOS gesetzt:
Manchmal kann es vorkommen das unter Proxmox ein Node nur ein graues Ausrufezeichen zeigt. Das ist meistens auf einen Fehler mit dem Storage zurückzuführen. In meinem Fall hatte ich testweise den Proxmox Backup Server virtualisiert, das Storage kann dann beim booten nicht verbunden werden und sorgt für einen Fehler, daraus resultiert das graue Ausrufezeichen.
Ein Neustart des Dienstes pvestatd auf dem betroffenen Node hat den Fehler behoben und der Node wurde grün
Ich habe festgestellt das wenn man einen LXC mit Debian 11 auf einem Proxmox laufen lässt, die Performance auf ssh ziemlich schlecht ist. Auch sudo dauert ziemlich lange (wenn man es verwendet)
Das liegt am Service systemd-logind wenn man diesen deaktiviert hat man wieder die gewohnte Performance.
Um zu verifizieren ob es an diesem Service liegt , grept einfach mal nach 'org.freedesktop.login1' in der Datei /var/log/auth.log
grep 'org.freedesktop.login1' /var/log/auth.log
wenn ihr dort Einträge findet, die wie folgt aussehen, liegt es vermutlich an diesem Dienst.
Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Problem wird dann mit diesen Befehl behoben (muss als root ausgeführt werden)
Ich setzte zuhause Proxmox ein und lasse alles auf LXC laufen, da es einiges an Overhead spart.
Normalerweise läuft ein LXC als "Unprivileged container" in machen Fällen kann es jedoch vorkommen das ein LXC als "Privileged container" laufen muss. Ein konvertieren des LXC ist nur über einen kleinen Umweg möglich.
Das einfachste Vorgehen :
1.) Stoppen des LXCs (in meinen Fall 102)
2.) einen Snapshot des LXC erstellen
2.) Diesen Snapshot dann als neue Maschine (hier 103) restoren und den Parameter für unprivileged auf 0 setzen
Dieses Vorgehen sollte aber nur verwendet werden wenn es GAR NICHT anders geht
Privileged containers: container uid 0 is mapped to the host's uid 0.
Unprivileged containers: container uid 0 is mapped to an unprivileged user on the host.
das bedeutet bei einem Privileged containers ist der user root im container auch der root user auf dem proxmox host
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
