We all know that Network I/O Control is your friend when it comes to production deployments of vSphere in general.  Today, I quickly wanted to make a point that NIOC is also great when it comes to home labs and why we should have it enabled, if possible.

A few days back, I was deploying a floating linked-clone desktop pool using Horizon View 5.3.  The process died while cloning the image.  Cleaning up and trying again a few times, didn’t help either.

Background info: I have a four host nested-ESXi environment with shared iSCSI storage on SSDs, running under the host OS (VMware Workstation 10).  Needless to say, the storage is not VAAI-compliant.

Going back to the issue, I looked at various things and saw that network usage was quite heavy through the various interfaces.  However, I also noted the “chaotic” nature of it.  It seemed that all different kinds of traffic was at war with each other. At the time, I didn’t have NIOC enabled on the distributed switch.  Looking at that, I decided to enable it and ran the deployment again. This time, it worked without a hitch!

For this post, I recreated the issue and took a couple of screenshots:

Cloning with and without NIOC

Here, pool deployment with NIOC enabled is on the left and then the same pool deployed without NIOC on the right.  As you can see, the traffic on the right looks chaotic and that’s what degraded connectivity to the extent that the deployment failed soon after (highlighted by the third arrow).

Another screenshot just shows the effect when NIOC is enabled part way through the cloning operation:

NIOC Enabled During Cloning

Here you can again see how enabling NIOC has a positive effect on traffic flow and makes all traffic take their fair share on the interfaces.

Moral of the story: Enable NIOC on your home labs, if there isn’t anything preventing it.