vCenter 5.5 vSphere Client Verbindung timed out

[JanClaas]

Hallo ich habe auf einem unserer vCenter ein merkwürdiges Phenomän, das ich mir nicht erklären kann.

Daten:
vCenter 5.5.0, 2001466 Standard, installiert auf einer Windows Server 2012 R2 Standard, VM Version 8, 4vCPU, 16GB Ram
Das vCenter verwaltet 4x vSphere 5.5.0, 2638301 Enterprise Plus Hosts, auf denen auch das vCenter gehostet wird.
Aktuell werden ca. 20-30 VM's verwaltet.

Problem:
Beim Aufbau einer Verbindung mit dem vCenter über den vSphere Client bekomme ich von Zeit zu Zeit die Meldung "The vSphere Client cloud not connect to vCenter Server. The server took too long to respond. (The command has timed out as the remote server is taking too long to respond.)
Wenn ich versuche eine remote desktop session zu dem vCenter aufzubauen funktioniert dies. Jedoch bricht die Verbindung von Zeit zu Zeit immer wieder für einige Sekunden aus unerklärlichen Gründen zusammen.

Das Netzwerk läuft stabil, alle anderen vCenter in dem Netzwerk zeigen nicht dieses Problem. Hat jemand hier in der Community eine Idee, wo dieses Problem her kommen könnte und wo ich noch nach Fehlerquellen gucken kann?

[vl13]

Wenn ich versuche eine remote desktop session zu dem vCenter aufzubauen funktioniert dies. Jedoch bricht die Verbindung von Zeit zu Zeit immer wieder für einige Sekunden aus unerklärlichen Gründen zusammen.

Unabhaengig ob das Netzwerk stabil ist oder nicht kann eine falsche Netzwerk config oder ein defektes kabel/gbic/port eine der Ursachen sein.

Bsp.: access stack => trunk uplink => core => esx trunk
Fehlerquellen: LACP (HP, Extreme, ...), port-channel load-balance (Cisco), ESX (Nic Teaming, Load Balancing) ...

Ist nur dieser eine vCenter betroffen oder auch andere VM's ?
Passiert das auch wenn der vCenter auf einen anderen Host verschoben wird?
Mir fallen noch mehr moegliche Ursachen ein ...

[irix]

Sofern du nicht aus dem gleichen Subnet kommst auch mal solche Dinge wie falsche MTU mit in der Fehlersuche einbeziehen. Hatten wir neulich und es ist erstaunlich wie lange man sowas ertraegt

Gruss
Joerg

[JanClaas]

Hallo Ihr beiden, danke für die Antworten.

@vl13:
- die Hardware ist neu (Dell BladeChassis M1000e mit M620 Blades, Dell Force 10 MXL, die an den Cisco Nexus Backbone). Ich werde entsprechend nochmal die Netzwerker darauf ansetzten.

- Das Problem ist nur mit dem vCenter bekannt. Die anderen VM's sind mit anderen vSwitches verbunden. Ich werde mal prüfen, ob die anderen VM's hostübergreifend auch dieses Problem aufweisen. Auf die Idee mit dem verschieben des vCeners auf einen anderen Host hätte ich auch selbst kommen können. Werde ich prüfen.

@irix: Es sind tatsächlich unterschiedliche Subnetze und VLAN's, die MTU ist jedoch auf der LAN seite defaultmäßig mit 1500 konfiguriert. Lediglich im iSCSI für die Datastoreanbindung wurde die MTU angepasst.

Als Hinweis noch, das vCenter hat eine VMXNET3 mit statischer IPv4 konfiguration. IPv6 ist im Netzwerk nicht vorhanden und daher auf der VM unberührt. Das Netzwerk ist bis zum Backbone durchgehend 10G.

[2-D]

Zum Thema RDP:
....der Vollständigkeithalber solltest du dir auch mal die Eventlogs des Windows Systems anschauen. Vielleicht gibt es hier einen Eintrag.
Ebenso würde ich zusätzlich schauen, ob das Problem nach einem Ausschalten weg ist (und ich meine wirklich aus, kein Reset oder so). Wenn das alles nichts war, würde ich auch als Maßnahme sehen, zu kontrollieren, ob das vCenter selbst die Verbindung verliert, oder einfach nur das System von dem du aus zugreifst das Problem hat?
Zudem würde ich noch folgende Fragen stellen:
- Reagiert das Win vCenter System auf einen Ping, obwohl es per RDP/VI Client nicht erreichbar ist?
- Tut es das nicht, wie schaut es in der Consolenansicht des vCenters aus (Sicht über VI Client -> Host)? Irgendwas zu sehen (system freeze, usw.) ?
- Wenn alles gut läuft, erreicht das Windows während es von aussen nicht verfügbar ist sein Gateway? (Prüfung innerhalb des Systems nach aussen)

Zum Thema "took too long..." des Clients:
Der VI Client prüft ja eine generelle Erreichbarkeit des Services auf dem vCenter Server. ggf. reicht schon der Service Reboot (oder eben wie o.g. der System reboot). Aber vielleicht helfen hier auch die VI Client logs bzw. die vCenters logs, das Problem einzugrenzen.

vSphere Log Pfade:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1021806


....Mehr fällt mir dazu auch grade nicht ein

[JanClaas]

@2-D:
Danke für deine Hinweise.

Ich habe jetzt am Wochenende erstmal noch Windows Updates eingespielt und damit das vCenter auch neu gestartet. Außerdem habe ich das vCenter noch auf einen anderen Host geschoben.
Der Dauerping test von außerhalb sagt aktuell 146k pings, davon 3 verlorene Pakete. Von innen auf das Gateway sieht genauso aus. Die Antwortzeit war zwischenzeitlich mal bei 32ms statt der üblichen 0/1 ms. Das ist vermutlich aber den 3 verlorenen Paketen geschuldet.
Seit heute morgen habe ich eine permanente remote desktop session zu dem vCenter offen und der vSphere client hat seit dem weder auf dem vCenter noch auf meinem desktop einen Verbindungsabbruch.

Ich werde das mal noch weiter beobachten und gucken, ob die Netzwerker noch etwas finden. Aber im Moment sieht es recht stabil aus.

Eine Frage noch lohnt das upgrade von 5.5.0, 2001466 auf 5.5.0, 2075275 im Sinne von möglichen Fehler fixes oder sollte ich lieber bei der aktuellen Version bleiben?

[2-D]

@JanClaas: gerne...behalte aber bei deinen RDP / VI Client Verbindungen im Hinterkopf, dass beide einen Reconnect im Falle eines VErbindungsabbruchs versuchen...RDP macht (afaik) 10 Versuche. Mit anderen Worte: Vielleicht fällt es dir ja mal zwischendurch gar nicht auf

Was das Update angeht:

Barney Stinson:
Neu ist immer besser...

[JanClaas]

Vielen Dank an all die Antworten.

Update ist durch und die Netzwerker haben ein kleines Leck in einer Weitverkehrsleitung gefunden und gestopft. Nach all den fixes funktioniert das vCenter nun wieder wie erwartet.

[close]