Alle VMs haben irgendwann einen Kernel-crash

[briearn]

Hallo,

man soll es kaum glauben, aber alle Gäste hängen sich bei mir nach einer gewissen Zeit einfach weg und haben einen kernel crash.
Auf allen physikalischen Maschinen passiert das. Sogar mit fertigen Virtual Appliances.
Dabei sind die Maschinen nun wirklich bestens ausgestattet, also es kann nicht an fehlenden Ressourcen oder so liegen. Es sind SUN X4100 mit 2x285 Opteron und 16GB RAM.
Das Poblem ist, das bei jeder Maschine die in diesen Zustand läuft, der Prozessor der physikalischen Maschine, der diesen Host bearbeitete dann auf 100% Auslastung steht.

Man kann da wirklich nicht von einem stabilen System sprechen.
Die SUN Hosts laufen unter FC5 x86_64 mit einem 2.6.17er Kernel.

ich häng mal einen Bildschirmsnap an, der macht es deutlicher...
Hoffentlich weiß hier igrnejemand weiter...


Danke schonmal

[Tschoergez]

Hi,

also ich würde auf einen Hardware-Defekt tippen (wahrscheinlich Speicher). Dazu müsstest Du den Server mal durchtesten, z.B. mit http://www.memtest86.com/.

Anonsten Hitze? Spannungsschwankungen? (wobei da natürlich dann meistens der ganze Host abstürzt)

Aber dass alle Gäste crashen, ist ungewöhlich

Passiert das gleichzeitig?

viele Grüße,
Jörg

[briearn]

Hi,

also ich würde auf einen Hardware-Defekt tippen (wahrscheinlich Speicher). Dazu müsstest Du den Server mal durchtesten, z.B. mit http://www.memtest86.com/.

Anonsten Hitze? Spannungsschwankungen? (wobei da natürlich dann meistens der ganze Host abstürzt)

Aber dass alle Gäste crashen, ist ungewöhlich

Passiert das gleichzeitig?

viele Grüße,
Jörg

Hi Jörg,

also HW-Defekte schließen sich wirklich aus. Das ist Registered ECC RAM, würde also im Hardware-Monitoring auftauchen. Außerdem sind es ja mehrere (insgesamt 4) identische Maschinen und es passiert auf allen. Wie gesagt, nur die Gäste crashen. Die Hosts laufen munter und vergnügt weiter bis ich die gecrashten Gäste kille oder restarte oder stoppe allerdings unter höherer Last wie man sieht.
Es chrashen auch nicht alle gleichzeitig. Successive einer nach dem anderen, mal der; ein andermal der; beim dritten mal zwei Gäste kurz hintereinander==> total wild!

Hitze scheidet aus, die Kisten sind im klimatisierten Rack. Spannungsschwankungen sind durch die USV heraus, außerdem läuft der Host ja weiter und das ohne wilde msg-log einträge...

Wie gesagt: Ich stehe vor einem Rätsel!

[devzero]

Linux Host Operating System Requirements

Supported distributions and kernels are listed in this section. VMware Server might not
run on systems that do not meet these requirements.Platforms that are not listed are
not supported.

VMware Server Administration Guide
8 VMware, Inc.
64‐bit host computers can run the following operating systems for 64‐bit extended
systems:
! Red Hat Enterprise Linux 3.0 AS, ES, and WS, stock 2.4.21, update 2.4.21‐15, and
updates 6 and 7
! Red Hat Enterprise Linux 3.0 AS, ES, and WS, update 8 (experimental support)
! Red Hat Enterprise Linux 4.0 AS, ES, and WS, including update 3
! Red Hat Enterprise Linux 4.0 update 4 (experimental support)
! SUSE Linux Enterprise Server 10 (experimental support)
! SUSE Linux Enterprise Server 9, including SP1, SP2, and SP3
! SUSE Linux 10
! SUSE Linux 10.1
! SUSE Linux 9.3
! SUSE Linux 9.2, including SP1
! SUSE Linux 9.1 stock 2.6.4‐52
! Mandriva Linux 2006
! Ubuntu Linux 5.04 and 5.10
! Ubuntu Linux 6.06 (experimental support)
32‐bit host computers can run the following operating systems:
! Mandriva Linux 2006
! Mandrake Linux 10.1
! Mandrake Linux 9.0 stock 2.4.19
! Red Hat Enterprise Linux 4.0 AS, ES, and WS, including updates 1,2, and 3
! Red Hat Enterprise Linux 4.0 update 4 (experimental support)
! Red Hat Enterprise Linux 3.0, updates 1, 2, 3, 4, 5, 6, and 7
! Red Hat Enterprise Linux 3.0 update 8 (experimental support)
! Red Hat Enterprise Linux 2.1stock 2.4.9‐e3
! Red Hat Linux 9.0, stock 2.4.20‐8 and upgrade 2.4.20‐20.9
! Red Hat Linux 8.0 stock 2.4.18
! Red Hat Linux 7.3 stock 2.4.18
VMware, Inc. 9
Chapter 1 Introduction and System Requirements
! Red Hat Linux 7.2, stock 2.4.7‐10 and upgrades 2.4.9‐7, 2.4.9‐13, 2.4.9‐21, and
2.4.9‐31
! SUSE Linux Enterprise Server 10 (experimental support)
! SUSE LINUX Enterprise Server 9, including SP1, SP2, and SP3
! SUSE Linux Enterprise Server 8 stock 2.4.19
! SUSE LINUX 9.3
! SUSE LINUX 9.2
! SUSE Linux 10
! SUSE Linux 10.1
! SUSE LINUX 9.1 stock 2.6.4‐52
! SUSE LINUX 9.0 stock 2.4.21‐99
! SUSE Linux 8.2 stock 2.4.20
! SUSE Linux 7.3
! Ubuntu Linux 5.04 and 5.10
! Ubuntu 6.06

[briearn]

Linux Host Operating System Requirements

Supported distributions and kernels are listed in this section. VMware Server might not
run on systems that do not meet these requirements.Platforms that are not listed are
not supported.
...

Hallo devzero,

sicher, es steht nicht in der Liste, doch was genau soll daran nun der technische KO sein? Sicher wird das VMware keine Verbindung zum www.vmware.com Webserver aufbauen und nachschauen ob im Admin-Guide das system was mit uname -a herauskommt enthalten ist. Es müssen schon handfestere Gründe existieren.

ich habe mir mal den "Spaß" gemacht, einen strace auf dem host und den VMs laufen zu lassen. Irgendwie bekommt die virtuelle Kiste zum /dev/sda einen Timeout, wobei allerdings unsicher ist woran das liegt. (Evtl. ein Bug in VMware-Server?!?! Hat hier jemand Erfahrungen?) Die Hostsysteme sind unter keiner nennenswerten Last (ca. 2% oder so) und IO queues gibts auch nicht.

[devzero]

ein strace auf die vmware-vmx prozesse ?

und genau dann bekommst du die timeouts ?

strace ist meiner erfahrung nach nicht ganz ungefährlich - ich hab schon programme gehabt die nach/durch nem strace -p $PID nicht mehr anständig liefen

[briearn]

ein strace auf die vmware-vmx prozesse ?

und genau dann bekommst du die timeouts ?

strace ist meiner erfahrung nach nicht ganz ungefährlich - ich hab schon programme gehabt die nach/durch nem strace -p $PID nicht mehr anständig liefen

Ja, da habe ich es bemerkt. Den Bildschirmsnap hingegen habe ich gemacht, als ich einmal richtig glück hatte schnell genug zu sein, bevor die Kernel-coredump-daten über den Schirm rauschten. Da lief zu dem Zeitpunkt kein strace...

Hast Du irgend eine Idee?

[devzero]

im moment wissen wir noch nicht, obs ein hardware oder ein softwareproblem ist.

um das auf eins von beiden einzugrenzen würde ich dir empfehlen, einmal das betriebssystem zu wechseln, d.h. ein supportetes betriebssystem zu nehmen.

[briearn]

im moment wissen wir noch nicht, obs ein hardware oder ein softwareproblem ist.

um das auf eins von beiden einzugrenzen würde ich dir empfehlen, einmal das betriebssystem zu wechseln, d.h. ein supportetes betriebssystem zu nehmen.

Nun, bei einem HW problem würde ich erwarten, das zumindest in einem logfile des Hosts ein paar Zeilen dazu stehe würden. Oder aber die Watchdogs in der Hardware das ins BMC schreiben. NIX da. Ist nur die VM bzw. sind die VMs (Plural)

Außerdem tritt das Problem auf allen 4 Servern auf... und ich erwarte nicht, das alle server probleme haben.

[devzero]

das ist wohl wahr.

ich würds trotzdem mal mit einer anderen linux version versuchen - wenn das dann läuft kanst du immer noch den "bug" suchen, der den crash bei fedora systemen verursacht

[briearn]

das ist wohl wahr.

ich würds trotzdem mal mit einer anderen linux version versuchen - wenn das dann läuft kanst du immer noch den "bug" suchen, der den crash bei fedora systemen verursacht

So, ein neues Phänomen: Clienten mit CentOS4.4 (=RHEL4U4) stürzen nicht ab, sondern laufen problemlos durch.
Sollte das an den VMs, die ich als fertige Appliances (z.B. Hercules oder aber m0n0wall ) direkt von VMWare geladen habe liegen? Kann doch nicht sein oder?

--> in der Zwischenzeit bin ich am Compilieren eines neuen Kernels um die CentOS4.4 Systeme als HOSTs zu haben... das kann aber noch dauern, ich benötige cluster und gfs filesystem und noch einen ISCSI adapter...