Today, whilst working on something in my home lab, I noticed an issue with SMB Multichannel which if you are using SMB Multichannel in your environment you will want to be aware of.
I’ll cover how to make SMB Multichannel actually work in another post, but for now, I’ll just cover the issue. I had configured my SMB networks using the New-SmbMultichannelConstraint Cmdlet to prevent the SMB traffic for my Hyper-V VMs from using my management network and I had assumed that all would work nicely, however when I ran the Get-SmbMultichannelConnection Cmdlet, I noticed that the Client IP and Server IP columns showed the address of my management network adapters and not the SMB adapters when it struck me.
I had registered the SMB Multichannel Constraint using the NetBIOS hostname of the servers however my Hyper-V server is using the FQDN of the storage server to connect to the SMB share with the VM data in it. I ran the New-SmbMultichannelConstraint Cmdlet again but this time registering the FQDN of the hosts on both side of the connections and shortly afterwards, running the Get-SmbMultichannelConnection Cmdlet, I observed that the connections where now being made to and from the Client and Server IPs in the SMB networks.
The bottom line here is that you should register SMB Multichannel Constraints for both your NetBIOS and FQDN server names. You may well design your Hyper-V deployment to use the FQDN after registering the constraint for the FQDN but you don’t know what other administrators are going to do long-term and having both the NetBIOS hostname and FQDN registered will prevent and potential issues down the road.