This configuration is slightly different compared with the Dynamic Backend QoS in part 5 because is simplifying the Backend configuration and only presenting 4 Multiplexed adapters to Windows. Once this is done, you just need to create a TEAM with two of these adapters for all the networks required on the parent partition, like Mgmt, CSV and Live Migration.

On top of the TEAM, you have to create a tNIC (Teaming NIC) for each traffic with the corresponding VLAN. This gives isolation between traffics and control from the OS, while allowing to dynamically create more tNICs if needed without having to reboot the Hyper-V host. (you may need additional tNICs for SMB for example)

Everything can be managed either by PowerShell or the NIC TEAM Console (lbfoadmin.exe) and of course RSS will give you the best possible performance from the adapters presented by the backend.

The TEAM and the vSwitch configuration on the right side of the diagram is identical to the Dynamic Backend QoS discussed in part 5, so the VMs/Tenants traffic is completely isolated from Mgmt, CSV and Live Migration traffics.

One caveat on this configuration is the QoS for each parent partition network traffic type. How I can prioritize Mgmt over CSV or viceversa? I would answer this questions with another question… do you really need to prioritize the traffic of your tNICs when there is already a QoS policy at the backend that will guarantee at least the amount of bandwidth that you define?

Is it true that in part 5 architecture each parent partition traffic will have his own QoS in the backend, but it is also true that the sum of them can be equivalent to what you may want to reserve when using the tNICs approach.

Many thanks to Hans Hvredevoort for the architecture reference.

Congratulations. You reached the last of these 7 posts covering the most common Hyper-V Network Architectures today. Maybe you don’t remember all the pros/cons and caveats on each case, but don’t worry. I’ve built this table that summarizes the most important factors to consider when deciding which Hyper-V Network Architecture you want to use. As I said from the beginning, there is not one unique best practice but different options for different situations or needs. Each column in the table represents an important factor to consider and each row represents the 5 scenarios covered in the Series. I’ve added a last column to categorize each scenario based on Performance and Throughput. I find it useful to explain the differences and I hope you find it useful as well. I personally prefer the Non-Converged Network Architecture if possible and affordable but there is no reason to discard the other options if you know how the end to end solution works and how the different pieces in the backend and Windows interact with each other.

References:

RSS and VMQ

Standardized INF Keywords for RSS

https://msdn.microsoft.com/en-us/library/windows/hardware/ff570864(v=vs.85).aspx

Standardized INF Keywords for VMQ

https://msdn.microsoft.com/en-us/library/windows/hardware/hh205410(v=vs.85).aspx

VMQ Deep Dive

https://blogs.technet.com/b/networking/archive/2013/09/10/vmq-deep-dive-1-of-3.aspx

https://blogs.technet.com/b/networking/archive/2013/09/24/vmq-deep-dive-2-of-3.aspx

https://blogs.technet.com/b/networking/archive/2013/10/22/vmq-deep-dive-3-of-3.aspx

NIC Teaming Whitepapers

Windows Server 2012

https://www.microsoft.com/en-us/download/details.aspx?id=30160

Windows Server 2012 R2

https://www.microsoft.com/en-us/download/details.aspx?id=40319

Hyper-V Virtual Switch

https://blogs.msdn.com/b/sdncorner/archive/2014/02/21/hyper-v-virtual-switch-architecture.aspx

Again, from bottom to top, there are two big purple Uplinks representing the CNA adapters. As you can see, this time the same uplinks must be shared not only between the different Hyper-V network’s traffic, but also with the Storage IO. This configuration and partition of the Uplinks is done by the backend software and a common setup is to dedicate 4GB from each Uplink for Storage. Windows will see these two adapters as HBAs and you will have to setup MPIO and the vendor DSM to provide HA.

As you can imagine, we suddenly sliced the total amount of bandwidth available for Ethernet to 6GB on each uplink, and here is exactly where we need to start planning accurately our Hyper-V Network Architecture.

• Windows will see the Multiplexed Ethernet adapters as 10GB cards. Of course this is not true at all because 4 of the 10GB are already blocked and dedicated exclusively for Storage IO. This shouldn’t be a big issue if you plan accordingly, but I’ve seen some customers complaining about network throughput without taking this factor into account.
• You might want to consider the number of multiplexed Ethernet NICs presented to the Hyper-V host. We have less available bandwidth for Ethernet and this may change your approach and the number of NICs.
• By definition, it is not the best approach to use the same path to send Storage and Network IOs. We are not isolating such traffic and this may lead to some bottlenecks if we don’t have a good capacity plan and performance baseline of our hardware. Personally I don’t like to put all my eggs in the same basket unless it is really necessary.

This is the last Hyper-V Network Architecture that I wanted to discuss and in my next post I will do a quick summary with the Pros and Cons from each solution. You may have noticed that I’ve never considered SR-IOV or RDMA NICs in any of the scenarios, but the main reason was to simplify the pictures.

Ideally, RDMA NICs should be completely dedicated and unless you use a Non-Converged Network approach, the backend solution does not provide RDMA support today. This probably will change in the near future. Until then RDMA NICs can be considered as FC HBAs and that’s why I didn’t include them in any scenario.

Regarding SR-IOV NICs, some vendors expose the SR-IOV VF on the Multiplexed cards presented to Windows. When this is the case, you will have to evaluate if you want to dedicate one or two of these multiplexed cards for this purpose. On the other hand, for the Non-Converged Scenarios, you will probably have to buy some extra adapters to provide this functionality if your environment or Workload requires it.

Today, most vendors already offer Dynamic QoS based on weight or minimum reservations. This allows us to use the entire bandwidth on each of the Multiplexed NICs presented to Windows. This is good because it means that each of the NICs on the Hyper-V Host will be able to reach 10GB if needed while prioritizing traffic in the event of conflict.

This backend solution enables us to have the best of both worlds. We can provide QoS and we can also take advantage of all the Hyper-V Network optimizations like RSS and dVMQ. Of course, it is important how many Multiplexed NICs we present to Windows and the weight assigned to each of them, but remember that the same rules from the Non-Converged network configurations will apply from a Windows perspective.

There are three major points with this configuration to bear in mind.

1. LACP is not exposed to Windows, so Link Aggregation on the Multiplexed NICs will not be possible.
2. QoS in the Backend and QoS from SCVMM 2012R2 on the vSwitch ports may be in conflict if policies are not properly planned and configured.
3. Windows does not know what these backend QoS and Multiplexed NICs are. Support and troubleshooting should be provided by the vendor.

Besides these three caveats, this architecture is one of the best options we have if your hardware supports it. MGMT, CSV and LM networks will be able to reach 10GB throughput when needed enhancing the Host performance while keeping HA and reliability.

Of course, again we are assuming that your storage connections are over FC using HBAs.

Again, let’s take a look to the following diagram and let’s elaborate what we are seeing:

Starting from the bottom you can see two big purple NICs representing the real uplinks available in the backend. These two uplinks use to be connected to different Physical Switches or Fabrics to provide HA and redundancy on the physical layer, but this is not what Windows sees after it is configured.

Usually Windows will see 8 NICs and in this diagram we will use only 6 of them because we assume that storage connection is done via FC over HBAs. On the Third Party backend QoS setup, we need to define what networks are required for a good Hyper-V Cluster environment and the bandwidth required for each of these networks.

One possible approach is to multiplex the uplinks with the above configuration. This will have almost the same benefits as a Non-Converged network Architecture except for:

• LACP is not exposed to Windows, so we cannot aggregate incoming traffic for the Mgmt or the VMs TEAMs
• On this Static QoS configuration, the bandwidth is hard blocked. Even if it’s not used, it will not be available for the other traffic. This might be a waste of bandwidth and not desirable.
• Combining the backend QoS with the SCVMM 2012 R2 QoS for the VMs can be difficult to understand and configure.
• Windows will see Physical NICs with non-standard bandwidth (anything different than 1GB or 10GB)
• It will require additional configuration and knowledge on how to integrate these backend solutions with Hyper-V.
• Firmware and drivers from these vendors will be a key component of the performance and reliability.

On the other hand, if our environment is really static and we know for sure the bandwidth consumption of all our traffic, this third party solution can help us to use RSS and dVMQ over the same uplinks. From a Windows perspective all the adapters will be physical and depending on the driver and the model you will be able to use both.

This kind of setup was really common until one year ago, when almost all vendors started to offer Dynamic QoS on the backend. Let’s talk about it in the next post.

As  you can see, in this diagram there are only 2 x 10 GB Physical Network cards. This hardware configuration is becoming more and more popular because 20GB of bandwidth should cover most customer’s needs while simplifying the datacenter and reducing costs. However, this architecture does include some caveats that must be mentioned in order to avoid potential performance issues.

So let’s start with the positives for this option and leave the constraints to the end of the post.

• Simplified and central management from SCVMM 2012 R2. We can setup almost everything from Virtual Machine Manager 2012 R2 using the powerful Logical Switch options. Hyper-V Host Traffic partitioning, VMs QoS and NIC Teaming will be configured automatically by VMM once our Logical Switch template is applied to the Hyper-V Host
• QoS based on weight can be applied by VMM 2012 R2 enhancing the resource utilization based on the need and the priority. For example, we might want to guarantee a minimum bandwidth to our CSV and LM vNICs on the Hyper-V host to make sure that Cluster reliability and stability is protected.
• You can take advantage of SMB Multichannel and use it with the vNICs to provide more bandwidth if needed. Each vNIC will use a VMQ and SMB Multichannel can help to use more CPU Cores to improve network throughput for the same traffic. CSV Redirection and Live Migration network traffic are good examples.
• You will be able to use LACP if needed if the 2 Physical NICs are connected to a Physical Switch. This might be desired or not depending on your needs. LACP configuration will force you to use a MIN-QUEUE configuration for dVMQ, so if you plan to run more VMs than Queues maybe this is not the best decision. You can always use Switch Independent / Hyper-V Port or Dynamic configuration for your TEAM if you don’t expect to need more than 10GB throughput for just one VM.

This architecture seems really handy right? I can manage almost all my network settings from VMM preserving good Network throughput… but talk about those caveats I mentioned:

• You lose RSS for the Hyper-V Host network traffic. This might have a performance impact in your Private Cloud if you don’t properly mitigate the penalty of losing RSS with several vNICs in your host to use SMB Multichannel. For example LM speed can be impacted unless you take advantage of SMB Multichannel.
• Generally speaking, you have a single point of failure on the TEAM. If for whatever reason the TEAM has a problem, all your network might be compromised impacting the Host and Cluster stability
• VM deployment from the VMM Library server will have just one core for the queue of the vNIC for management. This can reduce the deployment and provisioning speed. This can be a minor or big issue depending on how often you deploy VMs. One core can handle around 4Gbps throughput so I don’t really see this as a big constraint but something to keep in mind.
• The amount of VMQs available may be a concern if we plan to run a lot of VMs on this Hyper-V host. All the VMs without a queue will interrupt CPU 0 by default to handle their network traffic.
• We still need to configure VMQ processor settings with Powershell
• Ii is not possible to use SR-IOV with this configuration if the NICs are teamed at host level.

Hyper-V Converged Network using SCVMM 2012 R2 and Powershell strength is based on the fact that 90% of the configuration required can be done from VMM. However, we may face some performance constraints that we should be aware before making any decision. As a general rule I would say that most of the environments today can offer more performance than is required but in some cases we will need to think of different approaches.

Stay tuned for part 4!

At first sight you can recognize from left to right that there are 6 Physical Networks cards used in this example. You can also recognize that two of these adapter on the left are 1GB adapters and the other four green adapters are 10GB adapters. These basic considerations are really important because they will dictate how your Hyper-V Cluster nodes will perform.

On top of the 6 Physical Network cards you can see that some of them are using RSS and some of them are using dVMQ. Here is where things start to become interesting because you might wonder why I don’t suggest to create a big 4 NIC team with the 10GB adapters and dismiss or disable the 1GB adapters. At the end of the day, 40GB should be more than enough right?

Well, as a PFE, I like stability, high availability and robustness in my Hyper-V environments, but I also like to separate things that have different purposes. Using the approach from the picture above will give me the following benefits:

• You can use RSS for Mgmt, CSV and LM traffic. This will enable the host to squeeze the 10GB adapters if needed. Remember that RSS and dVMQ are mutually exclusive, so if I want RSS I need to use separate Physical NICs
• Since 2012 R2, LM and CSV can take advantage of SMB Multichannel, so I don’t need to create a Team, especially when the adapters support RSS. CSV and LM will be able to use 10GB each without external dependencies or aggregation on the Physical Switch like LACP
• CSV and LM Cluster networks will provide enough resilience to my cluster in conjunction with the Mgmt network.
• The Mgmt network will have HA using an LACP team. This is important and possible because each Physical NIC is connected directly to a Physical Switch that can be aggregated by our Network Administrator.
• Any file copy using SMB between Hyper-V hosts will use the CSV and LM network cards at 10GB because of how the SMB Multichannel algorithm works. Faster adapters take precedence, so even with simple a copy over the Mgmt network, I will take advantage of this awesome feature and will send the copy at 20GB (10GB from each CSV and LM adapter)
• SCVMM will always have a dedicated Mgmt network to communicate with the Hyper-V host for any required operation. So creation or deletion of any Logical Switch will never interrupt the communication between them.
• You can dedicate two entire 10GB Physical Adapters to your Virtual Machines using a LACP Team and create the vSwitch on top. dVMQ and vRSS will help VMs to perform as needed while the LACP /Dynamic Team will allow to receive and send up to 20GB from your VMs if really required. I have to be honest here, the maximum bandwidth inside a VM that I have seen using this configuration was 12GB, but that is not a bad number at all.
• You can use SCVMM 2012 R2 to create a logical switch on top and apply any desired QoS to the VMs if needed.
• You are not mixing Storage IOs with Network IOs

So, as you can see, this setup has a lot of benefits and best practice recommendations. It is not bad at all and maybe there are other benefits that I’ve forgotten to mention… but where are the constraints or limitations here with this Non-Converged Network Architecture? Here are some of them:

• Cost. Not a minor issue for some customer that can’t afford to have 4 x 10GB adapters and all the network infrastructure that this might require if we want real HA on the electronics.
• Additional Mgmt effort. This model requires us to setup and maintain 6 NICs and their configurations. It also requires the Network administrator to maintain the LACP port groups on the Physical Switch.
• More cables in the datacenter.
• Replica or other Management traffic that is not SMB will only have up to 2GB throughput.
• Enterprise Hardware is going in the opposite direction. Today it is more common to see 3rd party solutions that multiplex the real adapters in more logical partitions, but let’s talk about that later.

Maybe I didn’t gave you any new information regarding this configuration, but at least we can see that this Architecture is still a good choice for several reasons. If you have the hardware available, you certainly have the knowledge to use this option.

Let’s see you again in my next post where I will talk about Converged Networks Managed by SCVMM and Powershell

The series will contain these post:

1. Hyper-V 2012 R2 Network Architectures Series (Part 1 of 7 ) – Introduction (This Post)

2. Hyper-V 2012 R2 Network Architectures Series (Part 2 of  7) - Non-Converged Networks, the classical but robust approach

3. Hyper-V 2012 R2 Network Architectures Series (Part 3 of  7) – Converged Networks Managed by SCVMM and Powershell

4. Hyper-V 2012 R2 Network Architectures Series (Part 4 of 7 ) – Converged Networks using Static Backend QoS

5. Hyper-V 2012 R2 Network Architectures Series (Part 5 of 7) – Converged Networks using Dynamic QoS

6. Hyper-V 2012 R2 Network Architectures Series (Part 6 of 7 ) – Converged Network using CNAs

7. Hyper-V 2012 R2 Network Architectures Series (Part 7 of 7 ) – Conclusions and Summary

8. Hyper-V 2012 R2 Network Architectures (Part 8 of 7) – Bonus

Since 6 months now, I’ve been working on the internal readiness about Hyper-V Networking in 2012 R2 and all the options and functionalities that exists and how to make them work together and I realize that a common question in our team or from our customers is what are the best practices or the best approaches when defining the Hyper-V Network Architectures of your Private Cloud or your Virtualization farm. Hence I decided to write this series of posts that I think they might be helpful at least to do the brainstorm to find the best approach for every particular scenario. The reality is that each environment is different and use different hardware, but at least I can help you identify 5 common scenarios on how to squeeze the performance of your hardware.

I want to make clear that there is no just one right answer or configuration  and your hardware can help you determine the best configuration for a robust, reliable and performer Hyper-V Network Architecture.  Please note that I will do some personal recommendation based on my experience. These recommendations might or might not be the official – generic recommendations from Microsoft, so please call you support contact in case of any doubt.

The series will contain these post:

1. Hyper-V 2012 R2 Network Architectures Series (Part 1 of 7 ) – Introduction (This Post)

2. Hyper-V 2012 R2 Network Architectures Series (Part 2 of  7) - Non-Converged Networks, the classical but robust approach

3. Hyper-V 2012 R2 Network Architectures Series (Part 3 of  7) – Converged Networks Managed by SCVMM and Powershell

4. Hyper-V 2012 R2 Network Architectures Series (Part 4 of 7 ) – Converged Networks using Static Backend QoS

5. Hyper-V 2012 R2 Network Architectures Series (Part 5 of 7) – Converged Networks using Dynamic QoS

6. Hyper-V 2012 R2 Network Architectures Series (Part 6 of 7 ) – Converged Network using CNAs

7. Hyper-V 2012 R2 Network Architectures Series (Part 7 of 7 ) – Conclusions and Summary

8. Hyper-V 2012 R2 Network Architectures (Part 8 of 7) – Bonus

Hello Virtualization Community,

I am happy to announce that we have published the last release of the Hyper-V Management Pack Extensions with support for Windows Server 2012 R2 Hyper-V.

Please update your current HyperVMPE 2012 with this latest release from codeplex here :

New features on release 1.0.1.282

· Support for Windows Server 2012 R2 hyper-V

· Hyper-V Extended Replicas Monitoring and Dashboard

· Minor code optimizations

Features on release 1.0.1.206

· VMs Integration Services Version monitor

· Hyper-V Replica Health Monitoring Dashboard and States

· SMB Shares I/O latency monitor

· VMs Snapshots monitoring

· Managment Pack Performance improvements

Included features from previous release

· Hyper-V Hypervisor Logical processor monitoring

· Hyper-V Hypervisor Virtual processor monitoring

· Hyper-V Dynamic Memory monitoring

· Hyper-V Virtual Networks monitoring

· NUMA remote pages monitoring

· SLAT enabled processor detection

· Hyper-V VHDs monitoring

· Physical and Logical Disk monitoring

· Host Available Memory monitoring

· Stopped and Failed VMs monitoring

· Failed Live Migrations monitoring

Requirements

SCOM 2012 RTM or SCOM 2012 SP1
Windows OS Management Pack 6.0.7061.0 or higher.
https://www.microsoft.com/download/en/details.aspx?id=9296
System Center 2012 Management Pack for Windows Server Hyper-V 2012 6.2.6641.0 or higher.
https://www.microsoft.com/en-us/download/details.aspx?id=36438
System Center Management Pack for Windows Server Cluster 6.0.7063.0 or higher.
https://www.microsoft.com/download/en/details.aspx?id=2268

Regards,

Diego Martinez Rellan and Cristian Edwards,

In addition to simplifying and centralising the management of VMs, CSV volumes added a greater fault tolerance, allowing redirect access to the LUN through Cluster Networks to the Coordinator node, in the event that any of the nodes lose direct connectivity with the SAN. This for example allows continue giving service to the VMs hosted on a Hyper-V server that loses connectivity to storage, since you can redirect disk access through cluster networks until connectivity is restored with the SAN.

The main intention of this article is to cover and explain how the new Windows Server 2012 Failover Cluster manages the CSV Networks and the SMB Multichannel together, but before moving forward let’s review how this works actually in Windows Server 2008 R2.

The old way. Windows Server 2008 R2 Cluster Networks roles and metrics

In Windows Server 2008 R2 we can define which Cluster Network we want to use for CSV redirected traffic by configuring the network metric based on roles that we assign to them. CSV redirected traffic will use the network with the lowest metric. As you may know, we have three different types of Cluster Networks based on their role:

· External Network

The public network is the network which clients will connect to gain access to the highly available resources on the cluster. This network will be connected to the main network infrastructure in your organization. This is automatically selected when the cluster is built by determining which network has a default gateway.

· Internal Network

All networks in a cluster are used for intra cluster communication. You can fine tune this to ensure intra cluster communication uses a specific network and can fall back to another network if required. The private network should also be used for management tasks ensuring no additional overhead is being added to the public, storage and Live Migration networks.

· Excluded Cluster Networks

All the networks that we want to isolate from the Cluster and don’t use it for intra communications must be excluded. iSCSI or SMB storage traffic introduced in Windows Server 2012 are the types of networks you want to exclude

The following table shows the types of roles that exist in Windows Server 2008 R2 and the value of the metric assigned to each of these roles.

We will use an example to show how the Cluster networks configured metrics depending on the role that they play in Windows Server 2008 R2.

In the screenshoot below, we have a Cluster with 3 networks (Mgmt, Cluster, and Live Migration) and metrics have been automatically assigned.

· Network Mgmt is external and the Cluster automatically assigns the 10000 metric.

· The Cluster network is the first detected internal network and is automatically assigned the 1000 metric.

· The second internal network LiveMigration is assigned the metric of 1000 + 100

This configuration ensures that the CSV redirected traffic always use the “Cluster” network because it has the lowest metric.

While the Cluster can assign metrics correctly depending on the role as we have seen in the previous example, we may find ourselves in situations with multiple Cluster Networks, where might we configure these settings manually. To do this, Windows Server 2008 R2 offers us the possibility to use Powershell module for Clusters and assign metrics manually. The following code example shows how to change the Cluster network metrics rather than use its default 1000, use one even lower value, and thus ensure that other internal Cluster networks always have higher values. You can find more detailed information in the following link https://blogs.msdn.com/b/clustering/archive/2011/06/17/10176338.aspx

The new way. Windows Server 2012 Cluster Network roles and Metrics

In Windows Server 2012 Failover Clusters, the philosophy of the metrics and the roles of Cluster networks is maintained. So, we still have external, internal, and excluded networks, but the value of the metrics by default change substantially for a better integration with the new SMB Multichannel functionality. In Windows Server 2008 R2, the CSV traffic could be redirected by a single physical network adapter, but in Windows Server 2012, the CSV traffic can be redirected using more than one network adapter simultaneously taking advantage of SMB Multichannel.

However, if by any restrictions of our environment, we want to ensure that we only use the network with the lower metric, we must understand how the Cluster in Windows Server 2012 determines that the network traffic redirected CSV.

The following table shows how Windows Server 2012 assigns metrics automatically to the Cluster networks on the basis not only of the role, but the functionality of the physical network card

Like for Windows Server 2008 R2, let’s see a real example in Windows Server 2012 to better understand how this formula apply to our environment.

In the screenshoot below, we have a Cluster with 5 networks (Contoso_Mgmt, Contoso_Cluster, iSCSI, Live Migration and Slow) and the metrics that have been automatically assigned once the cluster was created.

· Network “Contoso_Mgmt” is external and the Cluster automatically assigns the 70240 metric.

o This is because the Physical Adapter is not RDMA but is RSS capable with a 10GB Link Speed. (80000 – 9600 -160 = 70240)

· The “Live Migration” network is the first detected internal network when the cluster was created and has the autometric of 30240.

o This is because the physical adapter is not RDMA but is RSS capable with a 10GB link Speed. (40000 -9600 – 160 = 30240)

· The second internal network “Contoso_Cluster” has the autometric of 30240 +1.

o This is because the physical adapter is not RDMA but is RSS capable with a 10GB link Speed. (40000 -9600 -160 +1 = 30241)

· The third internal network “Slow” has the autometric of 40000.

o This is because the physical adapter is not RDMA and RSS capable and the link Speed is 100MB. The NetFT substract is not applied because the adapter must be at least 1GB.

· The iSCSI network is automatically detected and Excluded from the Cluster Networks. The metric assigned (70241) will be the bigger and not used for Cluster communications

o This is because the physical adapter is not RDMA but is RSS capable with a 10GB link Speed (80000 – 9600 -160 +1 = 70241)

In the above configuration, the “Live Migration” Cluster network has the lowest metric, and this is maybe a configuration that we don’t want for our environment so let’s manually change the metrics and assign the lowest metric to the “Contoso_Cluster” Cluster Network.

How the SMB Multichannel changes the behavior to select the CSV Cluster Network:

Now, the “Contoso_Cluster” Cluster Network has the lowest metric, but does this means that this will be the only adapter used for CSV Redirected traffic? The answer is NO! The reason why the metrics doesn’t apply in Windows Server 2012 by default, is because SMB Multichannel is enabled by default as well. So let’s figure out what subnets or Cluster Networks will be used in this particular case applying these rules:

· Rule 1: SMB Multichannel take precedence over the Network Priorities of NetFT to decide what Subnets to use for the CSV Redirected traffic

· Rule 2: The cluster will only use Internal Cluster Networks by default for SMB Multichannel. This behavior can be changed to also used the External Networks modifying the UseClientAccessNetworksForSharedVolumes Cluster parameter

· Rule 3: SMB Multichannel requires identical link speed and features (RSS and/or RDMA) to stream the CSV redirected traffic over different subnets simultaneously

· Rule 4: If Adapters are not identical, SMB Multichannel will use the faster adapter/s only to stream the CSV redirected traffic

· Rule 5: Failover Cluster will fail back to NetFT the decision of what subnet to use only if SMB Multichannel is not available or disabled. Then the lowest metric logic will apply and the CSV redirected traffic will be send over the Lowest metric subnet

Reading the rules 1 and 2 we realize that SMB Multichannel is enabled because is the default configuration in Windows Server 2012, and three network adapters can be used for CSV Redirected traffic. The Internal adapters with role 1. If we continue reading the rules 3 and 4 we also see that “Slow” network has slower link speed (100MB) compared with networks “Contoso_Cluster” and “Live Migration”, so this finally explain us why these two Cluster Networks will be used for CSV Redirected traffic.

In some scenarios we may need to force use only one particular subnet for CSV Redirected traffic and avoid SMB Multichannel even if it’s the last recommended step. To achieve that, we need to disable SMB Multichannel using the command “Set-SMBClientConfiguration –EnableMultichannel $False” and reboot the server (Note that we must apply this on all cluster nodes). After this change, the Cluster will use the NetFT Network Priorities and will force to use only the subnet with the lowest metric that we have manually configured before.