Keep SRM From Renaming Datastores on Recovery

VMware Site Recovery Manager is one of the best products in the VMware arsenal.  If you’re using SRM, there have been some welcome changes in recent versions.  One is the sheer magic of automatically resignaturing your datastores, and managing the whole process transparently.

The only problem is, when the datasores fail over, they get renamed like a snapshot would.

 

This might not be a problem for you, since VMware takes care of the vmx, and everything else in the background.  But depending on what you use for backups, not having hte same datastore name could have a huge impact on your recovery.

There used to be an XML file you could change to fix this behavior, but in the 5.x versions, they moved the setting into the GUI.  Just to avoid the pain of poking around trying to find it, I thought I’d throw out a blog post.  There don’t seem to be many out there on this.

All you need to do is right click on the site, and go to Advanced Settings.

Put a check in the box that says storageProvider.fixRecoveredDatastoreNames.

Next time you do a failover, you won’t have the snap prefix on your datastores.  If you still have some residual ones with the wrong name, you will need to rename those manually before doing your next failover.

Limiting vCOps Access to vCenter Resources Using Permissions

If you’ve found your way to this blog post, you have likely already read, or even implemented the VMware KB articles on this.  I am not going to link them here, as there are some missing pieces in each of them.  With several hours of trauma under my belt, and a few e-mails back and forth with VMware support, I’ve got the missing pieces.  I’ll start from the beginning, so if you’ve already done some work on this, make sure you can retrace your steps so you don’t get lost.

First thing we need to do is figure out what resources we do not want vCOps to see.  In my example here, I want to limit access to my development environment (the DEV1 cluster).  Those guys are spinning up VM’s so fast, they’re causing vCOps licensing issues.

 

First thing to do is create a collection role for vCOps. It is best to have a user account specifically for this role in Active Directory.  I’ve created one called SVC_VCOPS.  We don’t have to give it any rights in AD.

Going into vCenter, we need to create a role for vCOps collection.

Right click on the Read-only role, and clone it.

You should now have a role called Clone of Read-only.  Rename that to vCOps Collection, or something like that.

Now, let’s go edit that role.

You need to check all of the following privileges.  This is important, and this is where some of the KB’s are missing info.

Once you have those privileges assigned, add the user we created in AD to the vCOps Collection role we just setup.

Go into vCOps Admin via https://vcopsserveraddress/admin and click the Update button next to your vCenter server to change the collection user to the AD user we created.

Once you get that set for your vCenter server, restart your vCOps services.

Now let’s go into vCenter and start applying these permissions.

In Hosts and Clusters, right click on your vCenter and Add Permission.

Add the AD user you created and give them the vCOps Collection role.

Make sure you leave the Propagate box checked.

Now, click on the cluster, or resource you want to exclude and click the permissions tab.  What you’ll see there is the permission you just defined at the vCenter level.  Double click it and change to No access.

Again, ensure the Propagate box is checked.  When you click okay, you’ll get a warning saying the permission is defined higher up, and it’s going to replace the existing one.  Click okay.

The next step is vital, and seems to be a glitch in the vCenter permissions setup.  Remember that Propagate checkbox you made sure was checked on that last step?  It probably didn’t propagate.  Here’s where you save a month of troubleshooting and phone calls.

Go in and check permissions on a VM in the cluster you just excluded.


Don’t panic.  There’s a solid workaround.

Go into VM’s and Templates view.  Add the permission there, and propagate it.

For some reason, some VMware people say not to do this.  It’s the only way I was able to get it to work, short of changing permissions on EVERY VM.  And since they’re spinning up 5 a day, I’m just not doing that.  This works.

First, you’ll want to SSH into the Analytics VM.  Login with “root” and your password.

Next, type the command in blue below.  The prompt shows “secondvm-external“, which indicates you’re on the Analytics VM.

secondvm-external:/ # vi /usr/lib/vmware-vcops/user/conf/controller/controller.properties

Take a look at this file, and find the following line:

deleteNotExisting = false

Change false to true

If you’re in a hurry, you can play with the deletionSchedulePeriod setting, or you can just wait 24 hours, and the objects you wanted deleted will be deleted.

When you’ve made the change, type the following:

:wq

 

One last step for good measure.

Back at the secondvm-external:/ # prompt, type the following:

ssh 172.20.20.1

Note the prompt now changes to firstvm-external:/ #

Type in: su – admin

Now you’re at the admin@firstvm-external:~> prompt.

Type:

vcops-admin restart

24 hours from now, objects that vCOps cannot see will not exist in vCOps.

So now, let’s go into vCOps and get rid of the objects we don’t want to see anymore.

Login to the custom UI via https://vcopsserveraddress/vcops-custom

Navigate to Environment Overview.

Search for, and select the objects that you isolated via permissions, and click on the nearly invisible 8 pixel delete button.

It looks like this, magnified 1000x.  ;-)

Now relax.

If you’re getting the over licensed usage watermark, it’ll go away in 24 hours.

If the objects you just deleted reappear after the next 5 minute collection cycle, you missed a step.

Happy vCOpsing!