SplitRXMode in VMware vSphere 5

My previous post was on how multicasting is handled in VMware vSwitch context. You can read about it here.

Now it is most apt to mention some advanced setting around it. The advanced setting we talk about is SplitRXMode.

While Multicasting worked fine for some multicast applications this still wasn’t sufficient enough for the more demanding multicast applications and hence stalled their virtualization. 

The reason being that in this case VMs would process the packet replication in a single shared context which ultimately led to constraints. This is because when there was a high VM to ESX ratio there was a consequent high packet rate that often caused large packet losses and bottlenecks. VMware vSphere 5 provides, the new splitRXMode to not only compensate for this problem but also enable the virtualization of demanding multicast applications.

SplitRx mode is an ESXi feature that uses multiple physical CPUs to process network packets received in a single network queue. This feature provides a scalable and efficient platform for multicast receivers. SplitRx mode typically improves throughput and CPU efficiency for multicast traffic workloads.

VMware recommends enabling splitRx Mode in situations where multiple virtual machines share a single physical NIC and receive a lot of multicast or broadcast packets.

NOTE: 

•         SplitRx mode is supported only on vmxnet3 network adapters. 
•         This feature is disabled by default.
•         SplitRx mode is individually configured for each virtual NIC.

To enable SplitRX do the following:

This feature, which is supported only for VMXNET3 virtual network adapters, is individually configured for each virtual NIC using the ethernetX.emuRxMode variable in each virtual machine’s .vmx file (where X is replaced with the network adapter’s ID).

The possible values for this variable are:

 ethernetX.emuRxMode = “0″

The above value disables splitRx mode for ethernetX.

ethernetX.emuRxMode = “1″

The above value enables splitRx mode for ethernetX.

To change this variable through the vSphere Client:

1. Select the virtual machine you wish to change, then click Edit virtual machine settings.
2. Under the Options tab, select General, then click Configuration Parameters.
3. Look for ethernetX.emuRxMode (where X is the number of the desired NIC). If the variable isn’t present, click Add Row and enter it as a new variable.
4. Click on the value to be changed and configure it as you wish.

The change will not take effect until the virtual machine has been restarted.

References and Credits: Chris Hendryx (it.toolbox.com).

vMotion network design considerations - Multi-NIC vMotion and Link Aggregation in vSphere 5.5 - Part1

vSphere 5.5 has been now out for some time. As always with a new release, there were some major enhancements (good for us), specially on the networking and vDS.

I was impressed by Multi-NIC vMotion support when it was introduced  in vSphere 5.0. With advent of 10G NIC cards and ever increasing size of worlkloads that run in single VM, it was important to leverage this technology to revamp existing vMotion.

And I must say, VMware is always two steps ahead in innovation and improving its product features.

I am today looking into the design consideration for vMotion network by using Multi-NIC vMotion and LACP support in vDS in vSphere 5.5 

LACP support till vSphere 5.1 was rather limited and exclusively dependent on IP Hash load balancing. With vSphere 5.5 a lot has changed with vDS specially LACP and support for all LACP load balancing types.

LACP now support dynamic link aggregation, multiple LAGs and is not exclusively dependent on IP Hash load balancing.

Till vSphere 5.1 Multi-NIC vMotion was correct as compared to LAGs backed NICs which in turn work on LACP. LACP support till vSphere 5.1 was rather limited and exclusively dependent on IP Hash load balancing.

Now for all of you who know how IP hash load balancing works and and how vMotion selects the preferred NIC can relate to this observation.

Rest of you can dig a little and it would be very clear. Please refer to excellent article by Frank Denneman ( Here )

I am still contemplating how does this change the LACP vs Multi-NIC vMotion debate. I am trying to discuss this with my friends in VMware and lets see what are there thoughts on this.

Keep watching this space on how has this changed with new vSphere 5.5