In the process of planning an upgrade to SRM & vSphere Replication 8.5, I noted the following in the vSphere Replication 8.5 release notes:
NEW A replicated VM becomes unresponsive or cannot serve network requests
During a vSphere Replication sync operation, the VM disk I/O blocks for the duration of the sync. The vSphere Replication filter driver fails the SCSI UNMAP commands during a sync operation, if these commands override the transfer of the current replica disk to the target site.
Workaround: Allow vSphere Replication to accommodate the UNMAP commands.
esxcli system settings advanced set -o /HBR/DemandlogFailCollidingUnmap -i 0
The command takes immediate effect and you don't need to perform a system reboot
I haven't been able to find any additional information on this. Has anyone seen this issue? Or does anyone have more information on this issue? I'm trying to confirm if an actual source VM can become unresponsive, and therefore could impact end users \ customers, if this issue arises.
I believe we ran into this issue. We have an RDS environment being Repl using vSphere Repl and our user profiles are stored on a File Server. Since the entire RDS environment relies on this FS, the entire environment became unresponsive when it went into a sync operation. The VMDK that had the user profiles stored actually became disconnected from Windows' perspective. This was a major headache for us. I didn't think a source VM could be affected by vSphere Repl like this. It's also the only thin provisioned VM we have, so this may be part of the issue? Our other VM's using vSphere Repl are not affected during a normal sync operation.