Virtualization Pro

Feb 27 2008   3:17PM GMT

Quickly adding VirtualCenter 2.5 network redundancy

Rick Vanover Rick Vanover Profile: Rick Vanover

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:

Lack of redundancy issue

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:

Reconfiguration

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.

2  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Blithespirit
    I found that by adding a second console to the Vmotion network with an IP range that is not on the main network is suffiecient to deal with any problem, the requirement is that HA requires access to a second redundant service console, any range as long as it is the same on all second service console ports will suffice to enable HA removing the notice. if you want true redundancy then a second switch along side the console would be a requirement and as we all know this can then be redundancy sprawl and go silly mode kicks in on expediture. if you add another service console IP address VC will not manage through this as it is only connected by Vswitch0, so the second console will theoretically not do much outside HA. open to views & thoughs ?
    700 pointsBadges:
    report
  • Bizrisky
    In our configuration we stack console 2 onto our vmotion nic and both of these are on a separate switch and subnet. You may not be able to easily get to the second console via the VC server but you can certainly use the VC client on your desktop to connect to console 2 IP using the root account (even if VC server is connected to console 1 at the same time).
    15 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: