Hyper-V Host SMB NIC Selection

When I was creating a simple proof of concept with some new DataOn DNS-1640D JBODs the other day (before several of these are going into production), I was seeing some unexpected behaviour with which network was being used by a Hyper-V host for SMB Multichannel. Very simply, the host had three network adapters: one management and two storage, all on separate subnets (as is required for SMB Multichannel).  The management NIC was onboard and the two storage NICs were an additional card.  Monitoring the networks when reading/writing data from/to the storage showed only the management NIC was being used.  I checked DNS, connections, client access point, etc. and everything seemed configured correctly on my SOFS cluster, so I configured SMB Multichannel constraints for select only my two storage NICs.  Still no joy.

So I reached out to Aidan Finn (www.aidanfinn.com), who is a Microsoft MVP and knows this stuff very well, to see if he could shed some light on the problem.  Despite him being on holiday, I had a reply within 5 hours with his thoughts about what was going on.  There is a specific order to which network card the Hyper-V server would select.  He said:

It’s a waterfall decision:

  1. If a NIC with RDMA is found: use it/them
  2. If a NIC with RSS enabled is found: use it/them
  3. The highest speed NIC: use it/them

The decision will go through that list in order and jump out at the first satisfied one.

He was spot on.  Sure enough, by running Get-SmbClientNetworkInterface on the Hyper-V host, I could see that my management NIC had Receive Side Scaling (RSS) enabled and my two storage NICs didn’t and so selection got to the management NIC and didn’t go looking for any others.  I’m sure Aidan will elaborate on this in one of his future blog posts.

To solve this, I had to do two things: disable RSS on the management NIC and then configure SMB Multichannel constraints on to the two storage NICs as all three were now equal, according to SMB Multichannel.  The following two PowerShell commands sorted it:

  • Disable-NetAdapterRss
  • New-SmbMultichannelConstraint

I have already blogged about SMB Multichannel Constraints, so for more information, see here: http://www.knappett.net/index.php/2014/07/10/configuring-smb-multichannel-contraints-to-a-scale-out-file-server-cluster-hyper-v-and-virtual-machine-manager/.  I won’t have to use this for the production clusters as I will have a much different types of network adapters and setup, but this should prove helpful for a proof of concept.  This would also need to be done on each Hyper-V host with this issue.

Thanks, Aidan!

Leave a Comment


Your email address will not be published. Required fields are marked *