SR-IOV bei 100GbE-Netzwerkkarten: Anleitung zur Aktivierung

Die Netzwerkkarte liefert theoretisch Durchsatz, doch jede VM schickt ihre Pakete zunächst durch den virtuellen Switch, den Host-Kernel und die CPU-Pipeline. Das funktioniert – bis die Last ernst wird. Dann steigen CPU-Overhead, Latenz und der Aufwand für die Fehlersuche gleichzeitig. Ein ausgesprochen schlechtes TCO-Modell.

Die SR-IOV-Aktivierung einer 100GbE-Netzwerkkarte umgeht diesen Umweg: Eine physische Karte stellt mehrere virtuelle PCIe-Funktionen bereit, die direkt an virtuelle Maschinen durchgereicht werden können. Das entlastet den Host erheblich. Aber SR-IOV ist keine Checkbox im Hypervisor. Wer nur dort sucht, produziert meist ein System, das entweder keine Virtual Functions erzeugt oder nach dem nächsten Neustart so tut, als hätte es die Konfiguration nie gegeben.

Die Kette muss vollständig stimmen: Mainboard-BIOS, IOMMU, Adapter-Firmware, Kernel-Parameter, Treiber und persistente Bereitstellung. Fällt ein Glied aus, ist die 100GbE-Karte bloß ein sehr teures Stück Blech mit blinkenden LEDs.

SR-IOV spart nicht automatisch Geld. Es spart CPU-Zeit und Latenz – aber nur, wenn Firmware, PCIe-Topologie und Betriebsmodell sauber zusammenpassen.

Was SR-IOV bei einer 100GbE-Karte tatsächlich verändert

Single Root I/O Virtualization teilt eine physische Netzwerkkarte in zwei Funktionsarten auf:

• Physical Function (PF): Die vollwertige Funktion der Netzwerkkarte. Sie wird vom Host verwaltet, trägt die Treiberlogik und erzeugt die virtuellen Instanzen.
• Virtual Functions (VFs): Reduzierte PCIe-Funktionen für einzelne VMs. Jede VF kann einer virtuellen Maschine direkt zugewiesen werden und erhält dabei einen sehr direkten Pfad zur Hardware.

Der wirtschaftliche Effekt liegt nicht in einer magischen Beschleunigung des Ethernet-Protokolls. Der Link bleibt ein 100GbE-Link. Der Unterschied entsteht im Datenpfad: Die VM muss bei passenden Workloads nicht mehr jede Paketbewegung über die vollständige Software-Schicht des Hosts abwickeln.

Das ist besonders sinnvoll bei:

• Storage-Verkehr mit hoher Paket- und I/O-Rate, etwa zwischen Compute-Knoten und NVMe-oF- oder Ceph-Umgebungen;
• datenintensiven Anwendungen, deren Netzwerkverkehr dauerhaft und nicht nur in kurzen Spitzen anliegt;
• Virtualisierungs-Hosts mit vielen VMs, bei denen die CPU bereits durch vSwitching, Verschlüsselung oder Storage-Stacks belastet wird;
• Latenz-sensiblen Workloads, bei denen zusätzliche Host-Scheduling-Schritte messbar stören.

Weniger überzeugend ist SR-IOV, wenn die Maschine nur wenige VMs mit moderatem Netzwerkverkehr trägt. Dann erkauft man sich einen komplexeren Lifecycle für einen Effekt, den der Einkauf später kaum in messbare Betriebsersparnis übersetzen kann.

Die verbreitete Annahme „100GbE gekauft, also Performanceproblem gelöst“ ist Herstellerlogik. In der Realität entscheidet die PCIe-Anbindung, die CPU-Plattform und der Netzwerkpfad darüber, ob die Karte ihre Kapazität überhaupt in nutzbaren Durchsatz verwandelt.

BIOS und IOMMU: Die Voraussetzung liegt vor dem Betriebssystem

Die SR-IOV-BIOS-Einstellungen sind der erste Prüfpunkt – und der häufigste Grund, warum eine ansonsten korrekte Linux-Konfiguration scheitert. Die Netzwerkkarte kann VFs nur zuverlässig bereitstellen, wenn die Plattform DMA-Zugriffe isolieren und zuordnen kann. Dafür benötigt sie die IOMMU-Funktion der CPU- und Chipsatzplattform.

Bei Intel-Systemen heißt diese Funktion üblicherweise Intel VT-d, bei AMD-Systemen AMD-Vi oder schlicht IOMMU. Zusätzlich braucht das BIOS eine globale Einstellung wie SR-IOV Support oder Single Root I/O Virtualization.

Die Menünamen unterscheiden sich zwischen Serverplattformen, aber die Logik bleibt gleich. Vor der Linux-Konfiguration sollten im UEFI mindestens diese Punkte aktiv sein:

1. Intel VT-d oder AMD-Vi aktivieren.

Das ist nicht dasselbe wie die CPU-Virtualisierung Intel VT-x oder AMD-V. Letztere ist für den Hypervisor relevant; für PCIe-Passthrough und SR-IOV braucht es die I/O-Virtualisierung.

2. SR-IOV-Unterstützung global einschalten.

Viele Server-BIOS-Versionen führen diese Option im PCIe-, Chipset- oder Advanced-Menü. Ist sie deaktiviert, kann ein Betriebssystem die Karte zwar erkennen, aber keine nutzbaren VFs anlegen.

3. PCIe-Slot und Lane-Anbindung prüfen.

Eine 100GbE-Karte gehört nicht in irgendeinen freien Slot. Die verfügbare PCIe-Generation, die Lane-Breite und die NUMA-Zuordnung bestimmen, ob die Karte unter Last ausgebremst wird. Eine Karte an einem überlasteten Chipsatzpfad zu betreiben und anschließend am Treiber zu feilen, ist klassische Fehlallokation von Administratorzeit.

4. Aktuelle BIOS- und BMC-Firmware einplanen.

Gerade bei Serverplattformen sind IOMMU-Gruppierungen, PCIe-Resource-Mapping und die Behandlung großer BAR-Bereiche Firmware-Themen. Ein altes BIOS kann aus einem lösbaren Konfigurationsproblem ein mehrtägiges Ticketsystem machen.

Nach dem Neustart sollte das System bestätigen, dass die IOMMU tatsächlich aktiv ist. Entscheidend ist nicht, dass eine BIOS-Option gesetzt wurde, sondern dass der Kernel die IOMMU initialisiert. Die BIOS-Maske ist nur der Antrag; die Kernel-Meldung ist die Genehmigung.

Kernel-Parameter: Ohne IOMMU bleibt die Virtualisierung halb fertig

Unter Linux muss die IOMMU beim Booten explizit aktiviert werden. Für Intel-Systeme lautet der maßgebliche Parameter intel_iommu=on, für AMD-Systeme amd_iommu=on. In beiden Fällen gehört üblicherweise iommu=pt dazu.

Der Zusatz steht für Pass-Through-Modus bei Geräten, die nicht isoliert an VMs durchgereicht werden. Er verhindert unnötige DMA-Übersetzungen im Normalbetrieb und reduziert damit vermeidbaren Overhead. Gerade bei einem Host, der sowohl klassische Netzwerkschnittstellen als auch SR-IOV-Workloads trägt, ist das ein sinnvoller Standard.

Je nach Distribution wird die Kernel-Kommandozeile in der Bootloader-Konfiguration ergänzt und anschließend der Bootloader aktualisiert. Nach dem Neustart sollte die Prüfung nicht bei der Kommandozeile enden. Relevant sind die Kernelmeldungen: Sie müssen zeigen, dass Intel-IOMMU beziehungsweise AMD-IOMMU initialisiert wurde.

Ein zweiter Punkt wird oft übersehen: SR-IOV braucht PCIe-Ressourcen. VFs verbrauchen unter anderem Interrupt- und Adressierungsressourcen. Deshalb ist die Frage „Wie viele VFs kann diese Karte?“ keine Frage, die sich pauschal mit einer Produktbroschüre beantworten lässt. Adaptermodell, Firmwarestand, Treiber, Host-Plattform, BIOS-Ressourcen und die konkrete PCIe-Topologie entscheiden gemeinsam.

Die saubere Beschaffungslogik lautet daher nicht: maximale VF-Zahl kaufen. Sie lautet: benötigte VM-Dichte definieren, Reserve für Wachstum berechnen und die gewünschte Anzahl auf der eigenen Plattform validieren. Wer pauschal die höchstmögliche Zahl einträgt, testet keine Skalierung – er testet den Moment, in dem MSI-X-Vektoren, BAR-Ressourcen oder Treibergrenzen unangenehm sichtbar werden.

Die nutzbare Zahl der VFs ist eine Eigenschaft des Gesamtsystems, nicht nur des Datenblatts der Netzwerkkarte.

Firmware-Ebene: Mellanox ConnectX und Intel E810 richtig vorbereiten

Bei 100GbE-Adaptern reicht es nicht, SR-IOV im Host zu aktivieren. Die Adapter-Firmware muss die Virtualisierungsfunktion ebenfalls freigeben. Genau hier unterscheiden sich die üblichen Plattformen deutlich.

Mellanox- und NVIDIA-ConnectX-Karten

Bei Mellanox- beziehungsweise NVIDIA-ConnectX-Adaptern wird SR-IOV über die Firmware-Konfiguration aktiviert. Dafür kommt typischerweise mstconfig aus dem Paket rund um mstflint zum Einsatz.

Die relevanten Firmware-Parameter sind:

• SRIOV_EN=1 aktiviert die SR-IOV-Fähigkeit des Adapters.
• NUM_OF_VFS=<Anzahl> legt fest, wie viele virtuelle Funktionen die Firmware bereitstellen soll.

Die Änderung wird auf der Karte gespeichert und erfordert in der Regel einen Neustart des Hosts, damit die neue Konfiguration vollständig übernommen wird. Ein reiner Treiber-Reload ist keine solide Betriebsstrategie, wenn die Firmwareebene angepasst wurde.

Die VF-Anzahl sollte konservativ beginnen. Wer beispielsweise zwölf produktive VMs mit direktem Netzwerkzugang plant, muss nicht reflexhaft die maximal mögliche Zahl provisionieren. Eine überschaubare Reserve für Wartung, Migration und Wachstum ist sinnvoll; eine VF-Farm ohne konkreten Verbraucher produziert hingegen nur zusätzliche Komplexität.

Intel E810: SR-IOV im Adapter-UEFI setzen

Bei Intel-E810-100GbE-Karten erfolgt die Grundkonfiguration über das UEFI-Menü des Netzwerkadapters. Dort wird unter den Hardware-Einstellungen typischerweise der Pfad Device Level Configuration → Virtualization Mode auf SRIOV gesetzt.

Das ist ein wichtiger Unterschied zur Mellanox-ConnectX-SR-IOV-Einrichtung: Bei Intel steht die entscheidende Konfigurationsfläche häufig direkt im Adapter-UEFI zur Verfügung, während ConnectX-Karten stärker über Firmware-Werkzeuge administriert werden.

In beiden Fällen gilt dieselbe Reihenfolge:

1. Plattform-IOMMU und SR-IOV im Server-BIOS aktivieren.

2. Adapter-Firmware für SR-IOV konfigurieren.

3. Host neu starten und die IOMMU-Initialisierung prüfen.

4. Linux-Treiber laden und erst dann VFs erzeugen.

5. VFs einer VM erst nach erfolgreicher Host-Prüfung zuordnen.

Diese Reihenfolge wirkt banal, spart aber Zeit. Die typische Fehlersuche beginnt nämlich am Ende: Hypervisor, VM-XML, virtuelle Switches. Häufig liegt der Fehler zwei Ebenen tiefer, in einer nicht gesetzten Firmware-Option oder einer BIOS-Vorgabe, die nach einem Firmware-Update wieder auf Standard fiel.

Virtual Functions unter Linux erstellen und kontrollieren

Sind BIOS, IOMMU und Adapter-Firmware vorbereitet, erzeugt Linux die eigentlichen VFs über das Sysfs-Dateisystem. Dafür wird die gewünschte Anzahl in die Datei sriov_numvfs der physischen Schnittstelle geschrieben.

Der relevante Pfad folgt diesem Muster:

/sys/class/net/<Schnittstelle>/device/sriov_numvfs

Für die produktive Umsetzung bedeutet das: Zuerst die korrekte Physical Function identifizieren. Bei Servern mit mehreren Dual-Port-Karten, Onboard-NICs und separaten Storage-Netzen ist der Interface-Name allein keine ausreichende Sicherheit. PCIe-Adresse, MAC-Adresse, Port-Zuordnung und die Ausgabe des Treibers müssen zusammenpassen.

Vor dem Erzeugen der VFs lohnt sich ein kurzer Abgleich:

• Ist die PF wirklich der erwartete Port der 100GbE-Karte?
• Ist der passende Treiber geladen?
• Meldet das System eine aktive IOMMU?
• Hat die Firmware SR-IOV freigegeben?
• Ist die gewünschte VF-Zahl realistisch für Adapter und Host?

Danach wird die VF-Anzahl gesetzt. Die VFs tauchen als virtuelle PCIe-Funktionen auf und lassen sich dem Hypervisor zuordnen. Wichtig: Das Erzeugen der VFs ist noch keine Zuweisung an eine VM. Es schafft lediglich die durchreichbaren Funktionen.

Ein häufiger Betriebsfehler besteht darin, VFs auf dem Host wie normale Netzwerkschnittstellen zu behandeln und gleichzeitig an VMs weiterzugeben. Das ist kein robustes Ownership-Modell. Eine VF, die exklusiv einer VM gehört, sollte nicht parallel durch Host-Dienste, Bridge-Konfigurationen oder automatische Netzwerkverwaltung umkonfiguriert werden.

Je nach Treiber und Hypervisor lassen sich für VFs Eigenschaften wie MAC-Adresse, VLAN-Zuordnung oder Vertrauensstatus auf der PF verwalten. Das ist keine Nebenfrage: Ohne saubere Port- und VLAN-Politik kann SR-IOV die Netzwerktrennung unterlaufen, die der virtuelle Switch vorher implizit durchgesetzt hat.

Persistenz: Warum die VF-Konfiguration nach dem Neustart verschwindet

VFs, die über sriov_numvfs erzeugt werden, bleiben standardmäßig nicht über einen Neustart hinweg erhalten. Das ist kein Defekt, sondern das erwartete Verhalten. Wer die SR-IOV-Aktivierung einer 100GbE-Netzwerkkarte manuell nach jedem Reboot wiederholt, hat kein Setup gebaut, sondern eine Erinnerungshilfe für den Bereitschaftsdienst.

Die VF-Erzeugung muss deshalb automatisiert werden. Dafür kommen drei Ansätze infrage:

• Systemd-Dienst: geeignet für klar definierte Hosts mit stabiler Interface-Zuordnung. Der Dienst wird nach Verfügbarkeit der Netzwerkschnittstelle ausgeführt und setzt die gewünschte VF-Zahl.
• Udev-Regel: sinnvoll, wenn die Erstellung direkt an das Erkennen der konkreten PCIe- oder Netzwerkschnittstelle gekoppelt werden soll.
• Startskript der Virtualisierungsplattform: praktisch, wenn die Reihenfolge eng an den VM-Start und die jeweilige Host-Konfiguration gebunden ist.

Für standardisierte Cluster ist ein Systemd-Dienst meist die berechenbarste Variante. Entscheidend ist die Startreihenfolge: Erst muss die Physical Function vorhanden und der Treiber geladen sein, dann werden die VFs erstellt, anschließend starten VMs, die auf diese Funktionen angewiesen sind.

Auch beim Lifecycle-Management darf man nicht sparen. Firmware-Updates der Netzwerkkarte, Kernel-Updates oder Änderungen an der Namensgebung von Interfaces können die Automatisierung brechen. Eine SR-IOV-Konfiguration gehört daher in die reguläre Infrastruktur-Dokumentation – inklusive Kartenmodell, Firmwarestand, PCIe-Slot, PF-Zuordnung, VF-Anzahl und VM-Zuordnung.

Das klingt nach Verwaltungsaufwand. Ist es auch. Aber dieser Aufwand ist deutlich günstiger als ungeplante Netzwerkausfälle nach einem Wartungsfenster, bei dem die VFs zwar nicht mehr existieren, die VMs aber dennoch starten sollen.

VFs per VFIO-PCI an KVM- und Proxmox-VMs durchreichen

Damit eine VF an eine virtuelle Maschine durchgereicht werden kann, benötigt der Host die VFIO-Komponenten. Dafür müssen die Kernel-Module vfio, vfio_iommu_type1 und vfio_pci verfügbar und geladen sein.

VFIO stellt die kontrollierte Übergabe von PCIe-Geräten an virtuelle Maschinen bereit. Die VM erhält damit einen sehr direkten Zugriff auf ihre VF, während die IOMMU die DMA-Zugriffe isoliert. Genau diese Kombination macht SR-IOV für 100GbE-Netzwerkkarten in KVM- und Proxmox-Umgebungen attraktiv.

Bei der Zuweisung gelten drei Regeln, die in der Praxis mehr zählen als eine beeindruckende Durchsatzgrafik:

1. Eine VF gehört eindeutig einer VM.

Keine parallele Nutzung durch den Host, keine spontane Umwidmung während der Laufzeit, keine unklare Zuständigkeit zwischen Netzwerk- und Virtualisierungsteam.

2. Die VM braucht einen passenden Gasttreiber.

Die VF ist kein abstraktes Netzwerkobjekt. Das Gastbetriebssystem muss den Adaptertyp und dessen Treiber unterstützen. Ohne Treiber sieht die VM im besten Fall ein unbekanntes Gerät, im schlechteren Fall ein Netzwerkproblem ohne offensichtliche Ursache.

3. Migration ist anders zu bewerten als bei virtuellen NICs.

Eine direkt zugewiesene VF bindet die VM stärker an den Host und dessen Hardware. Live-Migration, Failover und Wiederanlauf auf einem anderen Knoten müssen deshalb vor dem Produktivbetrieb im konkreten Clusterdesign geprüft werden.

Gerade der letzte Punkt wird in Wirtschaftlichkeitsrechnungen gern ausgeblendet. SR-IOV reduziert CPU-Last und Latenz, kann aber die Flexibilität klassischer virtueller Netzwerke einschränken. Für eine Datenbank-VM mit konstant hoher Ost-West-Last kann das ein sauberer Tausch sein. Für eine heterogene Flotte mit häufigen Live-Migrationen möglicherweise nicht.

Die richtige Entscheidung ist also nicht „alles SR-IOV“ oder „nie SR-IOV“. Sinnvoll ist ein zweigleisiges Modell: Hochlast-VMs erhalten dedizierte VFs, allgemeine Infrastruktur- und Management-Workloads bleiben auf virtuellen NICs. Das verbessert die Ressourcenauslastung, ohne den gesamten Cluster auf ein starres Hardware-Bindungsmodell festzulegen.

Die wirtschaftlich sinnvolle Reihenfolge für den Einkauf und Betrieb

SR-IOV ist dann rentabel, wenn es ein messbares Engpassproblem löst: CPU-Overhead am Host, unzureichende Paketverarbeitung, störende Latenz oder eine zu hohe Dichte netzwerkintensiver VMs. Es ist nicht rentabel, wenn es lediglich als Feature auf einer 100GbE-Karte mitgekauft und aus Prinzip aktiviert wird.

Für die Beschaffung und Einführung empfehle ich eine nüchterne Reihenfolge:

1. Workload messen: CPU-Last des Hosts, Netzwerkdurchsatz, Paketlast und Latenz vor der Änderung erfassen.

2. Plattform validieren: BIOS, IOMMU, PCIe-Slots und Firmwarestände für das konkrete Servermodell prüfen.

3. Mit wenigen VFs starten: Einen repräsentativen Hochlast-Workload auswählen, nicht gleich den gesamten Cluster umbauen.

4. Betrieb automatisieren: VF-Erzeugung, Treiberladung und Startreihenfolge persistent abbilden.

5. Migration und Recovery testen: Nicht nur den Normalbetrieb, sondern Host-Neustart, Kartenwechsel und VM-Wiederanlauf prüfen.

6. Erst danach skalieren: Die VF-Anzahl nach realem Bedarf erhöhen, nicht nach maximaler Zahl im Datenblatt.

Der eigentliche Gewinn von SR-IOV liegt nicht darin, dass eine 100GbE-Karte plötzlich „schnell“ wird. Sie war vorher schon schnell. Der Gewinn entsteht, wenn der Host aufhört, unnötig im Datenpfad zu stehen. Wer BIOS, Firmware und Linux-Konfiguration als zusammenhängende Lieferkette behandelt, bekommt genau das: mehr nutzbare Netzwerkleistung pro CPU-Kern – und damit eine Infrastrukturentscheidung, die sich auch in der TCO-Rechnung verteidigen lässt.