Zerto for Microsoft Hyper-V Part 4: Cross-Hypervisor replication for Microsoft Hyper-V and VMware

By Joshua Stenhouse, Zerto Technical Marketing Manager

In the final blog post of this series ( Part 1, Part 2, Part 3) on Zerto 4.0 support for Microsoft Hyper-V series I will cover cross—hypervisor replication for Microsoft Hyper-V and VMware vSphere.

In order to describe the processes involved with cross-hypervisor replication I am going to use the below example from my demo lab. In the lab I have 2 datacentres, Boston and London, each with a VMware vSphere and Microsoft Hyper-V environment and I have 4 Virtual Protection Groups (VPGs) replicating as per:

In the above configuration I have the 4 multi-VM applications that each consist of a database VM, file server VM and web front-end VM that together form my CRM application. They are set to replicate and recover as follows:

• CRMApp1 VPG replicating from Microsoft Hyper-V to Microsoft Hyper-V
• CRMApp2 VPG replicating from Microsoft Hyper-V to VMware vSphere
• CRMApp3 VPG replicating from VMware vSphere to VMware vSphere
• CRMApp4 VPG replicating from VMware vSphere to Microsoft Hyper-V

For the CRMApp1 and CRMApp3 VPGs as they are replicating within the same hypervisor then no conversion is required and the VM is kept exactly as is.

Microsoft Hyper-V to VMware vSphere Conversion

For CRMApp2 it is replicating from Microsoft Hyper-V to VMware vSphere and so requires conversion. Zerto replicates the data at the block level, from the source VHD, or VHDX disks, directly to VMDKs in the target VMware vSphere hypervisor. Zerto then simply replicates any changes, as they occur, continuously from the source disk and inserts them in the target disk format using our Virtual Replication Appliance (VRA) technology, it doesn’t matter that the underlying virtual disk is a different type. This means that there is no delay waiting for a disk format conversion when migrating or recovering the VM between the hypervisors, therefore maintaining a Recovery Time Objective (RTO) of just minutes.

When a move, failover, or failover test, is initiated from Microsoft Hyper-V to VMware vSphere ESXi Zerto follows the below process:

• A new VM is created in ESXi at the highest VM hardware version support for the target host
• Target VMDKs are attached to the new VM
• VMnics are added as E1000 adapters and by default are configured with the same IP and MAC address, unless a new IP and/or MAC address has been configured in the VPG
• The target VM is booted with the same name, disk layout, CPU and RAM configuration
• The process is reversed when failing back

This process does not currently include the installation of VMware tools. It is therefore recommended to install VMware tools in advance in order to maintain a low RTO. As the installation of VMware tools requires the VM to be running in VMware vSphere, the VMs should be migrated to the target VMware vSphere hypervisor out of working hours, the tools installed and the VM rebooted, then migrated back to the source Microsoft Hyper-V hypervisor. After migrating back the VMtools service will simply sit in an idle state ready for recovery in the VMware vSphere environment.

VMware vSphere to Microsoft Hyper-V Conversion

For CRMApp4 it is replicating from VMware vSphere to Microsoft Hyper-V. Zerto replicates the block level changes continuously from the source VMDK disks to target VHD or VHDX disks upon initial sync or pre-seeding.

When a move, failover or failover test is initiated from VMware vSphere ESXi to Microsoft Hyper-V Zerto follows the below process:

• A new VM is created in Hyper-V either as Gen1 or Gen2 depending on the supported configuration
• Target VHDs (if Gen1) or VHDXs (if Gen2) attached to the new VM
• VMNics are added and by default are configured with the same IP and MAC address, unless a new IP and/or MAC address has been configured in the VPG
• The target VM is booted with the same name, disk layout, CPU and RAM configuration
• The process is reversed when failing back

It should be noted that this process does not include the installation of host integration tools. If the guest OS is Windows Server 2012 then they are installed by default and no action is required. For any other OS you should perform the same process as is for installing VMware tools in advance by migrating, installing, rebooting and then migrating the VMs back to VMware to minimise the RTO.

Failover Testing

The cross-hypervisor replication in Zerto fully supports failover testing with no impact in production, or break in the replication. Thanks to this, I cannot recommend this feature enough to anybody replicating between hypervisors. You can use it to see how the VMs and guest OS behave in the target hypervisor without any impact, and then plan the steps needed to resolve the issues in advance of a migration or disaster recovery scenario.

This concludes my blog post series on Hyper-V support. I hope you enjoyed reading it and are looking forward to trying out our Hyper-V and cross-hypervisor replication support soon.