Proxmox verstehen#

Auf die beiden Server im Homelab soll Proxmox. Dabei interessiert mich auch, was hinter dem Installer steckt: Wenn das auf Debian basiert, wo hoert Debian auf und wo faengt Proxmox an? Und koennte ich selbst etwas in dieser Richtung bauen?

Ja: Eine kleine eigene Debian-Variante ist ein erreichbares Lernprojekt. Um zu verstehen, welche Arbeit darueber hinaus in Proxmox steckt, hilft ein Blick auf die einzelnen Teile.

Was Proxmox VE ist#

Gemeint ist Proxmox Virtual Environment, kurz PVE: eine auf Debian basierende Plattform fuer virtuelle Maschinen und Linux-Container. Sie wird normalerweise direkt auf dem Server installiert. Der physische Rechner heisst Host oder Node, die darauf laufenden virtuellen Systeme sind seine Gaeste. Die Verwaltung erfolgt unter anderem ueber eine Weboberflaeche. Proxmox verbindet dafuer bestehende Virtualisierungstechnik mit eigener Verwaltungssoftware. Proxmox: Funktionsuebersicht

Die Versionsnummern gehoeren zu unterschiedlichen Projekten: Proxmox VE 9 basiert auf Debian 13 „Trixie“. Proxmox liefert einen eigenen, angepassten Linux-Kernel mit. Das ist weiterhin Linux; die Proxmox-Entwickler waehlen und pflegen eine fuer ihre Plattform passende Variante. Proxmox VE 9.0: technische Basis

Virtuelle Maschine und Container#

Eine virtuelle Maschine bekommt virtuelle Hardware: Prozessoren, Arbeitsspeicher, Festplatten und Netzwerkkarten. Darauf startet ein eigenes Betriebssystem mit eigenem Kernel. QEMU stellt die virtuelle Maschine bereit; KVM im Linux-Kernel nutzt die Virtualisierungsfunktionen der CPU zur Beschleunigung. Der Gast sieht beispielsweise ein DVD-Laufwerk, obwohl dahinter nur eine ISO-Datei liegt. QEMU: Systememulation und Beschleuniger, Proxmox: QEMU/KVM

Ein LXC-Container teilt sich dagegen den Kernel mit dem Host. Linux grenzt seine Prozesse und deren Sicht auf das System ab; sogenannte cgroups regeln den Zugriff auf Ressourcen. Der Container hat seine eigenen Programme und Systemdateien, bootet aber keinen eigenen Kernel. Proxmox: Container und Isolation

Der konkrete Aufbau eines unprivilegierten Containers mit Docker steht unter LXC-Container verstehen. Dort ist auch der LXC dokumentiert, in dem Coolify installiert ist.

Fuer das Experiment mit einer eigenen Distribution ist deshalb eine VM passend: Dort laesst sich auch der Bootvorgang des eigenen Images ausprobieren.

Wie die Verwaltung aufgebaut ist#

Die Weboberflaeche fuehrt die Gaeste nicht selbst aus. Dahinter arbeiten Dienste mit unterschiedlichen Aufgaben:

pveproxy reicht privilegierte Auftraege an den lokalen pvedaemon weiter. pmxcfs speichert Konfigurationen, etwa die Einstellungen einer VM; deren virtuelle Festplatte ist davon getrennt. API-Zugang, API-Dienst, Konfigurationsdateisystem

Ein Klick auf „VM starten“ laesst sich vereinfacht so verfolgen:

1. Der Browser schickt einen authentifizierten API-Auftrag an den Host.
2. Die Verwaltung prueft die Berechtigung und liest die VM-Konfiguration.
3. Sie startet QEMU mit den vorgesehenen Ressourcen, Laufwerken und Netzwerkanschluessen.
4. Der Gast bootet sein eigenes Betriebssystem mithilfe von QEMU und KVM.

Die Oberflaeche beschreibt und steuert also den Betrieb. Die eigentliche Ausfuehrung liegt bei den Virtualisierungskomponenten. Proxmox: API und Weboberflaeche, VM-Konfiguration und Ausfuehrung

Speicher, Netzwerk und mehrere Hosts#

Virtuelle Festplatten liegen in einem konfigurierten Storage. Je nach Backend sind das beispielsweise Image-Dateien in einem Verzeichnis oder logische Volumes. Proxmox bietet eine gemeinsame Verwaltung fuer diese unterschiedlichen Speicherarten; welche davon verwendet wird, bleibt eine Entscheidung beim Aufbau des Hosts. Proxmox: Storage Manager

Eine Linux-Bridge wie vmbr0 funktioniert wie ein virtueller Switch. An ihr koennen die virtuellen Netzwerkkarten der Gaeste und eine physische Netzwerkkarte des Hosts haengen. So gelangen die Gaeste ins Heimnetz. VLANs lassen sich dabei passend zum vorhandenen Netz-Layout zuordnen. Proxmox: Netzwerkaufbau

Mehrere Hosts lassen sich zu einem Cluster fuer die gemeinsame Verwaltung verbinden. Zwei frisch installierte Server bilden noch keinen Cluster. Fuer hochverfuegbare Gaeste kommen weitere Entscheidungen hinzu, etwa ueber Speicher und Quorum: die erforderliche Mehrheit der Stimmen im Cluster. Gemeinsame Verwaltung und automatische Wiederherstellung nach einem Host-Ausfall sind unterschiedliche Funktionen. Proxmox: Cluster Manager

Der inzwischen eingerichtete Cluster xlab mit pve01, pve02 und einer externen Quorum-Stimme auf dem DNS-Server ist unter Proxmox-Cluster mit zwei Nodes und QDevice dokumentiert.

Wie aus Debian Proxmox wird#

Der Kernel verwaltet unter anderem Prozessor, Speicher und Hardware. Eine Distribution stellt darum ein benutzbares System zusammen: Programme, Bibliotheken, Paketverwaltung, Voreinstellungen und einen Weg, alles zu installieren und zu aktualisieren. Debian leistet diese Arbeit bereits fuer eine grosse Auswahl an Software. Debian: Was ist Debian?

Eine darauf aufbauende Distribution kann grosse Teile uebernehmen und sich auf ihren eigenen Zweck konzentrieren. Debian bezeichnet solche eigenstaendigen Varianten als Derivate und unterstuetzt ausdruecklich, dass sie entstehen. Debian: Derivate

Bei Proxmox laesst sich das an drei Stellen nachvollziehen:

• Eigene Software: Im Repository pve-manager liegen unter anderem die Verwaltung, die Weboberflaeche, Dienstdefinitionen und unter debian/ die Dateien fuer die Debian-Paketierung. Aus Quellcode werden installierbare Pakete. Quellcode von pve-manager
• Eigene Paketquellen: Das installierte System bezieht Debian-Pakete und Proxmox-Pakete aus den jeweils passenden Repositories. APT kann so beide Teile aktualisieren. Proxmox: Paketquellen
• Ein gemeinsamer Installer: Das Installationsmedium richtet daraus ein System fuer den vorgesehenen Einsatzzweck ein. Es bringt unter anderem Debian, den Proxmox-Kernel und die Verwaltungswerkzeuge zusammen. Proxmox: Installation

Die Entwicklungsarbeit umfasst damit die Verbindung und Pflege dieser Teile: Eine neue Version muss mit bestehenden Konfigurationen umgehen, Updates muessen zusammenpassen, und Fehler muessen sich nachvollziehen lassen. Ein eigenes Logo auf einer ISO waere nur ein kleiner Teil davon.

Was eine eigene kleine Distribution bedeuten kann#

Fuer ein persoenliches Projekt wuerde ich den Umfang stufenweise vergroessern:

Schon die erste Stufe kann fuer das Homelab reichen. Fuer ein eigenes bootfaehiges System ist die zweite ein ueberschaubarer Einstieg. Debian liefert mit live-build das Werkzeug, um ein Image aus einer beschriebenen Konfiguration zusammenzustellen. Debian Live: Werkzeuge und Grundlagen

Wer stattdessen lernen moechte, wie Compiler, Bibliotheken und Grundsystem aus Quellcode zusammengebaut werden, kann Linux From Scratch durcharbeiten. Das ist ein anderer Lernweg; fuer eine persoenliche Debian-Variante muss man diesen Unterbau nicht selbst bauen. Linux From Scratch

Erstes Lernprojekt: ein eigenes Debian-Live-Image#

Als Beispiel soll eine kleine Konsole mit curl, htop und tmux entstehen. Dazu kommt eine eigene Textdatei, an der sich das Image erkennen laesst. Die folgende Anleitung ist fuer eine separate Debian-13-VM auf amd64 mit Internetzugang und eingerichtetem sudo gedacht. Der Build braucht mehrere GB freien Speicherplatz. Auf dem Proxmox-Host selbst ist dafuer keine Installation noetig.

Das Werkzeug und die Konfiguration#

live-build wird in der Build-VM aus Debian installiert. Debian Live: Installation

sudo apt update
sudo apt install live-build

mkdir xlab-live
cd xlab-live

lb config --distribution trixie --architectures amd64 --binary-images iso-hybrid --debian-installer none

Das legt config/ an. Der Codename trixie haelt die gewaehlte Debian-Version fest; iso-hybrid bestimmt das Ausgabeformat. Mit --debian-installer none wird explizit ein Live-System ohne Installer gebaut. lb_config fuer Debian 13

Eigene Pakete und Dateien#

mkdir -p config/package-lists config/includes.chroot/etc

printf '%s\n' curl htop tmux > config/package-lists/xlab.list.chroot
printf '%s\n' 'xlab-live: mein erstes Debian-Image' > config/includes.chroot/etc/xlab-release

sudo lb build

Die Datei mit der Endung .list.chroot bestimmt die zusaetzlichen Pakete. config/includes.chroot/ entspricht dem spaeteren Wurzelverzeichnis: Aus der eigenen Datei wird im Live-System /etc/xlab-release. Paketauswahl, Eigene Dateien

Was beim Bauen passiert#

Das Werkzeug baut ein Debian-Grundsystem in einem Arbeitsverzeichnis auf; dafuer dient debootstrap. Dazu kommen die ausgewaehlten Pakete und Dateien. Fuer das Booten werden Kernel, ein fruehes Startsystem namens initramfs und ein Bootloader eingebunden. Beim Start findet live-boot das enthaltene Root-Dateisystem und macht es mit einer beschreibbaren Zusatzschicht nutzbar. live-config richtet anschliessend unter anderem den Live-Benutzer ein. debootstrap, Debian Live: Zusammenspiel der Werkzeuge

Das Ergebnis ausprobieren#

Nach erfolgreichem Build liegt live-image-amd64.hybrid.iso im Arbeitsverzeichnis. Die ISO laesst sich als virtuelles DVD-Laufwerk an eine neue Test-VM haengen und dort booten. Debian Live: Bauen und Testen

In der gebooteten Test-VM:

cat /etc/xlab-release
command -v curl htop tmux

Das ist ein eigenes zusammengestelltes Debian-Live-System. Aenderungen waehrend der Sitzung gehen ohne gesondert eingerichtete Persistenz beim Neustart verloren. Fuer die Installation auf Festplatte waere ein weiterer Schritt mit einem Installer noetig. Debian Live: Persistenz, Debian Live: Installer

Was danach zur eigenen Distribution fehlt#

Als naechstes wuerde ich die Build-Konfiguration in Git ablegen und den Bau aus einer frischen VM wiederholen. So ist festgehalten, wie das Image entsteht. Bytegleiche Builds verlangen zusaetzlich Kontrolle ueber Paketversionen und Build-Umgebung; ein Codename allein friert die enthaltenen Pakete nicht ein.

Eigene Programme und dauerhafte Systemanpassungen koennen spaeter in .deb-Pakete wandern. Mit eigenen Paketquellen lassen sie sich auch auf bereits installierten Systemen verteilen. Fuer ein veroeffentlichtes Derivat gehoeren ausserdem getestete Updates, Sicherheitsupdates und klar benannte Zustaendigkeiten dazu. Debian: Leitlinien fuer Derivate

Fuer mein Homelab waere das erste konkrete Ziel eine ISO, die in einer Proxmox-VM startet und genau die ausgewaehlten Werkzeuge enthaelt. Eine eigene Verwaltungsoberflaeche fuer virtuelle Maschinen waere danach ein separates Softwareprojekt — auf derselben Grundlage, aber mit deutlich mehr eigener Entwicklung.