root password in VMware vCenter Server Appliance zurücksetzen „Authentication token manipulation error“

Das lokale root-Kennwort einer VCSA zurückzusetzen ist, Konsolenzugriff vorausgesetzt, gar nicht so schwer. Das „Photon OS“ ist ja auch „nur“ ein Linux mit ein paar Extras.

root Kennwort an der Konsole zurücksetzen

  • vCenter neu starten
  • Beim booten ‚e‘ drücken um die GRUB-Config zu öffnen
  • Den linux call um init=/bin/bash ergänzen
  • Mit STRG+X die VM booten
  • An der daraufhin als root laufenden bash einfach mit passwd das Kennwort zurücksetzen

Wenn man an dieser Stelle (wie ich soeben) das rw in der Zeile vergisst, erhält man statt der Meldung „passwd: password updated successfully“ die zuerst seltsam erscheinende Meldung „passwd: Authentication token manipulation error with password unchanged“.

Man könnte die Appliance natürlich einfach neu starten und die Zeile mit rw init=/bin/bash korrekt ergänzen, aber man kann natürlich die Partition einfach nachträglich als Read/Write mounten, root ist man ja schon:

mount -o remount,rw /

Danach tut es passwd auch wieder wie gewohnt 🤦

Veeam Backup and Replication Logfile Pfade

Veeam B&R schreibt äußerst großzügige Logfiles, die die Fehlersuche in den allermeisten Fällen wesentlich vereinfachen. Das ist großartige – bitte bitte Veeam, ändert das niemals 😉

Früher(TM) war nicht nur alles besser, sondern man konnte über das Hilfe-Menü den Logfile-Ort schnell und komfortabel aufrufen; doch das war eine sinnvolle und hilfreiche Funktion und musste daher selbstverständlich ersatzlos gestrichen werden.

Naja, nicht ganz ersatzlos, denn dafür gibt es jetzt den freundlichen „Support-Assistenten“, der erst (wortwörtlich) Gigabyteweise Diag-Files zusammenkopiert, diese über alle CPU-Kerne verteilt einpackt und dem Informationensuchenden Admin schon nach einigen Minuten (!) ein wieder neu zu entpackendes .zip mit ALLEN logs darin präsentiert. In vielen Fällen eher sinnfrei, wenn Ihr mich fragt.

Lösung: Für das schnelle debuggen sind die Logfiles hier versteckt:

  • Windows Server XP/2003:
    %allusersprofile%\Application Data\VeeamBackup
  • Windows Server 2008/2008R2/7:
    %allusersprofile%\VeeamBackup
  • Windows Server 2026/2019/2022 und Windows 10: (thx Dezibel)
    %allusersprofile%\Veeam
  • Linux:
    /var/log/VeeamBackup/

vSphere vCLS VMs löschen, verschieben oder loswerden

Die neuen „vSphere Cluster Services (vCLS)“ sind standardmäßig aktiviert und die zugehörigen VMs werden per Default in allen vSphere-Clustern ab 7.0U3 ausgeführt.

Diese vCLS-Gäste stellen eine „Teilautarkie“ sicher, so dass beispielweise bei einem Crash des vCenter Servers die Clusterdienste weiterhin ihre Arbeit tun. Achtung: der vCenter Server ist trotzdem erforderlich um DRS und HA zu konfigurieren (und Operationen ausführen) zu können.

vSphere Cluster Services (vCLS)

Ein lesenswerter Artikel zu dem Konzept findet sich in den vSphere Docs unter https://docs.vmware.com/de/VMware-vSphere/7.0/com.vmware.vsphere.resmgmt.doc/GUID-96BD6016-4BE7-4B1C-8269-568D1555B08C.html

vCLS ist immer aktiviert, wenn man ein Upgrade oder Setup mit vSphere 7.0U3 macht. Technisch wird vCLS auch schon beim vCenter Server-Upgrades aktiviert. Spannend: vCLS-VMs unterstützen keine eigenen Netzwerkkarten.

Sollen die vCLS-<ID> VMs bleiben?

Manchmal muss man die klebrigen vCLS VMs „eine Weile“ loswerden. Zum Beisipel wenn man ein Storage tauschen möchte oder sich der Cluster AUSGERECHNET ein Veeam_NFS Volume für das Deployment ausgesucht hat (ohne Storage Motion natürlich).

Unnötig sind Sie zudem auch, wenn man kleine Cluster ohne DRS oder andere Cluster-Features betriebt.

Prinzipiell sind die Dinger sehr robust: Man kann Sie jederzeit abschalten und sie gehen sofort von selber wieder an. Leider verhindert das auch das Verschieben auf andere Speicher (ohne Storage Motion).

Lösung: vCLS VMs abschalten

Man kann den Cluster aber zum Glück relativ einfach dazu bewegen, die vCLS-VMs selbstständig zu entfernen.

  • Cluster-ID kopieren: Links in der Bestandsliste den Cluster auswählen und die ID aus der Adresszeile kopieren. Zum Beispiel „domain-c37“
  • vCenter Konfigurieren: Links ganz oben das vCenter auswählen, dann rechts Konfigurieren > Erweitert > Einstellungen bearbeiten > neuen Wert hinzufügen
  • Der Wert lautet config.vcls.clusters.<CLUSTER-DOMAIN>.enabled und muss auf „False“ gesetzt werden

Sobald das gespeichert ist, verschwinden die vCLS-Maschinen innerhalb weniger Sekunden. Löscht man den Eintrag wieder (oder stellt ihn auf „True“) kommen die Maschinen zuverlässig und schnell wieder.

vSphere 7.0.3 NTP funktioniert nicht „Zeitsynchronisierung des Hosts wurde unterbrochen“ und „NTP is not synced“

Die neue vSphere ESXi Version 7.0.3 bringt viele Neuerungen mit. Einige gut, andere sind neuen Herausforderungen für vmWare Admins.

Wir sehen es öfter, das frisch aktualisierte vsphere ESXi Hosts keine aktuelle Uhrzeit mehr von NTP Servern unter Windows abholen wollen. Es ist nicht nur eine Windows Server Zeitquelle betroffen, aber hier ist der Effekt am einfachsten nachzuvollziehen (und ja auch schon hinlänglich dokumentiert).

Hosts zeigen nach einer Weile den roten Fehler „Zeitsynchronisierung des Hosts wurde unterbrochen“ an.

vSphere: Zeitsynchronisierung wurde unterbrochen

Im Testprotokoll (Hosts > Konfigurieren > Uhrzeitkonfiguration > Dienste testen) sieht man leider nur den wenig hilfreichen Hinweis „NTP is not synced“ und „NTP never was synchronized.„. Nach der nett übersetzten Angabe „Die Konfiguration funtioniert nicht normal“.

Die Konfiguration funktioniert nicht normal

Lösung

Standardmäßig erlaubt Windows NTP Server eine Dispersion („Jitter“) von (großzügigen) 10 Sekunden und fügt diese auch in NTP-Antworten im DISP-Feld bei jedem Abfrageintervall hinzu. ESXi/ESX-Hosts ab 7.0.3 akzeptieren standardmäßig aber keine NTP-Antworten mit einer Root-Dispersion von mehr als 1,5 Sekunden.

Man könnte den Windows-NTP entsprechend anpassen, geht damit aber das Risiko fehlerhaft konfigurierter Domänenmitglieder ein. Oder man ermöglich dem NTP Client von vSphere ESXi einfach eine größere Dispersion. Letzteres machen wir hier.

Wichitg: Unter ESXi 7.0.3 kann man die /etc/ntp.conf nicht mehr manuell bearbeiten, denn sie wird durch das Webinterface (vSphere Client oder vCenter) überschrieben. Das hier ist die „richtige“ Lösung dazu.

NTP-Client auf ESXi-Hosts anpassen

  1. SSH auf Host aktivieren (Konfigurieren > Dienste > SSH > starten)
  2. Via SSH zum Host Verbinden und anmelden
  3. Eine NTP-Konfigurationsvorlagendatei erstellen und diese via esxcli setzen
# config-Datei mit Inhalt erstellen
printf "server pool.ntp.org\ntos maxdist 30\n" > /tmp/ntphack.txt

# Datei als NTP-Config "anhängen"
esxcli system ntp set -f /tmp/ntphack.txt

# NTP Client neu starten
esxcli system ntp set -e 1

Ein paar Sekunden (~20 Sekunden) später hat sich der Fehler selbst behoben und der Hoststatus ist wieder Normal.

vSphere: Alle eingelegten ISO-Dateien in VMs finden (via PowerCLI)

Alle CD’s in VMs finden: Ab und zu möchte ich eine ISO aus einem Datastore löschen, das dann mit einem Fehler fehlschlägt.

Die Datei [DATASTORE] isos/SW_DVD9_Win_Server_STD_CORE_2019_64Bit_German_DC_STD.ISO kann nicht gelöscht werden.

Das liegt meistens daran, das die ISO noch in einem Gast gemountet oder sogar verbunden ist.

Wie kann man also ISO Dateien in allen seinen VMs suchen?

Lösung

Alle VMs mit verbundenen ISO-Dateien via PowerCLI auflisten:

Get-VM | Get-CDDrive | select @{N="VM";E="Parent"},IsoPath | where {$_.IsoPath -ne $null}

… ISO-Dateien aus allen VM’s entfernen:

Get-VM | Get-CDDrive | where {$_.IsoPath -ne $null} | Set-CDDrive -NoMedia -Confirm:$False