Expose iommu to the guest os что это
Как IOMMU работает для связи ЦП и периферийных устройств
Как периферийные устройства взаимодействуют с процессором? Использование ОЗУ системы в качестве общей точки для взаимной связи, но это подразумевает ряд механизмов, наиболее важным из которых является тот, который мы собираемся описать ниже.
Где находится IOMMU?
Как видно на схеме выше, периферийные устройства подключены к южному мосту или южному мосту, который, в свою очередь, подключен к северному мосту, который является концентратором, с которым, в основном, обмениваются данными интерфейс оперативной памяти и процессора. каждый. Что ж, IOMMU расположен внутри южного моста, где сосредоточены все интерфейсы ввода-вывода, такие как USB, PCI Express, SATA и т. Д.
Все эти интерфейсы должны находиться под управлением IOMMU для доступа к системной RAM. В этом случае IOMMU действует как своего рода пограничный контроль, который следит за тем, чтобы периферийные устройства не осуществляли незаконный доступ к памяти и не обращаются к той части ОЗУ, которая назначена каждому из них и никуда больше.
Таким образом, IOMMU действует как MMU, но для периферийных устройств ввода-вывода.
В чем его полезность?
Периферийные устройства ввода-вывода не используют MMU (блок управления памятью) совместно с ЦП и, следовательно, не просматривают память так же, как центральный системный процессор. Эта проблема позволяет периферийным устройствам получать доступ к чувствительным частям системной памяти, например тем, которые зарезервированы для функций самой операционной системы, что является проблемой в многозадачных средах.
С другой стороны, IOMMU автоматически и динамически назначает адреса памяти для связи с различными периферийными устройствами, таким образом, ЦП всегда знает, на какие адреса памяти он должен указывать для связи с ними.
В более старых системах IOMMU не было доступно, и вместе с ними была предоставлена карта памяти, где программисты были проинформированы, какие адреса RAM предназначены для связи с устройствами. По этой причине разработчикам в каждой отдельной архитектуре приходилось изучать адресацию памяти, чтобы использовать периферийные устройства и другое поддерживающее оборудование в системе.
Сегодня это уже не так, и наличие IOMMU позволяет разработчикам избавиться от необходимости изучать адреса памяти для связи и расширяет возможности конфигурации и настройки наших ПК, позволяя создавать совершенно разные конфигурации.
Использование IOMMU в виртуализированных системах
IOMMU обеспечивает безопасный доступ к физическим устройствам в виртуализированных средах посредством того, что мы называем сквозной передачей устройств. Тандем между MMU и IOMMU позволяет устройствам, подключенным к ПК, появляться в пространстве виртуальной памяти, которое выполняет функцию физической памяти для виртуальной среды, которая работает в данный момент.
Без IOMMU виртуализированные среды, которые имеют правильный доступ к оборудованию, установленному в системе, были бы невозможны, поэтому сегодня он является незаменимой частью всех процессоров, которым приходится обрабатывать виртуализированные среды.
Как из домашнего ПК средствами виртуализации сохранить игровую систему
Благодаря конкуренции и развитию НТП современные ПК позволяют выполнять множество простых и сложных задач одновременно, например играть и воспроизводить видео на ТВ, рендерить графику и читать новости в интернете, раздавая торренты параллельно, и т.д. и т.п. Многие идут дальше и используют несколько ПК для работы и развлечений. Однако при помощи технологий виртуализации можно с одной стороны расширить возможности своего ПК, а с другой сэкономить, т.к. по сути можно запустить несколько операционных систем на одном железе в одно и то же время.
Введение
Виртуализа́ция — предоставление набора вычислительных ресурсов или их логического объединения, абстрагированное от аппаратной реализации, и обеспечивающее при этом логическую изоляцию друг от друга вычислительных процессов, выполняемых на одном физическом ресурсе.
Достигается как при помощи приложений (например VirtualBox, VMware) так и на уровне систем, поддерживающих аппаратную виртуализацию (например KVM, ESXi, Hyper-V). В последнем случае потери производительности по сравнению с нативными системами минимальна.
Здесь и далее в статье будет описание настроек системы виртуализации с открытым исходным кодом Proxmox потому что она в меру дружелюбна, есть легкий доступ к консоли через веб форму, а так же базируется на связке Debian + kvm, по которым очень много гайдов и описаний в сети, т.е. документации в т.ч. и на русском языке.
Требования к железу
— процессор и материнская плата с поддержкой VT-x, VT-d от Интел или AMD-Vi, IOMMU от АМД. Не поленитесь и уточните поддерживает ли именно Ваш экземпляр данные требования.
Что касается материнских плат. Категорически не рекомендую гнать железо при посредственной разводке на плате питания. По Z270 и Z390 игнорировать оранжевую зону или оставлять работать в стоке.
Установка и настройки
Мною было использована следующая игровая конфигурация:
— ПК для хоста конфиг был собран на далеко не лучшей материнской плате, но на англоязычных форумах очень часто хвалят эту фирму за то, что ее железо чаще всего подходит для таких вещей:
Процессор — i7 8700k
Мать — ASRock Z390M Pro4
Видеокарта — INNO3D GeForce GTX 1070 iChill X4
— второй ПК (Мини-ПК Morefine-M1s),
— 2 мыши,
— 1 клавиатуру на хосте, на остальных устройствах использовал софтварную,
— 3 подключения к монитору Dell U2713HM (VGA — для интегрированной видеокарты, HDMI — для GTX1070, на DVI находится Мини-ПК. Переключения между видеосигналами осуществлял через меню монитора)
0й этап — На материнской плате включаем VT-d:Enable, Intel Vitrualization Technology:Enable, Primary Graphx adapter:VGA, Above 4G Decoding:Enable. Если есть возможность обязательно выбираем основным графическим адаптером тот, на котором будет работать хост, т.е. более слабую видеокарту и переключаемся на нее.
1й этап — Устанавливаем Proxmox на хост. Для этого:
1.1. Скачиваем образ диска с официального сайта
1.2. Пишем образ на флешку при помощи специальных программ
1.3. Загружаемся с флешки, и производим инсталляцию с указанием на какой жесткий диск ставить, вводим пароль для будущего пользователя root, а так же настройки сети прописываем явно.
2й этап — Подключаемся по сети через веб интерфейс при помощи второго ПК или
планшета (в моем случае это был Мини-ПК) к хосту и настраиваем Proxmox по этому гайду через текстовую консоль.
Есть маленький нюанс, который возможно обходится программно, но я решил что поменять предыдущую материнскую плату будет проще, т.к. плата от Gigabyte этому требованию не соответствовала:
1) Run the «dmesg | grep ecap» command.
2) On the IOMMU lines, the hexadecimal value after «ecap» indicates whether interrupt remapping is supported. If the last character of this value is an 8, 9, a, b, c, d, e, or an f, interrupt remapping is supported. For example, «ecap 1000» indicates there is no interrupt remapping support. «ecap 10207f» indicates interrupt remapping support, as the last character is an «f».
Interrupt remapping will only be enabled if every IOMMU supports it.
Если условие выполняется — продолжаем.
Открываем файл командой из консоли (символ двойной решетки вводить не надо, так я буду разделять в тексте команды от того что необходимо внести в файл)
для процессоров Интел
для процессоров АМД
следом даем команду
после чего перезагружаем хост через веб интерфейс
Добавляем в файл конфигурации загрузку необходимых драйверов
Прописываем в консоли
На экран будет выведен список устройств доступных для проброса, находим интересующий нас блок с видеокартой, в моем случае это 2 устройства в группе видеокарта и звук по адрсам 01:00.0 и 01:00.1, поэтому я прописываю сразу группу.
Прописываем в консоли команду для того что бы определить модель и ее id
Теперь правим файл под нашу видеокарту (в Вашем случае id будут иные)
Заносим в черный лист драйвера
Теперь создаем через веб интерфейс и правим через консоль файл настроек виртуальной машины. Здесь строка «args:» решает, т.к. без нее драйвер видеокарты обнаружит виртуализацию, но путем подмены наименования оборудования, точнее hv_vendor_id=willitwork, мы снимаем проблему с ошибкой 43, которую может выдать видеодрайвер устройства. Здесь есть номер виртуальной машины в proxmox используемый в качестве имени.
Теперь перезагружаем хост и запускаем виртуальную машину.
3й этап — Через Удаленную видеоконсоль установим Windows и драйвера. В моем случае Windows распознал сперва видео драйвер proxmox для работы через видеоконсоль, потом нашел драйвер для GTX1070, а после обновления через интернет (принудительный поиск драйверов в сети) скачал и установил нужный мне драйвер для игровой видеокарты.
4й этап — Перезапустим Виртуальную машину, переключаем отображение видеопотока на мониторе на разъем видеокарты и… в моем случае все заработало сразу, никаких ошибок 43… При этом рабочий стол определяется как №2.
я попробовал запустить видео Blue-ray — без проблем, задержек и фризов с видеорядом нет, запустил Warhammer online — он завелся и в PvP играть было комфортно, запустил GTA5 у мя выскочила сюжетка, вполне комфортно пострелял. Визуально потерь в производительности нет.
Если нам необходимо пробросить жесткий диск целиком, то в файле настроек виртуальной машины необходимо добавить строку:
Конкретно какой именно sda/sdb/sdc/и т.п. можно уточнить в веб интерфейсе.
К бочке меда есть и ложка дегтя. Интегрированный звук отдельно прокинуть нельзя, т.к. в его группе находятся другие устройства, которые после проброса звуковой карты в виртуальную машину пропадают для хоста до следующей перегрузки хоста. В моем случае это
00:1f.0 ISA bridge: Intel Corporation Device a305 (rev 10)
00:1f.3 Audio device: Intel Corporation Device a348 (rev 10)
00:1f.4 SMBus: Intel Corporation Device a323 (rev 10)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Device a324 (rev 10)
00:1f.6 Ethernet controller: Intel Corporation Device 15bc (rev 10)
Т.е. звук или через видеокабель на монитор или внешняя звуковая карта. Порты USB пробрасываюся без проблем. К сожалению на текущий момент нерешаемо. Есть вариант удаленного подключения с другого ПК к игровому, через RDP или SPICE. В этом случае все будет нормально
Не всегда проброс видеокарты проходит идеально как в моем случае, мешается или ошибка 43 или что-то еще. Здесь описаны и другие настройки, которые могут помочь. В идеале нужно искать в сети удачные сетапы и ориентироваться на них, каким для меня явился этот, кроме того есть еще список железа, позволяющий достичь того же что и я, но он не полный.
Для мыши — аналогично.
2. По USB:
Что касается USB устройств там все проще, устройства прокидываются прямо из веб формы по ID или же целиком можно прокинуть порт. Однако есть нюанс — если Вы по каким-либо причинам не можете как и я прокинуть аудиоустройство в ВМ, т.к. оно содержится в группе с ключевыми контроллерами без которых хост не может полноценно работать, то проброс порта/устройства через USB решает эту проблему, но звук может начать отваливаться через некоторое время работы, шипеть/гудеть и прочие… прочее, в то же время на нативной системе все будет замечательно. В этом случае необходимо пробрасывать не порт/устройство, а сам контроллер USB как PCIe устройство по методу указанному в статье. И все резко наладится. Но в то же время через хост после запуска ВМ с такими настройками пробросить другие устройства с этого контроллера больше не получится.
3. Жесткие диски можно пробрасывать как через проброс контроллера как PCIe устройство по методу указанному в статье (не рекомендую пробрасывать контроллер интегрированный в материнскую плату, только подключенные к PCIe), либо напрямую:
заходим в
## cd /dev/disk/by-id
через dir смотрим листинг…
копируем строки вида ata-WDC_WD40EFRX-68WT0N6_WD-WCC4E1АС9SХ9, в которой прописан интерфейс подключения, марка и номер серии жесткого диска. Затем открываем Файл конфигурации ВМ и пишем:
sata1: volume=/dev/disk/by-id/ata-WDC_WD40EFRX-68WT0N6_WD-WCC4E1АС9SХ9
и все работает, при этом учитывайте, что sata0-sata5, т.е. для одной ВМ число подключаемых таким образом дисков, включая виртуальных, не может превышать 6шт.
UPDATE 2
1. На этом видео видно, что для обхода ошибки 43 помогает обманка со следующей строкой в конфигурационном файле ВМ:
www.youtube.com/watch?v=fgx3NMk6F54
Однако там проброс ВК организован с использованием rom файла, что отличается от моего варианта.
2. В связи с тем, что была обновлена версия ProxMox с 5й на 6ю, то что бы система работала с UEFI БИОСом, то необходимо добавить в оборудовании ВМ EFI-диск, иначе не взлетит и не заведется, на 5й версии ProxMox’а этой фичи не было.
Проблемы с включением IOMMU
Сап, лорчан. Имею мать GA-990FXA-D3, rev 1.2. Биосе присутствуют пункты Virtualization и IOMMU, оба включены. Тем не менее, в dmesg всё время
Написал в саппорт Gigabyte:
Здравствуйте! Год назад приобрел эту материнскую плату, вот возникла проблема: вне зависимости от включенности\выключенности IOMMU в BIOS система просит включить в Биосе поддержку iommu. Проверялось на Gentoo
На что получил ответ:
Благодарим Вас за использование нашей продукции и за обращение в службу технической поддержки GIGABYTE TECHNOLOGY.
Материнские платы компании Gigabyte проходят соответствующую сертификацию на предмет совместимости с операционными системами компании Microsoft (сертификат Windows Hardware Quality Labs/WHQL), так же информацию о совместимости Вы можете найти на сайте Microsoft: http://www.microsoft.com/windows/compatibility/windows-7/en-us/Search.aspx?l=. Вся продукция компании Gigabyte, все программное обеспечение разрабатывается и тестируется только под операционные системы компании Microsoft. В разделе «Спецификации» или «Описание», к любой модели материнской платы есть пункт, в котором указаны поддерживаемые операционные системы, в Вашем случае это Microsoft Windows 7/Vista/XP.
Так же, на сайте отмечено, что: «Из-за особенностей осуществления поддержки семейства ОС Linux со стороны производителей системной логики, пожалуйста, обратитесь за драйверами для Linux на сайты разработчиков.»
Таким образом, мы не можем гарантировать какую-либо стабильную работу компьютера при использовании операционных систем Linux.
С Уважением и Наилучшими пожеланиями, GIGABYTE TECHNOLOGY
Они, блин, совсем там упоролись? Слов нет просто.
KVM, PCI passthrough, Looking Glass и все-все-все
Искать выход долго не пришлось, но идея бить в бубен прожектором оказалась весьма странной. На тему проброса видеокарт в виртуальную машину интернет изобилует инструкциями различных времён и под различное железо. Чего стоит огромная статья на сайте Arch Linux’а [ 0 ]. Приведу сокращенную версию инструкции по пробросу видеокарты.
0. Проверяем, что железо поддерживает IOMMU
1. Включаем поддержку IOMMU в ядре.
GRUB_CMDLINE_LINUX_DEFAULT=«quiet splash amd_iommu=on»
или
GRUB_CMDLINE_LINUX_DEFAULT=«quiet splash intel_iommu=on»
2. Отбираем видеокарту у драйвера
Ищем нужные устройства и смотрим какие драйвера их используют.
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2)
Kernel driver in use: nouveau
Kernel modules: nvidiafb, nouveau
04:00.1 Audio device [0403]: NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1)
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
Добавляем модули VFIO, чтобы они подгружались при загрузке.
Настраиваем модуль VFIO, чтобы он перехватывал устройства, не давая загрузиться основным драйверам. При необходимости добавляем в черный список, основной драйвер.
options vfio-pci ids=10de:0a65,10de:0be3
blacklist nouveau
3. Перезагружаемся и проверяем, что всё получилось
DMAR: Intel® Virtualization Technology for Directed I/O
или
AMD-Vi: Found IOMMU at 0000:00:00.2 cap 0x40
AMD-Vi: Interrupt remapping enabled
AMD-Vi: Lazy IO/TLB flushing enabled
Составные устройства попали в одну группу.
/sys/kernel/iommu_groups/15/devices/0000:01:00.0
/sys/kernel/iommu_groups/15/devices/0000:01:00.1
/sys/kernel/iommu_groups/16/devices/0000:02:00.0
/sys/kernel/iommu_groups/17/devices/0000:03:00.0
/sys/kernel/iommu_groups/18/devices/0000:04:00.0
/sys/kernel/iommu_groups/18/devices/0000:04:00.1
Драйвера KVM и VFIO загружены.
Видеокарта для гостевой ОС захвачена VFIO.
04:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 210] [10de:0a65] (rev a2)
Kernel driver in use: vfio-pci
Kernel modules: nvidiafb, nouveau
04:00.1 Audio device [0403]: NVIDIA Corporation High Definition Audio Controller [10de:0be3] (rev a1)
Kernel driver in use: vfio-pci
Kernel modules: snd_hda_intel
4. Настраиваем QEMU и запускаем гостевую ОС
sudo apt install qemu-kvm qemu-utils seabios ovmf virt-viewer
Запускаем виртуальную машину без проброса видеокарты для установки гостевой ОС. Так как стоит прицел на Looking Glass, то для гостевой стоит выбирать Windows 10. Windows 8/8.1 по последнем данным тоже поддерживаются.
#!/bin/bash
remote-viewer spice://127.0.0.1:5900&
sudo qemu-system-x86_64 \
-machine q35,accel=kvm \
-enable-kvm \
-cpu host,kvm=off,check \
-smp cpus=2,sockets=1,cores=2,threads=1 \
-m 6G \
-rtc base=localtime,clock=host \
-device piix3-usb-uhci \
-device usb-tablet \
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive file=’w10.iso’,if=ide,format=raw,index=2,media=cdrom,cache=none \
-drive file=’virtio-win-0.1.141_st.iso’,if=ide,format=raw,index=3,media=cdrom,cache=none \
-drive file=’guest.img’,if=ide,format=raw,index=4,media=disk,cache=writeback \
-vga qxl \
-spice port=5900,addr=127.0.0.1,disable-ticketing \
-monitor stdio \
-netdev user,id=n1,ipv6=off,smb=»/media/user/data» \
-device e1000,netdev=n1,mac=67:77:78:88:89:99 \
«$@»
5. Пробрасываем видеокарту в гостевую ОС
Для начала загрузимся с двумя видеокартами. Смотрим, что проброшенная карта появилась в системе, ставим на неё драйвера и убеждаемся, что они заработали.
#!/bin/bash
remote-viewer spice://127.0.0.1:5900&
sudo qemu-system-x86_64 \
-machine q35,accel=kvm \
-enable-kvm \
-cpu host,kvm=off,check \
-smp cpus=2,sockets=1,cores=2,threads=1 \
-m 6G \
-rtc base=localtime,clock=host \
-device piix3-usb-uhci \
-device usb-tablet \
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive file=’virtio-win-0.1.141_st.iso’,if=ide,format=raw,index=3,media=cdrom,cache=none \
-drive file=’guest.img’,if=ide,format=raw,index=4,media=disk,cache=writeback \
-vga qxl \
-spice port=5900,addr=127.0.0.1,disable-ticketing \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root \
-device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on \
-device vfio-pci,host=04:00.1,bus=root,addr=00.1 \
-monitor stdio \
-netdev user,id=n1,ipv6=off,smb=»/media/user/data» \
-device e1000,netdev=n1,mac=67:77:78:88:89:99 \
«$@»
После как проброшенная видеокарта заработала, и в диспетчере устройств пишет «Устройство работает нормально», запускаем виртуальную машину только с проброшенной видеокартой.
#!/bin/bash
sudo qemu-system-x86_64 \
-machine q35,accel=kvm \
-enable-kvm \
-cpu host,kvm=off,check \
-smp cpus=2,sockets=1,cores=2,threads=1 \
-m 6G \
-rtc base=localtime,clock=host \
-device piix3-usb-uhci \
-device usb-tablet \
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive file=’virtio-win-0.1.141_st.iso’,if=ide,format=raw,index=3,media=cdrom,cache=none \
-drive file=’guest.img’,if=ide,format=raw,index=4,media=disk,cache=writeback \
-vga none \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root \
-device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on \
-device vfio-pci,host=04:00.1,bus=root,addr=00.1 \
-monitor stdio \
-netdev user,id=n1,ipv6=off,smb=»/media/user/data» \
-device e1000,netdev=n1,mac=67:77:78:88:89:99 \
«$@»
Подключаем к ней монитор и любуемся изображением рабочего стола гостевой ОС.
То место, где заканчиваются простые решения
Шить или не шить, вот в чем вопрос
#!/bin/bash
sudo qemu-system-x86_64 \
-machine q35,accel=kvm \
-enable-kvm \
-cpu host,kvm=off,check \
-smp cpus=2,sockets=1,cores=2,threads=1 \
-m 6G \
-rtc base=localtime,clock=host \
-device piix3-usb-uhci \
-device usb-tablet \
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive file=’virtio-win-0.1.141_st.iso’,if=ide,format=raw,index=3,media=cdrom,cache=none \
-drive file=’guest.img’,if=ide,format=raw,index=4,media=disk,cache=writeback \
-vga none \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root \
-device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on,romfile=gt210_uefi.rom \
-device vfio-pci,host=04:00.1,bus=root,addr=00.1 \
-monitor stdio \
-netdev user,id=n1,ipv6=off,smb=»/media/user/data» \
-device e1000,netdev=n1,mac=67:77:78:88:89:99 \
«$@»
Запускаем виртуальную машину и смотрим.
Темнота
#!/bin/bash
sudo qemu-system-x86_64 \
-machine q35,accel=kvm \
-enable-kvm \
-cpu host,kvm=off,check \
-smp cpus=2,sockets=1,cores=2,threads=1 \
-m 6G \
-rtc base=localtime,clock=host \
-device piix3-usb-uhci \
-device usb-tablet \
-drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd \
-drive file=’virtio-win-0.1.141_st.iso’,if=ide,format=raw,index=3,media=cdrom,cache=none \
-drive file=’guest.img’,if=ide,format=raw,index=4,media=disk,cache=writeback \
-vga none \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root \
-device vfio-pci,host=04:00.0,bus=root,addr=00.0,multifunction=on,romfile=gt210_uefi.rom \
-device vfio-pci,host=04:00.1,bus=root,addr=00.1 \
-monitor stdio \
-netdev user,id=n1,hostfwd=tcp:127.0.0.1:5600-:5600,ipv6=off,smb=»/media/user/data» \
-device e1000,netdev=n1,mac=67:77:78:88:89:99 \
«$@»
Подключаемся и видим рабочую машину, только монитор у неё странный Generic Non-PnP Monitor (Универсальный монитор не PnP). Картинка есть, значит можно пробовать запускать Looking Glass.
Looking Glass
Хоть данная технология и использует OpenGL, после gl пробел не нужен. А вот почитать инструкцию [ 5 ] на сайте проекта нужно обязательно. Для гостевой ОС скачать приложение захвата экрана looking-glass-host.exe [ 6 ], скачать и установить Microsoft Visual C++ 2015 Redistributable [ 7 ], скачать драйвер для IVSHMEM устройства [ 8 ]. Для хоста ставим зависимости, скачиваем и собираем клиентское приложение.
Запускаем виртуальную машину с IVSHMEM устройством. Размер памяти в 32Mb выбран для разрешения 1920×1080.
На этом у меня заработала система с NVidia GF210, а затем по этому же маршруту удалось запустить Intel HD530. С разрешением экрана была маленькая проблемка, для смены на редкое разрешение, например 2048х1152, пришлось использовать Custom Resolution Utility [ 9 ].
Ещё один нюанс, при добавлении приложения looking-glass-host.exe в автозагрузку, нужно настроить автоматический вход пользователя, по соображениям безопасности гостевая ОС не даёт захватывать экран входа в систему.
Послесловие
Если не ставить задачу, получение изображения на физическом видео выходе, то данного результата будет достаточно для получения рабочей виртуальной машины с физической видеокартой и отзывчивым управлением. Управление осуществляется из хоста в отдельном окне или на полном экране. Однако есть нюансы.
Производительность. Накладные ресурсы на виртуализацию и не самая расторопная гостевая ОС не дадут с комфортом работать на слабом и средне-слабом железе. Потребуется мощный процессор не меньше 6-8 ядер, хорошая видеокарта для гостевой ОС, 16ГБ+ оперативной памяти, минимум по 8ГБ на каждую ОС. И танцы с бубном, чтобы выжать максимум из железа.
Терпение. Если сразу не заработает, то сил и времени придётся потратить прилично. Искать, читать, пробовать. Опять искать, читать и снова пробовать. Оставлю ещё несколько ссылок, которые мне попадались, возможно там будет ещё какая-нибудь полезная информация. [ 10 ] [ 11 ] [ 12 ]