Virtualize iommu vmware что это

Обновлено: 02.07.2024

> 1. у нас есть: Количество процессоров, количество ядер.

> Процессор появляется программными средствами

"Процессор" (точнее - виртуальный сокет) - полностью(почти ) виртуален.

виртуальные ядра (VCPU) - реальны.

> добавить два vCPU. Откуда они берутся, из ядер или откуда?

vCPU делается из физического ядра. Физическое ядро передается во временное пользование VM

(с разделением времени, ровно так же как обычная операционка выдает ядра приложениям)

> 2. Что будет эффективней в виртуальной машине 2 vCPU с 2 ядрами к примеру или 1 vCPU с 2-4 ядрами?

Абсолютно без разницы. 1x4, 2x2, 4x1 - играет роль только итоговое количество vCPU - в вашем случае 4.
Разумнее - оставить дефолтный вариант - 4 сокета по одному vCPU (если, конечно, в виртуалке не используются лицензии завязанные на количество сокетов)

> 3. Так же вопрос vmWARE WorkStation использует только физические ядра или потоки тоже?

Если потоки есть - vCPU 'катается" на потоке, если потоков нет - vCPU едет на физическом ядре

> Допустим у меня 2 ядра и 4 потока. Я же могу указать под виртуальную машину 4 ядра?

Да. По потоку на vCPU

> Как Виртуальная машина определяет, поставил я ядра или потоки?

Никак. Когда исполняется на физическом ядре -

видит ровно то же, что и сидя в потоке. Единственная разница - поток (часто)

работает в два раза медленнее ядра. Впрочем, если в одном потоке ядра сидит vCPU

а в другой поток ничего не назначено - поток будет работать со скоростью физического ядра.

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

> Если я поставлю количество 12 к примеру, но у меня столько не будет ядер и потоков.

> Она тоже запустится и по какому принципу будет работать?

Она не запустится.

Количество vCPU у VM должно быть меньше-или равно количеству потоков

> 4. Параметры Виртуальный Intel VT-x/EPT или AMD-V/RVI что означает?

Аппаратная поддержка виртуализации процессора

> В каких случаях их выставлять надо, в каких нет.

Практически всегда лучше выставлять. Тогда виртуализация будет тормозить

на несколько процентов меньше. А на Xeon'ах с отключенным VT-x/EPT

можно запускать только 32-разрядные виртуалки, а 64-битные требуют VT-x.

В тех редких случаях, когда VT-x включен, но его использование "мешает" экзотическим настройкам режимов работы VM, гипервизор будет исполнять VM в режиме "binary translation", без использования функционала VT-x


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

Как периферийные устройства взаимодействуют с процессором? Использование ОЗУ системы в качестве общей точки для взаимной связи, но это подразумевает ряд механизмов, наиболее важным из которых является тот, который мы собираемся описать ниже.

Где находится IOMMU?

Южный мост северного моста IOMMU

Как видно на схеме выше, периферийные устройства подключены к южному мосту или южному мосту, который, в свою очередь, подключен к северному мосту, который является концентратором, с которым, в основном, обмениваются данными интерфейс оперативной памяти и процессора. каждый. Что ж, IOMMU расположен внутри южного моста, где сосредоточены все интерфейсы ввода-вывода, такие как USB, PCI Express, SATA и т. Д.

Все эти интерфейсы должны находиться под управлением IOMMU для доступа к системной RAM. В этом случае IOMMU действует как своего рода пограничный контроль, который следит за тем, чтобы периферийные устройства не осуществляли незаконный доступ к памяти и не обращаются к той части ОЗУ, которая назначена каждому из них и никуда больше.

Таким образом, IOMMU действует как MMU, но для периферийных устройств ввода-вывода.

В чем его полезность?


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

Здесь на помощь приходит IOMMU, выступающий в качестве ведомого устройства для MMU, с которым он связан через северный / северный мост системы. Благодаря этой связи периферийные устройства знают, к каким адресам RAM у них есть разрешение на доступ, а к каким - нет.

С другой стороны, IOMMU автоматически и динамически назначает адреса памяти для связи с различными периферийными устройствами, таким образом, ЦП всегда знает, на какие адреса памяти он должен указывать для связи с ними.

Исходная карта памяти ПК IOMMU

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

Сегодня это уже не так, и наличие IOMMU позволяет разработчикам избавиться от необходимости изучать адреса памяти для связи и расширяет возможности конфигурации и настройки наших ПК, позволяя создавать совершенно разные конфигурации.

Использование IOMMU в виртуализированных системах

Сквозная передача устройства IOMMU

IOMMU обеспечивает безопасный доступ к физическим устройствам в виртуализированных средах посредством того, что мы называем сквозной передачей устройств. Тандем между MMU и IOMMU позволяет устройствам, подключенным к ПК, появляться в пространстве виртуальной памяти, которое выполняет функцию физической памяти для виртуальной среды, которая работает в данный момент.

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



Эта статья будет посвещена настройки хоста именно для использования в «быту», т.е. разговор пойдет о GPU PASSTHROUGH.

Введение


Сперва несколько слов про виртуализацию в целом. Согласно Википедии:
Виртуализа́ция — предоставление набора вычислительных ресурсов или их логического объединения, абстрагированное от аппаратной реализации, и обеспечивающее при этом логическую изоляцию друг от друга вычислительных процессов, выполняемых на одном физическом ресурсе.

Достигается как при помощи приложений (например VirtualBox, VMware) так и на уровне систем, поддерживающих аппаратную виртуализацию (например KVM, ESXi, Hyper-V). В последнем случае потери производительности по сравнению с нативными системами минимальна.

Здесь и далее в статье будет описание настроек системы виртуализации с открытым исходным кодом Proxmox потому что она в меру дружелюбна, есть легкий доступ к консоли через веб форму, а так же базируется на связке Debian + kvm, по которым очень много гайдов и описаний в сети, т.е. документации в т.ч. и на русском языке.

Требования к железу

— процессор и материнская плата с поддержкой VT-x, VT-d от Интел или AMD-Vi, IOMMU от АМД. Не поленитесь и уточните поддерживает ли именно Ваш экземпляр данные требования.

Что касается материнских плат. Категорически не рекомендую гнать железо при посредственной разводке на плате питания. По Z270 и Z390 игнорировать оранжевую зону или оставлять работать в стоке.

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

Установка и настройки

Мною было использована следующая игровая конфигурация:

— ПК для хоста конфиг был собран на далеко не лучшей материнской плате, но на англоязычных форумах очень часто хвалят эту фирму за то, что ее железо чаще всего подходит для таких вещей:
Процессор — i7 8700k
Мать — ASRock Z390M Pro4
Видеокарта — INNO3D GeForce GTX 1070 iChill X4
— второй ПК (Мини-ПК Morefine-M1s),
— 2 мыши,
— 1 клавиатуру на хосте, на остальных устройствах использовал софтварную,
— 3 подключения к монитору Dell U2713HM (VGA — для интегрированной видеокарты, HDMI — для GTX1070, на DVI находится Мини-ПК. Переключения между видеосигналами осуществлял через меню монитора)

0й этап — На материнской плате включаем VT-d:Enable, Intel Vitrualization Technology:Enable, Primary Graphx adapter:VGA, Above 4G Decoding:Enable. Если есть возможность обязательно выбираем основным графическим адаптером тот, на котором будет работать хост, т.е. более слабую видеокарту и переключаемся на нее.

1й этап — Устанавливаем Proxmox на хост. Для этого:

1.1. Скачиваем образ диска с официального сайта

1.2. Пишем образ на флешку при помощи специальных программ

1.3. Загружаемся с флешки, и производим инсталляцию с указанием на какой жесткий диск ставить, вводим пароль для будущего пользователя root, а так же настройки сети прописываем явно.

2й этап — Подключаемся по сети через веб интерфейс при помощи второго ПК или
планшета (в моем случае это был Мини-ПК) к хосту и настраиваем Proxmox по этому гайду через текстовую консоль.

image

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

1) Run the «dmesg | grep ecap» command.

2) On the IOMMU lines, the hexadecimal value after «ecap» indicates whether interrupt remapping is supported. If the last character of this value is an 8, 9, a, b, c, d, e, or an f, interrupt remapping is supported. For example, «ecap 1000» indicates there is no interrupt remapping support. «ecap 10207f» indicates interrupt remapping support, as the last character is an «f».

Interrupt remapping will only be enabled if every IOMMU supports it.

Если условие выполняется — продолжаем.

Открываем файл командой из консоли (символ двойной решетки вводить не надо, так я буду разделять в тексте команды от того что необходимо внести в файл)


для процессоров Интел


для процессоров АМД


следом даем команду


после чего перезагружаем хост через веб интерфейс

Добавляем в файл конфигурации загрузку необходимых драйверов

Прописываем в консоли


На экран будет выведен список устройств доступных для проброса, находим интересующий нас блок с видеокартой, в моем случае это 2 устройства в группе видеокарта и звук по адрсам 01:00.0 и 01:00.1, поэтому я прописываю сразу группу.

Прописываем в консоли команду для того что бы определить модель и ее id

Теперь правим файл под нашу видеокарту (в Вашем случае id будут иные)

Заносим в черный лист драйвера

Теперь создаем через веб интерфейс и правим через консоль файл настроек виртуальной машины. Здесь строка «args:» решает, т.к. без нее драйвер видеокарты обнаружит виртуализацию, но путем подмены наименования оборудования, точнее hv_vendor_id=willitwork, мы снимаем проблему с ошибкой 43, которую может выдать видеодрайвер устройства. Здесь есть номер виртуальной машины в proxmox используемый в качестве имени.

Файл настроек виртуальной машины для ПК в статье

Теперь перезагружаем хост и запускаем виртуальную машину.

3й этап — Через Удаленную видеоконсоль установим Windows и драйвера. В моем случае Windows распознал сперва видео драйвер proxmox для работы через видеоконсоль, потом нашел драйвер для GTX1070, а после обновления через интернет (принудительный поиск драйверов в сети) скачал и установил нужный мне драйвер для игровой видеокарты.

4й этап — Перезапустим Виртуальную машину, переключаем отображение видеопотока на мониторе на разъем видеокарты и… в моем случае все заработало сразу, никаких ошибок 43… При этом рабочий стол определяется как №2.

я попробовал запустить видео Blue-ray — без проблем, задержек и фризов с видеорядом нет, запустил Warhammer online — он завелся и в PvP играть было комфортно, запустил GTA5 у мя выскочила сюжетка, вполне комфортно пострелял. Визуально потерь в производительности нет.

Если нам необходимо пробросить жесткий диск целиком, то в файле настроек виртуальной машины необходимо добавить строку:

Конкретно какой именно sda/sdb/sdc/и т.п. можно уточнить в веб интерфейсе.

image

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

00:1f.0 ISA bridge: Intel Corporation Device a305 (rev 10)
00:1f.3 Audio device: Intel Corporation Device a348 (rev 10)
00:1f.4 SMBus: Intel Corporation Device a323 (rev 10)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Device a324 (rev 10)
00:1f.6 Ethernet controller: Intel Corporation Device 15bc (rev 10)

Т.е. звук или через видеокабель на монитор или внешняя звуковая карта. Порты USB пробрасываюся без проблем. К сожалению на текущий момент нерешаемо. Есть вариант удаленного подключения с другого ПК к игровому, через RDP или SPICE. В этом случае все будет нормально

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

Для мыши — аналогично.

2. По USB:
Что касается USB устройств там все проще, устройства прокидываются прямо из веб формы по ID или же целиком можно прокинуть порт. Однако есть нюанс — если Вы по каким-либо причинам не можете как и я прокинуть аудиоустройство в ВМ, т.к. оно содержится в группе с ключевыми контроллерами без которых хост не может полноценно работать, то проброс порта/устройства через USB решает эту проблему, но звук может начать отваливаться через некоторое время работы, шипеть/гудеть и прочие… прочее, в то же время на нативной системе все будет замечательно. В этом случае необходимо пробрасывать не порт/устройство, а сам контроллер USB как PCIe устройство по методу указанному в статье. И все резко наладится. Но в то же время через хост после запуска ВМ с такими настройками пробросить другие устройства с этого контроллера больше не получится.

UPDATE 2
1. На этом видео видно, что для обхода ошибки 43 помогает обманка со следующей строкой в конфигурационном файле ВМ:

2. В связи с тем, что была обновлена версия ProxMox с 5й на 6ю, то что бы система работала с UEFI БИОСом, то необходимо добавить в оборудовании ВМ EFI-диск, иначе не взлетит и не заведется, на 5й версии ProxMox'а этой фичи не было.

Организуем несколько рабочих мест из одного десктопа.

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

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

Одно из них будет использовать Linux. Это может быть место приходящего админа, веб-разработчика или секретаря, обрабатывающего заказы.

Другие два, три и даже более (зависит он конфигурации материнской платы) рабочих места будут основаны на виртуальных машинах с выделенными для них ресурсами ввода-вывода (видеокарта, USB-порты). Использование таких виртуальных рабочих мест для пользователя практически ничем не будет отличаться от привычной работы за отдельным ПК. Дополнительным плюсом ко всему вышеуказанному будет возможность организовать на этих же мощностях файловое хранилище и другие необходимые инфраструктурные службы как на основе свободных бесплатных решений с использованием ОС семейства Linux (что предпочтительно), так и коммерческих. Это могут быть сервисы DHCP, DNS, брандмауэр/прокси для доступа в сеть Интернет, ряд других инфраструктурных служб.

Описанная выше конфигурация очень кстати придется для предприятий малого бизнеса. Преимущества описанного выше подхода использования одного мощного виртуализованного десктопа по сравнению с покупкой бюджетных моделей могут казаться не очевидными. А они есть:

  • Экономия бюджета. Действительно, на первый взгляд с финансовой точки зрения покупка одного десктопа на core-i5 может и не дать преимуществ перед покупкой двух ультрабюджетных десктопов/неттопов. Но уже при необходимости организации трех рабочих мест и хотя бы одной/нескольких инфраструктурных служб финансовые преимущества виртуализации могут быть заметны.
  • Увеличение производительности рабочих мест. Даже с учетом расходов на разделение ресурсов и виртуализацию виртуальная рабочая станция будет как минимум в два-три раза производительнее, чем бюджетные не виртуализованные аппаратные решения.
  • Гибкость в выделении ресурсов (память, ядра процессора) сотрудникам. В отчетный период можно выделить больше ресурсов на рабочее место бухгалтера, а если горит проект – выделить больше ресурсов разработчику. Пока сотрудник в отпуске или командировке, мощности его виртуальной машины можно отдать другим.
  • Более грамотная организация служб и изоляция их конфигураций от пользователей без ущемления их прав на рабочем месте. Часто для сокращения затрат инфраструктурные службы организуются прямо на рабочих местах сотрудника. Например, общие файловые ресурсы, прокси/брандмауэр для доступа в интернет. С использованием виртуализации для таких целей можно выделить отдельные виртуальные машины и не быть ограниченными в выборе ПО, совместимого только с одной операционной системой семейства Windows.

Есть, конечно, и недостатки:

  • Единая точка отказа, которая приведет к неработоспособности сразу нескольких рабочих мест. Здесь в каждом конкретном случае нужно рассмотреть возможные проблемы и пути их решения (ЗИП и резервное копирование никто не отменял).
  • Возможные проблемы с недостаточным количеством USB-портов (решаются многопортовым PCI-USB адаптером, USB-хабами).
  • Необходимость дискретной видеокарты на количество рабочих мест минус один (одно рабочее место на ОС хоста на встроенной графике).
  • Рабочие места на основе одного десктопа не могут быть сильно удалены друг от друга. Однако малый бизнес не настолько богат, чтобы выделять каждому сотруднику отдельный кабинет. В пределах одного-двух находящихся рядом небольших помещений такие виртуализованные рабочие места вполне реально организовать.

Кстати, это не просто теория: конфигурацию, аналогичную описываемой в статье, я использую дома с 2014 года. За это время был накоплен кое-какой опыт, которым мне с вами хочется поделиться.

Выбор аппаратной и программной конфигураций

Для того чтобы виртуализовать десктоп и организовать на его основе несколько рабочих мест, необходима поддержка аппаратной виртуализации (Hardware-assisted virtualization) и виртуализации ввода/вывода (IOMMU virtualization). Поддержка этих технологий должна быть реализована как на уровне аппаратной платформы, так и на уровне программной реализации (гипервизора).

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

На основе виртуализации ввода/вывода виртуальной машине с помощью «проброса» (pass-through) можно предоставить прямой доступ к устройствам ввода/вывода на шине PCI и более современных (например, PCI-E). Так можно организовать прямой доступ к видеокарте и USB-контроллерам и устройствам.

Основные вендоры начиная с 2005-2006 годов во многих своих решениях поддерживают аппаратную виртуализацию. У Intel поддержка аппаратной виртуализации процессором называется Intel VT-x, у AMD – AMD-V. Немного позже Intel и AMD разработали и добавили в свои аппаратные платформы поддержку виртуализации ввода/вывода (IOMMU virtualization). Intel назвал свою технологию Virtualization Technology for Directed I/O (VT-d), AMD – AMD I/O Virtualization Technology, которую сами называют IOMMU (распространено также название AMD-Vi).

Таким образом, выбор аппаратной платформы заключается в выборе процессора и материнский платы с поддержкой Intel VT-x и VT-d в случае выбора продукции Intel, а в случае AMD – с поддержкой AMD-Vi (IOMMU) для материнской платы и AMD-V и AMD-RVI для процессора.

Если закупка «железа» еще в планах, то не лишним будет заглянуть на сайты производителей, чтобы узнать о поддержке виртуализации ввода-вывода процессорами.

С материнскими платами сложнее, чипсет и BIOS должны поддерживать виртуализацию ввода/вывода. В BIOS материнской платы должен быть пункт VT-d в случае Intel, IOMMU или AMD-Vi для AMD. Все десктоп-чипсеты Q-серий от Intel начиная с Q35 (из современных это Q87, Q170, Q270) гарантированно поддерживают VT-d. Информацию о поддержке VT-d/Amd IOMMU(AMD-Vi) оборудованием можно почерпнуть в Wiki-разделах сайта проекта Xen и в Википедии. Если «железо» уже в наличии, выполнив команду:

date

22.09.2021

directory

Hyper-V, PowerShell, Windows Server 2019, Виртуализация

comments

комментариев 20

SR-IOV (Single Root Input/Output Virtualization) это технология виртуализации аппаратных устройств хоста, позволяющая предоставить виртуальным машинам прямой доступ к устройствам. Технология позволяет виртуализировать различные виды устройств, но чаще всего используется для виртуализации сетевых адаптеров. В этой статье мы расскажем, как правильно включить и настроить SR-IOV для сетевых адаптеров виртуальных машин на сервере Hyper-V.

SRV-IOV поддерживается в Hyper-V начиная с версии 2012, в том числе в бесплатном Hyper-V Server. Мы не будем погружаться в теорию SR-IOV, вы можете найти подробное описание технологии в сети. Для практического понимания достаточно знать, что SR-IOV позволяет предоставить доступ виртуальным машинам непосредственно к физическим сетевым адаптерам хоста, минуя обработку трафика виртуальными коммутаторами Hyper-V. Один физический сетевой адаптер в режиме SR-IOV может обслуживать несколько виртуальных машин.

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

Чтобы SRV-IOV работала на вашем хосте Hyper-V нужно выполнять ряд условий.

В первую очередь нужно включить поддержку SR-IOV и виртуализации в BIOS вашего сервера. В зависимости от вендора и модели сервера эти настройки могут отличаться.

  • Виртуализация: Intel (Virtualization Technology, Intel VT, VT-d, Vanderpool), AMD (SVM, AMD-V)
  • IOMMU
  • SR-IOV
  • ASPM

включить sr-iov в BIOS сервера

Каких-то пунктов может и не быть, даже пункта SR-IOV. Но это не означает, что SR-IOV не поддерживается сервером. Например, на материнских платах Supermicro пункт SR-IOV может отсутствовать, и при этом есть отключенный по умолчанию пункт ASPM. Если включить ASPM и поддержку виртуализации, то SR-IOV включится автоматически.

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

Вы можете проверить, поддерживается ли технология SR-IOV вашим Hyper-V сервером на аппаратном уровне с помощью PowerShell:

проверить поддержку IovSupport на сервере hyper-v

Если ваш сервер поддерживает эту функцию, то в поле IovSupport будет указано True. Если не поддерживает, то False. При этом в пункт IovSupportReasons будет описание причины, из-за которой SR-IOV не поддерживается. Причина как правило указывается довольно подробно. Вот типовые причины:

  • Ensure that the system has chipset support for SR-IOV and that I/O virtualization is enabled in the BIOS.
  • 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.
  • To use SR-IOV on this computer, the BIOS must be updated because it contains incorrect information describing the hardware capabilities. Contact your computer manufacturer for an update.
  • SR-IOV cannot be used on this computer because the processor does not support second-level address translation (SLAT). For Intel processors, this feature might be referred to as Extended Page Tables (EPT). For AMD processors, this feature might be referred to as Rapid Virtualization Indexing (RVI) or Nested Page Tables (NPT).
  • The chipset on the system does not do interrupt remapping, without which SR-IOV cannot be supported.
  • The chipset on the system does not do DMA remapping, without which SR-IOV cannot be supported.
  • SR-IOV cannot be used on this system as it has been configured to disable the use of I/O remapping hardware.
  • SR-IOV cannot be used on this system as it is reporting that there is no PCI Express Bus. Contact your system manufacturer for further information.
  • SR-IOV cannot be used on this system as the PCI Express hardware does not support Access Control Services (ACS) at any root port. Contact your system vendor for further information.

Полный вывод команды get-vmswitch | fl *iov* дает ряд полезной информации. Например:

Такие цифры сразу покажут сколько виртуальных устройств IOV доступно и сколько уже использовано виртуальными машинами.

включить Enable single-root I/O virtualization (SR-IOV) для виртуального коммутатора hyper-v

Либо включать опцию EnableIOV при создании коммутатора из командной строки PowerShell:

New-VMSwitch -Name "Ext_network" -NetAdapterName "Ethernet 2" -EnableIov 1

Важно. Нельзя включить поддержку SR-IOV после создания виртуального коммутатора. Если вы это не сделали сразу, придется его удалить и пересоздать.

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

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

Поэтому после сборки коммутатора проверьте его командой:

get-vmswitch | select IovSupport, IovSupportReasons, IovEnabled

Параметр IovEnabled показывает включен ли он.

Список сетевых адаптеров с поддержкой SR-IOV можно вывести с помощью PowerShell:

Get-NetAdapterSriov | sort name | ft Name, InterfaceDescription, SriovSupport

После того, как SR-IOV включен на уровне гипервизора и виртуального коммутатора, теперь его можно включить в виртуальных машинах (по умолчанию выключено). Опция Enable SR-IOV доступ в секции Hardware Acceleration сетевой карты виртуальной машины.

включить single root I/O virtualization в настройках виртуальной машины Hyper-V

Либо можно включить SR-IOV для сетевого адаптера виртуальной машины через PowerShell:

Set-VMNetworkAdapter -VMName testvm -VMNetworkAdapterName “Network Adapter” -IovWeight 100

Для отключения SR-IOV нужно изменить значение IovWeight на 0.

Ошибки при работе SR-IOV пишутся на Hyper-V в отдельный журнал в Event Viewer:

Application and Services Logs -> Microsoft -> Windows -> Hyper-V-SynthNic -> Admin.

Если SR-IOV работает штатно, то при запуске виртуальной машины в логе будут такие записи:

Технология SR-IOV дает хороший буст сетевой производительности виртуальных машин и гипервизора в целом. Максимальные результаты от использования SR-IOV вы заметите на хостах Hyper-V с большим трафиком виртуальных машин, который вызывает сильную нагрузку на хостовые CPU.

Предыдущая статья Следующая статья

page

page

page

Низкая скорость сети на хосте Hyper-V с Windows Server 2019 Установка VMWare ESXi в виртуальную машину Windows Hyper-V Маршрутизация между разными IP подсетями в Hyper-V Клонирование, импорт и экспорт виртуальных машин в Hyper-V

Спасибо. А нет ли опыта включения SR-IOV на материнских платах ASUS?
Вот какой результат дает диагностика:
(get-vmhost).IovSupport
True
(get-vmhost).IovSupportReasons

Вторая функция ничего не возвращает.

У Вас уже всё работает (IovSupport=True). Если НЕ работает, то IovSupportReasons указывается причина почему не работает (а если работает ,то там пусто).
Пересобирайте теперь виртуальный коммутатор (если он был собран без галки SR-IOV) и проверяйте работает ли в нём.

Если функция (get-vmhost).IovSupportReasons не возвращает ничего, то это не означает, что все работает.
В логах есть несколько ошибок:
Master_179_0_0: EXT_QP_MAX_RETRY_LIMIT/EXT_QP_MAX_RETRY_PERIOD registry keys were requested by user but FW does not support this feature. Please upgrade your firmware to support it.
For more details, please refer to WinOF User Manual.
Master_179_0_0: SRIOV cannot be enabled. Running in single-function mode.
Bios на материнке и сетевых картах последний. Вполне вероятно, что MB Asus bios не поддерживает эту функцию.

Кстати я предпочитаю команды:
get-vmhost | fl
и
get-vmswitch | fl

Они дают более подробный вывод.

>Мать вероятно не серверная?
Верно, игровая.
IovVirtualFunctionCount : 8
IovVirtualFunctionsInUse : 0
Написал производителям БИОСа, может помогут разобраться.

Name : Mellanox
Id : fb7cb754-7256-45c2-83ea-8dbb64b63a47
Notes :
Extensions :
BandwidthReservationMode : None
PacketDirectEnabled : False
EmbeddedTeamingEnabled : True
AllowNetLbfoTeams : False
IovEnabled : True
SwitchType : External
AllowManagementOS : True
NetAdapterInterfaceDescription : Teamed-Interface
NetAdapterInterfaceDescriptions :
NetAdapterInterfaceGuid :
IovSupport : True
IovSupportReasons :
AvailableIPSecSA : 0
NumberIPSecSAAllocated : 0
AvailableVMQueues : 516096
NumberVmqAllocated : 1
IovQueuePairCount : 8027
IovQueuePairsInUse : 16
IovVirtualFunctionCount : 8
IovVirtualFunctionsInUse : 0
PacketDirectInUse : False
DefaultQueueVrssEnabledRequested : True
DefaultQueueVrssEnabled : True
DefaultQueueVmmqEnabledRequested : True
DefaultQueueVmmqEnabled : True
DefaultQueueVrssMaxQueuePairsRequested : 16
DefaultQueueVrssMaxQueuePairs : 8
DefaultQueueVrssMinQueuePairsRequested : 1
DefaultQueueVrssMinQueuePairs : 1
DefaultQueueVrssQueueSchedulingModeRequested : StaticVrss
DefaultQueueVrssQueueSchedulingMode : StaticVrss
DefaultQueueVrssExcludePrimaryProcessorRequested : False
DefaultQueueVrssExcludePrimaryProcessor : False
SoftwareRscEnabled : True
RscOffloadEnabled : False
BandwidthPercentage : 0
DefaultFlowMinimumBandwidthAbsolute : 0
DefaultFlowMinimumBandwidthWeight : 0
CimSession : CimSession: .
ComputerName : HV3
IsDeleted : False
DefaultQueueVmmqQueuePairs : 8
DefaultQueueVmmqQueuePairsRequested : 16

Так, но тут же видно, что на уровне виртуального коммутатора тоже всё работает.
Надо смотреть что в логе Application and Services Logs -> Microsoft -> Windows -> Hyper-V-SynthNic -> Admin.
Вот те логи, которые Вы выше приводили, они откуда взяты?

Брали логи из mlx4_bus
>Application and Services Logs -> Microsoft -> Windows -> Hyper-V-SynthNic -> Admin.
Такого нет. Есть Application and Services Logs -> Microsoft -> Windows -> Hyper-V-VmSwitch -> Operational. Там ошибок нет.

Нашли логи в Application and Services Logs -> Microsoft -> Windows -> Hyper-V-Worker -> Admin.

12582 Network Adapter (D177948B-D880-42BC-ADDC-46B26F6FBFA8) started successfully. (Virtual Machine ID 364A642F-EB19-4900-B2F5-1AE3236FF9AE)

12589 The description for Event ID 12589 from source Microsoft-Windows-Hyper-V-SynthNic cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

The system cannot find message text for message number 0x%1 in the message file for %2

Собрал коммутатор без параметра -EnableEmbeddedTeaming $true. Результат тот же.
У меня сетевой адаптер с двумя портами на 40 GB. объединил их для увеличения количества
виртуальных функций. Результат тот же.
В Биосе включил технологии управляющие питанием. Результат тот же.
Все же прихожу к выводу, что не поддерживает материнская плата.

материнская плата SuperMicro H12SSL-NT, ОС Server 2019 Standart.

да и (get-vmhost).IovSupportReasons не показывает вообще ничего, но (get-vmhost).IovSupport показывает нормально True.

виртуальный коммутатор вроде создал, вроде работает, но не пойму всё ли правильно или нет. У меня кстати тоже нету в журналах Hyper-V-SynthNic, но в остальных вообще ниодной ошибки.

В информации о коммутаторе собранном на Броадкомах?

не, на броадкомах как раз не собирал. Нам надо как раз на Intel.

Потому что этот броадком может не поддерживать данную технологию либо она может быть не реализована производителем матери.

ну както странно. Современная материнка под AMD EPYC на базе ZEN2 и ZEN3 (именно новая модель а не новая ревизия старой от первых EPYC под новые), современные 10Гбит\с сетевые адаптеры Dual 10GBase-T LAN via Broadcom BCM57416, и показывает NotSupported.

Если «get-vmswitch | fl» выдает IovSupport=True и IovEnabled=True значит всё работает.

Name : Ethernet 4
InterfaceDescription : Intel(R) Ethernet Controller X540-AT2
Enabled : True
SriovSupport : NoVfBarSpace
SwitchName : DefaultSwitchName
NumVFs : 62

откопал даташит по бродкому, написано SR-IOV with up to 128 VFs. тоесть вроде поддерживается.

Get-NetAdapterSriov

Name : LAN3(BACKUP)
InterfaceDescription : Intel(R) Ethernet Server Adapter X520-2
Enabled : True
SriovSupport : Supported
SwitchName : DefaultSwitchName
NumVFs : 62

Name : WAN(INTERNET)
InterfaceDescription : Supermicro 10GBASE-T Ethernet Controller
Enabled : True
SriovSupport : NotSupported
SwitchName : Default Switch
NumVFs : 128

Читайте также: