KVM/QEMU direkt vs. Proxmox — wann sich der Umweg über die GUI nicht lohnt
Proxmox baut auf genau diesem KVM/QEMU/libvirt-Stack auf. Wer nur 1-2 VMs auf einem einzelnen Ubuntu-Server braucht (kein Cluster, kein zentrales Management mehrerer Hosts), spart sich mit direktem KVM/QEMU den Ressourcen-Overhead einer vollen Proxmox-Installation. Sobald mehr als eine Handvoll VMs oder mehrere Hosts im Spiel sind, überwiegt der Komfort von Proxmox klar den Verzicht auf die zusätzliche Management-Schicht.
KVM installieren
egrep -c '(vmx|svm)' /proc/cpuinfo # > 0 = Virtualisierung unterstützt
sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst
sudo adduser $USER libvirt && sudo adduser $USER kvm
sudo systemctl enable --now libvirtd
virsh -c qemu:///system version
Nach dem adduser ist ein Neuanmelden (oder newgrp libvirt) nötig, damit die Gruppenmitgliedschaft in der aktuellen Shell-Session wirksam wird — ein häufiger Stolperstein, wenn virsh-Befehle danach immer noch "permission denied" werfen.
Netzwerk-Bridge
# /etc/netplan/01-bridge.yaml
network:
version: 2
renderer: networkd
ethernets:
ens3:
dhcp4: no
bridges:
br0:
interfaces: [ens3]
dhcp4: yes
parameters:
stp: false
forward-delay: 0
netplan apply
stp: false und forward-delay: 0 sind wichtig, wenn die Bridge die einzige Netzwerkverbindung zum Host ist — mit aktiviertem Spanning Tree Protocol kann die Bridge nach einem Reboot minutenlang "blockiert" bleiben, bevor Traffic durchgelassen wird. Bei einem Remote-Server ohne physischen Zugriff ist das ein reales Aussperr-Risiko.
VM per Cloud-Image erstellen
wget https://cloud-images.ubuntu.com/noble/current/noble-server-cloudimg-amd64.img \
-O /data/vms/ubuntu-base.img
cp /data/vms/ubuntu-base.img /data/vms/web-01.qcow2
qemu-img resize /data/vms/web-01.qcow2 40G
virt-install \
--name web-01 --ram 4096 --vcpus 4 \
--os-variant ubuntu24.04 \
--disk path=/data/vms/web-01.qcow2,format=qcow2 \
--network bridge=br0,model=virtio \
--graphics none --import --noautoconsole
Cloud-Images haben standardmäßig kein Root-Passwort und keinen SSH-Zugang vorkonfiguriert — dafür braucht es zusätzlich cloud-init mit einem NoCloud-Datenträger (Benutzer, SSH-Key, Netzwerkkonfiguration), sonst bleibt die frisch erstellte VM unerreichbar.
VM-Verwaltung mit virsh
virsh list --all
virsh start web-01
virsh shutdown web-01
virsh console web-01 # Beenden mit Ctrl+]
virsh snapshot-create-as web-01 snap1 "Vor Update"
virsh snapshot-revert web-01 snap1
virt-clone --original web-01 --name web-02 --auto-clone
virsh undefine web-01 --remove-all-storage
virsh undefine --remove-all-storage löscht unwiderruflich auch die Disk-Dateien — kein Bestätigungsdialog, kein Papierkorb. Vor dem Ausführen lohnt sich ein zweiter Blick auf den VM-Namen.
FAQ
Was ist der Unterschied zwischen KVM und Proxmox?
Proxmox verwendet KVM als Hypervisor-Backend und ergänzt Web-UI, Cluster-Management, Backup-Integration (PBS) und Storage-Abstraktion — der darunterliegende Virtualisierungs-Mechanismus ist identisch.
Lohnt sich der Umstieg von reinem KVM auf Proxmox später?
Ja, meist problemlos — bestehende libvirt-VMs lassen sich importieren, Proxmox nutzt denselben QEMU/KVM-Unterbau.
Fazit
KVM/QEMU mit libvirt ist das Fundament, auf dem Proxmox aufbaut. Für einzelne Server ohne Cluster-Anspruch reicht der direkte Weg über virsh — wer wächst, migriert später ohne Bruch zu Proxmox.
Ich richte sowohl schlanke KVM-Einzelserver als auch vollständige Proxmox-Cluster für Unternehmen in Heidelberg und der Rhein-Neckar-Region ein. Anfragen.