KVM vs OpenVZ vs LXC vs VMware vs Hyper-V bei VPS/VDS

Grundunterschied zwischen Containern und vollständigen VMs

OpenVZ/LXC-Container teilen den Linux-Host-Kernel. Isolation erfolgt über Namespaces und cgroups. Das ist effizient, aber der Gast bootet keinen eigenen Kernel.

KVM, VMware ESXi und Hyper-V stellen virtuelle Hardware für vollständige VMs bereit; Windows und unterschiedliche Linux-Kernel laufen unabhängiger.

Warum KVM im VPS/VDS-Markt häufig ist

KVM nutzt die Linux-Kernel-Virtualisierung und wird häufig mit QEMU/libvirt verwaltet. CPU-Topologie, RAM, Disks und Netzwerkgeräte werden virtualisiert.

Für Windows, Custom ISO, eigenen Kernel, Nested Virtualization oder spezielle Kernel-Module ist eine vollständige VM meist geeigneter.

Sind OpenVZ/LXC schlecht? Nein, sie lösen ein anderes Problem

Container-Virtualisierung kann wenig Overhead und hohe Dichte bieten. Für Linux-Dienste ist sie effizient; dafür gibt es weniger Kernel-Unabhängigkeit als bei VMs.

Docker/Nested-Container können durch Provider-cgroup-/Kernel-Policies eingeschränkt sein. Root bedeutet nicht automatisch volle Kernel-Freiheit.

Wo VMware und Hyper-V einzuordnen sind

VMware ESXi ist ein etabliertes VM-Ökosystem; Hyper-V integriert stark mit Windows Server. Für Kunden sind CPU-, Storage-, HA- und Overcommit-Policies des Providers wichtiger als nur der Hypervisorname.

Was bei Nested Virtualization gefragt werden sollte

Für Proxmox, KVM-in-VM, Emulatoren oder Hyper-V reicht 'KVM VPS' nicht. Nested VT-x/AMD-V muss vom Provider freigegeben sein.

Unter Linux kann `systemd-detect-virt` die Virtualisierung erkennen; Nested/Masking kann das Ergebnis beeinflussen.

systemd-detect-virt

lscpu | grep -E 'Hypervisor|Virtualization|Model name'

grep -E 'vmx|svm' /proc/cpuinfo | head

Fünf Dinge, die wichtiger als der Hypervisorname sind

CPU-Sharing, Memory Ballooning/Swap, Storage/IOPS, Snapshot/Backup sowie Netzwerk/DDoS sind oft wichtiger. Ein schlecht verwalteter KVM-Host kann langsam sein; ein guter Container-Host sehr schnell.