vim | 22. listopadu 2024 1:55
Na řádcích níže bych rád popsal postup na zprovoznění VFIO PCI passthrough grafické karty skrz OVMF v KVM/QEMU pod libvirt v prostředí distribuce Debian. Stručně česky to znamená přiřazení grafické karty virtuálnímu stroji v KVM. Jako hostitelský operační systém je v návodu použit Debian 12 - Bookworm, případně Debian Testing (13 – Trixie v době psaní); na případné rozdíly v konfiguraci upozorním. Jako hostovaný operační systém bude použit Windows 11, případně Windows 10 (pro starší hostitelský HW).
V BIOSu je třeba mít aktivovanou podporu virtualizace (SVM u AMD, VT-x u Intelu) a IOMMU (AMD-Vi u AMD, VT-d u Intelu), dále pak nastavit, která grafická karta má být primární (iGPU). U platformy AMD je pak potřeba aktivovat nastavení PCIe AER – Advanced Error Reporting a případně PCIe ACS – Access Control Services (předpokládám běžný desktopový HW, ACS Intel podporuje u high-end desktopových platforem a Xeonů od řady E5).
Snímky z nastavení BIOSu na platformě Intel:
Zde se přiznám budu tak trochu vařit z vody, instalaci QEMU, Libvirtu a Virt-manageru provádím ihned po instalaci OS, k čemuž v mém případě naposledy došlo před více než rokem takže už nemám k dispozici příslušné logy aptu, proto si nejsem jist jestli uvedu kompletní seznam potřebných balíčků.
apt-get install qemu-system-x86 qemu-system-gui ovmf swtpm-tools \
libvirt-daemon-system libvirt-clients bridge-utils virt-manager
IOMMU je zařízení, které provádí překlad/mapování I/O virtuálních adres (dále jen IOVA) na adresy ve fyzické paměti.
Ovladač IOMMU se v jádře na platformě Intel aktivuje parametrem příkazového řádku intel_iommu=on
. Ovladač IOMMU na platformě AMD provádí autodetekci podpory v BIOSu. Jak na platformě AMD tak i na platformě Intel je doporučené jádru předat parametr iommu=pt
.
Proto v /etc/default/grub
upravíme řádek GRUB_CMDLINE_LINUX=""
na:
GRUB_CMDLINE_LINUX="iommu=pt"
(AMD)
nebo:
GRUB_CMDLINE_LINUX="intel_iommu=on iommu=pt"
(Intel)
Po uložení změny provedeme aktualizaci konfigurace grubu příkazem:
update-grub
Po rebootu příkazem: dmesg|grep -i -e IOMMU -e DMAR -e AMD-Vi
ověříme, že podpora IOMMU funguje:
AMD:[ 0.028248] AMD-Vi: Using global IVHD EFR:0x246577efa2254afa, EFR2:0x0
[ 0.348519] iommu: Default domain type: Passthrough (set via kernel command line)
[ 0.368835] pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported
[ 0.368868] pci 0000:00:01.0: Adding to iommu group 0
...
[ 0.369459] pci 0000:17:00.6: Adding to iommu group 28
[ 0.369470] pci 0000:18:00.0: Adding to iommu group 29
[ 0.369715] AMD-Vi: Extended features (0x246577efa2254afa, 0x0): PPR NX GT [5] IA GA PC GA_vAPIC
[ 0.369720] AMD-Vi: Interrupt remapping enabled
[ 0.568395] AMD-Vi: Virtual APIC enabled
[ 0.572260] perf/amd_iommu: Detected AMD IOMMU #0 (2 banks, 4 counters/bank).
Intel:[ 0.018886] DMAR: IOMMU enabled
[ 0.058050] DMAR: Host address width 39
[ 0.058051] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[ 0.058056] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c0000020660462 ecap f0101a
[ 0.058057] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[ 0.058060] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008020660462 ecap f010da
[ 0.058061] DMAR: RMRR base: 0x000000c87e1000 end: 0x000000c87edfff
[ 0.058063] DMAR: RMRR base: 0x000000cb000000 end: 0x000000cf1fffff
[ 0.058064] DMAR-IR: IOAPIC id 8 under DRHD base 0xfed91000 IOMMU 1
[ 0.058065] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[ 0.058066] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[ 0.058539] DMAR-IR: Enabled IRQ remapping in x2apic mode
[ 0.186059] iommu: Default domain type: Passthrough (set via kernel command line)
[ 0.248297] DMAR: No ATSR found
[ 0.248298] DMAR: No SATC found
[ 0.248299] DMAR: IOMMU feature pgsel_inv inconsistent
[ 0.248300] DMAR: IOMMU feature sc_support inconsistent
[ 0.248300] DMAR: IOMMU feature pass_through inconsistent
[ 0.248301] DMAR: dmar0: Using Queued invalidation
[ 0.248306] DMAR: dmar1: Using Queued invalidation
[ 0.378711] pci 0000:00:02.0: Adding to iommu group 0
...
[ 0.378869] pci 0000:06:00.0: Adding to iommu group 15
[ 0.378939] DMAR: Intel(R) Virtualization Technology for Directed I/O
Zařízení na PCIe sběrnici mohou komunikovat mezi sebou v režimu peer-to-peer. Taková komunikace, ale neprochází přes IOMMU jednotku a proto se správně nepřemapuje. V případě zařízení, která provádějí DMA operace to znamená zásadní problém. Jádro proto seskupuje zařízení, mezi kterými je tato komunikace možná do IOMMU skupin. Zařízení v rámci jednotlivých IOMMU skupin sdílejí I/O virtuální adresní prostor a zároveň s tím jsou izolovány od zařízení v ostatních skupinách.
Seznam IOMMU skupin a zařízení do nich patřících lze vypsat pomocí následujícího skriptu (z ArchWiki):
#!/bin/bash
shopt -s nullglob
for g in $(find /sys/kernel/iommu_groups/* -maxdepth 0 -type d | sort -V); do
echo "IOMMU Group ${g##*/}:"
for d in $g/devices/*; do
echo -e "\t$(lspci -nns ${d##*/})"
done;
done;
Příklad výpisu uvedeného skriptu:IOMMU Group 0:
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3 Processor Integrated Graphics Controller [8086:041a] (rev 06)
IOMMU Group 1:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3 Processor DRAM Controller [8086:0c08] (rev 06)
IOMMU Group 2:
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] [10de:1380] (rev a2)
01:00.1 Audio device [0403]: NVIDIA Corporation GM107 High Definition Audio Controller [GeForce 940MX] [10de:0fbc] (rev a1)
IOMMU Group 3:
00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06)
IOMMU Group 4:
00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05)
IOMMU Group 5:
00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04)
IOMMU Group 6:
00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 05)
IOMMU Group 7:
00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] (rev 05)
IOMMU Group 8:
00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 [8086:8c10] (rev d5)
IOMMU Group 9:
00:1c.1 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev d5)
03:00.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge [1b21:1080] (rev 03)
04:02.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev c0)
IOMMU Group 10:
00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 [8086:8c14] (rev d5)
IOMMU Group 11:
00:1c.3 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 [8086:8c16] (rev d5)
IOMMU Group 12:
00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 05)
IOMMU Group 13:
00:1f.0 ISA bridge [0601]: Intel Corporation C226 Series Chipset Family Server Advanced SKU LPC Controller [8086:8c56] (rev 05)
00:1f.2 SATA controller [0106]: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c02] (rev 05)
00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller [8086:8c22] (rev 05)
IOMMU Group 14:
05:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)
IOMMU Group 15:
06:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)
Pro nás je důležité, že s výjimkou můstků (bridges), kořenových portů (root ports) a přepínačů (switches) (tzv. interconnect fabric - propojovací logika), je nutné všechna zařízení z IOMMU skupiny, ze které chceme nějaké zařízení přidělit virtuálnímu stroji, svázat s ovladačem vfio-pci. V ideálním případě by měla být přiřazováná grafická karta v IOMMU skupině pouze se svým audio zařízením (to je součástí grafické karty kvůli HDMI rozhranní). V případě, že by grafická karta byla v IOMMU skupině s vícero zařízeními (s výjimkou výše zmíněných zařízení propojovací logiky), je možné zkusit grafickou kartu osadit do jiného PCIe slotu. V případě, že ani změna slotu nepomůže, je ještě možné jít cestou ACS override patche jádra, jehož použití přináší určitá rizika a proto se mu zde nebudu dále věnovat.
Ve výše zmíněném výpisu IOMMU skupin a PCI zařízení se grafická karta nachází v IOMMU skupině číslo 2 spolu se svým audio zařízením a PCI můstkem:
IOMMU Group 2:
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06)
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] [10de:1380] (rev a2)
01:00.1 Audio device [0403]: NVIDIA Corporation GM107 High Definition Audio Controller [GeForce 940MX] [10de:0fbc] (rev a1)
V uvedeném výpisu si u jednotlivých řádků zařízení povšimněte adresy zařízení na PCI sběrnici na začátku řádku a poté PCI identifikátor (PCI ID) zařízení který je v posledních hranatých závorkách, např. grafická karta má PCI adresu 01:00.0
a PCI identifikátor 10de:1380
, tyto údaje budou pro nás důležité v následujících krocích.
Nyní je na čase vytvořit soubor /etc/modprobe.d/vfio.conf
ve kterém ovladači vfio-pci předáme seznam PCI ID zařízení, se kterými se má svázat. Zároveň v tomto souboru také uvedeme ovladače před kterými má vfio-pci dostat přednost při startu.
softdep amdgpu pre: vfio-pci
softdep radeon pre: vfio-pci
softdep nouveau pre: vfio-pci
softdep nvidia pre: vfio-pci
softdep nvidia* pre: vfio-pci
softdep drm pre: vfio-pci
softdep snd_hda_intel pre: vfio-pci
softdep snd_hda_codec_hdmi pre: vfio-pci
softdep i915 pre: vfio-pci
softdep ehci-pci pre: vfio-pci
softdep xhci-pci pre: vfio-pci
# GeForce GTX 750 Ti, HD Audio, USB Controller
options vfio-pci ids=10de:1380,10de:0fbc,8086:8c2d
Řádky začínající softdep specifikují, že se uvedený ovladač má načíst až po vfio-pci, řádkem options předáváme v parametru ids seznam PCI identifikátorů zařízení (oddělených čárkou) se kterými se má ovladač vfio-pci svázat.
Upozornění: Nezapomeňte změnit PCI identifikátory na řádku options vfio-pci ids=10de:1380,10de:0fbc,8086:8c2d
v uvedeném příkladu na PCI identifikátory zařízení ve vašem počítači.
Zde se ještě krátce zmíním o USB řadiči s PCI ID 8086:8c2d, který má PCI adresu 00:1a.0 a je sám v IOMMU skupině 6 (viz. ukázkový výpis v podkapitole 4.2); je proto vhodným kandidátem pro přiřazení virtuálnímu stroji. USB porty, které jsou k tomuto řadiči připojeny je možné identifikovat zkusmo pomocí utility lshw
(připojujeme známé USB zařízení k USB portům a v lshw
sledujeme ve kterém stromu kterého řadiče se objeví). Pro identifikaci vhodného USB řadiče můžeme také použít následující skript (z ArchWiki):
for usb_ctrl in /sys/bus/pci/devices/*/usb*; do
pci_path=${usb_ctrl%/*};
iommu_group=$(readlink $pci_path/iommu_group);
echo "Bus $(cat $usb_ctrl/busnum) --> ${pci_path##*/} (IOMMU group ${iommu_group##*/})";
lsusb -s ${usb_ctrl#*/usb}:; echo;
done
Ještě bych rád zmínil, proč je lepší přiřadit virtuálnímu stroji celý USB řadič (pokud tedy vaše základní deska má víc USB řadičů), než přiřazovat jednotlivá USB zařízení (což KVM/QEMU a potažmo Libvirt také umí), důvody jsou následující:
Do souboru /etc/initramfs-tools/modules
je potřeba přidat seznam modulu ovladače vfio-pci a jeho závislostí, které mají být zahrnuty v počátečním ramdisku (initramfs):
vfio
vfio_pci
vfio_pci_core
vfio_iommu_type1
vfio_virqfd
Na systémech s jádry od verze 6.2 je možné vypustit řádek vfio_virqfd
, jehož funkcionalita byla sloučena do modulu vfio. Po úpravě souboru je potřeba přegenerovat počáteční ramdisk spuštěním následujícího příkazu:
update-initramfs -kall -u
Varování: Od jádra 6.0 výstup framebufferu po načtení modulů VFIO až do načtení ovladačů GPU zamrzne. Při použití šifrování disku (LUKS) se proto nezobrazí výzva k zadání hesla, nicméně by to nemělo bránit zadání hesla a pokračování bootu.
Aby nám při startu služba systemd-modules-load.service načetla modul vfio-pci do jádra je třeba vytvořit soubor /etc/modules-load.d/vfio-pci.conf
s řádkem:
vfio-pci
Vytvoříme soubor /etc/modprobe.d/kvm.conf
do kterého na platformě AMD vložíme:
options kvm_amd nested=1
Na platformě Intel:
options kvm-intel nested=1
Po uložení souboru je potřeba přegenerovat počáteční ramdisk:
update-initramfs -kall -u
Po provedených změnách je třeba počítač restartovat.
Spustíme si virt-manager
(Správa virtuálních strojů), v menu Úpravy vybereme Předvolby:
Otevře se okno předvoleb, ve kterém zaškrtneme volbu Umožnit upravování XML:
Nyní v hlavním okně virt-manageru klikneme na ikonu Vytvořit nový virtuální stroj, která otevře následující dialog:
Vybereme Instalace z lokálního média a potvrdíme tlačítkem Vpřed, v následujícím dialogu vybereme ISO soubor s obrazem instalačního média zvoleného systému, který jsme si předem stáhli.
V dalším kroku nastavíme velikost operační paměti a počet virtuálních procesorů vytvářeného virtuálního stroje. V případě operační paměti je potřeba pamatovat na to, že i hostitelský systém potřebuje na něčem fungovat, takže není dobré přidělovat veškerou dostupnou paměť virtuálnímu stroji. V minimálních požadavcích Windows 11 je uvedeno: 4096 MiB RAM a dvoujádrový procesor.
V následujícím kroku vybereme/vytvoříme úložiště pro vytvářený virtuální stroj (dle specifikace vyžadují Windows 11 minimálně 64 GiB):
V dalším kroku zadáme název nového virtuálního stroje, zaškrtneme volbu Doupravit nastavení před instalací a vybereme síť, ke které bude virtuální stroj připojen:
Po kliknutí na tlačítko Dokončit se nám zobrazí okno s konfigurací nového virtuálního stroje, v něm (pokud tak již není nastaveno) vybereme čipovou sadu Q35 a Firmware zvolíme UEFI:
Nyní odstraníme zbytečný virtuální hardware: Tablet, Obrazovka Spice, Channel (spice), Video QXL, USB přesměrování 1, USB přesměrování 2, výsledek by měl vypadat následovně:
Dále změníme typ primárního virtuálního disku ze SATA na VirtIO: v seznamu HW klikneme na položku SATA disk 1 a v jeho detailu klikneme na roletkové menu Sběrnice disku, kde místo SATA vybereme VirtIO, změnu potvrdíme tlačítkem Použít. Stručně řečeno VirtIO přináší vyšší výkon, nicméně vyžaduje specializované ovladače na straně hostovaného operačního systému, viz. dále.
Nyní změníme typ síťové karty na VirtIO, pokud si ale přejete založit online uživatelský účet Windows, tento krok pro tuto chvíli přeskočte; Windows nemají zabudovaný VirtIO ovladač síťové karty a neumí ho (narozdíl od ovladače disku) během instalace načíst. Update: Windows 11 verze 24H2 přichází s přepracovaným instalátorem ve kterém je také možné načíst ovladač síťové karty. V navazujícím návodu na instalaci Windows 11 budu nicméně předpokládat, že si ctěný čtenář nepřeje online Windows účet založit, a proto se mi bude absence síťového připojení hodit v postupu založení místního uživatelského účtu. Typ síťové karty změníme vybráním virtio v roletkovém menu Model zařízení:
Dále nastavíme virtuální TPM modul - Typ: Emulováno, Model není až tak důležitý, důležitá je Verze: 2.0
Ještě nastavíme topologii procesoru, kterou bude QEMU hlásit hostovanému operačnímu systému. Ve výchozím nastavení Libvirt nastaví, že se virtuální procesory budou hlásit jako jednojádrové procesory v samostatných socketech (paticích), což je pro Windows špatně: Windows 11 Home umí využít pouze jeden socket, Windows 11 Pro jen dva sockety. V seznamu hardware proto vybereme Procesory, dále si rozklikneme Topologie a zaškrtneme Nastavit topologii procesoru ručně. Následně snížíme počet Patic na 1 a počet Jader zvýšíme na požadovaný počet virtuálních CPU jader:
Teď můžeme přidávat potřebný hardware, začneme druhou virtuální CDROM mechanikou, která nám při instalaci Windows poslouží k zavedení VirtIO ovladače disku. V okně se seznamem hardware klikneme na tlačítko Přidat hardware, které by mělo otevřít následující okno:
v tomto okně (ze seznamu HW by mělo být vybráno úložiště) zvolíme Typ zařízení: CDROM zařízení, Typ sběrnice: SATA (SATA by měla být výchozí při volbě Q35 chipsetu), poté klikneme na tlačítko Spravovat... čímž otevřeme dialog:
pomocí kterého vybereme CD image s VirtIO ovladači. Ten jsme si v předstihu stáhli z adresy: https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso, odkazy na variantu latest a vysvětlení variant images jsou na stránce https://github.com/virtio-win/virtio-win-pkg-scripts/blob/master/README.md . Po vybrání image klikneme na tlačítko Zvolit svazek čímž se dostaneme do předchozího okna:
které potvrdíme tlačítkem Dokončit. Výsledek pak vypadá následovně:
Nyní je třeba virtuálnímu stroji přiřadit grafickou kartu, její zvukový kodek a fyzický USB řadič - v dialogu Přidat nový virtuální hardware vybereme PCI zařízení hostitele a v něm vybereme příslušné zařízení, které jsme předtím svázali s ovladačem vfio-pci, viz. kapitola 4.4 tohoto návodu. Začneme tedy grafickou kartou:
Poté co označíme položku grafické karty, klikneme na Dokončit a tím ji přidáme virtuálnímu stroji. Obdobně pokračujeme se zvukovou kartu grafické karty:
a nakonec přidáme fyzický USB řadič, jelikož je USB řadičů v systému více, musíme ten správný vybrat podle jeho PCI adresy, v tomto případě ten s adresou 00:1a.0
:
Výsledek by pak měl vypadat zhruba takto:
Všimněte si, že v seznamu hardware virtuálního stroje je PCI adresa v dekadickém formátu namísto obvyklého hexadecimálního (26 namísto 1A).
Tím jsme vyčerpali možnosti konfigurace ve virt-manageru a další potřebné úpravy budeme muset realizovat přímo v XML popisu virtuálního stroje. Začneme tím, že si znovu rozklikneme Přehled a v něm klikneme na kartu XML.
První úpravu provedeme tak, že do elementu <hyperv>
vložíme tag <vendor_id state="on" value="VIM Inc."/>
do hodnoty atributu value můžete zadat libovolný řetězec (já jsem zadal "VIM Inc."). Výsledná úprava vypadá v kódu takto:
Druhý zásah do kódu spočívá ve vložení elementu <kvm>
obsahující tag <hidden state="on"/>
Výše uvedené úpravy jsou nutné kvůli ovladačům grafické karty (před verzí 465 v případě Nvidie), které by bez těchto úprav detekovaly, že běží ve virtuálním stroji, a odmítly by proto fungovat. Úpravy aplikujeme tlačítkem Použít.
Další, byť volitelnou, úpravou je přidání vstupního zařízení typu evdev s jehož pomocí je možné sdílet klávesnici a myš mezi hostitelským systémem a virtuálním strojem. Alternativně je samozřejmě možné k fyzickému USB řadiči, který jsme přiřadili virtuálnímu stroji, připojit extra klávesnici a myš. V případě, že zvolíte sdílení klávesnice a myši, je třeba do stromu elementu <devices>
přidat:
<input type="evdev">
<source dev="/dev/input/by-id/SOUBOR_ZARIZENI_MYSI"/>
</input>
<input type="evdev">
<source dev="/dev/input/by-id/SOUBOR_ZARIZENI_KLAVESNICE" grab="all" grabToggle="ctrl-ctrl" repeat="on"/>
</input>
Kde:
SOUBOR_ZARIZENI_MYSI
je třeba nahradit názvem souboru zařízení myši na hostitelském stroji (soubor v adresáři /dev/input/by-id/
končící na -event-mouse
)SOUBOR_ZARIZENI_KLAVESNICE
je třeba nahradit názvem souboru zařízení klávesnice na hostitelském stroji (soubor v adresáři /dev/input/by-id/
končící na -event-kbd
).grabToggle
specifikujeme kombinaci kláves pomocí kterých budeme klávesnici a myš přepínat mezi hostitelským strojem a virtuálním strojem. Možné jsou následující kombinace: ctrl-ctrl
, alt-alt
, shift-shift
, meta-meta
, scrolllock
nebo ctrl-scrolllock
. Pro úplnost uvádím, že ctrl-ctrl
znamená současné stisknutí levé a pravé klávesy Ctrl.Úprava s evdev může vypadat následovně:
Po aplikování změn tlačítkem Použít by se měly v seznamu hardware objevit 2 položky (klávesnice a myš) vstupních zařízení typu evdev (v seznamu 2 zařízení Vstup s ikonou myši):
Před spuštěním instalace je potřeba připojit přiřazovanou grafickou k nějakému monitoru, VNC nebo Spice pro zobrazení framebufferu přiřazované grafické karty není možné použít.
Nyní již můžeme kliknout na tlačítko Zahájit instalaci v levé horní části okna, čímž virtuální stroj spustíme. Virtuální stroj by měl začít bootovat z připojeného image instalačního média. Návod na instalaci Windows 11 jsem kvůli rozsahu vyčlenil do samostatného článku.
Po dokončení instalace je třeba virtuální stroj vypnout.
Pokud pro zvukový výstup používáte reproduktory zabudované v monitoru připojeného přes HDMI k přiřazované grafické kartě (a tím vlastně zvukovou kartu integrovanou v grafické kartě), nebo používáte-li extra zvukovou kartu (připojenou např. k USB řadiči přiřazenému virtuálnímu stroji), případně pokud zvukový výstup nepotřebujete, můžete tuto podkapitolu přeskočit.
V opačném případě je třeba pořešit konfiguraci zvukového výstupu, mě se celkem osvědčilo použití PulseAudio backendu QEMU, jeho konfiguraci popíšu na řádcích níže. Pokud již váš systém používá PipeWire, je třeba abyste měli nainstalovaný balíček pipewire-pulse
.
Pro úspěšné zprovoznění zvukového výstupu pod libvirtem je potřeba nastavit libvirt tak, aby spouštěl QEMU pod uživatelem, který spouští virtuální stroje u kterých je potřeba zvukový výstup zprovoznit. Za tímto účelem v /etc/libvirt/qemu.conf
nastavte řádek: user = "uzivatelske-jmeno"
a restartujte službu libvirtd: systemctl restart libvirtd.service
Pozn. V případě, že virtuální stroje na daném počítači spouští vícero uživatelských účtů, je možné nastavit libvirt tak, aby QEMU spouštěl pod rootem.
Nyní k samotné úpravě konfigurace virtuálního stroje; v XML popisu VM vyhledáme tag audio:
ten upravíme/nahradíme:
<audio id="1" type="pulseaudio" serverName="/run/user/1000/pulse/native">
<input mixingEngine="no"/>
<output mixingEngine="no"/>
</audio>
kde číslo 1000 (v cestě /run/user/1000/pulse/native) je ID uživatele, který bude daný virtuální stroj spouštět. Výsledná úprava může vypadat takto:
Pokud by vám řešení s PulseAudio nevyhovovalo nebo jste narazili na nějaké problémy, v ArchWiki je několik dalších možností.
CPU pinning (neboli přidělení/spřažení virtuálních CPU k specifickým fyzickým jádrům hostitelského CPU) je technika, která může výrazně zvýšit výkon a stabilitu virtuálních strojů provozovaných na hypervizoru jako KVM/QEMU. Bez spřažení bude plánovač (scheduler) jádra hostitelského systému přehazovat vlákna vCPU mezi fyzickými CPU jádry a dojde tak degradaci výkonu. S nastavením pinningu a souvisejícím nastavením topologie CPU, viz. kapitola 6.2, si lze docela hodně vyhrát a získat nějaká procenta výkonu ve virtuálním stroji navíc, nicméně vše se odvíjí od topologie (struktura cache, rozložení CPU jader apod.) hostitelského systému, proto zde uvedu příklad obecného pinningu, který zlepší výkon na všech systémech, nicméně nebude zdaleka tak optimální jako vyladěná konfigurace pro konkrétní hardware. Pro zjišťování struktury cache a CPU jsou vhodné příkazy lscpu -e
a lstopo
.
Pod element:
<vcpu placement="static">4</vcpu>
Vložíme:
<iothreads>1</iothreads>
<cputune>
<vcpupin vcpu="0" cpuset="2"/>
<vcpupin vcpu="1" cpuset="3"/>
<vcpupin vcpu="2" cpuset="4"/>
<vcpupin vcpu="3" cpuset="5"/>
<emulatorpin cpuset="0"/>
<iothreadpin iothread="1" cpuset="1"/>
</cputune>
V ArchWiki je uvedeno varování před přiřazováním zařízení, která nepodporují reset. Volně přeloženo se v daném odstavci uvádí:
Při vypínání virtuálního počítače jsou všechna zařízení používaná hostem deinicializována jeho operačním systémem v rámci přípravy na vypnutí. V tomto stavu jsou tato zařízení nefunkční a před obnovením jejich normálního provozu je nutné je vypnout. Linux si s tímto vypínáním poradí sám, ale pokud zařízení nemá známé metody resetování, zůstává v tomto vypnutém stavu a stává se nedostupným. Protože Libvirt i Qemu očekávají, že všechna hostitelská PCI zařízení budou připravena k opětovnému připojení k hostiteli před úplným zastavením virtuálního stroje, při výskytu zařízení, které nepůjde resetovat, zůstanou viset ve stavu „Vypínání“, kdy je nebude možné znovu spustit, dokud nebude restartován hostitelský systém. Doporučuje se proto předávat pouze taková PCI zařízení, která je jádro schopno resetovat, o čemž svědčí přítomnost souboru reset v uzlu sysfs PCI zařízení, například /sys/bus/pci/devices/0000:00:1a.0/reset
.
Pro zjištění, zda dané zařízení podporuje je v ArchWiki uveden následující skript (mírně upraveno):
for iommu_group in $(find /sys/kernel/iommu_groups/ -maxdepth 1 -mindepth 1 -type d|sort); do
echo "IOMMU group $(basename "$iommu_group")";
for device in $(\ls -1 "$iommu_group"/devices/); do
if [[ -e "$iommu_group"/devices/"$device"/reset ]]; then echo -n "[RESET]"; fi;
echo -n $'\t';lspci -nns "$device";
done;
done
Výše uvedený skript na vzorovém systému vypsal (prefix [RESET] značí zařízení podporující reset):IOMMU group 0
[RESET] 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3 Processor Integrated Graphics Controller [8086:041a] (rev 06)
IOMMU group 1
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3 Processor DRAM Controller [8086:0c08] (rev 06)
IOMMU group 10
[RESET] 00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 [8086:8c14] (rev d5)
IOMMU group 11
[RESET] 00:1c.3 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 [8086:8c16] (rev d5)
IOMMU group 12
[RESET] 00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 05)
IOMMU group 13
00:1f.0 ISA bridge [0601]: Intel Corporation C226 Series Chipset Family Server Advanced SKU LPC Controller [8086:8c56] (rev 05)
00:1f.2 SATA controller [0106]: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c02] (rev 05)
00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller [8086:8c22] (rev 05)
IOMMU group 14
[RESET] 05:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)
IOMMU group 15
[RESET] 06:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network Connection [8086:1533] (rev 03)
IOMMU group 2
00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06)
[RESET] 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] [10de:1380] (rev a2)
01:00.1 Audio device [0403]: NVIDIA Corporation GM107 High Definition Audio Controller [GeForce 940MX] [10de:0fbc] (rev a1)
IOMMU group 3
[RESET] 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller [8086:0c0c] (rev 06)
IOMMU group 4
00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05)
IOMMU group 5
00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04)
IOMMU group 6
[RESET] 00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 05)
IOMMU group 7
[RESET] 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] (rev 05)
IOMMU group 8
[RESET] 00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #1 [8086:8c10] (rev d5)
IOMMU group 9
[RESET] 00:1c.1 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev d5)
[RESET] 03:00.0 PCI bridge [0604]: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge [1b21:1080] (rev 03)
[RESET] 04:02.0 FireWire (IEEE 1394) [0c00]: VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller [1106:3044] (rev c0)
Poznámka: Na 2 testovacích systémech s GPU NVIDIA, nepodporoval reset HD Audio controller grafické karty. Na obou systémech, ale přitom nedošlo k žádným výše popisovaným problémům a zvukový výstup přes HDMI bylo normálně možné používat. Tak si nejsem jistý, zda již nebyla nějakým způsobem problematika resetu v KVM/QEMU vyřešena, nebo zda reset HDMI HD Audio controlleru prevede nadřazené GPU, které reset samozřejmě podporuje viz. uvedený výpis.
2022 - 2025 vim