2

I need to migrate a number of VM's to a new server and was wondering if it is possible to use the approach of replicating the VM's to the new server with the new server acting as the replica destination and then simply use these replicas as the main VM's on the new server and then switching off the old server once completed.

As far as I'm aware, the replica VM's are the same as the original ones and this should not be a problem. Is this correct?

If the above understanding is correct, could I then set up another (3rd) server to act as the permanent replication server for the new server?

To clarify, I have say 5 VM's running on HOST1. I would set up HOST2 to receive the replication of the 5 VM's. Once completed, I'd then start the replica VM's on HOST2 and have HOST2 as my main server and decommission HOST1.

The further question is then can I set up HOST3 to be the new permanent replication server for HOST2 and all will work well? So replica's of the replica.

Currently HOST1 runs Windows Server 2012R2 and HOST2 will run Server 2016, a quick read indicates that you can replicate between these two OS's. Happy to be corrected on that though.

I can't think of a reason why this would not work unless Hyper-V knows they are replica's and wouldn't allow this operation.

That being the case (not possible to do this), I could export them, but this would take longer and I prefer the replica router as they'll be more up to date when I come to make the changes and I want to minimise downtime.

All comments/feedback on this approach?

Thanks.

3

I have used Hyper-V replication as a method to migrate VMs. It can work fine. You can't failover(migrate) via replication without stopping the VM during the failover, but that should only take a minute or two.

Just setup replication, of all the VMs you want to migrate. Wait for everything to sync up. When you are ready to migrate, stop the VM(s) and use the 'Planned failover' action, choosing the option to reverse replication and start the VM on the new server.

Keep in mind that when setting up replication you should ideally have VMSwitches on the source/destination that match name and configuration.

When you do the initial replication Hyper-V may default your VMs to be stored in a non-optimal path. If you setup replication, and then schedule it to happen 30 minutes in the future, and before replication starts migrate the VM storage on new host.

I like My VMs stored in D:\Hyper-V\{name of vm}, when you enable replication, the replica on my system defaulted to D:\Hyper-V\Hyper-V Replica based on my config. This is a PS fragment I used to relocate things.

Get-VM |
Where-Object { $_.Path -eq 'D:\Hyper-V\Hyper-V Replica' } |
ForEach-Object {
    $MoveOptions = @{
        'Name'                   = $_.Name
        'DestinationStoragePath' = 'D:\Hyper-V\{0}' -f $_.Name
    }
    Move-VMStorage @MoveOptions
}

Anyway, once everything is migrated, just remove replication between the new+old server. Then you can setup replication to your new permanent replication target.

  • 2
    Following up on this, I’ve migrated between HyperV clusters with this method. It takes a bit of planning to line it up nicely as zoredache implies, but it’s absolutely rock solid, there will obviously be a brief outage while failover happens as you can’t do this to a running machine, but it gives you a back-out plan and should be fine. – Rob Moir Apr 24 at 18:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.