Nein. Nested Virtualization ist auf unseren KVM vServern deaktiviert. In der VM steht kein AMD-V und kein Intel VT-x zur Verfügung, Proxmox, Hyper-V, VirtualBox mit Hardwarebeschleunigung oder eigene KVM-Gäste laufen dort also nicht. Und ehrlich gesagt: Nach allem, was 2026 bekannt geworden ist, gehen wir nicht davon aus, diese Funktion auf geteilten Hosts jemals freizuschalten. Wer eigene VMs betreiben will, ist mit einem Dedicated Server mit Virtualisierung richtig.

Wofür benötige ich Virtualisierung?

Virtualisierung brauchst du, wenn auf deinem Server weitere, vollständig eigenständige Betriebssysteme laufen sollen. Typische Werkzeuge dafür sind Proxmox VE, Hyper-V, VMware ESXi oder KVM mit libvirt. Auf einem vServer wäre das eine zweite Virtualisierungsebene, eben Nested Virtualization: Unser Host betreibt deine VM, und deine VM betreibt wiederum eigene VMs.

Warum ist Nested Virtualization deaktiviert?

Der Hauptgrund ist Sicherheit. Auf einem Host laufen viele Kunden-VMs nebeneinander. Die wichtigste Aufgabe des Hypervisors ist, diese VMs sauber voneinander und vom Host zu trennen. Genau an dieser Grenze ist Nested Virtualization in diesem Jahr mehrfach gebrochen.

Die Sicherheitslücken von 2026

  • Januscape (CVE-2026-53359), veröffentlicht im Juli 2026, CVSS 8,8: ein Use-after-free in der Shadow-MMU von KVM auf x86, betroffen sind Intel und AMD. Der Fehler steckte rund 16 Jahre im Linux-Kernel. Ein Gast mit Root-Rechten kann den Host zum Absturz bringen, und damit alle anderen VMs auf diesem Host. Laut den Forschern ist auch Codeausführung auf dem Host möglich. Für eine vollständige Korrektur gehört zusätzlich der Fix zu CVE-2026-46113 dazu, der denselben Codepfad betrifft.
  • Zapscape (CVE-2026-64561), veröffentlicht im August 2026: wieder die Shadow-MMU von KVM auf x86, wieder ein Use-after-free. Hier gibt es einen öffentlichen Proof of Concept, der den Ausbruch aus der VM bis zu Root-Rechten auf dem Host zeigt, demonstriert auf AMD. Der betroffene Code stammt aus dem Jahr 2020.

Beide Lücken haben dieselbe Voraussetzung: Der Host muss dem Gast Nested Virtualization anbieten. Erst dann muss KVM für die verschachtelten VMs auf die alte Shadow-MMU zurückgreifen, und genau dort sitzen die Fehler. Die zweite Voraussetzung ist Root im Gast. Auf einem vServer hat jeder Kunde Root, das ist ja der Sinn eines Root-Servers. Für einen Angreifer ist diese Hürde also schon genommen, sobald er einen vServer bestellt.

Bei uns war und ist Nested Virtualization auf allen Hosts deaktiviert. Dieser Angriffsweg war deshalb bei Prepaid-Hoster nie offen.

Und das, was noch niemand gefunden hat

Für Januscape und Zapscape gibt es Patches. Das Problem ist ein anderes: Beide Fehler lagen jahrelang unentdeckt im Kernel, einer davon 16 Jahre. Der Codepfad für Nested Virtualization ist alt, komplex und wird im normalen Betrieb kaum benutzt. Es wäre naiv anzunehmen, dass dort jetzt alles gefunden ist. Und ein einziger Ausbruch trifft nicht nur den Kunden, der ihn auslöst, sondern alle VMs auf demselben Host.

Deshalb lautet unsere ehrliche Antwort: Wir planen nicht, Nested Virtualization auf den vServern freizuschalten, und wir können auch nicht versprechen, dass sich das jemals ändert. Das Risiko für alle anderen Kunden auf einem Host steht in keinem Verhältnis zum Nutzen für wenige.

Machen andere Hoster das anders?

Manche ja. Wir gehen aber davon aus, dass es bei Hostern, denen die Sicherheit ihrer Kunden wichtig ist, genauso läuft wie bei uns: Nested Virtualization auf geteilten Hosts bleibt aus. Falls dein Anbieter die Funktion auf vServern anbietet, lohnt sich die Frage, wie er mit Lücken wie Januscape und Zapscape umgeht.

Faire Auslastung

Dazu kommt ein zweiter Grund: Virtuelle Server sind dafür gemacht, Last günstig zu verteilen. Eine weitere Virtualisierungsebene kostet zusätzlich Leistung und macht die Auslastung eines Hosts schwer planbar. Ohne Nested Virtualization bleibt die Leistung für alle Kunden auf einem Host stabil.

Kann ich Docker benutzen?

Ja. Docker braucht keine Hardware-Virtualisierung, Container teilen sich den Kernel deines vServers. Docker läuft auf unseren KVM vServern ohne Einschränkung. Wie du es einrichtest, steht in vServer mit Docker: Installation, Compose und Docker Hub.

Gleiches gilt für andere Container-Lösungen wie LXC oder Podman. Für viele Fälle, in denen man reflexartig an eine VM denkt (getrennte Dienste, Testumgebungen, mehrere Projekte auf einem Server), reichen Container völlig aus.

Reine Software-Emulation, etwa QEMU ohne KVM-Beschleunigung, startet zwar auch ohne AMD-V oder VT-x. Für den ernsthaften Betrieb ist sie aber viel zu langsam.

Die Lösung für eigene VMs: Dedicated Server

Wenn du wirklich eigene virtuelle Maschinen brauchst, etwa für Proxmox, Hyper-V, ein Homelab im Rechenzentrum oder eigene Kunden-VMs, nimm einen Dedicated Server. Dort gehört dir die komplette Hardware, AMD-V bzw. Intel VT-x stehen dir uneingeschränkt zur Verfügung.

Und hier passt die Sache auch sicherheitstechnisch: Auf einem Dedicated Server teilst du dir den Hypervisor mit niemandem. Selbst wenn in einer deiner VMs ein Ausbruch passieren sollte, trifft er nur dein eigenes System und keine fremden Kunden. Ob alle Patches eingespielt sind, entscheidest du selbst.

  • Rund 100 Konfigurationen, Standorte Falkenstein und Nürnberg
  • Prepaid wie gewohnt, ohne Vertragsbindung
  • Auslieferung im Rescue-Modus, Installation im Dedicated Cloud Manager
  • Unmanaged: Hardware und Erreichbarkeit stellen wir sicher, das Betriebssystem und deine VMs verwaltest du

Den Einstieg findest du im Dedicated Server: Schnelleinstieg. Ob deine gewünschte Konfiguration Virtualisierung unterstützt, klärt der Artikel Unterstützt mein Dedicated Server Virtualisierung?