Kategorie-Archiv: VMware

Ein vCenter mag „plötzlich“ keine root-Anmeldung mehr für das VMware Appliance Management machen.

Das kommt schon mal vor, weil Kennwort Standartmäßig in der VCSA ablaufen und es eineige Admins gibt die sich auch gerne länge mal nicht einloggen. „Warum auch, läuft doch“

Lösung

1. Öffnen einer SSH-Sitzung auf den vCenter Server, einloggen als ‚root‘ (dort funktioniert das auch noch)
2. Mit shell die Shell öffnen
3. Mit passwd ein neues Kennwort vergeben (das kann auch dem alten entsprechen)

… und schon funktioniert die Anmeldung sofort wieder, ein Neustart ist nicht notwendig.

Kennwort nicht ablaufen lassen

Meist stehen „solche“ vmWare vCenter Applicances eher „isoliert“, daher kann man das Kennwort dort auch nicht ablaufen lassen. Das geht in der Weboberfläche unter Verwaltung > Einstellungen für Kennwortablauf

Dies ist wieder so ein klassicher Fall von Selbst-Notiz: Nachdem ich schon wieder aus Gewohnheit das aktuellen VMware PowerCLI aus dem vMware Code Portal herunterladen wollte.

Das ist jetzt ein (NuGet) PowerShell Modul – man muss nichts mehr einzeln herunterladen. Install-Module läd das passende NuGet-Paket, sofern nicht vorhanden, auch gleich mit herunter.

PS> Install-Module -Name VMware.PowerCLI

Der native Download des NuGet-Paketes (für Offline-PCs) liegt hier:

https://psg-prod-eastus.azureedge.net/packages/vmware.powercli.12.1.0.17009493.nupkg

Das Hinzufügen eines neuen Hosts (vSphere ESX 6.7 U3) unter vCenter 6.7 schlägt mit der Meldung fehl:

Ein allgemeiner Systemfehler ist aufgetreten: Unable to push CA certificates and CRLs to host <HOSTNAME>

Lösung

Mit vSphere 6.7U3 wurde die Zertifikatssicherheit verschärft. Die Fehlermeldung ist (indirekt) darauf zurückzuführen, dass selbstsignierte Zertifikate (oder Zertifikate ohne vertraute CA) aus dem TRUSTED_ROOTS Speicher des vCenters Server beim Hinzufügen (oder Verbinden) den ESXi-Host übertragen werden sollen. Ab U3 lässt der Host das aber nicht mehr zu.

Man kann diese Verhalten aber zum Glück ändern:

1. vSphere Host-Client des neuen hosts öffnen
2. Verwalten -> System -> Erweiterte Einstellungen
3. Config.HostAgent.ssl.keyStore.allowSelfSigned auf „true“ setzen

Aktuelle ESXi Server beschweren sich mit einer Warnung über CPUs mit Microcode, die anfällig für Angriffe wie Meltdown, Lazy FP state restore und/oder die L1 Terminal Fault sind. Einige AMD und Intel Prozessoren können über so einen side-channel Angriff Daten lesbar machen, die nicht lesbar sein sollten.

Bevor die Warnung unterdrückt wird, lohnt abe ein Blick in die Mitigation und vor allem auch die performance impacts. In privaten Cluster Setups ist die Gefahr eines solchen Angriffs vermutlich auch nicht so hoch, wie in öffentlichen Wolken.

Lösung

Da die Mitigations dazu ziemlich viel CPU-Performance fressen, bleiben die Schutzfunktionen wie der „Side-Channel-Aware Scheduler“ in privaten und geschlossenen Clustern oft ausgeschaltet. Trotzdem will man die Warnung natürlich loswerden 🙂

Möglichkeit 1 – Warnung unterdrücken

1. vSphere GUI (vCenter) öffnen, den betroffenen Host auswählen
2. Konfigurieren > Erweiterte Systemeinstellungen > Bearbeiten
3. „UserVars.SuppressHyperthreadWarning“ auf „1“ stellen

Möglichkeit 2 – „Side-Channel-Aware Scheduler“ einschalten

1. ESXi Hostclient (nicht im vCenter) öffnen
2. Konfiguration > Erweiterte Einstellungen > Bearbeiten
3. „VMkernel.Boot.hyperthreadingMitigation“ auf „true“ stellen
4. Host neu starten

Es empfielt sich vor diesem Schritt das zugehörige Support-Dokument zu lesen. Hier sind die Vorbereitungen für diesen Schritt und die möglichen Auswirkungen davon genauer beschrieben.

Problem

Die Aktualisierung des VMware vCenter Servers (VCSA) kann bei der Lizenzanzeige (EULA) nicht fortgesetzt werden. Nach einem Klick auf „Next“ landet man immer im selben Bildschirm, der die Fehlermeldung „Error in method invocation Timeout happens while sending message to microservice“ zeigt.

Zudem findet man in /var/log/vmware/applmgmt/applmgmt.log mehrere Meldung wie:

DEBUG:vmware.appliance.update.update_functions: Exception happens  while sending message to microservice: ConnectionRefusedError(111,  'Connection refused')

INFO:vmware.appliance.update.update_functions:Timeout happens  while sending message to microservice

ERROR:vmware.vapi.provider.local:Error in invoking  com.vmware.appliance.update.pending in precheck - Timeout happens while sending message to microservice 

Lösung

Der Update-Micrososervice vergisst manchmal, sein PID-file zu entfernen. Das verhindert den korrekten neustart des Prozesses. Das lässt sich an der SSH-Konsole der VCSA (SSH öffnne, mit ’shell‘ eine Shell starten) aber schnell beheben.

Prüfen ob die PID noch da ist

 ls /var/run/vmware/applmgmt/update_microservice.pid 

Wenn dem so ist, diese PID File entfernen

rm /var/run/vmware/applmgmt/update_microservice.pid

Danach läuft da sUpdate sofort fehlerfrei weiter.