Linux för arbete, Windows VM för spel - How-to

Permalänk
Medlem

Linux för arbete, Windows VM för spel - How-to

Tja alla,

Jag har länge inväntat en uppgradering från min trogne 4670K, och ett av kraven var att jag ville ha möjligheten att köra Linux på bare metal, med ett dedikerat grafikkort till en Windows VM. På det sättet kan jag spela alla spel jag vill, utan problem med Anti-cheat, DRM eller att det helt enkelt inte stöds för Linux, men samtidigt ha Linux så jag kan använda min dator som jag vill. Vi alla vet varför vi föredrar Linux så tänker inte gå in på det. Jag vet att dual-boot är ett alternativ, men hur kul är det?

Jag tänkte här beskriva hur jag gjorde det, vad jag lärde mig, och vad jag ska göra om. Ni får ursäkta om jag hoppar lite mellan engelska och svenska. Jag kommer anta att det finns basic kunskaper inom Linux för att installera paket, redigera filer och navigera runt i terminalen och köra skript. Eftersom jag bara har AMD hårdvara med NVIDIA-gpuer kommer en del av detta vara aningen specifikt, men det är i grund och botten samma sak man behöver göra på ett system med Intel CPU och AMD GPU.

Först och främst, hur ser mitt system ut?

  • Moderkort: Asrock X570 Taichi

  • CPU: AMD Ryzen 3700X

  • Minne: 32GB

  • GPU0: NVIDIA GT1030

  • GPU1: NVIDIA RTX2070

  • Lagring: 1TB NVMe SSD

Som ni ser kräver detta två grafikkort, ett för vårt primära OS, och en för vår virtuella maskin. Har man ett Intel-baserat system kan man använda den integrerade GPUn och därmed frigöra en PCIe x16 slot. Jag köpte personligen ett passivt kylt GT1030 då jag inte behöver någon GPU-kraft i Linux (än).

Ett annat krav är att moderkortet har stöd för IOMMU gruppering, men även att den hanterar IOMMU-grupper på ett bra sätt. Dvs, att PCIe-enheterna får addresserbart minne inom samma IOMMU grupp. Detta möjliggör passthrough för en total enhet. RTX-korten specifikt har 4 olika PCIe device IDs som alla behöver befinna sig på samma IOMMU-grupp.

Vi antar att vi börjar från en fräsch ny installation av Ubuntu 20.04 (eller något som är baserat på det som PopOS!).

Vi kan börja med att installera de nödvändiga paketen vi behöver:

# apt install libvirt-bin bridge-utils virt-manager qemu-kvm ovmf

Innan vi startar om maskinen för att konfigurera UEFI så kan vi passa på och ställa in maskinen så att den alltid bootar med IOMMU påslaget. Det vi faktiskt gör här är att vi specificierar linux kernel-moduler och parametrar som vi vill att linuxkärnan laddar vid boot.

Editera följande fil med er favorit redigerare, /etc/default/grub och ändra raden som börjar med GRUB_CMDLINE_LINUX_DEFAULT och lägg till följande moduler och modulparametrar:

  • amd_iommu=on

  • kvm.ignore_msrs=1

  • iommu=pt

Så här såg min ut efter jag lade till det ovan:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amd_iommu=on kvm.ignore_msrs=1 iommu=pt"

OBS! Flaggorna kommer heta något annat om du har Intel.

Sedan behöver vi uppdatera vår Grub-konfiguration:

# update-grub

Nu kan vi starta om maskinen och gå in i UEFI för att aktivera ett par saker på vårt system.

  • AMD-SRV

  • IOMMU

Nu när vi bootar in i Linux så bör vi kunna se de olika IOMMU-grupperna under:
/sys/kernel/iommu_groups/*/devices/*

För att verifiera att IOMMU är påslaget så kan vi titta i dmesg och söka efter AMD-Vi.

# dmesg | grep -i amd-vi [ 0.734955] pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported [ 0.736312] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40 [ 0.736313] pci 0000:00:00.2: AMD-Vi: Extended features (0x58f77ef22294ade): [ 0.736315] AMD-Vi: Interrupt remapping enabled [ 0.736315] AMD-Vi: Virtual APIC enabled [ 0.736315] AMD-Vi: X2APIC enabled [ 0.736387] AMD-Vi: Lazy IO/TLB flushing enabled

Här är ett skript för att enkelt se IOMMU-grupper:

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

Jag kan rekommendera moderkortet Asrock X570 Taichi då den har bra IOMMU-gruppering. Jag hade inga problem själv, men har läst att om inte hela kortet hamnar i samma grupp så får man testa andra PCI-e slots. Finns säkert andra trick man kan göra, men som tur är så slapp jag lära mig dem.

När jag kör ovanstående skript ser jag att samtliga 4-PCI ID's för kortet är i samma IOMMU-grupp.

# bash iommu.sh | grep 'TU106' IOMMU Group 27 0e:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU106 [GeForce RTX 2070 Rev. A] [10de:1f07] (rev a1) IOMMU Group 27 0e:00.1 Audio device [0403]: NVIDIA Corporation TU106 High Definition Audio Controller [10de:10f9] (rev a1) IOMMU Group 27 0e:00.2 USB controller [0c03]: NVIDIA Corporation TU106 USB 3.1 Host Controller [10de:1ada] (rev a1) IOMMU Group 27 0e:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU106 USB Type-C UCSI Controller [10de:1adb] (rev a1)

(Note: Jag greppade efter 'TU106' för att göra det lite snyggare här, kör skriptet utan grep)

Nu har vi säkertställt att vi har IOMMU påslaget, att det är aktiverat och igenkänt av vårt operativsystem och även att samtliga del-enheter av vår GPU är del av samma IOMMU-grupp.

Nästa steg är att isolera GPUn som ska användas till vår VM från vår host genom att specificera VFIO som drivrutin för kortet. Detta gör vi lättast genom Grub igen genom att redigera samma fil och lägga till samtliga 4 PCI IDs som parametrar till VFIO-drivern i våra Grub-options. Detta gör kortet oanvändbart i Linux, men ger KVM möjligheten att använda GPUn i en virtuell maskin.

PCI IDn är det näst sista vi ser på varje rad av outputen ovan, så för mitt system blir det:

  • 10de:1f07

  • 10de:10f9

  • 10de:1ada

  • 10de:1adb

Redigera /etc/default/grub och lägg till följande till samma rad som tidigare:

vfio-pci.ids=10de:1f07,10de:10f9,10de:1ada,10de:1adb

OBS!!! Klipp inte och klistra in dessa värden. Dina ID's kommer säkerligen se annorlunda ut!

Så här ser min grub config ut efter jag lade till det ovan:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amd_iommu=on kvm.ignore_msrs=1 iommu=pt vfio-pci.ids=10de:1f07,10de:10f9,10de:1ada,10de:1adb"

Sedan behöver vi uppdatera vår Grub-konfiguration igen:

# update-grub

Starta om datorn så att kärnan laddas om med VFIO drivern:

# reboot

För att verifiera att vår VM-GPU nu använder sig utav VFIO som driver kan vi köra:

# lspci -k | grep -B3 vfio Kernel modules: snd_hda_intel 0e:00.0 VGA compatible controller: NVIDIA Corporation TU106 [GeForce RTX 2070 Rev. A] (rev a1) Subsystem: ASUSTeK Computer Inc. TU106 [GeForce RTX 2070 Rev. A] Kernel driver in use: vfio-pci Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia 0e:00.1 Audio device: NVIDIA Corporation TU106 High Definition Audio Controller (rev a1) Subsystem: ASUSTeK Computer Inc. TU106 High Definition Audio Controller Kernel driver in use: vfio-pci Kernel modules: snd_hda_intel 0e:00.2 USB controller: NVIDIA Corporation TU106 USB 3.1 Host Controller (rev a1) Subsystem: ASUSTeK Computer Inc. TU106 USB 3.1 Host Controller Kernel driver in use: vfio-pci Kernel modules: xhci_pci 0e:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU106 USB Type-C UCSI Controller (rev a1) Subsystem: ASUSTeK Computer Inc. TU106 USB Type-C UCSI Controller Kernel driver in use: vfio-pci

Perfekt. Nu är vår maskin förberedd för GPU-passthrough!

Dags att skapa en VM. Detta kan vi göra med virt-manager.
Följ stegen i GUI't för att skapa en Windows VM och välj resurser så att Linux kan köras parallelt med Windows, så lämna åtminstone 2 kärnor och 4GB RAM, helst mer. Personligen har jag gett maskinen 8 vCPUs som består av 4 fysiska kärnor med 2 logiska per kärna.

Ni behöver en Windows ISO som går att hämta från Microsoft gratis. Kör inte med någon egen variant om ni inte vet vad ni gör. Ladda hem den officiella ISOn från Microsoft, annars kan det uppstå problem med kompatibilitet.

Innan ni går vidare med sista steget (steg 5) men innan ni går vidare till att installera, välj Customize configuration before install

Under Overview, välj Q35 som chipset och UEFI x86_64: /usr/share/OVMF/OVMF_CODE.fd som firmware:

Innan vi kan köra måste vi sätta vår virtualisering i ett hidden-mode, och även lura NVIDIA's drivrutiner så att den inte detekterar att vi kör i en VM. Detta gör vi via terminalen via virsh.

# virsh edit <VM-namn>

Nu behöver vi lägga till lite rader i denna XML-filen:

... <features> ... <hyperv> ... <vendor_id state='on' value='randomid'/> ... </hyperv> ... </features> ...

Samt:

... <features> ... <kvm> <hidden state='on'/> </kvm> ... </features> ...

Nu finns det lite olika sätt att fortsätta. Antingen kan vi lägga till vår GPU innan vi installerar Windows, eller efteråt. Jag upplevde det lättare att lägga till grafikkortet efteråt. Testa lite som ni vill, jag var lite disträ under tiden jag gjorde det så jag kan ha upplevt fel som inte var relaterade till ordningen.

Jag rekommenderar starkt att använda VirtIO som drivrutiner på Windows-gästen för mycket bättre prestanda för lagring (VirtIO SCSI) och nätverk.

Under diskens options i virt-manager finns det Disk Bus, där man kan ändra till VirtIO. För att kunna installera Windows på en disk som har VirtIO som sin kontroller, så behöver vi installera drivrutiner innan vi installerar Windows (annars kan inte Windows detektera diskarna).

Ladda hem följande fil från Red Hat:

  • virtio-win.iso

Här är en bra guide för hur man installerar VirtIO-drivrutinerna för en Windows VM innan installation. I princip behöver man lägga till ytterligare en CD-ROM-läsare och montera ovanstående .ISO-fil där och under installation välja:

Browse:

Och sist amd64 --> w10

När Windows är färdiginstallerat så installera virtio-win-guest-tools.exe från ISOn på VMen och starta om. Guest-tools är kritiskt. Den hjälper KVM att hantera filskrivningar, suspend mode, mer effektiv minneshantering osv.

När Windows senare är installerat så är det dags att lägga till GPUn! Starta virt-manager, och sen Add hardware --> PCI Host Device --> och lägg till alla komponenter av kortet (4 i mitt fall).

Sist men inte minst behöver vi mus/tangentbord till vår VM. Som tur är har qemu en feature där man via evdev kan pass through kontrollenheter. För att göra det behöver vi först identifiera vårt tangentbord och mus under /dev/input/by-id/.

sagan ~ $ ls -l /dev/input/by-id/ total 0 lrwxrwxrwx 1 root root 9 Mar 25 20:01 usb-04d9_USB_Keyboard-event-if01 -> ../event6 lrwxrwxrwx 1 root root 9 Mar 25 20:01 usb-04d9_USB_Keyboard-event-kbd -> ../event3 lrwxrwxrwx 1 root root 9 Mar 25 20:01 usb-Kingsis_Peripherals_ZOWIE_Gaming_mouse-event-mouse -> ../event2 lrwxrwxrwx 1 root root 9 Mar 25 20:01 usb-Kingsis_Peripherals_ZOWIE_Gaming_mouse-mouse -> ../mouse0 lrwxrwxrwx 1 root root 9 Mar 25 20:01 usb-Kingston_HyperX_Cloud_Flight_Wireless_Headset-event-if03 -> ../event7 sagan ~ $

Filerna vi är ute efter är dessa:

  • usb-04d9_USB_Keyboard-event-kbd

  • usb-Kingsis_Peripherals_ZOWIE_Gaming_mouse-event-mouse

Dvs filerna som har event med i namnet. För att lägga till denna funktion till vår VM behöver vi redigera XML-filen igen:

# virsh edit <VM-namn>

Och i slutet, av filen, innan </domain> lägger vi till:

<qemu:commandline> <qemu:arg value="-object"/> <qemu:arg value="input-linux,id=mouse1,evdev=/dev/input/by-id/usb-Kingsis_Peripherals_ZOWIE_Gaming_mouse-event-mouse"/> <qemu:arg value="-object"/> <qemu:arg value="input-linux,id=kbd1,evdev=/dev/input/by-id/usb-04d9_USB_Keyboard-event-kbd,grab_all=on,repeat=on"/> </qemu:commandline>

Notera att det är den absoluta filvägen för muset och tangentbordet som behövs. Så fort VMen startas kommer tangentbordet och musen att gå över till att kontrollera VMen. Genom att trycka på båda Ctrl på tangentbordet samtidigt så kan man toggla mellan Host <-> VM. Glöm inte att ansluta en display-kabel mellan VM-GPUn och din skärm och byt input när VMen startas.

Nu har vi en fungerande VM med GPU-passthrough! Starta den via virt-manager eller terminalen med:

$ virsh start <vm-namn>

Prestanda-förbättringar
Om ni kör AMD så rekommenderar jag starkt att pinna CPU-kärnorna så att den virtuella maskinens alla kärnor befinner sig på en sida av CCX. Detta reducerar latency enormt, eftersom all data som en kärna kan tänkas behöva finns i den delade L3-cachen. För att hjälpa er få en överblick på er CPU's topografi kan ni köra kommandot lstopo. För att installera det behövs det ett paket som heter hwloc

# apt install hwloc # lstopo

Här kan vi se att fysiska kärnor 0-3 är ett set av kärnor med sin egna cache, med 4-7 på den andre. Jag valde att dedikera de logiska kärnorna på 4-7 för VMen, vilket ledde till en förminsking av overhead och därmed närmre native prestanda.

<vcpu placement='static'>8</vcpu> <iothreads>1</iothreads> <cputune> <vcpupin vcpu='0' cpuset='8'/> <vcpupin vcpu='1' cpuset='9'/> <vcpupin vcpu='2' cpuset='10'/> <vcpupin vcpu='3' cpuset='11'/> <vcpupin vcpu='4' cpuset='12'/> <vcpupin vcpu='5' cpuset='13'/> <vcpupin vcpu='6' cpuset='14'/> <vcpupin vcpu='7' cpuset='15'/> <emulatorpin cpuset='0-1'/> <iothreadpin iothread='1' cpuset='0-1'/> </cputune> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='4' threads='2'/> <cache mode='passthrough'/> <feature policy='require' name='topoext'/> </cpu>

Överklockning!
Vi är ju trots allt på Sweclockers. Eftersom Linux-kärnan inte riktigt hanterar rejäla överklockningar lika bra som Windows-kärnan så kändes det mer safe att köra på moderkortets integrerade auto-OC funktion på alla kärnor. GPUn går att överklocka i VMen precis som på baremetal så med lite OC med MSI Afterburner så kan man kräma ur mer prestanda.

För övrigt, VMens konfiguration är något som inte är etsat i sten. Man kan ändra CPU-parameterar och nästan hela VMens konfiguration senare. Allt förutom chipset och UEFI/BIOS-firmware kan ändras och justeras i efterhand.

Prestandatester

Tankar på förbättringar
Något jag hade velat göra annorlunda skulle vara att partionerna min NVMe SSD med LVM, och skapa en volym för min VM-data, för att sedan passa genom den partitionen till VMen. Då hade jag fått blockenhets-lagring med lite overhead istället för att skriva till en fil på ett filsystem. Fördelen med att filbaserad lagring är att backups blir väldigt smidigt. Kör man sen ett filsystem som ZFS för sina backups kan man enkelt ta snapshots.

Lagrings-prestandan i VMen är OK, men kan vara lite bättre. GPU prestandan är utmärkt, ungefär 5% prestanda är tappad ungefär. Eftersom inte hela CPUn är virtualiserad blir det svårt att testa men det är mer än tillräckligt bra med 8 vCPUs. Väldigt låg latens när jag spelar och jag spelar CS:GO och Rocket League utan konstigheter. Jag har ofta bättre ping än mina vänner, vilket är lite kul också.

För övrigt så har jag även lagt till en bluetooth-dongel så jag kan ansluta min PS4-kontroller, och även mitt trådlösa USB headset och allt bara funkar. Jag är shockad hur bra det fungerat hittils och jag har väl kört denna setupen i snart 2 månader.

-------------------------------------------------------------------
Proper dokumentation: https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF
Min XML för referens (uppdaterad 2021-03-26): https://pastebin.com/NiRaB6Ad

Visa signatur

We are the music makers, and we are the dreamers of dreams.
Youtube | Spotify Playlists | Soft | Rapp | Rytm | Kött | Kalas |

Permalänk
Medlem

Snyggt! Tänkte försöka mig på något liknande när det blir dags att gå ifrån sandy bridge
Hur fungerar det att använda typ både Windows och Linux samtidigt, säg att man spelar på windows och samtidigt har discord + youtube/stream i Linux?
Och hur är det med flera skärmar, går det att ha windows på ena och Linux på andra?

Permalänk
Medlem
Skrivet av kinkyboo:

Snyggt! Tänkte försöka mig på något liknande när det blir dags att gå ifrån sandy bridge
Hur fungerar det att använda typ både Windows och Linux samtidigt, säg att man spelar på windows och samtidigt har discord + youtube/stream i Linux?
Och hur är det med flera skärmar, går det att ha windows på ena och Linux på andra?

Multipla skärmar ska inte vara ett problem. Det finns faktiskt ett program som heter Looking Glass, som i princip gör att man slipper ansluta sin VM-GPU till sin skärm eftersom att programmet skapar en unifierad frame buffer där Windows skriver och Linux läser. Jag har inte testat den lösningen än, men det hade underlättat enormt i ett sånt scenario du beskriver för då blir Windows-VMen bara en till applikation som hanteras av ens fönsterhanterare som alla andra i Linux.

Då hade man aldrig behövt "lämna" Linux genom att byta skärminput.

Kör man inte med Looking Glass-lösningen, dvs så som jag kör i skrivandes stund, så går det alldeles utmärkt att ha Windows på en skärm och Linux på den andra, och skifta input mellan dem med båda ctrl-knapparna tex.

Visa signatur

We are the music makers, and we are the dreamers of dreams.
Youtube | Spotify Playlists | Soft | Rapp | Rytm | Kött | Kalas |

Permalänk
Inaktiv

Hejsan
Jag spelar inga spel, men jag är bara allmänt nyfiken utav mig... Är det inte bättre att ha 100% tillgång till hela cpun och 100% tillgång av hela minnet osv osv med hårdvaruresurserna när man ska spela krävande spel i windows?
Samt dualboot är väl mindre komplicerat än att sätta upp en sådan VM?

Jag är bara nyfiken.. inget annat. jag älskar att läsa om olika tillvägagångssätt och idéer då jag är halvnybörjare fortfarande i linux.

Permalänk
Medlem
Skrivet av anon309108:

Hejsan
Jag spelar inga spel, men jag är bara allmänt nyfiken utav mig... Är det inte bättre att ha 100% tillgång till hela cpun och 100% tillgång av hela minnet osv osv med hårdvaruresurserna när man ska spela krävande spel i windows?
Samt dualboot är väl mindre komplicerat än att sätta upp en sådan VM?

Jag är bara nyfiken.. inget annat. jag älskar att läsa om olika tillvägagångssätt och idéer då jag är halvnybörjare fortfarande i linux.

Hej! Jo det vore bättre i ett scenario där prestanda ökar linjärt med antalet kärnor och minne, men spelen som utvecklas, det är inte säkert att alla gör det riktigt. Har för mig att 8 kärnor är en sweet spot, med vissa undantag som Flight Simulator tex. Så allt är en kompromiss! Du har absolut en poäng, men för mig så var det mer värt att få till Linux som host OS än den eventuella prestandaförbättringen i spel med dual-boot med Windows. Jag har faktiskt en 5900X på ingång snart som ska byta ut min 3700X, där jag tänkt allokera 8c/16t till Windows, och 4c/8t till Linux.

Men du har helt rätt, detta är absolut en prestandaförlust, men för mig och min situation med arbetet och spel så vägde funkationaliteten mer än den eventuella prestandaförlusten jag får i spel.

Visa signatur

We are the music makers, and we are the dreamers of dreams.
Youtube | Spotify Playlists | Soft | Rapp | Rytm | Kött | Kalas |

Permalänk
Inaktiv
Skrivet av Cloudstone:

Hej! Jo det vore bättre i ett scenario där prestanda ökar linjärt med antalet kärnor och minne, men spelen som utvecklas, det är inte säkert att alla gör det riktigt. Har för mig att 8 kärnor är en sweet spot, med vissa undantag som Flight Simulator tex. Så allt är en kompromiss! Du har absolut en poäng, men för mig så var det mer värt att få till Linux som host OS än den eventuella prestandaförbättringen i spel med dual-boot med Windows. Jag har faktiskt en 5900X på ingång snart som ska byta ut min 3700X, där jag tänkt allokera 8c/16t till Windows, och 4c/8t till Linux.

Men du har helt rätt, detta är absolut en prestandaförlust, men för mig och min situation med arbetet och spel så vägde funkationaliteten mer än den eventuella prestandaförlusten jag får i spel.

Tackar, tackar för svaret.
Det är som sagt intressant att höra/läsa om olika tillvägagångssätt o synvinklar. Om man aldrig frågar, kan man ju aldrig lära sig mer sägs det ju. *hihi*

Jag spelade massssor från 87 när jag fick min första dator tills 2001.. sedan en dag dog bara intresset utan förvarning... Jag hade flera datorer 95-01 så vi var tre som bruka lana här och vi kunde sitta i över ett dygn i sträck.. bara korta mat pauser. *hahaha* Så jag förstår tjusningen även om jag förlorat den själv.

Själv kör jag dualboot med windows8.1OEM på två av mina äldre datorer ifall jag skulle behöva windows någon gång om året... men mina två primära datorer har bara linux på, men med dualboot Debian och LMDE.... bra att ha backupOS ifall det ena kraschar, så behöver jag inte fixa datorn på en gång utan bara boota upp det andra o sedan fixa det första när lust finns... ska man vara lat så ska man.
(dualboot på separata diskar med bios bootmeny som startval)

Permalänk
Medlem

Bra guide vet du om det går och göra på liknande sett med Virtualbox? Virtualbox har lite lättare GUI än vad kvm erbjuder.

Permalänk

Bra guide. Nästan 100% av de som både vill köra windows och linux gör tvärt emot och kör Linux virtuellt, då slipper de alla problem med windowsspel. Men jag förstår poängen med att göra motsatsen om man är en flitig linuxanvändare. och det blir säkerligen samma problem om man vill ha ut gpu prestanda virtuellt i linux.

Jag själv sitter mest med none windows maskiner nu och fjärrstyr windows maskiner, det fungerar hur bra som helst förutom grafikprestandan suger utan dess like. (Det känns som att sitta på en 486a när jag jobbar med grafik)

Permalänk

Vilken bra skriven genomgång av PCI-passthrough!
Jag blir lite inspirerad att kanske göra en liknande men för loginctl multi-seat.

Skrivet av Cloudstone:

Jag har faktiskt en 5900X på ingång snart som ska byta ut min 3700X, där jag tänkt allokera 8c/16t till Windows, och 4c/8t till Linux.

Jag kanske missförstår hur du tänkt göra men host OS program har väl ändå tillgång till alla kärnorna även om du pinnat 8 st till VM?

Permalänk
Medlem

Fantastisk guide! Går det att åstadkomma på bara en GPU om man behöver använda den i både linux och Windows eller är det bara dualboot som gäller då?

Permalänk
Medlem
Skrivet av FattarNiInte:

Vilken bra skriven genomgång av PCI-passthrough!
Jag blir lite inspirerad att kanske göra en liknande men för loginctl multi-seat.
Jag kanske missförstår hur du tänkt göra men host OS program har väl ändå tillgång till alla kärnorna även om du pinnat 8 st till VM?

Om en VM eller annat processträd bara låses till vissa kärnor "på vanligt sätt" så fungerar det som du tänker, men i kombination med OS-isolering av berörda kärnor (exvis "isolcpus=7-15" som bootflag i Linux) så kör OS:et "hands off" på de kärnorna... 👍

@Napoleongl
Jag har för mig att det går, men att grafisk prestanda kanske inte blir lika bra som vid passthrough. Jag kan ha fel dock, andra med erfarenhet får gärna fylla på här!

@Cloudstone - fantastiskt snyggt sammanfattat! 😃👍

Fyllde på lite, + credits.
Visa signatur

Hårdvara:
Varierande nog, = onödig information.

Gillar Linux, det kan vara värt vetande. 🙂

Permalänk
Medlem

Suverän guide! Har saknat detta på Swec.

En nyhet som dök upp idag är att vi som kör Geforce-kort i passthrough snart slipper manövern med

<vendor_id state='on' value='randomid'/>

som du skriver om. Se: https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Ge...

Detta alltså för att Nvidia slutar obstruera passthrough genom drivrutinen, vilket de gjort tidigare. Nu kostar det ju inget att ha med raden i XML-filen, men trevligt att Nvidia tillslut gett upp att försöka sabotera

Kan också vara värt att nämna att med AMD-GPU så har manövern aldrig behövts, då AMD aldrig försökt förhindra passthrough. Dessa kort är också lättare att passthrough:a generellt, för man brukar inte behöva OVMF utan kan skicka in dem till VM som vilket PCI-kort som helst. Undantaget vissa modeller (Vega tror jag), som har buggar som gör att de slutar fungera från att man stänger av en VM till att man startar om hela fysiska maskinen.

Bra tips med evdev, ser smidigt ut. Jag brukar ha en separat USB-kontroller som jag skickar igenom till VM, och kopplar in mus + TB till den, men det kostar ju PCIe-linor och hårdvara i stort sett i onödan.

Skrivet av Cloudstone:

...
Jag har faktiskt en 5900X på ingång snart som ska byta ut min 3700X, där jag tänkt allokera 8c/16t till Windows, och 4c/8t till Linux.
...

Med 8 kärnor från en 5900X blir det ju svårt att hålla Windows på en ensam CCD dock

Jag har inte testat med Ryzen så jag vet inte hur den hanterar det, men det kan vara så att de största nackdelarna med att ge kärnor från flera CCD eller CCX till Windows-VM kommer av att Windows i defaultläget inte kan "se" vilka kärnor som delar cache (till skillnad från baremetal). Det kan du dock tala om för Windows genom

<topology sockets=...

- genom att representera olika CCD/CCX som olika socklar så bör Windows förstå bättre hur kärnorna hänger ihop. (Nu kanske jag berättar nåt du redan tänkt på eller redan har en bättre lösning på )

Visa signatur

Här hade jag en historik sen 1990-talet, men den blev tillslut för lång. Aktiva maskiner 2022-framåt:
Work/Play/Everythingstation: AMD Epyc 7443p, Pop OS host, Win10 + Linux guests (KVM/Qemu)
Work/Play nr 2: AMD Phenom II 1090t, Debian + Win 10 (dual boot)
Server x3: Epyc 7252 (TrueNAS Core), Atom 2550 (FreeBSD, backup), Opteron 6140 (Ubuntu, off prem backup)
Retrohörna under uppbyggnad: Dual Pentium Pro 200MHz, Pentium P54C 90MHz, Gravis Ultrasound MAX

Permalänk
Medlem
Skrivet av Meto:

Bra guide vet du om det går och göra på liknande sett med Virtualbox? Virtualbox har lite lättare GUI än vad kvm erbjuder.

Det verkar faktiskt som att det finns den funktionen i Virtualbox - https://docs.oracle.com/en/virtualization/virtualbox/6.0/admi...

Det är dock inget jag testat men principen bör vara den samma!

Skrivet av lillaankan_i_dammen:

Bra guide. Nästan 100% av de som både vill köra windows och linux gör tvärt emot och kör Linux virtuellt, då slipper de alla problem med windowsspel. Men jag förstår poängen med att göra motsatsen om man är en flitig linuxanvändare. och det blir säkerligen samma problem om man vill ha ut gpu prestanda virtuellt i linux.

Jag själv sitter mest med none windows maskiner nu och fjärrstyr windows maskiner, det fungerar hur bra som helst förutom grafikprestandan suger utan dess like. (Det känns som att sitta på en 486a när jag jobbar med grafik)

Tack! Haha, ja det kan jag tänka mig.

Skrivet av FattarNiInte:

Vilken bra skriven genomgång av PCI-passthrough!
Jag blir lite inspirerad att kanske göra en liknande men för loginctl multi-seat.
Jag kanske missförstår hur du tänkt göra men host OS program har väl ändå tillgång till alla kärnorna även om du pinnat 8 st till VM?

Tack så mycket! Jag borde uppdatera den litegrann, ska göra den lite noggrannare. Det har du helt rätt i! m1k3_dd svarade på din fråga där. Man kan använda isolcpu= som grub-parameter om man vill isolera helt.

Skrivet av Napoleongl:

Fantastisk guide! Går det att åstadkomma på bara en GPU om man behöver använda den i både linux och Windows eller är det bara dualboot som gäller då?

Vad jag vet så kräver det två GPUer om man ska använda denna metoden med en värd och en gäst-vm, men jag kan ha fel. Jag skulle tro att det är bara dualboot som gäller men som sagt i tråden så får man ju ut all prestanda från maskinen egentligen så det är ingen dålig lösning.

Skrivet av m1k3_dd:

Om en VM eller annat processträd bara låses till vissa kärnor "på vanligt sätt" så fungerar det som du tänker, men i kombination med OS-isolering av berörda kärnor (exvis "isolcpus=7-15" som bootflag i Linux) så kör OS:et "hands off" på de kärnorna... 👍

@Napoleongl
Jag har för mig att det går, men att grafisk prestanda kanske inte blir lika bra som vid passthrough. Jag kan ha fel dock, andra med erfarenhet får gärna fylla på här!

@Cloudstone - fantastiskt snyggt sammanfattat! 😃👍

Tack så mycket! Jag tänkte att vissa var kanske intresserade av något liknande så jag försökte. Det vore bra om man kunde göra en Wiki av det på någotvis för att jag är ingen expert inom området, och alla har vi olika setups och kanske stöter på olika problem.

Skrivet av Oegat:

Suverän guide! Har saknat detta på Swec.

En nyhet som dök upp idag är att vi som kör Geforce-kort i passthrough snart slipper manövern med

<vendor_id state='on' value='randomid'/>

som du skriver om. Se: https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Ge...

Detta alltså för att Nvidia slutar obstruera passthrough genom drivrutinen, vilket de gjort tidigare. Nu kostar det ju inget att ha med raden i XML-filen, men trevligt att Nvidia tillslut gett upp att försöka sabotera

Kan också vara värt att nämna att med AMD-GPU så har manövern aldrig behövts, då AMD aldrig försökt förhindra passthrough. Dessa kort är också lättare att passthrough:a generellt, för man brukar inte behöva OVMF utan kan skicka in dem till VM som vilket PCI-kort som helst. Undantaget vissa modeller (Vega tror jag), som har buggar som gör att de slutar fungera från att man stänger av en VM till att man startar om hela fysiska maskinen.

Bra tips med evdev, ser smidigt ut. Jag brukar ha en separat USB-kontroller som jag skickar igenom till VM, och kopplar in mus + TB till den, men det kostar ju PCIe-linor och hårdvara i stort sett i onödan.

Med 8 kärnor från en 5900X blir det ju svårt att hålla Windows på en ensam CCD dock

Jag har inte testat med Ryzen så jag vet inte hur den hanterar det, men det kan vara så att de största nackdelarna med att ge kärnor från flera CCD eller CCX till Windows-VM kommer av att Windows i defaultläget inte kan "se" vilka kärnor som delar cache (till skillnad från baremetal). Det kan du dock tala om för Windows genom

<topology sockets=...

- genom att representera olika CCD/CCX som olika socklar så bör Windows förstå bättre hur kärnorna hänger ihop. (Nu kanske jag berättar nåt du redan tänkt på eller redan har en bättre lösning på )

Tack så mycket! Ja, jag läste det precis! Bra att NVIDIA äntligen inte försöker ställa till det för oss också Om 5900X, det har du helt rätt i. Jag har faktiskt fått den nu och körde en lstopo och har lite svårt att tolka det faktiskt:

Det slutade med att jag kör 8c/16t dynamiskt, men jag lär leka lite med det framöver. Mycket intressant det du säger om hur man kan sätta upp sina socklar för Windows!

Visa signatur

We are the music makers, and we are the dreamers of dreams.
Youtube | Spotify Playlists | Soft | Rapp | Rytm | Kött | Kalas |

Permalänk
Medlem
Skrivet av Cloudstone:

Tack så mycket! Ja, jag läste det precis! Bra att NVIDIA äntligen inte försöker ställa till det för oss också Om 5900X, det har du helt rätt i. Jag har faktiskt fått den nu och körde en lstopo och har lite svårt att tolka det faktiskt:

https://i.imgur.com/BX3t2uB.png

Det slutade med att jag kör 8c/16t dynamiskt, men jag lär leka lite med det framöver. Mycket intressant det du säger om hur man kan sätta upp sina socklar för Windows!

Ett tips är att kolla vilken topologi Windows-gästen ser med coreinfo, det ger ungefär samma info som lstopo fast i Windows.

lstopo verkar dölja några kärnor för att de inte får plats, de tre små kvadraterna i varje grupp av kärnor representerar de som inte fick plats i bilden. Core0-5 sitter på ena CCD och Core6-11 sitter på den andra - men jag är osäker på hur man ska tolka "PU L#" vs. "P#", och vilken av dessa som indikerar hårvarutrådar. Det är ju viktigt eftersom "cpuset=..." jobbar med trådar, inte kärnor...

Idealt så vill du ju att Windows ska veta både vilka vcpu (hårdvarutrådar) som delar L1-2, och vilka par av vcpu som delar L3. Kan dock hända att "host-passthrough" tar hand om en del av det, är osäker på vilken info som kommer med automatiskt. Du kan som sagt kolla med coreinfo, och testa olika varianter på <topology=...> för att styra vilken topologi gästen ser.

Vad jag tänker är att "<topology sockets=...>" kan användas för att visa vilka vcpu som delar L3, ifall inte Windows räknar ut det på annat sätt. Jag vill minnas att jag löst det så med min gamla rigg med Opteron 6140, som också är en MCM med två kluster av kärnor som delar L3, men det är ett tag sen nu.

En annan fråga är hur flexibelt topology-direktivet är. Det hade varit intressant om det gick att ge windows typ 1.25 CCD - Cores 0-5 på en "socket", och cores 6-7 på en annan, för 8 cores totalt. Men jag tror inte det går med libvirt-xml (och nästa fråga vore hur Windows reagerar...!). Däremot kan du nog ge 4 cores från varje CCD, och ange

<topology sockets='2' cores='4' threads='2'/>

för totalt 8 cores, som Windows då kommer att veta hur de mappar till L3.

Meddela gärna vad du testar och vad du kommer fram till!

Edit:

lscpu -e

i Linux ger också info om mappningen mellan kärnor, trådar och cache. Den kan vara ett alternativ för att dubbelkolla om lstopo är kryptiskt.

Visa signatur

Här hade jag en historik sen 1990-talet, men den blev tillslut för lång. Aktiva maskiner 2022-framåt:
Work/Play/Everythingstation: AMD Epyc 7443p, Pop OS host, Win10 + Linux guests (KVM/Qemu)
Work/Play nr 2: AMD Phenom II 1090t, Debian + Win 10 (dual boot)
Server x3: Epyc 7252 (TrueNAS Core), Atom 2550 (FreeBSD, backup), Opteron 6140 (Ubuntu, off prem backup)
Retrohörna under uppbyggnad: Dual Pentium Pro 200MHz, Pentium P54C 90MHz, Gravis Ultrasound MAX

Permalänk
Medlem
Skrivet av Cloudstone:

Tja alla,

Jag har länge inväntat en uppgradering från min trogne 4670K, och ett av kraven var att jag ville ha möjligheten att köra Linux på bare metal, med ett dedikerat grafikkort till en Windows VM. På det sättet kan jag spela alla spel jag vill, utan problem med Anti-cheat, DRM eller att det helt enkelt inte stöds för Linux, men samtidigt ha Linux så jag kan använda min dator som jag vill. Vi alla vet varför vi föredrar Linux så tänker inte gå in på det. Jag vet att dual-boot är ett alternativ, men hur kul är det?

Jag tänkte här beskriva hur jag gjorde det, vad jag lärde mig, och vad jag ska göra om. Ni får ursäkta om jag hoppar lite mellan engelska och svenska. Jag kommer anta att det finns basic kunskaper inom Linux för att installera paket, redigera filer och navigera runt i terminalen och köra skript. Eftersom jag bara har AMD hårdvara med NVIDIA-gpuer kommer en del av detta vara aningen specifikt, men det är i grund och botten samma sak man behöver göra på ett system med Intel CPU och AMD GPU.

Först och främst, hur ser mitt system ut?

  • Moderkort: Asrock X570 Taichi

  • CPU: AMD Ryzen 3700X

  • Minne: 32GB

  • GPU0: NVIDIA GT1030

  • GPU1: NVIDIA RTX2070

  • Lagring: 1TB NVMe SSD

Som ni ser kräver detta två grafikkort, ett för vårt primära OS, och en för vår virtuella maskin. Har man ett Intel-baserat system kan man använda den integrerade GPUn och därmed frigöra en PCIe x16 slot. Jag köpte personligen ett passivt kylt GT1030 då jag inte behöver någon GPU-kraft i Linux (än).

Ett annat krav är att moderkortet har stöd för IOMMU gruppering, men även att den hanterar IOMMU-grupper på ett bra sätt. Dvs, att PCIe-enheterna får addresserbart minne inom samma IOMMU grupp. Detta möjliggör passthrough för en total enhet. RTX-korten specifikt har 4 olika PCIe device IDs som alla behöver befinna sig på samma IOMMU-grupp.

Vi antar att vi börjar från en fräsch ny installation av Ubuntu 20.04 (eller något som är baserat på det som PopOS!).

Vi kan börja med att installera de nödvändiga paketen vi behöver:

# apt install libvirt-bin bridge-utils virt-manager qemu-kvm ovmf

Innan vi startar om maskinen för att konfigurera UEFI så kan vi passa på och ställa in maskinen så att den alltid bootar med IOMMU påslaget. Det vi faktiskt gör här är att vi specificierar linux kernel-moduler och parametrar som vi vill att linuxkärnan laddar vid boot.

Editera följande fil med er favorit redigerare, /etc/default/grub och ändra raden som börjar med GRUB_CMDLINE_LINUX_DEFAULT och lägg till följande moduler och modulparametrar:

  • amd_iommu=on

  • kvm.ignore_msrs=1

  • iommu=pt

Så här såg min ut efter jag lade till det ovan:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amd_iommu=on kvm.ignore_msrs=1 iommu=pt"

OBS! Flaggorna kommer heta något annat om du har Intel.

Sedan behöver vi uppdatera vår Grub-konfiguration:

# update-grub

Nu kan vi starta om maskinen och gå in i UEFI för att aktivera ett par saker på vårt system.

  • AMD-SRV

  • IOMMU

Nu när vi bootar in i Linux så bör vi kunna se de olika IOMMU-grupperna under:
/sys/kernel/iommu_groups/*/devices/*

För att verifiera att IOMMU är påslaget så kan vi titta i dmesg och söka efter AMD-Vi.

# dmesg | grep -i amd-vi [ 0.734955] pci 0000:00:00.2: AMD-Vi: IOMMU performance counters supported [ 0.736312] pci 0000:00:00.2: AMD-Vi: Found IOMMU cap 0x40 [ 0.736313] pci 0000:00:00.2: AMD-Vi: Extended features (0x58f77ef22294ade): [ 0.736315] AMD-Vi: Interrupt remapping enabled [ 0.736315] AMD-Vi: Virtual APIC enabled [ 0.736315] AMD-Vi: X2APIC enabled [ 0.736387] AMD-Vi: Lazy IO/TLB flushing enabled

Här är ett skript för att enkelt se IOMMU-grupper:

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

Jag kan rekommendera moderkortet Asrock X570 Taichi då den har bra IOMMU-gruppering. Jag hade inga problem själv, men har läst att om inte hela kortet hamnar i samma grupp så får man testa andra PCI-e slots. Finns säkert andra trick man kan göra, men som tur är så slapp jag lära mig dem.

När jag kör ovanstående skript ser jag att samtliga 4-PCI ID's för kortet är i samma IOMMU-grupp.

# bash iommu.sh | grep 'TU106' IOMMU Group 27 0e:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU106 [GeForce RTX 2070 Rev. A] [10de:1f07] (rev a1) IOMMU Group 27 0e:00.1 Audio device [0403]: NVIDIA Corporation TU106 High Definition Audio Controller [10de:10f9] (rev a1) IOMMU Group 27 0e:00.2 USB controller [0c03]: NVIDIA Corporation TU106 USB 3.1 Host Controller [10de:1ada] (rev a1) IOMMU Group 27 0e:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU106 USB Type-C UCSI Controller [10de:1adb] (rev a1)

(Note: Jag greppade efter 'TU106' för att göra det lite snyggare här, kör skriptet utan grep)

Nu har vi säkertställt att vi har IOMMU påslaget, att det är aktiverat och igenkänt av vårt operativsystem och även att samtliga del-enheter av vår GPU är del av samma IOMMU-grupp.

Nästa steg är att isolera GPUn som ska användas till vår VM från vår host genom att specificera VFIO som drivrutin för kortet. Detta gör vi lättast genom Grub igen genom att redigera samma fil och lägga till samtliga 4 PCI IDs som parametrar till VFIO-drivern i våra Grub-options. Detta gör kortet oanvändbart i Linux, men ger KVM möjligheten att använda GPUn i en virtuell maskin.

PCI IDn är det näst sista vi ser på varje rad av outputen ovan, så för mitt system blir det:

  • 10de:1f07

  • 10de:10f9

  • 10de:1ada

  • 10de:1adb

Redigera /etc/default/grub och lägg till följande till samma rad som tidigare:

vfio-pci.ids=10de:1f07,10de:10f9,10de:1ada,10de:1adb

OBS!!! Klipp inte och klistra in dessa värden. Dina ID's kommer säkerligen se annorlunda ut!

Så här ser min grub config ut efter jag lade till det ovan:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amd_iommu=on kvm.ignore_msrs=1 iommu=pt vfio-pci.ids=10de:1f07,10de:10f9,10de:1ada,10de:1adb"

Sedan behöver vi uppdatera vår Grub-konfiguration igen:

# update-grub

Starta om datorn så att kärnan laddas om med VFIO drivern:

# reboot

För att verifiera att vår VM-GPU nu använder sig utav VFIO som driver kan vi köra:

# lspci -k | grep -B3 vfio Kernel modules: snd_hda_intel 0e:00.0 VGA compatible controller: NVIDIA Corporation TU106 [GeForce RTX 2070 Rev. A] (rev a1) Subsystem: ASUSTeK Computer Inc. TU106 [GeForce RTX 2070 Rev. A] Kernel driver in use: vfio-pci Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia 0e:00.1 Audio device: NVIDIA Corporation TU106 High Definition Audio Controller (rev a1) Subsystem: ASUSTeK Computer Inc. TU106 High Definition Audio Controller Kernel driver in use: vfio-pci Kernel modules: snd_hda_intel 0e:00.2 USB controller: NVIDIA Corporation TU106 USB 3.1 Host Controller (rev a1) Subsystem: ASUSTeK Computer Inc. TU106 USB 3.1 Host Controller Kernel driver in use: vfio-pci Kernel modules: xhci_pci 0e:00.3 Serial bus controller [0c80]: NVIDIA Corporation TU106 USB Type-C UCSI Controller (rev a1) Subsystem: ASUSTeK Computer Inc. TU106 USB Type-C UCSI Controller Kernel driver in use: vfio-pci

Perfekt. Nu är vår maskin förberedd för GPU-passthrough!

Dags att skapa en VM. Detta kan vi göra med virt-manager.
Följ stegen i GUI't för att skapa en Windows VM och välj resurser så att Linux kan köras parallelt med Windows, så lämna åtminstone 2 kärnor och 4GB RAM, helst mer. Personligen har jag gett maskinen 8 vCPUs som består av 4 fysiska kärnor med 2 logiska per kärna.

Ni behöver en Windows ISO som går att hämta från Microsoft gratis. Kör inte med någon egen variant om ni inte vet vad ni gör. Ladda hem den officiella ISOn från Microsoft, annars kan det uppstå problem med kompatibilitet.

Innan ni går vidare med sista steget (steg 5) men innan ni går vidare till att installera, välj Customize configuration before install

https://i.imgur.com/aM8EHiA.png

Under Overview, välj Q35 som chipset och UEFI x86_64: /usr/share/OVMF/OVMF_CODE.fd som firmware:

https://i.imgur.com/uqAbuzE.png

Innan vi kan köra måste vi sätta vår virtualisering i ett hidden-mode, och även lura NVIDIA's drivrutiner så att den inte detekterar att vi kör i en VM. Detta gör vi via terminalen via virsh.

# virsh edit <VM-namn>

Nu behöver vi lägga till lite rader i denna XML-filen:

... <features> ... <hyperv> ... <vendor_id state='on' value='randomid'/> ... </hyperv> ... </features> ...

Samt:

... <features> ... <kvm> <hidden state='on'/> </kvm> ... </features> ...

Nu finns det lite olika sätt att fortsätta. Antingen kan vi lägga till vår GPU innan vi installerar Windows, eller efteråt. Jag upplevde det lättare att lägga till grafikkortet efteråt. Testa lite som ni vill, jag var lite disträ under tiden jag gjorde det så jag kan ha upplevt fel som inte var relaterade till ordningen.

Jag rekommenderar starkt att använda VirtIO som drivrutiner på Windows-gästen för mycket bättre prestanda för lagring (VirtIO SCSI) och nätverk.

Under diskens options i virt-manager finns det Disk Bus, där man kan ändra till VirtIO. För att kunna installera Windows på en disk som har VirtIO som sin kontroller, så behöver vi installera drivrutiner innan vi installerar Windows (annars kan inte Windows detektera diskarna).

Ladda hem följande fil från Red Hat:

  • virtio-win.iso

Här är en bra guide för hur man installerar VirtIO-drivrutinerna för en Windows VM innan installation. I princip behöver man lägga till ytterligare en CD-ROM-läsare och montera ovanstående .ISO-fil där och under installation välja:

https://linuxhint.com/wp-content/uploads/2019/12/14-10-810x614.png

Browse:

https://linuxhint.com/wp-content/uploads/2019/12/15-10-810x611.png

Och sist amd64 --> w10

https://linuxhint.com/wp-content/uploads/2019/12/16-10.png

https://linuxhint.com/wp-content/uploads/2019/12/17-9.png

När Windows är färdiginstallerat så installera virtio-win-guest-tools.exe från ISOn på VMen och starta om. Guest-tools är kritiskt. Den hjälper KVM att hantera filskrivningar, suspend mode, mer effektiv minneshantering osv.

När Windows senare är installerat så är det dags att lägga till GPUn! Starta virt-manager, och sen Add hardware --> PCI Host Device --> och lägg till alla komponenter av kortet (4 i mitt fall).

Sist men inte minst behöver vi mus/tangentbord till vår VM. Som tur är har qemu en feature där man via evdev kan pass through kontrollenheter. För att göra det behöver vi först identifiera vårt tangentbord och mus under /dev/input/by-id/.

sagan ~ $ ls -l /dev/input/by-id/ total 0 lrwxrwxrwx 1 root root 9 Mar 25 20:01 usb-04d9_USB_Keyboard-event-if01 -> ../event6 lrwxrwxrwx 1 root root 9 Mar 25 20:01 usb-04d9_USB_Keyboard-event-kbd -> ../event3 lrwxrwxrwx 1 root root 9 Mar 25 20:01 usb-Kingsis_Peripherals_ZOWIE_Gaming_mouse-event-mouse -> ../event2 lrwxrwxrwx 1 root root 9 Mar 25 20:01 usb-Kingsis_Peripherals_ZOWIE_Gaming_mouse-mouse -> ../mouse0 lrwxrwxrwx 1 root root 9 Mar 25 20:01 usb-Kingston_HyperX_Cloud_Flight_Wireless_Headset-event-if03 -> ../event7 sagan ~ $

Filerna vi är ute efter är dessa:

  • usb-04d9_USB_Keyboard-event-kbd

  • usb-Kingsis_Peripherals_ZOWIE_Gaming_mouse-event-mouse

Dvs filerna som har event med i namnet. För att lägga till denna funktion till vår VM behöver vi redigera XML-filen igen:

# virsh edit <VM-namn>

Och i slutet, av filen, innan </domain> lägger vi till:

<qemu:commandline> <qemu:arg value="-object"/> <qemu:arg value="input-linux,id=mouse1,evdev=/dev/input/by-id/usb-Kingsis_Peripherals_ZOWIE_Gaming_mouse-event-mouse"/> <qemu:arg value="-object"/> <qemu:arg value="input-linux,id=kbd1,evdev=/dev/input/by-id/usb-04d9_USB_Keyboard-event-kbd,grab_all=on,repeat=on"/> </qemu:commandline>

Notera att det är den absoluta filvägen för muset och tangentbordet som behövs. Så fort VMen startas kommer tangentbordet och musen att gå över till att kontrollera VMen. Genom att trycka på båda Ctrl på tangentbordet samtidigt så kan man toggla mellan Host <-> VM. Glöm inte att ansluta en display-kabel mellan VM-GPUn och din skärm och byt input när VMen startas.

Nu har vi en fungerande VM med GPU-passthrough! Starta den via virt-manager eller terminalen med:

$ virsh start <vm-namn>

Prestanda-förbättringar
Om ni kör AMD så rekommenderar jag starkt att pinna CPU-kärnorna så att den virtuella maskinens alla kärnor befinner sig på en sida av CCX. Detta reducerar latency enormt, eftersom all data som en kärna kan tänkas behöva finns i den delade L3-cachen. För att hjälpa er få en överblick på er CPU's topografi kan ni köra kommandot lstopo. För att installera det behövs det ett paket som heter hwloc

# apt install hwloc # lstopo

https://i.imgur.com/q6lXKgw.png

Här kan vi se att fysiska kärnor 0-3 är ett set av kärnor med sin egna cache, med 4-7 på den andre. Jag valde att dedikera de logiska kärnorna på 4-7 för VMen, vilket ledde till en förminsking av overhead och därmed närmre native prestanda.

<vcpu placement='static'>8</vcpu> <iothreads>1</iothreads> <cputune> <vcpupin vcpu='0' cpuset='8'/> <vcpupin vcpu='1' cpuset='9'/> <vcpupin vcpu='2' cpuset='10'/> <vcpupin vcpu='3' cpuset='11'/> <vcpupin vcpu='4' cpuset='12'/> <vcpupin vcpu='5' cpuset='13'/> <vcpupin vcpu='6' cpuset='14'/> <vcpupin vcpu='7' cpuset='15'/> <emulatorpin cpuset='0-1'/> <iothreadpin iothread='1' cpuset='0-1'/> </cputune> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='4' threads='2'/> <cache mode='passthrough'/> <feature policy='require' name='topoext'/> </cpu>

Överklockning!
Vi är ju trots allt på Sweclockers. Eftersom Linux-kärnan inte riktigt hanterar rejäla överklockningar lika bra som Windows-kärnan så kändes det mer safe att köra på moderkortets integrerade auto-OC funktion på alla kärnor. GPUn går att överklocka i VMen precis som på baremetal så med lite OC med MSI Afterburner så kan man kräma ur mer prestanda.

För övrigt, VMens konfiguration är något som inte är etsat i sten. Man kan ändra CPU-parameterar och nästan hela VMens konfiguration senare. Allt förutom chipset och UEFI/BIOS-firmware kan ändras och justeras i efterhand.

Prestandatester
https://i.imgur.com/bbXbQAk.png
https://i.imgur.com/jmdk69o.png
https://i.imgur.com/Ib3ovE9.png
https://i.imgur.com/9f90u0v.png
https://i.imgur.com/lYwVyMU.png
https://i.imgur.com/DWflTHP.png

Tankar på förbättringar
Något jag hade velat göra annorlunda skulle vara att partionerna min NVMe SSD med LVM, och skapa en volym för min VM-data, för att sedan passa genom den partitionen till VMen. Då hade jag fått blockenhets-lagring med lite overhead istället för att skriva till en fil på ett filsystem. Fördelen med att filbaserad lagring är att backups blir väldigt smidigt. Kör man sen ett filsystem som ZFS för sina backups kan man enkelt ta snapshots.

Lagrings-prestandan i VMen är OK, men kan vara lite bättre. GPU prestandan är utmärkt, ungefär 5% prestanda är tappad ungefär. Eftersom inte hela CPUn är virtualiserad blir det svårt att testa men det är mer än tillräckligt bra med 8 vCPUs. Väldigt låg latens när jag spelar och jag spelar CS:GO och Rocket League utan konstigheter. Jag har ofta bättre ping än mina vänner, vilket är lite kul också.

För övrigt så har jag även lagt till en bluetooth-dongel så jag kan ansluta min PS4-kontroller, och även mitt trådlösa USB headset och allt bara funkar. Jag är shockad hur bra det fungerat hittils och jag har väl kört denna setupen i snart 2 månader.

-------------------------------------------------------------------
Proper dokumentation: https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF
Min XML för referens (uppdaterad 2021-03-26): https://pastebin.com/NiRaB6Ad

Tjena, jag tänkte ge mig på detta, har dock noll kunskap om Linux, men då du gjort ovanstående kanske du kan peka mig på rätt väg?
Det jag skulle vilja få till är följande:
Linux hemmaserver med:
VM - Home assistant
VM (eller direkt i Linux?) - Fildelning /Cloud/Backup
VM - Windows för spelande (på RTX 2080)

Utöver detta funderar jag på Jellyfish och sen tillkommer säkert diverse efter vägen.
Jag kör idag på en Ryzen 3800x men tänker jag kanske borde uppgradera till en 5900x för att maxa kärnor och framtidssäkerhet.

Det jag undrar är:
Kan jag sätta en speciell hd till en VM? Tänker isf om jag sätter min nvme till Windows och en till Home Assistant och resterande till Fildelningen/Cloud/backup.

Måste man låsa kärnorna till varje VM, eller kan det ske dynamiskt så att det utnyttjas där det behövs? Samma med RAM?

Är det någon speciell tillverkare av gpu som funkar bättre än andra i Linux? Iom jag inte har inbyggd gpu får jag ju skaffa ett extra kort för att kunna låsa RTX kortet till Windows som du gjort.

Hoppas du har tid att ge dina tankar på mina frågor så här långt.. kommer säkert fler på vägen.

Permalänk
Medlem
Skrivet av Olsson80:

Absolut! Jag kan försöka hjälpa så gott jag kan. Kul projekt! Först och främst, med allt Linux, finns det många tillvägagångssätt att komma fram till ett fungerande resultat.

Jag kan ge några exempel på hur man kan göra detta. Först och främst behöver du ett grund OS som du installerar på hårdvaran. Finns för och nackdelar med alla. Jag tycker egentligen det finns två bra val för en som är ny till Linux och som vill använda det till virtualisering:

  • Ubuntu 22.04

  • Proxmox 7

Ubuntu Desktop för och nackdelar

  • + Är en Linux distribution baserat på Debian, väletablerat och känt sen länge

  • + Stort och aktivt community där man enkelt kan få hjälp med det mesta

  • + mycket dokumentation och nybörjarvänligt

  • + Modernt OS med stort utbud av paket och appar

  • + Kommer i olika "flavors", dvs grafiska gränssnitt (Kubuntu, Lubuntu osv)

  • - Lite bloated enligt vissa

  • - Inte designad för att hantera många körande virtuella maskiner samtidigt utifrån en användar sida (dock fullt kapabelt till det)

  • - För att konfiguera en gäst VM med GPU passthrough kräver en del tålamod och försök och misslyckande (guiden ovan beskriver ett tillvävagångssätt)

  • - Kan upplevas clunky att använda utan att man customizar det till ens smak

Proxmox för och nackdelar

  • + Är en Linux distribution baserat på Debian, väletablerat och känt sen länge

  • + Designat från grunden till att vara en virtualiseringsplatform för enterprise

  • + Mycket enkelt GUI där man kan hantera snapshots, backups, inställningar, begränsningar av resurser osv

  • + Fullt stöd för Proxmox Backup Server som hanterar fulla samt inkrementella backups där man enkelt kan återställa enstaka filer i flera olika filsystem, allt från Windows (NTFS) till olika Linux som ZFS, XFS, Ext4, och med LVM dessutom. Fullständiga backups och återställningar går givetvis också.

  • + Stöd för flera olika lagringsbackend såsom ZFS, Ceph, block och filbaserat, m.fl

  • + Läggs till fler och fler funktioner och förenklingar, aktivt projekt

  • - Eftersom Proxmox installeras på ZFS kan det kräva lite mer minne än ett enkelt workstation-baserat OS (minst 4GB)

  • - Inte lika funktionsrikt som andra mycket större aktörer inom virtualiseringsvärlden såsom ESXi (men så länge man inte driver en vinstdrivande verksamhet på 100-tals användare kan man gott klara sig på Proxmox)

Du kan absolut tilldela en, eller flera speciella diskar till en viss virtuell maskin. Virtualisering fungerar bäst med blockbaserad lagring, dvs inte en mapp eller en fil, utan en blockenhet såsom en disk eller en partition. Du kan, tex., partionera en 2TB NVMe disk till 2 partitioner, en på 1.8TB och en på 200GB, och tilldela den stora till din Windows gäst och den mindre till din Home Assistant.

Resterande diskar kan du köra till fildelning/backup VM. Om du väljer att gå via Proxmox hållet så kan jag mer än starkt rekommendera Proxmox Backup Server. Den kör du i en VM på Proxmox (eller om du har möjlighet en annan dator), och sätter upp ett schema med hur ofta du vill backa upp en maskin, och hur länge du vill bevara backupsen, sen sköter PBS resten. Låter enkelt, men det är guld med en sådan integration mellan din virtualiseringsplatform och dina VM backups. Får du ransomware på din maskin, kan du med några klickningar återställa filsystemet till hur den var innan.

Ett alternativ till en bra, libre och gratis backup lösning är https://www.elkarbackup.org/Elkarbackup. Den kan du köra på en egen VM, alternativt en VM + docker.

Här finns en guide för att sätta upp Home Assistant med Proxmox - https://www.wundertech.net/how-to-set-up-home-assistant-on-pr....

Du behöver inte låsa kärnor till varje VM, jag har faktiskt märkt av några prestandatester jag gjort att med moderna CPUer som 5900X så är dem så pass bra att man inte tjänar så värst mycket i praktiken av att pinna CPU kärnor längre, så lättast är att hålla det dynamiskt. Jag tvivlar på att det lär märkas av någon skillnad ändå. Absolut, det samma gäller RAM. Du behöver installera ett program på dina VMar (QEMU guest agent) som hjälper din server med minneshanteringen, annars funkar det inte lika bra.

När det gäller vilken GPU att använda, jag har personligen bara erfarenhet av NVIDIA. Man fick ju förr dölja för sin gäst VM att man körde NVIDIA för att det skulle fungera, men det är borttaget nu, och det tillåts köra NVIDIA med officiella drivrutiner på en virtuell maskin. Däremot har jag hört mycket gott om AMD i Linuxvärlden. Deras drivers är inkluderade i kärnan och behöver således ingen handpåläggning för att fungera.

Om du vill köra Ubuntu hållet, så går det absolut, men det kommer vara lite uppförsbacke med att konfigurera allt innan det känns bra. Om det låter kul (det tycker jag!) så go for it. För att om du hade tänkt använda Windows VM primärt ändå, så kanske Proxmox är ett bättre val då det ger dig fler funktioner, mer användarvänligt, backups med integration till din platform och beprövat och tokstabilt virtualiseringsplatform att ha dina maskiner på.

Lycka till och skriv gärna om du har fler frågor!

Visa signatur

We are the music makers, and we are the dreamers of dreams.
Youtube | Spotify Playlists | Soft | Rapp | Rytm | Kött | Kalas |

Permalänk
Medlem

Jag kom på en sak till;

Om du vill labba med olika andra saker, som att köra en egen proxy server, NAS, nextcloud server, nätverksmonitorering och cybersäkerhet osv osv, så kommer Proxmox absolut att underlätta det. Du kan spinna upp en ny VM på mindre än en minut, redan ha backups/snapshots konfigurerat enligt policy och spara en hel del tid och sätta igång direkt.

Medans på Ubuntu som grund går det absolut, men med betydligt fler manuella steg.

Visa signatur

We are the music makers, and we are the dreamers of dreams.
Youtube | Spotify Playlists | Soft | Rapp | Rytm | Kött | Kalas |

Permalänk
Medlem

Men lysande, jag tänker jag kör exakt som du skriver (borde vara lättast iom jag är helt noob på detta).

Så för att komma igång behöver jag:
Installera Proxmox som OS först och främst och det sätter jag upp utan att ha spel gpu i för enkelhetens skull.
Sen få igång en VM i taget. Tänker jag börjar med de enklare först och sist en Windows/spel vm.
Jag har ett gäng ssd och nvme diskar som jag tänkte köra dem olika delarna på, så nvme kan jag reservera helt till Windows och sen en disk till Home assistant och sen har jag nog ett par diskar jag kan ha som filserver med.
Tänkte införskaffa några server diskar med, behöver jag tänka på något där eller det är bara köpa typ Ironwolf Pro diskar?

Proxmox backup körs också som vm och inte direkt på servern alltså?

Såg att mitt moderkort bara hade 1 pci plats (trodde det fanns 2) så jag måste byta cpu till en 5700G, men det jag skall köra borde väl klara sig på dem kärnorna den har tänker jag?

Hur mkt ram behövs? Räcker 32 eller skall man fläska på med så mkt man kan? Tror kortet klarar 128 som mest..

Permalänk
Medlem

Det tycker jag låter som en bra idé! Precis, börja med att installera Proxmox som OS, och ifall du har möjlighet med 2 relativt säkra diskar, SATA SSD är ganska prisvärda att använda, så installera Proxmox på 2 drives med ZFS mirror (vilket innebär att om en OS disk dör, så kan du ersätta den sönder senare men samtidigt kunna använda servern).

Notera att det står RAID1 och inte RAIDZ2 som är något annat

ZFS komprimering är nämligen utmärkt, och kostar väldigt lite CPU, och med checksumming minskar man risker för datakorruption (ersätter dock inte ECC minnen, men det är overkill tycker jag för hemmaserver så vida man inte kommer över några billigt).

Därefter är installationen rätt så straight forward. När den sen är klar, så kommer det stå på vilken URL du kan nå webb-gränssnittet och en shell login prompt:

(inte adressen på bilden )

Det låter som du har bra med olika diskar som passar ändamålen fint. När det gäller att införskaffa nya så kan jag rekommendera CMR diskar. Ironwolf Pro är CMR vad jag vet, och dessa håller sin prestanda och livslängd längre statistiskt än SMR. När det kommer till filserver, jag kan starkt rekommendera dig att köra ZFS som filsystem på den, och sedan exportera din ZFS-lagring som tex. samba till din Windows VM. Anledningen är att det är så överlägset och som gjort för att hoarda och managera data. ZFS behöver dock mycket minne för att fungera bäst, eftersom den håller två tabellvärden av blockdata i minnet alltid; Most Recently Used och Most Frequently Used data, vilket innebär att den datan man accessar oftast alltid finns i minnet, och har således fantastiskt bra prestanda. I tillägg har den magiskt bra automatisk komprimering på filsystemnivå på datan (bättre eller sämre beroende på vilken typ av data). Man kan även, på blocknivå, skicka sin ZFS pools och filsystem (i princip mappar med fler funktioner) direkt till en annan server nånstans via SSH med relativt bra prestanda. Spelar ingen roll om det är sekventiell data eller hundratusentals småfiler på 4K styck, blockbaserad transfer befinner sig i ett lager under filsystemet, vilket innebär att den särskiljer inte mellan filer, filstorlek, metadata och dylikt, det är bara en dataström.

NTFS baserade filservrar och backuplösningar är begränsade i deras brist på funktionalitet, därför jag proppsar för en ZFS filserver.

Gällande CPUn, 5700G, så absolut kommer den enkelt klara av att driva dina icke-gaming VMar. Kör dessa utan GUI, med mjukvara som styrs över webben, såsom Proxmox själv. På det sättet ansträngs inte CPUns grafik alls i princip.

Du kan absolut köra din Proxmox Backup Server direkt på din Proxmox server, men du tappar inte så mycket genom att köra den på en VM ändå, då du abstraherar bort dina backups från din server. Visst så dör din server så fungerar inte backups heller, däremot kan du konvertera din backup VM och köra den i molnet tex, eller om du har en vän som också kör virtualisering så kan ni ha varandras backups körandes hos varandra. Det är lite mer flexibelt att köra med VMs när man har möjlighet överlag.

Jag tror att du hade klarat dig på 32GB. Låt säga 16GB för Windows VM, 8GB för Proxmox och 4GB vardera för Home Assistant och Filbackup. Det hade funkat men lämnar inte mycket marginal till något mer. 64GB hade gett dig plats för lite labbande och lite mer minne till din gaming VM som jag tror den hade mått bra av.

Och slutligen, ursäkta väggen av text, nätverkskonfigurering. Jag föredrar att köra mina VMs i en bridge, vilket innebär ett virtuellt nätverksinterface som sammankopplar mina VMars nätverk med mitt fysiska. Det betyder att min hemmarouter tror att det är nya maskiner i hushållet och tilldelar dem IP-adresser som allt annat. Underlättar nätverket hemma.

Finns en hel del i Proxmox Wiki, men här är ett exempel på hur man i Proxmox konfigurerar en VM bridge:

Fil: /etc/network/interfaces

auto lo iface lo inet loopback iface eno1 inet manual auto vmbr0 iface vmbr0 inet static address 192.168.10.2/24 gateway 192.168.10.1 bridge-ports eno1 bridge-stp off bridge-fd 0

-- källa https://pve.proxmox.com/wiki/Network_Configuration

Visa signatur

We are the music makers, and we are the dreamers of dreams.
Youtube | Spotify Playlists | Soft | Rapp | Rytm | Kött | Kalas |

Permalänk
Medlem

Tusen tack! Jag köper ihop delarna som fattas, börjar med stegen ovan och uppdaterar längs vägen!
Detta är ovärdeligt!! Verkligen, tusen tack!

Permalänk
Avstängd

Extremt snyggt! +1