Licentievrije Windows-VDI op Proxmox met een Intel Arc Pro B50 — en de Firmwarelimiet Die Het Stopte

Waarom Dit Tot Nu Toe Duur Was

VDI — Virtual Desktop Infrastructure — levert een volledige desktop vanuit een datacenter of cloud in plaats van vanaf het apparaat voor je. Een gebruiker meldt zich aan vanaf een laptop, een thin client of zijn eigen machine, en krijgt een vertrouwde Windows- of Linux-desktop waarvan de apps, bestanden en verwerking allemaal centraal gebeuren.

De aantrekkingskracht voor een IT-team is dat patchen, toegangscontrole en gegevensbescherming allemaal op één plek gebeuren, en mensen dezelfde desktop overal kunnen bereiken.

Het obstakel is nooit de hypervisor geweest. Het is de GPU geweest.

Eén fysieke GPU delen tussen meerdere desktops is NVIDIA’s terrein geweest, en NVIDIA rekent voor de vGPU-software die het opdelen doet. Die licentie is waarom VDI met hardware-versnelde graphics grotendeels het domein is geweest van bedrijven met bedrijfsbudgetten. Een jaarlijkse vergoeding betalen om iets in te schakelen dat het silicium al kan is een moeilijk ding om enthousiast over te zijn.

Intel veranderde de rekensom met de Arc Pro-lijn. Deze kaarten ondersteunen hardware-opdeling via standaard-SR-IOV, wat een PCIe-feature is in plaats van een product. Er is dan ook geen licentieserver, geen abonnement, en geen aparte vGPU-software om te kopen.

Dus ik bemachtigde een Intel Arc Pro B50 om te zien hoe schoon die met Proxmox samengaat. Het korte antwoord: het mechanisme werkt precies zoals geadverteerd, en toen kwam de firmware in de weg. Beide helften staan hieronder.

De Olifant: Je Hebt Eerst Windows Nodig

Voordat iets hiervan werkt, wil de kaart zijn firmware bijgewerkt. Intel levert die update binnen de Windows-driver-installer.

Wat lastig is, want de reden dat je de kaart kocht is om hem onder Proxmox te draaien.

Er is een weg eromheen die niets dan Proxmox nodig heeft: bouw een Windows-VM, geef de hele kaart eraan door, laat Windows de firmware updaten, en geef de kaart dan terug aan de host. Het is een bootstrap-lus, en het is de moeite waard erover te weten voordat je de build plant in plaats van erna.

De Kaart Vinden

Op de Proxmox-host, lspci om hem te lokaliseren:

lspci

Hier is hij op 03:00.0, gerapporteerd als Battlemage G21, het silicium achter de Arc Pro B50. Noteer het adres. Je hebt het meerdere keren nodig, en er is een aparte audiofunctie op 04:00.0 die ermee meekomt.

De Hele Kaart Doorgeven Aan Een Windows-VM

Voeg de kaart toe aan een Windows-VM als raw PCI-apparaat. In de hardware van de VM is dat een PCI Device-entry: 0000:03:00 met pcie=1:

De moeite waard op te merken wat die VM verder is, want niets ervan is toevallig: Q35-machinetype, OVMF-firmware, VirtIO SCSI single, en een TPM voor Windows 11. Q35 in het bijzonder is hiervoor niet optioneel. Een doorgegeven GPU op i440fx verschijnt als legacy-PCI-apparaat, wat de verkeerde vorm is voor een moderne graphics-driver. Dat wordt behandeld in Gebruik Altijd Q35, Niet i440fx.

Boot de VM en controleer dat Windows de kaart ziet:

Hij verschijnt als een Microsoft Basic Display Adapter omdat er nog geen driver geïnstalleerd is. Dat is de verwachte toestand, en het is genoeg. Windows heeft de hardware gevonden.

De Firmware Updaten

Haal de huidige driver van Intels Arc Pro B50-downloadpagina. Op het moment van schrijven was dat versie 32.0.101.8306 (Q4.25), voor Windows 11 en Windows 10 22H2:

Installeer hem, en laat de firmware-update draaien als onderdeel van het proces in plaats van vroeg af te breken. Die firmwarestap is de hele reden voor deze omweg.

Wanneer hij klaar is, geef de kaart terug aan de host en herstart, zodat hij volledig herinitialiseert onder Proxmox.

Bevestigen Dat SR-IOV Er Is

Vraag de kaart nu wat hij kan:

lspci -v

De regel die ertoe doet:

Capabilities: [320] Single Root I/O Virtualization (SR-IOV)

Dat is het hele voorstel in één regel lspci-uitvoer, zonder licentie eraan.

Drie andere dingen in die uitvoer zijn de moeite waard te lezen terwijl je er toch bent:

• Kernel driver in use: xe — de kaart draait op Intels nieuwere xe-driver in plaats van i915, wat de virtual functions zal aanmaken.
• [420] Physical Resizable BAR en [220] Virtual Resizable BAR — de kaart ondersteunt resizable BARs, en zijn virtual functions ook. De moeite waard te weten wat dat je kost in adresruimte als je er meerdere doorgeeft: zie PCIe Resizable BAR en Moderne GPU’s.
• IOMMU group 13 — de kaart zit in een groep op zichzelf, wat is wat je wilt voor schone passthrough. Waarom dat uitmaakt staat in het IOMMU-tax-artikel.

De Virtual Functions Bij Boot Aanmaken

Virtual functions zijn niet persistent. Erom vragen is een write naar sysfs, dus het moet bij elke boot gebeuren.

tmpfiles.d is een nette manier om dat declaratief te doen, in plaats van een script aan een unit-file te schroeven:

Het bestand doet drie klussen op volgorde.

Maak de virtual functions aan, door het aantal naar de sriov_numvfs van de physical function te schrijven:

w /sys/devices/pci0000:00/0000:00:01.1/0000:01:00.0/0000:02:01.0/0000:03:00.0/sriov_numvfs  - - - -  4

Ontkoppel elke nieuwe function van xe, want de host-driver claimt ze zodra ze verschijnen en een gast kan geen apparaat hebben dat de host vasthoudt:

w /sys/bus/pci/drivers/xe/unbind - - - - 0000:03:00.1
w /sys/bus/pci/drivers/xe/unbind - - - - 0000:03:00.2
w /sys/bus/pci/drivers/xe/unbind - - - - 0000:03:00.3
w /sys/bus/pci/drivers/xe/unbind - - - - 0000:03:00.4

Bind ze aan vfio-pci, wat is wat ze beschikbaar maakt om door te geven:

w /sys/bus/pci/drivers/vfio-pci/bind - - - - 0000:03:00.1
w /sys/bus/pci/drivers/vfio-pci/bind - - - - 0000:03:00.2
w /sys/bus/pci/drivers/vfio-pci/bind - - - - 0000:03:00.3
w /sys/bus/pci/drivers/vfio-pci/bind - - - - 0000:03:00.4

Let op de adressen: de physical function is 03:00.0 en de virtual functions komen op als .1 tot en met .4.

Eén detail over w dat de volgorde verklaart, en dat je zal bijten als je het fout doet. systemd documenteert het als: “Write the argument parameter to a file, if the file exists.” sriov_numvfs bestaat pas zodra een driver zich aan de physical function heeft gebonden, en de virtual-function-paden bestaan pas zodra die write heeft plaatsgevonden. Dus de volgorde in het bestand is niet stilistisch. Elke regel hangt ervan af dat de vorige effect heeft gehad.

Waarom Twee, en Niet Vier

Driver 32.0.101.8306 — degene hierboven geïnstalleerd — draagt graphics-firmware BMG__21,1162, en dat is de release waarin Intel voor het eerst officieel SR-IOV op Arc Pro inschakelde. Intels vermelde standaard voor de B50 in die release is twee virtual functions, elk met een VF Local Memory BAR van 8 GB.

Wat het getal rekenkunde maakt in plaats van beleid. De B50 heeft 16 GB. Bij 8 GB per virtual function is twee alles wat past.

Er is een kanttekening die de moeite waard is te kennen als je op zoek gaat naar een workaround. Voordat officiële ondersteuning bestond, draaiden sommige mensen oudere firmware die 12 virtual functions op een B50 blootlegde, en teruggaan naar driver 32.0.101.6979 herstelt dat aantal. Die 12 deelden dezelfde 16 GB, dus elk kreeg een fractie van het geheugen dat de mijne krijgen. Intels standpunt is dat twee bewust gekozen werd om elke function genoeg compute, capaciteit en bandbreedte te geven om voorspelbaar te gedragen.

Dus de limiet kan verplaatst worden, maar niet door jou. Het maximale VF-aantal en de VF Local Memory BAR-grootte leven in de IFWI, er is geen publiek gereedschap om beide te veranderen, en het ondersteunde antwoord op een huidige stack is twee.

Hoeveel Desktops Elke Kaart Je Geeft

De B50 is de kleine kaart in de familie, en zijn twee functions zijn het dieptepunt van de familie. Als het aantal zitplaatsen is waar je om geeft, koop dan verder in het assortiment.

De hele Battlemage Arc Pro-lijn doet SR-IOV. Wat verschilt is hoeveel functions de firmware zal uitsnijden, en dat volgt het geheugen:

Alleen de B50-rij is door Intel gedocumenteerd. De B60- en B70-getallen zijn wat mensen rapporteren uit lspci, en ze zijn meer dan eens verschoven. De B60 in het bijzonder ging van 24 naar 7 in een firmware-update, wat hetzelfde soort versmalling is als de B50 zag. Niemand lijkt überhaupt een VF-aantal voor de B65 te hebben gepubliceerd, dus behandel die rij als onbekend in plaats van als nul.

Twee dingen volgen uit die tabel, en beide doen er meer toe dan enig enkel getal erin.

Het VF-aantal is een geheugendeling, geen die-feature. Intels regel is dat een grotere VF Local Memory BAR minder functions betekent. Daarom geeft de 16 GB-kaart twee en de 32 GB-kaarten zeven: niets aan de shaders van de GPU beslist het.

Controleer de kaart die je op het punt staat te kopen, niet de familie. SR-IOV-aanwezigheid heeft gevarieerd tussen bordvendors op dezelfde chip — Sparkle’s B60 Blower werd aanvankelijk geleverd zonder de capability überhaupt zichtbaar en kreeg die pas na een igsc-firmware-update. Vraag om lspci -v-uitvoer van het exacte model, of begroot een firmware-update voordat je hierop rekent.

De Dual B60 Is Twee Kaarten Die Eén Beugel Dragen

Maxsuns Arc Pro B60 Dual 48G Turbo is de interessante voor het aantal zitplaatsen, en het ding om te begrijpen is dat de 48 GB geen pool is.

Het zijn twee B60-GPU’s — twee BMG-G21-dies — op één bord, met 24 GB GDDR6 aan elk bedraad, en geen PCIe-bridge-chip ertussen. Beide dies hangen rechtstreeks aan de x16-gouden vingers op PCIe 5.0 x8 elk.

Wat betekent dat de host het slot voor je moet splitsen. De kaart heeft het primaire x16-slot gebifurkeerd naar x8/x8 nodig, en de meeste consumentenborden schakelen dat niet standaard in. Het is een firmware-instelling waar je naar op zoek gaat, in dezelfde categorie als de IOMMU- en ACS-instellingen die iets hiervan nodig heeft.

Krijg dat goed en het besturingssysteem ziet twee aparte GPU’s, elk met zijn eigen physical function en zijn eigen SR-IOV-capability. Dus je krijgt twee stel virtual functions uit één slot — 14 zitplaatsen als elke die zich gedraagt als een enkele B60 — en het tmpfiles.d-bestand hierboven verdubbelt, één sriov_numvfs-write per die.

Krijg het fout en je ziet één GPU en de helft van de kaart is onzichtbaar.

De moeite waard duidelijk te zijn over wat de 48 GB niet is: een gast die aan een virtual function op de eerste die hangt, kan het geheugen van de tweede die niet bereiken. Dit zijn twee 24 GB-kaarten in één fysieke ruimte, wat precies is wat je wilt voor VDI-zitplaatsen en precies wat je niet wilt voor één groot model.

Dus: als twee zitplaatsen genoeg zijn, is de B50 een 70 W-kaart die het doet. Als je er zeven wilt, plan rond een B70. Als je er veertien wilt en een bord hebt dat bifurkeert, brengt de dual B60 je er in één slot.

Kun Je AI Draaien Op Een Virtual Function?

Kort antwoord: behandel het als niet-ondersteund. Langer antwoord, want de reden doet ertoe en het is niet degene die je zou raden.

Deze worden op de markt gebracht als AI-kaarten en ze doen niet alsof. De 128 XMX-engines van de B50 zijn beoordeeld op 170 piek-TOPS, de B70 op 367, en Intels softwareverhaal is echt — vLLM serveert modellen van 8B tot 120B op Arc Pro B-serie, en IPEX-LLM en llama.cpp’s SYCL-backend draaien er allebei op.

Maar kijk hoe elk van die resultaten wordt geproduceerd. vLLM’s eigen Arc Pro-cijfers komen van een Docker-container op bare metal, op systemen met vier en acht hele B60-kaarten die tensor parallelism doen. Intels post noemt SR-IOV of virtual functions geen enkele keer.

Dat patroon houdt overal stand waar ik keek. Intel beperkt de SR-IOV-use-cases tot gevirtualiseerde remote desktop, gast-OS-graphics-versnelling, en media-encode en -decode. Compute staat niet op die lijst, en ik kon geen enkel gepubliceerd geval vinden van iemand die LLM-inference draait binnen een VM die aan een virtual function hangt.

Wat mensen werkelijk doen is veelzeggend: ze draaien het model in Docker op de host, en geven virtual functions aan VM’s voor desktops. Eén persoon die beide tegelijk doet rapporteert simpelweg dat “VRAM gets pretty tight.”

Wat het echte probleem is, en het is rekenkunde in plaats van driverondersteuning.

Een virtual function krijgt een vaste plak lokaal geheugen — 8 GB op de B50, in firmware gezet. Die plak is het harde plafond voor gewichten plus KV-cache in die gast, en het groeit niet omdat de kaart meer heeft. Een 8B-model op FP16 is rond de 16 GB aan gewichten voordat je überhaupt enige context toevoegt, dus het past niet in een B50-virtual-function op welke driver dan ook. Kwantiseer naar Q4 en een 8B past in ongeveer 4 GB, wat een paar GB voor context overlaat — wat werkt, maar een heel eind van wat de kaart onverdeeld kan.

Dus de twee workloads concurreren om hetzelfde geheugen, en de deling wordt in firmware beslist voordat een van beide begint.

Als AI de klus is, verdeel de kaart niet. Geef het hele ding door aan één VM — dezelfde hostpci0-passthrough die eerder in deze post voor de firmware-update werd gebruikt — of draai de container op de host en sla virtualisatie over voor die workload. Beide geven het model alle 16 GB en de volledige XMX-array.

Als VDI de klus is, zijn virtual functions juist, en verwacht desktop-graphics in plaats van een inference-server achter elk. Hardware-versnelde desktops, videoweergave en encode werken. Daar is het mechanisme voor gedocumenteerd.

De moeite waard duidelijk te zeggen: afwezigheid van gepubliceerd bewijs is geen bewijs dat het faalt. De xe-driver legt compute bloot via Level Zero en OpenCL, en het is heel goed mogelijk dat een VF-ondersteunde gast die prima opstart. Maar niets van Intel zegt dat het gevalideerd is, niemand lijkt het werkend te hebben getoond, en het geheugenplafond beperkt de opbrengst zelfs als het wel zo is. Dat is niets om een plan op te bouwen.

Wat Het Nog Waard Is

Twee virtual functions is twee hardware-versnelde Windows-desktops uit één kaart, zonder vGPU-licentie, zonder abonnement en zonder licentieserver. Op een hypervisor die niets kost om te draaien. Dat is genoeg om te bewijzen dat de aanpak werkt, wat de eerlijke klus voor een B50 is. Het is de onderkant van het assortiment.

Voor een echte VDI-deployment zou ik de dual B60 specificeren.

Veertien functions uit één slot — als elke die zich gedraagt als een enkele B60 — plaatst het in hetzelfde zitplaats-territorium als de NVIDIA-kaarten die voor deze workload verkocht worden, tegen een veel lagere prijs, en met niets om per gebruiker te licentiëren. Dat laatste deel is degene die zich opstapelt. NVIDIA’s vApps, vPC en RTX vWS worden allemaal per gelijktijdige gebruiker gelicentieerd, ofwel als jaarabonnement of als eeuwigdurende licentie die naast een vijfjarig support- en onderhoudsabonnement gekocht moet worden. Elke zitplaats is een regelpost, en die komt weer langs. Aan de Intel-kant is er geen equivalente regel. Je koopt de kaart.

En het mechanisme is het deel dat op de lange termijn ertoe doet. SR-IOV op de GPU is een PCIe-capability, geen producttier, dus het tmpfiles.d-bestand groeit gewoon mee met wat de kaart ook toestaat.

De vorm is één sriov_numvfs-write, dan een unbind en een bind voor elke function — dus twee functions is vijf regels, en de negen hierboven zijn vier functions gevraagd op een kaart die er twee levert. Zeven functions is vijftien regels. Een dual B60 is dertig, want elke die is zijn eigen physical function en krijgt zijn eigen sriov_numvfs-write.

Niks anders verandert als je het opschaalt. Er verschijnt op geen enkel punt in dat bestand een licentieserver.

Referenties

• Intel support — waarom de nieuwste Arc Pro B50-firmware 2 SR-IOV VF’s toont — de gezaghebbende uitspraak: SR-IOV officieel ingeschakeld vanaf graphics-firmware BMG__21,1162 in driver 32.0.101.8306, twee VF’s met elk een 8 GB VF Local Memory BAR op de B50, en het maximale VF-aantal en de BAR-grootte gezet op IFWI-niveau zonder publiek gereedschap om ze te veranderen
• Intel Community — “Why did the latest Intel Arc Pro B50 firmware nerf SR-IOV VFs from 12 to 2?” — de 12-VF-pre-officiële firmware, de 32.0.101.6979-rollback die het herstelt, en Intels redenering voor de lagere standaard
• Level1Techs — B60 SR-IOV-ondersteuning in de Arc Pro-drivers — veld-lspci-rapporten voor de B60, de igsc-firmware-update die de capability blootlegde, en waar de 24-dan-7-cijfers vandaan komen
• Level1Techs — B50, B60 of B70 voor SR-IOV — de gerapporteerde VF-aantallen per kaart en per firmware, bron voor de B70-rijen
• ASRock — Intel Arc Pro B65 Creator 32GB — de specificaties van de B65: 32 GB GDDR6, 20 compute units, 160 XMX-engines, 256-bit, PCIe 5.0
• MAXSUN — Arc Pro B60 Dual 48G Turbo — de eigen uitspraak van de vendor dat de kaart “uses PCIe 5.0 x8 + x8 interfaces and runs efficiently on consumer platforms that support PCIe x16 lane bifurcation”
• vLLM — Fast and affordable LLM serving on Intel Arc Pro B-Series — het AI-verhaal op deze kaarten, en het feit dat het een Docker-op-bare-metal-verhaal is over vier en acht hele B60’s, zonder vermelding van SR-IOV of virtual functions
• Linux-kernel — Intel Xe-driver — de driver in gebruik op de kaart, per lspci -v
• tmpfiles.d(5) — het w-regeltype, en zijn “if the file exists”-voorwaarde die de volgorde hierboven dicteert
• NVIDIA Virtual GPU Software Packaging, Pricing and Licensing Guide — het gelicentieerde alternatief dat dit ontwerp vermijdt: vApps, vPC en RTX vWS allemaal per gelijktijdige gebruiker verkocht, als jaarabonnement of als eeuwigdurende licentie gebundeld met vijf jaar support en onderhoud
• Proxmox VE — PCI(e) Passthrough — host-side passthrough-vereisten