Monday, January 21, 2013

VMware View with Microsoft NLB

While implementing VMware View 5.1 we came across issue with Microsoft NLB .

Current Setup

We have 2 View Connection Servers for our Bangalore Setup.
We are using Microsoft NLB to load balance between the two in Unicast Mode

Issue

Intermittent disconnections when connecting to Virtual Desktops

Root Cause

Post Investigation with help of VMware we have realized that it is the issue related to NLB
The Microsoft NLB cluster masks the cluster's MAC address for all outgoing traffic to prevent the switch from learning the MAC address.
As NLB is configured in Unicast Mode we need to make sure about following

  • All members of the NLB cluster must be connected to a single portgroup on the virtual switch.
  • All members of the NLB cluster must be running on the same ESXi/ESX host.
  • vMotion for unicast NLB virtual machines is not supported (unless you want to migrate all NLB members to a different ESXi/ESX host).

Work around

Setup Rule on the VMware to ensure they are on the same hosts all the time. It is called Affinity Rules
Dilemma with workaround is if one of the physical server fails both the View Connection Servers will go down at the same time until it is restarted by VMware Cluster on the other hosts

VMware Recommendation

Setup NLB in Multicast Mode
In Multicast mode servers can communicate with each other via the original addresses of their NLB network cards.

References

  • http://kb.vmware.com/kb/1556 (Microsoft NLB not working properly in Unicast Mode)
  • http://kb.vmware.com/kb/1006558 (Sample Configuration - Network Load Balancing (NLB) Multicast Mode Configuration) 
  • http://www.borgcube.com/blogs/2012/02/vshpere-multicast-support/ (3rd Party Link, with Valid information)

VMware SRM 5.0 Permissions Controls

While performing Lab testing we came across strange behavior which we discussed with VMware.
Just sharing with every one

Setup

We are having SRM 5.0 Setup on vSphere 5.0
We have done initial paring using Administrator Account
We have created Customised Recovery.Admin account to perform failover

Behavior

When we initiate Test Failover using Recovery.Admin account it logs that it was initiated by Administrator
Administrator is the account which was used to perform initial pairing of the sites
We were not sure whether it is normal behavior or not so we escalated to our Point of Contact in VMware

VMware Response

“In the prior release SRM would actually do everything in VC on behalf of the logged in user. This allowed fine granular permission controls in VC but proved to be extremely cumbersome to set up: SRM needs many very specific permissions on very specific objects just to be able to run a failover. If the administrator does not get it right, the recovery plan will fail, which is not good for RTO. Thus, in SRM 5.0 we decided to check our own permissions and override all VC permissions by doing everything under the admin user. This simplifies the setup and allows more logical permission control. If I have a permission to run a recovery plan, it should not matter whether or not I have a permission to write to a datastore.

Sunday, January 20, 2013

Active Directory Integration with vSphere 5.1 Single Sign On

Following procedure needs to be followed to add AD Authentication to SSO

Login to the Web client using root credentials and Navigate to Administration Tab
Click “Configuration“ under “Sign-On and Discovery” and Click on the “+”
It will open Add Identity Source Page where you will need to specify the Active Directory Details

Default Password for vCenter SSO Admin Account on VCSA

You will be surprised to hear this but there is no default password for the vCenter SSO Admin account i.e. admin@system-domain
You need to reset the password using the web client. 
Following procedure needs to be followed

Login to the Web client using root credentials and Navigate to Administration Tab
Click “SSO User and Groups ” and you should see the admin account
Right Click on admin account and select Edit User
Specify the new password on the screen

Failed to connect to VMware Lookup Service SSL certificate verification failed

While connecting to Web client I got following message.
“Failed to connect to VMware Lookup Service. SSL certificate verification failed.”
Post investigation I remembered that I changed the host name so need to regenerate the certificates
Following procedure was followed to resolve it
Access the admin console for VCSA
https:// or fqdn>:5480
Navigate to Admin Tab
Click “Toggle certificate setting” under “Actions”
Restart the vCenter Server Appliance
During the restart certificates will be regenerated
Ensure we roll back the Toggle certificate setting under Admin Tab

Wednesday, January 2, 2013

NetApp Data ONTAP Edge VSA

NetApp Data ONTAP Edge is a low-cost remote office storage solution that runs on the VMware vSphere platform. Designed to complement NetApp FAS and V-Series storage solutions, Data ONTAP Edge allows you to build a data center on an enterprise server using the VMware vSphere platform. Data ONTAP Edge converts the server’s internal disk drives into a flexible storage platform, giving you many of the same benefits as a dedicated NetApp storage system. 

Data ONTAP Edge includes the NetApp Data ONTAP operating system, whose native data de-duplication and FlexClone, SnapVault and SnapRestore software leverages your central site’s NetApp storage system for data backup, data recovery, and archiving of remote-site data. The result is that your remote offices can participate in your shared IT infrastructure with the same levels of efficiency and flexibility that Data ONTAP provides in your data center.

If you need to recover your branch office data, SnapRestore software uses local Snapshot copies to recover entire file systems or data volumes in seconds, regardless of capacity or number of files, via a permanent connection to your central site.



Evaluation

You'll need a NetApp NOW account in order to get the software and documentation: