Remkomplekty.ru

IT Новости из мира ПК
4 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Hyper v проброс видеокарты

Enabling Physical GPUs in Hyper-V

In recent months, I have been noticing two Hyper-V trends that seem to be completely at odds with one another. On one hand, I have been noticing a lot of people transitioning away from virtual servers that are set up to use the full blown desktop experience, and making the move to Server Core deployments instead. This transition makes a lot of sense, because it helps admins to utilize hardware resources as efficiently as possible. My guess is that over the next year, this trend will go even further and we will see a lot of workloads migrated to Nano Servers or even to containers.

The other trend, which is completely at odds with the first trend, is that I have also been seeing organizations virtualizing workloads that are increasingly graphically intensive.

Hyper-V’s default configuration really isn’t well suited to running graphically intensive workloads. However, it is possible to configure Hyper-V to leverage a server’s physical GPUs. That way, graphical rendering can be offloaded to dedicated video hardware.

Before You Begin

Before I show you how to configure Hyper-V to use GPU acceleration, there are a few gotchas that I need to warn you about. First, GPU acceleration is based on RemoteFX, which is part of the Remote Desktop Service. Microsoft requires organizations using the Remote Desktop Services to deploy an RDS licensing server, and to purchase the required number of Client Access Licenses. You can operate without a licensing server for a while, but the Hyper-V host will display this warning:

The next thing that you need to be aware of is the fact that not every Hyper-V virtual machine can take advantage of GPU acceleration. Obviously, guest operating system support is required, but there is more to it than that. When you create a virtual machine in Hyper-V, you are asked whether you would like to create a Generation 1 virtual machine or a Generation 2 virtual machine. Generation 2 virtual machines do not include an option to add a RemoteFX 3D Video Adapter. The option exists only for Generation 1 virtual machines.

Another consideration is live migration and failover clustering. If a virtual machine is configured to use GPU acceleration, then any Hyper-V host that could potentially host the VM must be equipped with similar video hardware. Furthermore, hosts must have a sufficient number of GPUs available to accommodate any inbound virtual machines.

Finally, some documentation indicates that once a Hyper-V virtual machine has been configured to use RemoteFX, then the VM becomes accessible only through an RDP session, and not through the Hyper-V Manager console. This limitation might have existed at one time, but does not appear to be an issue today. The figure below shows a Windows Server 2016 (preview 5) VM running on a Windows Server 2012 R2 Hyper-V host. As you can see in the figure, the VM is configured to use the RemoteFX graphics device, and yet I am able to view it through the Hyper-V Manager’s console.

Configuring Hyper-V

You can access the Physical GPU settings by opening the Hyper-V Manager, right clicking on the Hyper-V host server, and choosing the Hyper-V Settings command from the shortcut menu. Upon doing so, you will be taken to the Hyper-V Settings dialog box for the selected host server. As you can see in the figure below, this dialog box contains a Physical GPU container that you can use to enable a physical GPU for use with Hyper-V. As you look at this dialog box however, you will notice that its configuration options are greyed out.

The first step in providing Hyper-V with GPU support is to check your video hardware configuration. In Windows Server 2012 R2, you can do this by right clicking on the Start button, and selecting the System option from the shortcut menu. When the System dialog box appears, click on the Device Manager link and expand the Display Adapters node. As you can see in the figure below, this server is configured to use the Microsoft Basic Display Adapter. This configuration is fairly common for server hardware, but does not provide good GPU support.

In this type of situation, it is necessary to determine the actual video hardware that is installed in your Hyper-V host server, make sure that the video adapter is equipped with a suitable GPU, and download a new driver if necessary. If you look at the figure below for example, you can see that after installing the correct driver, Windows went from identifying the driver as a generic Microsoft Basic Display Adapter, to correctly identifying the adapter as a NVIDIA GeForce GTX 750.

If I open the Hyper-V Manager, Hyper-V still does not make the GPU available for use. If you look at the summary information in the dialog box below however, you will notice that the Remote Desktop Virtualization Host role service must be installed.

You can install this role service by using PowerShell if you like, but if you prefer to use the GUI then it is easy enough to install the role service by using the Server Manager. To do so, open Server Manager, and select the Add Roles and Features option from the Manage menu. This will cause Windows to launch the Add Roles and Features Wizard.

Click Next to skip the wizard’s Before You Begin screen. You will now be taken to the Installation Type screen. Select the Role-Based or Feature-Based Installation option and click Next.

You will now be prompted to choose the server on which you wish to install the role. Choose the Select a Server from the Server Pool option. Make sure that the correct server is selected, and click Next.

You should now see the Select Server Roles screen. Select the Remote Desktop Services role, and click Next. Click Next again to bypass the Features screen, and once again to bypass the Remote Desktop Services introduction.

The next screen that you will see asks you to select the role services that you wish to install. Select the Remote Desktop Virtualization Host checkbox, as shown below. If prompted to install the Media Foundation and the Remote Server Administration Tools, be sure to click the Add Features button.

Click Next, followed by Install, and the required role services will be installed onto the server. When the process completes, click Close. You will need to reboot the server in order to finish the installation.

After the machine reboots, you can go back into the Hyper-V Manager, right click on the host server, and choose the Hyper-V Settings command from the shortcut menu. When the Hyper-V Settings dialog box appears, select the Physical GPUs container. This time, you should see the GPU listed, as shown in the figure below.

Now, click OK, and then right click on the virtual machine for which you want to enable GPU acceleration, and choose the Settings command from the shortcut menu. When Windows opens the Settings dialog box, select the Add Hardware container, select RemoteFX 3D Video Adapter as shown below, and click Add.

Читать еще:  Флешка не видит файлы что делать

You will also need to set the number of monitors that will be supported by the VM and the maximum display resolution, as shown below.

As you can see, it is relatively easy to add GPU acceleration to a virtual machine. It is worth noting however, that RemoteFX acceleration incurs licensing costs and does not work for every virtual machine.

Использование видеокарты в виртуальных машинах

Доброго дня, господа. Интересует небольшой вопрос. Необходимо собрать тестовый стенд в котором будут участвовать 4 ПК (на них запускаются видеоролики, презенташки, ресурсоемкое ПО). Компы подключаются по видеовыходам к видеокоммутатору, который управляется отдельно,и после сигнал из коммутатора передается на 4 монитора. Думаю в теории вместо кучи техники использовать один хороший ПК, на котором в виртуалках будут крутиться видеоролики, ПО и пр. и 4 видеовыхода идти на видеокоммутатор. В качестве среды виртуализации рассматриваю VMWare, ESXI, Hyper-V И на конец сам вопрос: существует ли возможность к виртуальной машине привязывать определенный порт видеовыхода? На сколько хорошо ВМ сможет реализовать потенциал видеокарты при запуске 3D приложений (достаточно ресурсоемких)? Буду рад услышать какие-то другие интересные предложения по оборудованию. Большое спасибо!

я такое делал без всяких пробросов — берется мощный комп с 4 видео портами для 4 мониторов, на нем поднимается KVM с 4 машинами (или одна машина с 4 виртуальными мониторами), открываются 4 консоли спайс, и каждая консоль утаскивается на отдельный монитор. Спайс прекрасно справляется с видеопотоком, HD фильмы показывает без проблем. Если не нужен 3д, ничего другого и не надо

погугли про xdmx.

Проблема в том, что есть пара приложений написанных на Unity. И аппаратное ускорение от видеокарты необходимо. KVM я так полагаю не может этого дать? Или я прочитал не правильно?=)

Тут тоже есть некоторые трудности. Приложения, написанные на Unity написаны для Windows. Потому в идеале нужно гибридное решение или решение на WIndows

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

Насколько ресурсоемкое и какой у тебя бюджет? Тут все упирается в процессор так как после определенной планки производительности тебе никакого дешевого проца не хватит на твои виртуалки и дешевле будет собрать несколько отдельных машин.

Скажем для тяжелых игр какой-нибудь i7 может потянуть 2 виртуалки, для простых типа доты 3-4 без особых проблем. Но если у тебя там какой-нибудь CAD или прочая жесть которая насилует проц то все упрется в него.

В качестве среды виртуализации рассматриваю VMWare, ESXI, Hyper-V

Учитывай, что если у тебя не линуксовая виртуализация то тебе придется: 1) Покупать карточки AMD. 2) Или платить за Nvidia Quadro а они очень дорогие. Драйвера для не-Quadro нвидий в виртуалках названных выше просто не заработают так как они вырубаются если видят виртуализацию. Обойти это можно только если использовать Linux / KVM (или Xen) / QEMU.

И на конец сам вопрос: существует ли возможность к виртуальной машине привязывать определенный порт видеовыхода?

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

Если не пробрасывать а просто использовать виртуальную видеокарту, то в VMWare в принципе есть более-менее рабочая реализация DirectX10 / OpenGL 3 которая даст тебе 15-50% (смотря че за софт) производительности и может даже это прокатит. Тогда мониторы останутся на хосте и ты сможешь из разрулить как хочешь.

по поводу проца — все упирается еще и в ядра. Виртуалку через qemu можно запускать через конструкцию вида

Виртуалку через qemu можно запускать через конструкцию вида

А ещё можно заюзать libvirt и не делать это ручками. В зависимости от потребностей можно vcpu, io и эмуляция повесить на разные ядра.

Но вообще речь о том, что если приложения очень тяжелые даже самый топовый интеловский четырехядерник тупо не потянет больше 2-3 виртуалок, а всякие там E или Xeon стоить будут дороже, чем несколько машин на обычном железе.

  • «один хороший ПК» с 4 PCIe слотами, идеально было бы x2 CPU Xeon конфирурация
  • Интегрированное в процессор видео для хоста + 4 PCIe видеокарты начального/среднего уровня для гостей
  • Linux + kvm + qemu + vfio + ovfm + win8.1
  • .
  • PROFIT

libvirt — создание замечательное, но вот только в арче он с сетью не дружит, что мне и помешало с ним подружиться в первый раз.К тому же конструкция в qemu простая, и это явно проще, чем с нуля в либвирт вникать, да вручную править xml`ки (я поленился осиливать, то, как туда прописывать проброшенную видяшку с кучей параметров, мне было проще скриптом, благо маны у qemu в разы лучше организованы, имхо). Недопиленный гуй — этот либвирт. В случае проблем ты лезешь и в маны по virsh’у, и в маны по гипервизору.. Так что удобно только когда нужно — все гипервизоры под одной рукой, но с другой — вряд ли автору понадобится на 3 разных гипервизорах запускать что либо.

К тому же конструкция в qemu простая, и это явно проще, чем с нуля в либвирт вникать

Зато поверх libvirt есть более одной оболочки и они сразу генерят правильные конфиги для виртуалок. С просто QEMU любой ленящийся читать маны человек скорее всего где-нибудь накосячит и это ему посадит производительность.

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

Проброс видюхи в ESXi

Мучился-мучился, но в итоге победил гипервизор ESXi и, что важнее, драйвера под убунту, которые категорически отказывали ставиться и вываливали всё новые и новые ошибки в процессе.

Написал большое пошаговое руководство, которые пригодится тем, кто тоже решит углубиться в эту тему и заюзать убунту-подобную ОС и организовать в неё проброс видеокарты: https://vk.com/@lord.alfred-nvidia-passthrough-to-ubuntu-in-vmware-esxi

Не сочтите за срам, решил оставить это тут, т.к. первоначально наткнулся на ваш топик и тут так и не было решения — а в гугле по релевантному запросу он висит очень высоко) Пускай люди из 2018 (или может даже 2019) найдут мой комментарий и не будут мучаться в процессе установки.

Hyper v проброс видеокарты

  • Материнская плата Gigabyte GA-Q67M-D2H-B3
    Прошивка BIOS — F5
    Setup: CPU->Intel Virtualization Technology=ON
    Setup: Chipset->North Bridge->VT-d=ON
  • Процессор Intel Core i5 2500 3.3 GHz
  • Память 16 GB
  • ATI Radeon HD 3470 в первом слоте PCIe, используется гипервизором
  • ATI Radeon HD 3450 во втором слоте PCIe, отдается гостевой ОС
  • Сетевой адаптер Intel в слоте PCI
  • XCP (Xen Cloud Platform) 1.0 (XenServer build 42052c)
  • Citrix XenCenter для управления
  • Windows 7 64 bit в качестве гостевой ОС, ATI Catalyst 12.1

Поначалу я долго экспериментировал с VMware vSphere 5.0. Собственно, аппаратная конфигурация подбиралась именно под нее. По дороге открылся ряд интересных подробностей: например, VT-d должен поддерживаться и процессором (пишут, что процессоры с индексом K не годятся), и чипсетом и материнской платой. С видеокартами вообще беда: известно, что с большинством этот фокус не проходит, с некоторыми (довольно короткий список) у одних получается, у других нет. Долгое и содержательное (хотя не слишком радостное) обсуждение было тут:
VMware Communities: VMDirectPath and ATI Radeon. Radeon 3450 ходил, пожалуй, в фаворитах как одна из самых пробрасываемых карт.
Я перебрал приличное количество разнообразных комбинаций железа. В конкурсе участвовали две материнские платы, три видеокарты плюс интегрированное видео SandyBridge (IGD), три сетевых адаптера и один процессор. Несколько раз я бросал эти бесплодные попытки на неделю-другую, потом придумывались какие-то варианты. По дороге был один момент, когда почти получилось: виртуалка правильно определила монитор, но дальше дело не пошло. Уперся в то, что карта вроде бы нормально пробрасывалась в виртуалку, и в девайс менеджере показывалась ровно, но Каталист упорно отказывался иметь с ней дело. Карта как живая, но не работает.

Читать еще:  Восстановление данных с флешки софт

Можно было попробовать много чего еще: Windows XP и Linux в качестве гостевых систем (ставил Windows 7 в 32 и 64-разрядном исполнении), добыть очередную видеокарту… В конце концов плюнул и решил зайти с другого конца, попробовав другой гипервизор. Не мудрствуя, взял то, что на виду: Xen в составе Xen Cloud Platform(XCP).
XCP поставился без сучка без задоринки.

На некоторое время поставил в тупик вопрос: как этой системой рулить? В смысле, должна же быть какая-нибудь консоль управления, желательно под винды? Поковырявшись полдня с условно-штатным OpenXenManager я пришел к мысли, что то ли лыжи не едут, то ли эта кроссплатформенная тулза на винде не живет. Один или два раза она сконнектилась с сервером, но померла где-то в процессе работы, остальные разы глухо висла при коннекте, сливая неудежимый поток исключений в консоль Питона.
К счастью, более широкий взгляд в окружающий интернет открыл мне, что Citrix XenCenterпрекрасно может рулить opensource-ным Xen-ом, а сам вполне бесплатен. Правда, при коннекте кричит, что через N дней у вашего сервера истечет Evaluation period, но знающие люди пишут, что это он просто не в курсе насчет opensource редакции сервера, а на самом деле все будет работать.
XenCenter позволяет создавать-включать-гасить виртуалки, а проброс устройств надо настраивать из sysadmin-friendly интерфейса командной строки.

Против ожиданий, проблем тут не случилось. Сделал все по мануалу, и хватило его одного.

NVIDIA GRID K1 и K2 — в основе готового решения VDI

Вот народ жалуется, что по Xen-у документации мало. Так другой раз и хорошо, что мало, если этого хватает. Сколько я по vSphere прочел, и все без толку… Впрочем, не хочу говорить дурных слов про vSphere. Под ней зато так железо настроилось, что Xen пролетел прямо со свистом.
Итак, с помощью XenCenter я организовал виртуалку о двух ядрах и 4 ГБ памяти, накатил туда седьмую 64-битную винду и пошел пробрасывать.

В соответстви с руководством правим , вставляя строку после каждого вхождения
Выполняем .
Шаги, связанные с модулем , пропускаем — пишут, что в шестерке он уже вкомпилирован в ядро.
Делаем xe vm-list и находим uuid нашей виртуалки, у меня
Выполняем команду и находим в выводе нашу карту, например 02:00.0 VGA compatible …, 02:00.1 Audio… (двойка удивительным образом соответствует номеру слота, куда воткнута карта).
Записываем однострочный скрипт вида

У меня на карте, помимо видеоадаптера, еще звук — поэтому, помня грабли, на которые наступал в vSphere, добавляю оба устройства: 0/0000:02:00.0, 0/0000:02:00.1.
Выполняем скрипт.

Для контроля — действительно
Останавливаем и снова запускаем виртуалку (пишут, что именно так, а не ребутом — не стану проверять лишний раз).
При первой попытке карта у меня в первом слоте PCIe (01:00.0, 01:00.1) и по умолчанию используется гипервизором. После перезапуска виртуалки монитор гаснет.
В XenCenter (с ноутбука) заходим в консоль виртуалки и после логина в винду видим, что она просит ребута. Признак того, что она нашла новое устройство. Не будем ей отказывать. Ребут. Действительно, в Device Manager появился новый видеоадаптер Radeon 3450 с драйвером Microsoft WDDM 1.1. Из предыдущего опыта известно, что драйвер нужен родной. Качаю и ставлю свежий ATI Catalist 12.1, тот после установки, как обычно просит ребута. Ребут… опаньки. Первая попытка накрывается медным тазом: падает гипервизор. Да… vSphere в такой ситуации одерживала убедительную победу над виртуалкой, устраивая ей BSOD.
Перепускаем хост и, по рекомендации лучших собаководов, смотрим, что пишет нам команда
. Пишет она, помимо прочего, такое:

Похоже, что передача карты на горячую нам не светит. Ладно. Дадим гипервизору свой VGA адаптер, благо видеокарт мне теперь хватает. Переставляем Radeon 3450 во второй слот, в первый ставим валяющийся рядом 3470. К каждой карте прицепляем по монитору. Включаем хост, запускаем виртуалку. Винда просит перезагрузки после изменения конфигурации. Ребут. Логинимся…

В консоли XenCenter заставка зависает, и я не сразу соображаю, что правый монитор светится синим


Оно все-таки произошло.
Итого, на Xen срослось за 3 дня (после того, как 3 месяца упражнялся на VMware).

Картинка на мониторе самая обыкновенная, без особенностей. Разрешение 1920х120 держит. Не тупит (хотя тестов не гонял). Видео с YouTube проигрывается нормально.

На этой радостной ноте завершу свой правдивый отчет, а сам займусь пробросом клавиатуры, мыши и прочей периферии.

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; если драйвер определяет, что операционная система работает внутри ВМ, то адаптер перестает работать.

Драйвер можно обмануть, добавив расширенную настройку в конфигурацию ВМ.
hypervisor.cpuid.v0 = «FALSE»

В этом случае графический адаптер сможет работать внутри ВМ. Однако, в связке с 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.

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

Бывает такой момент, что без Windows никак не обойтись, и даже wine не помогает, и тут к нам на помощь приходят виртуальный машины. Под Linux их хватает, VirtualBox, VMWare, XEN(гипервизор, но все же), qemu с kvm. Иногда нам необходима полноценная 3D графика, на виртуалке, и тут нам поможет проброс(passthrough) видеокарты в виртуалку.

В интернете полно статей, что да как делать, но интернет у нас большой и от еще одной статейки он не лопнет.
Для начала нам необходимо, что бы в компьютере было 2 видеокарты, например встроенная и дискретная. У меня основная видеокарта Geforce GXT 550ti, а прокидывал я GTX 650ti и Ati HD4850 и все успешно работало.
Существует 2 вида проброса, использовать OVMF, данный проект позволяет использовать UEFI в виртуалке, но и видеокарта должна быть не простая, а аж с двумя биосами, это можно выяснить следующим образом [ http://vfio.blogspot.ru/2014/08/does-my-graphics-card-rom-support-efi.html ].
Скачиваем, компилируем
Получаем BIOS видекарты
0000:01:00.0 — надо изменить на код вашего девайса.

Проверяем BIOS ./rom-parser image.rom
Если вы видите подобное PCIR: type 3(EFI ROM), то ваша видеокарта поддерживает OVMF.
Ваш конфиг виртуалки будет немножко отличаться.

Я поэкспериментировал с ядрами, ни к чему интересному и хорошему это не привело, писали [https://bbs.archlinux.org/viewtopic.php?id=203240] что в ядре 4.2.2-1 поломали проброс, но как оказалось все прекрасно работает.
Но если же у вас все же есть желание, то устанавливайте из AUR’a:
1. [ https://aur.archlinux.org/packages/linux-vfio/ ] — на данный момент типа багнутое ядро, где сломан проброс, но используются полезные патчи для видюх интел и еще что-то там
2. [ https://aur.archlinux.org/packages/linux-vfio-lts/ ] — рабочее ядро, с теми же патчами, что и выше.
Как пользоваться makepkg, разберетесь сами.

1. Устанавливаем необходимый софт pacman -S qemu libvirt synergy
2. Нужно подкорректировать загрузку ядра, что бы не подцеплялась, наша видеокарта которую мы будем прокидывать. Нужно узнать id вендора и кода нашей видеокарты. Для этого выводим lspci Находим там код видеокарты, запоминаем его, и вводим уже lspci -n Теперь правим параметры загрузки grub, для этого открываем /etc/default/grub
и добавляем параметр в GRUB_CMDLINE_LINUX_DEFAULT vfio-pci.ids=10de:11c6,10de:0e0b
У меня следующего вида
Применяем параметры grub-mkconfig -o /boot/grub/grub.cfg , после перезагрузки, должно быть нечто подобное dmesg | grep vfio_pci :
Подкорректируем /etc/mkinitcpio.conf:
Применим mkinitcpio -p linux (linux изменить на имя вашего ядра)

3. Настраиваем и создаем виртуалку.
Подправим конфиг qemu
/etc/libvirt/qemu.conf:
В принципе действия для того что бы использовать ovmf те же, так вот если вам повезло и у вас видеокарта поддерживает EFI, то следующий конфиг для вас:
pacman -S ovmf Если же нет, используем Seabios
windows.img — образ жесткого диска, создается командой dd if=/dev/zero of=windows.img bs=1M seek=60000 count=0 seek=60000 размер диска в мегабайтах.
virtio-win.iso — образ с драйверами, берется последующей ссылки [ https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.iso ]
windows.iso — образ диска с Windows, сами разберетесь где его брать, если используете ovmf убедитесь, что образ поддерживает загрузку UEFI. и при загрузке системы скорее всего надо будет ввести команду следующего вида: PS0:/EFI/BOOT/bootx64.efi
Данные конфиги для начальной установки Windows и все должно пройти на отлично.

3. После окончания установки, настало время прокинуть видеокарту.
Раскоментируем строку в конфиге
и запустим виртуалку.

Если все прошло хорошо, должно определиться новое устройство, скачиваем и устанавливаем драйвера для видеокарты, я не ставил никакого лишнего софта, только драйвера, пишут что Catalyst control center да и nvidia experience загоняет в синий экран, не проверял.

Нужно не забыть установить synergy, без этой программы управление(мышкой и клавиатурой) виртуалкой будет невозможно.
Найдете ее на торрентах или прочих сайтах, там в настройках надо указать client: 10.0.2.2(дефолтный ip хоста) и имя экрана, допустим Windows. Теперь настроим synergy на хосте(компьютер с Linux), создадим конфиг следующего содержания:
synergy.conf
Windows и Linux это имена экранов, измените на ваши
Запустим synergy synergys —config synergy.conf —debug INFO , и при передвижение мышки за левую часть экрана, она должна переходить на виртуалку.
Если все получилось, выключаем виртуальную машину, в конфиге меняем строку -vga std на -vga none , подключаем к выходу проброшенной видеокарты кабель к монитору, запускаем виртуалку и у нас на экране должна появится картинка с процессом загрузки. Проверяем функциональность synergy, кнопка F12 блокирует курсор на текущем экране.

4. Прокидываем звук, если вы используете pulseaudio просто укажите перед запуском quemu QEMU_AUDIO_DRV=pa если же ALSA, то предлагаю вам использовать утилиту apulse, она есть в AUR [ https://aur.archlinux.org/packages/apulse/ ] и запуск виртуалки будет следующим QEMU_AUDIO_DRV=pa apulse qemu-system-x86_64. 5. У меня 2 монитора, и при запуске виртуалки на главный монитор(центральный) через vga идет картинка с Windows. а правый становится главным Linux’овым монитором.
К основной видеокарте правый монитор подключен через DVI, центральный монитор подключен к «виртуальной» видюхе через VGA, а к основной через HDMI.
Команда xrandr —output DVI-I-1 —auto && xrandr —output HDMI-0 —off Ваши подключенные мониторы и возможные режимы работы можно посмотреть командой xrandr

Выклаываю полный скрипт запуска виртуалки
Так же рекомендую отключить запрос на восстановление системы при загрузке после сбоев
В данную тему я нырнул лишь ради интереса и возможности поиграть в ММО Black Desert, отлично кстати работает.

UPD 11.10.2016
Сегодня вновь столкнулся с пробросом видеокарты, но теперь мне нужен был еще и звук по hdmi, немного погуглив нашел решение http://vfio.blogspot.ru/2014/09/vfio-interrupts-and-how-to-coax-windows.html?m=1
Что бы нормально работал звук через HDMI проброшенный видюхи нужно включить Message Signaled Interrupts(MSI).
Для этого в реестре Windows необходимо внести правки, а именно в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnum найти вашу видеокарту, там будет два устройства видео и звук, далее в Device ParametersInterrupt Management создать(если его нет) раздел MessageSignaledInterruptProperties и в нем DWORD параметр MSISupported со значением 1, он включит MSI. После перезагрузки звук должен прекрасно заработать.

UPD 01.06.2019
Обновил компьютер до Ryzen и столкнулся с проблемой
Подробности здесь AMD Ryzen и проблемы с пробросом видеокарты в QEMU KVM

UPD 15.09.2019
После очередного обновления начались неприятности, qemu падал в core-dump при попытке издать малейший звук, решилась эта проблема добавлением строки
1000 — id вашего юзера, все переменные QEMU_AUDIO можно убрать.

Если будет писать что нет доступа

Можно скопировать пользовательские cookie в root
На 15.09 проблема с Ryzen еще присутствует, приходится патчить ядро.

Ссылка на основную публикацию
Adblock
detector