Professional Documents
Culture Documents
ZVR-AGVM-3.1U4-01-20-02-14
Copyright 2014, Zerto Ltd. All rights reserved.
Information in this document is subject to change without notice and does not represent a commitment on the part of Zerto
Ltd. Zerto Ltd. does not assume responsibility for any printing errors that may appear in this document. No part of this
document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including
photocopying, recording, or information storage and retrieval systems, for any purpose other than the purchaser's
personal use, without the prior written permission of Zerto Ltd.
All other marks and names mentioned herein may be trademarks of their respective companies.
ZVR-AGVM-3.1U4-01-20-02-14
Table of Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Overview of Content in This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Zerto Virtual Replication Documentation Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Support and Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Chapter 2: Accessing the Zerto Virtual Manager User Interface (Zerto GUI) . . 19
Accessing the Zerto GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Using the Zerto DR Management UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Using the vSphere Client Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Using the vSphere Web Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Adding a Security Certificate to Enable Access to the Zerto User Interface . . . . . . . . . . . . . . . . . 23
3
WAN Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Estimating the Bandwidth Requirements Between Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Collecting Data Characteristics for VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Estimating the Required Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Editing Information About a Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Site Configuration Advanced Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Defining the Maximum Bandwidth Used by Zerto Virtual Replication Between Sites . . . . . 88
Defining the Default Script Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Defining the Scaling Used for Performance Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Enable Replication to the Same Site That is Protecting the Virtual Machines . . . . . . . . . . . 89
Defining the Replication Pause Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Defining the Failover and Move Operation Default Commit Policy . . . . . . . . . . . . . . . . . . . . 90
Configuring Email Notifications for Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Defining Resource Report Sampling Period . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Reviewing Supported Host Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Defining Zerto Support Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4
Ensuring Application Consistency Checkpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Adding a Checkpoint to Identify a Key Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Ensuring Application Consistency With Microsoft Volume Shadow Copy Service (VSS) . . 135
Running Scripts Before or After Recovering a VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Creating a Script and Example Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Exporting and Importing VPG Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
VPG Statuses and Synchronization Triggers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
VPG Statuses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
VPG Synchronization Triggers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Managing Protection When a Recovery Datastore Will Be Unavailable
(Datastore Maintenance). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
5
Chapter 11: Migrating a Protection Group to the Recovery Site. . . . . . . . . . . 196
The Move Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Moving Protected Virtual Machines to the Remote Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Reverse Protection For a Moved VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Chapter 15: How Zerto Virtual Replication Works with VMware Features . . . 236
Protecting Virtual Machines in a vApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Protecting Virtual Machines that Use Thin-Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Zerto Virtual Replication and VMware Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
VMware High Availability (VMHA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
DRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Zerto Virtual Replication and Storage Profiles and Storage Clusters . . . . . . . . . . . . . . . . . . . . . 239
Zerto Virtual Replication and Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Zerto Virtual Replication and Host Affinity Rules and CPU Pinning . . . . . . . . . . . . . . . . . . . . . 240
Ensuring VPG Integrity When Using vMotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Zerto Virtual Replication and Storage vMotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
VMware Host Maintenance Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
VMware Roles and Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
6
Chapter 16: Troubleshooting and Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Ensuring the Zerto Virtual Manager is Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Troubleshooting Needs Configuration Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Troubleshooting GUI Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Message Displayed That Adobe Flash Player Version is Wrong . . . . . . . . . . . . . . . . . . . . . . 245
Zerto GUI Not Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Troubleshooting VRA Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
VPG Syncing Takes a Long Time Network Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Host is Not Displayed in List of Hosts in the Manage VPG Dialog . . . . . . . . . . . . . . . . . . . . 245
VRA Crashes During Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Cannot Install a VRA After Uninstalling a VRA on the Host . . . . . . . . . . . . . . . . . . . . . . . . 246
Handling Lack of Storage Space for Recovered Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . 246
Zerto Virtual Replication Diagnostics Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Collecting Zerto Virtual Replication Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Collecting Log Information for the ZertoVssAgent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Understanding the Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Zerto Virtual Replication Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Zerto Virtual Replication Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Zerto Virtual Replication Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Zerto Virtual Replication Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
7
Configure VNIC Dialog (vCD). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Configure Volume Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Configure Volume Dialog (vCD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
Delete VPG Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Edit VRA Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Events Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
Manage Journal Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Manage Sites Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Manage Static Routes Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Manage VPG Dialog Protecting a vApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Manage VPG Dialog Protecting to a vCenter Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Manage VPG Dialog Protecting to vCD. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Manage VPG Dialog Protecting vCD to vCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
New VPG Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Offsite Clone Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Outbound Protection Over Time Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Pause Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Protection Over Time by Organization Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Recent Activities Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Recovery Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Resource Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Resume Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Select Recovery Point Dialog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Select VMs Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Site Information Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
Sites Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Start Maintenance Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Stop Failover Test Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Summary Tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
Time-based Bandwidth Throttling Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Topology Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Usage Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
VMs Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
VPG Performance Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
VPGs Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
VRAs Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Zerto Virtual Replication License Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
8
About This Guide
Zerto Virtual Replication provides a business continuity (BC) and disaster recovery (DR) solution
in a virtual environment, enabling the replication of mission-critical applications and data as
quickly as possible and with minimal data loss. When devising a recovery plan, these two
objectives, minimum time to recover and maximum data to recover, are assigned target values:
the recovery time objective (RTO) and the recovery point objective (RPO). Zerto Virtual
Replication enables a virtual-aware recovery with low values for both the RTO and RPO.
This guide describes how to configure and manage Zerto Virtual Replication to implement
business continuity and disaster recovery (DR) solutions in a VMware virtual environment.
Intended Audience
9
Overview of Content in This Guide
The Zerto Virtual Replication documentation set includes the following documentation:
Release Notes Details specific to this release of Zerto Virtual Replication.
Zerto Virtual Replication How to install and initially configure Zerto Virtual Manager.
Installation Guide
Zerto Cloud Manager How to install Zerto Cloud Manager.
Installation Guide
Zerto Virtual Manager This guide: How to implement and manage replication and a
Administration Guide disaster recovery (DR) solution in a virtual environment using
Zerto Virtual Replication.
Zerto Cloud Manager How to configure and continue to manage Zerto Virtual
Administration Guide Replication using Zerto Cloud Manager.
Zerto Virtual Replication How to install and use the Zerto Virtual Replication Windows
PowerShell Cmdlets Guide PowerShell cmdlets, including the cmdlets to use when
upgrading Zerto Virtual Replication.
Zerto Virtual Replication REST How to use the Zerto Virtual Replication REST APIs to manage
API Reference Guide disaster recovery programmatically.
Disaster recovery is the process of preparing for recovery or continuation of IT processing tasks
that support critical business processes in the event of a threat to the IT infrastructure. This
chapter describes Zerto Virtual Replication general concepts to enable replication and recovery in
a virtual environment.
The following topics are described in this chapter:
What is Zerto Virtual Replication?, below.
Zerto Virtual Replication Architecture, on page 13.
How Zerto Virtual Replication Recovery Works, on page 14.
Benefits of Using Zerto Virtual Replication, on page 15.
For details about Zerto Virtual Replication for cloud service providers, also refer to Zerto Virtual
Replication Zerto Cloud Manager Installation, Configuration and Management.
Zerto Virtual Replication provides a business continuity (BC) and disaster recovery (DR) solution
in a virtual environment, enabling the replication of mission-critical applications and data as
quickly as possible and with minimal data loss. When devising a recovery plan, these two
objectives, minimum time to recover and maximum data to recover, are assigned target values:
the recovery time objective (RTO) and the recovery point objective (RPO). Zerto Virtual
Replication enables a virtual-aware recovery with low values for both the RTO and RPO.
Zerto Virtual Replication is installed in both the protected and the disaster recovery (DR) sites.
You can manage the replication from within a standalone UI in a browser, enabling DR
management from anywhere or from a vSphere Client console, so you only need to have one point
of control: All recovery that does not rely on native replication functionality can be managed from
the vSphere Client console1. Recovery that does rely on native replication functionality, such as
recovery available with Microsoft Active Directory or SQL Server, can also be replicated using
1. Windows PowerShell cmdlets are also available enabling management from a script instead of a GUI. For details, refer to the
Zerto Virtual Replication Cmdlets guide.
12
Zerto Virtual Replication Architecture
Zerto Virtual Replication, and whether the native replication functionality is used or not is
determined by site considerations, such as increased complexity of having multiple points of
control and possible additional costs incurred when using vendor native replication.
You configure replication by first pairing the site with virtual machines to be protected with a
recovery site. You then define what virtual machines you want replicated in groups, where the
virtual machines in the group comprise the application and data you want to protect. You can
group different virtual machines together or keep them separate. By creating different replication
groups, you can customize the replication requirements for each group to better optimize the
recovery plan.
Zerto GUI Recovery using Zerto Virtual Replication is managed via a user interface, Zerto DR
Management UI, vSphere Client console or vSphere Web Client.
The following diagram shows how the main Zerto Virtual Replication are deployed across sites to
provide disaster recovery across these sites.1
Zerto Virtual Replication sits in the hypervisor layer. You manage the protected and recovery
sites from a standalone browser-based GUI, or the vSphere Client console, or via in-house scripts,
using Zerto Virtual Replication PowerShell cmdlets to perform the required replication. In the
protected site you define the virtual machines that you want to replicate, either individually or
together, as a virtual protection group (VPG). The virtual machines that you include in the VPG
can come from one or more ESX/ESXi hosts in the vCenter Server. In this way, you can protect
applications that run on multiple virtual machines and disks as a single unit, in a single VPG. An
example of an application that runs on multiple virtual machines includes software that requires
a web server and database, both of which run on virtual machines different to the virtual machine
where the application software runs. Under VMware these machines can be bundled together
using VMware vAPP. In this case, the VPG can include the vAPP.
Every write is intercepted by Zerto Virtual Replication and a copy of the write is sent,
asynchronously, to the recovery site, while the write continues to be processed on the protected
site. For greater efficiency and performance, the write is compressed before being sent to the
recovery site with throttling techniques being used to prioritize network traffic.
On the recovery site the write is written to a journal managed by a Virtual Replication Appliance.
Each protected virtual machine has its own journal.
1. For cloud-based architecture diagrams, see Zerto Virtual Replication Zerto Cloud Manager Installation.
Every few seconds, a checkpoint is also written to the journals. These checkpoints ensure write
order fidelity and crash-consistency to each checkpoint. During recovery you pick one of these
crash-consistent checkpoints and recover to this point. Additionally, checkpoints can be manually
added by the administrator, with a description of the checkpoint. For example, when an event is
going to take place that might result in the need to perform a recovery, you can pinpoint when
this event occurs as a checkpoint in each journal.
The Virtual Replication Appliance manages the journals for every virtual machine that will be
recovered to the ESX/i hosting the Virtual Replication Appliance. It also manages images of the
protected volumes for these virtual machines. During a failover, you can specify that you want to
recover the virtual machines in the VPG using the last checkpoint or you can specify an earlier
checkpoint, in which case the recovery of the mirror images under the Virtual Replication
Appliance are synchronized to this checkpoint. Thus, you can recover the environment to the
point before any corruption and ignore the later writes in the journal that were corrupted, either
caused by a crash in the protected site or for other reasons, such as a virus.
To improve the RTO during recovery, the user is able to start working even before the virtual
machine volumes on the recovery site have been fully synchronized. Every request is analyzed
and the response returned either from the virtual machine directly or from the journal if the
information in the journal is more up-to-date. This continues until the recovery site virtual
environment is fully synchronized, up until, either the last checkpoint, or an earlier checkpoint,
when the integrity of the protected site was assured.
Datacenter optimization and virtualization technologies have matured and are now well adopted
into the IT infrastructure. As more and more applications are deployed in a virtualized
infrastructure, there is a growing need for recovery mechanisms to support mission critical
applications deployments while providing complete BC and DR.
Traditional replication and disaster recovery solutions were not conceived to deal with the
demands created by the virtualization paradigm. For example, most replication solutions are not
managed in the hypervisor layer, considering the virtual machines and disks, but at the physical
disk level, hence they are not truly virtualization aware.
The lack of virtualization awareness creates a huge operational and administrative burden. It
also results with operational inflexibility. Zerto Virtual Replication has been designed to resolve
these issues by being fully virtualization aware.
Hardware Agnostic
Because Zerto Virtual Replication software manages recovery of virtual machines and virtual
disks only, it does not matter what hardware is used in either the protected or recovery sites; it
can be from the same vendor or different vendors. As long as the storage device supports the SCSI
protocol, any storage device can be used. With Zerto Virtual Replication the logical storage is
separated from the physical storage so that the vendor and type of actual storage hardware do not
need to be considered.
Fully Scalable
Zerto Virtual Replication sits in the hypervisor level and enables defining software-only Virtual
Replication Appliances (VRAs) on each ESX/ESXi host to manage the replication of virtual
machines on that host. Increasing the number of ESX/ESXi hosts is handled by defining a new
VRA on each new ESX/ESXi host. There is no need to install additional software to the vCenter
Server to handle additional ESX/ESXi hosts or virtual machines and no need to consider
additional hardware acquisitions.
Near-zero RPO
Zerto Virtual Replication utilizes continuous data protection, sending a record of every write in
the virtual protection group to the recovery site. The transfer of this information is done over an
optimized WAN asynchronously. If recovery is required, all the data that was transferred to the
recovery site is available resulting is recovery within the requested RPO.
Near-zero RTO
During recovery the mirrors of the virtual machines that need recovering are recovered in the
recovery site from the Virtual Replication Appliance and synchronized to the checkpoint
requested for this failover. During this synchronization, users can access the virtual machine on
the recovery site. Every request is analyzed and the response returned either from the virtual
machine directly or from the journal for the virtual machine, if the information in the journal is
more up-to-date. This continues until the recovery site virtual environment is fully synchronized.
In traditional replication architectures, either a complete LUN with all the data for multiple
machines is replicated or a single LUN is used for each machine. In both of these cases, the
wasted storage and all the inflexibility, both in terms of planning and operating recovery, means
that although replication is achieved, either it is has a high RTO or it is prone to errors. A single
LUN can be used to store the data for multiple virtual machines and Zerto Virtual Replication
makes sure that only the data relevant to the virtual machine requiring replication is in fact
replicated. In addition, you can also create VPGs across different LUNs.
Policy-based
In the protected site you define the virtual machines that you want to recover, either individually
or as groups, as a virtual protection group (VPG). The virtual machines that you include in the
VPG can come from one or more ESX/ESXi hosts in the vCenter Server. In this way, you can
protect applications that run on multiple virtual machines and disks as a single unit, in a single
VPG.
You manage your vCenter site, including the protection and replication of virtual machines
between the protected and recovery sites, using the Zerto GUI.
The following topics are described in this chapter:
Accessing the Zerto GUI, below
Adding a Security Certificate to Enable Access to the Zerto User Interface, on page 23
Zerto also provides a set of PowerShell cmdlets and REST APIs to enable incorporating some of
the disaster recovery functionality within scrips or programs.
On first access to the user interface, you might have to set up secure communication, as described
in Adding a Security Certificate to Enable Access to the Zerto User Interface, on page 23.
You manage your vCenter site, including the protection and replication of virtual machines
between the protected and recovery sites, using one of the following ways:
The Zerto DR Management UI.
The vSphere Client console.
The vSphere Web Client.
19
2. Login using the user name and password for the vCenter Server connected to the Zerto
Virtual Manager.
Note: You cannot protect a vApp, as a vApp, using the Zerto DR Management UI.
You can use the VMware Web Client to manage Zerto Virtual Replication.
The vSphere Web Client is a browser-based interface for configuring and administering virtual
machines enabling you to connect to a vCenter Server system to manage an ESXi host through a
browser. The following procedure describes how to configure the vSphere Web Client to display
Zerto Virtual Replication dialogs.
This procedure is valid for vSphere Web Client version 5.1 communicating with vCenter Server
from version 5.0 and higher.
Note: The following procedure assumes that the vSphere Web Client version 5.1 has been
installed. Although you can run the vSphere Web Client version 5.1 with vSphere Server 5.0 and
5.1, when installing the vSphere Web Client you need access to a vSphere Server version 5.1
which includes an option for single sign on, required by the vSphere Web Client installation.
Note: Setting up Zerto Virtual Replication to be used via the vSphere Web Client disables the use
of other VMware plug-ins, such as VDP and VSA, causing them to disappear from the web client.
This is a known VMware problem, see http://kb.vmware.com/selfservice/microsites/
search.do?language=en_US&cmd=displayKC&externalId=2042455. To resolve this issue, set up
two web clients, on different servers. On one run Zerto Virtual Replication and on the other run
the VMware plug-ins.
20
Accessing the Zerto GUI
To set up the vSphere Web Client to work with To work with Zerto Virtual Replication:
1. When running the vSphere Web Client on a Microsoft Windows platform: Copy and run
VsphereWebClientPluginEnabler.exe to the machine where you run the web client. This
file is located in the Zerto Virtual Replication folder under the folder where Zerto
Virtual Replication was installed. You can copy VsphereWebClientPluginEnabler.exe to
any folder on the relevant machine. Run VsphereWebClientPluginEnabler.exe as an
administrator.
When running the vSphere Web Client on a Linux platform, via the vCenter Server Linux
Virtual Appliance (vCSA): In the directory /var/lib/vmware/vsphere-client, open the
webclient.properties file in a text editor and add the following to the file:.
scriptPlugin.enabled = true
2. Restart the vSphere Web Client.
Note: After the service has started you might have to wait a few minutes before you can open
the vSphere Web Client in your browser.
4. If more than one plug-in is installed, click Zerto to display the Zerto Virtual Replication UI.
4. Continue to the end of the wizard. Click Yes when the Security Warning is displayed.
Virtual machines are protected in virtual protection groups. A virtual protection groups (VPG) is
a group of virtual machines that you want to group together for replication purposes. For
example, the virtual machines that comprise an application like Microsoft Exchange, where one
virtual machine is used for the software, one for the database and a third for the Web Server,
require that all three virtual machines are replicated to maintain data integrity.
Once a virtual machine is protected, all changes made on the machine are replicated in the
remote site. The synchronization between the protected site and remote site takes time,
depending on the size of the virtual machine but after that, only the writes to disk from the
virtual machine in the protected site are sent to the remote site. These writes are stored by the
Virtual Replication Appliance (VRA) in the remote site in a journal for a specified period, after
which, the old writes are promoted to the mirror virtual disk managed by the VRA.
The number of VPGs that can be defined on a site is limited only by the number of virtual
machines that can be protected. Each site can protect a maximum of 5000 virtual machines. Note
that if two paired sites both have VPGs defined such that if the VPGs on one site are recovered to
the paired site, the 5000 virtual machine limit still applies and if the total exceeds this limit,
VPGs that take the number of virtual machines over the limit will not be recovered.
The following topics are described in this chapter:
Configuring Virtual Protection Groups, below.
Creating a Virtual Protection Group to a Recovery Site vCenter Server, on page 27.
Protecting a Single Virtual Machine, on page 41.
Protecting a vApp (via the vSphere Client Console or Web Client Only), on page 43.
Protecting Virtual Machines When VMware vCloud Director is Used, on page 56.
Protecting Virtual Machines to the Same Site, on page 72.
What happens After the VPG is Defined, on page 74.
25
Configuring Virtual Protection Groups
You protect one or more virtual machines in a VPG. The VPG must include at least one virtual
machine. After creating a VPG, you can add more virtual machines later.
The VPG includes the virtual machines to recover. These virtual machines can be defined under a
single ESX/ESXi host or under multiple ESX/ESXi hosts. The recovery can also be to a single
ESX/ESXi host or multiple ESX/ESXi hosts. The virtual machines are also recovered with the
same configuration as the protected machines. For example, if a virtual machine in the protected
site is configured so that space is allocated on demand (thin provisioning) and this machine is
protected in a VPG, then during recovery the machine is defined in the recovery site as thin
provisioned.
Note: You must be paired to a remote site and have installed a VRA in the remote site, which
manages the replication in the remote site, before you can create a VPG.
The procedure used to protect virtual machines depends on the following:
The virtual machines that need protecting are to be protected to a recovery site vCenter
Server: You protect the virtual machines as described in the procedure Creating a Virtual
Protection Group to a Recovery Site vCenter Server, below.
A single virtual machines needs protecting, either in an existing VPG or in a new VPG. For
details, refer to Protecting a Single Virtual Machine, on page 41.
The virtual machines that need protecting are in a vApp: You protect the vApp as a single
entity and not the individual virtual machines. For details, refer to Protecting a vApp (via
the vSphere Client Console or Web Client Only), on page 43.
Protection is to or from vCloud Director. For details, refer to Protecting Virtual Machines
When VMware vCloud Director is Used, on page 56.
Note: You cannot protect virtual machines with VirtualEthernetCardLegacyNetworkBackingInfo
NICs nor with IDE devices. Also, protected virtual machine VMDK descriptor files should be
default disk geometry settings. Both the disk geometry and BIOS geometry are written in the
descriptor file under ddb.geometry.sectors and ddb.geometry.biosSectors respectively. If these
values do not each equal 63 then there may be a recovery issues unless you configure the VPG
using preseeded volumes.
26
Creating a Virtual Protection Group to a Recovery Site vCenter Server
Specify the ZORG and recovery site supplied by the cloud service provider and click Continue.
Note: If the recovery site has vCD defined, the Recovery site is vCD checkbox is
automatically selected. To recover to the underlying vCenter Server, uncheck the box.
The Manage VPG dialog is displayed. The dialog can vary dependent on whether the license
being used is a cloud license or an enterprise license and whether Zerto Cloud Manager is
used or not.
The Manage VPG dialog when an enterprise license is used:
When protecting to a site with a cloud license, WAN compression is always implemented, so
the WAN Compression checkbox is not displayed.
When protecting to a cloud site and the cloud service provider uses Zerto Cloud Manager,
WAN compression is always implemented, so the WAN Compression checkbox is not
displayed and the VPG SLA values are controlled by a service profile.
Priority (QOS) Used to determine the priority for transferring data from the protected site to
the recovery site when there is limited bandwidth and more than one VPG is defined on the
protected site. When there are updates to virtual machines protected in VPGs with different
priorities, first the updates from the VPG with the highest priority are passed over the WAN.
Medium priority VPGs will only be able to use whatever bandwidth is left after the high
priority VPGs have used it. This is also true between medium and low priorities. Note that
updates to the protected virtual machines are always sent across the WAN before
synchronization data, such as during a Bitmap Sync or Delta Sync. During a
synchronization, only after updates to the virtual machines are sent over the WAN, based on
the VPG priority, is synchronization data from the VPG sent, and the synchronization data
from the VPG with the highest priority is passed over the WAN before data from medium and
low priority VPGs.
Target RPO Alert The maximum desired time between each automatic checkpoint being
written to the journal before an alert is issued. In reality checkpoints are written more
frequently.
Default Journal History The time for which all write commands are saved in the journal. Each
protected virtual machine has a dedicated journal volume on the recovery site associated with
the replicated virtual machine. This enables journal data to be maintained, even when
changing the target host for the recovery. When specifying a checkpoint to recover to, the
checkpoint must still be in the journal. For example, if the value specified here is 24 hours
then recovery can be specified to any checkpoint up to 24 hours. After the time specified, the
mirror virtual disk volumes maintained by the VRA are updated.
When a VPG is tested, either during a failover test or before committing a Move or Failover
operation, scratch volumes are created for each virtual machine being tested. The longer the
test period the more scratch volumes are used, until the maximum size is reached, at which
point no more testing can be done. The maximum size of all the scratch volumes is determined
by the journal size hard limit and cannot be changed. Thus, when considering the journal
history you should also consider the length of time you will want to test the VPG.
The more time saved the more space is required for each journal in the VPG to store the
information saved. The maximum journal size can be configured by clicking the configuration
button to display the Manage Journal dialog:
When custom values are selected for the Journal Size Hard Limit and Journal
Size Warning Threshold fields, the following is displayed:
removed after the time equivalent to three times the amount specified for the journal
history, or twenty-four hours, whichever is more.
With VMFS datastore and when the VRA is on a host ESX/ESXi that is version 5.1 or
higher, the journal can also reclaim unused space on a volume. This does not change the
provisioned journal size. The journal cannot reclaim unused space with NFS datastores.
When a virtual machine journal becomes close to the specified hard limit, Zerto Virtual
Replication starts to move data and checkpoints to the target disks. Once this begins, the
maintained history begins to decrease. If the journal history falls below 75% of the value
specified for the Default Journal History parameter, a warning alert is issued in the
GUI. If the history falls below one hour, an error is issued. However, if the amount of
history defined is only one hour, an error is issued if it is less than 45 minutes.
If the datastore where the journal resides drops below 30GB or 15% of the total datastore
size, whichever is the smaller of these two values, the datastore itself is considered full
and an error alert is issued and all writes to journal volumes on that datastore are
blocked. Replication is halted, but history is not lost. As such, the RPO begins to steadily
increase until space is made available on the datastore.
Journal Size Hard Limit The maximum size that the journal can grow, either as a
percentage or fixed amount. When the value is Unlimited the size for the journal is
unlimited and it can grow to the size of the recovery datastore. When the value is Custom,
you can specify a maximum journal size, either as a percentage of the virtual machine
volume size or as a fixed maximum size. The minimum journal size, set by Zerto Virtual
Replication, is 8GB. The journal is always thin-provisioned.
Journal Size Warning Threshold The size of the journal that triggers a warning that the
journal has neared its hard limit, either as a percentage or fixed amount. You can specify
the value as unlimited or change the value to Custom in order to specify a threshold,
either as a percentage of the virtual machine volume size or as a fixed size, both of which
must be less than the configured hard limit so that the warning will be generated if
needed. In addition to the warning threshold, Zerto Virtual Replication will issue a
message when the free space available for the journal is close to being as full as it can be.
Test Frequency Reminder The time recommended between testing the integrity of the VPG. A
warning is issued if a test is not done within this time frame.
WAN Compression (displayed when the Zerto Virtual Replication license is an enterprise
license) Whether the data is compressed before being transferred to the recovery site or not.
Compressing the data is more efficient but results in a small performance degradation.
Enable WAN compression if network considerations are more critical than CPU usage
considerations. Even if WAN compression is selected, Zerto Virtual Replication decreases the
level of compression if it takes too many resources. Zerto Virtual Replication can also work
with third-party WAN optimization and acceleration technologies, such as those supplied by
Riverbed Technologies, Silver Peak, and others. When third-party WAN optimization is
implemented, it is recommended to disable the VPG WAN compression.
Verify the settings for the VPG.
ZORG (displayed when Zerto Cloud Manager is used) The Zerto organization.
Target Site The site to which you want to recover the virtual machines. The recovery site
selected in the New VPG dialog is displayed and cannot be changed here.
5. Optionally, specify default values for the virtual machines you want to protect in the VPG.
These default properties can be overridden for each virtual machine in the group. The default
value fields include a filter option, enabling fast access to one of the items when there are too
many items to see at a glance. Entering a value in the field filters the results based on the
value. The filter value is not case-sensitive.
Host The default cluster, resource pool or ESX/ESXi host, in the recovery site which handles
the replicated data. If the site is defined in Zerto Cloud Manager, only a resource pool can be
specified and the resource pool must also have been defined in Zerto Cloud Manager. For
details about Zerto Cloud Manager, refer to Zerto Virtual Replication Zerto Cloud Manager
Installation, Configuration and Management.
When a resource pool is specified, Zerto Virtual Replication checks that the resource pool
capacity is enough for any virtual machines specified in the VPG. If a resource pool is
specified and DRS is disabled for the site later on, all the resource pools are removed by
VMware and recovery will be to any one of the hosts in the recovery site with a VRA installed
on it.
Note: All resource pool checks are made at the level of the VPG and does not take into account
multiple VPGs using the same resource pool. If the resource pool CPU resources are specified
as unlimited in the Edit Setting dialog for the resource pool, the actual limit is inherited from
the parent but if this inherited value is too small, failover move and failover test operations
can fail, even without a warning alert being issued by Zerto Virtual Manager.
Datastore The default datastore volume to use for all the recovered virtual machine files as
well as for their volumes. Every datastore for the selected default recovery host is included in
the drop-down options. The displayed datastores are accessible by the default host. If a cluster
or resource pool is selected for the host, only datastores that are accessible by every ESX/ESXi
host in the cluster or resource pool are displayed. When specifying the recovery storage for a
virtual machine with a storage cluster, you have to specify a datastore in the cluster.
Note: Zerto Virtual Replication uses the SCSI protocol. Only disks that support this protocol
can be specified.
Failover/Move Network The default network to use during a failover or move in which the
recovered virtual machines will run.
Failover Test Network The default network to use when testing the failover of virtual
machines in the recovery site. Zerto recommends using a fenced-out network so as not to
impact the production network at this site.
Folder The default folder where the virtual machines are recovered. Select a folder from the
list or the [Default]ZertoRecoveryFolder folder.
The default values are used as the defaults for all the virtual machines in the VPG, but can be
overridden for each virtual machine configuration, as described in the following steps.
If values are not specified for the default values, values must be specified per virtual machine in the
VPG, as described in the following steps.
6. Add virtual machines to the list of virtual machines that you want to protect in this group.
a) Click Add.
The Select VMs dialog is displayed with a list of virtual machines that are not protected.
Virtual machines with IDE disks cannot be protected. Zerto Virtual Replication supports
the SCSI protocol and only virtual machines with disks that support this protocol can be
specified.
b) Select one or more virtual machines to be protected. If the site is defined in Zerto Cloud
Manager, and the cloud service provider is responsible for both the protection and
recovery sites, an In Cloud Disaster Recovery, ICDR, scenario, the virtual machine must
be part of a resource pool and the resource pool must also have been defined as a resource
for the ZORG in Zerto Cloud Manager. For details about Zerto Cloud Manager, refer to
Zerto Virtual Replication Zerto Cloud Manager Installation, Configuration and
Management.
c) Click OK.
7. To specify the boot order of virtual machines in a VPG, click Boot Order.
When machines are started up on recovery, for example after a move operation, or shut down
after a failover test operation, the virtual machines in the VPG are not started up and
shutdown in a particular order. If you want specific virtual machines to startup or shutdown
before other machines, you can specify a boot order. The virtual machines are defined in
groups and the boot order applies to the groups and not between individual virtual machines
in the groups. You can specify a delay between groups during startup. During shutdown, the
groups are shutdown in the reverse order defined for starting them up.
The Boot Order Settings dialog is displayed.
Initially, virtual machines in the VPG are displayed together under the default group. If you
want specific machines to start before other virtual machines, define new groups with one or
more virtual machines in each group.
Note: There is no boot order for virtual machines in a group, only between groups.
a) Click Add or Remove to add or remove groups. You cannot remove the Default group nor
a group which contains a virtual machine.
b) To change the name of a group select the group and change the value in the Group Name
field to the required name.
c) Use the arrow buttons to move virtual machines from one group to another.
d) Use the arrow buttons to change the startup order by moving the groups up or down the
list.
e) Optionally, in Startup Action, specify a time delay between starting up the virtual
machines in the group and starting up the virtual machines in the next group, or specify
that the virtual machines in the next group only start up after VMware Tools are ready
for the virtual machines started up in the selected group.
For example, assume three groups, Default, Server and Client defined in this order. The
Start-up delay defined for the Default group is 10, for the Server group is 100 and for the
Client group 0. The virtual machines in the Default group are started together and after
10 seconds the virtual machines in the Server group are started. After 100 seconds the
virtual machines in the Client group are started up.
f) Click OK to save the boot order.
8. If you want a specific recovery configuration for a virtual machine in the VPG, select the
virtual machine from the list and click Configure. Otherwise, the default values specified as
part of the VPG properties are used for the virtual machine recovery configuration.
Note: If default values were not specified, values must be specified here.
The Configure VM dialog is displayed.
The Configure VM dialog enables configuring how the protected virtual machine will be
recovered, including details about the volumes and NICs used by the virtual machine and the
VMware file for the virtual machine.
Make any changes you want to the virtual machine specification on the recovery site and click
Save to save the configuration.
9. Optionally, select a volume and click Configure Selected Volume to configure the volume used
to replicate the virtual machine disks.
Note: A recovery host must be specified before you can configure recovery volumes.
The datastore specified for the replication must have at least the same amount of space as the
source volume and then an additional amount for the journal. The amount of additional space
needed for the journal can be fixed by specifying a maximum size for the journal, or can be
calculated as the average change rate for the virtual machines in the VPG, multiplied by the
length of time specified for the journal history.
Note: You can use the vSphere Client console Performance tab for each virtual machine to
help estimate the change rate. For more details, refer to Collecting Data Characteristics for
VMs, on page 80.
If you click Configure Selected Volume, the Configure Volume dialog is displayed.
configuration option to tune the RPC timeout parameter using the esxcfg-advcfg -s
<Timeout> /NFS/SetAttrRPCTimeout command.
If the protected disks are non-default geometry, configure the VPG using preseeded
volumes.
b) Click Save.
10. Optionally, select a NIC and click Configure Selected NIC to configure the NIC used to for the
replicated VM disks.
A recovery host must be specified before you can configure recovery NICs.
Note: You can configure a maximum of four NICs. If you configure more, a failover, move, or
test failover operation will fail.
If you click Configure Selected NIC, the Configure VNIC dialog is displayed.
Specify the network details to use for the recovered virtual machines after a live recovery or
migration, in the Failover/Move tab, and for the recovered virtual machines when testing the
replication, in the Failover Test tab. If the settings are the same for both failover and move
networks and for the failover test network, after setting the values in either tab, click the copy
button, Copy to test or Copy to failover, to copy all the settings defined in the one tab to the
other tab.
In each tab specify the following:
a) The network to use for this virtual machine.
b) Whether the Media Access Control address (MAC address) used on the protected site
should be replicated on the recovery site. The default is to use the same MAC address on
both sites. Check the box to create a new MAC address on the recovery site.
c) Whether to keep the default VNIC IP configuration or not. You can only change the VNIC
IP for virtual machines with VMware Tools running for the following operating systems:
Windows 2003 and higher, Red Hat Enterprise Linux versions 5-6, SUSE Linux
Enterprise versions 10-11 and CentOS versions 5-6.
If you can change the VNIC IP, check the Change Failover VNIC IP Configuration
in the Failover/Move tab or Change Test VNIC IP Configuration in the Failover
Test tab. If you select to use a static IP connection, you set the IP address, subnet mask
and default gateway to use. Optionally, change the preferred and alternate DNS server
IPs and the DNS suffix. If you select to use DHCP, the IP configuration and DNS server
configurations are assigned automatically, to match the protected virtual machine. You
can change the DNS suffix.
Note: During a failover, move or test failover, if the recovered virtual machine is assigned a
different IP to the original IP, after the virtual machine has started it is automatically
rebooted so that it starts up with the correct IP. If the same network is used for both
production and test failovers, it is recommended to change the IP address for the virtual
machines started for the test, so that there is no IP clash between the test machines and the
production machines.
d) Click Save.
11. The virtual machine details include the following:
Recovery Host The cluster, resource pool or ESX/ESXi that will host the recovered virtual
machine. If the site is defined in Zerto Cloud Manager, only a resource pool can be specified
and the resource pool must also have been defined in Zerto Cloud Manager. For details about
Zerto Cloud Manager, refer to Zerto Virtual Replication Zerto Cloud Manager Installation,
Configuration and Management.
When a resource pool is specified, Zerto Virtual Replication checks that the resource pool
capacity is enough for any virtual machines specified in the VPG. If a resource pool is
specified and DRS is disabled for the site later on, all the resource pools are removed by
VMware and recovery is to any one of the hosts in the recovery site with a VRA installed on it.
Note: All resource pool checks are made at the level of the VPG and does not take into account
multiple VPGs using the same resource pool. If the resource pool CPU resources are specified
as unlimited in the Edit Setting dialog for the resource pool, the actual limit is inherited from
the parent but if this inherited value is too small, failover move and failover test operations
can fail, even without a warning alert being issued by Zerto Virtual Manager.
VM Recovery Datastore The datastore where the VMware file for the virtual machine is
stored. If a cluster or resource pool is selected for the host, only datastores that are accessible
by every ESX/ESXi host in the cluster or resource pool are displayed. This is also the
datastore where RDM backing files for recovery volumes are located. When specifying the
recovery storage for a virtual machine with a storage cluster, you have to specify a datastore
in the cluster.
Recovery Folder The folder where the virtual machine is recovered to.
If default values were specified in the Manage VPG dialog, they are used for the virtual
machine configuration and are displayed in the Recovery Host, VM Recovery Datastore
and Recovery Folder fields. You can change these values for the specific virtual machine by
selecting new values from the drop-down lists.
Journal Size Hard Limit The maximum size that the journal can grow. You can specify the
value as unlimited or change the value to Custom in order to specify a maximum journal size,
either as a percentage of the virtual machine volume size or as a fixed maximum size.
Journal Size Warning Threshold The size of the journal that triggers a warning that the
journal is almost full. You can specify the value as automatically determined by Zerto Virtual
Replication or change the value to Custom in order to specify a threshold, either as a
percentage of the virtual machine volume size or as a fixed size.
Command to run The name of the script to run, including the full path. The script must be
located on the same machine as the Zerto Virtual Manager for the recovery site.
Params The values of any parameters to pass to the script. Separate parameters with a
space.
Timeout (sec) The time out in seconds for the script to run. If the script runs before executing
a failover, move or test failover and the script fails or a timeout value is reached, an alert is
generated and the failover, move or test failover is not performed. If the script runs after
executing a failover, move or test failover and the timeout value is reached, an alert is
generated. The default timeout value is specified in the Site Configuration Advanced
Settings dialog.
For more details about running scripts with Zerto Virtual Replication, see Running Scripts
Before or After Recovering a VPG, on page 142.
15. Click Save to create the VPG configuration.
You can protect a virtual machine, that is not already included in a VPG, directly via the Zerto
tab for the virtual machine in vSphere Client console. You are presented with the following
options:
To create a new VPG that includes the virtual machine, as described in To create a virtual
protection group (VPG):, on page 27. When using the Zerto DR Management GUI, use this
procedure.
To add the virtual machine to an existing VPG. The virtual machine is added to the VPG, as
described in To add a virtual machine to an existing VPG via the vSphere Client console or
Web Client:, below.
To create a new VPG that you intend should only include one virtual machine, as described in
To protect a single virtual machine:, on page 42. In this case, the VPG name is automatically
defaulted to the name of the virtual machine.
Note: You cannot protect virtual machines with VirtualEthernetCardLegacyNetworkBackingInfo
NICs or with IDE devices.
To add a virtual machine to an existing VPG via the vSphere Client console or Web Client:
1. In the vSphere Client console or vSphere Web Client, select the Zerto tab for the virtual
machine to be added.
Specify the ZORG and recovery site supplied by the cloud service provider and click Continue.
Note: If the recovery site has vCD defined, the Recovery site is vCD checkbox is
automatically selected. To recover to the underlying vCenter Server, uncheck the box.
3. Make any required changes to the VPG properties, as described in Configuring Virtual
Protection Groups, on page 26.
4. Click Save.
You can protect a vApp as a single entity in a VPG for any vApp defined under an ESXi host. All
the virtual machines defined in the vApp VPG are protected and you can migrate or recover the
whole vApp as a single entity to the recovery site.
In addition to being able to protect the vApp, you can protect individual virtual machines in the
vApp, in the same way as you protect any other virtual machine. However, if you protect a virtual
machine in the vApp, you cannot then protect the vApp as a single entity.
The individual machines in a vApp can be protected using the Zerto DR Management UI. A vApp
can only be protected as a vApp via the vSphere Client console or Web Client.
Note: Nested vApps are not protected. Also, if you drag a protected vApp under another vApp to
nest it, the protection is removed. You cannot protect vApps which include virtual machines with
VirtualEthernetCardLegacyNetworkBackingInfo NICs or with IDE devices.
To protect a vApp:
1. In the vSphere Client console or Web Client for the protected site, select the vApp node and
then the Zerto tab.
If the vApp contains virtual machines that are protected, the tab displays a message that the
vApp contains protected VMs and you have to remove the protection from these VMs before
continuing to protect the vApp.
Note: If the site is defined in Zerto Cloud Manager, and the cloud service provider is
responsible for both the protection and recovery sites, an In Cloud Disaster Recovery, ICDR,
scenario, the virtual machine must be part of a resource pool and the resource pool must also
have been defined as a resource for the ZORG in Zerto Cloud Manager. For details about
Zerto Cloud Manager, refer to Zerto Virtual Replication Zerto Cloud Manager Installation,
Configuration and Management.
2. Click Create New VPG.
The New VPG dialog is displayed, unless there is only one possible recovery site, in which case
the Manage VPG dialog is displayed.
When protection is to an enterprise, the enterprise version of the New VPG dialog is displayed.
Specify the ZORG and recovery site supplied by the cloud service provider and click Continue.
Note: If the recovery site has vCD defined, the Recovery site is vCD checkbox is
automatically selected. To recover to the underlying vCenter Server, uncheck the box.
The Manage VPG dialog is displayed. The name of the VPG is the name of the vApp. You
cannot add or remove virtual machines from the VPG.
The Manage VPG dialog when an enterprise license is used:
When protecting to a site with a cloud license, WAN compression is always implemented, so
the WAN Compression checkbox is not displayed.
When protecting to a cloud site and the cloud service provider uses Zerto Cloud Manager,
WAN compression is always implemented, so the WAN Compression checkbox is not
displayed and the VPG SLA values are controlled by a service profile.
3. If the VPG SLA settings are editable, when the Zerto Cloud Manager is not used or when a
Custom service profile is available, specify these settings for the group, which apply to every
virtual machine in the group.
Priority (QOS) Used to determine the priority for transferring data from the protected site to
the recovery site when there is limited bandwidth and more than one VPG is defined on the
protected site. When there are updates to virtual machines protected in VPGs with different
priorities, first the updates from the VPG with the highest priority are passed over the WAN.
Medium priority VPGs will only be able to use whatever bandwidth is left after the high
priority VPGs have used it. This is also true between medium and low priorities. Note that
updates to the protected virtual machines are always sent across the WAN before
synchronization data, such as during a Bitmap Sync or Delta Sync. During a
synchronization, only after updates to the virtual machines are sent over the WAN, based on
the VPG priority, is synchronization data from the VPG sent, and the synchronization data
from the VPG with the highest priority is passed over the WAN before data from medium and
low priority VPGs.
Target RPO Alert The maximum desired time between each automatic checkpoint being
written to the journal before an alert is issued. In reality checkpoints are written more
frequently.
Default Journal History The time for which all write commands are saved in the journal. Each
protected virtual machine has a dedicated journal volume on the recovery site associated with
the replicated virtual machine. This enables journal data to be maintained, even when
changing the target host for the recovery. When specifying a checkpoint to recover to, the
checkpoint must still be in the journal. For example, if the value specified here is 24 hours
then recovery can be specified to any checkpoint up to 24 hours. After the time specified, the
mirror virtual disk volumes maintained by the VRA are updated.
When a VPG is tested, either during a failover test or before committing a Move or Failover
operation, scratch volumes are created for each virtual machine being tested. The longer the
test period the more scratch volumes are used, until the maximum size is reached, at which
point no more testing can be done. The maximum size of all the scratch volumes is determined
by the journal size hard limit and cannot be changed. Thus, when considering the journal
history you should also consider the length of time you will want to test the VPG.
The more time saved the more space is required for each journal in the VPG to store the
information saved. The maximum journal size can be configured by clicking the configuration
button to display the Manage Journal dialog:
When custom values are selected for the Journal Size Hard Limit and Journal
Size Warning Threshold fields, the following is displayed:
must be recovered to ESX/ESXi hosts that can access the specified journal datastore. The
following table shows the different datastore options and the repercussions of each option:
Default Journal Journal Datastore per VPG Journal
Datastore for
Multiple VPGs
Allows No Yes Yes
storage tiering
Notes The journal for each virtual Specify a journal datastore Allows the use of
machine is located on the for each VPG sized using advanced
virtual machine recovery the Journal Sizing Tool. All settings like
datastore. journals for the VPG are storage IO
stored here. controls, to give
By default, the recovery
fairness to
datastore for each virtual Depending on deployment
customers.
machine is the same as the size, may require too many
VPG recovery datastore. datastores. This option is
recommended for
cloud service
providers.
The provisioned journal size is the current size of all the journal volumes.
If the journal grows to approximately 80% of the provisioned journal size, a new volume is
added to increase the journal size. The journal size can increase up until the specified
hard limit.
When the amount of the journal used is approximately 50% of the provisioned journal
size, the biggest unused journal volume is marked for removal. This volume is then
removed after the time equivalent to three times the amount specified for the journal
history, or twenty-four hours, whichever is more.
With VMFS datastore and when the VRA is on a host ESX/ESXi that is version 5.1 or
higher, the journal can also reclaim unused space on a volume. This does not change the
provisioned journal size. The journal cannot reclaim unused space with NFS datastores.
When a virtual machine journal becomes close to the specified hard limit, Zerto Virtual
Replication starts to move data and checkpoints to the target disks. Once this begins, the
maintained history begins to decrease. If the journal history falls below 75% of the value
specified for the Default Journal History parameter, a warning alert is issued in the
GUI. If the history falls below one hour, an error is issued. However, if the amount of
history defined is only one hour, an error is issued if it is less than 45 minutes.
If the datastore where the journal resides drops below 30GB or 15% of the total datastore
size, whichever is the smaller of these two values, the datastore itself is considered full
and an error alert is issued and all writes to journal volumes on that datastore are
blocked. Replication is halted, but history is not lost. As such, the RPO begins to steadily
increase until space is made available on the datastore.
Journal Size Hard Limit The maximum size that the journal can grow, either as a
percentage or fixed amount. When the value is Unlimited the size for the journal is
unlimited and it can grow to the size of the recovery datastore. When the value is Custom,
you can specify a maximum journal size, either as a percentage of the virtual machine
volume size or as a fixed maximum size. The minimum journal size, set by Zerto Virtual
Replication, is 8GB. The journal is always thin-provisioned.
Journal Size Warning Threshold The size of the journal that triggers a warning that the
journal has neared its hard limit, either as a percentage or fixed amount. You can specify
the value as unlimited or change the value to Custom in order to specify a threshold,
either as a percentage of the virtual machine volume size or as a fixed size, both of which
must be less than the configured hard limit so that the warning will be generated if
needed. In addition to the warning threshold, Zerto Virtual Replication will issue a
message when the free space available for the journal is close to being as full as it can be.
Test Frequency Reminder The time recommended between testing the integrity of the VPG. A
warning is issued if a test is not done within this time frame.
WAN Compression (displayed when the Zerto Virtual Replication license is an enterprise
license) Whether the data is compressed before being transferred to the recovery site or not.
Compressing the data is more efficient but results in a small performance degradation.
Enable WAN compression if network considerations are more critical than CPU usage
considerations. Even if WAN compression is selected, Zerto Virtual Replication decreases the
level of compression if it takes too many resources. Zerto Virtual Replication can also work
with third-party WAN optimization and acceleration technologies, such as those supplied by
Riverbed Technologies, Silver Peak, and others. When third-party WAN optimization is
implemented, it is recommended to disable the VPG WAN compression.
Specify the vApp Settings.
ZORG (displayed when Zerto Cloud Manager is used) The Zerto organization.
Target Site The site to which you want to recover the vApp. The recovery site selected in the
New VPG dialog is displayed and cannot be changed here.
vApp Recovery Cluster/Host The cluster, resource pool or ESX/ESXi host in the recovery site
which handles the replicated data. This value cannot be overridden for each virtual machine
configuration, unless it is to another host in the same cluster. If the site is defined in Zerto
Cloud Manager, only a resource pool can be specified and the resource pool must also have
been defined in Zerto Cloud Manager. For details about Zerto Cloud Manager, refer to Zerto
Virtual Replication Zerto Cloud Manager Installation, Configuration and Management.
When a resource pool is specified, Zerto Virtual Replication checks that the resource pool
capacity is enough for any virtual machines specified in the VPG. If a resource pool is
specified and DRS is disabled for the site later on, all the resource pools are removed by
VMware and recovery will be to any one of the hosts in the recovery site with a VRA installed
on it.
Note: All resource pool checks are made at the level of the VPG and does not take into account
multiple VPGs using the same resource pool. If the resource pool CPU resources are specified
as unlimited in the Edit Setting dialog for the resource pool, the actual limit is inherited from
the parent but if this inherited value is too small, failover move and failover test operations
can fail, even without a warning alert being issued by Zerto Virtual Manager.
vApp Folder The default folder where the vApp is recovered. Select a folder from the list or
the [Default]ZertoRecoveryFolder folder.
4. Optionally, specify default values for the virtual machines in the vApp.
Datastore The default datastore volume to use for all the recovered virtual machine files as
well as for their volumes. Every datastore for the selected default recovery host is included in
the drop-down options. The displayed datastores are accessible by the default host. If a cluster
or resource pool is selected for the host, only datastores that are accessible by every ESX/ESXi
host in the cluster or resource pool are displayed. When specifying the recovery storage for a
virtual machine with a storage cluster, you have to specify a datastore in the cluster.
Note: Zerto Virtual Replication uses the SCSI protocol. Only disks that support this protocol
can be specified.
Failover/Move Network The default network to use during a failover or move in which the
recovered virtual machines will run.
Failover Test Network The default network to use when testing the failover of virtual
machines in the recovery site. Zerto recommends using a fenced-out network so as not to
impact the production network at this site.
The default values are used as the defaults for all the virtual machines included in the VPG,
but can be overridden for each virtual machine configuration, as described in the following
steps.
Note: You define the boot order for vCenter Server vApps in the vSphere Client console, via
Edit Settings for the vApp.
5. If you want a specific recovery configuration for a virtual machine in the VPG, select the
virtual machine from the list and click Configure. Otherwise, the default values specified as
part of the VPG properties are used for the virtual machine recovery configuration.
Note: If default values were not specified, values must be specified here.
The Configure VM dialog is displayed.
The Configure VM dialog enables configuring how the protected virtual machine will be
recovered, including details about the VMware file for the virtual machine, and the volumes
and NICs used by the virtual machine.
Make any changes you want to the virtual machine specification on the recovery site and click
Save to save the configuration.
6. Optionally, select a volume and click Configure Selected Volume to configure the volume used
to replicate the virtual machine disks.
The datastore specified for the replication must have at least the same amount of space as the
source volume and then an additional amount for the journal. The amount of additional space
needed for the journal can be fixed by specifying a maximum size for the journal, or can be
calculated as the average change rate for the virtual machines in the VPG, multiplied by the
length of time specified for the journal history.
Note: You can use the vSphere Client console Performance tab for each virtual machine to
help estimate the change rate. For more details, refer to Collecting Data Characteristics for
VMs, on page 80.
If you click Configure Selected Volume, the Configure Volume dialog is displayed.
configuration option to tune the RPC timeout parameter using the esxcfg-advcfg -s
<Timeout> /NFS/SetAttrRPCTimeout command.
If the protected disks are non-default geometry, configure the VPG using preseeded
volumes.
b) Click Save.
7. Optionally, select a NIC and click Configure Selected NIC to configure the NIC used to for the
replicated VM disks.
Note: You can configure a maximum of four NICs. If you configure more, a failover, move, or
test failover operation will fail.
If you click Configure Selected NIC, the Configure VNIC dialog is displayed.
Specify the network details to use for the recovered virtual machines after a live recovery or
migration, in the Failover/Move tab, and for the recovered virtual machines when testing the
replication, in the Failover Test tab. If the settings are the same for both failover and move
networks and for the failover test network, after setting the values in either tab, click the copy
button, Copy to test or Copy to failover, to copy all the settings defined in the one tab to the
other tab.
In each tab specify the following:
a) The network to use for this virtual machine.
b) Whether the Media Access Control address (MAC address) used on the protected site
should be replicated on the recovery site. The default is to use the same MAC address on
both sites. Check the box to create a new MAC address on the recovery site.
c) Whether to keep the default VNIC IP configuration or not. You can only change the VNIC
IP for virtual machines with VMware Tools running for the following operating systems:
Windows 2003 and higher, Red Hat Enterprise Linux versions 5-6, SUSE Linux
Enterprise versions 10-11 and CentOS versions 5-6.
If you can change the VNIC IP, check the Change Failover VNIC IP Configuration
in the Failover/Move tab or Change Test VNIC IP Configuration in the Failover
Test tab. If you select to use a static IP connection, you set the IP address, subnet mask
and default gateway to use. Optionally, change the preferred and alternate DNS server
IPs and the DNS suffix. If you select to use DHCP, the IP configuration and DNS server
configurations are assigned automatically, to match the protected virtual machine. You
can change the DNS suffix.
Note: During a failover, move or test failover, if the recovered virtual machine is assigned a
different IP to the original IP, after the virtual machine has started it is automatically
rebooted so that it starts up with the correct IP. If the same network is used for both
production and test failovers, it is recommended to change the IP address for the virtual
machines started for the test, so that there is no IP clash between the test machines and the
production machines.
d) Click Save.
8. The virtual machine details include the following:
vApp Recovery Cluster/Host The host that was specified in the Manage VPG dialog to host the
recovered virtual machines in the vApp.
VM Recovery Datastore The datastore where the VMware file for the virtual machine is
stored. If the host is a cluster or resource pool, only datastores that are accessible by every
ESX/ESXi host in the cluster or resource pool are displayed. This is also the datastore where
RDM backing files for recovery volumes are located.
If a default value was specified in the Manage VPG dialog for the datastore, it is used for the
virtual machine configuration and is displayed in the VM Recovery Datastore field. You
can change the value for the specific virtual machine by selecting a different datastore from
the drop-down list.
Recovery Folder The folder where the virtual machine is recovered to, that was specified in
the Manage VPG dialog.
Journal Size Hard Limit The maximum size that the journal can grow. You can specify the
value as unlimited or change the value to Custom in order to specify a maximum journal size,
either as a percentage of the virtual machine volume size or as a fixed maximum size.
Journal Size Warning Threshold The size of the journal that triggers a warning that the
journal is almost full. You can specify the value as unlimited or change the value to Custom in
order to specify a threshold, either as a percentage of the virtual machine volume size or as a
fixed size.
Command to run The name of the script to run, including the full path. The script must be
located on the same machine as the Zerto Virtual Manager for the recovery site.
Params The values of any parameters to pass to the script. Separate parameters with a
space.
Timeout (sec) The time out in seconds for the script to run. If the script runs before executing
a failover, move or test failover and the script fails or a timeout value is reached, an alert is
generated and the failover, move or test failover is not performed. If the script runs after
executing a failover, move or test failover and the timeout value is reached, an alert is
generated. The default timeout value is specified in the Site Configuration Advanced
Settings dialog.
For more details about running scripts with Zerto Virtual Replication, see Running Scripts
Before or After Recovering a VPG, on page 142.
13. Click Save to create the VPG configuration for the vApp.
The VPG is created for the vApp. The VRA in the remote site is updated with information about
the VPG and then the data on the protected virtual machine volumes in the vApp are
synchronized with the replication virtual machines in the VRA on the recovery site. This process
takes some time, depending on the size of the VMs and the bandwidth between the sites. During
this synchronization, you cannot perform any replication task, such as adding a checkpoint, on
the virtual machine. Once synchronized, the VRA on the recovery site includes a complete copy of
every virtual machine in the vApp VPG. After synchronization, the delta changes to virtual
machines in the VPG are sent to the recovery site.
When VMware vCloud Director is installed at either the protected or recovery site, protection
involving vCD can be as follows:
Replication From a vCenter Server to vCloud Director, on page 57.
Replication From vCloud Director to vCloud Director, on page 64.
Replication From vCloud Director to a vCenter Server, on page 71.
When the vCD site is set up within Zerto Cloud Manager, as described in Zerto Virtual
Replication Zerto Cloud Manager Installation, Configuration and Management, the vCenter
Server underlying the vCD for the site cannot be specified as either the source site or target site.
When Zerto Cloud Manager is not used, the vCenter Server underlying the vCD can be specified.
When VMware vCloud Director is installed at the protected site and there are vCD vApps defined
at the protection site, clicking New VPG results in the following New VPG dialog being displayed:
Zerto Virtual Replication does not replicate fenced mode settings. If fenced mode is configured in
the vCD, it must be enabled for recovered virtual machines after a failover or move. This can lead
to clashes with MAC addresses and IP addresses. If this occurs the MAC address or IP address
must be configured after the failover or move.
When vCloud Director is used, you can have the journals on separate datastores from the recovery
volumes. For example, you might prefer to keep the recovery volumes on storage with better
performance, security, and reliability and the journal on less expensive storage1.
Note: You cannot protect virtual machines with VirtualEthernetCardLegacyNetworkBackingInfo
NICs or with IDE devices.
When the recovery site has vCloud Director installed, you can protect virtual machines and vApps
as vCD vApps in the recovery site vCD.
3. Click Continue.
1. As part of recovery after a failover or move operation, the data in the journal is promoted to the recovered virtual machines.
During this promotion, the virtual machines can be used, and Zerto Virtual Replication makes sure that what the user sees is
the latest data, whether from the virtual machine disks or from the journal. If the journal is on a slow storage device, this is
reflected in the response time the user experiences.
The following dialog is displayed if the target vCD is vCD 5.1, showing information about the
storage profile used for each virtual machine in the vCD vApp:
Note: Storage profiles were introduced to vCD in version 5.1. and allow users to intelligently
provision applications, mapping virtual machines to storage levels according to predefined
service levels, storage availability, performance requirements or cost. This mechanism lets
users define and label storage tiers to be used by Storage Distributed Resource Scheduler and
Storage vMotion. Virtual machines that run applications that require the highest level of
performance are mapped to tier one storage, while less critical applications are mapped to the
lower tiers.
4. Optionally, change the name provided for the VPG in the VPG Name field.
Note: The name must be unique per ZORG. Zerto Virtual Replication checks that the name is
unique as long as a VPG with the same name is not being defined while this VPG is still being
created.
5. If the VPG SLA settings are editable, when the Zerto Cloud Manager is not used or when a
Custom service profile is available, specify these settings for the group, which apply to every
virtual machine in the group.
Priority (QOS) Used to determine the priority for transferring data from the protected site to
the recovery site when there is limited bandwidth and more than one VPG is defined on the
protected site. When there are updates to virtual machines protected in VPGs with different
priorities, first the updates from the VPG with the highest priority are passed over the WAN.
Medium priority VPGs will only be able to use whatever bandwidth is left after the high
priority VPGs have used it. This is also true between medium and low priorities. Note that
updates to the protected virtual machines are always sent across the WAN before
synchronization data, such as during a Bitmap Sync or Delta Sync. During a
synchronization, only after updates to the virtual machines are sent over the WAN, based on
the VPG priority, is synchronization data from the VPG sent, and the synchronization data
from the VPG with the highest priority is passed over the WAN before data from medium and
low priority VPGs.
Target RPO Alert The maximum desired time between each automatic checkpoint being
written to the journal before an alert is issued. In reality checkpoints are written more
frequently.
Default Journal History The time for which all write commands are saved in the journal. When
specifying a checkpoint to recover to, the checkpoint must still be in the journal. For example,
if the value specified here is 24 hours then recovery can be specified to any checkpoint less
than 24 hours. After the time specified, the mirror virtual disk volumes maintained by the
VRA are updated. If the journal is not big enough to store all the data for the time specified,
as defined per virtual machine configuration in the VM Max Journal Size field, the time
frame for storing data is reduced. You can further configure the journal by clicking the
configuration button to display the Manage Journal dialog.
Journal Size Hard Limit The maximum size that the journal can grow, either as a
percentage or fixed amount. When the value is Unlimited the size for the journal is
unlimited and it can grow to the size of the recovery datastore. When the value is Custom,
you can specify a maximum journal size, either as a percentage of the virtual machine
volume size or as a fixed maximum size. The minimum journal size, set by Zerto Virtual
Replication, is 8GB. The journal is always thin-provisioned.
Journal Size Warning Threshold The size of the journal that triggers a warning that the
journal has neared its hard limit, either as a percentage or fixed amount. You can specify
the value as unlimited or change the value to Custom in order to specify a threshold,
either as a percentage of the virtual machine volume size or as a fixed size, both of which
must be less than the configured hard limit so that the warning will be generated if
needed. In addition to the warning threshold, Zerto Virtual Replication will issue a
message when the free space available for the journal is close to being as full as it can be.
Test Frequency Reminder The time recommended between testing the integrity of the VPG. A
warning is issued if a test is not done within this time frame.
Specify the vCD Settings for the group.
ZORG (displayed when Zerto Cloud Manager is used) The Zerto organization.
Target Site The site paired with the local site, to which you want to recover the virtual
machines. The recovery site selected in the New VPG dialog is displayed and cannot be
changed here.
Target Org vDC Select the organization datacenter, as defined in vCloud Director, from the
available list. The displayed list is that list that is specified during the vCD configuration. For
details refer to Zerto Virtual Replication Zerto Cloud Manager Installation, Configuration and
Management. The Target Storage Profile values are determined by the Target Org
vDC.
vCD Guest Customization When checked, VMware Guest OS Customization is enabled for the
virtual machine in vCloud Director. Enabling guest customization means that the computer
name and network settings configured for this virtual machine are applied to its Guest OS
when the virtual machine is powered on.
6. Specify the default values for the group.
Failover/Move Network The default Org Network to use during a failover or move in which the
recovered virtual machines will run.
Failover Test Network The default Org Network to use when testing the failover of virtual
machines in the recovery site.
The default values are used as the defaults for all the virtual machines included in the VPG,
but can be overridden for each virtual machine configuration, as described in the following
steps.
Note: You define the boot order for vCloud Director vApps in the vCloud Director console.
7. Add virtual machines to the list of virtual machines that you want to protect in this group.
a) Click Add.
The Select VMs dialog is displayed with a list of virtual machines that are not protected.
b) Select one or more virtual machines to be protected. If the site is defined in Zerto Cloud
Manager, and the cloud service provider is responsible for both the protection and
recovery sites, an In Cloud Disaster Recovery, ICDR, scenario, the virtual machine must
be part of a resource pool and the resource pool must also have been defined as a resource
for the ZORG in Zerto Cloud Manager. For details about Zerto Cloud Manager, refer to
Zerto Virtual Replication Zerto Cloud Manager Installation, Configuration and
Management.
c) Click OK.
Note: The hardware version of the virtual machine must be the same or less than the
hardware version supported by the vDC in vCloud Director otherwise recovery of the virtual
machine in vCD is not permitted. Set the supported hardware level in the Provider vDC
Properties for the vDC in the vCloud Director console.
8. If you want a specific recovery configuration for a virtual machine in the VPG, select the
virtual machine from the list and click Configure. Otherwise, the default values specified as
part of the VPG properties are used for the virtual machine recovery configuration.
The Configure VM dialog is displayed.
Note: If default network values were not specified, values must be specified here.
The following dialog is displayed if the target vCD version is less than is vCD 5.1:
If the target vCD is vCD 5.1, you can also specify the storage profile from the available list in
the VM Advanced Settings.
The Configure VM dialog enables configuring how the protected virtual machine will be
recovered, including details about the NICs and volumes used by the virtual machine.
9. Optionally, select the Failover/Move or Failover Test tab and then select a NIC and click
Configure Selected NIC.
The Configure VNic dialog is displayed.
By default, the NIC configuration for the failover or move production environment is copied
automatically to the configuration for the test environment.
Specify the org vDC network details to use for the recovered virtual machine:
a) The org vDC network to use for this virtual machine or none if disconnected.
b) The VNIC IP configuration. You can only change the VNIC IP for virtual machines with
VMware Tools running for the following operating systems: Windows 2003 and higher,
Red Hat Enterprise Linux 5-6 or SUSE Linux Enterprise 10, in which case you can select
to have a static IP assigned, either from a pool of IPs or manually assign the IP address.
If the virtual machine being protected has a static IP defined for a NIC, this is configured
in the VPG NIC configuration for the virtual machine, automatically.
c) The Media Access Control address (MAC address). The default is the MAC address used
on the protected site so that both the protected machine and recovered machine use the
same MAC address. Either accept the default Mac address or select Reset, to reset the
MAC address on recovery of the machine.
d) Click Save.
10. Optionally, select a volume and click Configure Selected Volume.
The Configure Volume dialog is displayed.
the exact location, the preseed folder configured for the customer and the disk name, of
the preseeded disk. A provider datastore must have been specified for preseeded disks in
the Configure provider vDCs dialog, from the Advanced Settings dialog, as
described in Zerto Virtual Replication Zerto Cloud Manager Installation, Configuration
and Management. Zerto Virtual Replication takes ownership of the preseeded disk,
moving it from its source folder to the folder used by the VRA. Note that if the virtual
machine has more than one preseeded disk, these disks must reside on the same
datastore. If the preseeded disk is greater than 1TB on NFS storage, the VPG creation
might fail. This is a known VMware problem when the NFS client does not wait for
sufficient time for the NFS storage array to initialize the virtual disk after the RPC
parameter of the NFS client times out. The timeout default value is 10 seconds. Refer to
the VMware documentation, http://kb.vmware.com/selfservice/microsites/
search.do?language=en_US&cmd=displayKC&externalId=1027919, which describes the
configuration option to tune the RPC timeout parameter using the esxcfg-advcfg -s
<Timeout> /NFS/SetAttrRPCTimeout command.
Note: Zerto Virtual Replication supports the SCSI protocol. Only disks that support this
protocol can be specified. Also, you cannot replicate RDM in a vCD environment.
b) Click Save.
11. The virtual machine details include the following:
Journal Size Hard Limit The maximum size that the journal can grow. You can specify the
value as unlimited or change the value to Custom in order to specify a maximum journal size,
either as a percentage of the virtual machine volume size or as a fixed maximum size.
Journal Size Warning Threshold The size of the journal that triggers a warning that the
journal is almost full. You can specify the value as automatically determined by Zerto Virtual
Replication or change the value to Custom in order to specify a threshold, either as a
percentage of the virtual machine volume size or as a fixed size.
If the target vCD is vCD 5.1:
Storage Profile Storage profiles enable mapping virtual machines to storage levels
according to predefined service levels, storage availability, performance requirements or
cost. You can define and label storage tiers and then specify the tier to use as a storage
profile, for each virtual machine in the VPG. The default storage profile is the default for
the Target Org vDC.
Note: When moving or failing over a VPG from a site with one version of vCD to a site running
a different version of vCD, the Reverse Protection link to configure the reverse protection
can change to Missing Configuration in red, to highlight that there are settings required
for one version that are not required by the other version.
12. Click Save to save the virtual machine configuration.
13. Configure all the virtual machines in the VPG in the same way.
14. Optionally, specify the settings for scripts to run on the recovery site before or after executing
a failover, move or test failover.
15. Click Save to create the VPG configuration.
The VPG is created. The virtual machines in the VPG are protected as a vCD vApp in the recovery
site. When recovering the VPG, reverse replication is configured to either virtual machines or
vApps, depending on what was originally protected.
When the both sites have vCloud Director installed, you can protect vCD vApps as well as virtual
machines and vApps as vCD vApps in the recovery site vCD.
5. The VPG name is the name of the vCD vApp. Optionally, change this name in the VPG Name
field.
Note: The name must be unique per ZORG. Zerto Virtual Replication checks that the name is
unique as long as a VPG with the same name is not being defined while this VPG is still being
created.
6. Specify the VPG SLA settings for the group.
Priority (QOS) Used to determine the priority for transferring data from the protected site to
the recovery site when there is limited bandwidth and more than one VPG is defined on the
protected site. When there are updates to virtual machines protected in VPGs with different
priorities, first the updates from the VPG with the highest priority are passed over the WAN.
Medium priority VPGs will only be able to use whatever bandwidth is left after the high
priority VPGs have used it. This is also true between medium and low priorities. Note that
updates to the protected virtual machines are always sent across the WAN before
synchronization data, such as during a Bitmap Sync or Delta Sync. During a
synchronization, only after updates to the virtual machines are sent over the WAN, based on
the VPG priority, is synchronization data from the VPG sent, and the synchronization data
from the VPG with the highest priority is passed over the WAN before data from medium and
low priority VPGs.
Target RPO Alert The maximum desired time between each automatic checkpoint being
written to the journal before an alert is issued. In reality checkpoints are written more
frequently.
Default Journal History The time for which all write commands are saved in the journal. Each
protected virtual machine has a dedicated journal volume on the recovery site associated with
the replicated virtual machine. This enables journal data to be maintained, even when
changing the target host for the recovery. When specifying a checkpoint to recover to, the
checkpoint must still be in the journal. For example, if the value specified here is 24 hours
then recovery can be specified to any checkpoint up to 24 hours. After the time specified, the
mirror virtual disk volumes maintained by the VRA are updated. You can further configure
the journal by clicking the configuration button to display the Manage Journal dialog:
Journal Size Hard Limit The maximum size that the journal can grow, either as a
percentage or fixed amount. When the value is Unlimited the size for the journal is
unlimited and it can grow to the size of the recovery datastore. When the value is Custom,
you can specify a maximum journal size, either as a percentage of the virtual machine
volume size or as a fixed maximum size. The minimum journal size, set by Zerto Virtual
Replication, is 8GB. The journal is always thin-provisioned.
Journal Size Warning Threshold The size of the journal that triggers a warning that the
journal has neared its hard limit, either as a percentage or fixed amount. You can specify
the value as unlimited or change the value to Custom in order to specify a threshold,
either as a percentage of the virtual machine volume size or as a fixed size, both of which
must be less than the configured hard limit so that the warning will be generated if
needed. In addition to the warning threshold, Zerto Virtual Replication will issue a
message when the free space available for the journal is close to being as full as it can be.
Test Frequency Reminder The time recommended between testing the integrity of the VPG. A
warning is issued if a test is not done within this time frame.
7. Specify the vCD Settings for the group.
ZORG (displayed when Zerto Cloud Manager is used) The Zerto organization.
Target Site The site paired with the local site, to which you want to recover the virtual
machines. The recovery site selected in the New VPG dialog is displayed and cannot be
changed here.
Target Org vDC Select the organization data center, as defined in vCloud Director, from the
available list. The displayed list is that list that is specified during the vCD configuration. For
details refer to Zerto Virtual Replication Zerto Cloud Manager Installation, Configuration and
Management. The Target Storage Profile values are determined by the Target Org
vDC.
vCD Guest Customization When checked, VMware Guest OS Customization is enabled for the
virtual machine in vCloud Director. Enabling guest customization means that the computer
name and network settings configured for this virtual machine are applied to its Guest OS
when the virtual machine is powered on.
Network Mapping The networks to use for failover and move operations, for failover test
operations, and for test failover operations after a failover or move when reverse protection is
configured. After selecting a target Org vDC, the vApp Network Mapping Configure button
is enabled. Click the Configure button to display the Configure Network Mapping dialog:
The list of current Org Networks is displayed and you can specify what network to use in
each of the situations. <Isolated> means that the network is an internal only vApp
network.
Note: You define the boot order for vCloud Director vApps in the vCloud Director console.
8. If you want a specific recovery configuration for a virtual machine in the VPG, select the
virtual machine from the list and click Configure. Otherwise, the default values specified as
part of the VPG properties are used for the virtual machine recovery configuration.
The Configure VM dialog is displayed.
Note: If default network values were not specified, values must be specified here.
The following dialog is displayed if the target vCD version is less than is vCD 5.1:
If the target vCD is vCD 5.1, you can also specify the storage profile from the available list in
the VM Advanced Settings.
The Configure VM dialog enables configuring how the protected virtual machine will be
recovered, including details about the NICs and volumes used by the virtual machine.
9. Optionally, select the Failover or Test tab and then select a NIC and click Configure Selected
NIC.
The Configure VNic dialog is displayed.
By default, the NIC configuration for the failover environment is copied automatically to the
configuration for the test environment.
Specify the network details to use for the recovered virtual machines:
a) The network to use for this virtual machine or none if disconnected.
b) The VNIC IP configuration. You can only change the VNIC IP for virtual machines with
VMware Tools running for the following operating systems: Windows 2003 and higher,
Red Hat Enterprise Linux 5-6 or SUSE Linux Enterprise 10, in which case you can select
to have a static IP assigned, either from a pool of IPs or manually assign the IP address.
If the virtual machine being protected has a static IP defined for a NIC, this is configured
in the VPG NIC configuration for the virtual machine, automatically.
c) The Media Access Control address (MAC address). The default is the MAC address used
on the protected site so that both the protected machine and recovered machine use the
same MAC address. Either accept the default Mac address or select Reset, to reset the
MAC address on recovery of the machine.
d) Click Save.
10. Optionally, select a Volume and click Configure Selected Volume.
The Configure Volume dialog is displayed.
machine has more than one preseeded disk, these disks must reside on the same
datastore.
Note: Zerto Virtual Replication supports the SCSI protocol. Only disks that support this
protocol can be specified. Also, you cannot replicate RDM in a vCD environment.
b) Click Save.
11. The virtual machine details include the following:
Journal Size Hard Limit The maximum size that the journal can grow. You can specify the
value as unlimited or change the value to Custom in order to specify a maximum journal size,
either as a percentage of the virtual machine volume size or as a fixed maximum size.
Journal Size Warning Threshold The size of the journal that triggers a warning that the
journal is almost full. You can specify the value as automatically determined by Zerto Virtual
Replication or change the value to Custom in order to specify a threshold, either as a
percentage of the virtual machine volume size or as a fixed size.
If the target vCD is vCD 5.1:
Storage Profile Storage profiles enable mapping virtual machines to storage levels
according to predefined service levels, storage availability, performance requirements or
cost. You can define and label storage tiers and then specify the tier to use as a storage
profile, for each virtual machine in the VPG. The default storage profile is the default for
the Target Org vDC.
Note: When moving or failing over a VPG from a site with one version of vCD to a site running
a different version of vCD, the Reverse Protection link to configure the reverse protection
can change to Missing Configuration in red, to highlight that there are settings required
for one version that are not required by the other version.
12. Click Save to save the virtual machine configuration.
13. Configure all the virtual machines in the VPG in the same way.
14. Optionally, specify the settings for scripts to run on the recovery site before or after executing
a failover, move or test failover.
15. Click Save to create the VPG configuration.
The VPG is created. The virtual machines in the VPG are protected as a vCD vApp in the recovery
site. When recovering the VPG, reverse replication is configured to either virtual machines or
vApps, depending on what was originally protected.
Note: Changing the name of a vCD vApp after a VPG has been defined does not result in the name
of the VPG changing.
When recovering the VPG, via a move or failover operation, reverse replication is configured to a
vCD vApp.
If you want the replication to be to a vCenter Server, the vCD vApp is replicated in the recovery
site as a vApp.
Note: Because recovery is as a vApp, DRS must be enabled in the recovery site. When protecting
virtual machines in vCenter Server and recovering to vCloud Director, after a recovery with
reverse protection, from the vCD to the vCenter, the virtual machines are not replicated back to
the original site as a vApp.
The same site can be used for both the protected and recovery sites. To enable replication to the
same site, check the Enable replication to self option in the Advanced Settings dialog,
as described in Enable Replication to the Same Site That is Protecting the Virtual Machines, on
page 89.
Even if the site is not paired with another site, VPGs can be created.
The following list of examples is not exclusive and is intended to provide useful scenarios where
replicating to the same site can be advantageous:
In an organization that does not have a recovery site but wants to protect its virtual machines
that use one datastore by creating recovery on a second datastore. this protects against a
disaster happening to the primary datastore.
Where the same vCenter Server manages different datacenters in different geographical
locations. One of the datacenters can be used as the recovery site. For example with remote
offices or branch offices.
Between hosts in different clusters. Within a cluster VMware provides the tools to ensure that
if there is a problem with one host in the cluster, the virtual machines belonging to that host
are vMotioned to another host, but this is not possible between clusters
protection against viruses, even in a single cluster, a different host can serve as the recovery
host for an internal problem with a virtual machine, such as a virus.
If the site is paired with another site, the New VPG dialog is displayed with the Recover
Site list including site (Local) where site is the site used for both protection and
recovery.
The procedure is the same as when protecting a virtual machines, described in Configuring
Virtual Protection Groups, on page 26.
After defining a VPG and then click Save in the Manage VPG dialog, the VPG is created. The VRA
in the remote site is updated with information about the VPG and then the data on the protected
virtual machines are synchronized with the replication virtual machines in the VRA on the
recovery site. This process can take some time, depending on the size of the VMs and the
bandwidth between the sites.
Note: For the synchronization to work, the protected virtual machines must be powered on. The
VRA requires an active IO stack to access the virtual machine data to be synchronized across the
sites. If the virtual machine is not powered on, there is no IO stack to use to access the source data
to replicate to the target recovery disks and an alert is issued.
Once synchronized, the VRA on the recovery site includes a complete copy of every virtual
machine in the VPG. After synchronization the virtual machines in the VPG are fully protected
and the delta changes to these virtual machines are sent to the recovery site
Note: The values for each virtual machine in the VPG include the provisioned storage and used
storage. These values are the values that are used in the vCenter Server and displayed in the
vSphere Client console per virtual machine in the Virtual Machines tab for the root vCenter
Server node. Each value is the sum of both the hard disk and memory. Thus, a virtual machine
with 1GB hard disk and 4GB memory will show 5GB provisioned storage.
For details of the screen, see Monitoring a VPG, on page 98.
Refer to Modifying a VPG Definition, on page 122 for details about adding, removing or
reconfiguring virtual machines in the VPG.
Setting Permissions
Zerto Virtual Replication supplies a number of default permissions that enable a VMware
administrator to perform specific actions:
Live Failover / Move Enables performing a failover or move.
Manage cloud connector Enables installing and uninstalling Zerto Cloud Connectors. For details,
refer to Zerto Virtual Replication Zerto Cloud Manager Installation, Configuration and
Management.
Manage Sites Enables editing the site configuration, including site details, pairing and unpairing
sites, updating the license and editing advanced site settings.
Manage VPG Enables creating, editing, and deleting a VPG and adding checkpoints to a VPG.
Manage VRA Enables installing and uninstalling VRAs.
76
Sizing Considerations
Sizing Considerations
There are a number of sizing issues to consider when setting up your disaster recovery, including
the following:
VMDK Size Limitations, below
WAN Sizing, on page 78
VMware imposes the following limits that impact on Zerto Virtual Replication.
ESXi 5.5 hosts The sum of all VMDKs of all virtual machines protected on a particular ESXi
must be lower than 64TB.
ESXi 5.0 and 5.1 hosts The sum of all VMDKs of all virtual machines protected on a particular
ESXi must be lower than, by default, 20TB. Using an ESX tweak, this can grow as high as 64TB.
ESX/ESXi 4.x hosts The sum of all VMDKs of all virtual machines protected on a particular ESXi
must be lower than, by default, 4TB. Using an ESX tweak, this can grow as high as 32TB.
This limit includes not only the VRA and any shadow VRAs, but also all virtual machines running
on that host.
Advanced Configuration 77
Sizing Considerations
WAN Sizing
When preparing your deployment, you need to make sure that the connectivity between the two
sites has bandwidth capacity that can handle the data to be replicated between the sites.
Zerto Virtual Replication employs sophisticated compression algorithms to reduce the bandwidth
required between the sites. While compression can be very effective in reducing the bandwidth
requirements, its efficiency is dependent on data characteristics.
Note: Zerto Virtual Replication can also work with third-party WAN optimization and acceleration
technologies, such as those supplied by Riverbed Technologies, Silver Peak, and others.
Estimating the bandwidth requirements between the protected and recovery sites involves the
following tasks:
1. Enable vCenter Server data collection.
2. Collect data characteristics for VMs.
3. Use the Zerto WAN Sizing Estimator to calculate the estimated bandwidth requirements.
Contact Zerto support to get a copy of the Zerto WAN Sizing Estimator.
Advanced Configuration 78
Sizing Considerations
4. Make sure that the Statistics Level value for all interval durations up to and including the
one day duration is at least 2.
If any of the durations have a value less than 2, do the following, starting with the smallest
interval:
a) Select the interval and click Edit.
b) Change Statistics Level to Level 2.
c) Click OK.
Advanced Configuration 79
Sizing Considerations
5. Repeat step 4 for all the values up to and including the 1 day interval duration.
6. Click OK and wait for at least a day before using the aggregate usage data.
You can collect data characteristics for the virtual machines in a VPG in one of the following
ways:
Via vSphere Client console performance statistics.
By running a script to collect the data characteristics.
By using operating system performance monitors, such as the Microsoft Performance Monitor
utility for Windows operating systems or the iostat command for Linux operating systems.
For further information about this option, contact support at support@zerto.com.
Collect data for a minimum of one day. Collecting this information impacts on performance and
therefore the collection period should be long enough to gather a true representation of usage but
not too long. The first procedure described below, to collect data characteristics for the VMs via
the vSphere Client console performance statistics, uses a timeframe of one day and the second
procedure, to collect data characteristics for the VMs by running a script to collect the data
characteristics uses a timeframe of seven days.
Note: When running vCenter Server versions before version 5.x, if any of the virtual machines use
NFS storage, metrics for the NFS storage are not generated by the vCenter Server.
To collect data characteristics for the VMs via the vSphere Client console performance statistics:
1. In the vSphere Client console select the VM and open the Performance tab.
2. Click Advanced Settings.
3. Click the Charts Options link.
The Customize Performance Chart dialog is displayed.
Advanced Configuration 80
Sizing Considerations
Advanced Configuration 81
Sizing Considerations
Use the chart for the average write rate of the VM.
Advanced Configuration 82
Sizing Considerations
The above script is available as a text file, WANSizing.ps1, in the Zerto Virtual Replication WAN
Sizing.zip file.
Use the average write rate for the virtual machines in a VPG in the Zerto WAN Sizing Estimator
to estimate the minimum bandwidth required.
Note: Contact Zerto support to get a copy of the Zerto WAN Sizing Estimator.
For each VM you also have to decide whether compression will be enabled for the VM, based on
the data characteristics.
Advanced Configuration 83
Editing Information About a Site
You provide information about the site during installation, to make it easier to identify the site in
the in the UI and to identify the contact person at the site. After installation you can updated
these settings.
Advanced Configuration 84
Editing Information About a Site
Advanced Configuration 85
Site Configuration Advanced Settings
You provide additional site settings, such as, the maximum bandwidth that Zerto Virtual
Replication will use between the protected and recovery sites, to determine the default script
timeout, and scaling for performance graphs in the Advanced Settings dialog accessed via the
Site Configuration dialog.
Advanced Configuration 86
Site Configuration Advanced Settings
3. Make any required changes to the settings, click Save and then Close. The following site
settings can be defined in the Advanced Settings dialog:
Defining the Maximum Bandwidth Used by Zerto Virtual Replication Between Sites,
below.
Defining the Default Script Timeout, on page 89.
Defining the Scaling Used for Performance Graphs, on page 89.
Enable Replication to the Same Site That is Protecting the Virtual Machines, on page
89.
Defining the Replication Pause Time, on page 90.
Defining the Failover and Move Operation Default Commit Policy, on page 90.
Configuring Email Notifications for Alerts, on page 91.
Defining Resource Report Sampling Period, on page 91.
Reviewing Supported Host Versions, on page 92.
Defining Zerto Support Settings, on page 92.
You also use the Advanced Settings dialog to setup vCloud Director and Zerto cloud connector
static routes. For details, refer to Zerto Virtual Replication Zerto Cloud Manager Installation,
Configuration and Management.
Advanced Configuration 87
Site Configuration Advanced Settings
Bandwidth Throttling The maximum bandwidth that Zerto Virtual Replication uses from this site
to recovery sites. The default value is for Zerto Virtual Replication to automatically assign the
bandwidth used per VPG, based on using the maximum available and then prioritizing the usage
according to priority set for the VPGs sending data over the WAN. You can use the slider to set
the Mb/sec. If you are going to protect virtual machines on this site as well as recover virtual
machines to this site, for example via failback, you have to also set the bandwidth on the remote
site out to this site.
Note: The minimum supported bandwidth is 5 Mb/sec.
For details about estimating the bandwidth, see Sizing Considerations, on page 77.
Time-based Bandwidth Throttling If you know that the bandwidth needs specific throttling for a
certain time, for example, during the daily peak transaction period you can override the general
throttling of the bandwidth for these specific times.
Advanced Configuration 88
Site Configuration Advanced Settings
Note: These throttling features can be disabled at the request of Zerto support.
Default Script Execution Timeout The time out in seconds for a script to run before or after a
failover, move or test failover. For details about scripts, see Running Scripts Before or After
Recovering a VPG, on page 142.
Graphical Scaling Fields enable changing the scaling used in the performance graphs:
VPG performance graphs, for example in the VPG Details dialog:
IOPS The IO between the applications running on the virtual machines in the VPG and the
VRA.
Throughput The MBs for the applications running on the virtual machines being protected.
WAN Traffic The traffic between the sites.
RPO The time since the last checkpoint was written to the journal.
VRA performance graphs, for example in the VPG Details dialog:
CPU The percentage of CPU usage by the VRA.
VRA Local Memory The percentage of the VRA memory used by protected volumes managed
by the VRA.
VRA Remote Memory The percentage of the VRA memory used by recovery volumes managed
by the VRA.
Enable replication to self When the same site is used for both the protected and recovery sites,
specify this option to enable recovery to the same site.
Advanced Configuration 89
Site Configuration Advanced Settings
Replication Pause Time The time to pause when synchronizing a VPG if continuing the
synchronization will cause all the checkpoints in the journal to be removed. A synchronization can
occur, for example, after the WAN or the recovery site host was down.
During the synchronization, the latest changes in the protection site are added to the journal and
older data in the journal is moved to the mirror virtual disk managed by the VRA for the virtual
machine. As the synchronization continues and more old data is moved out of the journal, the
checkpoints associated with the data are also removed from the journal and new checkpoints are
not added to the journal. If the synchronization continues for too long, all the checkpoints can be
removed from the journal meaning all recovery operations, test failover, move and failover, can no
longer be performed.
The replication pause time is an amount of time that the synchronization pauses, when the
number of checkpoints in the journal becomes too small. This time can then be used by the
administrator to resolve the issue, for example by cloning the virtual machines in the VPG,
described in Cloning Protected Virtual Machines to the Remote Site, on page 205, before
continuing with the synchronization. The value set here is applied to existing and new VPGs.
Failover/Move Commit Policy The policy to use during a failover or move operation, described in
Initiating a Failover, on page 211 and Moving Protected Virtual Machines to the Remote Site,
on page 197 respectively. The following options are available:
None The failover or move operation must be manually committed or rolled back by the user.
Commit After the time specified in the Default Timeout field the failover or move
operation is committed, unless manually committed or rolled back by the user before the time
out value is reached. During the specified time you can check the recovered VPG virtual
machines.
Rollback After the time specified in the Default Timeout field the failover or move
operation is rolled back, unless manually committed or rolled back by the user before the time
out value is reached. During the specified time you can check the recovered VPG virtual
machines.
The value set here applies as the default for all failover or move operations from this point on but
can be changed when defining a failover or move operation.
Default Timeout The time out in minutes after which a Commit or Rollback commit policy is
performed. A value of zero indicates automatically performing the commit policy, without waiting
for any user interaction.
Advanced Configuration 90
Site Configuration Advanced Settings
Configure Notifications Click Configure Notifications and configure Zerto Virtual Replication
alerts to be sent to an email address, so as to be better informed when an alert occurs.
Specify when you want to take resource samples to identify resource usage, either daily at a
specific hour and minute or hourly at a specific minute within each hour.
The time set is the time that the sample is taken, so for example, if you set a daily time at 12:00,
you will get a sample taken at midday every day. Note that collecting a sample hourly provides a
higher resolution picture of replication traffic than if collected every daily.
Information is saved for 90 days when the sampling period is hourly and for one year when the
sampling period is daily.
These samples are used to generate resource reports as described in Resource Report, on page
227.
Advanced Configuration 91
Site Configuration Advanced Settings
Zerto Virtual Replication works with most ESX/ESXi hosts. For a list of the supported hosts, click
Compatibility Matrix.
The Compatibility Matrix dialog is displayed, listing all the supported host versions.
When moving the mouse pointer over the top part of the dialog, a Support tab is displayed on the
right of the list.
Clicking the tab opens the Settings Requested by Zerto Support dialog.
Advanced Configuration 92
Chapter 5: Monitoring Zerto Virtual
Replication
You can monitor information about all the VPGs either protected at the local site or recovered to
the local site in the VPGs tab. You can also drill-down to monitor information about a specific
VPG displayed in the VPGs tab or about the virtual machines being protected by VPGs. You can
also view summary details of the protected and recovery sites in either the protected or recovery
site as well as monitor the status of each virtual protection group and any of the virtual machines
being protected in either site.
The following VPG management options are described in this chapter:
Monitoring Recovery Details The Summary Tab, below.
Monitoring VPGs The VPGs Tab, on page 96.
Monitoring a VPG, on page 98.
Monitoring Recent Activities, on page 100.
Monitoring Protected Virtual Machines The VMs Tab, on page 104.
Monitoring Virtual Replication Appliances, on page 106.
Monitoring VPG Usage by Remote Sites and Site Topology, on page 111.
93
Monitoring Recovery Details The Summary Tab
Once the protected and recovery sites have been paired, you can view information about the sites
and the defined virtual protection groups from the root vCenter Server node Zerto tab.
View summary details of both the protected and recovery sites.
The information includes the number of virtual machines being protected and the number of
VPGs defined. The arrows between the sites indicates the direction of the protection. For
example, in the above diagram there are three VPGs defined on the production site that are
protected to recovery sites and there are two VPGs defined on recovery sites that are protected to
the production site.
The following information is displayed in the left area:
The site name and IP address of the Zerto Virtual Manager for this site.
The number of virtual machines meeting the target RPO, the SLA, out of the total number of
virtual machines included in VPGs.
The number of VPGs meeting the target RPO, the SLA, out of the total number of VPGs
defined on the site.
The amount of storage being protected of the total possible for all the virtual machines in all
the VPGs defined on this site.
The current site performance, which includes the following information:
IOPS (IO per second) The IO between all the applications running on the virtual
machines being protected and the VRA that sends a copy to the remote site for replication.
VRA CPU Usage The percentage of the CPU being used by the VRA.
Throughput The MBs for all the applications running on the virtual machines being
protected. There can be a high IO rate with lots of small writes resulting in a small
throughput as well as a small IO with a large throughput. Thus, both the IOPS and
Throughput values together provide a more accurate indication of performance.
WAN Traffic The traffic between the sites.
When applicable, the date of the last test performed and the name of the VPG tested.
The amount of recovery storage being replicated to this site from remote sites.
The following information is displayed in the right area:
If the pairing is to one site only, the site name and IP address of the Zerto Virtual Manager for
the paired site, otherwise, the title Multiple Peers.
The number of virtual machines meeting the target RPO, the SLA, out of the total number of
virtual machines included in VPGs protected on the remote sites.
The number of VPGs meeting the target RPO, the SLA, out of the total number of VPGs
protected on the remote sites.
The amount of storage being replicated out of the total possible for all the virtual machines in
all the VPGs protected on the remote sites.
The amount of recovery storage being replicated to the remote sites, which includes both the
journal and target disk sizes.
View specific details of the VPGs in the VPGs tab. This tab lists all the VPGs from both the local
and remote sites and provides summary details of each VPG.
Actual RPO The time since the last checkpoint was written to the journal. This should be
less than the Target RPO Alert value specified for the VPG.
Status The current status of the VPG, such as Updating, Syncing, Protecting. Where
appropriate, the percentage of the operation completed, such as syncing, is displayed.
Last Test The date and time of the last failover test performed on this VPG.
Type (not shown by default) Icons describing the source and target sites:
vCenter Server to vCenter Server.
vCenter Server to vCloud Director.
vCloud Director to vCenter Server.
vCloud Director to vCloud Director.
ZORG Name (not shown by default) A name given to the organization by a cloud service
provider. For details refer to Zerto Virtual Replication Zerto Cloud Manager Installation,
Configuration and Management.
Provisioned Storage (not shown by default) The provisioned storage for all the virtual
machines in the VPG. This value is the sum of the values that are used in the vSphere Client
console per virtual machine in the Virtual Machines tab for the root vCenter Server node.
Each value is the sum of both the hard disk and memory. Thus, a virtual machine with 1GB
hard disk and 4GB memory will show 5GB provisioned storage.
Used Storage (not shown by default) The storage used by all of the virtual machines in the
VPG. This value is the sum of the values that are used in the vSphere Client console per
virtual machine in the Virtual Machines tab for the root vCenter Server node.
IO (not shown by default) The IO per second between all the applications running on the
virtual machines in the VPG and the VRA that sends a copy to the remote site for replication.
Throughput (not shown by default) The MBs for all the applications running on the virtual
machines being protected. There can be a high IO rate with lots of small writes resulting in a
small throughput as well as a small IO with a large throughput. Thus, both the IOPS and
Throughput values together provide a more accurate indication of performance.
Network (not shown by default) The amount of WAN traffic.
Filtering Information
You can filter the list so that you can easily identify the VPGs and virtual machines you want to
monitor.
You can filter columns by clicking the filter icon and then either by typing part of the value only,
for example with the Source Site field, or you can filter using actual values, for example with
the Priority field. The filter changes color from grey to blue when a filter is applied. A link in
the filter area enables clearing the filter.
Determining Which Columns to Display and the Order They Are Displayed
Right-clicking in the list enables selecting the Edit Columns dialog, where you can specify what
columns to display in the list.
You can also drag-and-drop column headers to rearrange the order the columns are displayed. A
thick vertical bar shows where a column can be dragged and dropped.
You can also reset the display to the default display by right-clicking in the list and selecting the
Reset Columns item.
Monitoring a VPG
You monitor the status of a specific VPG by drilling-down for the VPG in the VPGs tab or from a
virtual machine in the VMs tab. The specific VPG details are displayed in a dynamic tab.
You can monitor the recent tasks performed either for all Zerto Virtual Replication or for a
specific VPG.
In the title bar the last task run or a currently running task is displayed, with the percentage
completed and the total number of running tasks as a link.
Click the link to expand the Tasks area at the bottom of the dialog or move the separator in the
tasks area to expand this area.
You can move the separator bar up or down to show more or less tasks. You can also change the
period of time to show tasks by clicking the time in the tasks bar.
The default is to list all tasks in the specified period but you can filter the tasks by the following:
All tasks
Running tasks
Completed tasks
Failed tasks
The following information is displayed about each task:
Task The task.
Related Entities The names of the entities affected by the task, such as the VPGs and sites.
Initiated by The user who initiated the task, either the user who logged on or the system.
You can see the most recent actions for a specific VPG from within the VPG details view, either by
clicking the tasks link in the title bar or by clicking the Recent Activities button.
When you click the tasks link, the tasks view for the VPG is displayed.
You can switch the view to view the all the tasks in the specified period by clicking All in the tasks
bar.
When you click the Recent Activities button, the Recent Activities dialog is displayed.
The information in the Recent Activities dialog is similar to that displayed in the Tasks area
but includes a description and does not include the related entities nor both the start and end
times of the task.
Note: The Recent Activities dialog is useful when you need to identify target disks, for
example after deleting a VPG and keeping the target disks.
Time and Date The date of the activity.
View specific details of the protected VMs in the VMs tab. This tab lists all the protected virtual
machines from both the local and remote sites and provides summary details of each virtual
machine.
IO The IO per second between all the applications running on the virtual machine and the
VRA that sends a copy to the remote site for replication.
Throughput The MBs for all the applications running on the virtual machine being
protected. There can be a high IO rate with lots of small writes resulting in a small
throughput as well as a small IO with a large throughput. Thus, both the IOPS and
Throughput values together provide a more accurate indication of performance.
Network The amount of WAN traffic.
Provisioned Storage The provisioned storage for the virtual machine in the recovery site.
This value is the sum of the values that are used in the vCenter Server and displayed in the
vSphere Client console per virtual machine in the Virtual Machines tab for the root vCenter
Server node. Each value is the sum of both the hard disk and memory. Thus, a virtual
machine with 1GB hard disk and 4GB memory will show 5GB provisioned storage.
Used Storage The storage used by the virtual machine in the recovery site. This value is the
sum of the values that are used in the vCenter Server and displayed in the vSphere Client
console per virtual machine in the Virtual Machines tab for the root vCenter Server node.
Actual RPO The time since the last checkpoint was written to the journal. This should be
less than the Target RPO Alert value specified for the VPG.
Status The current status of the virtual machine, such as Updating, Syncing, Protecting.
Where appropriate, the percentage of the operation completed, such as syncing, is displayed.
Last Test The date and time of the last failover test performed on the VPG protecting this
virtual machine.
Direction (not shown by default) The direction of the replication, from this site to the remote
site or from the remote site to this site.
Type (not shown by default) Icons describing the source and target sites:
vCenter Server to vCenter Server.
vCenter Server to vCloud Director.
vCloud Director to vCenter Server.
vCloud Director to vCloud Director.
Source Site (not shown by default) The name of the site where the virtual machine is
protected.
Target Site (not shown by default) The name recovery site for the virtual machine.
Organization (not shown by default) The ZORG name given to the organization by a cloud
service provider. For details refer to Zerto Virtual Replication Zerto Cloud Manager
Installation, Configuration and Management.
Priority (not shown by default) The priority specified for the VPG in its definition.
Determining Which Columns to Display and the Order They Are Displayed
Right-clicking in the list enables selecting the Edit Columns dialog, where you can specify what
columns to display in the list.
You can also drag-and-drop column headers to rearrange the order the columns are displayed. A
thick vertical bar shows where a column can be dragged and dropped.
You can also reset the display to the default display by right-clicking in the list and selecting the
Reset Columns item.
Filtering Information
You can filter the list so that you can easily identify the VPGs and virtual machines you want to
monitor.
You can filter columns by clicking the filter icon and then either by typing part of the value only,
for example with the Source Site field, or you can filter using actual values, for example with
the Priority field. The filter changes color from grey to blue when a filter is applied. A link in
the filter area enables clearing the filter.
You can monitor information about all the VRAs for the local site in the VRAs tab. You can also
drill-down to monitor information about a specific VRA displayed in the VRAs tab:
Monitoring VRAs The VRAs Tab, below.
Monitoring a VRA, on page 109.
View specific details of the VRAs in the VRAs tab. This tab lists all the hosts in the local vCenter
and details of VRAs for each host, when installed.
Alert status indicator The color indicates the alert status of the VRA:
Green The VRA is functioning as required.
Orange The VRA is functioning, but as well as is require.
Red There is a problem with the VRA, for example communication with the Zerto Virtual
Manager is down.
VRA Name The name of the VRA virtual machine.
VRA Status The VRA status. For example, Installed, Ghost VRA.
Determining Which Columns to Display and the Order They Are Displayed
Right-clicking in the list enables selecting the Edit Columns dialog, where you can specify what
columns to display in the list.
You can also drag-and-drop column headers to rearrange the order the columns are displayed. A
thick vertical bar shows where a column can be dragged and dropped.
You can also reset the display to the default display by right-clicking in the list and selecting the
Reset Columns item.
Filtering Information
You can filter the list of VRAs in the VRAs tab.
You can filter columns by clicking the filter icon and then either by typing part of the value only,
for example with the VRA Group field, or you can filter using actual values, for example with the
#VPGs field. The filter changes color from grey to blue when a filter is applied. A link in the filter
area enables clearing the filter.
Monitoring a VRA
You monitor the status of a specific VRA by drilling-down for the VRA in the VRAs tab. The
specific VRA details are displayed in a dynamic tab.
Configuration details including the VRA virtual machine name, the datastore it uses and
network it connects to and the VRA RAM and network details defined when installing the
VRA.
A table of the VPGs with virtual machines managed by this VRA, including the name of the
VPG, the source and target sites, the VPG status and usage information.
A table of the virtual machines managed by this VRA, including the name of the virtual
machine, the name of the VPG used to protect the virtual machine, the source and target
sites, the VPG status and usage information.
You can display information about the remote sites for the local site either as a list via the Sites
tab or graphically via the Topology tab.
View specific details of the paired sites in the Sites tab. This tab lists all the paired sites to the
local site and provides summary details of each paired site.
# Used VMs The total number of virtual machines being protected by the site and replicated to
the site.
Location The location specified for the paired site during installation or in the Site
Configuration dialog.
Provisioned Storage The maximum storage that can be protected.
IO The IO per second between all the applications running on the virtual machine in the VPG
and the VRA that sends a copy to the remote site for replication.
Incoming Throughput The MBs for all the applications running on the virtual machine being
protected. There can be a high IO rate with lots of small writes resulting in a small throughput as
well as a small IO with a large throughput. Thus, both the IO and Incoming Throughput values
together provide a more accurate indication of performance.
Determining Which Columns to Display and the Order They Are Displayed
Right-clicking in the list enables selecting the Edit Columns dialog, where you can specify what
columns to display in the list.
You can also drag-and-drop column headers to rearrange the order the columns are displayed. A
thick vertical bar shows where a column can be dragged and dropped.
You can also reset the display to the default display by right-clicking in the list and selecting the
Reset Columns item.
The Topology tab graphically displays the sites and details about the sites, including the
number of VPGs and virtual machines being protected. Hovering the mouse over a site displays
the IP address for that site.
You can refresh the display and make the display larger or smaller using the slider.
Clicking on a site selects that site and details of the selected site are displayed in the Selected
Site Details pane.
The alert status indicator shows the alert status of the site:
Green The site VPGs are being replicated, including syncing the VPGs between the sites.
Orange The VPG is being replicated but there are problems, such as an RPO value larger than
the Target RPO Alert value specified for the VPG.
Red The site VPGs are not being replicated, for example because communication with the
remote site is down.
After defining virtual protection groups (VPGs) the virtual machines specified as part of each
VPG are protected. There are a number of ongoing management tasks that you can perform on a
VPG, such as specifying a checkpoint to enable recovery to that specific point or you can modify
the configurations of existing VPGs.
The following VPG management options are described in this chapter:
Adding a Virtual Machine to an Existing VPG, below.
Moving a Virtual Machine To or From a Protected vApp, on page 121
Modifying a VPG Definition, on page 122.
Modifying Source Virtual Machine Volumes, on page 125.
Pausing the Protection of a VPG, on page 126.
Forcing the Synchronization of a VPG, on page 129.
Deleting a VPG, on page 131.
Ensuring Application Consistency Checkpoints, on page 132.
Running Scripts Before or After Recovering a VPG, on page 142.
Exporting and Importing VPG Definitions, on page 149.
VPG Statuses and Synchronization Triggers, on page 151.
Managing Protection When a Recovery Datastore Will Be Unavailable (Datastore
Maintenance), on page 156.
You can add a virtual machine, that is not already included in a VPG, to an existing VPG.
After adding the virtual machine the VPG is updated. While the VPG definition is being updated,
you cannot perform any operations on the VPG, such as adding a checkpoint, editing the VPG
properties or failing the VPG. After the definition is updated, the VPG is synchronized with the
recovery site for the added virtual machine and also during this time you cannot perform any task
that requires the protected and recovery sites to be synchronized together, such as adding a
checkpoint or failing the VPG. You can, however, make changes to the VPG definition, as
described in Modifying a VPG Definition, on page 122.
Note: Adding a virtual machine to a VPG results in all checkpoints being removed and restarting
after the added virtual machine is synchronized.
114
Adding a Virtual Machine to an Existing VPG
You can add a virtual machine to an existing VPG, either via the VPG definition or, in the
vSphere Client console or Web Client, via the Zerto tab for the virtual machine to add, as
described in To add a virtual machine to an existing VPG via the vSphere Client console or Web
Client:, on page 41.
The Manage VPG dialog is displayed, enabling editing the VPG, including adding and
removing virtual machines from the VPG. The VPG SLA, Settings and Default Values
sections of the dialog can vary dependent on whether the license being used is a cloud license
or an enterprise license, whether Zerto Cloud Manager is used or not, whether a vApp is being
protected and whether the target site is vCD.
When protecting to a site with a cloud license, WAN compression is always implemented, so
the WAN Compression checkbox is not displayed. When protecting to a cloud site and the
cloud service provider uses Zerto Cloud Manager, WAN compression is always implemented,
so the WAN Compression checkbox is not displayed and the VPG SLA values are controlled by
a service profile.
2. Click Add and select the virtual machine to add to the VPG from the list and then click OK.
You can search for a specific virtual machine from the list.
Note: If the site is defined in Zerto Cloud Manager, and the cloud service provider is
responsible for both the protection and recovery sites, an In Cloud Disaster Recovery, ICDR,
scenario, the virtual machine must be part of a resource pool and the resource pool must also
have been defined as a resource for the ZORG in Zerto Cloud Manager. For details about
Zerto Cloud Manager, refer to Zerto Virtual Replication Zerto Cloud Manager Installation,
Configuration and Management.
3. Configure the virtual machine configuration, as described in To configure the virtual
machine in the VPG:, below.
4. Click Save.
The virtual machine is added to the VPG. This process may take a few minutes. The protected
and recovery sites are then synchronized so that the recovery site includes the replication of the
added virtual machine in the VPG. After synchronization, the delta changes to the virtual
machine are sent to the recovery site.
If the virtual machine is added to a VPG replicating to a resource pool, Zerto Virtual Replication
checks that the additional virtual machine doesnt exceed the resource pool capacity, such that
the sum of the virtual machine reservation is less than or equal to the resource pool CPU and
storage settings.
The Configure VM dialog enables configuring how the protected virtual machine will be
recovered, including details about the volumes and NICs used by the virtual machine and the
VMware file for the virtual machine.
Make any changes you want to the virtual machine specification on the recovery site and click
Save to save the configuration.
2. Optionally, select a volume and click Configure Selected Volume to reconfigure the volume
used to replicate the virtual machine disks.
If you click Configure Selected Volume, the Configure Volume dialog is displayed.
a) Specify the datastore for recovery and whether the volume is a swap disk:
If a cluster or resource pool is selected for the host, only datastores that are accessible by
every ESX/ESXi host in the cluster or resource pool are displayed.
Swap If the virtual machine to be replicated includes a swap disk as part of its
configuration, you can specify a mirror disk for replication that is marked as a swap disk.
In this case, data is not replicated to the swap disk after initial synchronization.
Recovery Datastore The datastore to use to create disks for the replicated data. Also
specify whether the target is thin provisioned. If the source disk is thin provisioned, the
default for the recovery volume is that it is also thin provisioned.
Raw Disk (RDM) The VMware RDM (Raw Device Mapping) to use for the replication. If
the protected virtual machine has RDMs attached, these disks are recovered by default as
thin-provisioned VMDKs to the datastore specified in the VM Recovery Datastore field
in the Configure VM dialog, unless an RDM is specified. Only a raw disk with the same
size as the protected disk can be selected from the list of available raw disks. Other raw
disks with different sizes are not available for selection. The RDM is always stored in the
recovery datastore used for the virtual machine. You cannot define an RDM disk if the
virtual machine uses a BusLogic SCSI controller, nor when protecting or recovering
virtual machines in an environment running vCenter Server 5.x with ESX/ESXi version
4.1 hosts.
Preseed A virtual disk (the VMDK flat file and header file) in the recovery site that has
been prepared with a copy of the protected data, so that the initial synchronization is
much faster since a Delta Sync is used to synchronize any changes written to the
recovery site after the creation of the preseeded disk. When using a preseeded VMDK, you
select the datastore and exact location, folder and name, of the preseeded disk, which
cannot be an IDE disk. Zerto Virtual Replication takes ownership of the preseeded disk,
moving it from its source folder to the folder used by the VRA. Only disks with the same
size as the protected disk can be selected when browsing for a preseeded disk. The
datastore where the preseeded disk is placed is also used as the recovery datastore for the
replicated data. If the preseeded disk is greater than 1TB on NFS storage, the VPG
creation might fail. This is a known VMware problem when the NFS client does not wait
for sufficient time for the NFS storage array to initialize the virtual disk after the RPC
parameter of the NFS client times out. The timeout default value is 10 seconds. Refer to
the VMware documentation, http://kb.vmware.com/selfservice/microsites/
search.do?language=en_US&cmd=displayKC&externalId=1027919, which describes the
configuration option to tune the RPC timeout parameter using the esxcfg-advcfg -s
<Timeout> /NFS/SetAttrRPCTimeout command.
If the protected disks are non-default geometry, configure the VPG using preseeded
volumes.
b) Click Save.
3. Optionally, select a NIC and click Configure Selected NIC to configure the NIC used to for the
replicated VM disks.
Note: You can configure a maximum of four NICs. If you configure more, a failover, move, or
test failover operation will fail.
If you click Configure Selected NIC, the Configure VNIC dialog is displayed.
Specify the network details to use for the recovered virtual machines after a live recovery or
migration, in the Failover/Move tab, and for the recovered virtual machines when testing the
replication, in the Failover Test tab. If the settings are the same for both failover and move
networks and for the failover test network, after setting the values in either tab, click the copy
button, Copy to test or Copy to failover, to copy all the settings defined in the one tab to the
other tab.
In each tab specify the following:
a) The network to use for this virtual machine.
b) Whether the Media Access Control address (MAC address) used on the protected site
should be replicated on the recovery site. The default is to use the same MAC address on
both sites. Check the box to create a new MAC address on the recovery site.
c) Whether to keep the default VNIC IP configuration or not. You can only change the VNIC
IP for virtual machines with VMware Tools running for the following operating systems:
Windows 2003 and higher, Red Hat Enterprise Linux versions 5-6, SUSE Linux
Enterprise versions 10-11 and CentOS versions 5-6.
If you can change the VNIC IP, check the Change Failover VNIC IP Configuration
in the Failover/Move tab or Change Test VNIC IP Configuration in the Failover
Test tab. If you select to use a static IP connection, you set the IP address, subnet mask
and default gateway to use. Optionally, change the preferred and alternate DNS server
IPs and the DNS suffix. If you select to use DHCP, the IP configuration and DNS server
configurations are assigned automatically, to match the protected virtual machine. You
can change the DNS suffix.
Note: During a failover, move or test failover, if the recovered virtual machine is assigned a
different IP to the original IP, after the virtual machine has started it is automatically
rebooted so that it starts up with the correct IP. If the same network is used for both
production and test failovers, it is recommended to change the IP address for the virtual
machines started for the test, so that there is no IP clash between the test machines and the
production machines.
d) Click Save.
4. The virtual machine details include the following:
Recovery Host The cluster, resource pool or ESX/ESXi that will host the recovered virtual
machine. If the site is defined in Zerto Cloud Manager, only a resource pool can be specified
and the resource pool must also have been defined in Zerto Cloud Manager. For details about
Zerto Cloud Manager, refer to Zerto Virtual Replication Zerto Cloud Manager Installation,
Configuration and Management.
When a resource pool is specified, Zerto Virtual Replication checks that the resource pool
capacity is enough for any virtual machines specified in the VPG. If a resource pool is
specified and DRS is disabled for the site later on, all the resource pools are removed by
VMware and recovery will be to any one of the hosts in the recovery site with a VRA installed
on it.
Note: All resource pool checks are made at the level of the VPG and does not take into account
multiple VPGs using the same resource pool. If the resource pool CPU resources are specified
as unlimited in the Edit Setting dialog for the resource pool, the actual limit is inherited from
the parent but if this inherited value is too small, failover move and failover test operations
can fail, even without a warning alert being issued by Zerto Virtual Manager.
VM Recovery Datastore The datastore where the VMware file for the virtual machine is
stored. If a cluster or resource pool is selected for the host, only datastores that are accessible
by every ESX/ESXi host in the cluster or resource pool are displayed. This is also the
datastore where RDM backing files for recovery volumes are located. When specifying the
recovery storage for a virtual machine with a storage cluster, you have to specify a datastore
in the cluster.
Recovery Folder The folder where the virtual machine is recovered to.
If default values were specified in the Manage VPG dialog, they are used for the virtual
machine configuration and are displayed in the Recovery Host, VM Recovery Datastore
and Recovery Folder fields. You can change these values for the specific virtual machine by
selecting new values from the drop-down lists.
Journal Size Hard Limit The maximum size that the journal can grow. You can specify the
value as unlimited or change the value to Custom in order to specify a maximum journal size,
either as a percentage of the virtual machine volume size or as a fixed maximum size.
Journal Size Warning Threshold The size of the journal that triggers a warning that the
journal is almost full. You can specify the value as automatically determined by Zerto Virtual
Replication or change the value to Custom in order to specify a threshold, either as a
percentage of the virtual machine volume size or as a fixed size.
In vSphere Client console you can reconfigure vApps by dragging virtual machines to or from the
vApp. In this case the Zerto Virtual Replication protection is updated automatically to recognize
the changes to the vApp.
Whenever a virtual machine is moved to or from a vApp, all the checkpoints are removed, since
the VPG configuration is essentially new. The replication of all the data of the virtual machines in
the vApp prior to the change is maintained.
Removing a virtual machine from the vApp results in that virtual machine no longer being
protected. However, protection of the remaining virtual machines continues uninterrupted.
Conversely, moving a virtual machine to the vApp causes that machine to be automatically added
to the VPG, with, wherever possible, the vApp default values set. The vApp VPG is updated and
synchronization begins for the added VM between the protected and recovery sites.
Note: If the default values cannot be set, for example the default recovery datastore does not have
enough room, then the VPG is saved with a status of Needs Configuration. To initiate protecting
the added virtual machine, you have to edit the VPG to define the datastore to use for the virtual
machine and the test and failover networks.
If the added virtual machine was protected, it is unprotected before being protected as part of the
vApp. If the added virtual machine was originally protected in a VPG containing other virtual
machines, the VPG is resynchronized after the virtual machine which is added to the vApp is
removed. If the added virtual machine was protected as the only virtual machine in the VPG, the
VPG is deleted.
You can modify a VPG via the Zerto tab for a virtual machine included in a VPG or from the VPGs
tab in the Zerto tab for the vCenter Server. You can modify the VPG properties as well as adding
virtual machines to the VPG, as described in Adding a Virtual Machine to an Existing VPG, on
page 114, deleting virtual machines from the VPG or changing the information about how virtual
machines are recovered, such as adding or removing volumes from the virtual machine.
After modifying the VPG, the definition is updated. While the VPG definition is being updated,
you cannot perform any operations on the VPG, such as adding a checkpoint, editing the VPG
properties or failing the VPG. After the definition is updated, the VPG is synchronized with the
recovery site and also during this time you cannot perform any task that requires the protected
and recovery sites to be synchronized together, such as adding a checkpoint or failing the VPG.
You can however make changes to the VPG definition, such as changing the history that is
maintained as long as the data requirements for the VPG or any of the virtual machines in the
VPG are not changed. If you change the datastore requirements for any of the virtual machines in
the VPG, the VPG definition is re-updated and the synchronization process is restarted.
Note: Synchronization after adding a removing a virtual machine volume for a virtual machine in
the VPG results in all checkpoints being removed and the checkpoint mechanism restarting after
synchronization completes.
To modify a VPG:
1. In the Zerto GUI, click the Edit icon for the VPG from the list of VPGs in the VPGs tab. You
can also select the VPG to display the VPG details and click Actions and then click Edit.
The Manage VPG dialog is displayed as a tab, enabling editing the VPG, including adding and
removing virtual machines from the VPG.
Note: If the VPG was previously viewed, and the tab for this VPG is still displayed, you can
access the details by selecting the tab.
2. Make any required changes to the VPG definition, as described in Configuring Virtual
Protection Groups, on page 26.
Note: If the default values, Host, Datastore, Failover Network, Test Network or
Folder are changed, the changed default values are not applied to existing virtual machines
but only to new virtual machines added to the VPG.
3. Click Save.
When a virtual machine is removed from a VPG, a warning is displayed when you remove the
virtual machine and another message is displayed when trying to save the VPG, whether to
save the recovery volumes or not, which can be used for preseeding, if the virtual machine is
added back to the VPG.
The VPG configuration is modified. The VPG is updated and then synchronized with the recovery
site, if required, for example when changing the host.
Note: Synchronization after deleting a virtual machine from a VPG results in all checkpoints
being removed and the checkpoint mechanism restarting after synchronization completes.
Adding or deleting volumes for a virtual machine protected in a VPG, are automatically reflected
in the volumes used for the mirror virtual machine, managed by the VRA in the recovery site.
Resizing non-RDM volumes of a virtual machine protected in a VPG are automatically reflected in
the volumes used for the mirror virtual machine, managed by the VRA in the recovery site.
Changing the defined size of a journal of a virtual machine in a VPG is automatically reflected in
the VRA in the recovery site.
Note: If the recovery site vCenter Server is version 4.0, the recovery site volumes are not resized
and the VPG state changes to Needs Configuration. If the source volume is associated with an
RDM as a target for replication, the RDM will need to be resized manually, as described in
Modifying a Source RDM Volume, below.
If a source RDM volume for a protected virtual machine is resized, it is not automatically resized
in the recovery site:
During periods when the WAN bandwidth is utilized to its maximum, you can pause the
protection of a VPG, to free-up some of this bandwidth. After pausing the protection, the VPG can
still be recovered, to the last checkpoint written to the journal before the pause operation.
Note: It is recommended to add a checkpoint to the VPG to pause, if you might want to recover the
VPG to the latest point in time before being paused.
Note: If the VPG was previously viewed, and the tab for this VPG is still displayed, you can
access the details by selecting the tab.
The VPG protection is paused until you click the Resume button.
2. Select the VPGs to pause and click Actions and then click Pause.
The Pause dialog is displayed.
2. Select which VPGs you want to resume protecting and click OK.
After resuming protection, a Bitmap Sync will most probably be performed to synchronize
the protection and recovery sites.
If the protected virtual machines are updated such that they are no longer synchronized with
their mirror machines in the recovery site, you can force the resynchronization of the machines.
An example of when the machines can be out-of-sync is when there is a rollback of a virtual
machine to a VMware snapshot. In this case, the recovery virtual machine will include changes
that have been rolled back in the protected machine, so that they are no longer synchronized.
You can force the synchronization of the machines in a VPG to remedy this type of situation.
Note: If the VPG was previously viewed, and the tab for this VPG is still displayed, you can
access the details by selecting the tab.
The VPG starts to synchronize with the recovery site. As the journal fills up during the
synchronization, older checkpoints are deleted from the journal to make room for the new data
and the data prior to these checkpoints are promoted to the virtual machine virtual disks. Thus,
during the synchronization, you can recover the virtual machine to any checkpoint still in the
journal, but as times progresses the list of checkpoints available can lessen. If the journal is not
big enough to complete the synchronization without leaving at least ten minutes worth of
checkpoints, the synchronization pauses for the time specified in the Replication Pause Time
value for the VPG, to enable intervention to ensure recovery to a checkpoint remains available.
The intervention can be, for example, increasing the size of the journal, or cloning the journal as
described in Deleting a VPG, below.
Deleting a VPG
You can delete a VPG via the Zerto tab for a virtual machine included in a VPG.
To delete a VPG:
1. In the Zerto GUI, access the VPGs or VMs tabs and select the VPG to display the VPG details.
2. Click Actions and then click Delete.
Note: If the VPG was previously viewed, and the tab for this VPG is still displayed, you can
access the details by selecting the tab.
The Delete dialog is displayed.
3. Check Keep target disks at the peer site if you might reprotect the virtual
machines. Checking this option means that the target replica disks for the virtual machines
are kept so that you can preseed to these disks so the synchronization is faster.
4. Click Next and then OK to delete the VPG.
The VPG configuration is deleted. The VRA on the recovery site that handles the replication
for the VPG is updated including keeping or removing the replicated data for the deleted
VPG, dependent on the Keep target disks at the peer site setting during the
deletion.
If, for whatever reason, the VPG cannot be deleted the VPG status changes to Pending Remove.
Attempting to delete the VPG a second time causes the following to be displayed:
Force Delete Forcibly delete the VPG. This option leaves the target disks, regardless of whether
they were wanted or not.
Cancel Cancel the delete operation.
Zerto Virtual Replication ensures crash consistency by writing checkpoints to the journal every
few seconds. You can also add checkpoints to identify key points to ensure application consistency
to this point if a disaster requiring failover occurs.
The crash consistent checkpoints are assured in terms of write order fidelity. For example, if write
A on any virtual machine in the VPG occurred before write B on any virtual machine in the VPG,
than any checkpoint will either contain:
Neither of the writes
Both writes, and if they overlap the B data takes precedence
Only A indicating the checkpoint occurred between A and B
The coordination is done by the Zerto Virtual Manager.
You can also integrate Microsoft Volume Shadow Copy Service (VSS) with Zerto Virtual
Replication to ensure application consistency.
This section describes the different options available to ensure application consistency:
Adding a Checkpoint to Identify a Key Point, below.
Ensuring Application Consistency With Microsoft Volume Shadow Copy Service (VSS), on
page 135.
You can also use a script to place the application in a quiesced mode, such as Oracle Hot Backup
mode, and execute the Zerto Virtual Replication PowerShell cmdlet Set-Checkpoint, then
release the quiesced mode. For more information about Zerto Virtual Replication PowerShell
Cmdlets, refer to Zerto Virtual Replication Cmdlets.
Note: In order to receive application consistent checkpoints, there is a performance impact on the
virtual machine itself, since the guest operating system and any integrated applications will be
quiesced. This performance impact may be negligible and is not always necessary since not all
applications require these enhanced checkpoints in order to achieve successful application
recovery. Also, Zerto Virtual Replication only requires the guest and application to quiesce for a
brief moment, just long enough to add a checkpoint.
Checkpoints are recorded automatically every few seconds in the journal. These checkpoints
ensure crash-consistency and are written to the virtual machine journals by the Zerto Virtual
Manager and each checkpoint has the same timestamp set by the Zerto Virtual Manager. During
recovery you pick one of these crash-consistent checkpoints in the journal and recover to this
point. In addition to these automatically generated checkpoints, you can manually add
checkpoints to identify events that might influence the recovery, such as a planned switch over to
a secondary generator. You can recover the machines in a VPG to any of the checkpoints in the
journal, either those added automatically or those added manually. Thus, recovery is done to a
point-in-time when the data integrity of the protected virtual machines is ensured.
Note: Changes to a VPG that result in re-synchronization of the VPG results in all checkpoints
being removed and restarted after synchronization completes. A forced synchronization of the
VPG only removes checkpoints if the journal fills up during the synchronization.
The list of VPGs is displayed with the requested VPG selected. You can select more VPGs to
add the same checkpoint to, for example, when there is a site occurrence for which you want
to add a checkpoint. You can also add the same checkpoint to VPGs on multiple sites by
selecting the site option for which you want to see the list of VPGs from which to select the
relevant VPGs: Local Site, Remote Site and Show All.
2. Enter a name for the checkpoint.
3. Click Save.
When testing a failover, as described in Testing Recovery, on page 181, or actually performing a
failover, as described in Managing Failover, on page 209, you can choose the checkpoint as the
point to recover to.
The checkpoints listed include checkpoints added via the ZertoVssAgent, as described in
Ensuring Application Consistency With Microsoft Volume Shadow Copy Service (VSS), below.
The Microsoft Volume Shadow Copy Service (VSS) enables taking manual or automatic backup
copies or snapshots of data, even if it has a lock, on a specific volume at a specific point-in-time
over regular intervals. This ensures not just that the data is crash consistent but also application
consistency if recovery is needed.
Zerto Virtual Replication enables adding checkpoints to the journal that are synchronized with
VSS snapshots.
To use Zerto Virtual Replication with VSS to ensure application consistency you must install the
ZertoVssAgent on every virtual machine that uses VSS and that you want to protect with Zerto
Virtual Replication. The ZertoVssAgent is available from Zerto Ltd. in both 32-bit and 64-bit
versions.
You can install the ZertoVssAgent on the following supported Windows operating systems:
32-Bit Operating Systems 64-Bit Operating Systems
Windows Server 2003 SP2 Windows Server 2003 SP2
Windows Server 2008, all versions (SPs and R2)
Windows Server 2012, all versions (SPs)
3. Specify the IP address and HTTP port number for the Zerto Virtual Managers managing the
protection of the virtual machines, both for the local site and optionally, for the paired, remote
site. If the same vCenter Server is used both for protecting and recovering virtual machines,
specify the IP address and HTTP port number for the single Zerto Virtual Manager installed.
Note: The default HTTP port number when Zerto Virtual Replication is installed is 9080.
If you enter a wrong IP address or port you can correct the address or port after the
installation completes by editing the ZertoVssAgentGUI.exe.conf file in the
ZertoVssAgent folder under the folder where the ZertoVssAgent is installed, for example,
C:\Program Files (x86)\Zerto.
4. Click OK.
The ZertoVssAgent is installed and the Add VSS Checkpoint is placed on the desktop.
You can add a checkpoint to the Zerto Virtual Replication via the Add VSS Checkpoint dialog,
via the command line or as a scheduled task. The ZertoVssAgent ensures that the virtual machine
is in an application consistent state and then sends the checkpoint to the Zerto Virtual Manager,
which then adds the checkpoint to the journals for the VPG containing that virtual machine.
The checkpoint is logged for the entire VPG, however any other virtual machine in the VPG will
have a crash-consistent checkpoint.
To add a checkpoint while ensuring application consistency via the Add VSS Checkpoint dialog:
1. On a virtual machine where the ZertoVssAgent has been installed, click Start > Programs >
Zerto Virtual Replication > Add VSS Checkpoint or double-click the Add VSS Checkpoint icon
on the desktop.
The Add VSS Checkpoint dialog is displayed.
To add a checkpoint while ensuring application consistency via the command line:
1. Open the command line dialog as an administrator.
2. Navigate to the directory where the ZertoVssAgent is installed. The default location is
C:\Program Files\Zerto\ZertoVssAgent\.
3. In the command line, run the following:
ZertoVssAgent.exe <localURL> <localPort> <remoteURL> <remotePort>
<checkpoint>
where:
localURL The URL for the Zerto Virtual Manager that manages the protected site.
localPort The HTTP port for the Zerto Virtual Manager that manages the protected site.
remoteURL The URL for the Zerto Virtual Manager that manages the recovery site.
remotePort The HTTP port for the Zerto Virtual Manager that manages the recovery site.
checkpoint The name of the checkpoint.
Note: A message that the process was completed is displayed on the machine where the
ZertoVssAgent has been installed. The handling of the checkpoint by the Zerto Virtual Manager is
done asynchronously and you can check via the recent tasks list in the Zerto GUI that the
checkpoint is added in the VPG.
To schedule checkpoints:
1. Open the Task Scheduler.
2. Under the Actions menu item, select Create Task.
The Create Task dialog is displayed.
5. Select the Actions tab and create a new action to start the ZertoVssAgent with the IP address
and port of the Zerto Virtual Manager and the checkpoint to use. For example:
C:\Program Files\Zerto\ZertoVssAgent\ZertoVssAgent.exe and
172.18.206.10:9080 172.18.206.10 9080 VSSTaskCP
6. Click OK.
7. Select the Settings tab and make changes as required. Make sure Stop the task if it
runs longer than is not selected.
8. Click OK.
There are certain permissions required for the windows scheduled task to execute successfully.
For example, you may see the following in the event logs:
Volume Shadow Copy Service error: Unexpected error querying for the
IVssWriterCallback interface. hr = 0x80070005
This is often caused by incorrect security settings in either the writer or requestor process.
If this is the case, the service which runs the Windows Scheduled Task must have NT
AUTHORITY\Network Service permissions or be using the SYSTEM account to run the task. VSS
operations are performed as NT AUTHORITY\Network Service which is not granted COM
access by default on the service assigned to Windows Scheduled Tasks.
The following procedure is only required if the windows scheduled task is using the Network
Services account.
The correct permissions can be assigned by using the Component Services application,
accessed by running dcomcnfg.exe, in the windows guest.
To set COM permissions for VSS when Access Denied Errors are received:
1. Run dcomcnfg.exe.
The Component Services dialog is displayed.
2. Expand the Component Services node to My Computer and right-click to access the
Properties menu.
The My Computer Properties dialog is displayed.
3. Select the COM Security tab and click Edit Limits under Access Permissions.
4. Add the NETWORK SERVICE local access.
5. Click OK and verify that the user is now in the Access Permission list.
During recovery you can recover to the VSS checkpoint, ensuring both application consistency
and that the data is crash consistent for this virtual machine. For details, refer to To test
failover:, on page 183 and To initiate a failover:, on page 211.
Before and after executing a failover, move or test failover, you can run executable scripts, such as
Windows bat files or PowerShell scripts. The scripts that run after a failover, move or test
failover, run after all the virtual machines have been powered on at the recovery site.
By specifying the %ZertoOperation% environment variable for a script, you can also run the
script in the middle of the move or failover operation, before the move is committed or rolled back.
The %ZertoOperation% is described below.
The scripts must be saved to the machine where the remote Zerto Virtual Manager is installed.
Note: It is recommended to duplicate scripts on the Zerto Virtual Managers for both the protected
and recovery sites, so that if reverse replication is required, the scripts are available. The location
of the script for reverse replication, on the machine where the Zerto Virtual Manager which
manages the protected site is installed, must be to the same path as in the remote Zerto Virtual
Manager machine. For example, if the scripts are saved to C:\ZertScripts on the remote Zerto
Virtual Manager machine, they must be saved to C:\ZertScripts on the local Zerto Virtual
Manager machine.
The scripts can include environment variables which can be included as part of the script itself, or
passed to the script as parameters. When the script is passed an environment variable as a
parameter, the variable is evaluated before executing the script. The following environment
variables are available:
%ZertoVPGName% The name of the VPG. If the name includes a space, enclose the variable in
double quotes (). For example, the VPG MyVPG uses the format %ZertoVPGName% but the VPG
My VPG uses the format %ZertoVPGName%.
%ZertoOperation% The operation being run: Failover, FailoverBeforeCommit,
FailoverRollback, Test, Move, MoveBeforeCommit, MoveRollback. Use this variable to
limit when the script runs, dependent on the operation. Use FailoverBeforeCommit or
MoveBeforeCommit to set up virtual machines in the recovery production environment just prior
to testing them before committing the operation. The recovery virtual machines are fully up at
this point and connected to the failover/move network. Use FailoverRollback or
MoveRollback when rolling back the Failover or Move operation, to undo whatever changes a
previous script has done (such as updates to the DNS records).
%ZertoVCenterIP% The IP address of the vCenter Server where the VPG is recovered.
%ZertoVCenterPort% The port used by the Zerto Virtual Manager to communicate with the
vCenter Server the default is 443.
%ZertoForce% A Boolean value, Yes/No, that dictates whether to abort the recovery operation
if the script fails. For example, whether to rollback a Move operation when the script fails and
returns a non-zero value.
For example, if a specific VPG should not be migrated, the pre-recovery script can determine
whether to continue based on the values of the %ZertoOperation% and %ZertoVPGName%.
When specifying scripts in the definition of a VPG, expand the recovery scripts to display the
script fields and enter values for the Pre-recovery Script and Post-recovery Script:
Command to run The name of the script to run, including the full path. The script must be
located on the same machine as the Zerto Virtual Manager for the recovery site.
Params The values of any parameters to pass to the script. Separate parameters with a
space.
Timeout (sec) The time out in seconds for the script to run. If the script runs before executing
a failover, move or test failover and the script fails or a timeout value is reached, an alert is
generated and the failover, move or test failover is not performed. If the script runs after
executing a failover, move or test failover and the timeout value is reached, an alert is
generated. The default timeout value is specified in the Site Configuration Advanced
Settings dialog.
Creating a Script
There are many ways to create scripts to run before or after a recovering a VPG. The following
procedure uses a Windows PowerShell file (.ps1) or a batch (.bat) file.
To create a script:
1. Create a file on the machine where the Zerto Virtual Manager that manages the recovery is
installed.
2. Enter the script that you want to run in the file.
3. Save the file as a Windows PowerShell file (.ps1) or batch (.bat) file.
When writing a PowerShell script, you can include the environment variables in the script.
For example, the following code snippet shows the use of the %ZertoOperation%
environment variable:
$Operation = "%ZertoOperation%"
If ($Operation -eq "FailoverBeforeCommit" -or "MoveBeforeCommit")
{ desired code here }
else { alternative code here }
4. Update Command to run and Params fields for all the VPG definitions that you want to run
the script.
Note: It is recommended to test both a PowerShell and Batch script by running it from the
command line, to ensure it runs correctly. Note that passing parameters is implemented
differently for the two script types. For information about passing command line parameters,
refer to the relevant PowerShell or Batch file documentation.
Example Scripts
The following scripts are examples of how to provide scripts to use with Zerto Virtual Replication:
Example 1 Recording Failover Tests, below.
Example 2 Moving Virtual Machines to a Resource Pool After a Failover, on page 146.
Example 3 Replace DNS A and PTR Records, on page 148.
Where %1 is the first parameter in the list of parameters, %ZertoOperation%, and %2 is the
second parameter in the list of parameters, %ZertoVPGName%.
Note: If the file ListOfTestedVPGs.txt does not exist it is created, as long as the folder,
c:\ZertoScripts\Results, exists.
Update Command to run and Params fields for all the VPG definitions that you want to run the
script.
Command to run c:\ZertoScripts\TestedVPGs.bat
Params %ZertoOperation% %ZertoVPGName%
Whenever a failover test is run on the relevant VPGs the TestedVPGs.txt file is updated with
the name of the VPG and the date and time the test was run.
##Variables:
##vCenter IP address
$strVCenterIP = "10.10.10.10"
##vCenter user account to use; account must have the ability to move the
desired machines
$strVCUser = "Administrator"
##vcenter user password
$strVCPw = "password"
##Array of VMs to move - this list should include ALL virtual machines in
the VPG and is case sensitive.
$strVMtoMove = @("VM-1", "VM-2", "VM-3")
##End of script
The script must be in the same folder, C:\ZertoScripts\, on both the local and remote Zerto
Virtual Managers and this is the folder is the folder specified for the variable $FP in the script.
Update Command to run and Params fields for all the VPG definitions that you want to run the
script.
Command to run CMD:powershell.exe
Params C:\ZertoScripts\DNS-Change.ps1
You can save the VPG definitions to an external file and import these definitions back to Zerto
Virtual Replication, for example exporting the settings before uninstalling a version of Zerto
Virtual Replication and importing the settings after reinstalling Zerto Virtual Replication.
2. Select the Export Protection Group Settings option and click Next.
3. Select the destination for the file to contain exported settings and specify the Zerto Virtual
Manager IP address and port where the VPGs are protecting virtual machines.
4. Click Next.
The list of exported VPGs is displayed.
5. Click Done.
Note: If you are uninstalling Zerto Virtual Replication, the VPGs are deleted. To prevent having to
perform a full synchronization when the VPG definitions are imported, it is recommended to
delete the VPGs in the Zerto GUI, keeping their target disks.
4. Select the file previously exported and enter the Zerto Virtual Manager IP address and port
specified when exporting the VPGs.
5. Click Next.
The list of exported VPGs is displayed.
6. Select the VPGs to import. Only VPGs with names that are not already defined can be
imported. VPGs in the import files with the same name as an existing VPG are displayed in
the list disabled.
7. Click Next.
The list of imported VPGs is displayed. If the VPG could not be imported the reason for the
failure is specified.
8. Click Done.
During normal operations the VPG status can change, dependent on circumstances. For example,
if a change is made to the VPG definition, or an operation such as move or failover is performed on
the VPG or an external event impacts the protection such as the WAN going down. When the
status changes, resulting in the VPG being synchronized, for example with a Delta Sync, the
estimated time to complete the synchronization is displayed under the VPG status, and if
relevant, the synchronization trigger, such as Network Congestion.
VPG Statuses
Delta Synca The Delta Sync uses a checksum comparison to minimize the use of
network resources. A Delta Sync is used when the protected virtual
machine disks and the recovery disks should already be synchronized,
except for a possible few changes to the protected disks, for example,
when the target recovery disk is defined as a preseeded disk or after a
VRA upgrade, or for reverse protection after a move or failover.
During the synchronization, new checkpoints are not added to the
journal. Also, recovery operations are not possible during a Delta
Sync.
Note: For the synchronization to work, the protected virtual machines
must be powered on. The VRA requires an active IO stack to access the
virtual machine data to be synchronized across the sites. If the virtual
machine is not powered on, there is no IO stack to use to access the
source data to replicate to the target recovery disks.
Disconnected From Peer Communication with the Zerto Virtual Manager at the remote,
recovery, site is down so continuing protection is halted (compare with
Recovery Possible, below).
Disconnected From Peer Communication with the Zerto Virtual Manager at the remote,
No Recovery Points recovery, site is down and there are no checkpoints to use to recover the
VPG at the recovery site.
Status Description
Empty Protection Group A configured VPG where the virtual machines have been removed from
it.
Error Problem situation, for example, when a ZVM is disconnected from a
VRA used to protect virtual machines. The VPG cannot be recovered
until the problem is resolved,
Failing Over Failing over the VPG.
Full Synca Full synchronization to ensure that the protected disks and recovery
disks are the same after some change to the system. This type of sync is
the same as an Initial Sync but occurs after protection started. In
general, this type of sync should not happen.
During the synchronization, new checkpoints are not added to the
journal. Also, recovery operations are not possible during a Full Sync.
Note: For the synchronization to work, the protected virtual machines
must be powered on. The VRA requires an active IO stack to access the
virtual machine data to be synchronized across the sites. If the virtual
machine is not powered on, there is no IO stack to use to access the
source data to replicate to the target recovery disks.
Initial Synca Synchronization performed after creating the VPG to ensure that the
protected disks and recovery disks are the same. Recovery operations
cannot occur until after the initial synchronization has completed.
Adding a virtual machine to a VPG is equivalent to creating a new VPG
and an initial synchronization is performed. In this case, any
checkpoints in the journal become unusable and only new checkpoints
added after the initial synchronization completes can be used in a
recovery. The data in the journal however remains and is promoted to
the recovered virtual machine as part of a recovery procedure.
Note: For the synchronization to work, the protected virtual machines
must be powered on. The VRA requires an active IO stack to access the
virtual machine data to be synchronized across the sites. If the virtual
machine is not powered on, there is no IO stack to use to access the
source data to replicate to the target recovery disks.
Move: Before Commit Preparing the VPG virtual machines in the recovery site.
Move: Committing Completing the move, including removing the source virtual machines.
Move: Rolling Back Rolling back a Move operation before committing it.
Needs Configuration One or more configuration settings are missing, for example, when
reverse protection is not specified or a virtual machine is added to a
vApp.
Status Description
Pending Remove An attempt to remove the VPG failed and it must be forcibly removed.
For details, see Deleting a VPG When the Status is Pending Remove,
on page 132.
Promoting Updating the recovery machines in the VPG with data from the journal.
Protecting Virtual machines in the VPG are protected.
Protecting, Bitmap Synca Synchronization after WAN failure or when the load over the WAN is
too great for the WAN to handle, in which case the VPGs with the lower
priorities will be the first to enter a Bitmap Sync. A Bitmap Sync can
also occur when there is storage congestion at the recovery site, for
example when the VRA at the recovery site cannot handle all the writes
received from the protected site in a timely fashion. In these situations,
Zerto Virtual Replication starts to maintain a smart bitmap in memory,
in which it tracks and records the storage areas that changed. Since the
bitmap is kept in memory, Zerto Virtual Replication does not require
any LUN or volume per VPG at the source side. The bitmap is small
and scales dynamically, containing references to the areas of the source
disk that have changed but not the actual I/O. The bitmap is stored
locally on the VRA within the available resources. For example, when a
VRA goes down and is then rebooted. On WAN failure Zerto Virtual
Replication starts to maintain a smart bitmap in memory, to track and
record storage areas that change. On WAN reconnection, the bitmap is
used to check updates to the source disks and send any updates to the
recovery site.
During the synchronization, new checkpoints are not added to the
journal. Recovery operations are still possible, unless the
synchronization takes longer than the configured history. For the
resolution of this situation, see Defining the Replication Pause Time,
on page 90.
If a disaster occurs requiring a failover during a bitmap
synchronization, the VPG status changes to Recovery Possible and
you can recover to the last checkpoint written to the journal.
Note: For the synchronization to work, the protected virtual machines
must be powered on. The VRA requires an active IO stack to access the
virtual machine data to be synchronized across the sites. If the virtual
machine is not powered on, there is no IO stack to use to access the
source data to replicate to the target recovery disks.
Recovery Possible Communication with the Zerto Virtual Manager at the protected site is
down so continuing protection is halted, but recovery on the remote site
is available (compare with Disconnected From Peer).
Status Description
Removing Deleting the VPG.
Replication Paused Replication paused to enable solving a Journal disk space problem, for
example, by increasing the disk size or cloning the VPG.
Rolling Back Rolling back to an initial status, for example, after cancelling a cloning
operation on the VPG.
Starting Failover Test Preparing to start a failover test for the VPG.
Sync Status while type of synchronization is being evaluated.
Test Failover test of the VPG.
Updating Changing the VPG definition.
Volume Delta Synca Synchronization when only delta changes for a volume needs
synchronizing, for example, when a virtual machine is added to a VPG
using a preseeded disk.
During the synchronization, new checkpoints are not added to the
journal. Also, recovery operations are not possible during a Volume
Delta Sync.
Note: For the synchronization to work, the protected virtual machines
must be powered on. The VRA requires an active IO stack to access the
virtual machine data to be synchronized across the sites. If the virtual
machine is not powered on, there is no IO stack to use to access the
source data to replicate to the target recovery disks.
Volume Full Synca Synchronization when a full synchronization is required on a single
volume.
During the synchronization, new checkpoints are not added to the
journal. Also, recovery operations are not possible during a Volume
Full Sync.
Note: For the synchronization to work, the protected virtual machines
must be powered on. The VRA requires an active IO stack to access the
virtual machine data to be synchronized across the sites. If the virtual
machine is not powered on, there is no IO stack to use to access the
source data to replicate to the target recovery disks.
Status Description
Volume Initial Synca Synchronization when a full synchronization is required on a single
volume, for example, when changing the target datastore or adding a
virtual machine to the VPG without using a preseeded disk.
During the synchronization, new checkpoints are not added to the
journal. Also, recovery operations are not possible during a Volume
Initial Sync.
Note: For the synchronization to work, the protected virtual machines
must be powered on. The VRA requires an active IO stack to access the
virtual machine data to be synchronized across the sites. If the virtual
machine is not powered on, there is no IO stack to use to access the
source data to replicate to the target recovery disks.
a. Synchronization after a recovery starts after the promotion of data from the journal to the virtual machine disks ends. Thus,
synchronization of virtual machines can start at different times, dependent on when the promotion for the virtual machine ends.
All synchronizations are done in parallel, whether a delta sync or full sync, etc.
Trigger Description
Recovery VRA A network error, such as the network being down for a period, requires
Communication Problem a synchronization of the VPG between the two sites, for example a
Bitmap Sync.
VPG Configuration The configuration of the VPG changed resulting in a synchronization
Changed being required. For example, the size of the journal was changed.
When access to a recovery datastore is not available, for example, during maintenance of the
datastore, you have to change the datastore in all affected VPGs to enable protection to continue.
Note: Changing the datastore directly in the Configure VM dialog or if the datastore used for the
journal is not set to Default in the Manage Journal dialog, causes the VPG to undergo an
initial synchronization.
During the following procedures the journal used for recovery is reset and until the VPG returns
to a protecting state, recovery is not possible.
To enable protection to continue when a virtual machine recovery datastore will be unavailable:
1. Remove all virtual machines from the VPG definitions that use the unavailable datastore as
the recovery datastore, as specified in the Configure VM dialog from the VPG, keeping the
recovery volumes.
2. Click No.
Note: A VPG must always have at least one virtual machine defined and therefore you cannot
remove all the virtual machines from a VPG at once. If all the VPGs use a datastore that
requires maintenance, remove all but one of the virtual machines and after completing this
procedure, adding the virtual machines back to the VPG, repeat the procedure with the last
virtual machine.
3. Change the default recovery datastore in the VPG definition to a new default datastore, if it
was set to the unavailable datastore.
4. Move the saved volumes to the default datastore.
5. Add the virtual machine back to the VPG, and configure the virtual machine volumes to use
the saved volumes as preseeded volumes accessed from the Configure VM dialog.
6. Click Save to save the virtual machine configuration and then the VPG.
The VPG will undergo a Delta Sync before returning to a Protecting status.
There are a number of tasks that you might need to perform on VRAs, including installing a new
VRA on a host added to the vCenter Server or uninstalling VRAs and moving the data maintained
by a VRA to another VRA when an ESX/ESXi host requires VMware maintenance.
During normal operation, a VRA might require more disks than a single virtual machine can
support. If this situation arises, the VRA creates new shadow VRA virtual machines, used by the
VRA to maintain additional disks. These virtual machines must not be removed. A VRA can
manage a maximum of 500 volumes, whether these are volumes being protected or recovered.
Note: VRAs and shadow VRAs are configured and managed by the Zerto Virtual Manager. You
cannot take snapshots of VRAs as snapshots cause operational problems for the VRAs.
The following VRA management options are described in this chapter:
Installing a VRA, below
Upgrading VRAs, on page 160.
Editing VRA Settings, on page 161.
Resetting the Host Passwords Required By More Than One VRA, on page 162.
Changing a Recovery VRA For Virtual Machines, on page 163.
Uninstalling VRAs, on page 165.
Handling a Ghost VRA, on page 166.
Managing Protection During VMware Host Maintenance, on page 168.
Managing Protection When Moving a Host to a Different Cluster, on page 169.
Installing a VRA
It is recommended to install a VRA on every ESX/ESXi host in every site so that if protected
virtual machines are moved from one host in the cluster to another host in the cluster there is
always a VRA to protect the moved virtual machines.
If a new host is added to a site, or a VRA is for any reason removed and a new VRA needs to be
installed, add the VRA as described in Zerto Virtual Replication Zerto Virtual Manager
Installation and Configuration.
159
Upgrading VRAs
Upgrading VRAs
When upgrading Zerto Virtual Replication, the VRAs that were installed in the previous version
are not upgraded automatically and can be upgraded via the Manage VRAs dialog. Zerto Virtual
Replication enables VRAs installed with the previous version of Zerto Virtual Replication to work
with VRAs installed with the current version of Zerto Virtual Replication in any combination of
VRAs (all from one version or a mix of VRA versions) as long as the VRAs are only one update
higher or lower than the version of Zerto Virtual Replication installed on this site. It is
recommended to upgrade the VRAs to be consistent with the latest version and this can be done in
the Manage VRAs dialog.
After upgrading Zerto Virtual Replication, the VRAs might also require an upgrade. You can see
if an upgrade is available in the VRAs tab, in the VRA Version column.
Note: An alert is also issued both on the site with the old VRA installed and on any paired site
with this site.
Move the mouse over the Outdated value to display the VRA version as a tooltip.
Considerations when upgrading VRAs:
VRAs managing protected virtual machines: Either vMotion the protected virtual machines
and datastores managed by the VRA to another host with a VRA, or upgrade the VRA without
vMotioning the virtual machines and a Delta Sync will be performed following the upgrade.
Upgrading a VRA that manages the recovery of virtual machines results in a Bitmap Sync
being performed after the upgrade. Note that the time to upgrade a VRA is short so the
Bitmap Sync should also be quick.
To upgrade VRAs:
1. For a VRA protecting virtual machines and vMotioning the protected virtual machines:
Remove affinity rules for protected virtual machines on the host with the VRA to be upgraded
and vMotion these protected machines from the host to another host with a VRA.
2. In the Zerto GUI, either select the VRAs to upgrade in the VRAs tab or for a single VRA
display the VRA details by clicking the VRA Name link in the VRAs tab, and click Actions and
then click Upgrade.
The Upgrade VRAs dialog is displayed, listing the selected VRAs and whether an upgrade is
available.
3. Review the list and deselect any VRAs that you decide not to upgrade.
4. Click Upgrade Selected VRAs.
The upgrade progress is displayed in the VRAs tab.
A Delta Sync, for VRAs protecting virtual machines, or a Bitmap Sync, for VRAs managing
recovery, is performed following the upgrade.
Note: The VRA name does not change, even if the naming convention in the latest version is
different.
If you need to change the host password, VRA Group or network settings for a VRA, for example
when the gateway to the VRA is changed, you can do this by editing the VRA.
VRAs installed on ESXi 4.x and 5.x hosts require a password to access the host. This password is
supplied as part of the installation of each VRA. The password is required for situations such as
rebooting or upgrading the host. If the password for a host is changed you can change the
password stored by the VRA by editing the VRA, either for a specific VRA, or when multiple hosts
have their passwords changed, each with the same password, you can update the password
information for the affected VRAs.
The Zerto Virtual Manager checks the password is valid once a day. If the password was changed,
an alert is triggered, requesting the user enter the new password.
In some circumstances you need to stop using a VRA for recovery, for example when the ESX/
ESXi hosting the VRA needs to be upgraded. When this happens, in order to continue protecting
virtual machines that are being protected to this VRA, you need to change this VRA so that the
virtual machines are being protected to another VRA.
Note: The datastores used by the original VRA and the changed VRA must be accessible by both
the original target host and by the changed target host.
The Change Target Host dialog is displayed, listing all the virtual machines that require a
change to the recovery host.
2. Review the list and select the virtual machines to change the target host to another specified
target host.
3. Select the target host for these virtual machines in the Select the replacement host
drop-down list. You can move some virtual machines to one replacement target host and by
repeating the operation, move other virtual machines to a different target host.
Validation is performed to make sure the selected target host can be used, for example the
datastores used by both the VRAs are accessible from both hosts.
Any implications of the change, such as whether synchronization might be required after the
change is also displayed.
4. Click OK.
5. Repeat this procedure from step 2 for all the virtual machines.
The VPG target host definitions are changed and the affected target data transferred to the
changed VRAs. During the change procedure you cannot edit the affected VPGs nor attempt a
failover, move, failover test or clone operation.
Uninstalling VRAs
VRAs are uninstalled via the Zerto GUI and not via the vCenter Server GUI. You cannot
uninstall a VRA which is used to protect or recover virtual machines.
For a VRA protecting virtual machines Before uninstallng the VRA, remove affinity rules for
protected virtual machines on the host and vMotion these protected virtual machines to another
host in the cluster with a VRA installed.
For a VRA recovering virtual machines Before uninstallng the VRA, change the host for all virtual
machines in VPGs recovering to this VRA to another host as described in Changing a Recovery
VRA For Virtual Machines, on page 163. A Bitmap Sync occurs to synchronize the VPGs with
the new host.
Note: If the VRA has crashed, or was accidently deleted, it must be forcibly uninstalled, as
described in Handling a Ghost VRA, on page 166.
For a VRA in a cluster, you can remove it and then install a new VRA. However, to ensure that
virtual machines in the cluster are not moved to the host without a VRA from the time the VRA is
removed to the time a new VRA is installed, it is recommended to perform the following
procedure.
When an event occurs, for example the host machine crashes or the VRA or a shadow VRA is
accidentally deleted, if the VRA has shared storage disks that are accessible by other hosts in the
site, you can copy these disks to another VRA in the site.
Note: If the host crashes, you must remove it from the inventory before recovering the VRA.
The VRA is represented in the Manage VRAs dialog as a ghost VRA and you restore access to the
disks using VRA maintenance.
Select the target host for maintenance from the Target for Original Maintenance
Host dropdown box and click OK.
The VRA recovery data is transferred to the selected host, however after the transfer
completes the VRA maintenance status does not change.
3. For the ghost VRA, click Actions and then click Uninstall.
Reinstall a VRA on this host, as described in Zerto Virtual Replication Zerto Virtual Manager
Installation and Configuration.
When a host machine requires VMware maintenance, at least for the duration of the
maintenance, to ensure continuous protection:
For a host machine on the protected site Remove affinity rules for protected virtual machines on
the host that requires maintenance and vMotion these machines to any other host with a VRA
installed. Shut down the VRA before starting the host maintenance. After the host maintenance
power on the VRA.
For a host machine on the recovery site VRA data and recovery volumes maintained by the VRA on
the host should be moved to another machine, by changing the destination host for all the virtual
machines being recovered to that host, as described in Changing a Recovery VRA For Virtual
Machines, on page 163. Shut down the VRA before starting the host maintenance. After the host
maintenance power on the VRA.
Note: Changing the VPG default host does not change the hosts for virtual machines already
included in the VPG. These virtual machine hosts must be changed directly by configuring the
individual virtual machines in the VPG definition.
To enable VMware host maintenance for a VRA both protecting and recovering virtual machines:
1. Remove affinity rules for protected virtual machines on the host that requires maintenance
and vMotion these machines to any other host with a VRA installed.
2. Change the host for all virtual machines in VPGs recovering to this VRA to another host as
described in Changing a Recovery VRA For Virtual Machines, on page 163.
3. Wait for any synchronization to complete.
4. Shutdown the VRA on the host manually in order to enable the host to enter VMware
Maintenance.
5. Enter VMware Maintenance for the host.
Note: Do not migrate powered-off virtual machines, if prompted to.
6. Remove the host from the cluster: Place it under the datacenter entity rather than the cluster
entity.
7. Perform required maintenance, for example, upgrading the host.
8. Exit VMware maintenance mode.
9. Power on the VRA.
10. Wait for the Zerto Virtual Manager to connect to the local VRAs. You can monitor the alerts to
determine when the connections have been established.
11. Add the host back in to the cluster.
The Zerto Virtual Manager runs as a Windows service and connects to both Zerto Virtual
Replication components, such as VRAs as well as VMware components such as the vCenter
Server and the vSphere Client console.
The following topics are described in this chapter:
Check Connectivity Between Zerto Virtual Replication Components, below
Reconfiguring the Zerto Virtual Manager Setup, on page 172.
Replacing the SSL Certificate, on page 174.
If you think that there are connectivity problems to or from a Zerto Virtual Manager, you can use
the Zerto diagnostics utility to check the connectivity.
170
Check Connectivity Between Zerto Virtual Replication Components
The Client options tests the client on completion a result dialog is displayed.
6. Click Stop (server test) or OK (client test) to return to the Zerto Virtual Replication
Diagnostics dialog.
When installing Zerto Virtual Replication, you provide the IP addresses of the vCenter Server to
connect the Zerto Virtual Manager with and the IP address of the machine where the Zerto
Virtual Manager runs to enable running the Zerto GUI.
You can change these IP addresses if necessary, using the Zerto Virtual Replication Diagnostics
utility.
2. Select the Reconfigure Zerto Virtual Manager option and click Next.
The installation settings for the connection to the vCenter Server are displayed. Change the
IP and username and password if necessary.
IP / Host Name The IP address or host name of the machine where the vCenter Server runs.
User Name The user name for an administrator to the vCenter Server. The name can be
entered using either of the following formats:
username
domain\username
Password A valid password for the given user name.
3. Click Next.
The dialog for Zerto Virtual Manager setup is displayed:
IP for use by vSphere Client The IP to access the Zerto Virtual Manager from the Zerto GUI. If
the machine has more than one NIC, select the appropriate IP from the list, otherwise the IP
that is displayed is the only option.
HTTP Port (ZVMApi) The port used for inbound communication between the Zerto Virtual
Manager and Zerto internal APIs, external Zerto PowerShell Cmdlets and a VSS Agent.
HTTPS Port (vSphere client<->ZVM) The port used for inbound communication between the
Zerto GUI and the Zerto Virtual Manager.
TCP Port (ZVM<->ZVM) The port used for communication between Zerto Virtual Managers. If
you change the value, when pairing sites, use the TCP port value specified here.
HTTP Certificate Check Replace SSL Certificate and browse for a certificate, if you
change the certificate you have been using.
4. Click Next.
The connectivity is checked.
Note: If one of the tasks fails, click the link for information about why it failed. Usually it is a
mistake when entering an IP address.
5. Click Next.
The Zerto Virtual Manager is reconfigured.
6. Click Finish.
If you changed the IP address of the Zerto Virtual Manager or the TCP port it uses to
communicate with paired Zerto Virtual Managers on other sites, you have to unpair these sites,
both from this site and from the remote sites and then pair the sites again.
The communication between the Zerto Virtual Manager and the user interface uses HTTPS. On
the first login to user interface, via the Zerto DR Management UI, vSphere Client console, or
vSphere Web Client, you have to install a security certificate in order to be able to continue
working without each login requiring acceptance of the security.
If you want to replace the SSL certificate, perform the procedure described in To reconfigure
the Zerto Virtual Manager:, on page 172 and select a new SSL certificate when the dialog for
Zerto Virtual Manager setup is displayed:
HTTP Certificate Check Replace SSL Certificate and browse for a replacement
certificate.
Zerto Virtual Replication provides a number of operations to recover virtual machines at the
remote site. This chapter describes these procedures. The following topics are described in this
chapter:
The Move Operation, below
The Failover Operation, on page 177
The Failover Test Operation, on page 178
The Clone Operation, on page 179
Use the Move operation to transfer protected virtual machines from the protected (source) site to
the recovery (target) site in a planned migration.
When you perform a planned migration of the virtual machines to the recovery site, Zerto Virtual
Replication assumes that both sites are healthy and that you planned to relocate the virtual
machines in an orderly fashion. For details, see Migrating a Protection Group to the Recovery
Site, on page 196.
176
The Failover Operation
The following diagram shows the positioning of the virtual machines before and after the
completion of a Move operation.
Note: The Move operation without reverse protection does not remove the VPG definition but
leaves it in a Needs Configuration state.
Use the Failover operation following a disaster to recover protected virtual machines to the
recovery site. A failover assumes that connectivity between the sites might be down, and thus the
source virtual machines and disks are not removed, as they are in a planned Move operation.
When you set up a failover you always specify a checkpoint to which you want to recover the
virtual machines. When you select a checkpoint either the last auto-generated checkpoint, an
earlier checkpoint, or a user-defined checkpoint Zerto Virtual Replication makes sure that
virtual machines at the remote site are recovered to this specified point-in-time. For details, see
Managing Failover, on page 209.
Note: To identify the checkpoint to use, you can perform a number of test failovers, each to a
different checkpoint.
with the disks in the source site. Once the VPG is in a protecting state the virtual machines can
be moved back to the source site. For details, see Migrating a Protection Group to the Recovery
Site, on page 196.
The following diagram shows the positioning of the virtual machines before and after the
completion of a Failover operation.
Note: The Failover operation without reverse protection does not remove the VPG definition but
leaves it in a Needs Configuration state.
Use the Failover Test operation to test that during recovery the virtual machines are correctly
replicated at the recovery site.
The Failover Test operation creates test virtual machines in a sandbox, using the test network
specified in the VPG definition as opposed to a production network, to a specified point-in-time,
using the virtual disks managed by the VRA. All testing is written to scratch volumes. The longer
the test period the more scratch volumes are used, until the maximum size is reached, at which
point no more testing can be done. The maximum size of all the scratch volumes is determined by
the journal size hard limit and cannot be changed. The scratch volumes reside on the same
datastore defined for the journal. Using scratch volumes makes cleaning up the test failover more
efficient. For details, see Testing Recovery, on page 181.
During the test, any changes to the protected virtual machines at the protected site are sent to
the recovery site and new checkpoints continue to be generated, since replication of the protected
machines continues throughout the test. You can also add your own checkpoints during the test
period.
The following diagram shows the positioning of the virtual machines before and during a Failover
test operation.
Use the Clone operation to create a copy of the VPG virtual machines on the recovery site in the
production network. The virtual machines on the protected site remain protected and live.
You might want to create a clone if you need to have a copy of the virtual machines saved to a
specific point-in-time, for example, when the VPG enters a Replication Paused state, or when
testing the VPG in a live DR test. For details, see Cloning a Protection Group to the Recovery
Site, on page 204.
The cloned machines are named the source machine with the timestamp of the checkpoint used
for the clone. The cloned virtual machines are not powered on.
The following diagram shows the positioning of the virtual machines before and after the
completion of a Clone operation.
In order to verify that the disaster recovery that you have planned is the one being implemented,
it is recommended to regularly test the recovery of the VPGs defined in the protected site, to the
recovery site. This chapter describes how to test VPG recovery.
The following topics are described in this chapter:
The Test Failover Process, below.
Starting and Stopping Failover Tests, on page 182.
Viewing Test Results, on page 188.
Live Disaster Recovery Testing, on page 189.
Use the Failover Test operation to test that during recovery the virtual machines are correctly
replicated at the recovery site.
The Failover Test operation creates test virtual machines in a sandbox, using the test network
specified in the VPG definition as opposed to a production network, to a specified point-in-time,
using the virtual disks managed by the VRA. All testing is written to scratch volumes. The longer
the test period the more scratch volumes are used, until the maximum size is reached, at which
point no more testing can be done. The maximum size of all the scratch volumes is determined by
the journal size hard limit and cannot be changed. The scratch volumes reside on the same
datastore defined for the journal.
During the test, any changes to the protected virtual machines at the protected site are sent to
the recovery site and new checkpoints continue to be generated, since replication of the protected
machines continues throughout the test. You can also add your own checkpoints during the test
period. You can initiate a failover during a test, as described in Initiating a Failover During a
Test, on page 222.
The Failover Test operation has the following basic steps:
1. Start the test.
a) Create the test virtual machines at the remote site using the network specified for testing
in the VPG settings and configured to the checkpoint specified for the recovery.
181
Starting and Stopping Failover Tests
b) Power on the virtual machines making them available to the user. If applicable, use the
boot order defined in the VPG to power on the machines.
2. Stop the test.
a) Power off the test virtual machines and remove them from the inventory.
b) Add the following tag to the checkpoint specified for the test:
Tested at startDateAndTimeOfTest(OriginalCheckpoint_DateAndTime).
Note: The updated checkpoint can be used to identify the point-in-time to restore the virtual
machines in the VPG during a failover.
Testing that recovery is accomplished successfully should be done periodically so that you can
verify that a failover will work if required. It is also recommended to test all the VPGs being
recovered to the same cluster to be tested together. For example, in a cluster if the HA
configuration includes admission control to prevent virtual machines being started if they violate
availability constraints, testing the failover of every VPG configured for recovery to this cluster,
at the same time, will show whether the constraints are violated or not.
When configuring a VPG, you specify the period between tests for that VPG, in the Test Period
field.
You can test a single VPG or multiple VPGs to make sure that if an actual is failover is needed,
the failover will perform as expected.
By default the virtual machines are started with the same IPs as the protected machines in the
protected site. This can create clashes, so it is recommended to ensure a different IP is assigned to
the virtual machines when they start, when configuring each virtual machine NIC properties in
the VPG, during the definition of the VPG. For details, refer to Configuring Virtual Protection
Groups, on page 26. If you ensure that the virtual machines are started with different IPs, then
after the recovered virtual machines are started, they are rebooted with the new IP.
To test failover:
1. In the Zerto tab set the operation to Test and click Failover.
The Test Failover wizard is displayed.
2. Select the VPGs to test from the list. You can filter the list of VPGs to show only those VPGs
defined on the local site, or just on the remote site or all the VPGs, from both sites.
Note: You can initiate the Test failover operation from either the protected site or recovery site
UI. The Dir arrow shows the direction.
3. Click Next
4. Select the point to which you want to test the recovery. The default is the last point, either
assigned by the Zerto Virtual Manager or a user defined checkpoint. To change this default,
click the checkpoint link.
The Select Recovery Point dialog is displayed.
Note: When the VPG is both being cloned and tested for failover at the same time, both status are
displayed and you click the tab at the left of the status area to display the clone or test
information.
All testing is written to scratch volumes. The longer the test period the more scratch volumes are
used, until the maximum size is reached, at which point no more testing can be done. The
maximum size of all the scratch volumes is determined by the journal size hard limit and cannot
be changed. The scratch volumes reside on the same datastore defined for the journal. Using
these test scratch volumes makes cleaning up the test failover more efficient.
You can monitor the status of the test in the VPGs tab and then drill-down to look at the specific
test details for each VPG. In the protected site the detailed view of the VPG shows that the VPG is
being tested and the VPGs tab shows the status as Test.
Alternatively, in the VPGs tab you can click the test icon the Status for the VPG.
The Stop Failover Test dialog is displayed.
3. Optionally, click in the Notes field and add notes to describe the test. For example, specify
where any external files that describe the tests performed is saved. Notes are limited to 255
characters.
4. Select the VPGs to stop testing and click Stop Selected.
5. Click Close. Any running tests continue.
After stopping a test, the virtual machines in the recovery site are powered off and then removed
and the checkpoint that was used for the test has the following tag added to identify the test:
Tested at startDateAndTimeOfTest(OriginalCheckpoint_DateAndTime). This
checkpoint can be used to identify the point-in-time to restore the virtual machines in the VPG
during a failover.
After stopping a test, you can see the test results as part of Zerto Virtual Replication reports.
Refer to Recovery Reports, on page 226,
The date and time of the last test is displayed in the Zerto tab for a virtual machine in a VPG that
has been tested, in the summary section. It is also displayed in a a column in the VPGs and VMs
tabs.
This section describes how to use the basic Zerto Virtual Replication recovery operations
described above to perform live disaster recovery tests, in different situations.
When performing a live DR test you need to consider the following:
The purpose of the live DR test. Whether you wish to merely verify the VMs can recover
properly, or to conduct a full DR test that will include running user traffic against the
recovered VMs.
The length of time you want to test the recovery, a few hours or several days.
Whether the changes to the recovered machine need to be retained after the test or can they
be discarded.
Whether you willing to accept temporary downtime of the application.
Whether you want to simulate an actual disaster at the source protected site, for example by
simulating a network outage or bringing down the source protected site.
The following flowchart shows the testing decision flow:
During any live test, it is recommended that you do not maintain two working versions of the
same virtual machines. Thus, the first step in any test, except for a Failover Test or Clone, is to
make sure that the protected virtual machines are shut down before starting to test recovered
machines. During a Zerto Virtual Replication Move operation the first step Zerto Virtual
Replication performs is to shut down the protected machines, to ensure data integrity. However, a
Zerto Virtual Replication Failover operation assumes that the protected virtual machines are no
longer accessible (the total site disaster scenario) and does not attempt to shut them down at the
beginning of the operation. In a live test using a failover operation you have to manually shut
down the virtual machines to be tested at the beginning of the test in order to prevent potential
split-brain situations where two instances of the same applications are live at the same time.
If you want to perform a live DR test that includes a simulated disaster you can simulate the
disaster by, for example, disconnecting the network between the two sites. In this type of test,
once the disaster is simulated a Move operation cannot be used, since it requires both sites to be
healthy, while a Failover operation can be used.
Basic testing that the virtual machines can recover is done using either a Failover Test operation
or an uncommitted Move operation, using the Rollback setting.
Procedure
The Failover Test operation is described in Starting and Stopping Failover Tests, on page 182.
Procedure
1. Change the VPG Failover Test Network to the production network used at the recovery
site.
2. Manually shutdown the virtual machines in the VPG.
3. Insert a new checkpoint. This avoids potential data-loss since the virtual machines are shut
down and the new checkpoint is added after all I/Os have been written to disk.
4. Optionally simulate a disaster, for example by disconnecting the connectivity between the two
sites.
5. Perform a test failover on the VPG, choosing the checkpoint you added in the second step.
6. Verify that the test machines are recovered as expected.
7. Run user traffic against the virtual machines.
8. Stop the failover test.
9. Reconnect the sites.
Procedure
The Move operation is described in Moving Protected Virtual Machines to the Remote Site, on
page 197. The following procedure highlights specific steps to enable using the Move functionality
for a DR test.
1. In the Move Wizard Configure dialog, uncheck the commit policy checkbox.
2. Either power off the relevant virtual machines or check the Force Shutdown checkbox to
make sure that the virtual machines are shut down, if they cannot be powered off using
VMware Tools.
3. After testing the machines in the recovery site you can roll back the Move operation, which
will return the virtual machines to their pre-test state.
Move Considerations
Changes from the precommit phase are not kept or applied to the source applications.
The virtual machines are allocated disks and connected to the network for a full test of the
environment.
The protected machines are turned off until the end of the test, ensuring that there are no
conflicts between the protected site and recovery site.
During the testing period, every change is recorded in a scratch volume to enable rolling back.
Thus, since both the scratch volume and virtual machines being moved are on the same site,
performance can be impacted by the increased IOs during the testing period. Also, the longer
the test period the more scratch volumes are used, until the maximum size is reached, at
which point no more testing can be done. The maximum size of all the scratch volumes is
determined by the journal size hard limit and cannot be changed. The scratch volumes reside
on the same datastore defined for the journal.
You can only recover to the last checkpoint written to the journal, at the start of the Move
operation.
To test actual user traffic against the recovered virtual machines can be done using a Clone, Move
or Failover operation, as follows:
Move operation When you can shut down the source virtual machines but you dont want or need
to simulate an actual disaster.
Failover operation When you want to simulate an actual disaster.
Clone operation When the source application has to continue throughout the test.
Procedure
The Move operation is described in The Move Operation, on page 176 and in Moving Protected
Virtual Machines to the Remote Site, on page 197. To enable using the Move functionality for a
DR test, in the Move Wizard Configure dialog uncheck the commit policy checkbox.
Move Considerations
You can test the moved machines before they are committed.
You can test for as long as you want.
The virtual machines are allocated disks and connected to the network for a full test of the
environment.
The originally protected disks are maintained for a faster failback when reverse replication is
specified.
The protected machines are turned off until they are committed and then removed from the
source protected site. This ensures that there are no conflicts between the source protected
site and recovery site.
You cannot test to any checkpoint you want but only to the last checkpoint, taken after the
protected virtual machines are shutdown.
An actual disaster is not simulated.
During the testing period, if reverse replication is not specified, there is no protection for the
recovered machines.
Procedure
The Failover operation is described in Initiating a Failover, on page 211. The following
procedure highlights specific steps for a DR test.
1. Manually shutdown the virtual machines.
2. Insert a new checkpoint. This avoids potential data-loss since the virtual machines are shut
down and the new checkpoint is added after all I/Os have been written to disk.
3. Optionally simulate a disaster, for example by disconnecting the connectivity between the two
sites.
4. Perform a live failover on the VPG, specifying the commit policy and choosing the checkpoint
you added in the second step. Via the commit policy you can check that the failed over virtual
machines have been successfully recovered to the correct point-in-time and if not, rollback the
failover.
5. Continue to use the recovered virtual machines.
6. The VPG is in a Needs Configuration state, because there is no access to the source site.
After testing the recovered virtual machine you can finalize the live DR test and fail the virtual
machines back to the source protected site:
1. Reconnect the sites.
2. Enable protection for the virtual machines by editing the VPG and clicking Save.
3. Zerto Virtual Replication uses the original disks to pre-seed the volumes and expedite the
synchronization between the two sites, using a Delta Sync. The time it will take for the Delta
Sync to complete is based on total size of the disks and storage performance at both sites.
After the synchronization completes the VPG enters the Protecting state.
4. Perform a Move operation to failback the virtual machines to the source site.
5. In the Move Wizard Configure dialog, uncheck the commit policy checkbox, or set the
commit policy to enable basic testing before the move is committed.
The VMs are recovered at the source site, and the VPG enters a Delta Sync phase before it enters
a Protecting state.
Failover Considerations
The originally protected disks are maintained for a faster failback.
Non-intuitive use of the failover procedure.
Includes manual procedures, such as shutting down the source virtual machines.
During the testing period, there is no protection for the recovered machines.
Procedure
The Clone operation is described in Cloning a Protection Group to the Recovery Site, on page
204.
The cloned virtual machines are independent of Zerto Virtual Replication. At the end of the test
you can remove these machines or leave them.
Clone Considerations
You can clone to a specific point-in-time.
There is no protection for the cloned machines.
After use of the clone ends, no changes made to the cloned virtual machines are applied to the
protected virtual machines.
The original virtual machines on the source site are live and online throughout the test.
Zerto Virtual Replication enables both recovering the virtual machines in a VPG both after an
unforeseen disaster, as described in Managing Failover, on page 209, and in advance of an event
that requires the migration of the virtual machines in the VPG to the remote site. This chapter
describes a planned migration of a VPG to the remote site.
The following topics are described in this chapter:
The Move Process, below.
Moving Protected Virtual Machines to the Remote Site, on page 197.
Reverse Protection For a Moved VPG, on page 202.
Use the Move operation to migrate protected virtual machines from the protected (source) site to
the recovery (target) site in a planned migration.
When you perform a planned migration of the virtual machines to the recovery site, Zerto Virtual
Replication assumes that both sites are healthy and that you planned to relocate the virtual
machines in an orderly fashion without loss of data.
Note: To recover virtual machines on the recovery site during disaster recovery, see Managing
Failover, on page 209.
The Move operation has the following basic steps:
1. Gracefully shutdown the protected virtual machines. This ensures data integrity.
If the machines cannot be gracefully shut down, for example, when VMware Tools is not
available, you can manually shut down the machines before starting the Move operation or
you specify as part of the operation to forcibly power off the virtual machines. If the machines
cannot be gracefully shut down automatically and are not manually shut down and the Move
operation is not set to forcibly power them off, the Move operation stops and Zerto Virtual
Replication rolls back the virtual machines to their original status.
196
Moving Protected Virtual Machines to the Remote Site
2. Insert a clean checkpoint. This avoids potential data-loss since the virtual machines are not
on and the new checkpoint is after all I/Os have been written to disk.
3. Transfer all the latest changes to the recovery site that are still being queued to pass to the
recovery site, including the new checkpoint.
4. Create the virtual machines at the remote site and attach each virtual machine to its relevant
vdisks, based on the checkpoint inserted in step 2.
5. Power on the virtual machines making them available to the user. If applicable, use the boot
order defined in the VPG settings to power on the machines in a specified order.
6. The default is to automatically commit the move operation without testing. However, you can
also run basic tests on the machines to ensure their validity to the clean checkpoint.
Dependent of the commit/rollback policy that you specified for the operation after testing
either the operation is committed, finalizing the move or rolled back, aborting the operation.
7. The source virtual machines are removed from the inventory.
8. The data from the journal is promoted to the machines. The machines can be used during the
promotion and Zerto Virtual Replication ensures that the user sees the latest image, even if
this is partially data from the journal.
9. If reverse replication was specified, the vdisks used by the virtual machines in the source site
are used for the reverse protection. A Delta Sync is performed to make sure that the two
copies, the new target site disks and the original source site disks, are consistent.
If reverse replication was not specified, the VPG definition is saved but the state is Needs
Configuration and the vdisks used by the virtual machines in the source site are deleted.
Thus, if reverse protection is now set the original vdisks are not available and a full
synchronization is required.
You can move the virtual machines in a virtual protection group to the remote site, whereby the
virtual machines are replicated. As part of the process you can also set up reverse replication,
whereby you create a virtual protection group on the remote site for the virtual machines being
moved, pointing back to the original site. This is commonly used, for example, when the protected
site has planned downtime.
Note: A move differs from a failover in that with a move you cannot select a checkpoint to restore
the virtual machine to. Also, to ensure complete data integrity, the protected virtual machines are
powered off completely and a final checkpoint created so that there is no data loss before the move
is implemented.
To initiate a move:
1. In the Zerto tab click Move.
The Move wizard is displayed.
2. Select the VPGs to move from the list. You can filter the list of VPGs to show only those VPGs
defined on the local site, or just on the remote site or all the VPGs, from both sites.
Note: You can initiate the Move operation from either the protected site or recovery site UI.
The Dir arrow shows the direction.
3. Click Next.
4. Specify the commit policy. The default policy displayed is the policy set in the Advanced
Settings dialog, described in Defining the Failover and Move Operation Default Commit
Policy, on page 90.
To enable committing or rolling back the move operation without manual user interaction:
a) Check the commit policy checkbox. If you do not check this box, the move must be
manually committed or rolled back by the user.
b) Specify the action you want, either Commit or Rollback, which will happen
automatically after the specified time, if there is no user interaction beforehand.
c) Specify the amount of time, in minutes, before the commit or rollback action is performed,
if there is no user interaction beforehand. During this time period you can check that the
VPG virtual machines have moved as required and then commit the move, or
alternatively decide to rollback the operation, cancelling the move. The maximum amount
you can delay the commit or rollback operation is 1440 minutes, which is 24 hours. Note
that the longer the time specified before committing the more space is used in the journal
to enable rollback, possible causing the journal to become full.
To enable committing the move operation only after manual user interaction, uncheck the
Commit Policy checkbox.
Note: When deciding to commit the move, you can decide to configure reverse protection,
regardless of the reverse protection setting when the move was started.
5. If you want to set up reverse protection, whereby the virtual machines in the VPG that is
moved are protected in the remote site, check the Reverse Protection checkbox for the
VPG and then click the Configure link. The Manage VPG dialog is displayed. The VPG SLA,
Settings and Default Values sections of the dialog can vary dependent on whether the
license being used is a cloud license or an enterprise license, whether Zerto Cloud Manager is
used or not, whether a vApp is being protected and whether the target site is vCD.
You can edit the configuration, as described in Configuring Virtual Protection Groups, on
page 26, with the following differences:
You cannot add or remove virtual machines to the reverse protection VPG.
By default, reverse protection is to the original hosts and protected disks. If you click
Configure Selected Volume from the Configure VM dialog, the Configure Volume
dialog is displayed. You can specify a different datastore to be used for the reverse
replication and whether the volume is thin-provisioned or not as well as whether it is
treated as a swap disk or not. For details about these options in the Configure Volume
dialog, refer to the procedure To create a virtual protection group (VPG):, on page 27.
By default, when running vSphere version 4.1 and higher, for each virtual machine in the
VPG, the IP address of the originally protected virtual machine is used in the Configure
VNIC dialog. Thus, during failback the original IP address of the virtual machine on the
site where the machine was originally protected is reused when recovering the virtual
machines back to the original site, unless the machine does not have VMware Tools
installed, in which case DHCP is used. For details about the Configure VNIC dialog,
refer to step 10 in To create a virtual protection group (VPG):, on page 27.
6. Specify if you want the virtual machines in the VPG to be forcibly shut down by checking the
Force Shutdown checkbox. If the virtual machines cannot be gracefully shut down, for
example when VMware Tools is not installed on one of the virtual machines in the VPG and
you do not check this box, the move operation stops and rolls back to the situation before the
move started. If the protected virtual machines have VMware Tools available, the procedure
waits five minutes for the virtual machines to be gracefully shut down before forcibly
powering them off.
7. Click Next.
8. Click the Move arrow to start the migration.
9. If a commit policy was set with a timeout greater than zero, as described in step 4, you can
check the moved virtual machines on the remote site before removing the machines from the
original site to complete the move operation.
Note: If a virtual machine exists on the recovery site with the same name as a virtual machine
being migrated, the machine is moved and named in the remote site with a number added as
a suffix to the name, starting with the number 1.
The indicator icon changes to orange, to warn the user that the procedure is waiting for either
a commit or rollback for the operation.
All testing done during this period, before committing or rolling back the Move operation, is
written to thin-provisioned vdisks, one per virtual machine in the VPG. These vdisks are
automatically defined when the machines are created on the recovery site for testing. The
longer the test period the more scratch volumes are used, until the maximum size is reached,
at which point no more testing can be done. The maximum size of all the scratch volumes is
determined by the journal size hard limit and cannot be changed. The scratch volumes reside
on the same datastore defined for the journal. Using these scratch volumes makes committing
the Move operation more efficient.
10. After checking the virtual machines on the recovery site:
Wait for the specified Commit Policy time to elapse, and the specified operation, either
Commit or Rollback, will be performed automatically.
Or,
Click Rollback to roll back the operation, removing the virtual machines that were created
on the recovery site and rebooting the machines on the protected site.
Or,
Click Commit.
The Commit Move dialog is displayed.
You can reconfigure reverse protection by checking the Reverse protection checkbox
for the VPG and then click the Configure link.Configuring reverse protection here
overwrites any of settings defined in step 5.
Click Commit to continue the move operation.
After the virtual machines are up and running and committed in the recovery site, the powered
off virtual machines in the protected site are removed from the protected site. Finally, data is
promoted from the journal to the moved virtual machines.
Note: During promotion of data, you cannot perform a vMotion on the moved virtual machines.
When moving thee virtual machines in a VPG you specify whether you want reverse protection
from the remote site back to the original protected site.
moved virtual machines and then synchronization with the original site is performed so that the
VPG is fully protected. The synchronization performed uses the original source disks and is either
a Delta Sync or, if there is only one volume to synchronize, a Volume Delta Sync.
Clicking Edit VPG displays the Manage VPG dialog with the settings filled in, using the original
settings for the virtual machines in the VPG from the source protected site, except for the
volumes, since the last step of the move operation is to delete the virtual machines from the
source protected site inventory, including the disks. To start replicating the virtual machines in
the VPG, specify the disks to use for replication and optionally, make any other changes to the
original settings and click Save. An initial synchronization is performed.
Note: You can edit the VPG definition from either of the sites, the site where the VPG virtual
machines were initially protected or the site they were moved to.
You can create a clone of each virtual machine in a VPG on the recovery site in the production
network. The clone is a copy of the protected virtual machines on the recovery site, while the
virtual machines on the protected site remain protected and live.
The following topics are described in this chapter:
The Clone Process, below.
Cloning Protected Virtual Machines to the Remote Site, on page 205.
Use the Clone operation to create a copy of the VPG virtual machines on the recovery site. The
virtual machines on the protected site remain protected and live.
The Clone operation has the following basic steps:
1. Create the cloned disks with the data from the journal to the specified checkpoint.
2. Create the virtual machines at the remote site in the production network and attach each
virtual machine to its relevant cloned disks, configured to the checkpoint specified for the
clone.
The cloned machines are named the source machine with the timestamp of the checkpoint used
for the clone. The cloned virtual machines are not powered on and are not protected by Zerto
Virtual Replication.
204
Cloning Protected Virtual Machines to the Remote Site
You might want to create a clone if you need to have a copy of the virtual machines saved to a
specific point-in-time, for example, when the VPG enters a Replication Paused state, or when
testing the VPG in a live DR test.
To clone a VPG:
1. In the Zerto GUI, access the VPGs or VMs tabs and select the VPG to display the VPG details.
2. Click Actions and then click Offsite Clone.
Note: If the VPG was previously viewed, and the tab for this VPG is still displayed, you can
access the details by selecting the tab.
The Offsite Clone dialog is displayed.
3. Click Configure Checkpoint to select the checkpoint to which to make the copy.
The Select Recovery Point dialog is displayed.
The cloned machines are named with name of the source machine with the timestamp of the
checkpoint used for the clone. The cloned virtual machines are not powered on. The VMDKs are
renamed (1).vmdk, (2).vmdk, etc. The cloned virtual machines are created in the
ZertoRecoveryFolder folder, and not the recovery folder defined in the VPG.
Note: If the protected virtual machine has RDMs attached, these disks are always cloned as thin-
provisioned VMDKs to the datastore specified in the VM Recovery Datastore field in the
Configure VM dialog.
When the VPG is both being cloned and tested for failover at the same time, both status are
displayed and you click the tab at the left of the status area to display the clone or test
information.
Zerto Virtual Replication enables both recovering the virtual machines in a VPG both after an
unforeseen disaster and in advance of an event that requires the migration of the virtual
machines in the VPG to the remote site, as described in Migrating a Protection Group to the
Recovery Site, on page 196. This chapter describes how to perform a failover to the recovery site.
The following topics are described in this chapter:
The Failover Process, below.
Initiating a Failover, on page 211.
Reverse Protection For a Failed Over VPG, on page 218.
Initiating a Failover During a Test, on page 222.
Use the Failover operation following a disaster to recover protected virtual machines to the
recovery site.
Note: You can also move virtual machines from the protected site to the recovery site in a planned
migration. For details, see Migrating a Protection Group to the Recovery Site, on page 196.
When you set up a failover you always specify a checkpoint to which you want to recover the
virtual machines. When you select a checkpoint either the last auto-generated checkpoint, an
earlier checkpoint, or a user-defined checkpoint Zerto Virtual Replication makes sure that
virtual machines at the remote site are recovered to this specified point-in-time.
Note: To identify the checkpoint to use, you can perform a number of consecutive test failovers,
each to a different checkpoint, as described in Testing Recovery, on page 181. At the end of each
test the checkpoint used for the test has the following added to identify the test:
Tested at startDateAndTimeOfTest(OriginalCheckpoint_DateAndTime). This
checkpoint can be used to pinpoint an exact time to restore the virtual machines in the VPG
during a failover. You can also test the failover before committing it, to make sure it is as you
require.
209
The Failover Process
Initiating a Failover
You can initiate a failover, whereby the virtual machines in the virtual protection group are
replicated to a set checkpoint in the recovery site. As part of the process you can also set up
reverse replication, whereby you create a virtual protection group on the recovery machine for the
virtual machines being replicated, pointing back to the protected site.
You can initiate a failover to the last checkpoint recorded in the journal, even if the protected side
is no longer up. You can initiate a failover during a test, as described in Initiating a Failover
During a Test, on page 222.
If you have time to initiate the failover from the protected site you can. However, if the protected
side is down, you initiate the failover from the recovery sight.
Note: Any VPGs that are in the process of being synchronized, cannot be recovered, unless the
synchronization is a bitmap synchronization (Protecting, Bitmap Sync).
To initiate a failover:
1. In the Zerto tab set the operation to Live and click Failover.
The Live Failover wizard is displayed.
2. Select the VPGs to failover from the list. You can filter the list of VPGs to show only those
VPGs defined on the local site, or just on the remote site or all the VPGs, from both sites.
Note: You can initiate the Failover operation from either the protected site or recovery site UI.
The Dir arrow shows the direction.
3. Click Next.
4. Specify the commit policy. The default policy displayed is the policy set in the Advanced
Settings dialog, described in Defining the Failover and Move Operation Default Commit
Policy, on page 90.
To enable committing or rolling back the failover operation without manual user interaction:
a) Check the commit policy checkbox. If you do not check this box, the failover must be
manually committed or rolled back by the user.
b) Specify the action you want, either Commit or Rollback, which will happen
automatically after the specified time, if there is no user interaction beforehand.
c) Specify the amount of time, in minutes, before the commit or rollback action is performed,
if there is no user interaction beforehand. During this time period you can check that the
VPG virtual machines have failed over as required and then commit the failover, or
alternatively decide to rollback the operation, cancelling the failover. The maximum
amount you can delay the commit or rollback operation is 1440 minutes, which is 24
hours. Note that the longer the time specified before committing the more space is used in
the journal to enable rollback, possible causing the journal to become full.
To enable committing the failover operation only after manual user interaction, uncheck the
Commit Policy checkbox.
Note: When deciding to commit the failover, you can decide to configure reverse protection,
regardless of the reverse protection setting when the failover was started.
5. Select what you want to do with the protected virtual machines before starting the failover, in
the Shutdown Protected VMs field:
No (default) The protected virtual machines are not touched before starting the failover. This
assumes that you do not know the state of the protected machines, or know that they are not
serviceable.
Yes If the protected virtual machines have VMware Tools available, the virtual machines
are gracefully shut down, otherwise the failover operation fails. This is similar to performing
a Move operation to a specified checkpoint.
Force The protected virtual machines are forcibly shut down before starting the failover.
This is similar to performing a Move operation to a specified checkpoint. If the protected
virtual machines have VMware Tools available, the procedure waits five minutes for the
virtual machines to be gracefully shut down before forcibly powering them off.
6. Select the point to which you want to recover. The default is the last point, either assigned by
the Zerto Virtual Manager or a user defined checkpoint. To change this default, click the
Checkpoint link.
The Select Recovery Point dialog is displayed.
Manual Select Click Open Selection Window to display a bigger selection of checkpoints,
particularly the most recent checkpoints. The further back you go, the more spaced out are
the checkpoints to enable a greater range from which to select the checkpoint.
8. Click OK.
9. If you can set up reverse protection, when the protected site is still up, the virtual machines in
the VPG that is recovered are protected in the remote site, check the Reverse Protection
checkbox for the VPG and then click the Configure link.
Note: If you cannot set up reverse protection, for example when the protected site is down, the
VPG definition is still defined on the recovery site, so that you can determine the disks, etc.
originally used for the protected virtual machines. The VPG SLA, Settings and Default
Values sections of the dialog can vary dependent on whether the license being used is a cloud
license or an enterprise license, whether Zerto Cloud Manager is used or not, whether a vApp
is being protected and whether the target site is vCD.
You can edit the configuration, as described in Configuring Virtual Protection Groups, on
page 26, with the following differences:
You cannot add or remove virtual machines to the reverse protection VPG.
By default, reverse replication is to the original protected disks. If you click Configure
Selected Volume from the Configure VM dialog, the Configure Volume dialog is
displayed. You can specify a different datastore to be used for the reverse replication and
whether the volume is thin-provisioned or not as well as whether it is treated as a swap
disk or not. For details about these options in the Configure Volume dialog, refer to the
procedure To create a virtual protection group (VPG):, on page 27.
By default, when running vSphere version 4.1 and higher, for each virtual machine in the
VPG, the IP address of the originally protected virtual machine is used in the Configure
VNIC dialog. Thus, during failback the original IP address of the virtual machine on the
site where the machine was originally protected is reused when recovering the virtual
machines back to the original site, unless the machine does not have VMware Tools
installed, in which case DHCP is used. For details about the Configure VNIC dialog,
refer to step 10 in To create a virtual protection group (VPG):, on page 27.
10. Click Next.
11. Click the Failover arrow to start the failover.
12. If a commit policy was set with a timeout greater than zero, you can check the failed over
virtual machines on the peer site before completing the failover operation.
The failover starts, by creating the virtual machines in the recovery site to the point-in-time
specified: either the last data transferred from the protected site or to one of the checkpoints
written in the journal.
Note: If a virtual machine exists on the recovery site with the same name as a virtual machine
being failed over, the machine is created and named in the peer site with a number added as a
suffix to the name, starting with the number 1.
If the original protected site is still up and reverse replication configured to use the protected
virtual machines vdisks, these virtual machines are powered off.
The indicator icon changes to orange, to warn the user that the procedure is waiting for either
a commit or rollback for the operation.
All testing done during this period, before committing or rolling back the Failover operation,
is written to thin-provisioned vdisks, one per virtual machine in the VPG. These vdisks are
automatically defined when the machines are created on the recovery site for testing. The
longer the test period the more scratch volumes are used, until the maximum size is reached,
at which point no more testing can be done. The maximum size of all the scratch volumes is
determined by the journal size hard limit and cannot be changed. The scratch volumes reside
on the same datastore defined for the journal. Using these scratch volumes makes committing
the Failover operation more efficient.
13. After checking the virtual machines on the recovery site, either:
Wait for the specified Commit Policy time to elapse, and the specified operation, either
Commit or Rollback, will be performed automatically.
Or,
Click Rollback to roll back the operation, removing the virtual machines that were created
on the recovery site and rebooting the machines on the protected site.
Or,
Click Commit.
The Commit Failover dialog is displayed.
If the protected site is still up and you can set up reverse protection, you can reconfigure
reverse protection by checking the Reverse protection checkbox for the VPG and then
click the Configure link.Configuring reverse protection here overwrites any of settings
defined when initially configuring the failover.
Click Commit to continue the failover operation.
If the original protected site is still up and reverse replication configured to use the protected
virtual machines vdisks, these virtual machines are removed from this site, unless the original
source site does not have enough storage available to failback the failed over virtual machines.
Finally, data is promoted from the journal to the recovered virtual machines.
Note: During promotion of data, you cannot perform a vMotion on the recovered virtual machines.
By default the virtual machines are started with the same IPs that were assigned to the protected
machines in the protected site. If you do not specify reverse protection, the original machines still
exist in the protected site and this can create clashes, In this case, it is recommended to ensure a
different IP is assigned to the virtual machines when they start, when configuring each virtual
machine NIC properties in the VPG, during the definition of the VPG. For details, refer to
Configuring Virtual Protection Groups, on page 26. If you ensure that the virtual machines are
started with different IPs, then after the recovered virtual machines are started, they are
rebooted with the new IP.
When you specify reverse protection, the virtual machines are recovered on the recovery site and
then protected using the values specified during the failover. The original virtual machines are
removed from the source site and then on the target site the data is promoted from the journal to
the recovered virtual machines and then synchronization with the original site is performed so
that the VPG is fully protected. The synchronization used is either a Delta Sync or if there is only
one volume to synchronize, a Volume Delta Sync is performed.
Note: For the failover operation to complete successfully, when reverse protection is specified, the
original source site must have enough storage available to failback the failed over virtual
machines.
If you do not specify reverse protection, the VPG definition is kept with the status Needs
Configuration and the reverse settings in the VPG definition are set to No Settings.
The Summary dialog also shows that the VPG is defined but is not being replicated. Clicking Edit
VPG displays the Manage VPG dialog with the settings filled in, using the original settings for the
virtual machines in the VPG from the source protected site. You can change the settings or keep
these settings. To start replicating the virtual machines in the VPG, optionally, make any
changes and click Save. If you click Cancel, the VPG is not updated with the original settings.
If the protected site is down, you can initiate the failover from the recovery site, as described
above in To initiate a failover:, on page 211.
When the protected site is down, the protected site right area shows up in the Summary tab,
grayed.
You can identify the site that is down via the Topology tab.
The VPG Details for a VPG a protected VPG being recovered to the site shows that recovery is
possible:
The VPG Details for a VPG being recovered to the down site shows that there is a disconnection
with the recovery site:
You can see the status of every affected VPG is the VPGs tab.
If the Zerto Virtual Manager service is down the actual machines that are being protected can
still be up, but they are only recoverable to the last checkpoint written before the Zerto Virtual
Manager service went down.
If the vCenter Server is down, some of the protected virtual machines might not be protected.
When there is no connection with the protected site, the status indicator for recovered VPGs is red
with an Error status and green while recovery is being performed. If the protected site restarts
so that reverse replication is possible, the status indicator changes to orange.
Replication continues during a test. If you need to initiate a failover during a test, you initiate the
failover. The test stops to enable the failover and then a normal failover is performed, as
described in Initiating a Failover, on page 211. Any changes made to test the failover are not
replicated, as only changes to the source machines in the VPG are replicated.
Note: You cannot initiate a failover while a test is being initialized or closed.
223
Outbound Protection Over Time
Information about how much data is actually being protected against the amount configured for
any of the sites can be displayed in the Outbound Protection Over Time tab under the Reports
item.
Note: The data displayed can be up to 30 minutes old, since the Zerto Virtual Manager collects the
relevant data every 30 minutes.
Target Site Select the site for which you want information displayed or for all the sites. If all the
sites are selected, All Sites is displayed for the field. The list displays all sites paired with the
local site.
Click Apply to apply the filtering selected via any of the above fields.
Click Reset to reset the display to the defaults values.
Information about the virtual machines and amount of data on the recovery site can be displayed
in the Protection Over Time by Organization tab under the Reports item.
Note: The data displayed can be up to 30 minutes old, since the Zerto Virtual Manager collects the
relevant data every 30 minutes.
Recovery Reports
Information about recovery operations, failover tests, moves and failovers, can be displayed in the
Recovery Reports tab under the Reports item. The information includes the protected and
recovery sites involved, when the recovery operation was started, the time taken to bring up the
machines in the recovery site, the RTO, and whether the operation succeeded or not and any
notes added during a failover test.
Click Apply to apply the filtering selected via any of the above fields.
Click Reset to reset the display to the defaults values.
To generate a full report, select the VPGs you want a report generated and click Generate to
generate a full report for each selected VPG. You can have each report written to a single PDF file
or to separate PDF files which are then zipped together. The PDF report includes detailed
information including the start and end time of the operation, the recovery host, datastore,
network, and folder, any boot order information, and details of the steps taken during the
operation, such as creating the test machine and scratch volumes for testing.
Determining Which Columns to Display and the Order They Are Displayed
Right-clicking in the list enables selecting the Edit Columns dialog, where you can specify what
columns to display in the list.
You can also drag-and-drop column headers to rearrange the order the columns are displayed. A
thick vertical bar shows where a column can be dragged and dropped.
You can also reset the display to the default display by right-clicking in the list and selecting the
Reset Columns item.
Resource Report
Resource information about the virtual machines being protected to a recovery site. The
information is collected at fixed times as defined in the Resource Reports section of the Advanced
Settings dialog. For details, see the Defining Resource Report Sampling Period, on page 91.
Information for the report is saved for 90 days when the sampling period is hourly and for one
year when the sampling period is daily.
The report collects the resource information for the virtual machines being recovered to the site
where the report is run. For resource information about these virtual machines being recovered,
the sampling period must be specified in the Advanced Settings dialog on the recovery site.
Usage
Information about usage can be displayed in the Usage tab under the Reports item. The
information is organized by organization and within each organization by site and then VPG and
then the virtual machines in each VPG.
Month Select the month to review. You can also see, under the month, the virtual machine count
for each day in the month.
1. Zerto Virtual Replication provides a number of RESYT APIs, described in the Zerto Virtual Replication API documentation.
The usage report displays for each month the number of virtual machines protected during the
month and the average number per day in the month. For example, if fifteen virtual machines are
protected in a few VPGs starting on the 28th of the month in a thirty day month, the total days
will be 30 (two days multiplied by fifteen machines) and the VM Count will be 1 (Total days
divided by the number of days in the month).
Click Export to CSV to save the report as a CSV file.
Click Export to PDF to save the report as a PDF file.
Click Export to Zip to save the report as zipped CSV and PDF files in a zip file.
VPG Performance
The performance graphs, for all VPGs or for individual VPGs, can be seen with better resolution
than the corresponding graphs in the Zerto tab for a virtual machine in a VPG or in the summary
screen in the VPG Performance tab under the Reports item.
You can specify which VPGs you want to monitor as well as the time period to display in the
graphs, between one and eight minutes. When graphs for multiple VPGs are displayed, you can
display the information for each VPG separately or together as an average.
All of the graphs have a scale. You can change this scale, as described in Customizing the
Performance Graphs, below, to suit the results being displayed, except for the VRA usage graph
in the Summary dialog, which is determined by Zerto Virtual Replication.
Position the cursor on the graph line to see exact information about that point.
The Zerto license includes information such as the number of virtual machines that can be
protected and the license expiry date. You can see the details of what is licensed via the The Site
Settings dialog.
License Type What is licensed: whether the license restricts the number of virtual machines that
can be protected or the number of sockets used.
Expiry Date The license expiry date.
Quantity The maximum amount licensed, either virtual machines or sockets, based on the license
type. If blank, the quantity is unlimited.
Max Sites The maximum number of sites allowed.
Usage Expandable table that lists the sites using the license and number of protected virtual
machines in each site.
A warning is generated when either the license expires or the more than the licensed number of
virtual machines are being protected. Protection continues but the license should be updated.
After getting a new license key you can update Zerto Virtual Replication with this key.
Note: The number of virtual machine is independent of whether they are in vApps or not.
This chapter describes the interaction between Zerto Virtual Replication and commonly used
VMware features such as vMotion, DRS and HA.
The following topics are described in this chapter:
Protecting Virtual Machines in a vApp, below.
Protecting Virtual Machines that Use Thin-Provisioning, on page 237.
Zerto Virtual Replication and VMware Clusters, on page 237.
Zerto Virtual Replication and Fault Tolerance, on page 239.
Zerto Virtual Replication and Host Affinity Rules and CPU Pinning, on page 240.
Ensuring VPG Integrity When Using vMotion, on page 240.
Zerto Virtual Replication and Storage vMotion, on page 240.
VMware Host Maintenance Mode, on page 241.
VMware Roles and Permissions, on page 241.
A VMware vApp is a resource container for multiple virtual machines that work together as part
of a multi-tier application. An example of a multi-tier application is a typical Web-based
application where you might have three tiers: Web, application and database; which are often run
on three separate servers. For example, you may have Microsoft IIS running on one server (tier
1), IBM WebSphere running on another server (tier 2) and IBM DB2 database running on a third
server (tier 3). The three applications on each server all work together and are mostly dependent
on each other for the application to function properly. If one part of the tier became unavailable,
the application will typically quit working as it relies on all the tiers for the application to work.
vApps provide a method for setting power-on options, IP address allocation and resource
allocation, and provide application-level customization for all the virtual machines in the vApp.
236
Protecting Virtual Machines that Use Thin-Provisioning
When you configure a vApp in vSphere you specify properties for it, including CPU and memory
resources, IP allocation, application information, and start order.
Because the VMware treats the vApp as a single logical entity comprising one or more virtual
machines, Zerto Virtual Replication also enables protecting a vApp as a single entity in a VPG for
any vApp defined under an ESXi host. For full details, see Protecting a vApp (via the vSphere
Client Console or Web Client Only), on page 43.
A VMware cluster is a group of tightly coupled ESX/ESXi hosts that work closely together so that
in many respects they can be viewed as though they are a single computer. VMware clusters are
used for high availability and load balancing. With a VMware Cluster, you define two or more
physical machines that will provide resources for the hosts that are assigned to that cluster. By
using clusters, you can achieve high availability and load balancing of virtual machines. Load
balancing is referred to as DRS (Distributed Resource Scheduler) by VMware.
Thus, you use VMware ESX Clusters for the following:
If one of the physical hosts goes down, the other physical host starts up the VMs that the
original host was running (high availability).
If one physical host is over utilized by a VM, that VM is moved to the other physical host
(DRS).
Both of these features use vMotion to move these virtual guests from one system to another.
You cannot apply high availability nor DRS to a Virtual Replication Appliance (VRA).
When protecting virtual machines in a cluster, if you are protecting a vApp, you must install a
VRA on every ESX/ESXi host in the cluster on both the protected and recovery sites and ensure
that DRS is enabled for these clusters. For other virtual machines, it is recommended to install a
VRA on every ESX/ESXi host in the cluster, or to disable DRS on the machine with the virtual
machines to be protected.
Note: When protecting virtual machines in vCloud Director and recovering to a vCenter Server,
the virtual machines are recovered as a vApp and thus DRS must be enabled in the recovery site.
When protecting virtual machines in vCenter Server and recovering to vCloud Director, after a
recovery with reverse protection, from the vCD to the vCenter, the virtual machines are not
replicated back to the original site as a vApp.
Also, see DRS, below.
VMware high availability decreases downtime and improves reliability with business continuity
by enabling another ESX/ESXi host to start up virtual machines that were running on another
ESX/ESXi host that went down.
High availability is automatically disabled by Zerto Virtual Replication while updating recovered
virtual machines in the recovery site from the VRA journal. After the promotion of the data from
the journal to the virtual machine completes, high availability is automatically re-enabled.
The HA configuration can include admission control to prevent virtual machines being started if
they violate availability constraints. If this is the case, then a failover, test failover or migration of
the virtual machines in a VPG to the cluster with this configuration will fail, if the availability
constraints are violated when the virtual machines are recovered. It is recommended to test the
failover, as described in Testing Recovery, on page 181, to ensure recovery will succeed, even
when HA is configured with admission control.
DRS
VMware DRS enables balancing computing workloads with available resources in a cluster.
DRS is automatically disabled by Zerto Virtual Replication while updating recovered virtual
machines in the recovery site from the journal for these recovered virtual machines. After the
promotion of the data from the journal to the recovered virtual machine completes, DRS is
automatically re-enabled.
If DRS is disabled for the site, VMware removes all resource pools in the site. If the recovery was
defined to a resource pool, recovery will be to any one of the hosts in the recovery site with a VRA
installed on it.
Note: If the site is defined in Zerto Cloud Manager, only a resource pool can be specified and the
resource pool must also have been defined in Zerto Cloud Manager. For details about Zerto Cloud
Manager, refer to Zerto Virtual Replication Zerto Cloud Manager Installation, Configuration and
Management.
Profile-Driven Storage provides visibility into your storage pool, letting you optimize and
automate storage provisioning.
Zerto Virtual Replication supports the use of storage profiles and storage clusters defined within
a profile.
VMware fault tolerance provides uninterrupted availability by eliminating the need to restart a
virtual machine by copying a functional virtual machine to a second ESX/ESXi host while making
sure that both virtual machines are synchronized, so that if the ESX/ESXi that is hosting the
primary virtual machine goes down, the secondary virtual machine takes over.
Zerto Virtual Replication does not support fault tolerance for machines in a VPG, nor for a Virtual
Replication Appliance (VRA).
VMware host affinity rules enable specifying which ESX/ESXi hosts a virtual machine can or
cannot run under. CPU pinning ties a specific workload to a specific processor within an ESX/
ESXi host. Thus, when DRS is enabled, the rules for which ESX/ESXi hosts a virtual machine can
be enforced regardless of the load.
Zerto Virtual Replication works whether host affinity and CPU pinning is used or not.
Note: Host affinity rules can be applied to Virtual Replication Appliances (VRAs).
If you use vMotion to migrate a virtual machine, which is part of a VPG, from one ESX/ESXi host
to another ESX/ESXi host, make sure of the following before moving the virtual machine:
The ESX/ESXi host where you are moving the virtual machine to has a Virtual Replication
Appliance (VRA) installed on it, as described in the Zerto Virtual Replication Installation
Guide.
The virtual machine is not a test virtual machine running on the recovery site during the
performance of a failover test, as described in Testing Recovery, on page 181.
You cannot move a Virtual Replication Appliance (VRA) from one ESX/ESXi host to another. Also
a virtual machine that is being updated from the VRA journal, after recovery has been initiated,
cannot be moved until the promotion of data to the virtual machine completes.
VMware Storage vMotion enables you to perform live migration of virtual machine disk files
across heterogeneous storage arrays with complete transaction integrity and no interruption in
service for critical applications enabling you to perform proactive storage migrations, simplify
array refreshes/retirements, improve virtual machine storage performance, and free up valuable
storage capacity in your data center.
Zerto Virtual Replication supports Storage vMotion for protected and recovered virtual machines
but not for a machine in a VPG being promoted.
You place a host in maintenance mode when you need to service it, for example, to install more
memory. A host enters or leaves maintenance mode only as the result of a user request.
Virtual machines that are running on a host entering maintenance mode need to be migrated to
another host (either manually or automatically by DRS) or shut down.
Zerto Virtual Replication enables moving recovery disks managed by a VRA on a host that needs
maintaining to be moved to another host for the duration of the maintenance, as described
Managing Protection During VMware Host Maintenance, on page 168.
VMware roles and permissions are the core of VMware infrastructure security. Permissions are a
combination of a user/group and a security role that is applied to some level of the VMware
Infrastructure. Zerto Virtual Replication supplies permissions that are assigned to the
Administrator role when Zerto Virtual Replication is installed that enable the administrator to
perform specific actions. For details, see Setting Permissions, on page 76.
You can handle problems related to the WAN connecting the protecting or recovery sites, or other
problems using a variety of diagnostic and troubleshooting tools.
The following topics are described in this chapter:
Ensuring the Zerto Virtual Manager is Running, below.
Troubleshooting Needs Configuration Problems, on page 244.
Troubleshooting GUI Problems, on page 245.
Troubleshooting VRA Problems, on page 245.
Handling Lack of Storage Space for Recovered Virtual Machines, on page 246.
Zerto Virtual Replication Diagnostics Utility, on page 246.
Collecting Zerto Virtual Replication Logs, on page 247.
Zerto Virtual Replication Alarms, on page 257.
Zerto Virtual Replication Alerts, on page 262.
Zerto Virtual Replication Events, on page 273.
If you have problems with accessing the Zerto tabs, check under Windows Services, on the
machine where Zerto Virtual Replication is installed, that the Zerto Virtual Manager Windows
service is started.
There are a number of scenarios where the VPG status changes to Needs Configuration.
Each scenario must be handled to resolve the issue. Clicking Edit VPG displays the Manage VPG
dialog with the settings filled in, using the original settings for the virtual machines in the VPG.
To resolve the status issue, change the VPG definition as appropriate.
The following scenarios result in the VPG status changing to Needs Configuration:
A protected disk resize operation fails, for example when there is not enough disk space.
When a virtual machine is added to a protected vApp and the added virtual machine has no
matching datastore or not enough room on the recovery datastore or the VPG settings are not
updated because of a site disconnection or vCenter Server error.
When a volume is added to a protected virtual machine and the added volume has no
matching datastore or not enough room on the recovery datastore or the VPG settings are not
updated because of a site disconnection or vCenter Server error.
When performing a Failover or Move operation, if you do not specify reverse protection.
An Org vDC network is removed from the recovery site that has a VPG replicating to it.
If a message is displayed that the Adobe Flash Player version is wrong, but it is correct, in
Internet Explorer select Internet Options under Tools and in the Security tab add the GUI
location as a trusted site.
If the Zerto GUI is not displayed after installing Zerto Virtual Replication, close and reopen the
console.
Check the network. If the firewall configuration is modified, the VRA TCP connections have to be
reset. After a VRA disconnect and reconnect the system can wait for up to fifteen minutes before
syncing the sites after the reconnection.
If the installation of a VRA completes successfully, but the allocation of the IP takes too long,
when attempting to specify the host to recover a VPG, the host where the VRA is installed does
not appear in the list, you have to uninstall and then re-install the VRA.
If a VRA is promoting data to a recovery virtual machine and the VRA fails, the VRA starts up
automatically but you might have to restart the virtual machine manually and then the
promotion will continue.
Uninstalling a VRA sometimes leaves a zagentid folder and you cannot install a new VRA,
because of an old, unused, zagentid folder. Delete the zagentid folder manually.
Note: This only happens if a file was manually added to the zagentid folder.
If a recovery virtual machine does not have enough space on the recovery site, the promotion of
data to the recovered virtual machine hangs. If this occurs you should add more space to the
machine and then start the machine. The promotion will then continue.
Zerto Virtual Replication includes a diagnostics utility to help resolve actual and potential
problems. Using the diagnostics tool, you can do the following:
Collect logs to help Zerto support resolve problems. The Zerto Virtual Manager must be
running on each site for which you want logs. See To collect logs for Zerto support to use
when troubleshooting:, below.
Collect local Zerto Virtual Manager logs. Use this option if the Zerto Virtual Manager is not
running. See Collecting Log Information for the ZertoVssAgent, on page 254.
Check the connectivity between Zerto Virtual Replication components. See Check
Connectivity Between Zerto Virtual Replication Components, on page 170.
Reconfigure the Zerto Virtual Manager, including the IP addresses of the vCenter Server and
of the machine running the Zerto Virtual Manager, and the SSL certificate used when
accessing the Zerto GUI. See Reconfiguring the Zerto Virtual Manager Setup, on page 172.
Export VPG settings to an external file and import these settings. This option is used when
upgrading Zerto Virtual Replication, described in the Zerto Virtual Replication Installation
Guide.
Note: A separate installation kit is available for download from the Zerto Support Portal
downloads page that installs the Zerto Virtual Replication Diagnostics utility as a standalone
utility on any Windows machine that has Microsoft .NET Framework 4 installed1.
You can collect logs using the diagnostics tool to help Zerto support resolve problems either when
the Zerto Virtual Manager is running on each site for which you want logs or when the Zerto
Virtual Manager is not running.
When the Zerto Virtual Manager is running on each site. See To collect logs for Zerto support
to use when troubleshooting:, below. This option enables you to specify the logs that you want
to collect, both generated by Zerto Virtual Replication, for example VRA logs, as well as logs
generated by VMware, for example, vCenter Server logs or host logs. The Zerto Virtual
Replication generated logs can be filtered by any alerts issued and by the VPGs that require
analysis to identify problems.
When the Zerto Virtual Manager is not running. See Collecting Log Information for the
ZertoVssAgent, on page 254.
1. The installation executable is included as part of the standalone utility installation kit and it requires an additional 1.8GB of free
disk space.
2. Select the Collect the Zerto Virtual Replication logs for use by Zerto support option.
3. Click Next.
The Initialize dialog is displayed.
5. Select any alerts that need analyzing from the list and click Next.
The Select VPGs dialog is displayed.
6. Select the VPGs that you want analyzed using the plus and minus buttons and click Next.
The Customize dialogs are displayed. These dialogs can generally be left with their default
values.
The following Customize dialogs are displayed:
The Select Sites dialog.
The Select VRA Hosts dialog.
The Select vSphere Logs dialog.
The Select vCloud Director Logs dialog.
The Select Sites dialog is displayed, with the list local site and all the sites paired to it
listed.
Those sites that are either protecting or used for recovery for any of the selected VPGs from
the previous dialog are automatically selected.
Note: Zerto Virtual Manager logs from both sites are collected when both sites are trusted
sites otherwise only logs from the local site are collected.
7. Verify that the sites that need analyzing are selected and click Next.
The Select VRA Hosts dialog is displayed.
Those hosts with VRAs that are used to protect or recover any of the selected VPGs are
automatically selected.
You can change the collection criteria using the plus and minus buttons. The expected size of
the collection package is updated dependent on the selected VRAs.
8. Verify that the host with VRAs that need analyzing are selected and click Next.
The Select vSCenter Server Logs dialog is displayed.
11. Specify destination for the details that you want collected.
Destination The name and location where the log collection will be saved.
Automatically upload files to Zerto FTP Server When this option is checked, the log collection is
automatically uploaded to a specified FTP site.
Note: If you choose to upload the log collection to a site that you specify, make sure that the
site is up.
12. Specify the FTP site to send the collection and the protocol to use, either FTP or HTTP.
13. Click Next.
The Review dialog is displayed.
Check that you have specified everything you want to collect and if you want to make
changes, click Back to change the selection.
14. Click Start.
The data is collected and stored in the destination file which, by default, is timestamped. If
specified, the collection is also sent to an FTP site.
Note: The log collection is performed on the server. Cancelling the collection in the GUI does
not stop the collection from continuing on the server and a new log collection cannot be run
until the running collection finishes.
When the log collection has completed the result is displayed. For example:
15. Click Done to return to the Zerto Virtual Replication Diagnostics menu dialog.
16. Send the log to Zerto support, unless the Automatically upload files to Zerto FTP
Server option was specified, in which case it is automatically sent to Zerto.
To collect local Zerto Virtual Manager logs (when the Zerto Virtual Manager is not running):
1. Click Start > Programs > Zerto Virtual Replication > Zerto Diagnostics.
The Zerto Virtual Replication Diagnostics menu dialog is displayed.
2. Select the Local Zerto Virtual Manager diagnostics option and click Next.
You are prompted to use the first option to collect more comprehensive diagnostics. If you
continue, the Initialize dialog is displayed.
Port The port used for inbound communication with the Zerto Virtual Manager.
Your Company Name A name to identify the log collection for the customer account. This
information is used by Zerto support. An account name must be entered.
Email An email address for use by Zerto support when analyzing the logs. An email address
must be entered.
Timeframe The amount of time you want to collect logs for. The more time, the bigger the
collection package.
Description An optional free text description of the reason for collecting the logs.
4. Click Next.
The Save Log Destinations dialog is displayed.
5. Specify the details that you want collected and click Next.
Destination The name and location where the log collection will be saved.
Automatically upload files to Zerto FTP Server When this option is checked, the log collection is
automatically uploaded to a specified FTP site.
Note: If you choose to upload the log collection to a site that you specify, make sure that the
site is up before clicking Finish.
The data is collected and stored in the destination file which, by default, is timestamped. If
specified, the collection is also sent to an FTP site.
Note: The collection progress is displayed.
When the log collection has completed the result is displayed.
6. Click Done to return to the Zerto Virtual Replication Diagnostics menu dialog.
7. Send the log to Zerto support, unless the Automatically upload files to Zerto FTP
Server option was specified, in which case it is automatically sent to Zerto.
When ZertoVssAgent is installed, adding checkpoints to the journal can be synchronized with
Microsoft Volume Shadow Copy Service (VSS) snapshots, as described in Ensuring Application
Consistency With Microsoft Volume Shadow Copy Service (VSS), on page 135.
Logs generated by the ZertoVssAgent are saved separately and not collected using the Zerto
Virtual Replication diagnostics tool, described in Collecting Zerto Virtual Replication Logs, on
page 247. These logs are small and can be zipped and sent to Zerto support separately.
The logs are saved to a Zerto folder under the program data folder. For example, depending on the
Windows operating system, the logs are accessed via C:\Documents and Settings\All
Users\Application Data\Zerto or C:\ProgramData\Zerto.
Zerto Virtual Replication is controlled by the Zerto Virtual Manager. If problems arise you can
view the Zerto Virtual Manager logs to see what is happening.
The current log is called logfile.csv and resides in the
<Zerto_Install_Dir>\Zerto Virtual Replication\logs folder, where
Zerto_Install_Dir is the folder specified during the installation.
When the log reaches 10MB its name is changed to log.nnnn.csv, where nnnn is a number
incremented by one each time logfile.csv reaches 10MB. Up to 100 log files are kept.
The log file has the following format:
FFFF, yyyy-mm-dd hh:mm:ss, ####, LVL, Component, API, Message
where:
FFFF A HEX code. For internal use.
LVL Severity level of the message. The more messages written to the log the bigger the impact
on performance. The number of messages written to the log decreases from Debug to Error. The
level can be one of the following:
Debug All messages are written to the log. This level should only be specified during testing.
Info Information messages.
Warn Warning messages such as a reconnect ion occurred.
Error Error messages that need handling to find the problem.
Component The specific part in the Zerto Virtual Manager that issued the message.
During the installation of Zerto Virtual Replication, the following Zerto Virtual Replication
alarms are defined in the vCenter Server:
Alarm Description
com.zerto.event.BacklogError Journal history problem. The amount of
history is at least 25% less than it should be,
probably because of a synchronization that
overwrote some of the checkpoints.
com.zerto.event.BacklogWarning Journal history problem. The amount of
history is between 15% and 25% less than it
should be, probably because of a
synchronization that overwrote some of the
checkpoints.
com.zerto.event.CloudConnector A problem with the Zerto Cloud Connector,
for example, it is powered off. For details
about Zerto Cloud Connectors, refer to Zerto
Virtual Replication Zerto Cloud Manager
Installation, Configuration and
Management.
com.zerto.event.Could not find matching recovery Specific to vCD targets: A VPG is replicating
storage profile to an Org vDC, and some VMs within the
VPG have no recovery storage profile
configured, and no enabled storage profile in
the recovery site contains their recovery
datastores.
com.zerto.event.CriticalCheckpoint The checkpoints available in the journal are
decreasing, and that there are only a few
minutes worth left. This can occur due to a
prolonged Bitmap Sync, or a general WAN
disconnect due to storage or network issues.
The replication/sync has been proactively
paused so as not to lose all of the history.
After the configured pause timeout expires,
replication/sync will continue and
checkpoints will be lost.
com.zerto.event.Datastore The datastore is not accessible.
com.zerto.event.DisconnectedVCenter vCenter Server disconnection.
Alarm Description
com.zerto.event.DuplicateMacAddress Mac Address conflict.
com.zerto.event.FotJournalFull Scratch volumes used for a failover test or
before committing either a move or failover
operation have reached the maximum size.
com.zerto.event.GhostCloudConnector A Zerto Cloud Connector was deleted,
leaving a ghost cloud connector. For details
about Zerto Cloud Connectors, refer to Zerto
Virtual Replication Zerto Cloud Manager
Installation, Configuration and
Management.
com.zerto.event.GhostVm A Virtual Replication Appliance was
deleted, leaving a ghost VRA, as described
in Handling a Ghost VRA, on page 166.
com.zerto.event.GhostVolume A shadow VRA was deleted, leaving a ghost
volume, as described in Handling a Ghost
VRA, on page 166.
com.zerto.event.HostPasswordChanged The password used by the VRA to access the
host ESX/ESXi is no longer valid.
com.zerto.event.InconsistentJournalSize A journal size is not consistent with its
configuration. Specifically, when the user
increases the journal size, the recovery
volume is resized accordingly. If the resize
fails, the configured size does not match the
actual disk size, leading to the alert.
com.zerto.event.JournalLimitReached The journal volume has reached the hard
limit set for it in the VPG definition.
com.zerto.event.JournalVolumeFull The journal volume is full.
com.zerto.event.LastTest The VPG has not been tested or was tested a
long time ago.
com.zerto.event.License License problem.
com.zerto.event.LowDiskFreeSpace The disk on which the Zerto Virtual
Manager is installed is low on space.
com.zerto.event.Missing recovery datastores in The storage profile does not include the
recovery storage profile recovery datastores.
com.zerto.event.MissingOrgVdcNetworkMapping Network mapping for Org vDC for the VPG
is missing.
Alarm Description
com.zerto.event.MissingRecoveryOrgVdcNetworkMapp Network mapping for the recovery site
ing provider Org vDC is missing.
com.zerto.event.PeerZvmCompatibility The paired remote Zerto Virtual Manager is
a different version that cannot work with
the local Zerto Virtual Manager.
Note: Pairing of incompatible Zerto Virtual
Managers is prevented, but upgrading a
Zerto Virtual Manager to an incompatible
version with a paired remote Zerto Virtual
Manager is possible.
com.zerto.event.ProtectedVolumeSizeChanged For internal use only.
com.zerto.event.ProtectionGroupError The VPG has an error. This only happens in
rare cases, for example, if a storage error
occurs while recovering from a VRA crash.
com.zerto.event.ProtectionGroupMissingConfiguration The VPG has a missing configuration.
com.zerto.event.ProtectionGroupPaused The VPG protection has been paused.
com.zerto.event.Recovery provider vDC storage profile The recovery provider vDC storage profile is
disabled disabled.
com.zerto.event.Recovery provider vDC storage profile The recovery provider vDC storage profile
not found could not be found.
com.zerto.event.Recovery storage profile disabled The recovery storage profile is disabled.
com.zerto.event.Recovery storage profile not found The recovery storage profile could not be
found.
com.zerto.event.RecoveryBeforeCommit The VPG is waiting to be committed or
rolled back.
com.zerto.event.RecoveryDataStoreFull The recovery datastore or journal is full.
com.zerto.event.RecoveryDataStoreLowFreeSpace The recovery datastore has less than 1GB of
free space.
com.zerto.event.ResourcePoolInsufficientError Resource Pool does not have enough
resource to support VPG.
com.zerto.event.ResourcePoolMissingError The target resource pool for the VPG can no
longer be found.
com.zerto.event.RpoError The target RPO is not being met. The
current RPO is at least 25% more than the
target RPO.
Alarm Description
com.zerto.event.RpoWarning The target RPO is not being met. The
current RPO is between 15% and 25% more
than the target RPO.
com.zerto.event.ServiceProfileMissing The service profile for the VPG cannot be
found.
com.zerto.event.Storage profile not found in underlying Storage profile not found in underlying
VCenter Server vCenter Server.
com.zerto.event.UndoRollbackFailed Rollback failed.
com.zerto.event.UninstalledHost The host has no VRA installed.
com.zerto.event.UnprotectedVMsError One or more of the virtual machines in the
VPG are not protected, for example a virtual
machine was vMotioned to an ESX/ESXi
host without a VRA.
com.zerto.event.VCDConnector vCloud Director connection problem.
com.zerto.event.VCDReflection vCloud Director problem with collecting the
reflection.
com.zerto.event.VirtualMachine For internal use only.
com.zerto.event.VPGOutofZorgOnProtected The VPG has been defined as belonging to a
ZORG but contains resources outside of the
ZORG, checked by the protected site.
com.zerto.event.VPGOutofZorgOnRecovery The VPG has been defined as belonging to a
ZORG but contains resources outside of the
ZORG, checked by the recovery site.
com.zerto.event.VraBallooning On 4.x: VRA on host does not have enough
resources. On 5.x: VRA on host does not
have enough reserved memory.
com.zerto.event.VraCloneVolume VRA clone volume error.
com.zerto.event.VraDidntReceiveIp The VRA didn't receive an IP.
com.zerto.event.VraIpChanged The VRA IP changed.
com.zerto.event.VraLogVolume A VRA journal volume error.
com.zerto.event.VraPoweredOff A VRA is powered off.
com.zerto.event.VraProtectedVolume A VRA protected volume error.
com.zerto.event.VRARegistrationFailed A problem with an ESX upgrade.
Alarm Description
com.zerto.event.VRAs reconciliation The Zerto Virtual Manager is synchronizing
all of its VRAs. It can happen if there was a
site disconnect and the Zerto Virtual
Managers detected that a change was made
while the sites were disconnected. For
example, executing a failover while the sites
are disconnected and then they reconnect.
com.zerto.event.VraTargetVolume A recovery volume error for a VRA.
com.zerto.event.VraToVraConnection A VRA is not connected to a remote site
VRA.
com.zerto.event.ZertoGenericAlert Alert issued when none of the specific alerts
are valid for the situation.
com.zerto.event.ZvmToVraConnection The Zerto Virtual Manager is not connected
to a VRA.
com.zerto.event.ZvmToZvmConnection The Zerto Virtual Manager is not connected
to a remote site Zerto Virtual Manager.
Each Zerto Virtual Replication alert is associated with an event in the vCenter Server. These
events can trigger vCenter Server alarms. Thus, when a Zerto Virtual Replication alert is fired, a
corresponding event is also fired. This event can trigger a vCenter Server alarm.
Note: Disabling an alarm in vCenter Server will not stop Zerto Virtual Replication alert being
fired.
Warnings are indicated by the orange icon and alerts by the red icon. The information displayed
includes the VPG name, Entity Name that triggered the alert, the date and time the alert was
issued and a description of the alert.
The alert status indicator in the top left shows the color for the most severe alert that is currently
valid. After the alert has been resolved, the alert is removed from the Alerts tab and the alert
status indicator changes, if appropriate, to show the new alert status.
You can filter the Alerts report for all the columns with a filter icon. Click the filter icon to enter
part of a value to filter the values. The filter icon changes color from grey to blue when a filter is
applied. A link in the filter input area enables clearing the filter.
You can dismiss alerts by selecting the relevant alerts and clicking the Acknowledge button. You
can also display the list of alerts to include acknowledged alerts or not. Toggle Display
Acknowledged Alerts to either display those alerts that have been dismissed or not. Note that the
number of alerts displayed in the title bar alerts indicator is the number of unacknowledged
alerts.
Any Zerto Virtual Replication alert will only be turned off when all instances of the alert are
turned off. For example, if you pause two VPGs, a vCenter Server alarm is raised. If you resume
just a single VPG the alarm remains on. Only when no VPGs are paused is the alarm stopped.
If the description of the alert is truncated, hover over the alert to display a tooltip with the
complete description.
Alerts form previous versions are displayed with an Unknown link.
Click Export to save the alerts as a Microsoft Excel worksheet.
For a listing of the Zerto Virtual Replication alerts, see Zerto Virtual Replication Alerts, below.
Or:
Failed extracting reflection for Org vDC {0} ({1}).
Exception
VCD0018 VM {0} has NICs with duplicate MACs: {1} and {2}
have MAC '{3}'
VCD0019 An Org vdc network mapping setting for networks Fix the mapping.
{0} in Vpg {1} has become corrupted.
VCD0020 number of entities [{0}] in startup-section is Perhaps a virtual machine was
different from the number of Vms[{1}] in vapp={2} removed from the vCenter.
VCD0021 Unknown entity={0} in StartupSection of vapp={1}. Perhaps a virtual machine was
removed from the vCenter.
VPG0003 The VPG {0} has been protected for {1} but the
journal history is only {2}.
Or:
VPG {0} journal history is less than 75% of the
configured {2}. This has occurred because of a
synchronization between the protected and
recovery sites and will automatically be resolved
when the journal history is fully populated.
The Events tab displays a log of tasks performed within Zerto Virtual Replication.
You can specify how you want to filter the log activity displayed:
Type You can display just the events generated by Zerto Virtual Replication or the alerts used to
turn the events on or off or both the events with their alerts.
From and To The dates for which you want activity information. Only activities performed,
between these dates are displayed.
Click Apply to apply the filtering selected via any of the above fields.
Click Reset to reset the display to the defaults values.
Click Export to export the listing of events to a Microsoft Excel file.
You can see more details about any event by clicking the event ID link for the event.
Configuration and management of the disaster recovery for a site is performed in the Zerto user
interface, in the Zerto GUI.
The following dialogs and tabs are described in this chapter:
Add Checkpoint Dialog, below.
Add Group Dialog, on page 276.
Add Site Dialog, on page 276.
Add Static Route Dialog, on page 277.
Advanced Settings Dialog, on page 277.
Alerts Tab, on page 279.
Boot Order Dialog, on page 280.
Browse for VMDK File Dialog, on page 281.
Change Host Password Dialog, on page 281.
Change Target Host Dialog, on page 281.
Compatibility Matrix Dialog, on page 282.
Configure & Install VRA Dialog, on page 282.
Configure Network Mapping Dialog, on page 283.
Configure Notifications Dialog, on page 284.
Configure Paired Site Routing Dialog, on page 284.
Configure Provider vDCs Dialog, on page 285.
Configure vCD Dialog, on page 286.
Configure VM Dialog, on page 286.
Configure VM Dialog (vCD), on page 288.
Configure VNIC Dialog, on page 290.
Configure VNIC Dialog (vCD), on page 291.
Configure Volume Dialog, on page 291.
Configure Volume Dialog (vCD), on page 292.
Delete VPG Dialog, on page 293.
Edit VRA Dialog, on page 293.
Events Tab, on page 294.
Manage Journal Dialog, on page 295.
Manage Sites Dialog, on page 297.
Manage Static Routes Dialog, on page 297.
Manage VPG Dialog Protecting a vApp, on page 298.
274
Manage VPG Dialog Protecting to a vCenter Server, on page 301.
Manage VPG Dialog Protecting to vCD, on page 304.
Manage VPG Dialog Protecting vCD to vCD, on page 306.
New VPG Dialog, on page 309.
Offsite Clone Dialog, on page 309.
Outbound Protection Over Time Report, on page 309.
Pause Dialog, on page 310.
Protection Over Time by Organization Report, on page 310.
Recent Activities Dialog, on page 311.
Recovery Reports, on page 311.
Resource Report, on page 312.
Resume Dialog, on page 313.
Select Recovery Point Dialog, on page 313.
Select VMs Dialog, on page 314.
Site Information Dialog, on page 314.
Sites Tab, on page 315.
Start Maintenance Dialog, on page 316.
Stop Failover Test Dialog, on page 316.
Summary Tab, on page 317.
Time-based Bandwidth Throttling Dialog, on page 318.
Topology Tab, on page 318.
Usage Report, on page 319.
VMs Tab, on page 320.
VPG Performance Report, on page 322.
VPGs Tab, on page 322.
VRAs Tab, on page 325.
Zerto Virtual Replication License Dialog, on page 326.
Checkpoints are recorded automatically every few seconds in the journal. These checkpoints
ensure crash-consistency and are written to the virtual machine journals by the Zerto Virtual
Manager and each checkpoint has the same timestamp set by the Zerto Virtual Manager. In
addition to the automatically generated checkpoints, you can manually add checkpoints to
identify events that might influence the recovery, such as a planned switch over to a secondary
generator.
The list of VPGs is displayed. You can select more VPGs to add the same checkpoint.
Enter a name for the checkpoint The name to assign the checkpoint.
275
Add Group Dialog
Source Site Name The name of the VPG source site, where virtual machines are protected.
Target Site Name The name of the VPG target site, where protected virtual machines are
recovered.
Local Site Display VPGs for the local site only.
Show All Display VPGs for both the local and remote sites.
Define a group to contain a static route to the subnet used by the Zerto Virtual Manager and can
be applied to more than one Zerto Cloud Connector.
Group The name of the group.
Also see: Add Static Route Dialog, on page 277.
To pair sites.
Remote Site ZVM IP Address IP address or host name of the remote site to pair to. The remote site
is the site where the remote Zerto Virtual Manager is installed.
Port The TCP port communication between the sites. Enter the port that was specified during
the installation. The default port during the installation was 9081.
Add a static route for a specified group, defined in Add Group Dialog, on page 276.
Group Name The name of the group which will contain the static route.
Address The IP address for the static route in the Zerto Virtual Manager network.
Gateway The gateway address for the network on the local network of the Zerto Cloud Connector
cloud network interface.
Site settings, such as, the maximum bandwidth that Zerto Virtual Replication will use between
the protected and recovery sites.
Bandwidth Throttling The maximum bandwidth that Zerto Virtual Replication uses from this site
to recovery sites. The default value is for Zerto Virtual Replication to automatically assign the
bandwidth used per VPG, based on using the maximum available and then prioritizing the usage
according to priority set for the VPGs sending data over the WAN. The minimum supported
bandwidth is 5 Mb/sec.
Slider Set the Mb/sec. The valid range is from Auto to 99 Mb/sec. With Auto, Zerto Virtual
Replication automatically assigns the bandwidth used per VPG, based on using the maximum
available and then prioritizing the usage according to priority set for the VPGs sending data
over the WAN.
Text box The Mb/sec. when the value required is 100 Mb/sec. or more.
Time-based Bandwidth Throttling To throttle the bandwidth for specific times. Enables the
Configure button.
Configure button To throttle the bandwidth for specific times. Opens the Time-based Bandwidth
Throttling Dialog dialog.
Default Script Execution Timeout The time out in seconds for a script to run before or after a
failover, move or test failover.
Graphical Scaling: IOPS The scaling used in performance graphs for the IO between the
applications running on the virtual machines in the VPG and the VRA.
Graphical Scaling: Throughput The scaling used in performance graphs for the MBs for the
applications running on the virtual machines being protected.
Graphical Scaling: WAN Traffic The scaling used in performance graphs for the traffic between the
sites.
Graphical Scaling: RPO The scaling used in performance graphs for the time since the last
checkpoint was written to the journal.
Graphical Scaling: CPU The scaling used in performance graphs for the VRA CPU usage.
Graphical Scaling: VRA Local Memory The scaling used in performance graphs for the VRA local
memory usage.
Graphical Scaling: VRA Remote Memory The scaling used in performance graphs for the VRA
remote memory usage.
Enable replication to self To enable the same vCenter Server to be used for both the protected and
recovery sites.
vCD Settings: Configure vCD button Set up access to vCD for the Zerto Virtual Manager. Opens
the Configure vCD Dialog dialog.
vCD Settings: Configure Provider vDCs button Set up access to provider vDCs and their datastore
configuration. Opens the Configure Provider vDCs Dialog dialog.
Replication Pause Time The time to pause when synchronizing a VPG if continuing the
synchronization will cause all the checkpoints in the journal to be removed.
Failover/Move Commit Policy The commit policy to use during a failover or move operation. The
value set here applies as the default for all failover or move operations from this point on but can
be changed when defining a failover or move operation. The following options are available:
None The failover or move operation must be manually committed or rolled back by the user.
Commit After the time specified in the Default Timeout field the failover or move
operation is committed. During the specified time you can check the recovered VPG virtual
machines.
Rollback After the time specified in the Default Timeout field the failover or move
operation is rolled back, unless manually committed or rolled back by the user before the time
out value is reached.
Default Timeout The time out in minutes after which a Commit or Rollback commit policy is
performed. A value of zero indicates automatically performing the commit policy, without waiting
for any user interaction.
Email Notifications: Configure Notifications button Enables configuring Zerto Virtual Replication
alerts to be sent to an email address. Opens the Configure Notifications Dialog dialog.
Resource Report: Sampling Rate When to take resource samples to identify resource usage, either
daily at a specific hour and minute or hourly at a specific minute within each hour. Note that
collecting a sample hourly provides a higher resolution picture of replication traffic than if
collected every daily.
Resource Report: Sampling Time The time that the sample is taken.
Manage Static Routes button Enables defining and managing static routes for Zerto Cloud
Connectors. Opens the Manage Static Routes Dialog dialog.
Compatibility Matrix button Displays the list of ESX/ESXi hosts supported by Zerto Virtual
Replication. Opens the Compatibility Matrix dialog.
Alerts Tab
Each Zerto Virtual Replication alert is associated with an event in the vCenter Server. These
events can trigger vCenter Server alarms. Thus, when a Zerto Virtual Replication alert is fired, a
corresponding event is also fired. This event can trigger a vCenter Server alarm.
Acknowledge button Dismiss selected alerts.
Alert ID The alert identifier, which can be clicked to provide mere details.
Filtering Information
You can filter the list so that you can easily identify sites.
You can filter columns by clicking the filter icon and typing part of the value. The filter changes
color from grey to blue when a filter is applied. A link in the filter area enables clearing the filter.
Determining Which Columns to Display and the Order They Are Displayed
Right-clicking in the list enables selecting the Edit Columns dialog, where you can specify what
columns to display in the list.
You can also drag-and-drop column headers to rearrange the order the columns are displayed. A
thick vertical bar shows where a column can be dragged and dropped.
You can also reset the display to the default display by right-clicking in the list and selecting the
Reset Columns item.
To specify the boot order of virtual machines in a VPG. When machines are started up on
recovery, for example after a move operation, or shut down after a failover test operation, the
virtual machines in the VPG are not started up and shutdown in a particular order. If you want
specific virtual machines to startup or shutdown before other machines, you can specify a boot
order. The virtual machines are defined in groups and the boot order applies to the groups and not
between individual virtual machines in the groups. You can specify a delay between groups
during startup. During shutdown, the groups are shutdown in the reverse order defined for
starting them up.
Initially, virtual machines in the VPG are displayed together under the default group. If you want
specific machines to start before other virtual machines, define new groups with one or more
virtual machines in each group.
There is no boot order for virtual machines in a group, only between groups.
Add button To add a group.
Remove button To remove a group. You cannot remove the Default group nor a group which
contains a virtual machine.
Group Name The name of the group. To change the name of a group select the group and change
the value in this field to the required name.
Arrow buttons To move virtual machines from one group to another and to change the startup
order by moving the groups up or down the list.
Startup Action Specify a time delay between starting up the virtual machines in the group and
starting up the virtual machines in the next group, or specify that the virtual machines in the
next group only start up after VMware Tools are ready for the virtual machines started up in the
selected group. For example, assume three groups, Default, Server and Client defined in this
order. The Start-up delay defined for the Default group is 10, for the Server group is 100 and for
the Client group 0. The virtual machines in the Default group are started together and after 10
seconds the virtual machines in the Server group are started. After 100 seconds the virtual
machines in the Client group are started up.
To select the folder with the preseeded disk to use. Drill-down to select the disk.
To change the target host for virtual machines to move all the VRA information and recovery
volumes maintained by the VRA to another host, maintaining full protection while the original
host is out of service.
New Password The new password required by the VRA to access the host.
To change the target host required by the VRA to access the host.
Alert status indicator The color indicates the status of the alert:
Green The virtual machine can be moved to the replacement host.
Red The virtual machine cannot be moved to the replacement host.
Direction The direction of the replication, from this site to the remote site or from the remote site
to this site.
VM Name The name of the virtual machine.
Organization The Zerto name given to the organization, the ZORG, by a cloud service provider.
Replacement Host The name of the host to move the recovery virtual machines information.
Supported Update The supported version for the ESX or ESXi host.
Host The target ESX/ESXi host for the VRA. The drop-down displays the hosts managed by the
vCenter Server which do not have a VRA installed.
Host Root Password The password used to access the host for the root user. This field is required
for ESXi 4.x and 5.x hosts. This field is disabled for ESX 4.x hosts. When the checkbox at the side
is checked the password is displayed as asterisks. The is used by the Zerto Virtual Manager when
deploying and upgrading the VRA on this host. Also, root access is required in case the Zerto host
component is down and needs an automatic restart. The Zerto Virtual Manager checks the
password is valid once a day. If the password was changed, an alert is triggered, requesting the
user enter the new password.
Datastore The datastore that the VRA will use for mirror virtual machines and for its journal.
You can install more than one VRA on the same datastore.
Network The network used to access the VRA.
Amount of VRA RAM The amount of memory to allocate to the VRA. The amount determines the
maximum buffer size for buffering IOs written by the protected virtual machines by the
protecting VRA, before they are sent over the network to the recovery VRA. The recovery VRA
also buffers the incoming IOs until they are written to the journal.
Amount of VRA RAM VRA Buffer Pool Size
1GB 461MB
2GB 1485MB
3GB 2509MB
The protecting VRA can use 90% of the buffer for IOs to send over the network and the recovery
VRA can use 75% of the buffer. That is, for example, a protecting VRA defined with 2GB of RAM
can buffer approximately 1337MB before the buffer is full and a Bitmap Sync is required.
VRA Group Specify the VRA Group as free text to identify the group or select from a previously
specified group. You group VRAs together when VRAs use different networks so they can be
grouped by network, for example when the same vCenter Server supports two datacenters with
separate networks and you are replicating from one datacenter to the second datacenter. The
group name is free text you use to identify the group.
Configuration Either have the IP address allocated via a static IP address or a DHCP server. The
Static option is the recommended option.
Address The IP address for the VRA.
Subnet Mask The subnet mask for the network. The default value is 255.255.255.0.
The Org Networks to use for failover and move operations, for failover test operations, and for test
failover operations after a failover or move when reverse protection is configured. The list of
current Org Networks is displayed.
Source Network The source network being used by the Org vDC.
Failover/Move Target Network The network to use during a failover or move in which the recovered
virtual machines will run.
Failover Test Target Network The network to use during a test failover in which the testing
recovered virtual machines will run.
Reverse Configuration Failover Test Network The network to use when failing back a failed over or
moved VPG.
<Isolated> means that the network is an internal only vApp network.
Sender Account A valid email address for the email sender name.
Send test Email button To test that the email notification is set up correctly. An email with the
subject ZVR Test Email is sent to the email address specified in the To field.
The IP address, subnet mask and gateway to access the peer site VRAs when the access to the
peer site VRAs is not via the network default gateway.
Address The IP address to access the network.
Subnet Mask The subnet mask for the network.
Provider datastore: Unlisted datastores are not used by Zerto Virtual Replication Unlisted datastores
cannot be used.
Provider datastore: Unlisted datastores are used only for recovery volumes Unlisted datastores of all
provider vDCs, even those provider vDCs that have not been added to the list of Provider vDCs
can be used as recovery datastores.
Provider datastore: Add button Add datastores.
Journal Check if the datastore can be used for the journal. If no datastores are configured as
journals, all datastores in the provider vDC can serve as journals. If at least one datastore, on any
provider vDC, is configured as a journal but the target provider vDC does not see any journal
datastore, all datastores eligible to be recovery datastores on that provider vDC, can also serve as
journal datastores. If at least one datastore is configured as a journal and the target provider vDC
sees at least one journal datastore, only datastores configured as journal, that are visible to that
provider vDC can serve as journal datastores.
Preseed Check if the datastore can be used for preseeded disks. Only datastores marked as
preseeded can be used, preventing different organizations being exposed to datastores of other
customers using the preseed option.
Default Storage Profile The default storage profile to use from the list of defined profiles, or leave
blank if the vCD does not have any storage profiles defined. Profile-Driven Storage allows you to
intelligently provision applications, mapping virtual machines to storage levels according to
predefined service levels, storage availability, performance requirements or cost. This mechanism
lets users define and label storage tiers to be used by Storage Distributed Resource Scheduler and
Storage vMotion. Virtual machines that run applications that require the highest level of
performance are mapped to tier one storage, while less critical applications are mapped to the
lower tiers. You set the storage profile for every virtual machine in a VPG where the target site is
vCD 5.1.
Configure VM Dialog
Enables configuring how the protected virtual machine will be recovered, including details about
the VMware file for the virtual machine, and the volumes and NICs used by the virtual machine.
If default values were specified in the VPG default properties, they are used for the virtual
machine configuration.
Volumes:Configure Selected Volume button To configure the recovery volume for the virtual
machine. See Configure Volume Dialog, on page 291.
Volumes:Source The source volumes used by the protected virtual machine.
Volumes group box:Provisioned The provisioned storage allocated to the protected virtual
machine.
NICs:Configure Selected NIC button To configure the vNIC for the virtual machine. See Configure
VNIC Dialog, on page 290.
NICs:NIC Name The name of the VNIC.
NICs:Failover Network The recovery site network to use for the failovered over or moved virtual
machine.
NICs:Test Network The recovery site network to use for the virtual machine being tested for
failover. This network can be a fenced-out network so as not to impact the production network.
VM Advanced Settings If a vApp is not being protected:
Recovery Host The cluster, resource pool or ESX/ESXi that will host the recovered virtual
machine. If the site is defined in Zerto Cloud Manager, only a resource pool can be specified
and the resource pool must also have been defined in Zerto Cloud Manager.
When a resource pool is specified, Zerto Virtual Replication checks that the resource pool
capacity is enough for any virtual machines specified in the VPG. If a resource pool is
specified and DRS is disabled for the site later on, all the resource pools are removed by
VMware and recovery will be to any one of the hosts in the recovery site with a VRA installed
on it.
Note: All resource pool checks are made at the level of the VPG and does not take into account
multiple VPGs using the same resource pool. If the resource pool CPU resources are specified
as unlimited in the Edit Setting dialog for the resource pool, the actual limit is inherited from
the parent but if this inherited value is too small, failover move and failover test operations
can fail, even without a warning alert being issued by Zerto Virtual Manager.
VM Recovery Datastore The datastore where the VMware file for the virtual machine is
stored. If a cluster or resource pool is selected for the host, only datastores that are accessible
by every ESX/ESXi host in the cluster or resource pool are displayed. This is also the
datastore where RDM backing files for recovery volumes are located. When specifying the
recovery storage for a virtual machine with a storage cluster, you have to specify a datastore
in the cluster.
Recovery Folder The folder where the virtual machine is recovered to.
If default values were specified in the Manage VPG dialog, they are used for the virtual
machine configuration and are displayed in the Recovery Host, VM Recovery Datastore
and Recovery Folder fields. You can change these values for the specific virtual machine by
selecting new values from the drop-down lists.
Enables configuring how the protected virtual machine will be recovered, including details about
the volumes and NICs used by the virtual machine. If default values were specified in the VPG
default properties, they are used for the virtual machine configuration.
NICs:Configure Selected NIC button To configure the vNIC for the virtual machine. See Configure
VNIC Dialog (vCD), on page 291.
The following fields can be set for the NICs used for failover and move operations, in a production
environment, and for test failovers, via the Failover/Move tab and the Failover Test tab,
respectively. By default, the NIC configuration for the failover or move production environment is
copied automatically to the configuration for the test environment.
NICs: Connected Whether the VM is connected to the org vDC network.
NICs: Mac Address The MAC address. By default this is the address used on the protected site, so
that both the protected machine and recovered machine use the same MAC address. Either accept
the default Mac address or select Reset, to reset the MAC address on recovery of the machine.
Volumes:Configure Selected Volume button To configure the recovery volume for the virtual
machine. See Configure Volume Dialog (vCD), on page 292.
Volumes:Source The source volumes used by the protected virtual machine.
Volumes group box:Provisioned The provisioned storage allocated to the protected virtual
machine.
VM Advanced Settings:Journal Size Hard Limit The maximum size that the journal can grow. When
the value is Unlimited the size for the journal is unlimited and it can grow to the size of the
recovery datastore. When the value is Custom, you can specify a maximum journal size, either as
a percentage of the virtual machine volume size or as a fixed maximum size.
VM Advanced Settings:Journal Size Warning Threshold The size of the journal that triggers a
warning that the journal is almost full. When the value is Unlimited, a warning is only issued
when the journal is close to being full. When the value is Custom, you can specify a threshold,
either as a percentage of the virtual machine volume size or as a fixed size. In addition to the
warning threshold, Zerto Virtual Replication will issue a message when the journal is close to
being as full as it can be.
VM Advanced Settings If the target vCD is vCD 5.1:
Storage Profile Storage profiles enable mapping virtual machines to storage levels according
to predefined service levels, storage availability, performance requirements or cost. You can
define and label storage tiers and then specify the tier to use as a storage profile, for each
virtual machine in the VPG. The default storage profile is the default for the Target Org
vDC.
To configure the NIC used for the replicated VM disks. You can configure a maximum of four
NICs.
Note: You can only change the VNIC IP for virtual machines with VMware Tools running for the
following operating systems: Windows 2003 and higher, Red Hat Enterprise Linux versions 5-6,
SUSE Linux Enterprise versions 10-11 and CentOS versions 5-6.
Specify the network details to use for the recovered virtual machines after a live recovery or
migration, in the Failover/Move tab, and for the recovered virtual machines when testing the
replication, in the Failover Test tab.
NIC Name The name used to identify the NIC.
Source Network The network used by the virtual machine being protected.
Failover/Move tab: Failover Network The recovery site network to use for the failovered over or
moved virtual machine.
Failover Test tab: Test Network The recovery site network to use for the virtual machine being
tested for failover. This network can be a fenced-out network so as not to impact the production
network.
MAC Address Whether the Media Access Control address (MAC address) used on the protected
site should be replicated on the recovery site or a new MAC address created on the recovery site.
The default is to use the same MAC address on both sites.
Failover/Move tab: Change Failover VNIC IP Configuration Either have the IP address allocated via a
static IP address or a DHCP server.
Failover Test tab: Change Test VNIC IP Configuration Either have the IP address allocated via a
static IP address or a DHCP server.
IP address The IP address to access the network.
Alternate DNS server The DNS alternative IP address for the network.
Copy to test button Copy the failover/move network settings to be the same for the test network.
Copy to failover button Copy the test network settings to be the same for the failover/move
network.
IP Mode The way the IP is allocated, either via a DHCP server or a static IP, assigned either
from a pool of IPs or by manually assigning the IP address.
IP Address The IP address when a static IP is manually allocated.
Mac Address The MAC address. By default this is the address used on the protected site, so that
both the protected machine and recovered machine use the same MAC address. Either accept the
default Mac address or select Reset, to reset the MAC address on recovery of the machine.
To configure the datastore for recovery. If a cluster or resource pool is selected for the host, only
datastores that are accessible by every ESX/ESXi host in the cluster or resource pool are
displayed.
Swap If the virtual machine to be replicated includes a swap disk as part of its configuration,
you can specify a mirror disk for replication that is marked as a swap disk. In this case, data is
not replicated to the swap disk after initial synchronization.
Recovery Datastore The datastore to use to create disks for the replicated data. Also specify
whether the target is thin provisioned. If the source disk is thin provisioned, the default for the
recovery volume is that it is also thin provisioned.
Raw Disk (RDM) The VMware RDM (Raw Device Mapping) to use for the replication: By default,
RDM is recovered to vmdk and not to RDM. Only a raw disk with the same size as the protected
disk can be selected from the list of available raw disks. Other raw disks with different sizes are
not available for selection. The RDM is always stored in the recovery datastore used for the
virtual machine. You cannot define an RDM disk if the virtual machine uses a BusLogic SCSI
controller, nor when protecting or recovering virtual machines in an environment running
vCenter Server 5.x with ESX/ESXi version 4.1 hosts.
Preseed A virtual disk (the vmdk flat file and header file) in the recovery site that has been
prepared with a copy of the protected data, so that the initial synchronization is much faster since
a Delta Sync is used to synchronize any changes written to the recovery site after the creation of
the preseeded disk. When using a preseeded VMDK, you select the datastore and exact location,
folder and name, of the preseeded disk. Zerto Virtual Replication takes ownership of the
preseeded disk, moving it from its source folder to the folder used by the VRA. Only disks with the
same size as the protected disk can be selected when browsing for a preseeded disk. The datastore
where the preseeded disk is placed is also used as the recovery datastore for the replicated data. If
the preseeded disk is greater than 1TB on NFS storage, the VPG creation might fail. This is a
known VMware problem when the NFS client does not wait for sufficient time for the NFS
storage array to initialize the virtual disk after the RPC parameter of the NFS client times out.
The timeout default value is 10 seconds. Refer to the VMware documentation, http://
kb.vmware.com/selfservice/microsites/
search.do?language=en_US&cmd=displayKC&externalId=1027919, which describes the
configuration option to tune the RPC timeout parameter using the esxcfg-advcfg -s
<Timeout> /NFS/SetAttrRPCTimeout command.
Note: Zerto Virtual Replication supports the SCSI protocol. Only disks that support this protocol
can be specified.
To configure the datastore for recovery. If a cluster or resource pool is selected for the host, only
datastores that are accessible by every ESX/ESXi host in the cluster or resource pool are
displayed.
Swap If the virtual machine to be replicated includes a swap disk as part of its configuration,
you can specify a mirror disk for replication that is marked as a swap disk. In this case, data is
not replicated to the swap disk after initial synchronization.
New VCD Datastore The datastore is allocated based on the available free space. You can specify
whether the recovery volume is thin provisioned or not. If the Org vDC only supports thin-
provisioned volumes, you cannot change the setting.
Preseed A virtual disk (the vmdk flat file and header file) in the recovery site that has been
prepared with a copy of the protected data, so that the initial synchronization is much faster since
a Delta Sync is used to synchronize any changes written to the recovery site after the creation of
the preseeded disk. When using a preseeded VMDK, you specify the exact location, the preseed
folder configured for the customer and the disk name, of the preseeded disk. A provider datastore
must have been specified for preseeded disks in the Configure Provider vDCs Dialog, on page
285 dialog. Zerto Virtual Replication takes ownership of the preseeded disk, moving it from its
source folder to the folder used by the VRA. Note that if the virtual machine has more than one
preseeded disk, these disks must reside on the same datastore. If the preseeded disk is greater
than 1TB on NFS storage, the VPG creation might fail. This is a known VMware problem when
the NFS client does not wait for sufficient time for the NFS storage array to initialize the virtual
disk after the RPC parameter of the NFS client times out. The timeout default value is 10
seconds. Refer to the VMware documentation, http://kb.vmware.com/selfservice/microsites/
search.do?language=en_US&cmd=displayKC&externalId=1027919, which describes the
configuration option to tune the RPC timeout parameter using the esxcfg-advcfg -s
<Timeout> /NFS/SetAttrRPCTimeout command.
Note: Zerto Virtual Replication supports the SCSI protocol. Only disks that support this protocol
can be specified.
To delete a VPG configuration. The VRA on the recovery site that handles the replication for the
VPG is updated.
Keep target disks at the peer site The target replica disks for the virtual machines are kept so that
you can resynchronize to these disks faster if you reprotect virtual machines in the VPG.
If, for whatever reason, the VPG cannot be deleted the VPG status changes to Pending Remove.
Attempting to delete the VPG a second time displays the following options:
Retry Retry deleting the VPG.
Force Delete Forcibly delete the VPG. This option leaves the target disks, regardless of
whether they were wanted or not.
Cancel Cancel the delete operation.
To change the network settings for a VRA, for example when the gateway to the VRA is changed.
Target Host The IP of the host on which the VRA is installed.
Host Root Password The password required by the VRA to access the host.
VRA Group The free text to identify the group to which a VRA belongs. If you create a group and
then change the name when editing the VRA so that there is no VRA in the site that belongs to
the originally specified group, the group is automatically deleted from the system.
Configuration Either have the IP address allocated via a static IP address or a DHCP server. If
the VRA was originally installed with a static IP, you cannot change this to DHCP. If the VRA
was originally installed to use a DHCP server, you can change this to use a static IP.
Address The static IP address for the VRA to communicate with the Zerto Virtual Manager.
Subnet Mask The subnet mask for the network. The default value is 255.255.255.0.
Events Tab
From and To The dates for which you want event information. Only activities performed,
between these dates are displayed.
Apply button To apply the filtering selected via any of the above fields.
User The users who initiated the event and the location of the user.
Filtering Information
You can filter the list so that you can easily identify sites.
You can filter columns by clicking the filter icon and typing part of the value. The filter changes
color from grey to blue when a filter is applied. A link in the filter area enables clearing the filter.
Determining Which Columns to Display and the Order They Are Displayed
Right-clicking in the list enables selecting the Edit Columns dialog, where you can specify what
columns to display in the list.
You can also drag-and-drop column headers to rearrange the order the columns are displayed. A
thick vertical bar shows where a column can be dragged and dropped.
You can also reset the display to the default display by right-clicking in the list and selecting the
Reset Columns item.
Journal Datastore The datastore used for the journal data for each virtual machine in the VPG.
The default is the datastore volume used for recovery of each virtual machine. Thus for example,
if protected virtual machines in a VPG are configured with different recovery volumes, the journal
data is by default stored for each virtual machine on that virtual machine recovery volume. To
change the default, you must first specify a default host and then select one of the datastores
accessible by this host to be used as the journal datastore. When you select a specific journal
datastore, the journals for each virtual machine in the VPG are stored in this datastore,
regardless of where the recovery datastores are for each virtual machine. In this case, all the
protected virtual machines must be recovered to ESX/ESXi hosts that can access the specified
journal datastore. The following table shows the different datastore options and the repercussions
of each option:
Default Journal Journal Datastore per Journal Datastore
VPG for Multiple VPGs
Allows No Yes Yes
storage tiering
Notes The journal for each virtual Specify a journal Allows the use of
machine is on the same datastore datastore for each VPG advanced settings
that the recovery volume is on (for sized using the Journal like storage IO
example, you can have two Sizing Tool. All journals controls, to give
volumes of the same VM for the VPG are stored fairness to
replicating to different datastores). here. customers.
By default, the recovery datastore Depending on This option is
for each virtual machine is the deployment size, may recommended for
same as the VPG recovery require too many cloud service
datastore. datastores. providers.
The provisioned journal size is the current size of all the journal volumes.
If the journal grows to approximately 80% of the provisioned journal size, a new volume is added
to increase the journal size. The journal size can increase up until the specified hard limit.
When the amount of the journal used is approximately 50% of the provisioned journal size, the
biggest unused journal volume is marked for removal. This volume is then removed after the time
equivalent to three times the amount specified for the journal history, or twenty-four hours,
whichever is more.
With VMFS datastore and when the VRA is on a host ESX/ESXi that is version 5.1 or higher, the
journal can also reclaim unused space on a volume. This does not change the provisioned journal
size.
Note: The journal cannot reclaim unused space with NFS datastores.
When a virtual machine journal becomes close to the specified hard limit, Zerto Virtual
Replication starts to move data and checkpoints to the target disks. Once this begins, the
maintained history begins to decrease. If the journal history falls below 75% of the value specified
for the Default Journal History parameter, a warning alert is issued in the GUI. If the
history falls below one hour, an error is issued. However, if the amount of history defined is only
one hour, an error is issued if it is less than 45 minutes.
If the datastore where the journal resides drops below 30GB or 15% of the total datastore size,
whichever is the smaller of these two values, the datastore itself is considered full and an error
alert is issued and all writes to journal volumes on that datastore are blocked. Replication is
halted, but history is not lost. As such, the RPO begins to steadily increase until space is made
available on the datastore.
Journal Size Hard Limit The maximum size that the journal can grow. When the value is
Unlimited the size for the journal is unlimited and it can grow to the size of the recovery
datastore. When the value is Custom, you can specify a maximum journal size, either as a
percentage of the virtual machine volume size or as a fixed maximum size. The journal is always
thin-provisioned.
Journal Size Warning Threshold The size of the journal that triggers a warning that the journal is
almost full. You can specify the value as unlimited or change the value to Custom in order to
specify a threshold, either as a percentage of the virtual machine volume size or as a fixed size. In
addition to the warning threshold, Zerto Virtual Replication will issue a message when the
journal is close to being as full as it can be.
To pair sites so as to enable replication between the sites managed by a separate vCenter Server.
Peer Name The site name of a paired site. The site name is defined in the Site Information Dialog
dialog.
Site Location The site location of the paired site. The site location is defined in the Site
Information Dialog dialog.
Peer Connection Details The IP address of the peer site and the port used to access the Zerto
Virtual Manager on this site.
Status The status of the pairing.
Add New Site button Define a paired site. Opens the Add Site Dialog dialog.
When providing DR as a Service, the cloud service provider needs to ensure complete separation
between the organization network and the cloud service provider network. The cloud service
provider needs to be able to route traffic between an organization network and the cloud
replication network, in a secure manner without going through complex network and routing
setups.
The cloud service provider can define a Zerto Cloud Connector per organization site that has two
Ethernet interfaces, one to the organizations network and one to the cloud service provider's
network. If the cloud service provider wants to institute additional security, considering both
cloud connector interfaces as part of the organization network, he can define a static route that
will hop to a different cloud network, specifically for use by the Zerto Virtual Manager and VRAs
in the cloud site.
Group: Add button Define a group to contain a static route to the subnet used by the Zerto Virtual
Manager. Opens the Add Group Dialog dialog.
Group: Remove button Remove a selected group.
Route: Add button Define a static route for a selected group. Opens the Add Static Route Dialog
dialog. You can defined more than one static route for a group. The static routes are displayed
under each group.
Route: Remove button Remove a selected static route.
You can protect a vApp as a single entity in a VPG for any vApp defined under an ESXi host. All
the virtual machines defined in the vApp VPG are protected and you can migrate or recover the
whole vApp as a single entity to the recovery site. For details about migrating a VPG and the
virtual machines in it, see Migrating a Protection Group to the Recovery Site, on page 196. For
details about recovering a VPG and the virtual machines in it, see Managing Failover, on page
209.
In addition to being able to protect the vApp, you can protect individual virtual machines in the
vApp, in the same way as you protect any other virtual machine. However, if you protect a virtual
machine in the vApp, you cannot then protect the vApp as a single entity.
Note: Nested vApps are not protected. Also, if you drag a protected vApp under another vApp to
nest it, the protection is removed. You cannot protect vApps which include virtual machines with
VirtualEthernetCardLegacyNetworkBackingInfo NICs or with IDE devices.
The dialog is divided in to the following sections:
The VPG name A unique name to identify the VPG.
VPG SLA Properties that govern the VPG service level, such as how often tests should be
performed on the VPG. Cloud service providers can group these properties together in a
service profile. When a service profile is used, the VPG SLA settings cannot be modified unless
a Custom service profile is available.
Settings VPG specific settings, such as the target site.
Default values Specific values used, by default, for the recovery of the virtual machines in the
VPG, in the recovery site, such as the ESX/ESXi host where the machine will be recovered to.
These values can be overridden for every virtual machine in the VPG.
Virtual machines to be protected The list of virtual machines being protected with details
about the machine as well as details of the how it will be recovered, such as the ESX/ESXi
host where the machine will be recovered to. These values are either specified directly for the
machine or the default values are used.
Scripts Scripts to be run before and after a VPG has been recovered.
VPG Name The name for the VPG, which by default is the name of the vApp.
Service Profile The name of the service profile to use which determines the VPG SLA settings for
the group, which apply to every virtual machine in the group. To change the VPG SLA settings,
select the Custom Service Profile.
Priority (QOS) Used to determine the priority for transferring data from the protected site to
the recovery site when there is limited bandwidth and more than one VPG is defined on the
protected site. When there are updates to virtual machines protected in VPGs with different
priorities, first the updates from the VPG with the highest priority are passed over the WAN.
Medium priority VPGs will only be able to use whatever bandwidth is left after the high
priority VPGs have used it. This is also true between medium and low priorities. Note that
updates to the protected virtual machines are always sent across the WAN before
synchronization data, such as during a Bitmap Sync or Delta Sync. During a
synchronization, only after updates to the virtual machines are sent over the WAN, based on
the VPG priority, is synchronization data from the VPG sent, and the synchronization data
from the VPG with the highest priority is passed over the WAN before data from medium and
low priority VPGs.
Target RPO Alert The maximum desired time between each automatic checkpoint being
written to the journal before an alert is issued. In reality checkpoints are written more
frequently.
Default Journal History The time for which all write commands are saved in the journal. When
specifying a checkpoint to recover to, the checkpoint must still be in the journal. For example, if
the value specified here is 24 hours then recovery can be specified to any checkpoint up to 24
hours. After the time specified, the mirror virtual disk volumes maintained by the VRA are
updated. The more time saved the more space is required for each journal in the VPG to store the
information saved. When protecting to a site using an enterprise license, the default size for the
journal is unlimited, up until the size of the datastore where it resides. When protecting to a cloud
site and the cloud service provider uses Zerto Cloud Manager, the default size for the journal is
10% of the datastore size. The journal size can be configured by clicking the configuration button
to display the Manage Journal Dialog.
Test Frequency Reminder The time recommended between testing the integrity of the VPG. A
warning is issued if a test is not done within this time frame.
WAN Compression (displayed when the Zerto Virtual Replication license is an enterprise
license) Whether the data is compressed before being transferred to the recovery site or not.
Compressing the data is more efficient but results in a small performance degradation.
Enable WAN compression if network considerations are more critical than CPU usage
considerations. Even if WAN compression is selected, Zerto Virtual Replication decreases the
level of compression if it takes too many resources. Zerto Virtual Replication can also work
with third-party WAN optimization and acceleration technologies, such as those supplied by
Riverbed Technologies, Silver Peak, and others. When third-party WAN optimization is
implemented, it is recommended to disable the VPG WAN compression.
ZORG (displayed when Zerto Cloud Manager is used) The Zerto organization.
Target Site The site to which you want to recover the virtual machines. The recovery site selected
in the New VPG dialog is displayed and cannot be changed here.
vApp Recovery Cluster/Host The cluster, resource pool or ESX/ESXi host in the recovery site
which handles the replicated data. This value cannot be overridden for each virtual machine
configuration, unless it is to another host in the same cluster. If the site is defined in Zerto Cloud
Manager, only a resource pool can be specified and the resource pool must also have been defined
in Zerto Cloud Manager. When a resource pool is specified, Zerto Virtual Replication checks that
the resource pool capacity is enough for any virtual machines specified in the VPG. If a resource
pool is specified and DRS is disabled for the site later on, all the resource pools are removed by
VMware and recovery will be to any one of the hosts in the recovery site with a VRA installed on
it. All resource pool checks are made at the level of the VPG and does not take into account
multiple VPGs using the same resource pool. If the resource pool CPU resources are specified as
unlimited in the Edit Setting dialog for the resource pool, the actual limit is inherited from the
parent but if this inherited value is too small, failover move and failover test operations can fail,
even without a warning alert being issued by Zerto Virtual Manager.
vApp Folder The default folder where the vApp is recovered. Select a folder from the list or the
[Default]ZertoRecoveryFolder folder.
Datastore The default datastore volume to use for all the recovered virtual machine files as well
as for their volumes. Every datastore for the selected default recovery host is included in the drop-
down options. The displayed datastores are accessible by the default host. If a cluster or resource
pool is selected for the host, only datastores that are accessible by every ESX/ESXi host in the
cluster or resource pool are displayed. Zerto Virtual Replication uses the SCSI protocol. Only
disks that support this protocol can be specified.
Failover/Move Network The default network to use during a failover or move in which the
recovered virtual machines will run.
Failover Test Network The default network to use during a test failover in which the testing
recovered virtual machines will run. This network can be a fenced-out network so as not to impact
the production network.
Configure button To configure a virtual machine recovery volumes and VNICs. Opens the
Configure VM Dialog dialog.
Boot button Displays a message that you define the boot order for vCenter Server vApps in the
vSphere Client console, via Edit Settings for the vApp.
Recovery scripts expansion To specify the settings for scripts to run on the recovery site before or
after executing a failover, move or test failover.
Pre-recovery Script The script to run before starting the recovery.
Post-recovery Script The script to run after the recovery.
Command to run The name of the script to run, including the full path. The script must be
located on the same machine as the Zerto Virtual Manager for the recovery site.
Params The values of any parameters to pass to the script. Separate parameters with a
space.
Timeout (sec) The time out in seconds for the script to run. If the script runs before executing
a failover, move or test failover and the script fails or a timeout value is reached, an alert is
generated and the failover, move or test failover is not performed. If the script runs after
executing a failover, move or test failover and the timeout value is reached, an alert is
generated.
VPG Name The name for the VPG, which by default is the name of the vApp.
Service Profile (when Zerto Cloud Manageris used) The name of the service profile to use which
determines the VPG SLA settings for the group, which apply to every virtual machine in the
group. To change the VPG SLA settings, select the Custom Service Profile.
Priority (QOS) Used to determine the priority for transferring data from the protected site to
the recovery site when there is limited bandwidth and more than one VPG is defined on the
protected site. When there are updates to virtual machines protected in VPGs with different
priorities, first the updates from the VPG with the highest priority are passed over the WAN.
Medium priority VPGs will only be able to use whatever bandwidth is left after the high
priority VPGs have used it. This is also true between medium and low priorities. Note that
updates to the protected virtual machines are always sent across the WAN before
synchronization data, such as during a Bitmap Sync or Delta Sync. During a
synchronization, only after updates to the virtual machines are sent over the WAN, based on
the VPG priority, is synchronization data from the VPG sent, and the synchronization data
from the VPG with the highest priority is passed over the WAN before data from medium and
low priority VPGs.
Target RPO Alert The maximum desired time between each automatic checkpoint being
written to the journal before an alert is issued. In reality checkpoints are written more
frequently.
Default Journal History The time for which all write commands are saved in the journal. Each
protected virtual machine has a dedicated journal volume on the recovery site associated with the
replicated virtual machine. This enables journal data to be maintained, even when changing the
target host for the recovery. When specifying a checkpoint to recover to, the checkpoint must still
be in the journal. For example, if the value specified here is 24 hours then recovery can be
specified to any checkpoint up to 24 hours. After the time specified, the mirror virtual disk
volumes maintained by the VRA are updated.
The more time saved the more space is required for each journal in the VPG to store the
information saved. The journal size can be configured by clicking the configuration button to
display the Manage Journal dialog.
Test Frequency Reminder The time recommended between testing the integrity of the VPG. A
warning is issued if a test is not done within this time frame.
WAN Compression (displayed when the Zerto Virtual Replication license is an enterprise
license) Whether the data is compressed before being transferred to the recovery site or not.
Compressing the data is more efficient but results in a small performance degradation.
Enable WAN compression if network considerations are more critical than CPU usage
considerations. Even if WAN compression is selected, Zerto Virtual Replication decreases the
level of compression if it takes too many resources. Zerto Virtual Replication can also work
with third-party WAN optimization and acceleration technologies, such as those supplied by
Riverbed Technologies, Silver Peak, and others. When third-party WAN optimization is
implemented, it is recommended to disable the VPG WAN compression.
ZORG (displayed when Zerto Cloud Manager is used) The Zerto organization.
Target Site The site to which you want to recover the virtual machines. The recovery site selected
in the New VPG dialog is displayed and cannot be changed here.
Host The default cluster, resource pool or ESX/ESXi host, in the recovery site which handles the
replicated data. If the site is defined in Zerto Cloud Manager, only a resource pool can be specified
and the resource pool must also have been defined in Zerto Cloud Manager. When a resource pool
is specified, Zerto Virtual Replication checks that the resource pool capacity is enough for any
virtual machines specified in the VPG. If a resource pool is specified and DRS is disabled for the
site later on, all the resource pools are removed by VMware and recovery will be to any one of the
hosts in the recovery site with a VRA installed on it. All resource pool checks are made at the level
of the VPG and does not take into account multiple VPGs using the same resource pool. If the
resource pool CPU resources are specified as unlimited in the Edit Setting dialog for the resource
pool, the actual limit is inherited from the parent but if this inherited value is too small, failover
move and failover test operations can fail, even without a warning alert being issued by Zerto
Virtual Manager.
Datastore The default datastore volume to use for all the recovered virtual machine files as well
as for their volumes. Every datastore for the selected default recovery host is included in the drop-
down options. The displayed datastores are accessible by the default host. If a cluster or resource
pool is selected for the host, only datastores that are accessible by every ESX/ESXi host in the
cluster or resource pool are displayed. Zerto Virtual Replication uses the SCSI protocol. Only
disks that support this protocol can be specified.
Failover/Move Network The default network to use during a failover or move in which the
recovered virtual machines will run.
Failover Test Network The default network to use during a test failover in which the testing
recovered virtual machines will run. This network can be a fenced-out network so as not to impact
the production network.
Add button To add a virtual machine to the VPG. Opens the Select VMs Dialog dialog.
Remove button To define a specific recovery configuration for a virtual machine in the VPG.
Configure button To configure a virtual machine recovery volumes and VNICs. Opens the
Configure VM Dialog dialog.
Boot button To specify the boot order of virtual machines in a VPG. See Boot Order Dialog, on
page 280.
Recovery scripts expansion To specify the settings for scripts to run on the recovery site before or
after executing a failover, move or test failover.
Pre-recovery Script The script to run before starting the recovery.
Post-recovery Script The script to run after the recovery.
Command to run The name of the script to run, including the full path. The script must be
located on the same machine as the Zerto Virtual Manager for the recovery site.
Params The values of any parameters to pass to the script. Separate parameters with a
space.
Timeout (sec) The time out in seconds for the script to run. If the script runs before executing
a failover, move or test failover and the script fails or a timeout value is reached, an alert is
generated and the failover, move or test failover is not performed. If the script runs after
executing a failover, move or test failover and the timeout value is reached, an alert is
generated.
VPG Name The name for the VPG, which by default is the name of the vApp.
Service Profile The name of the service profile to use which determines the VPG SLA settings for
the group, which apply to every virtual machine in the group. To change the VPG SLA settings,
select the Custom Service Profile.
Priority (QOS) Used to determine the priority for transferring data from the protected site to
the recovery site when there is limited bandwidth and more than one VPG is defined on the
protected site. When there are updates to virtual machines protected in VPGs with different
priorities, first the updates from the VPG with the highest priority are passed over the WAN.
Medium priority VPGs will only be able to use whatever bandwidth is left after the high
priority VPGs have used it. This is also true between medium and low priorities. Note that
updates to the protected virtual machines are always sent across the WAN before
synchronization data, such as during a Bitmap Sync or Delta Sync. During a
synchronization, only after updates to the virtual machines are sent over the WAN, based on
the VPG priority, is synchronization data from the VPG sent, and the synchronization data
from the VPG with the highest priority is passed over the WAN before data from medium and
low priority VPGs.
Target RPO Alert The maximum desired time between each automatic checkpoint being
written to the journal before an alert is issued. In reality checkpoints are written more
frequently.
Default Journal History The time for which all write commands are saved in the journal. Each
protected virtual machine has a dedicated journal volume on the recovery site associated with the
replicated virtual machine. This enables journal data to be maintained, even when changing the
target host for the recovery. When specifying a checkpoint to recover to, the checkpoint must still
be in the journal. For example, if the value specified here is 24 hours then recovery can be
specified to any checkpoint up to 24 hours. After the time specified, the mirror virtual disk
volumes maintained by the VRA are updated.
The more time saved the more space is required for each journal in the VPG to store the
information saved. The journal size can be configured by clicking the configuration button to
display the Manage Journal dialog.
Test Frequency Reminder The time recommended between testing the integrity of the VPG. A
warning is issued if a test is not done within this time frame.
WAN Compression (displayed when the Zerto Virtual Replication license is an enterprise
license) Whether the data is compressed before being transferred to the recovery site or not.
Compressing the data is more efficient but results in a small performance degradation.
Enable WAN compression if network considerations are more critical than CPU usage
considerations. Even if WAN compression is selected, Zerto Virtual Replication decreases the
level of compression if it takes too many resources. Zerto Virtual Replication can also work
with third-party WAN optimization and acceleration technologies, such as those supplied by
Riverbed Technologies, Silver Peak, and others. When third-party WAN optimization is
implemented, it is recommended to disable the VPG WAN compression.
ZORG (displayed when Zerto Cloud Manager is used) The Zerto organization.
Target Site The site to which you want to recover the virtual machines. The recovery site selected
in the New VPG dialog is displayed and cannot be changed here.
Target Org vDC Select the organization datacenter, as defined in vCloud Director, from the
available list.
vCD Guest Customization When checked, VMware Guest OS Customization is enabled for the
virtual machine in vCloud Director. Enabling guest customization means that the computer name
and network settings configured for this virtual machine are applied to its Guest OS when the
virtual machine is powered on.
Failover/Move Network The default Org Network to use during a failover or move in which the
recovered virtual machines will run.
Failover Test Network The default Org Network to use during a test failover in which the testing
recovered virtual machines will run.
Add button To add a virtual machine to the VPG. Opens the Select VMs Dialog dialog.
Remove button To define a specific recovery configuration for a virtual machine in the VPG.
Configure button To configure a virtual machine recovery volumes and VNICs. Opens the
Configure VM Dialog (vCD) dialog.
Boot button Displays a message that you define the boot order for vCloud Director vApps in the
vCloud Director console.
Recovery scripts expansion To specify the settings for scripts to run on the recovery site before or
after executing a failover, move or test failover.
Pre-recovery Script The script to run before starting the recovery.
Post-recovery Script The script to run after the recovery.
Command to run The name of the script to run, including the full path. The script must be
located on the same machine as the Zerto Virtual Manager for the recovery site.
Params The values of any parameters to pass to the script. Separate parameters with a
space.
Timeout (sec) The time out in seconds for the script to run. If the script runs before executing
a failover, move or test failover and the script fails or a timeout value is reached, an alert is
generated and the failover, move or test failover is not performed. If the script runs after
executing a failover, move or test failover and the timeout value is reached, an alert is
generated.
VPG Name The name for the VPG, which by default is the name of the vApp.
Service Profile The name of the service profile to use which determines the VPG SLA settings for
the group, which apply to every virtual machine in the group. To change the VPG SLA settings,
select the Custom Service Profile.
Priority (QOS) Used to determine the priority for transferring data from the protected site to
the recovery site when there is limited bandwidth and more than one VPG is defined on the
protected site. When there are updates to virtual machines protected in VPGs with different
priorities, first the updates from the VPG with the highest priority are passed over the WAN.
Medium priority VPGs will only be able to use whatever bandwidth is left after the high
priority VPGs have used it. This is also true between medium and low priorities. Note that
updates to the protected virtual machines are always sent across the WAN before
synchronization data, such as during a Bitmap Sync or Delta Sync. During a
synchronization, only after updates to the virtual machines are sent over the WAN, based on
the VPG priority, is synchronization data from the VPG sent, and the synchronization data
from the VPG with the highest priority is passed over the WAN before data from medium and
low priority VPGs.
Target RPO Alert The maximum desired time between each automatic checkpoint being
written to the journal before an alert is issued. In reality checkpoints are written more
frequently.
Default Journal History The time for which all write commands are saved in the journal. Each
protected virtual machine has a dedicated journal volume on the recovery site associated with the
replicated virtual machine. This enables journal data to be maintained, even when changing the
target host for the recovery. When specifying a checkpoint to recover to, the checkpoint must still
be in the journal. For example, if the value specified here is 24 hours then recovery can be
specified to any checkpoint up to 24 hours. After the time specified, the mirror virtual disk
volumes maintained by the VRA are updated.
The more time saved the more space is required for each journal in the VPG to store the
information saved. The journal size can be configured by clicking the configuration button to
display the Manage Journal dialog.
Test Frequency Reminder The time recommended between testing the integrity of the VPG. A
warning is issued if a test is not done within this time frame.
WAN Compression (displayed when the Zerto Virtual Replication license is an enterprise
license) Whether the data is compressed before being transferred to the recovery site or not.
Compressing the data is more efficient but results in a small performance degradation.
Enable WAN compression if network considerations are more critical than CPU usage
considerations. Even if WAN compression is selected, Zerto Virtual Replication decreases the
level of compression if it takes too many resources. Zerto Virtual Replication can also work
with third-party WAN optimization and acceleration technologies, such as those supplied by
Riverbed Technologies, Silver Peak, and others. When third-party WAN optimization is
implemented, it is recommended to disable the VPG WAN compression.
ZORG (displayed when Zerto Cloud Manager is used) The Zerto organization.
Target Site The site to which you want to recover the virtual machines. The recovery site selected
in the New VPG dialog is displayed and cannot be changed here.
Target Org vDC Select the organization datacenter, as defined in vCloud Director, from the
available list. The displayed list is that list that is specified during the vCD configuration.
vCD Guest Customization When checked, VMware Guest OS Customization is enabled for the
virtual machine in vCloud Director. Enabling guest customization means that the computer name
and network settings configured for this virtual machine are applied to its Guest OS when the
virtual machine is powered on.
Network mapping: Configure button After selecting a target Org vDC, the Configure button is
enabled. Opens the Configure Network Mapping Dialog dialog.
Configure button To configure a virtual machine recovery volumes and VNICs. Opens the
Configure VM Dialog (vCD) dialog.
Boot button Displays a message that you define the boot order for vCloud Director vApps in the
vCloud Director console.
Recovery scripts expansion To specify the settings for scripts to run on the recovery site before or
after executing a failover, move or test failover.
Pre-recovery Script The script to run before starting the recovery.
Post-recovery Script The script to run after the recovery.
Command to run The name of the script to run, including the full path. The script must be
located on the same machine as the Zerto Virtual Manager for the recovery site.
Params The values of any parameters to pass to the script. Separate parameters with a
space.
Timeout (sec) The time out in seconds for the script to run. If the script runs before executing
a failover, move or test failover and the script fails or a timeout value is reached, an alert is
generated and the failover, move or test failover is not performed. If the script runs after
executing a failover, move or test failover and the timeout value is reached, an alert is
generated.
When the protected site has vCloud Director installed, you can protect vCD vApps.
ZORG A Zerto organization defined in Zerto Cloud Manager.
Underlying vCenter Server The virtual machines to be protected will be selected from the
underlying vCenter Server.
vCD vApp A vCD vApp from the list should be protected.
Recovery site is vCD The selected recovery site has vCloud Director installed.
To create a clone of each virtual machine in a VPG on the recovery site in the production network.
The clone is a copy of the protected virtual machines on the recovery site, while the virtual
machines on the protected site remain protected and live.
Configure Checkpoint button Opens the Select Recovery Point Dialog dialog to select the
checkpoint to which to make the clone.
Target Datastore Select the datastore to use for the target virtual machines.
Information about how much data is actually being protected against the amount configured for
any of the sites.
Note: The data displayed can be up to 30 minutes old, since the Zerto Virtual Manager collects the
relevant data every 30 minutes.
You can filter the information by the following:
From and To The dates for which you want information.
Target Site Select the site for which you want information displayed or for all the sites. If all the
sites are selected, All Sites is displayed for the field. The list displays all sites paired with the
local site.
Apply button To apply the filtering selected via any of the above fields.
Pause Dialog
During periods when the WAN bandwidth is utilized to its maximum, you can pause the
protection of a VPG, to free-up some of this bandwidth. After pausing the protection, the VPG can
still be recovered, to the last checkpoint written to the journal before the pause operation.
Dir The direction of the protection, assuming the local site is to the left of the arrow.
Local Site Display VPGs that are protected on the local site.
Remote Site Display VPGs that are protected on the remote sites.
Show All Display all VGS protected on both the local site and all remote sites.
Information about the virtual machines and amount of data on the recovery site.
Note: The data displayed can be up to 30 minutes old, since the Zerto Virtual Manager collects the
relevant data every 30 minutes.
You can filter the information by the following:
From and To The dates for which you want the information.
Source Site Select the sites for which you want information displayed. If more than one site is
selected, Multiple Selection is displayed for the field. The list displays all sites paired with
the local site.
Resolution Select the resolution for the report: daily, weekly, monthly or All.
Apply button To apply the filtering selected via any of the above fields.
Reset button To reset the display to the defaults values.
An audit of recent actions for a specific VPG from within the VPG details.
Time and Date The date and time of the action.
User The users who initiated the event and the location of the user.
Description A description of the event. Clicking More displays the full description and can be
used when the displayed description is truncated.
Recovery Reports
Information about recovery operations, failover tests, moves and failovers. The information
includes the protected and recovery sites involved, when the recovery operation was started, the
time taken to bring up the machines in the recovery site, the RTO, and whether the operation
succeeded or not and any notes added during a failover test.
You can filter the tests by the following:
From and To The dates for which you want test information. Only tests performed, between
these dates are displayed.
VPG Select the VPGs for which you want test information displayed. If more than one VPG is
selected, Multiple Selection is displayed for the field. The list displays all VPGs that have
been tested.
Type Select the recovery operations for which you want information displayed: Failover, Move,
Failover Test. If more than one operation is selected, Multiple Selection is displayed for
the field.
Status Select the Statuses for which you want test information displayed: Success, Failed. If
more than one status is selected, Multiple Selection is displayed for the field.
Apply button To apply the filtering selected via any of the above fields.
Protected Site The site protecting the virtual machines in the VPG.
Recovery Site The site where the virtual machines in the VPG are recovered.
Resource Report
Resource information about the virtual machines being protected to a recovery site. The
information is collected at fixed times as defined in the Resource Reports section of the Advanced
Settings dialog. The report collects the resource information in the recovery site. For resource
information about the virtual machines being recovered, the sampling period must be specified in
the Advanced Settings dialog on the recovery site and the report must be generated from the
recovery site.
You can filter the information by the following:
From and To The dates for which you want information.
Note: If there are no samples to use to generate a report, the From and To data fields and
Generate to XLSX file button and not displayed.
Resume Dialog
Resuming the protection of paused VPGs, described in Pause Dialog, on page 310.
Dir The direction of the protection, assuming the local site is to the left of the arrow.
Local Site Display VPGs that are protected on the local site.
Remote Site Display VPGs that are protected on the remote sites.
Show All Display all VGS protected on both the local site and all remote sites.
Open Selection Window button Displays a bigger selection of checkpoints, particularly the most
recent checkpoints. The further back you go, the more spaced out are the checkpoints to enable a
greater range.
You provide information about the site during installation, to make it easier to identify the site in
the user interface and to identify the contact person at the site. After installation you can updated
these settings.
Site Name The name used to identify the site.
Site Location Information such as the address of the site or a significant name to identify it.
Contact Name the name of the person to contact if a need arises.
User Name The administrator name used to access the vCenter Server. If the user name to
access the vCenter Server from the Zerto Virtual Manager changes, specify the new name. The
name can be entered using either of the following formats:
username
domain\username
Password The password used to access the vCenter Server for the given user name. If the
password to access the vCenter Server from the Zerto Virtual Manager changes, specify the new
password. To ensure security, after saving the settings, the password field is cleared.
Sites Tab
# Used VMs The total number of virtual machines being protected by the site and replicated to
the site.
Location The location specified for the paired site during installation or in the Site
Configuration dialog.
Provisioned Storage The maximum storage that can be protected.
IO The IO per second between all the applications running on the virtual machine in the VPG
and the VRA that sends a copy to the remote site for replication.
Incoming Throughput The MBs for all the applications running on the virtual machine being
protected. There can be a high IO rate with lots of small writes resulting in a small throughput as
well as a small IO with a large throughput. Thus, both the IO and Incoming Throughput values
together provide a more accurate indication of performance.
Filtering Information
You can filter the list so that you can easily identify sites.
You can filter columns by clicking the filter icon and typing part of the value. The filter changes
color from grey to blue when a filter is applied. A link in the filter area enables clearing the filter.
Determining Which Columns to Display and the Order They Are Displayed
Right-clicking in the list enables selecting the Edit Columns dialog, where you can specify what
columns to display in the list.
You can also drag-and-drop column headers to rearrange the order the columns are displayed. A
thick vertical bar shows where a column can be dragged and dropped.
You can also reset the display to the default display by right-clicking in the list and selecting the
Reset Columns item.
When an event occurs, for example the host machine crashes or the VRA or a shadow VRA is
accidentally deleted, if the VRA has shared storage disks that are accessible by other hosts in the
site, you can copy these disks to another VRA in the site. The VRA is represented in the Manage
VRAs dialog as a ghost VRA.
Target for Original Maintenance Host The target host for maintenance. The VRA recovery data is
transferred to the selected host, however after the transfer completes the VRA maintenance
status does not change.
Displays details of VPGs being tested and enables stopping the testing of selected VPGs.
VPG Name The name of a VPG.
Checkpoint The timestamp of the checkpoint used as the recovery point for the test.
Stop Selected button Stops the testing of selected VPGs. After stopping a test, the virtual
machines in the recovery site are powered off and then removed and the checkpoint that was used
for the test has the following tag added to identify the test:
Tested at startDateAndTimeOfTest(OriginalCheckpoint_DateAndTime).
Summary Tab
The amount of storage being replicated to this site from remote sites.
The following information is displayed in the right area:
If the pairing is to one site only, the site name and IP address of the Zerto Virtual Manager for
the paired site, otherwise, the title Multiple Peers.
The number of virtual machines meeting the target RPO, the SLA, out of the total number of
virtual machines included in VPGs protected on the remote sites.
The number of VPGs meeting the target RPO, the SLA, out of the total number of VPGs
protected on the remote sites.
The amount of storage being replicated out of the total possible for all the virtual machines in
all the VPGs protected on the remote sites.
The amount of recovery storage being replicated to the remote sites, which includes both the
journal and target disk sizes.
To throttle the bandwidth for specific times. For example, during the daily peak transaction
period you can change the specific throttling of the bandwidth, to override the general throttling,
described in Advanced Settings Dialog, on page 277.
Max Bandwidth
Slider Set the Mb/sec. The valid range is from Auto to 99 Mb/sec. With Auto, Zerto Virtual
Replication automatically assigns the bandwidth used per VPG, based on using the maximum
available and then prioritizing the usage according to priority set for the VPGs sending data
over the WAN.
Text box The Mb/sec. when the value required is 100 Mb/sec. or more.
From The start time for the throttling, the hour, using a 24-hour clock, and the minute.
To The end time for the throttling, the hour, using a 24-hour clock, and the minute.
Topology Tab
Graphically displays the sites and details about the sites, including the number of VPGs and
virtual machines being protected. Hovering the mouse over a site displays the IP address for that
site.
You can refresh the display and make the display larger or smaller using the slider.
Clicking on a site selects that site and details of the selected site are displayed in the Selected
Site Details pane.
The alert status indicator shows the alert status of the site:
Green The site VPGs are being replicated, including syncing the VPGs between the sites.
Orange The VPG is being replicated but there are problems, such as an RPO value larger than
the Target RPO Alert value specified for the VPG.
Red The site VPGs are not being replicated, for example because communication with the
remote site is down.
Usage Report
Information about usage. The information is organized by organization and within each
organization by site and then VPG and then the virtual machines in each VPG.
You can filter the information by the following:
Year The year of interest.
Month Select the month to review. You can also see, under the month, the virtual machine count
for each day in the month.
The usage report displays for each month the number of virtual machines protected during the
month and the average number per day in the month. For example, if fifteen virtual machines are
protected in a few VPGs starting on the 28th of the month in a thirty day month, the total days
will be 30 (two days multiplied by fifteen machines) and the VM Count will be 1 (Total days
divided by the number of days in the month).
Export to CSV button To save the report as a CSV file.
Export to Zip button To save the report as zipped CSV and PDF files in a zip file.
VMs Tab
VM Name The name of the virtual machine. The name is a link: Click on the VM name to drill-
down to more specific details about the VPG for that VM, displayed in a dynamic tab.
VPG Name The name of the VPG. The name is a link: Click on the name to drill-down to more
specific details about the VPG, displayed in a dynamic tab.
IO The IO per second between all the applications running on the virtual machines in the VPG
and the VRA that sends a copy to the remote site for replication.
Throughput The MBs for all the applications running on the virtual machines being protected.
There can be a high IO rate with lots of small writes resulting in a small throughput as well as a
small IO with a large throughput. Thus, both the IOPS and Throughput values together provide
a more accurate indication of performance.
Network The amount of WAN traffic.
Provisioned Storage The provisioned storage for all the virtual machines in the VPG. This value
is the sum of the values that are used in the vCenter Server and displayed in the vSphere Client
console per virtual machine in the Virtual Machines tab for the root vCenter Server node. Each
value is the sum of both the hard disk and memory. Thus, a virtual machine with 1GB hard disk
and 4GB memory will show 5GB provisioned storage.
Used Storage The storage used by all of the virtual machines in the VPG. This value is the sum
of the values that are used in the vCenter Server and displayed in the vSphere Client console per
virtual machine in the Virtual Machines tab for the root vCenter Server node.
Actual RPO The time since the last checkpoint was written to the journal. This should be less
than the Target RPO Alert value specified for the VPG.
Status The current status of the VPG, such as Updating, Syncing, Protecting. Where
appropriate, the percentage of the operation completed, such as syncing, is displayed.
Last Test The date and time of the last failover test performed on this VPG.
Direction (not shown by default) The direction of the replication, from this site to the remote site
or from the remote site to this site.
Type (not shown by default) Icons describing the source and target sites:
vCenter Server to vCenter Server.
vCenter Server to vCloud Director.
vCloud Director to vCenter Server.
vCloud Director to vCloud Director.
Source Site (not shown by default) The name of the site where the VPG is protected.
Target Site (not shown by default) The name recovery site for the VPG.
ZORG Name (not shown by default) The ZORG name given to the organization by a cloud service
provider.
Priority (not shown by default) The priority specified for the VPG in its definition.
Filtering Information
You can filter the list so that you can easily identify sites.
You can filter columns by clicking the filter icon and typing part of the value. The filter changes
color from grey to blue when a filter is applied. A link in the filter area enables clearing the filter.
Determining Which Columns to Display and the Order They Are Displayed
Right-clicking in the list enables selecting the Edit Columns dialog, where you can specify what
columns to display in the list.
You can also drag-and-drop column headers to rearrange the order the columns are displayed. A
thick vertical bar shows where a column can be dragged and dropped.
You can also reset the display to the default display by right-clicking in the list and selecting the
Reset Columns item.
VPGs Tab
Details of the VPGs from both the local and remote sites.
Right-clicking in the list enables selecting the Edit Columns dialog, where you can specify what
columns to display in the list. You can also drag-and-drop column headers to rearrange the order
the columns are displayed. A thick vertical bar shows where a column can be dragged and
dropped. You can also reset the display to the default display by clicking the Reset Columns
link.
You can filter the list so that you can easily identify the VPGs and virtual machines you want to
monitor. You can filter columns by clicking the filter icon and then either by typing part of the
value only, for example with the Source Site field, or you can filter using actual values, for
example with the Priority field. The filter changes color from grey to blue when a filter is
applied. A link in the filter area enables clearing the filter.
Alert status indicator The color indicates the alert status of the VPG:
Green The VPG is being replicated, including syncing the VPG between the sites.
Orange The VPG is being replicated but there are problems, such as an RPO value larger
than the Target RPO Alert value specified for the VPG.
Red The VPG is not being replicated, for example because communication with the remote
site is down.
Direction The direction of the replication, from this site to the remote site or from the remote site
to this site.
Name The name of the VPG. The name is a link: Click on the VPG name to drill-down to more
specific details about the VPG displayed in a dynamic tab.
Func Icons you click to perform further actions, such as editing or deleting the VPG.
Source Site The name of the site where the VPG is protected.
Actual RPO The time since the last checkpoint was written to the journal. This should be less
than the Target RPO Alert value specified for the VPG.
Status The current status of the VPG, such as Updating, Syncing, Protecting. Where
appropriate, the percentage of the operation completed, such as syncing, is displayed.
Last Test The date and time of the last failover test performed on this VPG.
Type (not shown by default) Icons describing the source and target sites:
vCenter Server to vCenter Server.
vCenter Server to vCloud Director.
vCloud Director to vCenter Server.
vCloud Director to vCloud Director.
Organization (not shown by default) The ZORG name given to the organization by a cloud service
provider in Zerto Cloud Manager.
Provisioned Storage (not shown by default) The provisioned storage for all the virtual machines
in the VPG. This value is the sum of the values that are used in the vCenter Server and displayed
in the vSphere Client console per virtual machine in the Virtual Machines tab for the root
vCenter Server node. Each value is the sum of both the hard disk and memory. Thus, a virtual
machine with 1GB hard disk and 4GB memory will show 5GB provisioned storage.
Used Storage (not shown by default) The storage used by all of the virtual machines in the VPG.
This value is the sum of the values that are used in the vCenter Server and displayed in the
vSphere Client console per virtual machine in the Virtual Machines tab for the root vCenter
Server node.
IO (not shown by default) The IO per second between all the applications running on the virtual
machines in the VPG and the VRA that sends a copy to the remote site for replication.
Throughput (not shown by default) The MBs for all the applications running on the virtual
machines being protected. There can be a high IO rate with lots of small writes resulting in a
small throughput as well as a small IO with a large throughput. Thus, both the IOPS and
Throughput values together provide a more accurate indication of performance.
Network (not shown by default) The amount of WAN traffic.
Actions: Export CSV Saves details of every displayed VPG to a CSV file, which can be opened
using programs such as Microsoft Excel.
Actions: Pause Opens the Pause Dialog dialog.
Filtering Information
You can filter the list so that you can easily identify sites.
You can filter columns by clicking the filter icon and typing part of the value. The filter changes
color from grey to blue when a filter is applied. A link in the filter area enables clearing the filter.
Determining Which Columns to Display and the Order They Are Displayed
Right-clicking in the list enables selecting the Edit Columns dialog, where you can specify what
columns to display in the list.
You can also drag-and-drop column headers to rearrange the order the columns are displayed. A
thick vertical bar shows where a column can be dragged and dropped.
You can also reset the display to the default display by right-clicking in the list and selecting the
Reset Columns item.
VRAs Tab
All the hosts in the local vCenter and details of VRAs for each host, when installed.
Host Address The ESX/ESXi host IP address for the VRA. If the host is part of a cluster, the
cluster name is displayed with the hosts under the cluster.
Host Version The ESX/ESXi version.
Alert status indicator The color indicates the alert status of the VRA:
Green The VRA is functioning as required.
Orange The VRA is functioning, but as well as is require.
Red There is a problem with the VRA, for example communication with the Zerto Virtual
Manager is down.
VRA Name The name of the VRA virtual machine.
VRA Status The VRA status. For example, Installed, Ghost VRA.
VRA Version Either Latest if the version installed is the most current version or Outdated if it
can be upgraded. A tooltip displays the actual version.
VRA Group The group of VRAs to which this VRA belongs. VRAs can be grouped together when
they use different networks so they can be grouped by network, for example when the same
vCenter Server supports two datacenters with separate networks and you are replicating from
one datacenter to the second datacenter.
# VPGs The number of VPGs with a virtual machine for which the VRA either manages the
protection or the recovery of its data.
# VMs The number of virtual machines for which the VRA either manages the protection or the
recovery of its data.
You can limit the display to hosts with VRAs installed via the Show hosts without a VRA installed
toggle. When this toggle is set to On all hosts are displayed, and when set to Off only hosts with a
VRA installed are displayed.
Click Export to save the VRA list as a Microsoft Excel worksheet.
Filtering Information
You can filter the list of VRAs in the VRAs tab.
You can filter columns by clicking the filter icon and then either by typing part of the value only,
for example with the VRA Group field, or you can filter using actual values, for example with the
#VPGs field. The filter changes color from grey to blue when a filter is applied. A link in the filter
area enables clearing the filter.
Determining Which Columns to Display and the Order They Are Displayed
Right-clicking in the list enables selecting the Edit Columns dialog, where you can specify what
columns to display in the list.
You can also drag-and-drop column headers to rearrange the order the columns are displayed. A
thick vertical bar shows where a column can be dragged and dropped.
You can also reset the display to the default display by right-clicking in the list and selecting the
Reset Columns item.
The Zerto license includes information such as the license expiry date.
License The license key itself.
License Type What is licensed, for example, whether the license is for a cloud service provider
and whether the license restricts the number of virtual machines that can be protected or the
number of sockets used.
Expiry Date The license expiry date.
Quantity The maximum amount licensed, either virtual machines or sockets, based on the license
type. If blank, the quantity is unlimited.
Max Sites The maximum number of sites allowed.
Business Continuity & Disaster Recovery (BC/ DR) An organizations ability to recover from a
disaster and/or unexpected event and resume or continue operations. Organizations should have
a plan in place that outlines how this will be accomplished. The key metrics to be measured in a
disaster recovery environment are the Recovery Time Objective (RTO) and Recovery Point
Objective (RPO).
Checkpoint Zerto Virtual Replication ensures crash consistency by writing checkpoints to the
journal every few seconds. These checkpoints ensure write order fidelity and crash-consistency to
each checkpoint. During recovery you pick one of these crash-consistent checkpoints and recover
to this point. Additionally, checkpoints can be manually added by the administrator, with a
description of the checkpoint. For example, when an event is going to take place that might result
in the need to perform a recovery, you can pinpoint when this event occurs as a checkpoint in each
journal.
Disaster Recovery as a Service (DRaaS) In a DRaaS scenario, the customer may manage and have
complete control over the production data or the Cloud Service Provider (CSP) may provide a
partial or complete managed service. In either case, the CSP must ensure the availability of the
data and adapt as the customers infrastructure changes.
DRS Enables balancing computing workloads with available resources in a cluster. DRS is
automatically disabled by Zerto Virtual Replication while updating recovered virtual machines in
the recovery site from the journal for these recovered virtual machines. After the promotion of the
data from the journal to the recovered virtual machine completes, DRS is automatically re-
enabled. If DRS is disabled for the site, VMware removes all resource pools in the site. If the
recovery was defined to a resource pool, recovery will be to any one of the hosts in the recovery
site with a VRA installed on it.
ESX/ESXi Bare-metal hypervisors from VMware, meaning they install directly on top of the
physical server and partitions it into multiple virtual machines that can run simultaneously,
sharing the physical resources of the underlying server. ESXi is the most recent version.
High Availability (VMHA) VMware high availability decreases downtime and improves reliability
with business continuity by enabling another ESX/ESXi host to start up virtual machines that
were running on another ESX/ESXi host that went down. High availability is automatically
disabled by Zerto Virtual Replication while updating recovered virtual machines in the recovery
site from the VRA journal. After the promotion of the data from the journal to the virtual machine
completes, high availability is automatically re-enabled. The HA configuration can include
admission control to prevent virtual machines being started if they violate availability
constraints. If this is the case, then a failover, test failover or migration of the virtual machines in
327
a VPG to the cluster with this configuration will fail, if the availability constraints are violated
when the virtual machines are recovered.
Hypervisor The host for multiple VMs in a virtualized environment. ESX / ESXi is the VMware
brand hypervisor. The hypervisor is the virtualization architecture layer that allows multiple
operating systems, termed guests, to run concurrently on a host computer.
I/O (input/output) describes any operation, program, or device that transfers data to or from a
computer. Typical I/O devices are printers, hard disks, keyboards, and mouses. In fact, some
devices are basically input-only devices (keyboards and mouses); others are primarily output-only
devices (printers); and others provide both input and output of data (hard disks, diskettes,
writable CD-ROMs). In computer architecture, the combination of the CPU and main memory
(i.e. memory that the CPU can read and write to directly, with individual instructions) is
considered the brain of a computer, and from that point of view any transfer of information from
or to that combination, for example to or from a disk drive, is considered I/O.
In-Cloud DR (ICDR) When customers leverage an ICDR service, the CSP hosts the production and
DR sites. The virtual machines (VMs) are typically replicated from one CSP datacenter to another
CSP datacenter as a managed service or as managed co-located datacenters. The customers have
the ability to interact with their applications as if they were locally hosted.
iSCSI An Internet Protocol (IP)-based storage networking standard for linking data storage
facilities. By carrying SCSI commands over IP networks, iSCSI is used to facilitate data transfers
over intranets and to manage storage over long distances.
Journal Every write to a protected virtual machine is intercepted by Zerto Virtual Replication
and a copy of the write is sent, asynchronously, to the recovery site, while the write continues to
be processed on the protected site. On the recovery site the write is written to a journal managed
by the Virtual Replication Appliance. Each protected virtual machine has its own journal.
LUN Disk drives are the foundation of data storage, but operating systems cannot use physical
disk storage directly. The platters, heads, tracks and sectors of a physical disk drive must be
translated into a logical space, which an OS sees as a linear address space comprised of fixed-size
blocks. This translation creates a logical entity that allows OSes to read/write files. Storage
networks must also partition their physical disks into logical entities so that host servers can
access storage area network (SAN) storage. Each logical portion is called a logical unit number
(LUN). A LUN is a logical entity that converts raw physical disk space into logical storage space,
which a host server's OS can access and use. Any computer user recognizes the logical drive letter
that has been carved out of their disk drive. For example, a computer may boot from the C: drive
and access file data from a different D: drive. LUNs do the same basic job.
NAS A network-attached storage (NAS) device is a server that is dedicated to nothing more than
file sharing. NAS does not provide any of the activities that a server in a server-centric system
typically provides, such as e-mail, authentication or file management. NAS allows more hard disk
storage space to be added to a network that already utilizes servers without shutting them down
for maintenance and upgrades. With a NAS device, storage is not an integral part of the server.
Instead, in this storage-centric design, the server still handles all of the processing of data but a
328
NAS device delivers the data to the user. A NAS device does not need to be located within the
server but can exist anywhere in a LAN and can be made up of multiple networked NAS devices.
Pair Zerto Virtual Replication can be installed at multiple sites and each of these sites can
connect to any of the other sites enabling enterprises to protect virtual machines across multiple
vCenters. Two sites connected to each other are paired.
Quiesce Pausing or altering the state of running processes on a computer, particularly those
that might modify information stored on disk during a backup, in order to guarantee a consistent
and usable backup.
Replication, asynchronous Technique for replicating data between databases (or file systems)
where the system being replicated does not wait for the data to have been recorded on the
duplicate system before proceeding. Asynchronous Replication has the advantage of speed, at the
increased risk of data loss during due to communication or duplicate system failure.
Replication, synchronous Technique for replicating data between databases (or file systems)
where the system being replicated does wait for the data to have been recorded on the duplicate
system before proceeding. Synchronous Replication has the advantage that it is guaranteed that
the duplicate system has a copy of the data, but the disadvantage that the primary system must
wait for the secondary system before proceeding, leading to an increased response time. Because
of the increased response time and communication delays, synchronous replication is often
impractical unless the secondary system is physically located close to the primary system.
Replication to Self When a single vCenter is used, for example with remote branch offices, when
replicating from one datacenter to another datacenter, both managed by the same vCenter
Server, you have to enable replication to the same vCenter Server and pairing is not required.
RPO Refers to the amount of data at risk, measured by the amount of time between data
protection events. The metric is an indication of the amount of data at risk of being lost.
RTO Related to downtime. The metric refers to the amount of time it takes to recover from a
data loss event and how long it takes to return to service. The metric is an indication of the
amount of time the system's data is unavailable or inaccessible, thus preventing normal service.
SAN A storage area network (SAN) is any high-performance network whose primary purpose is
to enable storage devices to communicate with computer systems and with each other. A storage
device is a machine that contains nothing but a disk or disks for storing data. A SAN's
architecture works in a way that makes all storage devices available to all servers on a LAN or
WAN. As more storage devices are added to a SAN, they too will be accessible from any server in
the larger network. In this case, the server merely acts as a pathway between the end user and
the stored data. Because stored data does not reside directly on any of a network's servers, server
power is utilized for business applications, and network capacity is released to the end user.
Service Profile A predefined set of default properties to use when VPGs are defined or edited.
Zerto provides a default service profile and the option for the organization to specify their own
requirements. The cloud service provider can define service profiles to manage specific service
level agreements (SLAs) with its customers.
Snapshots A snapshot is a block device which presents an exact copy of a logical volume, frozen
at some point in time. Typically this would be used when some batch processing, a backup for
instance, needs to be performed on the logical volume, but you don't want to halt a live system
that is changing the data. Zerto does NOT use a snapshot mechanism, but is constantly
replicating data writes.
Virtual Replication Appliance (VRA) A virtual machine installed on each ESX/ESXi hosting virtual
machines to be protected or recovered, to manage the replication of data from protected virtual
machines to the recovery site.
VM, Virtual Machine A virtual machine (VM) is an environment, usually a program or operating
system, which does not physically exist but is created within another environment. In this
context, a VM is called a guest while the environment it runs within is called a host.
VMDK, Virtual Machine Disk Virtual Machines created with VMware products typically use virtual
disks. The virtual disks, stored as files on the host computer or remote storage device, appear to
the guest operating systems as standard disk drives.
VPG, Virtual Protection Group Virtual machines are protected in virtual protection groups. A
virtual protection groups (VPG) is a group of virtual machines that you want to group together for
replication purposes. For example, the virtual machines that comprise an application like
Microsoft Exchange, where one virtual machine is used for the software, one for the database and
a third for the Web Server, require that all three virtual machines are replicated to maintain data
integrity.
VRA, Virtual Replication Appliance A Zerto Virtual Replication virtual machine that manages the
replication of virtual machines across sites. A VRA must be installed on every ESX/ESXi which
hosts virtual machines that require protecting in the protected site and on every ESX/ESXi that
will host the replicated virtual machines in the recovery site.
Zerto Cloud Connector (ZCC) A virtual machine installed on the cloud side, one for each customer
organization replication network. The Zerto Cloud Connector requires both cloud-facing and
customer-facing static IP addresses. The ZCC routes traffic between the customer network and
the cloud replication network, in a secure manner ensuring complete separation between the
customer network and the cloud service provider network. The ZCC has two Ethernet interfaces,
one to the customers network and one to the cloud service provider's network. Within the cloud
connector a bidirectional connection is created between the customer and cloud service provider
networks. Thus, all network traffic passes through the ZCC, where the incoming traffic on the
A clone
advanced settings ................................. 88, 277 what is ...................................................204
commit policy .......................................... 90 cloning ..........................................................131
configure notifications ............................ 91 commit policy
enable replication to self .................. 72, 89 advanced settings ....................................90
RPO ......................................................... 89 failover and move ....................................90
script execution timeout ......................... 89 configuration
Throughput ............................................. 89 virtual protection group ..........................25
VRA Local Memory ................................ 89 configure notifications
VRA Remote Memory ............................. 89 advanced settings ....................................91
WAN Traffic ............................................ 89 crash consistency
alarms .......................................................... 257 VSS ........................................................135
alerts create
email notifications .................................. 91 virtual protection group ..........................25
AMQP
Erlang OTP ........................................... 286 D
installation ............................................ 286 datastore maintenance ................................156
RabbitMQ .............................................. 286 ddb.geometry.biosSectors ..............................26
application consistency ddb.geometry.sectors .....................................26
VSS ........................................................ 135 diagnostics utility ........................................246
architecture ................................................... 13 disaster recovery ..........................................209
during a test ..........................................222
B initiating ................................................211
bandwidth ............................................. 88, 277 disk geometry .................................................26
advanced settings ........................... 88, 277 disk size
bitmap estimating ..........................................36, 51
synchronization ...................................... 18 disk space .....................................................246
WAN resilience ....................................... 18 promotion hangs ....................................246
bitmap sync ................................................. 153
E
C edit VRA host passwords .............................162
change rate edit VRA network settings ..........................161
estimating ......................................... 36, 51 email
checkpoint ..................................................... 15 advanced settings ....................................91
add ......................................................... 133 enable replication to self
advanced settings ..............................72, 89
332
environment variable ................................. 143 L
ZertoForce ............................................. 143 license ...........................................................234
ZertoOperation ..................................... 143 logs ................................................................255
ZertoVCenterIP .................................... 143 collecting logs ........................................247
ZertoVCenterPort ................................. 143 when adding VSS checkpoint ...............254
ZertoVPGName .................................... 143
export to CSV M
virtual protection group ......................... 98 maintenance
datastore ................................................156
F host .........................................................168
failback migration
move ...................................................... 199 see move
failover ................................................. 209, 216 modify volumes ............................................125
commit policy .......................................... 90 RDM .......................................................125
during a test ......................................... 222 monitor ...........................................................93
initiating ............................................... 211 site details ...............................................94
process ................................................... 209 site topology ...........................................111
scratch volume ...................................... 216 sites ........................................................111
stop testing ........................................... 187 topology ..................................................113
testing ................................................... 181 virtual machines ...................................104
failover test ................................................. 185 virtual protection group ..........................98
scratch volume ...................................... 185 virtual protection groups ........................96
failover tests virtual replication appliance ................109
report ..................................................... 226 VPGs tab ..................................................96
failovers move .............................................................201
report ..................................................... 226 commit policy ...........................................90
force delete .......................................... 132, 153 failback ..................................................199
initiating ................................................198
G reverse replication .................................199
geometry .................................... 26, 38, 53, 119 scratch volume ......................................201
Ghost VRA ................................................... 166 what is ...................................................196
moves
H report .....................................................226
host not displayed in Manage VPG dialog 245
N
I Needs Configuration ............................121, 125
IDE device ..................................................... 26 needs configuration .....................................152
information for a site .................................... 84 troubleshooting ......................................244
network mapping
J vCD ..........................................................67
journal ................. 14, 30, 46, 66, 302, 305, 307 new virtual protection group .........................25
add checkpoint ...................................... 133
333
P recovery volume
Pending Remove preseed ...........................37, 52, 62, 69, 118
force delete .................................... 132, 153 raw device mapping (RDM) ......37, 52, 118
Permissions ........................................... 76, 241 swap ...............................37, 52, 62, 69, 118
point-in-time registration ..................................................234
add checkpoint ...................................... 133 remove Virtual Replication Appliances ......165
Preseed ............................................ 37, 52, 118 Replication Pause Time ...............................130
preseed ....................................... 26, 38, 53, 119 replication to self .....................................72, 89
recovery volume ............ 37, 52, 62, 69, 118 report
process failover tests ..........................................226
clone ...................................................... 204 failovers .................................................226
failover .................................................. 209 moves .....................................................226
move protection over time by organization ...225
test failover ........................................... 181 recovery ..................................................226
promotion hangs ......................................... 246 resources report .....................................227
protect usage ......................................................231
see virtual protection group VPG performance ..................................232
protection over time by organization resize volumes ..............................................125
report ..................................................... 225 RDM .......................................................125
provisioned resources report ...........................................227
storage ............................... 75, 97, 105, 320 reverse replication
provisioned storage ....................................... 75 move .......................................................199
RPO
R advanced settings ....................................89
RabbitMQ
Erlang OTP ........................................... 286 S
installation ............................................ 286 same site replication ......................................72
raw device mapping (RDM) scratch volume .............................185, 201, 216
recovery volume ........................ 37, 52, 118 scripts
raw disk execution timeout
recovery volume ........................ 37, 52, 118 advanced settings .............................89
Raw Disk (RDM) ............................. 37, 52, 118 ZertoForce environment variable .........143
RDM ................................................. 37, 52, 118 ZertoOperation environment variable .143
modifying .............................................. 125 ZertoVCenterIP environment variable 143
RDM (raw device mapping) ZertoVCenterPort environment variable ...
recovery volume ........................ 37, 52, 118 143
recovery ....................................................... 209 ZertoVPGName environment variable 143
during a test ......................................... 222 self replication .........................................72, 89
initiating ............................................... 211 shadow VRA
report ..................................................... 226 Virtual Replication Appliance ..............159
recovery data size ......................................... 99 signature matching
recovery storage .................................... 95, 318 WAN optimization ...................................18
334
site details triggers
monitoring .............................................. 94 synchronization .....................................151
site information ............................................. 84 VPG synchronization ............................155
site topology ................................................ 111 troubleshooting
sites tab ....................................................... 111 disk space ..............................................246
sizing host not displayed in Manage VPG dialog .
volumes ............................................. 36, 51 245
WAN ........................................................ 78 Virtual Replication Appliance crashes dur-
status ing promotion ...........................246
VPG ....................................................... 151 Zerto Virtual Manager service .............243
stop
testing ................................................... 187 U
storage uninstall Virtual Replication Appliances ...165
provisioned ........................ 75, 97, 105, 320 upgrade
summary tab ................................................. 94 Virtual Replication Appliance ..............160
swap ......................................................... 62, 69 upgrading .....................................................160
swap disk usage
recovery volume ............ 37, 52, 62, 69, 118 report .....................................................231
synchronization
bitmap ..................................................... 18 V
synchronization triggers vApp .......................................................43, 236
virtual protection group ....................... 151 vCD
VPG ....................................................... 155 network mapping ....................................67
virtual machine
T modify RDM ..........................................125
test modify volumes ......................................125
failover .................................................. 181 monitoring .............................................104
initiating failover .................................. 222 protect ......................................................41
stopping ................................................. 187 virtual protection group
virtual protection group ....................... 181 add machine ..........................................114
test failover ................................................. 181 via virtual machine node ..................41
process ................................................... 181 via VPG definition ..........................115
test scratch volume ..................................... 185 cloning ....................................................131
thin provisioning ......................................... 237 creating ....................................................25
throttling delete ......................................................131
advanced settings ........................... 88, 277 for a single virtual machine ....................41
Throughput modify ....................................................122
advanced settings ................................... 89 monitoring ...............................................98
time-based bandwidth throttling saving details to file ................................98
advanced settings ................................... 88 synchronization triggers .......................151
topology tab ......................................... 111, 113 synchronize ............................................129
testing ....................................................181
335
virtual protection groups VSS .......................................................132, 135
monitoring .............................................. 96 application consistency .........................135
Virtual Replication Appliance crash consistency ...................................135
crash during promotion ........................ 246 logs .........................................................254
edit host password ................................ 162 vStorage
edit network settings ............................ 161 thin provisioning ...................................237
shadow VRA .......................................... 159
uninstall ................................................ 165 W
upgrade ................................................. 160 WAN
virtual replication appliance bitmap sync .............................................18
monitoring ............................................ 109 signature matching .................................18
VirtualEthernetCardLegacyNetworkBack- sizing ........................................................78
ingInfo ........................................................... 26 WAN Traffic
vMotion ........................................................ 240 advanced settings ....................................89
VMware host maintenance ......................... 168 Windows service
volume Zerto Virtual Manager ..........................243
estimating size .................................. 36, 51
preseed .......................... 37, 52, 62, 69, 118 Z
raw device mapping (RDM) ..... 37, 52, 118 Zerto standalone UI .......................................19
swap .......................................... 37, 52, 118 Zerto Virtual Manager
Volume Shadow Copy Service ............ 132, 135 Windows service ....................................243
logs ........................................................ 254 Zerto Virtual Replication
VPG architecture .............................................13
see virtual protection group benefits ....................................................15
Synchronization triggers ...................... 155 how it works ............................................14
VPG performance logs .........................................................255
report ..................................................... 232 monitoring ...............................................93
VPG status what is .....................................................12
Pending Remove ........................... 132, 153 ZertoForce
VPG statuses ............................................... 151 script ......................................................143
VPGs tab ZertoOperation
monitoring .............................................. 96 script ......................................................143
VRA .............................................................. 160 ZertoVCenterIP
edit network settings ............................ 161 script ......................................................143
monitoring ............................................ 109 ZertoVCenterPort
VRA Local Memory script ......................................................143
advanced settings ................................... 89 ZertoVPGName
VRA Remote Memory script ......................................................143
advanced settings ................................... 89
336