Windows hyper v server 2019 проброс видеокарты

Развертывание графических устройств с помощью дискретного назначения устройств

Область применения: Windows Server 2022, Microsoft Hyper-V Server 2016, Windows Server 2016, Windows Server 2019, Microsoft Hyper-V Server 2019

Начиная с Windows Server 2016, вы можете использовать дискретное назначение устройств или DDA для передачи всего устройства PCIe в виртуальную машину. Это позволит обеспечить высокий уровень производительности доступа к таким устройствам, как хранилище NVMe или графические карточки из виртуальной машины, одновременно используя собственные драйверы устройств. Дополнительные сведения о том, какие устройства работают, каковы возможные последствия безопасности и т. д., см. в плане развертывания устройств с помощью дискретного назначения устройств.

Существует три этапа использования устройства с дискретным назначением устройств.

• Настройка виртуальной машины для дискретного назначения устройств
• Отключение устройства из раздела узла
• Назначение устройства гостевой виртуальной машине

Все команды можно выполнить на узле в консоли Windows PowerShell от имени администратора.

Настройка виртуальной машины для DDA

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

1. Настройка параметра «Автоматическое действие остановки» виртуальной машины для turnOff путем выполнения

Для графических устройств требуется дополнительная подготовка виртуальных машин

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

1. Включение Write-Combining на ЦП
2. Настройка 32-разрядного пространства MMIO
3. Настройка более 32-разрядного пространства MMIO

Приведенные выше значения пространства MMIO являются разумными значениями для экспериментирования с одним GPU. Если после запуска виртуальной машины устройство сообщает об ошибке, связанной с недостаточными ресурсами, скорее всего, потребуется изменить эти значения. Обратитесь к плану развертывания устройств с помощью дискретного назначения устройств , чтобы узнать, как точно вычислить требования MMIO.

Отключение устройства из раздела узла

Необязательно. Установка драйвера секционирования

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

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

Поиск пути расположения устройства

Путь к расположению PCI необходим для отключения и подключения устройства с узла. Пример пути расположения выглядит следующим образом: «PCIROOT(20)#PCI(0300)#PCI(0000)#PCI(0800)#PCI(0000)» Дополнительные сведения о расположении пути расположения можно найти здесь: планирование развертывания устройств с помощью дискретного назначения устройств.

Отключение устройства

С помощью диспетчера устройств или PowerShell убедитесь, что устройство «отключено».

Отключение устройства

В зависимости от того, предоставил ли поставщик драйвер устранения рисков, необходимо использовать параметр -force или нет.

• Если драйвер для устранения рисков был установлен
• Если драйвер устранения рисков не установлен

Назначение устройства гостевой виртуальной машине

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

Дальнейшие действия

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

Удаление устройства и его возвращение на узел

Если вы хотите вернуть устройство обратно в исходное состояние, необходимо остановить виртуальную машину и выдать следующее:

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

Пример

Подключение GPU к виртуальной машине

В этом примере мы используем PowerShell для настройки виртуальной машины с именем ddatest1, чтобы получить первый GPU, доступный производителем NVIDIA, и назначить его виртуальной машине.

Устранение неполадок

Если вы передали GPU в виртуальную машину, но удаленный рабочий стол или приложение не распознает GPU, проверьте следующие распространенные проблемы:

• Убедитесь, что вы установили последнюю версию поддерживаемого драйвера поставщика GPU и что драйвер не сообщает об ошибках, проверив состояние устройства в диспетчере устройств.
• Убедитесь, что на устройстве достаточно места MMIO, выделенного на виртуальной машине. Дополнительные сведения см. в разделе MMIO Space.
• Убедитесь, что вы используете GPU, поддерживаемый поставщиком в этой конфигурации. Например, некоторые поставщики не могут работать с карточками потребителей при передаче на виртуальную машину.
• Убедитесь, что запущенное приложение поддерживает работу на виртуальной машине, и что gpu и связанные с ним драйверы поддерживаются приложением. В некоторых приложениях есть списки разрешенных GPU и сред.
• Если вы используете роль узла сеансов удаленного рабочего стола или Службы Windows Multipoint Services на гостевом компьютере, необходимо убедиться, что для определенной записи групповой политики задано разрешение использования GPU по умолчанию. Используя объект групповой политики, примененный к гостеву (или редактору локальной групповой политики на гостевом компьютере), перейдите к следующему элементу групповой политики:Шаблоны администраторовконфигурации> компьютеров > windowsComponents> Remote DesktopServices> RemoteDesktop Host>Remote Session Environment>Use the hardware default graphics adapter for all Remote Desktop Services sessions. Задайте для этого значения значение «Включено», а затем перезагрузите виртуальную машину после применения политики.

Источник

Развертывание графических устройств с помощью vGPU RemoteFX

применимо к: Windows server 2022, Windows server 2019, Windows Server 2016, Microsoft Hyper-V Server 2016

Из соображений безопасности процессор RemoteFX vGPU по умолчанию отключен для всех версий Windows, начиная с обновления для системы безопасности за 14 июля 2020 г., и удален, начиная с обновления для системы безопасности за 13 апреля 2021 г. См. KB 4570006.

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

Требования к RemoteFX vGPU

Требования к системе узла:

• Windows Server 2016
• Совместимый с DirectX 11,0 графический процессор с драйвером 1,2 WDDM, совместимым с курьером.
• ЦП с поддержкой преобразования адресов второго уровня (SLAT)

Требования к гостевым виртуальным машинам:

• Поддерживаемая гостевая ОС. дополнительные сведения см. в разделе RemoteFX поддержка 3d-видеоадаптеров (gpu).

Дополнительные рекомендации для гостевых виртуальных машин:

• функции OpenGL и OpenCL доступны только в гостевых ос Windows 10 или Windows Server 2016.
• DirectX 11,0 доступен только для гостевых ос Windows 8 и более поздних версий.

включение RemoteFXного видеопроцессора

чтобы настроить RemoteFXный виртуальный жесткий процессор на узле Windows Server 2016:

1. Установите графические драйверы, рекомендованные поставщиком GPU, для Windows Server 2016.
2. создайте виртуальную машину с гостевой ос, поддерживаемой RemoteFXным графическим процессором. дополнительные сведения см. в разделе RemoteFX поддержка 3d-видеоадаптеров (gpu).
3. добавьте в виртуальную машину адаптер RemoteFX 3d graphics. дополнительные сведения см. в статье настройка 3d-адаптера RemoteFX для виртуальных gpu.

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

1. В диспетчере Hyper-V перейдите к параметрам Hyper-V.
2. выберите физические gpu в Параметры Hyper-V.
3. Выберите графический процессор, который не нужно использовать, а затем снимите флажок Использовать этот графический процессор в RemoteFX.

Настройка трехмерного адаптера vGPU RemoteFX

Вы можете использовать пользовательский интерфейс диспетчера Hyper-V или командлеты PowerShell, чтобы настроить трехмерный графический адаптер vGPU RemoteFX.

настройка RemoteFX виртуального устройства с помощью диспетчера Hyper-V

Останавливает виртуальную машину, если она выполняется в данный момент.

откройте диспетчер Hyper-V, перейдите к Параметры вм, а затем выберите добавить оборудование.

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

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

• Установка большего числа значений для любого из этих параметров повлияет на масштаб службы, поэтому следует задать только то, что необходимо.
• Если необходимо использовать 1 ГБ выделенной видеопамяти, для получения наилучших результатов используйте 64-разрядную гостевую виртуальную машину вместо 32-bit (x86).

Нажмите кнопку ОК , чтобы завершить настройку.

настройка RemoteFXного gpu с помощью командлетов PowerShell

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

Мониторинг производительности

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

Память системы узла

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

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

Видеопамять основного GPU узла

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

ЦП узла

Гипервизор планирует размещение и виртуальные машины на ЦП. дополнительная нагрузка на узел с поддержкой RemoteFX увеличивается, так как система запускает дополнительный процесс (rdvgm.exe) на виртуальном рабочем столе с поддержкой виртуальных рабочих столов. Этот процесс использует драйвер графического устройства для выполнения команд GPU. Кодек также использует ЦП для сжатия данных экрана, которые необходимо отправить обратно клиенту.

Большее число виртуальных процессоров означает лучшее взаимодействие с пользователем. Мы рекомендуем выделить не менее двух виртуальных процессоров на виртуальный рабочий стол с поддержкой виртуальных рабочих столов. Мы также советуем использовать архитектуру x64 для виртуальных рабочих столов с поддержкой GPU, так как производительность виртуальных машин x64 лучше по сравнению с виртуальными машинами x86.

Вычислительная мощность процессора

У каждого виртуального рабочего стола с поддержкой виртуальных рабочих столов есть соответствующий процесс DirectX, выполняемый на сервере узла. этот процесс воспроизводит все команды графики, полученные от RemoteFX виртуального рабочего стола, на физический графический процессор. Это аналогично одновременному запуску нескольких приложений DirectX на одном физическом GPU.

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

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

дополнительные сведения о счетчиках производительности для мониторинга RemoteFX поведения виртуальных gpu см. в статье диагностика проблем производительности графики в удаленный рабочий стол.

Источник

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.

Виртуальный сервер уже давно перестал быть чем-то IT-шным и все чаще данной услугой интересуются люди с совершено различными и повседневными рабочими задачами: от размещения бухгалтерских программ до программ по автоматизации рутинных SEO-задач, от игровых серверов до самих игр (самых современных!), от общего файлового сервера небольшой организации до полноценных удалённых рабочих столов крупных компаний.

Вовсе не обязательно играть в игры, чтобы вам потребовалась видеокарта, сейчас ресурсы видеокарт активно используют разработчики популярного программного обеспечения: любой современный браузер будет отрисовывать страницы сайтов значительно быстрее если сможет использовать графический ускоритель, не говоря уже о том, что 3D игры могут быть в самих браузерах, которые работают на платформе WebGL.

Возможность виртуализации ресурсов видеокарт не нова и присутствует во всех популярных средах: Hyper-V, KVM, XEN, VirtualBox и собственная среда от самого популярного производителя чипсетов – NVIDIA GRID.

В данной статье мы будем говорить о RemoteFX – возможностях видеокарт на виртуальных серверах под управлением Hyper-V, именно на этой платформе они работают на VPS.house с видеокартами профессионального уровня NVIDIA Quadro P6000.

В качестве простой демонстрации поведем тест, взяв конфигурацию VPS с 2 ядрами процессора и 2 ГБ оперативной памяти с виртуальной видеокартой 256МБ памяти и без. В обоих случаях мы откроем в браузере Internet Explorer пример на WebGL одной и той же страницы.

Результат на виртуальном сервере, где установлена видеокарта:

Если видеокарту с этого же сервера убрать:

Итак, с видеокартой мы получаем 42 кадра в секунду, без нее – всего 3 кадра, которые отчаянно рендерит процессор.

В качестве гостевой операционной системы использовалась Windows 10 PRO, так как, к сожалению, в серверной версии Windows 2016 браузеры не начинают использовать графический ускоритель, несмотря на то, что он фактически присутствует.

Технология RemoteFX впервые была внедрена в Windows Server 2008 R2 SP1 и включала в себя некоторое базовые возможности:

• RemoteFX vGPU – позволила распределить ресурсы физической видеокарты на несколько виртуальных экземпляров, таким образом на виртуальных машинах Hyper-V появился настоящий 3D-рендеринг силами графического адаптера.
• RemoteFX USB Redirection – поддержка перенаправления USB-устройств в виртуальные машины, что позволило использовать различные периферийные устройства, подключенные к «тонким клиентам»
• RemoteFX Codec – кодек для сжатия и передачи видео и текста высокой четкости, не требующий специального оборудования и использующий ресурсы исключительно процессора

Несмотря на описанные выше возможности, популярности RemoteFX не обрел ввиду крайней ограниченности ресурсов, которые можно было бы назначить виртуальной машине, с выходом Windows Server 2012 появилось множество дополнительных функций:

• Адаптивная графика RemoteFX – графический коннектор, динамически адаптирующийся к различным условиям работы: тип передаваемого графического контента, доступные вычислительные мощности процессора, скорость интернет-канала между сервером и клиентом, а также скорость рендеринга на стороне клиента.
• RemoteFX для WAN – серия модификаций на сетевом уровне для поддержки UDP и обеспечения стабильного подключения как в WAN, так и в беспроводных сетях
• RemoteFX Multi-Touch – позволила использовать тачскрины на тонких клиентах и передавать на сервер до 256 точек одновременного касания
• RemoteFX Media Redirection API – позволила VoIP-приложениям интегрироваться с RemoteFX, обеспечив рендеринг и передачу видео и аудио контента непосредственно на стороне клиента
• Выбор GPU – все функции RemoteFX доступны как с использованием графического процессора с программным эмулятором, так и с установленной физической видеокартой внутри сервера, что дает настоящее аппаратное ускорение
• В RemoteFX vGPU добавлена поддержка DirectX 11

Однако, настоящий прорыв в повсеместном использовании виртуальных видеокарт на серверах под управлением Hyper-V произошел только с выходом Windows Server 2016, позволяющая явно задавать выделяемый объём видеопамяти виртуальному серверу (VPS), а сами объемы значительно выросли (до 1ГБ на каждый экземпляр), обновленный протокол RemoteFX Media Streaming начал работать для всех типов медиаконтента и полностью заменил использующийся ранее протокол MMR (Multi Media Redirection). Помимо этого, появилась поддержка OpenGL 4.4 и OpenCL 1.1 API на виртуальной машине с помощью адаптера RemoteFX.

Тест производительности видеокарты на VPS в популярном бенчмарке FurMark

Подключённая к современному VDS (виртуальному серверу) видеокарта под управлением Windows Server 2016 превращает его в полноценный домашний ПК. Данная операционная система обладает привычным пользовательским интерфейсом, мало отличимым от Windows 10. На таком сервере вы можете свободно запускать практически любое программное обеспечение и решать самые разносторонние задачи.

Без долгих ожиданий запускается самые тяжёлые графические приложения. Пример работы Autodesk 3ds Max 2019 на виртуальном сервере VPS.house:

И конечно же современные игры, в Battlefield 1 видео игры будет таким же плавным, как если бы вы запустили её на своём домашнем ПК (при хорошем интернет-соединении):

For a short guide on how to enable GPU-PV for Hyper-V, click here.

Nowadays, Hyper-V has evolved from a server virtualization software to something very integral to contemporary Windows operating systems. The ability to run Linux applications (WSL 2), Virtualization-based Security, and application containerization (the WDAG and Windows Sandbox) are powered Hyper-V. Still, Hyper-V is one of the best virtualization platform available in Windows platform, if your guest is either a modern Linux or modern Windows. Being a Type-1 Hypervisor with tight integration to the host operating system means that Hyper-V offers unmatched performance when virtualizing said guests.

In this post, I am going to guide how to enable GPU acceleration in Hyper-V on Windows 10 guests. This is different from the previous RemoteFX approach (which is already discontinued, by the way), in which it creates a virtual GPU on guest and the guest application’s call on graphics API upon that virtual GPU is interpreted, translated, forwarded to host, and back again. Besides inefficient, this approach means limited graphics API support as different hardware has different characteristics and supports a different set of APIs, where a common denominator has to be selected. Further, every time there is a new graphics API such as Vulkan or DirectX 12, the whole system has to be engineered. This approach is similar to those used in VMware Workstation and VirtualBox, and they share the same limitations as well.

WDDM GPU Paravirtualization

Enter the WDDM GPU Paravirtualization (or GPU-PV for short). GPU-PV leverages the new graphics driver model in WDDM 2.5 (first introduced in Windows 10 version 1809) to provide support for virtualizing GPUs right from the graphics driver itself. The GPU is virtualized similarly to CPU (for example, multiple virtual machines and the host can share a single GPU, and a single virtual machine can fully utilize the GPU when the GPU is unused). Guest virtual machines use the same GPU driver as the host, which means that the full capabilities of the GPU are supported on the guest as well.

In this DirectX support for WSL 2 announcement, it is said that GPU-PV is already supported for WDAG (which was introduced way back in Windows 10 version 1809) and Windows Sandbox (introduced in Windows 10 version 1903). The announcement goes further that “GPU-PV is now a foundational part of Windows” and “Today this technology is limited to Windows guests, i.e. Windows running inside of a VM or container”. Indeed, as can be seen in this Windows Sandbox configuration reference, GPU support is explicitly mentioned there. Since Windows Sandbox is pretty limited, it would be nice to have this feature on a regular Windows 10 Hyper-V virtual machines. Unfortunately, documentation to enable this feature is scarce and practically nonexistent even on the internet.

Figuring It Out

Now cut to the chase, let’s start from PowerShell. Hyper-V virtual machines are typically managed with PowerShell, and perhaps we could find something there. Let’s begin with Get-Command, which will return all commands available in the current PowerShell session.

Searching the output for the word “GPU” yields these results! Seems like we are on the right path! Let’s try to run those commands. First, let’s begin with the Get-VMPartitionableGpu, which yields the following:

Name                    : \?PCI#VEN_10DE&DEV_1C8D&SUBSYS_07BE1028&REV_A1#4&1b8a2586&0&0008#{064092b3-625e-43bf-9eb5-d
                          c845897dd59}GPUPARAV
ValidPartitionCounts    : {32}
PartitionCount          : 32
TotalVRAM               : 1000000000
AvailableVRAM           : 1000000000
MinPartitionVRAM        : 0
MaxPartitionVRAM        : 1000000000
OptimalPartitionVRAM    : 1000000000
TotalEncode             : 18446744073709551615
AvailableEncode         : 18446744073709551615
MinPartitionEncode      : 0
MaxPartitionEncode      : 18446744073709551615
OptimalPartitionEncode  : 18446744073709551615
TotalDecode             : 1000000000
AvailableDecode         : 1000000000
MinPartitionDecode      : 0
MaxPartitionDecode      : 1000000000
OptimalPartitionDecode  : 1000000000
TotalCompute            : 1000000000
AvailableCompute        : 1000000000
MinPartitionCompute     : 0
MaxPartitionCompute     : 1000000000
OptimalPartitionCompute : 1000000000
CimSession              : CimSession: .
ComputerName            : DESKTOP-61MEFBD
IsDeleted               : False

Name                    : \?PCI#VEN_8086&DEV_591B&SUBSYS_07BE1028&REV_04#3&11583659&0&10#{064092b3-625e-43bf-9eb5-dc8
                          45897dd59}GPUPARAV
ValidPartitionCounts    : {32}
PartitionCount          : 32
TotalVRAM               : 1000000000
AvailableVRAM           : 1000000000
MinPartitionVRAM        : 0
MaxPartitionVRAM        : 1000000000
OptimalPartitionVRAM    : 1000000000
TotalEncode             : 18446744073709551615
AvailableEncode         : 18446744073709551615
MinPartitionEncode      : 0
MaxPartitionEncode      : 18446744073709551615
OptimalPartitionEncode  : 18446744073709551615
TotalDecode             : 1000000000
AvailableDecode         : 1000000000
MinPartitionDecode      : 0
MaxPartitionDecode      : 1000000000
OptimalPartitionDecode  : 1000000000
TotalCompute            : 1000000000
AvailableCompute        : 1000000000
MinPartitionCompute     : 0
MaxPartitionCompute     : 1000000000
OptimalPartitionCompute : 1000000000
CimSession              : CimSession: .
ComputerName            : DESKTOP-61MEFBD
IsDeleted               : False

It lists two GPUs here, which is what my system has (the Dell XPS 9560 with the NVIDIA Optimus system). Based on the PCI vendor IDs, the first one must correspond to the NVIDIA GeForce GTX 1050, and the second one to the Intel HD Graphics 630. The opposite of this command, Set-VMPartitionableGpu, seems to be used only for limiting the partition count.

Now, let’s try to set up a Hyper-V Windows 10 virtual machine, and try to run the Set-VMGpuPartitionAdapter on that virtual machine. This command accepts a plethora of options, which includes many things listed from the Get-VMPartitionableGpu above. However, we will skip those options and stick with the default settings.

Set-VMGpuPartitionAdapter -VMName $vmname

Now, let’s start the VM. And here we go! We got this:

Neat! Now GPU is showing up with the same name as the host’s GPU. However, the driver being used is vrd.sys and there is error code 43 as well. GPU acceleration still does not work obviously. Let’s go back to Windows Sandbox and see what it is doing there.

The Windows Sandbox has the same behavior as our VM! The GPU shows up as Intel HD Graphics and is using vrd.sys as well. However, GPU acceleration is working fine here. What gives? Let’s continue to dxdiag inside Windows Sandbox.

Here, we can see that we got a render-only device. Both name and Driver Model (WDDM version) correspond to host drivers. However, other elements do not seem to match up. Perhaps vrd.sys might internally load Intel’s driver somewhere? One thing for sure is that Windows Sandbox mounts certain components from the host Windows operating system, so the host’s drivers might be mounted somewhere as well. In the host’s dxdiag, one of the driver file listed is igdumdim64.dll.

Lo and behold, searching for this file in C:Windows folder results in a new discovery! There is a folder in Windows Sandbox called C:WindowsSystem32HostDriverStore, where the host’s C:WindowsSystem32DriverStore of hosts get mounted here. This folder is not available in either host or our custom Windows 10 VM. So, let’s copy the driver inside host’s DriverStore that corresponds to the Intel HD Graphics (this information could be found in either dxdiag or Windows Device Manager by opening “Driver Details”).

After copying the files, starting the virtual machine resulted in the virtual machine stuck at the Hyper-V boot logo for a few seconds until finally, we got to the login screen and … no GPU acceleration😢. Opening the device manager still shows error 43. Time to give up? Not yet! Perhaps the partitioned GPU is lacking a memory-mapped IO (MMIO) virtual address space?

Hyper-V supports another kind of GPU for the virtual machines, which is Discrete Device Assignment (DDA). DDA fully dedicates a GPU to a guest virtual machine. This blog post explains how to enlarge the MMIO space for both under 4 GB mark and above it for use with DDA. The post also suggests that “write-combining” be enabled. So let’s follow the post’s suggestions:

Set-VM -VMName $vmname -GuestControlledCacheTypes $true -LowMemoryMappedIoSpace 3072MB -HighMemoryMappedIoSpace 30720MB

And here we go! GPU acceleration works the same way as it is in Windows Sandbox! Now time to do some benchmarks!

Benchmarking

Let’s start with the AIDA64’s compute benchmark. This benchmark performs various relatively simple tasks using OpenCL API. The first image (the one that says “HD Graphics NEO”) is the result from the guest, and the other is from the host. The results are pretty good! Well within the margin of error of the host’s GPU performance!

Now for the Unigine Heaven benchmark, set at 800×600 windowed, high quality, moderate tessellation, and with DirectX 11 API.

The guest yielded an average FPS of 24.5 and a score of 617, whereas the host yielded an average FPS of 41.6 and a score of 1047. A pretty significant amount of performance loss this time, but anyways, nothing else even came close in the performance and API parity in GPU virtualization!

Now the only thing remaining is the ability to select which GPU should be used for the virtual machine. Unfortunately, I could not figure it out yet. The GPU-PV related commands shown at the beginning of this post does not seem to indicate that we can choose GPUs manually, without disabling the GPUs that we don’t need. Please comment if you know the way!

System Requirements

Since there is no official documentation regarding this feature, I don’t know the exact system requirements. However, after several testing with several computer systems, I can summarize the system requirements as follows:

• Windows 10 version 1903 or newer for both host and guest I also tested GPU-PV on Windows 10 version 1809 as well. It kind of works but after booting the guest, the guest stuck.
• GPU driver with WDDM 2.5 or higher It doesn’t matter if the driver is DCH or not. GPU drivers supporting WDDM 2.4 or lower are just outright not listed on Get-VMPartitionableGpu. Tip: you can check the WDDM version easily by looking at the first number of the driver version stated in the INF file (this version number could be different from the “marketed” version number, especially on NVIDIA GPUs). Typically, but not always all big three GPU vendors made this number correspond to the WDDM version is supported. For instance, number 27 corresponds to WDDM 2.7 support.
• GPU must drive the display directly I only tested this on NVIDIA GPUs with Optimus configuration, but this limitation might apply to other “headless” GPUs as well. Such GPUs simply don’t work (guest’s graphics got stuck on boot). See the next section for more details.

Partitioning a Render Only GPU

Render only GPU drivers do not have display outputs attached to them. This is commonly the case with “compute-only” GPUs, such as NVIDIA Tesla and AMD Radeon Instinct. However, these GPUs are also common on laptops with NVIDIA Optimus configuration, where the NVIDIA is the render only device. Testing GPU-PV on such GPUs (all tested are NVIDIA Optimus GPUs) on the released version of Windows 10 (version 2004 as of this writing) resulted in guest’s graphics stuck. Guest’s CPU still responds normally, and the guest responds to remote desktop requests as well (remote desktop has to have graphics acceleration disabled). Connecting to a remote desktop with graphics acceleration doesn’t work, and neither does attaching an indirect display (IddCx) to the partitioned GPU. Windows Sandbox on Windows 10 version 2004 also crashes when used with such GPUs.

However, in the latest version of Windows 10 “Iron” insider preview (build 20197 as of this writing), GPU-PV on such GPUs works. The only caveat is that the display output cannot be seen from the built-in Hyper-V video driver: we have to use either a graphic accelerated RDP (which is always the case when we use the Hyper-V’s enhanced session mode) or IddCx drivers. More things regarding IddCx will warrant a separate post :), however, my favorite IddCx driver right now is SpaceDesk, which will stream whatever displayed on the driver over IP.

In fact, the guest performs better than the host in this case! Guest scored 2424 at 96.2 average FPS, whereas host only scored at 2246 at 89.2 average FPS. This disparity might come down to the Intel’s SpeedShift on the i7 7700HQ mispredicted the workload and throttles it up and down occasionally. Locking host’s CPU to base clock should improve host’s performance, but not guest’s, as the CPU was pretty busy as well in guest workloads: it has to encode the stream from IddCx display, trasmit the data over local TCP/IP (which has their own overheads), and decode it back. The system used is my personal laptop, which is also used to take the above screenshot.

TL; DR;

To enable GPU virtualization (GPU-PV) on arbitrary Hyper-V Windows 10 virtual machines, do the following:

1. Ensure that both the host and the guest meet the system requirements, and use the generation 2 virtual machines.
2. The following commands are to be done in PowerShell. Check that GPU-PV is available by executing the Get-VMPartitionableGpu. If more than one GPUs are available, the first one listed will be used. Currently, the only way to “select” GPU in use is by disabling other GPUs until the wanted GPU resides at the top of the output of the said command.
3. Copy the appropriate GPU driver from host to guest. Copying has to be done manually. Installing the GPU driver from an installation package will not work.
   1. From the host, find out the correct driver package path. Open Windows Device Manager, open the GPU to be used for GPU-PV, go to the “Driver” tab, click “Driver Details”, and scroll down until you find a file with the following pattern: (filename.inf)_amd64_(random_hex_number)(somefiles.dll).
   2. On host, go to C:WindowsSystem32DriverStoreFileRepository. There should be a folder with the same name as above.
   3. Copy that folder to guest under C:WindowsSystem32HostDriverStoreFileRepository. If the folder is not there, create it.
4. Enable write-combining and enlarge MMIO address spaces on the guest (see here for details). The following example sets the 32-bit MMIO to 3 GB and above 32-bit MMIO to 30 GB.

   Set-VM -VMName $vmname -GuestControlledCacheTypes $true -LowMemoryMappedIoSpace 3072MB -HighMemoryMappedIoSpace 30720MB
   

5. Mark the virtual machine to use GPU-PV.

   Set-VMGpuPartitionAdapter -VMName $vmname
   

6. If everything works, the virtual machine should start with GPU acceleration. Enjoy! However, if it does not work, it is likely that you are partitioning a render only GPU. GPU-PV on such GPUs seems broken under Windows 10 version 2004 but seems to be fixed as well for the next version of Windows 10. See this section for details.

Hi Anthony, i got the same problem… AMD says you need to have a host driver…which they dont provide. They only provide guest driver. For your scenario they want us to buy (expensive + overpowered for our purpose) a

Radeon Instinct GPU….which is only provided by big server

This link https://www.amd.com/de/graphics/workstation-virtual-graphics 

is also stating that pro is for virtualization.

However i dont know why they advertising with this bull**** if its not working and i have not seen a single post where it worked….

Regarding your issue: you habe to create/edit 2 registry inputs.

Registry key path (create it if not present): HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsHyperV

Registry values:
RequireSecureDeviceAssignment = 0 (REG_DWORD)
RequireSupportedDeviceAssignment = 0 (REG_DWORD)

After this VM will start and you can install the Radeon software. You will even see your GPU.

But after installing you will get error 43….

And thats it … I contacted Amd support and their answer was simple: we dont have host driver…only guest driver.

if the AMD Gurus in this forum know how to get this done I will send money