When you create a datastore with SimpliVity, it is assigned a Backup Policy. Any new Virtual Machines (VMs) that reside on that datastore will inherit the Backup Policy. However, if you Storage vMotion a VM to a different datastore, the VM is suppose to retain the original SimpliVity Backup Policy. In reality, your results may vary.
This is an issue if you Storage vMotion a VM to a new datastore with a different SimpliVity Backup Policy, and assume that the VM will automatically inherit the SimpliVity Backup Policy assigned to the target datastore. In our experience, we've seen an existing Storage vMotioned VM, sometimes inherit the new target datastore Backup Policy, and sometimes retain the original Backup Policy.
In addition to our existing data center in Switch Las Vegas, we recently opened up a new data center in Switch Reno. We created a new datastore in Las Vegas and a new datastore in Reno. Both new datastores have a Backup Policy that backup locally and to the remote data center. For clients who want their VMs replicated between the two data centers (or for migrations between the two datacenters), we place their VMs on the datastore with the local and remote replication Backup Policy. If a client has existing VMs that they want to replicate to the remote data center, we perform a Storage vMotion to the datastore that has the local and replication Backup Policy. We assumed that the VM would start replicating to the remote datacenter when the Storage vMotion was complete. In practice, we've seen the VM sometimes get the target datastore Backup Policy and sometimes retain the source datastore Backup Policy.
The fix here is relatively simple. After you perform the Storage vMotion, right-click on the VM, and manually assign the target datastore Backup Policy to the migrated VM. Don't assume that the VM will inherit the target datastore Backup Policy. If you do not perform this step, the VM may not receive the target datastore Backup Policy. You may not discover it's an issue until you attempt to restore the VM in the remote datacenter.