Чем отличаются VT-x/AMD-V от VT-d/AMD IOMMU?

Это разные возможности платформы. VT-x или AMD-V отвечают за аппаратную виртуализацию CPU и нужны для обычных VM и вложенной виртуализации. VT-d или AMD IOMMU изолируют DMA-операции и позволяют безопасно назначать PCIe-устройства, включая GPU, виртуальной машине. Наличие одной возможности не означает наличие другой.

Можно ли использовать один GPU одновременно на хосте и в двух VM?

Обычно нет. При GPU passthrough физический PCIe GPU закрепляется за одной VM и становится недоступен одновременно хосту или другой виртуальной машине. Совместное использование возможно в режиме vGPU, но только если его поддерживают конкретные GPU, драйверы, лицензирование и платформа.

Нужен ли IOMMU, чтобы включить nested virtualization?

Нет, если VM не получает PCIe-устройства через passthrough. Для вложенной виртуализации внешний гипервизор должен передать внутренней VM расширения Intel VT-x или AMD-V. IOMMU требуется для DMA-изоляции и назначения PCIe-устройств, например GPU. При сочетании nested virtualization и GPU passthrough нужны оба набора возможностей.

Почему ESXi не даёт назначить GPU виртуальной машине?

Сначала сохраните текст ошибки и текущую конфигурацию VM, а затем сверяйте фактические PCI-адреса, а не только название адаптера. В ESXi проверьте состояние устройства командой esxcli hardware pci pcipassthru list: после включения DirectPath I/O обычно требуется перезагрузка хоста, и устройство должно получить статус, допускающий passthrough. Убедитесь, что в firmware включён VT-d или AMD IOMMU и что GPU, сервер и целевой релиз vSphere подтверждены VMware Compatibility Guide. Проверьте аудио- и другие зависимые функции GPU: часть платформ требует передавать их вместе с графической функцией. Не назначайте устройство, которое используется хостом, в том числе единственный адаптер локальной консоли. Добавляйте GPU только к полностью выключенной VM и меняйте режим UEFI/BIOS либо версию виртуального оборудования лишь при наличии требования в документации GPU или VMware. При неудаче откатите последнее изменение и используйте сетевое управление или out-of-band-консоль для восстановления доступа к хосту.

Почему Proxmox VE оставляет GPU у хоста?

Не меняйте параметры загрузки и VFIO наугад. После перезагрузки сначала подтвердите включение IOMMU командой dmesg | grep -Ei 'DMAR|IOMMU', затем проверьте драйвер GPU через lspci -nnk и состав IOMMU-группы в /sys/kernel/iommu_groups/. На Intel-хосте параметры IOMMU зависят от используемого загрузчика: для GRUB применяется настройка в /etc/default/grub с последующим update-grub, для systemd-boot — /etc/kernel/cmdline и proxmox-boot-tool refresh. Убедитесь, что доступны vfio, vfio_iommu_type1 и vfio_pci; при требовании документации релиза настройте их раннюю загрузку. Привязку к vfio-pci выполняйте осторожно: правило по vendor:device затронет все карты с теми же идентификаторами. Если в группе GPU находится нужное хосту устройство, сначала оцените другой PCIe-слот или поддерживаемую конфигурацию платформы, а не ACS override. Исходные конфигурации загрузчика и VM храните вне изменяемого узла.

Как проверить, что вложенная виртуализация действительно включена?

Недостаточно того, что внешняя VM успешно запускается. Внутренний гипервизор должен увидеть доступные расширения виртуализации CPU и запустить небольшую тестовую VM. Если внутренний гипервизор сообщает об отсутствии VT-x или AMD-V, проверьте настройки передачи hardware-assisted virtualization, тип CPU и совместимость гипервизоров.

GPU passthrough и вложенная виртуализация в ESXi и Proxmox VE

GPU passthrough и вложенная виртуализация решают разные задачи: в первом случае VM получает физическое PCIe-устройство, во втором — внутренний гипервизор получает расширения виртуализации CPU. Для passthrough нужны IOMMU, совместимость сервера, GPU и гипервизора, а также корректная изоляция устройства; для nested virtualization — Intel VT-x или AMD-V и явная передача этих возможностей внутренней VM. До любых изменений подготовьте независимый доступ к хосту: передача единственного или загрузочного GPU может лишить локального видеовывода.

Что проверить до начала работ

Работы выполняются на хосте виртуализации, а не в гостевой ОС. За аппаратную виртуализацию CPU отвечают Intel VT-x или AMD-V. За изоляцию DMA-операций и назначение PCIe-устройств отвечает IOMMU: у Intel это VT-d, у AMD — AMD IOMMU. Наличие VT-x или AMD-V не означает, что доступен VT-d либо AMD IOMMU, и наоборот.

Задача	Что требуется от CPU и firmware	Что дополнительно проверять
Обычные VM и nested virtualization	Intel VT-x или AMD-V включены и доступны гипервизору	Передачу CPU-расширений конкретной VM, тип CPU, совместимость внешнего и внутреннего гипервизоров
GPU passthrough	IOMMU: Intel VT-d или AMD IOMMU включены и доступны гипервизору	Совместимость сервера, GPU и релиза гипервизора; группу и зависимые PCIe-функции; драйвер Guest OS; загрузку VM
GPU passthrough + nested virtualization	Оба набора возможностей: VT-x/AMD-V и VT-d/AMD IOMMU	Два независимых набора настроек VM и ограничения каждого сценария

Сначала обеспечьте доступ для восстановления

Не назначайте VM адаптер, через который хост выводит локальную консоль, пока не проверены удалённое управление и возврат конфигурации. Используйте отдельную сеть управления и out-of-band-консоль сервера — BMC, iDRAC, iLO, XClarity Controller или аналог. Зафиксируйте текущие настройки firmware и конфигурацию VM. Снимок VM не является планом возврата passthrough-конфигурации.

Сверьте модель сервера, CPU, версию BIOS/UEFI и firmware PCIe-устройств с документацией производителя.
Для ESXi сверьте сервер, GPU и нужный релиз vSphere в VMware Compatibility Guide, затем откройте руководства Broadcom VMware по DirectPath I/O и виртуальным машинам именно для этого релиза.
Для Proxmox VE откройте разделы PCI(e) passthrough и nested virtualization в официальной документации установленного релиза Proxmox VE; также проверьте документацию используемого ядра и QEMU/KVM.
Проверьте у NVIDIA, AMD или Intel, допускает ли конкретная модель GPU виртуализированное применение, выбранный режим работы и нужный драйвер в Guest OS. Не переносите правила профессиональных ускорителей на потребительские GPU и наоборот.
Убедитесь, что управление хостом не зависит от передаваемых PCIe-устройств: сетевого адаптера, контроллера хранения, USB-контроллера с устройством ввода или единственного графического адаптера.

Зависимость от версий и платформы

Названия настроек BIOS/UEFI, статусы устройств, пункты интерфейса и доступные операции зависят от модели сервера, поколения платформы, версии firmware, релиза ESXi либо Proxmox VE и версии утилиты управления. Проверяйте их по официальному руководству производителя сервера и документации выбранного релиза гипервизора. Базовый порядок включения VT-x, AMD-V и IOMMU в firmware разобран отдельно: как включить виртуализацию в BIOS/UEFI.

GPU passthrough: что именно получает виртуальная машина

GPU Passthrough назначает VM физический PCIe GPU. Гостевая ОС обычно видит устройство как физическое и использует драйвер производителя. Устройство, как правило, добавляют в конфигурацию полностью выключенной VM. После назначения GPU используется этой VM монопольно и недоступен одновременно хосту или другой VM.

Passthrough — не замена vGPU и не способ автоматически разделить один ускоритель между VM. Проектирование VDI и vGPU рассматривается в статье [«VDI: виртуализация рабочих столов»](/baza-znaniy/teoriya/vdi-virtualizaciya-rabochih-stolov).

Режим	Что видит Guest OS	Совместное использование GPU
GPU passthrough	Физический PCIe GPU или его зависимые PCIe-функции	Обычно нет: устройство закреплено за одной VM
vGPU	Виртуальный GPU-профиль, созданный технологией производителя	Да, если это поддерживают GPU, драйверы, лицензирование и платформа
Обычный виртуальный видеоадаптер	Эмулируемый или паравиртуальный видеоконтроллер гипервизора	Физический GPU не передаётся; возможности 3D и вычислений зависят от платформы

Почему важны IOMMU-группа и связанные функции

PCIe-устройство может состоять из нескольких функций: например, у GPU часто есть графическая и аудиофункция. Кроме того, несколько устройств могут находиться в одной IOMMU-группе. Группа определяет минимальную область DMA-изоляции, которую платформа может гарантировать. Если в ней есть устройство, нужное хосту, либо функция, которую нельзя отделить от GPU, передача только одного адреса PCI может быть небезопасной или будет отклонена гипервизором.

Не разделяйте IOMMU-группу обходными методами без оценки рисков

ACS override и похожие способы искусственно изменить группировку не являются универсальным и безопасным решением. Они могут не поддерживаться платформой, нарушать ожидаемую DMA-изоляцию и усложнять обновления. Сначала проверьте топологию PCIe, документацию сервера и поддерживаемый вариант размещения GPU в другом слоте.

GPU passthrough в VMware ESXi: подготовка DirectPath I/O

Подготовка ESXi к DirectPath I/O

Последовательность применима как рабочая схема, но доступность DirectPath I/O, перечень устройств, требования к памяти и ограничения операций с VM нужно сверять с документацией Broadcom VMware для установленного релиза ESXi/vSphere.

1
Проверьте совместимость и роль GPU
Сверьте модель сервера и GPU с VMware Compatibility Guide для целевого релиза. Уточните у производителя GPU поддержку работы в виртуальной среде и драйвера гостевой ОС. Отдельно определите, не является ли GPU загрузочным или единственным адаптером локальной консоли хоста.
2
Проверьте, что ESXi видит PCIe-устройство
В интерфейсе управления хостом или через ESXi Shell найдите GPU по PCI-адресу и сопоставьте его с физическим слотом. Проверьте также аудио- и иные зависимые функции. Ожидаемый результат — известны все адреса устройств, которые документация платформы требует назначать вместе.
3
Включите passthrough для разрешённого устройства
Отметьте устройство для DirectPath I/O штатным интерфейсом ESXi либо используйте поддерживаемую команду ESXi Shell. После изменения ESXi обычно требует перезагрузить хост, чтобы устройство было отсоединено от драйвера хоста и подготовлено к назначению VM.
4
Перезагрузите хост и проверьте статус
После перезагрузки убедитесь, что устройство имеет статус, допускающий passthrough, а хост доступен через сеть управления и out-of-band-консоль. Если статус недоступен или устройство занято хостом, не добавляйте его в VM: проверьте IOMMU в firmware, совместимость и зависимые функции.
5
Назначьте GPU выключенной VM
Полностью выключите VM, добавьте PCIe-устройство и необходимые зависимые функции в её виртуальное оборудование. Проверьте требования конкретного GPU к режиму загрузки VM — UEFI или BIOS, версии виртуального оборудования и option ROM. Не меняйте одновременно несколько несвязанных параметров VM: это затруднит откат.
6
Проверьте резервирование памяти и ограничения VM
Убедитесь, что для VM действует полное резервирование настроенной памяти, требуемое для классического DirectPath I/O; интерфейс конкретного релиза может установить его автоматически или потребовать отдельного подтверждения. До эксплуатации проверьте по документации этого релиза доступность снимков, приостановки, миграции, DRS, HA и других операций: наличие DirectPath I/O может их ограничивать, а поддержка отдельных операций меняется между версиями и устройствами.
7
Запустите VM и проверьте гостевую ОС
В гостевой ОС проверьте обнаружение GPU по идентификатору производителя и модели, затем загрузку подходящего драйвера. Успешный запуск VM без ошибки назначения ещё не означает работоспособность GPU: устройство должно быть видно ОС и корректно инициализироваться драйвером.

Показывает PCIe-устройства и их состояние passthrough в ESXi Shell. Сопоставляйте адрес и идентификаторы устройства с инвентаризацией сервера, а не только с названием модели.

esxcli hardware pci pcipassthru list

Вывод:

В типичной конфигурации вывод содержит PCI-адрес устройства и признак включения passthrough.

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

esxcli hardware pci pcipassthru set -d 0000:bb:dd.f -e true

Проблема

ESXi не даёт назначить GPU или VM не запускается с DirectPath I/O

Возможные причины

VT-d/AMD IOMMU выключен или недоступен
GPU, сервер либо релиз ESXi не подтверждены VMware Compatibility Guide
не добавлена связанная PCIe-функция
конфигурация VM, режим загрузки или виртуальное оборудование не соответствуют требованиям устройства
устройство используется хостом

Решение

Сохраните текст ошибки и текущую конфигурацию VM. Сначала сверяйте PCI-адреса, статус passthrough и требования выбранного релиза ESXi, затем откатите последнее изменение при необходимости. Не включайте случайные параметры VM и не меняйте режим загрузки без требования документации GPU или VMware.

Как избежать

Сначала тестируйте на отдельной VM и используйте out-of-band-доступ к серверу.

GPU passthrough в Proxmox VE: IOMMU, VFIO и PCIe-устройство

Подготовка Proxmox VE к PCI passthrough

Proxmox VE использует QEMU/KVM и VFIO для прямого назначения PCI(e)-устройств. Пути загрузки и детали привязки драйвера зависят от релиза Proxmox VE и ядра; перед изменениями сопоставьте порядок с официальной документацией установленного релиза.

1
Инвентаризируйте GPU и его функции
На узле определите PCI-адреса GPU и связанных устройств командой lspci -nnk. Запишите адреса, идентификаторы vendor:device и драйвер каждого устройства. Не передавайте устройство, связанное с управлением узлом, хранилищем или единственной локальной консолью.
2
Определите загрузчик и включите IOMMU
Проверьте используемый механизм загрузки, в том числе командой proxmox-boot-tool status. Для GRUB добавьте intel_iommu=on на Intel-хосте в параметры ядра в /etc/default/grub и выполните update-grub. Для systemd-boot измените строку параметров в /etc/kernel/cmdline и выполните proxmox-boot-tool refresh. На AMD IOMMU обычно обнаруживается ядром автоматически после включения в firmware; добавляйте дополнительный параметр AMD только при явном требовании документации установленного ядра и релиза Proxmox VE. Затем контролируемо перезагрузите узел.
3
Подготовьте VFIO
Убедитесь, что доступны модули vfio, vfio_iommu_type1 и vfio_pci. Если документация релиза требует их ранней загрузки, добавьте названия модулей отдельными строками в /etc/modules, выполните update-initramfs -u -k all и перезагрузите узел.
4
Проверьте включение IOMMU и группы
После перезагрузки проверьте сообщения ядра командой dmesg | grep -Ei 'DMAR|IOMMU' и состав групп в /sys/kernel/iommu_groups/. Группа GPU не должна содержать устройство, которое необходимо оставить хосту. При неподходящей группировке сначала рассмотрите другой PCIe-слот или поддерживаемую конфигурацию платформы.
5
Освободите GPU от хостового драйвера
Если GPU остаётся занят хостовым драйвером, настройте его раннюю привязку к vfio-pci способом, документированным для установленного релиза. Типовой вариант — строка options vfio-pci ids=<vendor:device>,<vendor:device> в отдельном файле /etc/modprobe.d/ с последующим update-initramfs -u -k all и перезагрузкой. При одинаковых идентификаторах у нескольких карт такое правило затронет их все, поэтому используйте его только после проверки области действия; не блокируйте драйвер целиком, если он нужен другим устройствам хоста.
6
Добавьте PCIe-устройство выключенной VM
Остановите VM и добавьте PCI(e)-устройство через интерфейс Proxmox VE или параметр hostpci в конфигурации VM. Для PCIe GPU обычно выбирают режим PCIe. Передайте также функции, которые документация устройства требует использовать вместе; дополнительные параметры, включая использование GPU как основного адаптера, включайте только при документированной необходимости.
7
Проверьте запуск и устройство в госте
Запустите VM, проверьте журнал задачи запуска и обнаружение GPU внутри гостевой ОС. Если VM стартует, но драйвер не загружается, сначала подтвердите наличие PCI-устройства и его идентификатор в госте, а затем проверяйте совместимость драйвера производителя.

Показывает PCIe-устройства, идентификаторы `vendor:device` и используемые драйверы. Сохраните вывод до изменения конфигурации.

lspci -nnk

Выводит устройства по IOMMU-группам на Linux-хосте. Проверьте, какие PCI-адреса находятся в одной группе с GPU.

find /sys/kernel/iommu_groups/ -type l | sort

Вывод:

Каждая строка содержит номер группы и путь с PCI-адресом. Если рядом с GPU находится критичное устройство хоста, не назначайте GPU одной VM без изменения поддерживаемой топологии.

Проверяет сообщения ядра о включении Intel DMAR/VT-d или AMD IOMMU после перезагрузки. Отсутствие ожидаемых сообщений — повод перепроверить параметры загрузки и firmware.

dmesg | grep -Ei 'DMAR|IOMMU'

/etc/pve/qemu-server/<VMID>.conf

# Пример строки для уже проверенного PCI-адреса GPU
hostpci0: 0000:bb:dd.0,pcie=1

# Связанная функция добавляется отдельной строкой, если это требуется
# hostpci1: 0000:bb:dd.1,pcie=1

Проблема

Proxmox VE не запускает VM с GPU или GPU остаётся у хоста

Возможные причины

не активирован IOMMU в firmware или параметрах ядра
VFIO не загружен достаточно рано либо устройство не привязано к vfio-pci
выбраны не все необходимые PCIe-функции
группировка устройств не позволяет безопасно отделить GPU
конфигурация VM или драйвер гостя не соответствует устройству

Решение

Не меняйте параметры наугад. Верните последнюю правку загрузчика, VFIO или конфигурации VM, загрузите узел через out-of-band-консоль и подтвердите состояние командами dmesg, lspci -nnk и выводом IOMMU-групп. Если проблема в топологии, оценивайте другой PCIe-слот или другую платформу, а не ACS override как первый вариант.

Как избежать

Храните копии исходных конфигураций загрузчика и VM вне изменяемого узла.

Вложенная виртуализация: отдельная настройка CPU для внутреннего гипервизора

Вложенная виртуализация не назначает VM PCIe-устройство и не требует IOMMU сама по себе. Внешний гипервизор передаёт внутреннему гипервизору возможности аппаратной виртуализации CPU. Внутри такой VM можно запускать, например, KVM или другой поддерживаемый гипервизор, но совместимость пары «внешний гипервизор — внутренний гипервизор — гостевая ОС» нужно проверять отдельно.

Nested virtualization не равна полной поддержке кластера

Передача VT-x/AMD-V не делает поддерживаемой любую комбинацию гипервизоров и не гарантирует доступность live migration, высокой доступности, снапшотов, отладки, защиты VM или функций повышения производительности. Для VM с CPU типа host и с вложенной виртуализацией особенно важна совместимость CPU между узлами. Планирование Live Migration, HA и кластерных ограничений вынесено в статьи о миграции VM, VMware HA и DRS и VM, LXC, кластере и HA в Proxmox VE.

Как включить nested virtualization в ESXi

Настройка вложенной VM в ESXi

1
Проверьте аппаратную виртуализацию на хосте
Убедитесь, что VT-x или AMD-V включены в firmware и ESXi видит поддержку аппаратной виртуализации CPU. IOMMU для этого сценария не требуется, если одновременно не настраивается passthrough.
2
Выключите внешнюю VM
Изменение передачи расширений виртуализации выполняйте на полностью выключенной VM. Зафиксируйте текущий тип гостевой ОС, версию виртуального оборудования и параметры CPU.
3
Разрешите передачу аппаратной виртуализации гостю
В настройках процессора VM включите опцию передачи hardware-assisted virtualization в Guest OS. В конфигурационном файле VM соответствующий параметр обычно имеет вид vhv.enable = "TRUE"; используйте интерфейс управления или способ, документированный для вашего релиза ESXi.
4
Запустите внутренний гипервизор и тестовую VM
Внутри внешней VM проверьте, что внутренний гипервизор обнаруживает аппаратные расширения CPU, затем создайте небольшую тестовую VM. Успешный запуск тестовой VM подтверждает nested virtualization; один только запуск внешней VM — нет.
5
Проверьте ограничения эксплуатации
До переноса такой VM на другой ESXi-хост проверьте совместимость CPU и ограничения конкретного релиза vSphere. Если функция недоступна для VM с включённым nested virtualization, планируйте остановку VM или альтернативную архитектуру.

<VM>.vmx

vhv.enable = "TRUE"

Проверка результата в ESXi

Внутренний гипервизор должен видеть доступные CPU-расширения и запускать тестовую VM. Если он сообщает, что VT-x/AMD-V недоступны, сначала проверьте firmware внешнего хоста, затем настройку VM и совместимость внутреннего гипервизора с выбранной Guest OS.

Как включить nested virtualization в Proxmox VE

Настройка вложенной VM в Proxmox VE

1
Проверьте и при необходимости включите nested KVM
На Intel-хосте проверьте /sys/module/kvm_intel/parameters/nested, на AMD-хосте — /sys/module/kvm_amd/parameters/nested. Если nested virtualization отключена, создайте отдельный файл, например /etc/modprobe.d/kvm-nested.conf, со строкой options kvm-intel nested=Y для Intel или options kvm-amd nested=1 для AMD. Выполните update-initramfs -u -k all и после остановки или переноса работающих VM контролируемо перезагрузите узел. После загрузки повторно проверьте параметр модуля.
2
Выберите CPU типа host для внешней VM
У выключенной VM установите CPU type host. Такой режим передаёт наиболее полный доступный набор флагов CPU, включая VMX на Intel или SVM на AMD, если nested KVM включён. Он также сильнее привязывает VM к характеристикам конкретного узла.
3
Проверьте флаги CPU в госте
Запустите внешнюю VM и в Linux Guest OS проверьте vmx либо svm в /proc/cpuinfo. Затем установите или запустите внутренний гипервизор и создайте тестовую VM. Если флаг есть, но внутренняя VM не стартует, проверьте требования именно внутреннего гипервизора.
4
Оцените миграцию до эксплуатации
Не предполагайте, что VM с cpu: host можно перенести на любой узел. Для миграции нужны совместимые CPU-функции и поддерживаемая конфигурация всех узлов. Проверяйте ограничения Proxmox VE/QEMU до включения VM в производственный кластер.

Проверка nested virtualization на Intel-узле Proxmox VE. Обычно разрешающее значение — `Y` или `1`, в зависимости от ядра.

cat /sys/module/kvm_intel/parameters/nested

Проверка nested virtualization на AMD-узле Proxmox VE. Команда актуальна, если загружен модуль `kvm_amd`.

cat /sys/module/kvm_amd/parameters/nested

Запускается внутри внешней Linux VM. Вывод `vmx` на Intel или `svm` на AMD подтверждает, что гостю передан флаг аппаратной виртуализации.

grep -Ewo 'vmx|svm' /proc/cpuinfo | sort -u

/etc/pve/qemu-server/<VMID>.conf

# Для nested virtualization на совместимом узле
cpu: host

Проблема

Внутренний гипервизор не видит VT-x/AMD-V или не запускает тестовую VM

Возможные причины

VT-x/AMD-V выключен в firmware физического сервера
nested virtualization отключена в KVM или не передана настройками внешней VM
выбран совместимый, но ограниченный тип CPU вместо `host`
сочетание внешнего гипервизора, внутреннего гипервизора и версии Guest OS не поддерживается
на целевом узле отсутствуют нужные CPU-функции

Решение

Проверьте цепочку по порядку: CPU и firmware физического хоста, состояние nested KVM или настройки ESXi, CPU type внешней VM, наличие vmx/svm внутри неё и требования внутреннего гипервизора. Для отката выключите внешнюю VM и верните прежний CPU type либо отключите передачу виртуализации.

Как избежать

Отдельно тестируйте nested VM до добавления её в процессы миграции, HA или автоматического перезапуска.

Безопасный откат после passthrough и nested virtualization

Если после passthrough не запускается VM, выключите её и удалите из её конфигурации только добавленные PCIe-устройства. Не удаляйте устройство из хоста и не меняйте одновременно CPU, прошивку VM и драйверы.
Если хост потерял локальный видеовывод, подключитесь через проверенное out-of-band-управление или сеть управления. Верните GPU в использование хоста: отключите DirectPath I/O в ESXi либо отмените привязку к VFIO и параметр hostpci в Proxmox VE, затем выполните требуемую перезагрузку.
Если недоступен сам хост, не пытайтесь исправить проблему только из Guest OS. Используйте консоль BMC, восстановите последнюю известную рабочую конфигурацию загрузчика или firmware и проверьте журналы хоста.
Если не работает nested virtualization, откатывайте только настройку передачи CPU-расширений: vhv.enable в ESXi или CPU type/параметр nested KVM в Proxmox VE. IOMMU и конфигурацию GPU для этого менять не нужно, если passthrough не был частью задачи.
После возврата повторно проверьте сеть управления, локальную или out-of-band-консоль, запуск обычной VM и состояние переданного устройства. Сохраняйте сообщения об ошибках и вывод диагностических команд до следующей попытки.

Термины в статье

Аппаратная виртуализация: Аппаратная виртуализация — способ запуска ВМ с поддержкой процессора и платформы, где привилегированные операции гостя обрабатываются специальными механизмами CPU, а не только программной эмуляцией.
Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Виртуальное оборудование: Виртуальное оборудование — логическая аппаратная платформа, которую гипервизор предоставляет ВМ: виртуальные процессоры, память, устройства и системную прошивку.
Высокая доступность: Высокая доступность (HA) — способность системы сохранять сервис или автоматически восстанавливать его с минимальным простоем при отказе компонентов.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Снимок состояния: Зафиксированное гипервизором состояние поддерживаемых виртуальных дисков и конфигурации ВМ на определённый момент, иногда также памяти, к которому можно выполнить откат.
Хост виртуализации: Хост виртуализации — физический сервер или вычислительная система, на которой работает гипервизор и размещаются виртуальные машины; его CPU, память, сеть и хранилище распределяются между гостями.
DRS: Функция VMware vSphere для управления размещением ВМ в кластере и балансировки ресурсов хостов с помощью рекомендаций или автоматических миграций vMotion.
ESXi Shell: ESXi Shell — локальная командная оболочка VMware ESXi для диагностики и администрирования хоста. Удалённый доступ к командной среде предоставляется отдельно включаемой службой SSH.
GPU Passthrough: Режим назначения физического GPU виртуальной машине через PCIe/IOMMU, при котором гостевая ОС обращается к устройству напрямую с минимальными накладными расходами.
GRUB: GRUB — загрузчик операционных систем, который после BIOS или UEFI выбирает пункт своего меню, передаёт ядру Linux параметры и обычно загружает initramfs.
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
Intel VT-d: Intel VT-d — технология аппаратной виртуализации ввода-вывода Intel, ограничивающая DMA устройств и позволяющая безопаснее назначать их виртуальным машинам.
Intel VT-x: Intel VT-x — расширение процессоров Intel для аппаратной виртуализации x86, вводящее режимы VMX для выполнения гостевых ОС под контролем гипервизора без полной программной эмуляции.
IOMMU: IOMMU — аппаратный блок, который преобразует адреса DMA-запросов устройств в адреса физической памяти и ограничивает их доступ; нужен для изоляции и прямого назначения PCIe-устройств ВМ.
KVM: Подсистема аппаратной виртуализации ядра Linux, предоставляющая пользовательским мониторам ВМ, обычно QEMU, интерфейс для запуска изолированных виртуальных машин.
Live Migration: Перенос работающей виртуальной машины между хостами без выключения гостевой ОС; переключение обычно вызывает краткую паузу, а сохранение соединений зависит от сети и платформы.
Nested Virtualization: Вложенная виртуализация — возможность запускать гипервизор и виртуальные машины второго уровня внутри обычной виртуальной машины.
Proxmox: Открытая платформа серверной виртуализации на базе Debian, использующая QEMU/KVM для виртуальных машин и LXC для системных Linux-контейнеров.
QEMU: QEMU — открытый эмулятор вычислительных систем и монитор виртуальных машин; в Linux он может использовать KVM для виртуализации с аппаратным ускорением.
vGPU: vGPU — технология предоставления каждой ВМ отдельного виртуального GPU-устройства, позволяющая нескольким ВМ совместно использовать физический ускоритель.
VMware: VMware — бренд Broadcom и семейство продуктов виртуализации; серверная платформа vSphere объединяет гипервизор ESXi и средства управления vCenter Server.
VMware ESXi: VMware ESXi — гипервизор типа 1, устанавливаемый непосредственно на совместимый физический сервер для запуска и управления виртуальными машинами.
vSphere: Платформа виртуализации VMware, включающая гипервизор ESXi и средства управления vCenter для корпоративной инфраструктуры

Что проверить до начала работ

Сначала обеспечьте доступ для восстановления

Зависимость от версий и платформы

GPU passthrough: что именно получает виртуальная машина

Почему важны IOMMU-группа и связанные функции

Не разделяйте IOMMU-группу обходными методами без оценки рисков

GPU passthrough в VMware ESXi: подготовка DirectPath I/O

Подготовка ESXi к DirectPath I/O

Проблема

Возможные причины

Решение

Как избежать

GPU passthrough в Proxmox VE: IOMMU, VFIO и PCIe-устройство

Подготовка Proxmox VE к PCI passthrough

Проблема

Возможные причины

Решение

Как избежать

Вложенная виртуализация: отдельная настройка CPU для внутреннего гипервизора

Nested virtualization не равна полной поддержке кластера

Как включить nested virtualization в ESXi

Настройка вложенной VM в ESXi

Проверка результата в ESXi

Как включить nested virtualization в Proxmox VE

Настройка вложенной VM в Proxmox VE

Проблема

Возможные причины

Решение

Как избежать

Безопасный откат после passthrough и nested virtualization

Термины в статье

Вопросы по теме

Чем отличаются VT-x/AMD-V от VT-d/AMD IOMMU?

Можно ли использовать один GPU одновременно на хосте и в двух VM?

Нужен ли IOMMU, чтобы включить nested virtualization?

Почему ESXi не даёт назначить GPU виртуальной машине?

Почему Proxmox VE оставляет GPU у хоста?

Как проверить, что вложенная виртуализация действительно включена?