For the second part of our Zerto Replication install series, we are going install the Virtual Replication Appliances (VRAs) as well as pair our protected site to a recovery site.
First, let’s look at the Virtual Replication Appliance(s). VRAs are lightweight, Linux-based virtual machines that handle replication between sites. These VRAs are installed on each host that houses either a protected or a recovery virtual machine. As part of replication, the VRAs compress the data before traversing between sites.
VRA Requirements (Zerto 5.x – VMware Environment)
- 5 GB datastore space
- A minimum of 1 GB memory
- VMware ESXi 4.0U1 or higher
Install Zerto Virtual Replication Appliances (VRA)
From the ZVM Dashboard, navigate to the Setup tab.
One of my favorite aspects regarding Zerto Replication is the ease of deployment. In this series, we will run through the installation and configuration of Zerto 5.5 for VMware environments. The series will consist of three parts to get Zerto Replication up and running.
- Zerto Virtual Manager (ZVM) Install
- Virtual Replication Appliance (VRA) Deployment/Site Pairing
- Virtual Protection Group (VPG) Setup for Virtual Machines
The focus of today’s post is the Zerto Virtual Manager (ZVM) installation. If you are unfamiliar with the ZVM, it is the centerpiece of the Zerto solution, which oversees replication. It taps into vCenter server to monitor your environment and update Zerto components. Furthermore, the ZVM runs as a Windows service and serves up a user interface to manage Zerto activities. Typically, the ZVM is installed at both the recovery and protected sites.
Before we start, let’s look at some pertinent requirements.
Today, Zerto released a field notice for customers running Zerto 5.0 or 5.5 in VMware vSphere environments. The issue pertains to duplicate MoRef entries residing in the Zerto Virtual Manager database. These duplicate entries are being created by the ZVM or by the installer during an installation. Alone the presence of duplicate MoRefs doesn’t cause the issue. However, certain tasks or changes on the duplicated object can cause disruptions to synchronization or replication. This could force VPGs into an error state; consequently, rendering them unrecoverable. Zerto states that some environments may contain duplicated MoRefs, but not be impacted. Regardless, they recommend users on ZVR version 5.0 or 5.5 to upgrade to version 5.5U2P2. P2 will identify and delete duplicate entries. If you are unable to upgrade, Zerto Support can aid in identification and further mitigation of the issue.
ZVR Affected Versions: 5.0, 5.0 U1, 5.0 U2, 5.0 U3, 5.0 U4, 5.5, 5.5 U1, 5.5 U2
What is a MoRef?
Managed Object References are unique identifiers given to all objects in a vSphere environment for identification and tracking purposes. MoRef’s are designated by the object type followed by an identification number. For example, vm-110 or host-95.
A few weeks back, we discussed how to downgrade ESXi versions. These downgrades or rollbacks will often time bring compatibility issues into play. One such issue is the compatibility between the ESXi version and virtual machine hardware version. If a virtual machine with a higher version of hardware resides on an unsupported (lower) ESXi version, you will receive an error and not be able to start the machine. The error will state – This virtual machine uses hardware version x, which is no longer supported. Upgrade is recommended.
To address such issues, VMware supports three ways of downgrading virtual machine hardware.
- Revert to a pre-upgrade snapshot.
- Convert the virtual machine with VMware vCenter Converter Standalone and specify the appropriate destination hardware version.
- Create a new VM with a compatible hardware version and attach existing disks.
In this post, we will perform the latter; specifically, downgrading virtual machine hardware 13 to 11.
Occasionally, an issue or bug will require admins to revert to a previous build or version of ESXi. In the event you patch your hosts (as opposed to fresh installs), it is possible to rollback to a prior installed version via the GUI. Rollbacks should not be taken lightly. If you are reverting in a production environment, discuss options with support first.
A few housekeeping items before we jump into the rollback process.
Compatibility – If you are leveraging new features introduced in vSphere 6.5, ensure you check compatibility against vSphere 6.0. Two main features to be cognizant of when reverting from 6.5 to 6.0 are VMFS and virtual machine hardware versions.
- VMFS 6: VMFS 6 was introduced with vSphere 6.5. However, vSphere 6.0 utilized VMFS 5. If you created a VMFS 6 version with ESXi 6.5, you will not be able to access the datastore after rollback.
- VM Hardware Version: vSphere 6.5 also introduced version 13 virtual machine hardware. Version 13 hardware is not compatible with ESXi 6.0. Version 11 or lower is compatible. However, there are a few supported options for downgrading virtual machine hardware versions.
Back Up Host Configuration – Before making any changes, back up the ESXi Configuration.