vSphere Client 4.1/5/5.1/5.5 auf Windows 7 x64 und Server 2012/2012R2 Installationsfehler

Problem

Eigentlich sind wir ja bei vSphere5, aber es kommt ja schonmal vor das man noch an ältere Maschinen dran muss. Hier die Lösung für den leidigen alten Fehler im vSphere Client Installer. Unter Server 2012/2012R2 zeigt sich auch, das der Installer auch jetzt nicht wirklich fehlerfrei läuft.

 

Fehler 1406. Wert ProductLanguage für Schlüssel …VMware Virtual Infrastructure Client konnte nicht geschrieben werden. Überprüfen Sie, ob Sie über ausreichende Zugriffsrechte für die Schlüssel verfügen, oder wenden Sie sich an den Support.

 

Lösung

Den Schlüssel:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\VMware*

einschliesslich aller Unterschlüssel löschen und direkt Widerholen drücken. Wenn zusätzlich auf dem Client noch andere VMware-Produkte installiert sind (z.B. VMware Workstation) den Schlüssel einfach vorher ex- und hinterher wider importieren. Der Schlüssel kann „Vmware, Inc“, „VMWare“ oder ähnlich heissen – je nach Sprachkombination.

Veeam: Root-Login Passwort der virtual Proxy Appliance

Manchmal braucht man doch Zugriff auf die Veeam Virtual Proxy Appliance, die die Verbindung zwischen den SureBackup VirtualLabs und dem Produktivnetzwerk herstellt. Und sei es nur um die Netzwerkkonfiguration zu testen. Der Zugang ist möglich über:

  • Username: root
  • Passwort: <Hostname der Veeam Appliance>_r

Zum Beispiel haben wir eine Maschine die „BackupMachine“ heisst. Das Login wäre folglich:

  • Username: root
  • Password: BackupMachine_r
  • Der hostname is case sensitiv und ist NICHT der FQDN (fully-qualified domain name).

„Die Anzahl der vSphere HA-Taktsignal-Datenspeicher für diesen Host beträgt 1. Dies ist weniger als die erforderliche Menge: 2“

Vmware vSphere 5 führt den Heartbeat über den Datastore ein; genau wie im Management-Network muss auch dieser folgerichtig nun redundant ausgelegt oder angebunden sein. In kleinen Umgebungen gibt es häufiger aber nur ein SAN oder nur ein einzelnes Plattenshelf und die Warnung ist ein wenig nervig. Natürlich gibt es auch keinen (klickbaren) Schalter dafür, sondern in bester vmware-manier einen erweiterten Konfigurations-Eintrag.

Die Warnung wird entfernt durch:

  • Eigenschaften des Clusters
  • Vmware HA -> Erweiterte Optionen
  • Hinzufügen eines neuen Eintrages:

    das.ignoreinsufficienthbdatastore mit dem Wert true

 

Die vSphere Dokumentation hält diesen Eintrag natürlich auch bereit. Alle erweiterten Optionen sind Hier zu finden und alle Optionen für alle Knoten (FPM und VPXD) hier.

vSphere ESXi 5 Warnung „Die Systemprotokollierung ist auf dem Host nicht konfiguriert“

Vor allem bei von vSphere 4 oder 4.1 migrierten Hosts vergisst der ESXi5 Installer gerne mal den Syslog-Host auf den ESXi-Hosts zu konfigurieren. Dann erscheint auf jedem Hoats nach dem starten im vSphere Clients diese Warnung „Die Systemprotokollierung ist auf dem Host <hostname> nicht konfiguriert“:

 

Lösung: Den Syslog-Host (den vCenter Server) einfach nachtragen:

  • Host -> Tab: Konfiguration -> Erweiterte Einstellungen
  • In der Baumstruktur „Syslog“ aufwählen
  • In dem Feld „Syslog.global.loghost“ die Adresse des vCenter-Servers nachtragen:

    udp://<fqdn-hostname-vcenter>:514

    z.B.: udp://vcenter5.cooldomain.local:514

In der Konsole auf dem Hosts (local oder SSH) geht das natürlich auch:

esxcli system syslog config set –loghost=
udp://<fqdn-hostname-vcenter>:514

Der passende KB-Artikel dazu liegt hier.

Unsichtbare Snapshots

Es gibt immer mal wieder Snapshots von virtuellen Maschinen, die nicht (mehr) im Snapshot-Manager angezeigt werden. Seit ESX 3.5 bekommt man solche zum Beispiel, indem man einen Snapshot löscht und in der selben Sekunde den betreffenden Host in den Wartungsmodus wirft, oder im falschen Moment den vCenter Server neu startet.

Kein Panik, solande am Datastore und an der VM selber nichts geändert wurde hilft dieser dreizeile, auszuführen bei ausgeschalteter (!) VM:


mv FOOBAR.vmsd FOOBAR.vmsd.old
vmware-cmd FOOBAR.vmx createsnapshot recovery "recovery" 0 0
vmware-cmd FOOBAR.vmx removesnapshots

Das dauert jetzt je nach Größe und jetzt Anzahl der Snapshots und vmdk’s ein paar Ewigkeiten, führt aber in den meisten Fällen zum Erfolg. Achtung: Snapshots werden generell erst zusammengeführt (Paet-by-Part), dann übernommen. Es sollte also genügend Platz frei sein.

Man kann dem treiben auch recht komfortabel live zuschauen, indem man an einer zusätzlichen Konsole die Zeitstempeländerungen beobachtet:

watch "ls –oghut –-full-time *.vmdk"

*thanks to David Barrett