Kategorie-Archiv: VMware

Veeam Backup & Replication: „RPC error: Zugriff verweigert Code: 5“

Veröffentlicht am von — Keine Kommentare ↓

Problem

Veeam Backup and Replication sichert „auf einmal“ eine oder mehrere VM-Gastmaschinen nicht mehr, oder nur mit einer Warnung (je nach Application-Processin Einstellungen). Das passiert nach einem Upgrade der betroffenen virtuellen Maschinen auf Windows Server 2016. Die Fehlermeldung im Veeam-Bericht lautet:

Failed to prepare guest for hot backup. Details: Failed to check whether snapshot is in progress (network mode).

RPC function call failed. Function name: [IsSnapshotInProgress]. Target machine: [SERNAME.DOMAIN.TLD]. RPC error:Zugriff verweigert Code: 5
 Failed to index guest file system. Veeam Guest Agent is not started

Lösung

Bei Windows Server 2016 müssen die Credentials nicht mehr im UPN-Format ([email protected]) angelegt sein, sondern imklassischen NT-Format (DOMAIN\username). Warum das plötzlich so ist, wissen wir leider nicht und konnten das auch noch nicht herausfinden. Wenn man die Credentials aber entsprechend ändert, klappt die Application-Processing Sicherung aber sofort wieder.

VMware Tools Tray-Icon auf RDS- oder Terminalservern via GPO ausblenden

Veröffentlicht am von — Keine Kommentare ↓

In einer RDS/View/Desktop Umgebung wird das niedliche VMware Tools Icon ständig und bei allen Benutzer im Tray angezeigt. Der Benutzer hat zwar keine Möglichkeit den Prozess zu mißbrauchen, trotzdem frißt der VMwareTray.exe-Prozess lockere 3Megaby RAM (pro Nutzer) und hat keinen sinnvollen Nutzen.

Der Schlüssel für die dauerhafte Ausblendung des vmware Tray-Prozesses lautet:

[HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware Tools]
"ShowTray"=dword:00000000

Der DWORD(32)-Wert „ShowSystray“=0 bedeutet dass das Icon nicht angezeigt wird, mit dem Wert 1 ist es wieder sichtbar

Daß der Prozess überhaupt gestartet wird, ist im RUN Schlüssel des Systems abgelegt. Daher kann auch dieser entfernt werden. Beide Einstellungen sind natürlich auch über Group Policy Preferences konfigurierbar.

 

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