I, like many, love the new Hyper-V in Server 2012. NIC teaming, concurrent live migration, SMB VM storage, and the all-new Replica. Replica solves a few problems, but it’s definitely not a panacea on it’s own.
There is lots of info on Hyper-V Replica out there, but a few points I wanted to make that are being skipped for those of us new to it. Most importantly: Replica does not do automatic failover.
Things Replica can do:
- Keep a copy of your VM on another server and storage, up to within 5-15 minutes of current.
- Allow you to do a manual, “planned failover” for planned maintenance of host. This requires the VM to be shutdown.
Things Replica can’t do:
- Failover automatically before host server auto reboots, such as a monthly Windows Updates. Cluster-Aware Updating does this, but isn’t related or compatable with Replica.
- Do a Planned Failover without downtime for the VM.
- Auto start the replicas if primary host or VM’s goes offline. All starts of replicas are manual.
Now there are surely ways to automate these limitations with PowerShell, and certainly with System Center Orchestrator. Example could be a PowerShell script that does a Planned Failover on all VM’s as a shutdown script on the host. Also you might be able to create a script on replica host that watches for replicas in disconnected state, and then starts up replicas. If you’ve researched or tried this, let us know in comments.
Note that there is a way (I haven’t tested) to get VM’s to replica server for planned server hardware maintenance, but it’s not pretty. On primary host, remove replication, and then run the Move command for “shared nothing Live Migration”. Then once VM is live on secondary host, re-establish replication back to primary, but this is an insane amount of data transferring, and hugely inefficient. At the end of the day I wonder if Replica doesn’t create more problems than it solves.
(edited on 5/28/2013 to reflect new learnings on Planned Failover limitations).