KVM steckt in jedem Linux-Kernel — und ersetzt für viele Unternehmen teure Hypervisor-Lizenzen. Wie die Technik funktioniert, was QEMU, libvirt und VirtIO leisten und für wen sich der Umstieg lohnt.
KVM ist der Hypervisor, den viele Unternehmen schon im Haus haben, ohne ihn je installiert zu haben. Seit 2007 gehört die Kernel-based Virtual Machine zum Linux-Kernel. Jeder aktuelle Linux-Server bringt sie mit, Google betreibt seine Compute-Instanzen darauf, und viele Hosting-Anbieter setzen für ihre virtuellen Server ebenfalls auf KVM.
Auf die Tagesordnung vieler IT-Teams kommt das Thema trotzdem meist aus einem anderen Grund: Seit der Broadcom-Übernahme sind VMware-Lizenzverlängerungen für viele Unternehmen spürbar teurer geworden. Und wenn die nächste Lizenzrunde ansteht, wird plötzlich geprüft, was der Linux-Kernel eigentlich schon kann.
Dieser Ratgeber erklärt, wie KVM-Virtualisierung funktioniert, welche Komponenten zusammenspielen, wie Sie eine eigene Virtualisierungsumgebung einrichten und wo KVM im Vergleich zu VMware, Hyper-V, Proxmox und Virtuozzo steht.
Was ist KVM-Virtualisierung?
KVM (Kernel-based Virtual Machine) ist eine Open-Source-Virtualisierungstechnik, die den Linux-Kernel selbst zum Hypervisor macht. Ein Kernel-Modul gibt virtuellen Maschinen direkten Zugriff auf die Virtualisierungsfunktionen des Prozessors. Jede VM läuft als normaler Linux-Prozess mit eigenem Gastbetriebssystem — mit einer Geschwindigkeit nahe an nativer Hardware.
Virtualisierung trennt Betriebssysteme von der physischen Hardware. Ein Hypervisor verteilt Prozessor, Speicher und Netzwerk eines physischen Servers (Host) auf mehrere virtuelle Maschinen (Gäste). Jede VM verhält sich wie ein eigenständiger Server mit eigenem Betriebssystem — auf derselben Hardware laufen so ein Debian-Webserver, eine Windows-VM für die Fachanwendung und eine Testumgebung nebeneinander, sauber voneinander getrennt.
Der praktische Nutzen ist seit Jahren derselbe: bessere Auslastung der Server, schnellere Bereitstellung, einfachere Trennung von Systemen. Wie das Konzept im Detail funktioniert, haben wir im Beitrag zu den Grundlagen der Virtualisierung beschrieben.
Die Besonderheit von KVM steckt im Namen. Der Hypervisor ist kein zusätzliches Produkt, das auf dem Betriebssystem installiert wird — er ist Teil des Linux-Kernels, seit Version 2.6.20 aus dem Jahr 2007. Technisch besteht er aus dem Basismodul kvm.ko und je einem prozessorspezifischen Modul: kvm-intel für Intel-CPUs mit VT-x, kvm-amd für AMD-CPUs mit AMD-V.
Das hat eine Konsequenz, die man im Betrieb schnell schätzen lernt: KVM erbt die Fähigkeiten des Kernels, statt sie neu zu erfinden. Der Linux-Scheduler verteilt die Rechenzeit der VMs, die Speicherverwaltung des Kernels verwaltet ihren Arbeitsspeicher, und Sicherheitsmechanismen wie SELinux greifen auch für virtuelle Maschinen. Jede VM ist aus Sicht des Hosts ein Prozess — sichtbar in der Prozessliste wie jeder andere Dienst.
KVM gilt als Typ-1-Hypervisor: Das Modul läuft im Kernel und damit direkt auf der Hardware, nicht als Anwendung auf einem Betriebssystem. Weil dieser Kernel gleichzeitig ein vollwertiges Linux ist, wird KVM gelegentlich als Zwischenform einsortiert. Für die Praxis ist die Debatte unergiebig. Messbar ist dagegen die Leistung: KVM nutzt die Hardware-Virtualisierung des Prozessors direkt, und die Performance liegt auf dem Niveau anderer Typ-1-Hypervisoren wie VMware ESXi oder Hyper-V — nicht auf dem einer Desktop-Anwendung wie VirtualBox.
Wer KVM zum ersten Mal einrichtet, stolpert über die Arbeitsteilung: Das Kernel-Modul allein startet noch keine VM. Erst das Zusammenspiel von drei Ebenen ergibt eine brauchbare Virtualisierungsumgebung — KVM im Kernel, QEMU im Userspace, libvirt für die Verwaltung.
QEMU ist ein Emulator, der einer VM die komplette Hardware-Umgebung bereitstellt: Festplatten-Controller, Netzwerkkarten, USB, Grafikausgabe. Ohne KVM emuliert QEMU auch den Prozessor — das funktioniert, ist aber langsam. In Kombination übernimmt KVM die CPU- und Speichervirtualisierung in Hardware-Geschwindigkeit, während QEMU nur noch das Gerätemodell liefert. Jede laufende VM ist auf dem Host als QEMU-Prozess sichtbar.
libvirt ist die Verwaltungsschicht darüber: ein Dienst (libvirtd), der VMs als XML-Definitionen speichert, ihre Lebenszyklen steuert und eine einheitliche API anbietet. Darauf setzen die Werkzeuge auf, mit denen man tatsächlich arbeitet: virsh als Kommandozeile, virt-manager als grafische Oberfläche, virt-install für die Erstellung neuer Gäste. Auch Web-Konsolen wie Cockpit sprechen mit libvirt.
Die wichtigsten virsh-Befehle für den Alltag:
virsh list --all # alle VMs mit Status anzeigen
virsh start vmname # VM starten
virsh shutdown vmname # VM sauber herunterfahren
virsh console vmname # auf die Konsole der VM wechseln
virsh dominfo vmname # Ressourcen und Status einer VMEmulierte Hardware ist flexibel, aber langsam — bei jedem Zugriff muss QEMU ein echtes Gerät nachbilden. VirtIO löst das mit Paravirtualisierung: Das Gastbetriebssystem bekommt Treiber, die wissen, dass sie in einer VM laufen, und direkt mit dem Hypervisor sprechen. Der Umweg über die Emulation entfällt, Netzwerk- und Festplattenzugriffe werden deutlich schneller. Linux-Gäste bringen die VirtIO-Treiber von Haus aus mit. Bei Windows-Gästen müssen sie separat installiert werden — dazu unten mehr.
In den Paketquellen der Distributionen ist die Aufgabenteilung direkt sichtbar. Ein typisches KVM-Setup umfasst: qemu-kvm (Emulator mit KVM-Unterstützung), libvirt-daemon beziehungsweise libvirt (Verwaltungsdienst), virt-install und virt-manager (Werkzeuge) sowie Netzwerk-Utilities für die Bridge-Konfiguration. Die Kernel-Module selbst müssen nicht installiert werden — sie sind schon da.
Die Vorteile von KVM lassen sich schnell aufzählen. Interessanter ist die ehrliche Frage, wo im Betrieb Arbeit entsteht — denn dort entscheidet sich, ob der Umstieg trägt.
KVM ist Open Source und Bestandteil des Kernels. Es gibt keine Lizenz pro Sockel, pro Core oder pro VM. Kosten entstehen erst für Support-Subscriptions, Management-Plattformen oder Dienstleister — planbar und ohne Preissprünge nach einer Übernahme.
Durch die Hardware-Virtualisierung des Prozessors und VirtIO-Treiber liegt die Leistung von KVM-VMs auf dem Niveau etablierter Enterprise-Hypervisoren.
KVM trägt seit Jahren Public Clouds und Hosting-Plattformen. Die Technik ist in jeder größeren Linux-Distribution enthalten und wird von einer großen Community und mehreren Herstellern weiterentwickelt.
Vom einzelnen Host mit einer Handvoll VMs über Proxmox-Cluster bis zur OpenStack-Cloud mit hunderten Nodes — die Basis bleibt dieselbe.
Weil jede VM ein Linux-Prozess ist, greifen für sie dieselben Sicherheitsmechanismen wie für jeden anderen Prozess. Mit sVirt wird SELinux gezielt auf die Virtualisierung angewendet: Jede VM bekommt beim Start ein eigenes Sicherheitslabel, ihre Ressourcen (etwa die virtuellen Festplatten) werden entsprechend markiert. Bricht ein Angreifer aus einem Gastbetriebssystem aus, steht er nicht auf einem offenen Host, sondern in einem eng begrenzten Kontext — und kommt weder an den Host noch an die Nachbar-VMs heran. Auf RHEL-basierten Systemen ist das standardmäßig aktiv, ohne dass man es konfigurieren muss.
Management muss man sich zusammenstellen.
Ein Gegenstück zu vCenter liegt nicht einfach bei. Für einzelne Hosts reichen virt-manager oder Cockpit. Wer Cluster, Hochverfügbarkeit und zentrale Verwaltung braucht, holt sich eine Plattform wie Proxmox VE oder OpenShift Virtualization dazu — und damit auch deren Betriebsmodell.
Linux-Know-how ist Voraussetzung.
Troubleshooting findet auf der Kommandozeile statt. Ein Team, das bisher ausschließlich vSphere-Konsolen kennt, braucht Einarbeitungszeit — und die sollte im Projektplan stehen, nicht in der Freizeit der Admins.
Windows-Gäste brauchen Handarbeit.
Ohne VirtIO-Treiber läuft Windows auf emulierter Hardware und bleibt unter seinen Möglichkeiten. Die Treiberinstallation ist kein Hexenwerk, aber ein zusätzlicher Schritt, den VMware-Umsteiger nicht kennen.
Der Umstieg ist ein Projekt, kein Wochenende.
Bestehende VMs müssen konvertiert, Backups neu angebunden, Monitoring und Runbooks angepasst werden. Die Technik ist dabei selten das Problem — die undokumentierten Sonderfälle im Bestand sind es.
Für den Einstieg reicht ein einzelner Server oder eine Workstation mit Linux. Die Einrichtung folgt immer demselben Muster: Voraussetzungen prüfen, Pakete installieren, erste VM anlegen.
KVM setzt einen Prozessor mit Intel VT-x oder AMD-V voraus. Ob die CPU das kann, zeigt ein Befehl:
egrep -c '(vmx|svm)' /proc/cpuinfoJeder Wert größer als 0 bedeutet: Die CPU beherrscht Hardware-Virtualisierung. Steht dort eine 0, lohnt ein Blick ins BIOS/UEFI — auf vielen Servern und Business-PCs ist VT-x beziehungsweise AMD-V ab Werk deaktiviert. Danach die Ausstattung: genügend Arbeitsspeicher für Host und Gäste zusammen und ausreichend schneller Speicher für die virtuellen Festplatten.
Unter Ubuntu und Debian genügt ein Befehl:
sudo apt install qemu-kvm libvirt-daemon-system virtinst virt-managerAuf RHEL, AlmaLinux und Rocky Linux:
sudo dnf install qemu-kvm libvirt virt-install virt-viewerAnschließend den Verwaltungsdienst aktivieren und den eigenen Benutzer in die libvirt-Gruppe aufnehmen:
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt $USERFür die erste VM ist virt-manager der bequemste Weg: Assistent öffnen, Installations-ISO auswählen, vCPUs, Arbeitsspeicher und Festplattengröße festlegen, starten. Wer es reproduzierbar mag, nutzt virt-install:
virt-install
--name vmname
--memory 4096
--vcpus 2
--disk size=40
--cdrom /var/lib/libvirt/images/ubuntu-24.04-live-server-amd64.iso
--os-variant ubuntu24.04Danach läuft die Installation des Gastbetriebssystems wie auf physischer Hardware. Die fertige VM lässt sich mit virsh starten, stoppen und klonen.
KVM-Virtualisierung mit Windows als Gast ist Alltag, nicht Ausnahme — vom Windows Server für die Fachanwendung bis zum Test-Client. Damit die Performance stimmt, gehören die VirtIO-Treiber von Anfang an dazu: Das virtio-win-Treiberpaket (als ISO verfügbar) wird der VM als zweites CD-Laufwerk mitgegeben. Während der Windows-Installation findet das Setup die virtuelle VirtIO-Festplatte zunächst nicht — an dieser Stelle den Speichertreiber von der Treiber-ISO laden, danach läuft die Installation normal durch. Nach der Installation lohnt der restliche Treibersatz: Netzwerk (NetKVM), Ballooning für dynamischen Speicher und der Gast-Agent für sauberes Herunterfahren über virsh.
Bei der Zuweisung von Ressourcen entscheidet sich, wie stabil und wie effizient die Umgebung später läuft. Drei Themen tauchen dabei in jeder KVM-Umgebung auf.
Eine vCPU ist ein virtueller Prozessorkern, den der Linux-Scheduler auf die physischen Kerne und Threads des Hosts verteilt. „2 vCPUs“ heißt also: Die VM sieht zwei Prozessoren, bedient wird sie aus dem realen CPU-Pool des Hosts. Overcommitment — in Summe mehr vCPUs vergeben, als physisch vorhanden sind — ist technisch möglich und bei vielen parallelen, selten ausgelasteten VMs auch sinnvoll. Kritische Systeme mit konstanter Last plant man dagegen konservativ. Wer allen VMs großzügig vCPUs zuteilt, weil es nichts kostet, bezahlt später mit unerklärlichen Lastspitzen.
Virtuelle Festplatten sind aus Sicht des Gasts normale Laufwerke, auf dem Host je nach Format eine Datei oder ein Blockgerät. Die Wahl ist eine echte Betriebsentscheidung:
| Format / Backend | Stärke | Sinnvoll, wenn |
|---|---|---|
| qcow2 (Datei) | Snapshots, Thin Provisioning, kompakt | Flexibilität wichtiger ist als das letzte Quäntchen I/O-Leistung |
| RAW (Datei) | schlanker Aufbau, wenig Overhead | maximale Performance auf Dateiebene zählt und Snapshots das Storage übernimmt |
| LVM (Blockgerät) | Block-Performance, saubere Volume-Verwaltung | VMs direkt auf logischen Volumes statt in Image-Dateien liegen sollen |
Für einzelne Hosts ist lokaler Speicher die einfachste und schnellste Lösung. Sobald mehrere Hosts im Spiel sind, stellt sich die Frage nach Shared Storage: Ein NAS mit NFS-Freigabe ist der unkomplizierte Einstieg, iSCSI-SANs oder verteilter Speicher wie Ceph übernehmen in größeren Umgebungen. Spätestens wenn Live-Migration geplant ist, gehört Shared Storage auf die Anforderungsliste — sonst wandern mit jeder VM auch ihre kompletten Festplatten-Images durchs Netz.
Zwei Funktionen zeigen, wie weit KVM über das Starten und Stoppen von VMs hinausgeht — und beide stammen nicht aus einem Zusatzprodukt, sondern gehören zum Standardumfang.
Bei einer Live-Migration wechselt eine laufende VM von einem Host auf einen anderen, ohne dass Nutzer davon etwas merken. KVM kopiert dabei den Arbeitsspeicher der VM im Hintergrund auf das Ziel, hält die Maschine für einen kurzen Moment an und schaltet um. Der klassische Anwendungsfall ist Hardware-Wartung: Host leerräumen, Firmware aktualisieren oder Netzteil tauschen, VMs zurückholen — ohne Downtime-Fenster mit den Fachabteilungen verhandeln zu müssen. Voraussetzungen sind in der Regel Shared Storage und hinreichend gleiche CPU-Generationen auf beiden Hosts. Der Befehl selbst ist unspektakulär:
virsh migrate --live vmname qemu+ssh://zielhost/systemBeim GPU-Passthrough wird eine physische Grafikkarte komplett an eine VM durchgereicht. Die VM sieht die Karte samt vollem VRAM, als steckte sie direkt im Gehäuse — mit entsprechender Leistung für KI-Workloads, CAD, Videobearbeitung oder rechenintensive VDI-Arbeitsplätze. Der Host gibt die Karte dafür vollständig ab; er braucht entweder eine zweite GPU oder läuft headless.
Technisch steckt hinter dem GPU-Durchreichen das allgemeine PCI-Passthrough: Über das VFIO-Framework lässt sich fast jedes PCIe-Gerät exklusiv an eine VM geben — neben Grafikkarten auch Netzwerkkarten oder HBAs. Voraussetzung ist eine aktivierte IOMMU (Intel VT-d oder AMD-Vi) im BIOS/UEFI und im Kernel; der Gast bootet sinnvollerweise per UEFI (OVMF). Der Stolperstein in der Praxis sind die IOMMU-Gruppen: Geräte lassen sich nur gruppenweise durchreichen, und wie sauber die Gruppen geschnitten sind, entscheidet das Mainboard. Das prüft man besser vor der Hardware-Beschaffung als danach.
Welcher Hypervisor auf dem Papier der beste ist, hilft bei der Entscheidung selten weiter. Relevanter ist, was zum vorhandenen Bestand, zum Team und zum Betriebsmodell passt — denn ein Hypervisor-Wechsel ändert noch kein Betriebsmodell. Zuständigkeiten, Backup und Monitoring müssen genauso mitziehen wie die VMs.
vSphere ist das ausgereifteste Komplettpaket am Markt: ESXi als Hypervisor, vCenter als zentrale Verwaltung, HA und DRS als eingespielte Cluster-Funktionen. Dafür bezahlt man — seit der Broadcom-Übernahme in vielen Fällen deutlich mehr als früher, im Abo statt als Dauerlizenz. KVM bietet die Hypervisor-Leistung ohne Lizenzkosten, verlangt aber, dass man die Management-Ebene selbst wählt und betreibt. Wer den Umstieg erwägt, sollte ihn als Migrationsprojekt mit Parallelbetrieb planen; eine Übersicht der Optionen liefert unser Vergleich der VMware-Alternativen.
Hyper-V ist wie KVM ein Typ-1-Hypervisor und in Windows Server enthalten. In Umgebungen, die ohnehin auf Windows-Server-Lizenzen, Active Directory und System Center stehen, ist er der naheliegende Kandidat — die ehrliche Antwort auf „KVM oder Hyper-V“ beginnt beim vorhandenen Team und der Lizenzlage, nicht bei Benchmark-Balken. VirtualBox spielt in einer anderen Kategorie: ein Typ-2-Hypervisor, der als Anwendung auf dem Desktop läuft. Für Tests und lokale Entwicklungsumgebungen praktisch, für den Serverbetrieb nicht gedacht. „Ist KVM besser als VirtualBox?“ ist deshalb die falsche Frage — die beiden erledigen verschiedene Jobs.
Wer KVM produktiv betreibt, tut das selten „pur“, sondern über eine Plattform, die Cluster, Weboberfläche, Backup und Rechteverwaltung mitbringt. Proxmox VE ist im Mittelstand die verbreitetste Wahl: KVM für VMs, LXC für Container, Web-GUI, Cluster- und Backup-Funktionen inklusive; der Zugang zum stabilen Enterprise-Repository ist Teil der bezahlten Subscription. Red Hat hat sein klassisches RHV (Red Hat Virtualization) abgekündigt und führt die Virtualisierung in OpenShift Virtualization weiter — VMs laufen dort KubeVirt-basiert neben Containern. Dazu kommen OpenStack für Cloud-Größenordnungen und diverse Hosting-Panels, die KVM im Unterbau nutzen.
Die Frage stammt meist aus dem Hosting-Umfeld, und dort ist sie eigentlich eine Architekturfrage: Virtuozzo steht traditionell für Container-Virtualisierung, bei der sich alle Gäste einen Kernel teilen — dichter gepackt und günstiger, aber mit weniger Isolation und ohne freie Betriebssystemwahl. Eine KVM-VM bringt ihren eigenen Kernel mit: volle Isolation, eigene Kernel-Module, beliebige Betriebssysteme inklusive Windows. Wer einen virtuellen Server mit voller Kontrolle will, fährt mit KVM besser; wer viele gleichartige Linux-Instanzen möglichst dicht packen will, mit Containern.
| Ausgangslage | Naheliegender Weg | Dabei prüfen |
|---|---|---|
| Einzelne Linux-Hosts, Know-how vorhanden | KVM pur mit virt-manager oder Cockpit | Backup-Konzept, Monitoring-Anbindung |
| Mehrere Hosts, Cluster und Web-GUI gewünscht | Proxmox VE | Subscription-Modell, Migrationspfad der Alt-VMs |
| VMware-Bestand unter Lizenzdruck | Schrittweise Migration auf eine KVM-Plattform | Parallelbetrieb, Konvertierung, Backup-Integration |
| Kubernetes im Haus, VMs als Rest-Workload | KubeVirt / OpenShift Virtualization | Container-Know-how im Team, Storage-Klassen |
| Windows-geprägtes Team, AD-zentrierte IT | Hyper-V ernsthaft mitprüfen | Lizenz- und CAL-Kosten, Zukunftssicherheit |
Dass KVM Enterprise-tauglich ist, muss niemand mehr beweisen — die Belege laufen seit Jahren in Produktion.
In OpenStack übernimmt der Compute-Dienst Nova die Orchestrierung der virtuellen Maschinen — und als Hypervisor kommt dabei standardmäßig KVM über libvirt zum Einsatz. Nova entscheidet, auf welchem Host eine neue VM startet, libvirt und KVM führen aus. Wer eine Private Cloud auf OpenStack-Basis betreibt oder von einem Provider bezieht, betreibt damit fast immer KVM-Virtualisierung im großen Maßstab.
KubeVirt bringt VMs in die Kubernetes-Welt: Virtuelle Maschinen werden als Kubernetes-Ressourcen definiert und laufen — KVM-beschleunigt — in Pods neben regulären Containern. Interessant ist das für Teams, die ihre Plattform auf Kubernetes standardisiert haben, aber Workloads mitschleppen, die sich nicht containerisieren lassen: die alte Fachanwendung, die Appliance, der Windows-Dienst. Statt zwei Plattformen parallel zu betreiben, verwaltet ein Stack beides. OpenShift Virtualization ist die bekannteste kommerzielle Umsetzung dieses Ansatzes.
Die Liste ist länger, als viele vermuten. Google Compute Engine virtualisiert auf KVM-Basis, auch der Kern des AWS-Nitro-Hypervisors baut auf KVM-Technologie auf. Praktisch jeder Hoster mit „echten“ virtuellen Servern nutzt KVM im Unterbau, und im Enterprise-Umfeld läuft KVM über Proxmox-Cluster, OpenStack-Clouds und OpenShift-Plattformen.
Für die Entscheidung im eigenen Haus heißt das vor allem: Die Technik ist kein Wagnis. Das Projekt drumherum — Migration, Betrieb, Verantwortlichkeiten — bleibt trotzdem eines.
Wenn aus der Evaluierung ein konkretes Projekt wird und das Linux-Know-how im eigenen Team knapp ist, muss der Umstieg nicht allein gestemmt werden: In der Anbieterübersicht auf it-dock.de finden Sie IT-Dienstleister mit Datacenter- und Virtualisierungs-Schwerpunkt für Planung, Migration und Betrieb.
KVM ist eine Open-Source-Virtualisierungstechnik, die seit 2007 fester Bestandteil des Linux-Kernels ist. Sie macht den Kernel selbst zum Hypervisor: Virtuelle Maschinen laufen als Linux-Prozesse und nutzen die Hardware-Virtualisierung des Prozessors (Intel VT-x, AMD-V) — mit Leistung nahe an physischer Hardware.
KVM wird als Typ-1-Hypervisor eingeordnet, weil das Kernel-Modul direkt auf der Hardware läuft. Diskutiert wird die Einordnung nur, weil der Kernel zugleich ein vollständiges Linux ist. Praktisch relevant ist die Leistung — und die liegt auf dem Niveau von ESXi oder Hyper-V, nicht auf dem eines Desktop-Hypervisors.
Keine Hypervisor-Lizenzkosten, Performance nahe an nativer Hardware, bewährte Sicherheitsmechanismen wie SELinux/sVirt und ein breites Ökosystem von virt-manager über Proxmox VE bis OpenStack. Dazu kommt Unabhängigkeit: KVM gehört zum Linux-Kernel und hängt nicht am Lizenzmodell eines einzelnen Herstellers.
libvirt ist die Verwaltungsschicht für KVM (und andere Hypervisoren): ein Dienst mit einheitlicher API, der virtuelle Maschinen definiert, startet und überwacht. Werkzeuge wie virsh, virt-manager und Cockpit setzen darauf auf. Für den Alltag heißt das: einheitliche Befehle und Definitionen, unabhängig vom Werkzeug.
Ja — technisch ist KVM eine vollwertige Alternative zu vSphere/ESXi, bei Performance und Stabilität auf Augenhöhe. Der Unterschied liegt in der Management-Ebene: vCenter-Komfort muss über Plattformen wie Proxmox VE oder OpenShift Virtualization abgebildet werden. Der Wechsel ist damit weniger eine Frage der Technik als des Migrationsprojekts.
Die beiden lösen verschiedene Aufgaben. VirtualBox ist ein Typ-2-Hypervisor für den Desktop — gut für Tests und lokale Entwicklungsumgebungen. KVM ist ein Typ-1-Hypervisor für den Serverbetrieb mit deutlich besserer Performance und Serverfunktionen wie Live-Migration. Für produktive Server-Workloads ist KVM die richtige Wahl.
Grundsätzlich jede aktuelle Distribution, denn KVM steckt im Kernel. Für Server-Einsatz sind Debian, Ubuntu Server sowie RHEL und seine Ableger AlmaLinux und Rocky Linux gängig. Die Wahl richtet sich weniger nach der KVM-Funktion als nach Support-Anforderungen, Update-Zyklen und dem vorhandenen Know-how im Team.
Im Hosting-Kontext steht Virtuozzo meist für Container-Virtualisierung mit geteiltem Kernel, KVM für vollwertige virtuelle Maschinen mit eigenem Kernel. KVM bietet stärkere Isolation, freie Betriebssystemwahl und eigene Kernel-Module; Container packen gleichartige Linux-Workloads dichter. Für volle Kontrolle über den eigenen Server ist KVM die bessere Basis.
PUE-Grenzwerte, Abwärmequoten, Registermeldung zum 31. März: Das EnEfG macht Energieeffizienz im Rechenzentrum zur Pflicht mit Frist.
Exchange 2016 und 2019 bekommen keine Sicherheitsupdates mehr – Exchange Server SE ist der Weg für E-Mail im eigenen Haus. Lizenzen, Kosten, Systemanforderungen und Upgrade-Pfade im Überblick.
VMware wird nach Broadcom bis zu 6× teurer. 7 Alternativen wie Proxmox, Nutanix & Hyper-V im Vergleich – Kosten, Lizenzen und Migration erklärt.
Proxmox VE hat sich zur meistdiskutierten Alternative zu VMware entwickelt – quelloffen, kostenlos einsetzbar und in produktiven Umgebungen voll konkurrenzfähig.
VMware wird teurer: So finden Sie 2025 die passende Virtualisierung, senken Kosten und bleiben zukunftssicher.
Informiert bleiben
Erhalten Sie wöchentlich die wichtigsten Tech-Trends, exklusive Analysen und Experteninterviews – speziell für IT-Entscheider.
Kommentare (0)
Noch keine Kommentare vorhanden.