*offtopic* kann es sein, dass VMware zu viel Zeit in VVOLs und VSAN investiert oder die Leute dort seltsame Sachen rauchen?
Bitte korrigiert mich, aber ich habe gerade bemerkt, dass ich eagerzeroedthick vmdks nicht im eagerzeroedthick Format online vergrößern kann.
Wenn ich solche VMDKs online über die den vSphere Client vergrößere, dann bleibt der "alte Teil" der VMDK weiterhin eager, der angehängte Teil ist vom Typ lazy. Beeinflussen kann ich das Format dort gar nicht.
Code: Alles auswählen
# vmkfstools -t0 /vmfs/volumes/.../test/test.vmdk
Mapping for file /vmfs/volumes/.../test/test.vmdk (21474836480 bytes in size):
Der erste Teil bleibt eager:
Code: Alles auswählen
[ 0: 10737418240] --> [VMFS -- LVID:54e5a7ac-0bc7740a-0c56-0000c9f56ce8/54e5a7ac-00b7b227-491c-0000c9f56ce8/1:( 3563845582848 --> 3574583001088)]Der zweite Teil ist lazy (VMFS-Z = lazy)
Code: Alles auswählen
[ 10737418240: 10737418240] --> [VMFS Z- LVID:54e5a7ac-0bc7740a-0c56-0000c9f56ce8/54e5a7ac-00b7b227-491c-0000c9f56ce8/1:( 4180540391424 --> 4191277809664)]Dazu gibt es bei VMware auch einen KB Artikel.
Attempts to extend the size of an EagerZeroedThick VMDK from the vSphere Client might result in a LazyZeroedThick VMDK (http://kb.vmware.com/kb/2054563)
Das ist ja super - abgesehen davon, dass es im Betrieb etwas schwierig ist im L1 für die Vergrößerung einer simplen vDisks die CLI zu verwenden. Verschwiegen wird aber auch, dass das auch nicht online geht, zumindest nicht bei meinen Tests.
Code: Alles auswählen
# vmkfstools -X 5G -d eagerzeroedthick /vmfs/volumes/.../test/test.vmdk
Failed to open virtual disk (/vmfs/volumes/.../test/test.vmdk): Failed to lock the file (16392)Auf unseren neuen IBM SVC Storage ist die Vorgabe die VMDKs wegen Kompression eager thick anzulegen, auch diverse Applikationen geben das vor.
Was übersehe ich? Es kann doch nicht sein, dass man entweder die VM für eine Vergrößerung herunterfahren muss, oder eine svMotion Aktion durchführen muss.
)
