Network adapter windows server 2012

Объединения сетевых адаптеров NIC Teaming в Windows server 2012 R2

Увеличение пропускной способности — увеличение полосы пропускания пропорционально количеству адаптеров в группе. К примеру, если объединить в NIC Teaming два сетевых адаптера со скоростью 1 Гбит/с, то общая полоса пропускания составит 2 Гбит/с;
Отказоустойчивость — при выходе из строя одного из адаптеров в группе, связь ни на секунду не прерывается и остальные сетевые адаптеры поменяют вышедший из строя.

Технология NIC Teaming не нова, но ранняя ее реализация зависела от производителей сетевого оборудования. Возможность объединять сетевые адаптеры в группу средствами ОС появилась только в редакции начиная с Windows Server 2012. Эта технология позволяет объединять в группу адаптеры разных производителей, единственное ограничение — все они должны работать на одной скорости. Ограничение по количеству объединяемых сетевых адаптеров в NIC Teaming равна 32.

Настройка

По умолчанию режим «NIC Teaming» в Windows server 2012 R2 отключен. Для его активации открываем «Server Manager» и заходим в свойства сервера, далее нажимаем: Объединение сетевых карт (NIC Teaming).

В Задачах (Tasks) выбираем пункт Создать группу (New Team).

Далее именуем группу, выбираем отмечаем адаптеры и настраиваем дополнительные свойства группы. Далее подробней рассмотрим дополнительные параметры настройки «NIC Teaming» в Windows server 2012 R2:

Режим поддержки групп (Teaming mode) определяет режим взаимодействия группы с сетевым оборудованием:

1. Не зависит от коммутатора (Switch Independent) — группа работает независимо от коммутатора, никакой дополнительной настройки сетевого оборудования не требуется. Этот режим позволяет подключать адаптеры одной тиминговой группы к разным свичам для защиты от сбоя одного из них. настройка по умолчанию;
2. Статическая поддержка групп (Static Teaming) — режим с зависимостью от сетевого оборудования. Все адаптеры группы должны быть подключены к одному коммутатору. Порты коммутатора, к которым подключены адаптеры группы, настраиваются на использование статической агрегации каналов;
3. LACP — режим с зависимостью от сетевого оборудования. Коммутатор настраивается на использование динамической агрегации каналов с использованием протокола «Link Aggregation Control Protocol» (LACP).

Режим балансировки нагрузки (Load Balancing mode) определяет, каким образом распределять сетевой трафик между адаптерами группы:

1. Хэш адреса (Address Hash) — при передаче сетевого трафика на основании MAC или IP-адресов отправителя и получателя вычисляется хеш (некое число). Это число привязывается к определенному физическому адаптеру и в дальнейшем весь трафик от этого отправителя будет идти через этот адаптер;
2. Порт Hyper-V (Hyper-V Port) — в этом режиме осуществляется привязка адаптера teaming группы к определенному порту виртуального свича в Hyper-V. Этот режим используется в том случае, если на сервере активирована роль Hyper-V.

Резервный адаптер (Standby adapter) позволяет назначить один из адаптеров группы в качестве резервного. В нормальном состоянии резервный адаптер не используется для передачи трафика, но при выходе любого адаптера группы из строя сразу занимает его место и трафик продолжает передаваться без перерывов. Но даже без резервирования выход из строя одного адаптера в NIC Teaming не приведет к прерыванию сетевого соединения, потому что, нагрузка будет автоматически распределена по оставшимся адаптерам.

Команда создания группы «NIC Teaming» в powerShell:

New-NetLbfoTeam -Name First-team -TeamMembers ″Ethernet″,″Ethernet 2″ ` -TeamingMode SwitchIndependent -LoadBalansingAlgorithm TransportPorts

После создания группы, в окне «Сетевые подключения» появиться еще один сетевой адаптер, который как раз и является виртуальным адаптером созданной группы, при этом если посмотреть свойства физического сетевого адаптера, то мы увидим, что все компоненты кроме протокола мультиплексора сетевого адаптера отключены (выделено желтым).


Удалить группу можно также командой power shell: Remove-NetLbfoTeam -Name First-team или в графическом интерфейсе:

Установка драйвера сетевой карты Intel I219-V в Windows Server 2008/2012/2016

Небольшое лирическое отступление.
Однажды в студеную зимнюю пору, настраивая простенький файл- сервер, столкнулся с проблемой ранее мне не встречавшейся. Удачно установил серверную ОС (это была Windows Server 2008 R2) на не серверное оборудование и уже хотел открывать шампанское, но компания intel видимо решила, что жизнь моя проходит слишком легко и беззаботно. Установив почти все драйвера, стоп-кран сработал на драйвере сетевого контроллера!

Попробовал пару раз установить драйвер разными методами и понял, что проблема в самом драйвере. Найденная на официальном сайте intel, последняя версия драйвера ситуацию никак не изменила. Все та же ошибка. Полез ковырять инет и поиск показал, что есть причина моих (и многих других людей) бед. Как оказалось, маркетологи в Intel, перетерев тему с маркетологами microsoft, решили, что позволять ставить серверные ОСи на бытовые железки, слишком щедрый жест с их стороны. Отныне, хочешь серверную операционку – купи серверную железку! Видимо, чтобы глянуть, как у потребителя пройдет привыкание к новым реалиям, решили начать с малого – сетевых контроллеров:). К счастью, серверные и персональные версии Windows похожи друг на друга, а это часто дает возможность просто модифицировать драйвер. Данный случай не исключение.

Я использовал Windows Server 2008 R2 и сис.плату B150M-D3H со встроенным сетевым контроллером intel i219-v. Однако описанный метод актуален и для i217-v, и для i218-v, и для всех прочих новых сетевых intel серии PRO1000, и всех официально поддерживаемых версий ОС Windows Server.

Итак, все по порядку.

Переходим в Диспетчер устройств и смотрим ИД вашей сетевой

Я имел дело с I219-V с идентификатором поставщика и оборудования VEN_8086&DEV_15B8

Скачиваем последнюю версию драйвера intel network adapter driver с официального сайта Intel
Я не стал мелочиться и скачал Intel® Ethernet Adapters Connections CD

Распаковываем скачанный архив и переходим в PRO1000\Winx64\NDIS62 если у вас Windows Server 2008 R2. Или выбираем другую папку соответственно вашей ОС.

NDIS61 — для Windows Vista/Server 2008,
NDIS62 — для Windows 7/Server 2008 R2
NDIS63 — для Windows 8/Server 2012
NDIS64 — для Windows 8.1/Server 2012 R2
NDIS65 — для Windows 10/Server 2016

Внутри находим и открываем файл e1d62x64.inf (Для других версий Windows он соответственно будет иметь имя e1d63x64.inf, e1d65x64.inf )

Находим раздел [ControlFlags] и удаляем две строчки, что ниже [ControlFlags]

Должно получиться так

Далее в разделе [Intel.NTamd64.6.1.1] согласно ИД оборудования вашей карты ищем подходящие строки. Выделяем их и копируем в буфер

Переходим в следующий раздел [Intel.NTamd64.6.1] и в его конец вставляем скопированные строки
Должно получиться так

Сохраняем изменения и закрываем файл.

Если у вас Windows Server 2012 или более поздняя версия, то перед установкой модифицированного драйвера необходимо отключить проверку подписи драйверов. Иначе установка не пройдет. Делается это из командной строки следующими командами:

bcdedit -set loadoptions DISABLE_INTEGRITY_CHECKS
bcdedit -set TESTSIGNING ON

обязательно перезагружаем компьютер

пробуем запустить инсталляцию через установщик Autorun.exe, который находится в корне нашей распакованной папки с драйверами. Или просто указываем папку с модифицированным драйвером в случае установки через диспетчер устройств. В процессе установки появится ругань на неподписанный драйвер — как обычно, не обращаем внимания…

В итоге установка проходит без проблем.

Если у вас Windows Server 2008, то установка закончена.
Если у вас Windows Server 2012 или более поздняя версия, то необходимо снова включить проверку подписи. Делается это из командной строки следующими командами:

bcdedit -set loadoptions ENABLE_INTEGRITY_CHECKS
bcdedit -set TESTSIGNING OFF

Вот и все. Удачи…

56 Replies to “Установка драйвера сетевой карты Intel I219-V в Windows Server 2008/2012/2016”

Столкнулся с такой проблемой. Два часа не мог ни чего сделать. Нашел случайно эту статью, сделал как вы написали. И о чудо. Вы просто волшебник. Спасибо большое за совет.

Охренеть, ты красавчик))) тоже случайно совершенно наткнулся на статью!
Работает на Server 2016, проверено

Да и еще одно но у кого стоит безопасная загрузка — ничего не выйдет… а так работает

Читайте также:  Сетевое обнаружение отключено как включить windows server 2019

Решение для тех у кого UEFI + Безопасная загрузка:

Спасибо. Работает на W2K8 R2.

Огромное спасибо! Очень помогло!

Очень радует, что по нашей земле обетованной ходят такие люди, как автор этой статьи!
СПАСИБО!

Огромное спасибо. Столкнулся с такой проблемой. Пол дня потерял не мог ни чего сделать, все форумы прочитал, случайно наткнулся на Вашу статью, сделал как вы написали. И о чудо все заработало Спасибо большущие за совет.

Вот от всей души тебе огромное спасибо. Пол дня промучался, не мог понять в чем проблема. Долбанные капиталисты.

Гораздо проще проблема решается принудительной установкой драйвера от Intel 219-LM, это одинаковые (физически) адаптеры. И не нужно отключать цифровую подпись драйверов…. Кстати, в случае Server 2016 драйвер на 219-LM уже в составе дистрибутива 😉

Да но если на Server 2016 установить Intel 219-LM вместо Intel 219-V то система автообновления всегда будет предлагать скачть новый драйвер Intel 219-V ))) угараю над Microsoft, скачать то он скачает его, а вот устанавливать откажется ))) и так при каждом обновлении он будет предлагать

Чет у них видно руки кривые )))

Супер!
Прошелся по инструкции и решил проблему с сетевым драйвером win 2012.
Пашет !

Привет тебе, добрый человек! Висит твоя страница в закладках со времен когда я столкнулся с микротиками. Просматриваю редко, но периодично. Так вот, мучался очень давно на Win server 2016 с драйвером на i219-V. Решилось установкой драйвера от i219-LM через выбор руками. Встал, работает по сей день исправно на 1 gbit скорости. Сервер используется в качестве файлопомойки и sql сервера под 1С на 25 юзеров.

Спасибо огромное.
Помогло.
Побольше таких как ты в интернете)

Автору огромный респект.
По инструкции решил проблему на Hyper-V 2012 R2

В ТОП! Если снова пишет в HYPER-V 2016 «нет активных сетевых адаптеров» то просто понажимайте 8 и энтер несколько раз, должно помочь 😉

Большое спасибо, очень помогло

Огромное спасибо, все решилось в 2008R2 !

Добрый вечер, установил Windows server 2016 standard, RUS, 64 BIT, сделал как написано, установил драйвер, но постоянно пропадает линк и не видит сеть и нету интернета, помогите, может кто-нибудь сталкивался с такой проблемой, да , кстати, сетевуха встроенная на чипсете intel. Спасибо!

Пробуйте установкой драйвера от i219-LM через выбор руками из имеющихся в ОС драйверов.
Проверено на Windows Server 2016 Datacenter, ENG, 64 BIT

Спасибо!
Распакованный драйвер брал отсюда: https://github.com/FerdinandvHagen/I211AT-Windows-Server-2016 там уже пропатченный для I211, с этими изменениями на обе сетевушки встали дрова.

Автору громадное СПАСИБО!
На Server 2016 заработало, а ведь хотел уже внешнюю сетевуху ставить

ай спасибо тебе. server 2016 колупался несколько часов пока эту статью не увидел

Network Recommendations for a Hyper-V Cluster in Windows Server 2012

Applies To: Windows Server 2012

There are several different types of network traffic that you must consider and plan for when you deploy a highly available Hyper-V solution. You should design your network configuration with the following goals in mind:

To ensure network quality of service

To provide network redundancy

To isolate traffic to defined networks

Where applicable, take advantage of Server Message Block (SMB) Multichannel

This topic provides network configuration recommendations that are specific to a Hyper-V cluster that is running Windows Server 2012. It includes an overview of the different network traffic types, recommendations for how to isolate traffic, recommendations for features such as NIC Teaming, Quality of Service (QoS) and Virtual Machine Queue (VMQ), and a Windows PowerShell script that shows an example of converged networking, where the network traffic on a Hyper-V cluster is routed through one external virtual switch.

Windows Server 2012 supports the concept of converged networking, where different types of network traffic share the same Ethernet network infrastructure. In previous versions of Windows Server, the typical recommendation for a failover cluster was to dedicate separate physical network adapters to different traffic types. Improvements in Windows Server 2012, such as Hyper-V QoS and the ability to add virtual network adapters to the management operating system enable you to consolidate the network traffic on fewer physical adapters. Combined with traffic isolation methods such as VLANs, you can isolate and control the network traffic.

If you use System Center Virtual Machine Manager (VMM) to create or manage Hyper-V clusters, you must use VMM to configure the network settings that are described in this topic.

In this topic:

Overview of different network traffic types

When you deploy a Hyper-V cluster, you must plan for several types of network traffic. The following table summarizes the different traffic types.

Network Traffic Type Description
Management — Provides connectivity between the server that is running Hyper-V and basic infrastructure functionality.
— Used to manage the Hyper-V management operating system and virtual machines.
Cluster — Used for inter-node cluster communication such as the cluster heartbeat and Cluster Shared Volumes (CSV) redirection.
Live migration — Used for virtual machine live migration.
Storage — Used for SMB traffic or for iSCSI traffic.
Replica traffic — Used for virtual machine replication through the Hyper-V Replica feature.
Virtual machine access — Used for virtual machine connectivity.
— Typically requires external network connectivity to service client requests.

The following sections provide more detailed information about each network traffic type.

Management traffic

A management network provides connectivity between the operating system of the physical Hyper-V host (also known as the management operating system) and basic infrastructure functionality such as Active Directory Domain Services (AD DS), Domain Name System (DNS), and Windows Server Update Services (WSUS). It is also used for management of the server that is running Hyper-V and the virtual machines.

The management network must have connectivity between all required infrastructure, and to any location from which you want to manage the server.

Cluster traffic

A failover cluster monitors and communicates the cluster state between all members of the cluster. This communication is very important to maintain cluster health. If a cluster node does not communicate a regular health check (known as the cluster heartbeat), the cluster considers the node down and removes the node from cluster membership. The cluster then transfers the workload to another cluster node.

Inter-node cluster communication also includes traffic that is associated with CSV. For CSV, where all nodes of a cluster can access shared block-level storage simultaneously, the nodes in the cluster must communicate to orchestrate storage-related activities. Also, if a cluster node loses its direct connection to the underlying CSV storage, CSV has resiliency features which redirect the storage I/O over the network to another cluster node that can access the storage.

Live migration traffic

Live migration enables the transparent movement of running virtual machines from one Hyper-V host to another without a dropped network connection or perceived downtime.

We recommend that you use a dedicated network or VLAN for live migration traffic to ensure quality of service and for traffic isolation and security. Live migration traffic can saturate network links. This can cause other traffic to experience increased latency. The time it takes to fully migrate one or more virtual machines depends on the throughput of the live migration network. Therefore, you must ensure that you configure the appropriate quality of service for this traffic. To provide the best performance, live migration traffic is not encrypted.

You can designate multiple networks as live migration networks in a prioritized list. For example, you may have one migration network for cluster nodes in the same cluster that is fast (10 GB), and a second migration network for cross-cluster migrations that is slower (1 GB).

All Hyper-V hosts that can initiate or receive a live migration must have connectivity to a network that is configured to allow live migrations. Because live migration can occur between nodes in the same cluster, between nodes in different clusters, and between a cluster and a stand-alone Hyper-V host, make sure that all these servers can access a live migration-enabled network.

Storage traffic

For a virtual machine to be highly available, all members of the Hyper-V cluster must be able to access the virtual machine state. This includes the configuration state and the virtual hard disks. To meet this requirement, you must have shared storage.

In Windows Server 2012, there are two ways that you can provide shared storage:

Shared block storage. Shared block storage options include Fibre Channel, Fibre Channel over Ethernet (FCoE), iSCSI, and shared Serial Attached SCSI (SAS).

File-based storage. Remote file-based storage is provided through SMB 3.0.

SMB 3.0 includes new functionality known as SMB Multichannel. SMB Multichannel automatically detects and uses multiple network interfaces to deliver high performance and highly reliable storage connectivity.

By default, SMB Multichannel is enabled, and requires no additional configuration. You should use at least two network adapters of the same type and speed so that SMB Multichannel is in effect. Network adapters that support RDMA (Remote Direct Memory Access) are recommended but not required.

SMB 3.0 also automatically discovers and takes advantage of available hardware offloads, such as RDMA. A feature known as SMB Direct supports the use of network adapters that have RDMA capability. SMB Direct provides the best performance possible while also reducing file server and client overhead.

The NIC Teaming feature is incompatible with RDMA-capable network adapters. Therefore, if you intend to use the RDMA capabilities of the network adapter, do not team those adapters.

Both iSCSI and SMB use the network to connect the storage to cluster members. Because reliable storage connectivity and performance is very important for Hyper-V virtual machines, we recommend that you use multiple networks (physical or logical) to ensure that these requirements are achieved.

Replica traffic

Hyper-V Replica provides asynchronous replication of Hyper-V virtual machines between two hosting servers or Hyper-V clusters. Replica traffic occurs between the primary and Replica sites.

Hyper-V Replica automatically discovers and uses available network interfaces to transmit replication traffic. To throttle and control the replica traffic bandwidth, you can define QoS policies with minimum bandwidth weight.

If you use certificate-based authentication, Hyper-V Replica encrypts the traffic. If you use Kerberos-based authentication, traffic is not encrypted.

Virtual machine access traffic

Most virtual machines require some form of network or Internet connectivity. For example, workloads that are running on virtual machines typically require external network connectivity to service client requests. This can include tenant access in a hosted cloud implementation. Because multiple subclasses of traffic may exist, such as traffic that is internal to the datacenter and traffic that is external (for example to a computer outside the datacenter or to the Internet); one or more networks are required for these virtual machines to communicate.

To separate virtual machine traffic from the management operating system, we recommend that you use VLANs which are not exposed to the management operating system.

How to isolate the network traffic on a Hyper-V cluster

To provide the most consistent performance and functionality, and to improve network security, we recommend that you isolate the different types of network traffic.

Realize that if you want to have a physical or logical network that is dedicated to a specific traffic type, you must assign each physical or virtual network adapter to a unique subnet. For each cluster node, Failover Clustering recognizes only one IP address per subnet.

Isolate traffic on the management network

We recommend that you use a firewall or IPsec encryption, or both, to isolate management traffic. In addition, you can use auditing to ensure that only defined and allowed communication is transmitted through the management network.

Isolate traffic on the cluster network

To isolate inter-node cluster traffic, you can configure a network to either allow cluster network communication or not to allow cluster network communication. For a network that allows cluster network communication, you can also configure whether to allow clients to connect through the network. (This includes client and management operating system access.)

A failover cluster can use any network that allows cluster network communication for cluster monitoring, state communication, and for CSV-related communication.

To configure a network to allow or not to allow cluster network communication, you can use Failover Cluster Manager or Windows PowerShell. To use Failover Cluster Manager, click Networks in the navigation tree. In the Networks pane, right-click a network, and then click Properties.

Figure 1. Failover Cluster Manager network properties

The following Windows PowerShell example configures a network named Management Network to allow cluster and client connectivity.

The Role property has the following possible values.

Value Network Setting
0 Do not allow cluster network communication
1 Allow cluster network communication only
3 Allow cluster network communication and client connectivity

The following table shows the recommended settings for each type of network traffic. Realize that virtual machine access traffic is not listed because these networks should be isolated from the management operating system by using VLANs that are not exposed to the host. Therefore, virtual machine networks should not appear in Failover Cluster Manager as cluster networks.

Network Type Recommended Setting
Management Both of the following:

— Allow cluster network communication on this network
— Allow clients to connect through this network

Cluster Allow cluster network communication on this network Note: Clear the Allow clients to connect through this network check box.
Live migration Allow cluster network communication on this network Note: Clear the Allow clients to connect through this network check box.
Storage Do not allow cluster network communication on this network
Replica traffic Both of the following:

— Allow cluster network communication on this network
— Allow clients to connect through this network

Isolate traffic on the live migration network

By default, live migration traffic uses the cluster network topology to discover available networks and to establish priority. However, you can manually configure live migration preferences to isolate live migration traffic to only the networks that you define. To do this, you can use Failover Cluster Manager or Windows PowerShell. To use Failover Cluster Manager, in the navigation tree, right-click Networks, and then click Live Migration Settings.

Figure 2. Live migration settings in Failover Cluster Manager

The following Windows PowerShell example enables live migration traffic only on a network that is named Migration_Network.

Isolate traffic on the storage network

To isolate SMB storage traffic, you can use Windows PowerShell to set SMB Multichannel constraints. SMB Multichannel constraints restrict SMB communication between a given file server and the Hyper-V host to one or more defined network interfaces.

For example, the following Windows PowerShell command sets a constraint for SMB traffic from the file server FileServer1 to the network interfaces SMB1, SMB2, SMB3, and SMB4 on the Hyper-V host from which you run this command.

To isolate iSCSI traffic, configure the iSCSI target with interfaces on a dedicated network (logical or physical). Use the corresponding interfaces on the cluster nodes when you configure the iSCSI initiator.

Isolate traffic for replication

To isolate Hyper-V Replica traffic, we recommend that you use a different subnet for the primary and Replica sites.

If you want to isolate the replica traffic to a particular network adapter, you can define a persistent static route which redirects the network traffic to the defined network adapter. To specify a static route, use the following command:

route add mask if -p

For example, to add a static route to the 10.1.17.0 network (example network of the Replica site) that uses a subnet mask of 255.255.255.0, a gateway of 10.0.17.1 (example IP address of the primary site), where the interface number for the adapter that you want to dedicate to replica traffic is 8, run the following command:

route add 10.1.17.1 mask 255.255.255.0 10.0.17.1 if 8 -p

NIC Teaming (LBFO) recommendations

We recommend that you team physical network adapters in the management operating system. This provides bandwidth aggregation and network traffic failover if a network hardware failure or outage occurs.

The NIC Teaming feature, also known as load balancing and failover (LBFO), provides two basic sets of algorithms for teaming.

Switch-dependent modes. Requires the switch to participate in the teaming process. Typically requires all the network adapters in the team to be connected to the same switch.

Switch-independent modes. Does not require the switch to participate in the teaming process. Although not required, team network adapters can be connected to different switches.

Both modes provide for bandwidth aggregation and traffic failover if a network adapter failure or network disconnection occurs. However, in most cases only switch-independent teaming provides traffic failover for a switch failure.

NIC Teaming also provides a traffic distribution algorithm that is optimized for Hyper-V workloads. This algorithm is referred to as the Hyper-V port load balancing mode. This mode distributes the traffic based on the MAC address of the virtual network adapters. The algorithm uses round robin as the load-balancing mechanism. For example, on a server that has two teamed physical network adapters and four virtual network adapters, the first and third virtual network adapter will use the first physical adapter, and the second and fourth virtual network adapter will use the second physical adapter. Hyper-V port mode also enables the use of hardware offloads such as virtual machine queue (VMQ) which reduces CPU overhead for networking operations.

Recommendations

For a clustered Hyper-V deployment, we recommend that you use the following settings when you configure the additional properties of a team.

Property Name Recommended Setting
Teaming mode Switch Independent (the default setting)
Load balancing mode Hyper-V Port

NIC teaming will effectively disable the RDMA capability of the network adapters. If you want to use SMB Direct and the RDMA capability of the network adapters, you should not use NIC Teaming.

For more information about the NIC Teaming modes and how to configure NIC Teaming settings, see Windows Server 2012 NIC Teaming (LBFO) Deployment and Management and NIC Teaming Overview.

Quality of Service (QoS) recommendations

You can use QoS technologies that are available in Windows Server 2012 to meet the service requirements of a workload or an application. QoS provides the following:

Measures network bandwidth, detects changing network conditions (such as congestion or availability of bandwidth), and prioritizes — or throttles — network traffic.

Enables you to converge multiple types of network traffic on a single adapter.

Includes a minimum bandwidth feature which guarantees a certain amount of bandwidth to a given type of traffic.

We recommend that you configure appropriate Hyper-V QoS on the virtual switch to ensure that network requirements are met for all appropriate types of network traffic on the Hyper-V cluster.

You can use QoS to control outbound traffic, but not the inbound traffic. For example, with Hyper-V Replica, you can use QoS to control outbound traffic (from the primary server), but not the inbound traffic (from the Replica server).

Recommendations

For a Hyper-V cluster, we recommend that you configure Hyper-V QoS that applies to the virtual switch. When you configure QoS, do the following:

Configure minimum bandwidth in weight mode instead of in bits per second. Minimum bandwidth specified by weight is more flexible and it is compatible with other features, such as live migration and NIC Teaming. For more information, see the MinimumBandwidthMode parameter in New-VMSwitch.

Enable and configure QoS for all virtual network adapters. Assign a weight to all virtual adapters. For more information, see Set-VMNetworkAdapter. To make sure that all virtual adapters have a weight, configure the DefaultFlowMinimumBandwidthWeight parameter on the virtual switch to a reasonable value. For more information, see Set-VMSwitch.

The following table recommends some generic weight values. You can assign a value from 1 to 100. For guidelines to consider when you assign weight values, see Guidelines for using Minimum Bandwidth.

Network Classification Weight
Default weight 0
Virtual machine access 1, 3 or 5 (low, medium and high-throughput virtual machines)
Cluster 10
Management 10
Replica traffic 10
Live migration 40
Storage 40

Virtual machine queue (VMQ) recommendations

Virtual machine queue (VMQ) is a feature that is available to computers that have VMQ-capable network hardware. VMQ uses hardware packet filtering to deliver packet data from an external virtual network directly to virtual network adapters. This reduces the overhead of routing packets. When VMQ is enabled, a dedicated queue is established on the physical network adapter for each virtual network adapter that has requested a queue.

Not all physical network adapters support VMQ. Those that do support VMQ will have a fixed number of queues available, and the number will vary. To determine whether a network adapter supports VMQ, and how many queues they support, use the Get-NetAdapterVmq cmdlet.

You can assign virtual machine queues to any virtual network adapter. This includes virtual network adapters that are exposed to the management operating system. Queues are assigned according to a weight value, in a first-come first-serve manner. By default, all virtual adapters have a weight of 100.

Recommendations

We recommend that you increase the VMQ weight for interfaces with heavy inbound traffic, such as storage and live migration networks. To do this, use the Set-VMNetworkAdapter Windows PowerShell cmdlet.

Example of converged networking: routing traffic through one Hyper-V virtual switch

The following Windows PowerShell script shows an example of how you can route traffic on a Hyper-V cluster through one Hyper-V external virtual switch. The example uses two physical 10 GB network adapters that are teamed by using the NIC Teaming feature. The script configures a Hyper-V cluster node with a management interface, a live migration interface, a cluster interface, and four SMB interfaces. After the script, there is more information about how to add an interface for Hyper-V Replica traffic. The following diagram shows the example network configuration.

Figure 3. Example Hyper-V cluster network configuration

The example also configures network isolation which restricts cluster traffic from the management interface, restricts SMB traffic to the SMB interfaces, and restricts live migration traffic to the live migration interface.

Hyper-V Replica considerations

If you also use Hyper-V Replica in your environment, you can add another virtual network adapter to the management operating system for replica traffic. For example:

If you are instead using policy-based QoS, where you can throttle outgoing traffic regardless of the interface on which it is sent, you can use either of the following methods to throttle Hyper-V Replica traffic: Create a QoS policy that is based on the destination port. In the following example, the network listener on the Replica server or cluster has been configured to use port 8080 to receive replication traffic.

Appendix: Encryption

Cluster traffic

By default, cluster communication is not encrypted. You can enable encryption if you want. However, realize that there is performance overhead that is associated with encryption. To enable encryption, you can use the following Windows PowerShell command to set the security level for the cluster.

The following table shows the different security level values.

Security Description Value
Clear text 0
Signed (default) 1
Encrypted 2

Live migration traffic

Live migration traffic is not encrypted. You can enable IPsec or other network layer encryption technologies if you want. However, realize that encryption technologies typically affect performance.

SMB traffic

By default, SMB traffic is not encrypted. Therefore, we recommend that you use a dedicated network (physical or logical) or use encryption. For SMB traffic, you can use SMB encryption, layer-2 or layer-3 encryption. SMB encryption is the preferred method.

Replica traffic

If you use Kerberos-based authentication, Hyper-V Replica traffic is not encrypted. We strongly recommend that you encrypt replication traffic that transits public networks over the WAN or the Internet. We recommend Secure Sockets Layer (SSL) encryption as the encryption method. You can also use IPsec. However, realize that using IPsec may significantly affect performance.

Читайте также:  Принтер canon f158200 драйвер для windows
Оцените статью