SR-IOV: Dela ett nätverkskort mellan virtuella maskiner med nästan full prestanda

Redaktionens viktigaste punkter

  • SR-IOV låter ett fysiskt nätverkskort (NIC) dela upp sig i många virtuella funktioner (VFs) som varje virtuell maskin kan använda direkt, utan att trafiken passerar hypervisorn.
  • Varje VF får nästan samma prestanda som ett fysiskt kort: betydligt högre genomströmning och lägre latens än virtio, och nästan i nivå med full passthrough.
  • Kraven är fyra: ett SR-IOV-kompatibelt NIC som Intel X710 eller Mellanox ConnectX, ett moderkort med SR-IOV-stöd i BIOS, aktiverad IOMMU (Intel VT-d eller AMD-Vi) samt en drivrutin med stöd för tekniken.
  • På Proxmox och Linux aktiveras SR-IOV med en drivrutinsparameter eller via sysfs, varefter varje VF kan tilldelas en virtuell maskin direkt.
  • För hemlabbet är SR-IOV det smartaste sättet att dela ett snabbt 10- eller 25-gigabit-kort mellan flera virtuella maskiner utan att förlora prestanda.

SR-IOV: Dela ett nätverkskort mellan virtuella maskiner med nästan full prestanda

Den som kör flera virtuella maskiner på en hemmasever står förr eller senare inför ett nätverksdilemma. Ett fysiskt nätverkskort (NIC) per virtuell maskin blir snabbt dyrt, medan delning via hypervisorn kostar både CPU-kraft och prestanda. Lösningen heter SR-IOV — Single Root I/O Virtualization — en teknik som låter ett enda fysiskt kort presentera sig som många separata enheter, var och en med en direkt kanal till hårdvaran.

Vad är SR-IOV?

SR-IOV är en PCI Express-standard från PCI-SIG som gör att en fysisk enhet kan dela upp sig i flera virtuella instanser. I stället för att hypervisorn tar emot all nätverkstrafik och skickar den vidare i mjukvara får varje virtuell maskin en egen direktväg till nätverkskortets hårdvara. Hypervisorn konfigurerar bara uppdelningen — själva datatrafiken går sedan direkt mellan den virtuella maskinen och kortet.

Den virtuella maskinen ser en riktig PCIe-enhet och laddar en vanlig drivrutin, utan att märka någon virtualisering. Resultatet blir lägre latens, högre genomströmning och betydligt mindre belastning på värdens processor jämfört med klassiska paravirtualiserade nätverkskort.

Så fungerar SR-IOV: physical function och virtual functions

Physical function: kortets fulla gränssnitt

Varje SR-IOV-kompatibelt kort exponerar minst en physical function (PF) — kortets fullständiga PCIe-funktion med all konfiguration och administration. PF-drivrutinen körs på värdsystemet och är den som skapar, konfigurerar och övervakar de virtuella funktionerna. Via PF:n ställer administratören in antalet VFs, VLAN per VF och bandbreddsgränser.

Virtual functions: lätta delinstanser för varje VM

En virtual function (VF) är en lättviktig instans av kortet som delar den fysiska hårdvaran med PF:n och övriga VFs. Varje VF har egna köer för sändning och mottagning samt egna avbrott. Gästsystemet ser den som ett vanligt nätverkskort — till exempel med drivrutinen ixgbevf på Intel-kort eller mlx5 på Mellanox-kort. Kortets interna switch skickar paketen direkt till rätt VF baserat på MAC-adress eller VLAN, helt i hårdvara.

Maxantalet VFs varierar mellan modeller: Intel X710 klarar upp till 128, Intels nyare E810 upp till 256, och NVIDIAs Mellanox ConnectX-familj upp till 127 VFs per port. Ett hemlabb behöver sällan mer än en handfull, men taket visar teknikens skalbarhet.

Krav för SR-IOV: hårdvara, BIOS och IOMMU

SR-IOV kräver att hela kedjan stödjer tekniken — det räcker inte med ett kompatibelt nätverkskort. De fyra kraven är:

  • Ett SR-IOV-kompatibelt NIC. Vanliga val för hemlabbet är Intel X520, Intel X710 och Mellanox ConnectX-4 eller ConnectX-5. Billiga konsumentkort, till exempel från Realtek, stödjer inte SR-IOV.
  • Moderkort med SR-IOV-stöd i BIOS. Utan rätt BIOS-stöd syns inga VFs alls. Aktivera även “Above 4G decoding”, eftersom många VFs kräver stora PCIe-adressutrymmen.
  • Aktiverad IOMMU. IOMMU (Intel VT-d eller AMD-Vi) isolerar varje VF:s minnesåtkomst så att en virtuell maskin inte kan läsa en annans minne. Den slås på både i BIOS och via kärnparametern intel_iommu=on eller amd_iommu=on.
  • Drivrutin med SR-IOV-stöd. På Linux behövs PF-drivrutinen för ditt kort (till exempel i40e för X710 eller mlx5_core för ConnectX). Moderna kärnor har det mesta inbyggt, men kontrollera att firmwaren är uppdaterad.

Konfigurera SR-IOV på Proxmox och Linux: grunderna

När hårdvarukraven är uppfyllda är konfigurationen enkel. Aktivera IOMMU i BIOS och via kärnparametrar, slå på SR-IOV och “Above 4G decoding” i BIOS, och skapa sedan de virtuella funktionerna på värden via sysfs:

echo 8 > /sys/class/net/enp1s0f0/device/sriov_numvfs
ip link show enp1s0f0

Detta skapar åtta VFs på gränssnittet enp1s0f0. För att inställningen ska överleva en omstart läggs den i en udev-regel eller en systemd-tjänst. På Proxmox tilldelas en VF sedan till en virtuell maskin från webbgränssnittet under Hardware, eller från kommandoraden med qm set där VF:n anges som PCI-enhet. Gästen hittar ett vanligt nätverkskort och installerar sin vanliga drivrutin — från gästens perspektiv finns ingen virtualisering alls.

Prestanda: SR-IOV jämfört med virtio och full passthrough

Det finns tre vanliga sätt att ge en virtuell maskin nätverksåtkomst. Virtio är det paravirtualiserade standardvalet där hypervisorn hanterar trafiken i mjukvara. Full passthrough ger en hel fysisk enhet till en enda virtuell maskin. SR-IOV hamnar mittemellan: nästan passthrough-prestanda, men med delning mellan många virtuella maskiner.

EgenskapSR-IOVVirtioFull passthrough
GenomströmningNära fysisk hårdvaraBra, men CPU-begränsadFull fysisk prestanda
LatensMycket lågHögre, varierar med belastningLägst möjliga
CPU-belastning på värdenMycket lågHög vid mycket trafikFörsumbar
Delning av ett NICJa, upp till hundratals VFsJa, obegränsatNej, ett kort per VM
Live-migrering av VMBegränsad, kräver stödJa, fungerar smidigtNej
KomplexitetMedelLågLåg till medel

Den största praktiska skillnaden märks vid hög trafik: med virtio blir hypervisorns CPU flaskhalsen långt innan nätverket är mättat, medan SR-IOV låter hårdvaran göra jobbet. Priset är att live-migrering mellan värdar blir krångligare, eftersom VF:n är bunden till ett specifikt fysiskt kort — sällan ett problem i ett hemlabb med en eller två värdar.

Praktiska användningsfall i hemlabbet

SR-IOV glänser när ett snabbt nätverkskort ska delas mellan flera krävande virtuella maskiner. Ett klassiskt exempel är ett 10- eller 25-gigabit-kort som delas mellan en brandväggs-VM med OPNsense, en NAS-VM och ett par testmaskiner — var och en får sin egen VF med hårdvaruaccelererad trafik. Brandväggen får den låga latens den behöver för filtrering i linjefart, samtidigt som NAS:en kan mätta sin länk utan att störa de andra.

Andra användningsfall är virtualiserade routrar och lastbalanserare där varje millisekund räknas, samt labbmiljöer där flera virtuella maskiner ska generera stora trafikmängder samtidigt. Även vissa GPU:er har börjat få SR-IOV-stöd, vilket öppnar för att dela en fysisk GPU mellan flera virtuella maskiner på samma sätt.

Slutsats: praktiska köpråd

Ska du bygga ett hemlabb där nätverksprestanda spelar roll är SR-IOV en av de mest prisvärda uppgraderingarna du kan göra. Satsa på ett begagnat enterprise-kort med dokumenterat SR-IOV-stöd — Intel X710 eller Mellanox ConnectX-4 och ConnectX-5 är säkra, vältestade val som ofta säljs billigt på andrahandsmarknaden. Kontrollera före köpet att moderkortets BIOS stödjer SR-IOV och att processorn har IOMMU, och slå på “Above 4G decoding” i BIOS.

Börja med ett fåtal VFs — fyra till åtta räcker i de flesta hemlabb, trots att korten klarar hundratals. Ge din mest trafikkänsliga virtuella maskin, till exempel brandväggen eller NAS:en, en egen VF först och jämför mot virtio innan du migrerar resten. Och om SR-IOV känns för avancerat i början: virtio räcker långt för lättare laster, och du kan alltid aktivera SR-IOV senare utan att byta hårdvara — förutsatt att du köpt rätt kort från start.

Leave a Comment