VMware is in the process of working on the vSphere 5 edition of the Security Hardening Guide and will shortly make a public draft available for comment (I’ll let you know when it’s available). This will be great news to the many people who have been waiting patiently for it since the vSphere 5 release. A lot of work is going into making this edition of the Security Hardening Guide much more user friendly and easier to use and implement. Many of the locked down items will be the same as in 4.1, and of course some changes and enhancements too. Another difference this time around is there are now new implications and restrictions on functionality introduced by the recommendations due to changes at least one popular VMware vCenter Management Tool. This is where Site Recovery Manager (SRM) v5 comes into the picture.

This isn’t going to be a log article as I want your opinion and I have two Yes/No Polls for your to answer. SRM v5 introduced a lot of great new functionality, workflow improvements, more logical and useful dependency mappings and start-up orders, greater scale, greatly improved performance for recovery plans and recovery operations. The performance of recovery operations are now significantly faster to run than in the previous version. However to get that performance increase VMware has changed the mechanism used to change IP addresses and communicate with the Virtual Machines for some operations.

If you’re not sure what I’m talking about check out the vSphere 4.1 Hardening Guide and search for VMX30 or VIX.

This change is significant if you apply the security hardening recommendations. SRM now requires that the VIX API be enabled on all protected virtual machines that will have their IP changed during recovery. There are no other options available. You either use the VIX API and live with the security risks, or you don’t change the IP addresses on the VM’s during recovery.There is no option to use the old change of IP address mechanism that was slower but didn’t rely on the VIX API, which would have been a very good option to have in my opinion. This has already caused me design problems in a number of customer environments.

If you don’t have a need to disable the VIX API because your security policy and vSphere Hardening policy doesn’t really justify this level of security then the change to SRM is going to be no problem and in fact extremely beneficial for you. Thins will run much faster. If however you have strict security and hardening policies and some of the VM’s targeted for protection require the VIX API to be disabled, and need an IP address change during recovery, you will have a problem and need to deal with it. There are a number of potential ways to solve the problem, but none are very elegant or easy to implement.

So this leads me to the two polls. Do you have a policy to disable the VIX API, and will this cause you a problem with SRM that might force you not to use it? Please let me know and get as many of the people you know to respond to this survey. If I get enough responses I will send this feedback onto VMware to review. If nobody cares enough about it, I’ll forget it and move onto something else.

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.