Operational Defect Database
BugZero updated this defect 53 days ago.
Data sources
All data on this page is proprietary to BugZero® or gathered from public sources
VMware | 97140
FAQ: Site Recovery Manager & vSphere Replication Redeployment Guidelines
Last update date:
3/28/2024
Affected products:
vSphere Replication
Site Recovery Manager
Affected releases:
8.x
Fixed releases:
No fixed releases provided.
Description:
Symptoms
You see the below error when a VR appliance in a site pair is missing or deleted. ERROROperation FailedThe object 'MoRef: type = HmsGroup, value = GID-eb3dc220-cc22-4d25-a33d-7b6daeb52d5f, serverGuid = null' has already been deleted or has not been completely created8/19/22, 8:35:56 AM -0500You see the below error when a VR appliance in a site pair is missing or deleted. ERRORServer for guid '2f9b0a5a-3efc-4edc-a8c4-78c1be320c4e' not found, but pair server(s) exist: [PairSetupImpl {_server = HmsServerImpl { _guid = 20838dcb-2f47-4782-a910-0bb2fe163a48 _url = https://vrms.corp.local:8043 }_pairServerGuid = 2f9b0a5a-3efc-4edc-a8c4-78c1be320c4e_pairLsppUrl = https://vrms.corp.local:443/lookupservice/sdk_pairLsppsThumbprint = EA:61:03:8E:E6:21:9F:6B:AB:D3:BB:95:79:BF:F7:83:41:97:1E:EF:31:A6:BA:40:20:FE:F2:68:9E:D6:1C:F2}]Operation ID: 8d39d63e-77e6-468a-8cba-f6683ec00d5011/24/23, 12:59:18 PM -0800You see the below error when vCenter in a site pair is redeployed or deleted. ERRORvCenter Server with GUID '6ad26cb4-3594-45c0-9f02-22a43c9e41b9' not found.Operation ID: 91cc585f-4c2e-4130-b003-461d0b06240c1/19/24, 5:23:02 PM -0300You see the below error when a SRM appliance in a site pair is missing or deleted. ERRORUnable to retrieve Site Recovery Manager summary data.Server with UUID 'b15bf78d-3b12-4eb7-bf3d-fdec017d96cf' not found.Operation ID: 048314a6-d4ba-465c-8c85-35ebbedd66262/17/24, 12:06:39 PM -0500You see the below error when a SRM/VR appliance GUID changes or is offline; can also occur due to redeployment. ERRORUnable to get server with GUID '9230d8d9-b283-42e2-b145-1fac047e9fa6'.Unable to get server with GUID '9230d8d9-b283-42e2-b145-1fac047e9fa6'.Operation ID: 6b30e083-d639-4e64-ba53-da1a8626c6145/22/23, 3:48:23 AM +0800
Purpose
Serves as a guide for any FAQs regarding SRM & VR redeployments.
Resolution
Redeploying Site Recovery Manager (SRM) and vSphere Replication appliances typically depends on several factors, including changes in your infrastructure, upgrades, performance issues, or if you encounter any critical errors. Here are some scenarios where redeploying these appliances might be necessary:1. Infrastructure Changes: If you have made significant changes to your virtual infrastructure, such as upgrading vCenter Server or changing the network configuration, datastore corruption, it might be necessary to redeploy SRM and vSphere Replication appliances to ensure compatibility and proper integration.2. Faulty Appliances: If the appliances are experiencing hardware failures or software corruption that cannot be resolved through troubleshooting, redeploying them might be necessary to restore functionality.3. Upgrades: When upgrades fail or impractical to upgrade from a particular version to the version you intend to upgrade to. Before redeploying SRM and vSphere Replication appliances, make sure to: Backup any critical data or configurations associated with the appliances.Document the current configuration and settings for reference during redeployment.Communicate any planned downtime to relevant stakeholders.Follow VMware's documentation and best practices for redeploying appliances. Overall, the decision to redeploy SRM and vSphere Replication appliances should be based on specific requirements and circumstances within your environment.vCenter Server's Universally Unique Identifier (UUID) changes when its redeployed. This change has varied consequences on additional solutions that interact with it. Site Recovery Manager: SRM appends the UUID to all objects in the protection groups. If vCenter UUID changes, SRM must be rebuilt. vSphere Replication: vSphere Replication also appends the UUID retrieved from vCenter to its objects. If vCenter UUID changes, VRMS must be rebuilt. For context : Site A (Production) <> Site B (Recovery)1. Should I redeploy SRM (Site A) when its partner (Site B) gets redeployed or just unregister and configure the appliance from SRM VAMI ? Unregister and configure the appliance from SRM VAMI.2. Should I redeploy VR (Site A) when its partner (Site B) gets redeployed or just unregister and configure the appliance from VRMS VAMI ? It is mandatory to redeploy VR. Add-on VRs do not have to be redeployed. However, replications on the add-on VRs are removed after VRs are registered to the newly deployed VRMS.NOTE: Unregistering SRM cleans the SRM database while unregistering VR doesn't clean the VR database. 3. What are the repercussions on SRM & VR site pair when vCenter is restored from backup, will it cause site pair issues ? Reconfigure SRM/VRMS to vCenter. You may see errors with network/folder/resource pools/VMs depending on the difference of changes in the last backup. If you find errors under SRM inventory mappings, reconfigure the mapping to fix the mapping errors. If you find errors in VMs under the protection group, reconfigure the protection group to fix the errors.4. I had to redeploy one of my vCenters used with SRM/VR. Can I still use the SRM/VR configuration export belonging to the old vCenter with the redeployed vCenter & SRM/VR (same versions as before) and import this configuration into the new site pair ?Refer to Q6. SRM or VR configuration export belonging to the old vCenter can't be used in this case because vCenter is redeployed. You can do this only when SRM/VR is redeployed. 5. What are the repercussions on SRM & VR site pair when a vCenter is redeployed at either sites ? When a vCenter is redeployed, the SRM/VR pair becomes invalid. All the replications, protection groups & recovery plans also become invalid. Refer to Q6 for more information. 6. Should I redeploy vCenter (Site A) when its partner gets redeployed (Site B) ? No, please read the information below. Scenario 1: vCenter (Site A) is redeployed but the vCenter (Site B) is still in a functional state, then you do the following - A. Redeploy VR and SRM at Site A B. Redeploy VR at Site B C. Unregister and configure SRM at Site B D. Pair the two sites and configure replications, mappings, protection groups, recovery plans, IP customization and other settings from scratch.NOTE: As a thumb rule, you must redeploy VRMS at all the sites when one amongst them gets redeployed. Add-on VRs do not have to be redeployed. However, replications on the add-on VRs are removed after VRs are registered to the newly deployed VRMS.Scenario 2: vCenter (Site B) is redeployed but the vCenter (Site A) is still in a functional state, then you do the following - A. Redeploy VR and SRM at Site B B. Redeploy VR at Site AC. Unregister and configure SRM at Site AD. Pair the two sites and configure replications, mappings, protection groups, recovery plans, IP customization and other settings from scratch.7. Can we import SRM configuration export belonging to an older version of SRM (SRM 8.6, 8.7, etc) into higher versions of SRM (SRM 8.8, 8.9, etc) ? Is there a limit of n-1 versions this can be done between ?Yes, this can be tried & succeeds in most cases. But we don't test all cases. When the import fails, we can check the import log to see which field causes the problem and try to fix it, if possible. NOTE: This also applies to VR but there's no option to export/import VR configuration from UI, but you can use the vr-impex-tool (Please refer to Exporting and Importing Replication Configuration Data )
