“Host currently has no management network redundancy” Error Message After Upgrade

You have just completed upgrading to ESX 3.5 and Virtual Center 2.5 All is well and the final reboots are happening. Life is good in your world as “Lord of the VMware World”. Just as everything is looking fine, the yellow exclamation point appears on your server or cluster that has just rebooted. You click on it and discover an annoying and cryptic message:

“Host currently has no management network redundancy”

“Hmm… now what does this mean?” you wonder. Everything was just fine before in your virtual world.

Well, the answer is simple. ESX 3.5 and Virtual Center 2.5 likes redundancy in all things. You probably have done the exact same thing I did in my implementation; you only used one NIC for your management port. What’s happening is after the upgrade the Virtual Infrastructure has called thrown a yellow flag at you for not having enough NICs “in the box” (sorry, Bowl Season is in full force now and I’ve got football on the brain). Your Virtual Infrastructure wants you to have two NICs for the vSwitch the service console is on. Before you have another penalty called for unnecessary roughness (keeping with my football motif), understand that this is not a show stopper. It’s just VMware wanting you to follow best practices. Honestly, they are doing it for your own good.

My recommendation here is to add a second NIC to your port group that the Service Console lives on. Furthermore, I would dual home the network connections for these NICs and have each reside on a separate independent section of your network with each section living on its own power grid and having separate backup power supply. This serves the purpose of making VMware happy with you once again and giving you added redundancy on your service console. This redundancy will pay off in the following ways:

1. If you have only one NIC for the port group and this NIC should lose network connectivity you can no longer access this server to manage it until the problem is resolved. With two NICs enabled for the port group you minimize this risk and are only affected by a serious network issue.
2. Should you lose connection from your network to this single NIC (due to any of a host of reasons), your HA Isolation Response will not activate and turn the working servers off just to bring them back up on another server that it can detect. Again, risk is minimized for your virtual environment.

While having dual NICs for your service console port group may not be feasible for everyone, if you can I would definitely recommend it. After all, risk mitigation should be one of the areas we as IT technicians spend valuable brain power on. In my book risk that is avoided is potential work that is avoided freeing up our time for more valuable endeavors (like watching football!).