In every virtual data center, allocating network interface cards (NICs) can significantly influence everything from virtual machine performance to high availability. Given this influence, you would do well to adopt a NIC distribution strategy that promotes network efficiency and prevents latency in your data center.
A solid NIC allocation strategy ties in to the very essence of server virtualization. Virtual servers share a finite pool of physical hardware resources. Because these resources are limited, each VM must limit its resource consumption so as not to deplete other hosted VMs of needed resources. Most server chassis, however, lack the physical space to accommodate a dedicated network port for each VM.
When it comes to allocating physical NICs, there is no shortage of best practices, and it seems that every vendor has its own allocation technique. In my experience, no NIC allocation strategy works perfectly for every data center 100% of the time. You can, however, calculate the best NIC allocation strategy for your data center by considering factors such as bandwidth, clustering and virtual switches.
Dedicating NICs for the parent partition and server clusters
In general, you should reserve a NIC for the parent partition, also known as the host operating system, to host specific management traffic. This may seem a waste of a network port; however, in many cases backup traffic also flows through the parent partition's network connection.
Similarly, you should dedicate a physical NIC to cluster traffic. In virtual data centers, most host servers reside in clusters. Clustering allows VMs to fail over to another host server in the event that one fails. Dedicating a physical NIC to cluster traffic prevents failovers from competing for network bandwidth.
When NIC teaming is the better option
When IT first began adopting server virtualization, admins would often assign physical NICs on a per-VM basis. For example, a high-demand VM would have a dedicated physical NIC, while several low-demand VMs would share a physical NIC.
This method worked at the time but isn't as practical today when you consider how virtual networking works.
In a Hyper-V environment, you do not directly assign NICs to VMs. Instead, each NIC has a corresponding virtual switch. If you want to dedicate a NIC to a specific VM, then you only need to ensure that VM is the only VM connected to the NIC's switch.
This concept seems simple enough, but remember that virtual servers can dynamically move from one host to another. If you move a VM to an alternate host, then that VM only has access to the virtual switches on the new host. To guarantee that a given VM always has a dedicated NIC, you will have to reserve a NIC on any host server where the VM could potentially reside. This approach may occasionally be necessary, but it usually wastes network hardware.
You would be better off building a NIC team, which is a collection of NICs working together as one logical NIC. You can configure the VMs on a host server to share the aggregate bandwidth of a NIC team, rather than trying to allocate specific NICs to individual VMs.
When you create a NIC team, you must decide how many NICs to include in the team and whether you want to dedicate a NIC as a hot spare, which is used in the event that one of the NICs in a team fails.
Allowing all of a host's VMs to collectively use a NIC team can lead to resource contention. High-demand VMs can deprive lower-demand VMs of needed bandwidth.
To avoid contention, practice bandwidth management. Hyper-V's bandwidth management feature lets you set minimum and maximum bandwidth thresholds on a per-VM basis. This allows you to reserve bandwidth for a VM, or to limit the amount of bandwidth allocated to a VM.
Keep in mind when planning your own NIC allocation strategy that every organization is different, and your data center will have its own resource needs and requirements that will dictate the best method.
The NIC's effect on network performance
Easier NIC teaming with Windows Server 2012