Hypervisor migration
Moving a client’s virtual machines from one hypervisor to another, such as between VMware vSphere and Microsoft Hyper-V, in either direction.
Each server keeps its applications, its data, its name and its place in the domain. Almost everything underneath it changes. That layer in between is where these projects go well or badly.
What stays, and what changes underneath
A virtual machine is an operating system running on hardware the hypervisor invents for it. Change the hypervisor and that hardware changes too, even though nothing physical has moved.
Here is the same server on each platform.
| Layer | VMware vSphere | Microsoft Hyper-V |
|---|---|---|
| Applications and data | The same on both sides | |
| Operating system and identity | The same installation, computer name and domain membership | |
Below this line, nothing carries across as it is |
||
| Inside each machine | ||
| Guest toolsThe old platform’s tools come out and the new platform’s go in. VMware Tools in particular is far easier to remove while the machine is still on VMware. | VMware Tools | Integration services |
| Boot firmwareA Hyper-V machine’s generation is fixed when it’s created. A server that boots from BIOS can’t become Generation 2 as it is: its boot disk has to change partition style first, or it lands as Generation 1. | BIOS or EFI | Generation 1 (BIOS) or Generation 2 (UEFI) |
| Disk controllerA Linux guest needs the destination’s storage drivers in its boot image before the move, or it can’t find its own root disk. | VMware Paravirtual or LSI Logic SAS | SCSI controllerGeneration 1 boots from IDE |
| Network adapterTo the guest it’s a new network card with a new MAC address. On Windows a static IP address stays bound to the old, now hidden, adapter. Linux may rename the interface. | VMXNET3 or E1000E | Network adapterLegacy adapter on Generation 1 only |
| Virtual disksEvery disk is converted while the machine is shut down, so the copy is exact. Disk size is what mostly decides how long each machine is offline. | VMDK | VHDX |
| Point-in-time copiesNeither carries across. Any chain is merged into the disk first, and the merge checked: convert the wrong file in a chain and the server comes back as it was months ago. | Snapshots | Checkpoints |
| On the hosts | ||
| Virtual networkingEvery VLAN the old hosts carried is rebuilt on the new ones before anything moves, so each machine lands on the network it left. | Standard or distributed switches, with port groups | Virtual switches, with the VLAN set on each adapter |
| StorageThe new storage is laid out from what the machines use, and from what their thin-provisioned disks could still grow to. | VMFS datastores | NTFS or ReFS volumes, Cluster Shared Volumes |
The table reads the same in either direction. Going from Hyper-V to VMware is the same work in reverse, with the drivers and tools swapped.
What catches migrations out
Converting the disks is routine. These are the things that go wrong on the new platform afterwards, and finding them before the first change window is what the inventory is for.
-
The line-of-business app asks for a new licence
Some software ties its licence to a MAC address or a hardware fingerprint, and both change in the move. Windows may want reactivating too.
We find these beforehand and raise them, so the software vendor is lined up before the window rather than called after it. Where it suits, the old MAC address can be carried across.
-
A USB licence dongle with nowhere to plug in
VMware can pass a USB device on the host straight through to a virtual machine. Hyper-V has no general USB passthrough to guests, so a dongle making that move needs another route, such as a network USB device server.
Better found in the inventory than on the day.
-
Two copies of the same domain controller
A domain controller should never be copied while it’s running, and the original and its copy must never both be switched on.
Domain controllers move shut down, the original stays off, and we check where the domain gets its time after the move, so it doesn’t start following the host’s clock.
-
The backup fails the night after cutover
Backup, monitoring and anything else that works through the hypervisor is connected to the old hosts, not to the machines on them.
The inventory lists every one of these, so you know before cutover what needs pointing at the new platform.
-
Back on the network, but not tested
A server that’s back on the network isn’t the same as an application that works. Each machine is tested with the client: someone who uses it signs in and does real work before it’s signed off.
One machine, one change window
The new hosts and their networking are built first. Then machines move cold: shut down, converted and started on the new platform. Each one is offline for its window, and in return there is always a way back.
The original and the new copy are never running at the same time.
-
Prepared
While it’s still running: network settings recorded, snapshots merged, boot drivers for the new platform added.
Original: runningNew: not built -
Shut down
A clean shutdown. From here, nothing writes to the original disks.
Original: off, untouchedNew: not built -
Converted
Disks converted, and the machine rebuilt with the right generation, controllers and adapters, on the right VLAN.
Original: off, untouchedNew: built, off -
First boot
New guest tools in, network settings reapplied, the hidden old adapter removed, activation checked.
Original: off, untouchedNew: running -
Tested
The client uses it the way they normally would, and tells us it works.
Original: off, untouchedNew: running -
Signed off
In service. The original stays off until the old platform is decommissioned.
Original: off until decommissionNew: in service
Until sign-off, going back means shutting the new machine down and starting the original. Nothing has been done to it.
Which machine goes first
Something low-stakes, to prove the process on this client’s hosts before anything important moves. Machines that depend on each other move in the same window. Domain controllers and databases get a slot of their own, chosen on purpose.
What the client ends up with
-
Their machines, on the new platform
Each one running with the new platform’s drivers and guest tools, on the network it left, and tested with the client.
-
As-built documentation
The new hosts, their networking and storage, and where each machine now lives, written for whoever looks after the platform next. Usually that’s you.
-
A decommission record
What was retired from the old platform and when, so nobody has to wonder later whether those old hosts are still needed.