RECOVERPOINT FOR VIRTUAL MACHINES

VERSION 5.0 SP1

FULLY VIRTUALIZED MULTI-COPY CONTINUOUS
DATA PROTECTION USING VMWARE
HYPERVISOR-BASED REPLICATION

ABSTRACT
This white paper explains how RecoverPoint is integrated with VMware to provide
comprehensive per-VM data protection. It provides a technical overview detailing
architecture, topologies and use cases relating to the 5.0 SP1 release.

April, 2017

WHITE PAPER
Table of Contents
EXECUTIVE SUMMARY ...........................................................................................................4
Audience ........................................................................................................................................... 4

TERMINOLOGY .........................................................................................................................5
OVERVIEW ................................................................................................................................9
Fully Virtualized Solution ................................................................................................................. 10
Storage Agnosticism (SAN, DAS, NAS, iSCSI, FCoE, vSAN, SIO)................................................. 12
vSphere Hypervisor Based ESXi Splitter ......................................................................................... 12
Integrated Management within the VMware vSphere Web Client ................................................... 15

REPLICATION TOPOLOGIES ............................................................................................... 18

Workflow ......................................................................................................................................... 20
Topologies ....................................................................................................................................... 21
Protection ........................................................................................................................................ 25

RECOVERY OPERATIONS ................................................................................................... 43

Failover ........................................................................................................................................... 44
Recover Production ......................................................................................................................... 62

ORCHESTRATION ................................................................................................................. 71
KVSS ....................................................................................................................................... 85
SUPPORTED VMWARE FEATURES .................................................................................... 86
vMOTION/STORAGE vMOTION ............................................................................................ 87
LICENSING ............................................................................................................................. 88
REST API ................................................................................................................................ 89
VXRAIL ................................................................................................................................... 90
CONCLUSION ........................................................................................................................ 91
REFERENCES ........................................................................................................................ 92

2
The information in this publication is provided as is. EMC Corporation makes no representations or warranties of any kind with respect
to the information in this publication, and specifically disclaims implied warranties of merchantability or fitness for a particular purpose.
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

EMC2, EMC, the EMC logo, RecoverPoint and RecoverPoint for Virtual Machines are registered trademarks or trademarks of EMC
Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners.
Copyright 2017 EMC Corporation. All rights reserved. Published in the USA, April 2017, Part Number H16053.

EMC believes the information in this document is accurate as of its publication date. The information is subject to change without
notice.

EMC is now part of the Dell group of companies.

3
EXECUTIVE SUMMARY

The virtualization of the data center has proven to be a major factor in the transition of technology
providing a smaller footprint with increased flexibility and control in managing mission-critical data
assets. Many companies and organizations continue to adopt virtualization initiatives increasing
their virtual to physical estate ratios.

In conjunction with the continuing virtualization of data assets, customers require a Business
Continuity/Disaster Recovery (BC/DR) capability that is synonymous with their underlying
virtualization technology. RecoverPoint for Virtual Machines for VMware (referred to RecoverPoint
for VMs here on in) is synonymous with this requirement and provides customers with this
capability by enabling local AND/OR remote replication of virtual machines (VMs) on a per-VM
basis (containing VMDK and/or RDM files), allowing recovery to any Point in Time (PiT) snapshot
with orchestration features during Recover to Production or Failover.

RecoverPoint for VMs is a software-only data protection solution for protecting VMware VMs
enabling replication from any storage type to any storage type, leveraging Virtual RecoverPoint
Appliances (vRPAs) integrated in the VMware ESXi hosts as part of a VMware High Availability
cluster. This is achieved via a RecoverPoint write-splitter embedded in the ESXi hypervisor.

RecoverPoint for VMs simplifies operational recovery and disaster recovery with built-in
orchestration and automation capabilities accessible via VMware vCenter. vAdministrators can
manage the protection lifecycle of VMs via the RecoverPoint for VMs plug-in through the VMware
vSphere Web Client.

Audience
This white paper is intended for EMC customers, partners and employees who want to
understand and evaluate RecoverPoint for VMs. Familiarity with RecoverPoint and
VMware is required.

4
TERMINOLOGY

vRPA (Virtual RecoverPoint Appliance ) - A virtual data appliance that manages all aspects of data
replication.

vRPA cluster - A vRPA cluster is a group of 2-8 vRPAs that work together to replicate and
protect data.

Virtual RecoverPoint System - One or more connected vRPA clusters.

RP4VMs Plugin - RecoverPoint for VMs Web Client plugin.

ESXi Host - A VMware hypervisor software that virtualizes the hardware and allows running of VMs.
The term ESXi is also loosely used in reference to the physical server on which the ESXi software
runs (i.e. the ESXi host).

ESXi Cluster - A set of ESXi hosts that create a cluster in order to load balance, share resources and
provide continuous availability to VMs.

vCenter Server - A server that manages the virtual environment. Note that this is not a GUI.

VM (Virtual Machine) - A virtual machine (VM) is a software implementation of a computer

operating system that executes programs like a physical machine. More specifically it is a set of
files that describe the resources and configuration of hardware needed to create virtualized
hardware. In VMware the description of a VM is in a VMX file coupled with some VMDK files and a
swap file.

VMware Datastore - Storage LUNs are exposed to the ESXi cluster. A datastore is the storage area
with a VMFS built on top of the LUNs (though NFS is also supported). The datastore is where the
.vmx and .vmdk files are stored (or as the user sees it where VMs are stored).

VMDK (Virtual Machine Disk) - A container file format to hold vdisks. It may point to a file or to an
actual device (physical or virtual) that hold the data.

VMFS (Virtual Machine File System) - A distributed cluster file system. It allows for the ESXi host in
the cluster to concurrently access the same file system.

RDM (Raw Device Mapping) - A mapping file in a separate VMFS volume that acts as a proxy for a
raw physical storage device. The RDM allows a virtual machine to directly access and use the
storage device. The RDM contains metadata for managing and redirecting disk access to the
physical device.

VIB (vSphere Installation Bundle) - A package for installing programs for ESXi hosts. It consists of a
zipped content file and an xml manifest. In the context of this document it is used to deploy either
the vSCSI or IOF splitter on ESXi hosts.

Splitter - A mechanism used to intercept writes so that they are sent to their designated storage
volumes and the RPA simultaneously.
5
vSCSI - A layer in the ESX kernel that abstracts a SCSI interface to the VMs.

vSCSI Filter - A SCSI filter that facilitates the interception of I/Os at the vSCSI layer.

IOF An I/O filter driver that can intercept I/Os in conjunction with VMwares vSphere APIs for IO
Filtering

Shadow VM - A secondary replica VM, created, configured and managed by RP to allow access to
replica VMDK and/or RDM devices. A replica shadow VM is identified by the rp. prefix at the front of
the virtual machine name and the .copy.shadow extension at the end of the virtual machine name.
User action on replica shadow VMs is not supported.

Deployer The RecoverPoint for VMs Deployer is a new tool for installing vRPA clusters, connecting
vRPA clusters, modifying vRPA cluster network settings, and for upgrades to future versions of
RecoverPoint for VMs.

vMotion - An operation to move a VM from one ESX to another while the VM is running.

Storage vMotion - Moving the location of a VMDK within a datastore or between datastores while
the VM is running.

DRS (Distributed Resource Scheduler) - An automatic resource and load balancer that uses vMotion
to balance load over an ESXi HA cluster.

Storage DRS - An automatic load balancer that uses Storage vMotion to balance load and
utilization of datastores.

vApp - A collection of pre-configured VMs that combine applications with the operating systems
that they require.

vCSA (vCenter Server Appliance) - Linux-based virtual appliance VM used vCenter Server
management as opposed to the traditional Windows server convention.

vSwitch - A Layer 2 network switch that exists in every ESXi host.

Consistency Group - A logical entity used to configure protection policies across one or VMs.

Replication set - A set of vdisks consisting of a production VMDK or RDM vdisk and any local and/or
remote VMDK or RDM device to which it is replicating, per consistency group. The number of
replication sets in your system is equal to the number of production VMDK or RDM vdisks being
replicated.

Group set - A group set is a collection of consistency groups to which the system applies parallel
bookmarks at a user-defined frequency. Group sets are useful for consistency groups that are
dependent on one another or that must work together as a single unit.

Copy - In RecoverPoint for VMs, a replica copy is an image of a VM and its application data
accessible at a vRPA cluster.
6
Journals - Each copy of a consistency group must be assigned a journal provisioned as VMDK
contain a resource pool consisting of one or more datastores that is dedicated to holding marking
information or point-in-time history.

Snapshot - A snapshot is the difference between one consistent image of stored data and the next.
Snapshots are stored in the replica copy journal.

Snapshot consolidation - A process that consolidates the data of multiple snapshots into a single
snapshot to allow for a longer history to be retained in the journal. Automatic snapshot
consolidation settings can be specified in the replica copy protection policy.

Bookmark - A bookmark is a manual snapshot with a label you apply to it to identify it. Parallel
bookmarks are bookmarks with the same name applied at the same time to multiple consistency
groups in a group set.

Link - A link is the communication connection between RecoverPoint copies. When the link is open,
data can be transferred between copies.

Full Sweep - An efficient Initialization process, which is performed on all of the volumes in a
consistency group, when the virtual RecoverPoint System cannot identify which blocks are identical
between the production and replica volumes, and must therefore mark all blocks for all volumes in
the consistency group, as dirty.

Short init - An initialization process that uses marking information to re-synchronize a replica
copys volumes from the production sources.

Long resync - The process in which the target vRPA writes the initialization data directly to the
replica copy volume (bypassing the journal).

Volume Sweep - An initialization process, which is performed on a specific volume in a

consistency group.

Test Copy - Enabling access to point-in-time image at one of the replica copies, also referred to as
Image Access.

Failover - The process of changing the replication direction between the production VM(s) in a
consistency group and the replica copy VM(s) using a selected PiT snapshot.

Recover Production - Recovering production restores the production VM(s) in a consistency group
from the replica copy VM(s) using a selected PiT snapshot.

Recovery Point Objective (RPO) - RPO is the maximum amount of data that an organization is
willing to lose in case of a disaster. For example, an RPO of 30 seconds means that in case of a
disaster, the data that can be lost should not be more than the data generated in 30 seconds.

Recovery Time Objective (RTO) - RTO is the duration of time within which a business process must
be restored after a disaster. For example: An RTO of one hour means that in case of a disaster, the
data needs to be restored in one hour.

7
Asynchronous Replication - A replication mode that enables you to replicate data over long
distances while maintaining a dependent write consistent copy of data between the source copy
and replica copies at all times.

Synchronous Replication - A replication mode in which the VM host initiates a write to the
production array and the data must be successfully stored by the local RPA and/or the remote RPA
before an acknowledgement is sent back to the VM host.

8
OVERVIEW

RecoverPoint has always had the capability to replicate VMware application data either as part of a
VMware File System (VMFS) or as a Raw Device Mapping (RDM) in physical mode (RDM/P). This
traditional approach to replication has been undertaken using splitter technologies such as the
array-based splitters. However, the fundamental difference between classic RecoverPoint and
RecoverPoint for VMs is that the traditional approach replicates entire LUNs. In the case of VMware
this equates to whole datastores and their constituent VMs. Thus, per-VM replication was not a
possibility with classic RecoverPoint and as a consequence may impact the flexibility and
granularity requirement that is needed in virtual environments of today.

RecoverPoint for VMs addresses this requirement by replicating VMs (with VMDK and/or RDM
vdisks) on any type of storage supported by VMware over any distance, be it synchronous or
asynchronous. This unique approach to replication in the VMware environment is supported as per
the software versions specified in the latest RecoverPoint for Virtual Machines 5.0 Simple Support
Matrix and provides the following core capabilities:

Fully Virtualized Solution

Storage Agnosticism (SAN, DAS, NAS, iSCSI, FCoE, vSAN, SIO)
vSphere Hypervisor Based ESXi Splitter (vSCSI or IOF))
Web-based deployment
Integrated Management within the VMware vSphere Web Client
Recovery Operations with any PiT
Orchestration of recovery operations
REST API

Moreover, RecoverPoint for VMs has inherited many aspects of classic RecoverPoint such as WAN-
based data reduction via write-folding, deduplication and compression, policy driven protection,
PiT image access for testing and failover/recovery capability.

RecoverPoint for VMs 5.0 SP1 compliments the previous RecoverPoint for VMs 4.3 and 5.0 releases
by providing the following new and enhanced features. Refer to the New features section of the
RecoverPoint for VMs 5.0 Release Notes for additional information:

Deployer enhancements including more intuitive interface, improved validations, clearer

error messaging and default
Copy VM network configuration (re-IPing) is now a semi-automatic process that no longer
requires glue scripts
The MAC address of the VM is replicated to the remote VM by default (but configurable)
ESX UUID duplication support RecoverPoint for VMs replaces the use of VMware's ESX host
UUID and creates its own unique identifier, which ensures that no duplicate or degenerated
UUIDs exist in the system
Support for vSphere 6.5

9
FULLY VIRTUALIZED SOLUTION

Deployment

A vRPA cluster is dependent on the following virtualized components detailed in Figure 1 (the
exception to this is the option to deploy a virtual RecoverPoint System with a single vRPA) and has
the mandatory requirement of being managed by a vCenter server. Both Windows vCenter server
and Linux vCenter Server Appliance (vCSA) deployments are supported.

Note: vCenter Linked Mode has been qualified and tested with ESXi 5.5 and 6.0 with a maximum of
four vCenter servers. Note that all vCenter servers must be registered via the RP4VMs plugin.

As part of the RecoverPoint for VMs deployment the Web-based Deployer has a pre-requisite
requirement of the deployment of the vRPA(s) using the downloadable ova file and the creation of
iSCSI Software Adapters with a recommended two vmkernel ports on a per ESXi host basis. Once
deployment has been completed using Deployer, the only remaining activity is the registration of
the ESXi cluster(s) to ensure that any VMs residing in the cluster(s) can be protected. Registration
is performed via the RecoverPoint for VMs plugin.

Note: There is no need to register the ESXi cluster where the vRPAs reside unless there are VMs
residing on the ESXi cluster that require protection.

The splitter component is automatically installed on the ESXi cluster hosts where the vRPA(s)
reside as part of the deployment flow. When VMs on additional ESXi clusters are required to be
protected the vSCSI splitter component is automatically installed on the ESXi cluster hosts via a
push from the Site Control vRPA as part of the registration process or by the vCenter server for the
IOF splitter as part of the registration process. Any ESXi host that is added to an ESXi cluster that
has already been registered in the virtual RecoverPoint System will have the splitter component
automatically installed.

Note: The use of Auto-Deploy as part of a stateless or stateful ESXI host deployment is not
supported.

All datastores affected by replication, including the datastores for the repository and journal
requirement, are exposed to all the ESXi hosts in the ESXi cluster.

Refer to the latest RecoverPoint for VMs 5.0 Release Notes and RecoverPoint for VMs 5.0
Installation and Deployment Guide prior to deployment.

10
Figure 1

11
Storage Agnosticism (SAN, DAS, NAS, iSCSI, FCoE, vSAN, SIO)

By embedding the splitter technology in the ESXi hypervisor, RecoverPoint for VMs replicates VMs
(with VMDK and/or RDM vdisks) on any type of storage supported by VMware referenced in the
VMware Hardware Compatibility List,
http://www.vmware.com/resources/compatibility/search.php?deviceCategory=san

Note: Full VSAN support including data, journal and repository volumes is supported from version
4.2 P1.

Note: RecoverPoint does not support VMs with shared VMDK or RDM vdisks.

Note: VMDK -> VMDK, VMDK -> RDM, RDM -> RDM and RDM -> VMDK replication requires that the
vdisks, source and target, are exactly the same size and that the SCSI IDs are identical. During the
VM protection flow and selecting an existing VM replica, the vdisks must be the same size. When
choosing the automatic option as part of the protection flow, VMDK vdisks are created the exact
same size as the source disks. VMs containing RDM vdisks have a mandatory requirement to be
pre-created and selected as part of the protection process.

vSphere Hypervisor Based ESXi Splitter

The RecoverPoint for VMs splitter is proprietary software that currently exists in two forms, vSCSI or
IO Filter (IOF). IOF is a feature introduced by VMware in vSphere 6.0, which allows 3rd parties to
write filter drivers that integrate into the VMware I/O stack to facilitate the interception of I/Os. IOF
is officially named VAIO (vSphere APIs for IO Filtering) by VMware, however this document will refer
to it as IOF.

The IOF splitter is only supported with the RecoverPont for VMs 4.3 SP1 P3 and P4 releases but not
with the 5.0 releases. Furthermore, all ESXi hosts and vCenter servers must be running (at least)
vSphere 6.0 U2 and hardware version 11. RDM vdisks are NOT supported with the IOF splitter. This
is due to VMwares implementation of I/O Filters. I/Os destined for RDM vdisks will not be
intercepted by the same I/O stack on the ESXi hosts and therefore cannot be intercepted by an IOF
splitter.

The following table provides a summary of the two splitter types.

Table 1

12
RecoverPoint for VMs does not support ESXi hosts with a non-persistent scratch location
(stateless). The ScratchConfig location on an ESXi host must be permanently available, i.e. be a
persistent datastore. This is because the splitter backlog is stored in the scratch location which is
used for managing the metadata associated with the writes, plus it is also used for general logging.
It is important to note that the VMware default is non-persistent and any change to this advanced
parameter setting requires a reboot after reconfiguration.

Each splitter is exposed to all the volumes in the cluster even though only one or two splitters will
be accessing the same volume at a specific time. All the splitters in the cluster behave as an
aggregate splitter, therefore the ESXi cluster will be treated as a single entity.

Once a VM is protected by RecoverPoint for VMs, write I/Os from the VM go through the ESXi vSCSI
layer and will be intercepted by the vSCSI splitter unless the IOF splitter has been deployed,
whereupon each replicated VM running on the ESXi host has its own IOF splitter component
running within the VMX context and therefore the write I/Os are intercepted by the protected VM in
conjunction with the owner ESXi host which runs an IOF daemon (IOFD) process.

The write I/O will be sent to the owner vRPA and then down the stack if the I/O to the vRPA
succeeds. When the write I/O cannot be sent to the vRPA, the splitter will invoke marking mode
whereby the write I/Os are tracked whilst they continue to their VMDK or RDM destination.

Each vRPA exposes LUN 0 (937.94 GB disk) via each iSCSI IP portal to each of the ESXi hosts in the
cluster. These are vdisks that are used to facilitate I/Os between the ESXi host and the vRPAs.

The following steps in

Figure 2 depict the handling of a write I/O after protecting a VM using a VMDK device with
RecoverPoint for VMs in conjunction with the vSCSI splitter. This process is identical for a VM using
RDM vdisks.

Figure 2

13
The following steps in Figure 4 depict the handling of a write I/O after protecting a VM using a
VMDK device with RecoverPoint for VMs in conjunction with the IOF splitter.

Figure 3

14
Integrated Management within the VMware vSphere Web Client

The RecoverPoint for VMs plugin exists within the vSphere Web Client and is installed
automatically as part of the Deployer installation process.

It enables discovery, provisioning, automation and orchestration of disaster recovery workflows

such as PiT testing, failing over, failing back, and recovering production of a single consistency
group or of a group of consistency groups.

Access to the RecoverPoint for VMs plugin is performed via the vSphere Web Client and is initiated
using the following, where <vCenter-IP-address> is the IP address of the vCenter and <port> is the
port selected in the installation of the Web Client plugin. The default port is 9443.

https://<vCenter-IP-address>:<port>/vsphere-client/

Figure 4

Once successfully logged into the Web Client, the RecoverPoint for VMs plugin is visible and
accessible as a RecoverPoint for VMs option to initiate protection of a VM via the Manage tab of
the VM shown below in Figure 5. Protection of a VM can also be initiated by right clicking on the VM
and navigating to the All RecoverPoint for Virtual Machines Actions option or by right clicking on
the Summary tab of the VM and navigating to RecoverPoint for VMs.

The RecoverPoint for VMs plugin in the vCenter Home page is the management option for
RecoverPoint for VMs shown below in Figure 6.

15
 Figure 5

Figure 6

Note: The RecoverPoint for VMs plugin is the only supported method for management. Actions or
activities performed via the RecoverPoint UI are not supported and as of version 4.3 P1 has been
purposely blocked. A limited CLI set, plus RESTAPI capability, provides an alternative method for
managing RecoverPoint for VMs.

Installation of the RecoverPoint vSphere Web Client plugin on the vCenter server can also be
performed manually as and when required but should be automatically installed as part of the
vRPA cluster deployment flow.

The plugin can be downloaded from Dell EMC Online Support->Support by Product->RecoverPoint
for Virtual Machines->Downloads or alternatively it can be retrieved from the vRPA by pointing to:
16
https://<vRPA IP Address>/RPVWCPlugin.zip

Follow the plugin installation steps below to complete the installation.

Note: The Linux vCSA based vCenter deployment must be installed using the CLI procedure.

Plugin installation using GUI:

1. In the RecoverPoint for VMs Installation Kit, locate the file RPVWCPlugin.zip
file.
2. On Windows-based servers, unzip the file RPVWCPlugin.zip in a directory especially
created for the plugin, for example:

C:\ProgramData\VMware\vSphere Web Client\vc-packages\vsphere-client-

serenity\com.emc.recoverpoint.vwc-1.0.1

3. Click Next. Click Finish.

4. Restart the Web Client service.
5. Access the Web Client.

Plugin installation using CLI:

1. Create the directory:

localhost:/ # mkdir

/etc/vmware/vsphere-client/vc-packages/vsphere-client-
serenity/com.emc.recoverpoint.vwc-1.0.1

OR

/var/lib/vmware/vsphere-client/vc-packages/vsphere-client-
serenity/com.emc.recoverpoint.vwc-1.0.1

2. Unzip the plugin into the sub-directory:

localhost:/ # unzip RPVWCPlugin.zip d

3. Restart the Web Client service:

localhost:/ # service vsphere-client restart

4. Access the Web Client.

17
REPLICATION TOPOLOGIES

There can be up to five vRPA clusters in a virtual RecoverPoint System (RecoverPoint for VMs
system); one vRPA cluster is used for local replication and up to four vRPA clusters may be used for
remote replication targets. Local and remote replication can be achieved using two vRPA clusters.

Note: A vRPA cluster must be in a single ESXi cluster and cannot span multiple ESXi clusters.

There is a minimum of two vRPAs required in a vRPA cluster although the 5.0 version release allows
the deployment of a virtual RecoverPoint System with a single vRPA. To scale-up from a single vRPA
deployment or a two vRPA cluster to support a higher throughput rate, you can have up to eight
vRPAs in a vRPA cluster. All vRPA clusters in a virtual RecoverPoint System must have the same
number of vRPAs.

The vRPAs in the vRPA cluster can reside on the same ESXi host as a protected VM or a different
ESXi host in the ESXi cluster, or in a completely different ESXi cluster (see Topologies below). The
best practice recommendation would be to separate the ESXi host locality of the vRPA VMs from
the protected VMs.

Replication is at a VM level so only the VMDK and/or RDM vdisks are replicated. When a VM is
selected for protection (replication), a replica VM with the same configuration can be created
automatically, or alternatively it can be manually selected as a pre-created VM with all of the
constituent VMDK or RDM vdisks. It is then subsequently added to a consistency group.

Note: VMDK -> VMDK, VMDK -> RDM, RDM -> RDM and RDM -> VMDK replication requires that the
vdisks, source and target, are exactly the same size and that the SCSI IDs are identical. During the
VM protection flow and selecting an existing VM replica, the vdisks must be the same size. When
choosing the automatic option as part of the protection flow, VMDK vdisks are created of the exact
same size as the source disks. VMs containing RDM vdisks have a mandatory requirement to be
pre-created and selected as part of the protection process.

Note that the repository and journals must also be vdisks. A 6GB VMDK device is created as the
repository and is created per vRPA cluster as part of the vRPA cluster installation process and
resides in an RPvStorage sub-directory on the chosen datastore. Journals devices also reside in an
RPvStorage sub-directory on the datastores chosen as part of the journal pool(s).

The following logical entities constitute the replication environment:

Consistency Group: A consistency group is a container for VMs and all their copies whose
application data needs to be replicated to a consistent point in time. For instance, if you replicate a
database and its transaction log, you need both files, and you always need both files to be at the
exact same point in time. You can achieve this by placing the VM running the database and the
virtual machine running the transaction log in one consistency group or in one group set. The
consistency group comprises VMs, their copies, and their journals.

Copies: In RecoverPoint for VMs, a copy is a replica image of a VM and its application data
accessible at a vRPA cluster. The application data is immediately usable. The following types of
copies exist:

18
Production copy: The production copy consists of all of the VMs with their application data that are
the source for replication (that is, protected by RecoverPoint).

Local copy: A local copy is a replica copy of production VMs with their application data that is
accessible on the vRPA cluster running production. The local replica copy is used for continuous
data protection, such as recovering from logical errors and data corruption. A virtual machine that
is replicated to a local replica copy is identified by the .copy.recoverpoint extension at the end of
the virtual machine name.

Remote copy: A remote copy is a replica copy of production VMs with their application data that is
accessible on a remote vRPA cluster. Remote denotes clusters that are connected only by WAN. The
remote replica copy is commonly used for disaster recovery but can be used for recovery also. A VM
that is replicated to a remote replica copy is identified by the .copy.recoverpoint extension at the
end of the VM name.

Note: When multiple copies of the same VM are created the second replica copy will be demoted
by a .copy.1.recoverpoint extension and the third copy will be denoted by a .copy.2.recoverpoint
extension etc.

Shadow VM: A shadow VM represents the replica VM in a shutdown state and is identified by the
rp. at the front of the VM name and the .copy.shadow extension at the end of the VM name. User
action on replica shadow VMs is not supported.

Journals: Each copy of a consistency group must contain a resource pool consisting of one or more
datastores that is dedicated to holding marking information or point-in-time history.

Production journal: Production journals store information about the replication process that makes
synchronization between the production and copies more efficient. After failing over, the
production journal becomes a copy journal.

Copy journal: The copy journal receives successive writes written to production. Since the write-
order is maintained, it is possible to apply or undo writes so that the copy image can reflect any
point in time.

Snapshot: A snapshot is the difference between one consistent image of stored data and the next.
Snapshots are stored in the copy journal.

Snapshot consolidation: A process that consolidates the data of multiple snapshots into a single
snapshot to allow a longer history to be retained in the journal. Automatic snapshot consolidation
settings can be specified in the copy protection policy.

Bookmark: A bookmark is a manual snapshot with a label you apply to it to identify it. Parallel
bookmarks are bookmarks with the same name applied at the same time to multiple consistency
groups in a group set.

Group set: A group set is a collection of consistency groups to which the system applies parallel
bookmarks at a user-defined frequency. Group sets are useful for consistency groups that are
dependent on one another or that must work together as a single unit.

19
Link: A link is the communication connection between RecoverPoint copies. When the link is open,
data can be transferred between copies.

Workflow

The following diagram shows a topological representation of the I/O workflow for a VM protected
with the vSCSI splitter installed on the ESXi host as part of an asynchronous remote replication
scenario.

1. A write I/O is initiated by host VM.

2. The ESXi splitter intercepts the write and sends it to the vRPA via the iSCSI Software Adapter.
The vRPA acknowledges the write and the ESXi splitter subsequently sends it to the VMDK.
3. The vRPA in the source vRPA cluster sends the write as part of a snapshot over the WAN link
to its partner vRPA in the target vRPA cluster.
4. The snapshot is received by the target vRPA.
5. The target vRPA sends the write to the owner ESXi host.
6. The write is distributed by the ESXi host to the consistency group copy journal and replica
VM.
7. vRPA distributes the write to the journal and replica VM (not depicted in diagram).

Figure 7

20
Topologies

The following topologies are expected and typical topologies used in conjunction with the
deployment of RecoverPoint for VMs.

Note: RecoverPoint for VMs with VMware Stretch Clustering is not a currently supported topology
solution.

Local Protection of a VM within the same vRPA cluster but between two local ESXi clusters.

Figure 8

21
Local and Remote Protection of a VM between two vRPA/ESXi clusters.

Figure 9

Note: The topology above shows that up to two remote copies can be created at the same target
site/vRPA cluster

22
Remote Protection of a VM between five vRPA/ESXi clusters.

Figure 10

23
Scaled deployment of multiple vRPA clusters (refer to the RecoverPoint for Virtual Machines Scale
and Performance Guide for the scale limitations).

Figure 11

24
Protection

Local protection of a VM can be undertaken using one or more ESXi clusters with a virtual
RecoverPoint System containing a single vRPA or single vRPA cluster. Local protection of a VM can
also be undertaken within a virtual RecoverPoint System containing multiple vRPA clusters and can
be part of a multi-copy protection relationship including remote protection.

Remote protection of a VM can only be undertaken with a minimum of two ESXi clusters, each with
a vRPA cluster. The vRPA clusters must be connected to each other using the Deployer Connect
Cluster Wizard.

Refer to the topology examples in the previous section of this document for architectural reference
and guidance.

For each protected VM, RecoverPoint for VMs creates two VMs, a shadow VM and replica VM. Both
VMs are sharing the same vdisks (VMDKs or RDMs). Under normal operation the shadow VM is
registered and powered on. During this time the shadow VM is a lite VM using a single vCPU and
64MB of memory. Its only use is to allow RP access to the replica volumes while using as low
resources as possible.

While the shadow VM is powered on, the volumes are in FAIL-ALL mode, which means that the
user cannot access them (non-readable\non-writable state) to safeguard the state of the replica
and its data. When the user initiates Test Copy (image access), the shadow VM is powered off and
unregistered and the replica copy VM is registered and powered on. The replica VM uses the same
resources as the protected VM.

Protection of a VM is undertaken using the RecoverPoint for VMs plugin via the vSphere Web Client.
Prior to initiating protection it is recommended to check that all relevant datastores, including the
datastores intended for the repository and journal requirement, are exposed to ESXi hosts in the
ESXi cluster(s).

Note: Any ESXi cluster where VMs are required to be protected need to be registered with the vRPA
cluster via the RecoverPoint for VMs plugin via the vSphere Web Client -> Administration -> ESX
Clusters tab in order to facilitate protection.

It is also recommended to register the datastores to be used for journaling as part of the system.
This is also referred to as the journal resource pool. Complete the following steps to register a
datastore at a vRPA cluster:

1. In the vSphere Web Client home page, click the RecoverPoint for VMs icon >
Administration tab > Related Objects tab.
2. Select the vRPA cluster to which you wish to add datastores then click Add.
3. Select the vCenter server where the datastores are visible. The candidate datastore for
the journal pool(s) are listed with their total size and available size.
4. Select the datastores you wish to register and click OK.

Journal resource pools can also be added as part of the Protect VM Wizard flow.

25
Note: Localised ESXi datastores used for journal datastore pools are supported but are not a best
practice in the event that a vRPA is vMotioned to another ESXi host.

Prior to initiating protection of a VM it is recommended to review the RecoverPoint for Virtual

Machines 5.0 Scale and Performance Guide which provides guidance relating to performance,
scalability and limitations.

The following series of figures illustrates the Remote AND Local protection of a VM.

The RecoverPoint for VMs plugin provides replication visibility and summary task management
from the RecoverPoint for VMs tab in the Web Client shown below in Figure 12. However, the
RecoverPoint for VMs plugin also provides a RecoverPoint for VMs Management capability that is
specifically designed to manage a VM once it has been protected. This is initiated from the
RecoverPoint for VMs icon from the vCenter Home page.

There are three alternative methods of initiating protection of a VM. All methods initiate the Protect
VM Wizard which navigates through the required steps to complete the protection of a VM. Refer to
the RecoverPoint for Virtual Machines Administrator's Guide for step-by-step more detailed
guidance.

Firstly, by clicking on the VM -> Manage -> RecoverPoint for VMs, a VM can be protected by clicking
on the Protect this VM option as shown in the figure below.

Figure 12

26
Secondly, a VM can be protected by right clicking on the VM and navigating to the All RecoverPoint
for Virtual Machines Actions illustrated in the figure below.

Figure 13

Thirdly, a VM can be protected by right clicking on the Summary tab of the VM and navigating to
RecoverPoint for VMs.

Note: Protection of a VM can be initiated while the VM is powered off but initialization will not start
until the VM is powered on.

27
The Protect VM(s) Wizard allows a VM to be protected in isolation in its own consistency group or
as a member of an existing consistency group containing other federated VMs. It also adds the
ability to protect multiple VMs (VM batch protection) as part of the same protection flow via the
Protect additional VM(s) using this group option.

Note: When an additional VM is added to an existing consistency group its VMDK(s) is added as a
new replication set(s). The journal history is no longer deleted due to the RecoverPoint for VMs 5.0
VMDK addition without journal loss feature and only a volume sweep occurs on the new replication
set.

Figures 14 34 depict

Figure 14

28
A name assignment is then given to the consistency group and source vRPA cluster selected.

Figure 15

29
The source VM policy settings (production copy) are then selected including the journal
configuration.

The Add option allows addition of datastore resource pools for the journal from the Protect VM(s)
Wizard as opposed to registering them prior to protection.

Note: If more than one journal datastore/resource pool is registered and automatic provisioning is
selected, all datastores must satisfy the journal size requirement otherwise the journal
provisioning will fail.

Figure 16

30
The RecoverPoint for VMs 5.0 SP1 release replicates the MAC address of the VM to the remote
replica copy VM by default. The Advanced options tab now includes an additional option which
controls the ability to enable MAC address replication for the local replica copy VM:

Automatically replicate new VMDKs

Thin <-> Thick disk provisioning
Replication of VM hardware changes
MAC address replication disable for local copy VMs

Note: Protection of a VM as a RDM device using the automatic option will use a VMFS VMDK as the
replica VM.

Where the option to use an existing replica VM is selected, a sanity check of the replica VM is
undertaken to determine if the virtual disk(s) is/are identical in size to the protected VM.

Note: CPU and memory changes to protected and replica VMs can be performed once the VM is
protected and are visible when the replica VM is started during Test Copy or a recovery activity.

Figure 17

31
The replica copy name is then assigned and the remote vRPA cluster is selected to facilitate the
creation of a remote replica copy VM.

Figure 18

32
The replica VM copy settings are then selected including the replication mode and journal
configuration.

Figure 19

33
A replica ESXi host resource for the replica VM is selected along with a datastore for the replica VM.
The option exists to create the replica VM on a designated datastore or alternatively on an existing
VM.

Note: Where DRS is enabled, the user should select an ESXi cluster and not an individual ESXi host.

Figure 20

Figure 21
34
The final step of the Protect VM(s) Wizard shows a summary of all associated actions of the
previous steps with the option to edit them but it also provides the option to Add a Copy. The
following shows the addition of a local copy to protected VM with an existing remote copy.

Note: One local replica copy with up to three remote replica copies can created concurrently as part
of a multi vRPA cluster RP system. Two remote copies can be created as part of a single target
remote vRPA cluster.

Figure 22

35
The following series of figures depict the addition of a local replica VM to all the already configured
remote VM.

Figure 23

Figure 24

36
Figure 25

Figure 26

37
A summary composition of the consistency group is displayed and the completion of the Protect
VM(s) Wizard initiates an automatic initialization of the consistency group.

Note: Provisioning of the replica VM and journal volumes is not immediate, therefore the
consistency group status will not be initialized immediately and may remain in an N/A state for
several minutes.

Figure 27

38
Once the VM is protected, the status of the VM can be viewed from both the RecoverPoint for VMs
tab under the Manage option of the VM from the vCenter Web Client displayed shown in Figure 28
or via the RecoverPoint for VMs Management option from the Production vCenter Web Client shown
in Figure 30.

Figure 28 below shows the protected VM in the VM inventory along with the Local replica copy
shadow VM which is created as part of the protection process.

Note: A replica shadow VM is identified by the rp. at the front of the virtual machine name and the
.copy.shadow extension at the end of the virtual machine name. User action on replica shadow
VMs is not supported.

Figure 28

39
View from the Paris VC showing the AppServer VM remote replica copy as a shadow copy.

Figure 29

40
Figure 30 and Figure 31show the VM is protected as a VM and also as part of the consistency
group.

Figure 30

41
 Figure 31

Unprotecting a VM can be performed by using the Unprotect option available from RecoverPoint for
VMs via the Manage tab of the VM or from the RecoverPoint for VMs Management option initiated
via the RecoverPoint for VMs icon from the vCenter Home page.

A VM will also become unprotected when the consistency group, where the VM resides, is
removed. This task can only be performed via the RecoverPoint for VMs Management option from
the vCenter Home page. Note that removing a consistency group may unprotect multiple VMs.

Note: The replica copy VM(s) is not automatically deleted when a VM is unprotected or the
consistency group is removed. This is a deliberate action in the event that the user may want to
reinitiate protection or recover from the replica copy VM.

It is recommended that additional administration tasks such as Test a Copy (also known as Image
Access), Failover, Recover Production, creating a bookmark, consistency group management,
licensing etc, should be performed through the RecoverPoint for VMs Management option via the
vCenter Home page.

The Failover and Recover Production tasks are reviewed in the following section of this document.
The other administration tasks are not shown or reviewed as part of this document. Refer to the
RecoverPoint for Virtual Machines 5.0 Administrator's Guide for additional information relating to
these tasks.

42
RECOVERY OPERATIONS

RecoverPoint for VMs enables local AND remote replication allowing Failover or Recover Production
of a consistency group and its constituent VM(s) to any Point in Time. vAdministrators can manage
the lifecycle of VMs directly using the RecoverPoint for VMs plugin via the vSphere Web Client and
perform test, failover, fail back and recovery production to any point in time.

The following series of figures illustrates recovery operations executed against a VM with a local
and remote replica VM as demonstrated during the protection flow of the previous section of this
document.

RecoverPoint recovery operations are also guided by wizards and can be performed from
RecoverPoint for VMs via the Manage tab of the VM or using the RecoverPoint for VMs
Management option from the vCenter Home page.

The Recover Production and Failover tasks can be initiated from the VM or consistency group but
both initiate the relevant activity against the consistency group and all VMs within it. Both tasks
will initiate the pre-requisite Test Copy (image access) step prior to the recover or failover activity
as this is a mandatory step to allow customers to check the integrity of the VM(s) prior to
completing the Recover Production or Failover task.

Note that recovery operations can be initiated against a group of consistency groups known and
referred to as a group set. Group sets are useful for consistency groups that are dependent on one
another or that must work together as a single unit.

43
Failover

The Failover Wizard guides you through the process of recovering from a disaster at the Production
site and allows system operations to continue from the replica/copy VM. During failover, transfer is
paused and access to the original production source VM(s) is blocked. Failover promotes the
shadow VM at the replica to the role of Production. The original Production VM becomes the replica
VM adopting the role of a replica copy with a .shadow extension.

Figures 35 - 49 depict the summary flow of the Failover activity between two vRPA clusters (New
York and Paris) in a single RP system using the App1 consistency group containing a Local replica
copy (Prod Local) and a single remote replica copy (DR). For specific details relating to this recovery
operation refer to the Failover section in the RecoverPoint for Virtual Machines 5.0 Administrator's
Guide.

The Figure 32 below depicts initiation of the failover operation using the App1 consistency group
from the Prod copy at New York to the DR remote replica copy at Paris. However, the failover can
also be initiated from a specific VM under the Virtual Machines tab.

Figure 32

44
Both the Prod Local and DR replies are available for selection.

Figure 33

45
The DR remote replica copy is selected.

Figure 34

46
The latest image (snapshot) default option is selected.

Figure 35

47
Select the appropriate network option.

Figure 36

48
Enable image access mode to allow testing of the DR remote replica copy VM before failing over.

Figure 37

49
Wait for the DR remote replica VM to power up.

Figure 38

50
Initiate the Failover and confirm the action.

Figure 39

51
The Prod Local replica copy is removed from the replication relationship.

Figure 40

52
The original Production VM becomes the shadow.

Figure 41

53
Consistency group still failing over.

Figure 42

54
DR remote copy is transitioning to source (Remote Source) whilst original Production copy is
transitioning to target (Target at Production).

Figure 43

55
Once failover has been initiated because the consistency group has multi-copy protection, two
options are available as shown below after selecting Next Action. The replica/target VM copy can
be selected to a state of Set Copy as Production or Fail Back to Production via the Recovery
Activties option under the Dashboard tab.

Figure 44

56
Set the DR remote replica copy as the new Production.

Figure 45

57
After setting DR replica remote copy as the new Production copy (Set Copy as Production),
replication is reversed and there is the option to enable the original Prod Local copy as a remote
copy, thus creating two remote replica copy VMs.

Figure 46

58
The DR copy is now Production and has two remote replica copies.

Figure 47

59
View from the RP4VMs Management plugin at the original Production VC (New York) showing no
protected VMs because the VM is now protected from the Paris vRPA cluster in the Paris VC.

Figure 48

60
Figure 49

61
Recover Production

Recovering production restores the production/source VM from the replica VM at the selected point
in time. The Recover Production wizard guides you through the process of correcting file or logical
corruption, by rolling the production/source VM to a previous point-in-time.

Figures 50 - 58 depict the summary flow of the Recover Production activity between two vRPA
clusters (New York and Paris) in a single RP system using the App1 consistency group containing a
Local replica copy (Prod Local) and a single remote replica copy (DR). For specific details relating to
this recovery operation refer to the Failover section in the RecoverPoint for Virtual Machines 5.0
Administrator's Guide.

The Figure 50 below depicts initiation of the recover production operation using the App1
consistency group using the Prod Local copy at New York. However, the recover production can also
be initiated from a specific VM under the Virtual Machines tab.

Figure 50

62
Both the Prod Local and DR replies are available for selection.

Figure 51

63
The Prod Local replica copy is selected.

Figure 52

64
The latest image (snapshot) default option is selected.

Figure 53

65
Select the appropriate network option.

Figure 54

66
Enable image access mode to allow testing of the Prod Local replica copy VM before recovering
to production.

Figure 55

67
Wait for the Prod Local replica VM to power up.

Figure 56

68
Initiate the Recover Production and confirm the action.

Figure 57

69
Recovery completed and replication resumed to the replica copies.

Figure 58

70
ORCHESTRATION

The RecoverPoint for VMs provides the following orchestration features to compliment its recovery
capabilities:

Start-up priority
User scripts
User prompts
Re-IPing (Network Configuration Method)

The Start-up priority of a VM can now be pre-configured to facilitate prioritization when performing
recovery activities. It supports application inter-dependency by sequencing the start-up of VMs
within a consistency group and/or with multiple consistency groups within a group set. A VM can
be set to Critical as part of the start-up sequence. When a VM is set to critical, and it fails to power-
up, the start-up sequence will be paused by system, and no other VMs will power-up.

The start-up sequence can be configured using the Edit Start-Up Sequence option for the
consistency group and/or group set. This option also allows configuration of the User scripts and
User prompts before powering on and after powering on. An external host can be configured to run
scripts when executing a Test Copy, Recover Production or Failover. The prompted messages
feature provides the option of administrator configurable messages during the recovery flow.

Note that the VMware Tools should be installed in the operating system of a VM to facilitate the
use of user scripts.

Refer to the the RecoverPoint for Virtual Machines 5.0 Administrator's Guide for additional
configuration information relating to this feature.

The following figures depict the settings required within the RecoverPoint for VMs Management
option to initiate the start-up sequence features.

The re-IPing feature for replica VMs as part of RecoverPoint for VMs 5.0 SP1 facilitates network
configuration automation to avoid IP duplication without the need to use glue scripts.

Use the re-IPing feature to change a copy VM's network settings when testing a copy, failing over,
or recovering production. Use the RP4VMs Management plugin to change the network
configuration of a small number of VMs, or use a comma-separated values (*.csv) file to change the
network configuration of many VMs in a copy or system.

Note: VMware Tools is required on the replica VM.

Re-IPing is supported for VMs running the following OSes:

Microsoft Windows server versions 8, 10, 2008 R2, 2012, and 2016
Red Hat Linux server versions 6.5 and 7.2
Ubuntu Studio 15.10.n

71
 Linux CentOS 7.x, (requires VMware Tools version 10.1.0.57774 has been manually
installed, and the value of each production VM's ifconfig version has been changed to 1.6 in
the VM settings)
Linux SLES12, (requires Open VM Tools version 9.4.0.25793 and deployPkg manually
installed - VMWare KB article 2075048 for detailed information on how to install deployPkg)

Refer to the RecoverPoint for Virtual Machines 5.0 Administrator's Guide for additional
configuration information relating to this feature.

Figures 59- 75 depict the summary flow within the RecoverPoint for VMs Management plugin to
initiate re-IPing in conjunction with Test a Copy.

72
AppServer W2K12 replica VM in shadow state and therefore shutdown.

Figure 59

73
Open the RP4VMs Management plugin, select the Protection tab follows by the Consistency
Groups tab then open the Consistency Group and select the DR remote replica VM.

Figure 60

74
VMware Tools showing as installed in the AppServer W2K12 shadow replica.

Figure 61

75
Note that the legacy glue script option is still available for customers who have upgraded from a
previous version having already implemented a glue script solution.

Figure 62

76
Manually enter network configuration or use the Get Value From Production options and then
edit accordingly.

Figure 63

77
IP address set to different/unique address from Production VM.

Figure 64

78
Initiate Test a Copy.

Figure 65

79
The DR remote replica copy is selected.

Figure 66

Figure 67

80
The latest image (snapshot) default option is selected.

Figure 68

81
The isolated network option is selected in this example. With a Failover activity the dedicated
network option may be used.

Figure 69

82
 Figure 70

Wait for the DR replica VM to power up.

Figure 71

83
DR replica copy VM showing as transitioned from shadow to copy with new IP address.

Figure 72

84
KVSS

The RecoverPoint for VMs 5.0 release also introduces the ability to create application-consistent
snapshots, known as bookmarks, on every VM running Windows 2008 or 2012 R2 in its own
consistency group. KVSS bookmarks are created using the kvss.exe utility for Windows 32-bit VMs
or the kvssx64.exe utility for Windows 64-bit VMs.

The primary usage for the KVSS utility in conjunction with VMs protected by RecoverPoint for VMs is
where VMs are running a SQL database although the KVSS utility also supports Exchange.

For more information relating to this feature refer to the RecoverPoint for Virtual Machines
Administration Guide and/or the RecoverPoint Replicating Microsoft SQL Server Technical Notes
and/or the RecoverPoint Replicating Microsoft Windows File Systems Technical Notes. These
documents contain additional detailed information on how to download, install and use
RecoverPoint KVSS to create application-consistent bookmarks.

85
SUPPORTED VMWARE FEATURES

The following table details the features supported by RecoverPoint for VMs.

Feature1
VM File System (VMFS) Supported
Raw Device Mapping (RDM) Supported
High Availability (HA) Supported
Distributed Resource Scheduler (DRS) Supported
vMotion Supported
Storage vMotion Supported
Site Recovery Manager (SRM) Not Supported
Fault tolerance (FT) Not Supported
vStorage thin provisioning Supported
VMware Snapshots Supported2
VMware Tools Supported3
vApp Not Supported
VAAI Not Relevant4

Table 2
1
All ESXI hosts in the ESXi cluster are required to have a splitter installed and have shared access
to the datastores in order to support some of the features contained in the table above, e.g. HA,
vMotion etc.
2
The RecoverPoint for VMs solution works above the snapshots layer and is not aware of them.
Taking VMware snapshots is supported on production VMs and on replica copy VMs in Logged
image access mode. Using the VM Restore operation to restore a production VM from a VMware
snapshot or clone will cause a full sweep.
3
Upgrading VMware tools on the vRPAs is strictly unsupported and may lead to undesired results.
4
The VAAI primitives allow for offloading certain storage operations on the array itself and are
therefore transparent to RecoverPoint for VMs.

Note: For information relating to these features and supported VMware actions, refer to the
RecoverPoint for Virtual Machines Administrator's Guide.

86
vMOTION/STORAGE vMOTION

vMotion and Storage vMotion activities are supported with RecoverPoint for VMs on both the
source and replica VMs.

In order to facilitate a Storage vMotion of a replica VM both the shadow and replica VMs need to be
performed:

1. Storage vMotion the shadow VM only the configuration file (.vmx) should be migrated,
the replica VMDK(s) should be kept on the current datastore. By default, the
configuration file and all VMDKs are migrated as part of the storage vMotion process so it
is vital to click on "Advanced" on the "Select Datastore" step of the "Migrate Virtual
Machine" wizard and select a different datastore specifically for the configuration file
while keeping the VMDKs on the current datastore.
2. Initiate Test Copy (enable image access) using the available icon option in order to
power-up the replica VM.
3. Storage vMotion the replica VM (including the configuration file and all VMDKs) to the
target datastore.
4. Check if the target datastore has a "RecoverPoint" folder with a RecoverPointVM.flp file. If
it does not, copy the RecoverPoint folder from the source datastore to the target
datastore.
5. Initiate Disable Image Access using the available icon option in order to power down the
replica VM and re-register the shadow VM.
6. Edit the settings of the shadow VM and point the floppy image to the
RecoverPointVM.flp file on the target datastore.

87
LICENSING

Refer to the latest RecoverPoint for Virtual Machines Ordering and Licensing Guide for information
relating to licensing.

RecoverPoint for VMs licensing is per # of protected VMs with the Production VMs vCenter ID (of the
source vCenter where the VMs are being protected) needing to be licensed.

A protected VM is associated with a Production vCenter. This association is created when the CG
is defined, and is maintained even when a VM has failed over. There is no need for a license on the
DR site vCenter (replica/target site) the license for a failed-over VM continues to count against
the pool of its Production vCenter unless it is also desired to protect VMs on this site.

The license file acts as a dynamic pool. RecoverPoint for VMs cluster obtain their license from the
vCenter Server license pool. When a CG is protected, the number of available VM licenses
decreases by then number of VMs in that CG. When protection is removed from a CG, the available
license pool increases back to the same number of VMs.

The license to protect a VM includes all of its copies. Whether a VM is protected locally, remotely,
locally and remotely or with two remote copies, all copies count against one VM license.

88
REST API

RecoverPoint for Virtual Machines 5.0 REST (Representative State Transfer) API is intended for
developers who wish to integrate RecoverPoint for VMs with their own applications, and for those
who need to write scripts that automate RecoverPoint for VMs operations.

REST is an architectural style for designing networked applications whereby applications can be
developed to use HTTPS requests to POST GET PUT and DELETE RecoverPoint for VMs data.

The RecoverPoint for VMs 5.0 REST API provides a landing page at: https://<RPA IP
Address>:7225/fapi/rest/4_1/ that contains links to the auto-generated documentation, the
WADL, and the XML Schema.

For additional information relating to REST API, refer to the RecoverPoint for Virtual Machines 5.0
REST API Programming Guide.

89
VXRAIL

Refer to the Deploying RecoverPoint for Virtual Machines 5.0 SP1 with VxRAIL Whitepaper, Dell EMC
Online Support->Support by Product->VxRAIL Apppliance Family->Downloads.

90
CONCLUSION

This document provides comprehensive information in relation to RecoverPoint for Virtual

Machines.

It provides a summary of the latest release features, an in-depth overview of the components, a
review of potential topologies, a pictorial depiction of the replication and recovery flows plus
detailed reference to existing and related features.

Note that a successful deployment always requires efficient sizing and monitoring.

91
REFERENCES

The following documents were used or referenced in conjunction with the authoring of this
document. All documents are available at Dell EMC Online Support website,
https://support.emc.com:

RecoverPoint for Virtual Machines 5.0 Release Notes

RecoverPoint for Virtual Machines 5.0 Installation and Deployment Guide
RecoverPoint for Virtual Machines 5.0 Administrators Guide
RecoverPoint for Virtual Machines 5.0 Product Guide Release
RecoverPoint for Virtual Machines 5.0 Scale and Performance Guide
RecoverPoint for Virtual Machines 5.0 REST API Programming and Reference Guide
RecoverPoint for Virtual Machines Simple Support Matrix 5.0
RecoverPoint for Virtual Machines 5.0 Ordering and Licensing Guide Release
Deploying RecoverPoint for Virtual Machines 5.0 SP1 with VxRAIL Whitepaper

92