Reporting from the Field Part II – Issue #1: SRM 5.8 Network Port Mappings with 18+ Portgroups


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.

Print

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:

SRM 5.8 Bug

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:

ProtectionPlan

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:

OrchestratorPlugin

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.

Upload

Now, let’s go to the WebClient and select the Orchestrator:

OrchestratorWEB

Select Workflows and browse to the SRM folder and expand.

SRMORCH

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.

Login

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.

NetMap

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:

netmapsrm

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.

2 thoughts on “Reporting from the Field Part II – Issue #1: SRM 5.8 Network Port Mappings with 18+ Portgroups

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s