Zerto Virtual Replication Administration Guide

Zerto Virtual Replication
Administration Guide
Version 2.0U3
ZVR-AG-2.0U3-01-20-12-12
Copyright 2012, 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-AG-2.0U3-01-20-12-12
Table of Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Overview of Content in This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Zerto Virtual Replication Documentation Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Support and Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Chapter 1: Introduction to Zerto Virtual Replication . . . . . . . . . . . . . . . . . . . . . 11

What is Zerto Virtual Replication? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Zerto Virtual Replication Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Benefits of Using Zerto Virtual Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chapter 2: Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Initial Configuration for Both Enterprises and Cloud Providers . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Register Zerto Virtual Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Install Virtual Replication Appliances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Specific Steps for Enterprises Managing Protected and Recovery Sites . . . . . . . . . . . . . . . . . . . . 27
Pair Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Set Up a Peer Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Set Up vCloud Director (If Used) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Specific Steps for Cloud Providers Supplying a Recovery Service to Enterprises . . . . . . . . . . . . . 33
Install Cloud Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Hide Cloud Information From Customers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Enable the Customer to Pair to the Cloud Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Define Masking for a Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Set Up vCloud Director (If Used) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Specific Steps for Customers Pairing to a Cloud Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Pair to the Cloud Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Install Virtual Replication Appliances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Chapter 3: Protecting Virtual Machines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Configuring Virtual Protection Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protecting a Single Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protecting a vApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Moving a Virtual Machine To or From a vApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protecting Virtual Machines When VMware vCloud Director is Used . . . . . . . . . . . . . . . . . . . . .
Replication From a vCenter Server to vCloud Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Replication From vCloud Director to vCloud Director . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Replication From vCloud Director to a vCenter Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
73
74
83
84
85
90
91
Chapter 4: Advanced Zerto Virtual Replication Configuration . . . . . . . . . . . . . 92

Setting Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Sizing Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
VMDK Size Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
WAN Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Estimating the Bandwidth Requirements Between Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Collecting Data Characteristics for VMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Estimating the Required Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Setting Up Information About a Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Site Configuration Advanced Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Defining the Maximum Bandwidth Used by Zerto Virtual Replication Between Sites . . . . 102
Defining the Default Script Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Defining the Scaling Used for Performance Graphs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Defining Masking for Newly Paired Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Configuring vCloud Director and Provider vDCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Defining the Replication Pause Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Defining the Failover and Move Operation Default Commit Policy . . . . . . . . . . . . . . . . . . . 105
Configuring Email Notifications for Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Defining Zerto Support Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Defining Masking for a Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Configuring vCloud Director (If Used) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Configuring Provider vDCs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Masking vCloud Director Organization vDCs and Networks. . . . . . . . . . . . . . . . . . . . . . . . . 115
Chapter 5: Managing Zerto Virtual Replication. . . . . . . . . . . . . . . . . . . . . . . . . 117

Managing VPGs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Adding a Virtual Machine to an Existing VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Modifying a VPG Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Forcing the Synchronization of a VPG. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Cloning a VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Deleting a VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
VPG Statuses and Synchronization Reasons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Modifying a Virtual Machine Volume Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Ensuring Application Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Adding a Checkpoint to Identify a Key Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Ensuring Application Consistency With Microsoft Volume Shadow Copy Service (VSS) . . 138
Ensuring Application Consistency Using APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Running Scripts Before or After Recovering a VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Creating a Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Examples Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Managing VRAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Maintaining Shadow VRAs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Upgrading VRAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Editing a VRA Host Password and Network Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Sorting the VRA List. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Uninstalling VRAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Support for VMware Host Maintenance Mode and VRA Maintenance . . . . . . . . . . . . . . . . . 156
Handling a Ghost VRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Managing Cloud Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Handling a Ghost Cloud Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Managing a Zerto Virtual Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Reconfiguring the Zerto Virtual Manager IP Addresses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Restore the Zerto Virtual Manager to a Backed Up Version . . . . . . . . . . . . . . . . . . . . . . . . . 166
Chapter 6: Recovery Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

The Move Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Failover Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Failover Test Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Clone Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
168
169
170
171
Chapter 7: Testing Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

The Test Failover Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Starting and Stopping Failover Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Live Disaster Recovery Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basic Verification User Traffic Is Not Run Against the Recovered VMs . . . . . . . . . . . . . .
Run User Traffic Against the Recovered VMs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
173
174
180
181
182
183
Chapter 8: Migrating a Protection Group to the Recovery Site . . . . . . . . . . . . 187

The Move Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Moving Protected Virtual Machines to the Peer Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Reverse Protection For a Moved VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Chapter 9: Managing Failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

The Failover Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initiating a Failover From the Protected Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reverse Protection For a Failed Over VPG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initiating a Failover From the Recovery Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initiating a Failover During a Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
195
197
204
205
211
Chapter 10: Zerto Virtual Replication Reports . . . . . . . . . . . . . . . . . . . . . . . . . 212

Monitoring Site Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Monitoring Virtual Protection Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Saving Details of Virtual Protection Groups to File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Monitoring a Virtual Protection Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Monitoring Protected Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Monitoring Zerto Virtual Replication Peer Sites and Site Topology . . . . . . . . . . . . . . . . . . . . . . 222
The Site List Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
The Topology View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Zerto Virtual Replication Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Alerts Report Issued by Zerto Virtual Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Audit Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Failover Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Outbound Protection Over Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Protection Over Time by Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Top Sites Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
VPG Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Seeing What is Licensed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Chapter 11: How Zerto Virtual Replication Works With VMware Features. . . 242
Protecting Virtual Machines in a vApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Protecting Virtual Machines that Use Thin Provisioning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Zerto Virtual Replication and VMware Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
VMware High Availability (VMHA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
DRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Zerto Virtual Replication and Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Zerto Virtual Replication and Host Affinity Rules and CPU Pinning . . . . . . . . . . . . . . . . . . . . . 245
Ensuring VPG Integrity When Using VMotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Zerto Virtual Replication and Storage VMotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
VMware Host Maintenance Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
VMware Roles and Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Chapter 12: Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Ensuring Zerto Virtual Replication is Running. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zerto Virtual Replication Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Troubleshooting GUI Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zerto Tabs Not Displayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Host is Not Displayed in List of Hosts in the Manage VPG Dialog . . . . . . . . . . . . . . . . . . . .
Troubleshooting VRA Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VPG Syncing Take a Long Time Network Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Host is Not Displayed in List of Hosts in the Manage VPG Dialog . . . . . . . . . . . . . . . . . . . .
VRA Crashes During Promotion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Handling Lack of Storage Space for Recovered Virtual Machines . . . . . . . . . . . . . . . . . . . . . . . .
Understanding the Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Collecting Logs to Troubleshoot Problems: Running Zerto Virtual Replication Diagnostics . . .
Collecting Log Information for the ZertoVssAgent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
248
248
251
251
251
251
251
252
252
252
252
254
264
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 virtual environment using VMware
vSphere Client console.
Intended Audience
This guide is for the use of experienced VMware administrators.
Overview of Content in This Guide

This guide contains the following chapters:
Chapter Title
Description
Introduction to Zerto
Virtual Replication
Describes the underlying concepts and architecture of Zerto

Virtual Replication.
Initial Configuration
Describes how to set up the environment for recovery using

Zerto Virtual Replication.
Protecting Virtual
Machines
Describes how to set up protection for virtual machines.
Zerto Virtual Replication Documentation Set
Chapter Title
Description
Advanced Zerto
Virtual Replication
Configuration
Describes the processes available to manage protection and

recovery sites using Zerto Virtual Replication.
Managing Zerto
Virtual Replication
Describes the processes available to manage protection and

recovery sites using Zerto Virtual Replication.
Recovery Procedures
Describes the available recovery procedures and when they are

used.
Testing Recovery
Describes how to test recovery to ensure the results you want.
Migrating a Protection Describes the process of migrating protected virtual machines

Group to the Recovery from the protected site to the recovery site.
Site
Managing Failover
Describes the process of recovery from the protected site to the

recovery site.
10
Zerto Virtual
Replication Reports
Describes the interaction between Zerto Virtual Replication

and commonly used VMware features such as VMotion, DRS
and HA.
11
How Zerto Virtual

Replication Works
With VMware
Features
Describes the interaction between Zerto Virtual Replication

and commonly used VMware features such as VMotion, DRS
and HA.
12
Troubleshooting
Describes how to resolve problems.
Zerto Virtual Replication Documentation Set

The Zerto Virtual Replication documentation set includes the following documentation:
Release Notes
Details specific to this release of Zerto Virtual Replication.
Installation and Getting How to install and set up Zerto Virtual Replication.
Started Guide
Zerto Virtual Replication How to install and use the Zerto Virtual Replication Windows
Cmdlets
PowerShell cmdlets, including the cmdlets to use when upgrading
Zerto Virtual Replication.
About This Guide
Support and Feedback
Quick Reference
a single sheet with brief descriptions of how to perform the main

functions.
Administration Guide
This guide: How to implement and manage replication and a disaster

recovery (DR) solution in a virtual environment using Zerto Virtual
Replication.
Additionally, an API online help is available.

The documentation is available in both PDF and HTML formats. Access the PDF versions of the
documentation from the StartHere PDF.
Support and Feedback

Please send suggestions to improve the documentation to Zerto support.
About This Guide
10
Chapter 1: Introduction to Zerto Virtual

Replication
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 12.
How Zerto Virtual Replication Recovery Works, on page 14.
Benefits of Using Zerto Virtual Replication, on page 16.
What is Zerto Virtual Replication?

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 manage the replication from within the vSphere Client console, so you only need to have one
point of control: All recovery that does not rely on native replication functionality is 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
Zerto Virtual Replication, and whether the native replication functionality is used or not is
1. An extensive API and Windows PowerShell cmdlets are also available enabling management from a script instead of the
vSphere Client console. For details of the APIs, refer to the API online help. For details of the cmdlets, refer to the Zerto Virtual
Replication Cmdlets guide.
11
Zerto Virtual Replication Architecture
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 Virtual Replication comprises the following components:
Zerto Virtual Manager (ZVM) A Windows service, which manages the replication between the
vCenter Servers on the protection and recovery sites.

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.
Zerto Cloud Connector A cloud connector routes traffic between the customer network and the
cloud replication network, in a secure manner without requiring the cloud vendor to go through
complex network and routing setups, ensuring complete separation between the customer
network and the cloud provider network.
Zerto vSphere Client console plug-in A plug-in in the vSphere Client console that enables
managing recovery using Zerto Virtual Replication from the console.
The Zerto Virtual Replication components are deployed differently, depending on whether both
the protected and recovery sites belong to the same enterprise or whether a cloud provider
supplies disaster recovery services to an enterprise.
Introduction to Zerto Virtual Replication
12

Both the protected and recovery sites belong to the same enterprise The following diagram shows
how the Zerto Virtual Replication components are deployed and the communication protocols
used between the components, when both the protected and recovery sites belong to the same
enterprise.
Zerto Virtual Replication can be installed at multiple sites and each of these sites can be paired to
any of the other sites enabling enterprises to protect multiple data centers as well as remote
branch offices.
13

A cloud provider supplies disaster recovery services to the enterprise The following diagram shows
how the Zerto Virtual Replication components are deployed and the communication protocols
used between the components when a cloud provider supplies the disaster recovery to the
enterprise.
When a cloud provider supplies disaster recovery as a service (DRaaS), each enterprise network
must be completely fenced off from the other enterprises. Zerto Virtual Replication enables this
network separation by installing a cloud connector per enterprise, providing full multi-tenancy. In
addition, Zerto Virtual Replication is integrated with VMware vCloud Director enabling seamless
and automated recovery to and from a vCD.
How Zerto Virtual Replication Recovery Works
Zerto Virtual Replication sits in the hypervisor layer. You manage the protected and recovery
sites from the vSphere Client console or via in-house scripts, using Zerto Virtual Replication
PowerShell cmdlets or APIs 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.
Note: 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
14
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 machine the write is written to a journal under the Virtual Replication Appliance
virtual machine.
Every few seconds, a checkpoint is also written to the journal. These checkpoints ensure write
order fidelity and crash-consistency to each checkpoint. During recovery you pick one of these
crash-consistent checkpoints in the journal and recover to this point. Additionally, checkpoints
can be manually added to the journal 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 the journal.
As well as the writes being written to the journal, images of the protected volumes in the VPG are
created under the Virtual Replication Appliance virtual machine. 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.
The journal file size for each VPG is defined as part of the VPG definition and is estimated to be
big enough to hold all the transactions for the virtual machines specified in the VPG for a defined
period. After this period, or when the journal is approximately 95% full, the earliest entries in the
journal are written to the mirror images of the virtual disk volumes under the VRA.
15
Benefits of Using Zerto Virtual Replication

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.
Fully Virtual Sits in the Hypervisor

Zerto Virtual Replication software sits in the hypervisor level. Protection groups are configured
with virtual machines and virtual disks, without the need to consider the physical disks.
16
Focus is on the Application, Not the Physical Storage

By considering the physical disk level and not the virtual disk level, traditional replication is not
truly application aware. Even virtual replication recovers block writes at the SCSI level and not
at the application level. Zerto Virtual Replication is truly application focused, replicating the
writes from the application in a consistent manner.
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.
Efficient Asynchronous Replication

Writes are captured by the Zerto Virtual Replication software in the hypervisor level, before they
are written to the physical disk at the protected site. These writes are sent to the recovery site
asynchronously, thus avoiding long distance replication latency to the production applications.
Also, because these writes are captured and sent to the recovery site, it is only these delta changes
and not the whole file or disk that is sent to the recovery site, reducing the amount of network
traffic, which reduces WAN requirements and significantly improves both RPO and RTO targets.
One-Click Failover and Control of the Recovery Process

When recovery is required, the administrator clicks on a button in the vSphere Client console to
initiate failover. This means that control of when a recovery is initiated remains in the hands of
the administrator, who can decide when to initiate the recovery and, by selecting a checkpoint, to
what point-in-time to recover to.
17
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 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.
WAN Optimization Between Protected and Recovery Sites

Using compression to minimize bandwidth and other techniques such as throttling to prioritize
network traffic to reduce the impact on day-to-day operations, you can make sure that the
communication between the protected and recovery sites is fully optimized.
Zerto Virtual Replication also uses signature matching to reduce the amount of data sent across
the WAN. During synchronization of the protected site and recovery site for every virtual machine
in a VPG, Zerto Virtual Replication maintains a map of disk sectors so that in the case when there
is a need to resynchronize sites, the map signatures can be used to ensure that only data where
changes occurred are passed over the WAN.
18
WAN Resilience
Zerto Virtual Replication is highly resilient to WAN interruptions. In order to reduce storage
overhead used for replication purposes, on WAN failure 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. Once the WAN connection resumes, Zerto Virtual
Replication uses this bitmap to check whether there were updates to the source disks and if there
were updates to the disks, these updates are sent to the recovery site.
Single Point of Control

With Zerto Virtual Replication everything is managed from the VMware vSphere Client console.
You do not need to access multiple consoles to configure and manage the replication. This reduces
the number of control points and provides a unified method of configuring and managing
recovery.
You manage and control both protected and recovery sites from same vSphere Client console. In
addition to being able to manage the recovery configuration from the console, a full API and is
available to manage recovery from the command line and from scripts.
Fully Compatible with VMware Product Line

Zerto Virtual Replication runs in the VMware vCenter Server hypervisor and is compatible with
other VMware features, such as VMotion.
19
Chapter 2: Initial Configuration
Zerto Virtual Replication is configured and managed from within the vSphere Client console1, via
Zerto tabs. This chapter describes the initial configuration required after installing Zerto Virtual
Replication.
The configuration steps that must be performed depend on whether you are installing as an
enterprise managing the protected and recovery sites, a cloud provider, supplying recovery
services, or an enterprise, recovering to a cloud provider. The following table outlines the steps for
each of these configurations,
Enterprise managing protected Cloud provider supplying a
and recovery sites
recovery service to
enterprises
Register Zerto Virtual Replication, below.
Install Virtual Replication Appliances, on page 22.
Enterprise using a cloud

provider for recovery
Wait for cloud provider to

provide access details, to
enable pairing to the cloud
provider.
Pair Sites, on page 28.
Install Cloud Connectors, on

page 34.
Set Up a Peer Site, on page

30.
Hide Cloud Information From

Customers, on page 40.
Set Up vCloud Director (If

Used), on page 30.
Enable the Customer to Pair to Pair to the Cloud Provider, on

the Cloud Provider, on page 42 page 52.
Define Masking for a Site, on Install Virtual Replication
page 43.
Appliances, on page 53.
Set Up vCloud Director (If
Used), on page 46.
Initial Configuration for Both Enterprises and Cloud Providers, below

Specific Steps for Enterprises Managing Protected and Recovery Sites, on page 27
Specific Steps for Cloud Providers Supplying a Recovery Service to Enterprises, on page 33
Specific Steps for Customers Pairing to a Cloud Provider, on page 52
1. An extensive API is also available enabling management from a script instead of the vSphere Client console. For details of the
APIs, refer to the API online help.
20
Initial Configuration for Both Enterprises and Cloud

Providers
After installing Zerto Virtual Replication, both enterprises managing their own protection and
cloud providers supplying protection to enterprises perform the following procedures:
Register Zerto Virtual Replication, below

Install Virtual Replication Appliances, on page 22
Register Zerto Virtual Replication

On the very first access to a Zerto tab in vSphere Client console, you have to either register your
use of Zerto Virtual Replication, by entering the license key supplied by Zerto or pair to a site,
described below, where the license has already been entered.
After entering a valid license, the panels for the local site, on the left, and the remote, peer, site,
on the right, are displayed.
21
Initial Configuration for Both Enterprises and Cloud Providers
The site information, specified during the installation is displayed at the top of the panel for the
site.
In the top middle indicators show the Zerto Virtual Replication status. The status indicators are
green when there are no problems, yellow for warnings and red for errors. Hovering the mouse
over the red or yellow indicator, when it is showing, displays the reason for the error or warning.
This information is also displayed in the Alerts report, under the Reports item, available after a
VRA is installed and the site is paired with another site.
Install Virtual Replication Appliances

The Zerto Virtual Replication installation includes the installation package for Virtual
Replication Appliances (VRAs). A VRA is 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.
It is recommended to install a VRA on every ESX/ESXi host in each vCenter Server, so that if a
virtual machine being protected is moved for example, using VMware VMotion, it is still
protected.
22

Note: When protecting virtual machines in a cluster, it is recommended to install a VRA on every
ESX/ESXi host in the cluster 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, or to disable DRS on the virtual machines to be protected. 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.
To install Zerto Virtual Replication Appliances (VRAs) on ESX/ESXi hosts:
To install a VRA, 12.5GB datastore space is required. The VRA requires at least 1GB of reserved
memory. The VRA can only be installed on ESX/ESXi hosts version 4.0U1 and higher. You must
also know the following information to install a VRA:
The network used to access the VRA in the protected site.

If a static IP is used instead of DHCP, the IP address, subnet mask and default gateway to be
used by the VRA.
The network settings to access the peer site; either the default gateway or the IP address,
subnet mask and gateway.
Note: Installing a VRA requires that SSH is enabled on the host during the installation. After the
installation you can close this SSH connection.
1. In the vSphere Client console, select the Zerto tab for the vCenter Server.
The panels for the local site, on the left, and the remote, peer, site, on the right, are displayed.
2. Click the Manage VRAs button in the local site, left, panel.
The Manage VRAs dialog is displayed.
23
Note: You can resize the Manage VRAs dialog by dragging the marker symbol in the bottom
right corner of the dialog.

3. If the access to the peer site VRAs is not via the network default gateway, check the Paired
Site Routing checkbox and click the link.
The Configure Paired Site Routing dialog is displayed.
24
Specify the IP address, subnet mask and gateway to access the peer site VRAs and click Save.
These access details then apply to every VRA defined on this site to access the peer site.
4. Click the Install New VRA button.
The Configure & Install VRA dialog is displayed.
25
Specify the following target host details:

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.
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.
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 specified is
dependent on the number of volumes being protected or recovered. Use the following table as
a guideline:
VRA Protecting
Volumes
VRA Recovering
Volumes
VRA Protecting and

Recovering Volumes
1GB
9 volumes
15 volumes
9 volumes
2GB
56 volumes
90 volumes
56 volumes
3GB
103 volumes
165 volumes
103 volumes
When the VRA is used both for protection and recovery, the number of volumes is the sum of
both sites. For example, if four volumes are protected on one site and three on the peer site,
the number of volumes is seven and the VRA requires 1GB.
If the VRA is protecting or recovering more volumes than specified for the amount of RAM,
the chances that the VPGs require bitmap syncs will increase due to the load on the VRA.
Specify the following VRA network details:
Configuration Either have the IP address allocated via a static IP address or a DHCP server.
If you select the Static option, which is the recommended option, enter the following:
Address The 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.
Default Gateway The default mask for the network.
5. Click Install.
The installation starts and the status is displayed in the Status field of the Manage VRAs
dialog. This process includes a number of tasks, which you can see in the vSphere Client
console tasks list.
26
Specific Steps for Enterprises Managing Protected and Recovery Sites
6. Repeat steps 4 and 5 to add a VRA to every ESX/ESXi host that hosts virtual machines for
which you want replication.
Note: It is recommended to install a VRA on every listed ESX/ESXi host.
7. Click Close to exit the dialog. The installation procedure continues.

Click the Manage VRAs button to reopen the Manage VRAs dialog to monitor the VRA
installation.
After pairing the sites, click the configuration (cog) button in the local site panel to access the Site
Configuration dialog to install additional VRAs.
Specific Steps for Enterprises Managing Protected

and Recovery Sites
After registering Zerto Virtual Replication and installing VRAs you perform the following to
configure Zerto Virtual Replication:
Pair Sites, below.

Set Up a Peer Site, on page 30.
Set Up vCloud Director (If Used), on page 30.
27
Pair Sites
Zerto Virtual Replication is installed on both the protected and recovery sites. You have to pair
sites to enable replication between the sites before configuring the replication that you want.
To pair the sites:
1. In the vSphere Client console, select the Zerto tab for the vCenter Server node.
2. Click the Pair button in the peer site panel.
The Manage Sites dialog is displayed.1
3. Click the Add New Site button.

The Add Site dialog is displayed.
4. Specify the following:

Peer Site Address IP address or host name of the peer site to pair to. The peer site is the site
where the peer 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.
1. The Manage Sites dialog enables pairing to multiple sites. The number of sites you can pair with is determined by the license
agreement.
28
5. Click the Pair button.

The sites are paired, the process being reflected in the Status column. Once paired the status
changes to Paired meaning that the Zerto Virtual Manager for the local vCenter Server is
connected to the Zerto Virtual Manager on the peer server.
6. Click the Close button.
After the pairing completes the content of the Zerto tab for the vCenter node changes to present
summary information about the paired site.
Note: When the local site is paired with multiple sites, the peer site panel, on the right, specifies
multiple sites and specific site information, such as the site name and contact information is not
displayed.
29
Set Up a Peer Site

You set up a peer site by installing VRAs in the peer site.
To install VRAs on ESX/ESXi hosts in the peer site:
Repeat the procedure, Install Virtual Replication Appliances, on page 22, via a vSphere
Client console opened for the peer site vCenter Server.
If you install a VRA on a peer site before pairing the site, as recommended, you have to enter the
license to use Zerto Virtual Replication, as described in Register Zerto Virtual Replication, on
page 21.
Set Up vCloud Director (If Used)

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.
If you did not set up access to vCD for the Zerto Virtual Manager when installing Zerto Virtual
Replication, set it up using the following procedure.
Note: Before setting up Zerto Virtual Replication to work with vCD, you must have an AMQP
server installed. Zerto provides an AMQP installation kit if you do not have one installed for vCD.
Run ZertoAMQPInstallWizard.exe from the kit and when prompted enter the IP or host name of
the vCD and the administrator user and password to access this vCD. The Zerto Virtual Manager
connects to the vCD and checks whether an AMQP server is installed. If an AMQP server is not
installed, Zerto recommends using RabbitMQ, which in turn requires Erlang/OTP as a
prerequisite. Links to the sites to install both Erlang/OTP and RabbitMQ are provided as part of
the Zerto AMQP installation. Use these links to install Erlang/OTP and then RabbitMQ before
being able to continue with the Zerto AMQP installation. If an AMQP server was already
installed, change the connection details displayed to those defined in vCD. If you installed the
AMQP server as part of the Zerto AMQP installation, the default settings for these installations
are displayed, with a user and password of guest. At the end of the Zerto AMQP installation,
vCD is updated with these settings.
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.
30
To set up access to vCD:

2. Click the configuration (cog) button in the local site panel.
The Site Configuration dialog is displayed.
3. Click Advanced.
The Advanced Settings dialog is displayed.
4. Click the Configure vCD button.
5. Check the Use vCD checkbox.

6. Enter the VMware vCloud Director access details:
31

Address The IP address or host name of the machine where vCD runs. When connecting to
vCD with multiple cells, enter the virtual IP for the network load balancing used by the cells.
Username The user name for an administrator to vCD.
Password A valid password for the given user name.
AMQP-Username The user name for the AMQP server.
AMQP-Password A valid password for the given AMQP user name.
7. Click Save in the Configure vCD dialog.

8. Click Save in the Advanced Settings dialog.
Note: If a proxy server is defined on the machine where the Zerto Virtual Manager is installed,
add the Zerto Virtual Manager IP address to the Internet Explorer exception list.
To configure provider vDCs:

3. Click Advanced.
4. Click the Configure provider vDCs button.
5. Add the provider vDCs that you want to enable to use Zerto Virtual Replication.
6. Add datastores and specify how you want the organization to see these datastores, by clicking
in the Presented as column to edit the content.
7. Select what datastores not specifically added to the list are used for: either they are not used
or they are used for recovery volumes only.
32
Specific Steps for Cloud Providers Supplying a Recovery Service to Enterprises

Note: If the option Unlisted datastores are used only for recovery volumes is
selected, it refers to unlisted datastores of all provider vDCs, even those provider vDCs that
have not been added to the upper table.
8. Specify for each datastore added, what it can be used for: Recovery volume, Journal and
Preseed.
Only datastores marked as preseeded can be used for preseeded disks. This prevents different
organizations being exposed to datastores of other customers using the preseed option.
9. Click Save.
Specific Steps for Cloud Providers Supplying a

Recovery Service to Enterprises
After registering Zerto Virtual Replication and installing VRAs you perform the following to
configure Zerto Virtual Replication:
Install Cloud Connectors, below.

Hide Cloud Information From Customers, on page 40.
Enable the Customer to Pair to the Cloud Provider, on page 42.
Define Masking for a Site, on page 43.
Set Up vCloud Director (If Used), on page 46.
33
Install Cloud Connectors

A cloud connector is a virtual machine installed on the cloud side, one for each customer
organization replication network. The cloud connector routes traffic between the customer
network and the cloud replication network, in a secure manner without requiring the cloud
provider to go through complex network and routing setups, ensuring complete separation
between the customer network and the cloud provider network. The cloud connector has two
Ethernet interfaces, one to the customers network and one to the cloud provider's network.
Within the cloud connector a bidirectional connection is created between the customer and cloud
provider networks. Thus, all network traffic passes through the cloud connector, where the
incoming traffic on the customer network is automatically configured to IP addresses of the cloud
provider network.
34
The organization networks for disaster recovery are extended to the cloud. The Zerto Cloud
Connectors are installed to ensure that these networks have no touch points with the cloud
infrastructure network, providing complete network separation between each organization
network and the cloud provider infrastructure network. All the traffic to and from the
organization is routed through the cloud connector, so that the following is implemented:
None of the organizations have direct access to the cloud provider network and cannot see any
part of the cloud provider network that the cloud provider does not allow them to see.
Each organization has no access to the network of another organization.
If the cloud provider wants to institute additional security, considering both cloud connector
interfaces as part of the customer 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.
In the above diagram the cloud connector interfaces directly to the cloud provider VLAN200
network, while the Zerto Virtual Manager and VRAs in the cloud site are on a separate network
as is the cloud VC network. The hop to the Zerto Virtual Manager and VRAs in the cloud site is
specified as a static route in the cloud connector.
35
If you change the Zerto Virtual Manager and VRAs cloud network, changing the static route
settings for a group to the new network, changes the access for all cloud connectors with the
specified group.
To set up static routes:
1. In the vSphere Client console, select the Zerto tab for the vCenter Server and in the right
panel click the configuration (cog) button.
2. Click the Manage cloud connectors... button.
The Manage Cloud Connectors dialog is displayed.
3. Click the Manage Static Routes button.

The Manage Static Routes dialog is displayed.
36
4. Click Add under Group to define a group. This group will contain a static route to the subnet
used by the Zerto Virtual Manager and can be applied to more than one cloud connector.
5. Specify the name of the group and click Save.

6. Select a group and click Add under Route to define a static route for that group.
7. Specify the static route:

Address The IP address for the static route.
Subnet Mask The subnet mask for the network.
Gateway The gateway for the network.
8. Click Save.
You can defined more than one static route for a group. The static routes are displayed under
each group.
37
9. Click Save.
You can use the group in the definition of a cloud connector, described below. If you change the
Zerto Virtual Manager network or VRA network, changing the static route settings for a group to
the new network, changes the access for all cloud connectors with the specified group.
To install a cloud connector:
Note: The cloud connector requires 2GB of disk space.
1. In the vSphere Client console, select the Zerto tab for the vCenter Server and in the right
panel click the configuration (cog) button.
2. Click the Manage cloud connectors... button.
The Manage Cloud Connectors dialog is displayed.
38
3. Click the Install New Connector button.

The Configure and Install Cloud Connector dialog is displayed.
Specify the following:

Organization Name A name used by the cloud provider to identify the enterprise client.
Host The target ESX/ESXi host for the cloud connector virtual machine. The dropdown
displays the hosts which do not have a cloud connector installed.
Datastore The datastore for the cloud connector virtual machine.
Organization Network The network details opened to the customer. Specify the following cloud
connector network details:

Network The name of the network from the list of available networks.
Address The IP address for the customer to communicate with the cloud connector. The
customer pairs to this IP address.
Default Gateway The default gateway for the network.
Cloud Network The local network details for the cloud provider. Specify the following cloud
connector network details:
Network The name of the cloud-side network from the list of available networks.
Address The IP address for the cloud provider to communicate with the cloud connector.
Static Route Group The name of the group for which static routes are defined to the Zerto
Virtual Manager network and VRA network. If a static route group is not specified, it is
assumed that the Zerto Virtual Manager and VRAs are on the cloud network.
4. Click Install.
39
The installation starts and the status is displayed in the Status field of the dialog. You can
install more than one cloud connector per organization and per Zerto Virtual Manager.

6. Repeat the procedure for every customer.
After installing a cloud connector, add the machine to the host boot configuration, so that on
starting up a host the cloud connector is also powered on automatically.
The customer installs Zerto Virtual Replication and then pairs to the cloud connector using the IP
address specified in the Configure and Install Cloud Connector dialog by the cloud
provider.
Hide Cloud Information From Customers

After installing a cloud connector, you can supply the Customer Network IP address to the
customer to use to pair to the cloud provider. However, to prevent the customer from being able to
see cloud provider information, such as the IP addresses of ESX/ESXi hosts used by the cloud
provider, you block the customer from seeing this information.
To hide information about the local site:
40
3. Click Advanced.
4. Check Masking for new paired sites. Masking enables you to hide information from
being visible from the peer site. Instead of the peer site being able to see a specific ESX/ESXi
IP address and its datastores and NICs, other names can be assigned that are seen by the
peer site.
Note: The field is checked before pairing so that the peer sites cannot see any ESX/ESXi IP
addresses, datastores or NICs until masking is defined in the Site Management dialog, after
pairing.
5. Click Save.
6. Click Close.
Note: For full details about the Advanced Settings dialog, see the Site Configuration
Advanced Settings, on page 101.
41
Enable the Customer to Pair to the Cloud Provider

Zerto Virtual Replication is installed on both the customer and cloud provider sites. You have to
pair these two sites to enable replication between the sites before configuring replication.
On the very first access to a Zerto tab in vSphere Client console, the customer pairs to the cloud
provider.
The customer chooses the Start by pairing to a site with a license option and enters
the IP provided by the cloud provider in the Pair site address field. leave the value in the
Port field as 9081.
After pairing, the panels for the local site, on the left, and the remote, peer, site, on the right, are
displayed.
42
Define Masking for a Site

Masking enables you to mask host information from being visible from the peer site. Instead of
the peer site being able to see ESX/ESXi IP addresses and datastores and NICs, other names can
be assigned that are seen by the peer site.
To specify site masking information to be visible by the customer site:
2. Click the Site List button in the peer site panel.
The Site List dialog for the site is displayed.
This dialog lists all the sites paired with the local site and site information about the sites.
3. Click the Edit button for a site in the list which will have masking defined for it.
The Peer Site Configuration dialog for the site is displayed.
Note: You can also access the Peer Site Configuration dialog by clicking the
configuration (cog) for the peer site in the topology view.
43
4. Specify a name to identify the organization hosting the site.

5. In the Max number of protected VMs field specify the maximum number of virtual
machines that this organization is permitted to protect. An empty value means there is no
limit. If the maximum number of VMs is not reached but the maximum storage is reached, no
more virtual machines can be protected, unless the value of Max protected storage (GB)
is increased.
6. In the Max protected storage (GB) field specify the maximum storage that this
organization is permitted to protect. An empty value means there is no limit. If the maximum
amount of storage is not reached but the maximum number of protected virtual machines is
reached, no more virtual machines can be protected, unless the value of Max number of
protected VMs is increased.
7. Check the Mask vCenter Resources checkbox. Once checked, no vCenter Server resources
are exposed to the peer site. You then use the VC tab to expose resources you want the peer
site to see.
Note: If you want the peer site to protect its virtual machines to vCloud Director only, check
the Mask vCenter Resources checkbox without defining any resources.
8. In the VC tab, click the Add button for the Cluster & Hosts list.
9. From the displayed Select list, add the ESX/ESXi hosts that you want to hide.
Note: Once the Mask vCenter Resources checkbox is set, only the information added in the
tabs in this dialog is displayed in the peer site.
10. In the Presented as column, enter the name that you want displayed in the peer site.
44

Note: Click the copy link to copy the original name to the Presented as column, if you want
this specific entry to be visible in the peer site.
11. Repeat steps 9 and 10 for the Resource Pools, Datastores and Networks lists.
12. In the Folder field, specify the folder where you want to save recovered virtual machines and
disks. The specified folder and any sub-folders are the only folders displayed when creating a
VPG in the peer site.
45
When creating a VPG in the peer site, the masked values are presented:
The IP addresses for the host were masked to Cld1. Any other hosts are not displayed because
they were not added to the Cluster & Hosts list in the Peer Site Configuration dialog.
When the Mask vCenter Resources checkbox is not set, the IP addresses for the hosts in the
target site with a VRA installed, are displayed.
The host IP addresses for the target site are displayed.
Set Up vCloud Director (If Used)

You set up using vCloud Director by performing the following:
Setting up vCD and Configuring Provider vDCs, below.

Masking vCloud Director Organization vDCs and Networks, on page 50.
46
Setting up vCD and Configuring Provider vDCs


3. Click Advanced.
47

48


3. Click Advanced.
Preseed.
49
9. Click Save.
Masking vCloud Director Organization vDCs and Networks

When vCloud Director is used, the cloud provider can restrict what organization vDCs and
networks an enterprise connecting to the vCD can see.
To specify masking information for vCloud Director:
2. Click the Site List button in the customer, peer, site panel.
This dialog lists all the sites paired with the local site and information about the
communication between the sites via the VPGs defined.
3. Click the Edit button for the site for which you want to define masking.
is increased.
50
6. Check the Mask vCD Resources checkbox. Once checked, no vCD resources are exposed to
the peer site. You then use the vCD tab to expose resources you want the peer site to see.
Note: If you want the peer site to protect its virtual machines to the underlying vCenter
Server only, check the Mask vCD Resources checkbox without defining any resources.
7. Select the vCD tab.
8. Select the organization from the Select Organization dropdown listbox. The organization
names are those included in the Configure provider vDCs dialog, as described in Setting
up vCD and Configuring Provider vDCs, on page 47.
The organization vDCs and networks for this organization can then be added to the
Organization vDC and Organization Networks lists.
9. Add the organization vDCs and networks that you want the customer to see.
10. Specify the folder name where preseeded disks are saved. You must have specified disks to
use in the Configure provider vDCs dialog, described is the previous section.
11. Click Save.
51
Specific Steps for Customers Pairing to a Cloud Provider
Specific Steps for Customers Pairing to a Cloud

Provider
After installing Zerto Virtual Replication customers using a cloud provider for their recovery
requirements perform the following:
Pair to the Cloud Provider, below.

Pair to the Cloud Provider

Zerto Virtual Replication is installed on both the customer and cloud provider sites. You have to
pair these two sites to enable replication between the sites before configuring replication.
On the very first access to a Zerto tab in vSphere Client console, the customer pairs to the cloud
provider.
The customer chooses the Start by pairing to a site with a license option and enters
the IP provided by the cloud provider in the Pair site address field. leave the value in the
Port field as 9081.
After pairing, the panels for the local site, on the left, and the remote, peer, site, on the right, are
displayed.
52
The site information, specified during the installation is displayed at the top of the panel for the
site.
In the middle at the top of the Zerto tab indicators show the Zerto Virtual Replication status. The
status indicators are green when there are no problems, yellow for warnings and red for errors.
Hovering the mouse over the red or yellow indicator, when it is showing, displays the reason for
the error or warning. This information is also displayed in the Alerts report, under the Reports
item, available after a VRA is installed and the site is paired with another site.
Install Virtual Replication Appliances

The Zerto Virtual Replication installation includes the installation package for Virtual
Replication Appliances (VRAs). A VRA is 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.
It is recommended to install a VRA on every ESX/ESXi host in each vCenter Server, so that if a
virtual machine being protected is moved for example, using VMware VMotion, it is still
protected.
53

Note: When protecting virtual machines in a cluster, it is recommended to install a VRA on every
ESX/ESXi host in the cluster 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, or to disable DRS on the virtual machines to be protected. 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.
To install Zerto Virtual Replication Appliances (VRAs) on ESX/ESXi hosts:
To install a VRA, 12.5GB datastore space is required. The VRA requires at least 1GB of reserved
memory. The VRA can only be installed on ESX/ESXi hosts version 4.0U1 and higher. You must
also know the following information to install a VRA:
The network used to access the VRA in the protected site.

If a static IP is used instead of DHCP, the IP address, subnet mask and default gateway to be
used by the VRA.
The network settings to access the peer site; either the default gateway or the IP address,
subnet mask and gateway.
Note: Installing a VRA requires that SSH is enabled on the host during the installation. After the
installation you can close this SSH connection.
1. In the vSphere Client console, select the Zerto tab for the vCenter Server.
The panels for the local site, on the left, and the remote, peer, site, on the right, are displayed.
2. Click the Manage VRAs button in the local site, left, panel.
The Manage VRAs dialog is displayed.
54
Note: You can resize the Manage VRAs dialog by dragging the marker symbol in the bottom
right corner of the dialog.

3. If the access to the peer site VRAs is not via the network default gateway, check the Paired
Site Routing checkbox and click the link.
The Configure Paired Site Routing dialog is displayed.
55
Specify the IP address, subnet mask and gateway to access the peer site VRAs and click Save.
These access details then apply to every VRA defined on this site to access the peer site.
4. Click the Install New VRA button.
The Configure & Install VRA dialog is displayed.
56
Specify the following target host details:

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.
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.
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 specified is
dependent on the number of volumes being protected or recovered. Use the following table as
a guideline:
VRA Protecting
Volumes
VRA Recovering
Volumes
VRA Protecting and

Recovering Volumes
1GB
9 volumes
15 volumes
9 volumes
2GB
56 volumes
90 volumes
56 volumes
3GB
103 volumes
165 volumes
103 volumes
When the VRA is used both for protection and recovery, the number of volumes is the sum of
both sites. For example, if four volumes are protected on one site and three on the peer site,
the number of volumes is seven and the VRA requires 1GB.
If the VRA is protecting or recovering more volumes than specified for the amount of RAM,
the chances that the VPGs require bitmap syncs will increase due to the load on the VRA.
Specify the following VRA network details:
5. Click Install.
The installation starts and the status is displayed in the Status field of the Manage VRAs
dialog. This process includes a number of tasks, which you can see in the vSphere Client
console tasks list.
57
6. Repeat steps 4 and 5 to add a VRA to every ESX/ESXi host that hosts virtual machines for
which you want replication.
Note: It is recommended to install a VRA on every listed ESX/ESXi host.

Click the Manage VRAs button to reopen the Manage VRAs dialog to monitor the VRA
installation.
After pairing the sites, click the configuration (cog) button in the local site panel to access the Site
Configuration dialog to install additional VRAs.
58
Chapter 3: Protecting Virtual Machines

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 peer
site. The synchronization between the protected site and peer 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 peer site. These writes are stored by the Virtual Replication
Appliance (VRA) in the peer site in a journal for a specified period, after which, the old writes are
promoted to the mirror virtual disk managed by the VRA.
Configuring Virtual Protection Groups, below.

Protecting a Single Virtual Machine, on page 73.
Protecting a vApp, on page 74.
Protecting Virtual Machines When VMware vCloud Director is Used, on page 84.
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 have installed a VRA in the peer site, which manages the replication in the peer
site before you can create a VPG.
59
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 below, To create a
virtual protection group (VPG):, on page 60.
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 73.
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, on
page 74.
Virtual machines and vApps need protecting to a VMware vCloud Director, as described in
Protecting Virtual Machines When VMware vCloud Director is Used, on page 84.
To create a virtual protection group (VPG):

2. Click the New VPG button in the local site panel.
The New VPG dialog is displayed, unless there is only one paired recovery site, in which case
the Manage VPG dialog is displayed.
Specify the recovery site and click Continue. If the recovery site has vCD defined, the
Recovery site is vCD checkbox is automatically selected. If you still want to recover to
the underlying vCenter Server, uncheck the box.
60
The Manage VPG dialog is displayed.
The dialog is divided in to the following sections:

The VPG name A unique name to identify the VPG.
General properties General properties that govern the VPG, such as how often tests should be
performed on the VPG.

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.
3. Optionally, change the name provided for the VPG in the VPG Name field.
Note: The name must be unique. Zerto Virtual Replication checks that the name is unique as
long as a VPG with the same name is not being defined at the same time, either via another
vSphere Client console or before a VPG with the same name was defined and is still being
created while a new VPG is defined.
4. Specify the general properties for the group. Each protection group has general properties and
default properties. The general properties apply to every virtual machine in the group.
Protecting Virtual Machines
61

Priority 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.
Target RPO The maximum desired time in seconds between each automatic checkpoint being
written to the journal. In reality checkpoints are written more frequently. During recovery,
you can recover to a specific checkpoint.
Journal CDP 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 in the 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 Datastore The datastore used for the journal data. 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, all the journal data is 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
62
journal datastore. The following table shows the different datastore options and the
repercussions of each option:
Default Journal Journal
Datastore per
VPG
Journal
Datastore per
Customer
Single Journal
Datastore for
multiple
customers
Allows storage
tiering
No
Yes
Yes
Yes
Notes
The journal for

each volume
lives on the
same datastore
that the recovery
volume lives on
(you can have
two volumes of
the same VM
replicating to
different
datastores).
Specify a
Journal datasore
for each VPG
sized using the
estimator.
Allows the use of

advanced
settings like
storage IO
controls etc. to
give fairness to
customers.
Could introduce
additional crosscustomer LUN
masking issues.
Depending on
deployment size,
may require too This option is
many LUNs.
recommended
for cloud
providers.
If many recovery
datastores are
used then
journal
consolidation
suffers, and it is
more
complicated to
perform the size
estimation.
Where necessary each datastore resides on a different physical LUN.
Additional CDP History Additional time to save in the journal, over and above the maximum
that can be specified in the Journal CDP History field.
Max Journal Size The maximum size of the journal. When approximately 95% of this
value is reached, the older entries are written to the mirror virtual disk volumes
maintained by the VRA. It is recommended to set this value as Auto, in which case, the
journal size is determined dynamically, based on the number of inputs in a specified time
and the value of the Journal CDP History field. The default value is 100GB. The bigger
the size of the journal, the longer the time taken to promote the data from the journal to
the virtual machine, impacting the virtual machine performance.
63

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.
This time can then be used by the administrator to resolve the issue, for example by
increasing the journal disk size or by cloning the virtual machines in the VPG, described
in Cloning a VPG, on page 129, before continuing with the synchronization. This value
overrides the value in the Advanced Settings dialog, described Site Configuration
Test Frequency 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 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.
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.
5. Specify the default values for the group. 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. Every ESX/ESXi host, cluster and resource pool on the recovery site that
hosts a Virtual Replication Appliance (VRA) is included in the drop-down options.
When a resource pool is specified, Zerto Virtual Replication checks that the resource pool
exists and that the resource pool capacity is enough for any virtual machines specified in the
VPG.
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.
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.

64

Failover Test Network The default network to use during a test failover in which the testing
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 here 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.
b) Select one or more virtual machines to be protected.
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.
65
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 keys to move virtual machines from one group to another.
d) Use the arrow keys 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.
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 VMware file for the virtual machine, and the volumes
and NICs used by the virtual machine.
66
The virtual machine details include the following:

Recovery Host The cluster, resource pool or ESX/ESXi that will host the recovered virtual
machine
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.
Recovery Folder The folder where the virtual machine is recovered to.
If default values were specified in the VPG properties step, 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.
9. Make any changes you want to the virtual machine specification on the recovery site and click
Save to save the configuration or, 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 CDP 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 96.
If you click Configure Selected Volume, the Configure Volume dialog is displayed.
67
a) Specify the datastore for recovery from one of the options.

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. You cannot define an RDM disk if the
virtual machine uses a BusLogic SCSI controller.
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 synchronization 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.
Note: Zerto Virtual Replication supports the SCSI protocol. Only disks that support this
protocol can be specified.
b) Click Save.
10. Click Save to save the virtual machine configuration or, 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. Also, any VNIC configuration is ignored when the vCenter
Server is version 4.0.
If you click Configure Selected NIC, the Configure VNIC dialog is displayed.
68
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 VMTools 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.
When possible, to change the default VNIC IP configuration, 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
69
machines started for the test, so that there is no IP clash between the test machines and the
production machines.
d) Click Save.
11. Click Save to save the virtual machine configuration.
12. Configure all the virtual machines in the VPG in the same way.
13. Optionally, expand the Recovery scripts option at the bottom of the dialog to specify the
settings for scripts to run on the recovery site before or after executing a failover, move or test
failover. If the site is masked, as described in Define Masking for a Site, on page 43, you
cannot see or specify scripts in the VPG definition at the masked site, but the site that
implements the masking can edit the VPG to add scripts.
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 performed1. 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 details about the advanced settings, see Site Configuration Advanced
Settings, on page 101.
For more details about running scripts with Zerto Virtual Replication, see Running Scripts
Before or After Recovering a VPG, on page 141.
14. Click Save to create the VPG configuration.
The VPG is created. The VRA in the peer site is updated with information about the VPG and
then the data on the protected virtual machines are synchronized with the replication virtual
1. When using the Zerto Virtual Replication APIs instead of the vSphere Client console, you can set the failover, move or test
failover to continue even if the script fails or times out. For details of the APIs, refer to the API online help.
70
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.
71
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 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.
The Type icons describe the source and target sites: vCenter Server or vCloud Director:
vCenter Server to vCenter Server.
vCenter Server to vCloud Director.
vCloud Director to vCenter Server.
vCloud Director to vCloud Director.
The Group column refers to the boot order group for the virtual machine.
Refer to Modifying a VPG Definition, on page 124 for details about adding, removing or
reconfiguring virtual machines in the VPG.
72
Protecting a Single Virtual Machine
Protecting a Single Virtual Machine

You can protect a virtual machine, that is not already included in a VPG, directly via the Zerto
tab for the virtual machine. You are presented with the following options:
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 Zerto tab for the virtual
machine:, below.
To create a new VPG that includes the virtual machine, as described in To create a virtual
protection group (VPG):, on page 60.
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 74. In this case, the VPG name is automatically
defaulted to the name of the virtual machine.
To add a virtual machine to an existing VPG via the Zerto tab for the virtual machine:
1. In the vSphere Client console, select the Zerto tab for the virtual machine to be added.
2. Click Add to Virtual Protection Group (VPG).

The Select VPG for VM Addition dialog is displayed.
3. Select the VPG from the list of VPGs.
4. Click Save.
The Manage VPG dialog is displayed, with the virtual machine added to the list of protected
virtual machines.
5. Configure the virtual machine configuration, as described in To create a virtual protection
group (VPG):, on page 60, starting with step 8.
6. Click Save.
73
Protecting a vApp
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.
To protect a single virtual machine:
1. In the vSphere Client console, select the Zerto tab for the virtual machine to be protected.
2. Click Protect as a Standalone VM.
The VM to VPG dialog is displayed.
3. Select the Standalone radio button.
4. Click Next.
5. Make any required changes to the VPG properties, as described in Configuring Virtual
Protection Groups, on page 59.
6. Click Save.
Protecting a vApp
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 187. For
details about recovering a VPG and the virtual machines in it, see Managing Failover, on page
195.
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.
To protect a vApp:
1. In the vSphere Client console for the protected site, select the vApp node and in the Zerto tab
click the button to create a VPG for the vApp.
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.
74
Protecting a vApp
The New VPG dialog is displayed, unless there is only one paired recovery site, in which case
the Manage VPG dialog is displayed.
Specify the recovery site and click Continue.

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.
2. Specify the general properties for the group, such as the WAN optimization required, and
specifically the Host and Storage values, since these are not set automatically.
protected site.
75
Protecting a vApp
Journal dialog.
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, all the journal data is 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
76
Protecting a vApp
journal datastore. The following table shows the different datastore options and the
repercussions of each option:
Default Journal Journal
Datastore per
VPG
Journal
Datastore per
Customer
Single Journal
Datastore for
multiple
customers
Allows storage
tiering
No
Yes
Yes
Yes
Notes
The journal for

each volume
lives on the
same datastore
that the recovery
volume lives on
(you can have
two volumes of
the same VM
replicating to
different
datastores).
Specify a
Journal datasore
for each VPG
sized using the
estimator.
Allows the use of

advanced
settings like
storage IO
controls etc. to
give fairness to
customers.
Could introduce
additional crosscustomer LUN
masking issues.
Depending on
deployment size,
may require too This option is
many LUNs.
recommended
for cloud
providers.
If many recovery
datastores are
used then
journal
consolidation
suffers, and it is
more
complicated to
perform the size
estimation.
Where necessary each datastore resides on a different physical LUN.
Additional CDP History Additional time to save in the journal, over and above the maximum
that can be specified in the Journal CDP History field.
77
Protecting a vApp
Target Site The site paired with the local site, to which you want to recover the vApp. The
recovery site selected in the New VPG dialog is displayed.

vApp Recovery Cluster/Host The cluster, resource pool or ESX/ESXi host in the recovery site
which handles the replicated data. Every ESX/ESXi on the recovery site that hosts a Virtual
Replication Appliance (VRA) is included in the drop-down options. This value cannot be
overridden for each virtual machine configuration, unless it is to another host in the same
cluster.
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.

3. Specify the default values for the group.
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.
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
78
Protecting a vApp
Failover Test Network The default network to use during a test failover in which the testing
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. You define the boot order for vCloud Director vApps in the
vCloud Director console.
vApp Recovery Cluster/Host The host that was specified in the Manage VPG dialog to host the
recovered virtual machines in the vApp.

79
Protecting a vApp
Recovery Folder The vApp folder that was specified in the Manage VPG dialog, where the
vApp virtual machine files are saved.

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 CDP 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 96.

80
Protecting a vApp
b) Click Save.
test failover operation will fail.
other tab.
81
Protecting a vApp
c)
Whether to keep the default VNIC IP configuration or not. You can only change the VNIC
d) Click Save.

8. Optionally, expand the Recovery scripts option at the bottom of the dialog to specify the
settings for scripts to run on the recovery site before or after executing a failover, move or test
failover.
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
1. When using the Zerto Virtual Replication APIs instead of the vSphere Client console, you can set the failover, move or test
failover to continue even if the script fails or times out. For details of the APIs, refer to the API online help.
82
Protecting a vApp
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 details about the advanced settings, see Site Configuration Advanced
For more details about running scripts with Zerto Virtual Replication, see Running Scripts
Before or After Recovering a VPG, on page 141.
9. Click Save to create the VPG configuration for the vApp.
The VPG is created for the vApp. The VRA in the peer 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.
Moving a Virtual Machine To or From a vApp

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 missing 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.
83
Protecting Virtual Machines When VMware vCloud Director is Used
Protecting Virtual Machines When VMware vCloud

Director is Used
When VMware vCloud Director is installed at the protected site, protection can be as follows:
From a vCenter Server, protecting one or more virtual machines or a vCenter Server vApp, to
vCloud Director. The vCenter Server can be the vCenter Server underlying vCD.
From vCloud Director, protecting a vCD vApp, to vCloud Director.
From vCloud Director, protecting a vCD vApp, to a vCenter Server. The vCenter Server can
be the vCenter Server underlying vCD.
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:
Via this dialog you can perform the following:
Replication from the vCD underlying vCenter Server at the protected site to the underlying
vCenter Server at the recovery site, as described in Configuring Virtual Protection Groups,
on page 59.
Replication From a vCenter Server to vCloud Director, on page 85.
Replication From vCloud Director to vCloud Director, on page 90.
Replication From vCloud Director to a vCenter Server, on page 91.
84
Replication From a vCenter Server to vCloud Director

When the recovery site has vCloud Director installed, you can protect virtual machines and vApps
as vCD vApps in the recovery site vCD.
To define a VPG to vCloud Director:
1. In the New VPG dialog select Underlying vCenter Server.
2. Select the target recovery site from the list of recovery sites.
If the selected recovery site is a vCD, the Recovery site is vCD checkbox is selected.
Note: If you want the replication to be to the vCenter Server underlying the vCD, and this is
enabled, via the Enable VC checkbox in the Peer Site Configuration dialog, uncheck
the Recovery site is vCD checkbox. In this case the VPG definition is the same as
described in Configuring Virtual Protection Groups, on page 59. For details of the Peer
Site Configuration dialog, see Define Masking for a Site, on page 43.
3. Click Continue.
The following dialog is displayed:
4. Optionally, change the name provided for the VPG in the VPG Name field.
Note: The name must be unique. Zerto Virtual Replication checks that the name is unique as
long as a VPG with the same name is not being defined at the same time, either via another
vSphere Client console or before a VPG with the same name was defined and is still being
created while a new VPG is defined.
85
5. Specify the general properties for the group.

protected site.
Journal dialog:
volume used for recovery of each virtual machine. You can specify a different datastore if
the datastore has been exposed in vCD via the Configure provider vDCs dialog, from
the Advanced Settings dialog, as described in Setting up vCD and Configuring
Provider vDCs, on page 47.
Additional CDP History Additional time to save in the journal, over and above the
maximum that can be specified in the Journal CDP History field.
86
6. Specify the vCD Settings for the group.

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.
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 Setting up vCD and Configuring Provider vDCs, on page 47.
vCD Guest Customization The IP addresses configured for the virtual machines are applied
when the virtual machines are powered on.

7. Specify the default values for the group.
Failover/Move Network The default Org Network to use during a failover or move in which the

Failover Test Network The default Org Network to use during a test failover in which the
testing recovered virtual machines will run.

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.
8. 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.
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.
87

Note: If default network values were not specified, values must be specified here.
10. Optionally, select a Volume and click Configure Selected Volume.

The Configure Volume dialog is displayed.

New VCD Datastore The datastore is allocated Zerto Virtual Replication 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.
you specify the exact location, the preseed folder configured for the customer and the disk
88
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 Setting up vCD and Configuring Provider vDCs, on page 47. Zerto
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.
b) Click Save.
11. 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. The displayed list of
networks is that list that is specified in the Peer Site Configuration dialog, in the
vCD tab, as being visible to the customer. For details refer to Masking vCloud Director
Organization vDCs and Networks, on page 50.
b) The VNIC IP configuration. You can only change the VNIC IP for virtual machines with
VMware VMTools 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.
c)
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.
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.
89
d) Click Save.
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 target
recovery site. When recovering the VPG, reverse replication is configured to either virtual
machines or vApps, depending on what was originally protected.
Replication From vCloud Director to vCloud Director

When the recovery site has vCloud Director installed, you can protect virtual machines and vApps
as vCD vApps in the recovery site vCD.
When both sites use vCloud Director and the protected site has vCD vApps defined, clicking New
VPG results in the New VPG dialog being displayed:
To define a VPG to protect a vCD vApp to vCloud Director:

1. In the New VPG dialog select vCD vApp and select the vCD vApp to protect.
3. Click Continue.
The procedure is the same as when protecting virtual machines to vCloud Director, described
above, in Replication From a vCenter Server to vCloud Director, on page 85, except that the
90
VPG name is the name of the vCD vApp and you cannot add or remove virtual machines to
the VPG.
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.
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.
Replication From vCloud Director to a vCenter Server

If you want the replication to be to a vCenter Server, which can be the underlying vCenter Server
to a vCD, the vCD vApp is replicated in the target recovery site as a vApp.
To define a VPG to protect a vCD vApp to vCenter Server:
1. In the New VPG dialog select vCD vApp and select the vCD vApp to protect.
Uncheck this box to replicate the vCD vApp to the underlying vCenter Server.
Replication to the vCenter Server underlying the vCD must be enabled, via the Enable VC
checkbox in the Peer Site Configuration dialog. For details of the Peer Site
Configuration dialog, see Define Masking for a Site, on page 43
3. Click Continue.
The procedure is the same as when protecting a vApp, described in Protecting a vApp, on
page 74 except that changing the name of a vCD vApp after the VPG has been defined does
not result in the name of the VPG being changed.
When recovering the VPG, via a move or failover operation, reverse replication is configured to a
vCD vApp.
91
Chapter 4: Advanced Zerto Virtual

Replication Configuration
There are a number of configuration tasks that you can perform.
Setting Permissions, below.

Sizing Considerations, on page 93.
Setting Up Information About a Site, on page 100.
Site Configuration Advanced Settings, on page 101.
Defining Masking for a Site, on page 108.
Configuring vCloud Director (If Used), on page 111.
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.
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.
Test Failover Enables performing a test failover.
Viewer For internal use only.
These permissions are assigned to the Administrator role when Zerto Virtual Replication is
installed. You can define additional roles and assign these roles to all of these permissions or to a
subset of them as necessary. All the permissions are implemented at the root level, and thus
apply to every object in the vCenter Server.
92
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 94
VMDK Size Limitations

VMware imposes the following limits that impact on Zerto Virtual Replication.
ESXi 5.x 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.
To adjust the value:
1. Log in to vCenter Server or the ESX/ESXi host using VMware Infrastructure (VI) Client. If
connecting to vCenter Server, select the ESX/ESXi host from the inventory.
2. Click the Configuration tab.
3. Click Advanced Settings.
4. Select VMFS3.
5. Update the field in VMFS3.MaxHeapSizeMB.
In ESX/ESXi 4.x, the maximum heap size is 128MB.
In ESXi 5.x, the maximum heap size is 256MB.
6. Reboot the host for the changes to take affect.
Note: The net effect of this change is that the ESX/ESXi kernel will require a small amount of
additional memory, such as the 128MB used to get a maximum of 32TB for ESX/ESXi 4.x hosts
specified in the above procedure, for the larger heap, but it will allow virtual machines with more
than 4TB (ESXi/ESX 4.x) or 8TB (ESXi 5.x) of virtual disk to be addressed.
Advanced Zerto Virtual Replication Configuration
93
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.
Estimating the Bandwidth Requirements Between Sites

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.
To enable vCenter Server data collection:
1. Via the vSphere Client console connect to the vCenter Server.
2. In the Administration menu item, select vCenter Server Settings.
The vCenter Server Settings dialog is displayed.
3. Select Statistics.
94
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.
95
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.
Collecting Data Characteristics for VMs

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.
Note: 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.
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.
3. Click the Charts Options link.
The Customize Performance Chart dialog is displayed.
96
4. In Chart Options, drill-down in Disk and select Past day.

5. In Counters, click None to clear all the selections and then select Disk Write Rate or Write
Rate.
6. Click OK.
97
A chart similar to the following is generated:
Use the chart for the average write rate of the VM.
To collect data characteristics for the VMs via the vSphere Client console performance statistics:
1. Run the following script:
$report = @()
Get-VM | %{
$stats = Get-Stat -Entity $ -Stat disk.write.average -Start (GetDate).adddays(-7) -ErrorAction SilentlyContinue
if($stats){
$statsGrouped = $stats | Group-Object -Property MetricId
$row = "" | Select Name, WriteAvgKBps, WriteAvgMBps
$row.Name = $_.Name
$row.WriteAvgKBps = ($statsGrouped |
where {$_.Name -eq "disk.write.average"} |
%{$_.Group | Measure-Object -Property Value -Average}).Average
$row.WriteAvgMBps = $row.WriteAvgKBps/1024
$row.WriteAvgKBps = "{0:N2}" -f $row.WriteAvgKbps
$row.WriteAvgMBps = "{0:N2}" -f $row.WriteAvgMBps
$report += $row
}
}
$report | Export-Csv "C:\Program Files
(x86)\VMware\Infrastructure\vSphere PowerCLI\ZertoOutput.csv"
Note: If you want a value other than seven days, change the value of the adddays() function. For
example to collect data for three days, use adddays(-3).
98
Use the file, vmware\Infrastructure\vSphere PowerCLI\ZertoOutput.csv, for the

average write rate of the VM, where vmware is the VMware root folder, which is usually
C:\Program Files\VMware.
Estimating the Required Bandwidth

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.
To use the Zerto WAN Sizing Estimator:
1. Open the Zerto WAN Sizing Estimator.
2. Enter the following information:
The VM name.
The Write KB/s data, based on the statistics gathered in the previous task. Use a period
for the decimal mark.
Define whether compression is enabled for this VM: Select Yes or No.
The application data characteristics: Select Compressed or Compressible.
Note: The Zerto WAN Sizing Estimator colors the cell red if you decide to employ compression
on compressed data and orange if you decide to avoid compression for compressible data.
The Zerto WAN Sizing Estimator calculates the total bandwidth estimation for your deployment,
using a minimum value of 5 Mbps. The estimation is displayed on the top of each page of the Zerto
WAN Sizing Estimator.
You can estimate the WAN sizing required without using the Zerto WAN Sizing Estimator using
the following procedure.
To estimate sizing without using the Zerto WAN Sizing Estimator:
1. For each virtual machine in the VPG multiply the KB/s, based on the statistics gathered by 8
and divide the result by 1024 to provide an answer in Mbps. Divide this result by 2 if
compression is enabled for the VM and the data is compressible.
2. Sum the results of step 1.
WAN Mbps = SUM(KB/s * (8/1024/(1 or 2 if compressible data that will be
compressed)))
The result is an estimate of the required Mbps for the WAN.
Note: If the result is less than 5 Mbps, you must use a minimum bandwidth of at least 5 Mbps.
99
Setting Up Information About a Site
Setting Up Information About a Site

You provide information about the site during installation, to make it easier to identify the site in
the vSphere Client console and to identify the contact person at the site. After installation you can
updated these settings.
To update information about the local site:
The panels for the local and remote sites are displayed. The site information is displayed at
the top of the panel for the site.
2. Click the configuration (cog) button in the local, left, site panel.
The Site Configuration dialog for the site is displayed.
3. Define general information about the site:
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 Info Information about who to contact if a need arises, such as a phone number or
email address.
4. If the credentials to access the vCenter Server from the Zerto Virtual Manager change, specify
the new credentials:
User Name The administrator name used to access the vCenter Server. 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. To
ensure security, after saving the settings, the password field is cleared.
Note: The Site Configuration dialog also enables installing or uninstalling Virtual
Replication Appliances and cloud connectors, pairing or unpairing the sites, updating the
license to run the software, and defining advanced settings, all of which are described in other
sections of the documentation.
5. Click Save.
The updated site information is displayed at the top of the panel for the site.
100
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.
To specify site settings:
3. Click Advanced.
4. Make any required changes to the settings as described below, click Save and then Close. The
following additional 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 102.
Defining the Scaling Used for Performance Graphs, on page 102.
Defining Masking for Newly Paired Sites, on page 103.
101
Configuring vCloud Director and Provider vDCs, on page 103.

Defining the Replication Pause Time, on page 105.
Defining the Failover and Move Operation Default Commit Policy, on page 105.
Configuring Email Notifications for Alerts, on page 106.
Defining Zerto Support Settings, on page 107.
Defining the Maximum Bandwidth Used by Zerto Virtual Replication

Between Sites
Max Bandwidth 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 maximum value, where the bandwidth is displayed both as megabits per second and
megabytes per second. 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
peer site out to this site.
For details about estimating the bandwidth, see Sizing Considerations, on page 93.
Override Physical Bandwidth Limit This option is for use only when directed by Zerto support.
When problems occur with the network bandwidth due to usage limits that are not identified by
Zerto Virtual Replication, Zerto support can use this option to help identify the network
bandwidth issues.
Defining the Default Script Timeout

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 141.
Defining the Scaling Used for Performance Graphs

Graphical Scaling The following fields enable changing the scaling used in the performance
graphs, for example in the Summary 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.
102

WAN Traffic The traffic between the sites.
RPO The time since the last checkpoint was written to the journal.
For details, see Zerto Virtual Replication Reports, on page 212.
Defining Masking for Newly Paired Sites

Masking for new paired sites Masking enables you to hide information from being visible from the
peer site. Instead of the peer site being able to see a specific ESX/ESXi IP address and its
datastores and NICs, other names can be assigned that are seen by the peer site.
Note: Checking the Masking for new paired sites field only affects the peer site if it was
paired after the field is checked. If pairing was done before the Masking for new paired
sites field is checked, the status of the field is ignored. If the field is checked before pairing, the
peer sites cannot see any ESX/ESXi IP addresses, datastores or NICs until masking is defined in
the Site Management dialog, described in Defining Masking for a Site, below and vCloud
Director information, described in Configuring vCloud Director (If Used), on page 111.
Configuring vCloud Director and Provider vDCs

Configure vCD Click Configure vCD and configure access to VMware vCloud Director, either if
has changed or if it was not initially specified during the installation.
Use vCD Whether to use vCD or not.

Address The IP address or host name of the machine where vCD runs.
AMQP User name The user name for the AMQP server.
AMQP Password A valid password for the given AMQP user name.
103
Click Save.
To ensure security, after saving the settings, the password fields are cleared.
Configure provider vDCs Click Configure provider vDCs when vCloud Director is used and the
cloud provider wants the journals on separate datastores from the recovery volumes. For
example, the cloud provider might prefer to keep the recovery volumes on storage with better
Add the Provider vDCs that you want to enable to use Zerto Virtual Replication.
Add datastores and specify how you want the organization to see these datastores, by clicking
Select what datastores not specifically added to the list are used for: either they are not used
Specify for each datastore added, what it can be used for: Recovery volume, Journal and
Preseed.
104
Click Save.
Defining the Replication Pause Time

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. This time can then be used
by the administrator to resolve the issue, for example by increasing the journal disk size or by
cloning the virtual machines in the VPG, described in Cloning a VPG, on page 129, before
continuing with the synchronization. The value set here applies as the default for all new VPGs.
The value can be overridden in a VPG.
Defining the Failover and Move Operation Default Commit Policy

Failover/Move Commit Policy The policy to use during a failover or move operation, described in
Initiating a Failover From the Protected Site, on page 197 and Moving Protected Virtual
Machines to the Peer Site, on page 188 respectively. The following options are available:
None The move operation must be manually committed or rolled back by the user.
Commit After the time specified in the Default Timeout field the move 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 that the VPG virtual machines have moved as
required.
105

Rollback After the time specified in the Default Timeout field the move 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 that the VPG virtual machines have moved as
required.
The value set here applies as the default for all move operations from this point on but can be
changed when defining a 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.
Configuring Email Notifications for Alerts

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.
Check the Use Email Notifications box.

Specify the SMTP server Address of the vCenter Server.
If the SMTP Server Port was changed from the default, 25, specify the port number.
Specify a valid email address for the email sender name in the From field.
Specify a valid email address where you want to send the email in the To field.
You can test that the email notification is set up correctly by clicking Sending Test Email. An
email with the subject ZVR Test Email is sent to the email address specified in the To field.
Click Save.
106
Defining Zerto Support Settings

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.
This dialog has the following functions:
Support settings for use only in coordination with Zerto support.

Sending analytics to Zerto. When the checkbox is selected analytics are sent to Zerto which
can be used solely to improve Zerto Virtual Replication.
107
Defining Masking for a Site

Also see details about the Masking for new paired sites checkbox in Site Configuration
Masking enables you to mask host information from being visible from the peer site. Instead of
the peer site being able to see ESX/ESXi IP addresses and datastores and NICs, other names can
be assigned that are seen by the peer site.
To specify site masking information to be visible by the customer site:
2. Click the Site List button in the peer site panel.
This dialog lists all the sites paired with the local site and site information about the sites.
3. Click the Edit button for a site in the list which will have masking defined for it.
Note: You can also access the Peer Site Configuration dialog by clicking the
configuration (cog) for the peer site in the topology view.
108
4. Specify a name to identify the organization hosting the site.

is increased.
7. Check the Mask vCenter Resources checkbox. Once checked, no vCenter Server resources
are exposed to the peer site. You then use the VC tab to expose resources you want the peer
site to see.
Note: If you want the peer site to protect its virtual machines to vCloud Director only, check
the Mask vCenter Resources checkbox without defining any resources.
8. In the VC tab, click the Add button for the Cluster & Hosts list.
9. From the displayed Select list, add the ESX/ESXi hosts that you want to hide.
Note: Once the Mask vCenter Resources checkbox is set, only the information added in the
tabs in this dialog is displayed in the peer site.
10. In the Presented as column, enter the name that you want displayed in the peer site.
109

Note: Click the copy link to copy the original name to the Presented as column, if you want
this specific entry to be visible in the peer site.

11. Repeat steps 9 and 10 for the Resource Pools, Datastores and Networks lists.
12. In the Folder field, specify the folder where you want to save recovered virtual machines and
disks. The specified folder and any sub-folders are the only folders displayed when creating a
VPG in the peer site.
110
Configuring vCloud Director (If Used)
When creating a VPG in the peer site, the masked values are presented:
The IP addresses for the host were masked to Cld1. Any other hosts are not displayed because
they were not added to the Cluster & Hosts list in the Peer Site Configuration dialog.
When the Mask vCenter Resources checkbox is not set, the IP addresses for the hosts in the
target site with a VRA installed, are displayed.
The host IP addresses for the target site are displayed.

You set up using vCloud Director by performing the following:
Configuring Provider vDCs, below.

Masking vCloud Director Organization vDCs and Networks, on page 115.
111
Configuring Provider vDCs


3. Click Advanced.
112

113


3. Click Advanced.
Preseed.
114
9. Click Save.
Masking vCloud Director Organization vDCs and Networks

When vCloud Director is used, the cloud provider can restrict what organization vDCs and
networks an enterprise connecting to the vCD can see.
To specify masking information for vCloud Director:
2. Click the Site List button in the customer, peer, site panel.
This dialog lists all the sites paired with the local site and information about the
communication between the sites via the VPGs defined.
3. Click the Edit button for the site for which you want to define masking.
is increased.
115
6. Check the Mask vCD Resources checkbox. Once checked, no vCD resources are exposed to
the peer site. You then use the vCD tab to expose resources you want the peer site to see.
Note: If you want the peer site to protect its virtual machines to the underlying vCenter
Server only, check the Mask vCD Resources checkbox without defining any resources.
7. Select the vCD tab.
8. Select the organization from the Select Organization dropdown listbox. The organization
names are those included in the Configure provider vDCs dialog, as described in Setting
up vCD and Configuring Provider vDCs, on page 47.
The organization vDCs and networks for this organization can then be added to the
Organization vDC and Organization Networks lists.
9. Add the organization vDCs and networks that you want the customer to see.
10. Specify the folder name where preseeded disks are saved. You must have specified disks to
use in the Configure provider vDCs dialog, described is the previous section.
11. Click Save.
116
Chapter 5: Managing Zerto Virtual

Replication
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 ongoing management options are described in this chapter:
Managing VPGs, below.

Modifying a Virtual Machine Volume Size, on page 136.
Adding a Checkpoint to Identify a Key Point, on page 137.
Ensuring Application Consistency With Microsoft Volume Shadow Copy Service (VSS), on
page 138.
Running Scripts Before or After Recovering a VPG, on page 141.
Managing VRAs, on page 148.
Managing Cloud Connectors, on page 161.
Managing a Zerto Virtual Manager, on page 163.
Managing VPGs
After defining a VPG you can manage the VPG, performing operations on the VPG including
changing the number of virtual machines protected by the VPG, modifying the VPG, and creating
a clone of the protected virtual machines.
The following VPG management options are described in this section:
Adding a Virtual Machine to an Existing VPG, below.

Modifying a VPG Definition, on page 124.
Forcing the Synchronization of a VPG, on page 127.
Cloning a VPG, on page 129.
Deleting a VPG, on page 132.
VPG Statuses and Synchronization Reasons, on page 133.
117
Managing VPGs
Adding a Virtual Machine to an Existing VPG

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 124.
Note: Adding a virtual machine to a VPG results in all checkpoints being removed and restarting
after the added virtual machine is synchronized.
You can add a virtual machine to an existing VPG, either via the VPG definition or via the Zerto
tab for the virtual machine to add. That is, if you have a specific VPG to which you need to add a
virtual machine, use the procedure To add a virtual machine to an existing VPG via the VPG
definition:, below. Use this procedure, for example, when another unprotected virtual machine
becomes used in conjunction with a group of connected virtual machines, which are already
protected. If you are working from the perspective of a virtual machine, use the procedure To add
a virtual machine to an existing VPG via the Zerto tab for the virtual machine:, on page 73.
Managing Zerto Virtual Replication
118
Managing VPGs
To add a virtual machine to an existing VPG via the VPG definition:

1. In the vSphere Client console, select the Zerto tab for the vCenter Server and then click the
Edit icon for the VPG from the list of VPGs in the VPG List dialog.
Note: You can also edit the VPG definition by selecting the Zerto tab for the vCenter Server
and then click the Edit icon for a virtual machine in the required VPGs in the VM List dialog
or by selecting the Zerto tab for a virtual machine already protected in the VPG and clicking
Actions and then click Edit VPG.
The Manage VPG dialog is displayed, enabling editing the VPG, including adding and
removing virtual machines from the VPG.
119
Managing VPGs
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.
3. Configure the virtual machine configuration, as described in To configure the virtual
machine in the VPG:, on page 120.
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.
To configure the virtual machine in the VPG:
120
Managing VPGs
Recovery Host The cluster, resource pool or ESX/ESXi that will host the recovered virtual
machine
Recovery Folder The folder where the virtual machine is recovered to.
121
Managing VPGs
a) Specify the datastore for recovery and whether the volume is a swap disk:
b) Click Save.
122
Managing VPGs
test failover operation will fail.

other tab.
c) Whether to keep the default VNIC IP configuration or not. You can only change the VNIC
123
Managing VPGs
d) Click Save.
Modifying a VPG Definition

You can modify a VPG via the Zerto tab for a virtual machine included in a VPG or from the VPG
List view 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 118, 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.
124
Managing VPGs
To modify a VPG:
1. In the vSphere Client console, either select the Zerto tab for the vCenter Server and then click
the Edit icon for the VPG from the list of VPGs in the VPG List view, or select the Zerto tab
for a virtual machine protected in the VPG, click Actions and then click Edit VPG.
The Manage VPG dialog is displayed, enabling editing the VPG, including adding and
removing virtual machines from the VPG.
125
Managing VPGs
2. Make any required changes to the VPG properties, as described in Configuring Virtual
Protection Groups, on page 59.
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 trying to save
the VPG, whether to save the VM recovery volumes or not.
126
Managing VPGs
The VPG configuration is modified. The VPG is updated and then synchronized with the recovery
site.
Forcing the Synchronization of a VPG

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.
127
Managing VPGs
To forcibly synchronize a VPG:

In the vSphere Client console, either select the Zerto tab for the vCenter Server and then click
the VPG name link for the VPG from the list of VPGs in the VPG List view, or select the
Zerto tab for a virtual machine protected in the VPG. Click Actions and then click Force Sync.
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 Cloning a VPG, below.
128
Managing VPGs
Cloning a VPG
You can create a clone of the virtual machines 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.
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:
Zerto tab for a virtual machine protected in the VPG. Click Actions and then click Clone.
The Clone dialog is displayed.
129
Managing VPGs
2. Click Configure Checkpoint to select the checkpoint to which to make the copy.
The Select Recovery Point dialog is displayed.
3. Select the point to recover to:

Last The recovery is to the last recovery point. This ensures that the data is crash consistent
for the recovery. When selecting the last checkpoint to recover to, the checkpoint used is the
last at this point. If a checkpoint is added between this point and starting the test, this later
checkpoint is not used.
Latest VSS When VSS is used the recovery will be to the latest VSS snapshot, ensuring both
that the data is crash consistent and application consistency. However, depending on how
often VSS snapshots were taken as to how much data is not recovered.
Checkpoint To a manually provided checkpoint. Checkpoints are added for the VPG from
within Zerto Virtual Replication, ensuring that the data is crash consistent to this point or via
the ZertoVssAgent ensuring both the data is crash consistent and application consistency for
the virtual machine in the VPG for which the VSS checkpoint was written. For details about
VSS checkpoints, refer to Ensuring Application Consistency With Microsoft Volume Shadow
Copy Service (VSS), on page 138. For details about adding checkpoints to ensure application
consistency when VSS is not used, see Ensuring Application Consistency Using APIs, on
page 141.
130
Managing VPGs
Check the Show VSS Only box to filter the manually defined checkpoints to display only
checkpoints defined using the ZertoVssAgent.
Time Enables moving a slider to an automatically generated checkpoint nearest to a specific
time wanted for recovery. The slider shows only a selection of the possible checkpoints. The
further back you go, the more spaced out are the checkpoints to enable a greater range. To be
even more specific use the Manual Select option.
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.
4. Click OK.
5. Select the target datastore to use for the target virtual machines.
6. Click Clone to clone the VPG.
The cloning starts and the status is displayed in the VPG details dialog.
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.
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.
131
Managing VPGs
Deleting a VPG
You can delete a VPG via the Zerto tab for a virtual machine included in a VPG.
To delete a VPG:
Zerto tab for a virtual machine protected in the VPG. Click Actions and then click Delete.
The Delete dialog is displayed.

2. 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 resynchronize to these disks faster.
3. 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.
4. 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:
132
Managing VPGs
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.
Note: Synchronization after deleting a virtual machine from a VPG results in all checkpoints
being removed and the checkpoint mechanism restarting after synchronization completes.
VPG Statuses and Synchronization Reasons

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 Bitmap Sync, the
estimated time to complete the synchronization is displayed under the VPG status, and if
relevant, the synchronization reason, such as Network Congestion.
133
Managing VPGs
VPG Statuses
The following statuses are displayed:
Status
Description
Bitmap Sync
Synchronization after WAN failure, 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.
Cleaning Up Failover Test After stopping a failover test for the VPG.
Delta Sync
A synchronization of delta changes to ensure the recovery site is up-todate. 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.
Disconnected From Peer
Communication with the Zerto Virtual Manager at the peer, recovery,

site is down so continuing protection is halted (compare with Recovery
Possible).
Disconnected From Peer

No Recovery Points
Communication with the Zerto Virtual Manager at the peer, recovery,

site is down and there are no checkpoints to use to recover the VPG at
the recovery site.
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.
Failing Over
Failing over the VPG.
Full Sync
A full synchronization.
Initial Sync
Synchronization performed after creating the VPG.
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.
Pending Remove
An attempt to remove the VPG failed and it must be forcibly removed.
134
Managing VPGs
Status
Description
Promoting
Updating the recovery machines in the VPG with data from the journal.
Protecting
Virtual machines in the VPG are protected.
Recovery Possible
Communication with the Zerto Virtual Manager at the protected site is

down so continuing protection is halted, but recovery on the peer site is
available (compare with Disconnected From Peer).
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 Sync
Synchronization when only delta changes for a volume need

synchronizing, for example, for reverse protection after a move or
failover.
Volume Full Sync
A full volume synchronization.
Volume Initial Sync
Synchronization when a full volume synchronization is required, for

example, when changing the target datastore or adding a VM to the
VPG.
VPG Synchronization Reasons

The following synchronization reasons are displayed:
Reason
Description
Force Sync
The user requested to synchronize the VPG, as described in Forcing

the Synchronization of a VPG, on page 127.
Network Congestion
The network bandwidth is not wide enough to handle all the data,
causing some of the data to be backed up.
Protected Storage Error
An I/O error occurred to a protected virtual machine, after the data was
sent to the recovery side.
Protected VRA
Congestion
The host where the VRA is installed is highly loaded: many updates are
made to the protected machines at the same time, causing a time lapse
before the updates are passed to the recovery site.
135
Modifying a Virtual Machine Volume Size
Reason
Description
Recovery or Journal
Storage Error
There was an I/O error either to the recovery storage or journal, for
example if the journal was full and the size was increased. Once the
problem is resolved a synchronization is required.
Recovery Storage
Congestion
The recovery datastore is being written to a lot, causing a delay for

some of the data passed from the protected site to be written to disk.
Recovery VRA
Communication Problem
A network error, such as the network being down for a period, requires
a synchronization of the VPG between the two sites, for example a
Bitmap Sync.
VPG Configuration
Changed
The configuration of the VPG changed resulting in a synchronization

being required. For example, the size of the journal was changed.
Modifying a Virtual Machine Volume Size

Changes to the 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.
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.
Ensuring Application Consistency

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. You can also integrate Microsoft Volume
Shadow Copy Service (VSS) with Zerto Virtual Replication or use Zerto Virtual Replication APIs
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 138.
Ensuring Application Consistency Using APIs, on page 141.
136
Adding a Checkpoint to Identify a Key Point

Checkpoints are recorded automatically every few seconds in the journal. These checkpoints
ensure crash-consistency. 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. These checkpoints ensure crash-consistency and
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.
To add a checkpoint to a VPG:

1. In the vSphere Client console, select the Zerto tab for a virtual machine protected in the VPG
and click Checkpoint.
The Add Checkpoint dialog is displayed.
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
137
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 173, or actually performing a
failover, as described in Managing Failover, on page 195, 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.
Ensuring Application Consistency With Microsoft Volume Shadow

Copy Service (VSS)
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.
138
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)
To install the ZertoVssAgent:

1. Run either ZertoVss32Agent.msi or ZertoVss64Agent.msi on every virtual machine that uses
VSS and that you want to protect with Zerto Virtual Replication, where ZertoVss32Agent.msi
is for 32-bit Windows operating systems and ZertoVss64Agent.msi is for 64-bit Windows
operating systems.
2. Follow the wizard through the installation.
The Zerto Virtual Manager Connections Settings dialog is displayed.
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 and paired, remote, sites and click OK.
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.
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 or
via the command line.
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.
139
2. Enter a name for the checkpoint.

3. Click OK.
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> <peerURL> <peerPort>
<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.
peerURL The URL for the Zerto Virtual Manager that manages the recovery site.
peerPort The HTTP port for the Zerto Virtual Manager that manages the recovery site.
checkpoint The name of the checkpoint.
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
journal for the VPG containing that virtual machine.
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 vSphere Client console for
the vCenter Server that the checkpoint is added in the VPG.
During recovery you can recover to this 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 174 and To initiate a failover from the protected site:, on page 197 or To initiate a
failover from the recovery site:, on page 208.
Changing the Zerto Virtual Manager Used

When you install the ZertoVssAgent, you specify the Zerto Virtual Manager to use to manage the
addition of checkpoints for the virtual machines that uses VSS and that you want to protect in
140
Running Scripts Before or After Recovering a VPG
VPGs. You can change the IP and port of the VPG that you specified during the installation either
by rerunning the installation and selecting the Repair ZertoVssAgent option or by editing IP
and port values in the ZertoVssAgentGUI.exe.conf file in the folder where the ZertoVssAgent
is installed.
Ensuring Application Consistency Using APIs

Using Zerto Virtual Replication checkpoints ensures the data is crash consistent when recovering
from a crash. If Microsoft Volume Shadow Copy Service (VSS) is available then it can be used to
ensure application consistency. If VSS is not used, for example for virtual machines running
Linux, you can write scripts that include Zerto Virtual Replication APIs to write checkpoints to
the Zerto Virtual Replication journal at points when there is application consistency.
For example, in the following pseudo code for Oracle Hot Backup, the second last step, alter
system switch logfile, which forces a checkpoint, can be changed to include adding a
checkpoint to the Zerto Virtual Replication journal, using the APIs:
for ts in tablespaces
alter tablespace $ts begin backup
for df in datafiles of $ts
cp $df $SAVE/$df
alter database datafile '$df' end backup
end
alter tablespace end backup
end
alter system switch logfile
alter database backup controlfile to trace
For details of the APIs, refer to the API online help.

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.
141
The scripts must be saved to the machine where the peer Zerto Virtual Manager is installed. If
the site is masked, as described in Define Masking for a Site, on page 43, you cannot see or
specify scripts in the VPG definition at the masked site, but the site that implements the masking
can edit the VPG to add scripts.
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 peer Zerto Virtual
Manager machine. For example, if the scripts are saved to C:\ZertScripts on the peer 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 operation if the
script fails.
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%.
142
When specifying scripts in the definition of a VPG, check the Use recovery scripts checkbox
to display the script field.
The following values are entered 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
executing a failover, move or test failover and the timeout value is reached, an alert is generated.
The default value is the value specified in the Site Configuration Advanced Settings
dialog.
For details about Timeout and other advanced settings, see Site Configuration Advanced
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.
1. When using the Zerto Virtual Replication APIs instead of the vSphere Client Console, and executing a failover, move or test
failover, you can set the procedure to continue even if the script fails or times out. For details of the APIs, refer to the API online
help.
143
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.
Examples 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 145.
Example 3 Replace DNS A and PTR Records, on page 147.
Example 1 Recording Failover Tests

The following script, c:\ZertoScripts\TestedVPGs.bat, writes the VPG name and date to
the TestedVPGs.txt file every time a failover test is run:
SET isodt=%date:~10,4%-%date:~7,2%-%date:~4,2% %time:~0,2%-%time:~3,2%%time:~6,2%
IF %1==Test ECHO %2 %isodt% >>
c:\ZertoScripts\Results\ListOfTestedVPGs.txt
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
144

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.
Example 2 Moving Virtual Machines to a Resource Pool After a Failover

The following PowerShell script is an example of how to move virtual machines into resource
pools as a post-recovery script. This script would typically be used when you want to move virtual
machines into a resource pool following a failover. Note that this script is a basic example and
requires some configuration, as noted in the comments of the script:
##The following are a list of requirements for this script:
##
- This script must be present in the same directory on both sites
##
listed in the Manage VPGs dialog
##
- PowerShell v2.0 installed on both Zerto Virtual Managers
##
- VMWare PowerCLI installed on both Zerto Virtual Managers
##
##This script was written by Zerto Support and is used at the customer's
##own risk and discretion.
##
##Note: The desired resource pool MUST exist on the vCenter Server prior to
##running this script.
##
##To run this script from the VPG screen, an example command is
'powershell.exe' with the parameter 'C:\ZertoScripts\Move-VMs.ps1'
##
##START OF SCRIPT
##
##PowerCLI requires remote signed execution policy - if this is not
##enabled, it may be enabled here by uncommenting the line below.
##Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Force
##Below are the variables that must be configured.
##Variables:
##The location of this script
$strMoveScriptLoc = "C:\Zerto Scripts\"
##vCenter IP address
$strVCenterIP = "10.10.10.10"
145
##vCenter user account to use; account must have the ability to move the
desired machines
$strVCUser = "Administrator"
##vcenter user password
$strVCPw = "password"
##Name of resource pool in vCenter
$strResPool = "ResourcePool"
##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")
##The PowerCLI snap-in must first be registered
Add-PSSnapin VMware.VimAutomation.Core
##Move to directory where script is located
CD $strMoveScriptLoc
##Connect to target VC server based on variables above
Connect-VIServer -Server $strVCenterIP -Protocol https -User $strVCUser Password $strVCPw
##execute the move for each VM specified
foreach ($objVM in $strVMtoMove){
Move-VM -VM $objVM -Destination $strResPool }
##Disconnect from session with VC server
Disconnect-VIServer -Server $strVCenterIP -Force
##End of script
146
Example 3 Replace DNS A and PTR Records

The following script, c:\ZertoScripts\DNS-Change.ps1, replaces multiple DNS A and PTR
records for the two DNS servers, mydns1 and mydns2.
Note: This example is for reference only. It is shown as an example of how powerful scripting
before or after a failover, move or test operation can be. The script requires CSV files with a
precise format and that all prerequisites for DNSCMD.exe are available, among other
requirements, that if not fulfilled can cause errors to the system.
Therefore, if you want to implement a similar script at your site, contact Zerto support.
## Set DNS servers in an array
$DNSservers= @("mydns1", "mydns2")
## Filepath to script and CSV files
$FP = "C:\ZertoScripts\"
CD $FP
Foreach($DNSserver in $DNSservers)
{
Import-CSV .\DNS-OldA.csv | foreach {
dnscmd $DNSserver /RecordDelete $_.zone $_.hostname A $_.ip /f}
Import-CSV .\DNS-NewA.csv | foreach {
dnscmd $DNSserver /RecordAdd $_.zone $_.hostname A $_.ip}
Import-CSV .\DNS-OldPTR.csv | foreach {
dnscmd $DNSserver /RecordDelete $_.reversezone $_.lowip PTR $_.fqdn /f}
Import-CSV .\DNS-NewPTR.csv | foreach {
dnscmd $DNSserver /RecordAdd $_.reversezone $_.lowip PTR $_.fqdn}
}
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
147
Managing VRAs
Managing VRAs
There are a number of tasks that you might need to perform on VRAs, including uninstalling
VRAs and moving the data maintained by a VRA to another VRA when an ESX/ESXi host
requires VMware maintenance.
Note: 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 section:
Maintaining Shadow VRAs, below.

Upgrading VRAs, on page 149.
Editing a VRA Host Password and Network Settings, on page 152.
Sorting the VRA List, on page 154.
Uninstalling VRAs, on page 155.
Support for VMware Host Maintenance Mode and VRA Maintenance, on page 156.
Handling a Ghost VRA, on page 159.
Maintaining Shadow VRAs

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.
Note: Shadow VRAs are configured and managed by the VRA. You cannot take snapshots of the
shadow VRAs.
148
Managing VRAs
Upgrading VRAs
When upgrading Zerto Virtual Replication, the VRAs that were installed in the previous version
are not upgraded. Zerto Virtual Replication enables working with VRAs installed on the previous
version with the current version in any combination of VRAs (all from one version or a mix of VRA
versions). It is recommended to upgrade the VRAs to be consistent with the latest version and this
can be done in the Manage VRAs dialog.
VRA Upgrade Considerations

You can upgrade a VRA in one of the following ways:
With replication downtime Upgrade the VRA without touching the virtual machines managed by
the VRA. This is a simple operation but after the upgrade the protected and recovery site need to
be synchronized, potentially impacting performance.
Non-disruptively Move the protected virtual machines and datastores managed by the VRA to
another host. This a more lengthy process but there is no replication downtime.
VRA Upgrade With Replication Downtime

Zerto Virtual Replication records all the changes to the protected virtual machines. If you are
upgrading a VRA used to recover virtual machines, a bitmap sync is performed after the upgrade.
If you are upgrading a VRA used to protect virtual machines, a delta sync is performed after the
upgrade.
To upgrade a VRA:
2. Click the configuration (cog) button in the local, left, site panel.
The Site Configuration dialog for the site is displayed.
3. Click the Manage VRAs...button.
149
Managing VRAs
You can see if an upgrade is available in the VRA Version column.

4. If an upgrade is available, select the VRA that can be upgraded and click the Upgrade
Selected button.
The VRA is upgraded and then either a bitmap sync or delta sync is performed on all VPGs
impacted by the upgrade.
Non-disruptive VRA Upgrade
To upgrade a VRA that is protecting virtual machines, VMotion the machines to another host
with a VRA that is not being upgraded and then upgrade the VRA as described in the above
procedure (To upgrade a VRA:).
To upgrade a VRA on the recovery site, use VRA maintenance to move all the VRA information
and recovery volumes maintained by the VRA to another VRA. While the VRA is in maintenance
mode, upgrade it. After the upgrade, end the maintenance for the VRA.
You can only perform VRA maintenance when you have more than one host installed at the site
and the host to be used to replace the host with the VRA being put into maintenance has access to
the datastores.
To non-disruptively upgrade a recovery VRA using VRA maintenance:
1. Click the Maintenance Mode (cog) icon for the host that you want to enter maintenance mode.
The Start Maintenance dialog is displayed.
150
Managing VRAs
2. 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. Once Zerto Virtual Replication
VRA maintenance is ready, the Manage VRAs dialog shows the maintenance status.
3. Upgrade the VRA as described in the above procedure, To upgrade a VRA:, on page 149.
151
Managing VRAs
4. Wait for the Zerto Virtual Manager to connect to the upgraded VRA. You can monitor the
alerts to determine when the connections have been established.
5. Click the Maintenance Mode (cog) icon for the target host with maintained resources selected
in step 2 to begin exiting maintenance mode.
The End Maintenance dialog is displayed.
a) The Original Host Group field includes all hosts that are using this host as the target
for maintenance. Select the host for which you want to exit maintenance mode.
b) In the Target for Original Maintenance Host field select the host you want to
manage the original host group. This can be the current host as well as the original host.
c) Click OK.
Repeat this procedure for every VRA that needs upgrading.
Editing a VRA Host Password and Network Settings

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 the VRA. If the password for the host is changed you can
change the password stored by the VRA by editing the VRA. The password is required for
situations such as rebooting or upgrading the host.
Also, if you need to change the VRA network settings, for example when the gateway to the VRA
is changed, you can do this by editing the VRA.
To edit the VRA:
1. Select the VRA to edit and click Edit Selected VRA.
The Edit VRA dialog is displayed.
152
Managing VRAs
2. Edit the VRA settings as follows:

Host Root Password If the password for the host has changed, specify the new password.
3. Click Save.
153
Managing VRAs
Sorting the VRA List

You can sort the list of VRAs by any one of the fields displayed in the dialog.
154
Managing VRAs
Uninstalling VRAs
VRAs are uninstalled via the Manage VRAs dialog.
You cannot uninstall a VRA which is used to protect virtual machines on the same host as the
VRA. Before uninstallng the VRA, VMotion protected virtual machines to another host. If the
VRA is installed on a host in a cluster it is recommended not to uninstall the VRA 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.
Note: If the VRA has crashed, or was accidently deleted, it must be forcibly uninstalled, as
described in Uninstalling a Ghost VRA, on page 160.
To remove a VRA:
Select the VRA to remove and click the Uninstall Selected VRA button.
If a VRA cannot be removed, when the VRA was installed on an ESXi version 4.x or 5.x host and
the password to the host was changed, contact Zerto support.
If the intention is to replace a VRA in a cluster, for whatever reason, 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 between removing the old VRA and installing a new VRA, it is recommended
to perform the following procedure:
1. Remove affinity rules for protected virtual machines on the host and VMotion the protected
virtual machines to another host in the cluster with a VRA installed.
2. Enter VMware Maintenance for the host.
155
Managing VRAs
3. Shutdown the VRA manually in order to enable the host to enter VMware Maintenance.
Note: The Zerto Virtual Manager attempts to boot up the VRA, generating errors when this
doesnt succeed. You can ignore these errors.
4. Remove the host from the cluster: Place it under the datacenter entity rather than the cluster
entity.
5. Take the host out of VMware Maintenance.
6. Power on the VRA.
7. Remove the VRA, as described below.
8. Once the VRA is completely removed, install a new VRA on the host and then add the host
back into the cluster.
Support for VMware Host Maintenance Mode and VRA Maintenance

When a host machine requires VMware maintenance, or you want to upgrade a VRA as described
in Upgrading VRAs, on page 149, virtual machines that are being protected on the host should
be moved to another host and VRA information and recovery volumes maintained by the VRA on
the host should be moved to another machine, at least for the duration of the maintenance, to
ensure continuous protection without additional synchronizations after the maintenance
completes.
156
Managing VRAs
You can only perform maintenance when you have more than one host installed at the site and
the host to be used to replace the host being put into maintenance has access to the datastores.
The procedure involves steps in Zerto Virtual Replication and VMware steps.
To perform VMware maintenance:
1. Click the Maintenance Mode (cog) icon for the host that you want to enter maintenance mode.
The VRA recovery data is transferred to the selected host. Once Zerto Virtual Replication
VRA maintenance is ready, the Manage VRAs dialog shows the maintenance status.
157
Managing VRAs
3. Before entering VMware maintenance mode for the host, remove affinity rules for protected
virtual machines on the host that requires maintenance and move these machines to any
other host in the cluster with a VRA installed.
4. Enter VMware Maintenance for the host.
Note: Do not migrate powered-off virtual machines, if prompted to.
5. Shutdown the VRA on the host manually in order to enable the host to enter VMware
Maintenance.
Note: The Zerto Virtual Manager attempts to boot up the VRA, generating errors when this
doesnt succeed. You can ignore these errors.
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.
12. Click the Maintenance Mode (cog) icon for the target host with maintained resources selected
in step 2 to begin exiting maintenance mode.
The End Maintenance dialog is displayed.
158
Managing VRAs
a) The Original Host Group field includes all hosts that are using this host as the target
for maintenance. Select the host for which you want to exit maintenance mode.
b) In the Target for Original Maintenance Host field select the host you want to
manage the original host group. This can be the current host as well as the original host.
c) Click OK.
Handling a Ghost VRA

When an event occurs, for example the host machine crashes or the VRA is accidentally deleted, if
the VRA has SAN 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 mode.
159
Managing VRAs
Note: When selecting the ghost VRA the buttons change to Upgrade Selected VRA and Force
Uninstall.
To recover VRA disks from a ghost VRA:

1. Click the Maintenance Mode (cog) icon for the ghost VRA.
The VRA recovery data is transferred to the selected host, however after the transfer
completes the VRA maintenance status does not change.
3. Forcibly uninstall the VRA as described in Uninstalling a Ghost VRA, below, and then
install a new VRA.
Uninstalling a Ghost VRA

When either the VRA or shadow VRA crashes, or is accidently deleted, you can recover the data
managed by the VRA as described in Handling a Ghost VRA, on page 159, but you have to
forcibly uninstall the VRA and any shadow VRAs and then reinstall the VRA, as described in
160
Managing Cloud Connectors
To forcibly uninstall a ghost VRA:

1. Make sure any virtual machines that were protected by this VRA are moved to another host
with a VRA. The VPGs affected have a status of Recovery Possible.
2. Select the ghost VRA and click the Force Uninstall button.

Zerto cloud connectors are installed during the initial configuration of the site, as described in
Install Cloud Connectors, on page 34. During normal operation there should be no need to
manage the cloud connector. However if something happens to the cloud connector or the ESX/
ESXi hosting it, you might need to repair it, as described below.
Note: Cloud connectors are configured and managed by the Zerto Virtual Manager. You cannot
take snapshots of cloud connectors as snapshots cause operational problems for the cloud
connectors.
161
Handling a Ghost Cloud Connector

When an event occurs, for example the host machine crashes or the cloud connector is
accidentally deleted, the cloud connector is displayed in the Manage Cloud Connectors dialog
as a Ghost Cloud Connector.
You can repair the cloud connector by selecting is and clicking the Repair Cloud Connector button
to reinstall the cloud connector with the original settings.
162
Managing a Zerto Virtual Manager
A new cloud connector is created using the same settings as the original cloud connector. At the
end of the process, the ghost cloud connector is removed.

The Zerto Virtual Manager runs as a Windows service and connects to the vCenter Server and the
vSphere Client console. You can perform the following management tasks on the Zerto Virtual
Manager:
Reconfiguring the Zerto Virtual Manager IP Addresses, below.

Restore the Zerto Virtual Manager to a Backed Up Version, on page 166.
Reconfiguring the Zerto Virtual Manager IP Addresses

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 connecting to the vSphere Client console.
You can change these IP addresses if necessary, using the Zerto Virtual Replication Diagnostics
utility.
163
To reconfigure the Zerto Virtual Manager:

1. Click Start > Programs > Zerto Virtual Replication > Zerto Diagnostics.
The Zerto Virtual Replication Diagnostics menu dialog is displayed.
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
3. Click Next.
The dialog for Zerto Virtual Manager setup is displayed:
164
IP for use by vSphere Client The IP to access the Zerto Virtual Manager from the vSphere
Client console. 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 The port used for inbound communication between the vSphere Client console and
the Zerto Virtual Manager.

TCP Port The port used for communication between Zerto Virtual Managers.
Both the protected and recovery sites belong to the same enterprise If you change the value,
when pairing sites, use the TCP port value specified here.
A cloud provider supplies disaster recovery services to the enterprise You must not change
this value.
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.
165
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 peer sites and then pair the sites again.
Restore the Zerto Virtual Manager to a Backed Up Version

The Zerto Virtual Manager runs as a Windows service. If for any reason the machine on which it
runs becomes corrupted, you can restore it to a previous point-in-time, using an existing backup of
the machine. In order for the backed up version to function with the existing VRAs and Zerto
Virtual Manager on remote sites, you have to run a Zerto utility on the backup.
Note: You can only restore a Zerto Virtual Manager for the same version.
The following issues are resolved by removing the problematic entities:
A VRA or shadow VRA is defined on a host but is not recognized by the Zerto Virtual Manager
the VRA is removed.
A VRA or shadow VRA is registered with the Zerto Virtual Manager but does not exist in the
vCenter Server the Zerto Virtual Manager is cleaned up.
A cloud connector is defined on a host but is not recognized by the Zerto Virtual Manager
the cloud connector is removed.
A cloud connector is registered with the Zerto Virtual Manager but does not exist in the
vCenter Server the Zerto Virtual Manager is cleaned up.
A VPG is defined on one site but not the specified paired site the VPG is removed from the
site where it is defined.
A VPG is defined on both sites with mismatching volumes or virtual machines the VPG is
removed from both sites.
To restore a Zerto Virtual Manager:

1. Power off the original machine that hosted the Zerto Virtual Manager.
2. Create another machine with the Zerto Virtual Manager from the available backup, making
sure that this machine is not powered on after it is created.
3. Disconnect the NICs on the new Zerto Virtual Manager machine.
4. Power on the restored Zerto Virtual Manager machine and log in to it.
5. Verify the Zerto Virtual Manager service is stopped and disabled. If the Zerto Virtual
Manager is running, stop it and change the Startup Type to Disabled.
6. Reconnect the NICs and verify connectivity to the remote site.
7. Verify that the restored machine has the same IP address as the original machine. If the IP is
different, set the static IP address to be the same as the original machine hosting the Zerto
Virtual Manager.
166
8. Run the restore utility: <Zerto Virtual ReplicationInstallationDir>\Zerto

Virtual Replication\ZvmRepair.exe, where Zerto Virtual
ReplicationInstallationDir is the folder where Zerto Virtual Replication was installed,
for example, C:\Program Files (x86)\Zerto.
9. Restart the vSphere Client console to load the GUI.
The utility reconfigures the Zerto Virtual Manager and resolves any issues, as described above.
For example, deleting a VPG when the volumes or virtual machines specified in the VPG are not
the same on the protected and recovery sites. The utility starts up the Zerto Virtual Manager
before finishing and lists all the VPGs that were removed in a text file, named Repair ReportYYYY-MM-DD_HH-MM-SS-A/PM.txt, in the same folder where the utility runs.
After the Zerto Virtual Manager restarts on the new machine, it needs to establish connections to
paired Zerto Virtual Managers and to power on the VRAs on the local site and establish a
connection with them. This can take a few minutes.
Removing the VPG from the remote site will only occur once communication between the restored
Zerto Virtual Manager and the remote Zerto Virtual Manager has been established.
167
Chapter 6: Recovery Procedures

Zerto Virtual Replication provides a number of operations to recover virtual machines at the peer
site. This chapter describes these procedures. The following topics are described in this chapter:
The Move Operation, below

The Failover Operation, on page 169
The Failover Test Operation, on page 170
The Clone Operation, on page 171
The Move Operation

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 187.
168
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.
The Failover Operation

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.
Note: To identify the checkpoint to use, you can perform a number of test failovers, each to a
different checkpoint.
Failback After the Original Site is Operational

After completing a failover, when the original site is back up and running you can move the
recovered virtual machines back again using the Move operation. The VPG that is now protecting
the virtual machines on the target site has to be configured and then a delta sync is performed
with the disks in the source site. Once the VPG is in a protecting state the virtual machines can
Recovery Procedures
169
The Failover Test Operation
be moved back to the source site. For details, see Migrating a Protection Group to the Recovery
Site, on page 187.
For details, see Managing Failover, on page 195.
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.
The Failover Test Operation

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 virtual disks
managed by the VRA. The journal is used to track any changes made to these machines so that at
the end of the test the journal can be returned to its normal state, with data and checkpoints from
the protection site only.
The longer the test lasts the more journal space is required to track changes to the test recovered
machines, which can cause space problems with the test machines and IO errors.
Recovery Procedures
170
The Clone Operation

Note: 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.
For details, see Testing Recovery, on page 173.
The following diagram shows the positioning of the virtual machines before and during a Failover
test operation.
The Clone 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.
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.
For details, see Cloning a VPG, on page 129.
Recovery Procedures
171
The Clone Operation
completion of a Clone operation.
Recovery Procedures
172
Chapter 7: Testing Recovery

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 Test Failover Process, below.

Starting and Stopping Failover Tests, on page 174.
Viewing Test Results, on page 180.
Live Disaster Recovery Testing, on page 181.
The Test Failover Process

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 to a specified point-intime, using the virtual disks managed by the VRA. The journal is used to track any changes made
to these machines so that at the end of the test the journal can be returned to its normal state,
with data and checkpoints from the protection site only.
The longer the test lasts the more journal space is required to track changes to the test recovered
machines, which can cause space problems with the test machines and IO errors.
Note: 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 211.
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.
173
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.
Note: The test virtual machines use the journal, so there is no promotion from the journal.
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 59. 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. For a single VPG, in the Zerto tab for one of the virtual machines in the VPG to test, set the
operation to Test and click Failover.
For multiple VPGs, in the Zerto tab for the root vCenter Server node, in either the VPG List
or VM List dialogs, set the operation to Test and click Failover. The Test Failover wizard
is displayed.
Testing Recovery
174

Note: You can perform failover tests on VPGs whether managing the VPGs from the protected
site or the recovery site. You can set the operation to Test and click Failover in either site.
Select the VPGs to test from the list. You can test VPGs from either the local or remote sites.
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.
2. Click Next
3. 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.
Testing Recovery
175

page 141.
5. Click OK.
6. Click Next.
Testing Recovery
176
7. Click the Failover arrow to start the test.

The test starts for the selected VPGs.
The virtual machines in the virtual protection group are created at the recovery site with the
suffix testing recovery.
The VPG continues to be protected and you can add checkpoints to it and if necessary failover the
VPG, as described in Initiating a Failover During a Test, on page 211. However, during the test
you cannot move the VPG.
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.
Testing Recovery
177
You can monitor the status of the test in the VPG List dialog 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 VPG List dialog shows the status as Test.
Testing Recovery
178
To stop a failover test:

1. In the Zerto tab for one of the virtual machines in the VPG being tested, click the test icon
(
) in the testing area in the top right of the dialog.
Alternatively, in the VPG List view you can click the test icon the Status for the VPG.
The View Failover Tests dialog is displayed.
2. In the Result field specify whether the test passed or failed.

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.
Testing Recovery
179
Viewing Test Results
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.
Viewing Test Results

After stopping a test, you can see the test results as part of Zerto Virtual Replication reports.
Refer to Failover Tests, on page 228,
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 the VPG List and VM List views,
in the last column.
Testing Recovery
180
Live Disaster Recovery Testing

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
Testing Recovery
181
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 Verification User Traffic Is Not Run Against the Recovered

VMs
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.
Using a Failover Test Operation

You use a Failover Test operation if recovering the virtual machines in a sandbox, with network
isolation, is sufficient for the test.
Procedure
The Failover Test operation is described in Starting and Stopping Failover Tests, on page 174.
Failover Test Considerations
You dont have to shutdown the protected virtual machines and changes from the test phase
are not kept or applied to the source applications.
You can recover to a specific point-in-time.
You can use an isolated network to enable testing in a sandbox environment and not a live DR
environment. This is the recommended practise.
During the testing period, every change is recorded in the journal. Thus, since both the
journal and moved virtual machines are on the same site, performance can be impacted.
The longer the test period the bigger the journal, which can result in the journal becoming too
full, generating system errors, even before the test time has ended.
Testing Recovery
182
Using an Uncommitted Move Operation

You use a Move operation with the commit/rollback policy set to rollback after the test period, if
recovering the virtual machines needs testing in the recovery site production environment.
Procedure
The Move operation is described in Moving Protected Virtual Machines to the Peer Site, on page
188. 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 VMTools.
3. After testing the machines in the recovery site you can rollback the Move operation, which
will return the virtual machines to there pre-test state.
Note: Alerts are issues if the journal starts to become too full.
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 the journal to enable rolling back. This
can impact performance.
The longer the test period the bigger the required journal space, which can result in the
journal becoming too full, generating system errors, even before the specified test time has
ended.
You can only recover to the last checkpoint written to the journal, at the beginning of the
Move operation.
Run User Traffic Against the Recovered VMs

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.
Testing Recovery
183

Clone operation When the source application has to continue throughout the test.
Using a Move Operation

You use a Move operation when you can shut down the source virtual machines but you dont
want to simulate an actual disaster. After the virtual machines have been recovered in the target
site they are used as the protected machines for as long as the test lasts.
Procedure
The Move operation is described in The Move Operation, on page 168 and in Moving Protected
Virtual Machines to the Peer Site, on page 188. The following procedure highlights specific steps
to enable using the Move functionality for a DR test.
In the Move Wizard Configure dialog, uncheck the commit policy checkbox.
Ending the Test

Move the VPG back to the source site. A delta sync is performed to copy the new transactions
performed on the virtual machines in the target site back to the source site.
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.
Testing Recovery
184
Using a Failover Operation

You use a Failover operation when you can shut down the source virtual machines and you want
to simulate an actual disaster. After the virtual machines have been recovered in the target site
they are used as the protected machines for as long as the test lasts.
Using a Failover operation to test DR requires specific steps to ensure that the virtual machines
are gracefully migrated to the target site, similar to a Move operation and that, like a Move
operation they can be verified prior to committing the failover.
Procedure
The Failover operation is described in Initiating a Failover From the Protected Site, on page
197. The following procedure highlights specific steps for a DR test.
1. Manually shutdown the virtual machines.
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. 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
sync 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.
Testing Recovery
185
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.
Using a Clone Operation

You use the Clone operation when the source application has to continue throughout the test. You
can create a clone of the virtual machines in a VPG on the peer site to a specific point-in-time. 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.
Procedure
The Clone operation is described in Cloning a VPG, on page 129.
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, none of the changes to the clone are kept.
The original virtual machines on the source site are live and online throughout the test.
Testing Recovery
186
Chapter 8: Migrating a Protection

Group to the Recovery Site
Zerto Virtual Replication enables both recovering the virtual machines in a VPG both after an
unforeseen disaster, as described in Managing Failover, on page 195, and in advance of an event
that requires the migration of the virtual machines in the VPG to the peer site. This chapter
describes a planned migration of a VPG to the peer site.
The Move Process, below.

Moving Protected Virtual Machines to the Peer Site, on page 188.
Reverse Protection For a Moved VPG, on page 193.
The Move Process

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 195.
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.
187
Moving Protected Virtual Machines to the Peer 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 peer 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 peer 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.
Migrating a Protection Group to the Recovery Site
188
To initiate a move:
1. For a single VPG, in the Zerto tab for one of the virtual machines in the VPG to migrate, click
Move.
For multiple VPGs, in the Zerto tab for the root vCenter Server node or for any datacenter
node, click Move. Select the VPGs from the list and click Next.
The Move Wizard Configure dialog is displayed.
2. Specify the commit policy. The default policy displayed is the policy set in the Advanced
Settings dialog, described in Site Configuration Advanced Settings, on page 101.
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.
3. If you want to set up reverse protection, whereby the virtual machines in the VPG that is
moved are protected in the peer site, check the Reverse Protection checkbox for the VPG
and then click the Configure link.
If you specify reverse protection, the VPG configuration dialog for the reverse protection is
displayed, with a default configuration, based on the original VPG definition.
189
You can edit the configuration, as described in Configuring Virtual Protection Groups, on
page 59, with the following differences:
You cannot add or remove virtual machines to the reverse protection VPG.
By default, reverse protection 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 in thin provided 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 step 9 in
To create a virtual protection group (VPG):, on page 60.
190
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 VMTools
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 60.
4. 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 VMTools is not installed on one of the virtual machines in the VPG. If you do
not check this box and a virtual machine in the VPG cannot be shut down gracefully, the move
operation stops and rolls back to the situation before the move started.
5. Click Next.
6. Click the Move arrow to start the migration.
7. If a commit policy was set with a timeout greater than zero, as described in step 2, you can
check the moved virtual machines on the peer site before removing the machines from the
original site to complete the move operation.
191
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 peer site with a number added as a
suffix to the name, starting with the number 1.
8. After checking the virtual machines on the recovery site, either:

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.
192
Reverse Protection For a Moved VPG
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 3.
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 peer site back to the original protected site.
Reverse Protection Specified

When you specify reverse protection, the virtual machines are moved to the recovery site and then
protected using the values specified during the move. Data is promoted from the journal to the
moved virtual machines and then synchronization with the original site is performed so that the
193
VPG is fully protected. The synchronization used is either a delta synchronization or if there is
only one volume to synchronize, a volume delta synchronization is performed.
Reverse Protection Not Specified

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 and the target
datastores are not set. 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.
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.
194
Chapter 9: Managing Failover

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 peer site, as described in Migrating a Protection Group to the
Recovery Site, on page 187. This chapter describes how to perform a failover to the recovery site.
The Failover Process, below.

Initiating a Failover From the Protected Site, on page 197.
Reverse Protection For a Failed Over VPG, on page 204.
Initiating a Failover From the Recovery Site, on page 205.
Initiating a Failover During a Test, on page 211.
The Failover Process

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 187.
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 173. 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.
195
The Failover Process
The Failover operation has the following basic steps:

1. If the source site or Zerto Virtual Manager is down, continue with step 2.
If the source site or Zerto Virtual Manager is still running, determine the failover
requirements:
If the default is requested, doing nothing to the protected virtual machines, the failover
operation continues with step 2.
If shutting down the protected virtual machines is requested and the protected virtual
machines do not have VMware Tools available, the failover operation fails.
If forcibly shutting down the protected virtual machines is requested, the protected source
virtual machines are shut down.
2. Create the virtual machines at the remote site in the production network and attach each
virtual machine to its relevant vdisks, configured to the checkpoint specified for the recovery.
Note: The source virtual machines are not touched since the assumption is that the source
protected site is down.
3. Power on the virtual machines making them available to the user. If applicable, the boot order
defined in the VPG settings to power on the machines in a specified order is used.
4. The default is to automatically commit the failover operation without testing. However, you
can also run basic tests on the machines to ensure their validity to the specified checkpoint.
Dependent of the commit/rollback policy that you specified for the operation after testing
either the operation is committed, finalizing the failover or rolled back, aborting the
operation.
5. If the source site is still available, for example, after a partial disaster, and reverse protection
is possible and specified for the failover operation, the source virtual machines are powered
off and removed from the inventory. 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.
Note: If reverse protection is not possible, the source site virtual machines are not powered off
and removed.
6. 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.
Failback After the Original Site is Operational

To perform a failback to the source site, the VPG that is now protecting the virtual machines on
the target site has to be configured and then a delta sync is performed 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, as described in Migrating a Protection Group to the Recovery Site, on page 187.
Managing Failover
196
Initiating a Failover From the Protected Site

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 211.

If you have time to initiate the failover from the protected site you can, as described below.
However, if the protected side is down, you initiate the failover from the recovery sight, as
described in Initiating a Failover From the Recovery Site, on page 205.
To initiate a failover from the protected site:
1. For a single VPG, in the Zerto tab for one of the virtual machines in the VPG to test, set the
operation to Live and click Failover.
For multiple VPGs, in the Zerto tab for the root vCenter Server node, in either the VPG List
or VM List dialogs, set the operation to Live and click Failover. The Live Failover wizard
is displayed.
Select the VPGs from the list. You can fail over VPGs from either the local or remote sites.
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.
2. Click Next.
The Live Failover Wizard Configure dialog is displayed.
Managing Failover
197
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
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
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.
4. 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.
Yes If the protected virtual machines have VMware Tools available, the virtual machines
are gracefully shut down, otherwise the failover operation fails.

Force The protected virtual machines are forcibly shut down before starting the failover.
5. 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.
Managing Failover
198

page 141.
7. Click OK.
Managing Failover
199
8. 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 peer 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.
If you specify reverse protection the VPG configuration dialog for the reverse protection is
displayed, with a default configuration, based on the original VPG definition.
You can edit the configuration, as described in Configuring Virtual Protection Groups, on
page 59, 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 in thin provided 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 step 9 in
To create a virtual protection group (VPG):, on page 60.
Managing Failover
200
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 VMTools
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 60.
9. Click Next.
10. Click the Failover arrow to start the failover.
check the failed over virtual machines on the peer site before completing the failover
operation.
Managing Failover
201
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.
being failed over, the machine is created and named in the peer site with a number added as a
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.
Or,
Click Commit.
The Commit Failover dialog is displayed.
Managing Failover
202
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 in step 8.
Click Commit to continue the failover operation.
virtual machines vdisks, these virtual machines are removed from this site. 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 59. 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.
Managing Failover
203
Reverse Protection For a Failed Over VPG
Reverse Protection For a Failed Over VPG

When you specify reverse protection, the virtual machines are recovered on the recovery site and
then protected using the values specified during the failover. First 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
synchronization or if there is only one volume to synchronize, a volume delta synchronization is
performed.
If you do not specify reverse protection, the VPG definition is kept with the status Needs Reverse
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.
Managing Failover
204
Initiating a Failover From the Recovery Site

If the protected site is already down, you can initiate the failover from the recovery site, from the
vSphere Client console for the recovery site vCenter Server, in the Zerto tab.
When the Zerto Virtual Manager managing the protected site is down, via the vSphere Client
console for the recovery site vCenter Server, the protected site right panel shows up in the Zerto
tab, grayed.
Managing Failover
205
The VPG Details shows that recovery is possible:
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.
The following alert is issued:
[siteName] The Zerto Virtual Manager not connected to Hostname ip,port #
Managing Failover
206
You can see that the Zerto Virtual Manager service is down from the Alerts report:
If the vCenter Server is down, some of the protected virtual machines might not be protected. The
following alert is displayed in the Alerts report:
Managing Failover
207
To initiate a failover from the recovery site:

1. In the Zerto tab for the root vCenter Server node, in the right panel, which represents the
source protected site, set the operation to Live and click Failover.
After clicking Failover, the Live Failover wizard is displayed.
2. Select the VPGs to recover.
Note: If any of the VPGs were in the process of being synchronized, they cannot be recovered.
3. Click Next.
The Live Failover Wizard Configure dialog is displayed.
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
VPG virtual machines have failed over as required and 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
5. 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.
Managing Failover
208

page 141.
7. Click OK.
Managing Failover
209
8. If the protected site is not completely down you may be able to set up reverse protection,
whereby the virtual machines in the VPG that is recovered are protected in the peer site,
check the Reverse Protection checkbox for the VPG. If possible the Configure link is
displayed to enable setting up reverse protection, otherwise click Next.
9. Click the Failover arrow to start the failover.
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.
being failed over, the machine is created and named in the peer site with a number added as a
virtual machines vdisks, these virtual machines are powered off.
Or,
Click Commit.
The Commit Failover dialog is displayed.
Managing Failover
210
Initiating a Failover During a Test
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 in step 8.
Click Commit to continue the failover operation.
The VPG List on the recovery machine shows the status of the VPGs that are being recovered.
When there is no connection with the protected site, the traffic light 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 traffic light indicator changes to yellow.
Initiating a Failover During a Test

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 From the Protected Site, on page 197.
Note: You cannot initiate a failover while a test is being initialized or closed.
Managing Failover
211
Chapter 10: Zerto Virtual Replication

Reports
You can 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, any of the virtual
machines being protected and any alerts in both sites.
Monitoring Site Details, below.

Monitoring Virtual Protection Groups, on page 215.
Monitoring Protected Virtual Machines, on page 219.
Monitoring Zerto Virtual Replication Peer Sites and Site Topology, on page 222.
Zerto Virtual Replication Reports, on page 225.
Seeing What is Licensed, on page 240.
212
Monitoring Site Details

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 is one VPG defined on a recovery site that is protected to the
production site.
The following information is displayed in the left panel:
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.
Zerto Virtual Replication Reports
213
The amount of storage being replicated to the peer site out 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 peer 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.
VRA CPU Usage The percentage of the CPU being used by the VRA.
The number of VPGs meeting the target RPO, the SLA, specified as part of the VPG
definition.
When applicable, the date of the last test performed and the name of the VPG tested.
The amount of storage being replicated to this site from the peer site.
The following information is displayed in the right panel:
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 replicated to the peer site out of the total possible for all the
virtual machines in all the VPGs defined on this site.
The amount of storage being replicated to this site from the peer site.
214
Monitoring Virtual Protection Groups

View specific details of the VPGs in the VPG List dialog. This dialog lists all the VPGs from both
the local and peer sites and provides summary details of each VPG.
The following information is displayed:
Traffic light indicator The color of the traffic light icon indicates the status of the VPG:
Green The VPG is being replicated, including syncing the VPG between the sites.
Yellow The VPG is being replicated but there are problems, such as an RPO value larger
than the defined maximum.

Red The VPG is not being replicated, for example because communication with the peer site
is down.
Direction The direction of the replication, from this site to the peer site or from the peer site
to this site.
Func Icons you click to perform further actions, such as editing or deleting the VPG.
Type Icons describing the source and target sites: vCenter Server or vCloud Director:
215
Source Site Name The name of the site where the VPG is protected.
Target Site Name The name recovery site for the VPG.
Organization Name A name given to the organization.
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.
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.
Priority The priority specified for the VPG in its definition.
# VMs The number of VMs being protected in the VPG.
Provisioned 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 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 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 peer site for replication.
Network A visual representation of the WAN traffic.
Actual RPO The time since the last checkpoint was written to the journal. This should be
less than the target RPO value specified for the VPG.
Last Test The date and time of the last failover test performed on this VPG.
Determining Which Columns to Display and the Order They Are Displayed
When moving the mouse pointer over the list, a configuration cog is displayed on the right of the
list. Clicking the cog icon opens the Edit Columns dialog, where you can specify what columns to
display in the list.
You can also reset the display to the default display by clicking the Reset Columns link.
The ability to reset the columns and to open the Edit Columns dialog is also available by rightclicking 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.
216
Saving Details of Virtual Protection Groups to File

You can save details of every VPG displayed in the VPG List dialog to a CSV file, which can be
opened using programs such as Microsoft Excel.
In the VPG List dialog, click the Export to CSV button and specify where to save the VPG details.
217
Monitoring a Virtual Protection Group

You monitor the status of each VPG from the Zerto tab for any protected virtual machine in the
protected site or by drilling-down from a VPG in the VPG List dialog or from a virtual machine
in the VM List dialog.
The view provides the following information:
The status of the protection, such as Updating, Syncing, Protecting, Testing, Missing
Configuration.
Summary details, including the number of virtual machines being protected in the VPG,
amount of data protected on the local site and the amount being replicated on the recovery
site and the date and time of the last failover test.
Performance details:
IOPS 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 peer site for replication.
Current RPO The time since the last checkpoint was written to the journal. This should
be less than the target RPO value specified for the VPG.
Configuration details including the general properties defined for the VPG. For information
about the configuration details, see Configuring Virtual Protection Groups, on page 59.
218
Monitoring Protected Virtual Machines
A table of the protected virtual machines including the name of the virtual machine, the
source and target ESX/ESXi hosts, the source and target datastores and the provisioned and
used storage and the recovery storage and the networks specified for failovers and moves and
for test failovers.

View specific details of the protected VMs in the VM List dialog. This dialog lists all the virtual
machines from both the local and peer sites and provides summary details of each virtual
machine.
Traffic light indicator The color of the traffic light icon indicates the status of the VPG:
Green The VPG is being replicated, including syncing the VPG between the sites.
Yellow The VPG is being replicated but there are problems, such as an RPO value larger
Red The VPG is not being replicated, for example because communication with the peer site
is down.
Direction The direction of the replication, from this site to the peer site or from the peer site
to this site.
219
Func Icons you click to perform further actions, such as editing or deleting the VPG.
Type Icons describing the source and target sites: vCenter Server or vCloud Director:

Source Site Name The name of the site where the VPG is protected.
Target Site Name The name recovery site for the VPG.
Organization Name A name given to the organization.
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.
VPG 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.
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.
Priority The priority specified for the VPG in its definition.
# VMs The number of VMs being protected in the VPG.
Provisioned The provisioned storage for the virtual machine 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 The storage used by the virtual machine 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.
IOPS 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 peer site for replication.
Throughput The MBs for all the applications running on the virtual machine being
Network A visual representation of the WAN traffic.
Actual RPO The time since the last checkpoint was written to the journal. This should be
less than the target RPO value specified for the VPG.
Last Test The date and time of the last failover test performed on the VPG protecting this
virtual machine.
220
221
Monitoring Zerto Virtual Replication Peer Sites and Site Topology
Monitoring Zerto Virtual Replication Peer Sites and

Site Topology
You can display information about the peer sites for the local site either as a list via the Site
List dialog or graphically via the Topology view.
The Site List Dialog

View specific details of the peer sites in the Site List dialog. This dialog lists all the peer sites
and provides summary details of each peer site.

Site Name The name specified for the site during installation or in the Site Configuration dialog.
Organization Name A name used to describe the organization that hosts the site.
# VPGs The total number of VPGs being protected by both sites.
Used/Permitted # VMs The total number of virtual machines being protected by both sites and the
maximum allowed to be protected.
222

Used/Permitted storage (GB) The total storage being protected by both sites and the maximum
storage allowed to be protected.
Location The location specified for the site during installation or in the Site Configuration
dialog.
223
The Topology View

The Topology view 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. For all remote sites you can click the configuration (cog) button to access the Peer
Site Configuration dialog, described in Defining Masking for a Site, on page 108.
The traffic light indicator icon that indicates the status of the site:
Green The site VPGs are being replicated, including syncing the VPGs between the sites.
Yellow The site VPGs are being replicated but there are problems, such as an RPO value larger

Red The site VPGs are not being replicated, for example because communication with the peer
site is down.
224

Zerto Virtual Replication includes reporting for the following:
Alerts Report Issued by Zerto Virtual Replication, below.

Audit Report, on page 227.
Failover Tests, on page 228.
Outbound Protection Over Time, on page 229.
Protection Over Time by Organization, on page 230.
Top Sites Reports, on page 231.
Usage, on page 237.
VPG Performance, on page 238.
The Alerts report is displayed by default when accessing the Reports item.
225
Alerts Report Issued by Zerto Virtual Replication

During operations, Zerto Virtual Replication issues alerts if something happens that relates
specifically to Zerto Virtual Replication, such as not testing the replication within the specified
timeframe. These alerts are displayed in the Alerts tab under the Reports item.
Warnings are indicated by the yellow 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 traffic light icon in the top middle of the Zerto tab 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 traffic light indicator changes, if appropriate, to show the new alert status.
You can dismiss alerts by clicking the trash can function icon for an alert.
You can see more details about any alert by clicking the More link for the alert.
226
Audit Report
The Audit report displays a log of tasks performed within Zerto Virtual Replication. The Audit
tab under the Reports item.
You can specify how you want to filter the log activity displayed for the following:
From and To The dates for which you want activity information. Only activities performed,
between these dates are displayed.

VPG Select the VPGs for which you want activity information displayed. If more than one VPG
is selected, Multiple Selection is displayed for the field. The list displays all VPGs.
Site Select the sites for which you want activity information displayed. If more than one site is
selected, Multiple Selection is displayed for the field. The list displays all paired sites with
the local site.
Event Type Select the events for which you want activity information displayed, such as
Installing VRAs, pairing to sites or creating VPGs. If more than one event type is selected,
Multiple Selection is displayed for the field.
User Select the users for which you want activity information displayed. If more than one user is
selected, Multiple Selection is displayed for the field. The list displays all users logged in to
vSphere Client console at any of the paired sites.
Click Apply to apply the filtering selected via any of the above fields.
227
Click Reset to reset the display to the defaults values.

You can see more details about any activity by clicking the More link for the activity.
Failover Tests
Information about failover tests can be displayed in the Tests tab under the Reports item. The
information includes when the test was started and the duration of the test, the time taken to
bring up the machines in the recovery site, the RTO, and whether the test succeeded or not and
any notes added about the 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.
Status Select the Statuses for which you want test information displayed. If more than one
status is selected, Multiple Selection is displayed for the field.
228
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.
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.
229
Protection Over Time by Organization

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.

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 everything.
230
Top Sites Reports

When multiple sites are configured, for example with a cloud provider, you can monitor how the
top sites are performing against specific criteria:
Top Sites by SLA Levels, on page 231 How sites are performing with respect to the specified
target RPO per VPG and the actual RPO and RTO values. You can see the top sites that are
meeting the SLA levels and the sites that are failing to meet these levels.
Top Sites by VMs and Data, on page 233 The sites with the most virtual machines and data being
protected.
Top Sites Failing to Meet Their SLA Levels, on page 235 Information per site about the VPGs
protecting virtual machines in the site that are failing to meet the target RPO values specified in
each VPG.
Top Sites by SLA Levels

Information per site about the VPGs protecting virtual machines in the site and the response of
these VPGs based on the defined target RPO for each VPG against the actual RPO and the actual
RTO based on failover tests for the VPG.
Move the slider to Grid to see the information in a table.
231
Move the slider to Chart to see the information graphically.

Max Results The maximum number of sites listed.
Date The date for which you want the information.
Top Priority How the sites should be sorted, by the target RPO defined in the VPG definition, the
actual RPO, based on the time between checkpoints, or the actual RTO, based on the time to
recover the virtual machines in the VPG during a failover test.
Site Select the site for which you want information displayed or for all the sites. If all the sites
are selected, All is displayed for the field. The list displays all sites paired with the local site.
232
Top Sites by VMs and Data

Information per site about the number of virtual machines being protected the total configured
size of these machines and the amount of data being protected.
Move the slider to Grid to see the information in a table.
233

Date The date for which you want the information.
234
Top Sites Failing to Meet Their SLA Levels

Information per site about the VPGs protecting virtual machines in the site to identify those that
are failing to meet the target RPO values specified in each VPG.

From and To The dates for which you want the information.
Top Priority How the sites should be sorted, by RPO difference between the specified target RPO
and actual RPO or the duration, being the length of time the RPO value was not met.
235
Select a VPG and click Show VPGs SLA History to display RPO details for the VPG:
236
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.

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).
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 a CSV file in a zip file.
237
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.
238
Position the cursor on the graph line to see exact information about that point.
Customizing the Performance Graphs

You can change the scale used for the graphs in the Advanced Settings tab, described in Site
Configuration Advanced Settings, on page 101.
239
Seeing What is Licensed

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.
The license includes the following details:

License The license key itself.
License ID An identifier for the license.
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.
240

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.
To update a license key:
3. Click License.
The Zerto License dialog is displayed.
4. Enter a valid license key and click Update.
5. Click Close.
The license is updated on the local site and the paired peer sites.
241
Chapter 11: How Zerto Virtual

Replication Works With VMware
Features
This chapter describes the interaction between Zerto Virtual Replication and commonly used
VMware features such as VMotion, DRS and HA.
Protecting Virtual Machines in a vApp, below.

Protecting Virtual Machines that Use Thin Provisioning, on page 243.
Zerto Virtual Replication and VMware Clusters, on page 243.
Zerto Virtual Replication and Fault Tolerance, on page 245.
Zerto Virtual Replication and Host Affinity Rules and CPU Pinning, on page 245.
Ensuring VPG Integrity When Using VMotion, on page 245.
Zerto Virtual Replication and Storage VMotion, on page 246.
VMware Host Maintenance Mode, on page 246.
VMware Roles and Permissions, on page 246.
Protecting Virtual Machines in a vApp

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.
242
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, on page 74.
Protecting Virtual Machines that Use Thin

Provisioning
VMware vStorage thin provisioning is a component of vStorage that enables over-allocation of
storage capacity for increased storage utilization, enhanced application uptime and simplified
storage capacity management.
When migrating or recovering the virtual machines in a VPG, the virtual machines are migrated
or recovered with the same configuration as the protected machines. Thus, if a virtual machine in
a VPG is configured with thin provisioning, then during migration or recovery the machine is also
defined in the recovery site as thin provisioned.
Zerto Virtual Replication and VMware Clusters

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).
How Zerto Virtual Replication Works With VMware Features
243
Zerto Virtual Replication and VMware Clusters

Note: 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.
VMware 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 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 173, 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 mirror virtual
machines in the recovery site from the journal. After the promotion of the data from the journal to
the mirror virtual machine completes, DRS is automatically re-enabled.
244
Zerto Virtual Replication and Fault Tolerance
Zerto Virtual Replication and Fault Tolerance

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).
Zerto Virtual Replication and Host Affinity Rules and

CPU Pinning
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).
Ensuring VPG Integrity When Using VMotion

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 Install Virtual Replication Appliances, on
page 22.
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 173.
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.
245
Zerto Virtual Replication and Storage VMotion
Zerto Virtual Replication and Storage VMotion

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 either a machine in a VPG being promoted, nor for a Virtual Replication Appliance
(VRA).
VMware Host Maintenance Mode

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
Support for VMware Host Maintenance Mode and VRA Maintenance, on page 156.
VMware Roles and Permissions

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 92.
246
Chapter 12: Troubleshooting

You handle problems related to the WAN connecting the protecting or recovery sites, or other
problems that Zerto support needs to resolve, as described below.
Ensuring Zerto Virtual Replication is Running, below.

Zerto Virtual Replication Alarms, on page 248.
Troubleshooting GUI Problems, on page 251.
Troubleshooting VRA Problems, on page 251.
Handling Lack of Storage Space for Recovered Virtual Machines, on page 252.
Understanding the Logs, on page 252.
Collecting Logs to Troubleshoot Problems: Running Zerto Virtual Replication Diagnostics,
on page 254.
Collecting Log Information for the ZertoVssAgent, on page 264.
Troubleshooting
247
Ensuring Zerto Virtual Replication is Running
Ensuring Zerto Virtual Replication is Running

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.
Zerto Virtual Replication Alarms

During the installation of Zerto Virtual Replication, the following 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.
Troubleshooting
248
Alarm
Description
com.zerto.event.CloudConnector
A problem with the Zerto Cloud Connector,

for example, it is powered off.
com.zerto.event.CriticalCheckpoint
Critical checkpoint: Only a few minutes of

checkpoints are left in the journal for the
VPG.
com.zerto.event.Datastore
The datastore is not accessible.
com.zerto.event.DisconnectedVCenter
vCenter Server disconnection.
com.zerto.event.DuplicateMacAddress
Mac Address conflict.
com.zerto.event.GhostCloudConnector
A Zerto Cloud Connector was deleted,

leaving a ghost cloud connector, as described
in Handling a Ghost Cloud Connector, on
page 162.
com.zerto.event.GhostVm
A Virtual Replication Appliance was

deleted, leaving a ghost VRA, as described
in Handling a Ghost VRA, on page 159.
com.zerto.event.GhostVolume
A shadow VRA was deleted, leaving a ghost

volume, as described in Maintaining
Shadow VRAs, on page 148.
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.PeerZvmCompatibility
The paired peer 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 peer Zerto Virtual
Manager is possible.
com.zerto.event.ProtectedVolumeSizeChanged
The volume size has changed.
com.zerto.event.ProtectionGroupError
The VPG has an error and must be deleted.
com.zerto.event.ProtectionGroupMissingConfiguration The VPG has a missing configuration.

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.
Troubleshooting
249
Alarm
Description
com.zerto.event.RpoError
The target RPO is not being met. The

current RPO is at least 25% more than the
target RPO.
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.UndoRollbackFailed
Rollback failed.
com.zerto.event.UninstalledHost
The host has no VRA installed.
com.zerto.event.VCDConnector
vCloud Director connection problem.
com.zerto.event.VCDReflection
vCloud Director problem.
com.zerto.event.VirtualMachine
Virtual machine state error.
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.VraProtectedVolume
A VRA protected volume error.
com.zerto.event.VRAregistrationFailed
A problem with an ESX upgrade.
com.zerto.event.VraTargetVolume
A VRA recovery volume error.
com.zerto.event.VraToVraConnection
A VRA is not connected to a peer site VRA.
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 peer site Zerto Virtual Manager.
Troubleshooting
250
Troubleshooting GUI Problems
Troubleshooting GUI Problems

Zerto Tabs Not Displayed
If the Zerto tabs are not displayed in the vSphere Client console, after installing Zerto Virtual
Replication, close and reopen the console.
Host is Not Displayed in List of Hosts in the Manage VPG Dialog

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.
Note: An alert is issued when the VRA is installed, displayed in the Alerts & Reports panel,
accessed from the Zerto tab for the vSphere Client console root node.
Troubleshooting VRA Problems

VPG Syncing Take a Long Time Network Problems
Check the network. If the firewall configuration is modified, the VRA TCP connections have to be
reset.
Troubleshooting
251
Handling Lack of Storage Space for Recovered Virtual Machines
Host is Not Displayed in List of Hosts in the Manage VPG Dialog

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.
VRA Crashes During Promotion

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.
Handling Lack of Storage Space for Recovered

Virtual Machines
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.
Understanding the Logs

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
increment ed by one each time logfile.csv reaches 10MB. the number of log files saved
depends on the amount of activity and the size of the site, but is approximately 24 hours of logs.
The log file has the following format:
FFFF, yyyy-mm-dd hh:mm:ss, ####, LVL, Component, API, Message
Troubleshooting
252
Understanding the Logs
where:
FFFF A HEX code. For internal use.
yyyy-mm-dd hh:mm:ss Timestamp for the message.
#### Number 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.
API The specific API that issued the message.
Message The message written in the log.
Troubleshooting
253
Collecting Logs to Troubleshoot Problems: Running Zerto Virtual Replication Diagnostics
The following is a sample from a log:

07f4c878,2010-12-01 19:54:41.4237,Debug,5,
Zerto.Zvm.RemoteZvmConnector.ResyncingRemoteZvmConnector,
TestConnectivity,TestConnectivity returning true,
07f4c878,2010-12-01 19:54:41.7362,Info,11,
Zerto.Zvm.ZvmServices.Protection.PromotionMonitor,
PromotionMonitoringThreadFunc,Promoting protection groups: ,
07f4c878,2010-12-01 19:54:42.7987,Info,9,
Zerto.Infra.ZvmReaderWriterLock,LogLock,Synchronizer: Enter Writer,
07f4c878,2010-12-01 19:54:42.7987,Info,9,
Zerto.Zvm.ZvmServices.ReconnectingConnectorProxy,
GetConnector,"Connecting IP=172.16.223.86, PORT=4005, attempt (1/3)",
07f4c878,2010-12-01 19:54:42.7987,Debug,9,
Zerto.Zvm.VraConnector.VraNetworkConnector,
Connect,try to connect 172.16.223.86:4005 ...,
07f4c878,2010-12-01 19:54:43.0643,Debug,17,
Zerto.Zvm.ZvmServices.CrossSiteService,Ping,Ping,
07f4c878,2010-12-01 19:54:43.0643,Debug,17,
Zerto.Zvm.ZvmServices.PingService,Ping,Ping called,
07f4c878,2010-12-01 19:54:43.8612,Error,9,
Zerto.Zvm.VraConnector.VraNetworkConnector,
ClearAndThrow,connection is closed: No connection could be made because the
target machine actively refused it 172.16.223.86:4005,
07f4c878,2010-12-01 19:54:43.8612,Warn,9,
Zerto.Zvm.ZvmServices.ReconnectingConnectorProxy,GetConnector,failed,
Collecting Logs to Troubleshoot Problems: Running

Zerto Virtual Replication Diagnostics
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. 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
Troubleshooting
254
Replication generated logs can be filtered by any alerts issued and by the VPGs that require
analysis to identify problems.
Check the connectivity between Zerto Virtual Replication components. See To check
connectivity between Zerto Virtual Manager components:, on page 261.
Collect local Zerto Virtual Manager logs. Use this option if the Zerto Virtual Manager is not
running. See To collect local Zerto Virtual Manager logs (when the Zerto Virtual Manager is
not running):, on page 263.
Reconfigure the Zerto Virtual Manager, when either the IP of the vCenter Server or of the
machine running the Zerto Virtual Manager changes. See Reconfiguring the Zerto Virtual
Manager IP Addresses, on page 163.
Note: A separate installation kit is available for download from Zerto support that installs the
Zerto Virtual Replication Diagnostics utility as a standalone utility on any Windows machine that
has Microsoft .NET Framework 4 installed1.
To collect logs for Zerto support to use when troubleshooting:

2. Select the Collect the Zerto Virtual Replication logs for use by Zerto support option.
3. Click Next.
The Initialize dialog is displayed.
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.
Troubleshooting
255
4. Specify the following and click Next.

IP / Host Name The IP of the Zerto Virtual Manager where the log collection runs from. Logs
are collected from this site and from the paired site.
Port The port used for inbound communication with the Zerto Virtual Manager.
Account 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. After this
information is added it is displayed in subsequent uses of the diagnostics utility.
Email An email address for use by Zerto support when analyzing the logs. An email address
must be entered. After this information is added it is displayed in subsequent uses of the
diagnostics utility.
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.
After clicking Next the utility connects to the Zerto Virtual Replication and if any alerts have
been issued, they are displayed in the Select Alerts dialog.
If there are no alerts, this dialog is skipped.
5. Select any alerts that need analyzing from the list and click Next.
Troubleshooting
256
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. Thus for example, when the peer site is a cloud provider, only logs from the local site are
collected.
7. Verify that the sites that need analyzing are selected and click Next.
Troubleshooting
257
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 vSphere Logs dialog is displayed.
Specify the vSphere data to collect.

Collect vCenter Server Diagnostics Collects vCenter Server diagnostics.
Collect Host Logs Collects logs generated for hosts. If you check the Collect host logs
checkbox, you can select the host logs to be included in the collection by using the plus and
minus buttons.
The vSphere data that can be collected enlarges the size of the log collection package
significantly and is not collected by default.
9. Click Next.
The Select vCloud Director Logs dialog is displayed.
Troubleshooting
258
By default all the VRAs are selected in the right list box to be included in the log collection.
You can change the collection criteria using the plus and minus buttons.
10. Click Next.
The Save Log Destinations dialog is displayed.
11. Specify 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. Click Next.
Troubleshooting
259
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.
13. 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:
14. Click Done to return to the Zerto Virtual Replication Diagnostics menu dialog.
15. 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.
Troubleshooting
260
To check connectivity between Zerto Virtual Manager components:

2. Select the IP Connectivity Tests option and click Next.
The IP Connectivity dialog is displayed.
You can use this dialog to check the following:

TCP communication between the Zerto Virtual Managers (ZVMs) on the protected and
recovery sites. The default port, specified during installation is 9081.
Communication between VRAs on the local site and paired site, via the control port and
the data port.
3. Select the connectivity you want to test and in the case of the Zerto Virtual Manager (ZVM),
specify the TCP communication port specified during the installation if the default port, 9081,
was changed.
4. Specify the type of test to perform:
Server Test for incoming communication.
Client Test for outgoing communication. Specify the IP address of the receiving Zerto Virtual
Manager.
5. Click Next to test the specified connectivity.

The Server option listens for communication from a paired VRA. Stop listening by clicking
Stop.
Troubleshooting
261
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.
Troubleshooting
262
To collect local Zerto Virtual Manager logs (when the Zerto Virtual Manager is not running):
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.
3. Specify the details that you want collected.

IP / Host Name The IP of the Zerto Virtual Manager where the log collection runs from. Logs
are collected from this site and from the paired site.
Port The port used for inbound communication with the Zerto Virtual Manager.
Account 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.
Troubleshooting
263
Collecting Log Information for the ZertoVssAgent

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.
Collecting Log Information for the ZertoVssAgent

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 138.
Logs generated by the ZertoVssAgent are saved separately and not collected using the Zerto
Virtual Replication diagnostics tool, described in Collecting Logs to Troubleshoot Problems:
Running Zerto Virtual Replication Diagnostics, on page 254. 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.
Troubleshooting
264
Index
A
advanced settings dialog
Default Script Execution Timeout ....... 102
Masking for new paired sites ......... 41, 103
Max Bandwidth .................................... 102
Override Physical Bandwidth Limit ... 102
RPO ....................................................... 103
Throughput ........................................... 102
WAN Traffic .......................................... 103
alarms .......................................................... 248
alerts ............................................................ 248
monitoring ............................................ 225
report ............................................. 207, 226
AMQP
Erlang OTP ............................... 30, 47, 112
installation ................................ 30, 47, 112
RabbitMQ .................................. 30, 47, 112
application consistency
VSS ........................................................ 138
architecture ................................................... 12
audit
report ..................................................... 227
B
bitmap
synchronization ...................................... 19
WAN resilience ....................................... 19
C
change rate
estimating ......................................... 67, 80
checkpoint ..................................................... 15
add ......................................................... 137
cloning ......................................................... 129
cloud connector ..............................................34

install .......................................................34
Command to run field
scripts ....................................................143
configuration
virtual protection group ..........................59
connecting sites
see pairing
crash consistency
VSS ........................................................138
create
virtual protection group ..........................59
D
Default Script Execution Timeout
advanced settings ..................................102
disaster recovery ..........................................195
during a test ..........................................211
initiating ........................................197, 208
disk size
estimating ..........................................67, 80
disk space .....................................................252
promotion hangs ....................................252
E
edit Virtual Replication Appliances ............152
environment variable ..................................142
ZertoForce ..............................................142
ZertoOperation ......................................142
ZertoVCenterIP .....................................142
ZertoVCenterPort ..................................142
ZertoVPGName .....................................142
export to CSV
virtual protection group ........................217
265
F
failback
failover .................................................. 200
move ...................................................... 189
failover ......................................................... 195
during a test ......................................... 211
failback .................................................. 200
initiating ....................................... 197, 208
process ................................................... 195
reverse replication ................................ 200
stop testing ........................................... 179
testing ................................................... 173
failover tests
report ..................................................... 228
G
Ghost Cloud Connector ............................... 162
Ghost VRA ................................................... 159
H
Host not displayed in Manage VPG dialog 251
host not displayed in Manage VPG dialog 252
I
information for a site .................................. 100
J
journal
add checkpoint ...................................... 137
L
license .................................................... 21, 240
logs ............................................................... 252
collecting logs ........................................ 254
when adding VSS checkpoint .............. 264
M
Masking for new paired sites
advanced settings ........................... 41, 103
Max Bandwidth
advanced settings ................................. 102
migration
see move
266
Zerto Virtual Replication Documentation
monitor .........................................................212
alerts ......................................................225
site details .............................................213
site topology ...........................................222
virtual machines ...................................219
virtual protection groups ......................215
move
failback ..................................................189
initiating ................................................189
reverse replication .................................189
what is ...................................................187
N
new virtual protection group .........................59
O
Override Physical Bandwidth Limit
advanced settings ..................................102
P
pairing ............................................................28
Params field
scripts ....................................................143
Permissions ............................................92, 246
point-in-time
add checkpoint .......................................137
preseed
recovery volume ..................68, 80, 88, 122
process
failover ...................................................195
move
test failover ............................................173
promotion hangs ..........................................252
protect
see virtual protection group
protected site
pairing ......................................................28
protection over time by organization
report .....................................................230
provisioned
storage .....................................72, 216, 220
R
RabbitMQ
Erlang OTP ............................... 30, 47, 112
installation ................................ 30, 47, 112
raw device mapping (RDM)
recovery volume ........................ 68, 80, 122
raw disk
recovery volume ........................ 68, 80, 122
RDM (raw device mapping)
recovery volume ........................ 68, 80, 122
recovery ....................................................... 195
during a test ......................................... 211
initiating ....................................... 197, 208
recovery site
pairing ..................................................... 28
recovery volume
preseed ................................ 68, 80, 88, 122
raw device mapping (RDM) ..... 68, 80, 122
swap .................................... 68, 80, 88, 122
registration ............................................ 21, 240
remove Virtual Replication Appliances ..... 155
report
alerts ............................................. 207, 226
audit ...................................................... 227
failover tests ......................................... 228
protection over time by organization ... 230
tests ....................................................... 228
top sites by SLA level ........................... 231
top sites by VMs and data .................... 233
top sites falling behind their SLA level 235
usage ..................................................... 237
VPG performance ................................. 238
reverse replication
failover .................................................. 200
move ...................................................... 189
RPO
S
scripts
Command to run field ...........................143
Params field ..........................................143
Timeout field .........................................143
ZertoForce environment variable .........142
ZertoOperation environment variable .142
ZertoVCenterIP environment variable 142
ZertoVCenterPort environment variable ...
142
ZertoVPGName environment variable 142
shadow VRA
Virtual Replication Appliance ..............148
signature matching
WAN optimization ...................................18
site details
monitoring .............................................213
site information ...........................................100
site topology .................................................222
sizing
volumes ..............................................67, 80
WAN .........................................................94
sort Virtual Replication Appliance list .......154
status
VPG ................................................133, 134
stop
testing ....................................................179
storage
provisioned ..............................72, 216, 220
swap ................................................................88
swap disk
recovery volume ..................68, 80, 88, 122
synchronization
bitmap ......................................................19
synchronization reasons
VPG ........................................................135
267
T
test
failover .................................................. 173
initiating failover .................................. 211
stopping ................................................. 179
virtual protection group ....................... 173
test failover ................................................. 173
process ................................................... 173
tests
report ..................................................... 228
thin provisioning ......................................... 243
Throughput
Timeout field
scripts .................................................... 143
top sites by SLA level
report ..................................................... 231
top sites by VMs and data
report ..................................................... 233
top sites falling behind their SLA level
report ..................................................... 235
troubleshooting
disk space .............................................. 252
Host not displayed in Manage VPG dialog
251
host not displayed in Manage VPG dialog
252
Virtual Replication Appliance crashes during promotion ........................... 252
Zerto Virtual Manager service ............. 248
U
uninstall Virtual Replication Appliances .. 155
upgrade
Virtual Replication Appliance ............. 149
upgrading .................................................... 149
usage
report ..................................................... 237
268
Zerto Virtual Replication Documentation
V
vApp .......................................................74, 242
vCD
set up access ..............................31, 47, 112
vCD multiple cells ...........................31, 47, 112
virtual machine
modify volume .......................................136
monitoring .............................................219
protect ......................................................73
virtual protection group
add machine ..................................117, 118
via virtual machine node ..................73
via VPG definition ..........................119
cloning ....................................................129
creating ....................................................59
delete ......................................................132
for a single virtual machine ....................73
modify ....................................................124
monitoring .....................................215, 218
saving details to file ..............................217
Synchronization reasons .......................133
synchronize ............................................127
testing ....................................................173
Virtual Replication Appliance .................22, 53
crash during promotion ........................252
edit .........................................................152
install .................................................22, 53
shadow VRA ..........................................148
sort .........................................................154
uninstall .................................................155
upgrade ..................................................149
VMotion ........................................................245
VMware Host Maintenance ........................156
volume
estimating size ..................................67, 80
preseed .................................68, 80, 88, 122
raw device mapping (RDM) ......68, 80, 122
swap ...........................................68, 80, 122
Volume Shadow Copy Service ............ 136, 138

logs ........................................................ 264
VPG
see virtual protection group
Synchronization reasons ...................... 135
VPG performance
report ..................................................... 238
VPG statuses ....................................... 133, 134
VRA .............................................................. 149
VSS ...................................................... 136, 138
application consistency ........................ 138
crash consistency .................................. 138
logs ........................................................ 264
vStorage
thin provisioning .................................. 243
W
WAN
bitmap sync ............................................. 19
signature matching ................................ 18
sizing ....................................................... 94
WAN Traffic
Windows service
Zerto Virtual Manager ......................... 248
Z
Zerto Virtual Manager
Windows service ....................................248
Zerto Virtual Replication
architecture .............................................12
benefits ....................................................16
how it works ............................................14
logs .........................................................252
monitoring .............................................212
what is .....................................................11
ZertoForce
script ......................................................142
ZertoOperation
script ......................................................142
ZertoVCenterIP
script ......................................................142
ZertoVCenterPort
script ......................................................142
ZertoVPGName
script ......................................................142
269

Zerto Virtual Replication Administration Guide

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Zerto Virtual Replication Administration Guide

Загружено:

Авторское право:

Доступные форматы

Zerto Virtual Replication

Copyright 2012, Zerto Ltd. All rights reserved.

Chapter 1: Introduction to Zerto Virtual Replication . . . . . . . . . . . . . . . . . . . . . 11

Chapter 2: Initial Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Chapter 3: Protecting Virtual Machines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Chapter 4: Advanced Zerto Virtual Replication Configuration . . . . . . . . . . . . . 92

Chapter 5: Managing Zerto Virtual Replication. . . . . . . . . . . . . . . . . . . . . . . . . 117

Chapter 6: Recovery Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Chapter 7: Testing Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Chapter 8: Migrating a Protection Group to the Recovery Site . . . . . . . . . . . . 187

Chapter 9: Managing Failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Chapter 10: Zerto Virtual Replication Reports . . . . . . . . . . . . . . . . . . . . . . . . . 212

Chapter 12: Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

About This Guide

Overview of Content in This Guide

Describes the underlying concepts and architecture of Zerto

Describes how to set up the environment for recovery using

Describes how to set up protection for virtual machines.

Zerto Virtual Replication Documentation Set

Describes the processes available to manage protection and

Describes the processes available to manage protection and

Describes the available recovery procedures and when they are

Describes how to test recovery to ensure the results you want.

Migrating a Protection Describes the process of migrating protected virtual machines

Describes the process of recovery from the protected site to the

Describes the interaction between Zerto Virtual Replication

How Zerto Virtual

Describes the interaction between Zerto Virtual Replication

Describes how to resolve problems.

Zerto Virtual Replication Documentation Set

Details specific to this release of Zerto Virtual Replication.

About This Guide

Support and Feedback

a single sheet with brief descriptions of how to perform the main

This guide: How to implement and manage replication and a disaster

Additionally, an API online help is available.

Support and Feedback

About This Guide

Chapter 1: Introduction to Zerto Virtual

What is Zerto Virtual Replication?, below.

What is Zerto Virtual Replication?

Zerto Virtual Replication Architecture

determined by site considerations, such as increased complexity of having multiple points of

Zerto Virtual Replication Architecture

vCenter Servers on the protection and recovery sites.

Introduction to Zerto Virtual Replication

Zerto Virtual Replication Architecture

Introduction to Zerto Virtual Replication

Zerto Virtual Replication Architecture

Introduction to Zerto Virtual Replication

Zerto Virtual Replication Architecture

Introduction to Zerto Virtual Replication

Benefits of Using Zerto Virtual Replication

Benefits of Using Zerto Virtual Replication

Fully Virtual Sits in the Hypervisor

Introduction to Zerto Virtual Replication

Benefits of Using Zerto Virtual Replication

Focus is on the Application, Not the Physical Storage

Efficient Asynchronous Replication

One-Click Failover and Control of the Recovery Process

Introduction to Zerto Virtual Replication

Benefits of Using Zerto Virtual Replication

WAN Optimization Between Protected and Recovery Sites

Introduction to Zerto Virtual Replication