Kernel Live Patching

[Alvin2k8]

Hallo an alle,

habe ihr eine Lösung den Proxmox Kernel live zu patchen, ohne Neustart des Systems?

Freue mich auf eure Erfahrungen!

 

[Dunuin]

Denke die meisten umgehen das einfach über einen Cluster und Live Migration. Da flog sogar ein Script (glaube von Tuxis?) rum was dir automatisch einen Node von Gästen freiräumt, dann kannst du den Node neustarten, ohne das irgendein Gast Downtime hätte und dann werden die Gäste wieder automatisch zurückmigriert.

Und selbst wenn du den Kernel ohne Neustart patchen könntest, die VMs müssen so oder so gelegendlich mal neugestartet werden. Weil sonst laufen die mit einer veralteten QEMU Version weiter.

 

[Falk R.]

Denke die meisten umgehen das einfach über einen Cluster und Live Migration. Da flog sogar ein Script (glaube von Tuxis?) rum was dir automatisch einen Node von Gästen freiräumt, dann kannst du den Node neustarten, ohne das irgendein Gast Downtime hätte und dann werden die Gäste wieder automatisch zurückmigriert.

Das macht HA ja alles automatisch, wenn du die Policy auf migrate stellst.

Und selbst wenn du den Kernel ohne Neustart patchen könntest, die VMs müssen so oder so gelegendlich mal neugestartet werden. Weil sonst laufen die mit einer veralteten QEMU Version weiter.

Stimme dir in dem Punkt 100% zu.

 

[devaux]

Und selbst wenn du den Kernel ohne Neustart patchen könntest, die VMs müssen so oder so gelegendlich mal neugestartet werden. Weil sonst laufen die mit einer veralteten QEMU Version weiter.

Stimmt dies denn? Laut: https://forum.proxmox.com/threads/qemu-9-0-available-on-pve-no-subscription-as-of-now.149772/

Note, as with all QEMU updates: A VM must either be completely restarted (shut it down then start it again, or use the restart command via the CLI or web-interface) or, to avoid downtime, consider live-migrating to a host that has already been upgraded to the new QEMU package version.

 

[Dunuin]

Das Zitat sagt doch genau das. Du musst die VM migrieren oder neustarten (und das über PVE was dann ein Shutdown + Start macht damit die VM einmal wirklich stoppt...Reboot innerhalb der VM reicht nicht). Sonst läuft die VM mit der veralteten QEMU Version weiter selbst wenn auf dem Host bereit das QEMU Package aktualisiert wurde.

 

[devaux]

Das Zitat sagt doch genau das. Du musst die VM migrieren oder neustarten (und das über PVE was dann ein Shutdown + Start macht damit die VM einmal wirklich stoppt...Reboot innerhalb der VM reicht nicht). Sonst läuft die VM mit der veralteten QEMU Version weiter selbst wenn auf dem Host bereit das QEMU Package aktualisiert wurde.

Ja. Aber wenn ich zwei VM-Hosts habe und auf beiden live patche, dann muesste ich nur die VMs einmal von Node a nach Node b verschieben und es nimmt dann die aktualisierte Qemu-Version.
So verstehe ich das jedenfalls.

 

[Dunuin]

Ja. Aber wenn ich zwei VM-Hosts habe und auf beiden live patche, dann muesste ich nur die VMs einmal von Node a nach Node b verschieben und es nimmt dann die aktualisierte Qemu-Version.
So verstehe ich das jedenfalls.

Dann bist du aber auch schon wieder an einem Punkt wo du fast kein Live Patching mehr brauchst. Dann könntest du noch für 10+€ einen SBC/Thin-Client als QDevice dazupacken und hättest ein Cluster, damit du mit Live Migration einen Node für einen Reboot freiräumen könntest.

 

[Falk R.]

Live Patching braucht im Enterprise Umfeld niemand bei einem Hypervisor. Egal ob du ZFS Replikation, Ceph oder ein externes Storage benutzt. Sobald du einen Cluster hast, bootest du regelmässig die Nodes mal durch. Eventuell sollte man ja auch mal Firmwareupdates machen, weil einige Lücken in Treibern lassen sich nur mit neuer Firmware fixen.