Archives for October 2009

If you run VMWare ESX in your data center, you might be interested in finding new ways to tune your overall system performance. One easy way to tune performance is often overlooked, because it initially is thought to affect system redundancy. Rest assured, this will not affect your system redundancy. Here is the situation:

Usually an ESX host is built with 2 physical NICs assigned to the service console. The VMotion setup is configured to use the same switch so that NIC teaming can be used. However, VMWare recommends to separate your VMotion traffic from any other traffic, but if you ask around in the VMWare Administratosphere (yes, I know – it is a word I just made up) you will find out that almost nobody does it because of the limited number of NICs you can “throw” at a server. So, the VMotion NIC and the Service Console NIC are usually teamed.

Here is a neat little trick that allows you to physically separate the traffic at least on the NIC level and to dedicate a physical NIC to your VMotion traffic. Adjust your NIC teaming settings and instead of having both NICs active on the Service Console and on the VMotion side, make one NIC primary and the other one secondary and vice versa.

So, in production this looks like that the Service Console is running on VMNIC0 as the active NIC and VMNIC1 as the Standby NIC. At the same time the VMotion NIC is set to use VMNIC1 as the primary NIC and VMNIC0 as the standby NIC.

Conclusion: In the old setup a VMotion process could flood your NIC with traffic and any service console traffic would then be affected by this flood of VMotion related traffic. Worst case scenario this can make a host non-responsive or very slow responding. So, with this change made as discussed, you can effectively separate VMotion traffic from normal Service Console traffic and still give the Service Console virtual switch the redundancy you want.