Attempting to configure VMware SRM (Site Recovery Manager) Protection Group fails with: "... due to unresolved devices"

Problem

You attempt to configure a new VMware SRM protection group but receive the following error:

ERROR

Operation Failed Task completed with error CompositeException Unable to protect VM '<virtualMachineName>' due to unresolved devices Unable to protect VM '<virtualMachineName>’ due to unresolved devices Unable to protect VM '<virtualMachineName>' due to unresolved devices

Operation ID: 33a8561f-c6b5-4868-b2f7-01453d762ad6

Solution

This error is usually thrown due to components of SRM not being completely configured. The following are a few common items:

1. Network Mappings
2. Folder Mappings
3. Resource Mappings

There will be times when the administrator has configured the mappings the configuration in the mapping may not be correct and the best way to identify exactly what is preventing the protection group from being configured is to navigate to the Virtual Machines tab and review the Protection Status output, which would explicitly display the problem. In the case of this example, the network mappings were configured but various port groups and cluster mapping for these VMs were not configured:

The configuration for the Protection Groups should successfully complete once the missing mappings are configured:

Deploying VMware SRM (Site Recovery Manager) 8.1.1 with vSphere vCenter Server 6.5

It has been a while since I’ve deployed SRM (VMware Site Recovery Manager) and since I recently had the opportunity to do so at a client, I took a few screenshots during the process to write this blog post that demonstrates the process.

Prerequisites

Before you begin, make sure you use the VMware Product Interoperability Matrices to verify that the vCenter Server, vSphere Replication Appliance (if you’re using it for replication), and VMware Site Recovery Manger versions are supported:

VMware Product Interoperability Matrices
https://www.vmware.com/resources/compatibility/sim/interop_matrix.php

Deployment

The official deployment guide can be found at the following URL:

Install Site Recovery Manager Server
https://docs.vmware.com/en/Site-Recovery-Manager/8.1/com.vmware.srm.install_config.doc/GUID-723EAC1B-AC21-4CAA-9867-627CA8CB680A.html

Begin by downloading the installation file and then run the install:

Select appropriate drive or destination folder you would like to use:

Enter the information for the PSC (Platform Services Controller) for the site this SRM will be deployed in and an administrative account. Note that the administrator account is going to be used for creating the Site Recovery Manager solution user so you can use any account with administrative privileges:

Accept the PSC’s certificate if it a trusted certificate was not installed:

Select the appropriate vCenter that this SRM will register with:

Enter the appropriate values for the configuration below:

Unless you are going to use a custom Site Recovery Manger Plug-in, proceed with the Default option:

If there is a certificate issued for this deployment then select the second option, otherwise, generate one with the first option:

Fill in the information for the new certificate if one is being generated:

The default option for the Database Server Selection step is to use a custom server with a Data Source already configured. Older SRM version used to only support databases such as Microsoft SQL, Oracle, DB2 (https://pubs.vmware.com/srm-51/index.jsp?topic=%2Fcom.vmware.srm.install_config.doc%2FGUID-84218C7E-3242-4A33-A771-71F944850319.html) so it was a requirement to have a DSN already configured but newer versions of SRM provide the option of using an embedded PostgreSQL database so for the purpose of this demonstration, we’ll use the embedded option:

Provide a Data Source Name which will be used to setup the DSN on the Windows server, a database user name for accessing the database, and a password:

Select whether to use a Local System account or a service account:

Proceed with the install:

Note the following 2 new items after the successful install of SRM:

Also note the new Roles created for SRM in vCenter:

A new user would user with a GUID will also be created:

Clicking on the Site Recovery view should now display the Site Recovery manager component:

There are times when it will be necessary to log off and back on to allow the SRM plugin loads properly so if the above items are not displayed, try relogging on.

Clicking the OPEN Site Recovery button will launch a separate window for the Site Recovery console:

Proceed with deploying the other SRM site and pair them.

Backing up vPostgres Database

Below is a demonstration of how to backup the vPostgres Database.

The VMware official guide can be found here:

Back Up and Restore the Embedded vPostgres Database
https://docs.vmware.com/en/Site-Recovery-Manager/5.8/com.vmware.srm.install_config.doc/GUID-E1FC67CD-48E3-4B25-AA1D-8A2408F5B517.html

All of the vPostgres executables are located in the following directory:

C:\Program Files\VMware\VMware vCenter Site Recovery Manager Embedded Database\bin

The following is the syntax to backup the database:

pg_dump -Fc --host 127.0.0.1 --port port_number --username=db_username srm_db > srm_backup_name

If you had forgotten the parameters used for the deployment, you can retrieve them from the ODBC Data Source Administrator console as shown here:

Note that the install does not allow changing the database name so it will always be srm_db.

The following is an example of the backup command:

pg_dump -Fc --host 127.0.0.1 --port 5678 --username=administrator srm_db > SRM-Backup

A backup should be placed in the same directory as the pg-dump.exe executable:

VMware vCenter Site Recovery Manager 5.5.1.8569 service starts and stops

Problem

You’ve noticed that VMware vCenter Site Recovery Manager Server service briefly starts and then stops:

The System event logs has the following error entry:

Log Name: System

Source: Service Control Manager

Event ID: 7034

Level: Error

The VMware vCenter Site Recovery Manager Server service terminated unexpectedly. It has done this 3 time(s).

Reviewing the SRM latest log in the folder:

C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\Logs\

… reveals the following entry:

Section for VMware vCenter Site Recovery Manager, pid=5092, version=5.5.1, build=1647061, option=Release
2018-10-24T14:49:07.083+01:00 [03480 info 'Default'] Logging uses fast path: false
2018-10-24T14:49:07.083+01:00 [03480 info 'Default'] Handling bora/lib logs with VmaCore facilities
2018-10-24T14:49:07.083+01:00 [03480 info 'Default'] Initialized channel manager
2018-10-24T14:49:07.083+01:00 [03480 info 'Default'] Current working directory: C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin
2018-10-24T14:49:07.083+01:00 [03480 verbose 'Default'] Setting COM threading model to MTA
2018-10-24T14:49:07.083+01:00 [03480 info 'Default'] ThreadPool windowsStackImmediateCommit = true
2018-10-24T14:49:07.083+01:00 [03480 info 'ThreadPool'] Thread pool on asio: Min Io, Max Io, Min Task, Max Task, Max Concurency: 2, 401, 2, 200, 2147483647
2018-10-24T14:49:07.083+01:00 [03480 info 'ThreadPool'] Thread enlisted
2018-10-24T14:49:07.083+01:00 [03480 info 'Default'] Set dump dir to 'C:\ProgramData\VMware\VMware vCenter Site Recovery Manager\DumpFiles'
2018-10-24T14:49:07.083+01:00 [04204 info 'ThreadPool'] Thread enlisted
2018-10-24T14:49:07.083+01:00 [04684 info 'ThreadPool'] Thread enlisted
2018-10-24T14:49:07.083+01:00 [03652 info 'ThreadPool'] Thread enlisted
2018-10-24T14:49:07.083+01:00 [00496 info 'ThreadPool'] Thread enlisted
2018-10-24T14:49:07.177+01:00 [03480 info 'Default'] Vmacore::InitSSL: handshakeTimeoutUs = 20000000
2018-10-24T14:49:07.239+01:00 [03480 error 'Default'] Certificate has expired.
2018-10-24T14:49:07.270+01:00 [03480 verbose 'HttpConnectionPool-000000'] HttpConnectionPoolImpl created. maxPoolConnections = 200; idleTimeout = 900000000; maxOpenConnections = 50; maxConnectionAge = 0
2018-10-24T14:49:07.317+01:00 [03652 verbose 'Default'] Local and remote versions are the same.  Talking with version vim.version.version9
2018-10-24T14:49:07.426+01:00 [03480 info 'Default'] VC Connection: Logging in extension by subject name
2018-10-24T14:49:07.426+01:00 [03480 info 'vmomi.soapStub[0]'] Resetting stub adapter for server <cs p:00000000041821b0, TCP:vcenter03.contoso.com:80> : Closed
2018-10-24T14:49:07.442+01:00 [03480 error 'Default'] VC server does not trust our client certificate.
2018-10-24T14:49:07.520+01:00 [00496 info 'ThreadPool'] Thread delisted
2018-10-24T14:49:07.520+01:00 [03652 info 'ThreadPool'] Thread delisted
2018-10-24T14:49:07.520+01:00 [04684 info 'ThreadPool'] Thread delisted
2018-10-24T14:49:07.520+01:00 [04204 info 'ThreadPool'] Thread delisted

Solution

As indicated in the log file above, the certificate that SRM uses for communication with vCenter has expired.  This can be confirmed by launching the certificate console and reviewing the properties of the certificate used by SRM.

To correct this issue, simply renew the certificate and update SRM to use the certificate by using the Change option in Programs and Features:

Select the Modify option:

You will need the service account you use to connect to the vCenter server:

The Automatically generate a certificate. option will generate a self-signed certificate.  For this example, I have generated a certificate with an internal Enterprise CA so I’ll be selecting Use a PKCS#12 certificate file.:

**Note that the bottom indicates the Installed certificate status: Certificate has expired.

Proceed and enter the SRM database information in the wizard:

Select the Use existing database. option:

Continue by clicking Install to apply the changes:

--------------------------------------------------------------------------------------------------------------------------------------------------------

A few items worth mentioning for the certificate are:

• You can export a certificate as a PFX format the rename it to have the .p12 extension for importing it in the wizard.
• The requirements for the certificate may not be what you typically anticipate (e.g. you need the IP address in it for some reason) so refer to the following KB and carefully read the requirements (https://kb.vmware.com/s/article/2085644).  The following are a few prompts that you may receive if the certificate being used does not meet the requirements:

Failed to validate certificate.

Details:

The certificate does not contain the SRM hots name. SRM server certificates must contain the SRM host name in the Subject Alternative Name field.

Failed to validate certificate.

Details:

The host name (somehostName.domain.com) in the Subject Alternative Name of the provided certificate does not identically match the SRM host name (10.31.30.12).