VMware vCenter Site Recovery Manager - 5.0 Administrator’s Guide

Site Recovery Manager Administration

Guide

vCenter Site Recovery Manager 5.0

This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new edition. To check for more recent editions of this document, see http://www.vmware.com/support/pubs.

EN-000706-01

Site Recovery Manager Administration Guide

You can find the most up-to-date technical documentation on the VMware Web site at:

http://www.vmware.com/support/

The VMware Web site also provides the latest product updates.

If you have comments about this documentation, submit your feedback to:

docfeedback@vmware.com

Copyright © 2008–2012 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at

http://www.vmware.com/go/patents.

VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies.

VMware, Inc.

3401 Hillview Ave. Palo Alto, CA 94304 www.vmware.com

2 VMware, Inc.

About This Book 7

Administering VMware vCenter Site Recovery Manager 9

SRM Deployment 10

Protected Sites and Recovery Sites 11

Array-Based Replication 11

vSphere Replication 12

About Protection Groups and Recovery Plans 13

Testing and Running a Recovery Plan 14

About Reprotect 16

About Failback 16

About the Site Recovery Manager Database 16

SRM and VMware vCenter Server 17

SRM Licensing 18

SRM Authentication 18

Requirements When Using Public Key Certificates 19

Understanding Roles and Permissions 20

Assign Roles and Permissions 21

SRM Roles Reference 21

SRM Network Ports 23

Connecting to SRM 24

Operational Limits of Site Recovery Manager 24

Installing and Updating Site Recovery Manager 27

Configuring the SRM Database 28

Microsoft SQL Server Configuration 28

Oracle Server Configuration 28

DB2 Server Configuration 29

About the vSphere Replication Management Database 29

Configure the VRM Database 29

Install the SRM Server 31

Upgrading SRM 33

Prepare for SRM Upgrade 34

Update the SRM Server 35

Upgrade the SRM Client Plug-In 36

Configure the Upgraded SRM Installation 36

SRM Migration Utility 37

Install Storage Replication Adapters 38

Install the SRM Client Plug-In 38

Connect the Sites 39

Revert to a Previous Release 40

Repair or Modify the Installation of a Site Recovery Manager Server 40

VMware, Inc.

Site Recovery Manager Administration Guide

Install the SRM License Key 42

Establishing Inventory Mappings and Placeholder Datastores 43

Understanding Placeholder Datastores 43

Configure a Placeholder Datastore 44

Configure Datastore Mappings for vSphere Replication Management 44

Select Inventory Mappings 44

Configuring Array-Based Protection 47

Configure Array Managers 47

Rescan Arrays to Detect Configuration Changes 48

Edit Array Managers 48

Installing vSphere Replication Servers 51

Deploy a vSphere Replication Management Server 52

Configure vSphere Replication Management Server Settings 52

Configure VRMS Security Settings 53

Configure VRMS Network Settings 54

Configure VRMS System Settings 54

Configure vSphere Replication Management Connections 55

Deploy a vSphere Replication Server 55

Configure vSphere Replication Server Settings 56

Creating Protection Groups and Replicating Virtual Machines 59

Limitations to Protection and Recovery of Virtual Machines 59

Create Array-Based Protection Groups 60

Edit Array-Based Protection Groups 61

Create vSphere Replication Protection Groups 61

Edit vSphere Replication Protection Groups 62

Configure Replication for a Single Virtual Machine 62

Configure Replication for Multiple Virtual Machines 63

Replicate Virtual Machines Using Physical Couriering 64

Move a Virtual Machine to a New vSphere Replication Server 66

Apply Inventory Mappings to All Members of a Protection Group 66

Recovery Plans and Reprotection 67

Create a Recovery Plan 67

Edit a Recovery Plan 68

Remove a Recovery Plan 68

Test a Recovery Plan 68

Cancel a Test or Recovery 69

Run a Recovery Plan 70

Understanding Reprotection 71

Reprotection Process 72

Reprotection State Reference 73

4 VMware, Inc.

Customizing Site Recovery Manager 75

Customizing a Recovery Plan 75

Recovery Plan Steps 75

Customize Recovery Plan Steps 77

Customize the Recovery of an Individual Virtual Machine 80

Customize IP Properties For an Individual Virtual Machine 80

Report IP Address Mappings for a Protection Group 82

Understanding Customizing IP Properties for Multiple Virtual Machines 82

Configure Protection for a Virtual Machine or Template 86

Configure Resource Mappings for a Virtual Machine 87

Configure SRM Alarms 88

Working with Advanced Settings 88

Guest Customization Settings 88

Change Recovery Site Settings 89

Change Array-Based Storage Provider Settings 89

Change Local Site Settings 90

Change Remote Site Settings 91

Change Storage Settings 91

Change Replication Setting 92

Change vSphere Replication Settings 92

Contents

Troubleshooting SRM 93

Events and Alarms 93

Site Status Events 94

Protection Group Events 94

Recovery Events 96

SNMP Traps 97

Storage and Storage Provider Events 98

Licensing Events 101

Permissions Events 101

Collecting SRM Log Files 102

Collect SRM Log Files Using the vSphere Client 102

Collect SRM Server Log Files 102

Features Are Unavailable When Deploying VRMS 103

OVF Package is Invalid and Cannot be Deployed 103

Connection Errors Between VRMS and SQL Cannot be Resolved 103

Configuration of the VRMS Database Fails with DB2 Databases 104

Index 105

VMware, Inc. 5

Site Recovery Manager Administration Guide

6 VMware, Inc.

About This Book

VMware® vCenter Site Recovery Manager (SRM) is an extension to VMware vCenter that delivers a business continuity and disaster recovery solution that helps you plan, test, and execute the recovery of vCenter virtual machines. SRM can discover and manage replicated datastores, and automate migration of inventory from one vCenter to another.

Intended Audience

This book is intended for Site Recovery Manager administrators who are familiar with vSphere and it replication technologies such as host based replication and replicated datastores. This solution serves the needs of administrators who want to configure protection for vSphere inventory. It may also be appropriate for other users who need to add virtual machines to protected inventory or verify that existing inventory is properly configured for use with SRM.

VMware Technical Publications Glossary

VMware Technical Publications provides a glossary of terms that might be unfamiliar to you. For definitions of terms as they are used in VMware technical documentation, go to http://www.vmware.com/support/pubs.

Document Feedback

VMware, Inc.

VMware welcomes your suggestions for improving our documentation. If you have comments, send your feedback to docfeedback@vmware.com.

Site Recovery Manager Administration Guide

Technical Support and Education Resources

The following technical support resources are available to you. To access the current version of this book and other books, go to http://www.vmware.com/support/pubs.

Online and Telephone Support

Support Offerings

VMware Professional Services

To use online support to submit technical support requests, view your product and contract information, and register your products, go to

http://www.vmware.com/support.

Customers with appropriate support contracts should use telephone support for the fastest response on priority 1 issues. Go to

http://www.vmware.com/support/phone_support.html.

To find out how VMware support offerings can help meet your business needs, go to http://www.vmware.com/support/services.

VMware Education Services courses offer extensive hands-on labs, case study examples, and course materials designed to be used as on-the-job reference tools. Courses are available onsite, in the classroom, and live online. For onsite pilot programs and implementation best practices, VMware Consulting Services provides offerings to help you assess, plan, build, and manage your virtual environment. To access information about education classes, certification programs, and consulting services, go to

http://www.vmware.com/services.

8 VMware, Inc.

Administering VMware vCenter Site

Recovery Manager 1

VMware vCenter Site Recovery Manager (SRM) is a business continuity and disaster recovery solution that helps you plan, test, and execute the recovery of vCenter virtual machines between one site (the protected site) and another site (the recovery site).

You can configure SRM to work with several third-party disk replication mechanisms (array based replication) or with VMware vSphere Replication.

Two types of recovery are available.

Planned Migration

Disaster Recovery

SRM coordinates the recovery process with the underlying replication mechanisms that the virtual machines at the protected site are shut down cleanly (in the event that the protected site virtual machines are still available) and the replicated virtual machines can be powered up. Recovery of protected virtual machines to the recovery site is guided by a recovery plan that specifies the order in which virtual machines are started up. The recovery plan also specifies network parameters, such as IP addresses, and can contain user-specified scripts that can be executed to perform custom recovery actions.

After a recovery has been performed, the running virtual machines are no longer protected. To address this reduced protection, SRM supports a reprotect operation for virtual machines protected on array-based storage. The reprotect operation reverses the roles of the two sites after the original protected site is back up. The site that was formerly the recovery site becomes the protected site and the site that was formerly the protected site becomes the recovery site.

SRM lets you test recovery plans. You can conduct tests using a temporary copy of the replicated data in a way that does not disrupt ongoing operations at either site. You can conduct tests after a reprotect has been done to confirm that the new protected/recovery site configuration is valid.

This chapter includes the following topics:

Planned migration is the orderly decommissioning of virtual machines at the protected site and commissioning of equivalent machines at recovery site. For planned migration to succeed, both sites must be up and fully functioning.

Disaster recovery is similar to planned migration except it does not require that both sites be up. During a disaster recovery operation, failure of operations on the protected site are reported but otherwise ignored.

VMware, Inc.

“SRM Deployment,” on page 10

“Protected Sites and Recovery Sites,” on page 11

“About the Site Recovery Manager Database,” on page 16

“SRM and VMware vCenter Server,” on page 17

“SRM Licensing,” on page 18

“SRM Authentication,” on page 18

Site Recovery Manager Administration Guide

“Understanding Roles and Permissions,” on page 20

“SRM Network Ports,” on page 23

“Connecting to SRM,” on page 24

“Operational Limits of Site Recovery Manager,” on page 24

SRM Deployment

You must complete several groups of tasks to configure SRM. You complete some tasks in all cases, and you complete some tasks only for vSphere Replication (VR) or for array based replication. If your environment will use both types of replication, consider all tasks, but if not, you might need to complete only a subset of the total possible set of tasks.

The set includes the following tasks:

1 Obtain the latest SRM software and any required patches.

2 Configure the SRM databases at each site.

3 Install SRM at the protected site.

4 Install SRM at the recovery site.

5 Pair sites.

In the case of using VR, complete the following tasks:

1 Deploy a vSphere Replication Management Server (VRMS) at the protected site.

2 Deploy VRMS at the recovery site.

3 Configure a database for VRMS at both sites.

4 Configure both VRMS servers using the Virtual Appliance Management Interface (VAMI).

5 Deploy a vSphere Replication Server (VRS) at the recovery site.

6 If bi-directional replication is required, deploy a VR server at the protected site.

7 Register VRS with VRMS.

8 Connect the two VRMS appliances between sites.

In the case of using array based replication, complete the following tasks at both sites:

1 Install Storage Replication Adapters (SRAs).

2 Configure array managers.

After you establish the required infrastructure for VR, arrays, or both, complete the following steps:

1 Configure inventory mappings.

2 Configure placeholder datastores.

3 If you are using VR, configure datastore mappings.

4 Create protection groups.

5 Protect virtual machines.

6 Create recovery plans.

10 VMware, Inc.

Protected Sites and Recovery Sites

In a typical SRM installation, the protected site provides business-critical datacenter services. The recovery site is an alternative facility to which these services can be migrated.

The protected site can be any site where vCenter supports a critical business need. The recovery site can be located thousands of miles away. Conversely, the recovery site can be in the same room as a way of establishing redundancy. The recovery site is usually located in a facility that is unlikely to be affected by environmental, infrastructure, or other disturbances that affect the protected site.

SRM has the following requirements for the VMware vSphere® configurations at each site:

Each site must have at least one datacenter.

If you are using array-based replication, identical replication technologies must be available at both sites.

The recovery site must have hardware, network, and storage resources that can support the same virtual machines and workloads as the protected site.

The sites should be connected by a reliable IP network. If you are using array-based replication, ensure your network connectivity meets the arrays' network requirements.

The recovery site should have access to comparable networks (public and private) as the protected site, although not necessarily the same range of network addresses.

Chapter 1 Administering VMware vCenter Site Recovery Manager

Site Pairing

The protected and recovery sites must be paired before you can use SRM. SRM includes a wizard that guides you through the site-pairing process. You must establish a connection between the sites and you must provide authentication information for the two sites so they can exchange information. Site pairing requires vSphere administrative privileges at both sites. To initiate the site-pairing process, you must know the user name and password of a vSphere administrator at each site. If you are using vSphere Replication, pair vSphere Replication Management Servers similarly to how SRM sites are paired.

Array-Based Replication

When using array-based replication, one or more storage arrays at the protected site replicate data to peer arrays at the recovery site. Storage replication adapters (SRAs) enable integration of SRM with a wide variety of arrays.

If you plan to use array-based replication with SRM, establish replication before you install and configure SRM.

Storage Replication Adapters

Storage replication adapters are not part of an SRM release. They are developed and supported by your array vendor. You can download storage replication adapters and their documentation from

http://www.vmware.com/download/srm/. VMware does not support storage replication adapters

downloaded from other sites. You must install an SRA specific to each array that you use with SRM on the SRM server host. SRM supports using multiple SRAs.

About Bidirectional Operation

You can use a single set of paired SRM sites to protect in both directions. Each site can simultaneously be both a protected site and recovery site but for a different set of virtual machines. This feature is not limited to arraybased replication but when you are using array-based replication, any given one of the array’s LUNs is only ever replicating in one direction. Two different LUNs in the same array can each be replicating in different directions from each other.

VMware, Inc. 11

Site Recovery Manager Administration Guide

How Site Recovery Manager Computes Datastore Groups

The composition of a datastore group is determined by the set of virtual machines that have files on the datastores in the group, and by the devices on which those datastores are stored.

When you use array-based replication, each storage array supports a set of replicated devices. On Storage Area Network (SAN) arrays that use connection protocols such as Fibre Channel and iSCSI, these devices are called LUNs (logical storage units comprising one or more physical devices). On NFS arrays, they are typically referred to as volumes. In every pair of replicated storage devices, one device is the replication source and the other is the replication target. Data written to the source device is replicated to the target device on a schedule controlled by the arrays' replication software. When you configure SRM to work with an SRA, the replication source is at the protected site and the replication target is at the recovery site.

A datastore provides storage for virtual machine files. By hiding the details of physical storage devices, datastores simplify the allocation of storage capacity and provide a uniform model for meeting the storage needs of virtual machines. Because any datastore can span multiple devices, SRM must ensure that all devices backing the datastore are replicated before it can protect the virtual machines that use that datastore. SRM must ensure that all devices containing protected virtual machine files are replicated. During a recovery or test, SRM must handle all such devices together. To achieve this goal, SRM aggregates datastores into datastore groups to accommodate virtual machines that span multiple datastores. SRM regularly checks that datastore groups contain all necessary datastores to provide protection for appropriate virtual machines. When necessary, datastore groups are recalculated. For example, this may occur when new devices are added to a virtual machine, and those devices are stored on a datastore that was not previously a part of the datastore group.

A datastore group consists of the smallest set of devices required to ensure that if any of a virtual machine's files is stored on a device in the group, all of the virtual machine's files are stored on devices that are part of the same group. For example, if a virtual machine has disks on two different datastores, then both datastores must be combined into a datastore group. Conditions that can cause datastores to be combined into a datastore group include:

A virtual machine has files on two different datastores.

Two virtual machines share an RDM device on a SAN array, such as in the case of an MSCS cluster.

Two datastores span extents corresponding to different partitions of the same device.

A single datastore spans two extents corresponding to partitions of two different devices.

Multiple devices belong to a consistency group. A consistency group is a collection of replicated devices where every state of the target set of devices existed at some point in time as the state of the source set of devices. Informally, the devices are replicated together such that when recovery happens using those devices, software accessing the targets do not see the data in a state it is not prepared to deal with.

vSphere Replication

In vSphere Replication (VR), SRM uses vSphere replication technologies to replicate data to servers at the recovery site.

vSphere Replication uses vSphere Replication Management Server (VRMS) to manage the VR infrastructure. VR requires installing the VR Server (VRS) virtual appliance and VRMS virtual appliance, both of which can be installed with SRM during the installation process. While VR does not require storage arrays, an VR storage replication source and target can be any regular storage device, including, but not limited to, storage arrays.

12 VMware, Inc.

Chapter 1 Administering VMware vCenter Site Recovery Manager

About Protection Groups and Recovery Plans

A protection group is a collection of virtual machines and templates. A recovery plan specifies how the virtual machines in a specified set of protection groups are recovered. In the case of virtual machines replicated using array-based replication, protection groups are composed of virtual machines that use the same replicated datastore group.

When you create a protection group for array-based replication, you specify array information and SRM computes the set of virtual machines. When you create a protection group for virtual machines that are replicated with vSphere Replication, you can add any virtual machines to the protection group.

With array-based replication, all of the virtual machines and templates on the datastores in the protection group's datastore group are recovered together. When you create a protection group, it initially contains only those virtual machines that store all of their files on one of the datastore groups associated with the protection group. You can add virtual machines to the protection group by creating them on one of the datastores that belong to the datastore groups associated with the protection group. You can also add virtual machines to the protection group by using Storage vMotion to move their storage onto one of the datastores that belong to the datastore groups associated with the protection group. You can remove a member from a protection group by moving the virtual machine's files to another datastore. A protection group can contain one or more datastore groups. However, a datastore group can belong to only one protection group.

Multiple Recovery Plans for the Same Protection Group

A recovery plan is like an automated runbook. It controls every step of the recovery process, including the order in which virtual machines are powered off or powered on, the network addresses that recovered virtual machines use, and so on. Recovery plans are flexible and easy to customize.

A recovery plan references one or more protection groups. A protection group can be specified in more than one recovery plan. For example, you can create one recovery plan to handle a planned migration of services from the protected site to the recovery site, and another plan to handle an unplanned event such as a power failure or natural disaster. Having these different recovery plans allow you to decide how recovery occurs.

You can use only one recovery plan at a time to recover a protection group. If multiple recovery plans that specify the same protection group are tested or run simultaneously, only one recovery plan can failover the protection group. Other running recovery plans that specify the same protection group report warnings for that protection group and the virtual machines it contains. These warnings explain that the virtual machines were failed over. Other protection groups that those recovery plans cover are not affected by the warnings.

Configuring and Maintaining the Protection of a Virtual Machine

Every virtual machine in a protection group must be configured in such a way that it can be added to vSphere inventory at the recovery site. Array-based replication requires that each virtual machine be assigned to a resource pool, folder, and network that exist at the recovery site. An SRM administrator can specify defaults for these assignments. These defaults, called inventory mappings, are applied when the protection group is created, and can be reapplied as needed, for example, whenever you add a new virtual machine to the protection group. If you do not specify inventory mappings, you must configure them individually for each member of the protection group. Virtual machines that are on a protected datastore but that are not configured or are improperly configured are not protected.

VMware, Inc. 13

Site Recovery Manager Administration Guide

About Placeholder Virtual Machines and Inventory Mapping

For each virtual machine that you add to a protection group, SRM creates a placeholder at the recovery site. These placeholders are added to, and can be managed as part of, the recovery site's inventory.

When you add a virtual machine or template to a protection group, SRM reserves a place for it in the recovery site's inventory by creating a subset of virtual machine files at the recovery site and then using that subset as a placeholder to register the virtual machine with the recovery site vCenter. The presence of these placeholders in recovery site inventory provides a visual indication to SRM administrators that the virtual machines are protected, and to vCenter administrators that the virtual machines can be powered on and start consuming local resources when SRM tests or runs a recovery plan.

No member of a protection group is protected until its placeholder has been created. Placeholders are not created until valid inventory mappings have been established by either applying the site’s inventory mappings to all members of a protection group or configuring mappings for individual members. If inventory mappings are established for a site, you cannot override them by configuring the protection of individual virtual machines. If you need to override inventory mappings for a few members of a protection group, use the vSphere Client to connect to the recovery site and edit the settings of the placeholders or move them to a different folder or resource pool.

You can treat placeholders like other members of the recovery site vCenter inventory, although they cannot be powered on. When a placeholder is created, its folder and compute resource assignments are derived from inventory mappings established at the protected site. A recovery site vCenter administrator can modify folder and compute resource assignments as necessary. Changes to a placeholder virtual machine network can be edited only in the inventory mappings. If no mapping for a network exists, the user can specify a new network when protecting the virtual machine. Changes made to the placeholder override settings established during the protection of the virtual machine and are preserved at the recovery site during the test and recovery.

When you recover a protected virtual machine by testing or running a recovery plan, its placeholder is replaced by the recovered virtual machine and powered on as directed by the recovery plan. After a recovery plan test finishes, the placeholders are restored as part of the cleanup process.

Testing and Running a Recovery Plan

Testing a recovery plan exercises nearly every aspect of a recovery plan, though several concessions are made to avoid disrupting ongoing operations. While testing a recovery plan has no lasting effects on either the protected or the recovery site, running a recovery plan has significant effects on both sites.

Run test recoveries as often as needed. Testing a recovery plan does not affect replication or the ongoing operations of either site. Testing a recovery plan might temporarily suspend selected local virtual machines at the recovery site if recoveries are configured to do so. You can cancel a recovery plan test at any time.

In the case of planned migrations, a recovery stops replication after a final synchronization of the source to the target. For disaster recoveries, virtual machines are restored to the most recent available state, as determined by the recovery point objective (RPO). After the final replication is completed, SRM makes changes at both sites that require significant time and effort to reverse. Because of this, the privilege to test a recovery plan and the privilege to run a recovery plan must be separately assigned.

You need different privileges when testing and running a recovery plan.

Table 1-1. Differences Between Testing and Running a Recovery Plan

Test a Recovery Plan Run a Recovery Plan

Required privileges Assign the Site Recovery

Manager.Recovery Plans.Testpermission from the Permissions tab.

Effect on virtual machines at protected site

None Virtual machines are shut down in reverse

Assign the Site Recovery

Manager.Recovery Plans.Recovery

permission from the Permissions tab.

priority order.

14 VMware, Inc.

Chapter 1 Administering VMware vCenter Site Recovery Manager

Table 1-1. Differences Between Testing and Running a Recovery Plan (Continued)

Test a Recovery Plan Run a Recovery Plan

Effect on virtual machines at recovery site

Effect on replication Temporary snapshots of replicated

Network If test networks are explicitly

Interruption Can be canceled. May be canceled in some cases.

Local virtual machines are suspended if required by the plan. Suspended virtual machines are restarted after the test is cleaned up.

storage are created at the recovery site. For array based replication, the arrays are rescanned to discover them.

assigned, recovered virtual machines are connected to a test network. If virtual machine network assignment is auto, SRM assigns virtual machines to temporary networks that are not connected to any physical network.

Local virtual machines are suspended if required by the plan.

In the case of a planned migration, replicated datastores are synchronized, then replication is stopped, and the target devices at the recovery site are made writable. During a disaster recovery, the same steps are attempted, but if they do not succeed, the errors are ignored.

Recovered virtual machines are connected to a datacenter network.

How SRM Interacts with DPM and DRS During Recovery

Distributed Power Management (DPM) is a VMware feature that manages power consumption by ESX hosts. Distributed Resource Scheduler (DRS) is a VMware facility that manages the assignment of virtual machines to ESX hosts. DPM and DRS are not mandatory, but SRM supports both services and enabling them provides certain benefits when using SRM.

SRM temporarily disables DPM for the cluster and ensures that all hosts in it are powered on before recovery begins. After the recovery or test is complete, SRM re-enables DPM for the cluster, but the hosts in it are left in the running state so that DPM can power them down as needed. SRM registers virtual machines across the available ESX hosts in a round-robin order, to distribute the potential load as evenly as possible. SRM always uses DRS placement to balance the load intelligently across hosts before it powers on recovered virtual machines on the recovery site, even if DRS is disabled on the cluster. If DRS is enabled and in fully automatic mode, DRS might move other virtual machines to further balance the load across the cluster while SRM is powering on the recovered virtual machines, and DRS will continue to balance all virtual machines across the cluster after SRM has powered on the recovered virtual machines.

Test Bubble Networks and Datacenter Networks

SRM can create a test bubble network to which recovered virtual machines are connected during a test. SRM defaults to the Auto setting so that an accidental test recovery does not affect production. This network is managed by its own virtual switch, and in most cases recovered virtual machines can use it without having to change network properties such as IP address, gateway, and so on. A datacenter network, in contrast, is one that typically supports existing virtual machines at the recovery site. To use it, recovered virtual machines must conform to its network address availability rules. These virtual machines must use a network address that can be served and routed by the network's switch, must be configured to use the correct gateway and DNS host, and so on. Recovered virtual machines that use DHCP can connect to this network without additional customization. Others require IP customization and recovery plan steps that apply the customization.

Virtual machines that must interact with each other should be failed over to the same test bubble network. For example, if a Web server accesses information on a database, those virtual machines should fail over together to the same network. This step enables testing of the function of the failed over virtual machines.

VMware, Inc. 15

Site Recovery Manager Administration Guide

About Reprotect

With reprotect, you can protect recovered virtual machines after a recovery back to the original protected site, including reversing the direction of replication.

Reprotect uses the protection information that was established before a recovery to reverse the direction of protection. You can complete the Reprotect process after a recovery is finished. If the recovery finishes with errors, you must fix all errors and rerun the recovery, repeating this process until no errors occur.

IMPORTANT Reprotect is supported only for array-based replication. vSphere Replication (VR) reprotect is not supported. If a recovery plan contains VR groups, remove those groups before you run a reprotect operation.

About Failback

A failback is an optional procedure that restores the original configuration of the protected and recovery sites after a recovery. You can configure and run a failback procedure when you are ready to restore services to the protected site.

Failback is a term for a collection of procedures that you can use to restore the original configuration of the protected and recovery sites after a recovery. Anytime errors occur during a failback, you must resolve those errors and repeat the failback until the process completes successfully.

After a recovery has occurred, a failback can be completed. Failbacks have three phases. For example, at the start, A is the protected site and B is the recovery site. A recovery occurs, migrating the virtual machines to site B. You might choose to run a failback. At that point, the following phases occur:

Perform a reprotect. The former recovery site, B, is made the protected site and information about protection is used to establish protection with A being the recovery site.

Perform a planned migration. The virtual machines are recovered to site A. To avoid interruptions in virtual machine availability, you may want to run a test before actually completing the planned migration. If errors are identified by the test, these issues can be resolved before actually performing the planned migration.

Perform a second reprotect, this time with site A being protected with site B as the recovery site.

About the Site Recovery Manager Database

The SRM server requires its own database, which it uses to store data such as recovery plans and inventory information.

The SRM database is a critical part of any SRM installation. The database must be created and a database connection established before you can install SRM. If you are updating SRM to a new release, you can use the existing database connection, but you must back up the database first, otherwise, you will not be able to revert to the previous release of SRM.

The SRM database at each site holds information about virtual machine protection groups and recovery plans. SRM cannot use the vCenter database because it has different database schema requirements, though you can use the vCenter database server to create and support the SRM database. Each SRM site requires its own instance of the SRM database. Before you can install SRM, the database must exist .

When you install SRM, you specify the following information about how SRM connects to the database.

Server Type

DSN

16 VMware, Inc.

The type of database server being used.

The DSN (database source name) specifies a data structure that contains information about the SRM database that the ODBC driver needs to connect to that data source.

Chapter 1 Administering VMware vCenter Site Recovery Manager

User Name and Password

Connection Count

Max Connections

This authentication information is required so that SRM can use the database.

The initial connection pool size. If all connections are in use and a new one is needed, a connection is created as long as it does not exceed the maximum number of connections allowed. It is faster for SRM to use a connection from the pool than to create a new one. In most cases, it is not necessary to change this setting. Before changing this setting consult with your database administrator.

The maximum number of connections to open to the database at one time. If the database administrator has restricted the number of connections that the database can have open, this value cannot exceed that number. In most cases, it is not necessary to change this setting. Before changing this setting consult with your database administrator.

SRM and VMware vCenter Server

The SRM server operates as an extension to the vCenter Server at a site. Because the SRM server depends on vCenter Server for some services, you must install and configure vCenter Server at a site before you install SRM.

SRM takes advantage of vCenter services, such as storage management, authentication, authorization, and guest customization. SRM also uses the standard set of vSphere administrative tools to manage these services.

How Changes to vCenter Server Inventory Affect SRM

Because SRM protection groups apply to a subset of vCenter inventory, changes to the protected inventory made by vCenter administrators and users can affect the integrity of SRM protection and recovery. SRM depends on the availability of certain objects, such as virtual machines, folders, resource pools, and networks, in the vCenter inventory at the protected and recovery sites. Deletion of resources such as folders or networks that are referenced by recovery plans can invalidate the plan. Renaming or relocating objects in the vCenter inventory does not affect SRM, unless it causes resources to become inaccessible during test or recovery.

SRM can tolerate the following changes at the protected site without disruption:

Deleting protected virtual machines.

Deleting an object for which an inventory mapping exists.

SRM can tolerate the following changes at the recovery site without disruption:

Moving placeholder virtual machines to a different folder or resource pool.

Deleting an object for which an inventory map exists.

SRM and the vCenter Database

If you update the vCenter installation that SRM extends, do not reinitialize the vCenter database during the update. SRM stores identification information about all vCenter objects in SRM's database. If you reinitialize the vCenter database, the identification data that SRM has stored no longer matches identification information in the new vCenter and objects are not found.

VMware, Inc. 17

Site Recovery Manager Administration Guide

SRM and Other vCenter Server Solutions

You can run other VMware solutions such as vCenter Update Manager, vCenter Server Heartbeat, VMware Fault Tolerance, and vCenter CapacityIQ in deployments that you protect using SRM. However, use caution before connecting other VMware solutions to the vCenter Server instance to which the SRM server is connected. Connecting other VMware solutions to the same vCenter Server instance as SRM might cause problems when you upgrade SRM or vSphere. Check the compatibility and interoperability of these solutions with SRM before you deploy them.

SRM Licensing

The SRM server requires a license key to operate. You install each SRM server with an evaluation license that is valid for 60 days and supports protecting up to 75 virtual machines.

SRM uses the vSphere licensing infrastructure for license management. Additionally, vSphere needs to be licensed sufficiently for SRM to protect and recover virtual machines.

After the evaluation license expires, existing protection groups remain protected and can be recovered, but you cannot create new protection groups or modify existing ones until you obtain and assign a valid SRM license key. VMware recommends that you obtain and assign SRM license keys as soon as possible after installing SRM. You can obtain a license key from your VMware sales representative.

How License Keys Apply to Protected and Recovery Sites

SRM requires a license key that specifies the maximum number of protected virtual machines at a site. Larger licenses are often required when protecting large numbers of virtual machines.

Install keys at one site to enable failover.

Install keys at both sites to enable bidirectional operation including reprotection.

If your SRM Servers are connected with linked vCenter Servers, the SRM servers can share the same license key.

To obtain your license keys, go to the VMware Product Licensing Center (http://www.vmware.com/support/licensing/index.html).

SRM licensing checks for a valid license whenever you add a virtual machine to or remove a virtual machine from a protection group. If licenses are not in compliance, vSphere triggers a licensing alarm. VMware recommends that you configure alerts for triggered licensing events so that licensing administrators are notified by email.

SRM Authentication

All communications between SRM and vCenter Servers take place over a SSL connections and are authenticated by public key certificates or stored credentials.

When you install an SRM server, you must choose either credential-based authentication or certificate-based authentication. You cannot mix authentication methods between SRM servers at different sites and between SRM and vCenter. By default, SRM uses credential-based authentication, but certificate-based authentication can alternatively be selected. The authentication method you choose when installing the SRM server is used to authenticate connections between the SRM servers at the protected and recovery sites, and between SRM and vCenter.

18 VMware, Inc.

Chapter 1 Administering VMware vCenter Site Recovery Manager

Certificate-Based Authentication

If you have or can acquire a PKCS#12 certificate signed by a trusted authority, use certificate-based authentication. Public key certificates signed by a trusted authority streamline many SRM operations and provide the highest level of security. Certificates used by SRM have special requirements. See “Requirements

When Using Public Key Certificates,” on page 19.

Credential-Based Authentication

If you are using credential-based authentication, SRM stores a user name and password that you specify during installation, and then uses those credentials when connecting to vCenter. SRM also creates a special-purpose certificate for its own use. This certificate includes additional information that you supply during installation. That information, an Organization name and Organization Unit name, must be identical for both members of an SRM server pair.

NOTE Even though SRM creates and uses this special-purpose certificate when you choose credential-based authentication, credential-based authentication is not equivalent to certificate-based authentication in either security or operational simplicity.

Certificate Warnings

If you are using credential-based authentication, attempts by the SRM server to connect to vCenter produce a certificate warning because the trust relationship asserted by the special-purpose certificates created by SRM and vCenter cannot be verified by SSL. A warning allows you to verify the thumbprint of the certificate used by the other server and confirm its identity. To avoid these warnings, use certificate-based authentication and obtain your certificate from a trusted certificate authority.

Requirements When Using Public Key Certificates

If you installed SSL certificates issued by a trusted certificate authority (CA) on the vCenter Server that supports SRM, the certificates you create for use by SRM must meet specific criteria.

While SRM uses standard PKCS#12 certificate for authentication, it places a few specific requirements on the contents of certain fields of those certificates. These requirements apply to the certificates used by both members of an SRM server pair (the protected site and the recovery site).

The certificates must have a Subject Name value constructed from the following componants.

A Common Name (CN) attribute, whose value must be the same for both members of the pair. A string such as "SRM" is appropriate here.

An Organization (O) attribute, whose value must be the same as the value of this attribute in the supporting vCenter Server's certificate.

An Organizational Unit (OU) attribute, whose value must be the same as the value of this attribute in the supporting vCenter Server's certificate.

The certificate used by each member of an SRM server pair must include a Subject Alternative Name attribute whose value is the fully-qualified domain name of the SRM server host. (This value will be different for each member of the SRM server pair.) Because this name is subject to a case-sensitive comparison, use lowercase letters when specifying the name during SRM installation.

If you are using an openssl CA, modify the openssl configuration file to include a line like the following if the SRM server host's fully-qualified domain name is srm1.example.com:

subjectAltName = DNS: srm1.example.com

If you are using a Microsoft CA, refer to http://support.microsoft.com/kb/931351 for information on how to set the Subject Alternative Name.

VMware, Inc. 19

Site Recovery Manager Administration Guide

The certificate used by each member of an SRM server pair must include an extendedKeyUsage or

enhancedKeyUsage attribute whose value is serverAuth, clientAuth. If you are using an openssl CA,

modify the openssl configuration file to include a line like the following:

extendedKeyUsage = serverAuth, clientAuth

The SRM certificate password must not exceed 31 characters.

Understanding Roles and Permissions

SRM provides disaster recovery by performing operations on behalf of users. These operations involve managing objects, such as recovery plans or protection groups, and performing operations, such as replicating or powering off virtual machines. SRM must be able to complete these tasks, when appropriate, and refuse to complete operations when they are not authorized. To achieve this goal, SRM uses permissions and roles.

the following are key terms related to permissions and roles.

Privilege

The right to perform an action. Examples of privileges include creating a recovery plan or modifying a protection group.

Role

A collection of privileges. Default roles are designed to provide the privileges associated with some user role such as users who will manage protection groups or complete recoveries.

Permissions

A role granted to a particular user or group (also known as a principal) on some object. A permission is the intersection of role, object, and principal.

A permission is the intersection of a privilege and an object. For example, the privilege to modify a protection group as it applies to a specific protection group in the inventory.

SRM determines if the operation is permitted when protection is configured, rather than at the time the operation is to be completed. After SRM verifies that the appropriate permissions are assigned on vSphere resources, future actions are carried out on behalf of users by SRM using the vSphere administrator context.

For configuration operations, user permissions are validated when the operation is requested. Other operations require two phases of validation.

1 During configuration, SRM verifies that the user configuring the system has the required permissions to

complete the configuration on the vCenter object. For example, a user must have permission to protect a virtual machine and use resources on a secondary vCenter Server that the recovered virtual machine would use.

2 The user executing the configuration must have permissions to complete the task. For example, a user

must have permissions to execute a recovery plan. The task is then completed in the administrative context.

As a result, a user who completes a particular task, such as a failover, does not have to have permissions to act on vSphere resources. The action is authorized by the role, but is completed by SRM acting as an administrator. These operations are carried out using the administrator credentials provided during site pairing.

SRM maintains a database of permissions for internal SRM objects using a model similar to the one used by vCenter Servers. SRM verifies its own SRM privileges even on vCenter objects. For example, SRM checks for Recovery Use permission on the target datastore rather than multiple low-level permissions, such as Allocate space.

20 VMware, Inc.

Chapter 1 Administering VMware vCenter Site Recovery Manager

Assign Roles and Permissions

Permission assignments apply on a per-site basis. After installation only vCenter Administrators can log into SRM. To allow other users access, vCenter Administrators must grant them permissions in the SRM UI. You must add corresponding permission on both sites.

SRM requires permissions on vCenter objects as well as SRM objects. To configure permissions on the remote vCenter installation, start another instance of vSphere Client. You can change SRM permissions from the same UI on both sites after pairing. SRM augments vCenter roles and permissions with additional ones that allow detailed control over SRM specific tasks and operations. You can use the SRM Assign Permissions window the same way that you use the Assign Permissions window in the vSphere Client.

Procedure

1 Click Sites, and select the site for which you want to assign permissions.

2 Click the Permissions tab.

3 Right-click one of the items and click Add Permission.

4 Select a role from the Assigned Role drop-down menu.

This menu displays all the roles that are available from SRM and vCenter. When the role appears, the privileges granted to the role are listed in the section below the role title.

5 Select Propagate to Child Objects to apply the selected role to all child objects of the selected inventory

object.

6 Click the Add button.

7 Identify a user or group for the role.

a From the Domain drop-down menu, select the domain where the user or group is located.

b Either enter a name in the Search text box or select a name from the Name list.

c Click Add and click OK.

8 Click OK to finish the task.

The list of permissions references all users and groups that have roles assigned to the object and where in the hierarchy those roles are assigned.

What to do next

Repeat the procedure to assign roles and permissions to users at the recovery site.

SRM Roles Reference

SRM includes a set of roles. Each role is assigned a set of privileges, which enable the completion of actions.

Roles may have overlapping sets of privileges and actions. For example, both the SRM Administrator role and the SRM Protection Groups Administrator have the Create privilege for protection groups for Site Recovery Manager. This privilege enables them to complete one aspect of the set of tasks that make up managing protection groups.

The complete list of roles, the privileges granted to those roles, and the actions associated with those privileges are described in the following table.

VMware, Inc. 21

Site Recovery Manager Administration Guide

Table 1-2. SRM Roles

Role Privilege Action

SRM Administrator Site Recovery Manager > Advanced

Settings > Modify

Site Recovery Manager > Array Manager > Configure

Site Recovery Manager > Diagnostics > Export

Site Recovery Manager > Inventory Preferences > Modify

Site Recovery Manager > Placeholder Datastores > Configure

Site Recovery Manager > Protection Group > Assign to Plan

Site Recovery Manager > Protection Group > Create

Site Recovery Manager > Protection Group > Modify

Site Recovery Manager > Protection Group > Remove

Site Recovery Manager > Protection Group > Remove from Plan

Site Recovery Manager > Recovery History > View Deleted

Site Recovery Manager > Recovery History > Plans

Site Recovery Manager > Recovery Plan > Configure

Site Recovery Manager > Recovery Plan > commands

Site Recovery Manager > Recovery Plan > Create

Site Recovery Manager > Recovery Plan > Modify

Site Recovery Manager > Recovery Plan > Remove

Site Recovery Manager > Recovery Plan > Reprotect

Site Recovery Manager > Recovery Plan > Test

Site Recovery Manager > Remote Site > Modify

Virtual Machine > Replication > Protect

Virtual Machine > Replication > Stop

SRM Protection Groups Administrator Site Recovery Manager > Protection

Group > Create

Site Recovery Manager > Protection Group > Modify

Site Recovery Manager > Protection Group > Remove

Virtual Machine > Replication > Protect

Virtual Machine > Replication > Stop

Configure advanced settings

Configure connections

Configure inventory preferences

Configure placeholder datastores

Configure array managers

Manage protection groups

Manage recovery plans

Protect virtual machines

Edit protection groups

Remove protection groups

Manage protection groups

Protect virtual machines

22 VMware, Inc.

Chapter 1 Administering VMware vCenter Site Recovery Manager

Table 1-2. SRM Roles (Continued)

Role Privilege Action

SRM Recovery Plans Administrator Site Recovery Manager > Protection

SRM Test Administrator Site Recovery Manager > Recovery

SRM Network Ports

SRM servers use several network ports to communicate with each other, with client plug-ins, and with vCenter. If any of these ports are in use by other applications or are blocked on your network, you must reconfigure SRM to use different ones.

Group > Assign to Plan

Site Recovery Manager > Protection Group > Remove from Plan

Site Recovery Manager > Recovery Plan > Configure

Site Recovery Manager > Recovery Plan > Commands

Site Recovery Manager > Recovery Plan > Create

Site Recovery Manager > Recovery Plan > Modify

Site Recovery Manager > Recovery Plan > Remove

Site Recovery Manager > Recovery Plan > Test

Resource > Recovery Use

plan > Modify

Site Recovery Manager > Recovery plan > Test

Manage recovery plans

Add protection groups to recovery plans

Test recovery plans

Cancel recovery plan test

Edit virtual machine recovery properties

Test recovery plans

Cancel recovery plans test

Edit virtual machine recovery properties

Table 1-3 lists the default network ports the SRM uses for intrasite (between hosts at a single site) and intersite

(between hosts at the protected and recovery sites) communications. You can change these defaults when you install SRM. Beyond these standard ports, you must also ensure the following requirements.

vSphere Replication (VR) Servers and SRM servers have NFC traffic access to target ESX servers.

Any network requirements of your particular array-based replication are met.

Table 1-3. SRM Network Ports

Default Port Protocol or Description Endpoints or Consumers

80 All traffic to SRM servers through the

vCenter Server proxy.

8095 SOAP SRM server and vCenter Server

(intrasite only). This port must be accessible from the vCenter Server proxy system.

9085 HTTP vCenter Server (for plug-in download).

This port must be accessible from the vCenter Server proxy system.

9007 SOAP Used by external API clients for task

automation.

VMware, Inc. 23

Site Recovery Manager Administration Guide

Table 1-4. How VRMS Uses Network Ports

Default Port Protocol or Description Endpoints or Consumers

80 All traffic to SRM servers through the

8043 SOAP VRM and the vCenter Server proxy.

8080 VAMI Web UI Administrator's web browser.

Table 1-5. How VR Servers Use Network Ports

Default Port Protocol or Description Endpoints or Consumers

8123 SOAP Management traffic used by VRMS to

5480 VAMI Web UI Administrator's web browser.

31031 Initial replication traffic From the ESX host at the protected site

44046 Ongoing replication traffic From the ESX host at the protected site

Connecting to SRM

Use the vSphere Client to connect to and manage SRM. Ensure you connect using an account that has been paired with a role that has the necessary permissions.

SRM does not require that you connect to a specific SRM site in an SRM deployment. Changes can be made to the protected and recovery sites by connecting to a vCenter Server at either site. Completing administrative tasks on a SRM deployment begins with the following steps:

vCenter Server proxy.

manage the VR Servers.

to the VR appliance at recovery site.

Procedure

1 Open a vSphere Client and connect to the vCenter Server for either the protected or recovery site.

If sites are not paired, you must select the system to which to connect.

If sites are paired, you must provide the user name and password for both sites.

2 On the vSphere Client Home page, click the Site Recovery icon.

Once you have clicked the Site Recovery icon, complete the steps prescribed for the particular administrative task.

SRM adds several roles, each of which include permissions for completing SRM tasks. You can pair users with these particular roles, enabling them to complete tasks. For more information about the roles that SRM adds and the privileges required to complete tasks, see “SRM Roles Reference,” on page 21.

Operational Limits of Site Recovery Manager

Each SRM server can support up to a certain number of virtual machines, protection groups, datastore groups, vSphere Replication Management Server (VRMS) instances per host, and vSphere Replication Servers (VRS) servers per VRMS.

You can run one SRM Server per vCenter Server instance.

The limits for replicated datastore groups and running recovery plans are suggested and not enforced.

24 VMware, Inc.

Chapter 1 Administering VMware vCenter Site Recovery Manager

Table 1-6. SRM Protection Limits for Array Based Protection

Item Maximum

Protected virtual machines per protection group 500

Protected virtual machines 1000

Protection groups per recovery plan 150

Datastore groups 150

Concurrent recoveries 10

Table 1-7. SRM Protection Limits for vSphere Replication Protection

Item Maximum

Protected virtual machines per protection group 500

Protected virtual machines 500

Protection groups per recovery plan 250

Datastore groups 250

Concurrent recoveries 10

Table 1-8. SRM Deployment Limits for vSphere Replication

Item Maximum

vSphere Replication Management Server (VRMS) appliances per vCenter Server instance

vSphere Replication Server (VRS) appliances registered to a VRMS appliance

Virtual machine replication schedules per VRS appliance 100

VMware recommends that you never use SRM to protect Active Directory domain controllers. Active Directory provides its own replication technology and restore mode, and these technologies can be used to handle disaster recovery situations.

VMware, Inc. 25

Site Recovery Manager Administration Guide

26 VMware, Inc.

Installing and Updating Site Recovery

Manager 2

You must install an SRM server at the protected site and also at the recovery site. After the SRM servers are installed, you can download the SRM client plug-in from either SRM server using the Manage Plugins menu from your vSphere Client. You use the SRM client plug-in to configure and manage SRM at each site.

Prerequisites

SRM requires that a vCenter Server be installed at each site prior to installing SRM. The SRM installer must be able to connect with this server during installation. VMware recommends installing SRM on a system that is different from the system where vCenter Server is installed. If SRM and vCenter Server are installed on the same system, administrative tasks might become more difficult to perform. If you are upgrading SRM, only protection groups and recovery plans that are in a valid state are saved during the upgrade. Protection groups or recovery plans that are in an invalid state are discarded.

The system on which SRM is installed has the following hardware requirements:

Processor – 2.0GHz or higher Intel or AMD x86 processor

Memory – 2GB minimum

Disk Storage – 5GB minimum

Networking – Gigabit recommended

For current information about supported platforms and databases, see the Site Recovery Manager Compatibility Matrixes, at http://www.vmware.com/support/pubs/srm_pubs.html.

This chapter includes the following topics:

“Configuring the SRM Database,” on page 28

“About the vSphere Replication Management Database,” on page 29

“Install the SRM Server,” on page 31

“Upgrading SRM,” on page 33

“Install Storage Replication Adapters,” on page 38

“Install the SRM Client Plug-In,” on page 38

“Connect the Sites,” on page 39

“Revert to a Previous Release,” on page 40

“Repair or Modify the Installation of a Site Recovery Manager Server,” on page 40

“Install the SRM License Key,” on page 42

VMware, Inc.

Site Recovery Manager Administration Guide

Configuring the SRM Database

Each SRM server requires its own database to store recovery plans, inventory information, and similar data. Before installing the SRM server, you must configure and initialize the SRM database.

If you are updating SRM to a new release, you can use the existing database. Before attempting an SRM environment upgrade, ensure both SRM server databases are backed up. This helps ensure you can revert after the upgrade, if required.

SRM cannot use the vCenter database because it has different database schema requirements, though you can use the vCenter database server to create and support the SRM database. Each SRM site requires its own instance of the SRM database. The database must exist before SRM can be installed.

NOTE If you reinitialize the database after you install SRM, you must run the SRM installer in maintenance mode and specify a new database connection.

Microsoft SQL Server Configuration

A Microsoft SQL Server configuration must meet specific requirements to support SRM.

SRM requires that the Microsoft SQL Server must have a 32-bit DSN. Microsoft SQL Server has the following configuration requirements when used as the SRM database.

The database schema has three requirements:

It must be owned by the SRM database user (the database user name you supply when configuring the SRM database connection).

It must be the default schema for the SRM database user.

The DB schema name must be the same as the DB user name.

You must grant the SRM database user the following permissions:

bulk insert

connect

create table

If you are using Windows authentication, the database user account must be the same user account that you use to run the SRM service.

If you are using SQL Authentication, you can leave the default local System user.

If the SRM server and database server run on different hosts, you must use mixed mode authentication.

If SQL Server is installed locally, you might need to disable the Shared Memory network setting on the database server.

Oracle Server Configuration

An Oracle Server configuration must meet specific requirements to support SRM.

Oracle Server has the following configuration requirements when used as the SRM database.

When creating the database instance, specify utf-8 encoding.

You must grant the following permissions to the SRM database user (the database user name you supply when configuring the SRM database connection):

connect

resource

28 VMware, Inc.

Chapter 2 Installing and Updating Site Recovery Manager

create session

DB2 Server Configuration

A DB2 Server configuration must meet specific requirements to support SRM.

DB2 Server has the following configuration requirements when used as the SRM database:

When creating the database instance, specify utf-8 encoding.

Because DB2 uses Windows authentication, specify the database owner as a domain account.

About the vSphere Replication Management Database

To use vSphere Replication with SRM, you will need vSphere Replication Management (VRM) Servers. Each VRM Server requires its own database, separate from the SRM database.

The vSphere Replication Management (VRM) database is a critical part of any VRM installation. The database schema must be created before you can install VRM.

VRM cannot use the vCenter database because it has different database schema requirements, although you can use the vCenter database server to create and support the VRM database. Each VRM site requires its own instance of the VRM database. The database must exist before you can install VRM . If the VRM database at either site becomes corrupted, the VRM servers at both sites will shut down.

Configure the VRM Database

You must configure the vSphere Replication Management (VRM) database to enable VRM and vSphere Replication (VR).

To configure the common VRM Server (VRMS) database properties you have to go to the VRMS VAMI (Virtual Appliance Management Interface) by navigating your browser to the VRMS URL and port number, which is

8080. Alternately you can navigate to the VRMS VAMI by clicking on the Configure VRM Server link available in the SRM UI. You must configure each VRMS site separately. If you reinitialize the database after you deploy VRMS, you must go to the VRMS VAMI to re-setup the VRM to use the new database connection.

Common Database Configurations

Common database properties include the following.

DB Type: Choose one of the supported database types.

Microsoft SQL Server

Oracle Server

DB2 Server

DB Host: The database server URL.

DB Port: When you select your database type a default port value will be suggested. You can keep it or change it to match your database server configuration.

DB Username: The VRM database user.

DB Password: The VRM database user password.

DB Name: The VRM database schema name. Create the schema name in advance.

DB URL: This URL is auto-generated and hidden by default. Advanced users might want to fine-tune other database properties.

VMware, Inc. 29

Site Recovery Manager Administration Guide

Microsoft SQL Server Configuration

A Microsoft SQL Server configuration must meet specific requirements to support VRM. You must configure these requirements in Microsoft SQL Server.

You can use either a named instance or the default instance of SQL Server.

Enable TCP on the database instance.

Use a static TCP port, for example set to the default of 1433. Alternatively, to use dynamic TCP ports, you must perform additional configuration.

Use a named instance of SQL Server rather than the default instance. You can only use dynamic ports with a named instance of SQL Server.

In the DB URL in the VRMS configuration interface, replace port=

instanceName=

Verify that the SQL Server Browser service is running.

The SQL Server Browser runs on port 1434. Use the PortQuery tool from a remote machine to check that the port on which the SQL Server Browser service runs is not blocked by a firewall.

instance_name

port_number

with

PortQry.exe -n

Because the VRMS and the database server run on different hosts, you must use mixed mode

Machine_Name

-p UDP -e 1434

authentication and not Windows Authentication.

The VRM database requires a security login with SQL Server Authentication.

The VRM database login must be the database owner.

Because it is the database owner, the login maps to the database user dbo and uses the dbo schema. Keep the dbo user and dbo schema settings.

The VRM database user must have database administrator privileges.

The VRM database user must have the following permissions:

bulk insert

connect

create table

create view

Oracle Server Configuration

An Oracle Server configuration must meet specific requirements to support VRM. Oracle Server has the following configuration requirements when used as the VRM database.

When creating the database instance, specify utf-8 encoding.

The VRM database user (the database user name you supply when configuring the SRM database connection) must be granted the following permissions:

connect

resource

create session

create view

30 VMware, Inc.

+ 78 hidden pages