Дополнение B. Всё что вы хотели знать об SR-IOV в Hyper-V

Содержание

Дополнение B. Всё что вы хотели знать об SR-IOV в Hyper-V
Часть 1. Зачем нужен SR- IOV
Часть 2. Аппаратная поддержка в виде устройства IOMMU
Часть 3. Модель драйвера поддержки как PF, так и VF
Часть 4.
Часть 5.
Часть 6.
Часть 7.
Часть 8.

Часть 1

Перевод блога John Howard -MSFT March 12, 2012

Теперь, когда завеса молчания была приподнята над выпуском Windows Server "8" бета, я имею возможность рассказать вам немного больше о том, над чем я работал теперь на протяжении пяти лет. Инсайдерская шетка состоит в том, что функция с двумя блоками пометки в своём UI Диспетчера Hyper-V потребовала почти два с половиной года на каждый свой блок пометки!. Совершенно ясно, что это слегка больше чем только это! На самом деле намного больше!

SR- IOV является сокращением для Single-Root Input/Output (I/O) Virtualization (Виртуализации ввода/ вывода с единым корнем). Это некий стандарт, который определяется PCI Special Interest Group. Если вы работаете в одной из компаний- участниц, у которых имеется к нему доступ, а также готову к некоторому лёгкому чтеню перед сном, все спецификации доступны у них на вебсайте.

Чтобы описать его на самом верхнем уровне (как и всё что вам, скорее всего, необходимо знать чтобы применять такую функциональность), SR- IOV является стандартом, который описывает как устройство PCI Express может быть сконструировано с тем, чтобы оно хорошо работало с вовременными решениями виртуализации. Вам может быть интересным что означает "хорошо работать" когда у вас уже имеется отличная модель совместного использования устройства ввода/ вывода представленная в Hyper-V как в Windows Server 2008, так и в Windows Server 2008 R2? Хороший вопрос. Прежде чем я отвечу на него, давайте рассмотрим схему, которую многие из вас уже видели во множестве вариаций десятки раз ранее.

 

Рисунок B.1


Включение SR-IOV в виртуальном коммутаторе при его создании

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

Сопоставление эмулируемых и программно определяемых устройств

Виртуальные машины "видят" либу эмулируемые устройства (такие как Intel/DEC 21140), либо устройства на основе программного обеспечения (обычно именуемые как "синтетические" устройства, некий термин который я сам пытаюсь не применять и избегаю его, либо как "паравиртуализированные" устройства). которые спроектированы для надлежащей работы в каком- то виртуальном окружении. Для обоих вариантов использования эти устройства не являются "реальными" устройствами, физически присутствующими в реальном оборудовании, которое вы можете пощупать. На самом деле, в случае устройств на основе программного обеспечения, это полностью сфабрикованное устройство. Вы можете проследовать в свой местный магазин и купить его как если бы оно имелось в реальном мире. Программные устройства пользуются преимуществом нашего высокоскоростного механизма взаимодействия между разделами, VMBus, для эффективной передачи данных между всеми родительскими разделами и некоторой виртуальной машиной. Устройства на основе программного обеспечения намного более эффективны чем эмулируемые устройства по четырём основным причинам:

  • Во- первых, нам не требуется (обычно) вовлекать сам Гипервизор в имеющийся горячий путь для передачи данных. Эмклируемое устройство требует множества вмешательств со стороны Гипервизора для всякого отделного ввода/ вывода, что делает их чрезвычайно затратными с точки зрения производительности, что именно и является почему все наши поддерживаемые операционные системы также содержат драйверы для программных устройств.

  • Во- вторых, VMBus использует совместно используемые буферы памяти и дескрипторы памяти для перемещения данных между имеющимся родительским разделом и соответствующей виртуальной машиной. Доступ к совместно используемой памяти между разделами чрезвычайно быстрый, в особенности поскольку архитектура системы и аппаратные технологии за последние годы были существенно улучшены.

  • В- третьих, нам не требуется буквально эмулировать некое физическое устройство в режиме пользователя в самом рабочем процессе, инструкция за инструкцией, как мы это делаем для эмулируемых устройств. Программно определяемые устройства не требуют эмуляции.

  • И четвёртое, нтерфейсы VMBus (по крайней мере для сетевой среды и для хранилища) исполняются в режиме ядра как в самой ВМ, так и в её родительском разделе. Нам нет нужды переходить наверх в режим пользователя в таком родительском разделе чтобы осуществлять ввод/ вывод, затрачивая дополнительные циклы на вычисления.

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

В конце концов, настали дни, когда само по себе программное обеспечение не имеет возможности сохранять скорость имеющегося соединения. В случае RDMA мы уже становимся ближе. Одна очень приблизительная цифра, причём преднамеренно, рассматривает вопрос о том сколько вычислительных ресурсов требуется для сетевого ввода/ вывода на основе Ethernet. Это по большей степени зависит от класса процессора и драйвера производителя, однако на сегодняшний день некое отдельное ядро могло бы потреблять между 5 и 7 ГБ в секунду сетевого обмена, вырабатываемого виртуальными машинами под упралвением Windows Server 2008 R2 SP1. Более того, по мере роста скоросте линий, уже стандартизированы 40 и 100 Гигабитные Ethernet и мы должны искать как мы могли бы действенно масштабировать ввод/ вывод Hyper-V для виртуализации центров обработки данных.

Сейчас я не говорю что SR-IOV полезен только в средах с 40 или 100 Гигабит. Точное нет! Однако при быстром освоении оборудования 10GE самое время рассмотреть альтернативы более эффективных механизмов для устройств ввода/ вывода, которые в будущем будут хорошо масштабироваться.

Таким образом, чтобы ответить на вопрос что такое "работает хорошо", как это я упоминал ранее, означает что это модель некоторого безопасного устройства, которая имеет отношение к совместно используемому устройству ввода/ вывода на основе программного обеспечения, более низкую латентность, более выстокую пропускную способность, более низкие вычислительные накладные расходы и будет масштабироваться в последующем. Именно всему этому соответствует SR- IOV.

Итак, вы теперьпонимаете немного больше о том почему Microsoft вложился в SR- IOV и Heper-V в Windows Server "8" в следующей части я начну вдаваться в подробности.

Часть 2

Перевод блога John Howard -MSFT March 13, 2012

D первой части я обсуждал почему Microsoft инвестировал в SR- IOV для ввода/ вывода устройств из виртуальных машин. Именно это ключевой момент в котором уменьшается латенстность, увеличивается пропускная пособность, снижаются накладные вычислительные расходы и имеются возможности последующего масштабирования. Часть два рассмотрит SR- IOV с точки зрения перспектив оборудования.

Для тех, кто не последовал моему совету на сон грядущий очитать спецификации SR- IOV (или же не имеет к ним доступ), позвольте мне суммировать чем же является SR- IOV. И, чтобы внести ясность, когда я упоминаю "SR- IOV", не забудьте включить в него тесно связанные с ним спецификации или добавления к спецификациям, так ие как

  • ATS (Address Translation Services, Службы трансляции адреса) - некий протокол PCI Express, который позволяет какому-то устройству извлекать трансляцию из некоторого IOMMU (Input/Output Memory Management Unit, Устройства управления памятью ввода/ вывода).

  • ARI (Alternate Routing Interpretation, Интерпретация альтернативных маршрутов) - некое изменение коммутатора или изменение устройства PCI Express, которое позволяет какому- то устройству занимать более восьми RID (Requestor ID) в отдельной шине.

  • ACS (Access Control Services, Службы управления доступом) - некая функциональность PCI Express, которая понуждает восходящий поток обднораногового обмена с тем, чтобы он был способен транслироваться IOMMU.

В начале я собираюсь сказать, чем SR- IOV не является. Наиболее важно то, что он не имеет ничего общего ни с какими класами ввода/ вывода и, как таковой, не имеет никакого отношения сетевым классам, классам хранения или прочим классам ввода/ вывода. Он никоим образом не предписывает как следует разрабатывать программное обеспечение для использования аппаратных возможностей SR- IOV. Это всего лишь технические средства. Поэтому он не описывает ни модель драйвера, которая требуется для законченного решения, ни подробности специфичекого оборудования (одну из которых я упомянул в конце предыдущего поста), относительно любого класса ввода/ вывода.

Тем не менее, спецификация SR- IOV предписывает как некое аппаратное устройство может выставлять множество апапартаных проявлений с "малым весом" для их применения виртуальными машинами. Именно они именуются Виртуальными функциями (Virtual Functions), или для краткости VF. VF ассоциируются с PF (Physical Function, Физическими функциями). Именно PF является тем, что использует основной родительский раздел в Hyper-V и она эквивалентна обычной адресации устройства PCI BDF (Bus/Device/Function), которую вы могли слышать ранее. PF отвечает за арбитраж, относящийся к решениям политик (таким как скорость соединения или адреса MAC при использовании в ВМ в случае сетевых сред), а также за ввод/ вывод из самого родительского раздела. Хотя VF может применяться самим родительским разделом, в Windows Server "8" VF используются только виртуальными машинами. Некое отдельное устройство PCI Express может выставлять множество PF (например, сетевой устройство со множеством портов {Прим. пер.: или плата GPU с несколькими графическими процессорами}), причём каждое (обычно) независимо и имеет свой собственный набор ресурсов VF. Существуют некоторые тонкости устройств со множеством функций, такие как те, которые, скажем, поддерживают iSCSI, Ethernet и FCoE, однако это выходит за границы данной последовательности постов и подход к ним отличается у различных производителей.

Важно отметить, что VF являются аппаратными ресурсами. Так как они являются аппаратными ресурсами, имеются ограничения на общее число VF, которые доступны в каждом определённом устройстве. Реальное число будет отличаться по производителям и устройствам. Вы можете ожидать, что по мере продвижения аппаратных средств к более новым выпускам, имеющаяся теденуия будет предлагать всё больше VF на PF. Обычно мы наблюдаем предложения устройствами 16, 32 или 64 VF на PF в первом поколении 10 GE оборудоввании с разрешённым SR- IOV.

VF сами по себе не достаточны для обеспечения безопасности разрешения некотрой ВМ прямого доступа к оборудованию. Обычные устройства PCI Express как правило "общаются" в терминах физического адресного пространства системы (SPA, system physical address). Как вы уже можете знать, мы не исполняем гостевые операционные системы в SPA, мы исполняем их в гостевом физическом адресном протранстве (GPA, guest physical address). Следовательно, должно иметься нечто, что транслирует (а видеале кэширует) адреса для обмена DMA. Именно это устанавливает соответствие DMA. Кроме того, по причинам безопасности, мы требуем аппаратного асистирования переназначению прерываний. Для тех, кто желает дополнительно ознакомиться с аппаратной стороной этого, смотрите эту страницу относительно VT-d для Intel, либо страницу AMD-V для AMD. Имеется множество спецификаций для любознательных читателей!

Начиная с данного момента в своей последовательности блогов я собираюсь обычно употреблять соответствующий термин IOMMU чтобы обозначать аппаратные те возможности, которые предоставляют переназначение прерываний и DMA.

Для полноты картины, если я не говорю об этом иным образом в яном виде, некое устройство SR- IOV с каким- то подходящим драйвером может применяться как обычное устройство ввода/ вывода вне виртуализации. Скорее всего, не требуется применять преимущества имеющихся дополнительных аппаратных возможностей без наличия виртуализации, однако его всё же можно применять как обычное устройство ввода/ вывода. К тому же, данное устройство не требует присутствия оборудования "IOMMU", которое будет применяться таким образом.

Хотя я уже ссылался несколько раз на сетевые ресурсы, я также сказал, что SR- IOV с точки зрения спецификации ничего не сообщает о классе ввода/ вывода. Когда мы (команда Hyper-V) где находятся наибольшие выгоды от применения SR- IOV, нам стало совершенно очевидно, что имеющиеся накладные расходы на ввод/ выводхранения были значительно ниже чем имеющиеся у сетевых операций ввода/ вывода. Таким образом, для Windows Server "8" мы работали над SR- IOV исключительно для сетевых сред в качестве поддерживаемого класса устройств.

Хотя это может быть не сразу очевидным, поставка NIC от производителя для создания некоторого усройства с поддержкой SR- IOV не достаточна чтобы следовать имеющейся спецификации SR- IOV. Одна из причин состоит в том, что сетевой адаптер должен осуществлять сетевое взаимодействие в свою сторону и от себя со множеством источников (PF и VF), помимо самих проводов. Чтобы допускать кадры Ethernet для маршрутизации между двумя VF, например, большая часть коммутаторов Ethernet должна быть встроена в определённую физическую NIC. В имеющейся спецификации SR- IOV ничего не говорится об этом.

Поэтому мы теперь рассматрели SR- IOV с точки зрения "почему" в части 1 и с точки зрения аппаратной в этой части. Часть 3 взглянет на перспективы программной поддержки SR- IOV в Windows Server "8".

Часть 3

Перевод блога John Howard -MSFT March 14, 2012

До сих пор в данной последовательности блогов мы рассматривали вопрос "почему" и "аппаратные стороны" SR- IOV и указали, что для использования SR- IOV в Hyper-V необходимо иметь поддержку ситемного оборудования в определённом виде устройства IOMMU, а также некое устройство PCI Express, которое имеет возможности SR- IOV. Теперь самое время начать разговор о взгляде на сторону программного обеспечения. В этой части мы рассмотрим драйверы устройства.

Драйверы устройства SR- IOV

Я уже упоминал, что модель лрайвера существенна для общего решения SR- IOV. Даже спецификации SR- IOV ничего не упоминают о моделях драйверов. Следовательно, Microsoft должна указать все необходимые интерфейсы, которые нужны для поддержки VF и PF работающие совместно в виртуальной среде. Вы можете спросить зачем нам нужно обновлять имеющуюся модель драйвера для SR- IOV когда у нас уже имеется хорошо устоявшаяся модель для сетевых сред в виде NDIS. Если вы представляете себе "традиционный" сетевой драйвер устройства, этот драйвер отвечает только за управление отдельным устройством (в самом родительском разделе, либо единственный экземпляр Windows когда мы вне виртуализации). Такое устройство, конечно, является тем, что в мире SR- IOV именуется как PF.

До Windows "8" в виртуальных машинах Hyper-V у нас имелись только устройства на основании эмуляции или программного обеспечения и производителям устройства не было необходимоссти сильно рассматривать их сами по себе относительно того, что исполняется внутри виртуальных машин. Hyper-V имел дело с ковенной моделью ввода/ вывода самой по себе и предоставляет драйверы для таких виртуальных устройств. Однако, некое устройство SR- IOV имеет помимо PF также и VF. При SR- IOV некая часть оборудования производителя выставляется внутри имеющейся виртуальной машины. Поскольку наш сетевой код не знает как манипулировать с этой частью оборудования напрямую, нам необходимо загрузить некий поставляемый производителем драйвер в такую ВМ.

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

Хотя VF являются переходными, её PF всегда доступна (то есть при условии что это устройство PCI Express включено). VF не могут существовать без присутствия PF. Так как PF работает в доверенном домене (в своём родительском разделе), такая PF может выступать арбитром для всех решений политики, а сама контрольная точка для установки экземпляра VF и демонтажа включает распределение аппаратных ресурсов, которые работают совместно с останльной частью всего стека виртуализации Hyper-V.

Имеет ся две ситуации, в которых такому драйверу VF необходимо безопасно взаимодействовать с основным драйвером PF. Это касается не только самого пути ввода/ вывода, но также и логики политики и контроля. Microsoft рассматривает апппаратный фонофый какнал менее безопасным нежели позволить Hyper-V вносить поправки в этот канал взаимодействия. Выставляя интерфейсы в Windows для такой функциональности мы можем проверять поведение драйверов, предоставляя тестирование завуалированности и проникновения как часть сертификации драйвера, тем самым поощряя поставщиков длительно рассматривать модель безопасности при выставлении оборудования непосредственно в виртуальную машину. Именно это является критически важным моментом в нашем Trustworthy Computing SDL, который проходят все компоненты Windows.

Итак, какие интерфейсы мы определяем на самом верхнем уровне?

  • Чтобы разрешить некому драйверу PF сообщать Windows о тех возможностях SR- IOV, которые она имеет.

  • Чтобы разрешить некому драйверу PF устанавливать экземпляры VF и гасить их, включая предоставление и изымание очередей и фильтров оборудования по мере необходимости.

  • Чтобы разрешить некому драйверу PF отправлять логику политики и контроля в PF (и получать обратно).

Именно эти установки экземпляра драйвера документированы в функциях SR- IOV NDIS в MSDN.

Один из моментов относительно модели драйвера, который я хочу затронуть состоит в том, что мы оставили авторам драйверов устройств решение того как они хотят создавать свои драйверы. Либо как модель с разделённым драйвером, в котором имеются отдельные драйверы для PF и VF. Либо как некий комбинированная модель драйвера, в которой имеется единый драйвер и для PF, и для VF. Либо на самом деле применять драйвер виртуальной шины (VBD, virtual bus driver), если это именно то, с чем они знакомы. Другими словами, хотя и имеются новые концепции, данный шаг для поддержки SR- IOV не является громадным с точки зрения автора драйверов, поскольку он основывается на имеющихся моделях.

Когда шинаPCI не является шиной PCI?

Вероятно это странный вопрос. Обычное устройство PCI Express как правило перечисляется в имеющейся шине PCI, расположенной под Корневым портом PCI Express. Вот некий снимок экрана из Диспетчера устройств, применяемого в Windows Server "8" бета в его родительском разделев той машине, которая имеет сетевые устройства с двумя портами и возможностями SR- IOV. Вы можете видеть все устройства PF под неким портом Корня PCI Express.

 

Рисунок B.2



И то же самое с неким драйвером VBD на своём месте в другой машине с неким отдельным сетевым устройством с дуальным портом и возможностями SR- IOV.

 

Рисунок B.3



Если бы мы взглянули на некую виртуальную машину с подключёнными устройствами SR- IOV, вы бы увидели некое тонкое отличие в имеющемся дереве устройств. Эта особая виртуальная машина имеет два программных сетевых адаптера, причём каждый из них основан на некоторой виртуальной функции. Такие виртуальные функции выставляются в енкую виртуальную шину PCI под VMBus, как вы это можете увидеть из следующего экранного снимка. Это не очень важно с точки зрения перспективы профессионала ИТ, однако в данном случае вы хотите видеть имеющуюся иерархию устройства.

 

Рисунок B.4



И опять- таки, при размещение здесь драйвера VBD (с двумя VF, назначенными этой определённой ВМ):

 

Рисунок B.5



Эта часть данного потса блога начинает обзор со стороны программного обеспечения SR- IOV, в частности, с точки зрения автора драйвера производителя устройства. Суммируя, помимо ответа на вопрос "зачем", на данный момент ы обозначили три зависимости, необходимые для поддержки SR- IOV в Hyper-V Windows Server "8" бета и успешно пояснили почему все они существенны:

  • Аппаратная поддержка системой в виде некоторого устройства IOMMU

  • Какое- то устройство PCI Express, которое имеет возможности SR- IOV

  • Некая модель драйвера для поддержки как PF, так и VF

В нашей следующей части я рассмотрю следующие зависимости для добавления их в имеющийся перечень.

Часть 4

Перевод блога John Howard -MSFT March 15, 2012

До сих пор в нашем сериале мы обсуждали вопрос "зачем" и указали три зависимости для SR-IOV в Hyper-V Windows Server "8" бета:

Эта часть сериала добавляет ещё один важный компонент в наш перечень и один второстепенный. Второстепенным является т, что система обязана поддерживать SLAT (Second Level Address Translation, Вложенный пейджинг). В предаставленной экосистеме серверов вам будет проблематично отыскать систему, которая имеет набор микросхем IOMMU и процессор без возможностей SLAT, поэтому почти для любых амерений и целей это не является проблемой.

основной системой, не обсуждавшейся до сих пор является встроенное ПО системы (firmware) или BIOS. Хотя у нас и имеется документ на множестве страниц соместно используемый разработчиками втроенного ПО аппаратных систем, описывающий необходимые изменение (и прочие незначительные зависимости), все детали этого документа не относятся к тому, что является обязательным для понимания SR- IOV с точки зрения конечного пользователя. Однако, то что вам следует осознать, что без подобных изменений Hyper-V не сможет включить SR- IOV даже если у нас имеется набор микросхем в виде некоторого устройства IOMMU, которое присутствует на самом деле.

Существует пара вещей из необходимых изменений встроенного ПО, которые просачиваются в примененеие конечным ползователем Hyper-V и о которых я расскажу более подробно в части "отладка, или почему SR- IOV не работает" данного сериала. На текущий момент я просто назову их, один из них это переносимый в операционную систему PCI Express Native Control, а другой поддержка обхода проблемы с набором микросхем.

Мы долгое время работали с производителями систем чтобы убедиться что вам доступны системы чтобы попробовать SR- IOV в Windows Server "8". Мы находимся на пороге выпуска следующего поколения циклов выпуска поставщиками систем в ближайшие месяцы и на таких платформах последнего поколения будет гораздо более широкая поддержка. Однако на текущий момент количество тех систем, которое может быть применено достаточно ограничено. Естественно, не ожидайте что SR- IOV будет работать на настольных платформах (или в ноутбуках) из- за тербований к их встроенному ПО. Это прочная функциональность серверов (наличие PUN - Physical Unit Number). Для получения более подробной информации обратитесь к производителю своей системы относительно информации о версиях BIOS и поддерживаемых платформах в имеющихся аппаратных средствах. Сегодня доступны платформы с необходимой поддержкой Dell, Fujitsu и HP, а также прочие OEM имеют системы с поддержкой "наилучших возможностей". Некая информация по ним перечислена в замечаниях к выпуску для Windows Server "8".

Одна вещь, которую я бы хотел указать, состоит в том, что некоторые BIOS имеют более чем одно место для включения SR- IOV. Поэтому потратьте некоторое время чтобы убедиться что вы в точности следуете инструкциям своего производителя.

4 года назад мой коллега, Джейк Ошин на WinHEC 2008 сделал интересную презентацию. В ней представлены некоторые дополнительные ссылки, на тот случай если у вас есть интерес к дальнейшему ознакомлению с некоторыми аспектами из того, что было рассмотрено на данный момент в данном сериале. Часть информации изменилась, однако основная информация по- прежнему актуальна.

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

Часть 5

Перевод блога John Howard -MSFT March 16, 2012

В частях с 1 по 4 я рассмотрел внешние зависимсости SR- IOV и "зачем" он нужен. Итак, теперь самое время показать как установить SR- IOV и то как он вышглядит более подробно с точки зрения конфигурации, как для интерфейса ползователя в Диспетчере Hyper-V, так и из PowerShell.

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

 

Рисунок B.6



Несколько ключевых моментов, которые я хочу вынести из этой схемы:

  • Я не художник!

  • Имеющийся в родительском разделе Виртуальный коомутатор находится в "режиме SR- IOV"

  • Основной путь данных ввода/ вывода от рассматриваемой VF не проходит через VMBus или через Гипервизор Windows. Это прямой путь от данной VF в NIC ВМ.

  • Управляющий путь для данной VF пролоен через VMBus (обратно в основной драйвер PF в его родительском разделе)

Смый первый шаг при разрешении какой- то виртуальной машине иметь подключение к физической сетевой среде сотоит в создании некоторого внешнего коммутатора с помощью Диспетчера Виртуального коммутатора в Диспетчере Hyper-V. Определёный дополнительный шаг, который требуется при использовании SR- IOV состоит в обеспечении соответствующей отметки в контрольном блоке ри создании такого виртуального коммутатора. Невозможно изменить виртуальный коммутатор "без режима SR- IOV" в некий коммутатор с "режимом SR- IOV". Данный выбор необходимо сделать в момент создания коммутатора.

 

Рисунок B.7



Это также можно выполнить и PowerShell с помощью New-VMSwitch. New-VMSwitch требует некоего параметра для определения того физического сетевого адаптера, который вы намереваетесь применять. Все физические сетевые адаптеры можно определить при помощи Get-NetAdapter.На следующем снимке экрана у меня есть машина, которая имеет множество физических NIC, один из которых является встроенным NIC, который не имеет возможностей SR- IOV, а также два двух- портовых 10G NIC PCI Express, которые имеют поддержку SR- IOV. Отметим, что я придал некоторым из этих адаптеров "дружественные названия" припомощи сетевой управляющей панели (ncpa.cpl).

 

Рисунок B.8



Два следующих снимка экрана отображают различные имеющиеся способы применения New-VMSwitch для создания виртуального коммутатора, связанного с сетевыми адаптерами с возможностями SR- IOV из предыдущего снимка экрана. Отметим применение параметра неоходимого -EnableIov.

 
 

Рисунок B.9-10




Давайте более подробно посмотрим на свойства , которые мы выставили в своём объекте VMNetworkAdapter.

 

Рисунок B.11



IovEnabled: True если данный коммутатор создан с режимом SR- IOV. В противном случае False.

IovVirtualFunctionCount: Общее число VF, которые доступны для применения в виртуальных машинах. Оно различается в зависимости от производителя. Отметим, что всякая NIC на основе программного обеспечения может иметь в своей основе некую VF, а всякая VF может иметь вплоть до 8 NIC на основе программного обеспечения.

IovVirtualFunctionsInUse: Общее число VF, используемых в настоящее время исполняемыми ВМ. В данном снимке экрана это число равняется 1, так как у меня имеется единственная исполняемая ВМ с единственным NIC на основе программного обеспечения в режиме SR- IOV.

IovQueuePairCount: Общее число пар очередей доступное в виде аппаратных ресурсов в данной физической NIC. Оно разнится в зависимости от производителя. Моежет иметься столько пар очередей, сколько существует VF, хотя некоторые производители могут иметь больше пар очередей доступными чем присутствует VF. Я рекомендую вам представлять некую VF как целиком назначенную какому- то сетевому адаптеру виртуальной машины вместо того чтобы иметь одну или более пар очередей. Однако, всякая VF требует для работы по крайней мере одну пару очередей. Если производитель вашей NIC поддерживает некие дополнительные функции, например RSS в некоторой ВМ, опирающейся на VF, может понадобиться более одной пары очередей для VF. Для получения дополнительной информации вам следует обратиться к руководству производителя NIC.

IovQueuePairsInUse: Общее число аппаратных пар очередей выделенных VF, назначенной исполняемым ВМ.

IovSupport/IovSupportReasons: Массив численных одов и описаний в зависимости от текущего состояния данного сетевого адаптера. Дополнительную информацию по этим свойствам бедет рассмотрено в части "отладка, или почему SR- IOV не работает" данного сериала.

Когда некий виртуальный коммутатор создан, следующим этапом является настройка виртуальной машины. SR-IOV в Windows Server "8" поддерживается вредакциях x64 Windows "8" в качестве гостевой операционной системы(как в Windows "8" Server, так и в клиенте Windows "8" x64, но не в клиенте x86). Мы перераспределили все установки виртуальной машины для введения суб- узлов в сетевом адаптере, один из которых является нашим узлом с аппаратным ускорением. Внизу присуствует блок пометки для включения SR- IOV.

 

Рисунок B.12



За сценой, данный блок пометки устанавливает некое свойство, IovWeight. Оно идентично по функциональности VMQWeight в Windows Server 2008 R2 и выражает пожелание для некторой аппаратной разгрузки, без какой- либо гарантии. Некое положительное значение между 1 и 100 является "включением", а 0 означает "отключение". В Windows Server "8" мы не применяем систему относительных весов. Все значения от 1 до 100 означают одно и то же. Такая архитектура позволяет нам добавлять функциональность "весов" в последующем без необходимости изменения API.

Как и для создания коммутатора, включение SR- IOV в виртуальном сетевом адаптере виртуальной машины может быть выполнено в PowerShell при помощи Set-VMNetworkAdapter через установку свойства IovWeight как это показано на снимке ниже.

 

Рисунок B.13



Допустим, что вы удовлетворили все необходимые требования соотвествия SR- IOV, тогда вы обнаружите соответствующее изменение состояния в своей закладке сетевой среды в Диспетчере Hyper-V для выбранной ВМ в "OK (SR-IOV active)".

 

Рисунок B.14



Давайте вернймся обратно к предыдущему выводу PowerShell и опросим свойства SR- IOV, относящиеся к нашему объекту VMNetworkAdapter.

IovWeight: Обсуждался ранее.

IovQueuePairsRequested/IovQueuePairsAssigned: Это применяется для расширенных сетевых функций в VF. Одним из примеров является RSS в некоторой виртуальной машине (когда в её основе VF), и требует чтобы данный физический сетевой адаптер сам по себе поддерживал RSS в VF. Отметим, что это самый первый раз, когда мы имеем возможность получить RSS для ВМ. Так как данный сериал постов не посвящён RSS, его преимуществам или тому как его настраивать, будет лучше не отвлекаться. Дополнительную информацию об RSS, который впервые был введён в Windows Server 2008, можно получить тут.

По умолчанию значение IovQueuePairsRequested будет установлено в 1, причём оно никогда не может быть ниже 1. Если ваше оборудование VF поддерживает RSS и у вас имеется ВМ со множеством процессоров, вы можете применять этот параметр для запроса дополнительных пар очередей из имеющегося аппаратного набора ресурсов доступных для позволения такой ВМ масштабировать их. Это, однако, некий запрос, и реальное число выделенных пар очередей может быть меньше и зависит от аппаратных ресурсов. Общее число выделенных будет определено в IovQueuePairsAssigned.

IovInterruptModeration: Многие современные физические NIC имеют некое расширяющее свойство позволять своему драйверу иметь возможность уменьшать прерывания. Так как теперь имеется множество функций (PF и VF), которые обрабатывают прерывания, данное свойство позволяет имеющемуся драйверу VF иметь возможность приспособления к нагрузке. Лежащая в основе реализация находится в руках автора драйвера. Следовательно вам следует ознакомиться с руководством произодителя NIC относительно того как оно реализовано, либо что рекомендуется устанавливать в соотвтествии с исполняемыми рабочими нагрузками. Возможными значениями являются: Default; Adaptive; Off; Low; Medium и High. В большинстве случаев будет достаточным оставить неизменным установленное по уолчанию значение "Default".

IovUsage: Будет иметь значение 1 если некая VF активно применяется в ВМ, 0 в противном случае.

Status/StatusDescription: Массив численных значений и описаний в зависимости от текущего состояния данного сетевого адаптера. Это не является исключительным для SR- IOV, хотя мы и заполняем его когда установлен IovWeight, но не работает как нужно. Дополнительную информацию по данному свойству будет приведена в части "отладка, или почему SR- IOV не работает" данного сериала.

VirtualFunction: Предоставляет намного больше информации об имеющейся VF самой по себе, однако для всех намерений и целей вы можете игнорировать это свойство. Тем не менее, может оказаться потенциально полезным чтобы сценарии могли бы привязываться к физическому взаимодейтвию, применяемому в данной системе через свойства ifAlias и ifDesc. Для тех из вас, кто желает знать все кровожадные подробности данного объекта, вот его полный вывод:

 

Рисунок B.15



VirtualFunctionsAssigned: Будет отвергаться вплоть до окончательного выпска и может игнорироваться в Windows Server "8" бета. Применяется праметр IovUsage.

Итак, в большей степени это касается интерфейса пользователя и стороны PowerShell при настройке SR- IOV. В своей следующей части я расскажу о Миграции в Реальном времени и покажу SR- IOV в действии в коротком видео- ролике.

Часть 6

Перевод блога John Howard -MSFT March 19, 2012

Суммируя весь сериал до текущего момента, мы ответили "Зачем нужен SR-IOV?", рассмотрели зависимости от оборудования и встроенного ПО, а также прошлись по интерфейсу пользователя и cmdlet PowerShell в настройке SR- IOV. Далее в нашем распорядке стоит рассмотрение того как совместно работают SR- IOV и миграция в реальном режиме. Кроме того имеется видео демонстрация, затрагивающая стороны настройки SR- IOV из предыдущей части, в которой также показывается миграция в реальном масштабе в действии.

На самой ранней стадии планирования Windows "8" одной из целей было очень важно рассмотреть функции, которые несовместимы со сценариями мобильности, такими как миграция в реальном времени. (На самом деле SR- IOV находится в стадии разработки намного дольше чем вы скорее всего можете себе представить, например, WinHEC 2008, на который я уже ссылался и обсуждение велось даже на WinHEC 2006.)

Данная задача представляет собой определённую проблему при назначении аппаратных средств виртуальной машине. Давайте на момент забудем про SR- IOV и вернёмся на шаг назад на несколько лет в начальную разработку и прототипирование данной функциональности. Вы можете быть уже знакомы с термином "Discrete Device Assignment" (Назначение дискретного устройства). В этом случае на виртуальную машину выделяется полноценное устройство PCI Express. С точки зрения разработки программного обеспечения дискретное выделение можно рассматривать как некоторого рода первичный шаг к поддержке SR- IOV. Однако дискретное выделение сталкивается с проблемами в некоторых областях:

  • Безопасность

  • Применимость и мобильность

  • Масштабирование

С точки зрения безопасности некая виртуальная машина со значительным неконтролируемым доступом к оборудованию слишком рискована в представлении поставляемого решения, однако всё ещё предоставляется в утверждениях поддержки решения. Было бы чрезвычайно сложно обезопасить вашу виртуальную машину до такой степени, чтобы она не смогла оказывать воздействие на прочие разделы, тем самым нарушая критически важный догмат безопасности.

С точки зрения масштабируемости сложно представить себе масштабируемым некое выделение устройства, при котором слот PCI Express целиком берётся под отдельную виртуальную машину. Получалось бы очень затратным масштабирование до десятков и сотен виртуальных машин. Только если вы на самом деле не найдёте сервер с очеь большим числом слотов PCI Express.

С точки зрения применимости трудно себе представить некий общеупотребимый сценарий использования. Безусловно, имеются некие нишевые исключения, имеющие определённые достоинства, однако в данном процессе будет утрачен ряд моментов. Наиболее важным из них является поддержка миграции в реальном времени за которой сразу следуют изменения состояния (помимо исполнения и останова) и далее моментальные снимки. Наверное, в наивысшей степени. Основная причина состоит в том, что чрезвычайно сложно сохранить состояние части произвольного оборудования внутри работающей ВМ и впоследствии восстановить его в рабочее состояние на другой платформе. Кроме того, даже если мы можем временно остановить свою виртуальную машину без вмешательсвта в её состояние оборудования (что было бы обязательно в процессе гашения миграции в реальном режиме), без абсолютно идентичной конфигурации на оконечном месте миграции на всех уровнях (не только на аппаратном), нет никаких шансов на успешное восстановление.

Следовательно, мы рассматриваем дискретное назначение как не очень полезное за исключением очень ограниченного сегмента своей пользовательской базы, которая не слишком озабочена безопасностью, масштабируемостью и мобильностью. Вместо этого мы сосредоточимся на чём- то, что способно разрешить все эти вызовы, а именно SR- IOV. Безопасность встроена на всех уровнях. Для поддержки множества виртуальных машин требуется всего один слот PCI Express. К тому же мы поддерживаем мобильность (миграцию вживую и быстро), изменения состояния и моментальные снимки.

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

Несмотря на свою простоту, имеющийся ответ не сразу становится очевидным. и заключается этот ответ в том, что мы вообще не сохраняем состояние аппаратных средств и даже и не пытаемся решить эту проблему. И всё же мы можем перейти на некую платформу, которая может иметь абсолютно другой физический сетевой адаптер с тем же самым типом NIC, либо с другим уровнем выпуска встроенного ПО, либо даже на платформу, на которой нет поддержки SR- IOV. Причём при всех этих сценариях оставаться с поддержкой полностью работающей сетевой среды в этой виртуальной машине. Пока не запутались?

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

Наиболее внимательные, возможно, отметили, что я сказал что "мы заранее удаляем любые VF из ВМ" и задаются вопросом имеются ли последствия если гостевая операционная система не действует в кооперации. Короткий ответ- нет, наша модель состояния охватывает такой сценарий, хотя, конечно, легче когда гостевая операционная система сотрудничает в освобождении VF.

Обратите внимание также, что я использую понятие "отрабатывает отказ" в кавычках. Я мог бы сказать "группирование" (team), однако это подразумевает слегка большую функциональность, нежели "отработка отказа" (failover). Честно говоря, мы ещё пока не придумали хорошего термина, однако это факт, что "отработка отказа" не имеет ничего общего с группированием NIC, которое также теперь имеется в Windows Server "8"/ Это просто означает, что мы автоматически используем VF если она имеется, либо программно определяемую сетевую среду, если её нет, а при перемещении в любом случае не будет потерь сетевых пакетов. Как мы вскорости увидим, группирование NIC и SR- IOV могут сосуществовать одновременно в виртуальной машине.

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

 

Рисунок B.16

Windows Server “8” Демонстрация SR-IOV в Hyper-V и миграции в Реальном времени

Дополнительные подробности в следующей части.

Часть 7

Перевод блога John Howard -MSFT March 20, 2012

В данном сериале остались нераскрытыми всего несколько тем. Данная часть сериала взглянет на устойчивость с применением SR- IOV. Под устойчивостью я, естественно, подразумеваю группирование (teaming) NIC, иначе именуемое как Балансировка нагрузки/ отработка отказов (LBFO, Load Balancing/Failover), конкретная возможность агрегирования сетевых соединений или восстановления в случае падения одного из соединений. Я не хочу вдаваться в подробности настройки группирования NIC, которое упаковано в Windows Server "8", а остановлюсь только на том как оно соотносится с SR- IOV.

Когда некая группа создаётся поверх двух или более физических сетевых адаптеров с возможностями SR- IOV, такие возможности SR- IOV не распространяются вверх. Следовательно, эти две функции не совместимы в имеющемся родительском разделе.

Соответствующим решением для сетевой избыточности виртуальных машин с SR- IOV и гостевой операционной системой Windows Server "8" является осуществление группирования внутри самой гостевой операционной системы такой виртуальной машины. Чтобы его настроить:

  • Всякая физическая NIC должна иметь некий виртуальный коммутатор связанный с ней в её родительском разделе, причем все они с включённым SR- IOV.

  • Сама ВМ настроена с двумя сетевыми адаптерами, причём каждый из них подключён к одному из имеющихся виртуальных коммутаторов.

  • В данном родительском разделе все сетевые виртуальные одапетры ОБЯЗАНЫ быть настроенными с разрешённым группированием (что означает, что каждый сетевой адаптер может подставлять - spoof - MAC адрес другого) через исполнение следующей команды PowerShell:

    
Get-VMNetworkAdapter –VMName "VMName" | Set-VMNetworkAdapter –AllowTeaming On

  • Настроить значение IOVWeight в имеющихся виртуальных сетевых адаптерах как это обсуждалось в предыдущих частях этого сериала.

  • Настроить группирование в своей гостевой операционной системе в независимом коммутаторе, в режиме распределённого хэша адреса.

Следующий снимок экрана изнутри виртуальной машины настроенной именно таким образом, с одним отказавшим физическим подключением (реализованного отключением одной из NIC при помощи ncpa.cpl в основном родительском разделе).

 

Рисунок B.17



Имеется возможность создать некую группу в своей гостевой операционной системе, в которой из имеющегося родительского раздела один виртуальный коммутатор находится в режиме SR- IOV, в то время как другой нет (либо подвязан к некому сетевому адаптеру, который не поддерживает SR- IOV). Это полностью чабочая схема, однако вы должны держать в уме, что она может наводить сторонние эффекты. LBFO не осведомлён о том, что в основе находятся такие NIC в данной группе, следовательно не имеет информации о том, какая из частей имеет включённым SR- IOV (потенциально с некоей VF), а другой путь без него. В таком случае хотя ВМ всё ещё избыточна в отношении отказа соединения, вы можете пожелать настроить свои виртуальные NIC для операций Active/ Standby внутри этой ВМ.

Хотя некий групповой интерфейс и может быть создан с поддержкой до 32 NIC, внутри виртуальной машины имеющаяся (без принуждения) поддержка ограничена 2 NIC.

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

Приводимый ниже снимок экрана был взят с такой физической NIC, которая ограничена отключённым виртуальным коммутатором "TeamDemoB".

 

Рисунок B.18



Диспетчер Hyper-V правильно отображает текущее состояние своего второго виртуального сетевого адаптера как "OK" с точки зрения самого Hyper-V. Это происходит потому, что всё ещё имеется связь с другими виртуальными машинами, подключёнными к "TeamDemoB". Другими словами, Диспетчер Hyper-V пульсирует при изменении состояния лежащего в его основе физического подключения.

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

Часть 8

Перевод блога John Howard -MSFT March 21, 2012

Эта часть сериала посвящена определению того почему SR- IOV может не работать. Как вы уже обнаружили, имеется рыд причин, причём некоторые из них очевидны если в следили за всеми частями до сих пор, а некоторые более скрытные. К концу данной части вы станете экспертом!

Допустим, у вас имеется некий коммутатор в режиме SR- IOV и какой- то виртуальный сетевой адаптер с включённым SR- IOV, наиболее очевидное место в котором вы можете заметить что SR- IOV не работает, это Диспетчер Hyper-V после выбора закладки сетевых средств для работающей виртуальной машины. (Я влюблён в эту панель! - моё самое предпочитаемое место Диспетчера Hyper-V, в котором я работаю с выпуском Windows "8"!)

 

Рисунок B.19



Я уже обозначал зависимости в своих предыдущих постах. Но давайте допустим, что вы ещё пока не слышали о них и делаете это на некоторой древней машине, у которой нет возможностей SLAT, нет поддержки BIOS для SR- IOV и даже нет какого бы то ни было сетевого адаптера с возможностями SR- IOV, как это отображено на следующем снимк экрана. Самая певая улика поступает от cmdlet PowerShell Get-VMHost. В данном случае свйство IovSupportReasons, возвращаемое из этого cmdlet достаточно многословно в выводе числа причин.

 

Рисунок B.20



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

Нашим следующим примером является машиа, которая имеет поддержку набора микросхем, однако её BIOS не поддерживает SR- IOV. Возможно, это наиболее распространённая ошибка, которую вы обнаружите в поставляемых в настоящий момент серверах, либо если вы устанавливаете Windows Server "8" бета на машине уровня настольных. Ошибка- эта самая первая запись, в которой говорится: "Чтобы применять SR- IOV в данной системе необходимо обновить её BIOS, чтобы Windows могла управлять PCI Express. Обатитесь к производителю вашей системы за обновлением."

 

Рисунок B.21



Далее давайте предположим, что ваша машина имеет поддержку набора микросхем, её BIOS поддерживает SR- IOV и вы применяете NIC с возможностями SR- IOV, но он всё ещё не работает. В данном случае Get-VMHost может выдать следующее:

 

Рисунок B.22



Кроме того, после запуска виртуального сетевого адаптера (через изменение состояния виртуальной машины в исполняемое или переключив свойство IOVWeight в работающем виртуальном сетевом адаптере в положительное значение из диапазона 1..100) в журнале событий может появиться следующаязапись, указывающая что данный пользователь SR- IOV был запрещён политикой этой системы:

 

Рисунок B.23



причина этого требует небольшого пояснения. Даже если производитель вашей системы внёс необходимые изменения в свой BIOS для базовой функциональности Windows необходимые для поддержки SR- IOV, некоторые реализации наборов микросхем имеют свои недостатки. В ряде случаев производители могут решить такую проблему посредством исправления в своём встроенно ПО (firmware). Это не универсальная истина, и могут быть случаи, которые потребуют пересмотра микросхем, которые не богут быть исправлены через встроенное ПО (другими словами, выпуск новой версии материнской платы). Результат недостатков наборов микросхем таков, что для гостевой операционной системы, которая имеет назначенную VF, может вызвать работу вашей физической системы с пониженной производительностью или в худшем случае приводить к краху.

Если вы готовы назначать VF только в "доверенные" рабочие нагрузки вместо некоторого обновления BIOS с неким обходным путём (допустим, что в вашем оборудовании имеется такая возможность), можно добавить следующий ключ реестра в вашем родительском разделе IOVEnableOverride. Тип DWORD. Значение 1. В HKLM\Software\Microsoft\Windows NT\CurrentVersion\Virtualization. Систему также следует перезапустить после установки данного ключа (Технически говоря, вы можете перезапустить службу VMMS и сохранить/ восстановить все исполняемые ВМ, которые также имеют установленным IOVWeight.)

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

 

Рисунок B.24



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

Следующим полезным cmdlet является Get-NetAdapterSriov. этот cmdlet предоставит море полезной информации о вашем физическом сетевом адаптере, в предположении что он поддерживает SR- IOV.

 

Рисунок B.25



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

 

Рисунок B.26



тот факт, что нечто было возвращено, указывает на то, что ваш сетевой адаптер поддерживает SR- IOV. Более того, глядя на NumVFs мы можем увидеть, что этот адаптер работает правильно и имеет доступные ресурсы.

Если вы создали виртуальный коммутатор, третьим полезным cmdlet является Get-VMSwitch. Помите, что чтобы включить SR- IOV, этот коммутатор должен быть создан с режимом SR- IOV для начала. Когда SR- IOV не доступен в имеющеqся физическоq NIC, существует множество свойств, которые укажут почему. IovVirtualFunctionCount и IovQueuePairCount будут равны нулю. IovSupport будет иметь значение false, а IovSupportReasons перечислит список причин.

первым идёт пример в котором машина сама по себе не поддерживает SR- IOV, а её коммутатор ограничен сетевым адаптером, который вообще не поддерживает SR- IOV.

 

Рисунок B.27



Вот некий пример, в котором ваша машина поддерживает SR- IOV, однако ей физический сетевой адаптер нет. Из IovSupportReasons ясно что вызывает данную проблему, вне зависимости от того создан ли виртуальный коммутатор с включённым SR- IOV или нет.

 

Рисунок B.28



А следующий пример в котором ваша машина поддерживает SR- IOV, также как и её физический сетевой адаптер, однако имеющийся коммутатор не был создан с режимом SR- IOV. Это слегка более утончённо, так как IovSupport и IovSupportReasons показывают, что всё в порядке. Значением свойства IovEnabled является False, поэтому IovVirtualFunctionCount равен нудю, даже если физическая NIC имеет потенциально доступные ресурсы.

 

Рисунок B.29



В "хорошей" (правильно настроенной) машине вы получите совершенно другие результаты в этих свойствах. Заметим, что поскольку имеется некое положительное целое в IovVirtualFunctionCount, IovSupport установлен в True, а IovSupportReasons имеет единственное значение в своём массиве, "OK".

 

Рисунок B.30



Последним cmdlet является Get-VMNetworkAdapter. Его следует исполнять для работающего сетевого адаптера ВМ. Здесь вновь пример с какой- то физической машиной, которая не поддерживает SR- IOV и не имеет сетевого адаптера с возможностями SR- IOV. Даже хотя свойство IovWeight не нулевое, отметим, что IovQueuePairsAssigned и IovUsage равны нулю, а Status и StatusDescription содержат разворот причин почему данный сетевой адаптер деградировал.

 

Рисунок B.31



Вот некая "хорошая" машина для сравнения. Отметим, что IovUsage равен 1.

 

Рисунок B.32



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

 

Рисунок B.33



К сожалению, значение StatusDescription не оказывается полезным для указания точной причины. На самом деле, по целому ряду технических причин это нечто, что невероятно сложно точно обеспечить, так что навряд ли что- то изменится к окончательному выпуску. Вместо этого вам следует взглянуть на применяемые политики. В данном конкретном сучае я включил RouterGuard в своей ВМ. Когда мы применяем политику, которая может быть применена только виртуальным коммутатором, а не физической NIC, мы автоматически отключаем SR- IOV в такой ВМ с тем, чтобы можно было применить эту политику. Отключение любых таких политик (при условии, что это совместимо с требованиями сетевой конфигурации вашей ВМ) позволит SR- IOV вновь начать работать.

Теперь, хотя я упомянул об этом в более раннем сообщении, однако если вы всё ещё пытаетесь активировать SR- IOV и полагаете, что у вас есть всё, что вам необходимо (набор ммикросхем, сетевой адаптер, виртуальный коммутатор в режиме SR- IOV), имеется ещё один момент, который несомненно стоит проверить. Некоторые BIOS имеют более одного параметра втроенного ПО для включения SR- IOV. Если вы сомневаетесь, всегда вновь обращайтесь к документации производителя систем с тем, чтобы убедиться что все настройки выполнены корректно. И помните, что если вы изменяете настройки BIOS, вам может понадобиться жёсткий цикл перезагрузки машины с вуключением питания, а не просто мягкий перезапуск.

Имеются также ещй две другие причины, о которых стоит упомянуть. Одна состоит в том, что если вы применяете клиента Hyper-V, поскольку это только свойство сервера, необходимый интерфейс пользователя для SR- IOV не существует в Диспетчере Hyper-V в клиенте. (Заметим, что сами опции SR- IOV появятся если вы применяете Диспетчер Hyper-V в клиенте, подключённом к удалённому Windows Server "8")/

 

Рисунок B.34



 

Рисунок B.35



Если вы исполнили get-vmhost в клиенте, лн укажет что SR- IOV не поддерживается.

 

Рисунок B.36



И аналогично для виртуального коммутатора (к сожалению, у моего ноутбука нет сетевого адаптера 10G, который поддерживает SR- IOV - это будет следующим обновлением :)!)

 

Рисунок B.37



Так что это в значительной степени связано с диагностикой того, почему SR-IOV может не работать. Если вы поняли всё вышеперечисленное, вы теперь полноценный супергерой и заслужили награду!

Вероятно ещё одна часть поступит в этот сериал- часть "кухонной мойки" - как и во всём, что уже обсуждалось. Надеюсь, это будет на следующей неделе после того, как я найду время чтобы написать её.