The other day I had an issue with a VM on my ESXi (old-ish) install and I needed to move a VM to a new location. Unfortunately, the VM was quite big (about 200G) and the move process went reeeallyyy slooooow. I mean it :).
I needed to abort the move process, but I was stuck for a long time and I figured that I must wait until the move of the particularly large file finishes before the cancel is actually triggered. I've aclaculated it'd take about a day for this so I needed an alternative...
I came up with a solution that not only worked but kept my source .vmdk
intact and was much better than a reboot of the host since I have no idea what that would do to my source .vmdk
.:
- Create a new guest (I called it "Space Filler VM") on the destination datastore that's about 2GB less than the total remaining space left on the datastore and wait a few minutes.
- The move will fail due to a lack of space on the destination leaving your source
.vmdk
intact. - In the end I got all three moves to fail and my source
.vmdk
was intact.
The justification for the 2GB less than the total remaining space statement is that by the time you create the empty VM, the VM copy process is still running and, if you don't provide a decent buffer, the VM creation will fail and free up the space. This will get you back to the starting point.
Note: an a HDD-based setup like I have, copying 2GB in RAID0 is slow enough that the VM creation finished before. If you have a faster setup (like fast HDDd or SSDs), you may want to increase the buffer.
Note: The same process also works for copying VMs around.
HTH,
Member discussion: