Fejlfinding af en virtuel maskine, der ikke længere svarer

Mål
Denne artikel indeholder trin til at isolere mulige årsager til, at en virtuel vSphere-maskine ikke svarer.

En virtuel maskine, der ikke svarer, reagerer ikke på forbindelsesforsøg og kan muligvis ikke reagere på forsøg på at slukke og slukke for den. Der kan være forskellige årsager til, at en virtuel maskine ender i en tilstand, hvor den ikke reagerer. Denne artikel giver dig mulighed for at identificere og løse disse almindelige årsager og, når det er løst, returnere den virtuelle maskine til en driftstilstand.

Det er muligt at slukke hårdt for en virtuel maskine uden fejlfinding af årsagen, men dette forhindrer indsamling og analyse af oplysninger, der kan hjælpe med at bestemme årsagen til afbrydelsen. 

Fakta
En virtuel maskine, der kører på VMware ESX/ESXi, reagerer ikke på eksternt input eller udviser nogen aktivitet. Specifikt:

• Guest OS reagerer ikke på tastatur- eller museaktivitet ved konsollen

• Guest OS reagerer ikke på netværkskommunikation, herunder ping, RDP, SSH osv.

• Skærmen på konsollen til virtuelle maskiner er statisk og ændres eller opdateres ikke

• Opgaver, der udføres på den virtuelle maskine, mislykkes, får timeout eller starter ikke

• Den virtuelle maskine genererer ikke netværks- eller disktrafik

Løsning
De tjenester, som en virtuel maskine leverer, kan blive utilgængelige eller utilgængelige på grund af en række årsager, herunder problemer med programmerne eller gæsteoperativsystemet i den virtuelle maskine, problemer med den virtuelle maskines skærm eller virtuelle enheder, ressourcestrid på værten eller problemer med underliggende lager- eller netværksinfrastruktur.
Hvis gæsteoperativsystemet producerer en aktivitet, kører den korrekt. I dette tilfælde skyldes manglende respons sandsynligvis et forbindelsesproblem eller ressourcestrid eller er specifik for en komponent på højere niveau, f.eks. et program eller en tjeneste, der kører i gæsteoperativsystemet.

Godkend omfanget:
Det er vigtigt at have nøjagtige symptomer og en forståelse af omfanget af et problem. For at bekræfte problemets omfang skal du gennemgå disse kontroller:

1. Bekræft, at den virtuelle maskine faktisk ikke reagerer. Det er muligt, at den virtuelle maskine ikke reagerer via én grænseflade, men fungerer korrekt på andre. 

2. Kontrollér, at den virtuelle maskine er tændt. Hvis den virtuelle maskine er blevet slukket uventet, skal du tænde den igen og derefter foretage fejlfinding af årsagen til den uventede nedlukning.

3. Find ud af, om dette problem påvirker flere virtuelle maskiner eller kun én. Hvis flere virtuelle maskiner påvirkes, skal du overveje lighederne mellem de berørte virtuelle maskiner, når du forsøger at indsnævre det potentielle omfang. Der skal især fokuseres på delt infrastruktur, som gruppen af berørte virtuelle maskiner er afhængige af, og om alle virtuelle maskiner, der er afhængige af den fælles infrastruktur, påvirkes. 

4. Find ud af, om gæsteoperativsystemet reagerer på interaktion på konsollen til den virtuelle maskine. Hvis et problem er blevet isoleret til gæsteoperativsystemet eller programmerne på den virtuelle maskine, og gæsteoperativsystemet reagerer på konsollen, skal du interagere med gæsteoperativsystemet på konsollen for at løse problemet. 

5. Find ud af, om gæsteoperativsystemet eller dets programtjenester reagerer på interaktion via netværket.

6. Find ud af, om gæsteoperativsystemet har rapporteret kritiske fejl til konsollen og er i en standset tilstand.

7. Find ud af, om ESX/ESXi-værten ikke også reagerer. Hvis værten også ikke reagerer, er omfanget større end oprindeligt antaget.

Identificer årsagen:
På dette tidspunkt har du konstateret, at en eller flere virtuelle maskiner ikke svarer både på den virtuelle konsol og via netværket. Værten selv er lydhør. Der kan være et problem med ressourcetilgængelighed eller -strid eller med underliggende storage- eller netværksinfrastruktur.
Sådan identificeres årsagen:

1. Find ud af, om problemet udløses af en handling eller opgave, der udføres på den virtuelle maskine. For eksempel bedøver snapshot- og vMotion-handlinger begge en virtuel maskine i korte perioder, mens hukommelsestilstanden kopieres over netværket eller til disken.

2. Nogle almindelige konfigurationsfejl kan føre til, at en virtuel maskine ikke svarer, f.eks. mens du venter på en ressource. Gennemse konfigurationen af den virtuelle maskine og værten. 

3. Virtuelle maskiner er afhængige af en funktionel sikkerhedskopieringsinfrastruktur. Hvis der er et problem med sikkerhedskopieringslageret eller netværksinfrastrukturen, som den virtuelle maskine er afhængig af, kan den virtuelle hardware, som en virtuel maskine præsenterer for gæsteoperativsystemet, blive påvirket. Løs det underliggende storage- eller netværksproblem.

4. Virtuelle maskiner er afhængige af tilgængelige værtsressourcer (CPU, hukommelse), og gæsteoperativsystemet bruger disse ressourcer. Et problem med ressourcetilgængelighed eller planlægning i eller uden for den virtuelle maskine kan medføre, at den ikke svarer. Den virtuelle maskine blokerer muligvis også for utilgængelige ressourcer eller roterer ved 100 % vCPU-udnyttelse. 

Handlingsplan:
På dette tidspunkt har du fastslået, at værten, der kører den eller de virtuelle maskiner, både reagerer og ikke støder på problemer med delt lager eller netværksinfrastruktur. Gæsteoperativsystemet har ikke fejlet med en kritisk fejl, men reagerer ikke på den virtuelle maskinkonsol og via netværket.
Foretag handlinger for at gendanne eller indsamle oplysninger om den virtuelle maskine, der ikke svarer, baseret på det arkitektoniske lag, der er mistænkt:

• Hvis et problem er blevet isoleret til gæstens operativsystem, eller %RUN er relativt høj, men den virtuelle maskine skærm fungerer korrekt, flytte undersøgelse til inden for den virtuelle maskines gæst OS eller programmer. Et gæsteoperativsystem kan holde op med at reagere inde i en virtuel maskine på samme måde som på fysisk hardware:

  1. Indsaml ydeevnedata, mens problemet opstår.

  2. Forsøg manuelt at fremkalde panik i kernen inde i gæsteoperativsystemet for at indsamle yderligere oplysninger om dens interne tilstand. Hvis gæsteoperativsystemet producerer nyttige diagnosticeringsoplysninger som svar på en af disse hændelser, skal du kontakte gæstens OS-leverandør for at undersøge sagen nærmere.

  3. Hvis trin 2 ikke giver nyttige oplysninger, skal du suspendere den virtuelle maskine for at indsamle oplysninger om dens interne tilstand og åbne en sag hos VMware Support:

     1. Afbryd den virtuelle maskine, og indsaml .vmss Afbryd tilstandsfil.

     2. Indsaml logfiler fra den vært, der kører den virtuelle maskine.

     3. Tænd den virtuelle maskine igen, og nulstil den derefter.

     4. Kontakt VMware Support ved at levere de oplysninger, der er indsamlet i trin 1, 3a og 3b.

• Hvis et problem er blevet isoleret til den virtuelle maskines skærm, eller %WAIT er relativt høj, eller forsøg på at suspendere den virtuelle maskine er mislykkedes, indsamle ydeevnedata og kraftigt få den virtuelle maskine til at gå ned for at indsamle yderligere oplysninger om dens interne tilstand:

  1. Indsaml ydeevnedata, mens problemet opstår.

  2. Nedbrud den virtuelle maskine for at indsamle oplysninger om dens interne tilstand.

     BEMÆRK: Hvis forsøg på at få den virtuelle maskine til at gå ned mislykkes, skal du springe til næste afsnit og forsøge at få værten til at gå ned.

  3. Kontakt VMware Support ved at levere de oplysninger, der er indsamlet i trin 1 og 2.

• Hvis et problem er blevet isoleret til overvågningen af den virtuelle maskine, men forsøg på at afbryde eller gå ned på den virtuelle maskine mislykkes, afspejler dette et problem med VMkernel. Indsaml et logbundt fra værten, evakuer alle upåvirkede virtuelle maskiner fra værten, og brug et NMI til bevidst at generere en lilla diagnosticeringsskærm:

  1. Indsaml ydeevnedata, mens problemet opstår.

  2. Flyt alle upåvirkede virtuelle maskiner væk fra værten ved hjælp af vMotion. Hvis det er muligt, skal du bruge vedligeholdelsestilstand til at forhindre, at der startes yderligere virtuelle maskiner på værten.

  3. Konfigurer værten til at gå i panik, når der modtages en afbrydelse, der ikke kan maskeres, og udsted derefter en NMI for at udløse panik.

  4. Når værten har genereret en lilla diagnosticeringsskærm og fuldført dump af diagnosticeringsoplysninger, skal du tage et skærmbillede eller et billede af konsollen og genstarte værten.

  5. Indsaml diagnosticeringsoplysninger fra værten.

  6. Kontakt VMware Support ved at levere de oplysninger, der er indsamlet i trin 1, 4 og 5.

Relaterede artikler
VMware KB-1007819: https://kb.vmware.com/kb/1007819