Nun, dass M$ da so seine eigenen Vorstellungen von "Industriestandard" hat, habe ich auch schon mal gehoert. Muss man dann wohl so hinnehmen...
Aber alles Weitere deutet dann m.E. auf einen Fehler im ESXi HostClient hin, der sich halt mit seinem Assistenten zum Erstellen einer VM oder auch beim Aendern der VM-Konfiguration (z.B. Hinzufuegen einer Virtuellen Festplatte) irgendwann "festlegt", und zur Laufzeit des Assistenten diese Entscheidung bei Auswahl eines anderen Datenspeicher(typ)s nicht mehr revidiert.
Ich habe da jetzt mal ein wenig "gespielt", und fuer mich sieht es so aus:
Die Auswahlmöglichkeiten fuer den VMDK Type richten sich danach, auf welchem Typ Datenspeicher die Konfigurationsdatei der VM aktuell liegt. Dabei ist es egal, worauf die VM urspruenglich erstellt wurde (NFS/VMFS): Sobald die VM z.B. von NFS auf VMFS migriert wurde, bietet der Assistent alle Auswahlen, obwohl er vorher auf NFS nur Thin Provisioned anbot (OK, bei mir heissen alle drei Optionen noch "Thin...", aber das haben wir ja schon behandelt.)
Bei der Operation "Neue VM" waehlt man den (ersten) Datenspeicher selber aus (und erhaelt dessen Optionen); bei der Operation "Bearbeiten einer existierenden VM" liegt das Heimatverzeichnis der VM schon irgendwo, und dann erhaelt man die Optionen dieses Datenspeichers, weil er fuer VMDKs per Default zuerst immer "speichern mit der VM" anbietet.
Diese Fehler treten uebrigens im vCenter-Client nicht auf: Da wird beim Umstellen des Zieldatenspeichers einer Aktion auch die Auswahl der Typ-Optionen korrekt umgestellt; der Assistent sieht auch (natuerlich) etwas anders aus.
Aber ich bin jetzt vorsichtiger: YMMV...
![Wink ;-)](./images/smilies/icon_wink.gif)
Ich habe das hier nur auf NFS, VMFS und vSAN kurz ausgetestet. Das erhebt keinerlei Anspruch auf Vollstaendigkeit.
PS: Mit vmkfstools ist klar, warum eine "eagerzeroedthick" VMDK auf NFS tatsaechlich Eagerzeroedthick erstellt wird: Da schreibt vmkfstools halt gleich beim Anlegen eine Menge Nullen recht eager in die Datei, und damit wird diese eben gleich zu diesem Zeitpunkt auf die Zielgroesse aufgeblasen. Waehlt man dagegen "zeroedthick" (ohne das "eager") beim Befehl, wird die Datei auf NFS als Thin angelegt (kann man leicht mit "du *" ueberpruefen), und nicht als "Thick".