Proxmox VE für kleine Unternehmen – Warum der Wechsel von VMware/ESXi lohnt

Kleine Firmen stehen seit der Broadcom-Aufnahme von VMware vor einem Problem: Die Lizenzkosten sind in kürzer Zeit nicht mehr vorhersehbar, und die Appliance-Vorgabe (vSphere als zwingende Einheitsumgebung) zwingt auch zu komplexen Deployment-Modellen, wenn man nur einen oder zwei physische Host hat. Proxmox VE ist eine Linux-native Alternative, die aus einer anderen Annahme kommt: die Infrastruktur ist kein abgekapseltes Produkt, sondern ein verwalterbarer Bestandteil des Systems.

Dieser Artikel geht nicht davon aus, dass Proxmox besser ist – sondern dass es an einigen Stellen die passendere Wahl sein kann, wenn man die Kompromisse kennt.

Warum kleine Firmen auf Proxmox VE wechseln

Drei Gründe stehen in der Praxis vorne:

Lizenzkosten. Proxmox VE ist Open Source (AGPL für die Community Edition). Es gibt keine Laufzeitlizenz, die je nach Anzahl VM oder Kerne kumuliert. Die Enterprise-Subscription (unter anderem für Zugriff auf stabile Repositories und Support) kostet je nach Knotenanzahl einen festen Jahresbetrag – im Modell mit zwei Hosts etwa 190–360 EUR/Jahr, je nach gewählter Stufe. Das ist strukturell anders als VMware, wo die Lizenz oft je nach CPU-Kernanzahl oder Socket skaliert und Zusatzkosten für vCenter und Ultra Majesty-Features kommen können. (Die Werte sind grobe Annahmen – konkrete Preise ändern sich, und man prüft sie direkt bei Proxmox.)

Kein Appliance-Zwang. VMware zwingt nicht zu vCenter für den kleinen Betrieb – man kann ESXi auch einzeln betreiben. Aber die reale Welt zeigt jedenfalls: wenn eine Firma wächst, landet sie beim Appliance-Modell mit vCenter, Lizenz-Konsolidierung und den dazugehörigen Wartungsverträgen. Proxmox liefert alle Funktionen der Enterprise-Edition – Cluster, Migration, HA, Backup-Schedule, Storage-Management – in derselben Installation, ohne dass man ein separates Management-Appliance braucht. Der Cluster-Management-Logik liegt pve-cluster mit Corosync zugrunde, nicht ein eigenständiges vCenter-System.\

Linux-nativer Ansatz. Proxmox basiert auf Debian (in VE 8 auf Bookworm, Kernel 6.8). Das bedeutet: die Verwaltungskomponenten sind Debian-Pakete,updates laufen über das Debian-Ökosystem, und man hat Zugriff auf das volle Tooling von Linux. Für Firmen, die eh schon Linux im Betrieb haben, ist der Einstieg weniger fremd als ein komplett abgekapseltes VMware-System.

LXC-Container gegen VM: Entscheidungstabelle

Proxmox VE kennt zwei Virtualisierungsformen: LXC-Container (CT) und QEMU/KVM-VMs. CTs sind kernel/namespace-nah, VMs vollständig isoliert. Beide haben ihren Platz.

| Szenario | Empfehlung | Grund und Schmerz |

|---|---|---|

| Linux-basierte Dienste (Mail, Web, DNS, DHCP, Datenbank, Monitoring) | CT | Geringerer Overhead, schneller Start, geringerer Platzbedarf; Kernel wird vom Host geteilt – kein separates Kernel-Update nötig. |

| Windows-basierte Dienste | VM | LXC kann keinen Windows-Kernel ausführen. Windows tasks auf Proxmox sind VMs. |

| Isolierung von nicht vertrauenswürdigen Diensten | VM (oder CT mit strengen Capabilities) | CT teilt Kernel und einige Subsysteme. Wenn ein Dienst explizit eine andere Kernel-Isolation braucht, kommt eine VM. |

| Docker innerhalb einer Umgebung | CT möglich, aber Konfiguration nötig | Docker in CT läuft, aber Namespace-Isolation, Device-Cgroups und entweder AppArmor-Profile müssen behandelt werden; manche Docker-Networks (bridge/host modes) funktionieren weniger direkt. Für Docker-Farmen ist eine VM oft die einfachere Wahl. |

| ZFS-Abhängige Tasks | Host-Seite | ZFS ist ein Host-Modul; ein CT kann ZFS-Pools vom Host nutzen (Mount), aber eso ist keine ZFS-Implementation im CT selbst. Wenn viele ZFS-Operationen laufen, gehört die Logik auf den Host oder in eine VM mit eigener ZFS-Installation. |

| Nested Virtualization | VM mit KVM-Nested-Modus | LXC CT kann nicht direkt nested Virtualization liefern. QEMU-VMs können mit kvm_intel.nested=1 (Intel) oder kvm_amd.nested=1 (AMD) weitere KVM-VMs starten. Das wird im VM-Config gesetzt, nicht im LXC-CT. |

| Migration zwischen Hosts in einem Cluster | VM (Live-Migration) oder CT mit Shared Storage | Beide können im Cluster migriert werden, aber CT-Migration erfordert entweder Shared Storage oder eine entsprechende Netzwerk-Übertragung. |

Eine direkte Regel: wenn der Dienst ohnehin Linux ist und keine separate Kernel-Isolation braucht, ist CT oft der schnellere und schlankere Weg. Wenn der Dienst eine andere OS ist oder eine striktere Isolation braucht, kommt eine VM.

Snapshot-Strategie ohne Snapshot-Müll

Ein Snapshot in Proxmox ist kein Backup. Ein Snapshot erfasst den Zustand auf demselben Storage zur selben Zeit – wenn das Storage-Problem auftritt, ist der Snapshot mitbetroffen. Snapshots sind eher ein Rollback-Tool vor einer Risky Operation (Update, Konfigurationsänderung, Migrationstest) als ein Langzeitarchiv.

Eine sinnvolle Strategie:

Kurzerlöser-Snapshot vor jeder mutierenden Aktion. Ein Snapshot vor einem Dienst-Update oder einer größeren Konfig-Änderung, der danach nach ein paar Tagen gelöscht wird. Proxmox-CT und VM-Snapshots sind schnell angelegt und werden im Web-Interface unter dem jeweiligen CT/VM aufgelistet.
Template statt Snapshot für wiederkehrende Deployment. Wenn man häufig gleiche CT/VM-Setups aufsetzt (Mail, Web, ähnliche Service-Informationen), erstellt man ein Template (CT-Template: im CT-Menü als Template generieren; VM-Template: mit qm template oder im UIs als Template markieren). Templates sind unabhängig von Snapshot-Zeiten und reproduzierbar.
Rücksichtsloser Snapshotkette loswerden. Snapshot-Ketten (mehrere Snapshots nacheinander, die alle inaktiv sind) verbrauchen Verwaltungsaufwand und können bei der Wiederherstellung oder bei Backup-Komplexität stören. Der regelmäßige Löschzyklus für Snapshots, die nicht mehr für aktive Rollbacks genutzt werden, ist empfehlenswert. In der gängigen Proxmox-Praxis entfernt man Snapshots nach dem Zeitraum, in dem der Rollback noch Sinn hat (oft 3–7 Tage für Operations-Rollbacks).

Backups sind ein separates Konzept: vzdump (oder Backup-Schedules im Web-UI) erzeugen echte Backup-Dateien auf einem anderen Storage mit eigener Retention.

Storage-Design für kleine Firmen

Proxmox VE unterstützt verschiedene Storage-Typen. Für kleine Firmen kommt es auf die Knotenanzahl und die RAM-Situation an.

LVM-Thin. Einfach zu bedienen, Thin Provisioning, arbeitet gut mit einzelnen Hosts oder kleineren Setups. Storage wird unter Datacenter → Storage → Add → LVM-Thin angelegt (nachdem ein LVM-Thin-Pool auf dem Host eingerichtet wurde). Für kleine Firmen mit einem Host oder zwei Hosts ohne Cluster-Shared-Storage ist LVM-Thin eine gute Wahl. Nachteil: kein integriertes Snapshot-Feature auf Storage-Ebene wie bei ZFS, Verwaltung auf Host-Ebene.

ZFS. ZFS bietet komprimierte Datasets, Snapshot-Fähigkeit und integrierte Prüfsummen. Für einzelne Hosts oder kleine ZFS-Pools (Mirror, RAID-Z1/2) gut geeignet. ZFS braucht jedoch RAM für den ARC (Cache). Für 1–2 Hosts mit 16–32 GB RAM oder mehr ist ZFS eine starke Wahl. ZFS als Proxmox-Storage wird unter Datacenter → Storage → Add → ZFS eingebunden.

Ceph. Ceph ist verteiltes Storage für Cluster. Für kleine Firmen mit 1 oder 2 Knoten ist Ceph in der Regel zu komplex. Ein minimales Ceph-Cluster braucht in der Regel mindestens 3 Knoten für definierten Datenverfügbarkeitsschutz (ohne Ceph-Deployments mit weniger OSDs und höherem Verlustrisiko). Ceph lohnt sich, wenn man bereits eine Cluster-Infrastruktur mit 3+ Hosts hat und einen gemeinsamen verteilten Storage braucht, der unabhängig von einzelnen Host-Ausfällen steckt.

Empfehlung je Bundle-Große:

1 Host, keine Cluster-Anforderung: LVM-Thin oder ZFS (ZFS bei ausreichendem RAM, sonst LVM-Thin).
2 Hosts, einfache Failover- oder Migration-Anforderung ohne Shared-Storage-Zwang: ZFS pro Host oder LVM-Thin je Host; Backups auf separaten Storage (ISCSI, NFS, Verzeichnis).
3+ Hosts mit Cluster-Anforderung und gemeinsamem Storage: Ceph als Option, wenn die Hardware und das Netzwerk das tragen.

Beispielhafte CT-Aufteilung einer Beispielfirma

Beispiel für eine kleine Firma mit einem Proxmox-Host und vier Kern-LXC-Containern + einer Backup-Strategie:

|---|---|---|---|

| 100 | Mail (Postfix/Dovecot, Webmail) | CT | 25, 465, 587 (SMTP); 993, 995, 143 (IMAP/POP) |

| 101 | Webserver | CT | 80, 443 |

| 102 | DNS (PowerDNS/BIND) | CT | 53 TCP/UDP |

| 103 | Datenbank (PostgreSQL) | CT | 5432 |

| 104 | Monitoring (Prometheus-node-exporter + Alertmanager) | CT | 9100, 9093 (Beispiel) |

Die Wahl, welche Dienste in CT und welche in VM laufen, hängt von den Anforderungen ab – bei Windows-Abhängigkeiten (z.B. Buchhaltung) kommen VMs hinzu.

Befehlsbeispiele

CT anlegen mit `pct`

Ein Debian-12-CT aus dem Standard-Template (Voraussetzung: Template liegt unter /var/lib/vz/template/cache/ oder einem Proxmox-Storage als CT-Template verfügbar):


pct create 100 local:vztmpl/debian-12-standard_12.5-1_amd64.tar.xz \
  --hostname mail.brillianze.local \
  --net0 name=eth0,ip=192.168.3.100/24,gw=192.168.3.1 \
  --storage local-lvm \
  --rootfs local-lvm:20 \
  --ssh-key "ssh-ed25519 AAAA…"

Danach SSH-Zugriff und Nameserver setzen:


pct set 100 --nameserver 192.168.3.1 --searchdomain brillianze.local
pct start 100
pct status 100

Das Tool pct kennt ferner pct snapshot, pct clone, pct resize, pct mount/pct unmount für Filesystem-Operationen.

Backup-Plan mit `vzdump`

Ein Backup aller produktiven CTs/VMen auf einen Backup-Storage (z.B. ein separater NAS oder ein lokaler 2. Storage), täglich 7 Versionen, wöchentlich 4, monatlich 6 halten:


vzdump --mode snapshot --compress zstd \
  --storage backup \
  --keep-daily 7 --keep-weekly 4 --keep-monthly 6 \
  100 101 102 103

Im Web-UI (Datacenter → Backup → Add) lässt sich daraus ein wiederkehrender Schedule machen, der dieselben Retention-Parameter nutzt – die Kommandozeilen-Parameter entsprechen dem, was im UI konfigurierbar ist. Für eine Backup-Storage-Überprüfung prüft man regelmäßig --storage als gültigen Proxmox-Storage-Typ (z.B. NFS, CIFS, Verzeichnis, iSCSI).

Kostenrahmen – drei Firmenbeispiele

Die folgenden Werte sind Annahmen auf Basis öffentlicher Preisinformationen und typischer Lizenzkosten-Modelle; konkrete Kosten prüft man bei Proxmox (Enterprise-Subscription-Preise) und beim Hardware-Anbieter.

Firma A – Ein Host, 4–5 CTs, keine Umschulungsnotwendigkeit

Proxmox VE Community Edition: keine Lizenzkosten.
Enterprise Subscription (optional, für stabile Repos und Support): je nach Knoten-Stufe ca. 95–180 EUR/Jahr (Annahme, Basis-Stufe).
Hardware: bereits vorhanden, keine Mehrkosten.
Umstellungsaufwand: eine Person an einem Tag, plus Testfenster. Kostenschätzung: 1–2 Arbeitstage intern.

Firma B – Zwei Hosts, 10–15 Workloads, aktuelle ESXi-Lizenzen ersetzen

Proxmox Enterprise Subscription für zwei Knoten: Annahme ca. 190–360 EUR/Jahr (Stufe je nach Auswahl).
VMware-Lizenz, die entfällt: je nach vorhandener Vertragssituation (kann mehrere Hundert bis Tausend EUR/Jahr sein). Diese Einsparung ist abhängig vom konkreten Vertrag.
Umstellung: Migration existing VMs/CTs, Test, Abschaltung alter ESXi-Host. Schätzung: mehrere Tage Arbeit, ggf. externer Support.

Firma C – Freiburg-Setup, CVS-Anbindung vermeiden, Storage-Zentralisierung

Proxmox CE: keine Lizenzkosten.
Optional Enterprise: Annahme je nach Knoten-Stufe 95–180 EUR/Jahr.
Hardware: zusätzlicher 2. Host für Failover, falls nicht vorhanden. Schätzung: Hardware-Kosten je nach Konfiguration (z.B. reused Server/HYPER-V oder ähnliches).
Netto: spart Appliance-Lizenz und Komplexität, kostet ggf. Hardware-Zeit.

Checkliste: Wann lohnt sich Proxmox, wann nicht

Proxmox lohnt sich, wenn:

Man ohnehin Linux in der Infrastruktur hat und Linux-Kompetenz vorhanden ist.
Die aktuelle VMware-Lizenzstruktur Kosten oder Komplexität bringt, die nicht erklärt wird.
Mehrere kleine Dienste auf wenigen Rechnern betrieben werden und LXC als effiziente Option infrage kommt.
Eine Storage-Lösung (LVM-Thin, ZFS) ohne Cluster-Overhead reicht.
Backup und Snapshot-Strategie klar geplant sind und man die Unterscheidung versteht.

Proxmox lohnt sich weniger, wenn:

Die Firma reine Windows-Infrastruktur hat und die Mitarbeiter nur VMware kennen. Dann ist der Umstellungsaufwand hoch und der Lernerfolg spät.
Nur eine einzige VM auf einem Host läuft und die Kosten von Proxmox (auch wenn es keine Lizenz kostet) den Aufwand nicht rechtfertigen.
Es spezifische VMware-Features gibt, die ohne VMware nicht verfügbar sind (z.B. bestimmte VMware-virtuelle Hardware oder Lizenz-gebundene Funktionen), die zwingend benötigt werden.
Das vorhandene Netzwerk und die Hardware Ceph als Storage-Planning nicht tragen und ein verteilter Storage ohne sinnvollen Gewinn eingesetzt werden soll.

FAQ

Wie lange dauert die Umstellung von ESXi auf Proxmox?

Je nach Umfang: kleine Firmen mit 3–5 VMs/CTs können die Migration in einem bis drei Tagen bewältigen (Bestandsaufnahme, Umzug der VM-Definition/Content, Test), vorausgesetzt die Workloads sind Linux-basiert oder lassen sich leicht verwalten. Windows-VMs brauchen ebenfalls eine Migration, aber den Umzug der VM-Dateien als QEMU-KVM-VM (Backend-Kompatibilität, ggf. Treiber-Anpassung). Ein externes Tool oder Skript unterstützt den Export aus ESXi und Import nach Proxmox.

Kann meine Buchhaltung im Container laufen?

Wenn die Buchhaltungssoftware Linux-basiert ist (geht das? in der Regel für kleine Firmen eher nicht – viele Buchhaltungssysteme sind Windows- oder webbasiert auf Fremd-Host), kann sie in einem LXC-CT laufen. Die gängigere Situation: Buchhaltungssoftware läuft auf Windows, und dann braucht man eine QEMU-VM auf Proxmox, nicht einen CT. Eine Lösung: Windows-VM auf Proxmox für die Buchhaltung, daneben Linux-CT für übrige Dienste.

Was kostet Proxmox?

Die Community Edition ist frei (Open Source, AGPL). Die Enterprise-Subscription (unter anderem für stabile Repositories und Support-Möglichkeit) kostet einen festen Jahresbetrag je nach Knoten-Stufe, Annahme ca. 95–360 EUR/Jahr für kleine Setups. Hardware-Kosten und Umstellungsaufwand kommen zusätzlich. Genaue Preise prüft man direkt bei Proxmox.

LXC-Container vs. VM – was nehme ich wann?

CT: Linux-Dienste, die keinen eigenen Kernel brauchen, mit wenig Overhead und schnellem Start. VM: Windows-tasks, strikte Isolation, andere Kernel-Anforderungen. Docker: CT möglich mit Konfiguration, VM oft einfacherer Weg für Docker-Farmen. Nested Virtualization: nur in VMs (mit KVM-Nested-Modus), nicht in LXC-CT.

Kurzfassung in 5 Punkten

1. Proxmox VE ist Open Source und kann VMware-Lizenzkosten und Appliance-Komplexität bei kleinen Firmen ersetzen, wenn Linux-Kompetenz vorhanden ist.

2. LXC-Container sind für Linux-Dienste schnell und schlank; VMs sind für Windows, strikte Isolation, andere Kernel und Nested Virtualization.

3. Snapshots sind kein Backup. Ein Backup mit vzdump (oder Backup-Schedule im UI) mit klarer Retention ist Pflicht.

4. Storage: LVM-Thin für Einfachheit, ZFS für Features (Compression, Snapshots), Ceph nur bei Cluster mit 3+ Knoten und entsprechendem Netzwerk.

5. Proxmox lohnt sich besonders für mehrere Dienste auf wenigen Linux-betriebenen Rechnern – nicht für reine Windows-Infrastruktur oder Single-VM-Setup ohne Mehrwert.

Hinweis: Dieser Artikel ist redaktioneller Inhalt und enthält keine Affiliate- oder Partner-Links. Alle Angaben entsprechen dem Stand 2026 und können sich ändern.