Hi gueys, I have tested this in vSphere 6 and seems to be fixed there 
↧
By: Ondrej
↧
By: Ralf
Ondrej, where did you get the info that this is fixed in 6.0? I can not find anything related in the Changelog and can not test it at the moment.
↧
↧
By: John
I opened a support case with VMware and they confirmed this “behavior” (they refused to call it a bug and instead said it was by design), is “fixed” in 6.0. Due to the large amount of code changes required, it will not be back-ported to 5.1 or 5.5.
↧
By: Ralf
Thanks, I also opened a case a while ago and received the answer that this is the intended behavior. But i did not receive the update that this is now fixed in 6.0.
↧
By: shreyas
why virtual disks must be created using the EagerZeroedThick only ?
↧
↧
By: Ralf
Great work VMware. NOT! Now that eagerzeroed vDisks are extended in eagerzero format in 6.0, the VM does hang until the task has finished. That can be a couple of minutes for the extension of some hundred GB. This means the whole VM is not responding! No ping, nothing. And that means that we cannot increase the vDisks anymore during working hours, we need a scheduled downtime.
↧
By: Patrick Long
In our ESXi 6.0 environment, previous attempts to extend an existing eagerzeroedthick disk resulted in temporary vm inaccessibility during the extend operation due to stun operation as described in KB 2135380. The release Notes for ESXi 6.0 Update1b (build3380124) indicate the following:
” Expansion of eager zeroed VMDK causes the VM to be inaccessible
In ESXi 6.0, VMDKs of eager zeroed type are expanded in the eager zeroed format, which takes a long time and might result in the VM being inaccessible.
This issue is resolved in this release.”
Does anyone know exactly HOW this was resolved? Does the Eagerzeroedthick disk expansion process in 6.0 Update1b simply revert to the 5.0/5.5 behavior of creating the new extended part of the disk as thicklazyzeroed, thereby causing the entire newly-resized virtual disk to be reported as thicklazyzeroed?
↧
By: swiftangelus
FYI, when running the vmkfstools to extend as eagerzeroedthick VAAI is not used.
↧
By: 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.
↧
↧
By: SP
hi its a good article and we are facing exact issue in our environment, but when i tried ” vmkfstools -X 6G -d eagerzeroedthick /vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk ” for the VM what i would like to extend, its giving the following error and is unable to extend, please let me how do i get this working.
Failed to extend disk : One of the parameters supplied is invalid (1).
also, is this applicable to all vSphere versions, we are ESXi 5.1 build 1065491
↧
By: palong
Cormac – forgive me responding to this old post, but I recently ran across this issue and wanted to point out something incorrect (or at least ambiguous) about the description and command you list in Step 3 above. You wrote:
Step 3 – Extend it by 4GB.
~ # vmkfstools -X 4g /vmfs/volumes/cs-ee-symmlun-001A/cormac.vmdk
Grow: 100% done.
Actually the -X option calls for the value of , NOT the amount by which you want to extend the disk, correct? So if your original cormac.vmdk file is 10 GB, your command above will not result in a 14 GB cormac.vmdk, but rather will possibly corrupt your current disk, per KB 994 “You must specify the size you want like to Extend To and not how much you want like to Extend By. Otherwise, the disk shrinks to the new smaller size and data inside the VMDK file might get corrupted. ”
Same information is also unclear in KB 2054563
↧