SESParse.VMDK removal after storage migration

[MSchaff]

Hello,

I've seen a number of questions about removing SESParse.VMDK files, with the vast majority of the replies suggesting that consolidating the disks or removing the snapshots should eliminate the files.  In my case, I did a storage migration of a VM from one datastore to another (in this case the target datastore was on a completely separate disk array from the original).  After the migration, vCenter reports no connection between the VM and the original datastore, and no snapshots exist on the VM.

That said, I want to be entirely sure that the SESparse.VMDK file remaining on the old datastore can be safely removed.  The file has a timestamp of two months ago, but I don't know whether that is truly reflecting it's last-accessed date.  I have full backups of the VM, but would rather not have to restore from a backup if I can avoid it.

Can anyone offer any thoughts on this?  Again, there are no snapshots in place, vCenter shows no connection between the VM and the original datastore where the file lives, and vCenter also shows no VMs remaining on the datastore.  The SESPARSE.VMDK file is roughly 2 GB in size.

Thanks for your help!

[continuum]

Make sure the VM is running to which the sesparse.vmdk may belong to.

Then create a new directory "delete-me-later" and move the sesparse snapshot into it.

When that is allowed the file is not locked by any running process.

Leave the directory where it is for a day - when none of your coworkers and colleagues complains - delete the "delete-me-later" directory.

[a_p_ · Accepted solution]

Do you see any reference to the sesparse file in the VM's current vmware.log file?

What .vmdk file name shows up for the virtual disk in the VM's settings?

André

[MSchaff]

Andre,

I migrated the VM onto different hosts a couple of times to generate new VMware.log file instances.  In the new instances, there was no mention of the SESparse.VMDK files.  Looks like they might be leftover orphans from the original VM.

I appreciate the pointer on this - I hadn't thought of checking the log files.  Thanks!