BEKOM OPEN PROVirtualisierung ohne LizenzfalleProxmox, KVM, XCP-ng
Open-Source-Virtualisierung für den produktiven Einsatz: Proxmox VE, KVM und XCP-ng im Vergleich. Auswahlkriterien, HA-Konzepte und Update-Logik.
Virtualisierung als Open-Source-Entscheidung
Die Broadcom-Übernahme von VMware hat für viele mittelständische Unternehmen eine grundlegende Frage aufgeworfen: Wie lange bleibt der bisherige Virtualisierungsstack wirtschaftlich vertretbar, und welche Alternativen stehen für den produktiven Einsatz zur Verfügung? Open-Source-Hypervisoren wie Proxmox VE, KVM und XCP-ng sind in den letzten Jahren zu produktionsreifen Alternativen herangereift.
Virtualisierungsplattformen sind geschäftskritische Infrastruktur, da sie die Basis für alle operativen Geschäftsprozesse bilden – von der Auftragsverarbeitung bis zur standortübergreifenden Anbindung der Filialen. Die Verfügbarkeit der Virtualisierungsschicht ist direkte Betriebsvoraussetzung für ERP-Systeme, Kundenportale und Compliance-relevante Dokumentationssysteme. Weiterführend: BEKOM OPEN PRO Infrastructure.
Warum Virtualisierung neu bewertet wird
Geschäftsführung und IT-Leitung stehen aktuell vor drei sich überlagernden Entwicklungen, die eine Überprüfung des Virtualisierungsstacks nahelegen. Die kommerziellen Rahmenbedingungen haben sich durch die Lizenzumstellung bei VMware verändert; parallel ist der Reifegrad der Open-Source-Alternativen auf ein Niveau gestiegen, das den produktiven Einsatz ermöglicht; schließlich verlangen Compliance-Anforderungen und Datensouveränitäts-Überlegungen eine klare Einordnung, welche Technologien langfristig tragfähig sind.
Typische Auslöser für eine Neuausrichtung:
- Lizenzänderungen bei proprietären Hypervisoren führen zu deutlich gestiegenen Betriebskosten bei gleichbleibender Funktionalität
- Vendor-Lock-in wird als strategisches Risiko bewertet, weil Migrationsfähigkeit in die Cloud oder zu anderen Betreibern erschwert wird
- Fachkräfte-Verfügbarkeit: Open-Source-Know-how ist am Arbeitsmarkt breiter verfügbar als spezialisierte Expertise für proprietäre Stacks
- Regulatorische Anforderungen verlangen Nachvollziehbarkeit und Kontrolle über eingesetzte Technologie-Komponenten
Für die Geschäftsführung bedeutet das: Die Virtualisierungsfrage ist keine rein technische Entscheidung, sondern ein strategisches Thema mit Auswirkungen auf Kosten, Risiko und Handlungsfähigkeit der nächsten Jahre.
Was BEKOM OPEN PRO Virtualisierung umfasst
BEKOM OPEN PRO Infrastructure ist neutral gegenüber konkreten Produkten. Die Kernaussage lautet: Für die meisten Workloads im Mittelstand gibt es mehrere tragfähige Open-Source-Optionen; die Entscheidung hängt von Einsatzszenario, Team-Skills und vorhandener Infrastruktur ab.
Inhaltlicher Scope:
- Technologische Einordnung von Proxmox VE, KVM (libvirt) und XCP-ng
- Auswahlkriterien entlang Reifegrad, Support-Modell und Migrationsfähigkeit
- Betriebsprinzipien für den produktiven Einsatz (High Availability, Change-Management, Härtung)
- Architektur-Empfehlungen für On-Premise, Cloud und Hybrid
BEKOM unterstützt Unternehmen bei der Technologie-Auswahl, bei der Planung des Übergangs und beim Aufbau einer nachhaltigen Betriebsstruktur – ohne produktseitige Festlegung.
Auswahlkriterien: Proxmox VE, KVM, XCP-ng
Die Entscheidung für einen Open-Source-Hypervisor folgt drei Kerndimensionen: Reifegrad für den Produktionseinsatz, Betriebsmodell und Support-Verfügbarkeit, sowie Migrations- und Exit-Fähigkeit. Alle drei Dimensionen sind gleichwertig – eine technisch reife Lösung ohne passendes Support-Modell ist für den produktiven Einsatz ebenso ungeeignet wie eine gut unterstützte Lösung mit unklarer Exit-Strategie.
Reifegrad und Produktionseinsatz
Proxmox VE, KVM und XCP-ng sind alle drei produktionsreife Hypervisor-Plattformen mit unterschiedlichen Schwerpunkten. Die Reifegrad-Einschätzung erfolgt entlang nachvollziehbarer Kriterien.
Bewertungskriterien:
Release-Zyklus und LTS-Verfügbarkeit: Stabile Versionen mit dokumentierten Support-Zeiträumen sind die Grundlage für planbaren Betrieb
Verbreitung im produktiven Umfeld: Anzahl dokumentierter Enterprise-Einsätze und aktive Community-Größe als Indikator für Langzeittragfähigkeit
Feature-Umfang: Live-Migration, Snapshots, Cluster-Betrieb, Backup-Integration als Mindeststandard
Dokumentationsqualität: Offizielle Dokumentation, Troubleshooting-Ressourcen und Referenzarchitekturen
Hardware-Kompatibilität: Breite der unterstützten Server-, Storage- und Netzwerk-Hardware im Rechenzentrumsumfeld
Security-Reife: Nachvollziehbare Meldekette für Schwachstellen, Erscheinungsfrequenz von Security-Updates und öffentlich dokumentierte CVE-Historie
Proxmox VE bietet eine integrierte Web-Oberfläche und einen abgeschlossenen Produktumfang; KVM in Kombination mit libvirt und Management-Tools wie oVirt ist flexibler, aber auch komplexer in der Erst-Einrichtung; XCP-ng positioniert sich als direkter Nachfolger der Citrix-Hypervisor-Linie mit Fokus auf Migrationsfähigkeit.
Betriebsmodell und Support-Verfügbarkeit
Der reine Technologie-Vergleich greift zu kurz – entscheidend ist die Frage, wie der laufende Betrieb abgesichert wird. Drei Modelle sind in der Praxis relevant.
Support-Optionen:
Community-basiert: Offene Foren und Mailing-Listen als Wissensquelle, ohne SLA – geeignet für Test- und Entwicklungsumgebungen, nicht für geschäftskritische Systeme
Subscription-Support vom Hersteller: Proxmox Server Solutions, Vates (XCP-ng) und andere bieten kommerzielle Subscriptions mit garantierter Reaktionszeit
Dienstleister-Support: Systemhäuser und spezialisierte Anbieter übernehmen Betrieb und Incident-Response als Paket – BEKOM zählt zu dieser Kategorie
Die Entscheidung hängt von der Risikotoleranz und den internen Kapazitäten ab. Für produktive Workloads im Mittelstand empfiehlt sich mindestens ein Subscription-Support, ergänzt um einen Dienstleister-Support für Betrieb und Incident-Management.
Migrations- und Exit-Fähigkeit
Ein oft unterschätztes Kriterium: Wie lassen sich Workloads später in eine andere Umgebung überführen? Open-Source-Hypervisoren unterscheiden sich in ihrer Exit-Fähigkeit deutlich von proprietären Stacks.
Migrations-Charakteristika:
Standardformate wie qcow2 oder raw-Disks erleichtern den Austausch zwischen KVM-basierten Systemen (Proxmox VE, KVM direkt, OpenStack)
V2V-Werkzeuge unterstützen die Migration aus VMware, Hyper-V oder älteren Xen-Installationen
XCP-ng bietet zusätzlich eine Rückwärts-Migration in Citrix-basierte Szenarien, falls erforderlich
Kein Lizenz-Lock: Workloads können ohne Lizenz-Zuweisung zwischen Umgebungen verschoben werden
Die Migrationsfähigkeit ist keine theoretische Option – sie ist ein strategisches Asset, weil sie die Abhängigkeit vom gewählten Anbieter reduziert und Verhandlungsmacht im Vertragsgespräch erhält.
Konkrete Hypervisor-Ablöse-Szenarien
Für die zwei häufigsten Hypervisor-Wechsel sind eigenständige Szenario-Seiten mit Migrationspfad, Vergleichsmatrix und Werkzeug-Empfehlungen dokumentiert:
VMware-Exit – Proxmox VE, KVM und XCP-ng als strukturierte Alternativen mit V2V-Werkzeugen, Cluster-Konzepten und Lizenzfreiheit
Citrix-XenServer-Exit – XCP-ng, Proxmox und KVM als Migrationspfade für Hypervisor-Workloads ohne Funktionsverlust
Betriebsprinzipien für produktiven Einsatz
Open-Source-Hypervisoren erreichen ihre Zuverlässigkeit im produktiven Betrieb nicht durch das Produkt allein, sondern durch strukturierte Betriebsprinzipien. Drei Bereiche sind dabei entscheidend: High Availability, Update- und Change-Logik, sowie Sicherheit und Härtung.
High Availability und Cluster-Konzepte
High Availability bedeutet: Ein Hardware-Ausfall einzelner Knoten führt nicht zum Verlust des Geschäftsbetriebs. Für Virtualisierungsumgebungen ist das über Cluster-Konzepte lösbar.
Cluster-Prinzipien:
Quorum-basierte Entscheidungen: Mindestens drei Knoten, um Split-Brain-Situationen bei Netzwerkstörungen zu vermeiden
Shared oder Hyperconverged Storage: Ceph, ZFS Replication oder externes SAN als Grundlage für VM-Failover
Live-Migration zwischen Knoten: Wartungsarbeiten ohne Abschaltung der Produktions-VMs
Automatisches Failover: Bei Knotenausfall starten betroffene VMs auf anderen Knoten des Clusters neu
Die Cluster-Dimensionierung orientiert sich am Lastprofil: Für geschäftskritische Workloads ist das Prinzip N+1 – es muss immer ein Knoten mehr vorhanden sein, als für den Normalbetrieb nötig, um bei Ausfall oder Wartung nicht in den kritischen Bereich zu kommen.
Update- und Change-Logik
Hypervisor-Updates sind sicherheitsrelevant und gleichzeitig risikobehaftet – ein fehlgeschlagenes Update kann die gesamte Infrastruktur betreffen. Strukturierte Update-Prozesse sind daher Pflicht.
Update-Disziplin:
Rolling Updates im Cluster: Knoten werden nacheinander aktualisiert, VMs vorab weggemigriert
Staging-Umgebung: Updates werden zuerst in einer Testumgebung gegen die produktiven Workloads geprüft
Rollback-Strategie: Für jede Update-Kampagne ist dokumentiert, wie im Fehlerfall zurückgewechselt wird
Change-Dokumentation: Jedes Update wird mit Zeitstempel, durchführender Person und beobachteten Auffälligkeiten protokolliert
Die Update-Frequenz orientiert sich an Security-Relevanz der jeweiligen Patches. Security-kritische Updates werden priorisiert eingespielt, Feature-Updates in längeren Zyklen.
Sicherheit und Härtung
Ein Hypervisor betreibt sensible Workloads – seine Sicherheits-Konfiguration ist die Grundlage für die gesamte darüberliegende IT-Landschaft.
Härtungsmaßnahmen:
Minimierung der installierten Dienste auf dem Hypervisor-Host (keine zusätzlichen Anwendungen auf Management-Nodes)
Trennung von Management-Netzwerk, Storage-Netzwerk und VM-Netzwerken auf Layer-2-Ebene
Zugriffskonzept: rollenbasierte Berechtigungen, zentrale Authentifizierung über LDAP oder SSO, keine geteilten Admin-Accounts
Logging und Audit-Trail: Jede administrative Aktion wird protokolliert, Log-Daten werden an ein zentrales SIEM weitergeleitet
Verschlüsselung der Management-Kommunikation (TLS) und der VM-Disk-Daten bei Bedarf
Konfigurations-Backup der Cluster- und Host-Konfiguration, damit eine Wiederherstellung nach Hardware-Tausch ohne manuelle Rekonstruktion möglich ist
Die Härtungsmaßnahmen sind dokumentierter Bestandteil des Betriebshandbuchs und werden bei jeder Änderung nachvollziehbar aktualisiert.
Betriebsmodelle: On-Premise, Cloud, Hybrid
Open-Source-Virtualisierung funktioniert in allen drei Betriebsmodellen. Die Wahl hängt von Anforderungen an Datensouveränität, Skalierung und vorhandener Infrastruktur ab. Die folgende Gegenüberstellung zeigt die jeweiligen Charakteristika.
On-Premise
Die klassische Variante: Virtualisierung im eigenen Rechenzentrum oder Serverraum, Hardware und Betrieb in eigener Hand.
Vorteile:
- Vollständige Kontrolle über Hardware, Daten und Konfiguration
- Keine laufenden Cloud-Gebühren, stattdessen Investitionen mit planbarer Abschreibung
- Latenz-Optimierung für lokal angebundene Fachanwendungen und Produktions-IT
- Datensouveränität: keine Übermittlung an Cloud-Anbieter, Compliance für regulierte Branchen vereinfacht
Ideal für diese Szenarien:
- Produktionsumgebungen mit lokalen Schnittstellen zu Maschinen und Steuerungen
- Unternehmen mit bestehender Hardware-Investitionsstrategie
- Szenarien mit strengen regulatorischen Vorgaben an Datenstandort
On-Premise bleibt für viele Mittelständler die wirtschaftlichste Option bei stabilem Ressourcenbedarf. Die Herausforderung liegt im Aufbau und Betrieb der Infrastruktur – hier unterstützt BEKOM durch Referenzarchitekturen und Betriebsbegleitung.
Cloud
Virtualisierung in BEKOM-Rechenzentren oder anderen souveränen Cloud-Umgebungen – Hardware und physischer Betrieb liegen beim Anbieter.
Vorteile:
- Keine eigenen Hardware-Investitionen oder Abschreibungszyklen
- Skalierbare Ressourcen je nach Bedarf – Erweiterung ohne Beschaffungsprozess
- Professioneller Infrastrukturbetrieb im Hintergrund (Kühlung, Netzanbindung, physische Sicherheit)
- Standorte in Deutschland oder der EU: Datensouveränität ohne eigenes Rechenzentrum
Ideal für diese Szenarien:
- Neue Workloads ohne bestehende Hardware-Basis
- Saisonal schwankender Ressourcenbedarf
- Unternehmen, die IT-Investitionen in planbare Betriebsausgaben umwandeln möchten
Die Cloud-Variante reduziert die operative Komplexität erheblich, verlagert aber die Kontrolle über physische Aspekte zum Anbieter. Die Wahl des richtigen Cloud-Partners – mit transparenten Betriebsprinzipien und Exit-Klauseln – ist der entscheidende Faktor.
Hybrid
Kombination aus On-Premise und Cloud, verbunden über dedizierte Netzwerke oder VPN. Workloads werden je nach Anforderung im passenden Modell betrieben.
Vorteile:
- Bestehende Infrastruktur weiter nutzen, neue Workloads in der Cloud ergänzen
- Latenzkritische Workloads bleiben lokal, skalierende oder temporäre Workloads in der Cloud
- Disaster Recovery durch Spiegelung zwischen Standorten
- Schrittweise Migration möglich, kein Big-Bang-Umzug erforderlich
Ideal für diese Szenarien:
- Bestehende On-Premise-Landschaft, die modernisiert statt ersetzt werden soll
- Gemischte Workload-Profile (lokale Fachanwendungen + Cloud-native Ergänzungen)
- Compliance-Anforderungen, die bestimmte Daten ausschließlich vor Ort erlauben
Hybrid ist für viele mittelständische Unternehmen der pragmatische Einstieg: bestehende Investitionen werden nicht abgeschrieben, gleichzeitig entstehen neue Möglichkeiten in der Cloud. Die Komplexität der Netzwerkanbindung und der konsistenten Verwaltung erfordert strukturierte Planung.
Kostentreiber bei der Virtualisierungsplattform-Entscheidung
Die Betriebskosten einer Virtualisierungsplattform entstehen durch mehrere Kostentreiber, die bei der Technologieentscheidung oft unterschätzt werden. Neben den offensichtlichen Lizenzkosten für proprietäre Hypervisoren fallen variable Aufwände für Patch-Management, Security-Updates und die kontinuierliche Überwachung der Virtualisierungsschicht an. Besonders kritisch sind ungeplante Kosten durch Lizenz-Audits, Upgrade-Zyklen oder die Migration zwischen verschiedenen Hypervisor-Technologien. BEKOM strukturiert diese Kostenstruktur durch eine planbare Monatspauschale, die sowohl den Betrieb der Open-Source-Virtualisierung als auch ein initiales Assessment der bestehenden Umgebung umfasst. Planbare Betriebskosten entstehen durch die Standardisierung auf bewährte Open-Source-Technologien und die Vermeidung von Vendor-Lock-in-Situationen.
Verwandte Themen: Virtualisierung & Compute verzahnt sich mit Container-Orchestrierung und Storage-Datenplattform.
Häufige Fragen zur Open-Source-Virtualisierung
Ist Proxmox VE für den produktiven Einsatz geeignet?
Proxmox VE wird seit über einem Jahrzehnt in Produktivumgebungen eingesetzt, auch bei mittelständischen Unternehmen und in Rechenzentren. Der Release-Zyklus ist dokumentiert, kommerzielle Subscriptions stehen zur Verfügung, und die Feature-Tiefe (Live-Migration, Cluster, Backup-Integration) entspricht den Anforderungen an geschäftskritische Workloads. Für produktive Einsätze empfiehlt sich die Kombination aus Subscription-Support und spezialisiertem Dienstleister.
Was kostet ein Umstieg auf Open-Source-Virtualisierung?
Die Kosten hängen vom Umfang der bestehenden Umgebung, der gewählten Zielplattform und dem Umfang der Migrationsunterstützung ab. Struktureller Unterschied zu proprietären Stacks: Lizenzkosten pro CPU oder Kern entfallen, stattdessen fallen Subscription-Kosten für Support und Updates an – deutlich planbarer und ohne Core-zählungsbasierte Steigerungen. Die konkreten Konditionen werden im Strategiegespräch auf Basis der vorhandenen Landschaft ermittelt.
Wie lange dauert eine Migration von VMware zu Proxmox oder KVM?
Die Dauer hängt primär von der Anzahl der Workloads, ihrer Kritikalität und den vorhandenen Schnittstellen ab. Für mittelständische Umgebungen typischerweise mehrere Monate in einem stufenbasierten Vorgehen mit Pilotphase, Migrationsstufen und Validierung. Eine exakte Planung entsteht im Assessment. Die Systeme können während der Migration im Parallelbetrieb laufen – kein Big-Bang-Umzug erforderlich.
Welche Rolle spielt das interne IT-Team beim Umstieg?
Das interne IT-Team bleibt als Wissensträger und zentraler Entscheider beteiligt. BEKOM übernimmt Migrationsplanung, technische Umsetzung, Incident-Response-Support und Schulung; fachliche Priorisierung, Budget-Entscheidungen und strategische Weichenstellungen verbleiben beim Unternehmen. Der Wissenstransfer ins interne Team ist Bestandteil jeder Migration, damit die Abhängigkeit vom Dienstleister begrenzt bleibt und das Team die Umgebung langfristig versteht.
Kann ich später zwischen Proxmox, KVM und XCP-ng wechseln?
Ja, das ist durch die gemeinsame qcow2/raw-Disk-Basis möglich. VMs können zwischen KVM-basierten Systemen (Proxmox VE und direktes KVM) ohne Format-Konvertierung verschoben werden, zwischen XCP-ng und KVM mit V2V-Werkzeugen wie virt-v2v. Dieser Exit-Vorteil ist einer der wichtigsten Gründe für Open-Source-Virtualisierung: die strategische Entscheidung lässt sich später nachjustieren, ohne dass Workloads grundlegend neu aufgebaut werden müssen – ein Vorteil gegenüber proprietären Lock-in-Stacks.
Lässt sich bestehende VMware- oder Hyper-V-Hardware für Proxmox-/KVM-Betrieb weiternutzen?
In der Regel ja, sofern die Hardware aktuelle CPU-Virtualisierungs-Erweiterungen (Intel VT-x/EPT, AMD-V/RVI) und kompatible Storage-Controller bietet. Die Bestandsaufnahme im Service-Design-Dokument prüft je Host: CPU-Generation, NICs (Treiber-Support), Storage-Backend (HBA, RAID-Controller, iSCSI/FC), Netzwerk-Konfiguration und Firmware-Stand. Proxmox VE und KVM unterstützen den gängigen Hardware-Stack des Mittelstands (Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem, Supermicro). VMs werden über V2V-Werkzeuge (virt-v2v) oder Storage-Mover migriert. Wenn einzelne Komponenten nicht unterstützt sind, wird das vor dem Cut-Over benannt – inklusive Hardware-Tausch-Bedarf und Wirtschaftlichkeit.
Wie unterscheidet sich BEKOM von reinem Distributor-Support?
Distributoren oder Subscription-Anbieter liefern den Hersteller-Support für das Produkt selbst – Break-Fix, Bug-Reports, Hersteller-Eskalation bei Produktfehlern. BEKOM ergänzt das um den Betrieb: Architektur-Beratung, Migrationsplanung, laufender Betrieb mit Monitoring, Incident-Response auf Infrastruktur-Ebene und Integration in die bestehende Gesamtarchitektur des Unternehmens. Die beiden Leistungen ergänzen sich – BEKOM koordiniert auf Wunsch auch den Hersteller-Support als Single Point of Contact.
Wie unterscheidet sich BEKOM OPEN PRO Virtualisierung von BEKOM MANAGED?
BEKOM OPEN PRO Virtualisierung adressiert die Technologie- und Architektur-Entscheidung: Welche Plattform, welche HA-Topologie, welche Migrationsstrategie, welche Betriebsprinzipien? BEKOM MANAGED Infrastructure – konkret Managed Virtualisierung – übernimmt den laufenden Betrieb mit Monitoring, Updates und Incident-Response nach definiertem SLA-Rahmen. Viele Kunden nutzen OPEN PRO für die Auswahl- und Architekturphase und übergeben den anschließenden Betrieb an MANAGED.
Nächster Schritt: Virtualisierungs-Evaluierung
Der Einstieg beginnt mit einem strukturierten Strategiegespräch: Bestandsaufnahme der vorhandenen Virtualisierungsumgebung, Bewertung der Optionen und Erstellung einer konkreten Handlungsempfehlung.
Strategiegespräch anfragen
Kontaktieren Sie BEKOM für ein unverbindliches Infrastruktur-Strategiegespräch. Gemeinsam mit Ihrem Team erfasst BEKOM die vorhandene Virtualisierungslandschaft, identifiziert Modernisierungsoptionen und bewertet die strategischen Alternativen.
Technologie-Evaluierung durchführen
Auf Basis des Strategiegesprächs vertieft BEKOM die technische Bewertung: Passt Proxmox VE, KVM oder XCP-ng am besten zur bestehenden Landschaft? Welche Migrationswege bieten sich an, welche Risiken sind zu adressieren? Ergebnis ist eine dokumentierte Empfehlung mit Begründung.
Pilotphase planen
Vor der vollständigen Migration startet ein Pilotbetrieb mit ausgewählten Workloads. Die Pilotphase validiert die gewählte Technologie unter realen Bedingungen und liefert die Erkenntnisse für die spätere Rollout-Planung. Die detaillierte Umsetzung ist Gegenstand des Folgegesprächs.