VMDK file stayed on both VVol Datastores after Storage vMotion
Article ID: 419012
Updated On:
Products
Issue/Introduction
After a successful Storage vMotion between VVol datastores, the source VMDK file is not deleted, leading to 'vmdk already exists' errors on subsequent migration attempts.
During the initial migration, the destination VMDK is successfully copied (e.g., appended with a numerical suffix such as TestVM_3.vmdk0001), while the source directory incorrectly retains the original .vmdk file.
Source directory observation:
ls -lha /vmfs/volumes/vvol:1####/rfc###.####.####/
-rw-rw-r-- 1 <REDACTED_SECRETS> <REDACTED_SECRETS> 596 Nov 15 14:21 TestVM_1.vmdk
-rw-rw-r-- 1 <REDACTED_SECRETS> <REDACTED_SECRETS> 599 Nov 14 22:47 TestVM_2.vmdk
-rw-rw-r-- 1 <REDACTED_SECRETS> <REDACTED_SECRETS> 622 Nov 15 14:03 TestVM_3.vmdk
Destination directory observation confirms the target file exists:
/vmfs/volumes/vvol:2####-####/rfc####-/####-####/TestVM_3.vmdk
The virtual machine's configuration file (.vmx) accurately reflects that the virtual machine is running on the new VMDK location:
less TestVM.vmx
scsi0:0.deviceType = "scsi-hardDisk"
scsi0:0.fileName = "TestVM.vmdk"
sched.scsi0:0.shares = "normal"
scsi1:1.deviceType = "scsi-hardDisk"
scsi1:1.fileName = "/vmfs/volumes/vvol:2####-####/rfc####.####-####/TestVM_3.vmdk"
sched.scsi1:1.shares = "normal"
Environment
ESXi 7.x and above.
Cause
If VMDK files remain on the source vVol Datastore after a successful Storage vMotion, the files are likely orphaned, not in use by the live VM, or are remnants of an incomplete cleanup process. This behavior is generally abnormal for a completed migration, which should clean up all related files automatically.
Symptom: Error `vmdk already exists`
Several issues can cause files to be left behind:
- Mounted ISOs or Floppy Images
Cause An ISO image or a virtual floppy image stored on the old datastore is still connected to the VM.
Solution In the VM's settings, change the CD/DVD drive and/or Floppy drive settings to "Client Device" or disconnect the media entirely. This should cause the old datastore reference in the VM summary to disappear, allowing the files to be deleted.\
- Leftover Snapshots
Cause Backup software or an interrupted process can leave behind snapshot (delta) files or snapshot metadata files (`.vmsn`, `.vmsd`) that are not properly consolidated or removed.
Solution Check the Snapshot Manager (or equivalent in the vSphere Client) for the VM. If snapshots exist, execute "Delete All Snapshots" to consolidate them into the base disk on the new datastore. If the files are still present after consolidation, they are likely safe to remove.
- Backup Software Interference
Cause Backup applications can sometimes leave behind temporary snapshot files or "attach" disks to a backup appliance during a backup, preventing proper cleanup after the Storage vMotion.
Solution Check if any backup processes were running during the migration. Verify if any other VMs (like a backup appliance) have the disk attached in their settings and remove it from there.
- VASA Provider/Storage Array Issue (vVols Specific)
Cause With vVols, the VASA provider manages the lifecycle of the virtual volumes. An issue with the VASA provider or the storage array's communication might prevent the automatic deletion of the source volumes.
Solution `<VERSION_REQUIRED>` *(Requires specific array/VASA diagnostic steps)*
Resolution
Feedback
