Quickly adding VirtualCenter 2.5 network redundancy

When VirtualCenter (VC) 2.5 was released, I, like many others, started on a path to migrate to the new version for my VMware implementation. After the VC installation, my ESX hosts, which had only one network interface, displayed a message similar to the one shown below:

Initially, I was somewhat irritated at this message. I had already planned out my connectivity for the ESX hosts in the VC 2.0 and ESX 3.02 version behavior. But after some thought I determined that management network redundancy is actually a good idea despite the slight hassle. Here is what I did to quickly and solidly get rid of this message and the corresponding yellow indicator on the cluster:

Get an additional IP address

An additional TCP/IP address is required to resolve the lack of redundancy for the role of VMware service console. In my environment, it worked best to have this additional IP on the same VLAN as the primary VMware service console address. Furthermore, I have one DNS entry for the ESX host that I will leave configured for the primary interface. This is unless there is an issue requiring me to have all service console traffic migrated to this secondary interface. In that scenario, I would also change the DNS entry.

Stack the roles

I chose to “stack” the role of service console on top of an existing vSwitch that was, up to this point, configured to only provide virtual machine traffic. Here are the steps to do this:

• go to the ESX host in the VMware Infrastructure Client, (VIC)
• selected the configuration tab,
• In the networking section, select Add Networking
• and add the Service Console role on top of the existing vSwitch as shown below:

This interface will not have significant traffic back to the VC server unless it is configured to be the primary interface. In my case, the DNS entry will still point to the primary interface on vmnic0. In this configuration, I am not taking precious bandwidth from the virtual machines (not shown) on the PROD-VLAN network across the two physical interfaces vmnic1 and vmnic2.

In general, I do not wish to stack roles on physical adapters. My initial design was based on having dedicated interfaces for virtual machines, vMotion, service console and a hardware management interface (Dell DRAC or HP iLO). In this situation, there is virtually no traffic on the new service console, and the benefit of having the degraded cluster condition cleared is work changing the practice of stacking network roles.

In fulfilling the redundancy requirement, a true issue that would cause the cluster to be in a degraded state with the yellow icon would not be masked. The other, more intuitive option is to add or allocate a physical interface with the specific role of the additional service console assigned. Most implementations, however, don’t have extra physical network interfaces available.

Feel free to share your own strategies in addressing this annoying growing pain of VC 2.5 by commenting.