Gast Maschinen gehen einfach aus

[doc-sneider]

Hi,

nach einem Hardware Upgrade von 4 uf CPUs und 12 auf 24 GByte Hauptspeicher, gehen jetzt per Zufall die Gastmaschinen einfach aus. Sie fahren nicht runter sie gehen einfach aus. Ein System kann ich dabei nicht erkennen und auf in den Logs von VMware und Windows ist nichts zu finden.

Eine 8proc. Lizenz ist vorhanden, demnach sollte es daran nicht liegen. Den Upgrade haben wir auf zweit Hosts gemacht und beide zweigen das gleiche Fehlerbild.

Unsere VMware GSX 3.1 Hosts sind Windows 2003 Server Enterprise als Host OS.

Hatte das jemand schon mal?

Greetz
Andreas

[continuum]

Hi
verwendet ihr SMP in den Gaesten ?
Das in den vmware.logs der einzelnen Maschinen nichts zu sehen ist, kann ich ja gar nicht glauben - selbst wenn man sie hart abschaltet schreiben sie doch sonst auch noch einmal Tschuess.
Wie hat sich denn die Situation fuer die VMs veraendert - haben sie mehr RAM als vorher ?
Um was fuer Gaeste geht es denn eigentlich?
Habt ihr irgendeine Form von Netzwerkmonitoring? sind die VMs vielleicht vor dem Ausgehen schon fuer eine Weile nicht erreichbar ?

Jeses Detail koennte helfen.

Ulli

[doc-sneider]

Moin

danke für deine Antwort . Du hast natürlich recht das in den Logs der VM die Abstürze verzeichnet werden (jetzt hab ich 9 Monate keine Fehler gehabt da geht halt manches verloren :wink: )

SMP benutzen wir nicht, zumindest nicht in den Gästen, allerdings muss ich zugeben das der Host mit P4 Xeon DPs ausgestattet ist welche meines wissen nur im doppelpack (SMP) arbeiten. GSX unterstützt ja nur uniproc Gäste deshalb verstehe ich die Frage nicht so ganz (wie krige ich SMP auf ein VM uniproc system . ???)

Wir habe feststellen müssen das es vollkommen egal ist welches Gast OS installiert ist (w2k, w2k3, Linux oder NT4), die legen sich einträchtig und wahrlos nacheinander auf die Nase. Irgendwann zerlegt sich dann noch der serverd Prozess und dann ist Schicht .

Für die Gast Systeme hat sich "garnix" verändert nur der Host wurde von 4 auf 8 Proc. (+ ein Brick) und von 12 auf 24 GByte aufgerüsted (FSC Primergy RX800), aber die SMP geschichte ist ein guter Tip das werden wir jetzt mal auf einem Host testen.

Wenn es dich interessiert kann ich dir aber gerne mal das log einer Vm senden oder posten.

geeetz
Andreas

[continuum]

Hi
SMP in einer GSX-VM ist natuerlich Bloedsinn - ich muss wohl gerade an GSX 7.1 gedacht haben ...
Ich wuerde mir gerne mal ein VM-log ansehen - ich wuerde auch gerne mal sehen wenn 'regmon' von sysinternals.com einmal fuer eine Weile dem Serverdienst auf die Finger guckt. Irgendetwas laeuft da doch ins Leere - und verpulvert die ganze Lebensenergie.
Bei sehr vielen Workstations ist zB vmware.exe 20 mal in der Sekunde damit beschaeftigt die config.ini nicht zu finden.
Vielleicht gibt es bei euch aehnliche Effekte.
Welche SCSI-treiber verwendest du fuer die Windowsgaeste? Manche LSI-versionen sind lausig ...
Wie siehts mit Nics aus ? Verwendest du noch PCNet32 Treiber die bei der Erst-Installation von Windows dabei sind - fuer lange Uptimes vielleicht doch mal aktuelle AMD-treiber ausprobieren.

Ulli

[doc-sneider]

Puh das Problem ist gelöst

Ich hatte das Thema auch noch bei VMWare im forum diskutiert und da hat ein Kollege von VMWare mir folgenden KB Artikel geposted

http://www.vmware.com/support/kb/enduse ... ZT0x&p_li=

Das hat mein Prob. voll getroffen, wenn ich die VMs mit "processor<n>.use = FALSE" auf einen NUMA binde ist das Problem weg. Das ist zwr nicht gerade der Königsweg aber zurzeit wenigsten funktional. Ich habe das auch bi FSC eingkippt und denen gesagt das ich schon von ihenen erwarte das sie mir eine HAL leifern welche die TimeSync Probleme behebt.

Den Bug mit der config.ini habe ich auch beobachtet ihm aber keine bedeutung begemessen da ich das an der Performance nicht bemerkt habe. Gibts dafür ne einfach Lösung?

Ansonsten sind die Gäste so belassen wie Windows (via sysprep) sie installiert hat (hatte bisher 0 Problem damit :wink: )

Da wir aber demnächst alle Installationen überprüfen müssen könnte ein gewisses fine tuning nicht schaden