PCIe passthrough для GPU и NVMe: BIOS/UEFI на HPE и Dell

Зачем нужен PCIe passthrough и где чаще всего болит

PCIe passthrough для GPU и NVMe - это режим, когда виртуальной машине отдают устройство почти как на физическом сервере: не «виртуальный диск» или «виртуальную видеокарту», а конкретный NVMe-накопитель или GPU по PCIe. Его выбирают, когда важны максимальная скорость, низкие задержки и доступ к функциям железа, которые не проходят через обычную виртуализацию (например, CUDA на GPU или близкая к нативной производительность NVMe).

На стенде все нередко выглядит стабильно, а в продакшене начинаются сюрпризы. GPU и NVMe чувствительны к PCIe-топологии, IOMMU-группам, питанию и нюансам прошивок. Эти устройства активно используют DMA, поэтому ошибки от «почти правильных» настроек часто проявляются не сразу, а под нагрузкой.

Типовые симптомы:

• устройство периодически пропадает из ВМ или не поднимается после перезагрузки;
• ВМ зависает при старте драйвера GPU или при интенсивном I/O на NVMe;
• в логах появляются DMA/IOMMU, AER/PCIe errors;
• производительность скачет: было быстро, стало как на обычном виртуальном диске.

Часть проблем лечится настройками BIOS/UEFI: включением VT-d/AMD-Vi (IOMMU), корректными режимами SR-IOV/ACS (если они вообще доступны на платформе), включением Above 4G Decoding и отключением лишнего энергосбережения PCIe. Но если видите странные ресеты, нестабильность под нагрузкой или не получается нормально развести устройства по IOMMU-группам, это часто уже про подбор и совместимость железа: конкретные модели GPU/NVMe, версии firmware, PCIe-слоты и райзеры, питание и охлаждение.

Подготовка: что проверить до входа в BIOS/UEFI

PCIe passthrough для GPU и NVMe часто ломается не в BIOS/UEFI, а из-за мелочей вокруг. Потратьте 15-20 минут до перезагрузки сервера: это экономит часы на поиске «плавающих» зависаний и ошибок сброса устройства.

Начните с совместимости платформы. Важно не только наличие IOMMU (VT-d или AMD-Vi), но и то, как разведены линии PCIe. Бывает, что нужный слот делит линии с другим устройством или физически сидит за другим сокетом CPU. Это напрямую влияет на IOMMU-группы и иногда на стабильность.

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

Для NVMe отдельно оцените способ подключения: U.2, M.2 или PCIe-адаптер. Не все накопители одинаково спокойно переживают reset в виртуализации. Тревожные признаки - редкие зависания при перезапуске ВМ, потеря диска после миграций (если вы вообще пробуете их с passthrough), ошибки power state.

Короткий набор проверок перед входом в BIOS/UEFI:

• зафиксируйте гипервизор и версию, чтобы тестировать конкретную связку;
• проверьте, что слот PCIe дает нужную ширину (x16/x8) и поколение;
• убедитесь, что питание GPU подключено правильно и с запасом по линии;
• подготовьте план обновления прошивок (BIOS/UEFI, iLO/iDRAC, firmware GPU/NVMe);
• сохраните текущие настройки, чтобы можно было быстро откатиться.

Пример: NVMe стоит через PCIe-адаптер, рядом добавляете вторую GPU. Если слоты делят линии, одна из карт может уйти в x4, а в passthrough это иногда проявляется только под нагрузкой. Лучше поймать это на этапе инвентаризации.

Базовые опции BIOS/UEFI, которые влияют на passthrough

Успешный PCIe passthrough почти всегда упирается в несколько настроек BIOS/UEFI. Они отвечают за изоляцию устройств, адресное пространство PCIe и то, как система перечисляет железо.

1. IOMMU (Intel VT-d или AMD-Vi) должно быть включено. Без IOMMU гипервизор не сможет безопасно «отдать» устройство ВМ: DMA начнет ходить куда не надо, а IOMMU-группы часто окажутся слишком крупными.

2. Above 4G Decoding (64-bit MMIO) для современных GPU и быстрых контроллеров обычно критичен. У видеокарт большие BAR, им нужно большое MMIO-окно. Если опция выключена, карта может определяться, но драйвер падает при старте ВМ, появляется черный экран или происходят ребуты хоста.

3. Resizable BAR иногда помогает, когда гостевая ОС активно работает с памятью видеокарты. Но на части платформ добавляет нестабильность в виртуализации. Практичнее сначала добиться стабильности без него, а потом включать и сравнивать под нагрузкой.

4. SR-IOV включайте только когда он действительно нужен (обычно для сетевых карт и некоторых контроллеров). Если SR-IOV не используете, лучше оставить выключенным: меньше сюрпризов с IOMMU-группами и распределением ресурсов.

5. Режим загрузки. Чистый UEFI и выключенный CSM обычно дают более предсказуемое перечисление PCIe-устройств. С CSM чаще всплывают проблемы с Option ROM, и passthrough превращается в лотерею.

Минимальный набор перед тестами:

• IOMMU (VT-d или AMD-Vi) - Enabled
• Above 4G Decoding - Enabled
• Boot Mode - UEFI, CSM - Disabled
• SR-IOV - только при необходимости
• Resizable BAR - по умолчанию Disabled

Простой пример: передаете в ВМ GPU для расчетов. Если Above 4G Decoding выключен, ВМ может запускаться, но драйвер GPU падает при первом же тесте нагрузки.

Типовые настройки на HPE: что искать в меню

На серверах HPE нужные опции обычно находятся в System Utilities (F9 при старте), дальше - BIOS/Platform Configuration (RBSU). Названия пунктов немного меняются между поколениями ProLiant, но смысл одинаковый.

Virtualization и Security

Для passthrough нужна аппаратная поддержка IOMMU: на Intel это VT-d, на AMD - AMD-Vi. На HPE эти настройки чаще лежат в Virtualization Options или Security.

Что важно помнить: VT-x/AMD-V включают почти всегда, но для passthrough решает именно VT-d/AMD-Vi. Если после включения устройство все равно не попадает в отдельную IOMMU-группу, дополнительно проверьте, не включен ли CSM и не упираетесь ли вы в дефицит PCIe-ресурсов.

PCIe, MMIO и режим загрузки

Для связки GPU + NVMe часто упираются в MMIO. Найдите и включите Above 4G Decoding (если пункт есть). Переведите сервер в чистый UEFI и отключите CSM/Legacy - так меньше неожиданных конфликтов ресурсов и проблем с ROM-инициализацией.

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

• Virtualization Technology (VT-x/AMD-V) - Enabled
• Intel VT-d или AMD-Vi (IOMMU) - Enabled
• Boot Mode - UEFI, CSM/Legacy - Disabled (если поддерживается)
• Above 4G Decoding - Enabled (если есть)
• SR-IOV - включать только при реальном использовании

Отдельно про питание: агрессивные режимы энергосбережения иногда дают редкие обрывы или «зависания» PCIe-устройств под нагрузкой. Если ловите нестабильность, начните с отключения ASPM (если доступно) и выберите более предсказуемый профиль питания (максимальная производительность). Экономию возвращайте по одному пункту и сразу перепроверяйте.

Типовые настройки на Dell: что искать в меню

На серверах Dell PowerEdge параметры обычно разнесены по нескольким разделам BIOS Setup. Формулировки отличаются между поколениями, но логика одна: включить виртуализацию ввода-вывода, дать PCIe достаточно адресного пространства, затем проверить слоты и профиль питания.

Virtualization Support и профиль системы

Начните с Virtualization Support. Для passthrough обычно нужно включить VT for Directed I/O (VT-d) (на Intel) или аналог для вашей платформы. Пункт SR-IOV включайте только если используете SR-IOV (например, для сетевых карт). Для GPU и NVMe passthrough это не обязательное требование.

Дальше загляните в System Profile. Если есть выбор профиля, на время тестов выбирайте профиль производительности: так меньше шансов получить неожиданные ограничения по питанию и частотам. Это особенно заметно, когда в одной ВМ и GPU, и быстрый NVMe.

PCIe, адресное пространство и слоты

В разделе про PCIe/Integrated Devices проверьте вещи, которые чаще всего ломают passthrough:

• Above 4G Decoding - должен быть включен, иначе крупные BAR у GPU могут не поместиться.
• Bifurcation - важен, если используете райзеры или плату с несколькими устройствами на одном слоте. Режим должен соответствовать железу.
• Memory Mapped I/O (если встречается как отдельный пункт) - убедитесь, что выделенного пространства достаточно.
• Ненужные встроенные устройства - при дефиците ресурсов их иногда приходится отключать.

Быстрая проверка здравого смысла: после включения Above 4G Decoding и VT-d система должна стабильно видеть GPU и NVMe, без «исчезновения» после перезагрузки. Если устройство пропадает или ВМ не стартует, чаще всего проблема в адресном пространстве или настройках конкретного слота.

Настройки на уровне гипервизора: общая логика без привязки к вендору

После того как в BIOS/UEFI включены IOMMU (VT-d или AMD-Vi), основная работа переезжает в гипервизор. Логика везде похожая: выбрать правильное PCIe-устройство, закрепить его за ВМ и заранее убедиться, что устройство нормально переживает перезагрузки. Это одинаково важно и на HPE/Dell, и на любых стойках, включая серверы класса GSE S200.

Что именно отдавать в passthrough

С GPU частая ошибка - передать только графическую функцию и забыть про вторую «часть» видеокарты. У многих карт рядом есть аудиофункция (HD Audio), а у некоторых решений - отдельный USB-контроллер. Если отдать в ВМ только половину, драйвер может работать нестабильно или не подняться.

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

Короткая проверка перед закреплением:

• видны ли все функции устройства (GPU + audio и т.п.);
• нет ли в IOMMU group лишних устройств;
• нужна ли миграция ВМ (с passthrough чаще всего нет).

Закрепление и перезагрузки: где ломается чаще всего

ВМ с passthrough нельзя «случайно» унести на другой хост. Поэтому обычно отключают live migration для такой ВМ или настраивают жесткий affinity/pinning, чтобы она всегда запускалась на одном узле.

Вторая частая ловушка - reset устройства. Некоторые GPU или PCIe-карты после перезагрузки ВМ не возвращаются в «чистое» состояние: драйвер в госте падает, а хост видит устройство занятым до перезагрузки сервера. Это нужно ловить до продакшена: несколько циклов reboot в госте и несколько циклов полного выключения/включения ВМ.

Из параметров, которые чаще всего влияют на стабильность, обычно всплывают MSI/MSI-X (прерывания), AER (отчет об ошибках PCIe) и поведение устройства в IOMMU. Если под нагрузкой растет счетчик PCIe-ошибок или появляются timeouts, лучше остановиться и сначала разобраться с причиной.

Про NVMe: безопаснее и предсказуемее отдавать в passthrough весь NVMe-контроллер (целый PCIe-девайс), а не «диск как файл/том». Это дает почти нативную производительность, но требует, чтобы NVMe был выделен под одну ВМ и не делился с хостом.

Пошаговый план настройки и первичной проверки

Этот план помогает быстро понять, взлетит ли PCIe passthrough для GPU и NVMe на вашем железе, и поймать проблемы до установки драйверов и переноса нагрузки.

Держите настройку в виде короткого цикла: включили опции - проверили хост - проверили гостя - дали нагрузку - повторили после перезагрузок.

Короткий рабочий сценарий (5 шагов)

1. После изменения BIOS/UEFI сохраните конфигурацию и полностью перезагрузите хост. На время тестов избегайте агрессивного энергосбережения: оно иногда делает поведение PCIe менее предсказуемым.

2. На хосте проверьте, что IOMMU реально включился и нет критичных ошибок по шине. В логах ищите IOMMU/VT-d/AMD-Vi и AER/PCIe errors. Быстрый ориентир на Linux:

dmesg | egrep -i "iommu|vt-d|amd-vi|aer|pcie"

3. Назначьте устройство в ВМ и проверьте обнаружение внутри гостя. Важно не просто «увидеть» устройство, а убедиться, что это правильный PCI ID/модель, и что оно не делит IOMMU-группу с тем, что нужно хосту.

4. Дайте короткую нагрузку и соберите логи. Для GPU - тест вычислений или рендера, для NVMe - чтение/запись 5-10 минут. Сразу проверьте: не растет ли AER, нет ли сбросов устройства, зависаний драйвера, таймаутов.

5. Повторите тест после перезагрузки хоста и нескольких перезапусков ВМ (3-5 циклов). Многие проблемы вылезают на втором старте: устройство не возвращается после reset, меняется адресация/ресурсы, появляется конфликт BAR.

Если на любом шаге видите PCIe-ошибки или нестабильность после перезапусков, не усложняйте дальше. Сначала приводите в порядок базу (BIOS/UEFI, firmware, питание), а потом переходите к долгим прогонам.

Тесты до продакшена: что прогонять и что смотреть

PCIe passthrough для GPU и NVMe чаще ломается не в момент настройки, а под нагрузкой и после перезагрузок. До продакшена проверьте три вещи: производительность, стабильность и восстановление устройства после reset.

Минимальный набор проверок, который быстро показывает явные проблемы:

• GPU: тест вычислений и тест видеопамяти под нагрузкой, плюс контроль температуры и частот (без резкого троттлинга через 5-10 минут)
• NVMe: последовательный и случайный I/O, отдельно чтение и запись, с фиксацией средних и 99-процентильных задержек
• Reset-тест: 10-20 перезапусков ВМ подряд и проверка, что устройство каждый раз инициализируется без ручных действий
• Ошибки шины: мониторинг PCIe AER и повторяющихся corrected errors
• Длительный прогон: 2-8 часов смешанной нагрузки, чтобы увидеть деградацию и накопление ошибок

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

Что фиксировать в отчете:

• GPU: стабильность частот, температура, ошибки драйвера (например, Xid), повторяемость результатов
• NVMe: p99 latency, глубина очереди, ошибки записи, timeouts
• Система: AER-сообщения, WHEA-ошибки, «отвалы» устройства после reboot
• Поведение после миграций и снапшотов (если используете): нет ли зависаний при старте ВМ

Пример: ВМ для аналитики, где GPU считает, а NVMe хранит локальный датасет. На коротком тесте все быстро, но после 12 перезапусков ВМ GPU один раз не поднимается и появляется серия corrected AER. Это сигнал вернуться к IOMMU, ASPM и порядку инициализации устройств, пока проблема не стала продакшен-инцидентом.

Типовые ошибки и ловушки, из-за которых все падает

Самая частая причина внезапных проблем проста: IOMMU (VT-d для Intel или AMD-Vi) включили, а связанные опции оставили по умолчанию. Без Above 4G Decoding серверу может не хватить адресного пространства под большие устройства, и GPU либо не поднимается, либо драйвер падает сразу после старта.

Вторая ловушка - смешанные режимы загрузки. Когда часть системы живет в UEFI, а часть в Legacy/CSM, симптомы бывают странные: ВМ не стартует после изменений, устройство видно до ребута и пропадает после, установщик ОС «не видит» диск. На HPE и Dell это часто всплывает после обновления прошивок, когда настройки могли сброситься.

Ресурсы и питание: редкие проблемы, которые долго ищут

Даже при правильных галочках passthrough может рушиться из-за нехватки MMIO. Признаки: устройство отображается, но не инициализируется, появляются ошибки выделения ресурсов, GPU уходит в Code 43 или аналог, а NVMe становится нестабильным под нагрузкой.

Энергосбережение тоже умеет портить жизнь. ASPM и агрессивные C-states иногда дают редкие, но тяжелые зависания: раз в несколько часов ВМ «замирает», а в логах почти пусто. Если ловите такое, временно отключите энергосберегающие режимы и сравните поведение.

Reset и «исправленные» ошибки, которые не стоит игнорировать

С NVMe частая боль - reset. После перезагрузки ВМ диск может исчезать, потому что устройство плохо переносит виртуальный reset или гипервизору нужен другой режим сброса.

И не игнорируйте corrected PCIe ошибки (AER). Они «исправленные», но под нагрузкой превращаются в обрывы, таймауты и спонтанные ребуты драйвера.

Чтобы быстрее локализовать проблему, проверьте:

• включены ли VT-d/AMD-Vi и Above 4G Decoding;
• единый режим UEFI без Legacy/CSM;
• нет ли признаков нехватки MMIO (ошибки ресурсов, падения драйвера);
• не исчезает ли NVMe после reboot ВМ;
• растут ли corrected PCIe ошибки в логах во время тестов.

Быстрый чек-лист перед выкаткой в продакшен

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

• BIOS/UEFI: включены VT-d (Intel) или AMD-Vi (AMD), и включен Above 4G Decoding (если доступно).
• Загрузка: чистый UEFI, CSM/Legacy отключен.
• Логи: нет устойчивых PCIe/AER ошибок в простое и под нагрузкой, нет повторных таймаутов.
• Рестарты: 10-20 перезапусков ВМ подряд (включая полное выключение и включение) без изменений поведения устройства.
• Производительность: тест повторяется 3-5 раз с близкими задержками и пропускной способностью; подготовлен понятный план отката.

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

Реальный пример: GPU и NVMe в одной ВМ и как поймать проблему заранее

Сценарий простой: один сервер (типичный HPE или Dell), одна ВМ под ML-инференс с passthrough на GPU, и отдельный NVMe с passthrough под кэш (например, для быстрых моделей и временных данных). На стенде все завелось, но через 20-30 минут нагрузки ВМ начала внезапно перезагружаться.

Что сделали правильно: включили IOMMU (VT-d или AMD-Vi), отключили лишние виртуальные устройства у ВМ и закрепили vCPU/память. Что пропустили: в BIOS/UEFI не включили Above 4G Decoding (иногда рядом встречается Re-Size BAR), а профиль питания оставили «сбалансированным». В итоге GPU периодически отваливался при пиковом потреблении, а NVMe ловил ошибки шины.

Подсказки пришли из симптомов. В логах хоста появились строки про IOMMU fault и PCIe AER errors (исправляемые, но частые). Метрики показали скачки latency на NVMe и падение производительности инференса перед перезагрузкой ВМ.

Исправление оказалось набором понятных шагов:

• включили Above 4G Decoding и (если доступно) выставили PCIe на Gen3 вместо Auto для конкретного слота;
• переключили power profile на Maximum Performance и отключили агрессивное энергосбережение PCIe;
• переставили NVMe в другой слот/порт, чтобы развести устройства по разным корневым комплексам (на части платформ это снижает «шум» на шине).

Чтобы не ловить это перед продом, результат оформили как шаблон: фиксированный набор BIOS/UEFI опций и минимальные тесты.

• прогон GPU (15-30 минут) параллельно с интенсивным I/O на NVMe;
• мониторинг AER/IOMMU ошибок в логах хоста;
• контроль температуры и потребления;
• повторный старт ВМ 10-20 раз подряд.

Следующие шаги: как стандартизировать настройки и проверку

Когда passthrough уже завелся на одном стенде, главный риск - повторить успех на другом сервере, в другом слоте и с другой прошивкой. Снижает риск простая дисциплина: одинаковые профили, одинаковые тесты, понятные критерии приемки.

Полезный набор артефактов, который стоит поддерживать в актуальном виде:

• матрица совместимости: модель сервера, конкретный слот, GPU/NVMe (и ревизия), версии BIOS/UEFI и прошивок, версия гипервизора, результат тестов;
• эталонный профиль BIOS/UEFI (скриншоты или короткое описание опций) и правило «что менять нельзя»;
• эталонные параметры хоста (IOMMU, драйверы, политики энергосбережения) и минимальный набор модулей/пакетов;
• набор тестов «перед продакшеном» с командами и порогами (например, допустимый p99 latency для NVMe);
• шаблон отчета приемки: что проверили, что увидели, какие отклонения допустимы.

Отдельно заранее решите, где passthrough действительно нужен, а где он усложняет эксплуатацию. Обычно помогает простое правило: чем больше пользователей и чем важнее миграции/HA, тем осторожнее с passthrough.

• Passthrough: максимум производительности и предсказуемости, но меньше гибкости (миграции, кластерные возможности).
• vGPU: когда важна плотность и управляемость, а «абсолютный максимум» не обязателен.
• Выделенный хост: когда требования по изоляции и поддержке важнее экономии ресурсов.

Если нужно собрать стенд под ключ и закрыть вопросы совместимости, поставки и поддержки, имеет смысл подключать системного интегратора. GSE.kz (gse.kz) поставляет серверы и рабочие станции, делает системную интеграцию и обеспечивает круглосуточную поддержку по Казахстану, что удобно при масштабировании одинаковой конфигурации на несколько площадок.