Proxmox Virtual Environment Upgrade von Version 8 auf 9, Debian 13

news

news

Renowned Member
Sep 14, 2022
1,431
477
93
Germany
Heute auch mal ein vollständig positiver Bericht über meine Upgrades, System, LXC und VM waren am Start.

Grundlage ist ein Test PC auf Basis von vorhandener Hardware:
  • Mainboard: ASRock B450M PRO4 R2.0
  • CPU: AMD Ryzen 5 2600 @3,9 GHz
  • CPU-Kühler: Xilence A404T; be quiet! Pure Wings 2 92 mm PWM
  • DDR4 Ram: G.Skill 16GB DDR4-3200 Kit, CL16,18,18,36 (F4-3200C16D-16GVKB Ripjaws V)
  • 1x NVME: Crucial CT500P3SSD8, PCIe 3.0x4
  • 2x SSD: ADATA SU800 Ultimate 512 GB
  • 1x NIC: TP-Link TG-3468 PCIe, 1 Gbit/s
Die Basisinstallation war ein Debian 12, das noch um die ZFS Umgebung erweitert wurde und anschließend wurde noch das Proxmox VE 8.xy installiert.

* Das Root und Boot-System ist auf der NVMe, Debian + Proxmox VE, die als ext4 formatiert wurde.
* Der ZFS Pool dpool ist auf den beiden SSD als VDEV ZFS Mirror eingerichtet. no comments please . its a test system .

Bei meinen Setup werden auf je einem ZFS Dataset das Root Verzeichnis /root und das /etc Verzeichnis alle 15 Minuten gespiegelt und dort laufen auch noch zfs auto-snapshot alle 15 Minuten.

Die ersten Schritte heute waren ein vollständiges Systemupdate nach 1): Step 2, 3 und 4.
1) https://linuxconfig.org/how-to-upgrade-debian-to-latest-version

Danach ging es weiter mit 2) und:
  • Continuously use the pve8to9 checklist script
  • Update Debian Base Repositories to Trixie
  • Add the Proxmox VE 9 Package Repository, noch etwas Handarbeit bei den APT Configfiles war notwendig.
  • run apt update
2) https://pve.proxmox.com/wiki/Upgrade_from_8_to_9

Danach habe ich den Pfad etwas verlassen und wieder 1) verwendet.
Siehe ab "Debian 13 Upgrade Process"
  • Step 1: apt upgrade --without-new-pkgs
  • Step 2: apt dist-upgrade -y und apt full-upgrade -y
Weiter geht's mit "Post-Upgrade Verification"
  • Step 1
  • Step 2: apt autoremove -y und apt autoclean -y
  • Step 3: apt update und apt list --upgradable
  • Step 4: systemctl reboot # und neustart
Das installieren der Updates dauert seine Zeit; und bei der mehrstufigen installation und System-Säuberung, verlief der Prozess problemlos.

Die Netzwerkschnittstellen-Bezeichnungen bleiben erhalten und das System booted ohne Änderung der selben.

Danach wurden die vohandenen LXC von Debian 12 auf Debian 13 nach Anleitung 1) gebracht.
Und selbiges auch für eine Debian 12 VM -> Debian 13 VM.
 
Last edited:
Dazu mal eine andere Erfahrung:
  • Ergebnisse von pve8to9 abgearbeitet, bis nur noch eine Meldung bzgl. laufender VMs übrig war
  • Upgrade durchgeführt.
  • Host platt. Der Rechner erkennt nichts bootbares und landet nur noch im BIOS.
  • Langes Gesicht!
Dank IP-KVM und Bootstick neu mit 8.4 aufgesetzt
  • danach eine frische 8.4.9 Installation auf 9.0.3 durchgeführt.
  • Kiste startet wieder.
  • Alle zurückgespielten VMs sind sofort am Start.
Fazit: ohne IP-KVM kann man auch mal am Arsch sein. Vor allem, wenn die Zielkiste 3.000km entfernt steht.

P.S.:
Auf den ersten Blick sind viele Nickligkeiten in der neuen Version beseitigt. Dafür Hut ab. Der Zuverlässigkeit sehe ich positiv entgegen, kann es logischerweise noch nicht beurteilen.
Vielleicht ist ja sogar das Intelnetzwerkkartendilemma Geschichte.
 
Last edited:
Biernot said:
Wie hast du die Reposetories angepasst ?
Click to expand...
Guten Morgen, ja da hast du Recht das habe ich nicht im Detail beschrieben , es gibt aber ein Hinweis darauf im Text. Das ist natürlich so gelaufen, wie unter 2) dargestellt wurde.
 
Noch ein Hinweis: Wer mit PCI Passthrough (dazu noch eine Nvidia vom Hypervisor an eine VM durchreicht) läuft Gefahr, dass diese VM nach dem Upgrade nicht mehr startet. Mit Proxmox 9 ist auch eine neue Version von qemu auf dem System aktiv. War es vorher qemu v9 ist es nun v10! Damit geht auch eine neue efidisk einher.
Hier die grobe Vorgehensweise:
  1. VM stoppen
  2. Alte efidisk in $VM.conf löschen
  3. Neue efidisk unter einem anderen Namen anlegen
  4. VM starten und checken, ob alles läuft
  5. Wenn ja, alte efidisk im ZFS Pool löschen
  6. Neue efidisk in alte efidisk umbenennen
  7. Namen der efidisk in $VM.conf wieder anpassen
  8. Sofort Backup der VM im STOPP Modus anlegen...und evtl. Snapshots vergessen.
  9. Alte Snapshot Backups löschen...und, wenn nötig, mit frischen / neuen Snapshots anfangen
 
eMTB said:
Noch ein Hinweis: Wer mit PCI Passthrough (dazu noch eine Nvidia vom Hypervisor an eine VM durchreicht) läuft Gefahr, dass diese VM nach dem Upgrade nicht mehr startet. Mit Proxmox 9 ist auch eine neue Version von qemu auf dem System aktiv. War es vorher qemu v9 ist es nun v10! Damit geht auch eine neue efidisk einher.
Hier die grobe Vorgehensweise:
  1. VM stoppen
  2. Alte efidisk in $VM.conf löschen
  3. Neue efidisk unter einem anderen Namen anlegen
  4. VM starten und checken, ob alles läuft
  5. Wenn ja, alte efidisk im ZFS Pool löschen
  6. Neue efidisk in alte efidisk umbenennen
  7. Namen der efidisk in $VM.conf wieder anpassen
  8. Sofort Backup der VM im STOPP Modus anlegen...und evtl. Snapshots vergessen.
  9. Alte Snapshot Backups löschen...und, wenn nötig, mit frischen / neuen Snapshots anfangen
Click to expand...
Warum hüserst du mit der EFI-disk rum?






I
 
In bestimmten VM Setups ist das wohl erforderlich. Ich habe bestimmte HW per PCI Passthrough anders nicht durchreichen können. Kann ja auch vom Mainboard / dem BIOS abhängen...
 
eMTB said:
In bestimmten VM Setups ist das wohl erforderlich. Ich habe bestimmte HW per PCI Passthrough anders nicht durchreichen können. Kann ja auch vom Mainboard / dem BIOS abhängen...
Click to expand...
Ja für PCI Passthru brauchst du EFI, aber so viel Aufwand musst du nicht betreiben. Wenn das eine zu Proxmox migrierte VM ist, kannst du auch auf die EFI Disk verzichten und die VM bootet. Sonst kannst du jederzeit auch eine neue EFI Disk generieren, wenn du z.B. die neuesten Server2025 Updates installierst, erwartet der neuere Zertifikate und dann macht man mal eben eine neue EFI Disk und löscht die alte. Da steht nix besonderes drin.
 
  • Like
Reactions: Johannes S
Ich bin mir nicht sicher, ob ich dich richtig verstanden habe. Ich habe unter Proxmox v8 mehrere VMs angelegt, an die ich PCI Decvices durchreiche. Hier musste ich efidisks verwenden. Nach dem Upgrade auf v9 (und dem damit verbundenen Upgrade auf qemu v10) waren die alten efidisks nicht mehr brauchbar. Also habe ich, so wie du u.a. erwähnt hast, die alten efidisks gelöscht und neue angelegt. Jetzt ist alles wieder schicki.

Was meinst du mit "neueste Server2025 Updates"? Ich würde davon ausgehen, dass ich die mit Proxmox v9 installiert habe...???
 
Du hast die neueste PVE Version.
Ich habe in meiner Testumgebung aber den Effekt gehabt, wo ich ein aktuelles Server2025 Image benutzt habe zum installieren, die VM aber vor dem PVE9 Upgrade erstellt wurde.
Die VM wollte nicht booten, erst nachdem die EFI Disk neu erzeugt wurde mit PVE9.
 
  • Like
Reactions: Johannes S
Yepp! Das passt dann wohl zu meiner Situatin. Anyways...ist ja nun gelöst. Allerdings wären ein paar offensichtlichere Logs eine schöne Sache. Ich habe jedenfalls keine Infos finden können, die besagen: "Hey! Deine efidisk ist zu alt und muss aktualisiert werden."

Frohe Weihnachten.
:)
 
eMTB said:
Yepp! Das passt dann wohl zu meiner Situatin. Anyways...ist ja nun gelöst. Allerdings wären ein paar offensichtlichere Logs eine schöne Sache. Ich habe jedenfalls keine Infos finden können, die besagen: "Hey! Deine efidisk ist zu alt und muss aktualisiert werden."

Frohe Weihnachten.
:)
Click to expand...
Da das eine Windows-Krankheit ist, kann man das schwer im Hypervisor erkennen.
 
  • Like
Reactions: Johannes S
Nope! Hier ist nach dem Upgrade eine VM mit Linux als OS nicht mehr gestartet. Erst nachdem ich die efidisk neu angelegt hatte, ließ sich diese VM starten.
...und ja: Du hast Recht! Man kann das schwer am Hypervsior erkennen. Genau das war mein Punkt! Es wäre toll, wenn der Hypervisor den Startvorgang "irgendwie" loggen könnte. Das ist nun nicht als Vorwurf an irgendwen gedacht.
Man kann das ja auch "umdrehen" und sagen: Hey, der Hypervisor stellt eine virtualisierte HW zur Verfügung! Wie soll er da den Startvorgang eines autarken OS, welches sich dieser HW bedient, loggen?

Vielleicht fällt ja irgendwem noch ein Dreh' ein, wie man da etwas mehr Transparenz in den Vorgang bekommt.
Ich versuche, das Mal aus meiner laienhaften Sicht aufzudröseln.
  • Wenn erstmal der Bootloader der VM ge-triggered ist, hat man ja noch eine Chance etwas in der Konsole zu sehen.
  • Wenn jedoch die efidisk (quasi als NVRAM) so früh im Spiel ist, dass das OS im Zweifelsfall erst gar nicht hoch kommt, bräuchte es auf Seiten des Hypervisors irgendetwas, was da eine Plausiprüfung oder Versionsprüfung z.B. einer efidisk durchführt. M.E. müsste es möglich sein, die Versionsunterschiede von efidisks festzustellen und nach dem Upgrade einen entsprechenden Check anzustoßen, ggf. sogar mit einem Script zur Migration der efidisk und einem Hinweis, dass die VM nach der Migration 1x im Stopp-Modus gesichert werden sollte, da essenzielle Bestandteile der VM geändert wurden.
 
eMTB said:
Man kann das ja auch "umdrehen" und sagen: Hey, der Hypervisor stellt eine virtualisierte HW zur Verfügung! Wie soll er da den Startvorgang eines autarken OS, welches sich dieser HW bedient, loggen?
Click to expand...
Und genau so ist es auch. Bei einem physischen PC bekommst sowas auch nicht gelogged. Da bleibt nur die Console übrig.
Der einzige, der das loggen könnte, wäre einen mangement chip bsp. intel me, broadcom was auch immer, nur sagt dir der dann auch, das das OS nicht gestattet werden konnte.

Das 2025er zertifikat von MS für die efi disk kann man auf der PVE Console für die VM updaten, da gibt es einen Befehl. Habe den aber nicht im kopf, da ich das auf der console gelesen und ausprobiert hatte. Steht aber bestimmt auch im WIKI oder Handbuch.
 
Last edited:
  • Like
Reactions: Johannes S
You must log in or register to reply here.
Top Bottom