Archiv der Kategorie: VMware

VMware vSphere CLI „Connect to failed. Server SHA-1 thumbprint FF… „

Veröffentlicht am von — Keine Kommentare ↓

Problem

Die neuen VMware vSphere CLI Tools ab Version 6.0+ (Download v6.5) möchten nicht mehr „einfach so“ eine ESXcli Verbindung aufbauen. Wenn man einen Befehl startet, kommt sofort die Fehlermeldung „Server SHA-1 thumbprint <not trusted>„.

C:\>esxcli -s <SERVER> -u root -p <PASSWORT>
Connect to <SERVER> failed. Server SHA-1 thumbprint: F5:CE:AF:AF:D2:13:48:3D:C2:FB
:EE:C9:22:BE:B8:39:20:09:9D:B5 (not trusted).

Das passiert, weil vSphere heute ganz spontan noch total viel sicherer ist als früher. Blöderweise laufen alle möglichen Scripts damit nun ins leere. Selbstverständlich gibt ESXCLI trotz des Fehlers den Errorlevel 0 („Erfolg“) zurück *seufz*. Naja, mittelfristig geht es eh in Richtung Powershell. Ach nein, die hat das Problem ja auch.

Lösung

Die schnellste und einfachste Möglichkeit: Den Fingerabdruck des Server an der Kommandozeile mitgeben. Die Reichenfolge ist wichtig.

C:\> esxcli -s <SERVER> -u root -p <PASSWORT> --thumbprint <THUMBPRINT> <befehle>

Beispiel:

C:\> esxcli -s 128core-esx01.farm.local -u root -p <PASSWORT> --thumbprint <THUMBPRINT> storage vmfs unmap -l iscsivol36tb-a

Eine ‚permanente‘ Lösung ist dann (zum Beispiel), gar nicht direkt mit dem ESX-Host zu sprechen sondern über den vCenter Server über den Parameter ‚vihost‘ mit dem Host. Das erlaubt es, das vCenter Server Zertifikat vorher in den lokalen Zertifikatsspeicher zu importieren und somit der Maschine zu vertrauen.

  1. Die lokalen vSphere root-Zertifikate herunterladen und in den Stammzertifizierungsstellen-Speicher importierenvmware-root-zertifikat-herunterladen
  2. C:\>esxcli -s <VCENTER-SERVER> -u root -p <PASSWORT> --vihost <ESX-HOST>

 

vmWare vSphere 5.5 vCenter/VCSA administrator SSO-Kennwort ([email protected]) zurücksetzen

Veröffentlicht am von — Keine Kommentare ↓

Unter vmware vSphere 5.1/5.5 nutzt der schnelle Admin in kleineren Umgebungen gerne das root-Kennwort oder die lokale Benutzerstruktur des vCenter Servers, respektive der vCenter Server Appliance (vCSA). Das Single-Sign On (SSO) System ist zwar recht nett, aber für kleine und übesichgtlinbe Netze oft etwas überdimensioniert. Beim Upgrade (oder der SSO-Verbindung) wird das Kennwort aber zwingend benötigt.

Administrator-Kennwort der vCenter Server Appliance (VCSA) zurücksetzen

  1. SSH-Verbindung zur vCenter Server Appliance öffnen
  2. Ausführen:
    vcenter55:~ # /usr/lib/vmware-vmdir/bin/vdcadmintool
  3. Im Admin-Tool „3“ drücken („Reset account password“)
  4. Den DN oder UPN des administrators (je nach Aufforderung) eingeben. In der Standardeinstellung lautet der DN:
    cn=administrator,cn=users,dc=vSphere,dc=local
    Der UPN lautet natürlich einfach nur „[email protected]“
  5. Fertig, es wurde ein neues Kennwort generiert.

Achtung! Wenn das generierte Kennwort ein Ausrufezeichen enthalten sollte („!“), funktioniet die Kennwortänderung in der Weboberfläche nicht mehr. Die Admins raten dazu, einfach ein neues zu generieren, bis kein ausrufezeichen mehr drin ist …

Administrator-Kennwort unter vCenter Server (Windows) zurücksetzen

Auf dem vCenter SSO-Server anmelden (RDP oder Console). Meistens sind vCenter und SSO auf einer Maschine installier.

  1. CMD als Administrator (!) öffnen
  2. Ausführen:
    c:\> CD "%ProgramFiles%\VMware\Infrastructure\VMware\CIS\vmdird"
    C:\Program Files\VMware\Infrastructure\VMware\CIS\vmdird> vdcadmintool.exe
  3. … ab hier den Anweisungen oben unter der VCSA ab Punkt 3 folgen 🙂

Achtung! Auch unter Windows dringend Ausrufezeichen und Emojies in Kennwörtern vermeiden. Dinge explodieren sonst später mit absurden Fehlermeldungen.

VMWare ESXi: „Es wurde kein Ziel für Coredumps konfiguriert. Derzeit können keine Coredumps für den Host gespeichert werden.“

Veröffentlicht am von — Keine Kommentare ↓

Es wurde kein Ziel für Coredumps konfiguriert. Derzeit können keine coredumps für den Host gespeichert werden

Es gibt zwei Möglichkeiten, die Meldung „Es wurde kein Ziel für Coredumps konfiguriert. Derzeit können keine coredumps für den Host gespeichert werden“ los zu werden. Es gibt den „sauberen“ Weg, der ein neues Ziel für die Kerneldumps angibt, den schnellen und einfachen Weg Coredumps ganz abzuschalten und die schnelle „Hackery“ Die Warnung (pro Host) zu entfernen.

Möglichkeit 1 (korrekt): Neues Ziel für coredumps konfigurieren

1) Per SSH am Server anmelden und die coredump Konfiguration anschauen:

~ # esxcfg-dumppart -l
Configured Dump Partition Not Found, Skipping

3) Freie Partitionen für Coredumps anschauen:

~ # esxcfg-dumppart -f

4) Die passende Partition zur coredump config hinzufügen:

~ # esxcfg-dumppart -s name

Zum Beispiel: esxcfg-dumppart -s naa.444408f4444000071c57384957867ee:7

Danach steht in der Ausgabe von esxcfg-dumppart -l in der Spalte „Is Active“ bei der entsprechenden Partiton ein „Yes“ und die Meldung im vSphere Client ist verschwunden.

Möglichkeit 2 (naja): Coredumps abschalten

Die coredump.Funktion des Kernels lässt sich auch komplett deaktivieren. Das geht unter Konfiguration -> Erweiterte Einstellungen -> VMKernel. Danach ist ein Host-Reboot notwendig.

es-wurde-kein-ziel-fuer-coredumps-konfiguriert-abschalten

Möglichkeit 3 (Hackery): Coredump-Warnung abschalten

Diese Eintellung ist pro Host möglich und verhindert die gelbe Warnmeldung. Die Einträge im Logfile bleiben vorhanden.

Host > Konfiguration > Erweiterte Einstellungen > UserVars > UserVars.SuppressCoredumpWarning auf 1 stellen

kein-coredump-ziel-konfiguriert-warnung-ausschalten

vmWare Gast VM ohne vCenter von einem Host auf einen anderen verschieben

Veröffentlicht am von — Keine Kommentare ↓

Problem

Auf QUELLHOST ist eine VM die auf ZIELHOST verschoben werden soll. Es gibt kein Shared Storage, kein vCenter und keine sonstigen Werkzeuge.

Lösung

Es gibt zwei ganz gute Möglichkeiten eine VM von ESX-zu-ESX zu kopieren. Einmal das ovftool (schnell) und scp (im Lieferumfang). Ersteres berücksichtigt die VM(X) selbst, also auch die Einstellungen wie verbundene Netzwerke und VMDKs die in anderen Ordnern liegen. SCP dagegen kann „nur“ stumpf Dateien kopieren, ist dafür aber in jedem SSH-Paket (auf jedem ESX/i) enthalten.

Virtuelle Maschine mit OVFTool kopieren

  1. Das vmware „OVF Tool“ herunterladen und auf einem Rechenr (Windows/Linux/Mac …) installieren: https://www.vmware.com/support/developer/ovf/
  2. Syntax: 
    ovftool -ds="ZIELDATASTORENAME" "vi://root@QUELLHOST/VMNAME" "vi://root@ZIELHOST"

Es gibt einige mögliche Fehler die hierbei öfters auftreten:

Error: No network mapping specified OVF networks

Die Quellmaschine ist mit einem virtuellen Netzwerk verbunden, das der Zielhost nicht kennt. Entweder das Quellnetz umbenennen, NIC entfernen oder das Zielnetz anpassen. Es gibt auch die Möglichkeit das Ziel an der Kommandozeile anzupassen, aber da wir das in diesem Fall nicht brauchten, müsst ihr selber in die Dokumentation schauen 🙂

The operation is not supported on the object. Completed with errors

vmware-maschine-ohne-vcenter-kopierenAuf Quelle und Ziel müssen die SSH/HTTP/HTTPS-Dienste sowohl gestartet als auch in der Firewall freigegeben sein. In diesem Fall war es der SSH-Client, bzw. dessen ausgehende Verbindung. Alle ESX-Server haben auch ausgehende (!) firewall aktiv. Zudem muss die zu kopierende Maschine ausgeschaltet sein.

Virtuelle Maschine mit SCP kopieren

  1. Auf der Quellmaschine ausgehende SSH-Verbindungen („SSH-Client“) in der Firewall erlauben und dne SSH-Server starten.
  2. Auf dem Zielserver SSH-Server starten und eingehende Verbindungen erlauben (standart)
  3. SCP Syntax auf dem Quellhost: 
     # scp -r /vmfs/volumes/QUELLDATASTORE/QUELLMASCHINE root@ZIELHOST:/vmfs/volumes/ZIELDATASTORENAME

Die Übertragung ist verschlüsselt, sicher und sehr zerlässig. Leider nicht wahnsinnig schnell. Auf einem aktuellen Host habe ich soeben einige Maschinen mit 30-40Mb/S umgezogen. Innerhalb des Clusters, über das vCenter, lief die Kopie mit rund 160Mb/s. Wenn das durchgelaufen ist, gibt es die Maschine zweimal (SCP heisst „Secure copy“, nicht move), also die Quelle danach natürlich löschen.

VMware vCenter Server Appliance Upgrade 5.5 auf 6.0 schlägt fehl: File /usr/lib/vmidentity-firstboot.py (2119876)

Veröffentlicht am von — 1 Kommentar ↓

Problem

Der Upgrade Assistent in Form des netten HTML-Setups is ausgefüllt, alle Eingaben sind validiert und das Setup legt los. Nach (gefühlten) 10 Minuten steht die Migration still und es erscheint diese unfreundliche Fehlermeldung:

Firstboot script execution error: 
Encountered an internal error. Traceback (most recent call last): File "/usr/lib/vmidentity-firstboot.py", line 202, in main vmidentityFB.boot()
File "/opt/vmware/lib64/vmidentity_firstboot_core.py", line 180, in boot self.dolmport()
File "/opt/vmware/lib64/vmidentity_firstboot_core.py", line 1369, in dolmport self.doLSImport()
File "/opt/vmware/lib64/vmidentity_firstboot_core.py", line 1411, in dolSImport returncode = self.runShellCommand(command, True)
File "/opt/vmware/lib64/vmidentity_firstboot_core.py", line 1515, in runShellCommand args = shlex.split(command)
File "/opt/vmware/lib/python2.7/shlex.py", line 279, in split return list(lex)
File "/opt/vmware/lib/python2.7/shlex.py", line 269, in next token = self.get_token()
File "/opt/vmware/lib/python2.7/shlex.py", line 96, in get_token raw = self.read_token()
File "/opt/vmware/lib/python2.7/shlex.py", line 172, in read_token raise ValueError, "No closing quotation" ValueError: No closing quotation 

This is an unrecoverable error, please retry install.
If you run into this error again, please collect a support bundle and open a support request.

Lösung

Das Kennwort für root und den SSO-Adminbenutzer dürfen keine Sonderzeichen enthalten (/\+()“ Leereichen und so weiter). Einfach eine neues Kennwort nur aus Buchstaben und Zahlen vergeben, schon läuft der Assistent *kopfschüttel*

Das gilt für den root und [email protected], wenn SSO nicht eingerichtet ist.

Update: vmware hat dieses Verhalten zwar nicht gefixt, aber Dokumentiert: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2119876