KVM vs. VMware Vergleich für Unternehmensvirtualisierung

Informatec Digital » Ressourcen » KVM vs. VMware Vergleich für Unternehmensvirtualisierung

Wenn Sie noch unentschlossen sind, ob Sie Ihre Infrastruktur auf KVM oder VMware einrichten sollen (oder einfach nur besser verstehen möchten, was die jeweilige Lösung bietet), bietet Ihnen dieser Leitfaden einen detaillierten Vergleich: Leistung, Sicherheit, Lizenzierung, Support, Containerkompatibilität, Datensicherung, Clustering, Netzwerk, Festplattenformate, Integration mit anderen Komponenten wie OpenStack oder Active Directory… Ziel ist es, dass Sie nach dem Lesen dieses Leitfadens genau wissen, in welchem ​​Szenario die jeweilige Option ihre Stärken hat.

Was sind KVM und VMware und worin ähneln sie sich?

VMware ist das Unternehmen hinter einer ganzen Familie von Virtualisierungsprodukten. Im Kontext von Rechenzentren ist VMware ESXi der Schlüsselakteur – ein Hypervisor vom Typ 1, der das Herzstück der VMware vSphere- Plattform bildet . Um ESXi herum agieren vCenter, vSAN, NSX, Horizon, Tanzu und viele weitere Komponenten, die ein ausgereiftes Ökosystem für anspruchsvolle Unternehmensumgebungen bilden.

Sowohl KVM als auch ESXi sind Bare-Metal-Hypervisoren des Typs 1, die mehrere virtuelle Maschinen (VMs) mit Gastbetriebssystemen wie Windows, Linux, BSD oder Solaris ausführen können und hardwaregestützte Virtualisierung (Intel VT-x, AMD-V) unterstützen. Prinzipiell ermöglichen beide die Bereitstellung und Isolation von VMs, Live-Migrationen , Snapshots und die Verwaltung großer Cluster. Der Unterschied liegt in der Art und Weise, wie diese Funktionen realisiert werden, in den Kosten, der Flexibilität und den jeweiligen administrativen Möglichkeiten.

Hypervisor-Typen und interne Architektur

In der Virtualisierung wird üblicherweise zwischen Hypervisoren des Typs 1 (Bare-Metal-Hypervisoren) und des Typs 2 (Hypervisoren, die auf einem Host-Betriebssystem installiert werden) unterschieden . KVM und ESXi gehören zum Typ 1, während Produkte wie VMware Workstation, VMware Player, VMware Fusion und VirtualBox dem Typ 2 angehören.

Im Fall von KVM , obwohl es als Teil eines Linux-Hosts installiert wird, gilt es als Hypervisor vom Typ 1, da der Linux-Kernel als direkter Hypervisor auf der Hardware fungiert. KVM erbt daher den CPU-Scheduler, die Speicherverwaltung und den Netzwerk-Stack von Linux selbst, was ihm erhebliche Flexibilität und Hardwarekompatibilität verleiht.

ESXi ist VMware's eigenes, minimales Betriebssystem, das speziell als Hypervisor entwickelt wurde. Es verfügt über einen geschlossenen Kernel , integrierte zertifizierte und optimierte Treiber und nutzt die VMware-Managementebene zur Interaktion mit der Hardware und den übrigen Komponenten (vCenter, NSX usw.). Dieser Ansatz reduziert den Softwareaufwand auf das für die Virtualisierung unbedingt Notwendige.

Neben der Unterscheidung zwischen Typ 1 und Typ 2 ist es wichtig, den Unterschied zwischen vollständiger, softwarebasierter Virtualisierung und hardwaregestützter Virtualisierung zu verstehen . Bei der rein softwarebasierten Virtualisierung emuliert der Hypervisor die gesamte Hardware und übersetzt CPU-Befehle (Binärübersetzung). Dies ist zwar langsamer, ermöglicht aber den Betrieb ohne VT-x/AMD-V. Bei der hardwaregestützten Virtualisierung werden einige vCPU-Befehle direkt auf der physischen CPU ausgeführt, wodurch der Overhead deutlich reduziert wird. KVM und ESXi nutzen diesen Ansatz, um hohe Leistung zu erzielen.

Leistung: Ist KVM oder VMware leistungsfähiger?

Die Rohleistung von KVM und ESXi ist in den meisten Produktionsszenarien sehr ähnlich. KVM basiert auf rund 10.000 hochoptimierten Codezeilen innerhalb des Linux-Kernels, was den Overhead reduziert, und erreicht mit QEMU und virtio nahezu native Leistung für CPU, Festplatte und Netzwerk.

Im Fall von VMware ESXi ist der Quellcode proprietär, aber das Gesamtprodukt umfasst schätzungsweise mehrere zehn Millionen Zeilen, wenn alle Ökosystemkomponenten einbezogen werden. In bestimmten synthetischen Benchmarks liefen VMs auf KVM etwas schneller als auf ESXi, aber in realen Unternehmensumgebungen sind die Unterschiede im Vergleich zu anderen Engpässen wie Speicher oder Netzwerk meist geringfügig .

VMware erzielt Vorteile in Szenarien mit Scheduling-Optimierungen, DRS, vMotion und Storage vMotion , die Lastausgleich und das Verschieben von VMs im laufenden Betrieb mit minimalen Auswirkungen ermöglichen und eine sehr stabile Leistung auch bei hoher Clusterauslastung gewährleisten.

KVM hingegen spielt seine Stärken besonders in Umgebungen aus, in denen Linux bereits etabliert ist und der Kernel (CPU-Governor, I/O-Scheduler, Hugepages, NUMA usw.) sowie der Netzwerk-Stack feinabgestimmt werden können. Durch die gemeinsame Nutzung des Kernels mit dem Host-System übernimmt KVM sehr schnell Hardwareverbesserungen , die Hersteller in den Linux-Kernel integriert haben.

Installations-, Komplexitäts- und Verwaltungstools

Die Lernkurve ist einer der Bereiche, in denen der Unterschied zwischen KVM und VMware am deutlichsten wird. Bei KVM erfordert die Installation zunächst die Einrichtung eines Linux-Systems (Ubuntu, RHEL, CentOS, Oracle Linux, SUSE usw.) und die Installation der notwendigen Pakete: KVM/QEMU, libvirt , Management-Tools wie virt-manager oder virt-install und gegebenenfalls die manuelle Konfiguration des virtuellen Switches, der Bridges und des Bondings . Es ist sehr flexibel, setzt aber ein fundiertes Verständnis des Linux-Ökosystems voraus.

Bei VMware ESXi ist der Workflow stärker geführt: Sie laden das ISO-Image herunter, brennen es auf einen USB-Stick oder eine CD, starten den Server und folgen einem einfachen grafischen Assistenten . Im nächsten Schritt wird üblicherweise die vCenter Server Appliance (eine vorkonfigurierte VM) von diesem ISO-Image bereitgestellt. Ab diesem Zeitpunkt wird praktisch alles über die Weboberfläche des vSphere Clients verwaltet.

KVM wird im täglichen Betrieb mit Tools wie virsh (einer Befehlszeilenschnittstelle für libvirt) und virt-manager (einer Desktop-GUI zur Verwaltung mehrerer KVM-Hosts) sowie SSH, VNC oder SPICE für die Verbindung zu VM-Konsolen verwaltet. Web-Oberflächen wie Kimchi und Foreman sind verfügbar, und Projekte wie oVirt und Red Hat Virtualization bieten eine erweiterte visuelle Ebene für KVM.

In VMware vSphere bildet vCenter mit seinem Webclient vSphere Client die zentrale Verwaltungsplattform. Über diesen Client lassen sich ESXi-Hosts, Cluster, virtuelle Netzwerke, Datenspeicher, HA, DRS, vSAN, NSX und vieles mehr steuern. Zusätzlich stehen ESXCLI für die Befehlszeile, PowerCLI (basierend auf PowerShell) zur Automatisierung nahezu aller Vorgänge sowie die Host-Client-Schnittstelle für eigenständige ESXi-Hosts ohne vCenter zur Verfügung.

Kosten-, Lizenz- und Supportmodell

Der Kostenunterschied ist deutlich: KVM ist Open-Source-Software, die in Linux integriert ist und keine separaten Hypervisor-Lizenzen benötigt. Da KVM seit 2007 in den Kernel integriert wurde, ist es auf allen modernen Linux-Distributionen verfügbar. Kosten entstehen durch kommerziellen Support (Red Hat, SUSE, Oracle usw.) und eventuell benötigte zusätzliche Verwaltungstools; die Kernfunktionalität ist jedoch kostenlos.

VMware vSphere ist eine kommerzielle Lösung, die üblicherweise pro CPU/Kern und Edition (Standard, Enterprise Plus usw.) lizenziert wird. Sie umfasst Lizenzen für ESXi und vCenter. Für zusätzliche Produkte wie NSX, vSAN, Tanzu, Horizon oder vRealize ist jeweils eine separate Lizenz erforderlich. Es gibt zwar eine kostenlose Edition von ESXi (vSphere Hypervisor), diese weist jedoch erhebliche Einschränkungen auf : schreibgeschützte APIs, keine vCenter-Verwaltung, kein technischer Support und keine Kompatibilität mit Backup-Lösungen, die auf den APIs basieren.

VMware bietet im Rahmen des Vertrags einen 24/7-Unternehmenssupport inklusive Zugriff auf die Wissensdatenbank, Updates, Patches und direkte Unterstützung. Bei KVM hingegen hängt der „offizielle“ Support von Ihrem Vertriebspartner (Red Hat, Oracle, SUSE usw.) oder Ihrem eigenen IT-Team ab. Zwar steht Ihnen stets eine sehr aktive Community zur Verfügung, doch gibt es keinen zentralen KVM-Anbieter, an den Sie sich bei Supportanfragen wenden können, es sei denn, Sie haben einen Vertrag mit einem bestimmten Anbieter abgeschlossen.

Hardwarekompatibilität und Skalierungsgrenzen

Hardwarekompatibilität ist ein weiterer entscheidender Faktor. Da KVM auf Linux basiert , profitiert es von der umfangreichen Liste der vom Kernel unterstützten Hardware: x86-CPUs mit VT-x/AMD-V , verschiedene Festplattencontroller, Netzwerkadapter, Architekturen wie ARM oder PowerPC in bestimmten Varianten usw. Solange der Kernel einen Treiber bereitstellt, funktioniert KVM in der Regel problemlos auf dem entsprechenden Host.

VMware ESXi setzt voraus, dass Server und Komponenten auf der Hardware-Kompatibilitätsliste (HCL) stehen . Dies gewährleistet zertifizierte Treiber und optimale Leistung, schränkt aber die Nutzung auf älterer oder sehr neuer Hardware ein, die den Zertifizierungsprozess noch nicht durchlaufen hat. In großen Projekten kann dies die Plattformkosten erhöhen, da spezielle, von VMware empfohlene Hardware angeschafft werden muss.

Kommerzielle Distributionen, die KVM enthalten, geben hinsichtlich der Leistungsgrenzen Richtwerte an. Beispielsweise werden in bestimmten Umgebungen bis zu 384 CPU-Kerne und 6 TB RAM pro Host unterstützt, mit rund 600 gleichzeitig laufenden VMs. Pro VM sind bis zu 256 vCPUs (in neueren Versionen auch mehr) und mehrere Terabyte virtueller RAM möglich . Dies hängt von der jeweiligen Distribution (Red Hat, Oracle Linux, SUSE) und den Validierungstests des Anbieters ab.

In VMware vSphere setzt die offizielle Dokumentation sehr hohe Grenzwerte: bis zu 896 logische CPUs und 24 TB RAM pro ESXi-Host , 1.024 VMs pro Host, 4.096 aggregierte vCPUs, 256 vCPUs pro VM, mehr als 6 TB RAM pro VM, virtuelle Festplatten bis zu 62 TB und Cluster mit bis zu 64 Hosts und 8.000 VMs . Auf vCenter-Ebene lassen sich bis zu 2.500 ESXi-Hosts und 40.000 VMs pro Instanz verwalten, was erhebliches Wachstumspotenzial bietet.

Sicherheit: Isolation, Verschlüsselung und Compliance

Die Sicherheit des Hypervisors ist von entscheidender Bedeutung: Wird der Host kompromittiert, hat der Angreifer freien Zugriff auf alle virtuellen Maschinen (VMs) und deren Daten. KVM nutzt das Linux-Sicherheits-Ökosystem, um die Isolation zu verstärken. Das Hauptmerkmal ist die kombinierte Verwendung von SELinux (Security-Enhanced Linux) und sVirt (Secure Virtualization) . SELinux definiert obligatorische Zugriffskontrollrichtlinien (MAC), und sVirt erweitert diese Richtlinien auf die VMs, indem es Prozesse und Festplattenabbilder kennzeichnet, um sie voneinander zu isolieren.

Zusätzlich können Sie iptables/nftables für erweiterte Firewall-Funktionen, UEFI Secure Boot auf Gastsystemen (mit manueller Konfiguration) und Speicherverschlüsselungstechnologien wie TME/MKTME auf kompatibler Hardware nutzen. Auf Festplattenebene ermöglicht KVM die transparente Verschlüsselung von QCOW2-Images mit 128-Bit-AES für den Gast oder die Delegierung der Verschlüsselung an das Host-Dateisystem oder das Gastbetriebssystem selbst.

VMware vSphere zeichnet sich auch in diesem Bereich durch einen Funktionsumfang aus, der speziell für regulierte Umgebungen (HIPAA, PCI DSS usw.) entwickelt wurde. Es bietet eine integrierte Firewall in ESXi , Unterstützung für Secure Boot UEFI, Integration mit TPM und vSphere Trust Authority, detaillierte Verwaltung von Berechtigungen und Rollen sowie die Verschlüsselung virtueller Maschinen mit Integration externer KMS oder des nativen vSphere-Schlüsselanbieters.

VMs in VMware können vTPM und virtualisierungsbasierte Sicherheitsfunktionen nutzen, und NSX bietet verteilte Endbenutzersicherheit (Mikrosegmentierung, verteilte Firewall, IDS/IPS je nach Edition). Darüber hinaus bietet VMware Tools zur Überwachung der Einhaltung von Vorschriften und zur Durchsetzung der Hypervisor-Konfiguration, wodurch die Plattform leichter an strenge regulatorische Vorgaben angepasst werden kann.

Virtuelle Netzwerke und Konnektivität

Auf Netzwerkebene nutzt KVM die Funktionen des Linux-Kernels und spezifische Tools. Für virtuelle Switches wird häufig Open vSwitch (OVS) verwendet , das öffentliche oder private virtuelle Bridges, verteiltes Switching zwischen Hosts sowie die Unterstützung von VLANs, VXLANs, QoS und weiteren erweiterten Funktionen ermöglicht. Klassische Linux-Bridges lassen sich ebenfalls erstellen, und Bonding oder Teaming können verwendet werden, um Verbindungen hinzuzufügen oder Redundanz zu konfigurieren.

Virtio-Netzwerkschnittstellen unterstützen VLANs und lassen sich mit libvirt orchestrieren , das die Verwaltung virtueller Netzwerke und einen in QEMU integrierten DHCP-Server umfasst. Die Firewall-Funktionen sind ebenso umfangreich wie der Linux-Netzwerkstack selbst, und VXLANs, Tunnel, VPNs und mehr können mit Standardwerkzeugen des Ökosystems eingerichtet werden.

In VMware vSphere basiert das Netzwerk auf zwei Switch-Typen: dem Standard-vSwitch (pro Host konfiguriert) und dem Distributed-vSwitch (zentral über vCenter verwaltet). Beide unterstützen VLANs, NIC-Teaming für Lastverteilung und Failover sowie grundlegende Sicherheitsrichtlinien. Für erweiterte softwaredefinierte Netzwerkfunktionen (Mikrosegmentierung, VXLAN, Load Balancer, verteilte Richtlinien) wird VMware NSX verwendet.

Die Konfiguration von Link-Aggregation, Portgruppen, Verkehrsrichtlinien oder Netzwerken für vMotion und Speicher ist in der vSphere-GUI in der Regel benutzerfreundlicher als die Durchführung über die CLI unter Linux. KVM bietet jedoch mehr Freiheit für „exotische“ Szenarien, wenn man mit iproute2, OVS und ähnlichem vertraut ist.

Speicherung, Festplattenformate und Migration

Mit KVM lässt sich praktisch alles, was Linux als physischen oder logischen Speicher einbinden kann, nutzen: SAS-, SATA- und NVMe-Festplatten, LVM-Volumes, NFS, iSCSI, SAN, NAS usw. VMs können virtuelle Festplattenabbilder oder Raw Device Mapping (Geräte- oder Volume-Passthrough) verwenden. Es ist auch möglich, ein LVM-Volume direkt an eine VM anzubinden.

Die nativen Image-Formate sind RAW (img) und QCOW2 . Das RAW-Format ist sehr einfach und schnell (etwa 10 % schneller als Formate mit zusätzlichen Ebenen), unterstützt aber keine internen Snapshots oder inkrementelle Block-Backups. QCOW2 hingegen bietet Snapshots, Komprimierung, Verschlüsselung, Thin Provisioning und TRIM/UNMAP-Unterstützung , wodurch Sie ungenutzten Speicherplatz mit Tools wie virt-sparsify freigeben können. Darüber hinaus versteht KVM weitere Formate wie VMDK (von VMware), VDI (VirtualBox), VHDX (Hyper-V) und viele mehr, was die Migration zwischen Plattformen erleichtert.

In VMware ESXi ist das Standard-Festplattenformat VMDK . Jede Festplatte besteht typischerweise aus einem .vmdk-Deskriptor und einer flachen .vmdk-Datei mit den Daten. Thin und Thick Provisioning werden unterstützt, und der Datenspeicher befindet sich üblicherweise auf VMFS oder NFS. Festplatten können automatische Unmaps nutzen, um Speicherplatz freizugeben, und Raw Device Mapping (RDM) ermöglicht die direkte Zuordnung von LUNs zu VMs.

Für die VM-Migration bietet KVM Live-Migration zwischen Hosts, sofern diese gemeinsam genutzten Speicher verwenden, sowie in bestimmten Szenarien Speichermigration (Verschieben von VM-Dateien auf einen anderen Host). Die Live-Speichermigration soll zukünftig erweitert werden. VMware bietet vMotion (Live-VM-Migration zwischen Hosts) und Storage vMotion (Migration von Festplatten zwischen Datenspeichern ohne Herunterfahren der VM) bereits seit Jahren an. Beide Lösungen sind ausgereift und optimal in das Clustermanagement integriert.

Clustering, Hochverfügbarkeit und Lastverteilung

Im Clustering bietet KVM die Komponenten, jedoch kein „geschlossenes“ Produkt wie vSphere. Für Hochverfügbarkeit werden Tools wie DRBD (Blockreplikation über das Netzwerk), Heartbeat und Pacemaker als Cluster-Ressourcenmanager eingesetzt . Failover-Konfigurationen zwischen Knoten sind zwar möglich , erfordern aber in der Regel viele manuelle Eingriffe und umfangreiches Fachwissen.

Automatisierter Lastausgleich ist keine Standardfunktion; er basiert typischerweise auf Projekten wie oVirt oder Red Hat Virtualization , die eine erweiterte Managementschicht auf KVM aufbauen, um automatische Migrationen basierend auf Last, Hochverfügbarkeit (HA), Richtlinien und anderen Faktoren zu ermöglichen. Im Allgemeinen ist die Einrichtung eines optimal konfigurierten KVM-Clusters mit HA ohne eine entsprechende kommerzielle Lösung nicht unkompliziert.

VMware vSphere zeichnet sich hingegen gerade durch seine Clustering-Funktionen aus. Features wie vSphere HA ermöglichen den automatischen Neustart von VMs auf anderen Hosts, falls ein Knoten ausfällt. Der Distributed Resource Scheduler (DRS) gleicht die Last aus, indem er VMs mithilfe von vMotion basierend auf CPU- und RAM-Auslastungsrichtlinien zwischen Hosts verschiebt. Für bestimmte VMs ist zudem Fehlertoleranz verfügbar , die eine Echtzeitreplik erstellt und so im Falle eines Host-Ausfalls eine nahtlose Kontinuität gewährleistet.

Darüber hinaus kann das verteilte Energiemanagement Hosts bei geringer Last herunterfahren und bei Bedarf wieder starten, wodurch Energie gespart wird, ohne die Kapazität zu beeinträchtigen. Die Konfiguration dieser Mechanismen ist über den vSphere Client sehr einfach, was VMware zur komfortabelsten Option macht, wenn Sie komplexe Cluster benötigen und sich nicht mit der Konsole auseinandersetzen möchten.

Gastsystem- und Containerkompatibilität

Sowohl KVM als auch VMware ESXi unterstützen eine Vielzahl von Gastbetriebssystemen: Windows (von sehr alten Versionen wie NT oder 95 bis hin zu aktuellen Versionen), viele Linux-Distributionen (Ubuntu, Debian, RHEL, CentOS, Fedora, Oracle Linux, SUSE, Kali usw.), BSD-Derivate (FreeBSD, OpenBSD), Solaris, OpenSolaris, NetWare, MS-DOS und sogar macOS mit gewissen Anpassungen und Einschränkungen.

Die Unterschiede liegen in der Integration mit der Containerwelt . Mit KVM lassen sich Docker oder Kubernetes wie mit jedem anderen Hypervisor in VMs ausführen. Zusätzlich gibt es spezielle Treiber (docker-machine-driver-kvm), mit denen sich Docker-Maschinen transparent auf KVM erstellen lassen. Dies verbessert Isolation und Performance im Vergleich zur manuellen VM-Einrichtung. Darüber hinaus integriert sich KVM hervorragend in OpenStack , wo es der Gruppe A (maximale Kompatibilität) zugeordnet ist und in privaten Linux-Clouds häufig als bevorzugter Hypervisor gilt.

VMware unternahm seinerseits erste Schritte mit vSphere Integrated Containers (Ausführung von Containern als schlanke VMs unter Photon OS) und hat mit VMware Tanzu einen bedeutenden Fortschritt erzielt . Tanzu integriert Kubernetes und Container direkt in ESXi. Es wandelt ESXi-Hosts mithilfe von Spherelet in Kubernetes-Knoten um, stellt eine Steuerungsebene für DevOps bereit, wird über vCenter verwaltet und nutzt NSX-T und gemeinsam genutzten Speicher, um eine umfassende Containerumgebung für Unternehmen zu schaffen (allerdings mit zusätzlichen Lizenzkosten).

Kurz gesagt: Wenn Sie stark in Linux-basierte native Cloud-Ökosysteme eingebunden sind, ist KVM + OpenStack/Kubernetes eine hervorragende Lösung; wenn Sie bereits eine bedeutende Investition in VMware getätigt haben und nach Containern suchen, die in Ihre vSphere-Plattform integriert sind und alle Netzwerk- und Sicherheitsfunktionen beinhalten, ist Tanzu eine leistungsstarke Option.

Integration mit anderen Komponenten: AD, OpenStack und Ökosystem

VMware vSphere integriert sich nativ mit Microsoft Active Directory für Authentifizierung und rollenbasierte Zugriffskontrolle. Benutzer können sich mit ihren Domänenanmeldeinformationen beim vSphere Client anmelden und Objekten (VMs, Datenspeichern, Clustern usw.) detaillierte Berechtigungen zuweisen. Darüber hinaus integriert sich die VMware Suite nahtlos: NSX für Netzwerkfunktionen, vSAN für softwaredefinierten Speicher, Horizon für VDI, vRealize für Automatisierung und Überwachung und vieles mehr.

In der KVM- Welt ist die Active Directory-Integration durch das Einbinden des Linux-Hosts (oder der VMs) in die Domäne problemlos möglich. Die Konfiguration erfordert jedoch den Einsatz von Tools wie sssd, winbind oder realmd. Für die Cloud-Orchestrierung spielt KVM seine Stärken mit OpenStack aus und ist dort die bevorzugte Wahl (Gruppe A), während ESXi der Gruppe B zugeordnet wird: Es wird zwar unterstützt, genießt im OpenStack-Ökosystem aber eine etwas geringere Priorität.

Was die Herstellerbindung angeht, ermöglicht KVM als Open-Source-Lösung ohne Herstellerbindung die Integration mit nahezu jeder kommerziellen oder Open-Source-Software und passt den Stack flexibel an Ihre Bedürfnisse an. Bei VMware hingegen tendiert man systembedingt dazu, die Lösung um die eigene Steuerungsebene und die Produkte herum aufzubauen. Dies sorgt zwar für hohe Konsistenz, bindet Sie aber auch an die Lizenzen und die Roadmap von VMware.

Datensicherung, Replikation und Datenschutz

Die Art der VM-Sicherung hat ebenfalls einen wesentlichen Einfluss. Bei KVM werden standardmäßig virsh und Festplatten-Snapshots verwendet. Werden LVM-Volumes für die VMs eingesetzt, lassen sich LVM-Snapshots erstellen und von diesen sichern. Dies bietet zwar eine sehr gute Performance, macht aber Migration und Speicherplatzverwaltung komplexer.

Bei Rohabbildern sind Backups nur bei ausgeschalteter VM möglich, da keine native Unterstützung für Snapshots auf Image-Ebene vorhanden ist. Mit qcow2 lassen sich Snapshots auf einer laufenden VM erstellen (hierfür ist der QEMU-Gastagent auf dem Gastbetriebssystem und die Konfiguration eines org.qemu.guest_agent.0-Kanals erforderlich), und die Daten können anschließend konsistent kopiert werden. Es gibt Lösungen, die libvirt und oVirt nutzen , um inkrementelle Backups basierend auf Blockänderungen zu implementieren.

Zur Replikation kann KVM DRBD auf Blockebene des Linux-Kernels verwenden und Festplatten synchron zwischen Knoten replizieren, um Hochverfügbarkeitscluster zu erstellen, allerdings in der Regel ohne Verschlüsselung, es sei denn, der Datenverkehr wird in VPNs oder Ähnlichem gekapselt.

In VMware vSphere ist der Datenschutz dank der vStorage Data Protection APIs robust . Backup-Anbieter (Veeam, NAKIVO usw.) nutzen diese APIs, um konsistente Snapshots laufender VMs zu erstellen, wobei die Anwendungen mithilfe von VMware Tools inaktiviert werden. Zudem wird Changed Block Tracking (CBT) genutzt , um hocheffiziente inkrementelle Backups zu ermöglichen, indem nur geänderte Blöcke kopiert werden.

Backup-Lösungen für VMware unterstützen typischerweise die sofortige VM-Wiederherstellung , die detaillierte Wiederherstellung von Anwendungsdateien oder -objekten (Exchange, SQL, AD usw.) sowie die Replikation zwischen ESXi-Hosts oder -Standorten. Die kostenlose Edition von ESXi stellt diese APIs nicht bereit. Daher wären in diesem Fall Skripte und manuelle Backups ausgeschalteter VMs erforderlich, was im Produktivbetrieb in der Regel nicht akzeptabel ist.

Wenn Datenschutz auf Hypervisor-Ebene und die Integration mit zahlreichen kommerziellen Backup-Lösungen entscheidend sind, bietet vSphere ein ausgereifteres und homogeneres Ökosystem. KVM ermöglicht zwar robuste Strategien, erfordert aber eine größere Vielfalt an Ansätzen und eine stärkere Abhängigkeit vom Fachwissen des Teams und den gewählten Tools.

Wann lohnt sich KVM und wann VMware?

Die Wahl zwischen KVM und VMware hängt nicht davon ab, welches System absolut „besser“ ist, sondern vielmehr davon, welches Tool am besten zum jeweiligen Kontext passt. Für Unternehmen mit begrenztem Budget , einer ausgeprägten Linux-Kultur und dem Wunsch nach individueller Plattformanpassung ist KVM sehr attraktiv: Es benötigt keine Hypervisor-Lizenzen, bietet breite Hardwarekompatibilität und umfangreiche Konfigurationsmöglichkeiten. Es eignet sich ideal für Startups, kleine VPS-Anbieter, Testlabore, Linux-zentrierte Umgebungen oder private Clouds auf Basis von OpenStack.

VMware ESXi und vSphere eignen sich optimal für Umgebungen, die einen hochintegrierten Ansatz, umfassenden kommerziellen Support und eine vereinfachte Verwaltung großer Cluster erfordern. Unternehmen, die bereits VMware-Produkte (Horizon, NSX, vSAN, Tanzu) einsetzen und hohe Anforderungen an Verfügbarkeit, Compliance und 24/7-Support stellen oder Wert auf eine ausgereifte, zentrale Konsole legen, investieren in der Regel bevorzugt in vSphere-Lizenzen und bauen ihre Virtualisierungsstrategie auf diesem Ökosystem auf.

Ganz praktisch betrachtet ist KVM eine leistungsstarke und kostengünstige Lösung , die Teams mit Linux-Erfahrung und der Bereitschaft zu etwas mehr Komplexität zugutekommt. VMware hingegen bietet ein eher „geschlossenes, aber komfortables“ Erlebnis: Man zahlt für Lizenzen und Wartung, erhält im Gegenzug aber eine äußerst ausgereifte Virtualisierungsplattform mit fortschrittlichem Clustering, fein abgestimmten Backup-Tools und einer sehr soliden Integration in die übrige VMware-Infrastruktur.