Proxmox VE Dedicated Server

Ein Proxmox-Dedicated-Server ist eine physische Single-Tenant-Maschine, die Proxmox VE — die Debian-basierte Open-Source-Virtualisierungsplattform — direkt auf der Hardware ausführt. Statt einen Anteil am Hypervisor eines anderen zu mieten, erhalten Sie die komplette Maschine: ein Web-UI und eine REST-API zum Aufsetzen von KVM-VMs und LXC-Containern, vollen Root-Zugriff auf den Host und jeden Core sowie jedes Gigabyte ECC-RAM, um es nach eigenem Ermessen zuzuweisen.

Der stärkste Grund, es hier zu betreiben, sind die Wirtschaftlichkeit und der Besitz. Proxmox VE steht unter der GNU AGPLv3 und lässt sich im Produktivbetrieb kostenlos ohne Hypervisor-Lizenz pro Sockel oder pro Core betreiben — ein kostenpflichtiges Abonnement kauft den Enterprise-Update-Kanal und Support, nicht die Funktionen. Stellen Sie es als fertiges Image auf ECC-EPYC-Hardware in unter einer Minute bereit, und der gesamte Virtualisierungs-Host gehört Ihnen — keine VMware-artige Rechnung pro Core und kein zwischen Ihnen und dem Metal geteilter Hypervisor.

Neu bei Hypervisoren? Lesen Sie unseren Leitfaden zu Bare-Metal-Hypervisoren.

Was Proxmox VE tatsächlich ist

Proxmox VE ist eine vollständige Virtualisierungsplattform, nicht bloß eine weitere Linux-Distribution. Es setzt einen Management-Stack auf Debian auf — das aktuelle Release, Proxmox VE 9.2, basiert auf Debian 13 „Trixie“ — und gibt Ihnen zwei Virtualisierungstechnologien unter einem Dach: den KVM-Hypervisor für vollständige VMs und LXC für Systemcontainer. Beide steuern Sie über eine einzige Weboberfläche auf Port 8006 oder über eine REST-API und die Kommandozeilenwerkzeuge pvesh / qm / pct, falls Sie lieber automatisieren.

Da die gesamte Plattform Open Source ist, liegt alles auf dem Host und nichts wird hinter einer Lizenzstufe zurückgehalten. Integriertes Clustering, Live-Migration, softwaredefinierter Speicher mit ZFS und Ceph, eine integrierte Firewall und ein Backup-Framework sind allesamt im kostenlosen Download enthalten. Auf einer Serverside-Maschine haben Sie vollen Root-Zugriff auf diesen Host, sodass die Version, die Sie betreiben, die Repositorys, die Sie aktivieren, und der Update-Zyklus ganz Ihre Entscheidung sind — die Appliance gehört Ihnen zum Betreiben, sie ist kein verwalteter Anteil, zu dem Sie sich Zugang mieten.

Subscription- vs. No-Subscription-Repositorys

Das ist der Teil, der Erstbetreibern von Proxmox Probleme bereitet, und es lohnt sich, ihn klarzustellen. Proxmox VE wird mit aktiviertem Enterprise-APT-Repository ausgeliefert, das einen kostenpflichtigen Subscription-Key zum Abrufen erfordert. Ohne Key schlagen apt-Updates gegen dieses Repository fehl — daher wechseln die meisten auf einer frischen Maschine als Erstes zum kostenlosen No-Subscription-Repository. Unter Proxmox VE 9 sind beide im modernen deb822-.sources-Format unter /etc/apt/sources.list.d/ definiert, und Sie deaktivieren jenes, das Sie nicht verwenden, statt es zu löschen.

Die beiden Repositorys unterscheiden sich in Erprobung und Support, nicht in den Funktionen. Proxmox’ eigene Empfehlung lautet, dass das No-Subscription-Repository „can be used for testing and non-production use“ ist und „not recommended on production servers“, weil seine Pakete nicht so streng validiert werden wie der Enterprise-Kanal. Ein Abonnement wird pro belegtem CPU-Sockel und Jahr abgerechnet — ein Sockel zählt einmal, unabhängig von der Core-Anzahl — und schaltet das stabile Enterprise-Repository sowie Support-Tickets mit SLA frei. Es schaltet keine Funktion frei: Jede Fähigkeit ist bereits im kostenlosen Download enthalten.

Welches Repository Sie auch wählen, ein Host ohne aktives Abonnement zeigt beim Web-UI-Login den bekannten „No valid subscription“-Dialog. Das ist ein Hinweis, keine Einschränkung — die Plattform ist in beiden Fällen voll funktionsfähig. Da Ihnen auf einer Serverside-Maschine der Root-Zugriff gehört, entscheiden Sie, ob Sie ein Abonnement für den Enterprise-Kanal und Support kaufen oder das No-Subscription-Repository betreiben und Updates selbst verwalten.

VMs vs. LXC-Container — wann was einsetzen

Proxmox gibt Ihnen zwei Möglichkeiten, einen Host aufzuteilen, und richtig zu wählen ist der Großteil der Kunst. Eine KVM-VM ist vollständige Hardware-Virtualisierung: Sie bootet ihren eigenen Kernel, betreibt jedes beliebige Betriebssystem — Windows, die BSDs, jedes Linux — und ist stark von ihren Nachbarn und dem Host isoliert. Diese Isolation und OS-Unabhängigkeit ist der Grund, warum VMs die richtige Wahl sind für alles, dem Sie nicht vollständig vertrauen, für alles Nicht-Linux und für alles, das Sie ohne Ausfallzeit zwischen Cluster-Nodes live migrieren möchten.

Ein LXC-Container ist ein Systemcontainer: Er teilt sich den Kernel des Hosts und betreibt darauf ein Linux-Userland. Das macht ihn weit leichtgewichtiger als eine VM — er startet in Sekundenbruchteilen, trägt nahezu keinen Speicher-Overhead und erlaubt es Ihnen, viele weitere Workloads auf dieselbe Hardware zu packen. Der Kompromiss ist, dass er Linux sein muss und die Isolation schwächer ist als bei einer vollständigen VM, da jeder Container auf dem einen geteilten Kernel aufsetzt.

In der Praxis betreiben die meisten Proxmox-Hosts eine Mischung: LXC für den dichten Bestand an Linux-Diensten, bei denen Effizienz zählt — Reverse-Proxys, interne Tools, selbst gehostete Apps —, und KVM-VMs für Windows-Gäste, alles, was einen anderen Kernel erfordert, und Workloads, die feste Isolation oder Live-Migration benötigen. Eine Maschine mit 32 Cores und 512 GB hat reichlich Reserven, um beide Muster gleichzeitig zu fahren.

Speicher: ZFS, Ceph und LVM-thin auf Bare Metal

Proxmox VE unterstützt mehrere Speicher-Backends, und der Betrieb auf Bare Metal ist es, der Ihnen erlaubt, das richtige zu wählen, statt zu erben, was ein Cloud-Host vorgibt. Auf einem einzelnen Node begegnen Ihnen die zwei Standards local — ein Verzeichnisspeicher für ISO-Images, Container-Templates und Backups — und local-lvm, ein LVM-thin-Pool, der VM-Disks und Container-Root-Volumes hält. Installieren Sie stattdessen auf ZFS, wird dieser Block-Speicher zu local-zfs.

ZFS ist die beliebte Single-Node-Wahl, weil es Ihrem VM-Speicher sofortige Snapshots, blockweise Replikation zwischen Nodes, geprüfte Datenintegrität und Kompression bringt. Der Preis ist RAM: ZFS möchte rund 2 GB Grundspeicher plus etwa 1 GB ARC-Cache pro Terabyte Pool. Aktuelle Proxmox-Installationen begrenzen den ARC standardmäßig auf 10 % des installierten RAMs, aber die Faustregel ist der Grund, warum Virtualisierungs-Hosts reichlich Speicher wollen — was genau der Grund ist, warum unsere Beispielkonfigurationen mit 384 GB und 512 GB DDR5 aufwarten.

Ceph ist das andere Ende der Skala: eine verteilte, selbstheilende Speicherschicht, die Disks über einen Cluster bündelt, sodass jeder Node jede VM betreiben kann, direkt in das Proxmox-Web-UI integriert. Es ist echt hyperkonvergent und echt anspruchsvoll — Proxmox empfiehlt mindestens drei Nodes und ein dediziertes Netzwerk von 10 Gbit/s oder mehr für Ceph-Traffic, steigend auf 25 Gbit/s und darüber für NVMe-gestützte Pools. Genau hier zahlt sich der Besitz des Bare Metals aus: echtes NVMe auf dem Host und ein schneller privater Uplink zwischen Ihren Servern sind es, die replizierten und geclusterten Speicher performen lassen, statt einer virtualisierten Disk auf einem geteilten Backend.

Clustering, Quorum und HA

Mehrere Proxmox-Hosts lassen sich zu einem einzigen Cluster zusammenschließen, der als eine Einheit verwaltet wird. Unter der Haube übernimmt corosync das Messaging zwischen den Nodes, und pmxcfs — das Proxmox Cluster File System — hält /etc/pve über alle hinweg synchron, sodass jeder Node dieselben VMs, denselben Speicher und dieselbe Konfiguration sieht. Von dort erhalten Sie Live-Migration und, mit geteiltem oder repliziertem Speicher, Hochverfügbarkeit, die Gäste anderswo neu startet, wenn ein Node ausfällt.

Der Haken, den jeder Cluster-Betreiber lernt, ist das Quorum. Ein Cluster handelt nur, wenn eine Mehrheit der Nodes abstimmen kann, weshalb eine ungerade Anzahl von Nodes empfohlen wird und drei das praktische Minimum für zuverlässige HA ist. Ein Zwei-Node-Cluster kann allein kein Quorum halten, wenn ein Node ausfällt — die Lösung ist ein QDevice, ein leichtgewichtiger externer Schlichter, der eine ausschlaggebende Stimme liefert, sodass ein Zwei-Node- (oder Even-Node-)Cluster einen einzelnen Ausfall übersteht.

Hier zählt der Besitz des Netzwerks genauso viel wie der Besitz der Hardware. Corosync ist latenzempfindlich und Ceph-Replikation bandbreitenhungrig, und keines von beiden gehört auf Ihre öffentliche Schnittstelle. Sie können virtuelles privates Networking zwischen Ihren Serverside-Servern einrichten, sodass Cluster-Messaging, Speicherreplikation und Live-Migration-Traffic allesamt über einen privaten Link laufen, wodurch die Management- und Replikationsebene vollständig vom öffentlichen Internet ferngehalten wird, während der schnelle Uplink die Last trägt.

Proxmox VE auf Serverside bereitstellen

Proxmox VE ist ein erstklassiges Deployment-Image in unserem OS-Katalog, sodass ein frischer Hypervisor auf Bare Metal gespielt und über sein Web-UI in unter einer Minute erreichbar ist — kein ISO zu mounten, kein Installer durchzuklicken, bevor Sie eine VM bauen können. Von dort gehört der Host ganz Ihnen: Voller Root-Zugriff bedeutet, dass Sie wählen, welches Repository Sie betreiben, wann Sie upgraden, ob Sie ein Abonnement kaufen und wie Sie Ihren Cluster aufbauen, ohne dass von unserer Seite etwas gesperrt ist.

Falls Sie den Host lieber selbst bauen möchten, können Sie das. Eine individuelle iPXE-Konfiguration lässt Sie Ihren eigenen Proxmox-Build oder eine gepinnte Version per Netboot auf das Metal starten, und Plug-and-Play-ISO-Mounting mit KVM-Konsolenzugriff ist stets als Rückfalloption vorhanden — mounten Sie den Proxmox-Installer, verfolgen Sie das Hochfahren über die Konsole und wählen Sie Ihr eigenes ZFS-Layout. In beiden Fällen sitzt der Netzwerkrand vor dem Hypervisor: Dauerhaft aktive, inline arbeitende DDoS-Mitigation in unserem Netzwerk mit über 2 Tbit/s filtert Angriffe, bevor sie Ihre Management-Ebene auf Port 8006 erreichen, und self-service Firewall-Regeln lassen Sie einschränken, wer sie erreichen kann.

Booten Sie Ihren eigenen Proxmox-Build mit individuellem iPXE

Sie sind nicht auf unser Standard-Image beschränkt. Individuelle iPXE-Konfigurationen lassen Sie einen von Ihnen kontrollierten Proxmox-Build oder Installer direkt auf die Hardware chain-booten, sodass der Host genau so hochkommt, wie Sie es spezifiziert haben, statt aus einem Template, das Sie nicht gewählt haben.

Das ist der Weg für Teams, die eine bestimmte Proxmox-und-Kernel-Kombination über eine Flotte pinnen oder die Post-Install-Schritte — Repository-Auswahl, Speicher-Layout, Cluster-Beitritt — in eine einzige reproduzierbare Boot-Definition falten. Wir übergeben Ihnen das Metal und halten uns aus der Boot-Kette heraus.