I have been working with SRM for quite some time now. It is an excellent product that provides Orchestrated Failover for DR purposes OR planned migration of Workloads, whether it’s for a Data Center Migration or Workload Mobility across Data Centers.
To learn more about the product, you can check out the VMware SRM Product info page here.
Part of the configuration of SRM is to setup your mappings between sites. They include Resource Mappings, Folder Mappings, and Network Mappings. This particular customer had a total of 26 Portgroups in a dvSwitch (Includes Uplink Portgroup). I was ready to move on to setup the Network Mappings with the SRM plugin in the WebClient and a strange thing occurred. When I went to select the PortGroups to Map, it would not list the Portgroups, under the Portgroups heading.
To protect the customer’s information, I am not taking a screenshot of this, rather I took this screenshot from the VMware Blog article to show effect:
A quick search on Google revealed, in fact, there was a bug in SRM 5.8 when using greater than 18 Portgroups either in a Standard or Distributed vSwitch, the Portgroups will not list out and be selectable for mapping.
Please see KB2091459 for more information.
My interest, of course, was in the resolution. VMware has a couple of suggestions, the first being setting up each individual VM Protection within the Protection Groups. As you know, this can be daunting if you are protecting hundreds of VM’s:
The next method is to use vCenter Orchestrator. This is the method that will make sense for most deployments of SRM.
I have written a blog post on how to setup Orchestrator here. You can use this as a guide to install and configure the appliance.
Out of the box, the appliance does not come with the SRM workflows. There is a SRM Orchestrator Plugin that will need to be installed. It’s a very simple process. You can obtain the Plugin here.
Next, open up the Orchestrator Configuration Page by typing this in your browser: https://<your vco ip or fqdn>:8283
Next select the Plugins Tab on the left:
Select the upload button and browse the Plugin file you downloaded earlier and select Upload and Install. After the installation completes you should see the plugin.
Now, let’s go to the WebClient and select the Orchestrator:
Select Workflows and browse to the SRM folder and expand.
Now, the very first Workflow you must run is under Configuration subfolder called Login. This Workflow does exactly that, it logs you into SRM to login into the Site Pair. This is what allows the other workflows to see the remote site and has to be done first.
After the Login Workflow is completed you can move on to Network Mappings. Select and expand the Subfolder Inventory Mappings and right click and Run the Add a Network Mapping Workflow. Here is where you can configure your Network Mappings.
When completed, you can browse to the SRM plugin in the WebClient and select your site. As you can see, now we have network mappings:
Very simple! Orchestrator saves the day. Much better than having to setup the mappings on a Per-VM basis!
In conclusion, we were able to work around the SRM 5.8 bug listed in the KB article outlined earlier in this post using vCenter Orchestrator. I want to make this point very clear, this workaround will address the network mapping issue in the SRM WebClient interface. There isn’t a need to run anything during Failover or testing, this is only setting up the Mappings that couldn’t be configured in the Web Client.
Of course, our Journey with Orchestrator won’t and shouldn’t stop there. This is a tool that can automate many things within the VMware product set. You can even call Orchestrator Workflows through vCAC if that’s your thing. I hope this helps with your SRM 5.8 Deployments.
We did open a Support Case with VMware during this process and i’ve been told (Don’t hold me too it) that a fix to this issue is coming early December timeframe.