Kategorie-Archiv: VMware

Warnung „esx.problem.hyperthreading.unmitigated“ unter ESXi 6.5/6.7

Veröffentlicht am von — Keine Kommentare ↓
esx.problem.hyperthreading.unmitigated

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.

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
SuppressHyperthreadWarning

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.

Office 2013 auf Office365 offline herunterladen/installieren oder im Netzwerk verteilen
VMWare Workstation 9.0.2 Release Notes
Office 2010 aus Office365 sagt "Produkt nicht aktiviert"

VMware vSphere VCSA/vCenter Liste über VMs mit Betriebssystemen ausgeben

Veröffentlicht am von — Keine Kommentare ↓

Manchmal braucht man eine schnelle Liste über die laufenden Gast-Betriebssysteme (und -Versionen) in einer vCenter-Instanz. In meinem speziellen Fall benötigte ich vor allem die konfigurierten Betriebssysteme und die tatsächlich laufenden Gäste, um nach einer Migration die Einstellungen für die ESXi-Hosts auz zu räumen.

Nach ein bisschen Bastelei nutze ich nun diesen PowerCLI Einzeiler. Das Script erstellt einfach eine Liste über Name, Konfiguriertes OS und das gemeldete OS aller Gastsysteme.

Lösung

Liste aller OS in einem vCenter via Powershell erstellen:

Get-VM | Get-View -Property @("Name", "Config.GuestFullName", "Guest.GuestFullName") | Select -Property Name, @{N="Eingestellt";E={$_.Config.GuestFullName}},  @{N="Läuft";E={$_.Guest.GuestFullName}} | Format-Table -AutoSize
So sieht die Ausgabe des Befehls aus.

Exchange 2010 "Sie verfügen über 10 Telefonpartnerschaften ..."
Windows 10 Anmeldung mit Fingerabdruck in Active-Directory Domäne via GPO erlauben
VMware ESXi/vCenter: Wann war eine VM das letzte mal eingeschaltet?

Veeam Update „Warning 1327.Invalid Drive D:\“

Veröffentlicht am von — Keine Kommentare ↓

Normalerweise sind Veeam Backup&Replication Updates dank der extensiven Q&A-Kultur von Veeam äußerst stressfrei und unter Berücksichtung der neuen Features/Funktionen schnell erledigt. Es gibt aber ein Problem im Setup der aktuellen Versionen (hier: Update 4a) wenn der „Veeam Backup Catalog“ irgendwann einmal verschoben wurde. Das Update-Setup

Warning 1327.Invalid Drive: D:\

Lösung

Der VBRCatalog wurde offensichtlich irgendwann einmal verschoben. Das Setup liesst bei der Installation einmal den Pfad aus der Windows-Freigabe aus, wenn die Installation lokal ist, und versucht diesen veralteten Pfad dann erfolglos zu nutzen.

  1. In der Computerverwaltung unter den Freigaben die Freigabe „VBRCatalog“ prüfen und den Pfad korrigieren (auf die Berechtigungen achten!)
  2. In der Registry diesen Pfad ebenfalls korrigieren: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup Catalog (Zeichenfolge: „CatalogPath“ auf den richtigen Pfad ändern, zum Beispel „C:\VBRCatalog“)

Danach das Setup neu starten und schon läuft es wie gewohnt stressfrei durch.

vSphere erzeugt beim Snapshots-Erstellen NTFS-Fehler auf Windows-Servern (Event 50/57/137 ...)
Windows 7 Update "Es wird nach Updates gesucht" dauert ewig, wird nicht fertig
Windows Server 2016 (oder Windows 10) Windows Update 0x8024001e

vSphere Gastinformationen im vCenter manuell aktualisieren

Veröffentlicht am von — Keine Kommentare ↓

In einen VMware Gast gehören idealerweise möglichst aktuelle VMware Tools installiert und gestartet. Denn nur dann gibt es zusätzliche Funktionen wie die Guest Operations-APIs, mit denen der Admin Dinge direkt im Gast ausführen kann, auch wenn kein Netzwerk verfügbar ist. Zusätzlich gibt es in der VCSA Konsole einen Einblick in den Gast, zum Beispiel das installierte Betriebssystem, einige Datenträger und vor allem die Netzwerkinformationen wie Hostname und IP-Adressen.

Das Standardintervall für die Aktualisierung dieser Informationen beträgt 30 Sekunden. Im Allgemeinen ist das auch vollkommen okay, da sich in der Regel weder die Adresse noch das Betriebssystem allzu häufig ändern

Wenn man aber beispielsweise mehrere Instant-Clones ausführt und sich auf die vSphere-API und die GuestInfo-Daten zur Ermittlung der IP-Adresse des Gasts verlassen muss, sind 30 viel Zeit. Zumal der eigentliche Clone-Vorgang in ein paar Sekunden fertig ist.ne viel einfachere Lösung.

Lösung

Es gibt die Möglichkeit für ein Instant-Update:

c:\Program Files\VMware\VMware Tools\VMwareToolboxCmd.exe info update network

Unter Linux:

~$> /usr/bin/vmware-toolbox-cmd info update network
Shit like this Lenovo: Neuer Synaptics Treiber zerstört die Mittle-Maustastaste
Windows 7 Offline-Cache leeren (Zurücksetzen)
Windows 10 Store Apps im Autostart ausführen oder auf Desktop verknüpfen

VMware ESXi/vCenter: Wann war eine VM das letzte mal eingeschaltet?

Veröffentlicht am von — Keine Kommentare ↓

Manchmal ist es hilfreich zu wissen, wann ein VMware Gast zuletzt eingeschaltet gewesen ist. Es soll ja schon mal vorkommen das „tote“ virtuelle Maschinen jahrelang auf der Infrastruktur liegen aber eigentlich nicht mehr gebraucht werden.

Lösung

Es gibt keine „eingebaute“ Möglichkeit, Einschaltdaten von VMs nachzuschlagen. Am einfachsten ist es aber, das Ereignisprotokoll rückwärts nach dem letzten „Power on“ Event zu durchsuchen.

An der PowerCLI Powershell geht das beispielsweise so:

Get-VM GASTNAME | Get-VIEvent -Types Info -MaxSamples 1000 | Where-Object {$_.fullFormattedMessage -match "Power On"} | %{Write-Host $_.vm.name $_.createdTime | Out-Default}

Wobei hier „MaxSamples“ ein Beispiel ist; möglicherweise muss man mehr Events durchsuchen. Wenn man beispielsweise oft Sicherungen von Gästen via VCB erstellt, reichen 1000 Events nicht aus.

Ohne die Angabe „GASTNAME“ gibt es eine Liste aller verbundenen virtuellen Maschinen.

Office365 (Office 2013 ProPlus Programme) stürzen beim starten ab
Nach einem Upgrade von vSphere 4.1 auf 5 kann der datastore nicht erweitert werden
Stromproblem

VMware Speicherrichtlinie neu anwenden – Ungültige Konfiguration der virtuellen Maschine.

Veröffentlicht am von — Keine Kommentare ↓

Problem:

Man hat frisch eine Storage Policy konfiguriert und auf eine VM angewendet. Es wurden allerdings nicht alle Einstellungen sofort übernommen (z.B. die NimbleStorage AppSync Konfiguration).
Nach dem Korrigieren dieser, möchte man die Richtlinie neu anwenden. VMware zeigt einem jedoch den Fehler:

Ungültige Konfiguration der virtuellen Maschine.

Lösung:

Die VM hat vermutlich noch einen Snapshot. Nach dem entfernen klappt das erneute Anwenden der Richtlinien sofort.

Wo kann ich das HPONCFG herunterladen?

BIOS und EFI Version unter Windows anzeigen (ohne reboot)

Fehlerbeschreibung des Tages

HPE NimbleStorage Snapshots von VMware VVols mit VSS AppSync

Veröffentlicht am von — Keine Kommentare ↓

Problem:

Man hat gerade ein frisches Nimble Array in Betrieb genommen, iSCSI konfiguriert, einen VVol Datastore erstellt und VMs dorthin migriert.
Nun möchte man z.B. von einem Windows Server 2012 R2 mit installiertem SQL-Server 2014 Snapshots mit VSS (im Nimble-Jargon: „Application Synchronization“) konfigurieren.
Dazu gibt es von HPE auch einen brauchbaren Guide allerdings scheitert es in dem Moment in dem man im Nimble Plugin für den vSphere Client AppSync für die Maschine aktivieren möchte:
Der vSphere Client braucht einen Moment und zeigt einem dann den Fehler:

Ein allgemeiner Systemfehler ist aufgetreten: java.lang.IllegalStateException: Could not find guest iqn to add to initiator group

Lösung:

Die VM muss über das iSCSI-Netz mit der Nimble reden können. Da wir in unserem Fall ein Separates VLAN für unser Storage-Netz angelegt haben, empfiehlt HPE eine VM-Portgruppe auf dem „Storage-vSwitch“ hinzuzufügen und der Maschine eine zusätzliche vNIC in dieser Portgruppe hinzuzufügen. (Im Windows kann man dort dann auch alle Elemente außer TCP/IPv4 für diese Netzwerkkarte ausschalten).

Der Guide besagt außerdem bei der Installation des Nimble Windows Toolkits (NWT), für VMware/VVol umgebungen wird MPIO auf dem ESXi geregelt, daher solle man die „Nimble DSM for MPIO“ (und somit auch „Nimble Connection Manager for iSCSI“) Option abwählen.
Leider gibt es derzeit (getestet mit NimbleOS 5.0.5.0-585753-opt) einen (mehr oder weniger bekannten) Bug im AppSync, welcher dafür sorgt, das derzeit *immer* der Nimble Connection Manager (NCM) benötigt wird.

Daher:

  1. Portgruppe auf dem iSCSI vSwitch hinzufügen
  2. der VM eine Netzwerkkarte in dieser Portgruppe hinzufügen
  3. Netzwerkkarte in Windows konfigurieren (nur TCP/IPv4 aktivieren, feste IP-Adresse vergeben)
  4. das Windows Feature „Multipath-I/O“ (Multipfad-E/A) auf der Maschine hinzufügen
  5. das NWT-Setup erneut ausführen und den NCM nachinstallieren. Das Setup behauptet dann, es wäre noch ein Neustart erforderlich, das AppSync funktioniert aber auch ohne selbigen.
  6. Dann AppSync erneut über das vSphere Client Nimble Plugin aktivieren. Dieses mal ohne Fehlermeldung

vSphere mountet Datastore nicht "Device detected to be a snapshot"

Outlook 2010/2013 "Diese Ordnergruppe kann nicht geöffnet werden. Fehler bei der Anmeldung an Micros...

Bitlocker: "Kann die angegebene Datei nicht finden"