"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 beginnen, sich mit Proxmox zu beschäftigen, dreht sich das Gespräch fast immer um dieselbe Frage: Was ersetzt die vertrauten VMware-Funktionen?
vMotion. Distributed Switches. DRS. Cluster-Networking.
Diese Tools sind in VMware-Umgebungen nicht nur Funktionen — sie prägen, wie Administratoren Infrastruktur entwerfen. Nimmt man sie weg, ändert sich plötzlich das gesamte mentale Modell.
Ein Engineer hielt genau diesen Moment kürzlich fest, während er einen Übergang von ESXi und vCenter zu Proxmox plante. Seine Umgebung sollte drei oder vier Hosts umfassen, wobei ein Node spezialisierte Hardware enthielt, die PCIe-Passthrough erforderte. Da diese VMs von physischen Geräten abhängen, könnte das Verschieben zwischen Hosts ernsthafte Probleme verursachen.
Die Frage des Engineers war einfach, aber aufschlussreich: Sollten diese Hosts trotzdem in einen Cluster eingebunden werden, oder sollte die Infrastruktur anders entworfen werden?
Diese Frage löste eine überraschend detaillierte Diskussion darüber aus, wie Proxmox Virtualisierung anders angeht als VMware.
Live-Migration existiert — aber die Philosophie ist eine andere
Eine der ersten Antworten klärte das wichtigste Anliegen: Ja, Proxmox unterstützt Live-Migration.
Virtuelle Maschinen und Container können sich innerhalb eines Clusters zwischen Hosts bewegen, ohne heruntergefahren zu werden, ähnlich wie bei VMwares vMotion. Aber die Automatisierungsebene verhält sich anders.
In VMware-Umgebungen analysiert der Distributed Resource Scheduler ständig die Host-Ressourcennutzung und kann Workloads automatisch neu ausbalancieren.
Proxmox verfolgt einen leichteren Ansatz.
Cluster Resource Scheduling — von Administratoren oft als CRS bezeichnet — konzentriert sich in erster Linie auf High-Availability-Ereignisse statt auf ständige Optimierung. Administratoren erstellen typischerweise Host-Prioritätsgruppen und weisen VMs gezielt über Nodes hinweg zu. Der Cluster stellt dann bei Ausfällen die Verfügbarkeit sicher, statt Workloads fortlaufend basierend auf CPU- oder Speicherauslastung zu verschieben.
Manche Engineers mögen diese Einfachheit.
Andere vermissen VMwares automatisiertes Load-Balancing.
Allein dieser Unterschied prägt oft, wie Teams ihre Proxmox-Cluster entwerfen.
Distributed Switches werden zum Networking-Puzzle
Networking wurde schnell zum zweiten großen Thema in der Diskussion.
VMware-Administratoren verlassen sich häufig auf vSphere Distributed Switches, um VLANs, Port-Gruppen und Netzwerkkonfiguration zentral über mehrere Hosts hinweg zu verwalten.
Proxmox bildet diese Funktion nicht direkt nach.
Stattdessen baut es Networking auf Linux-Primitiven wie Bridges, Bonding und optionalen Open-vSwitch-Konfigurationen auf. Für Administratoren, die eine zentralisierte "Switch-Oberfläche" erwarten, kann sich das zunächst ungewohnt anfühlen.
Mehrere Engineers schlugen vor, dass Proxmox' Software Defined Networking-System das nächstliegende Äquivalent bietet.
Die Idee funktioniert so:
Administratoren erstellen eine SDN-Zone, hängen sie an eine über Hosts hinweg gemeinsam genutzte Linux-Bridge und definieren dann virtuelle Netzwerke — genannt VNets —, die einzelne VLAN-basierte Netzwerke repräsentieren. Sobald die SDN-Richtlinie angewendet ist, erscheinen diese Netzwerke auf jedem Host im Cluster.
In der Praxis funktionieren VNets ähnlich wie VMware-Port-Gruppen.
VM-Ersteller wählen beim Anhängen einer virtuellen NIC einfach das gewünschte Netzwerk aus.
Manche Engineers bevorzugen weiterhin Open vSwitch
Nicht alle waren sich einig, dass SDN der beste Ansatz ist.
Ein anderer Engineer argumentierte, dass Open vSwitch für Organisationen, die große Mengen an VMs oder komplexe VLAN-Setups verwalten, besser passen könnte. In diesem Modell werden VLANs direkt auf der Switch-Ebene konfiguriert statt über Proxmox' SDN-Abstraktion.
Seine Begründung war unkompliziert.
Manche Umgebungen enthalten Tausende von VMs. VLAN-Tags einzeln auf VM-Ebene zu konfigurieren wird mühsam. Ein traditionelleres Switch-Modell kann den operativen Aufwand reduzieren.
Diese Perspektive zeigt etwas Wichtiges über Proxmox-Networking: Mehrere Architekturen können funktionieren.
Es gibt kein einziges vorgeschriebenes Modell.
Die Linux-Networking-Ebene bleibt sichtbar
Ein weiterer Teil der Diskussion zeigte, wie tief Linux-Networking-Konzepte die Proxmox-Infrastruktur beeinflussen.
Ein Engineer beschrieb seine Produktionsumgebung mit sechs physischen Schnittstellen:
Zwei gebondete 1-Gb-Ports für Management-Traffic, verbunden mit separaten Switches für Redundanz.
Zwei 25-Gb-Schnittstellen, die Trunk-Traffic für virtuelle Maschinen abwickeln und mehrere VLANs transportieren.
Und ein weiteres Paar 25-Gb-Verbindungen, das für Shared Storage reserviert ist.
Ihre Networking-Kette sah so aus:
Physische Schnittstelle → Linux-Bond → Linux-VLAN → Linux-Bridge.
Nach der Konfiguration wählen VM-Ersteller einfach die passende Bridge für das gewünschte Netzwerk aus.
Es ist ein System, das gut funktioniert, aber es verlangt von Administratoren ein tieferes Verständnis der Linux-Networking-Grundlagen, als es viele VMware-Umgebungen erfordern.
Hardware-Passthrough bringt eine weitere Einschränkung mit sich
Auch die ursprüngliche Sorge um PCIe-Passthrough erhielt praktische Antworten.
Virtuelle Maschinen, die VFIO-Geräte-Passthrough nutzen — etwa GPUs oder spezialisierte Netzwerkkarten —, können nicht ohne Herunterfahren einfach zwischen Hosts migriert werden. Diese Einschränkung existiert bei den meisten Hypervisoren.
Die vorgeschlagene Lösung war unkompliziert.
Diese VMs einfach nicht an High-Availability-Migrationsregeln anhängen. Der Cluster kann die Hosts weiterhin normal verwalten, während die hardwareabhängigen VMs an ihre spezifischen Nodes gepinnt bleiben.
Administratoren können weiterhin Startreihenfolge, verzögerte Boot-Sequenzen und Shutdown-Verhalten auf Host-Ebene konfigurieren.
Das unterscheidet sich grundsätzlich nicht davon, wie viele VMware-Umgebungen ähnliche Workloads handhaben.
Die Storage-Architektur prägt weiterhin alles
Ein anderer Engineer wies darauf hin, dass die Storage-Architektur letztlich bestimmen kann, ob Clustering überhaupt sinnvoll ist.
Live-Migration funktioniert am besten, wenn mehrere Hosts gemeinsamen Zugriff auf dieselben VM-Disks haben. In VMware-Umgebungen bedeutet das meist SAN- oder NAS-Storage.
Proxmox-Umgebungen ersetzen SAN-Appliances oft durch verteilte Storage-Systeme wie Ceph. Mit Ceph können dieselben Nodes, die virtuelle Maschinen ausführen, auch Disks zu einem gemeinsamen Storage-Pool beisteuern.
Der Cluster repliziert Daten automatisch über die Nodes hinweg, sodass VMs sich zwischen Hosts bewegen können, ohne zentralisierte Storage-Hardware zu benötigen.
Aber Ceph bringt auch neue Design-Überlegungen mit sich: Netzwerkbandbreite, Disk-Balancing und Cluster-Gesundheit werden eng miteinander verknüpft.
Für Teams, die an SAN-basierte Umgebungen gewöhnt sind, kann diese Verschiebung ein anderes Mindset erfordern.
Die eigentliche Lektion, die in der Diskussion steckt
Was als einfache Frage zu Distributed Switches begann, deckte am Ende fast jeden Kernbereich der Virtualisierungsinfrastruktur ab.
Live-Migration.
Cluster-Scheduling.
Networking-Modelle.
Storage-Architektur.
Hardware-Passthrough.
Und das Gespräch offenbarte etwas Tieferes.
Viele der Funktionen, auf die sich VMware-Administratoren verlassen, existieren auch in Proxmox. Aber sie sind anders implementiert und legen oft mehr vom Linux-Fundament unter der Plattform frei.
VMware versteckt Komplexität hinter polierten Abstraktionen.
Proxmox legt die Bausteine offen.
Für manche Engineers ist diese Transparenz befähigend.
Für andere bedeutet sie eine Lernkurve, die über das simple Ersetzen eines Hypervisors durch einen anderen hinausgeht.