Deleted VM expiration by TSM for VE

The classical implementation of TSM for VE relies on one or multiple Datamover node processing the backups (let's say at least one).

A Datamover node is usually not the "master" node, i.e. the datamover node is a proxy node of the main "container" node managing the retention of all the VMs. The main node generally corresponds to a Datacenter and stores all the VM as filespaces (not files).

Datamover nodes are performing all the backups, never the main node. In this situation, when a VM deletion occurs, the expiration of the deleted VM thru the usual parameters of the VM Management Class does not apply (VERDELETE then RETONLY/RETEXTRA that applies to deleted versions).

A datamover node connected to a HOST (not to a vCenter) is not able to track a deleted VM, and thus is not able to inactivate any deleted VM.

Thus, deleted VM are never expired and consumes a lot of storage in the TSM back-end.

Deleted VM management in TSM storage has to be a manuel process which is not convenient for a large Cloud or VMware environment.

The requirement is to have an automatic process (command or script bundled in TSM for VE) that searches for deleted VMs in a DC and then expire the corresponding VMs based on retention critiria (delete filespace command would be necessary as TSM retention parameters does apply to files not filespaces).