ESXi Host niet te managen vanuit vsphere

[Meekoh]

Even voor de duidelijkheid, ik ben niet op zoek naar een oplossing maar wil even weten of dit echt zo gaar is als ik denk.

Goed Klant X heeft een ESXi cluster met VSphere(of Vcenter, whatever) en alle HA rommel gekocht/enabled.
Nu dient de situatie zich aan dat ESXi Host Y om een of andere reden niet meer te beheren is via VSphere. Schijnt een bekend probleem te zijn en een reboot van Host Y lost dit op.
Echter daarvoor moeten alle VM's(De VM's werken gewoon naar behoren) die dan op Host Y draaien worden uitgezet. Want volgens de ESX beheerders, werkt Vmotion vanuit VSphere en aangezien VSphere geen verbinding meer heeft met Host Y kunnen ze de VM's niet ervanaf krijgen zonder downtijd.

Nu denk ik gelijk: Wat is dit voor retarded HA oplossing? Bij een probleem tussen Host en VSphere server kun je gelijk niet meer Vmotionen?

Is er ook echt geen mogelijkheid om die VM vanaf de console van de host zelf te Vmotionen zonder downtijd?
Bij Hyper-V kan dat gewoon...

[Craven]

Voor zover ik weet kan dat niet. Wat je wel kan proberen is de management agents rebooten vanuit de console van de esx host. Via die management agents verbind je esx bak met vsphere dus je hebt een grote kans dat dit het ook oplost.

[ComBax]

Wat bedoel je met 'niet meer te beheren'?
Dat ben ik nog niet tegengekomen tot nu toe en we hebben hier wel een aantal ESXi hosts draaien.
Wat wel al is voorgevallen, is dat de ESXi host op disconnected stond. Deze kan je dan gewoon weer reconnecten (moet je wel het root-wachtwoord voor weten).

[Meekoh]

ComBax schreef op vrijdag 26 juni 2015 @ 13:29:
Wat bedoel je met 'niet meer te beheren'?
Dat ben ik nog niet tegengekomen tot nu toe en we hebben hier wel een aantal ESXi hosts draaien.
Wat wel al is voorgevallen, is dat de ESXi host op disconnected stond. Deze kan je dan gewoon weer reconnecten (moet je wel het root-wachtwoord voor weten).

Geen idee, de beheerders van die omgeving zeggen dat ze vanuit Vsphere niets meer kunnen doen met die host. Ik neem even voor het gemak aan dat ze dat al geprobeerd hebben.

Waar het mij meer om gaat is het feit dat men uberhaupt niet kan vmotionen zodra er iets met Vshpere, de agent op de Host of de communicatie tussen beide aan de hand is. Ik heb veel meer ervaring met Hyper-V en daar kun je altijd een VM live migreren. Het enige dat je nodig hebt is communicatie tussen Host A en Host B en toegang tot de commandline/powershell. Dus van daar dat ik dit een beetje een rare HA oplossing vind.

[ Voor 3% gewijzigd door Meekoh op 26-06-2015 13:37 ]

[CAPSLOCK2000]

Klopt, je hebt vCenter nodig om de coordiantie tussen de ESXi's te verzorgen. Zonder vCenter geen vmotion. De ESXi systemen zijn helemaal zelfstandig. Alles was tussen verschillende servers speelt loopt via vCenter.

De management agents herstarten op de weigerachtige ESXi zou ook mijn eerste herstelpoging zijn. Moet je daar wel toegang tot hebben.

[ Voor 18% gewijzigd door CAPSLOCK2000 op 26-06-2015 13:39 ]

[Question Mark]

Meekoh schreef op vrijdag 26 juni 2015 @ 13:23:
Schijnt een bekend probleem te zijn en een reboot van Host Y lost dit op.

Ik doe veel met VSphere en ken deze issue totaal niet. Het lijkt me dan ook geen bekend probleem, maar meer iets wat ligt aan de inrichting bij de klant.

• Welke versies gebruiken ze? Zowel VCenter als VSPhere
• Hoe staan de firewalls ingesteld?
• Wat gebeurdt er als je de management agents herstart?

Meekoh schreef op vrijdag 26 juni 2015 @ 13:36:
[...]
Geen idee, de beheerders van die omgeving zeggen dat ze vanuit Vsphere niets meer kunnen doen met die host.

Vraag het na... Een host die "disconnected" is binnen VSPhere, is iets anders dan een host die simpelweg niet meer reageerd.

Ik neem even voor het gemak aan dat ze dat al geprobeerd hebben.

Vraag het even na, dan weet je het zeker...

Dus van daar dat ik dit een beetje een rare HA oplossing vind.

VMotion is dan ook geen HA.
HA werkt wel zonder tussenkomst van VSPhere.

[ Voor 38% gewijzigd door Question Mark op 26-06-2015 13:43 ]

[Meekoh]

Question Mark schreef op vrijdag 26 juni 2015 @ 13:40:
[...]

Ik doe veel met VSphere en ken deze issue totaal niet. Het lijkt me dan ook geen bekend probleem, maar meer iets wat ligt aan de inrichting bij de klant.

• Welke versies gebruiken ze? Zowel VCenter als VSPhere
• Hoe staan de firewalls ingesteld?
• Wat gebeurdt er als je de management agents herstart?

[...]
Vraag het na... Een host die "disconnected" is binnen VSPhere, is iets anders dan een host die simpelweg niet meer reageerd.

[...]
Vraag het even na, dan weet je het zeker...

[...]

VMotion is dan ook geen HA.
HA werkt wel zonder tussenkomst van VSPhere.

Ik zal eens informeren bij het betreffende beheerders clubje om wat meer details. Echter was het nu een mededeling van: "Wij moeten die host booten om deze reden, dus zorg dat je VM uit is op tijdstip X".
Heb dus zelf ook niet echt toegang tot die omgeving, alleen mijn VM.

VMotion is inderdaad geen HA, het is echter wel een middel om Hoge Beschikbaarheid te bieden aan je gebruikers wanneer er onderhoud moet worden gepleegd aan een host.

Maar er is dus geen manier om je VM te verkassen zonder downtijd als de host niet bij zijn vsphere server kan komen om een of andere reden, correct?

[Question Mark]

Meekoh schreef op vrijdag 26 juni 2015 @ 14:08:
[...]
Maar er is dus geen manier om je VM te verkassen zonder downtijd als de host niet bij zijn vsphere server kan komen om een of andere reden, correct?

Klopt, de management agent moet verbonden zijn met de VCenter server. Even de agent herstarten en het zou weer moeten werken, daarvoor hoeft de hele host niet down.

Overigens is Hyper-V hier niet anders in. Als de Clustering Service op een Hyper-V host geen verbinding meer kan maken met een andere host, kun je ook geen live migration uitvoeren.

Verder moet deze issue natuurlijk zo snel mogelijk opgelost worden. Dit is geen known issue, men moet gewoon een supportcall aan laten maken bij VMWare. Daar wordt ook dik voor betaald overigens. En mijn ervaringen met VMWare support zijn redelijk erg goed, mits aan alle requirements voldaan is (supported hardware, firmware/bios versies en software up-to-date).

[ Voor 5% gewijzigd door Question Mark op 26-06-2015 14:16 ]

[Meekoh]

Question Mark schreef op vrijdag 26 juni 2015 @ 14:13:
[...]
Overigens is Hyper-V hier niet anders in. Als de Clustering Service op een Hyper-V host geen verbinding meer kan maken met een andere host, kun je ook geen live migration uitvoeren.

Nope, twee losse Hyper-V hosts kunnen altijd live migreren zolang er maar een netwerk connectie is tussen beide (Server 2012 R2). Als het binnen een Cluster is en de cluster service is gecrasht, dan kan het nog steeds. Het cluster zal wel even niet meer snappen waar die VM nou heen is (moet je handmatig fixen), maar die VM is gewoon zonder downtijd verkast.

[DJSnels]

Dit ben ik links en rechts wel eens vaker tegengekomen. Je kunt dan inderdaad het beste de services herstarten via SSH:
# services.sh restart

De VMs blijven gewoon doordraaien, en na een herstart van de services kun je ze moven om de host te onderzoeken (en down te brengen).

[Meekoh]

Na navraag blijkt dat de Host agent "hangt". Is het dan niet gewoon een kwestie van process killen en service starten? Of denk ik nu te simpel in windows termen?

edit:
Nog meer info, dit schijnt het probleem te zijn:
http://kb.vmware.com/self...playKC&externalId=1007261
Volgens VMWare support is rebooten de enige optie...

[ Voor 40% gewijzigd door Meekoh op 26-06-2015 16:07 ]

[Kavaa]

Heb dit ook wel eens gehad, en een restart van de MGMT Agent (services.sh restart kan ook) en het werkte voor mij toen weer dus geen reboot van de Host.

Laat ze dat een proberen kan nooit kwaad de VM's gaan er niet van down.

[CAPSLOCK2000]

Meekoh schreef op vrijdag 26 juni 2015 @ 16:02:
Na navraag blijkt dat de Host agent "hangt". Is het dan niet gewoon een kwestie van process killen en service starten? Of denk ik nu te simpel in windows termen?

edit:
Nog meer info, dit schijnt het probleem te zijn:
http://kb.vmware.com/self...playKC&externalId=1007261
Volgens VMWare support is rebooten de enige optie...

Dat KB artikel geeft de oplossing voor het probleem. Maar goed, veel zin heeft het niet om dit verder uit te zoeken als jij niet achter de knoppen zit.

[Meekoh]

CAPSLOCK2000 schreef op maandag 29 juni 2015 @ 13:12:
[...]


Dat KB artikel geeft de oplossing voor het probleem. Maar goed, veel zin heeft het niet om dit verder uit te zoeken als jij niet achter de knoppen zit.

Inderdaad, echter men heeft dus geprobeerd dat proces van die agent te killen. Echter zonder success, volgens VMWare support was dit de enige oplossing...

[Craven]

Heb jij vmware support aan de lijn gehad of de externe partij? Zal niet de eerste keer zijn dat een externe partij maar wat verzint.