Wie geht man bei Verwendung von vGPU vor, um bestimmte Komponenten nicht zu aktualisieren?

[Raudi]

Hallo,

nach dem ich nun die vGPU Umgebung mit den NVIDIA Treibern am laufen habe, stellt sich mir die Frage, wie verhindere ich das mir Updates die Umgebung zerstören?

In der Anleitung stehen ja nun die unterstützten Versionen: NVIDIA vGPU on Proxmox VE - Software Versions

Wie verhindere ich das hier z.B. eine Version 9.1.5 oder ein Kernel 6.17.5 installiert wird?

Ich habe nun erstmal das Proxmox Repository deaktiviert und lade zukünftig nur Debian Updates herunter. Aber gibt es da nicht noch eine optimalere Variante?

Ich habe gelesen, ich kann den entsprechenden Kernel anpinnen, so dass dieser immer geladen wird. Aber wenn dann schon neuere installiert wurden, dann werden aber doch auch die Abhängigkeiten zu dem neuen Kernel installiert, was ist, wenn da irgendwas mit einem älteren Kernel nicht mehr funktioniert?

Gleiches mit dem pve-manager, wie geht man hier vor? Was würde man machen, wenn eine zukünftige Version z.B. 9.1.5 erst auf der Supporteten Liste landet, wenn es schon eine 9.1.6 gibt. Wie würde ich hier verhindern, dass eine 9.1.6 installiert wird? Und wie wird gewährleistet, dass alle anderen Updates noch mit der Version 9.1.5 zusammenarbeiten?

Hier würde ich mir noch einen Abschnitt in der Anleitung wünschen, wo genauer auf dieses Thema eingegangen wird.

Viele Grüße
Stefan

 

[Johannes S]

Wie verhindere ich das hier z.B. eine Version 9.1.5 oder ein Kernel 6.17.5 installiert wird?

Am Besten gar nicht, weil jedes Update üblicherweise auch Securityfixes enthält. Laut der wikiseite arbeitet der nvidia-treiber mit dkms, dann sollte eigentlich bei einem Update auch das passende Modul neu gebaut werden.

Falls es mal nötig sei sollte, kann man normalerweise über das Bootmanager auf einen älteren Kernel starten und selbigen mit den proxmox-boot-tool pinnen.

Das bitte aber erst dann, wenn man ein Problem hat, im Zweifelsfall ist es besser den aktualisierten Kernel am Laufen zu haben.

Um das ganze System auf einen früheren Stand zurücksetzen zu können bietet sich neben einen ( eh sinnvollen ) Backup ein Snapshot an, mit zfs ist das relativ easy:
https://github.com/Corsinvest/cv4pve-autosnap
Gibt aber auch noch andere Skripte, die ähnliches leisten.

Prinzipiell geht das auch mit ovm, da darf man die Snapshots nicht zu lange aufbewahren, weil das sonst zuviel Platz und Performance kostet. Außerdem gibt es da keine Skripte mit vergleichbaren Funktionsumfang wie bei zfs. Bei zfs kostet es einen nur Speicherplatz, aber all zu lange sollte man die ja eh nicht aufbewahren

 

[Raudi]

Ja aber die vorherige NVIDIA Version (19.3) konnte noch nicht mit dem Kernel 6.17 (kompilieren schlug fehl), nur mit dem Kernel 6.14, der mit 9.0 ausgeliefert wurde, funktioniert das. Was wäre wenn ich alles unter 9.0 am laufen habe, dann ein Update auf 9.1 mache, dann würde doch sicherlich auch das dkms auf die Nase fallen, oder nicht? Und lt. Liste ist es ja auch nicht supportet. Der neue Kernel braucht eine neuere NVIDIA Version (19.4). Ich kann doch nicht einfach Versionen installieren die nicht supportet sind...

 

[Raudi]

Hui da ist ja noch was dazu gekommen, hatte mich schon gewundert, die erste Nachricht so so unfertig aus.

Aber mal ehrlich, wozu gibt es Listen die angeben welche Versionen Supportet sind? Wenn wir uns im Enterprise Umfeld bewegen, da macht man keine Experimente mit einfach neuere Version installieren und schauen was passiert. Sowas kann ich in meinem Homeoffice machen, aber nicht in produktiven Kundenumgebungen...

Stell dir vor ein Dienstleister installiert bei einem Kunden ein Update auf die aktuellste Version, in der Liste steht aber nur eine ältere Version. Danach funktioniert dann die vGPU Implementierung nicht mehr und er muss zurück, das kostet Zeit... Wer bezahlt dann den Aufwand? Als Kunde würde ich sagen, ich zahle nicht, weil da wollte jemand ein Update auf eine nicht supportete Version machen...

Ich möchte eigentlich nur gewährleisten, dass bei der Installation von Updates die Umgebung immer den supporteten Softwarestand hat.

Aber wenn das in Verbindung mit vGPU nicht möglich ist, dann ist diese Kombination vermutlich (noch) nichts für produktive Umgebungen.

 

[Johannes S]

Naja solche "Kompatibilitätslisten" nützen einen halt nichts, wenn eine kritische Sicherheitslücke in der "supporteten Version" drin ist. Nicht nur darum halte ich Enterprise-IT und deren üblichen Zinober (Kompatiblitätslisten etc) für albernes Theater

Oder wird es einen ein Kunde danken, wenn man über eine bekannte Sicherheitslücke geownt wurde aber dafür bis zum Angriff man keine Probleme durch den neuen Kernel hatte? Da habe ich doch so meine Zweifel.
Auf der von dir verlinkten Webseite steht übrigens auch:

It is recommended to use the latest stable and supported version of Proxmox VE and NVIDIA drivers. However, newer versions in one vGPU Software Branch should also work for the same or older kernel version.

Daraus kann man also auch schlußfolgern, dass für Support man immer auf den neuesten Stand sein sollte.

 

[Raudi]

Aber da steht es doch: "It is recommended to use the latest stable and supported version of Proxmox VE and NVIDIA drivers." Und was supportet ist, steht auf der verlinkten Seite im ersten Post.

Aber über der Liste steht: "The installation is supported on the following versions of Proxmox VE, Linux kernel, and NVIDIA drivers:"

Und auch klar, eine neuere vGPU Version wird mit dem gleichen oder einem älteren Kernel arbeiten.

Was bringt es einem Kunden eine Sicherheitslücke gestopft zu haben, aber alle Anwender können nicht mehr arbeiten weil die Terminal Server nicht mehr funktionieren. Für viele Sicherheitslücken gibt es auch einen Workaround und meistens müssen die Angreifer zum ausnutzen ja auch erstmal im lokalen Netz sein. Und wenn dem so ist, dann hat man schon ganz andere Probleme.

Wie gesagt, ich hatte versucht vor dem erscheinen der vGPU Version 19.4 die 19.3 auf PVE 9.1.4 mit Kernel 6.17 zu installieren, das funktionierte nicht, da kamen beim kompilieren etliche Fehler.

Aber wenn es eine Sicherheitslücke im Kernel gibt, dann wird es doch sicherlich erstmal eine Version aus dem selben Bereich geben, also ein 6.17.4-3, wenn der 6.17.4-2 ein Problem hat, das ist ja sicherlich auch nicht das Problem. Vielleicht ist ja auch 6.17.5 nicht das Problem, aber ein 6.18 bestimmt...

Egal wie wir hier diskutieren, es ist fakt, es gibt eine Liste von PVE, Kernel und vGPU Version was supportet ist. Meine Frage ist, wie soll man da gewährleisten, dass diese Versionen aktiv bleiben und nichts neueres installiert wird?

Ich würde mich freuen, wenn wir auf meine eigentliche Frage zurück kommen könnten. Da muss es doch eine Lösung geben...

 

[Johannes S]

Aber wenn es eine Sicherheitslücke im Kernel gibt, dann wird es doch sicherlich erstmal eine Version aus dem selben Bereich geben, also ein 6.17.4-3, wenn der 6.17.4-2 ein Problem hat, das ist ja sicherlich auch nicht das Problem. Vielleicht ist ja auch 6.17.5 nicht das Problem, aber ein 6.18 bestimmt...

Naja, auch dabei kann es dann ja sein, mit dem neuen Kernel etwas nicht mehr funktioniert, was es mit dem alten schon tat. Und ProxmoxVE hat ein rolling-release-Modell, wenn man also deine Befürchtung ernst nimmt, darf man dann tatsächlich nie updaten. Das halte ich für grob fahrlässig, auch und gerade im Unternehmenseinsatz

 

[Raudi]

So krass ist es ja auch nicht, es kommen ja auch immer neue vGPU Releases und die Support Matrix wird immer ergänzt. Aber wie beim Beispiel 9.0->9.1 mit Kernel 6.14 -> 6.17 musste man halt zuerst von vGPU 19.3 auf 19.4 updaten. Also man muss eine Reihenfolge einhalten.

Aber seit wann gab es die 9.1 mit Kernel 6.17? Die vGPU ist erst Mitte Januar erschienen, also man braucht hier schon eine eine gewisse Zeit wo man verhindern muss, dass neuere Kernel und PVE Versionen installiert werden...

Und vielleicht funktioniert ja der nächste Kernel auch mit der aktuellen vGPU Version, dass muss dann aber erst in der Support Matrix stehen, und bis dahin soll er halt verhindern, dass neue Versionen installiert werden.

Also in irgendeine Datei eintragen keine neuere Version als Kernel X und keine neuer Version als PVE Y. Dann ist man auf nummer Sicher. Wenn es dann neue Kernel gibt und die dann in der Matrix stehen, dann ändert man das und der Kernel wird wieder aktualisiert.

 

[fabian]

der vorherige kernel wird nicht automatisch deinstalliert, und du kannst beliebige installierte kernel versionen pinnen wenn ein DKSM modul mal noch nicht mit der neuesten series kompatibel ist:

https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#sysboot_kernel_pin

 

[Raudi]

Das hatte ich in meiner ersten Nachricht bereits geschrieben, aber da war dann ja die Frage, es werden ja auch alle Abhängigkeiten zum neuen Kernel installiert, ist es dann gewährleistet dass die neuen Komponenten die mit dem neuen Kernel kamen auch alle mit dem älteren Kernel zusammenarbeiten?

Vielleicht mache ich mir ja auch zu viele Gedanken, möchte nur Probleme verhindern...

Und in der Matrix steht ja auch die PVE Version, die muss ja auch eine ältere bleiben, also aktuell steht 9.1.4 auf der Matrix, demnach erstmal keine 9.1.5 installieren bis die Matrix aktualisiert wurde...

Vielleicht mache ich das auch zu kompliziert, aber wozu gibt es dann eine Support Matrix? Da muss es dann doch auch mittel und Wege geben diese einzuhalten.

 

[fabian]

der kernel hat (de facto) keine abhaengigkeiten..

 

[Raudi]

Kernel kann ich anpinnen, geht definitiv problemlos, okay, habe ich verstanden.

Und wie verhält es sich mit der PVE Version? In der Support Matrix stehen ja 3 Komponenten, neben Kernel und vGPU Version auch noch die PVE Version.

Steht die PVE Version da nur, weil der Entsprechende Kernel bei der PVE Version X kam? Also eher unwichtig, weil Kernel primär wichtig wegen dem Treiber? Oder ist die PVE Version auch wichtig und muss eingehalten werden?

 

[dcsapak]

nur um ein bisschen Klarheit zu schaffen (die Doku page kann man hier sicher noch verbessern!):
grundsätzlich sind die angegebenen Versionen miteinander kompatibel weil explizit getestet, bzw. beim expliziten durchtesten von neuen NVIDIA Treiber Versionen kamen diese Versionen zum Einsatz.

jetzt ist es aber so das unsere neueren Versionen (zB PVE manager 9.1.5 vs 9.1.4) eigentlich immer kompatibel sein müssen, das heist ein update nur von 9.1.4 auf 9.1.5 (ohne große kernel Änderung) sind kompatibel.

Probleme hier gibt es eigentlich nur wenn der kernel größere Änderungen hat (zB von 6.14 auf 6.17) und der NVIDIA Treiber noch nicht dafür vorbereitet ist (hier können wir, außer NVIDIA vorab feedback geben, meistens nicht viel machen)

Bugs kann es natürlich immer geben, und ein theoretisches update von 6.17.9 auf 6.17.10 könnte es grundsätzlich auch kaputtmachen, ist aber sehr unwahrscheinlich und würde in unserem lab schnell auffallen. Das würden wir entweder rasch beheben, oder (falls das kernel update kritisch ist, zb wegen security updates) einen entsprechenden Eintrag im wiki machen (das ist so aber noch nie passiert).

tl;dr:

wichtig sind vor allem die (haupt) Kernelversion <-> NVIDIA Treiber Kompatibilität, der restliche stack ist normalerweise kompatibel unabhängig von den minor Versionen.
wir updaten die liste nicht bei jeder kleinen Änderung, sondern hauptsächlich bei neuen NVIDIA Treiber Versionen oder großen kernel Änderungen

 

[Raudi]

jetzt ist es aber so das unsere neueren Versionen (zB PVE manager 9.1.5 vs 9.1.4) eigentlich immer kompatibel sein müssen, das heist ein update nur von 9.1.4 auf 9.1.5 (ohne große kernel Änderung) sind kompatibel.

Okay, das bedeutet man kann gefahrlos Patches installieren und wenn ein Kernel nicht funktioniert pinnt man einfach die vorherige Version an.

Probleme hier gibt es eigentlich nur wenn der kernel größere Änderungen hat (zB von 6.14 auf 6.17) und der NVIDIA Treiber noch nicht dafür vorbereitet ist (hier können wir, außer NVIDIA vorab feedback geben, meistens nicht viel machen)

Klar, aber auch hier wäre das dann so, einfach installieren, testen, wenn Treiber mit Kernel nicht funktionieren die vorherige Version nutzen und anpinnen...

wichtig sind vor allem die (haupt) Kernelversion <-> NVIDIA Treiber Kompatibilität, der restliche stack ist normalerweise kompatibel unabhängig von den minor Versionen.
wir updaten die liste nicht bei jeder kleinen Änderung, sondern hauptsächlich bei neuen NVIDIA Treiber Versionen oder großen kernel Änderungen

Danke für die Info.

Fazit:
Das ganze ist nicht so strikt wie es auf den ersten Blick aussieht. Updates kann man Zeitnah installieren, wenn der Kernel nicht mit den NVIDIA Treiber funktioniert die vorherige Version nutzen und anpinnen. Alles andere sollte funktionieren. Ansonsten regelmäßig in die Matrix schauen und die vGPU Version natürlich auch entsprechend aktuell halten.