Home > Blogs > VMware vSphere Blog


Extending an EagerZeroedThick Disk

Here is something which came my way via an observation made by one of our customers (thanks Guido). When extending a VMDK which is EagerZeroedThick, the extended part is only LazyZeroed. Its probably easier to explain using the following example.

 

Step1 – Create an EagerZeroedThick VMDK:

~ # vmkfstools -c 2g -d eagerzeroedthick /vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk
Creating disk '/vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk' and zeroing it out…
Create: 100% done. 

 

Step 2 – Look at it's details. The VMFS — before the LVID indicates that it is eager zeroed thick:

~ # vmkfstools -t0 /vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk
Mapping for file /vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk (2147483648 bytes in size):
[           0:  2147483648] –> [VMFS -- LVID:4e5cda72-26b067db-5bc1-d8d3855ff8b4/4e5cda72-14e9dc64-690f-d8d3855ff8b4/1:( 581291737088 -->  583439220736)] 

 

Step 3 – Extend it by 4GB.

~ # vmkfstools -X 4g  /vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk                  
Grow: 100% done. 

 

Step 4 – Look at it's details again. The VMFS Z- indicates that it is lazy zeroed. Interesting, eh? An eagerzeroedthick VMDK that has been extended with a lazyzeroed chunk!

~ # vmkfstools -t0 /vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk
Mapping for file /vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk (4294967296 bytes in size):
[           0:  2147483648] –> [VMFS -- LVID:4e5cda72-26b067db-5bc1-d8d3855ff8b4/4e5cda72-14e9dc64-690f-d8d3855ff8b4/1:( 581291737088 -->  583439220736)]
[  2147483648:  2147483648] –> [VMFS Z- LVID:4e5cda72-26b067db-5bc1-d8d3855ff8b4/4e5cda72-14e9dc64-690f-d8d3855ff8b4/1:( 583439220736 -->  585586704384)]

 

Step 5 – If we use the correct options, we can of course grow the VMDK with an eagerzeroedthick chunk as shown below:

~ # vmkfstools -X 6G -d eagerzeroedthick  /vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk                                              
Grow: 100% done. All data on '/vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk' will be overwritten with zeros from sector <8388608> onwards.
Zeroing: 100% done. 

 

Step 6 – Look at it again & we see an initial eagerzeroedthicnk section, then a lazyzero section, and finally another eagerzeroedthick section:

~ # vmkfstools -t0 /vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk
Mapping for file /vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk (6442450944 bytes in size):
[           0:  2147483648] –> [VMFS -- LVID:4e5cda72-26b067db-5bc1-d8d3855ff8b4/4e5cda72-14e9dc64-690f-d8d3855ff8b4/1:( 581291737088 -->  583439220736)]
[  2147483648:  2147483648] –> [VMFS Z- LVID:4e5cda72-26b067db-5bc1-d8d3855ff8b4/4e5cda72-14e9dc64-690f-d8d3855ff8b4/1:( 583439220736 -->  585586704384)]
[  4294967296:  2147483648] –> [VMFS -- LVID:4e5cda72-26b067db-5bc1-d8d3855ff8b4/4e5cda72-14e9dc64-690f-d8d3855ff8b4/1:( 589881671680 -->  592029155328)]

 

If you need to grow your VMDK and you require your VMDK to be eagerzeroedthick, then be sure to use the parameters outlined in step 5 and do it via the CLI. If you do it via the UI, you have no control over the grow options and it will automatically use lazyzero'ing for the extension, even if the initial VMDK is eagerzeroedthick.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: Twitter @VMwareStorage

6 thoughts on “Extending an EagerZeroedThick Disk

  1. Satyam Vaghani

    Good point, but may I point out this is by design. The default disk type that vmkfstools assumes when the ‘-d’ option is not explicitly used is zeroedthick. This is true of extend as it is true of create.
    One might argue that at the time of extension, vmkfstools should figure out the disk type based on the file that is being extended, i.e. if it is eagerzeroedthick, extend it as eagerzeroedthick. However, such guesses are not possible since a fully written thin or zeroedthick file might look like an eagerzeroedthick file too.

  2. Chogan

    Thank you Satyam. Always great to hear from you.
    We think this may be a concern when one tries to grow an FT or MSCS VM, both of which need to use eagerzeroedthick.
    We’re having some conversations internally to see if there is a way to address those use cases.

  3. Nate Klaphake

    I am interested specifically in the MCSC piece of this conversation. I have tried and failed to expand a eagerzerothick vmdk while the cluster is running via CLI due to file locks. now I could shutdown both nodes of the cluster and expand the vmdk no problem but that defeats the purpose of a cluster where the only downtime you take is the time it takes to failover.
    Could you possibly introduce a -L lunreset into your eagerzerothick expand command in step 5 and get the expansion to start running without downtime. My guess is that if that would even work(which I doubt) you would be stuck waiting for the 0′s to be written before the clustered servers could do anything with the volume.
    would love to hear your thoughts
    Nate

  4. Chogan

    Hi Nate,
    Thanks for the comment/question. As you observed, any VM using a VMDK must be powered off before a VMDK can be grown (kb.vmware.com/kb/1007266)
    This is the reason for the file lock, and specifically isn’t related to MSCS. I don’t believe there is any way around it (and clearing the lock while the cluster is still active isn’t recommended). Sorry.
    Cormac

  5. Steve

    Hey Cormac – any update on this with the later releases of vSphere/vCenter? I just noticed this exact behavior on our vCenter 5.1 U1 environment when expanded a eager zeroed thick VMDK using the thick client.

Comments are closed.