1. Вступление
Две разные системы (win + linux) на одной аппаратной базе - реальность. В этом нет ничего нового или инновационного (на данный момент времени), но если требуется максимальная производительность гостевой системы, то не обойтись без проброса реальных устройств в виртуальную машину. Проброс сетевых карт, usb-контроллеров (etc) экстраординарных особенностей не несёт, а вот попытка "шаринга" ресурсов видеокарты и процессора вполне может принести некоторое количество проблем.
Итак, а для чего, собственного говоря, городить системы с полнофункциональным использованием ресурсов GPU и CPU? Самый простой и очевидный ответ - игры (широко известный факт - если не большинство, то очень многие, написаны под ОС Windows). Другой вариант - полноценное рабочее место с возможностью запуска требовательных приложений (например, CAD-софта), быстрым бэкапом (скопировать файл ВМ куда проще, чем создавать полную копию HDD/SSD) и опцией полного контроля сетевого трафика гостевой системы.
2. Аппаратная часть
Процессор: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz
Материнская плата: ASRock Z390 Phantom Gaming 4S
Видеокарта 0 (для проброса в ВМ): Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X]
Видеокарта 1 (для хост-системы): Park [Mobility Radeon HD 5430]
USB-контроллер (для проброса в ВМ и последующего подключения периферийных устройств, например, клавиатуры): VIA Technologies, Inc. VL805 USB 3.0 Host Controller
3. Настройки ОС
В качестве хост-системы выбрана ОС AlmaLinux 8 (вариант установки«Server with GUI»). Долгое время пользовался CentOS 7/8, поэтому, думаю, выбор тут очевиден.
Первое, что необходимо сделать, - это ограничить использование видеокарты, предназначенной для использования в ВМ, хост-системой. Для этого применяем ряд команд и настроек:
1) с помощью команды «lspci -nn | grep RX
» получаем уникальные идентификаторы видеокарты. Т. к. видеокарта RX-серии, то, соответственно, ищем в выводе lspci
(утилита устанавливается посредством команды «dnf install pciutils
») по этим двум символам. Вывод получим примерно такой (выделенные подстроки — это и есть искомые идентификаторы устройств) -
«02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] [1002:699f] (rev c7)
02:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Baffin HDMI/DP Audio [Radeon RX 550 640SP / RX 560/560X] [1002:aae0]
», где 1002:699f — идентификатор VGA-контроллера, а 1002:aae0 — встроенной аудиокарты. Также запоминаем идентификаторы «02:00.0» и «02:00.1»;
2) добавив к команде «lspci -nn
» ключ «k
» («lspci -nnk
») находим в выводе устройство «1002:699f» и запоминаем значение «Kernel driver in use»
. В моём случае — это «amdgpu
»;
3) в файле «/etc/default/grub
» находим строку, начинающуюся с «GRUB_CMDLINE_LINUX
», и добавляем после «quiet
» значения «intel_iommu=on iommu=on rd.driver.pre=pci-stub pci-stub.ids=1002:67ff,1002:aae0», где «intel_iommu / iommu
» – параметры, отвечающие за поддержку технологии IOMMU (технология взаимодействия виртуальных машин с реальным оборудованием), «rd.driver.pre=pci-stub» - указание на принудительную первоочередную загрузку фиктивного драйвера pci-sub, «pci-stub.ids» - перечисление устройств, для которых при загрузке ядра необходимо использовать фиктивный драйвер (т.е. происходит изоляция устройств для дальнейшего использования в виртуальных машинах). Если на хост-машине используется CPU от AMD, то «intel_iommu» меняем на «amd_iommu»;
4) в файл «/etc/modprobe.d/local.conf
» добавляем строки «blacklist amdgpu
» и «options pci-stub ids=1002:67ff,1002:aae0
», где «blacklist amdgpu
» - явное указание на запрет использования драйвера AMD для графических устройств, а «options pci-stub ids=1002:67ff,1002:aae0
» - явное указание на использование фиктивного драйвера для соответствующих идентификаторов устройств;
5) выполняем команду «grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
» (т.е. пересоздаём конфигурационный файл загрузчика GRUB). Если речь не про EFI-загрузку, то команда выглядит так - «grub2-mkconfig -o /boot/grub2/grub.cfg
»;
6) выполняем команду «dracut --regenerate-all --force
» для пересоздания образа initramfs (initial RAM disk image, загружаемый в оперативную память файл с образом файловой системы), используемого при загрузке Linux в качестве первоначальной корневой файловой системы;
7) перезагружаем хост виртуализации.
Смысл этих настроек в том, чтобы ограничить использование определённых устройств при загрузке. Например, до прописания параметров в выводе команды «lspci -v» для VGA-контроллера будет присутствовать подстрока «Kernel driver in use: amdgpu
», а после перезагрузки – «Kernel driver in use: pci-stub
». При старте же ВМ с Windows (и после проброса устройств) – “Kernel driver in use: vfio-pci
” (в чём можно убедиться после запуска созданной ВМ). Важный момент — используемая для хост-системы видеокарта должна использовать драйвера, отличные от используемых для пробрасываемой видеокарты, например, в моём случае используется «Radeon HD 5430», драйвер для которой — это «radeon» (в выводе «lspci -v
» – «Kernel driver in use: radeon
»).
4. Установка софта для виртуализации
1) «dnf install epel-release
».
2) «dnf install qemu-kvm qemu-img libvirt virt-install libvirt-client virt-viewer virt-manager seabios numactl perf cockpit cockpit-machines xauth virt-top libguestfs-tools
».
3) «dnf install @virt
».
4) Optional. «dnf install perl
» (Perl – one love).
5. Настройки ВМ QEMU-KVM via virt-manager
Предварительно скачиваем iso-образ Windows 10 и драйвера Virtio от RedHat (тоже в виде iso-образа).
При первоначальной установке всегда ставим галочку «Customize configuration before install
».
1) Указываем iso-образ устанавливаемой операционной системы (например, Windows 10). Также добавляем дополнительное устройство вида «CD-ROM» и монтируем в доп. устройство iso-образ с драйверами Virtio.
2) Для виртуального HDD (куда планируется установка ОС) выставляем: «Bus type = Virtio
». Тип виртуального диска — qcow2 или raw.
3) Для более эффективной работы размещаем основной виртуальный диск для ВМ на SSD.
4) Модель сетевой карты - virtio.
5) Overview: chipset = “Q35”, firmware = “UEFI x86_64: /usr/share/OVMF/OVMF_CODE.secboot.fd”.
6) OS Information: Operation System = “Microsoft Windows 10”.
7) CPU (соответствующие блоки в XML должны выглядеть именно так, если речь про аналогичную аппаратную конфигурацию):
Развернуть
<cpu mode="host-passthrough" check="none">
<topology sockets="1" dies="1" cores="4" threads="1"/>
<cache mode="passthrough"/>
<feature policy="disable" name="hypervisor"/>
</cpu>
<features>
<acpi/>
<apic/>
<hyperv>
<relaxed state="off"/>
<vapic state="off"/>
<spinlocks state="off"/>
<vendor_id state="on" value="1234567890"/>
</hyperv>
<kvm>
<hidden state="on"/>
</kvm>
<smm state="on"/>
</features>
8) Удаляем из конфигурации ВМ: «Tablet», «Display VNC», «Channel qemu-ga», «Video VGA».
9) Добавляем (через «Add Hardware → PCI Host Device») нужные устройства (VGA-контроллер, встроенный в видеокарту аудиконтроллер и отдельный USB-контроллер), ориентируясь на выделенный идентификатор «02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] (rev c7)» (пример вывода «lspci»).
10) Подключаем монитор к проброшенной видеокарте, а «мышь» с клавиатурой — к проброшенному USB-контроллеру.
11) Запускаем процесс установки («Begin installation»). В процессе установки указываем инсталлятору на образ Virtio в качестве драйвер-источника для HDD.
12) После установки заходим в диспетчер задач и для неизвестных устройств указываем в качестве драйвер-источника диск с Virtio. Также инсталлируем драйвера видеокарты.
Если всё сделано правильно, то в диспетчере задач Windows вы увидите реальную видеокарту и 4 ядра CPU с расшаренными ресурсами процессора (Кэш L1 + L2 + L3).
Комментарии (18)
vovochka404
08.02.2022 07:26+1А еще при пробросе AMD карт polaris, vega и rdna1 очень рекоммендую добавить в систему модуль vender_reset. Это позволит перезагружать виртуалку без страха, что придется перезагружать всю хост систему.
Procyon_lotor
08.02.2022 10:13Тут только стоит добавить, что этот фокус полностью зависит от технологии IOMMU и если на серверах, не знаю как там, возможно часть стандартного набора опций, то на бытовых материнских платах, если вы не выбирали ее специально под такие эксперименты, то скорее всего у вас этого IOMMU нет. Поддержка чипсетом сама по себе ни о чем не говорит. Так же должено быть соответствующее ПО как часть BIOS. Если производитель не добавил, то и особо ничего не сделать.
alexcloud2
08.02.2022 10:14+1Клавиатуру с мышью можно использовать те же, что и подключены к хосту, если пробросить их через evdev (как описано, например, здесь). Переключать ввод между хостом и виртуалкой при этом можно нажатием на оба контрола.
rageorg
08.02.2022 10:14+5https://habr.com/ru/post/437598/
https://habr.com/ru/post/448312/
https://habr.com/ru/post/433878/
Вот же статьи о том же самом. Да еще и с картинками.
Lapk
08.02.2022 10:30+12. Аппаратная часть
Дальше можно не читать, у меня только одна видюха и второй не будет до конца жизни, походу :(
Valser
08.02.2022 11:47" Perl – one love " - судя по этой фразе, это скопированный перевод? Не нашел просто у автора статей по Perl .
habrauser008
08.02.2022 18:10+2Итак, а для чего, собственного говоря, городить системы с полнофункциональным использованием ресурсов GPU и CPU? Самый простой и очевидный ответ - игры (широко известный факт - если не большинство, то очень многие, написаны под ОС Windows). Другой вариант - полноценное рабочее место с возможностью запуска требовательных приложений (например, CAD-софта), быстрым бэкапом (скопировать файл ВМ куда проще, чем создавать полную копию HDD/SSD) и опцией полного контроля сетевого трафика гостевой системы.
В этих сценариях самый простой и очевидный вывод - хостом должна быть Windows, в которую ничего пробрасывать и не надо, если только вы не любитель непонятных глюков на ровном месте. И любому линуксу там в WSL/HyperV тоже будет хорошо.
Gordon01
09.02.2022 17:18-1Согласен, делаю так же, после 10+ линукса без дуалбута.
Если бы сейчас были времена нормальных DE и WM на линуксе, как это было во времена KDE 3.5 и GNOME 2 был бы хотя бы смысл, но то, чем приходится пользоваться сейчас на линуксе еще хуже, чем даже макось (которая до сих пор не может сохранять порядок окон в переключателе) и гораздо хуже экспириенса в виндовс.
WSL2 покрывает потребности в нормальном линуксе. Что еще надо?
С удовольствием вернусь в линукс, когда появится нормальная DE хотя бы уровня третьих кедов.
vovochka404
В чем идея скрывать от винды факт работы в виртуалке? Обычно это делают при пробросе nvidia-карточек. А тут в чем?
Зачем amdgpu добавлять в blacklist? А если у меня и для хоста видюха, требующая этот драйвер?
По мимо проброса usb-контрллера с физическим переключением устройств, довольно не плохо заходит evdev устройства, что позволяет использовать одни и те же клава-мышь и на хосте и в виртуалке. Но тут каждому свое.
Не раскрыта тема звука. Там может быть довольно много танцев с бубном вокруг пульсаудио. Да и вообще, разрешить выводить звук - там вроде нужно тоже что-то в конфиги добавлять. Из-за проблем с выводом звука на bluetooth гарнитуру в итоге перешел на использование scream аудио.
13werwolf13
отвечу за автора
подозреваю что скрывает факт виртуализации от винды он не ради проброса как в случае с geforce (квадры этого тоже не требуют), а потому что на винде есть софт который так же как драйвера geforce отказываются работать или работают не так как надо если видят что живут в виртуалке.
а вот зачем он amdgpu в блеклист добавил мне и правда непонятно, всё делается средствами vfio
по переключению клавомыши при наличии двух мониторов лично мне нравится решение позволяющее использовать вторую ос (даже на другом компе) как просто второй монитор в системе. раньше я юзал ныне покойный synergy, сейчас ему есть опсосная замена Barrier (но её я не пробовал так как к тому моменту наконец-то смог полностью отказаться от винды)
со звуком самое печальное, если хочется прям очень годный звук то лучше так же пробросить pci/usb звуковую карту, я же решил по другому. я купил какую-то софтину (уж простите не помню название) которая делала виртуальную звуковую карту в винде и весь выход пуляла в сеть, а на линуксе принять сетевой звук и отправить на вывод есть 100500 способов разной адекватности.
vovochka404
Насчет второго рабочего места, согласен, удобно. Но у меня один монитор и один набор клава-мышей :)
По звуку, указанный scream и создает виртуальную карточку, пуляющую звук в сеть :)
13werwolf13
за ссылку на scream спасибо, мне не рпигодится, но знаю кому пригодится и поделюсь. жаль я тогда не нашёл ничего подобного опсосного, заплатил баксов 20 за прогу название которой теперь уже даже не помню...
mchaluk
Можно использовать любой KVM, достаточно удобно между двумя ос переключаться . По звуку: в usb хаб вставлена звуковая, и колонки на два звуковых входа.
slonopotamus
Эээ... Но он вполне себе жив: https://symless.com/synergy
13werwolf13
поправлюсь
опсосная версия синержи покойная, а свежая проприетарная, закрытая, и по слухам работает шустрее, но глючит (старая опсосная практически не глючила).
vaddyf
Существует Synergy Core, на основе которой, кажется, пилят Synergy 2
https://github.com/symless/synergy-core
Единственное — нет шифрования, а так вполне рабочая штука. Надо только самому компилировать