Глава 3. Виртуальные сетевые среды

Некий обычный сервер обладает одним или более сетевыми адаптерами, которые настраиваются с какими- то адресами IPv4 и IPv6, либо статически, либо динамически с применением таких служб как DHCP (Dynamic Host Configuration Protocol, Протокола динамической конфигурации хоста). Такой сервер может быть частью какой- то VLAN для предоставления изоляции и управления широковещательным обменом. Это может потребовать различных сетевых соединений для подключения к различным сетевым средам, таким как некие обособленные сети без маршрутизации для взаимодействия в кластере между серверами в каком- то отказоустойчивом кластере, отдельной сетевой среды для обмена iSCSI, отдельной сети управления и тому подобных. При виртуализации имеющиеся требования для сетевых подключений настолько же важны, как и для физического сервера. Однако доступны дополнительные возможности, поскольку в отдельным физическом активе доступно множество серверных экземпляров. Более того, в некоторых случаях им требуется взаимодействие только друг с другом, а не внешним образом с их хостом виртуализации.

Виртуальные машины имеют большое число виртуальных ресурсов. Одним из типов является определённый виртуальный сетевой адаптер (как уже обсуждалось в предыдущей главе, для виртуальной машины 1 поколения доступны два вида сетевых адаптеров, однако их возможности подключения одни и те же). Один или более виртуальных сетевых адаптеров доставляются в некую виртуальную машину и затем каждый виртуальный адаптер подключается к какому- то виртуальному коммутатору, который был создан на имеющемся уровне хоста Hyper-V. Хост Hyper-V может иметь созданными множество виртуальных коммутаторов. Доступны три вида виртуальных коммутаторов: внешние, внутренние и частные, как это показано на Рисунке 3.1.

 

Внешние виртуальные сети

Внешние виртуальные сети ограничены в своём хосте некоторой физической сетевой картой. Виртуальные машины имеют доступ к такой физической сетевой среде через данную физическую NIC, которая подключена к своему внешнему коммутатору и к которому присоединён его виртуальный сетевой адаптер. Виртуальные машины в одном и том же виртуальном коммутаторе могут также взаимодействовать друг с другом. Если они расположены в различных коммутаторах, которые способны взаимодействовать через имеющуюся физическую сетевую среду (то есть посредством маршрутизации), тогда они тоже могут взаимодействовать. Всякая виртуальная машина видит некое виртуальное сетевое устройство, а её хост Hyper-V всё ещё обнаруживает необходимый сетевой адаптер, однако более он не применяет его. Такое сетевое устройство в своём хосте Hyper-V является определённой физической NIC, которая ограничена лишь расширяемым виртуальным коммутатором своего хоста, что означает, что он применяется неким виртуальным коммутатором Hyper-V.

Сам по себе хост Hyper-V, его ОС управления, также обладают возможностью продолжать применять сетевой адаптер при создании виртуального коммутатора, даже если этот адаптер был назначен виртуальному коммутатору. Совместное применение данного адаптера работает посредством создания некоторого виртуального сетевого адаптера в разделе управления, который подключён к самому виртуальному коммутатору Hyper-V с тем, чтобы всё взаимодействие проходило сквозь такой виртуальный коммутатор, который исключительно обладает данным физическим сетевым адаптером. В Windows Server 2012 и выше имеется возможность создавать множество виртуальных сетевых адаптеров в данном разделе управления, что открывает новые варианты и сценарии настройки, которые я поясню позднее в этой главе. Если в рассматриваемом хосте Hyper-V у вас имеется только один сетевой адаптер, вам следует явно выбрать такой вариант для совместного применения данного сетевого адаптера с его операционной системой управления. Этот вариант может быть включён или отключён в любой момент после создания такого внешнего коммутатора.

 

Внутренние виртуальные сети

Внутренние виртуальные сети не ограничены каким- то физическим NIC, а следовательно, не могут осуществлять доступ к любой машине вне данного физического сервера. Некая внутренняя сетевая среда видна самому хосту Hyper-V и всем виртуальным машинам, что означает что она может применяться для взаимодействия между виртуальными машинами, а также между виртуальными машинами и их хостом Hyper-V. Она может быть полезной когда в таком разделе управления вы размещаете службы, например, некие цели iSCSI, для которых вы желаете иметь возможность применения в своих виртуальных машинах. Как для самого хоста Hyper-V, так и для виртуальных машин, видно некое сетевое устройство, которое представлено такой внутренней виртуальной сетевой средой.

 

Частные виртуальные сети

Частные виртуальные сети видны только в виртуальных машинах и они применяются для виртуальных машин чтобы они взаимодействовали друг с другом. Данный тип сетевой среды может применяться для виртуальных машин, которые являются частью некого гостевого кластера. Такая частная сетевая среда может применяться для самой сети кластера, в том представлении, что все хосты такого кластера исполняются в одном и том же хосте Hyper-V.

В большинстве случаев применяется некий внешний коммутатор, так как основной части виртуальных машин требуется взаимодействие за пределами своего локального хоста Hyper-V при использовании внутренней или частной сетевых сред для сценариев тестирования или нишевого сокрытия, скажем как это имеет место в случае определённого гостевого кластера, который настраивается в каком- то отдельном хосте. Однако, более вероятно, когда вы создали некий промышленный гостевой кластер в виртуальных машинах, вы пожелаете распространить его на множество хостов Hyper-V для защиты от отказов хоста, и в таком случае понадобился бы некий внешний коммутатор.

Некий отдельный физический сетевой адаптер может быть ограничен исключительно отдельным внешним коммутатором, а в промышленных средах в таком хосте Hyper-V распространено применения группирования (Teaming) NIC. Это делает возможным связывать воедино множество сетевых адаптеров и выставлять их в операционную систему как некий отдельный групповой (teamed) сетевой адаптер, который проявляет устойчивость к отказу отдельного сетевого адаптера, а также предоставляет агрегированную полосу пропускания, которая делает возможным взаимодействие с более высокой скоростью. (Относительно этого имеется множество предостережений, которые я сделаю позднее в данной главе). Некий групповой сетевой адаптер может также применяться и ограничиваться каким- то внешним коммутатором с Hyper-V, давая дополнительную устойчивость коммутации всем виртуальным сетевым адаптерам для взаимодействия с таким коммутатором.

Если у вас в некотором хосте имеется целый ряд сетевых адаптеров и они подключены к различным сетевым средам (которые, скажем, для изолирования обмена могут применять VLAN), тогда, если виртуальным машинам требуется осуществлять доступ к таким сетям, вы будете создавать множество внешних виртуальных коммутаторов, причём каждый из них ограничен своим собственным физическим сетевым адаптером, подключённым к одной из таких сетевых сред. Это может показаться очевидным, однако виртуальные машины способны взаимодействовать только с прочими службами, которые доступны в такой физической сетевой среде или же могут выполнять через эту сетевую среду маршрутизацию. По существу, через такой виртуальный коммутатор вы расширяете имеющиеся связи своего физического сетевого адаптера в виртуальных машинах.

К одним и тем же виртуальным сетевым средам может быть подключено множество виртуальных машин, причём одно из замечательных свойств состоит в том, что если множество виртуальных машин в одном и том же хосте Hyper-V подключены к одной и той же внешней сетевой среде и взаимодействуют через такую сеть, весь их обмен никогда не поступает в сам физический сетевой адаптер. Имеющийся сетевой стек Hyper-V является достаточно интеллектуальным чтобы понимать что такой обмен следует в другую подключённую к тому же самому коммутатору ВМ и напрямую отправляет весь такой обмен в эту ВМ, даже не прикасаясь к имеющемуся физическому сетевому адаптеру или физической сети.

Когда вы начинаете создавать виртуальные коммутаторы, важно применять согласованную схему именования по всем хостам для таких коммутаторов. Это важно, поскольку когда виртуальные машины перемещаются между хостами Hyper-V, они ищут некий виртуальный коммутатор с тем же самым названием , как их имеющийся виртуальный коммутатор чтобы подключиться к его целевому хосту. Если необходимый виртуальный коммутатор отсутствует, такой виртуальный сетевой адаптер оказывается отсоединённым - а следовательно данная виртуальная машина утратит своё подключение. В отказоустойчивых кластерах критически важным является согласованное именование, при котором виртуальные машины могут свободно перемещаться между узлами кластера. Начиная с Windows Server 2012, и в последующих версиях, имеется возможность перемещения виртуальных машин между любыми хостами без совместно используемых ресурсов и времени простоя, причём при этом важно иметь согласованное именование виртуальных коммутаторов во всех хостах Hyper-V. Теперь уделите немного времени на то, чтобы подумать о хорошей стратегии именования и придерживайтесь её.

Также имеется возможность создавать списки управления доступом с названием списки управления доступом расширенного порта (extended port access control lists) в рамках имеющегося виртуального коммутатора, чтобы разрешать и блокировать взаимодействие между виртуальными машинами, подключаемыми к такому коммутатору на основе адреса IP, протокола или порта. Дополнительно можно создавать правила с запоминанием состояния чтобы разрешать взаимодействие только в случае соответствия определённых условий. Microsoft имеет подробное руководство по применению ACL в следующем месте: http://technet.microsoft.com/en-us/library/dn375962.aspx.

При применении Программно определяемых сетевых сред (Software Defined Networking) v2 доступно даже более богатое множество контроля за обменом через встроенный межсетевой экран центра обработки данных и прочие типы расширений.

Когда в сервере включена роль Hyper-V, вы задали некий вариант создания какого- то внешнего коммутатора выбирая сетевой адаптер в своём хосте. Если вы выбираете такой вариант, виртуальный коммутатор уже представлен в данном хосте и будет автоматически настраиваете на включение управления операционной системой для совместного применения этого адаптера с тем, чтобы какой- то внешний виртуальный адаптер Ethernet Hyper-V будет представлен в своём хосте Hyper-V. В целом, я предпочитаю не создавать такие виртуальные коммутаторы в процессе установки роли Hyper-V, а настраивать их после установки. К тому же, как вы прочитаете позднее, когда вы производите развёртывание в неком промышленном применении и вы пользуетесь System Center, тогда Virtual Machine Manager способен выполнить для вас всю необходимую настройку. Тем не менее, я пройдусь по настройке виртуальных коммутатор в вручную:

Создание коммутаторов также допустимо и при помощи PowerShell. приводимые ниже команды создают некий внешний (без его разделения с управлением операционной системы), какие- то внутренний и частный коммутаторы и затем перечисляют коммутаторы, обладающие типом External:

#Создаём новый внешний (в неявном виде внешний, поскольку передан адаптер)
New-VMSwitch -Name "External Switch" -Notes "External Connectivity" `
-NetAdapterName "VM NIC" -AllowManagementOS $false
#Создаём новый внутренний (видимый в хосте) и частный (только для вм)
New-VMSwitch -Name "Internal Switch" -SwitchType Internal
New-VMSwitch -Name "Private Switch" -SwitchType Private
		

После создания коммутатора вы можете просматривать его в Диспетчере виртуальных коммутаторов и изменять его свойства. В любой момент времени можно изменять тип коммутатора, пока он не является внешним виртуальным коммутатором с включённым SR IOV. В таком случае его тип не может изменяться без удаления и повторного его создания. Виртуальные сетевые адаптеры могут подключаться к этому коммутатору через соответствующие свойства такого виртуального сетевого адаптера.

Расширяемый коммутатор (наращиваемый) Hyper-V предоставляет разнообразные возможности, которые можно применять имеющимися виртуальными сетевыми адаптерами, подключёнными к соответствующим портам виртуального коммутатора, включая такие функциональные возможности, как зеркалирование, защиту от мошеннических серверов DHCP и объявлений маршрутизаторов, управление полосой пропускания, поддержка VMQ и многое иное. Тем не менее, хотя этот особый набор возможностей и охватывает большинство сценариев и требований клиентов, он может не покрывать все требования, которые могут иметься у различных клиентов. Те, кто знаком с VMware, возможно слышали о Cisco Nexus 1000V, который доступен для ESXi и, по существу заменяет коммуникационную инфраструктуру VMware. Cisco Nexus 1000V - единственная поддерживаемая VMware модель и основная проблема состоит в том, что не у многих производителей имеются ресурсы для создания полноценной инфраструктуры виртуальной коммутации. В Windows Server 2012 Microsoft пошла иным путём.

Windows Server 2012 ввёл расширяемый коммутатор для Hyper-V. Такой расширяемый коммутатор позволяет сторонним разработчикам подключаться к имеющемуся виртуальному коммутатору Hyper-V в различных точках без необходимости заменять его целиком, тем самым облегчая организациям привнесения дополнительной ценности. Добавление функциональных возможностей в коммутатор Hyper-V было распространено, например, расширение возможностей фильтрации пакетов, межсетевой экран и выявление вторжений на уровне коммутации, переключение передачи, а также утилит для помощи в проверке данных в вашей сетевой среде. Учтите, что Windows уже обладает богатыми возможностями относительно API и взаимодействий со сторонними частями для интеграции со своей операционной системой, в частности драйверы фильтрации NDIS (Network Device Interface Specifcation, Спецификации интерфейса сетевого устройства) и драйверов вызовов WFP (Windows Filtering Platform, Платформ фильтрации Windows). Расширяемый коммутатор Hyper-V применяет те же самые интерфейсы, которые уже применяют партнёры, что позволяет производителям легко приспосабливать решения для интеграции с расширяемым коммутатором Windows 2012 и более поздних версий. Расширение sFlow InMon для отслеживания позволяет анализировать тенденции обмена, у NEC имеется расширение OpenFlow, а 5nine Software обладает полным расширением межсетевого экрана для расширяемого коммутатора Hyper-V.

Коммутатор Hyper-V обладает четырьмя особыми типами расширений, которые перечислены в Таблице 3.1.

Таблица 3-1.Типы расширения для виртуального коммутатора Hyper-V

Расширение	Цель	Примеры	Наращиваемый компонент
Инспекция сетевых пакетов	Инспекция сетевых пакетов, но без их изменения	Сетевой мониторинг	Драйвер фильтрации NDIS
Фильтрация сетевых пакетов	Внедрение в сетевые пакеты, их изменение и отбрасывание	Безопасность	Драйвер фильтрации NDIS
Сетевое продвижение	Стороннее продвижение с обходом передачи по умолчанию	VEPA (Virtual ethernet Port aggregator) и частные сетевые структуры	Драйвер фильтрации NDIS
Межсетевой экран/ выявление вторжений	Фильтрация и изменение пакетов TCP/IP, мониторинг или авторизация подключений, фильтрация защищённого IPsec обмена и фильтрация RPC	Виртуальный межсетевой экран и мониторинг соединений	Драйвер вызовов WFP

В виртуальном коммутаторе могут быть включёнными многие расширения и эти расширения применяются как для входящего, так и для исходящего обмена. Одно большое изменение из Windows Server 2012 состояло в том, что в Windows Server 2012 R2 модуль Hyper-V Network Virtualization (HNV) был перемещён в сам виртуальный коммутатор вместо того чтобы выступать внешним для такого виртуального коммутатора. Это позволяет расширениям коммутатора инспектировать заголовки как поставщика, так и потребителя и, тем самым работать с сетевой виртуализацией. (Дополнительно вы ознакомитесь с этим позднее, но на данный момент: собственно заголовок поставщика это тот пакет, который позволяет Сетевой виртуализации работать в физических сетевых средах, а заголовок потребителя это тот обмен IP, который наблюдают виртуальные машины в виртуальной сетевой среде.) Такое перемещение модуля Сетевой виртуализации также позволило сторонним расширениям продвижения, таким как Cisco Nexus 1000V, работать с Сетевой виртуализацией, что не было вариантом для Windows Server 2012. И да, Cisco обладает Nexus 1000V для Hyper-V, который работает с коммутатором Hyper-V вместо его замены целиком. Это важно, поскольку многие организации пользуются сетевыми решениями Cisco, а Nexus 1000V позволяет превращать управление в единообразное как в физической, так и в виртуальной сетевых средах через набор инструментария сетевого управления Cisco.

Расширяемый коммутатор Windows Server 2012 R2 также поддерживает гибридную передачу, которая позволяет передавать пакеты в различные агенты продвижения на основе значения типа пакета. Например, допустим, установлено расширение Cisco Nexus 100V (агент продвижения). При гибридном продвижении, когда сетевая виртуализация обмена отправляется через такой коммутатор, он вначале бы проходил через имеющийся модуль HNV, а затем в свой агент продвижения, Nexus 1000V. Когда этот обмен не являлся обменом сетевой виртуализации, установленный модуль HNV обходился бы и этот обмен напрямую бы отправлялся в Nexus 1000V.

Рисунок 3.3 лучше отражает сам расширяемый коммутатор и тот способ, коим обмен протекает через его расширения. Обратите внимание, что этот обмен протекает абсолютно через все уровни самого коммутатора дважды; один раз входя в этот коммутатор (что может происходить со стороны ВМ или от внешних источников), а второй раз выходя из своего коммутатора (и это может происходить в сторону ВМ или внешнего источника).

Расширения для самого коммутатора предоставляются сторонними разработчиками, устанавливаются в соответствующий сервер Hyper-V и затем включаются для виртуального коммутатора. Сам процесс включения достаточно прост. Откройте Диспетчер Виртуального коммутатора, выберите тот виртуальный коммутатор, для которого вы желаете включать расширения и затем выберите дочерний узел Extensions в этом виртуальном коммутаторе. В области расширений блока диалога выберите флаг установки для тех расширений, которые вы намерены включить. И это всё!. Выбранные расширения теперь включены. На Рисунке 3.4 вы можете наблюдать различные типы расширений. Два не являются стандартной частью Hyper-V: Расширение Microsoft VMM DHCPv4 Server Switch и sFlow Traffc Monitoring. После своего включения, расширение sFlow Traffc Monitoring отправляет сведения анализа тенденций и прочее в инструментарий sFlowTrend для их графической визуализации и анализа. Расширение Microsoft VMM DHCPv4 Server Switch это некий фильтр, когда он отслеживает обмен DHCP, он прерывает сами запросы и применяет пулы IP внутри Диспетчера виртуальной машины (VMM) для обслуживания запросов DHCP поверх самого виртуального коммутатора вместо стандартных служб DHCP, позволяя VMM для управления всей конфигурацией IP.

Windows Server 2016 добавил новое встроенное расширение, расширение коммутатора Microsoft Azure VFP. Это Virtual Filtering Platform (VFP), изначально разработанная под Azure, делает для решения сетевой виртуализации Windows Server 2016 допустимыми аналогичные Azure функциональные возможности, именуемые как SDNv2 (Software Defined Networking v2). Первоначально, без VFP, коммутатор ВМ Windows Server 2016 это не более чем оболочка, и именно добавление VFP (которая реализуется в качестве расширения передачи), при включённом SDNv2 в его коммутаторе, зажигает большинство новых функциональных возможностей 2016, например:

Такая Платформа виртуальной фильтрации (VFP) выполняет всю обработку и действует как мозг и собственный виртуальный коммутатор внутри коммутатора ВМ Hyper-V. Рисунок 3.5 показывает её архитектуру.

Основные уровни Платформы виртуальной фильтрации (VFP) реализованы и действуют как обособленные таблицы потоков, которые определяют необходимые правила воздействия на приходящие пакеты от своей физической NIC. Таблица потока состоит из самого потока обмена и определённых типов политик - например, весь обмен к определённой подсети и затем какое- то действие, которое изменяется в зависимости от значения типа политики, применяемого в этой таблице потока. Такое действие может вставляться в сам пакет и отправляться по определённому адресу (VNet), для применения определённого типа NAT (SLB) или даже для блокировки самого пакета (ACL), как то показано на Рисунке 3.6. Обратите внимание, что хотя этот рисунок показывает три типа политик, существуют и прочие, например, таблицы маршрутизации и таблицы зеркалирования портов.

Такие таблицы потока реализуются неким особым образом; вначале реализуются те правила виртуальной сети, которые руководят как будут инкапсулироваться и обрабатываться между самими виртуальной сетью и физической сетью пакеты, затем программно определяемые правила балансировки нагрузки и NAT, а потом, наконец, собственно ACL для управления тем будет ли дозволено обмену достигать определённой ВМ. Сама Платформа виртуальной фильтрации (VFP) также применяется для исходящего от её ВМ обмена, причём все уровни реализуются в обратном порядке (ACL, затем SLB NAT и, наконец, сама виртуальная сеть). Такой порядок приложений логичен: Для входящего обмена, значение адреса IP должно быть первым для соответствия пространству адресов виртуальной сети посредством удаления инкапсуляции, которая в настоящий момент была бы адресована с применением адресного пространства центра обработки данных; затем должна выполняться любая NAT; и, наконец, может применяться ACL. Все эти таблицы потоков наполняются политиками из своего сетевого контроллера, который является другим новым компонентом SDNv2, вдохновлённым Azure, и который поясняется подробнее далее в этой главе.

Применение всех этих уровней правил к каждому из пакетов претерпевало бы значительные штрафы в производительности. Для исправления этого, сама Платформа виртуальной фильтрации (VFP) реализует алгоритм типизации таблиц; для каждого потока (соединения) вырабатывается таблица просмотра хэша кэшируемого потока, и сохраняется весь полный набор правил. Это означает, что только самый первый пакет для каждого потока проходит сквозь все правила (что может быть сложным). Последующие пакеты из того же самого потока будут находить соответствие в установленной таблице кэширования потока и применять её действия. Допустим, окончательный ACL отвергает такой обмен после прохождения всех установленных правил. Кэшируя получаемые результаты для всех последующих пакетов, не требуется выполнять никакой обработки для пакетов, которые в любом случае удаляются немедленно. Это отображено на Рисунке 3.6, и именно это позволяет нашей Платформе виртуальной фильтрации (VFP) поддерживать быстрые сетевые скорости, которые применяются в современных центрах обработки данных - 40 Gbps и выше. Кроме того, применение VFP не блокирует никакие разгрузки вашей NIC, что критически важно для гарантии оптимальной производительности.

На данный момент мы рассмотрели множество технологий, относящихся к сетевым подключениям. Последующие разделы охватят некоторые технологии, которые могут помочь с производительностью сетевого взаимодействия. Хотя они и вносят некие вызовы при попытке максимально возможного своего применения и получения наивысших уровней производительности и полосы пропускания, 40 Gbps и выше становятся всё более распространёнными во многих центрах обработки данных.

SR-IOV и Dynamic Virtual Machine Queue (DVMQ, Динамические очереди Виртуальных машин) являются двумя популярными сетевыми технологиями, которые способны расширить сетевую производительность и могут минимизировать накладные расходы своего гипервизора. Эти технологии отображены на Рисунке 3.37.

SR-IOV (Single-root I/O virtualization, виртуализация ввода/ вывода с единым корнем) позволяет отдельному сетевому устройству PCI Express представлять себя как множество отдельных устройств напрямую в виртуальные машины. {Прим. пер.: и не только сетевых, а например и GPU MxGPU AMD, поскольку функциональность SR- IOV предоставляется на уровне шины PCIe.} В случае SR- IOV и виртуальных машин это означает, что некая физическая NIC может представлять множество виртуальных NIC, которые в терминах SR- IOV именуются виртуальными функциями (VF, virtual functions). Каждая VF имеет тот же самый тип, что и физическая карта и предоставляется напрямую в определённые физические машины. Такое взаимодействие между самой виртуальной машиной и переданной ей VF полностью обходит сам Hyper-V, так как данная ВМ использует Прямой доступ к памяти (DMA, direct memory access) для взаимодействия с самой VF. Это сделано для очень быстрого и имеющего низкую латентность взаимодействия между ВМ и имеющейся VF, так как и сама VMBus и присутствующий коммутатор Hyper-V больше не вовлечены в получаемый между самими физической NIC и ВМ сетевой поток. Благодаря тому, что коммутатор Hyper-V обходится при использовании SR-IOV, SR- IOV не желателен при наличии проверок ACL, QoS, охране DHCP, расширениях сторонних производителей, сетевой виртуализации или прочих применяемых свойствах коммутатора. SR- IOV допустим только когда никакие функции коммутатора не являются активными.

SR- IOV не прерывает Миграцию в реальном времени, технологию, которую мы пока ещё не обсудили, но которая делает возможным для виртуальных машин перемещаться между хостами без времени простоя, причём даже если вы перемещаете некую виртуальную машину на какой- то хост, который не поддерживает SR- IOV. За сценой, при использовании SR- IOV Клиент сетевых виртуальных служб (NetVSC, Network Virtualization Service Client) создаёт два пути для самого сетевого адаптера виртуальной машины внутри такой ВМ. Один путь через SR- IOV, а второй через обычный путь VMBus, который применяет имеющийся коммутатор Hyper-V. Когда данная ВМ исполняется на хосте с SR- IOV, применяется имеющийся путь SR- IOV, а VNBus используется только для управляющего обмена, однако если такая ВМ перемещается в некий хост без SR- IOV, тогда имеющийся путь SR- IOV закрывается со стороны NetVSC, а для данных и для управляющего обмена применяется путь VMBus; причём всё это прозрачно для самой виртуальной машины. Чтобы применить SR- IOV необходимо выбрать опцию использования SR- IOV на момент создания такого виртуального коммутатора, как это отображено на Рисунке 3.38. Если вы применяете командлет New-VMSwitch для создания своего виртуального коммутатора, для включения SR- IOV воспользуйтесь параметром EnableIov $True. Убедитесь что выбран блок пометки Enable SR- IOV в закладке свойств Аппаратного ускорения (Hardware Acceleration) данного виртуального сетевого адаптера для той виртуальной машины, к которой требуется применять SR- IOV.

Чтобы убедиться что ваш сервер поддерживает SR- IOV, вы можете выполнить различные команды. Для начала исполните команду PowerShell Get-VMSwitch | Format-List *iov*, как это показано в следующем фрагменте кода. Отметим, что этот пример показывает что данный сетевой адаптер поддерживает SR- IOV, однако он не поддерживается из- за ограничений имеющейся материнской платы сервера и её BIOS.

PS C:\> Get-VMSwitch | Format-List *iov*

IovEnabled                 : True
IovSupport                 : False
IovSupportReasons          : {To use SR-IOV on this system, the system BIOS must be updated to allow Windows to control
PCI Express. Contact your system manufacturer for an update., This system has a security
vulnerability in the system I/O remapping hardware. As a precaution, the ability to use
SR-IOV has been disabled. You should contact your system manufacturer for an updated BIOS
which enables Root Port Alternate Error Delivery mechanism. If all Virtual Machines
intended to use SR-IOV run trusted workloads, SR-IOV may be enabled by adding a registry
key of type DWORD with value 1 named IOVEnableOverride under 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization and changing
state of the trusted virtual machines. If the system exhibits reduced
performance or instability after SR-IOV devices are assigned to Virtual Machines,
consider disabling the use of SR-IOV.
Чтобы применять SR- IOV в данной системе, BIOS этой системы следует обновить чтобы позволить Windows управлять PCI Express. 
Обратитесь к производителю своего оборудования за обновлением. Данная система имеет некую уязвимость безопасности в своём аппаратном 
переназначении ввода/ вывода. В качестве предосторожности данная возможность применения SR- IOV была отключена. 
Вам следует обратиться к производителю вашей системы для обновления BIOS, которое включит механизм Альтернативной ошибки порта корня. 
Если все Виртуальные машины, которые вы собираетесь применять для SR- IOV исполняют доверенные рабочие нагрузки, SR- IOV может быть 
включён через добавление некоего ключа в реестр с типом DWORD и значением 1 с названием IOVEnableOverride в 
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization и изменить состояние таких доверенных виртуальных машин. 
Если ваша система будет испытывать проблемы со снижением производительности или станет нестабильной после назначения устройств SR- IOV в 
виртуальные машины, рассмотрите отключение применения SR- IOV.}
IovVirtualFunctionCount : 0
IovVirtualFunctionsInUse: 0
IovQueuePairCount       : 0
IovQueuePairsInUse      : 0
		

Следующий вывод получен из другой системы с одним адаптером, который не поддерживает SR- IOV и дополнительными адаптерами, которые поддерживают его:

PS C:\> Get-VMSwitch | Format-List *iov*

IovEnabled              : False
IovSupport              : False
IovSupportReasons       : {This network adapter does not support SR-IOV.}
IovVirtualFunctionCount : 0
IovVirtualFunctionsInUse: 0
IovQueuePairCount       : 0
IovQueuePairsInUse      : 0

IovEnabled              : True
IovSupport              : True
IovSupportReasons       : {OK}
IovVirtualFunctionCount : 62
IovVirtualFunctionsInUse: 10
IovQueuePairCount       : 63
IovQueuePairsInUse      : 10

IovEnabled              : True
IovSupport              : True
IovSupportReasons       : {OK}
IovVirtualFunctionCount : 6
IovVirtualFunctionsInUse: 2
IovQueuePairCount       : 7
IovQueuePairsInUse      : 2
		

Для получения в своей системе информации поддерживающего SR- IOV адаптера вы можете исполнить команду PowerShell Get-NetAdapterSriov; она также отобразит общее число VF, которые поддерживает данная карта. Если некая виртуальная машина успешно использует SR- IOV, тогда при просмотре своей закладки Networking этой виртуальной машины в Диспетчере Hyper-V данное состояние будет отображать "OK (SR-IOV active)".

PS C:\> Get-NetAdapterSriov

Name                : VM NIC
InterfaceDescription: Mellanox ConnectX-3 Pro Ethernet Adapter
Enabled             : True
SriovSupport        : Supported
SwitchName          : "Default Switch"
NumVFs              : 32

Name                : VM NIC 2
InterfaceDescription: Mellanox ConnectX-3 Pro Ethernet Adapter #2
Enabled             : True
SriovSupport        : Supported
SwitchName          : "Default Switch"
NumVFs              : 32
		

В настоящий момент времени реальность такова, что не так много систем имеют возможность SR- IOV. SR- IOV будет применяться в целевых сценариях, так как в большинстве случаев имеющиеся стандартные сетевые возможности Hyper-V через его виртуальный коммутатор будут достаточными даже для самых требовательных рабочих нагрузок. SR- IOV имеет целью те очень ограниченные случаи, когда необходимы самые высокие сетевые пропускные способности. Другой общий случай в котором могут найти своё место реализации SR- IOV это решения "укомплектованного облака", когда отдельный производитель поставляет все серверы, всю сетевую среду, а также все хранилища. Одно из таких я наблюдал в решении Cisco UCS, которое интенсивно применяло SR- IOV, поскольку многие сетевые возможности были реализованы с применением собственных технологий Cisco, VM-FEX. Впечатляющий блог со множеством частей доступен в Microsoft по теме SR- IOV; он расскажет вам всё, что вы только пожелаете знать: http://blogs.technet.com/b/jhoward/archive/2012/03/12/everything-you-wanted-to-know-about-sr-iov-in-hyper-v-part-1.aspx.