Guide for VM Server Migration...

Joel

Hi Team
So I was wondering if anyone has posted before, or can create a step by step (basic level) guide of how to migrate a VM.

Let me explain... I have an environment with approx 50 users and they use HyperV with three VM's running: (1xDC, 1xFileServer, 1xSQL Server).

I have a unused server with relatively good spec just lazing around so i'd like to put it to good use and do some testing, breaking and fixing on it. A couple of things i'd like to test/demo/try....

taking those 3x VM's and migrating them to the demo/test sever.
Excuse my ignorance but could I quite simply copy those VDHX files from inital server, put them onto the new and spin them up (after matching the IP settings etc)? I was wondering if there was any simple guide on this someone has posted before? Is it as simple as that?
Once I have those 3x VM's running, I'd like to then test replciating the server to an Azure environment - I appreciate there is more involved with his perhaps but I believe using the Windows Admin Centre tool - there are some links which will help me with this so for now (unless others again have a good guide on this), I'd like to start with part 1 and simply migrate those VMs from one server to another...

Is there any usefil tips/tricks/guides on this floating around?
Thanks

scottalanmiller

@Joel said in Guide for VM Server Migration...:

taking those 3x VM's and migrating them to the demo/test sever.
Excuse my ignorance but could I quite simply copy those VDHX files from inital server, put them onto the new and spin them up (after matching the IP settings etc)?

You could...

Move manually as you describe. Literally just copying things over.
Move using a backup and restore system (Veeam, Unitrends, Storagecraft, URBackup, etc.)
Move using a vMotion technique.
Rebuild using scripts or a state management system (or manually.)

scottalanmiller

@Joel said in Guide for VM Server Migration...:

Once I have those 3x VM's running, I'd like to then test replciating the server to an Azure environment - I appreciate there is more involved with his perhaps but I believe using the Windows Admin Centre tool - there are some links which will help me with this so for now (unless others again have a good guide on this), I'd like to start with part 1 and simply migrate those VMs from one server to another...

While possible for testing, be aware that some workloads, like databases and file servers, don't make sense in the cloud and will be a disaster to actually use. These are workloads we never put there.

Also, of all clouds, Azure is pretty much the worst. High cost, low performance, poor reliability. Unless you are forced into this, it shouldn't even be on a short list for consideration.

For your first clouds, consider Vultr, Digital Ocean and Linode. When you get advanced, AWS and maybe Softlayer.

Azure would be so far down on my list of things to even look at.

PhlipElder

1: Export from the source and import at the test server.

2: Why not use Azure backup to back up the production VMs and then use that backup to restore to the test server? That would be a great way to test the entire process.

Obsolesce

Live migration works well.

PhlipElder

@Obsolesce said in Guide for VM Server Migration...:

Live migration works well.

Indeed. Set up Kerberos Constrained Delegation between the old and new host and configure incoming migration settings on the new host and go for it. Shared Nothing Live Migration.

It can also be done using self-issued certificates thus avoiding the AD join and changes.

JaredBusch

Except he does not actually what migration he wants a copy of the VM on the other server so you can test to break things without messing with his live system

Obsolesce

@JaredBusch said in Guide for VM Server Migration...:

Except he does not actually what migration he wants a copy of the VM on the other server so you can test to break things without messing with his live system

Then I would set up replication to the new server. After replication is finished, you can disable replication and be left with a replica you can reconfigure offline.

It's the easiest way to get a real copy somewhere else with minimal effort and requirements.