Zurück zum BlogKVM und ein klassischer OpenVZ-Container-VPS teilen sich mit anderen Kunden einen physischen Server. Der entscheidende Unterschied liegt beim Kernel, dem Kern des Betriebssystems: Ein OpenVZ-Container nutzt den Linux-Kernel des Hosts mit. Eine KVM-Maschine startet ihren eigenen Gast-Kernel. Das verändert die Softwareauswahl, die Verwaltung und die Sicherheitsgrenze.
EDIS bot früher selbst OpenVZ an. Heute verwenden wir für VPS ausschließlich KVM. Hier erklären wir die praktischen Unterschiede und die Grenzen einfacher Werbeversprechen.
KVM und OpenVZ auf einen Blick
- Kernel: Ein klassischer OpenVZ-Container teilt den Host-Kernel; eine KVM-VM startet ihren eigenen.
- Ressourcen: Beide Technologien können Limits setzen. Garantien hängen von der Zuteilung durch den Anbieter ab. EDIS stellt KVM-Tarife mit zugewiesenen vCPU, garantiertem RAM und Tarifspeicher bereit.
- Betriebssysteme: Klassische OpenVZ-Container bieten Linux-Umgebungen, die zum Host-Kernel passen. KVM unterstützt geeignete Linux- und Windows-Gäste sowie unterstützte eigene Images.
- Isolation: Container trennen Prozesse und Dateien über Funktionen desselben Kernels. KVM gibt jedem Gast eine eigene virtuelle Hardwareumgebung.
Was unterscheidet einen KVM-VPS von einem OpenVZ-VPS?
Ein klassischer OpenVZ-VPS ist ein Betriebssystem-Container. Seine Anwendungen laufen als Prozesse auf dem Host, bekommen aber eine getrennte Sicht auf Dateien, Netzwerk und Prozessnummern. Für den Kunden wirkt er wie ein Server; einen unabhängigen Gast-Kernel hat er nicht. Ein KVM-VPS ist eine vollständige virtuelle Maschine mit virtueller CPU, RAM und Festplatte, in der ein eigenes Betriebssystem startet.
Hier vergleichen wir KVM mit den älteren OpenVZ-Containerangeboten. Die umfassendere OpenVZ-Plattform konnte später auch KVM-basierte virtuelle Maschinen betreiben; der Name OpenVZ bezeichnet also nicht automatisch nur Container.
Kann ich meinen eigenen Kernel starten oder Kernel-Module laden?
Bei KVM kontrollieren Sie den Gast-Kernel. Sie können ihn aktualisieren, einen unterstützten anderen Kernel wählen und innerhalb der VM dessen Funktionen oder Module nutzen, sofern virtuelle Hardware und Konfiguration das erlauben. Root-Rechte gelten innerhalb Ihrer VM, nicht auf dem physischen Host.
Ein klassischer OpenVZ-Container teilt den Host-Kernel mit allen anderen Containern. Aus dem Container heraus können Sie ihn weder austauschen noch beliebige Module in den Host-Kernel laden. Das machte manche Softwareanforderung früher zur Support-Anfrage.
Sind CPU, RAM und Speicher wirklich dediziert?
KVM weist einer VM virtuelle CPUs, Arbeitsspeicher und ein virtuelles Laufwerk zu. Das bedeutet für sich genommen weder einen exklusiven physischen CPU-Kern pro vCPU noch einen eigenen physischen Server. Prozessoren, Speichermedien und Netzanschlüsse sind weiterhin gemeinsame Infrastruktur. Entscheidend sind daher Tarif und Bereitstellung durch den Anbieter.
Auch OpenVZ konnte CPU-, RAM- und Speichergrenzen setzen; ältere Angebote arbeiteten oft mit anderer Abrechnung und Burst-Regeln. Bei EDIS hat jeder KVM-Tarif seine ausgewiesene vCPU-Zuteilung, garantierten RAM und bereitgestellte Speicherkapazität. Prüfen Sie den konkreten Tarif am gewünschten Standort. Eine bestimmte Netzwerkgeschwindigkeit ergibt sich nicht allein aus dem Wort KVM.
Welche Betriebssysteme kann ich installieren?
Ein klassischer OpenVZ-Container stellt eine Linux-Umgebung auf dem Linux-Kernel des Hosts bereit. Kompatible Linux-Vorlagen sind möglich; Windows als Container oder ein völlig eigener Betriebssystem-Kernel hingegen nicht.
KVM kann geeignete Linux- und Windows-Gastsysteme starten, da jede VM virtuelle Hardware und ihren eigenen Kernel besitzt. EDIS bietet Linux-Images, Windows bei passenden Tarifen und die Installation über eigene ISO-Dateien. Prüfen Sie Image, Boot-Modus, Treiber und Lizenz des konkreten Tarifs. Für Windows Server empfehlen wir mindestens 4 GB RAM und 2 vCPU.
Wie unterscheidet sich die Sicherheitsisolation?
OpenVZ-Container waren keineswegs ohne Isolation: Prozesslisten, Dateisystemsichten und weitere Ressourcen werden getrennt. Die zentrale Grenze ist der gemeinsame Host-Kernel. Ein Fehler, mit dem jemand diese Grenze durchbricht, kann andere Container desselben Hosts gefährden. Eine kompromittierte Anwendung öffnet nicht automatisch alle Nachbar-Container, doch der gemeinsame Kernel vergrößert den möglichen Schadensbereich.
KVM ergänzt einen eigenen Gast-Kernel und eine hardwaregestützte Virtualisierungsgrenze pro VPS. Ein Kunde kann normalerweise weder Prozesse noch Dateien eines anderen Gasts über seine eigene VM auslesen. Sicherheitslücken im Hypervisor und Host bleiben möglich. Isolation ist ein Architekturvorteil, keine Zusage absoluter Unangreifbarkeit; Updates und Zugriffskontrollen bleiben wichtig.
Können andere Kunden oder EDIS in meinen VPS hineinschauen?
Andere Mandanten können die Prozessliste oder eingebundene Dateien einer KVM-VM normalerweise nicht einfach wie auf ihrem eigenen Server durchsehen. Ihr Gast hat eine eigene Sicht und ein eigenes Betriebssystem. Das unterscheidet ihn von Prozessen und Dateibäumen, die ein Container-Host direkt verwaltet.
Die Aussage, niemand könne jemals in eine KVM-VM sehen, wäre jedoch falsch. Personen mit privilegiertem Zugriff auf Host oder Storage könnten potenziell virtuelle Platten oder den Speicher einer laufenden VM untersuchen. KVM trennt Kunden voneinander; EDIS muss die darunterliegende Infrastruktur weiterhin betreiben und absichern. Vertrauen in den Anbieter und dessen Zugriffskontrollen gehört zur Sicherheitsentscheidung.
Kann ich die Festplatte in einem KVM-VPS verschlüsseln?
Ja. Im Gast kann auf unterstützten virtuellen Laufwerken eine Betriebssystem-Verschlüsselung wie Linux LUKS eingerichtet werden. Wenn Sie den Schlüssel kontrollieren, schützt das ruhende Daten vor unbefugtem Offline-Zugriff. Planen Sie das Entsperren nach einem Neustart, bewahren Sie Wiederherstellungsschlüssel sicher auf und testen Sie eine Wiederherstellung. KVM aktiviert Verschlüsselung nicht automatisch.
Bei einer laufenden VM macht Festplattenverschlüsselung den Inhalt für einen privilegierten Host-Zugriff nicht unsichtbar: Die VM braucht Klartext und Schlüssel im Arbeitsspeicher. Verschlüsselte Backups, sichere Anwendungen und gutes Schlüsselmanagement bleiben nötig. Prüfen Sie Boot- und Recovery-Ablauf vor dem produktiven Einsatz.
Was war Waveride, und warum verabschiedete sich EDIS von OpenVZ?
Vor vielen Jahren betrieb EDIS das beliebte OpenVZ-Projekt Waveride. Die damalige Website nannte es „an EDIS company“ und bewarb günstige VPS in Wien, Amsterdam und Chicago. Der surfende Pinguin machte Waveride unverwechselbar. Es machte Spaß; das damalige SolusVM-Panel und andere verfügbare Bedienoberflächen überzeugten uns allerdings weniger.
Unsere Container wirkten eher wie vom Host verwaltete Prozesse und Dateibäume als wie eigenständige Maschinen. Wir wollten Kunden mehr Kernel-Kontrolle und stärkere Trennung bieten. Deshalb stellten wir die OpenVZ-VPS vor ungefähr zehn Jahren ein und wechselten vollständig zu KVM. Das beschreibt unsere Geschichte, nicht jede heutige Containertechnik: Neuere OpenVZ-Versionen können Dateien auch in Disk-Images speichern.
Warum bietet EDIS Global heute ausschließlich KVM an?
Jeder VPS soll ein eigenes Gastsystem starten, dem Kunden Kernel-Kontrolle geben und durch eine starke VM-Grenze von anderen Kunden getrennt sein. KVM passt zu diesem Modell. Wir können die tariflich ausgewiesenen vCPU-, RAM- und Speicherressourcen bereitstellen und Linux sowie geeignete Windows-Konfigurationen unterstützen.
Container sind weiterhin sinnvoll, wenn Sie den Host selbst kontrollieren und Anwendungen leichtgewichtig verpacken möchten. Für einen Kunden-VPS mit eigenem Kernel und stärkerer Trennung wählen wir KVM. Vergleichen Sie die KVM-VPS-Tarife und Standorte von EDIS Global vor der Bestellung.