By Joshua Stenhouse, Zerto Technical Marketing Manager
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:
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:
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:
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.
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.