14
Proxmox stoppte alle VMs
Hallo Leute,
heute war ich etwas geschockt, als ich durch das Monitoring den Ausfall von 27 Server diagnostiziert bekam.
Bin dann sofort an den PC, und habe zuerst mal versuche einzelne Server zu pingen - vergebens.
Zunächst natürlich sofort in Proxmox eingeloggt, und sah, dass *alle* Server (VM) offline sind, und nur der Knoten lief.
Proxmox hat absolut nichts verraten, warum und weswegen es das getan hat, folgende Infos habe ich:
(Anhang: p1.png)
(Anhang: p2.png)
Was auffällig ist: Plötzlich wird ein ClusterLog geführt - Ich bin mir sehr sicher, das der sonst immer leer war (p2.png)
Proxmox auth.log:
VM´s starteten nach dem manuellen Befehl ohne Probleme.
Hat jemand eine Idee was da los sein könnte, bzw. wo ich anfangen könnte zu suchen?
Evtl. Autp-Updates?
Vielen Dank bereits jetzt für eure Hilfe.
Sebi
heute war ich etwas geschockt, als ich durch das Monitoring den Ausfall von 27 Server diagnostiziert bekam.
Bin dann sofort an den PC, und habe zuerst mal versuche einzelne Server zu pingen - vergebens.
Zunächst natürlich sofort in Proxmox eingeloggt, und sah, dass *alle* Server (VM) offline sind, und nur der Knoten lief.
Proxmox hat absolut nichts verraten, warum und weswegen es das getan hat, folgende Infos habe ich:
(Anhang: p1.png)
(Anhang: p2.png)
Was auffällig ist: Plötzlich wird ein ClusterLog geführt - Ich bin mir sehr sicher, das der sonst immer leer war (p2.png)
Proxmox auth.log:
Jun 4 19:57:11 xxxxxxxx sshd[3351]: Server listening on 0.0.0.0 port xxxx.
Jun 4 19:57:11 xxxxxxxx sshd[3351]: Server listening on :: port xxxx.VM´s starteten nach dem manuellen Befehl ohne Probleme.
Hat jemand eine Idee was da los sein könnte, bzw. wo ich anfangen könnte zu suchen?
Evtl. Autp-Updates?
Vielen Dank bereits jetzt für eure Hilfe.
Sebi
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 339814
Url: https://administrator.de/contentid/339814
Ausgedruckt am: 22.11.2024 um 16:11 Uhr
14 Kommentare
Neuester Kommentar
Hallo Sebastian,
bei 27 Servern dürfte es sich wohl lohnen einen Experten hin zu ziehen. Aus den obigen Logs sieht man nicht wirklich viel, auser, naja, dass der SSH Server unter dem Port xxxx läuft (Juhe!)
Der Rest ist auch wenig aufschlussreich.
Viele Grüße,
Christian
bei 27 Servern dürfte es sich wohl lohnen einen Experten hin zu ziehen. Aus den obigen Logs sieht man nicht wirklich viel, auser, naja, dass der SSH Server unter dem Port xxxx läuft (Juhe!)
Der Rest ist auch wenig aufschlussreich.
Viele Grüße,
Christian
Vielen Dank erstmal für deine Antwort.
Deweil laufen alle Server wieder ohne auch nur ein Problem.
Möchte nur wissen wodurch das Herunterfahren erzwungen wurde, um dem vorzubeugen.
Hast du evtl. eine idee, welche Logs aufschluss geben könnten?
LG
Deweil laufen alle Server wieder ohne auch nur ein Problem.
Möchte nur wissen wodurch das Herunterfahren erzwungen wurde, um dem vorzubeugen.
Hast du evtl. eine idee, welche Logs aufschluss geben könnten?
LG
Kannst mir eine PN schicken, dann schau ich mir das System gerne an.
Was sagt denn die Uptime des Proxmox-Hosts und was das Syslog?
Vielleicht ist der Host-Server z.B. durch Kernel-Panic rebooted und die VMs starten nicht automatisch?
Vielleicht ist der Host-Server z.B. durch Kernel-Panic rebooted und die VMs starten nicht automatisch?
UPDATE:
Anbei scrrenshot vom debug.log - (Geht ewig so weiter wie aus S1 zu sehen)
Würde glatt auf einen RAM Fehler tippen, oder liege ich da falsch?
LG & Danke nochmal
Anbei scrrenshot vom debug.log - (Geht ewig so weiter wie aus S1 zu sehen)
Würde glatt auf einen RAM Fehler tippen, oder liege ich da falsch?
LG & Danke nochmal
@LordGurke
Guter Ansatz - Vielen Dank!
Die Betriebszeit liegt nicht mehr bei ca. 7 Monaten, sondern nur mehr bei 2Std.
Was dennoch die Frage aufwirft, warum er neu getartet hat.
Unten ein Screen des debug.log
Guter Ansatz - Vielen Dank!
Die Betriebszeit liegt nicht mehr bei ca. 7 Monaten, sondern nur mehr bei 2Std.
Was dennoch die Frage aufwirft, warum er neu getartet hat.
Unten ein Screen des debug.log
Das debug-Log hilft dir hier wenig.
Ergiebiger sollte das syslog bzw. dir messages sein, wo du mal schaust was unmittelbar vor dem nächsten Boot gelogged wurde.
Ergiebiger sollte das syslog bzw. dir messages sein, wo du mal schaust was unmittelbar vor dem nächsten Boot gelogged wurde.
Hallo,
hier ist mal der syslog von Gestern, inkl. den Zeilen davon um 19:37 - Das waren die letzten Einträge:
Kann hier aber eigl. nichts betreffendes erkennen, du...?
LG
hier ist mal der syslog von Gestern, inkl. den Zeilen davon um 19:37 - Das waren die letzten Einträge:
Jun 4 19:17:01 sys71 /USR/SBIN/CRON[18912]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jun 4 19:37:12 sys71 rrdcached[3320]: flushing old values
Jun 4 19:37:12 sys71 rrdcached[3320]: rotating journals
Jun 4 19:37:12 sys71 rrdcached[3320]: started new journal /var/lib/rrdcached/journal/rrd.journal.1496597832.026009
Jun 4 19:37:12 sys71 rrdcached[3320]: removing old journal /var/lib/rrdcached/journal/rrd.journal.1496590632.026188
Jun 4 19:57:11 sys71 kernel: imklog 5.8.11, log source = /proc/kmsg started.
Jun 4 19:57:11 sys71 rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="3188" x-info="http://www.rsyslog.com"] start
Jun 4 19:57:11 sys71 kernel: Initializing cgroup subsys cpuset
Jun 4 19:57:11 sys71 kernel: Initializing cgroup subsys cpu
Jun 4 19:57:11 sys71 kernel: Linux version 2.6.32-39-pve (root@lola) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Fri May 8 11:27:35 CEST 2015
Jun 4 19:57:11 sys71 kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-39-pve root=/dev/mapper/pve-root ro quiet
Jun 4 19:57:11 sys71 kernel: KERNEL supported cpus:
Jun 4 19:57:11 sys71 kernel: Intel GenuineIntel
Jun 4 19:57:11 sys71 kernel: AMD AuthenticAMD
Jun 4 19:57:11 sys71 kernel: Centaur CentaurHauls
Jun 4 19:57:11 sys71 kernel: BIOS-provided physical RAM map:
Jun 4 19:57:11 sys71 kernel: BIOS-e820: 0000000000000000 - 000000000009a800 (usable)
Jun 4 19:57:11 sys71 kernel: BIOS-e820: 000000000009a800 - 00000000000a0000 (reserved)
Jun 4 19:57:11 sys71 kernel: BIOS-e820: 00000000000e6000 - 0000000000100000 (reserved)
Jun 4 19:57:11 sys71 kernel: BIOS-e820: 0000000000100000 - 00000000d7e80000 (usable)
Jun 4 19:57:11 sys71 kernel: BIOS-e820: 00000000d7e8e000 - 00000000d7e90000 type 9
Jun 4 19:57:11 sys71 kernel: BIOS-e820: 00000000d7e90000 - 00000000d7eb4000 (ACPI data)
Jun 4 19:57:11 sys71 kernel: BIOS-e820: 00000000d7eb4000 - 00000000d7ee0000 (ACPI NVS)
Jun 4 19:57:11 sys71 kernel: BIOS-e820: 00000000d7ee0000 - 00000000d8000000 (reserved)
Jun 4 19:57:11 sys71 kernel: BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
Jun 4 19:57:11 sys71 kernel: BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
Jun 4 19:57:11 sys71 kernel: BIOS-e820: 0000000100000000 - 0000002027000000 (usable)
Jun 4 19:57:11 sys71 kernel: DMI present.Kann hier aber eigl. nichts betreffendes erkennen, du...?
LG
Moin,
habe selbst zwar kaum bis keine Erfahrungen mit Proxmox, habe aber mal nach dem letzte Log-Eintrag und "reboot" im WWW gesucht (https://www.google.de/search?q=proxmox+removing+old+journal+reboot).
Offenbar gibt es noch andere, die ähnliche Probleme haben:
https://forum.proxmox.com/threads/random-restarting.30964/
Beim Überfliegen bin ich drüber gestolpert, dass das ZFS-FileSystem, auf dem auch die VMDKs (oder wie die bei Proxmox heißen) liegen, eine hohe Schreib/ Lese-Last hatten. Mit Anpassungen von 2-3 Parametern konnte man das Problem wohl eindämmen....
Vllt. hilft dir das ja weiter...
Gruß
em-pie
€dit: Typo
habe selbst zwar kaum bis keine Erfahrungen mit Proxmox, habe aber mal nach dem letzte Log-Eintrag und "reboot" im WWW gesucht (https://www.google.de/search?q=proxmox+removing+old+journal+reboot).
Offenbar gibt es noch andere, die ähnliche Probleme haben:
https://forum.proxmox.com/threads/random-restarting.30964/
Beim Überfliegen bin ich drüber gestolpert, dass das ZFS-FileSystem, auf dem auch die VMDKs (oder wie die bei Proxmox heißen) liegen, eine hohe Schreib/ Lese-Last hatten. Mit Anpassungen von 2-3 Parametern konnte man das Problem wohl eindämmen....
Vllt. hilft dir das ja weiter...
Gruß
em-pie
€dit: Typo
Hallo,
das wird mich kaum betreffen, da im Log desjenigen eindeutig die Aufmerksamkeit auf die HDD gelenkt wurde, bei mir ist da nichts ersichtlich.
Andere Theorie:
Der Server steht *nicht abgesperrt* in einem Rechenzentrum, wäre es möglich, dass einer meinte, er muss Stromfeed A+B von meinem Server entfernen, und er somit einfach keinen Strom mehr hatte? Haben natürlich nur eine Hand voll Leute Zugriff - Dennoch im Bereich des möglichen, Videoüberwacht wird alles, also im Zweifelsfall könnte ich das Material anfordern.
Wie wird soetwas geloggt? Hat ja schon jemand Erfahrungen mit gehabt?
LG
das wird mich kaum betreffen, da im Log desjenigen eindeutig die Aufmerksamkeit auf die HDD gelenkt wurde, bei mir ist da nichts ersichtlich.
Andere Theorie:
Der Server steht *nicht abgesperrt* in einem Rechenzentrum, wäre es möglich, dass einer meinte, er muss Stromfeed A+B von meinem Server entfernen, und er somit einfach keinen Strom mehr hatte? Haben natürlich nur eine Hand voll Leute Zugriff - Dennoch im Bereich des möglichen, Videoüberwacht wird alles, also im Zweifelsfall könnte ich das Material anfordern.
Wie wird soetwas geloggt? Hat ja schon jemand Erfahrungen mit gehabt?
LG
OK, da hast du recht, dort gab es in der Tat indizien auf HHD-Aspekte.. Hatte wie gesagt ja "nur Überflogen"...
Die Sache mit der Stromunterbrechung... hatte ich auch kurzweilen überlegt...
Ich meine im Kopf zu haben, dass bei unseren IBM-Servern soetwas im IPMI-Log erscheint, kurz bevor der Server die Biege macht.
Zumindest müsste man erkennen, dass erst das eine Netzteil Powerless ist, bevor es das andere erwischt. Habt ihr IPMI-Module o.Ä. verfügbar?
Wenn es die USV-erwischt hat... vllt. gibt die ja Auskunft
Aber warum sollte einer der "handvoll Leute" auf die Idee kommen, Strom zu ziehen? Außer, es waren Wartungsarbeiten an anderen Systemen angedacht und man hat versehentlich das falsche Kabel erwischt!? Wobei derjenige dann sicherlich ausreichend "Eier in der Hose" haben sollte, dies zu melden/ den Zustand zu begradigen....
Die Sache mit der Stromunterbrechung... hatte ich auch kurzweilen überlegt...
Ich meine im Kopf zu haben, dass bei unseren IBM-Servern soetwas im IPMI-Log erscheint, kurz bevor der Server die Biege macht.
Zumindest müsste man erkennen, dass erst das eine Netzteil Powerless ist, bevor es das andere erwischt. Habt ihr IPMI-Module o.Ä. verfügbar?
Wenn es die USV-erwischt hat... vllt. gibt die ja Auskunft
Aber warum sollte einer der "handvoll Leute" auf die Idee kommen, Strom zu ziehen? Außer, es waren Wartungsarbeiten an anderen Systemen angedacht und man hat versehentlich das falsche Kabel erwischt!? Wobei derjenige dann sicherlich ausreichend "Eier in der Hose" haben sollte, dies zu melden/ den Zustand zu begradigen....
Zitat von @em-pie:
Außer, es waren Wartungsarbeiten an anderen Systemen angedacht und man hat versehentlich das falsche Kabel erwischt!? Wobei derjenige dann sicherlich ausreichend "Eier in der Hose" haben sollte, dies zu melden/ den Zustand zu begradigen....
Außer, es waren Wartungsarbeiten an anderen Systemen angedacht und man hat versehentlich das falsche Kabel erwischt!? Wobei derjenige dann sicherlich ausreichend "Eier in der Hose" haben sollte, dies zu melden/ den Zustand zu begradigen....
Will niemandem etwas unterstellen, aber genau das war mein Verdacht.
Einen Zugriff aufs Supermicro IPMI habe ich zwar, aber das gibt überhaupt keinen Aufschluss darüber, wann der Server stromlos war, oder neu gestartet hat. Im Eventlog war nur zusehen, dass FAN2, also Lüfter 2 nicht auf der Leistung arbeitet, wie er sollte - Werde ich also demnächst austauschen (Der Lüfter verschuldet aber sicherlich nicht den reboot, da das ein kleiner, ziemlich unwichtiger Lüfter ist)
Grüße
Selbst ohne Log würde ich basierend auf der Spurenlage von einer Stromunterbrechung oder wenigstens einem Hardware-Reset per Reset-Taster ausgehen - du solltest also in jedem Fall mal in die Videos gucken.
Gerade bei zwei Kabeln (es sind doch zwei Kabel und nicht nur ein Y-Stecker?) kann man ein Versehen ja eigentlich schon ausschließen, sofern die vernünftig beschriftet sind...
Gerade bei zwei Kabeln (es sind doch zwei Kabel und nicht nur ein Y-Stecker?) kann man ein Versehen ja eigentlich schon ausschließen, sofern die vernünftig beschriftet sind...
Hallo,
ja es ist ein A+B Feed, also wirklich 2 Unterschiedliche Kabeln, mit Unterschiedlicher Versorgung.
Nur schade, dass der IPMI Log keinen Aufschluss gibt :/
Nun denn, dann muss ich wohl Videos gucken...
Danke für eure Hilfe!
UPDATE
Resetknopf habe ich aus solchen Gründen nie angeschlossen :D
ja es ist ein A+B Feed, also wirklich 2 Unterschiedliche Kabeln, mit Unterschiedlicher Versorgung.
Nur schade, dass der IPMI Log keinen Aufschluss gibt :/
Nun denn, dann muss ich wohl Videos gucken...
Danke für eure Hilfe!
UPDATE
Resetknopf habe ich aus solchen Gründen nie angeschlossen :D
