Replication has filled datastore

[unsichtbarre]

I am working with a client on a situation where a large SQL replication job was started on a datastore with very little overhead (about 5%) to begin with, the snapshots have filled the datastore, then the VM failed because there was no more room for the *.vswp file.
Problem is the snapshots don't show in the snapshot manager, yet are definitely attached to the VM, as can be determined by reading the *.vmx

I had the client sVmotion one of the disks to make room and power on the VM now how can I commit the snapshots, get the VM powered on and move forward?

[Gostev]

John, it would be best to open support case with VMware on this, as they may know some specifics and gotchas, and better walk you through the process. I am sure they have seen these issues before and have the procedure documented.

[unsichtbarre]

So deleting/removing the replication job won't remove the snapshots even though they were created with a replication specifying 3 restore points? For each Virtual Disk I am seeing a *000001-ctk.vmdk and *000002-ctk.vmdk with corrisponding *000001*.vmdk (delta)?

[Gostev]

Veeam does not explicitly create any files on source VM (which is why we only require read access to the source LUN), so deleting the job will not remove any files from source VM. All these files were created by ESX host.

Some of them are snapshot files created by ESX host when our job requested that snapshot is made on a source VM (so that we could perform hot replication): replication job always issues snapshot removal command at the end of job's cycle, which normally makes ESX to remove these files; but clearly lack of disk space prevented ESX from doing this properly. Depending on what step this operation failed for ESX host; snapshot may not show in snapshot manager, but files may still exist on storage. This is the situation which is best to resolve with help of VMware support, to do it properly to avoid source VM corruption as well as any further issues down the road.

CTK files are used by ESX server to track virtual disk changes, generally these should not be removed at all (they are permanent). Although again, may be VMware will advice on removing them in this particular case, as their content may have been implicitly affected by the disk space issue.