Proxmox VE – Virtualisierungslösung

1. Grundlegende Infos

Proxmox VE (Virtual Environment) ist eine Open-Source-Virtualisierungsplattform, die KVM-basierte virtuelle Maschinen (VMs) und Linux-Container (LXC) integriert. Es bietet eine webbasierte Oberfläche zur Verwaltung und ist ideal für On-Premise- oder On-Cloud-Infrastrukturen. Die Architektur basiert auf Debian Linux, ergänzt durch zusätzliche Pakete, die Virtualisierung, Hochverfügbarkeit (HA), Speicher- und Netzwerkmanagement vereinen.

Die Hauptkomponenten von Proxmox VE sind:

  • Proxmox VE Kernel: Ein angepasster Linux-Kernel mit KVM-Unterstützung.
  • QEMU/KVM: Für voll virtualisierte Maschinen.
  • LXC: Für containerbasierte Virtualisierung (leichtgewichtige Container).
  • Cluster-Management: WAN- oder LAN-Cluster mit verteiltem Speicher.
  • Storage-Integration: Unterstützung für lokal angeschlossene Laufwerke, SAN (iSCSI, Fibre Channel), NAS (NFS, SMB) und verteilte Systeme wie Ceph.
  • Backup und Restore: Integriertes CLI-Tool, ergänzt durch den Proxmox Backup Server (PBS).
  • Netzwerkmanagement: Bridge-, VLAN-, Bonding- und SDN-Funktionen.

Proxmox VE wird kontinuierlich weiterentwickelt, bietet regelmäßige Updates und hat eine aktive Community. Der Enterprise-Repository-Zugriff ist kostenpflichtig, doch es existiert ein kostenfreier Repository für reguläre Updates.

2. Installation und Grundlagen

2.1 Systemanforderungen

Für eine Proxmox-VE-Installation empfehlen sich mindestens:

  • CPU: 64-Bit-Prozessor mit AMD-V oder Intel VT-Unterstützung.
  • RAM: Mindestens 4 GB, besser ab 8 GB für VMs und Container.
  • Storage: SSDs oder NVMe-SSDs für schnellen I/O. RAID 1/10 für Hochverfügbarkeit.
  • Netzwerk: Mindestens eine dedizierte Netzwerkkarte (1 GbE oder mehr). Bessere Performance mit 10 GbE für verteilte Storage- und Netzwerkfunktionalitäten.

2.2 Schritt-für-Schritt-Installation

  1. ISO herunterladen: Besuchen Sie proxmox.com und laden Sie die neueste Proxmox-VE-ISO.
  2. Bootmedium erstellen: Schreiben Sie die ISO auf einen USB-Stick (z. B. mit Etcher oder Rufus).
  3. Installation starten: Booten Sie vom USB-Stick, wählen Sie “Install Proxmox VE” im Bootmenü.
  4. Partitionierung & Dateisystem: Wählen Sie ein Laufwerk aus und konfigurieren Sie LVM-Thin für flexible Speicherzuteilung.
  5. Verwaltungsnetzwerk: Geben Sie Hostname, IP-Adresse, Gateway und DNS-Server ein.
  6. Initiale Benutzeranmeldung: Nach Abschluss der Installation erreichen Sie die Weboberfläche unter https://<IP-Adresse>:8006 und melden sich mit dem Benutzer root und dem bei der Installation vergebenen Passwort an.
  7. Lizenz-Repository: Standardmäßig wird das öffentliche NO-SUBSCRIPTION-Repository genutzt. Für produktive Umgebungen empfiehlt sich ein Enterprise-Abonnement.

2.3 Erste Schritte in der Web-GUI

Die Weboberfläche gliedert sich in einen Navigationsteil links (Datacenter, Node, Storage, Netzwerk, Firewall) und einen Inhaltsbereich rechts. Wichtige Menüpunkte:

  • Datacenter: Cluster-Verwaltung, Benutzerverwaltung, Zugriffsrechte (ACLs), Storage-Pools.
  • Node: Systemressourcen, Dienste, Protokolle, Hardwareinformationen.
  • Storage: Anzeige und Konfiguration von Speicherpools (LVM, ZFS, Ceph, NFS, CIFS).
  • Network: Bridges, Bonds, VLAN, SDN (abversion 6.x).
  • Firewall: Proxmox-VE-Firewall, pro-VM/Container-Regeln, Audit-Log.
  • Backup: Lokale und externe Backup-Jobs konfigurieren, PBS-Integration.

3. Konfiguration: Netzwerk

Proxmox VE nutzt Debian-Standardkonfigurationen in /etc/network/interfaces. Netzwerk-Interfaces sind durch Bridges verbunden, die VMs und Container anbindet. Eine typische Konfiguration könnte folgendermaßen aussehen:

# /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eth0
    bridge-stp off
    bridge-fd 0

eth0 wird in den Bridge-Modus vmbr0 eingebunden. Alle VMs/Container können so über vmbr0 in das physische Netzwerk.

3.1 VLANs auf Bridges

VLANs nutzt man, um Netzwerke feiner zu segmentieren. Beispiel für getaggte VLANs:

auto vmbr1
iface vmbr1 inet manual
    bridge-ports eth1
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes

auto vmbr1.10
iface vmbr1.10 inet static
    address 192.168.10.10/24
    vlan-raw-device vmbr1

auto vmbr1.20
iface vmbr1.20 inet static
    address 192.168.20.10/24
    vlan-raw-device vmbr1

bridge-vlan-aware yes aktiviert VLAN-fähige Bridge. Subinterfaces vmbr1.10 und vmbr1.20 definieren VLANs 10 und 20.

3.2 Bonding (Link Aggregation)

Für erhöhte Bandbreite und Redundanz verbindet man mehrere physische Interfaces mittels Bonding:

auto bond0
iface bond0 inet manual
    slaves eth2 eth3
    bond-miimon 100
    bond-mode 802.3ad

auto vmbr2
iface vmbr2 inet static
    address 10.0.0.10/24
    gateway 10.0.0.1
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0

bond0 im LACP-Modus (802.3ad) verbindet eth2 und eth3. Darauf baut vmbr2 auf.

4. vSwitches

Proxmox verwendet Linux Bridges als vSwitches. Eine Bridge verbindet physische und virtuelle Interfaces und leitet Layer-2-Traffic weiter. Die gängigsten Brücken sind:

  • vmbr0: Standard-Bridge, oft für Verwaltung und öffentliche Netzwerke.
  • vmbr1, vmbr2: Zusätzliche Bridges für VM-Netzwerke, Storage oder Backups.

Eine vSwitch-Topologie kann mehrere Bridges umfassen, um verschiedene VLANs, Backup-Netzwerke oder Storage-Netzwerke zu segmentieren. Beispiel:

  • vmbr0: 192.168.1.0/24 (Management, Default).
  • vmbr1: 10.10.10.0/24 (VM-Produktions-Netzwerk).
  • vmbr2: 172.16.100.0/24 (Ceph-Cluster-Netzwerk).
  • vmbr3: 192.168.2.0/24 (Backup-Netzwerk).

Über die Web-GUI lassen sich Bridges unter Datacenter → Node → System → Network erstellen und konfigurieren. Änderungen an /etc/network/interfaces werden automatisch übernommen, sofern kein temporärer Konflikt besteht.

5. LXC Container

LXC (Linux Containers) sind leichtgewichtige Virtualisierungseinheiten, die den mechanischen Overhead virtueller Maschinen vermeiden. Container teilen sich den Host-Kernel, aber sind durch Namespaces und cgroups isoliert. Vorteile von LXC:

  • Geringer Ressourcenverbrauch im Vergleich zu KVM-VMs.
  • Schnelle Bereitstellung (wenige Sekunden bis Minuten).
  • Hohe Dichte: Mehr Container pro Host möglich.

5.1 Container-Templates

Proxmox stellt vorgefertigte Templates für diverse Distributionen bereit. So legen Sie ein neues LXC an:

  1. Template herunterladen: Unter Datacenter → Storage → local (pve) → Content → Templates ein LXC-Template (z. B. Debian, Ubuntu, CentOS) auswählen und herunterladen.
  2. Container erstellen: Create CT im Node-Kontext: ID, Hostname, Template, Root-Passwort, SSH-Keys konfigurieren.
  3. Ressourcen festlegen: CPU-Cores, RAM, Swap, Root-FS (LVM-Thin, ZFS, Directory), Netzwerk-Interface (Bridge, VLAN, IP).
  4. Netzwerk: Container bekommt ein virtuelles Interface (eth0) und wird an eine Bridge (z. B. vmbr0) gebunden. Wahlweise kann man ein /24 oder VLAN-IP-Bereich zuweisen.
  5. Sicherheitsprofile: Standardmäßig nutzt LXC unprivilegierte Container (unprivileged), was mehr Sicherheit bietet.
  6. Starten und Zugriff: Container starten und unter Console auf der Proxmox-Weboberfläche oder via pct enter auf die Shell zugreifen.

5.2 Netzwerk in LXC

Beispielkonfiguration in /etc/pve/lxc/.conf:

lxc.net.0.type = veth
lxc.net.0.link = vmbr0
lxc.net.0.flags = up
lxc.net.0.ipv4.address = 192.168.1.50/24
lxc.net.0.gateway = 192.168.1.1

➔ Der LXC-Container erhält eine statische IP-Adresse. Alternativ kann man auf dhcp stellen: lxc.net.0.ipv4.address = dhcp.

5.3 Ressourcenbegrenzung

LXC-Container können CPU- und RAM-Limits erhalten:

lxc.cgroup2.memory.max = 2048M
lxc.cgroup2.cpuset.cpus = 0-1

➔ Begrenzung auf 2 GB RAM und CPU-Cores 0 und 1. cgroup v2 wird in neueren Proxmox-Versionen standardmäßig genutzt.

6. Virtuelle Maschinen (VMs)

Proxmox VE verwendet QEMU/KVM zur Virtualisierung. VMs sind vollständig isoliert und nutzen einen eigenen virtuellen BIOS/UEFI. Schritte zum Erstellen einer VM:

  1. ISO-Upload: Unter Datacenter → Storage → local (pve) → Content → ISO Images die gewünschte ISO (z. B. Debian, Windows) hochladen.
  2. Create VM: ID, Name, ISO auswählen, BIOS/UEFI-Modus, OS-Typ definieren.
  3. System: CPU-Architektur (x86_64), Anzahl der Cores, Sockets, BIOS- oder OVMF-UEFI (für Secure Boot).
  4. Festplatte: Typ (IDE, SATA, SCSI, VirtIO), Storage auswählen (LVM-Thin, ZFS, Directory) und Größe festlegen.
  5. Netzwerk: Virtuelle Netzwerkkarte (e1000, VirtIO) an eine Bridge (vmbr0, vmbr1) binden. VLAN-Tagging optional.
  6. Starten und Betriebssystem installieren: VM starten, über VNC-Console auf Installer zugreifen, OS installieren.

6.1 VirtIO-Treiber und Performance

Für beste I/O-Leistung sollten VirtIO-Treiber verwendet werden:

  • Disk: VirtIO SCSI oder VirtIO Block.
  • Netzwerk: VirtIO (paravirtio) für geringere CPU-Belastung und höhere Durchsatzraten.
  • Windows-Gastsysteme: VirtIO-Treiber müssen während Installation eingebunden werden (z. B. über ISO von Fedora VirtIO).

6.2 Snapshots und Prüfpunkte

Proxmox erlaubt Snapshots von VMs:

  • Snapshots: Speichern den Zustand von Festplatte und RAM (wenn VM angehalten). Ideal vor größeren Updates.
  • Prüfpunkte (Checkpoints): Nur in bestimmten Storage-Typen (LVM-Thin, ZFS) verfügbar.
  • Rollback: Snapshot auswählen und Rollback durchführen, um VM in früheren Zustand zurückzusetzen.

7. Software-Defined Networking (SDN)

Ab Proxmox VE 6.0 gibt es experimentelle SDN-Funktionen. SDN ermöglicht zentrale Steuerung von Netzwerkkomponenten, separate Overlay-Netzwerke und automatisierte Policy-Regeln. Kernkomponenten:

  • Controller-Knoten: Überwacht Konfiguration, verteilt Updates an alle SDN-Knoten.
  • Open vSwitch (OVS): Ersetzt den Standard-Bridge-Switch bei SDN-Betrieb.
  • SDN-Router: Erzeugt virtuelle Router, die Funktionsweise als virtuelle L3-Switches haben.
  • SDN-Switch: VSwitches, die VLANs und VXLANs programmiert per Controller verwalten.
  • SDN-Gateways: Tor aus Overlay zu Underlay oder zum physischen Netzwerk.

SDN wird in Proxmox über das Menü Datacenter → SDN konfiguriert. Beispiele:

7.1 SDN-Bridge

# Beispiel: Erstelle eine SDN-Bridge im Controller
Name: sdn-br0
Type: bridge
Description: Overlay-Bridge für VMs

7.2 SDN-VLAN

# Beispiel: Erstelle ein SDN-VLAN-Objekt
Name: vlan100
VLAN-ID: 100
Parent: vmbr0
Description: Kundennetz

7.3 SDN-VXLAN

# Beispiel: Erstelle ein VXLAN-Tunnel
Name: vxlan200
VNI: 200
Bridge: vmbr1
Local IP: 10.0.0.10
Members: 10.0.0.11, 10.0.0.12

➔ VMs und Container können dann an diese SDN-Netzwerke angebunden werden, ohne separate Linux-Bridge-Konfiguration.

8. Ceph Storage

Ceph ist ein verteiltes, fehlertolerantes Storage-System, das objekt-, block- und dateibasierten Zugriff unterstützt. Es verteilt Daten selbstständig und repliziert sie auf mehrere Knoten. Proxmox VE integriert Ceph nahtlos:

  • RADOS (Reliable Autonomic Distributed Object Store): Basisschicht für Objektspeicherung.
  • Ceph OSD Daemon: Speichert und repliziert Daten auf Knoten.
  • Ceph Monitor (MON): Verwalten Cluster-Zustände und Metadaten.
  • Ceph Manager (MGR): Dient Statistiken, Metriken und Plugins für Monitoring.
  • Ceph MDS (Metadata Server): Für CephFS (Dateisystem), nicht zwingend für Block-Storage.

8.1 Ceph-Installation in Proxmox

  1. Vorbereitung: Mehrere Proxmox-Knoten mit dedizierten Festplatten oder SSDs für Ceph-OSDs.
  2. Ceph-Cluster erstellen: Datacenter → Ceph → Monitor wählen. Name und Initial-Monitor definieren.
  3. OSD hinzufügen: Datacenter → Ceph → OSD. Festplatte wählen und zu Ceph-OSD konvertieren.
  4. Pool anlegen: > Ceph → Pools → Create. Einstellungen: Namen, Replication-Level (z. B. 3 Kopien), CRUSH-Profile (z. B. „replicated_rule“).
  5. RBD Storage in Proxmox: Datacenter → Storage → Add → RBD. Pool-Namen, User, Keyring angeben.

➔ Anschließend stehen RBD-Images als VM-Festplatten zur Verfügung, inklusive Thin Provisioning, Snapshots und Klonen.

8.2 Netzwerküberlegungen für Ceph

Ceph empfiehlt dedizierte Netz im Cluster:

  • Public Network: Client-Datenverkehr (Beispiel: 10.0.0.0/24).
  • Cluster Network: Interne OSD-Replikation (Beispiel: 10.0.1.0/24), idealerweise separate NICs oder VLANs.

Beispiel in /etc/ceph/ceph.conf:

[global]
fsid = <UUID>
mon_initial_members = pve1,pve2,pve3
mon_host = 10.0.0.11,10.0.0.12,10.0.0.13
public_network = 10.0.0.0/24
cluster_network = 10.0.1.0/24
osd_journal_size = 1024

9. Storage und Replikation

Proxmox VE unterstützt diverse Storage-Typen:

  • Directory: Einfache Verzeichnisse auf ext4, xfs oder ähnlichen Dateisystemen.
  • LVM-Thin: Flexible Thin-Provisioning-Volumes, ideal für Container und VMs.
  • ZFS: Dateisystem und Volume-Manager, unterstützt Snapshots und Replikation.
  • Ceph RBD: Blockdevice für verteiltes Storage.
  • NFS/CIFS: Netzwerk-Dateisysteme, einfache NAS-Integration.

9.1 Lokaler vs. Netzwerk-Storage

Lokaler Storage (z. B. Direkt-SSD) eignet sich für Single-Node-Setups, erfordert Backup und Replizierung. Netzwerk-Storage (z. B. NFS, Ceph) ermöglicht zentrale Verwaltung und Hochverfügbarkeit über mehrere Nodes hinweg.

9.2 Replikation (ZFS & Ceph)

ZFS Replikation

ZFS bietet native Snapshot- und Replikationsfunktionen. Beispiel:

# Auf Quell-Node
zfs snapshot rpool/data/vm-100-disk-0@replica
zfs send rpool/data/vm-100-disk-0@replica | ssh root@backup-node "zfs receive backup/vm-100"

# Automatisiert via Proxmox:
# Datacenter → Storage → ZFS → Replication

➔ Regelmäßige Snapshots werden erzeugt und inkrementell übertragen. Beim Failover kann man die replizierten Daten als Laufwerk einbinden.

Ceph RBD Replikation

Ceph repliziert automatisch Objekte basierend auf dem gewählten Replication-Level (z. B. 3 Kopien). Keine manuelle Replikation nötig. Bei Ausfall eines OSD wird das Objekt neu verteilt, um replizierte Kopien wiederherzustellen.

9.3 Storage-Pools in Proxmox

Unter Datacenter → Storage → Add lassen sich Pools konfigurieren:

  • LVM-Thin: Bei lokalen Laufwerken oder SAN.
  • ZFS: Kann auf lokalen RAID-Sets oder SSD-Pools basieren.
  • Ceph RBD: Verteiltes Block-Storage über das Cluster.
  • NFS: Netzwerkfreigabe für ISO, Container-Templates, VM-Festplatten.
  • CIFS: SMB-Freigaben, ähnlich NFS.

Jeder Storage wird einer oder mehreren VM/Container-Ressourcen zugewiesen, mit YYYY als Priorität bei gleichzeitiger Nutzung mehrerer Storages.

10. Cluster

Ein Proxmox-Cluster verbindet mehrere Nodes zu einer einheitlichen Verwaltungsoberfläche. Vorteile:

  • Zentralisierte Verwaltung aller Nodes.
  • Verteiltes Storage (z. B. Ceph) kann über mehrere Nodes laufen.
  • Hochverfügbarkeits-VMs/Container (HA) mit automatischem Failover.
  • Live-Migration von VMs/Container zwischen Nodes.

10.1 Cluster erstellen

  1. Auf Node A: pvecm create clustername. Generiert Cluster-Konfiguration und Corosync-Stack.
  2. Auf Node B: pvecm add <IP von Node A>, Eingabe des Root-Passworts von Node A. Node B tritt dem Cluster bei.
  3. Weitere Nodes: Analog hinzufügen.
  4. Cluster-Status prüfen: pvecm status oder in der Web-GUI Datacenter → Cluster.

10.2 Quorum und Corosync

Corosync verwaltet Messaging und Quorum. Quorum (Abstimmungsmehrheit) ist nötig, damit Cluster-Operationen ausgeführt werden. Bei ungerader Node-Anzahl kann man Quorum-Geräte oder QDevices nutzen, um Split-Brain zu vermeiden.

10.3 Live-Migration

Virtuelle Maschinen und Container können ohne Downtime zu einem anderen Node verschoben werden, wenn Shared Storage (z. B. Ceph oder NFS) genutzt wird:

# In Web-GUI:
# NodeA → VM → Migrieren → NodeB

# CLI:
qm migrate 100 nodeB --online
pct migrate 101 nodeB --online

11. Backup-Möglichkeiten

Proxmox VE bietet mehrere Backup-Optionen:

  • Built-in Backup: Unter Datacenter → Backup lassen sich Jobs erstellen, die VMs oder Container in definierten Intervallen sichern. Backup-Modi:
    • Snapshot: Datenkonsistente Sicherung mittels Snapshots (ZFS, LVM-Thin, Ceph).
    • Stop: VM/Container wird gestoppt, Backup erstellt, dann wieder gestartet (bessere Konsistenz, aber Downtime).
    • Suspend: VM/Container wird angehalten, Backup ausgeführt, anschließend fortgesetzt.
  • Proxmox Backup Server (PBS): Ein dedizierter Backup-Server, optimiert für Inkrementelle Backups, Deduplizierung und Kompression. PBS kann mehrfach virtuelle Festplatten (RBD-Images, LXC-Container) sichern:
    • Inkrementelle Backups sparen Speicherplatz und Zeit.
    • Deduplizierung identischer Datenblöcke über alle Backups.
    • Verschlüsselung auf Client-Seite möglich.
    • Restaurierung im Granularitätslevel von Dateien (für Container mit PBS 1.0.x+).

11.1 Einrichtung eines Backup-Jobs (Built-in)

  1. Storage konfigurieren: Backup-Storage (Directory, NFS) unter Datacenter → Storage → Add → Directory/NFS.
  2. Backup-Job anlegen: Datacenter → Backup → Add. Wählen Sie:
    • Mode: Snapshots, Stop oder Suspend.
    • Selection: Alle VMs/Container oder nur bestimmte IDs.
    • Schedule: Cron-ähnliche Syntax (z. B. täglich um 3 Uhr: 0 3 * * *).
    • Retention: Anzahl der Backups, die behalten werden.
  3. Job speichern und aktivieren. Backup läuft automatisch nach Zeitplan.

11.2 Proxmox Backup Server (PBS) Integration

Der Proxmox Backup Server (PBS) ist eine separate Distribution, die dediziert für effizient komprimierte und deduplizierte Backups von Proxmox VE optimiert ist. So richtet man PBS ein:

  1. PBS installieren: ISO herunterladen, auf separatem Server installieren.
  2. Datastore anlegen: Unter Store → Datastore → Create. Speicherpfad und Retention-Richtlinien definieren.
  3. API-Key generieren: PBS-Benutzer mit pve-admin Rolle erstellen und API-Token generieren.
  4. Proxmox VE konfigurieren: Unter Datacenter → Storage → Add → PBS Host, Port, Datastore, API-Token eintragen.
  5. Backup-Job mit PBS: Datacenter → Backup → Add, als Storage PBS auswählen, Backup-Modus “Snapshot” und Inkrementell automatisch aktiviert.

➔ PBS speichert nur geänderte Blöcke, wodurch Backups sehr schnell und platzsparend sind. Durch Deduplizierung und Kompression bewahrt PBS Speicherkapazität.

11.3 Restore und Testen

Restaurierung erfolgt wahlweise per Web-GUI oder CLI:

  • Web-GUI: Backup → Datastore → Select Backup-Datei → Restore. VM/Container-ID wählen und Ziel-Node angeben.
  • CLI für PBS: proxmox-backup-client restore [snapshotID] [target path].

Regelmäßige Restore-Tests sind wichtig, um Datenintegrität und Disaster-Recovery zu gewährleisten.