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

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).
C:\>

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*

Lösung

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

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

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>

 

Sie sind zu oft hier

Die IT-Serviceverträge unseres Arbeitsgebers beinhalten meistens pauschale Vor-Ort oder Remote-Consultingkontingente. Das bedeutet, das einer der Admins aus unserem Team den IT-Staff der Kunden „vollzeit“ Vor-Ort verstärkt. Je nach Aufgabengebiet und Schwerpunkten fallen für uns dann in der Regel Tätigkeiten an, die sonst niemand machen kann (oder möchte). Das beinhaltet die unbeliebten Server-Reboots („Es geht *foo* nicht“), performancedegradierende Patchinstallationen, fiese Geräteneustarts, Systrem- und Stresstest, Sicherheitsprüfungen und so weiter.

Daher sind Admins in aller Regel zu 50% beliebt und zu 50% gehasst. Ein Unternehmen brachte das soeben ziemlich genau auf den Punkt:

Sie sind viel zu selten hier. Und viel zu oft.

🙂

Microsoft Edge Startseite mit Gruppenrichlinien (GPO) festlegen

Seit der Windows 10 Version 1511+ lässt sich ENDLICH die Startseite des neuen (und recht flottem) Browsers Edge über eine Gruppenrichtlinie vorgeben. Das hat eine Weile gedauert, viele Admins waren verblüfft über die offizielle „geht nicht“ Ansage kurz vorher.

Die nagelneuen passenden ADMX-Templates für Windows 10 (mit Edge) gibt es hier zum herunterladen: https://www.microsoft.com/de-DE/download/details.aspx?id=53430

Unsere Empfehlung ist an dieser Stelle, die neuen ADMX-Files auch direkt im AD Central-Store abzulegen.

Danach findet man die neue Einstellung in der Gruppenrichtlinienverwaltung unter:

Benutzerkonfiguration > Richtlinien > Administrative Vorlagen > Windows-Komponenten > Microsoft Edge

 

Someone is currently logged into the APC Management Web Server. Please try again later.

Problem:

Beim anmelden an einer UPS Network Management Card von APC / Schneider Electric via Webinterface bekommt man nur folgenden Hinweis zu sehen:apc_webinterface_someone-currently-logged-in

Lösung:

In einigen Fällen hilft es die logoff.htm der APC aufzurufen:

http://FQDN-oder-ip-der.usv/logoff.htm

Sollte dies nicht genügen (bzw. auf den selben Hinweis hinaus laufen) hilft es, sich einmal via telnet mit der USV zu verbinden und wieder zu trennen:

telnet FQDN-oder-ip-der.usv 23
User Name : wie beim Webinterface
Password  : wie beim Webinterface

apc>quit

Danach sollte die Anmeldung auch am Webinterface wieder klappen. (Im log sieht man dann auch von welcher IP sich der Benutzer nicht korrekt abgemeldet hat.)

vmWare vSphere 5.5 vCenter/VCSA administrator SSO-Kennwort (administrator@vsphere.local) zurücksetzen

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.

vsphere-sso-kennwort-zuruecksetzenAdministrator-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 des administrators eingeben. In der Standarteinstellung lautet dieser:
    cn=administrator,cn=users,dc=vSphere,dc=local
  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.“

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

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.