Wenn man ESXi 5.x bzw. 4.x auf ein SD bzw. USB Medium installieren möchte, stellt sich relativ bald die Frage, welche Hardware von VMware unterstützt wird.

In der VMware Knowledge Base findet man dazu den Artikel KB 1010574 (VMware support for USB/SD devices used for installing VMware ESXi) – leider wird auch hier nur empfohlen, eine vom Serverhersteller unterstützte Hardware zu verwenden.

Die Antwort welche das genau ist, lässt der Artikel leider aber offen. Und eine Suche auf den Seiten der Hersteller kann relativ schnell zeitaufwändig werden.

Darum habe ich eine Liste zusammen gestellt, die die mir aktuell bekannten SD/USB Medien auflistet, die für die Installation von vSphere 5.x bzw. 4.x unterstützt werden.

Sollte jemand weitere Medien (auch von anderen Herstellern) kennen die hier fehlen, bitte ein kurzes Kommentar hinterlassen.



Hewlett Packard – HP:

HP 4GB SD Enterprise Performance Flash Media Kit #580387-B21



IBM:

Source: link to ibm.com



DELL:

Informationen zu von DELL unterstützten USB und SD Medien findet man hier: VMware vSphere 5 on Dell PowerEdge and Storage Systems Compatibility Matrix – Seite 10 ff

Bis zu vSphere 5 Update 2 wurden im Zuge eines Storage vMotions (wenn notwendig) die Dateinamen bzw. der Ordername der virtuellen Maschine an den Displaynamen des vCenters angeglichen.

Das war immer dann von Vorteil wenn man den Servernamen und den Displaynamen geändert hat und dann auch die Konfigurationsdateien am Storage ändern wollte.

VMware hat dies als Bug angesehen und diese “Schwachstelle” mit dem U2 von vSphere 5 behoben – sehr zum Ärger der Community. In vielen Foren wurde immer wieder darauf hingewiesen, dass dieser Bug eigentlich mehr ein Feature war.

Doch mit vSphere 5.1 Update 1 wurde diese Änderung wieder rückgängig gemacht. In den Release notes findet man folgenden Hinweis:

vSphere 5 Storage vMotion is unable to rename virtual machine files on completing migration
In vCenter Server, when you rename a virtual machine in the vSphere Client, the VMDK disks are not renamed following a successful Storage vMotion task. When you perform a Storage vMotion task for the virtual machine to have its folder and associated files renamed to match the new name, the virtual machine folder name changes, but the virtual machine file names do not change.

This issue is resolved in this release. To enable this renaming feature, you need to configure the advanced settings in vCenter Server and set the value of the provisioning.relocate.enableRename parameter to true.

Um herauszufinden ob VAAI vom Storage unterstützt wird, verwendet man am Besten den Kommandozeilenbefehl “esxcli”.
Dazu gibt man in der ESXi Shell oder in einer SSH Verbindung folgendes ein:

esxcli storage core device vaai status get

So wird einem detailiert angezeigt, welche VAAI Primitives unterstützt werden.

Ob VAAI unterstützt wird kann man auch im vCenter herausfinden – allerdings sind hier teilweise unzureichende Informationen zu finden.

Öffnet man im vCenter den Reiter “configuration” – “Storage” so werden einem hier drei mögliche Stati angezeigt:

Supported – das bedeutet, alle vier VAAI Primitives werden unterstützt
Unsupported – kein einziges Primitive wird unterstützt
Unknown- es wird ein oder mehrere VAAI Primitives unterstützt – aber nicht alle vier!

Solange also “Supported” oder “Unsupported” angezeigt wird, ist die Sache klar. Bei “Unknown” wird man allerdings auf “esxcli” zurückgreifen müssen.

Beim Starten eines p2v Vorgangs mit Hilfe des Standalone Converters 5.0 kam folgende Fehlermeldung:

“A specified parameter was not correct. spec.synchronizeImmediately”

Lösung/Workaround:

Im Standalone Converter Wizzard bei der Auswahl “Options” / “Post-conversion” das Hackerl bei “Remove System Restore checkpoints on destination” entfernen:

Lange Zeit habe ich eine Lösung für die folgende Fehlermeldung gesucht.
Diese trat bei einigen VMs während der TSM Full VM Sicherung auf – es war absolut nicht möglich diese virtuellen Maschinen zu sichern:

“The guest OS has reported an error during quiescing. The error code was: 5 The error message was: ‘VssSyncStart’ operation failed: IDispatch error #8472 (0×80042318)”

Die Lösung war ein re-register der VSS Components mit Hilfe eines kleinen Scripts. Kopiert einfach die folgenden Befehle in eine Batchdatei (.bat) – zb. mit Hilfe von Notepad:

cd /d %windir%\system32
net stop vss
net stop swprv
regsvr32 /s ole32.dll
regsvr32 /s oleaut32.dll
regsvr32 /s vss_ps.dll
vssvc /register
regsvr32 /s /i swprv.dll
regsvr32 /s /i eventcls.dll
regsvr32 /s es.dll
regsvr32 /s stdprov.dll
regsvr32 /s vssui.dll
regsvr32 /s msxml.dll
regsvr32 /s msxml3.dll
regsvr32 /s msxml4.dll
vssvc /register
net start swprv
net start vss

Nachdem das Script in der betroffenen virtuellen Maschine ausgeführt wurde, sollte sie sich wieder ohne Probleme sichern lassen (kein Reboot notwendig):