blog.vmpress.org

Страницы

понедельник, 15 апреля 2019 г.

Проброс графического адаптера и режим ускорения графики vDGA

Сегодня я хочу рассказать о некоторых нюансах проброса графических адаптеров внутрь ВМ в режиме VMDirectPath I/O и ускорении графики в режиме vDGA в Horizon.

VMware Horizon поддерживает различные режимы ускорения графики для виртуальных десктопов. Из них три режима так или иначе могут задействовать ресурсы графических адаптеров: vSGA, Shared Pass-Through Graphics (он же NVIDIA vGPU или AMD MxGPU), а также vDGA.

Пример использования ускорителя NVIDIA Quadro P2000 в режиме vDGA можно увидеть по ссылке: http://blog.vmpress.org/2019/02/horizon-blast-h265.html.

vDGA задействует технологию проброса PCI устройства внутрь ВМ (VMDirectPath I/O) и позволяет предоставить одной из ВМ графический адаптер в монопольное использование. После проброса внутри гостевой ОС устанавливаются соответствующие драйверы устройства, и с ним можно работать также, как если бы оно было подключение к обычному настольному компьютеру. Это и является основным преимуществом, равно как и недостатком, данного режима, поскольку позволяет обеспечить максимальный уровень производительности работы графического адаптера, но в то же время накладывает на ВМ ряд ограничений, например, невозможность использования VMware HA, vMotion, снапшотов, необходимость резервирования оперативной памяти ВМ и т.д.

При использовании vDGA в связке с графическими адаптерами производства NVIDIA есть несколько нюансов.

Десктопные графические адаптеры серии GeForce (например, GeForce GTX 1060) не поддерживаются в данном режиме. При пробросе такого адаптера внутрь ВМ после установки соответствующих драйверов в диспетчере устройств будет отображаться сообщение об ошибке:
Windows has stopped this device because it has reported problems. (Code 43)

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

Драйвер можно обмануть, добавив расширенную настройку в конфигурацию ВМ.

В этом случае графический адаптер сможет работать внутри ВМ. Однако, в связке с VMware Horizon вы все равно не сможете обеспечить корректную работу протоколов PCoIP или BLAST с десктопными адаптерами — при удаленном подключении к такой ВМ вы просто увидите черный экран. Это вызвано ограничениями десктопной версии драйвера NVIDIA GeForce.

Возможности по работе с Horizon доступны только в линейке графических адаптеров серии Quadro и Tesla, причем младшие модели Quadro (400, 600) также не будут работать (error 43). Минимальные поддерживаемые модели, начинаются с 2000, например, M2000, P2000, M4000 и т.д. Если вы планируете использовать vDGA в Production среде, то обязательно проверьте совместимости с HCL на сайте VMware. Если вы хотите, чтобы ваше решение поддерживалось, то вы должны использовать поддерживаемый графический адаптер И поддерживаемую модель сервера И поддерживаемое поколение процессоров И поддерживаемую версию гипервизора ESXi И поддерживаемую версию Horizon. Даже если вы знаете, что какой-нибудь NVIDIA Quadro K5000 будет прекрасно пробрасываться внутрь ВМ с ESXi 6.7, отсутствие поддержки данной версии гипервизора означает, что решение в целом будет неподдерживаемым со стороны вендора.

Существует заблуждение, что при использовании ускорителей NVIDIA Tesla в связке с vDGA не требуется приобретать лицензии NVIDIA GRID (в отличие от vGPU). Это не так, в чем легко можно убедиться, заглянув в документацию по лицензированию NVIDIA.

Проброс видеокарты NVIDIA в VMware ESXi 6.0

diz решил поделиться своим опытом проброса видеокарты NVDIA GTX в ESXi 6.0.

Добрый день, дорогие друзья!

Говорят, что с 2015-ого года работодатели стали сразу выгонять с собеседования ИТ-шников, если вдруг выясняется, что у них нет личного сервера с развернутым частным облаком.

Чтобы не выбиваться из тренда, я собрал дома небольшой двухпроцессорный сервер на базе материнской платы SUPERMICRO X9DRI-F и пары Xeon E5-2670. Т.к. несколько лет своей жизни я посвятил, в т.ч. администрированию инфраструктуры VMWare, то в качестве гипервизора виртуализации был выбран именно ESXi.

Частное облако-домашняя лаба — это, конечно, замечательно и здорово, однако, для комфортной повседневной работы и StarCraft2 желательно иметь доступ к дискретной видеокарте.

Тому, как задружить “бытовую” nVidia GTX и ESXi 6 и посвящается данная статья — краткий проводник-путеводитель по граблям.

Первое, что вам захочется сделать после установки дискретной видеокарты в сервер — переключить приоритет инициализации видеокарты в BIOS в пользу внешней, чтобы видеть POST прямо на экране подключенного к ней монитора. Этого делать не стоит, т.к. в таком случае вы потеряете возможность использовать iKVM материнской платы.

Итак, приступаем к пробросу видеокарты в виртуальную машину с MS Windows 10. Увидев web-интерфейс ESXi 6 я искренне обрадовался тому, что завязал с системным администрированием четыре года назад. Откладываем этот замечательный интерфейс в сторону, т.к. проброс видеокарты через него вы настроить не сможете, при старте виртуальная машина будет ругаться на несоответствие идентификатора устройства PCIe (PCIe passthrough device id invalid) и переключаемся на старый добрый и толстый клиент:

Жмем “Edit..”: И ставим галочки только напротив видеокарты и связанного HD AUDIO. Яочень рекомендую сперва добиться ее работоспособности, а уже потом пробрасывать мышку-клаву и звук. Затем переходим к добавлению PCIe устройства в виртуальную машину:

В мире розовых пони, где nVidia не жлобы, а VMWare тестируют свои продукты перед релизом, на этом все бы и закончилось. В нашем реальном мире грабли только начинаются. Сперва выясняется, что мы выдали виртуальной машине >2 Гб памяти и теперь она не может поделить адресное пространство с видеокартой. SUPERMICRO протягивает свой FAQ помощи http://www.supermicro.com/support/faqs/results.cfm?id=34 Цитирую:

“We need to make sure GPU BARs are memory mapped above 4GB and to enable EFI firmware add the following 3 lines to configuration (.vmx) file of VM: «pciPassthru.use64bitMMIO = «TRUE» «, «firmware = «efi» » and «vmci.msix = FALSE «.”

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

Еще раз обращу внимание, что тип firmware виртуальной машины должен быть “EFI”, кстати, его можно поменять только через web gui, если будете пытаться менять его через толстый клиент, то он перескочит обратно на “BIOS”.

Далее наша виртуальная машина должна успешно запуститься, а драйвер видеокарты порадовать нас такой ошибкой: Суть проблемы: nVidia хочет чтобы все покупали видеокарты серий TESLA и QUADRO и выступает против того, чтобы пользователи занимались виртуализацией видеокарт “бытовых” серий. Драйвер детектит запуск в виртуальной машине и не дает видеокарте стартовать. Обходится при помощи того же трюка, который используется в nested виртуализации — прописыванием строчки hypervisor.cpuid.v0 = “FALSE” в vmx файле виртуальной машины.

Почти все. Теперь при включении виртуальной машины у нас всего-навсего наглухо виснет гипервизор, даже не выкидывая PSOD. Просто все замирает без каких-либо записей в логах. Можно притвориться умным и сказать, что эту проблему мне помогло решить чтение главы “Problems with Device Assignment Dependencies” документа “Configuration Examples and Troubleshooting for VMDirectPath”, доступного по ссылке http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vsp-4-vmdirectpath-host-technical-note.pdf, но нет. Форумы в интернете забиты вопросами по этим симптомам с криками о том, что при переходе с версии 5.0 к более старшим VMWare сломала passthrough видеокарт (это относится как к nVidia, так и к ATI) и только один человек c ником mvrk нашел решение: необходимо отредактировать файл по пути /etc/vmware/passthru.map хоста виртуализации и исправить для нашей видеокарты режим проброса с bridge на link:

Вот теперь можно переходить к пробросу мышки и клавиатуры. Тут тоже не обошлось без “особенностей”: когда я пробросил оба USB контроллера материнской платы в vm, драйвер видеокарты снова стал падать с 43й ошибкой. Решилось пробросом только одного контроллера, к портам которого я подключил оба устройства.

Какая виртуальная среда для Windows 10 может использовать видеокарту (в Hyper-V к примеру не отображается моя NVIDIA 1080) установленную в ПК?

Задача развернуть изолированное игровое пространство на виртуальной машине. В дальнейшем будет предоставляться удаленный доступ к этой виртуальной игровой среде. Как-то так.

Огромная просьба без хейтерства и отсылок к гуглу, заранее спасибо!

• Вопрос задан более двух лет назад
• 5082 просмотра

Чтобы виртуальная машина могла использовать видеокарту на полную катушку нужно ее «пробросить» с помощью настроек виртуальной машины в гипервизоре. При этом сам хост уже не сможет ее использовать. То же самое верно и для других устройств.
Чтобы вы могли пробросить в виртуалку видеокарту у вас должно быть две видеокарты. Тогда одну вы можете использовать на хосте, а другую пробросить в виртуалку.
Не факт, что ваш гипервизор умеет пробрасывать что-то, кроме USB портов.

Из того что я знаю, подобное умеют VMWare ESXi и Citrix XenServer (Hypervisor).
Десктопные варианты гипервизоров это не умеют, имхо.

А такой вопрос. Если у меня есть интегрированное видео
Моник подключен к мат. плате (будем думать что настроили так, чтобы показывало изображение)

Тогда возможно будет ее пробросить?
Как считаете?

начиная с 1809 поддержка RemoteFX закрывается

(источник — консоль Hyper-V, upd кажется в настройках самого сервера. там же было что то о причинах и что в замен, но снес его в пользу VMWare на данный момент, по этому точнее не подскажу. но возможно там дается решение для текущего поколения Hyper-V)

то есть лучше не то что бы 1803, а вообще LTSB или гуевый сервер 1607
еще аргумент в пользу поколения 1607 — в LTSB все еще есть контроль загрузки процессора. где то с 1709, его выпилили из проф

так же рекомендую к прочтению, возможно пригодится, если варианты типа vSphere не годятся, читать начиная с упоминания NVIDIA GRID VGPU — https://habr.com/post/257425/

В общем-то не удивительно, что тема набирает популярность — задача иметь линух на хосте и полноценную игровую машину на винде гостем (или как здесь — винда в винде) для того, чтобы разделить мух и котлет все интереснее, тем более, что видеокарты все мощнее.
Вот только производители видеокарт тоже об этом знают и нифига этому не рады 🙂 Да и производители гиперов тоже не сидят на месте.
Чтоюы видюха могла полностью использоваться виртуалкой — ее нужно просунуть туда целиком, как устрйоство, чтобы виртуалка ее нашла и поставила дрова. Мне известна только одна комбинация железа, гипера и оси, где по неподтвержденным данным этот финт ушами канает — видюха от ATI (НЕ NVidia!), гипер KVM, линух хостом, винда гостем.
Какое-то время я пробовал сам, но нифига не преуспел — в KVM видюха пробрасывается, но винда нифига не запускает дрова (потому что NVidia противодействует этому. Намеренно.) в ESXi дрова ставятся, но как «переключить» на нее «монитор» я так и не понял. В Hyper-V же я не уверен, что даже пробросить удастся.

Там статья по ссылке выше. Ее конечно стоит прочитать, но исключительно для самообразования, потому что автор скромно умолчал, сколько стоит GRID K1/K2 карта. Для справки — GRID K1 — порядка 200 тыс руб, GRID K2 — порядка 400 тыс
Пруф

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

таким образом конфиг был пересобран на далеко не лучшей матери, но забугорные ребята хвалят эту фирму за то что ее железо чаще всего подходит для таких вещей:
Процессор — i7 8700k
Мать — ASRock Z390M Pro4
Видеокарта — INNO3D GeForce GTX 1070 iChill X4

# If you change this file, run ‘update-grub’ afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
# info -f grub -n ‘Simple configuration’

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=»Proxmox Virtual Environment»
GRUB_CMDLINE_LINUX_DEFAULT=»quiet intel_iommu=on»
GRUB_CMDLINE_LINUX=»»

# Disable os-prober, it might add menu entries for each guest
GRUB_DISABLE_OS_PROBER=true

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD . )
#GRUB_BADRAM=»0x01234567,0xfefefefe,0x89abcdef,0xefefefef»

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo’
#GRUB_GFXMODE=640×480

# Uncomment if you don’t want GRUB to pass «root=UUID=xxx» parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=»true»

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE=»480 440 1″

# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with «#» are ignored.
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

options vfio-pci ids=10de:1b81,10de:10f0 disable_vga=1

blacklist radeon
blacklist nouveau
blacklist nvidia

args: -cpu ‘host,+kvm_pv_unhalt,+kvm_pv_eoi,hv_vendor_id=willitwork,kvm=off’
bios: ovmf
boot: dcn
bootdisk: sata0
cores: 8
cpu: host
hostpci0: 01:00.0,pcie=1
ide2: local:iso/ru-en_windows_10_1803_x86-x64.iso,media$
machine: q35
memory: 16384
net0: e1000=EA:20:FA:6A:D6:A0,bridge=vmbr0
numa: 0
ostype: win10
sata0: local-lvm:vm-100-disk-0,size=120G
scsihw: virtio-scsi-pci
smbios1: uuid=751edeca-d249-4c0d-9ded-b59d929df0f1
sockets: 1
usb0: host=1-8.4
usb1: host=1-8.3
vmgenid: b75aeb27-3102-458d-8e23-18cd27796dc1

Следующий нюанс. Я использовал:
— второй ПК (Мини-ПК),
— 1 мышь, которую переставлял постоянно,
— 1 клавиатуру на хосте
— 3 подключения к монитору (VGA — для интегрированной видеокарты, HDMI — для GTX1070, на DVI находится Мини-ПК. Переключения между видеосигналами осуществляется через меню монитора)

0й этап — на материнке включил VT-d:Enable, Intel Vitrualization Technology:Enable, Primary Graphx adapter:VGA, Above 4G Decoding:Enable.
1й этап — Установил Proxmox на хост.
2й этап — Настроил Proxmox (см. конфиги выше) удаленно с Мини-ПК через текстовую консоль, т.е. настройки были прописаны вручную, но сам файл виртуальной машины был создан через вебформу.
3й этап — Через Удаленную видеоконсоль я поставил Windows 10 Pro и накатил драйвера. Windows распознал сперва видеодрайвер proxmox для работы через видеоконсоль, потом нашел драйвер для GTX1070, а после обновления через интернет (принудительный поиск драйверов в сети) скачал и установил нужный мне драйвер.
4й этап — Я перезапустил виртуалку, переключил отображение видеопотока на мониторе на HDMI разъем и. все заработало, никаких ошибок 43. При этом рабочий стол определяется как №2, №1 недоступен, он открывается через видеоконсоль, но там пусто.

я попробовал запустить видео Blue-ray — нет проблем, тормозов с видеорядом нет, запустил Warhammer online — он завелся и в столице у мя лагов нет, запустил GTA5 у мя выскочила сюжетка, вполне комфортно пострелял. Правда у мя не проброшена клавиатура, т.к. PS/2 поэтому далеко не ушел. На сколько я потерял в производительности — не могу сказать, визуально на текущий момент нисколько, но после проброса клавиатуры я смогу прогнать более адекватные тесты и бенчмарки. По крайней мере это работает нормально, в отличие от «сносного» Remote-FX Hyper-V, который зато пашет из коробки.