I have been requested by several people to do an update of my original Service Console Redundancy article. Although personally, I am still of the opinion that the three options stated in the article are still valid I have rewritten them and dropped one option, as now a days the majority of companies now have a decent infrastructure with vlan’s.

Both configurations are supported by VMware and each has their own pros and cons:

1. Requirements: 2 physical nics, vlan’s and vlan trunking:
   • vSwitch0: 2 Physical nics(vmnic0 & vmnic2)
   • 2 Portgroups(Service Console & VMkernel)
   • Service Console active on vmnic0 and standby on vmnic2
   • VMkernel active on vmnic2 and standby on vmnic0

   Each portgroup has a vlan ID assigned and runs dedicated on its own physical NIC, only in the case of a fault it’s switched over to the standby NIC. It will return to the original NIC when the physical NIC is up and running again. This is achieved by setting “Failback” to Yes!

   Pros: Only need 2 NICs in total for the Service Console and VMkernel, especially useful in Blade environments. Simple setup.

   Cons: If the connection is dropped several times it will cause the NIC to fail-over each time which can cause HA to kick in eventually. You will need to set the Failure Detection Time (das.failuredetectiontime) to 60 seconds opposed to the default of 15 seconds. (According to VMware best practices.)

2. Requirements: 3 physical NICs, vlan’s and vlan trunking:
   • vSwitch0 – 1 Physical NIC(vmnic0) – 1 Portgroup(Service Console)
   • vSwitch1 – 2 Physical NICs(vmnic1 & vmnic3)
   • 2 Portgroups (VMkernel & Secondary Service Console)

   The primary Service Console runs dedicated on a physical NIC, vmnic0, with a vlan assigned on either the physical switch port or the portgroup. (I would prefer portgroup for consistency).

   The second vSwitch, vSwitch1, will run the VMkernel active on vmnic1 and standby on vmnic3. The secondary Service Console will be active on vmnic3. For the secondary Service Console I would prefer to set the vmnic1 to “unused”, this way you are 100% sure that the Service Console will run only on vmnic0 and vmnic3.

   Pros: a lower “failure detection time”(das.failuredetectiontime) can be defined this is because of the fact that the service console is already active. Here the Failure Detection Time can be set to 20 seconds, further no Spanning Tree problems will occur as the setup contains two service consoles, and subsequently 2 MAC addresses. (This is also the reason why I would set vmnic1 to unused for this portgroup)

   Cons: Need to set extra isolation addresses(das.isolationaddress), and secondary Service Console preferably in a different subnet.

Thanks goes out to mr Tom Howarth for a sanity/grammar check.