Kotipalvelimen yksi näytönohjain riittää nykyään moneen käyttötarkoitukseen samaan aikaan. Yksi Proxmox VE 9 -isäntä voi ajaa Windows-pelivirtuaalikonetta ja Linux-tekoälyvirtuaalikonetta samalla RTX-kortilla, kunhan GPU-läpivienti on tehty oikein. Tässä oppaassa käydään läpi koko prosessi nollasta toimivaan asetukseen: BIOS-valmistelut, IOMMU:n käyttöönotto, VFIO-moduulit, virtuaalikoneen rakentaminen ja lopuksi suorituskyvyn viilaus. Kirjoitushetkellä 23. syyskuuta 2026 tuoreimmat Nvidia-ajurit ovat 595.104.02-tuotantohaarassa ja 615.71.09-uusien-ominaisuuksien haarassa, ja niiden erot vaikuttavat suoraan siihen, miten läpivienti kannattaa rakentaa.

Opas sopii kotilabran rakentajille, pienyrityksen IT-vastaavalle ja kehittäjille, jotka haluavat oman GPU-pohjaisen tekoälypalvelimen ilman pilvilaskutusta. Vaadittavat taidot ovat perustason Linux-komentorivi ja hieman rohkeutta BIOS-asetusten kanssa. Koko prosessi ensikertalaiselta vie noin puolitoista-kaksi tuntia, kun laitteisto on jo pöydällä ja käyttöjärjestelmä asennettuna. Tämä artikkeli kuuluu sivustomme laitteisto-osioon, jossa käsittelemme säännöllisesti näytönohjaimiin, suorittimiin ja kotilabroihin liittyviä käytännön oppaita.

Miksi yksi GPU riittää nyt kahteen käyttötarkoitukseen

Näytönohjainten hinnat eivät ole helpottaneet syksyllä 2026. Muistipula on nostanut GPU-hintoja tasaisesti koko vuoden, ja moni kotilabran rakentaja joutuu miettimään tarkkaan, kannattaako ostaa toinen kortti vai jakaa yksi useampaan tarkoitukseen. Samaan aikaan GPU-pohjaisten laskentapalvelujen vuokraus on kallistunut isoissa pilvipalveluissa selvästi, mikä on ohjannut kotilabran harrastajia rakentamaan omaa laskentakapasiteettia entistä useammin.

GPU-läpivienti ratkaisee juuri tämän ongelman. Sama fyysinen kortti voi palvella iltaisin peliharrastusta Windows-virtuaalikoneessa ja päivisin paikallista tekoälymallia Linux-virtuaalikoneessa, eikä kumpikaan käyttötarkoitus vaadi omaa erillistä laitetta. Tämä on eri asia kuin tavallinen näytönohjaimen jakaminen ajurien tasolla, koska läpivienti antaa virtuaalikoneelle suoran, käytännössä paljaan metallin tasoisen pääsyn laitteistoon PCIe-väylän yli. Jos olet aiemmin puhdistanut Nvidia-ajureita isäntäkoneella tai mitannut GPU:n suorituskykyä paljaalla metallilla, huomaat että läpivienti tuottaa lähes identtiset luvut oikein viritettynä.

Läpivienti, toinen GPU vai pilvivuokraus: mikä kannattaa

Ennen kuin ryhdyt purkamaan koneen sisuksia, kannattaa vertailla vaihtoehtoja rehellisesti. Kolme reittiä johtavat samaan lopputulokseen, mutta hyvin eri kustannusrakenteella. Ensimmäinen on tämän oppaan mukainen GPU-läpivienti, jossa yksi jo omistettu kortti jaetaan ajassa kahden käyttötarkoituksen kesken. Toinen on toisen fyysisen näytönohjaimen ostaminen kokonaan omaan koneeseensa, jolloin kumpikin virtuaalikone tai käyttötarkoitus saa oman raudan eikä vuorottelua tarvita. Kolmas on GPU-laskentakapasiteetin vuokraaminen pilvipalvelusta tarpeen mukaan.

Aiemmin käsittelimme, että GPU-pilvivuokraus voi suurilla hyperscaler-toimijoilla olla jopa moninkertaisesti kalliimpaa kuin pienemmillä eurooppalaisilla vaihtoehdoilla, ja että esimerkiksi Hetznerin GEX45-palvelin hinnoittelee GPU-tunnin selvästi maltillisemmin. Silti jatkuva kuukausivuokra kasvaa nopeasti isommaksi kuin kertaostettu kortti, jos käyttöä on säännöllisesti useita tuntia viikossa. Toisen fyysisen kortin ostaminen puolestaan on nykyisessä muistipulan vaivaamassa markkinassa kallista, ja moni koti-käyttäjä ei halua maksaa täyttä hintaa kortista, joka on käytössä vain muutaman tunnin päivässä. GPU-läpivienti on tässä vertailussa se vaihtoehto, joka ei maksa lainkaan lisää rahaa, vaan vaatii ainoastaan aikaa asetusten tekemiseen kerran. Suomessa ja muualla Pohjolassa sähkön hinta vaikuttaa myös valintaan enemmän kuin monessa muussa maassa: kahden erillisen aina päällä olevan koneen pitäminen käynnissä maksaa pitkässä juoksussa selvästi enemmän sähkölaskussa kuin yhden tehokkaan koneen, joka jakaa yhden GPU:n ajassa kahden käyttötarkoituksen kesken. Tämä puoltaa läpivientiä erityisesti niille, jotka maksavat sähkönsä pörssihinnan mukaan ja seuraavat kulutustaan tarkasti.

Ostoslista ja budjetointi ennen aloitusta

Suurin osa lukijoista tekee läpiviennin laitteistolla, joka on jo pöydällä, mutta jos rakennat konetta juuri tätä käyttötarkoitusta varten, muutama hankintapäätös kannattaa tehdä tietoisesti. Valitse emolevy, jonka valmistaja mainitsee tuotesivulla nimenomaan IOMMU- tai VT-d-tuen, älä oleta sitä automaattisesti kaikilla samaan piirisarjaan perustuvilla malleilla. Varaa virtalähteeseen riittävästi tehoa myös silloin, kun isännällä on oma kevyt näytönohjain GPU:n lisäksi, koska molemmat kortit voivat olla käynnissä samaan aikaan.

Toinen, halvempi näytönohjain isännän omaan käyttöön kannattaa hankkia, jos budjetti sen sallii, koska se säästää huomattavasti aikaa jatkuvassa ylläpidossa: isäntä säilyttää oman näytön ja hallintakäyttöliittymän koko ajan, eikä sitä tarvitse hoitaa yksinomaan SSH-yhteyden kautta. Muistin osalta 32 gigatavua on käytännön minimimäärä, jos isäntä pyörittää samaan aikaan muitakin palveluita kuin yhtä GPU-virtuaalikonetta, ja tekoälykäytössä kannattaa harkita jopa 64 gigatavua, koska suuret kielimallit varaavat helposti kymmeniä gigoja jo itse mallin lataamiseen.

Kaapeloinnin osalta varmista, että virtalähteessä on riittävä määrä erillisiä PCIe-virtaliittimiä molemmille korteille, äläkä jaa samaa kaapelia haaroittimella kahden vaativan kortin kesken. Tapauskoon sisällä kannattaa jättää muutaman sentin ilmarako korttien väliin, jos molemmat kortit ovat paksuja kolmen tuulettimen malleja, koska ahtaassa kotelossa lämpötila nousee helposti korkeammaksi kuin yksittäisen kortin asennuksessa.

Esitiedot ja laitteistovaatimukset

Ennen kuin avaat BIOS-valikon, tarkista että laitteisto ja ohjelmistoversiot täyttävät seuraavat vähimmäisvaatimukset. Vanhemmalla emolevyllä tai puuttuvalla IOMMU-tuella koko projekti kaatuu ensimmäiseen vaiheeseen, joten tämä taulukko kannattaa käydä läpi rauhassa ennen kuin ruuvaat mitään auki.

KomponenttiVähimmäisvaatimusHuomio
IsäntäkäyttöjärjestelmäProxmox VE 9.0 tai uudempiPerustuu Debian 13 -kerneliin, tukee UEFI-vieraita oletuksena
SuoritinIntel VT-d tai AMD-ViTarkista emolevyn käsikirjasta, halvimmat toimisto-emolevyt eivät tue tätä
Emolevyn BIOSAbove 4G Decoding + Re-Size BAR tukiPakollinen RTX 30-sarjalle ja uudemmille sekä AMD RDNA2/3/4-korteille
Nvidia-ajuri (vieras, tuotanto)595.104.02Julkaistu 21.9.2026, parempi Wayland-tuki
Nvidia-ajuri (vieras, uusi ominaisuus)615.71.09Vulkan/Proton-parannukset, NVIDIA Reflex Vulkan-peleille
Nvidia vGPU-ohjelmisto (vaihtoehto)20.2Manager 595.91.04/596.84, vierasajuri 595.91.07/596.86, elokuu 2026
Toinen näytönohjain isännälleSuositeltu, ei pakollinenIlman sitä isäntä menettää oman näytön kun VM käynnistyy
Muisti32 Gt+16 Gt riittää kevyeen käyttöön, mutta AI-kuormat syövät nopeasti

Huomaa ero kahden Nvidia-ajurihaaran välillä. 595-sarja on vakaampi tuotantohaara ja sopii AI-työkuormille, joissa ajuri ei saa kaatua kesken pitkän koulutusajon. 615-sarja tuo uudempia Vulkan- ja Proton-ominaisuuksia, joten pelivirtuaalikoneeseen se on usein parempi valinta. Molemmat toimivat läpiviennin kanssa identtisesti, koska itse VFIO-mekanismi ei riipu ajuriversiosta lainkaan, vaan se toimii yhtä matalalla tasolla kuin PCIe-väylä itse.

Ota myös varmuuskopio Proxmox-isännän konfiguraatiosta ennen kuin aloitat. Riittää, että kopioit tiedostot /etc/default/grub, /etc/modules-load.d/ ja /etc/modprobe.d/ talteen, jotta virhetilanteessa pääset palaamaan lähtötilanteeseen nopeasti sen sijaan, että joutuisit asentamaan Proxmoxin uudelleen.

GPU-läpivienti vai vGPU: kumpi sopii sinulle

Ennen ensimmäistä komentoa kannattaa valita lähestymistapa, koska ne johtavat täysin eri konfiguraatioon ja osin eri laitteistovaatimuksiin.

Täysi PCI-läpivienti (VFIO)

Koko näytönohjain irrotetaan isännältä ja annetaan yhdelle virtuaalikoneelle kokonaan. Isäntä ei näe korttia enää lainkaan sen jälkeen kun VM on käynnissä, aivan kuin kortti olisi fyysisesti kytketty irti emolevystä. Tämä on tämän oppaan pääpolku, koska se toimii millä tahansa kuluttajakortilla ja on täysin ilmainen ratkaisu. Sopii parhaiten tilanteeseen, jossa yksi käyttäjä siirtyy käyttötarkoituksesta toiseen, esimerkiksi töiden jälkeen pelaamisesta yöllä ajettavaan mallikoulutukseen.

Nvidia vGPU -ohjelmisto

vGPU jakaa yhden fyysisen kortin useiden virtuaalikoneiden kesken samanaikaisesti hallintaohjaimen (vGPU manager) avulla. Tämä vaatii Nvidian tuetun datakeskuskortin ja lisenssin, eikä toimi tavallisilla GeForce-kuluttajakorteilla samalla tavalla kuin täysi läpivienti. Kotilabrassa tämä on harvoin järkevä valinta kustannussyistä, mutta pienyrityksen palvelinsalissa se kannattaa, jos useampi käyttäjä tarvitsee samaa GPU:ta samaan aikaan eikä vuorottelu VM:ien välillä riitä. Nvidian oma vGPU-dokumentaatio listaa tuetut kortit ja ohjelmistoversiot yksityiskohtaisesti, ja sitä kannattaa tarkistaa aina ennen hankintapäätöstä. Käytännössä vGPU tulee kysymykseen vasta silloin, kun useampi käyttäjä tarvitsee jatkuvaa, samanaikaista pääsyä GPU-laskentaan esimerkiksi etätyöpöytäympäristössä, eikä vuorottelu yhden kortin ja kahden virtuaalikoneen välillä riitä kattamaan tarvetta.

OminaisuusTäysi läpivientivGPU
Tuettu laitteistoKäytännössä mikä tahansa PCIe-GPUVain Nvidian listaamat datakeskuskortit
Lisenssikustannus0 €Vuosilisenssi per käyttäjä/GPU
Käyttäjiä per kortti1 samanaikaisestiUseita samanaikaisesti
Isäntä näkee GPU:n käytön aikanaEiOsittain, hallintakerroksen kautta
Soveltuu kotilabraanErinomaisestiHarvoin kannattava

Mitä IOMMU tarkalleen tekee taustalla

IOMMU (Input-Output Memory Management Unit) on suorittimen ja piirisarjan yhteistyössä toteuttama muistinkäännösyksikkö, joka valvoo mitä muistialueita mikä PCI-laite saa lukea ja kirjoittaa suoraan DMA-siirroilla. Ilman IOMMU:a mikä tahansa PCI-laite pääsisi periaatteessa käsiksi koko fyysiseen muistiin, mikä olisi vaarallista jos laite annetaan virtuaalikoneen käyttöön. IOMMU rakentaa laitteelle omat käännöstaulut, jotka rajaavat sen näkemän muistiavaruuden vain siihen alueeseen, joka kuuluu kyseiselle virtuaalikoneelle.

Tämä on juuri se mekanismi, joka tekee turvallisen GPU-läpiviennin mahdolliseksi: näytönohjain voi kirjoittaa suoraan sille osoitettuun muistialueeseen täydellä nopeudella, mutta ei pääse vahingossa tai tahallisesti koskemaan isännän tai muiden virtuaalikoneiden muistiin. IOMMU-ryhmät, joita käsiteltiin vaiheessa 5, ovat käytännössä emolevyn piirisarjan tapa ryhmitellä laitteet sen mukaan, kuinka tarkasti niiden DMA-liikennettä pystytään erottelemaan toisistaan. Mitä uudempi ja kalliimpi piirisarja, sitä hienojakoisempaa erottelu tyypillisesti on.

Access Control Services (ACS) on PCIe-standardin osa, joka määrittää kuinka tarkasti yksittäiset PCIe-portit eristävät laitteidensa liikenteen toisistaan silloinkin, kun laitteet ovat kytkettyinä saman fyysisen PCIe-kytkimen taakse. Halvemmissa kuluttajaemolevyissä ACS-tuki on usein puutteellinen tai puuttuu kokonaan, minkä seurauksena useampi PCIe-laite päätyy samaan IOMMU-ryhmään vaikka niitä haluaisi käsitellä erikseen. Tämä on suora syy vaiheessa 5 mainittuun tilanteeseen, jossa GPU pitää siirtää toiseen korttipaikkaan tai turvautua ACS-ohituspatchiin.

Muistilista: tarkista nämä ennen ensimmäistä käynnistystä

Seuraava lyhyt lista kannattaa käydä läpi juuri ennen kuin aloitat varsinaiset komentorivivaiheet. Se säästää turhia edestakaisia BIOS-käyntejä, koska useimmat niistä vaativat fyysisen uudelleenkäynnistyksen näppäimistön ääreltä.

  • Proxmox VE on päivitetty versioon 9.0 tai uudempaan, ja järjestelmä on käynnistetty kerran päivityksen jälkeen.
  • Emolevyn laiteohjelmisto (BIOS/UEFI) on päivitetty valmistajan uusimpaan vakaaseen versioon ennen IOMMU-asetusten muuttamista.
  • Näytönohjaimen malli ja PCIe-korttipaikka on tiedossa etukäteen, jotta osaat tunnistaa oikean laitteen lspci-tulosteesta.
  • Isännälle on varattu jokin vaihtoehtoinen pääsytapa (SSH, IPMI tai toinen näyttö), koska ensisijainen näyttö katoaa isännältä läpiviennin jälkeen.
  • Tärkeät tiedostot on varmuuskopioitu, ja tiedät miten palaat lähtötilanteeseen, jos jokin vaihe menee pieleen.

Vaihe 1: Tarkista suorittimen ja emolevyn virtualisointituki

Kirjaudu Proxmox-isäntään SSH:lla ja tarkista löytyykö järjestelmästä IOMMU-tuki ennen kuin kosket BIOS-asetuksiin lainkaan.

egrep -c '(vmx|svm)' /proc/cpuinfo
dmesg | grep -e DMAR -e IOMMU
lspci -nnk | grep -A3 -i nvidia

Jos ensimmäinen komento palauttaa 0, suorittimessa itsessään ei ole virtualisointitukea eikä eteenpäin kannata jatkaa ennen laitteistopäivitystä. vmx viittaa Intelin VT-x-tukeen ja svm AMD:n vastaavaan. dmesg-komennon tuloksessa pitäisi näkyä rivejä kuten “DMAR: IOMMU enabled”, jos BIOS-asetus on jo valmiiksi päällä. Useimmilla uusilla työpöytäsuorittimilla itse suoritintuki on kunnossa, mutta emolevyn laiteohjelmisto rajoittaa toimintoa silti hyvin usein oletusasetuksissa.

Vaihe 2: Ota IOMMU, Above 4G Decoding ja Re-Size BAR käyttöön BIOSissa

Käynnistä palvelin uudelleen ja siirry BIOS/UEFI-asetuksiin. Etsi seuraavat kohdat, jotka sijaitsevat eri emolevyillä eri valikoissa mutta useimmiten Advanced- tai Chipset-osiossa:

  • Intel VT-d tai AMD-Vi / IOMMU: Enabled
  • Above 4G Decoding: Enabled (pakollinen RTX 30-sarjalle ja uudemmille)
  • Re-Size BAR Support: Enabled
  • SR-IOV Support: Enabled, jos vaihtoehto näkyy valikossa
  • CSM / Legacy Boot: Disabled (UEFI-vieraat vaativat puhtaan UEFI-käynnistyksen)

Tallenna asetukset ja käynnistä Proxmox uudelleen. Tämä on vaihe, jossa suurin osa epäonnistuneista läpivienneistä syntyy, koska Above 4G Decoding on oletuksena pois päältä useimmilla emolevyillä eikä virhe näy missään lokissa vielä tässä vaiheessa. Ongelma paljastuu vasta myöhemmin, kun virtuaalikone kaatuu käynnistyksen yhteydessä ilman selkeää syytä.

Valikkojen nimet vaihtelevat valmistajan mukaan, mikä hämmentää monia ensikertalaisia. ASUS-emolevyillä asetus löytyy usein kohdasta Advanced > PCI Subsystem Settings, MSI:llä kohdasta Settings > Advanced > PCI Subsystem, ja Gigabytella kohdasta Chipset > Above 4G Decoding suoraan päävalikon alla. Jos asetusta ei löydy suoraan, hae emolevyn käyttöoppaasta hakusanalla “Above 4G” tai “Re-Size BAR”, koska nimi voi vaihdella laiteohjelmistoversion mukaan samallakin mallilla.

Vaihe 3: Aktivoi IOMMU kernelin käynnistysparametreissa

Proxmox VE 9 käyttää oletuksena systemd-boot-latausohjelmaa tai GRUB:ia riippuen asennustavasta. Tarkista kumpi on käytössä komennolla proxmox-boot-tool status. GRUB-pohjaisessa asennuksessa muokkaa tiedostoa /etc/default/grub.

# Intel-suorittimelle
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"

# AMD-suorittimelle
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"

update-grub
reboot

iommu=pt-parametri jättää muut PCI-laitteet isännän omaan hallintaan ja rajoittaa VFIO:n koskemaan vain niitä laitteita, jotka erikseen sidotaan siihen. Jos käytössä on systemd-boot, sama rivi lisätään tiedostoon /etc/kernel/cmdline ja päivitetään komennolla proxmox-boot-tool refresh. Käynnistyksen jälkeen kannattaa tarkistaa /proc/cmdline, jotta näkee ovatko parametrit varmasti tulleet mukaan.

Vaihe 4: Lataa VFIO-moduulit käynnistyksessä

VFIO (Virtual Function I/O) on Linux-kernelin kehys, jonka avulla PCI-laite voidaan antaa suoraan virtuaalikoneelle. Neljä moduulia täytyy ladata joka käynnistyksellä, ennen kuin mikään muu ajuri ehtii varata näytönohjaimen itselleen.

cat << EOF >> /etc/modules-load.d/vfio.conf
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd
EOF

update-initramfs -u -k all
reboot

update-initramfs on tärkeä eikä sitä saa ohittaa, koska moduulit täytyy olla saatavilla jo initramfs-vaiheessa, siis ennen varsinaisen käyttöjärjestelmän täyttä käynnistymistä. Jos tämä vaihe unohtuu, Nvidian oma ajuri ehtii ladata kortin ensin ja koko läpivienti epäonnistuu myöhemmin ilman selkeää virheilmoitusta.

Vaihe 5: Tunnista GPU ja tarkista IOMMU-ryhmät

Seuraavaksi selvitetään GPU:n PCI-osoite ja laitetunnukset (vendor:device ID). Näytönohjaimella on käytännössä aina kaksi PCI-funktiota: näyttöpiiri ja HDMI/DisplayPort-äänilaite, ja molemmat tarvitaan mukaan läpivientiin, koska ne kuuluvat samaan fyysiseen komponenttiin.

lspci -nn | grep -i nvidia

Esimerkkituloste omalla RTX-testipalvelimella:

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation [10de:2684]
01:00.1 Audio device [0403]: NVIDIA Corporation [10de:22bc]

Merkitse muistiin molemmat tunnisteet (tässä esimerkissä 10de:2684 ja 10de:22bc) sekä PCI-osoitteet (01:00.0 ja 01:00.1). Tarkista lisäksi mitkä muut laitteet jakavat samaa IOMMU-ryhmää, koska koko ryhmä pitää siirtää virtuaalikoneelle yhdessä, ei osittain.

for d in /sys/kernel/iommu_groups/*/devices/*; do
  n=${d#*/iommu_groups/*}; n=${n%%/*}
  printf 'IOMMU Group %s: ' "$n"
  lspci -nns "${d##*/}"
done

Jos GPU on samassa ryhmässä muiden, isännälle tärkeiden laitteiden kanssa (esimerkiksi levyohjain tai verkkokortti), joudut usein siirtämään näytönohjaimen fyysisesti toiseen PCIe-korttipaikkaan, joka kuuluu eri IOMMU-ryhmään. Tämä riippuu suoraan emolevyn piirisarjan sisäisestä reitityksestä, eikä sitä voi korjata ohjelmallisesti kuin ACS-ohituksella, joka heikentää eristystä.

Vaihe 6: Sido GPU vfio-pci-ajuriin ja estä isäntäajuri

Nvidian oma ajuri pitää estää lataamasta korttia isännälle, jotta vfio-pci saa sen käyttöönsä ennen kuin mikään muu prosessi ehtii siihen käsiksi käynnistyksen aikana.

echo "options vfio-pci ids=10de:2684,10de:22bc" > /etc/modprobe.d/vfio.conf
echo "softdep nvidia pre: vfio-pci" >> /etc/modprobe.d/vfio.conf
echo "softdep nouveau pre: vfio-pci" >> /etc/modprobe.d/vfio.conf
echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
echo "blacklist nvidia" >> /etc/modprobe.d/blacklist.conf

update-initramfs -u -k all
reboot

Vaihda esimerkin laitetunnukset omiksi, vaiheessa 5 kirjattuihisi. Uudelleenkäynnistyksen jälkeen tarkista, että driver-kenttä näyttää vfio-pci:tä, ei nvidiaa tai nouveauta:

lspci -nnk | grep -A3 -i nvidia
# odotettu tuloste sisältää rivin:
# Kernel driver in use: vfio-pci

Jos rivi puuttuu tai näyttää edelleen vanhaa ajuria, palaa vaiheeseen 4 ja tarkista, että initramfs on todella päivittynyt uusilla asetuksilla. Tämä on yleisin syy siihen, että läpivienti “ei ota” ensimmäisellä yrittämällä.

Vaihtoehtoinen tapa saavuttaa sama lopputulos ilman pysyvää blacklist-tiedostoa on driverctl-työkalu, joka sallii ajurin sitomisen ja vapauttamisen ajonaikaisesti ilman uudelleenkäynnistystä. Tämä on kätevä erityisesti testausvaiheessa, kun haluat kokeilla eri asetuksia nopeasti.

apt install driverctl
driverctl set-override 0000:01:00.0 vfio-pci
driverctl set-override 0000:01:00.1 vfio-pci
driverctl list-overrides

driverctl-menetelmä ei vaadi initramfs-päivitystä eikä uudelleenkäynnistystä, mutta ylikirjoitukset eivät säily automaattisesti seuraavaan käynnistykseen, jos et erikseen ota käyttöön driverctl:n omaa persist-tilaa. Pysyvään tuotantoasetukseen blacklist- ja modprobe-tiedostot ovat siksi luotettavampi valinta, mutta driverctl on erinomainen apuväline nopeaan kokeiluun ennen lopullista konfiguraatiota.

Vaihe 7: Luo virtuaalikone UEFI-tilassa

Luo Proxmoxin web-käyttöliittymässä uusi virtuaalikone. Käytä seuraavia asetuksia, koska nämä ovat käytännössä pakollisia modernille GPU-läpiviennille.

  • BIOS: OVMF (UEFI), ei SeaBIOS
  • Machine: q35 (viimeisin versio)
  • Lisää EFI-levy (EFI Disk) samalla ohjatulla toiminnolla
  • CPU-tyyppi: host, jotta vieras näkee isännän täyden käskykannan
  • SCSI-ohjain: VirtIO SCSI single, parempi levyn suorituskyky

Windows-vierasta varten muista lisätä myös VirtIO-ajurien ISO-levykuva toiseen CD-asemaan, koska Windows ei tunnista VirtIO-verkko- tai levylaitteita oletuksena asennusvaiheessa. Ilman tätä Windows-asennus ei löydä levyä lainkaan.

Windows 11 -vierasjärjestelmän TPM- ja Secure Boot -vaatimukset

Jos pelivirtuaalikoneeseen asennetaan Windows 11, käyttöjärjestelmän asennusohjelma vaatii virtuaalisen TPM 2.0 -sirun ja usein myös Secure Bootin, aivan kuten fyysisellä koneella. Proxmox tukee tätä swtpm-ohjelmistopohjaisen TPM-emuloinnin kautta, joka lisätään virtuaalikoneelle omana levylaitteenaan.

qm set 101 --tpmstate0 local-lvm:1,version=v2.0
qm set 101 --bios ovmf
qm set 101 --machine q35

Secure Boot kannattaa jättää oletuksena päälle OVMF:n omilla esiladatuilla Microsoft-sertifikaateilla, koska Windows 11:n asennusohjelma tarkistaa tämän asennuksen alussa. Nvidian allekirjoitetut ajurit toimivat Secure Bootin kanssa suoraan ongelmitta, mutta jos asennat myöhemmin allekirjoittamattomia lisäosia vierasjärjestelmään, Secure Boot täytyy tilapäisesti kytkeä pois OVMF-asetuksista Proxmoxin web-käyttöliittymässä VM:n laitteistonäkymän kautta.

Vaihe 8: Liitä GPU virtuaalikoneen konfiguraatioon

GPU liitetään suoraan VM:n konfiguraatiotiedostoon, koska web-käyttöliittymän PCI-lisäysvalikko ei aina tarjoa kaikkia tarvittavia lippuja. Muokkaa tiedostoa /etc/pve/qemu-server/<VMID>.conf. Proxmoxin oma virallinen wiki-dokumentaatio listaa kaikki hostpci-rivin tukemat parametrit, jos tarvitset tähän listaan harvinaisempia lippuja.

hostpci0: 01:00,pcie=1,x-vga=1
machine: q35
bios: ovmf
cpu: host
efidisk0: local-lvm:vm-101-disk-1,efitype=4m
args: -cpu host,kvm=off

Kirjoittamalla PCI-osoitteen muodossa 01:00 ilman funktionumeroa Proxmox liittää automaattisesti molemmat funktiot (näyttö ja äänilaite). x-vga=1-lippu kertoo QEMU:lle, että tämä on ensisijainen näyttölaite. args-rivin kvm=off tarvitaan vain, jos Nvidian ajuri valittaa “Code 43” -virheestä havaitessaan virtuaaliympäristön, mikä on ollut ajoittainen ongelma erityisesti GeForce-kuluttajakorteilla.

Jos näytönohjain on aiemmin toiminut isännän ensisijaisena näyttönä ja sen BIOS on siksi jo alustettu (POST) emolevyn puolesta, virtuaalikone ei aina saa korttia täysin puhtaaseen tilaan. Tässä tapauksessa kortin oma vBIOS-ROM kannattaa purkaa talteen ja liittää erikseen VM-konfiguraatioon romfile-parametrilla.

# pura vBIOS toiselta koneelta tai GPU-Z:lla Windowsissa,
# tallenna tiedosto Proxmoxiin /usr/share/kvm/ -hakemistoon
hostpci0: 01:00,pcie=1,x-vga=1,romfile=rtx5090.rom

Tämä ratkaisee tilanteen, jossa näyttö jää mustaksi vain silloin, kun sama kortti on aiemmin ollut kytkettynä näyttöön isäntäkäynnistyksen aikana. Jos GPU on ollut koko ajan pelkkä laskentakortti eikä isännän ensisijainen näyttö, romfile-parametria ei tarvita lainkaan.

Vaihe 9: Käynnistä VM ja asenna vierasajurit

Käynnistä virtuaalikone ja asenna käyttöjärjestelmä normaalisti. Kun perusasennus on valmis, asenna Nvidia-ajuri vierasjärjestelmän sisällä, ei koskaan isännässä.

wget https://download.nvidia.com/XFree86/Linux-x86_64/615.71.09/NVIDIA-Linux-x86_64-615.71.09.run
chmod +x NVIDIA-Linux-x86_64-615.71.09.run
./NVIDIA-Linux-x86_64-615.71.09.run

Windows-vieraalle riittää tavallinen ajurien asennusohjelma Nvidian sivuilta, aivan kuten fyysisellä koneella. Käynnistä vieras uudelleen asennuksen jälkeen ja tarkista laitehallinnasta, että näytönohjain näkyy virheettömänä.

Vaihe 10: Vahvista toiminta ja testaa suorituskyky

Aja vierasjärjestelmässä nvidia-smi ja tarkista, että kortti näkyy oikein tunnistettuna ja täydellä muistimäärällä.

nvidia-smi
+-----------------------------------------------------------------------+
| NVIDIA-SMI 615.71.09    Driver Version: 615.71.09   CUDA Version: 13.0|
|-------------------------------+----------------------+----------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr|
|===============================+======================+================|
|   0  NVIDIA GeForce RTX 5090  | 00000000:01:00.0  On  |            N/A |
+-----------------------------------------------------------------------+

Jos GPU näkyy tässä tulosteessa täydellä muistimäärällä, läpivienti toimii. Testaa lopuksi todellisella kuormalla: peli vierasjärjestelmässä tai python3 -c "import torch; print(torch.cuda.is_available())" tekoälykuormaa varten. Fyysiseen koneeseen verrattuna suorituskykyhäviö on tyypillisesti muutaman prosentin luokkaa, kun host-CPU-tyyppi ja hugepages on määritetty oikein. Ero on samaa suuruusluokkaa kuin GPU-benchmarkkaus paljaalla metallilla osoittaa normaalinkin ajuripäivityksen aiheuttavan.

Vaihe 11: Viilaa suorituskykyä CPU-pinningillä ja hugepages-muistilla

Kun perusläpivienti toimii, viimeinen viilaus tuo lisää tasaisuutta erityisesti peli- ja reaaliaikaisiin AI-kuormiin. Tämä on samaa periaatetta kuin fyysisen koneen BIOS-viritys Ryzenille ja RTX-kortille, mutta virtuaalikoneen puolella se tehdään konfiguraatiotiedoston kautta.

# /etc/pve/qemu-server/<VMID>.conf
hugepages: 1024
numa: 1
cpu: host,flags=+aes
cores: 8
# sido tietyt ydinparit VM:lle isolcpus-parametrilla GRUB:issa
# GRUB_CMDLINE_LINUX_DEFAULT="... isolcpus=4-11"

Hugepages vähentää muistinhallinnan ylimääräistä työtä ja pienentää kehysaikojen vaihtelua peleissä. isolcpus varaa fyysiset ydinparit yksinomaan virtuaalikoneelle, jolloin isäntä ei kilpaile niistä samaan aikaan. NUMA-asetus kannattaa ottaa käyttöön erityisesti kaksisuoritinjärjestelmissä, joissa muisti on jaettu useamman NUMA-solmun kesken.

Kannattaa myös tarkistaa isännän suorittimen taajuusohjaustila. Jos käytössä on powersave-tila oletuksena, suorittimen ytimet skaalautuvat alas kuormituksen vähentyessä ja skaalautuvat takaisin ylös vasta pienellä viiveellä, mikä näkyy peleissä satunnaisina kehysaikapiikkeinä. Vaihtamalla ohjaustila performance-tilaan (cpupower frequency-set -g performance) ytimet pysyvät korkealla taajuudella jatkuvasti, mikä kuluttaa hieman enemmän sähköä mutta tasoittaa suorituskykyä merkittävästi läpivienti-VM:ssä.

Suorituskyvyn seuranta jatkuvassa käytössä

Kun läpivienti on saatu toimimaan, kannattaa asentaa vierasjärjestelmään nvtop-työkalu, joka näyttää GPU:n kuormitusprosentin, muistinkäytön ja lämpötilan reaaliajassa suoraan komentoriviltä. Isännän puolella Proxmoxin oma web-käyttöliittymä näyttää edelleen suorittimen, muistin ja levyn kuormituksen normaalisti, vaikka GPU itse on piilossa isännän näkyvistä koko sen ajan kun virtuaalikone on käynnissä.

SkenaarioKarkea suorituskykyhäviöYleisin pullonkaula
Paljas metalli (ei virtualisointia)Ei häviötä, vertailukohta–
Läpivienti, oikein viritetty (cpu host, hugepages, isolcpus)Muutaman prosentin luokkaaOhjainten pieni ylimääräinen kirjanpito
Läpivienti, oletusasetuksin (kvm64-suoritintyyppi)Selvästi suurempi ja epätasainenSuorittimen käskykannan emulaatio
vGPU jaettuna kahden käyttäjän keskenKarkeasti puolet raakatehosta per käyttäjäMuistin ja laskentayksiköiden jako ajassa

Taulukon luvut ovat suuntaa-antavia ja riippuvat vahvasti käytetystä pelistä tai työkuormasta, mutta suunta pätee johdonmukaisesti: mitä lähempänä konfiguraatio on host-CPU-tyyppiä ja mitä enemmän muistinhallintaa on viritetty, sitä pienempi on ero paljaaseen metalliin.

Jos haluat seurata GPU:n kuntoa pidemmällä aikavälillä eikä vain yksittäisillä hetkellisillä komennoilla, node_exporter ja siihen liitettävä nvidia_smi-laajennus keräävät lämpötila-, kuormitus- ja muistihistoriaa Prometheus-tietokantaan, jota voi myöhemmin tarkastella Grafana-kojelaudalla. Tämä on hyödyllistä erityisesti, jos AI-virtuaalikone ajaa pitkiä koulutusajoja yöllä ja haluat jälkikäteen tarkistaa, nousiko lämpötila liian korkeaksi tai putosiko kellotaajuus lämpöjarrutuksen vuoksi.

Verkko ja tallennustila esimerkkiprojektissa

GPU-läpivienti ei muuta virtuaalikoneen verkko- tai levyasetuksia mitenkään erityisesti, mutta muutama käytännön yksityiskohta kannattaa hoitaa kuntoon samalla. Käytä VirtIO-verkkosovitinta, koska emuloitu Realtek- tai Intel-verkkokortti hidastaa siirtonopeutta selvästi verrattuna suoraan paravirtualisoituun VirtIO-ajuriin. Levytilaan kannattaa varata riittävästi puskuria: pelivirtuaalikoneelle vähintään 100 Gt SSD-tilaa ja tekoälyvirtuaalikoneelle huomattavasti enemmän, jos paikallisia kielimalleja ladataan levylle useita rinnakkain.

Molemmille esimerkkivirtuaalikoneille kannattaa myös määrittää oma erillinen VLAN tai vähintään oma verkkosilta, jos GPU-palvelin on samassa lähiverkossa kuin muu kotitalouden liikenne. Tämä pitää mahdollisen ongelman yhden virtuaalikoneen sisällä eikä se leviä koko kotiverkkoon. Levyjärjestelmän puolella kannattaa käyttää cache=none-asetusta virtuaalilevyille, jos taustalla on NVMe-pohjainen tallennustila, koska se välttää turhaa isäntätason välimuistin kaksinkertaistumista ja pitää levyn I/O-viiveen tasaisena myös silloin, kun molemmat virtuaalikoneet lataavat suuria tiedostoja samanaikaisesti.

Kahdeksan yleisintä sudonvirhettä läpiviennissä

Näihin virheisiin kannattaa varautua etukäteen, koska ne toistuvat käytännössä joka toisessa keskustelupalstan avustuspyynnössä.

  • Above 4G Decoding jää pois päältä BIOSissa, minkä seurauksena VM kaatuu heti käynnistyksessä ilman selkeää virheilmoitusta.
  • GPU:n äänifunktio unohtuu hostpci-rivistä, jolloin näyttö toimii mutta äänenulostulo puuttuu vierasjärjestelmästä kokonaan.
  • SeaBIOS jää valituksi vahingossa OVMF:n sijaan, ja moderni GPU-BIOS ei käynnisty legacy-tilassa lainkaan.
  • IOMMU-ryhmä sisältää muita kriittisiä laitteita, ja koko ryhmän siirto katkaisee isännän levy- tai verkkoyhteyden odottamatta.
  • Nvidian ajuri jää isännälle ladattuna, koska blacklist-tiedosto kirjoitetaan mutta initramfs-päivitys ja uudelleenkäynnistys unohtuvat.
  • vBIOS-ROM-tiedoston puuttuminen jää huomaamatta, kun samaa korttia on aiemmin käytetty isännän omana näyttönä ennen läpivientiä.
  • Proxmox päivitetään suoraan tuotantoon testaamatta, ja uusi kerneliversio muuttaa PCI-osoitteita niin, että hostpci-rivi osoittaa väärään laitteeseen.
  • Käyttäjä yrittää ottaa live-snapshotin tai siirtää VM:n toiseen isäntään kesken ajon, mikä ei onnistu PCI-läpiviennin kanssa lainkaan, koska QEMU ei pysty tallentamaan suoraan laitteistoon sidottua tilaa.

Vianmääritys: kahdeksan yleistä ongelmaa ja ratkaisu

Seuraavat tilanteet kattavat suurimman osan käytännön ongelmista, joita kotilabroissa syntyy läpiviennin kanssa. Käy nämä läpi järjestyksessä ennen kuin etsit apua keskustelupalstoilta, koska yli puolet avustuspyynnöistä ratkeaa jollain näistä.

  • VM ei käynnisty, näyttö pysyy mustana: tarkista, että bios-rivi VM-konfiguraatiossa on ovmf ja että EFI-levy on lisätty. Puuttuva EFI-levy on selvästi yleisin syy tähän.
  • Windows näyttää Code 43 -virheen laitehallinnassa: lisää args-riville kvm=off ja varmista, ettei vm.conf:issa ole vahingossa ylimääräistä hyperv-lippua, joka paljastaa virtualisoinnin ajurille.
  • dmesg ei näytä IOMMU-rivejä käynnistyksen jälkeen: BIOS-asetus on jäänyt pois päältä, tai GRUB-konfiguraatio ei ole päivittynyt oikein. Aja update-grub uudelleen ja tarkista /proc/cmdline manuaalisesti.
  • lspci näyttää edelleen “Kernel driver in use: nvidia”: blacklist- ja modprobe-tiedostot on kirjoitettu väärään hakemistoon, tai initramfs ei ole päivittynyt. Aja update-initramfs -u -k all uudelleen ja käynnistä kokonaan uudelleen.
  • VM käynnistyy, mutta nvidia-smi ei löydä laitetta vieraassa: ajuri puuttuu vierasjärjestelmästä, tai PCI-osoite hostpci-rivillä on väärä. Tarkista lspci vieraan sisällä ensimmäisenä.
  • Isäntä menettää oman näytön pysyvästi VM:n käynnistyksen jälkeen: tämä on odotettu käytös yhden GPU:n asetuksessa, käytä SSH-yhteyttä hallintaan tai lisää toinen halvempi kortti isännän omaan käyttöön.
  • Suorituskyky on selvästi heikompi kuin paljaalla metallilla: tarkista cpu-tyyppi (pitää olla host), hugepages-asetus ja että VM:n ydinmäärä ei ylitä fyysisten ydinten määrää yhden NUMA-solmun sisällä.
  • IOMMU-ryhmä sisältää liikaa laitteita eikä ACS-ohitus onnistu: kokeile ACS override -patchia vain, jos emolevy ei tarjoa PCIe-porttikohtaista eristystä, ja hyväksy tietoisesti pienentynyt eristystaso luotettavassa sisäverkossa.

Edistyneet vinkit: dynaaminen läpivienti, moni-GPU ja Looking Glass

Kun perusasetus toimii vakaasti, kannattaa harkita hook-skriptiä, joka vapauttaa GPU:n takaisin isännälle automaattisesti aina kun virtuaalikone sammuu. Tämä poistaa tarpeen käynnistää koko Proxmox-isäntä uudelleen vain vaihtaakseen GPU:n käyttäjää.

#!/bin/bash
# /var/lib/vz/snippets/gpu-hookscript.sh
VMID="$1"; PHASE="$2"
if [ "$PHASE" = "pre-start" ]; then
  modprobe -r nvidia_drm nvidia_uvm nvidia_modeset nvidia
  modprobe vfio-pci
fi
if [ "$PHASE" = "post-stop" ]; then
  modprobe -r vfio-pci
  modprobe nvidia
fi

Liitä skripti VM:ään komennolla qm set <VMID> --hookscript local:snippets/gpu-hookscript.sh. Useamman GPU:n asetuksissa kannattaa antaa yksi kortti kokonaan yhdelle AI-koulutusvirtuaalikoneelle ja toinen erikseen pelivirtuaalikoneelle, jolloin IOMMU-ryhmiä ei tarvitse jakaa eikä hook-skriptejä tarvita ollenkaan. Tämä on huomattavasti vakaampi ratkaisu, jos budjetti sen sallii.

Jos et halua kytkeä pelivirtuaalikoneeseen erillistä fyysistä näyttöä, avoimen lähdekoodin Looking Glass -projekti mahdollistaa VM:n näytön striimaamisen isännälle käytännössä ilman viivettä jaetun muistipuskurin kautta. Vaihtoehtoisesti Sunshine-palvelin virtuaalikoneessa ja Moonlight-asiakas toisella laitteella toimivat samaan tarkoitukseen tavallisen verkon yli, joskin pienemmällä viiveellä hyötyä lähiverkossa kuin Looking Glassista. Jos jokin näistä edistyneistä konfiguraatioista jää epäselväksi, Nvidian omat kehittäjäfoorumit ja syyskuussa 2026 päivitetty riippumaton läpivientiopas ovat hyviä lisälähteitä yksityiskohtien tarkistamiseen.

Valmis esimerkkiprojekti: yksi isäntä, kaksi käyttötapaa

Kokoava esimerkki yhdistää kaiken edellä opitun: yksi Proxmox VE 9 -palvelin, yksi RTX-näytönohjain ja kaksi virtuaalikonetta, joita käytetään vuorotellen hook-skriptin avulla.

  • VM 101 “gaming-win11”: Windows 11, OVMF, q35, cpu host, hostpci0 osoittaa GPU:hun, käytössä iltaisin pelaamiseen.
  • VM 102 “ai-ubuntu”: Ubuntu 24.04, OVMF, q35, cpu host, sama hostpci0-rivi, käytössä päivisin paikallisten kielimallien ajamiseen Ollamalla.
  • Hook-skripti vapauttaa GPU:n automaattisesti kun kumpi tahansa VM sammutetaan, jolloin toinen voi käynnistyä välittömästi.
  • Isäntä itse käyttää integroitua näytönohjainta tai toista halvempaa korttia omaan hallintaan ja Proxmox-web-käyttöliittymän ajamiseen.

Tällä asetuksella yksi RTX 5090 -luokan kortti palvelee molempia käyttötarkoituksia ilman, että sitä tarvitsee jakaa vGPU-lisenssillä. Vaihto virtuaalikoneiden välillä kestää käytännössä vain sammutuksen ja käynnistyksen verran, tyypillisesti alle minuutin. Jos toinen virtuaalikoneista alkaa ylikuumentua raskaan kuorman alla, kannattaa katsoa erillinen GPU:n ylikuumenemisen korjausopas, koska syyt ja ratkaisut ovat samat kuin paljaalla metallilla.

Muita yleisiä käyttötapauksia kotilabrassa

Peli- ja tekoälykäyttö on yleisin syy GPU-läpivientiin, mutta samaa tekniikkaa käytetään laajasti myös muihin tarkoituksiin. Mediapalvelinkäyttäjät liittävät GPU:n Jellyfin- tai Plex-virtuaalikoneeseen, jotta laitteiston NVENC-piiri hoitaa videon transkoodauksen ilman, että isäntäkoneen suoritin kuormittuu. Kehittäjät käyttävät samaa tekniikkaa testatakseen CUDA-sovelluksia eristetyssä ympäristössä, jota voi nollata puhtaaseen tilaan yhdellä komennolla ilman, että isäntäkone kärsii epävakaista ajureista. Kolmas yleinen tapaus on vanhojen pelien tai erikoisohjelmistojen ajaminen omassa Windows-virtuaalikoneessa, joka pidetään täysin erillään päivittäiskäytössä olevasta isännästä. Neljäs, harvemmin mainittu tapaus on kevyt 3D-suunnittelu- tai renderöintityö: freelance-suunnittelija voi ajaa CAD- tai Blender-virtuaalikonetta samalla GPU:lla, jota käytetään muina aikoina pelaamiseen, jolloin kalliin työasemakortin hankinta jää tarpeettomaksi.

Yhteistä kaikille näille tapauksille on se, että itse läpivientikonfiguraatio pysyy samana riippumatta käyttötarkoituksesta. Erot syntyvät vasta vierasjärjestelmän ohjelmistovalinnoissa: transkoodauskäytössä riittää kevyt Linux-jakelu ja NVENC-tuki, kun taas AI-koulutuksessa tarvitaan täysi CUDA-pino ja usein huomattavasti enemmän muistia.

AMD-näytönohjaimen läpivienti käytännössä

Kaikki tähän mennessä käydyt vaiheet toimivat AMD-korteilla identtisesti Nvidia-korttien kanssa, koska VFIO ei tee eroa valmistajan välillä. Ainoat erot syntyvät vierasjärjestelmän ajurien asennuksessa ja suorituskyvyn tarkistuksessa.

# Ubuntu-vierasjärjestelmässä AMD:n ROCm-pino
sudo apt update
sudo apt install rocm-smi
rocm-smi --showproductname
rocm-smi --showtemp

rocm-smi vastaa suoraan nvidia-smi:tä ja näyttää kortin nimen, lämpötilan ja kuormituksen. AMD-korteilla IOMMU-ryhmän tarkistus vaiheessa 5 on erityisen tärkeää, koska useissa integroidun grafiikkapiirin sisältävissä APU-emolevyissä discrete-GPU ja emolevyn oma grafiikka voivat päätyä samaan ryhmään, jolloin niitä ei voi erottaa toisistaan ohjelmallisesti. Pelivirtuaalikoneessa Windowsin puolella AMD:n Adrenalin-ajuripaketti asentuu identtisesti kuin fyysisellä koneella, ja Linux-vierailla avoimen lähdekoodin Mesa/RADV-ajuripino toimii usein jo valmiiksi jakelun mukana ilman erillistä asennusta.

Kun näytönohjain vaihtuu: siirtyminen uuteen GPU-malliin

Ennen pitkää tulee tilanne, jossa fyysinen kortti vaihtuu uudempaan malliin, esimerkiksi päivityksen tai vikaantumisen vuoksi. Läpivientikonfiguraation kannalta tärkeintä on muistaa, että laitetunnukset (vendor:device ID) muuttuvat uuden kortin mukana, vaikka PCI-osoite (esimerkiksi 01:00) pysyisi samana korttipaikan pysyessä ennallaan.

  • Sammuta virtuaalikone ja isäntä kokonaan, vaihda kortti fyysisesti paikoillaan.
  • Aja lspci -nn | grep -i vga uudelleen ja päivitä /etc/modprobe.d/vfio.conf-tiedostoon uudet laitetunnukset.
  • Aja update-initramfs -u -k all ja käynnistä isäntä uudelleen.
  • Tarkista, että hostpci-rivin PCI-osoite VM-konfiguraatiossa vastaa edelleen uuden kortin sijaintia, koska osoite voi muuttua jos kortti asennetaan eri korttipaikkaan.
  • Asenna uuden sukupolven ajuri vierasjärjestelmään ennen ensimmäistä käynnistystä uudella kortilla, koska vanha ajuriversio ei aina tunnista täysin uutta GPU-sukupolvea.

Jos vanha kortti jää käyttöön isännän omana näytönohjaimena, muista poistaa sen laitetunnus vfio-pci-listalta, ettei isäntä yritä vahingossa irrottaa omaa näyttöään käytöstä seuraavassa käynnistyksessä. Kannattaa myös testata uusi kortti erikseen ilman läpivientiä isännän omana näyttönä ensin, jos sellainen vaihtoehto on käytettävissä, koska tämä paljastaa nopeasti mahdolliset viallisen laitteen ongelmat ennen kuin sekoitat ne läpiviennin konfiguraatiovirheisiin.

Ylläpito, päivitykset ja tietoturva

GPU-läpivienti laajentaa virtuaalikoneen pääsyä lähemmäs fyysistä laitteistoa, joten eristys ei ole yhtä tiukka kuin täysin virtualisoidulla laitteistolla. Pidä siksi Proxmoxin kerneliä ja mikrokoodipäivityksiä ajan tasalla, ja rajoita fyysinen pääsy palvelimeen, jos VM:ssä ajetaan vähemmän luotettua ohjelmistoa. Nvidia julkaisee ajuripäivityksiä käytännössä kuukausittain, ja tuoreimman tuotantoajurin (595.104.02) tai uuden ominaisuushaaran (615.71.09) valinta kannattaa tehdä sen mukaan, tarvitaanko vakautta vai uusimpia Vulkan-ominaisuuksia.

Testaa Proxmoxin isopäivitykset aina ensin testiympäristössä, jos sellainen on käytettävissä, koska kernelin vaihtuminen voi muuttaa PCI-osoitteita ja rikkoa hostpci-rivin viittauksen. Pidä myös vBIOS-ROM-tiedostot ja alkuperäiset modprobe-konfiguraatiot varmuuskopioituna erillisessä paikassa, jotta palautuminen virhetilanteesta on nopeaa.

Muista myös, ettei PCI-läpivientiä käyttävää virtuaalikonetta voi siirtää elävänä toiseen isäntään eikä siitä voi ottaa live-snapshotia, koska GPU:n sisäinen tila ei ole QEMU:n hallinnassa siirron ajan. Jos tarvitset varmuuskopion, sammuta virtuaalikone ensin ja ota tavallinen offline-varmuuskopio Proxmox Backup Serverin tai vzdumpin kautta. Tämä rajoitus koskee kaikkia PCI-läpivientiä käyttäviä hypervisoreja, ei ainoastaan Proxmoxia, ja se kannattaa hyväksyä osana ratkaisua alusta alkaen sen sijaan, että yrittää kiertää sitä.

Kun tämä kaikki on tehty kerran huolella, GPU-läpivienti Proxmoxissa on käytännössä huoltovapaa ratkaisu. Suurin osa ylläpidosta rajoittuu ajurien päivittämiseen vierasjärjestelmässä ja Proxmox-isännän tavalliseen tietoturvapäivitysrytmiin. Jos GPU-virtuaalikoneessa ajetaan ohjelmistoa, jonka lähdettä ei täysin tunneta, kannattaa myös rajata sen verkkoliikenne palomuurisäännöin niin, ettei se pääse suoraan keskustelemaan muiden kotiverkon laitteiden kanssa ilman erillistä sallimista. Tämä ei liity suoraan GPU-läpivientiin, mutta samalla kertaa tehtynä koko kotilabra pysyy siistimpänä ja helpommin hallittavana.

Yhteenveto: kannattaako läpivienti vaivan arvoinen

Kun BIOS-asetukset, IOMMU, VFIO-moduulit ja VM-konfiguraatio on kerran saatu kohdilleen, GPU-läpivienti Proxmoxissa muuttuu käytännössä huomaamattomaksi osaksi arkea. Sama kortti palvelee peli-iltaa ja seuraavana aamuna paikallista tekoälymallia ilman, että kumpikaan käyttötarkoitus tuntuu tekevän kompromisseja suorituskyvyn suhteen. Suurin osa tässä oppaassa käydyistä sudonvirheistä liittyy juuri BIOS- ja käynnistysasetuksiin, joten niiden huolellinen läpikäynti etukäteen säästää helposti useita turhia uudelleenkäynnistyksiä. Aikainvestointi on kertaluonteinen: kun konfiguraatio on kunnossa, se pysyy toimivana ajurien ja Proxmox-päivitysten läpi, kunhan ottaa huomioon tässä oppaassa mainitut varmuuskopiointi- ja testauskäytännöt.

Usein kysytyt kysymykset

Toimiiko GPU-läpivienti tavallisella kuluttajaemolevyllä?
Kyllä, kunhan suoritin tukee VT-d/AMD-Vi-tekniikkaa ja BIOS tarjoaa IOMMU-asetuksen. Monet budjettiemolevyt rajoittavat tätä silti laiteohjelmistotasolla, joten tarkista valmistajan tuotesivu ennen ostoa. Keskihintaiset ja kalliimmat emolevyt tukevat tätä nykyään käytännössä poikkeuksetta, ja myös useimmat viime vuosina julkaistut mini-ITX- ja mATX-mallit ovat tässä yhtä hyviä kuin täyskokoiset ATX-emolevyt, kunhan piirisarja on riittävän uusi.

Voiko samaa GPU:ta käyttää isännässä ja virtuaalikoneessa yhtä aikaa?
Ei täydellä läpiviennillä. Kortti kuuluu joko isännälle tai yhdelle virtuaalikoneelle kerrallaan, ei molemmille yhtä aikaa. Samanaikainen jako useille käyttäjille vaatii Nvidian vGPU-ohjelmiston ja tuetun datakeskuskortin, mikä on eri ratkaisu kuin tässä oppaassa käyty täysi läpivienti.

Toimiiko tämä opas myös AMD-näytönohjaimilla?
Kyllä, VFIO-mekanismi on valmistajariippumaton. AMD RDNA2/3/4-korteilla Above 4G Decoding ja Re-Size BAR ovat samalla tavalla pakollisia, ja ajurin asennus vierasjärjestelmään tapahtuu AMD:n omilla paketeilla nvidia-smin sijaan rocm-smi:llä. Muut vaiheet, kuten IOMMU-ryhmien tarkistus ja hostpci-konfiguraatio, ovat identtisiä.

Tarvitseeko Proxmox-lisenssiä GPU-läpivientiin?
Ei. Itse Proxmox VE on ilmainen ja avoimen lähdekoodin, eikä VFIO-läpivienti vaadi mitään maksullista lisäosaa. Maksullinen tukisopimus koskee vain yritystukea ja päivitysrepositorion vakautta, ei itse toiminnallisuutta.

Kuinka paljon suorituskykyä läpivienti syö verrattuna paljaaseen metalliin?
Oikein viritetyllä asetuksella (cpu host, hugepages, isolcpus) häviö on tyypillisesti muutaman prosentin luokkaa. Ilman näitä viilauksia erot voivat olla selvästi suurempia erityisesti kehysaikojen tasaisuudessa, mikä näkyy peleissä hetkellisinä nykäyksinä vaikka keskimääräinen ruudunpäivitysnopeus näyttäisi hyvältä.

Voiko kannettavassa tietokoneessa tehdä GPU-läpiviennin?
Teoriassa kyllä, jos suoritin ja BIOS tukevat IOMMU:ta, mutta kannettavien näytönohjaimet on usein kytketty tiukasti emolevyn muun laitteiston kanssa samaan IOMMU-ryhmään, mikä tekee puhtaasta läpivienneistä huomattavasti hankalampaa kuin pöytäkoneella. Käytännössä tämä opas soveltuu parhaiten pöytäkoneisiin ja palvelinlaitteistoon.

Mitä tehdä, jos VM ei käynnisty enää GPU:n liittämisen jälkeen?
Poista hostpci-rivi väliaikaisesti VM-konfiguraatiosta ja käynnistä kone ilman GPU:ta. Jos se käynnistyy normaalisti, ongelma on PCI-osoitteessa, IOMMU-ryhmässä tai bios/machine-asetuksissa, ei itse käyttöjärjestelmässä. Lisää GPU takaisin yksi asetus kerrallaan, kunnes löydät virheellisen kohdan.

Kannattaako valita Nvidian 595- vai 615-ajurihaara vierasjärjestelmään?
Tuotantokäyttöön ja AI-koulutukseen 595.104.02 on vakaampi valinta, koska se on Nvidian nimeämä tuotantohaara. Pelivirtuaalikoneeseen 615.71.09 kannattaa harkita, koska se tuo NVIDIA Reflex -tuen Vulkan-peleille Protonin läpi ja uudempaa cgroups-pohjaista muistinhallintaa. Voit myös pitää molempia asennettuna eri virtuaalikoneisiin, koska ajurivalinta tehdään erikseen vieraskohtaisesti.

Mitä eroa on VFIO-läpiviennillä ja SR-IOV-pohjaisella jaolla?
SR-IOV (Single Root I/O Virtualization) on piirisarjatason tekniikka, joka jakaa yhden fyysisen PCIe-laitteen useiksi virtuaalisiksi funktioiksi jo laitteistotasolla, ja sitä käytetään lähinnä verkkokorteissa ja tietyissä datakeskus-GPU:issa. Tavallisilla kuluttajanäytönohjaimilla SR-IOV ei ole käytössä, joten VFIO-pohjainen täysi läpivienti on käytännössä ainoa toimiva reitti kotilabrassa.