I have seen this error appearing after the upgrade to ESX 3.5 / VC2.5 on HA-enabled systems. Somehow ESX thinks it is not redundant enough for HA I guess. Does anyone know the exact parameters for ESX to come up with this? My setup has one service console connected to a vswitch, which has two physical uplinks. Obiously, ESX does not think this is redundant enough. Anyone got more info on how to get rid of this message (eg how you should design network setup in the eyes of ESX HA)?
the pages you are referring to do indeed state how to setup network redundancy. It states that nic-teaming usually satisfies redundancy needs. I have tyhat already in place, but still I get the warning stated in the subject.
I am looking for the rules that apply for ESX to display or remove this warning. Creating redundancy by using a NIC team does not appear to do the trick...
Anyone got more on this. I have configured redundant networking through double physical NICs on both hosts. Still the warning keeps popping up. Anyone knows the "rules" to which this warning is bound?
I have the same problem. Two hosts were upgrades from ESX 3.0.1, and another failed an upgrade so I just blew it away and installed fresh. VC 2.5, fresh install there (not by choice..)
Anyways, I have the same problem. "xyz.company.com has no management network redundancy" on all three hosts. I plugged in another NIC (they have 12) and assigned it to Service Console on all three, configured the NIC Teaming in different ways... no dice. Did the "Reconfigure for HA" after making changes...
I'm hoping you are joking. HA and DRS are expensive, payed for and are a must for the Enterprise environment. HA must stay on. Redundancy on the management console however is not a concern in our environment.
While I do not know how to turn it off, I was able to apparently make it happy. I created a second service console on the virtual switch which carries the VMotion traffic, and VC is now happy.
Confirmed. Adding a second SC to the vmotion interface did the trick in my case as well. However, it is a useless addition, since my vmotion network has no connectivity whatsoever to an other networks. I am curious what vmware tries to accomplish here: I have never seen a vswitch explode as of yet . Possibly to avoid human error? In any case, customers ask questions about it, and with this a 4 pNIC system becomes hard to configure properly for HA (allthough 4 pNIC systems are quite redundant!). So it is still a problem for us. So now we have to go and ship 6 pNIC systems just to satisfy this warning? Seems just a little overdone to me.
I just wanted to follow up here - my error messages DID dissapear. I assigned two NICs to the Service Console (Vmotion and several VM networks only have one each, I didn't change anything there) and did the "Reconfigure for HA." Strangely, this DOES work, but only after several hours did the warning dissapear.
I used the same virtual switch - I just added another NIC to it. (Note that both NICs have to be actually plugged in and active.)
On the one host that I added the second NIC to the SC and did not do "Reconfigure for HA" the error message remained. Once I did that reconfigure, about 5 hours later the error dissapeared.
Oh well.. At least VC 2.5 seems a little less buggy in other regards, so I can live with this one.
That is weird. I tried the same thing. I'll try to remove the second service console from the vmotion network, hope for the warning to return, then reconfigure for HA and possibly see it disappear. Will keep you all posted.
Just got off the phone with VMware support. Bottom line per them is that it is a bug that needs to be fixed with VC so expect a patch to come out. Supposedly HA will work fine once installed, even with the warning message. It is there from an isolation response perspective and is a highly recommended setup. Me being the paranoid person I am an not wanting to see this 'warning' message, we worked through the process of removing it and what has already been discussed is the work around to getting rid of them.
What I did -->
First, I disabled HA. I had one vmnic dedicated to my service console and one dedicated to VMotion (2 separate VSwitches), I combined the 2 into 1 VSwitch with both port groups, teamed the vmnic's and made sure each physical nic was on a separate physical switch. re-enabled HA and viola, the warnings disappeared. All of my physical nics are 1000/Full so that helps.
Alternate method -->
You can also add a 2nd unclaimed nic to your existing vSwitch (already talked about in other posts) for this purpose and keep the VMotion separate from the service console or you can add another service console (service console2, to either an existing vSwitch or create a new one). I did not opt for either of these as combining them was the easiest and most cost effective solution for my environment. I tested my VMotion after I did this an have had no issues migrating sessions between hosts.
Thanks for sharing this with the community! I am aware of the need for redundancy. HA and no redundancy is just not an option in my opinion. But the problem was that this warning would not go away, even with a teamed nic on the vswitch where the service console resides.
Anyway, glad to hear it is a bug, and not really affecting the quality of HA. We know now how to get rid of it, even with teamed nics, so I guess it is purely a small annoyance to get rid of it until it gets fixed by VMware.
Yea, redundancy is good and all, but for my part, it's not necessary to make the service console NIC redundant. I've been working with IT for quite a few years now, and not once have I had a NIC go bad in mid-flight. For our purposes, it's overkill to require another NIC on the service console, and kind of a pain since all our hosts have at least eight NICs plugged for VM Networks and Vmotion already.
Oh well. Not the end of the world.
Do not forget the impact of having a single NIC for the service console. Pull the service console, loose all VMs running on that host (HA will hard-poweroff those VMs by default). Even more "fun" is having a single switch, and the a switch failure in an HA environment. Result will be that ALL your VMs will power off.
Have you even considered moving to trunked connections (dot1q) in order to "mix" different networks over the same group of wires? Using a separate nic for each LAN (customer?) will not scale...