Warum wir ein eigenes Panel für Proxmox gebaut haben
Mehrere Proxmox-Hosts bedeuten mehrere Logins, eine sperrige API und viel Handarbeit. Wie daraus NexoVirt wurde.
Proxmox VE ist ein solides Stück Software. Es macht genau das, wofür es gebaut wurde: Virtualisierung auf einem Host oder in einem Cluster. Sobald aber mehrere Cluster im Spiel sind, wird der Alltag mühsam.
Das Problem beginnt beim zweiten Host
Beim ersten Host merkt man nichts. Beim zweiten öffnet man einen zweiten Tab. Beim vierten hat man eine Lesezeichenleiste voller Weboberflächen, vier Sitzungen, die unterschiedlich schnell ablaufen, und keine gemeinsame Sicht auf Auslastung, Backups oder freie Adressen.
Dazu kommt die API. Sie ist vollständig, aber sie ist nicht angenehm. Wer Bereitstellung automatisieren will, schreibt am Ende eine eigene Zwischenschicht. Genau diese Zwischenschicht hatten wir irgendwann dreimal in unterschiedlicher Qualität herumliegen.
Was wir stattdessen wollten
Die Anforderungen waren kurz:
- Eine Oberfläche für alle Hosts, unabhängig vom Cluster
- Eine API, die man an einem Nachmittag versteht
- Kunden dürfen ihre eigenen Server sehen, aber nur ihre eigenen
- Pläne, Kontingente und Ablauf sollen automatisch durchgesetzt werden
- Kein Eingriff in die bestehende Proxmox-Installation
Der letzte Punkt war der wichtigste. Ein Panel, das eine Neuinstallation verlangt, ist im laufenden Betrieb wertlos.
Wie es heute läuft
NexoVirt verbindet sich über SSH mit einem schlanken Agenten und liest den Zustand der Nodes aus. Die Oberfläche zeigt Gäste, Speicher, Netze und Backups über alle Cluster hinweg. Alle Aktionen laufen asynchron, damit die Oberfläche nicht blockiert, während im Hintergrund ein Klon läuft.
Die REST-API deckt den kompletten Lebenszyklus ab. Wer möchte, betreibt das Panel nur als Ansicht und steuert alles über Automatisierung.
Was daraus geworden ist, steht im Detail auf der Projektseite.