Storage VMotion - "DMotion-scsi....vmdk" stays in old datastore

[tobalf]

Hello!

After a successful storage vmotion a "DMotion-scsi0:05....vmdk" (has grown from 36 MB to about 120 MB in the last two days) file stays on the older storage. In the summary of the VM the old storage is also (the new too) shown as storage location.

What can we do, to get the whole VM Files to the new storage?

System Information:

VMWare ESX Server, 3.5.0, 84374

[Cameron2007]

if it is growing there may have been a snapshot there so roll back the snapshot. Once you have done this you could clone the VM to the new storage and all thevmdks wil be migrated.

[tobalf]

No there isn´s a snapshot on that vm (I think if there was any, storage vmotion fail before starts migration), but in this case, storage vmotion works fine and finished with status "successful"!

But Thanks for the idea.

[RParker]

Well power off the VM, remove that dvmotion VMDK from the VM, point to the correct VMDK, and make sure there are NO referrences to that old dvmotion VMDK file. Then power on the VM. make sure it comes up, and looks correct. Leave that 'OLD' file where it's at for a week. If you don't need it, delete it.

Problem solved.

Data Vmotion works like a snapshot in reverse. It keeps updating data to the old location while it rewrites / moves the original VMDK. It may have been a successful move, but apparently it didn't change the link. So it only needs this file WHILE the data is being migrated. Once the migration is done, it doesn't need it, but it doesn't always change the vmx file to reflect this, hence the left over usage of the dvmotion file. You can delete it if you are sure ALL the data to the original VMDK is in tact.

[tobalf]

Thank you for your answer.

The DMotion File in the old datastore has grown to near 1 GB now and I think there will be some actual data stored in this Dmotion File. Can I delete it although it is growing?

[Cameron2007]

try to clone the VM and bring it up elswhere and check if the old vmdk either comes across or is no longer needed then you should be able to see if you need it or not.

[tobalf]

The Problem was known by VMWare and it is grounded in a ServicePack1 on ESX 3.5.0, 84374. The not moved virtual disk was "Independet", and that cause the problem. Before storage vmotion we had to deactivate this option and everything would work.

Solution from VMWare: "There is a known issue with the Storage VMotion of Independent-persistent disks. The workaround is to change the disks from "Independent-persistent" to "persistent" before starting the Storage Vmotion. Once the Storage VMotion is complete, the disks can be changed back to "Independent-persistent".

We solve this problem now by creating a new virtual drive, copy everything from the not moved drive to the new drive (in this case database files), and delete then the "old" drive and therewith the datastore.

Thanks for you replies!

[mdinisoae]

Thanks a lot Cameron2007.

I discovered the same problem today for one of my server when I tried to extend VMDK file. I checked settings and I saw settings for disk Independent-Persistent.

So ... I remove settings for disk and I create a clone VM to other location. Now everything comes to normal.