Wer aus der VMware-Welt kommt, findet in Proxmox die Rechenleistung schnell wieder: VM anlegen, CPU, RAM, Platte, fertig. Beim Netzwerk ist es anders. Nicht schwerer — aber die Begriffe, mit denen man denkt, passen nicht mehr. Und solange man sie weiterbenutzt, sucht man Dinge, die es nicht gibt.
Dieser Beitrag ist der Versuch, die Übersetzung einmal sauber hinzuschreiben.
Der Denkfehler, den man mitbringt
In VMware ist der Mittelpunkt die Port Group. Sie trägt das VLAN, sie trägt die Teaming-Richtlinie, sie ist das Objekt, das man der VM zuweist. Beim verteilten Switch liegt sie zentral im vCenter und gilt für alle Hosts.
In Proxmox gibt es dieses Objekt nicht. Der Mittelpunkt ist die Bridge — ein Stück Linux, das wie ein dummer Switch arbeitet. Sie trägt kein VLAN und keine Richtlinie. Das VLAN wandert dorthin, wo es in Linux hingehört: an die Netzwerkkarte der VM.
Das ist der ganze Unterschied, und er erklärt fast alles andere.
| VMware | Proxmox | Anmerkung |
|---|---|---|
| vSwitch (Standard) | Linux Bridge vmbr0 | pro Knoten, in /etc/network/interfaces |
| Distributed Switch | SDN-Zone mit VNets | zentral im Cluster, optional |
| Port Group mit VLAN-ID | VLAN-Tag an der VM-Karte | bei VLAN-aware Bridge |
| NIC Teaming | Bond (bond0) | LACP oder active-backup |
| VMkernel-Port | IP-Adresse am Knoten oder an der Bridge | kein eigenes Objekt |
| Uplink | physische Karte in der Bridge | |
| Network I/O Control | — | gibt es nicht |
| Health Check des dvSwitch | — | gibt es nicht |
Wie das in der Praxis aussieht
In meinem Labor hatte ich lange den einfachen Fall: vmbr0 mit der
Onboard-Karte, alle VMs untagged im Server-VLAN. Das reicht, bis man ein
zweites Netz braucht.
Anfang Oktober habe ich dann umgestellt — ich brauchte eine DMZ und wollte sie nicht über eine zweite Karte lösen. Dafür sind zwei Dinge nötig, und zwar beide:
Die Bridge muss VLAN-aware sein. Ohne diese Einstellung wirft sie getaggte
Pakete weg, und die VM sieht einfach nichts.
Dazu kommt die andere Seite: der Switchport muss ein Trunk sein. Bei mir sind die Ports auf dem Cisco jetzt Trunks, natives VLAN 99 für den Management-Verkehr, VLAN 100 für die DMZ. Danach ist das Zuweisen eines Netzes an eine VM genau ein Feld:
Eine Zahl statt einer Port Group. Der Unterschied ist nicht groß, aber man
sucht erst mal danach.
Der Umbau selbst war erfreulich unspektakulär: Haken setzen, Switchports
umstellen, kurzer Ausfall, weiter. Was mir dabei auffiel — man gewinnt dabei
etwas, das VMware nicht so leicht hergibt: die Konfiguration ist eine
Textdatei. /etc/network/interfaces lässt sich lesen, versionieren und mit
einem Blick vergleichen. Wer schon einmal zwei dvSwitch-Konfigurationen in
zwei vCentern verglichen hat, weiß, was ich meine.
Wo Proxmox weniger bietet
Das gehört dazu, sonst wird es Werbung:
- Kein Network I/O Control. Es gibt keine Bandbreitengarantie je Port Group. Man kann je VM eine Rate setzen, aber keine Shares verteilen.
- Kein Health Check. Der verteilte Switch in VMware kann prüfen, ob auf
allen Uplinks dieselben VLANs ankommen und die MTU stimmt. Das ist eine der
nützlichsten Funktionen überhaupt, und sie fehlt. Falsch gesetzte VLANs auf
einem von drei Switchports findet man in Proxmox selbst — mit
tcpdumpund Geduld. - Kein zentrales Switch-Objekt, solange man kein SDN benutzt. Jede Bridge
ist Sache ihres Knotens. Das heißt auch: der Name muss auf allen Knoten
gleich sein. Eine VM, deren Konfiguration
bridge=vmbr0sagt, lässt sich nicht auf einen Knoten migrieren, der seine Bridgevmbr1nennt. Das ist das Gegenstück zu „Port Group existiert auf dem Zielhost nicht" — und es ist der Fehler, der beim ersten Mal in der Migration auffällt und nicht vorher. - Firewall je VM, nicht als verteiltes Regelwerk. Proxmox hat eine brauchbare Firewall auf Knoten- und VM-Ebene. Ein Pendant zu NSX ist es nicht.
Wo es mehr bietet
- Es ist Linux. Bond, VLAN, Bridge, Policy Routing,
ip,tcpdump,ethtool— alles, was man auf einem Server kann, kann man hier. Fehlersuche findet mit denselben Werkzeugen statt wie überall sonst. - SDN ist inzwischen erwachsen. Ab Proxmox VE 9.0 gibt es SDN-Fabrics mit OpenFabric und OSPF, 9.1 brachte Routenverteilung für OSPF und mehrere EVPN-Controller samt Anzeige der gelernten MAC- und IP-Adressen in der Oberfläche, und 9.2 hat eine WireGuard-Fabric, BGP-Route-Maps und einen IPv6-Underlay für EVPN dazugelegt. Damit bekommt man ein zentral verwaltetes, clusterweites Netzobjekt — also das, was man vom verteilten Switch gewohnt ist, auf einer anderen Grundlage.
- Kein zusätzliches Lizenzthema. Das klingt nebensächlich, ist es aber nicht: ein verteilter Switch hängt in VMware an der Edition.
SDN ist der Weg zum clusterweiten Netzobjekt. Für ein Drei-Knoten-Labor mit
zwei VLANs braucht man es nicht — für mehr schon.
Fazit
Das Netzwerk ist die Stelle, an der sich der Wechsel am deutlichsten anfühlt, und zwar nicht wegen fehlender Funktionen, sondern wegen verschobener Zuständigkeiten. Die Port Group verteilt sich auf zwei Orte: das VLAN an die VM, die Uplinks an die Bridge. Wer das einmal verinnerlicht hat, findet den Rest schnell.
Für kleine und mittlere Aufbauten reichen VLAN-aware Bridges und Bonds völlig aus, und sie haben den Vorzug, dass man sie komplett lesen kann. Sobald mehrere Standorte, Mandanten oder Overlays ins Spiel kommen, lohnt der Blick auf SDN — das ist dann aber ein eigener Beitrag, und erst nach Ceph.
Wie immer: Fragen, Anregungen und Widerspruch gerne in die Kommentare oder per Mail.