Quantcast
Channel: Comments on: Extending an EagerZeroedThick Disk
Viewing all 31 articles
Browse latest View live

By: Satyam Vaghani

$
0
0

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.


By: Chogan

$
0
0

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.

By: Nate Klaphake

$
0
0

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

By: Chogan

$
0
0

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

By: swiftangelus

$
0
0

FYI, when running the vmkfstools to extend as eagerzeroedthick VAAI is not used.

By: Steve

$
0
0

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

$
0
0

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

$
0
0

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


By: palong

$
0
0

Grrr – should say -X calls for the value of New disk size

By: SP

$
0
0

Hi Cormac & palong,
thanks for creating and responding on this article, i was in a similar situation mentioned in this.
used the above command for extending the disk type and was sucessfull with message saying 100 % done at the end of the extending process, i can see the extended .vmdk file size in datastore, but thats not reflecting VMware GUI for the VM’s vmdk file and is still showing the old size only.

also, can this be run on Powered ON VMs as well, if so why is this command #vmkfstools -t0 /vmfs/volumes/DATASTORE/VM/VM.vmdk not working on Powered ON VMs and i am getting the below error.

“Failed to open virtual disk: Failed to lock the file 16392″

the above command is only working on Powered “OFF” VMs.

Please check with this and reply.

thanks
SP

By: Ralf

$
0
0

I ran into this today and I cannot belief that this is still an issue. So at the moment there is no way to extend a eager disk in eager format while the VM is running? I just checked the disks in one of our clusters and all of them that were extended in the past are now lazy. This is a real bummer.

By: Ondrej

$
0
0

Hi gueys, I have tested this in vSphere 6 and seems to be fixed there :)

By: Ralf

$
0
0

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

$
0
0
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

$
0
0

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

$
0
0

why virtual disks must be created using the EagerZeroedThick only ?

By: Ralf

$
0
0

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: palong

$
0
0

Grrr – should say -X calls for the value of New disk size

By: SP

$
0
0

Hi Cormac & palong,
thanks for creating and responding on this article, i was in a similar situation mentioned in this.
used the above command for extending the disk type and was sucessfull with message saying 100 % done at the end of the extending process, i can see the extended .vmdk file size in datastore, but thats not reflecting VMware GUI for the VM’s vmdk file and is still showing the old size only.

also, can this be run on Powered ON VMs as well, if so why is this command #vmkfstools -t0 /vmfs/volumes/DATASTORE/VM/VM.vmdk not working on Powered ON VMs and i am getting the below error.

“Failed to open virtual disk: Failed to lock the file 16392”

the above command is only working on Powered “OFF” VMs.

Please check with this and reply.

thanks
SP

By: Ralf

$
0
0

I ran into this today and I cannot belief that this is still an issue. So at the moment there is no way to extend a eager disk in eager format while the VM is running? I just checked the disks in one of our clusters and all of them that were extended in the past are now lazy. This is a real bummer.

Viewing all 31 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>