Tijdens een "rolling upgrade" (dus met maintenance mode etc) van onze ESX hosts van versie 3.5.0, 143128 naar versie 3.5.0, 153875 (dus update 4) deed DRS een vmotion van VM's naar een geupgrade ESX host, waarbij van enkele Windows 2003 R2 SP2 VM's de netwerkverbinding (flexible) wegviel. Kon enkel hersteld worden door binnen Windows de netwerkverbinding (die overigens keurig op connected stond) te disablen en daarna weer te enablen.

Bij verreweg de meeste VM's ging het goed, al hadden sommigen nog een zeer oude versie VMware Tools build 55869 uit 2007.
Dus aan de versie VMware Tools ligt het ook niet zou je zo zeggen.
En hoewel up-to-date houden van je VMware Tools versie natuurlijk aanbevolen wordt, lijkt ook dat geen garantie voor succes.

DRS staat bij ons op fully automated en agressive, we hebben 2 clusters van elk 4 ESX 3.5 hosts met 200 VM's en de vmotion teller staat inmiddels op 4177 succesvolle migraties.

Wie komt dit bekend voor, en waar zou het aan kunnen liggen?

Zal eens gaan testen met een 2 tal machines. Ben het tot nu toe nog niet tegen gekomen. Wel is het zo dat al men vmware tools up to date zijn.

Vast bedankt. Het probleem lijkt OS onafhankelijk te zijn want het komt ook voor bij Linux VM's. De eerste cluster van 72 VM's had hier overigens geen enkel probleem mee, maar heeft andere hardware (4x HP Proliant DL585 G1 met AMD Opterons 850 (4CPU) en 885 (8CPU)) dan cluster 2 (4x HP Proliant DL580 G5 16CPU Xeon X7350).

Zal onze dl580g5 met xeon 7340 van het weekend een update geven kijken of het probleem daar op voor komt.

KAn het namelijk op de dl380's niet reproduceren

NEt een update gedaan van de 2 580's. Geen problemen.

Drs op aggresive gezet en op fully automated. Geen problemen.

esx 3.5 U3 machines uitgezet en laten vmotionen. Geen problemen.

esx 3.5 u2 machines uitgezet en laten vmotionen. Geen problemen

Ik heb geen idee waardoor het komt. MOgelijk toch door de Vmware tools? Deze zijn bij ons altijd op het 1 na laatste lvl gehouden

Vreemd. Kon ik het op een of andere manier maar betrouwbaar reproduceren. In elk geval bedankt voor het testen en mooi dat het bij jou wel werkt.

Ik denk dat we gaan kijken of het probleem weg blijft als we VMware Tools up-to-date houden. Of andersom: een VM vinden met up-to-date VMware Tools die bij ons toch niet goed migreert.

Inderdaad. Hopelijk bied dat de oplossing.

Ben nog wat aan het testen geweest met migraties maar ik krijg het probleem niet gereproduceerd. zelfs niet met verschillende cpu's en of het hard uitzetten van een esx machine.

We hebben het probleem gevonden. Een van de vier vmnics in de portgroup voor VMs bleek geen observed IP range meer te hebben. Na disablen en enablen (tijdens maintenance mode) hiervan was de observed IP range weer gelijk aan die van de andere 3 vmnics in deze portgroup. Network failure detection hebben we naar aanleiding hiervan aangepast van Link Status Only naar Beacon Probing, maar de tijd zal leren of we daar goed aan doen. Volgens wat ik nu net lees in de VI3 Advanced Technical Design Guide and Advanced Operations Guide wordt dit zelden gebruikt en niet aanbevolen voor produktie-omgevingen.
Nogmaals bedankt voor het testen.

En bedankt voor het melden van de oorzaak.. ik gebruik het niet maar voor anderen toch wel handig dat het hier staat zodat er rekening mee gehouden kan worden.

Om nog terug te komen we hebben hier nu 2 machines waar we het op hebben kunnen reproduceren. Meest vervelende was na verloop van tijd loste het zichzelf op. Bleek ook te maken te hebben met de observed range.

Hoi,
Hier ook wat netwerk perikelen met update 4. Vers geinstalleerd op een ml110 testbak. Het begon met uitvallende vi client verbindingen. Toen bleek vanaf verschillende machine's pingen naar de service console wisselend succes en uitval te geven. Uiteindelijk maar eens de firewall uitgezet en het probleem is niet meer voor gekomen
Vreemd, of niet? Morgen weer eens verder testen....

gr -frank-