VMware-Forum

Guten Morgen in die Runde.

Hier die Vorgeschichte:

Wir haben 2 ESX Enterprise Server 3.5 Update 1 im Cluster mit HA,DRS etc. laufen.

Typ FuSi RX600 mit je 2x Xeon DualCore CPUs, 8GB RAM.
Als gemeinsamer Speicher dient ein StorageTek SAN, welches über je 2 2Gb FC Karten über Fabrics angeschlossen ist.

Darauf liefen bisher problemfrei 17 Windows VMs. VMotion, DRS etc., alles kein Thema.

Da wir nun weitere VMs erwarten und die beiden RX600 mit den 17 VMs schon deutlich ausgelastet sind, haben wir ein Update der Server beschlossen.

Wir hatten gerade zwei RX600 S2 mit je 4 Xeon DualCore CPUs und je 16 GB RAM frei bekommen, die wollten wir nehmen.

Am Freitag habe ich alle VMs auf den ersten, der beiden "alten" RX600 migriert und den zweiten abgeschaltet.
Dann haben wir den ersten "neuen" RX600 S2 eingebaut und die Verkabelung des "alten" angeschlossen.
Gleiches sollte dann noch mit dem zweiten "alten" RX600 geschehen, sobald wir alle Maschinen auf den ersten "neuen"RX600 S2 migriert hätten.

Die neuen RX600 S2 sind bereits mit ESX 2.5 Update 2 installiert, ansonsten aber identisch installiert, sprich alle Netzwerke sind identisch mit exakt gleichem Namen angelegt worden.

Das Problem nun:

Schon bei der Einrichtung im Infrastructure Client 2.5 fiel uns auf, dass sich der "neue" sehr zäh verhält und bei Configänderungen teilweise sogar Timeouts auftraten.
Alle VMs, die wir (offline, da andere CPUs) auf die "neue" ESX Maschine migirert haben., verhalten sich ebenfalls unheimlich zäh und langsam.
So langsam, dass eine Konsolen-Session teils 30-40 Sekunden braucht, bis sie überhaupt mal geöffnet ist.
An einen Betrieb ist so auf keinen Fall zu denken.
Die migrierten Maschinen laufen in Timeouts und sind so nicht zu gebrauchen.
Ich musste alle VMs wieder herunter nehemen und nun laufen derzeit alle 17 VMs auf dem verbliebenen "alten" RX600, der aus allen Nähten platzt.

Ich habe mir nochmal die Netzwerkconfig des "neuen" angesehen, kann aber keine Auffälligkeiten erkennen. VLANs haben wir keine, nur 4 einzelne Netzwerksegmente.

Was kann das nur sein?
Hat jemand eine Idee, oder ist über dieses Phänomenschon mal gestolpert?

Ich bedanke mich schon mal im Vorraus fürs lesen und für hilfreiche Tipps.

Schon mal die Porteinstellungen auf den Switches kontrolliert, ob die ident sind? Ebenso die Netzwerkeinstellungen auf den ESX Servern (NICs, Virtual Machine Port Groups, etc.)

Hast Du den alten ESX aus dem VC ordnungsgemäß entfernt, und den neuenneu eingebunden, oder den alten im VC dringelassen, und mit dem neuen Blech nur "reconnected"?

letzteres ist nicht wirklich empfehlenswert. Schmeiß doch mal den neuen ESX ganz aus dem VC raus, und nimm ihn wieder rein.

Oder schau mal, ob die Performance auch so bescheiden ist, wenn Du ihn ganz unabhängig vom VC nur standalone betreibst. (ich tippe mal, da funktioniert dann alles).

Hast Du die Performace der VMs nur gefühlt gemessen über die VI Client Console, oder auch wirklich langsame pingzeiten zum Gast usw.?

dann das übliche: passt die Namensauflösung (vorwärts rückwärts mit kurzem und langem namen), ziegt ein top in der console irgendwelche dicken prozesse in der console?
und schau mal mit esxtop, was denn überhaupt für Auslastung passiert auf dem ESX.

Viele Grüße,
Jörg

Erst einmal schönen Dank für eure Ratschläge.

Praktisch haben wir den "alten" in den Maintenence Mode genommen und dann herunter gefahren.
Dann den "neuen" mit den Leitungen des "alten" angeschlossen.

Dazu muss ich sagen, dass der "neue" eine neue IP Adresse und einen neuen Namen bekommen hat.
Also haben wir einen weiteren in den VC mit aufgenommen.
Den "alten" habe ich später entfernt.

"Gefühlt". Das bedeutet, dass sich die Anwender beschweren, dass es in den Anwendungen Timeouts gibt und das eine RDP oder Konsolenanmeldung bis zu 2 Minuten dauert. Aufrufen der Windows Verwaltung dauert schon mal bis zu 10 Sekunden.
Auch der Login per web access dauert länger, als beim anderen ESX Server.

Ich werde das heute mal alles noch einmal in Ruhe durchgehen und melde mich dann, was es gebracht hat.

Edit:
So viel kann ich schon sagen: Auch wenn ich ihn aus dem VC raus nehme, ändert sich leider nichts an seinem Verhalten und den Gästen. Langsam und nicht zu gebrauchen.

Ich habe mir überlegt den Server abzuschalten und seinen "Bruder" einzubauen und zu schauen, ob sich dieser ebenso verhält.

So.

Wir haben heute zunächst den VC Management Server mit Version 2.5 Update 3 neu auf Hardware aufgesetzt.

Anschließend haben wird den 2. "neuen" Server eingebaut (den 1. ausgebaut) und noch einmal akribisch alle IP, DNS und Domain Name Einstellungen angeschaut.

etc/hosts, /etc/sysconfig/network und /etc/resolv.conf sehen alle richtig aus.

Des weiteren haben wir die Firewall freigeschaltet und SSH Zugriff ermöglicht.

Nachdem wir den Server im neuen VC eingebunden haben, sah das schon mal gut aus, denn der Server lies sich problemlos im VC Manager bedienen und einrichten.

Nocheinmal haben wir alle Netzwerke, die wir eingerichtet haben gründlich überprüft, dass auch alle gleich heißen wie die, des "alten" ESX Servers.
Wir haben jede Netzwerkkarte überprüft und jedes Kabel gezogen und gecheckt.

Nachdem wir dann 4 Gäste auf den "neuen" Server offline migriert haben, das Gleiche Problem: Die Gäste sind zäh, wie Kaugummi, und nicht zu gebrauchen.

Ein top in der Console zeigt mir, dass der Prozess kipmi0 regelmäßig 99% Auslastung erzeugt.
Das gleiche Bild zeigt der Performance Monitor im VIC an. Etwa alle 5 Minuten zeigt sich auf der CPU 0 eine Sptize von 90 - 100%.

Unter esxtop fällt mir auf, dass die Console teils über 70 - 100 %Used springt.
Dies auch nur kurz, meist liegt sie um 2-3 %Used.
Alles andere ist ruhig und es stehen meist 390% von 400% zur Verfügung.

Ich weiß hier nicht mehr weiter, als nächsten Schritt planen wir die Firmwarestände des neuen Servers auf den aktuellsten Stand zu bringen.
Auch wenn er in der HCL steht, sagt das ja nichts über die Firmware aus.

Weiß jemand noch weiteres, was es sein kann? Diese Spitzen im Prozess Manager, verursacht durch den kipmi0 Prozess sind wohl schon mal sehr verdächtig, aber dass diese Spitzen auf einer CPU das System so sehr in die Knie zwingen soll, dass die Gäste nicht mehr vernünftig laufen?

Im Anhang mal ein Screenshot der Performance, die IPs habe ich unkenntlich gemacht, sollte jemand sie vermissen

Hallo, ich kann Dir soviel sagen dass wir seit dem Update auf 3.5 U2 das gleiche Problem auf einem Server haben, deswegen schiebe ich das Update auf dem 2. Server schon 1 Monat vor mir her, weil da die kritischeren Maschinen drauf laufen.

Es handelt sich hier ebenfalls um FSC Maschinen RX300 mit Dual Quad-Core's ... ich habe einen Beitrag in einem anderen Forum gefunden der ausgesagt hat dass DELL für genau dieses Problem mal extra ein BIOS-Update rausgebracht hat, ich frage mich derzeit ob es etwa an FSC und dem Server BIOS liegt

Das kann gut sein. Auch wir (Sun) haben teilweise neues BIOS Versionen speziell für 3.5 U2 gebracht. Vielleicht liegt es wirklich daran.

Ja, es sieht alles danach aus.

Das kipmi0 Problem haben wir lösen können, es ist aber nicht der Grund für den langsamen Betrieb.
kipmi0 ist für die Kommunikation mit den BMC (Health Status) Board zuständig.
Klemmt man diesen Dienst ab, sind die Peaks weg (und der Hardwaremonitor natürlich auch). Ist also Kosmetik.

Dann scheint es wohl ein Problem zu geben, in welchen PCI-X Slot man im Server Karten eingesteckt hat. Insbesonder PCI-X Slot #6 ist wohl ein Problem, das analysieren wir aber noch.

Ich melde mich, wenn es neues gibt.

EDIT: Also, umstecken der 4 Port Intel NIC auf den anderen PCI-X Slot brachte ebenso wenig Verbesserung, wie alle verfügbaren Patches für Update 2 zu installieren.
Aber nun kommt es: Eine Neuinstallation mit 3.5 Update 1 war ebenso erfolglos.
Alles beim alten. Schneckig ohne erkennbaren Grund..

Das Firmwareupdate hat auch nicht geklappt, da der FuSi Server die USB Sticks zwar erkannte, aber sich weigerte davon zu booten ... schöne neue Welt.
Früher gab es CD Images bei FuSi.

Wie konntest Du das Problem mit kipmi0 lösen?
Ich habe auf einem ESX 3.5U4 nun auch das Problem, daß dieser Prozess bei 100% steht.

Restart des Pegasus-Service hilft nicht, auch ein kill -9 stoppt diesen Prozess nicht.

Was tun??

Tut mir leid, wir haben dann die Server gewechselt und sind auf IBM 3850 gegangen.
Damit gibt es keinerlei Probleme mehr.