2 Commits (c3c05ff9f8cad433405fc4ea62c66b4d486027df)

Author	SHA1	Message	Date
nexxo	665a0c4e08	Release v1.3.91 — die Host-Seite zeigt Last statt Ausstattung ... Die Karte "Rechenleistung" zeigte keine Leistung. 12 Kerne und 63 GB sind die Ausstattung des Blechs und ändern sich nie — sie standen aber im selben Kartenraster wie "Zustand" und "Speicher", die beide leben. Wer die Seite öffnete, um zu sehen, wie es dem Host geht, las dort eine Zahl, die das nie sagen konnte. An ihrer Stelle steht jetzt die Last: CPU und RAM als Stundenkurve, beide in Prozent auf EINER Achse, dazu die aktuellen Werte als beschriftete Zahlen. Die Geschichte kommt aus Proxmox' eigener Aufzeichnung (/nodes/{node}/rrddata), nicht aus einem eigenen Sampler. Ein Sampler hieße neue Tabelle, minütlicher Job, Aufräum-Job und ~1440 Zeilen je Host und Tag — um weniger genau nachzubauen, was ohnehin auf der Platte liegt. Die RRD ist ab der ersten Sekunde gefüllt, auch für die Stunde vor dem ersten Hinsehen, und kann nicht von dem abweichen, was Proxmox' eigene Oberfläche zeigt. Eine Lücke bleibt eine Lücke: ein Punkt ohne Messwert wird null, nie 0, und spanGaps steht auf false. Dieselbe Regel wie in instance_metrics. Antwortet der Host gar nicht, sagt die Tafel das in einem Satz, statt eine ruhige Stunde zu zeichnen — auf dem Testhost live bestätigt. Der Fehler, den das ans Licht gebracht hat ------------------------------------------ x-ui.chart steht überall unter wire:ignore, sonst zerstört Livewire das Canvas. Ein Poll erreicht den Chart also nie. Dafür bekam das Bauteil ein optionales update-on: es hört auf ein Fenster-Ereignis und tauscht die Daten IM bestehenden Chart.js-Objekt. Das lief nicht. Die Zahlen neben der Kurve wanderten, die Kurve nicht, und chart.update() starb still im Legenden-Plugin: TypeError: Cannot set properties of undefined (setting 'fullSize') Grund: die Chart.js-Instanz lag als Eigenschaft im Alpine-Objekt und wurde damit reaktiv umhüllt. Chart.js' Plugin-Innenleben überlebt das Proxy nicht. Gemessen statt geschlossen: dieselbe Instanz wirft über das Proxy und läuft über Alpine.raw(). Sie liegt jetzt in der Closure. Aufgefallen ist es nie, weil bis zum ersten Live-Chart kein einziger Chart in diesem Repo je update() gerufen hat — konstruieren und Erstzeichnen gehen durch die Hülle noch. tests/Feature/ChartLiveUpdateTest.php hält die Regel fest, damit der nächste Live-Chart nicht denselben Nachmittag kostet. Der Rest -------- - Version lesbar: "Proxmox VE 9.2.6" statt pve-manager/9.2.6/7f8d…, mitten in der Bau-Kennung abgeschnitten. Die Kennung steht klein darunter. Eine unerwartete Form wird unverändert durchgereicht statt verschluckt. - Vier Kleinkarten (Mgmt-IP, Node, Version, Instanzen) sind eine Ausstattungs-Tafel geworden. Die Instanzen-Anzahl steht in der Überschrift der Liste, die sie ohnehin zeigt. - Der Übernahme-Fortschritt klappt zu, sobald sie durch ist. Fünfzehn abgehakte Schritte sind auf einem laufenden Host kein Dauerinhalt — aufklappbar über <details>, ohne JavaScript. - PlanVersion::requiredTemplateVmids() ersetzt die dritte Kopie derselben Fensterlogik. - BuildVmTemplate sagt nicht mehr "this takes 10–20 minutes". Das war eine Schätzung vor dem ersten Lauf; gemessen waren es unter zwei. Eine Konsole, die falsch vorhersagt, erzieht dazu, sie zu ignorieren. Geprüft: 2281 Tests grün, Pint sauber, Codex ohne Befund. Die Farbwahl gegen den Validator gerechnet (ΔE 28,3 protan / 39,2 normal; der Akzent liegt unter 3:1 gegen die Fläche, deshalb tragen beide Reihen sichtbare Beschriftung). Im Browser: null Konsolenfehler über einen vollen Poll-Zyklus, und die Kurve wandert auf dem echten Poll ohne Neuladen — mit eingespielten Messwerten belegt, weil die Testhosts in TEST-NET liegen und nie antworten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 10:24:21 +02:00
nexxo	db125781ed	Release v1.3.88 — die Vorlage baut sich selbst ... Der letzte Handgriff in der Host-Übernahme fällt weg. VerifyVmTemplate meldete bisher nur, dass eine Vorlage fehlt, weil niemand entschieden hatte, was in die goldene Vorlage gehört. Entschieden ist es längst und steht in deploy/bootstrap/lib/template.sh — der neue Schritt BuildVmTemplate lädt genau diese Datei auf den Host und führt sie dort aus, statt ihre Prüfungen ein zweites Mal in PHP zu haben. Er läuft abgekoppelt und wird abgefragt: Abbild laden und drei virt-customize-Läufe brauchen zehn bis zwanzig Minuten, ein einzelner SSH-Aufruf liefe gegen den Befehlszeitablauf von 2000 s. "Läuft noch" heißt dabei, dass der Prozess lebt (kill -0 gegen die hinterlegte PID) — in der Statusdatei steht "running" auch dann noch, wenn niemand mehr da ist, der sie ändert. Fünf Fehler, die dabei aufgefallen sind und Geld gekostet hätten: - qm importdisk hängte die Platte unter ${storage}:vm-9000-disk-0 ein. Der Name gilt nur bei Block-Ablagen; auf einer Verzeichnis-Ablage heißt sie local:9000/vm-9000-disk-0.qcow2 — also genau auf dem per Debian aufgesetzten Proxmox, um das es hier geht. Jetzt qm set --import-from, und Proxmox benennt selbst. - growpart war nie installiert. GrowGuestFilesystem ruft es auf, und es lief bisher, weil Debians Cloud-Abbild es zufällig mitbringt. Fiele es heraus, läge jedes gekaufte Kontingent über einem Dateisystem, das nie gewachsen ist. Jetzt ausdrücklich eingebaut und als vierte Falle nachgewiesen. - local nimmt ab Werk keine Platten an. Ohne das stirbt nicht nur der Bau, RegisterCapacity meldet danach Kapazität 0: ein Host, der fertig aussieht und nie einen Kunden tragen kann. ensure_image_storage greift nur ein, wenn keine Ablage Platten annimmt, hängt images an die vorhandene Liste an statt sie zu ersetzen, und schreibt über pvesm set statt in die pmxcfs-Datei. - Ein abgebrochener Download blieb unter dem Zielnamen liegen und wäre beim nächsten Lauf ungeprüft weiterbenutzt worden. Jetzt .part, umbenannt erst nach geprüfter Summe. - VerifyVmTemplate und VmTemplateCheck fragten nur, ob VMID 9000 existiert. Ein abgebrochener Bau hinterlässt eine gewöhnliche VM mit dieser Nummer, und beide sagten dazu "passt" — der Fehler kam beim ersten bezahlten Klon zurück. Jetzt template: 1. isTemplate() stellt zwei Anfragen, weil die falsche Antwort hier etwas zerstört: false heißt "Vorlage fehlt", und der Bau fängt mit qm destroy --purge an. Proxmox beantwortet die Konfiguration einer nicht vorhandenen VM mit 500 — demselben Code wie einen Knoten in Not. Die VM-Liste klärt deshalb die Abwesenheit, alles darunter wirft und landet im Wiederholungs-Zweig. Aufgeben beendet erst die Prozessgruppe, dann räumt es auf, und gebaut wird nur die Fehlliste: create_proxmox_template räumt eine VMID weg, bevor es sie anlegt, also hätte "alles Verlangte" eine gesunde zweite Vorlage auf dem Weg zerstört. Geprüft: 2267 Tests grün, Pint sauber, sh -n über alle drei Shell-Dateien, die storage.cfg-Auswertung gegen eine echte Beispieldatei durchgespielt, und jeder Befehl, den der Schritt absetzt, geht durch sh -n — keine andere Prüfung führt diese Shell je aus. Drei Codex-Runden (R15), alle Befunde behoben. Nicht geprüft: nichts davon lief je gegen echte Hardware. Die erste Übernahme auf einem Proxmox-Host ist die Abnahme. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 05:01:44 +02:00