Using Zerto for Disaster Recovery & Workload Migration to a VMware Cloud: Part 1

ByMarch 16, 2018
Zerto partner 2016 & 2017 logoThe flexibility and scalability of Zerto replication technology means that, not only is it used for business continuity purposes in a cloud-based DR scenario, but also increasingly for migrating workloads to the cloud. In this blog, I will provide an overview of the important considerations that need to made when using Zerto with a VMware based cloud provider. The following recommendations apply to scenarios where you are migrating VMs to a vCloud Director environment as well as protecting VMs using Zerto replication. In the event of a failover, you will find that adhering to the following recommendations in your on-premises environment will ensure a smooth transition for the duration of your disaster scenario.
My colleague recently wrote a blog exploring issues to consider when migrating VMware virtual machines to the cloud. In this blog, we will go through the pre-migration steps necessary to move your VMs to the cloud and I’ll follow that up with a blog on post-migration steps.

Cautions for VM Cloud Migration
One of the popular use cases for using Zerto Virtual Replication is migrating workloads to the cloud with minimal downtime. This is possible due to two major advantages of using Zerto technology; continuous replication, which means the latest copy of the data is already in the cloud, and the efficiency of the live failover function, which means even a large group of VMs can be created and powered on in the recovery site within minutes.

The fast pace at which production VMs can be moved from your on-premises environment into a vCloud Director based cloud should not dissuade anybody from taking the necessary precautions to ensure the transition will be as smooth as possible. Whilst the back-end infrastructure of a cloud provider utilising VMware’s technology would be similar to your own vSphere environment, any differences in software versions or utilised hardware would need to be accounted for. This will ensure that not only will your VMs come up and the OS boots but also that the applications you are running perform at a level your users or customers are expecting.

Updating the virtual hardware version
Most virtualised environments will have VMs with various virtual hardware compatibility versions. This setting is often overlooked due to the seemingly limited benefits it offers. This is becoming more and more of a misconception as the performance of the underlying hardware becomes greater. A low virtual hardware compatibility version might limit the virtual hardware that can be attached to a VM. A great example, that can significantly increase performance, would be using VMXNet3 10Gb network adapters, Paravirtual storage controllers and the limitation of vCPUs that can be allocated to a VM. The full list can be found in this article.

As the virtual hardware version upgrade requires downtime and can only by performed on a powered off VM, it’s best to proceed with the upgrade after the migration to avoid unnecessary downtime in the future. You don’t want to be in a position when you would like to hot-add hardware to your VM only to find out that the specific hardware in question is not available without moving to a higher version of the virtual hardware.
pic 1

ESXi/ESX hosts and compatible virtual machine hardware versions list – source: https://kb.vmware.com/s/article/2007240

It’s very important to remember that the virtual hardware version supported by a VMware platform is limited by the version of vSphere running on that platform. As such, when moving workloads to iland please make sure that your VMs do not exceed the maximum version we support in our datacentres. You can check the current versions being utilise by iland on the iland Product Compatibility Matrix page.

The process for updating the virtual hardware version is very simple and very similar across vSphere and vCloud interfaces, as well as the iland console. It’s just a case of powering off the VM in question, right clicking it and selecting Upgrade Virtual Hardware/Manage Virtual Hardware. Precautions should be taken however, as there’s no easy way to rollback this change – VMware does not offer an interface to do so. The safest way to proceed would be to take a snapshot of the VM beforehand. If you encounter any problems, you can revert to the snapshot, which will roll back the virtual hardware version change. In case of any problems, VMware recommends two other ways to revert back to an older version of virtual hardware, both of which are easy to execute in a vSphere environment. As per the following knowledge base article, you can either attach the existing drives to a new VM or edit the VMX file of a virtual machine.
Pic 2

The virtual hardware update can be scheduled to occur automatically on VM reboot or shutdown. As this method does not offer any rollback caution is advised.

As a best practice, make sure that the VM is running the latest version of VMware tools before proceeding with the virtual hardware upgrade. Update VMware tools if necessary, to avoid any problems with the new hardware.

Updating VMware tools
Before we discuss the update process itself lets outline the role of VMware tools in our VMs. The importance of VMware tools cannot be overlooked, as they are effectively the drivers for your operating system running in a virtual machine. It’s not just about the graphics driver and the mouse/keyboard performance in the console as well. Whilst that is also the case, the biggest benefits are much more important, and relevant even to operating systems that don’t care for a GUI, i.e. *nix systems. The drivers included in VMware tools are, among others, the VMXNet network adapter drivers, which will provide your VM with 10Gb connectivity, and the Paravirtual SCSI driver, which will allow you to utilise the performance benefits of all-flash storage arrays, whilst keeping CPU utilisation low.

Let us also not forget about the memory balloon driver, which will help with memory management in our environment, or the VSS component, which gives us the ability to take quiesced snapshots of the guest OS, which will enable backup solutions, like Veeam, to take application consistent backups.
You might think that some of the benefits are not going to be useful to you, but the rest will help you keep your VMs running smoothly and efficiently. You should therefore consider keeping them up to date and assigning that task the same priority as keeping your operating systems patched and updating the firmware on your physical hardware devices.

Pic 3
The traditional way of updating VMware tools would be by mounting the ISO using the vSphere or vCloud Director interface. This is a simple method that has been used for years. The benefit of this method is that you only need a CD-ROM drive in your VM in order to mount the ISO with the tools.

With the release of version 10 of VMware tools, we now have an option to download them from the ‘My VMware’ website. The advantage of using the downloadable packages is that we can install a higher version than we would be able to install from the ISO. The reason for this is that the version available to mount is delivered with the version of ESXi you are using.

This means that when using downloadable packages of VMware Tools, we can prepare our VMs for migration to a higher version of ESXi. As iland is in the process of updating our backend to the latest release of vSphere, this would often be the case for anybody thinking of using Zerto Virtual Replication to migrate workloads into our cloud.
Pic 4

With version 10 of VMware tools they are now available for download directly from VMware’s website

We will cover the alternative methods in the second post of this series. Be sure to check them out as they can be quite time saving.

Disabling time synchronisation with the host
Whilst you might be using time synchronisation with ESXi host in your environment it is advisable to consider switching to using a NTP server. Time synchronisation is especially important within Active Directory environments. The default setting for time difference tolerance is only 5 minutes. This means that should any of your servers go out of sync, above this threshold, the domain controllers would stop trusting them and not provide authentication services. This means that any applications relying on AD would effectively stop working. Within an AD environment, Microsoft recommends that the PDC of the root domain in the forest syncs it’s time with an external NTP server and the remaining domain controllers sync up to that PDC. More information on that can be found in this article. For any non-AD environments please consult the documentation of the application to establish what is the recommended time sync setting.

For optimal results in migrating workloads to a VMware based cloud with Zerto, its important to make sure the following points are addressed prior to  moving your workloads to the cloud:

1. Make sure the virtual hardware version of your VMs is supported within the iland environment.
2. Check if VMware tools are up to date to ensure good performance of the VM.
3. Disable time synchronisation with the host and use an NTP server to ensure your VMs are always in sync.

Stay tuned for my next blog which continues the learning with a deep-dive into post-migration tasks for successful migration to a VMware based cloud.
Daniel Stasinski

Daniel Stasinski

Daniel is a Cloud Deployment Engineer at iland. He’s experienced in deploying business continuity solutions, running disaster recovery tests as well as migrating on-premise workloads to the cloud. He holds current certifications from VMware, Zerto and Cisco. Daniel works closely with iland customers to implement cloud solutions that meet their business requirements.