VMware-Forum

moin,
ich möchte diverse ESXi 5.x Server an verschiedenen Standorten über WAN an das VCenter 5.5 anbinden, lediglich für Administration und Monitoring.

Das initiale Verbinden klappt auch, der esxi Server und die VMs werden im VC registriert. Nach einigen Minuten werden die Verbindungen aber regelmäßig getrennt und die Server müssen manuell reconnected werden, was dann auch klappt.

Die Vermutung liegt nahe, dass es an der WAN Strecke liegt, denn an anderen Standorten mit SEHR fetten Leitungen klappt das über WAN zuverlässig. Nur an kleineren Standorten mit schmaleren Leitungen kommt es zu dem Beschriebenen Problem.

Die Latungsqualität sollte aber dennoch ausreichen, denn ansonsten sehr sensible Terminal Server Verbindungen laufen ohne Probleme.

Ich habe das Dokument hier gefunden, https://communities.vmware.com/docs/DOC-11492
darin werden Verbindungen von 128kps angegeben, das ist deutlich weniger als hier zur Verfügung steht.

Was kann also das Problem sein und wie kann ich das korrigieren? Gibt es Timeouts am VC die ich einstellen kann?

Firewall kann er m.E. auch nicht sein, denn die initiale Verbindung klappt, reconnects auch, aber dennoch werden die Verbindungen getrennt.

Danke
Georg

Verlieren sie IMMER kurz nach dem einbinden den Kontakt oder nur ab und zu?

Gruss
Joerg

eigentlich recht schnell nach dem Connecten, jetzt wo du fragst, eigentlich immer nach dem einbinden oder reconnecten.
ich hab das jetzt an drei Standorten mit je 2 Hosts. Fünf werden immer getrennt, interessanterweise ist ein sechster Host an einem dieser Standorte verbunden geblieben...kann in diesem Fall also nicht wirklich an der Verbindung liegen...

Muss eingestehen, ich versuche etwas gerade zu biegen, was ein andere Kollege angefangen hat, d.h. es sind nicht meine Hosts, sondern die, die ein Kollege eingerichtet hat. Das Vcenter läuft seit Monaten stabil mit etlichen anderen Hosts im zentralen RZ, das sind meine Hosts! Könnte also auch an den esxi Servern liegen.

Die Niederlassungen waren eigentlich nicht für den Betrieb von Servern vorgesehen gewesen, könnte also auch die FW sein, erklärt aber nicht die nachträgliche Trennung nach dem ersten Aufbau (Port Hopping im Nachhinein?) und auch nicht warum EINER der Hosts läuft.

Hast du ne Ahnung was das sein könnte?

Hast Du schon überprüft, daß alle Adressen der Systeme im DNS vorwärts und rückwärts korrekt aufgelöst werden können?
Wenn die Einträge im DNS nicht komplett bzw. korrekt sind, gibt es ähnliche Effekte.

DNS war mein erster Gedanke, der Kollege sagt das passt, wollen wir hoffen, dass der das richtig gecheckt hat.

IRIX Frage hat mich aber auf einen Gedanken gebracht und dabei habe ich das gefunden

ESXi/ESX host disconnects from vCenter Server 60 seconds after connecting
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1029919

Die ESXi Hosts müssen UDP 902 zum VCenter machen können, das ist garantiert nicht in der FW konfiguriert, lasse das gerade von den Netzwerkern überprüfen.

EDIT: das wars, Netzwerker gerade UDP 902 frei geschaltet und alles Host wurden automatisch connected

Danke Joerg für den Denkansroß

Ich wollte es laut herausrufen aber ich hab heute vormittag im Auto gesessen und da hoert mich keiner schreien

vCenter benutzt Port 443 fuer die Erstkontaktaufnahme welche den vpxa initialisiert sowie ihm auch die Adresse des vCenter uebergibt. Nun startet der vpxa und will dem vCenter Daten schicken welches drauf wartet. Das tut es ca. 1-2 Minuten und wenn nichts kommt dann sagt er wieder disconnected. Das heist die Netzwerker muessen den Port aus der Richtung vom Host zum vCenter freigeben.

Gruss
Joerg

Ich muß hier nochmal nachhacken...

ich hab es letztes WE geschafft, VCenter zum laufen zu bringen.
Habe alle Systeme erstmal auf die Testversion wieder umgestellt und verbunden.
Beim localhost ist alles einwandfrei verlaufen (VCenter läuft auch auf localhost).

Die Kiste die in meiner 2t Wohnung läuft hab ich auch mit hängen und würgen hinbekommen. Hier ist/war NAT das Problem. Verbinden ging anfänglich... aber nach einer Minute gabs n Disconnect.

Die einfache Lösung war hier:


Diese Woche hab ich bei Hetzer n Testserver bestellt wo ESXi drauf läuft. Sprich: Das Teil steht nun im RZ.
Habe die gleichen Einstellungen in xvpa.cfg vorgenommen wie bei der Kiste, die in meiner 2t Wohnung läuft. Nur hier klappt es nicht. Das ding bleibt Disconnectet.
Stell ich von dynvpn.de um auf die statische IP, dann klappt es. Nur alle 24h ne neue IP einzutragen ist natürlich sinnfrei.

pinge ich von der Shell (im RZ) auf die dynvpn.de Addy, dann wird es korrekt aufgelöst.
Was kann das liegen?

Weiß einer Rat oder hat Ideen ?

Bist du dir sicher, daß alle UDP/TCP-Ports beim Ping auf ****.dynvpn.de auch wirklich weitergeleitet werden?
Je nach DDNS-Anbieter werden meist nur die üblichen Web- und Email-Ports sprich 80 bzw 443 und 25 bzw 587 weitergeleitet. Da nicht alle Anbieter zumindest in der kostenlosen Version dafür eine Config-Möglichkeit anbieten, heißt es hier variabel bleiben und notfalls mehrere Anbieter nutzen. Bei einigen Anbietern hat man als langjähriger, auch kostenloser Kunde zudem noch einige Einstellungen, die einem Neukunden überhaupt nicht mehr angeboten werden.

Wenn man um diese Besonderheiten weiß, verringert dies unter Umständen auch die Angriffsfläche, da ja nicht jeder x-beliebige Port weitergeleitet wird. Von daher stellt sich für mich die Frage, ob bei deinem Ping auch wirklich dein "Rechner" oder nicht dein DDNS-Anbieter antwortet. Mit einem reinen Ping-Versuch kannst du das jedenfalls nicht feststellen.

Hab mich heute nochmal mit den Thema beschäftigt.

Hab's nun hinbekommen und den "schuldigen" gefunden.

Es war der DNS Server.
Das hatte ich eigendlich schon ausgeschlossen, indem ich ein Ping auf meine dyndns-Adresse tätigte. Diese wurde korrekt aufgelöst. Also ging ich von einer korrekten Arbeitsweise aus.

ABER... ich hab's grad mal auf die google namesserver umgestellt (8.8.8.8 und 8.8.4.4)... und siehe da... in VCenter war der Server nun ohne mein zutun wieder connected.

Für die, die das gleiche Problem haben.... erstmal auf die google-NS umstellen.
Kann man ja später wieder ändern, sofern man damit das Problem gefunden hat.