Replicating thin VMs with guest UNMAP

[DonZoomik]

We generally run thin VMs with guest UNMAP enabled. This means that VMDKs can shrink when required.
Does this somehow work with replication as well? For example some data is deleted from VM, thin VMDK shrinks on source side. Would this be (eventually) mirrored to replica VM as well?

I fully expect it not to work due to some VMware limitations (mainly https://kb.vmware.com/s/article/56608) but maybe Veeam has devised some clever workaround? For example, occasionally delete replica snapshots and UNMAP from hotadd proxy; or write zeroes to nonexistant data and use vmkfstools --punchZero.

It'd be especially bad if Veeam replayed source VM's UNMAP commands on replica VM (while snapshot are active) - this would essentially grow replica to fully provisioned size when snapshot is commited.

I haven't tested these scenarios myself yet, just asking around if anyone has any experience as in-guest UNMAP is still relatively new and little used functionality.

[HannesK]

Hello,

Does this somehow work with replication as well?

yes it works with replication.

I did not do any further tests. But automatic UNMAP is already some years old (I had that question in my VCP some years ago for 6.5) and I expect that many installations use it.

Best regards,
Hannes

[tsightler]

If the question is, does it work, I think Hannes answer is correct, however, if the question is actually this:

For example some data is deleted from VM, thin VMDK shrinks on source side. Would this be (eventually) mirrored to replica VM as well?

I'm going to say that it's almost certain the VMDK on target VM would not shrink. Veeam uses snapshots and CBT on the source VM for replication. I'm not 100% sure how CBT would deal with this case, but my guess is it would either consider the block "changed" which would trigger Veeam to read the block or, possibly, it would just skip the block altogether. The read would produce zeros and we'd write zeros to the snapshot for the block. I just don't believe the base VMDK on the replica would ever shrink in this scenario.

[DonZoomik]

If we fstrim the whole thin file system before backup, Veeam does huge logical reads while not touching the the actual block device (Direct SAN proxy doesn't actually read anything). I guess it reports that unallocated space was marked by CBT for change and actually ignores it.

If Veeam would zero these unallocated areas on replica, it'd be very bad, resulting in effectively fully provisioned VMDKs. If Veeam ignored them, it'd be... acceptable. I could occasionally just reprovision replicas, if disk space got too big.