I’ve been using the new Storage VMotion functionality fairly heavily over the last couple of months. I have encountered a couple of significant bugs whilst using it, which have resulted in corrupted VMDK files. Here are my two tips when using Storage VMotion, to avoid the problems I have seen:
- Ensure that you have sufficient space in the source datastore as Storage VMotion uses snapshots to transfer the VMDKs over. This is a particular problem with large frequently changing VMs, e.g. database servers. Large disks mean that the whole transfer can take several hours, and frequently changing data means large snapshot files. If sufficient space is not available, the datastore can fill up, preventing any more data being written to the disks and causing the Storage VMotion to fail. I would recommend you have empty space equivalent to the size of the VM’s disk files before you start. VMFS extents are an excellent solution to this short term problem.
- The other problem I have encountered occurs when the VM has its VMDK disk files spread across more than one datastore. The operation begins successfully, but during the transfer the host gets confused and the process fails. The disks have snapshots applied, but are corrupt. Unfortunately, the only way to avoid this situation is to cold migrate all the VM’s files onto one datastore first.
Great care has to be taken to recover disks after a Storage VMotion failure, to avoid total data loss.
5 thoughts on “Problems with Storage VMotion”
But, then how do you recover corrupted vmdk file? Is there any software with you can do it? Our company does not have Storage VMotion option, but they are thinking about upgrading to entreprise edition of ESX.
Hi, i’ve a question and i can’t find a unified clear answer on the internet. Just some different cases.
My question is: where’s a list of “common reasons” that makes datastore vmotion to certainly fail? Es. you can’t move a machine with a snapshot if it’s powered on. Either you can’t if there’s a .iso mounted and it’s not visible from the destination Esx and so on… would someone please help me? Thanks a million!
Here is the official word for 4.1:
and here it is for 5.0:
The big difference is that snapshotted VMs can be moved with 5.0.
Hope that helps.
Ok, thanks… but what about other possibly causes of fault in svmotion? I still have a VM that seems to meet all the requirements but is impossible to svmove if powered on…
Which version of vSphere are you using?
What is the VM’s hardware version?
You should get a basic error message in the events tab of the VM in vCenter. If that doesn’t help, check the VM’s log file (vmware.log) and the host’s hostd.log.
You could try to move just one disk from the command line and see if it errors: http://kb.vmware.com/kb/1004040 (not sure if this works on 5.0 shell or not).