VMware Cloud Community
storagevmotion
Contributor
Contributor
Jump to solution

storage vmotion timedout

Hi ,

I Started svmotion for a vm which has 12 disks each pointing to separate lun (12 luns). After 10 minutes svmotion stopped giving a message as timed out.

when i checked the configuration , all disks were pointing to a single LUN, but actual disks are located in same odl LUN (weird). delta disks(snapshot disks ) are getting created in the new lun pointed out where configuration files exist.

What i did is to edit the vmx config file and point each disk to same old lun and it started working fine. Though we have lost some date due to deletion of delta disks without commiting them due to business downtime and backups in hand. I dint understand the reason what made this point to same lun for all disks. If this happens how do we resolve it.

Reply
0 Kudos
1 Solution

Accepted Solutions
Chuck8773
Hot Shot
Hot Shot
Jump to solution

Welcome to the forums!!

Before modifying the vmx file, seek asistance. It was probably recoverable without losing data.

When a storage vmotion starts, ESX takes a snapshot of the disks and moves the main disk file underneath. When it is finished, it updates pointes and commits the snapshot. The delta files are stored with the config files during the svmotion. That is what you saw. The vmx was pointing to the delta files. The delta files were pointing to the main disks on separate LUNs. The process may have still been working even though it reported as timing out.

If you have a support contract with VMWare, call them next time this happens and they shoulld be able to fix it without losing data.

Charles Killmer, VCP

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

Charles Killmer, VCP4 If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

View solution in original post

Reply
0 Kudos
4 Replies
Chuck8773
Hot Shot
Hot Shot
Jump to solution

Welcome to the forums!!

Before modifying the vmx file, seek asistance. It was probably recoverable without losing data.

When a storage vmotion starts, ESX takes a snapshot of the disks and moves the main disk file underneath. When it is finished, it updates pointes and commits the snapshot. The delta files are stored with the config files during the svmotion. That is what you saw. The vmx was pointing to the delta files. The delta files were pointing to the main disks on separate LUNs. The process may have still been working even though it reported as timing out.

If you have a support contract with VMWare, call them next time this happens and they shoulld be able to fix it without losing data.

Charles Killmer, VCP

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

Charles Killmer, VCP4 If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".
Reply
0 Kudos
storagevmotion
Contributor
Contributor
Jump to solution

Hi Chuck,

Thanks for quick reply. The reason for losing data is, the delta files filled the entire LUN and server almost went down with 1 GB. So we dont have any option. We pointed our users to other same replica in one more datacenter which has backup till evening 5. we do not have time to commit the delta files and bring the server online. so we choose this option.

Why this has happedned? we are upgrading our Fibre channel from EMX 3 to EMX 4 so we have to remove data from old LUN anyway. we cant let this vm create delta files and point to old disks. this made us take this decision.

Reply
0 Kudos
Chuck8773
Hot Shot
Hot Shot
Jump to solution

Understood. If you need to prevent the VM from creating delta files, you will need to shut the VM down and then move it. It won't create any snapshots if the VM is powered off. Not sure how much downtime you can handle though. It may take a while to copy the files.

Charles Killmer, VCP

If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".

Charles Killmer, VCP4 If you found this or other information useful, please consider awarding points for "Correct" or "Helpful".
Reply
0 Kudos
storagevmotion
Contributor
Contributor
Jump to solution

Thas true. W ehave to copy nearly 2TB of data, which would takemore than 10 hours. we dont have that much time since all dept's data exist in same place. hence we took that step.

really appreciate ur quick response. Thank you very much.

Reply
0 Kudos