I get questions about SRM and VR every day and if the same question comes up more than once I document it in the SRM FAQ or vSphere Replication FAQ. If you have questions about either SRM or VR I recommend looking there first. Now and in the coming months, I’m going to highlight some of the questions and answers that I’m asked frequently.
What changes and doesn’t change when SRM fails over a VM?
SRM is coordinating the replication of the VMX file, and moving the VM to a new vCenter, so the attributes it preserves are the ones that are in the VMX file, and unrelated specifically to the protected site vCenter.
What is preserved:
– GUID (note that the placeholder VM at the recovery site will have its own UUID. However after a failover, the recovered VM will have the same UUID as it did at the protected site)
– MAC address
– VM config (nics, drives, etc)
What is not preserved
– MOID
– Reservations/limits (these can be configured on the placeholder, or even better, use a resource pool and map it in SRM)
– DRS configurations (affinity/anti-affinity rules, DRS groups, etc)
– VM permissions
More details on reservations, affinity rules, and limits:
When Site Recovery Manager recovers a virtual machine to the recovery site, it does not preserve any reservations, affinity rules, or limits that you have placed on the virtual machine. Site Recovery Manager does not preserve reservations, affinity rules, and limits on the recovery site because the recovery site might have different resource requirements to the protected site.
You can set reservations, affinity rules, and limits for recovered virtual machines by configuring reservations and limits on the resource pools on the recovery site and setting up the resource pool mapping accordingly. Alternatively, you can set reservations, affinity rules, or limits manually on the placeholder virtual machines on the recovery site.
Why don’t SPPGs (Storage Policy-Based Protection Groups) require a placeholder datastore?
For storage policy protection, Site Recovery Manager applies inventory mappings to virtual machines when you run a recovery plan that contains a storage policy protection group.
With array-based and vSphere Replication protection groups, Site Recovery Manager applies inventory mappings at the moment that you configure protection on a virtual machine. With storage policy protection groups, because storage policy protection is dynamic, Site Recovery Manager only applies the inventory mappings at the moment that you run a recovery plan. Virtual machine placement decisions are made according to the inventory mappings when a recovery plan runs, so Site Recovery Manager does not create placeholder virtual machines on the recovery site.
Can SRM failover automatically?
Technically yes. Is it recommended? No. SRM workflows, including failover, can be triggered by a script. However, In almost all scenarios, falling over in an automated fashion is a poor idea. There is a lot of risk associated with it and a lot of potential liability for failing over due to incorrect reasoning. Failing over automatically in test mode, however, makes a lot of sense For more details see this blog post – Automating Failover with SRM and PowerCLI
What are the requirements for having SRM change VM IP addresses?
There are two requirements.
1. The VM must have a supported version of VMtools installed
2. The OS on the VM must be compatible with vCenter’s Guest OS Customization feature. This can be checked here
How does SRM respond if licensing isn’t available for a VM?
Licensing restrictions are only imposed when a VM is protected. The idea behind this is that recovery should always work. Keep in mind that running a reprotect workflow will trigger the license check so valid licenses will be required. If there are insufficient licenses at the recovery site (which is now your protected site) the reprotect workflow will fail.
Remember that SRM is licensed per protected VM so if the license key is installed at the protected site, not using enhanced linked mode when the VMs failover to the recovery site they won’t be able to be reprotected until licenses are moved from the protected site.
