Neues YouTube-Video: Visualisierung im Devices-Adapter

[MartinP]

Gefühlt alle paar Tage ein neues Kernel nebst Reboot des PVE natürlich
Alle paar Tage wieder mehrere Dutzend Updates über die Kommandozeile ...

Ist das alles der KI geschuldet, die hier richtig die Build - Pipelines zum Glühen bringt?

upgrading:
  gnutls-bin          libgnutls30t64           libpve-network-perl  lxc-pve           proxmox-kernel-6.17  proxmox-widget-toolkit  pve-ha-manager  pve-manager          qemu-server
  libgnutls-dane0t64  libpve-network-api-perl  libpve-rs-perl       proxmox-firewall  proxmox-kernel-7.0   pve-container           pve-i18n        pve-yew-mobile-i18n  rsync

Installing dependencies:
  proxmox-kernel-6.17.13-11-pve-signed  proxmox-kernel-7.0.2-6-pve-signed

[MartinP]

Kiste kommt gerade wieder hoch ... iobroker ist schon wieder gestartet, aber noch etwas langsam

[Meister Mopper]

@MartinP

Schau hier, dann weißte was abgeht.

https://bugzilla.proxmox.com/

[mading]

KIs Plan, die Welt zu erobern…Schritt 0.0001. 😂

[BananaJoe]

@MartinP dann mache es doch wie ich: 2 x Proxmox Hosts, installiert mit ZFS-Dateisystem und Replication der VMs.
Da patche ich den ersten Host, starte neu, schiebe alle VMs auf diesen Hosts und patche dann den anderen. Ohne Downtime der VMs.

Kosten: Halt noch mal den gleichen Host (CPUs sollten aus der gleichen Generation sein oder du musst etwas Kompatibles als CPU bei der VM einstellen).
Nachteil: Geht halt nur mit VMs, nicht mit Containern. Container werden gestoppt und wieder gestartet beim Verschieben.

[MartinP]

Die Downtime ist ja nicht das Schlimmste, das Daumendrücken, dass alles wieder sauber hochkommt ist schlimmer.
Und zum Teil die Unwägbarkeiten, was alles noch kleine Anstöße braucht, um wieder zu funktionieren.
Zu den VMs: Haben die keinen Zugriff auf spezielle Hardware? USB sticks für Zigbee oder HMIP etc? Muss da keine Hardware von einem zum anderen Server umziehen?

[Homoran]

@MartinP sagte:

USB sticks für Zigbee

Nimmt man dann per LAN

@MartinP sagte:

HMIP

Dito oder ccu, oder HAP

[peterfido]

Man ist doch nicht gezwungen, da jedes Update gleich aufzuspielen. Ich mache das, wenn es zeitlich passt oder Probleme gibt.

[Thomas Braun]

@peterfido

Es gibt aber auch Sicherheitsupdates die man nicht aufschieben sollte. Die aktuellen Kernel-Updates gehören dazu.
Immer zeitnah einspielen.

[da_Woody]

@MartinP welche downtime? Während dem Update? Kenne ich nicht. Erst wenn ein reboot notwendig ist dauert es 2-4 Minuten bis alle meine 3 VM und 1 lxc wieder online sind. OK, bis alle Instanzen wieder gestartet sind dauert es noch eine Zeit.
Hab aber noch nicht erlebt, daß irgendwas nachher nicht funktioniert hat.
Mag vllt daran liegen, weil ich nicht jede Menge verschiedene Systeme am laufen habe. Shelly und ein paar Tasmota...

[MartinP]

Mein Celeron N3000 spielt in der Liga eines Pi4 und hat nur eine SATA SSD. Da dauert alles etwas länger
Die reine Downtime war auch kürzer.
Erstes Posting erfolgte, als die Anzeigen während des Updates auf einen notwendigen Reboot hinwiesen.
Danach hat der Update-Prozess noch viel Zeit mit Grub Konfigurationen usw gedauert. Downtime vielleicht 5...8 Minuten.

Erst kommt PVE nebst Weboberfläche hoch, danach kann man den Lxc Containern beim Grün werden zuschauen.

Ich habe zwar einen weiteren gebrauchten Mini-PC in der Schublade, aber auf das Aufsetzen eines Hochverfügbarkeitssystems werde ich wohl verzichten.

LXC Container sind etwas schmalfüßiger, deshalb will ich ungerne auf VM wechseln. Mehr als 8 GB RAM passen nicht in die Mini-Systeme.

[Samson71]

@MartinP sagte:
Mehr als 8 GB RAM passen nicht in die Mini-Systeme.

Hat mit dem Thread nichts zu tun, aber eine solche Aussage kann man so pauschal nicht stehen lassen. Das kommt ganz klar auf das "Mini-System", bzw. dessen Definition an.
Ein Lenovo ThinkCentre Tiny z.B. läuft ebenfalls unter Mini-PC und kann problemlos 32GB mit einer M.2 SSD und kann sogar mit einer 2.5GbE LAN-Schnittstelle aufgerüstet werden.

[MartinP]

Ich meinte speziell meine beiden System

Gigabyte GB BACE3000 (Kaufpreis damals 69€) schluckt EINEN SODIMM DDR3 Riegel. Mehr als 8 GB habe ich damals nicht gefunden. Es gibt aber wohl 16 GB Module

In den Futro S920 mit AMD GX Prozessor (Kaufpreis 29 €) gehen wohl zwei DDR3 Riegel. Da wären dann wohl 16 bzw 32 GB möglich, wenn Prozessor oder Bios nicht streiken...

[MartinP]

@Homoran sagte:

Dito oder ccu, oder HAP

Ich habe OpenCCU in einer VM auf dem Proxmox System, dazu den USB-Stick Bausatz von ELV

Läuft inzwischen sehr unauffällig...

Wenn sich die Preise für Hardware wieder einigermaßen normalisiert haben, kann ich ggfs über eine "Reform" nachdenken ...

Vielleicht alles, was USB braucht auf dem alten System lassen, ohne Redundanz, und für den Rest über zwei neue Mini-PCs nachdenken... Proxmox Backup-Server steht auch noch auf der Todo-Liste ...

[da_Woody]

@MartinP sagte:

Erst kommt PVE nebst Weboberfläche hoch, danach kann man den Lxc Containern beim Grün werden zuschauen.

was erwartest du? reboot, pling, alles ist online?
logisch, PVE muss mal starten, erst dann werden alle anderen gestartet. vorher müssen ja auch alle anderen runtergefahren werden und neu gestartet.

@MartinP sagte:

Danach hat der Update-Prozess noch viel Zeit mit Grub Konfigurationen usw gedauert.

deutet für mich darauf hin, daß du nicht regelmässig updates macht...
mal schon auf den ultimate updater gelinst?
https://github.com/BassT23/Proxmox

[MartinP]

Habe mal autoremove nachgeschoben.

Gammelten noch 8...10 Kernels rum. Irgendwie hat sich der Update mit all den alten Kernels länglich beschäftigt, um sie in Grub einzutragen....

[Meister Mopper]

@MartinP sagte:

Proxmox Backup-Server steht auch noch auf der Todo-Liste ...

Den kann ich nur empfehlen. Der läuft bei mir auf einem schlanken LXC und macht seit Jahren einen sehr guten Job in/von Richtung eines Synology-NAS.

Spoiler

[Meister Mopper]

@da_Woody sagte:

deutet für mich darauf hin, daß du nicht regelmässig updates macht...
mal schon auf den ultimate updater gelinst?
https://github.com/BassT23/Proxmox

Ich sehe die Automatismen bei Updates/Upgrades kritisch, weil man nicht mehr Herr des Systems ist.

Ich habe schon oft erlebt, dass Upgrades kurze Zeit später korrigiert werden mussten. Da schaue ich mir die Upgrades lieber vorher an und entscheide, ob sie für mein System relevant sind. Bei Fehlern muss ich mit größerem Zeitaufwand ein Backup zurückspielen.

Bei Docker-Containern ist das was anderes. Da nutze ich Tugtainer und wenn es nicht läuft, schmeiße ich den Container weg, lade den alten und "gut is".

[Thomas Braun]

@Meister-Mopper sagte:

ob sie für mein System relevant sind.

Das setzt aber ein enormes Wissen über a) das eigene System und b) über die Natur des per Update adressierten Problems voraus. Das würde ich mir z. B. nicht zutrauen, weswegen hier zunächst Updates eingespielt werden.

Bei Fehlern muss ich mit größerem Zeitaufwand ein Backup zurückspielen.

Oder die Vorversion installieren. Oder die Auffälligkeit in einem BugTracker hinterlegen.

[Meister Mopper]

@Thomas-Braun

Deine Hilfe bietest du immer über das gesamte Wissenssprektum der User an, ich bedanke mich ausdrücklich dafür und deine unerreichte Ausdauer!

Ich wollte hier nur die Gefährlichkeit verdeutlichen, Skripte aus GitHub zu installieren ohne zu wissen, was diese tun und bewirken.