Eager Zeroed - manchmal verfügbar, manchmal nicht

[UrsDerBär]

Salut,

Kann mir jemand verraten aufgrund welcher Kriterien der ESXi Webclient entscheidet ob eine neue Disc Eager zeroed / lazy zeroed oder eben nur Thin ausgewählt werden kann? Mir ist das komplett schleierhaft.

Ich habe zwar einige Infos zu einem Bug gefunden bezüglich der Grösse einer Disc weil Datastore Infos nicht übernommen werden, aber nix zu obigem. Nach welchem System der Client aber den Datastore auswählt auf welchen er sich bezieht ist für mich nicht nachvollziehbar.

Workaround ist möglich indem ein neue VM erstellt wird oder eine VM für die Erstellung der Disc gergenommen wird, wo es korrekt funktioniert. Ist beides irgendwie nervig. Beim neu erstellen nimmt er die möglichen Parameter des Datastores wo die VM abgelegt wird.

Gibt es eine schnellere Lösung? Muss ich die Kommandozeile nehmen? Jetzt wo ich mich an den webclient gewöhnt habe und der sogar richtig schnell ist?

Grüsse und Danke

[irix]

ESXi WebClient.... also der Hostclient wenn du dich per Browser direkt zum ESXi und nicht zu einem vCenter verbindest? Weil ich erinnere mich das im deutschen Hostclient da irgendwie die Uebersetzung krum war das genau das Gegenteil gemacht wurde von dem was man ausgewaehlt hatte.


Damals.... als NFS == NetApp war hies es das VMs immer autom. Thin sind. Da ich weder viel mit NFS und noch weniger mit Netapp mache kann ich nur sagen mir sind da noch nie Probleme untergekommen. Ich hab auch immer mit einem vCenter zu tun und eigentlich erstellen wir VMs immer basierend auf einer VM Vorlage. Beim spaeteren hinzufuegen von vDisks faellt uns aber auch nichts auf.

Edit: Lesen sollte man koennen.
Uns kann da bei Eager zeroed nichts auffallen weil wir ja Thin machen und haben wollen

Gruss
Joerg

[JustMe]

Der Weg ist schon richtig...

NFS ist halt file-based storage, und dort gibt's eben prinzipbedingt nur Thin-Provisioned, weil sich nur um die Datei(en) selber gekuemmert wird, und nicht um die Verwaltung derselben auf dem tatsaechlichen Datentraeger. U.a. deswegen gibt's dafuer ja auch kein Formattieren.
Local/FC/iSCSI/... ist dagegen block-oriented storage, so sich der ESXi selbst um die Verwaltung der vom Storage zur Verfuegung gestellten Bloecke kuemmert, und da kann er halt seine eigenen Dateisysteme mit deren vielfaeltigen Features ausspielen.

Das ist selbstverstaendlich unabhaengig von der Verwendung ESXi HostClient oder vCenter-Client; trotzdem sind die bereits angesprochenen Uebersetzungsprobleme nicht zu vergessen, und leider auch fuer die Zukunft ebenso nicht auszuschliessen.

[UrsDerBär]

Es spielt nicht wirklich eine Rolle ob SAN, NFS, Local Storage (RAID-Controller, Single Disc). Wenn ich die VM frisch erstelle, dann kann ich das auch auswählen. Egal auf welchem Store. Wenn die VM besteht, kann ich bei manchen VM's nix auswählen. Egal welcher Store. Bei manchen schon. Das Muster dahinter habe ich noch nicht begriffen nur bleibt es über die VM gesehen immer gleich, auch nach Reg/unreg. =)

Naja, ich erstelle immer Thick eager zeroed. NFS habe ich "nur" (mittlerweile oft) in Verbindung mit Windows als Storage VM. Da wo die OS drauf laufen, läuft anschliessend normalerweise ein Dedupe drauf. Bei Windows als Storage VM eh sinnlos was anderes, sobald man ein Quickformat im OS drüber laufen lässt, wird die Disc sowieso aufgeblasen und das ist nervig. Also lieber gleich eager erstellen.
Windows erledigt dann Thin mittels Dedupe enorm effizient.

Bezüglich Übersetzung: Nö, das ist mittlerweile korrekt. Wird auch korrekt dargestellt. Die Bezeichnungen sind mittlerweile im grossen und ganzen auch stimmig.

Ist wenn ich ohne vCenter arbeite. Weiss jetzt gar nicht wie es mit vCenter ist. Der WebClient ist mittlerweile top und vCenter etwas zu aufgeblasen für Kleinstumgebungen.

Naja ich habe mich jetzt für den Moment wieder etwas mehr mit CMD beschäftigt. Funktioniert auch.

[JustMe]

Tja, nehme ich jetzt mal als Aussage so hin. Glaube es aber nicht.

Irgendwas ist hier sowieso merkwuerdig, denn ein Quickformat im Gast sollte eine Thin-VMDK nicht aufblasen. Quick bedeutet ja gerade, dass eben NICHT alle Bloecke geschrieben werden.

Anyway: Die Beobachtungen sind oftmals unterschiedlich.

Ach ja: "Disc" steht fuer Sachen wie "Compact Disc". Eine VMDK ist eine "Disk" (mit "k").

[UrsDerBär]

Nö bei Windows als NFS-Server ist das wohl normal. Hat mir mal einer erklärt warum das so ist, Details hab ich aber wieder vergessen. War irgendwas mit Windows sei kein richtiger NFS. Bei Windows müsse man komprimieren oder deduplizieren um den Effekt von Thin zu haben. Wobei komprimieren eher dem klassischen Thin entspreche wenn auch nicht wirklich das gleiche, nur vom Speicherplatz her. Irgendwie sowas in der Art. Aber eben ist eine Ewigkeit her. Jedes mal ärgere ich mich, wenn ich mal thick vergesse und dann bei der Inst das quick eine Ewigkeit bei 0 hängen bleibt um dann direkt auf 100 zu springen.

Eine Logik habe ich rausgefunden: Wenn ich die VM in einem NFS Datastore erstelle, kann ich nur Thin auswählen. Zumindest wenn ich ihn als erstes auswähle. Also DS auswählen und auch darin installieren. Nachfolgende Disks können dann auch nur thin erstellt werden, egal welcher DS.
Wähle ich beim erstellen als erstes eine SAN oder Local Storage, änder im zweiten Schritt bei den Discs aber auf ein NFS3 Store, dann kann ich alle drei Varianten auswählen. Sprich VMX+Log etc. auf SAN oder local und Disk auf NFS. Normalerweise auch wenn ich später zusätzliche Disks hinzufüge. Aus irgend einem Grund ist das aber nicht bei allen VM's so, auch wenn alle bestehenden Disks eager zeroed sind. Kann auch gerne Screenshots machen wenn dus nicht glaubst....

Aber eben, passt eigentlich zum Bug, dass nur eine so grosse Disk erstellt werden kann wie Platz auf dem Laufwerk ist in welchem die VM ursprünglich erstellt wurde. Manche können das lösen indem zwischen DS, grösse der Disk usw. Werte verändert werden, bei manchen klappts aber auch nicht. Mein beobachtetes Verhalten entspricht eigentlich dem gleichen. Disks können so erstellt werden wie es üblich ist auf dem ersten DS der ausgewählt wurde. Warum bei NFS eager oder lazy zeroed nicht gewählt werden kann, weiss ich nicht.

Naja, mit vmkfs gehts ja problemlos, kleiner Umweg aber was solls...

[JustMe]

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...
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".

[UrsDerBär]

Bezüglich MS: Jo hat teilweise aber auch Design-Technische Hintergründe. MS arbeitet viel mehr mit geplanten Tasks mit Triggern auf Ereignisse oder Zeit als On-The-Fly. On The Fly wird eigentlich keinerlei File-System Optimierung durchgeführt, da wird nur weggeschrieben. Hat aber auch seine Vorzüge.

Bezüglich Optionen: Jo die heissen bei mir auch Thin. Thin , Thin eager bzw. schwach nullgesetzt, Thin eager bzw. stark nullgesetzt. Und Yep, das mit der Konfigurationsdatei habe ich auch festgestellt. Die letzten beiden Optionen sind bei mir bei NFS nicht verfügbar in der GUI sondern nur wenn Konfig-Datei auf Blockstorage liegt. Habe aber auch eine VM auf welche das nicht zutrifft. VMX liegt lokal auf Block und neue HDD mit Specs von NFS. Selbst nach Dereg und neureg. Insofern hat der Bug auch Vorteile, so kann ich wenigestens zeroed auf nfs erstellen. Ohne den Bug würde das nicht gehen

Ansonsten hast Du Recht! Ist nicht Thick weil ich es so ausgewählt hatte. Sorry da habe ich mich missverständlich ausgedrückt. Meine Aussage sollte heissen, dass ich immer eager zeroed erstelle. Früher ging das nur mit Thick. Heute auch mit Thin bzw. erhält man nur noch Thin-Varianten als Auswahl. Faktisch macht aber Windows-NFS aus einem Thin immer ein Thick, spätestens wenn formatiert wird. Erstellt man es als "thin eager zerored", dann dauert die Erstellung identisch lange wie wenn vollständig formatiert wird. Ist defakto also von Anfang an thick auch wenn natürlich Thin angezeigt wird. Thin wird es dann wieder wenn man per Task komprimiert oder besser dedupliziert.