[VMWARE] VM host migration fails

[dotacom]

Op mijn stage mag ik meehelpen aan het ondersteunen van een VMWare omgeving met 3 hosts waarbij DRS & Vmotion opgezet is. Doordat er hardware problemen waren met 1 host, moesten alle VM's op die 1e host overgeheveld worden naar de andere hosts.

Waren in totaal een tiental VM's maar bij 1 VM ging het fout. vCenter rapporteerde nogtans dat host migration completed was maar de VM zelf reageerde niet meer. Pingen hielp niet. De console overnemen via vCenter werkte ook niet.

Vind het niet gemakkelijk om dit probleem via google te troubleshooten omdat in vCenter duidelijk te zien was dat migration completed was. Hierdoor heeft het ook niet om vCenter logs na te gaan. Belangrijk om weten is dat het om een vSphere 5.5 omgeving gaat. Het enige merkbare verschil tussen die 1e VM die failde en de andere is dat deze aanzienlijk meer RAM toegewezen heeft. (32 GB) Google zoektoch over problemen om VM's te migreren met "veel" ram leverden weinig tot niets op.

Mensen hier met ervaring die mij kunnen sturen in de goeie richting om dit probleem correct aan te pakken? Het is ook niet echt mogelijk om overdag de VM migration te testen omdat deze als database server fungeert voor een professionele omgeving.

[Room42]

Wat is de foutmelding?

Wat is de status van de VM? Kun je hem uit zetten/herstarten? Heeft ie snapshots? Is alle gekoppelde media (harddisk, CD) op shared storage opgeslagen?

[3DDude]

Wat heb je zelf opgezocht?
Je snapt hoe Live migration werkt?
Hoeveel resources zijn er op de host waar je naartoe hebt gemigreerd nog vrij?
Je zegt dat de VM niet up komt, wat bedoel je daarmee? kan je er niet naar RDP'n/telnet/ssh/vnc/enz.. ?
Pingen hielp niet ? wat bedoel je daarmee ? dat je het ip adres niet kan pingen?

Ik vind het een onduidelijk verhaal.

Maak eens helder wat je precies bedoelt en een lijstje met de punten die je reeds geprobeerd hebt?

[dotacom]

3DDude schreef op donderdag 05 juni 2014 @ 01:09:
Wat heb je zelf opgezocht?
Je snapt hoe Live migration werkt?
Hoeveel resources zijn er op de host waar je naartoe hebt gemigreerd nog vrij?
Je zegt dat de VM niet up komt, wat bedoel je daarmee? kan je er niet naar RDP'n/telnet/ssh/vnc/enz.. ?
Pingen hielp niet ? wat bedoel je daarmee ? dat je het ip adres niet kan pingen?

Ik vind het een onduidelijk verhaal.

Maak eens helder wat je precies bedoelt en een lijstje met de punten die je reeds geprobeerd hebt?

De host naar waar werd gemigreerd had zeker nog voldoende resources om die VM in kwestie te kunnen draaien. Dit heb ik eerst en vooral getest.

Met niet up komen, bedoel ik inderdaad dat er niets van RDP/TELNET/SSH/VNC/Ping kan uitgevoerd worden. Deze zaken falen allemaal waardoor het lijkt of de VM gewoon af staat. Toch staat deze powered on in de vCenter console en actief onder de nieuwe host al.

Ik heb vooral gericht zitten zoeken naar iemand die hetzelfde probleem tegenkwam maar levert haast geen zoekresultaten op. Ik vind wel veel zaken terug waarbij vm migration faalt en dat ook duidelijk wordt weergegven in vCenter. In mijn geval zegt vCenter dat de VM migration completed is.

[dotacom]

Room42 schreef op donderdag 05 juni 2014 @ 01:09:
Wat is de foutmelding?

Wat is de status van de VM? Kun je hem uit zetten/herstarten? Heeft ie snapshots? Is alle gekoppelde media (harddisk, CD) op shared storage opgeslagen?

De HDD is inderdaad op shared stage opgeslagen. Hiervoor is een ISCSi volume aangemaakt op een SAN. Dat volume wordt trouwens nog door andere VM's gebruikt als HDD. in vCenter staat de vm powered on maar zoals reeds gezegd reageert deze niet meer.

[Room42]

En de foutmelding bij het migreren...? Zie ook de events van de VM.

[|sWORDs|]

Weet je zeker dat de VM niet hing voor de migration? Welk OS draait op die VM?

Edit: ik zie nu ook iSCSI staan. Gebruik je gescheiden nics voor storage en vMotion?

[ Voor 36% gewijzigd door |sWORDs| op 05-06-2014 01:59 ]

[Room42]

Ik neem aan dat er geen storage vmotion is gedaan op het moment dat het misging.

[|sWORDs|]

Evanescent, dat maakt niet veel uit, vMotion vult zonder problemen een 10Gbit link volledig en dan wil storage wel eens weggedrukt worden, als deze op dezelfde nic zonder NetIOC zit, iets waar niet elk OS even goed tegen kan. Ook zie je heel soms tijdens de guesttrace of switch over sommige os-en het echt niet leuk vinden. Met name de guesttrace problemen komen met vSphere 5 eigenlijk niet meer voor, net als de problemen amdersom, voorheen kon het voorkomen dat het geheugen van de vm sneller bijgewerkt werd dan te vMotion-en was, versie 5 zet dan gewoon de rem op de virtuele machine, waardoor dus belasting door storage meer voor vertraging zorgt dan voor fouten.

[ Voor 30% gewijzigd door |sWORDs| op 05-06-2014 02:26 ]

[Room42]

Ah juist, goed punt. Dat zag ik even over het hoofd.

[dotacom]

|sWORDs| schreef op donderdag 05 juni 2014 @ 01:57:
Weet je zeker dat de VM niet hing voor de migration? Welk OS draait op die VM?

Edit: ik zie nu ook iSCSI staan. Gebruik je gescheiden nics voor storage en vMotion?

Alle ISCSi traffic zit op een aparte vswitch waaraan 2 vmnic's zijn aan gekoppeld.
Voor vMotion is ook een aparte vswitch voorzien ook met 2 vmnic's aan gekoppeld.
En de VM hing 100% zeker niet. De VM is een centrale database server die voor 15 vestigingen actief wordt gebruikt. Als deze 1min uitvalt, stromen de telefoontjes al binnen

[dotacom]

Room42 schreef op donderdag 05 juni 2014 @ 01:44:
En de foutmelding bij het migreren...? Zie ook de events van de VM.

Daar zit hem net de "moeilijkheid" om dit probleem te troubleshooten. Ik zie alleen een host migration completed event opgewerpt worden. Niets à la host migration failed wat het troubleshooten toch ietwat zoe vergemakkelijken.

[|sWORDs|]

dotacom schreef op donderdag 05 juni 2014 @ 10:42:
[...]


Alle ISCSi traffic zit op een aparte vswitch waaraan 2 vmnic's zijn aan gekoppeld.
Voor vMotion is ook een aparte vswitch voorzien ook met 2 vmnic's aan gekoppeld.
En de VM hing 100% zeker niet. De VM is een centrale database server die voor 15 vestigingen actief wordt gebruikt. Als deze 1min uitvalt, stromen de telefoontjes al binnen

Het gaat me niet om de virtuele switches en nics, maar de fysieke. (Waarvan de nics nu ietsje duidelijker zijn)
Geef eens wat meer info over de hosts (type nr's, geheugen, cpu's en nic config) en de VM (os en versie) die hing.

Voor vMotion van 32GB zou je trouwens minimaal 4 gigabit nics alleen voor vMotion moeten gebruiken om binnen de recommended configuratie te zitten. Voor iSCSI is sowieso 10Gbit aan te bevelen. (Maar beide zouden alleen voor traagheid moeten zorgen, niet voor een hangende VM.)

[ Voor 19% gewijzigd door |sWORDs| op 05-06-2014 11:31 ]

[StarWing]

Aangezien je over vmotion spreekt, vermoed ik dat je 'm live gemigreerd hebt.
Heb je de guest al eens een harde reset gegeven ?

[dotacom]

StarWing schreef op donderdag 05 juni 2014 @ 11:26:
Aangezien je over vmotion spreekt, vermoed ik dat je 'm live gemigreerd hebt.
Heb je de guest al eens een harde reset gegeven ?

Inderdaad live migratie.
En bij het doorvoeren van een harde reset reboot de vm zonder problemen.

[Equator]

Even een hele knullige vraag: Heeft de host waar je de VM naar gemigreerd hebt wel het juiste VLAN ter beschikking?
Ik bedoel, als dat specifieke VLAN niet in de trunk naar deze host zit, of zelfs naar de switch waarop de fysieke host is gekoppeld dan is die VM gewoonweg niet toegankelijk.

[dotacom]

Equator schreef op donderdag 05 juni 2014 @ 14:17:
Even een hele knullige vraag: Heeft de host waar je de VM naar gemigreerd hebt wel het juiste VLAN ter beschikking?
Ik bedoel, als dat specifieke VLAN niet in de trunk naar deze host zit, of zelfs naar de switch waarop de fysieke host is gekoppeld dan is die VM gewoonweg niet toegankelijk.

Ja, dat is het geval.
2 andere servers die op dezelfde vlan zitten (en in hetzelfde domein) konden wel perfect migreren naar de andere host zonder problemen. Ik denk nog steeds dat het misloopt door het hoge RAM geheugen dat deze VM toegewezen krijgt itt de andere VM's.

[xares]

Clone maken van de VM en het testen?
Gaat het met de clone ook fout? Geef je de clone minder geheugen en je test het nog eens.

[Question Mark]

dotacom schreef op donderdag 05 juni 2014 @ 15:07:
[...]
Ik denk nog steeds dat het misloopt door het hoge RAM geheugen dat deze VM toegewezen krijgt itt de andere VM's.

Waar is dit op gebasseerd? Ik beheer meerdere VM's met dergelijke geheugentoewijzingen en dat is nog nooit een probleem geweest.

dotacom schreef op donderdag 05 juni 2014 @ 01:04:
Vind het niet gemakkelijk om dit probleem via google te troubleshooten omdat in vCenter duidelijk te zien was dat migration completed was. Hierdoor heeft het ook niet om vCenter logs na te gaan.

Wat zeggen je VM specifieke logs die VSphere aanmaakt? Controleer ook de logs binnen de VM zelf (bv. de Windows eventviewer indien het om een Windows guest gaat).

[Bor]

Een VM met 32 GB Ram is niets bijzonders. Daar zou het niet aan mogen liggen. Ik zelf zal eerst ook aan het missen van netwerk config op de edge te denken maar gezien de console vanuit vmware zelf ook niet meer reageert lijkt de vm idd gewoon compleet te hangen. Heeft deze VM wel de vmware tools goed draaien? Hoe is je failover policy op het netwerk ingesteld? Doe je een arp release bijvoorbeeld? Zitten deze hosts allemaal op dezelfde switch?

[CAPSLOCK2000]

Je zal toch echt de esx/vcenter/vm logs in moeten in de hoop dat je daar een hint kan vinden.

[|sWORDs|]

En het is veel makkelijker mee denken als je de vragen zou beantwoorden.

[ Voor 6% gewijzigd door |sWORDs| op 05-06-2014 17:28 ]

[DJSnels]

Kun je niet gewoon een kopie van de vmdk maken, en deze disk aan een nieuwe VM hangen? Dan kun je hem in ieder geval gewoon booten. Eventuele netwerk (VLAN) issues kom je mbv de console wel uit.

[Question Mark]

De VM boot na een herstart prima. De TS wil gewoon weten waarom de vmotion aktie gezorgd heeft voor een niet reagerende VM.