"Wo ist vMotion?" Die Frage, die die wahre Lernkurve beim Umstieg von VMware auf Proxmox offenlegt

Die Migrationsfrage, mit der alles beginnt

Wenn VMware-Administratoren anfangen, sich mit Proxmox zu beschäftigen, landet das Gespräch fast immer bei derselben Frage: Was ersetzt die vertrauten VMware-Funktionen, also vMotion, Distributed Switches, DRS und das Cluster-Networking?

In VMware-Umgebungen sind diese Werkzeuge mehr als Funktionen, sie prägen, wie Administratoren Infrastruktur entwerfen. Nimmt man sie weg, ändert sich das ganze mentale Modell.

Ein Engineer hat genau diesen Moment kürzlich festgehalten, während er den Übergang von ESXi und vCenter zu Proxmox plante. Seine Umgebung sollte drei oder vier Hosts umfassen, wobei ein Node spezialisierte Hardware mit PCIe-Passthrough enthielt. Weil diese VMs von physischen Geräten abhängen, kann ein Verschieben zwischen Hosts ernsthaft Probleme machen.

Seine Frage war einfach und aufschlussreich: Sollten diese Hosts trotzdem in einen Cluster, oder gehört die Infrastruktur anders entworfen? Daraus wurde eine überraschend detaillierte Diskussion darüber, wie anders Proxmox Virtualisierung angeht als VMware.

Live-Migration gibt es, die Philosophie ist eine andere

Eine der ersten Antworten klärte das Wichtigste: Ja, Proxmox unterstützt Live-Migration. Virtuelle Maschinen und Container können sich innerhalb eines Clusters zwischen Hosts bewegen, ohne herunterzufahren, ähnlich wie bei vMotion. Die Automatisierungsebene verhält sich allerdings anders.

In VMware-Umgebungen analysiert der Distributed Resource Scheduler ständig die Ressourcennutzung der Hosts und kann Workloads automatisch neu ausbalancieren. Proxmox geht es leichter an. Cluster Resource Scheduling, von Administratoren oft CRS genannt, kümmert sich vor allem um High-Availability-Ereignisse und nicht um laufende Optimierung. Typischerweise legen Administratoren Host-Prioritätsgruppen an und verteilen VMs gezielt über die Nodes. Der Cluster sorgt dann bei Ausfällen für Verfügbarkeit, statt Workloads fortlaufend nach CPU- oder Speicherauslastung zu verschieben.

Manche Engineers mögen diese Einfachheit, andere vermissen das automatisierte Load-Balancing von VMware. Schon dieser Unterschied prägt oft, wie Teams ihre Proxmox-Cluster entwerfen.

Distributed Switches werden zum Networking-Puzzle

Networking wurde schnell das zweite große Thema. VMware-Administratoren verwalten VLANs, Port-Gruppen und Netzwerkkonfiguration häufig zentral über vSphere Distributed Switches. Proxmox bildet diese Funktion nicht direkt nach, sondern baut Networking auf Linux-Primitiven auf, also auf Bridges, Bonding und optional Open vSwitch. Wer eine zentrale Switch-Oberfläche erwartet, findet das anfangs ungewohnt.

Mehrere Engineers verwiesen auf das Software-Defined-Networking-System von Proxmox als nächstliegendes Äquivalent. Die Idee dahinter: Administratoren erstellen eine SDN-Zone, hängen sie an eine Linux-Bridge, die alle Hosts gemeinsam nutzen, und definieren dann virtuelle Netzwerke, VNets genannt, die je ein VLAN-basiertes Netzwerk abbilden. Ist die SDN-Richtlinie angewendet, erscheinen diese Netzwerke auf jedem Host im Cluster.

In der Praxis verhalten sich VNets ähnlich wie VMware-Port-Gruppen. Wer eine VM anlegt, wählt beim Anhängen der virtuellen NIC einfach das passende Netzwerk aus.

Manche Engineers bevorzugen weiterhin Open vSwitch

Dass SDN der beste Ansatz ist, sahen nicht alle so. Ein Engineer argumentierte, dass Open vSwitch besser passt, wenn eine Organisation sehr viele VMs oder komplexe VLAN-Setups verwaltet. In diesem Modell konfiguriert man VLANs direkt auf der Switch-Ebene und nicht über die SDN-Abstraktion von Proxmox.

Seine Begründung war schlicht. Manche Umgebungen enthalten Tausende von VMs, und VLAN-Tags einzeln pro VM zu setzen wird mühsam. Ein klassischeres Switch-Modell kann den Aufwand im Betrieb senken.

Diese Sicht zeigt etwas Wichtiges über Proxmox-Networking: Mehrere Architekturen funktionieren, und ein einziges vorgeschriebenes Modell gibt es nicht.

Die Linux-Networking-Ebene bleibt sichtbar

Ein weiterer Teil der Diskussion zeigte, wie stark Linux-Networking-Konzepte die Proxmox-Infrastruktur prägen. Ein Engineer beschrieb seine Produktionsumgebung mit sechs physischen Schnittstellen: zwei gebondete 1-Gb-Ports für Management-Traffic, aus Redundanzgründen an getrennten Switches, zwei 25-Gb-Schnittstellen, die den Trunk-Traffic der virtuellen Maschinen mit mehreren VLANs transportieren, und noch ein Paar 25-Gb-Verbindungen für Shared Storage.

Seine Networking-Kette lief von der physischen Schnittstelle über den Linux-Bond und das Linux-VLAN zur Linux-Bridge. Ist das konfiguriert, wählen VM-Ersteller einfach die passende Bridge für das gewünschte Netzwerk.

Das System funktioniert gut, verlangt von Administratoren aber ein tieferes Verständnis der Linux-Networking-Grundlagen, als viele VMware-Umgebungen es fordern.

Hardware-Passthrough bringt eine weitere Einschränkung mit

Auch die ursprüngliche Sorge um PCIe-Passthrough bekam praktische Antworten. Virtuelle Maschinen mit VFIO-Geräte-Passthrough, etwa für GPUs oder spezialisierte Netzwerkkarten, lassen sich nicht ohne Herunterfahren zwischen Hosts migrieren. Diese Einschränkung gilt bei den meisten Hypervisoren.

Die vorgeschlagene Lösung war unkompliziert: Diese VMs einfach nicht an High-Availability-Migrationsregeln hängen. Der Cluster verwaltet die Hosts weiter normal, während die hardwareabhängigen VMs an ihre Nodes gepinnt bleiben. Startreihenfolge, verzögerte Boot-Sequenzen und Shutdown-Verhalten können Administratoren weiterhin auf Host-Ebene konfigurieren, ähnlich wie viele VMware-Umgebungen solche Workloads behandeln.

Die Storage-Architektur prägt weiterhin alles

Ein anderer Engineer wies darauf hin, dass die Storage-Architektur am Ende darüber entscheiden kann, ob Clustering überhaupt sinnvoll ist. Live-Migration funktioniert am besten, wenn mehrere Hosts auf dieselben VM-Disks zugreifen, was in VMware-Umgebungen meist SAN- oder NAS-Storage bedeutet.

Proxmox-Umgebungen ersetzen SAN-Appliances oft durch verteilte Storage-Systeme wie Ceph. Dort können dieselben Nodes, auf denen die virtuellen Maschinen laufen, auch Disks in einen gemeinsamen Storage-Pool einbringen. Der Cluster repliziert die Daten automatisch über die Nodes, sodass sich VMs zwischen Hosts bewegen können, ohne dass zentrale Storage-Hardware nötig ist.

Ceph bringt allerdings neue Design-Fragen mit: Netzwerkbandbreite, Disk-Balancing und Cluster-Gesundheit hängen eng zusammen. Teams, die SAN-basierte Umgebungen gewohnt sind, brauchen dafür ein anderes Mindset.

Die eigentliche Lektion aus der Diskussion

Was als einfache Frage zu Distributed Switches begann, berührte am Ende fast jeden Kernbereich der Virtualisierungsinfrastruktur, von Live-Migration und Cluster-Scheduling über Networking-Modelle und Storage-Architektur bis zum Hardware-Passthrough.

Und es kam noch etwas zum Vorschein. Viele Funktionen, auf die sich VMware-Administratoren verlassen, gibt es in Proxmox ebenfalls. Sie sind nur anders umgesetzt und legen oft mehr vom Linux-Fundament unter der Plattform frei. VMware versteckt Komplexität hinter polierten Abstraktionen, Proxmox zeigt die Bausteine.

Manche Engineers empfinden diese Transparenz als Gewinn. Für andere bedeutet sie eine Lernkurve, bei der es um mehr geht als darum, einen Hypervisor durch einen anderen zu ersetzen.