Проброс видеокарты в виртуальную машину windows

Вступление.

В статье рассмотрена виртуализация Win10 посредством qemu—kvm совместно с libvirt и virt-manager, а так же проброс видеокарты Nvidia.

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

Несколько слов об Nvidia. Видеокарты данного вендора являются наихудшим вариантом для проброса из-за злонамеренного препятствования, которое подразумевает негласный запрет на проброс «непрофессиональных» моделей видеокарт. Проблема особенно характерна для Win10, в которой проброс без настройки приводит к неработоспособности системы.

В статье описано решение характерной для сочетания Win10 и Nvidia «Ошибки 43» (код 43) и VIDEO_TDR_FAILURE с драйвером nvlddmkm.sys, приводящей к «синему экрану смерти» (BSOD) из-за проблем с MSI (Message Signaled Interrupts). Не смотря на это, GTX 1060 возможно пробросить и она не имеет проблемы со сбросом GPU (reset bug) после выключения виртуальной машины. Проблема со сбросом выражается в том, что после завершения работы виртуальной машины реинициализация видеокарты не произойдёт и она останется в режиме выключения. Чтобы хост-компьютер смог взаимодействовать с таким «подвисшим» устройством, потребуется перезагрузка хоста, что, как правило, очень неудобно.

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

• Дистрибутив: Linux Mint 20 (Ubuntu 20.04).
• Ядро Linux 5.10.9. Вполне подойдёт и LTS.
• Процессор: Intel i7 6800K 12 потоков.
• Видеокарта для хоста: AMD RX 480 8 Гб.
• Видеокарта для проброса: Nvidia GTX 1060 6 Гб.
  • На хосте проприетарный драйвер не применяется. Допустимо использование только свободного (nouveau) в виду специфики технологии проброса.
• qemu-kvm 4.2 из стандартного репозитория (Ubuntu 20.04).

Вопросы оптимизации виртуализации рассмотрены в отдельной статье: https://noostyche.ru/blog/2021/03/30/optimizaciya-virtualizacii-win10-qemu-kvm/

Базовые требования и рекомендации.

• В настройках материнской платы (UEFI) необходимо включить поддержку виртуализации.
  • Базовая аппаратная виртуализация.
    • Intel VT.
    • AMD SVM.
  • Поддержка виртуализации ввода-вывода — IOMMU.
    • Intel. Активировать VT-d (Intel Virtualization Technology for Directed I/O).
    • AMD. Активировать AMD-Vi.
• Две дискретные видеокарты.
  • Видеокарты AMD наиболее предпочтительны для проброса в виду отсутствия искусственного препятствования со стороны вендора, что делает проброс практически беспроблемным.
  • Видеокарта, используемая для проброса, НЕ ДОЛЖНА быть в первом PCI-слоте.
  • Для пробрасываемой видеокарты не должны использоваться проприетарные драйверы, только свободные. В данном случае nouveau. Иначе на этапе захвата видеокарты драйвером vfio_pci хост или видеокарта могут зависнуть.
  • При наличии встроенной в процессор графики можно пробросить дискретную.
• Видеокарта для проброса должна иметь поддержку EFI (модели от 2012 года).
• Для вывода изображения с двух видеокарт достаточно одного монитора. Потребуется два кабеля. Первый будет от основной видеокарты, а второй — от пробрасываемой.
  • Переключение между выводом изображения с первой и второй видеокарты будет осуществляться через переключение видеорежима в настройках монитора.
• Очень желательна материнская плата среднего ценового сегмента и выше, поддерживающая работу PCI в режиме 8x/8/x4 или 16x/8x.
• Процессор минимум с восемью потоками.
• В upstream-ядрах могут быть различные улучшения виртуализации, поэтому желательно использовать свежее ядро.

Содержание.

1. Установка qemu-kvm, libvirt, virt-manager и сопутствующих пакетов.
2. Базовая настройка libvirt.
3. Загрузка модулей ядра.
   1. Модуль kvm.
   2. Модули IOMMU.
      1. Группы IOMMU и видеокарта.
   3. Модули vfio.
4. Завершение подготовки проброса видеокарты GTX 1060.
5. Создание и настройка виртуальной машины.
   1. Создание виртуальной машины с помощью Virt-manager.
   2. Подробная настройка виртуальной машины.
6. Нюансы Windows.
7. Проброс видеокарты Nvidia.
   1. Базовый проброс видеокарты.
   2. Установка драйвера Nvidia.
      1. Подготовка гостя.
      2. Включение MSI для видеокарты Nvidia.
      3. Маскировка виртуализации для решения «ошибки 43».
8. Заключительная часть.

Предварительная настройка.

Установка qemu-kvm, libvirt, virt-manager и сопутствующих пакетов.

Примечание: Набор пакетов характерен именно для Ubuntu 20.04 и деривативов.

sudo apt install qemu-kvm libvirt-daemon libvirt-daemon-system libvirt-daemon-driver-qemu gir1.2-spiceclientgtk-3.0 virt-manager ovmf

qemu-kvm — средство виртуализации qemu с гипервизором kvm.

libvirt-daemon, libvirt-daemon-system и libvirt-daemon-driver-qemu — это основные пакеты, которые подтянут прочие необходимые. В них входит несколько демонов (сервисов) libvirt и утилит для управления виртуальными машинами.

virt-manager — графическая оболочка libvirt для управления виртуальными машинами и редактирования их конфигурации.

gir1.2-spiceclientgtk-3.0 — пакет для поддержки управления виртуальной машиной по протоколу SPICE. Поддерживает шифрование, общий буфер обмена, проброс USB и многое другое. Документация: https://www.linux-kvm.org/page/SPICE

ovmf — Open Virtual Machine Firmware — прошивка с поддержкой эмуляции EFI. Альтернатива seabios. Оптимальный выбор для ОС с поддержкой EFI (все актуальные Linux-дистрибутивы, Win8.1, Win10).

Место хранения прошивок /usr/share/qemu/

qemu-utils — набор утилит. Необязательный пакет для установки.

• qemu-img — утилита для создания и преобразования образов накопителей. К примеру, позволяет преобразовать образ в формате vdi (Virtualbox) в img.
• qemu-io — утилита для работы с QEMU I/O.
• qemu-nbd — экспорт образа накопителя QEMU с помощью протокола NBD.

После установки пакетов требуется перезагрузка.

Базовая настройка libvirt.

После установки пакетов и перезагрузки требуется осуществить подготовку libvirt к использованию.

Пользователь и группа libvirt.

Убедиться, что пользователь был добавлен в группу libvirt:

id $USER | grep libvirt

Это позволит пользователю запускать виртуальные машины без привилегий суперпользователя и получить доступ к расширенным сетевым опциям.

Если пользователь не в группе — добавить вручную. Команда на добавление активного пользователя в дополнительную группу libvirt без удаления из предыдущих групп:

sudo usermod -aG libvirt $USER

$USER — активный пользователь.

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

Запуск демона libvirtd.

Запуск libvirtd вручную.

systemctl start libvirtd

Можно добавить сервис в автозагрузку.

systemctl enable libvirtd

Вместе с libvirtd будет запущен virtlogd для ведения журнала событий.

Место хранения журнала событий виртуальных машин: /var/log/libvirt/qemu/

Загрузка модулей ядра.

В данном примере будет рассмотрен вариант передачи параметров для ядра посредством Grub. Для этого потребуется внести изменения /etc/default/grub.

Модули для загрузки и параметры для ядра должны быть перечислены в строке GRUB_CMDLINE_LINUX_DEFAULT=

Итоговый набор параметров для процессоров Intel и видеокарты GTX 1060 будет выглядеть так:

GRUB_CMDLINE_LINUX_DEFAULT="kvm_intel=on intel_iommu=on iommu=pt vfio-pci.ids=10de:1c03,10de:10f1 vfio_iommu_type1.allow_unsafe_interrupts=1 vfio_virqfd=1"

Далее подробно и по порядку.

Модуль kvm.

Основное предназначение — ускорение виртуализации.

Проверить поддержку kvm-ускорения можно утилитой kvm-ok:

sudo kvm-ok

Вывод, указывающий, что ускорение будет использоваться:

INFO: /dev/kvm exists
KVM acceleration can be used

Если модуль kvm не активирован, будет показано предупреждение:

INFO: /dev/kvm does not exist
HINT: sudo modprobe kvm_intel

Если ускорение не поддерживается:

INFO: Your CPU does not support KVM extensions
KVM acceleration can NOT be used

Проверить загружен ли модуль:

lsmod | grep -i kvm

Если вывод пустой, необходимо загрузить модуль.

Модуль kvm_intel зависит от модуля intel_iommu, загрузка которого описана ниже. То есть, чтобы загрузить модуль kvm_intel достаточно загрузить intel_iommu, но можно загрузить и вручную.

Утилита modprobe позволяет загрузить модуль, но только для текущей сессии:

sudo modprobe kvm_intel

Модули IOMMU.

Input Output Memory Management Unit https://ru.wikipedia.org/wiki/IOMMU

Настройка IOMMU является важным этапом для проброса видеокарты.

В настройках материнской платы (UEFI) нужно сделать следующее:

• Для Intel активировать VT-d (Intel Virtualization Technology for Directed I/O).
• Для AMD активировать AMD-Vi.

Загрузка с помощью Grub. В файле /etc/default/grub в строку GRUB_CMDLINE_LINUX_DEFAULT добавить intel_iommu=on iommu=pt.

Итоговый вид:

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on iommu=pt vfio-pci.ids=10de:1c03,10de:10f1 vfio_iommu_type1.allow_unsafe_interrupts=1 vfio_virqfd=1"

intel_iommu=on — включить поддержку транслятора виртуальных адресов в физические. Материнская плата должна иметь блок управления памятью ввода/вывода (IOMMU). По идее, этот блок есть во всех современных не супер бюджетных материнских платах.

iommu=pt — включает режим проброса. Это снижает нагрузку IOMMU для устройств принадлежащих хосту.

После необходимо обновить конфигурацию Grub, чтобы изменения вступили в силу после перезагруки:

sudo update-grub

Перезагрузиться.

Удостовериться, что IOMMU используется:

dmesg | grep -iE "(DMAR|IOMMU)"

i — игнорировать различие регистра.

E — расширенное регулярное выражение.

Если вывод пустой, то IOMMU выключено или отсутствует аппаратная поддержка в материнской плате.

Группы IOMMU и видеокарта.

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

Проверка наличия групп устройств IOMMU:

ls /sys/kernel/iommu_groups

Должен быть подобный вывод (у всех будет разный):

0 1 10 11 12 13 2 3 4 5 6 7 8 9

Если пусто, значит IOMMU не включено.

Видеокарта разделена на два устройства: видео и аудио (звук через HDMI). Нужно проверить в какую IOMMU-группу входит видео и аудио видеокарты. Сначала потребуется узнать их ID. Для Nvidia:

lspci -nn | grep -i nvidia

Для GTX 1060 вывод будет такой:

Искомые ID имеют следующий вид:

• Видео 02:00.0
• Аудио 02:00.1

Теперь, зная ID устройств видеокарты, можно провести проверку принадлежности устройств к конкретной группе IOMMU:

find /sys/kernel/iommu_groups/ -type l | grep -iE "(02:00.0|02:00.1)"

Вывод:

Это означает, что устройства видеокарты находятся в группе 27, то есть всё в порядке.

Модули vfio.

Брошюра о vfio: http://www.linux-kvm.org/images/b/b4/2012-forum-VFIO.pdf

Рассмотрим следующий необходимый набор модулей:

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on iommu=pt vfio-pci.ids=10de:1c03,10de:10f1 vfio_iommu_type1.allow_unsafe_interrupts=1 vfio_virqfd=1"

vfio-pci.ids — обеспечивает мягкий захват видеокарты драйвером vfio на этапе загрузки хост-системы. Это ключевой модуль, обеспечивающий успех проброса.

vfio_iommu_type1.allow_unsafe_interrupts=1 — уменьшает задержки (latency) прерываний. Позволит включить в Win-госте MSISupported для решения проблемы VIDEO_TDR_FAILURE nvlddmkm.sys.

vfio_virqfd=1 — драйвер для поддержки irqfd — механизма передачи прерываний между хостом и гостем.

Завершение подготовки проброса видеокарты GTX 1060.

Вернёмся к модулю vfio-pci.ids.

Видеокарта состоит из двух устройств: видео и аудио. В целях проброса модулю vfio-pci.ids необходимо передать vendor id и device id устройств видеокарты.

Вывести ID устройств видеокарты:

lspci -nn | grep -i nvidia

Вывод для GTX 1060:

02:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] [10de:1c03] (rev a1)
02:00.1 Audio device [0403]: NVIDIA Corporation GP106 High Definition Audio Controller [10de:10f1] (rev a1)

Искомые vendor id и device id имеют такой вид:

• Видео [10de:1c03]
• Аудио [10de:10f1]

Итоговый результат для GTX 1060 выглядит так:

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on iommu=pt vfio-pci.ids=10de:1c03,10de:10f1 vfio_iommu_type1.allow_unsafe_interrupts=1 vfio_virqfd=1"

После перезагрузки vfio захватит видеокарту, что сделает её доступной для проброса.

Проверить успешность захвата по ID видеоустройства:

lspci -nnk -d 10de:1c03

Вывод:

В строке Kernel driver in use должно быть vfio-pci. Это означает, что видеокарта была успешно захвачена драйвером vfio_pci.

На этом непосредственная настройка хоста окончена.

Создание и настройка виртуальной машины.

Процесс будет осуществлён с помощью Virt-manager.

Если при запуске Virt-manager выводится ошибка «Не удалось подключиться к libvirtd», то стоит удостовериться в следующем:

• Установлены пакеты libvirt-daemon и libvirt-daemon-system.
• Пользователь находится в группе libvirt.

id $USER | grep libvirt

• libvirtd на самом деле запущен.

systemctl start libvirtd

Дополнительные варианты решения: https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#virt-manager_has_permission_issues

Если есть какие-то другие проблемы, то их можно отследить через вывод в системном журнале:

journalctl -xb | grep -i libvirt

Создание виртуальной машины с помощью Virt-manager.

Создание подключения.

Необходимо создать подключение к гипервизору QEMU/KVM.

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

В данном примере для установки Win10 в качестве гостевой ОС используется базовая конфигурация. Далее будет проделана дополнительная настройка виртуальной машины, чтобы осуществить проброс видеокарты, успешно установить драйвер и обойти нелепые искусственные ограничения Nvidia («ошибка 43» и BSOD из-за отключенного MSI).

Официальный установочный образ Win10 в формате ISO:

https://www.microsoft.com/ru-ru/software-download/windows10ISO

Образ будет использоваться для установки с использованием эмуляции CD-ROM.

Шаг 0.

Файл / Создать виртуальную машину

Шаг 1.

В методе установки выбрать «Локальный ISO или CDROM»:

Шаг 2.

Выбрать ранее загруженный установочный образ:

В этом же шаге выбрать тип устанавливаемой ОС. Это важно для подтягивания мета-информации, в зависимости от которой предоставляются те или иные настройки в Virt-manager и libvirt. Для отображения полного списка отметить «Include end of life operating systems»:

Шаг 3.

Указать количество ОЗУ и потоков для виртуальной машины.

В данном примере для гостевой ОС будет выделено 16384 Мб из 32768 Мб ОЗУ и 8 из 12 потоков процессора.

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

Шаг 4.

Необходимо указать образ виртуального накопителя, в который будет установлена гостевая (виртуализируемая) ОС.

В libvirt используются специальные хранилища данных, что делает задачу несколько нетривиальной. Ознакомиться можно здесь: https://libvirt.org/storage.html

В примере создаётся хранилище данных с названием pool и типом «Каталог в файловой системе»; в строке Target Path указывается путь до каталога в файловой системе хоста, в котором по итогу расположится хранилище данных.

При выборе места для хранилища стоит учитывать достаточное количество свободного места на физическом накопителе. Для Win10 желательно от 60 Гб.

Хранилище создано. Теперь необходимо создать сам образ виртуального накопителя, в который будет установлена Win10.

Формат: raw. Оптимален для Windows-гостей.

Объём: 60 Гб

Подтвердить создание.

Созданный виртуальный накопитель появится в списке томов. Останется выбрать его.

На этом четвёртый шаг заканчивается.

Шаг 5.

Отметить пункт «Проверить конфигурацию перед установкой»:

Это позволит перейти к непосредственной настройке виртуальной машины.

Подробная настройка виртуальной машины.

Обзор.

Выбрать набор микросхем q35. Он лучше поддерживает проброс.

Выбрать прошивку (firmware) ovmf — OVMF_CODE.fd.

Применить изменения.

Информация об ОС.

Убедиться, что выбрано Windows 10, так как это подтягивает мета-информацию, которая влияет на доступные настройки Virt-manager и libvirt.

Процессоры.

В этой вкладке указывается число потоков, конфигурация (модель процессора) и топология процессора. В данном примере копируется конфигурация хоста с разделением на 8 потоков: 4 ядра умножаются на 2 потока, что имитирует гиперпоточность.

Память.

Для гостя выделяется 16384 Мб ОЗУ. Всего в системе 32 Гб.

Параметры загрузки.

Переставить SATA CDROM 1, к которому примонтирован установочный образ, на первое место, тем самым повысив приоритет загрузки:

Иначе процесс установки не сможет начаться. Можно будет лишь наблюдать интерфейс UEFI Interactive Shell, в котором придётся указать путь до загрузочной области вручную:

SATA Диск 1.

Ранее созданный виртуальный накопитель подключается через эмуляцию шины SATA:

В параметрах производительности переключить «Режим кэширования» на «none», а «Режим ввода-вывода» на «native». Это улучшит отзывчивость и позволит избежать потери данных при принудительном выключении виртуальной машины.

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

SATA CDROM 1.

Эмуляция CD-ROM устройства, подключенного по шине SATA. В него примонтирован установочный образ.

После установки гостевой ОС устройство SATA CDROM 1 можно удалить.

NIC (Настройки сети).

Если используется обычная конфигурация сети, то можно оставить как есть.

Планшет.

Подобные устройства правильнее пробрасывать в виртуальную машину. Поэтому эмулируемое устройство лучше удалить.

Дисплей VNC.

Заменить VNC на «Сервер SPICE» и убрать прослушивание (Listen type), так как виртуализация будет локальной:

Этот протокол более предпочтителен, когда требуется передача звука от гостя к хосту. Так же у него нет проблемы с «залипанием» курсора по краям экрана.

Консоль.

Для Windows-гостей это не требуется, поэтому лучше удалить.

Видео QXL.

Это виртуальный графический адаптер, поддерживающий 2D ускорение. Будет выводить графику, пока не задействована проброшенная физическая видеокарта.

Controller USB 0.

Оставить по умолчанию.

Теперь всё готово для установки ОС, останется нажать кнопку «Начать установку».

После подтверждения будет запущена виртуальная машина с процессом установки:

Курсор из окна виртуальной машины освобождается комбинацией Ctrl + Alt.

С установкой Win10 предлагаю разобраться самостоятельно. Основная сложность в том, что каждое крупное обновление появляются всё новые и новые преграды для отказа от навязываемой учётной записи MS и прочего «ненужно». На момент 2021 года только для отказа от некоторой(!) части телеметрии предлагается снять более десятка галочек, которые, как в головоломке, надёжно спрятаны в графическом интерфейсе и разнесены на несколько окон. Стоит отметить, что без применения спецсредств отключить основную массу телеметрии невозможно.

После установки и завершения работы виртуальной машины можно удалить SATA CDROM 1:

Нюансы Windows.

• Интерфейс схож с KDE Plasma, но намного менее привлекательный и довольно неудобный, особенно меню запуска («Пуск») и файловый менеджер с его «десятиэтажной» верхней панелью (ужас-ужас). Всё это «приправляет» графический разнобой: мутные шрифты в одном месте и чёткие в другом; в файловом менеджере своё оформление окон, в панели управления другое, в настройках вообще третье. Вся эта «биполярная» картина создаёт удручающее впечатление, но пережить можно.
• «Из коробки» вас встретит ужасающее количество мусорных программ: от полностью никчёмных, навроде Paint 3D, OneDrive, ознакомительной версии MS Office и так далее, до рекламы в меню запуска («Пуск»). Вся эта «красота», если верить тестам, отбирает до 7% производительности в 3D(!) программах, создаёт невменяемое количество прерываний (interrupts) и очень любит устраивать зашкаливающую пилообразную нагрузку как для процессора, так и для накопителя. Поэтому первым делом вам предстоит избавиться от всего лишнего. Работа непростая, но необходимая.
• НИ В КОЕМ СЛУЧАЕ недопускайте обновления драйверов на видеокарту через менеджер обновлений Windows. Это может привести к полной неработоспособности Win10.
• Недопустимо, чтобы хост уходил в гибернацию и сон с запущенной виртуальной машиной. Это может привести к полному зависанию хоста или проброшенной видеокарты.
• На госте с Windows очень нежелательно применять гибернацию и сон, так как это может привести к зависанию проброшенной видеокарты.
• Образ виртуального накопителя в формате raw можно примонтировать, как обычный накопитель, что позволит производить чтение и запись хостом. При этом есть ряд важных ограничений, в особенности для файловой системы NTFS:
  • Без крайней необходимости не осуществляйте запись от хоста на виртуальный накопитель. Одновременная запись хоста и гостя может привести к сбою файловой системы на виртуальном накопителе. Запись от хоста должна осуществляться только при выключенном(!) госте.
  • Если работа гостя была завершена переходом в сон, гибернацию, сбоем или принудительным выключением, то запись от хоста даже при выключенном госте может повредить файловую систему.
    • Восстановление файловой системы NTFS возможно Win-утилитой chkdsk, при этом повреждённые записи будут удалены с потерей затронутых файлов.

Проброс видеокарты Nvidia.

Базовый проброс видеокарты.

Осуществялется через Virt-manager.

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

Открыть настройки виртуальной машины и найти кнопку «Добавить оборудование». В списке выбрать видеоустройство видеокарты и аудиоустройство.

Для GTX 1060 результат выглядит так:

Установка драйвера Nvidia.

Подготовка гостя.

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

Вручную загрузить драйвера для видеокарты с официального сайта: https://www.nvidia.ru/Download/

Для установки потребуется перейти в безопасный режим, иначе установка будет прервана BSOD («синим экраном смерти») и не завершится корректно. После такого сбоя потребуется удалять то, что успело установиться, специальной утилитой (DDU или подобной).

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

• Нажать комбинацию клавиш META + R. В появившейся строке ввести msconfig и подтвердить.

• В открывшемся окне перейти на вкладку «Загрузка» и отметить «Безопасный режим»:

Перезагрузиться.

Визуально безопасный режим будет выглядеть подобным образом:

Теперь можно установить драйвер, не опасаясь BSOD.

Для этого запустить ранее загруженный установочный файл.

В установочнике отметить «Выборочную установку», чтобы установить только драйвер без дополнительного софта:

Ни в коем случае не устанавливать предлагаемый GeForce Experience. Это очень проблемный софт, который становится ещё проблемнее на виртуальной машине.

Перезагрузиться, всё ещё оставаясь в безопасном режиме.

Теперь предстоит настроить MSI (Message Signaled Interrupts). Без этого в обычном режиме запуска будет происходить зацикленный BSOD с ошибкой VIDEO_TDR_FAILURE в драйвере nvlddmkm.sys.

Включение MSI для видеокарты Nvidia.

Оптимально включить вручную через реестр, создав специальный параметр.

Сначала необходимо узнать ID видеокарты, по которому её можно найти в реестре.

META + R и в появившейся строке ввести devmgmt.msc, а затем подтвердить.

Это откроет окно «Диспетчера устройств»:

Развернуть свиток «Видеоадаптеры», нажать на видеокарте ПКМ и выбрать «Свойства».

В «Свойствах» перейти во вкладку «Сведения». В списке найти «ИД оборудования». Первым в списке будет искомый ID видеокарты. Для GTX 1060: VEN_10DE&DEV_1C03&SUBSYS_1C0310DE&REV_A1

Теперь можно редактировать реестр. Это осуществляется стандартной утилитой regedit.

META + R и в появившейся строке ввести regedit. Откроется окно редактора реестра:

Необходимо проследовать в самые дебри:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnumPCI

И вот здесь должен быть раздел с тем самым ID видеокарты. В данном примере это VEN_10DE&DEV_1C03&SUBSYS_1C0310DE&REV_A1

Развернуть раздел с ID видеокарты, нажать ПКМ на разделе Device Parameters и создать раздел Interrupt Management:

Нажать ПКМ на разделе Interrupt Management и создать раздел с именем MessageSignaledInterruptProperties:

Нажать ПКМ на созданном разделе и создать параметр DWORD (32 бита) с именем MSISupported:

Сделать двойной клик по параметру MSISupported и в появившемся окне присвоить значение равное 1 в шестнадцатеричной системе счисления:

Готово. Теперь можно закрыть редактор реестра.

Примечание: MSI может сбрасываться после обновления Win и драйвера для видеокарты. Поэтому придётся проделывать процедуру снова, но будет достаточно добавить параметр MSISupported, остальное должно остаться.

В msconfig включить обычный запуск:

Перезагрузиться.

Казалось бы, проделан такой большой путь и теперь уж точно всё должно работать, но не тут-то было. Nvidia так просто не сдаётся. Видеокарта всё ещё не будет работать из-за «ошибки 43»: «Система Windows остановила это устройство, так как оно сообщило что Nvidia в край обнаглела о возникновении неполадок».

Эта проблема решается маскировкой факта виртуализации для гостя.

Маскировка виртуализации для решения «ошибки 43».

Маскировка осуществляется в настройках виртуальной машины. Необходимо, чтобы гость был выключен.

Конфигурация виртуальной машины хранится в специальном файле в формате xml. Их можно редактировать с помощью утилиты virsh, но в данной статье ограничимся Virt-manager.

Редактирование конфига можно осуществить непосредственно через Virt-manager во вкладке XML (Edit libvrit XML). Пример настроенной конфигурации:

Маскировка разнесена на три блока:

• domain / features / hyperv
• domain / features / kvm
• domain / cpu

hyperv.

В этот блок нужно добавить следующую строку:

<vendor_id state="on" value="FckYouNVIDIA/>

Целиком будет выглядеть так:

<hyperv>
  <relaxed state="on"/>
  <vapic state="on"/>
  <spinlocks state="on" retries="8191"/>
  <vendor_id state="on" value="FckYouNVIDIA"/>
</hyperv>

Строка vendor_id доступна для чтения из гостевой ОС. Драйвер Nvidia проверяет её наличие. Если она отсутствует, то это является одиним из поводов показать «ошибку 43».

Cтроке value может быть присвоен любой набор из 12 символов. В «классическом» варианте можно указать следующее: FckYouNVIDIA

kvm.

По умолчанию блок kvm отсутствует. Его необходимо самостоятельно добавить в блок features.

<kvm>
  <hidden state="on"/>
</kvm>

Строка отвечает за опцию маскировки использования гипервизора kvm от обнаружения гостем. Драйвер Nvidia проверяет этот момент и при обнаружении признаков использования kvm покажет «ошибку 43».

cpu и host-passthrough.

Основной задачей является пробросить информацию о процессоре хоста, предоставить гостю возможность напрямую использовать процессорный кэш и отключить оптимизации гипервизора, которые явно указывают на то, что гостевая ОС запущена на виртуальной машине. Этот факт будет легко обнаружен драйвером Nvidia, что вновь приведёт к «ошибке 43».

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

<cpu mode="host-model" check="partial">
  <topology sockets="1" cores="4" threads="2"/>
</cpu>

Гостевой ОС будет предоставлено только название процессора без проброса детаельной информации и кэша. Это необходимо исправить.

Конечный результат будет выглядеть так:

<cpu mode="host-passthrough" check="none">
  <topology sockets="1" cores="4" threads="2"/>
  <cache mode="passthrough"/>
  <feature policy="require" name="invtsc"/>
  <feature policy="disable" name="hypervisor"/>
</cpu>

Режим проброса указывается следующей строкой:

<cpu mode="host-passthrough" check="none">

Далее указывается топология ядер процессора. В данном случае это 8 потоков (4 ядра умножаются на 2 потока, что имитирует гиперпоточность):

<topology sockets="1" cores="4" threads="2"/>

Проброс процессорного кэша:

<cache mode="passthrough"/>

Это значительно улучшает производительность гостевой ОС.

Опция invtsc улучшает обработку прерываний для Win-гостя, что позитивно сказывается на производительности:

<feature policy="require" name="invtsc"/>

Она не критична для маскировки, но очень желательна для улучшения работоспособности.

Отключение оптимизаций гипервизора:

<feature policy="disable" name="hypervisor"/>

Гостевая ОС не будет видеть, что запущена на виртуальной машине. Драйвер Nvidia тоже не сможет определить факт виртуализации, что наконец избавит от «ошибки 43».

Применить изменения.

Заключительная часть.

Наконец всё готово и видеокарта сможет свободно работать в гостевой ОС!

Ключевым признаком работы проброшенной видеокарты будет «зависание» картинки в окне просмотра Virt-manager. Если используется один монитор, то потребуется переключить видеорежим, чтобы увидеть графику гостевой ОС.

Рабочий стол будет отображаться в полноэкранном режиме:

Останется испытать производительность.

Рекомендую следующие программы для тестирования производительности:

• LatencyMon — предназначена для измерения задержек прерываний. Чем выше задержки, тем сильнее проявляются «заикания».
• Cinebench — тестирование производительности процессора.
• Unigine Superposition Benchmark — общее тестирование производительности.

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

Варианты оптимизации рассмотрены в отдельной статье: https://noostyche.ru/blog/2021/03/30/optimizaciya-virtualizacii-win10-qemu-kvm/

Проблема с отсутствием звука в виртуальной машине.

Как правило, при использовании протокола SPICE со звуком проблем нет, но бывают исключения.

Звук может отсутствовать из-за блокировки apparmor. Проверка наличия предупреждений о блокировке:

cat /var/log/syslog | grep -i 'apparmor="DENIED"'

Если блокировка отсутствует, то вывод будет пустой.

При наличии предупреждений, самым простым способом является отключение защиты через конфигурационный файл /etc/libvirt/qemu.conf. Защита будет отключена только для виртуальных машин, запускаемых с использованием libvirt.

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

security_driver = [ "selinux", "apparmor" ]

Для отключения необходимо добавить строку со значением «none»:

security_driver = "none"

Для применения изменений перезапустить libvirtd:

sudo service libvirtd restart

Как из домашнего ПК средствами виртуализации сохранить игровую систему

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

Введение

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

Достигается как при помощи приложений (например 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 по этому гайду через текстовую консоль.

Есть маленький нюанс, который возможно обходится программно, но я решил что поменять предыдущую материнскую плату будет проще, т.к. плата от 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

## lspci -n -s 01:00
01:00.0 0300: 10de:1b81 (rev a2)
01:00.1 0403: 10de:10f0 (rev a1)

Теперь правим файл под нашу видеокарту (в Вашем случае 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/и т.п. можно уточнить в веб интерфейсе.

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

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 или что-то еще. Здесь описаны и другие настройки, которые могут помочь. В идеале нужно искать в сети удачные сетапы и ориентироваться на них, каким для меня явился этот, кроме того есть еще список железа, позволяющий достичь того же что и я, но он не полный.

UPDATE1:
Несколько замечаний по переферии:
1. Как прокинуть в ВМ клавиатуру с порта PS/2:
сперва вводим комманду в консоли
## dmesg | grep input
Ищем в тексте запись навроде
…
input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
…
Запоминаем цифру 2 в конце, она может быть и другой. Потом в файл настроек ВМ в строку добавляем:
args: -object ‘input-linux,id=kbd,evdev=/dev/input/event2,grab_all=on,repeat=on’
вставляя 2 в конец evdev=/dev/input/event2

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

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

3. Жесткие диски можно пробрасывать как через проброс контроллера как PCIe устройство по методу указанному в статье (не рекомендую пробрасывать контроллер интегрированный в материнскую плату, только подключенные к PCIe), либо напрямую:
заходим в
## cd /dev/disk/by-id
через dir смотрим листинг…
копируем строки вида ata-WDC_WD40EFRX-68WT0N6_WD-WCC4E1АС9SХ9, в которой прописан интерфейс подключения, марка и номер серии жесткого диска. Затем открываем Файл конфигурации ВМ и пишем:
sata1: volume=/dev/disk/by-id/ata-WDC_WD40EFRX-68WT0N6_WD-WCC4E1АС9SХ9
и все работает, при этом учитывайте, что sata0-sata5, т.е. для одной ВМ число подключаемых таким образом дисков, включая виртуальных, не может превышать 6шт.

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

www.youtube.com/watch?v=fgx3NMk6F54
Однако там проброс ВК организован с использованием rom файла, что отличается от моего варианта.

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

Источник

Проброс видеокарты в виртуальную машину

1. Вступление

Две разные системы (win + linux) на одной аппаратной базе — реальность. В этом нет ничего нового или инновационного (на данный момент времени), но если требуется максимальная производительность гостевой системы, то не обойтись без проброса реальных устройств в виртуальную машину. Проброс сетевых карт, usb-контроллеров (etc) экстраординарных особенностей не несёт, а вот попытка «шаринга» ресурсов видеокарты и процессора вполне может принести некоторое количество проблем.

Итак, а для чего, собственного говоря, городить системы с полнофункциональным использованием ресурсов GPU и CPU? Самый простой и очевидный ответ — игры (широко известный факт — если не большинство, то очень многие, написаны под ОС Windows). Другой вариант — полноценное рабочее место с возможностью запуска требовательных приложений (например, CAD-софта), быстрым бэкапом (скопировать файл ВМ куда проще, чем создавать полную копию HDD/SSD) и опцией полного контроля сетевого трафика гостевой системы.

2. Аппаратная часть

Процессор: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz

Материнская плата: ASRock Z390 Phantom Gaming 4S

Видеокарта 0 (для проброса в ВМ): Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]

Видеокарта 1 (для хост-системы): Park [Mobility Radeon HD 5430]

USB-контроллер (для проброса в ВМ и последующего подключения периферийных устройств, например, клавиатуры): VIA Technologies, Inc. VL805 USB 3.0 Host Controller

3. Настройки ОС

В качестве хост-системы выбрана ОС AlmaLinux 8 (вариант установки«Server with GUI»). Долгое время пользовался CentOS 7/8, поэтому, думаю, выбор тут очевиден.

Первое, что необходимо сделать, — это ограничить использование видеокарты, предназначенной для использования в ВМ, хост-системой. Для этого применяем ряд команд и настроек:
1) с помощью команды « lspci -nn | grep RX » получаем уникальные идентификаторы видеокарты. Т. к. видеокарта RX-серии, то, соответственно, ищем в выводе lspci (утилита устанавливается посредством команды « dnf install pciutils ») по этим двум символам. Вывод получим примерно такой (выделенные подстроки — это и есть искомые идентификаторы устройств) —

«02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] [1002:699f] (rev c7)

02:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] [1002:aae0] », где 1002:699f — идентификатор VGA-контроллера, а 1002:aae0 — встроенной аудиокарты. Также запоминаем идентификаторы «02:00.0» и «02:00.1»;

2) добавив к команде « lspci -nn » ключ « k » (« lspci -nnk ») находим в выводе устройство «1002:699f» и запоминаем значение «Kernel driver in use» . В моём случае — это « amdgpu »;

3) в файле « /etc/default/grub » находим строку, начинающуюся с « GRUB_CMDLINE_LINUX », и добавляем после « quiet » значения «intel_iommu=on iommu=on rd.driver.pre=pci-stub pci-stub.ids=1002:699f,1002:aae0», где « intel_iommu / iommu » – параметры, отвечающие за поддержку технологии IOMMU (технология взаимодействия виртуальных машин с реальным оборудованием), «rd.driver.pre=pci-stub» — указание на принудительную первоочередную загрузку фиктивного драйвера pci-sub, «pci-stub.ids» — перечисление устройств, для которых при загрузке ядра необходимо использовать фиктивный драйвер (т.е. происходит изоляция устройств для дальнейшего использования в виртуальных машинах). Если на хост-машине используется CPU от AMD, то «intel_iommu» меняем на «amd_iommu»;

4) в файл « /etc/modprobe.d/local.conf » добавляем строки « blacklist amdgpu » и « options pci-stub ids=1002:699f,1002:aae0 », где « blacklist amdgpu » — явное указание на запрет использования драйвера AMD для графических устройств, а « options pci-stub ids=1002:67ff,1002:aae0 » — явное указание на использование фиктивного драйвера для соответствующих идентификаторов устройств;

5) выполняем команду « grub2-mkconfig -o /boot/efi/EFI/almalinux/grub.cfg » (т.е. пересоздаём конфигурационный файл загрузчика GRUB). Если речь не про EFI-загрузку, то команда выглядит так — « grub2-mkconfig -o /boot/grub2/grub.cfg »;

6) выполняем команду « dracut —regenerate-all —force » для пересоздания образа initramfs (initial RAM disk image, загружаемый в оперативную память файл с образом файловой системы), используемого при загрузке Linux в качестве первоначальной корневой файловой системы;

7) перезагружаем хост виртуализации.

Смысл этих настроек в том, чтобы ограничить использование определённых устройств при загрузке. Например, до прописания параметров в выводе команды «lspci -v» для VGA-контроллера будет присутствовать подстрока « Kernel driver in use: amdgpu », а после перезагрузки – « Kernel driver in use: pci-stub ». При старте же ВМ с Windows (и после проброса устройств) – “ Kernel driver in use: vfio-pci ” (в чём можно убедиться после запуска созданной ВМ). Важный момент — используемая для хост-системы видеокарта должна использовать драйвера, отличные от используемых для пробрасываемой видеокарты, например, в моём случае используется «Radeon HD 5430», драйвер для которой — это «radeon» (в выводе « lspci -v » – « Kernel driver in use: radeon »).

4. Установка софта для виртуализации

1) « dnf install epel-release ».

2) « dnf install qemu-kvm qemu-img libvirt virt-install libvirt-client virt-viewer virt-manager seabios numactl perf cockpit cockpit-machines xauth virt-top libguestfs-tools ».

3) « dnf install @virt ».

4) Optional. « dnf install perl » (Perl – one love).

5. Настройки ВМ QEMU-KVM via virt-manager

Предварительно скачиваем iso-образ Windows 10 и драйвера Virtio от RedHat (тоже в виде iso-образа).

При первоначальной установке всегда ставим галочку « Customize configuration before install ».

1) Указываем iso-образ устанавливаемой операционной системы (например, Windows 10). Также добавляем дополнительное устройство вида «CD-ROM» и монтируем в доп. устройство iso-образ с драйверами Virtio.

2) Для виртуального HDD (куда планируется установка ОС) выставляем: « Bus type = Virtio ». Тип виртуального диска — qcow2 или raw.

3) Для более эффективной работы размещаем основной виртуальный диск для ВМ на SSD.

4) Модель сетевой карты — virtio.

5) Overview: chipset = “Q35”, firmware = “UEFI x86_64: /usr/share/OVMF/OVMF_CODE.secboot.fd”.

6) OS Information: Operation System = “Microsoft Windows 10”.

7) CPU (соответствующие блоки в XML должны выглядеть именно так, если речь про аналогичную аппаратную конфигурацию):

Источник

How to Deploy Graphics Devices Using RemoteFX vGPU

Hardware virtualization allows you to share hardware resources between virtual machines to achieve flexible and rational usage of resources. If one VM is idle, another VM running heavy applications can consume more CPU and memory resources. Sometimes you may need to run applications that require hardware video acceleration and a graphics card. While installing a video card on a physical computer is not a problem, it’s not as straightforward on a virtual machine. Virtual machines use only basic video functionality to display data by default. However, you can configure a virtual machine to use a video card and 3D acceleration. Hyper-V RemoteFX is a feature that helps you with this task. This blog post covers Hyper-V RemoteFX and explains how to configure RemoteFX on Windows machines.

What Is RemoteFX

RemoteFX is a feature that allows Hyper-V virtual machines to share a physical GPU (graphics processing unit). The resources of a video card are shared among multiple VMs. This is the optimal scenario for high-burst workloads when the dedicated resources of a video card are not required at all times. Hyper-V RemoteFX can be used to deploy a VDI (virtual desktop infrastructure). A RemoteFX GPU is a virtual device attached to a virtual machine that shares the resources of a physical video card installed on a Hyper-V host (shares the GPU and video memory).

RemoteFX was introduced in Windows 7 and has been available in Windows 8, Windows 10, Windows Server 2008 R2 SP1, Windows Server 2012, and Windows Server 2016. This feature is not present in Hyper-V Manager in the latest version of Windows Server 2019 – you cannot enable Hyper-V RemoteFX in the graphical user interface (GUI). Using RemoteFX decreases CPU (central processing unit) load and increases scalability in a virtual environment. You don’t need to attach a dedicated GPU for each VM when using Hyper-V RemoteFX because virtual machines can dynamically share the GPU for the workload.

Video rendering, processing heavy images, working with CAD applications, and 3D modeling are some of the cases when you may need 3D acceleration and a RemoteFX GPU in a VM. A modern GPU is better adapted for parallel processing than the CPU, handles more threats simultaneously, and has more processing cores. The number of monitors and used resolutions depends on the video memory and the GPU performance of a video card. Use Remote Desktop, not VMConnect (Virtual Machine Connection), to connect to VMs using RemoteFX.

The advantage of RemoteFX is that it can be used on desktop and server Windows versions. While buying a supported video card that is compatible with server hardware may not be easy, most desktop computers that usually run client Windows operating systems have PCI Express graphics adapters installed.

End of Support

There is a vulnerability (CVE-2020-1036) that can be used by cybercriminals for remote code execution. Hackers can execute remote code on a host machine by using specially crafted applications on a VM with RemoteFX GPU to attack video drivers on a Hyper-V host. A host server cannot properly validate input from an authenticated user on a guest OS in this case. Microsoft doesn’t provide a patch to fix this vulnerability and says that this is an architectural issue. Due to these security concerns, Microsoft decided to disable and remove RemoteFX from all Windows versions using automatic updates:

• RemoteFX vGPU was disabled on July 14, 2020, for all Windows versions.
• RemoteFX vGPU was removed on April 13, 2021.

RemoteFX works on Windows 10 version 1803 and earlier Windows versions (can be configured in a few clicks in the GUI of Hyper-V Manager). After the KB4571756 update (a cumulative update released in September 2020), this feature is disabled in the GUI. As a result, Windows 10 RemoteFX configuration is not available in the GUI of the Hyper-V Manager in Windows 10, version 1809, because the feature was disabled. Until the updates in April 2021, RemoteFX GPU had to be enabled in PowerShell with special commands.

RemoteFX Requirements

• A supported Windows version on a Hyper-V host (Windows 7 Ultimate/Enterprise, Windows 8 Ultimate/Enterprise, Windows 10; Windows Server 2008 R2 SP1, Windows Server 2012, Windows Server 2016, Windows Server 2019). Updates removing Hyper-V RemoteFX must not be installed.
• A GPU must be compatible with DirectX 11 on a host machine (DirectX 10 can be used on Windows Server 2008 and Windows 7 installed on a physical machine). If multiple video cards are installed on the Hyper-V host, they must be identical. DirectX 11 is available on Windows 8.1 and newer Windows versions on guest VMs.
• A CPU must support SLAT (Second Level Address Translation). The name of this feature is Extended Page Tables (EPT) for Intel processors and Nested Page Tables (NPT) for AMD processors.
• Supported guest operating systems are Windows 7 SP1, Windows 8 and 8.1, Windows 10 1703 or later, Windows Server 2008 R2, Windows Server 2012, Windows Server 2016 (in a single-session deployment only).

Prepare the physical machine that is the Hyper-V host. Make sure that you have installed graphics drivers for a graphics adapter on the Hyper-V host. It is recommended that you install the latest stable version of drivers provided by your GPU vendor (for example, NVIDIA or AMD).

Prepare a virtual machine that is running a supported version of Windows to use Hyper-V RemoteFX. In my example, the name of the VM is Windows-VM, and the name of the Hyper-V host is Hyper-V-prim.

Installing the needed features

Install the Remote Desktop Virtualization Host service on the Hyper-V host.

Open Server Manager, and click Manage > Add Roles and Features.

The Add Roles and Features Wizard opens.

Installation Type. Select Role-based or feature-based installation. Hit Next at each step of the wizard to continue.

Server Selection. Select a server from the server pool. Make sure that your Hyper-V host is selected.

Server Roles. Select Remote Desktop Services in the list of roles. If the Hyper-V role is not installed, select and install the Hyper-V role.

Features. Skip this step.

Remote Desktop Services. Read the explanation, and go to the next step.

Role Services. Select Remote Desktop Virtualization Host. You can read the description in the right pane.

Reboot the Hyper-V host when the installation of the role is finished.

Configuring Hyper-V Settings

Open Hyper-V Manager by running virtmgmt in the command line or using the Windows GUI. Then open Hyper-V Settings.

In the navigation pane of the Hyper-V Settings window, click Physical GPUs. In the drop-down menu, select your video card, and then select the Use this GPU with RemoteFX checkbox.

If you cannot select this checkbox, then your video adapter cannot be used for RemoteFX, or RemoteFX is disabled.

Stop the virtual machine.

Open Hyper-V Manager, select your VM, right-click the VM, and open VM Settings.

In the VM Settings window, click Add Hardware in the left pane (the navigation pane). In the right pane, you see a list of devices that you can add to a virtual machine. The workflow is similar for Generation 1 and Generation 2 VMs.

If a RemoteFX 3D Video Adapter is active (a black font is used), select this adapter and click Add. This option is active in Windows versions until July 14, 2020, updates are installed.

If your Windows was updated, the RemoteFX 3D Video Adapter option is inactive (a grey font is used), and you cannot add this adapter in the GUI of Hyper-V Manager. At the same time, the Physical GPUs option is no longer displayed in Hyper-V Settings.

You can fix this in PowerShell.

Run the command in PowerShell on the Hyper-V host to add a RemoteFX 3D video adapter to a VM:

Add-VMRemoteFx3dVideoAdapter -VMName your_VM_name

If the command is executed successfully, a warning message is displayed.

WARNING: We no longer support the RemoteFX 3D video adapter. If you are still using this adapter, you may become vulnerable to security risks.

If you see the error: Add-VMRemoteFx3dVideoAdapter: To enable this device, use Server Manager to install the Remote Desktop Virtualization Host role service

The Remote Desktop Virtualization service is not installed on the Hyper-V host. See Installing the needed features earlier in this post.

Enabling Windows 10 RemoteFX after installing updates

As I mentioned earlier, if the Windows updates of July 14, 2020, are installed, Microsoft RemoteFX is disabled. If you have VMs configured to use RemoteFX, they won’t start. The following Windows 10 RemoteFX error for Windows 10 with the July 14, 2020, update is displayed when trying to start a VM:

An error occurred while attempting to start the selected virtual machine(s):

‘VM-name’ failed to start.

Synthetic 3D Display Controller (Instance ID xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx): Failed to Power on with Error ‘Insufficient system resources exist to complete the requested service.’.

The virtual machine cannot be started because all the RemoteFX-capable GPUs are disabled in Hyper-V Manager. You must enable at least one GPU.

Another variant of the error:

The virtual machine cannot be started because the server has insufficient GPU resources.

You can fix this in PowerShell. This method is applicable for Windows 10 and the appropriate Windows Server versions. Use commands in PowerShell to fix this error and enable RemoteFX. Run this command to check information about the video adapter on the Hyper-V host:

Get-VMRemoteFXPhysicalVideoAdapter

Find this string:

Enabled: False

It means that RemoteFX is disabled. Change this value to True.

Copy the name of the video card (in my example, NVIDIA GeForce GTX 1060).

Run the command:

Enable-VMRemoteFXPhysicalVideoAdapter -Name «video_card_name»

Enter your graphic card name.

Try to start your VM using RemoteFX again. The VM should start now.

Note also these PowerShell cmdlets to manage a RemoteFX 3D video adapter:

Set-VMRemoteFx3dVideoAdapter

Get-VMRemoteFXPhysicalVideoAdapter

After adding a RemoteFX 3D video adapter to a VM, this adapter should be visible in the list of VM hardware with options to set resolution, the number of monitors, and dedicated video memory.

If you don’t see these options in the GUI of Hyper-V Manager, use additional parameters when adding a RemoteFX video adapter to a VM in PowerShell, for example:

Set-VMRemoteFx3dVideoAdapter -VMName Windows-VM -MaximumResolution 1024×768 -VRAMSizeBytes 536870912

If Microsoft RemoteFX was configured successfully, in the guest Windows that is running on the VM, you see a Microsoft RemoteFX Graphics Device – WDDM device in the Display Adapters section of Device Manager. This RemoteFX 3D video adapter is a virtual device that shares the resources of the physical video card installed on the physical Hyper-V host by using RemoteFX.

Troubleshooting

Sometimes additional errors may occur. Let me explain a common error when a user cannot connect to a running VM using Remote desktop RemoteFX.

Symptoms:

1. Video remoting was disconnected and the appropriate message is displayed.
2. RDP failed to connect: Your Remote Desktop session has been ended, possibly for one of the following reasons.

If this error occurred on your VM, edit a group policy in the guest Windows on the VM.

Click Start > Run > gpedit.msc to open the Group Policy Editor for a local machine.

In the left pane of the Group Policy Editor window, navigate to

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Remote Session Environment > RemoteFX for Windows Server. Double-click Configure RemoteFX in the right pane of the window.

A window with Configure RemoteFX properties opens. Select Enabled, and hit OK to save settings.

Double-click Use WDDM graphics display driver for Remote Desktop Connections (available for Windows 10 version 1903 and newer Windows versions).

In the window that opens, select Disabled, and hit OK.

Update configuration of group policies to apply new settings with the command:

gpupdate /force

Reboot your virtual machine. Try to connect to your VM using the Enhanced Session Mode.

How to Prevent Disabling RemoteFX on a Hyper-V host

After the Windows update released in April 2021 is installed, VMs using a RemoteFX 3D video adapter fail to start. You can disable automatic updates on Windows computers at your own risk to continue using RemoteFX. Note that security patches are not installed automatically on Windows machines if Windows updates are disabled. Unpatched vulnerabilities are a threat for your computers, which are then at risk of getting infected with ransomware, viruses, and other malware. You can download Windows updates (patches) manually from the Microsoft site and install them. Learn which Window updates are intended to remove RemoteFX and don’t install them. Consider deploying WSUS (Windows Server Update Services) in your organization and deselect the updates that you don’t need.

Don’t forget to back up your Windows servers and Hyper-V virtual machines. In case of a disaster or ransomware attack, having a backup allows you to recover your data, restore workloads, and resume operations in a short time. Use NAKIVO Backup & Replication to back up your physical and virtual machines.

Alternatives to Hyper-V RemoteFX

Microsoft recommends that customers use DDA instead of using RemoteFX after April 2021.

DDA (Discrete Device Assignment) is a feature that allows you to attach a device (in my case, a PCI Express device) directly to a VM. In the case of a graphics card, the card should be disconnected from the host machine and connected to a VM. Only one VM can use a video card with DDA at any given time.

A video driver for a GPU must be installed on the guest OS of a VM, not on a host machine. In this case, features such as DirectX 12 and CUDA (Compute Unified Device Architecture) are available on a VM  (CUDA is not available on a VM when using RemoteFX). When using Direct Device Assignment, VM migration between Hyper-V hosts is not possible.

Consider using VMware alternatives for servers and desktops running VMs. Use Virtual Shared Graphics Acceleration (vSGA) and Virtual Shared Pass-Through Graphics Acceleration in VMware vSphere to share GPU with multiple VMs. Use compatible video cards that support GPU virtualization and have the appropriate hardware features:

• nVidia GRID vGPU
• AMD Multiuser GPU

You can enable accelerated 3D graphics for a VM in VMware Workstation if you use a desktop machine rather than a server.

Conclusion

Hyper-V RemoteFX is a useful feature that allows VMs to share hardware resources of a physical video adapter installed on a Hyper-V host and use 3D acceleration for applications on virtual machines. To configure RemoteFX on a virtual machine, install the Remote Desktop Virtualization Host service on the Hyper-V host, edit general Hyper-V settings to select the GPU that must be used for video acceleration, and add a RemoteFX 3D video adapter in the virtual hardware options of the VM. Unfortunately, Hyper-V RemoteFX is deprecated by Microsoft, and using RemoteFX is possible only until you install Windows updates of April 2021.

I realize a few years have passed but wanted to answer since this post shows up pretty high when you google for «virtualbox 3d multiple GPU». In the time that has passed, things have gotten a lot simpler and better.

People that stumble upon this thread will likely land here because they have a laptop or PC that has two GPU’s, which is quite common these days — especially on gaming laptops. The onboard Intel GPU is used for rendering windows and general applications, but applications that make use of GPU 3D functionality should do that via the higher performing Nvidia GPU.

Today, I was building an Ubuntu VM on my laptop to do some cross-platform development, and everything was fine except the guest VM was extremely slow, and there was no explanation for it because CPU, memory, disk were all showing low utilization.

It didn’t take long to figure out it was video performance that was causing the problem. Launching applications, maximizing/minimizing windows — anything that we take for granted in 2019 but needs 3D acceleration to work at any reasonable speed — was using GPU 0.

It was easy to determine this because Windows 10 now has the ability to see GPU utilization using «task manager», then the «performance» tab. And I could see as I moved windows, maximized, minimized, that was being done through GPU on the host. That GPU on the host is the integrated Intel HD GPU, and I wanted to use the NVidia GTX-1050ti, which was GPU1.

After searching around I didn’t really find anywhere where you could specify which GPU to use. But this thread, and some others, reminded me that on these kind of setups you have to go into the NVidia control panel, then «manage 3d settings», then the «Program Settings» tab.

You won’t likely find «Virtualbox» in the list. But you can press the «Add» button, and add virtualbox.exe. You may have to drill down the drive/path where your virtualbox installation is. Once you have added it, in the settings below make sure that item 2. «Select the preferred graphics processor for this program» is set to the GPU that you want it to use, which in my case was «HIgh-performance NVIDIA processor».

Don’t set it to auto, and certainly don’t set it to integrated. Of course, you need the VM settings set with the 3D acceleration box ticked, and you need the guest additions installed on the host. But once you have set the host video 3d settings as described above, shutdown the guest VM, exit virtual box, and then re-launch virtualbox and the VM.

If you use task manager|performacne and look at the «virtualbox manager» process and watch what GPU gets used when you navigate the guest VM’s UI, you should see it using the better GPU now. See the image pasted below.

All that said, don’t expect to be able to run games in a guest VM. 3D acceleration pass thru still is not quite that far along. But you can expect to have a modern OS and UI in your guest, and have an acceptable experience. One would be able to play older games in the guest VM, like anything based on directX9. Unfortunately, as the ability to virtualize GPU eveolves, the 3d gaming technology evolves quicker.

Рассмотрим, как пробросить графический адаптер Nvidia GeForce в виртуальную машину Windows 10 с хоста KVM (на базе Linux CentOS 8).

В BIOS хоста KVM должна быть включена поддержка IOMMU. Проверьте, что в /etc/default/grub включена поддержка IOMMU. Если нет, добавьте в файл строку:

GRUB_CMDLINE_LINUX="crashkernel=auto resume=/dev/mapper/cl-swap rd.lvm.lv=cl/root rd.lvm.lv=cl/swap rhgb quiet intel_iommu=on"

И обновите конфигурацию:

# grub2-mkconfig -o /boot/grub2/grub.cfg

Отключите драйвер nouveau, который может вызвать проблемы с привязкой vfio-pci к видеокарте.

# grubby --update-kernel=ALL --args="rd.driver.blacklist=nouveau nouveau.modeset=0"
# mv /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak
# dracut /boot/initramfs-$(uname -r).img $(uname -r)
# echo 'blacklist nouveau' > /etc/modprobe.d/nouveau-blacklist.conf

Выведите список доступных видеокарт на хосте KVM:

# lspci -nn | grep -i nvidia

Каждая видеокарта состоит из нескольких компонентов. Например:

82:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU102 [GeForce RTX 2080 Ti Rev. A] [10de:1e07] (rev a1)
82:00.1 Audio device [0403]: NVIDIA Corporation TU102 High Definition Audio Controller [10de:10f7] (rev a1)
82:00.2 USB controller [0c03]: NVIDIA Corporation TU102 USB 3.1 Host Controller [10de:1ad6] (rev a1)
82:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU102 USB Type-C UCSI Controller [10de:1ad7] (rev a1)

Скопируйте VID:PID устройств, которые нужно пробросить в ВМ.

Создайте файл /etc/modprobe.d/vfio.conf и добавьте в него строку со списком, доступных для vfio-pci (список в одной строке):

options vfio-pci ids=10de:1e07, 10de:10f7, 10de:1ad6, 10de:1ad7

Выполните команду:

# echo 'vfio-pci' > /etc/modules-load.d/vfio-pci.conf

И перезагрузите KVM хост.

Проверьте, что графические карты доступны в режиме vfio:

# lspci -vs 81:00.0

В выводе должны присутствовать строки:

Kernel driver in use: vfio-pci
Kernel modules: nouveau

В моем примере я создал на хосте KVM чистую ВМ (с UEFI firmware) с Windows 10 и выключил ее. Теперь нужно отредактировать конфигурационный XML файл виртуальной машины KVM.

Внутри тегов <hyperv></hyperv> добавьте:

<vendor_id state='on' value='111111111'/>

Внутри тегов <features></feature>:

<kvm>
<hidden state='on'/>
</kvm>

И в конце конфигурационного файла перед тегами </devices> </domain> добавьте следующую конфигурацию:

<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0' bus='0x82' slot='0x0' function='0x0'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0' bus='0x82' slot='0x0' function='0x1'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0' bus='0x82' slot='0x0' function='0x2'/>
</source>
</hostdev>
<hostdev mode='subsystem' type='pci' managed='yes'>
<source>
<address domain='0x0' bus='0x82' slot='0x0' function='0x3'/>
</source>
</hostdev>

В этом примере мы хотим пробросить в ВМ устройства все устройства с видеокарты 82:00. На ней доступны 4 функции, мы добавили их все в XML файл:

• VGA controller (82:00.0)
• Audio device (82:00.1)
• USB 3.1 Host Controller3.1 (82:00.2)
• USB Type-C UCSI Controller (82:00.3)

Сохраните XML файл и запустите ВМ. Windows должна определить новое графическое устройство и вы можете установить драйвера Nvidia.