Migration ESXi zu Proxmox

Inhaltsverzeichnis

Meine Liebe zu Linux begann mit der Anschaffung der Erstausgabe des Raspberry Pi. Er lehrte mich die Kommandozeile, Basics im Umgang mit Linux und wesentliche Konzepte um Software selber und selbstbestimmt zu hosten. Der kleine Pi kam leistungstechnisch schnell an seine Grenzen und skalierte keineswegs mit meinen Anforderungen. Hinzu kam ein beträchtlich-frustrierender Verschleiß an korrupten SD-Karten. Es musste etwas mächtigeres und zuverlässigeres her und so kaufte ich mir im Jahr 2020 einen Intel NUC10I7FNH, stopfte eine 2TB SSD für Virtuelle Maschinen hinein und eine weitere 250GB NVME für den Hypervisor ESXi aus dem Hause vmware.

Ein geschätzter Mensch zeigte mir damals die ersten Schritte im Umgang mit dem Hypervisor, Virtualisierung, Docker und Basics wie das Betreiben eines Reverse Proxys. Wissen, für das ich bis heute dankbar bin, da es digitale Autonomie ermöglicht und den Menschen aus der selbstverschuldeten digitalen Unmündigkeit befreit.

Mein Fundus an selbstgehosteten Diensten wuchs über die letzten Jahre an:

Home Assistant automatisierte mein Heim.
Firefly III trackte meine Finanzen.
FreshRSS versorgte mich mit zentral mit Nachrichten.
VaultWarden syncte meine Passwörter.
Pi-hole filterte Werbung im Heimnetz und übernahm DHCP und DNS.
Nginx Proxy Manager fungierte als Reverse Proxy.
Apprise für Push-Benachrichtigungen.
Windows 10 für Backups mit Veeam Backup & Replications
…

Der NUC und ESXi liefen rock solid. Neu gestartet wurde das System im Mittel alle sechs Monate, wenn ein neues ESXi Update zwingend eingespielt werden musste. Gleichzeitig stellte sich mit den Jahren auch eine Gewisse Angst vor dem Tag X ein, an dem das System versagen würde. Schlafen konnte ich zwar ruhig, weil ich nächtliche Backups mit Veeam Backup & Replication fuhr, aber trotzdem blieb immer ein wenig Unbehagen in mir vorhanden.

Nach zwei Jahren Dauerbetrieb des Systems fing der Lüfter des NUC hörbar an lauter zu werden und nicht mehr rund zu laufen. ein Jahr darauf kamen Knack-, Kratz- und Klöderlaute hinzu, die den Beginn eines Schadens der Lüfterlagerung andeuteten. Das Geräusch verflog wenn man liebevoll, aber mit Nachdruck, auf den NUC schlug. Da Tag X spürbar näher rückte, nahm ich ein wenig Geld in die Hand und kaufte das passiv gekühlte Gehäuse Akasa Turing FX, ohne nervigen Lüfter.

Der NUC schaffte noch weitere drei Jahre bis ich kürzlich von einem grässlichen Lärm eines halb-blockierten Lüfters wach wurde und das System sich automatisch wegen Überhitzung herunterfuhr. Der Tag X war gekommen und das Innenleben des NUCs wurde spontan entkernt und in das neue Akasa gehäuse verfrachtet. ESXi bootete problemlos wieder durch und ich genoss einen Moment, der ähnlich zur Anschaffung meines ersten MacBook Air ohne Lüfter war. Die Stille des neuen passiv-gekühlten Gehäuses, ohne klödernden Lüfter, war eine Freude für dir Ohren. Meine Freude sollte leider nur eine kurze Weile andauern…

Zwei Tage später traten sonderbare Phänomene im Heimnetzwerk auf. Neue Geräte konnten sich nicht mehr verbinden, alte Geräte nur sporadisch. Webseiten luden nicht mehr. Grund war meine VM auf der Pi-hole lief. Diese zeigte schwerwiegende Fehler im Dateisystem, die weder ein fsck, noch ein Reboot beheben konnte. Nach und nach traten diese Fehler in allen VMs auf. Die SSD hatte den letzten Shutdown vor dem Umzug ins neue Gehäuse scheinbar nicht verkraftet und verabschiedete sich nach fast sechs Jahren Dauerbetrieb.

Das Timing des Versagens hätte nicht besser sein können, um eine neue 2TB SSD zu kaufen. 535€ und eine Lieferzeit aus der Hölle… schönen Dank auch, schöne neue AI-Welt!

Gute vier Wochen lief der NUC nicht. Meine Veeam Backups ließen sich aber erfolgreich temporär in vmware Workstation auf meinem Desktop PC auslesen. Der wichtigste Teil war somit gelöst und die Daten intakt, aber in der Welt der Hypervisor ist viel in den letzten Jahren geschehen. vmware wurde von Broadcom gekauft und stellte die kostenfreie Version von ESXi aus dem Nichts ein. Auch sonst machte Broadcom, nach der Übernahme, wenig gute Schlagzeilen, die Vertrauen für die Zukunft erweckten:

Es gab nur eine Lösung für das Dilemma: Wenn der NUC eh gerade in die Knie gegangen ist, die SSD ausgetauscht werden musste und ein neues flüsterleises Gehäuse bereitsteht, dann muss jetzt auch Proxmox her, um langfristig weitermachen zu können. Der Umzug auf den Open-Source Hypervisor war lange überfällig und der Zeitpunkt war unbestreitbar da.

Proxmox Installation

Die Installation von Proxmox lief reibungslos und dauerte nur wenige Minuten. Das System bootete anstandslos, ließ sich konfigurieren und fuhr sich selbstständig nach einem halben Tag wegen Überhitzung herunter… WTF. So hatte ich mir das nicht vorgestellt. Der NUC erzeugte so viel Hitze, dass es das passiv-gekühlte Gehäuse von Akasa scheinbar nicht abtransportieren konnte. Ein Blick in mein Home Assistant und die serverseitig vorgeschaltete Steckdose zeigt eine Leistung jenseits der 40W an. ESXi lief im Mittel immer mit 14W:

Wie so oft im Leben gilt: RTFM - Read the fu**ing manual. Akasa, der Hersteller des neuen Gehäuses, empfiehlt die Limitierung der CPU-Leistung im BIOS auf einen Grenzwert von 25 Watt. Gesagt, Getan! Der NUC lief nun im mittel mit knapp 30 Watt. Immer noch viel zu viel im Vergleich zu ESXi. Das System schaffte zwei Tage Dauerbetrieb und schaltete sich dann erneut wegen zu hoher Temperaturen ab…

Scheinbar war ich nicht der Einzige mit diesem Problem. Insbesondere auf Reddit waren diverse Beiträge von Leuten zu finden, die ebenfalls Hitzeprobleme mit dem Gehäuse hatten:

Abhilfe schaffte der Post PSA How to configure Proxmox for lower power usage im Home Assistant Forum. Dieser Beitrag schildert ausführlich, dass Proxmox per default eine CPU-Setting besitzt, die auf Performance ausgelegt ist. Alternativ steht aber auch eine Modus namens powersafe zur Verfügung, der mittels folgenden Kommandos gesetzt werden kann und bis zum nächsten Reboot persistent vorhanden ist:

 echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Dieses Kommando wirkte unmittelbar Wunder und die Leistung des NUCs reduzierte sich im Mittel auf bekannte Werte von 14-15 Watt:

Stromverbrauch nach CPU Govenor Konfiguration

Um dieses Setting persistent nach jedem Neustart des NUCs zu setzen, bedurfte es eines Cronjobs, der mittels crontab -e gesetzt werden muss:

@reboot  echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Danach lief mein NUC stabil und es traten keine automatischen Shutdowns aufgrund von Hitze auf. Der Stromverbrauch reduzierte sich sogar noch etwas nachdem das System einige Stunden lief:

Was aber immer nach ca. drei Tagen Betrieb auftrat, war ein sonderbares Verhalten, dass der NUC nicht mehr im Netzwerk erreichbar war…

Verbindungsabbrüche

Wenn ich mich mit meiner JetKVM aufschaltete lief alles auf dem NUC unverdächtig. Alle VMs rannten und ich konnte mit in dem Login Screen von Proxmox ganz normal anmelden. Eine IP wurde auch erfolgreich zugewiesen. Ein Ping war aber nicht von der Proxmox-Konsole möglich. Nichts ging über die Leitung. Wenn man das LAN-Kabel abzog und wieder ansteckte, war wieder alles OK - aber auch wieder nur für maximal drei Tage. Zuerst hatte ich den Intel e1000e NIC im NUC im Verdacht, der bekannt war für Probleme und für den auch ein Community Script bereitstand, um ein offloading der Network Interface Card zu verhindern. Also schnell das Script über die Proxmox Shell installieren und erneut observieren. Das Offloading des NICs schien aber nicht die Ursache der Nicht-Erreichbarkeit gewesen zu sein. Das Problem blieb bestehen. Nach einigen Tagen der Ratlosigkeit fand ich die Lösung in diesem Thread: Proxmox verliert ständig Netzwerkverbindung (Ethernet)

Schuld war eine Funktion meiner Fritz!Box namens Energy Efficient Ethernet. Schaltete man diese Funktion für den LAN-Port an dem der NUC hing aus, war das Problem behoben:

FritzBox Einstellungen für Energy Efficient Ethernet

Matrix Notification

Um stets im Bilde zu sein, was auf dem Host geschieht, habe ich Matrix als Notifier in Proxmox eingerichtet. Dafür muss im ersten Schritt ein Bot-User auf dem Matrix Server seiner Wahl eingerichtet werden, der die Nachrichten verschicken soll. Anschließend wird ein Raum auf dem Matrix Server erstellt und der Account in diesen eingeladen. Für den Bot muss nun der access_token ausgelesen werden. Im Zweiten Schritt muss die Room ID des Chats ermittelt werden. Dies kann in der Element App in den erweiterten Einstellungen des Raums erfolgen:

Abschließend kann in Proxmox ein Webhook Notifier eingerichtet werden, der diese Werte nutzt um Statusmeldungen in den Chatraum zu pushen:

Der Webhook muss mit folgenden Werten eingerichtet werden:


Type	POST
URL	`https://SERVER/_matrix/client/v3/rooms/{{ secrets.room_id }}/send/m.room.message?access_token={{ secrets.token }}`
Header	`Content-Type` / `application/json`

Der Access Token und die Room ID können als Secrets angelegt werden und stehen anschließend über die Syntax {{ secrets.<name> }} zur Verfügung. Final muss der eigentliche Message Body definiert werden. Wer nur den Title einer Notification erhalten möchte kann folgendes Eintragen:

{
  "msgtype": "m.text",
  "body": "{{ title }}"
}

Wer den Titel und den vollen Benachrichtigungstext erhalten möchte kann diese Zeilen nutzen:

{
  "msgtype": "m.text",
  "body": "{{ escape severity }}: {{ title }}\n\n{{ text }}{{ escape message }}"
}

Der Notifier kann nach Anlage über den Button Test getestet werden.

Eine Meldung trat bei mir nach kürzester Zeit auf und war erneut Grund zur Verwunderung:

Die fast sechs Jahre alte NVME meldet einen SMART Error aufgrund zu hoher Temperaturen. Gleichzeitig teilt sie in der Meldung gar keine Temperatur mit… Prüft man die Temperatur mittels smartctl -a /dev/nvme0 erhält man einen Wert von 32°C:

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning:                   0x00
Temperature:                        32 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    2%
...

Dieser Wert ist komplett normal und völlig im Rahmen. Was ist hier schon wieder los?

NVME Firmware Updaten

Es stellte sich herraus, dass meine Samsung 980 NVME vor Jahren mit der Firmware 1B4QFXO7 ausgeliefert wurde. Diese Firmware Version liefert random falsche Temperaturwerte:

Samsung stellt einer neuere Firmware 3B4QFXO7 für die SSD auf ihrer Homepage zum Download bereit. Ebenfalls gibt es eine Software von Samsung zum Flashen der Firmware namens Samsung Magician, die für Windows, macOS und Android bereitgestellt wird. Nicht jedoch für Linux… Die Firmware aus Proxmox zu updaten erfordert, daher einen gewissen Aufwand:

Glücklicherweise gibt es ein kleines Skript namens Linux Samsung NVMe Firmware ISO Extractor, das diese Schritte vereinfacht. Also los! Firmware ISO heruntergeladen, Script ausführbar gemacht und angeworfen. Das Skript läuft fehlerfrei und ohne Datenverlust durch.

Ein Reboot und ein schneller Check der Firmware mit nvme list ergab: Nichts hat sich getan. Die Firmware ist nach wie vor die veraltete Version 1B4QFXO7.

Stellt sich heraus: Das Samsung Tool zum Updaten der Firmware fumagician benötigt als Abhängikeit zwingend das Paket unzip, um die Firmware zu flashen. Dokumentiert scheint das nirgendwo zu sein. Gleichzeitig prüft das Tool nicht, ob diese Abhängigkeit vorhanden ist.

Weiter im Gefecht! Das Paket unzip installieren mittels…

apt install unzip

… und anschließend das Skript Linux Samsung NVMe Firmware ISO Extractor erneut ausführen. Nun sind die fehlerhaften SMART-Meldungen nicht länger vorhanden und die Firmware der NVME wurde korrekt auf die Version 3B4QFXO7 aktualisiert. Danke für Nichts, Samsung!

Backups

Im alten Setup hatte ich eine Windows 10 VM auf der Veeam Backup & Replications lief. Das feine an Proxmox ist, dass es einen zusätzlichen Proxmox Backup Server (PBS) gibt und ich dadurch nicht mehr auf Veeam angewiesen bin und zeitgleich auch keine Windows 10 VM mehr benötige. Der Backup Server lässt sich entweder als LXC-Container oder als eigenständige VM installieren. Ich habe letzteren Weg gewählt und einfach eine HDD an den NUC angeschlossen und an die PBS durchgereicht. Kein ideales Setup, aber ein Off-Site Backup wird in naher Zukunft noch folgen. Der PBS ließ sich ebenfalls ohne Aufwand konfigurieren und in Proxmox einbinden. Ein Backup Job und ein weiterer Verfy Job war schnell und reibungslos angelegt.

Auch die PBS stellt eine Funktion für Notifications bereit, in der analog ebenfalls Matrix für Notifications genutzt werden kann:

Fazit

Die Migration war in Teilen ein Pfad kleiner Rätsel, aber am Ende halb so schlimm und lehrreich. Ich bin mit meinem Setup zufrieden, das nun nicht länger von proprietären Lösungen wie ESXi oder Veeam Backup & Replication abhängig ist. Proxmox und der PBS sind Open Source Software und geben mir für die Zukunft ein ruhigeres gewissen.

Im Unglück finden wir meistens die Ruhe wieder, die uns durch die Furcht vor dem Unglück geraubt wurde.

— Marie von Ebner-Eschenbach

Zeitgleich konnte ich während des Umzugs und der Downtime des Systems in mich gehen und hinterfragen, welche Dienste ich eigentlich wirklich effektiv nutze. Ich habe bspw. meine Firefly III VM gar nicht erst wieder aufgesetzt und das akribische Tracking meiner Finanzen eingestellt. Manche Dienste erzeugen Routinen, die am Ende keinen spürbaren Mehrwert generieren und manchmal gilt weniger ist mehr. Auch habe ich Pi-hole nicht wieder in Betrieb genommen, da Ad-Blocking mittlerweile nicht mehr so effektiv ist wie vor sechs Jahren, als ich das System ins Leben rief. Mit dem Ausfall des NUC fiel zeitgleich auch Pi-hole als DHCP- und DNS-Server in meinem Heimnetz aus und das war keine Freude. Passenderweise bekommt die Fritz!Box mit dem Update 8.40 nativ eine Funktion um Blocklisten auf DNS-Ebene einzubinden. Ich bin gespannt, ob dieses Feature Pi-hole dann grundsätzlich obsolete macht.