wir nutzen ein paar VMs mit Linbo zur Unterstützung des Torrent-Seeds. Ich dachte, auch wenn die nix zu tun haben, könnten die ja einfach im Hintergrund weiter laufen. Nun beobachte ich aber, dass seit Tagen jede dieser VMs 30% CPU-Last fährt, d.h. konstant 3 GHz benötigt:
Wird der Framebuffer in irgendeiner Busy-Waiting-Schleife sekündlich neu geschrieben oder wieso kommt /usr/bin/linbo_gui -platform linuxfb auf 3 Stunden 33 Minuten CPU-Zeit? Bei nur 10 Minuten längerer VM-Laufzeit?
Die Version ist 4.2.16-0 GUI 7.2.5.
linbo war nie auf powersaving getrimmt sondern immer auf „Größe“.
Ich kenne das vom clonen bei Laptops: da geht dann schon mal der Lüfter an, weil linbo die Powersavingmethoden von VIOS udn CPU nicht verwendet.
Ich denke, du solltest mal linbo 4.3 versuchen.
Das ist zwar auch nciht auf powersave getrimmt, bringt aber deutlich neuere kernel mit die das vielelciht schon automatisch drin haben …
Außerdem ist linbo 4.3 so eingestellt, dass die Clients direkt nach dem booten anfangen zu seeden: du brauchst dann also kein initcache mehr machen nach dem booten.
LG
Holger
wenn die Linbo-Gruppe den Parameter nogui nutzt, scheint der Client nicht mehr zu prüfen, ob ein neues Image vorliegt. Er bootet direkt in den Bildschirm “console boot menu of group …” und fertig. In der Weboberfläche ist für die Gruppe der Haken “Beim Start Cache aktualisieren“ gesetzt. Kann das jemand bestätigen?
Im aktuellen Zustand müssen wir nach einem Image-Update in der Weboberfläche nogui für die Gruppe entfernen, die Seedhosts (virtuellen Maschinen) rebooten, warten bis die ihre Images aktualisiert haben, danach nogui wieder für die Gruppe setzen und die VMs rebooten.
ich dachte der Parameter initcache entspricht dem Haken “Beim Start Cache aktualisieren” und der ist ja gesetzt.
Der Parameter nogui war bisher nur die Notlösung, um die hohe CPU-Last der VMs wegzubekommen. Ich vermute ja eher, dass es ein Bug in der linbo7-gui ist, der die hohe CPU-Last erzeugt, weil zu oft der Framebuffer aktualisiert wird oder so etwas ähnliches.
Für unseren Workflow wäre folgendes Vorgehen am einfachsten:
Admin aktualisiert irgendein Image
Admin startet im vSphere oder auf dem lmn-server via linbo-remote -i Linbo-Deploy1,Linbo-Deploy2,Linbo-Deploy3,Linbo-Deploy4 -c rebootdie vier Seedhosts neu
die VMs aktualisieren mit Reboot automatisch das Image und unterstützten fortan den weiteren Deployment-Prozess in den Gebäuden/Lehrsälen
Wenn die GUI das Lastproblem nicht hätte, würden die Admins im Schritt 2 auch im vSphere-Client die VM-Konsole öffnen und auf den Reboot-Button in der Linbo-GUI klicken.
OK: ihr verwendet Clients in nogui als seeder und wollt die Images verteilen.
Es wäre mir neu, dass sich ein linbo mit GUI da anders verhalten würde.
Wenn du einen Cleint in linbo bootest (mit GUI) und kein Betriebsystem syncst, dann holt der auch von sich aus kein Image in den Cache: es sei denn, du hast das in der start.conf.GRUPPE so voreingestellt.
Habt ihr das gesetzt und wenn ihr neustartet mit nogui wird der Cache nicht aktualisiert?
Ich denke aber, wenn eure Admins, statt Neustarten der Seeder, diesen einfach ein initcache per linbo-remote schicken, dass ihr dann genau den Effekt habt, den ihr haben wollt: neues Image auf dem Seeder und er seeded dieses.
ich verstehe, dass du meinst ein Befehl linbo-remote -i <hostname> -c initcache sollte in der laufenden VM den Cache/die Images aktualisieren. Ich sehe auch gerade, dass ich exakt das schonmal als Bash-Skript angelegt hatte.
Dennoch bleibt die Beobachtung, dass nach Start des Linbo-Clients mit Parameter nogui keine Aktualisierung stattfindet. Wir haben die VMs halt auch mal aus Gründen (bspw. Update BIOS-Update der Virtualisierungs-Hosts) ausgeschaltet und starten die erst beim nächsten Bedarf. Das Problem würde ja normale Clients auch treffen, wenn dort nogui verwendet würde.
Ein “normaler” Client aktualisiert die Images nicht beim Booten oder direkt danach. Erst wenn ein BS gesynct wird, wird geschaut, ob auf dem Server eine neuere Version dieses Images auf dem Server ist. Ist es das, wird es heruntergeladen, ist es das nciht, wird das aus dem Cache genommen.
Ein AutoInitCache Eintrag in der start.conf.GRUPPE kann das Verhalten verändern.
Bei dem von mir beschriebenen Vorgang wird auch nur das Image aktualisiert, welches gesynct wird: nicht alle.
Habt ihr AutoInitCache für die Clients gesetzt und das wird nicht befolgt?
wie Holger schon schrieb: Das ist das normale Verhalten, auch mit GUI. Es wird erst dann auf ein neues Image geprüft, wenn man ein OS synchronisiert startet.
wie ich schon schrieb ist “Beim Start Cache aktualisieren” für die Image-Gruppe gesetzt, also gehe ich davon aus, dass jegliches Image beim Start des Rechners bedingungslos aktualisiert wird und nicht nur dass, welches (vielleicht gar nicht) in der GUI angeklickt wird.
Nope, es ist kein Bug. Es ist ganz einfach so, dass die globale Linbo-Option AutoInitcache vom Gui ausgewertet wird. Wird das Gui nicht gestartet, passiert diesbzgl. auch nix.
Das ist aber doch ohnehin ungeschickt, dann musst Du den Rechner ja (ferngesteuert) regelmäßig neu starten - da ist es einfacher, ihm regelmäßig ferngesteuert ein initcache-Kommando zu schicken…
beides ist die Eingabe eines Befehls. Wie kommst du darauf, dass die Eingabe des einen Befehls einfacher wäre als die Eingabe des anderen Befehls?
Es kommt doch ganz auf das Einsatzszenario an. Wenn - nur mal als Beispiel - mein Szenario ist, dass ich mehrere Admins mit Erfahrung in Windows-Administration und Virtualisierung, aber wenig Linux-Erfahrung habe, dann ist ein Rechner oder eine VM neu starten einfacher. Ich betrachte die Situation halt nicht nur aus meinem Blickwinkel. Anderes Beispiel: Die VMs zum Unterstützen des Torrent-Seeds sind aus diversen Gründen auch mal ausgeschaltet. Wenn ich sie dann mal brauche, ist es tatsächlich einfacher, wenn sie nach dem Einschalten sich von alleine aktualisieren. Da möchte ich mich nicht nochmal irgendwo extra einloggen um ein initcache-Befehl auszuführen und genau dafür hat die Linbo-WebGUI Optionen vorgesehen, die im nogui-Modus nicht gewirkt hatten.
weil ich natürlich nur von dem Szenario ausgegangen bin, dass ich selbst verwende, nämlich das ich torrent-seeder als ständig laufende Maschinen haben will, bei denen ich nicht von Hand irgendwelche Befehle eingeben muss, um sie zu aktualisieren. Und ja, implizit gehe ich auch immer davon aus, dass Leute, die eine Linuxmusterlösung benutzen im Zweifelsfall den Linux-Weg gehen, ich hatte also angenommen, dass Du regelmässig per crontab-Eintrag einen reboot machst und fand deswegen, das man stattdessen auch einen initcache machen könnte. My fault.
Aber wenn man Dein Szenario nimmt – Leute, die hauptsächlich Erfahrung mit Windows-Administration haben dürften sich ja nicht daran stören, dass Ihre Server (hier: Torrent Seeder) mit einer eigentlich unnötigen, ressourcenfressenden GUI laufen, das sind sie ja von Windows-Servern gewohnt …
