oVirt Host Nede? Din Fejlfindingsguide

Et pludseligt strømsvigt kan skabe kaos i selv de mest velorganiserede IT-miljøer. Når strømmen endelig vender tilbage, og du logger ind på din oVirt-administrationskonsol, er det sidste, du ønsker at se, en host, der er markeret som utilgængelig. En virtuel maskine er måske strandet, og panikken begynder langsomt at indfinde sig. Skal du fjerne hosten fra klyngen og tilføje den igen? Skal du genstarte? Denne situation er desværre alt for almindelig for administratorer af selv-hostede virtualiseringsmiljøer. Men frygt ej. Denne artikel er din førstehjælp til at diagnosticere og løse problemer med oVirt-hosts, så du kan bringe dit miljø tilbage til en sund og operationel tilstand.

Vi vil dykke ned i de mest almindelige fejlstatusser, give dig konkrete fejlfindingstrin og afklare, hvornår drastiske skridt som at fjerne en host er den rigtige løsning. Lad os starte med at forstå, hvad oVirt forsøger at fortælle dig.

Forstå Host-Status: Forskellen på "Non-Responsive" og "Non-Operational"

Når en host ikke fungerer korrekt, bruger oVirt primært to statusser til at beskrive problemet: 'Non-Responsive' og 'Non-Operational'. At kende forskellen er afgørende for at kunne løse problemet effektivt, da de peger på vidt forskellige årsager.

Non-Responsive

En 'Non-Responsive' status er den mest kritiske af de to. Den betyder, at oVirt Engine (den centrale styringsenhed) slet ikke kan kommunikere med VDSM-tjenesten (Virtual Desktop and Server Manager), som kører på hosten. Kommunikationen er fuldstændig brudt. Årsagerne er typisk relateret til grundlæggende infrastruktur:

• Netværksproblemer: Et netværkskabel er taget ud, en switch er nede, eller der er en forkert netværkskonfiguration (VLAN, IP-adresse).
• Firewall: En firewall på hosten, i netværket eller på oVirt Engine blokerer for den nødvendige trafik.
• VDSM-tjenesten er nede: Tjenesten på hosten er crashet, stoppet eller kan ikke starte korrekt efter en genstart.
• Hosten er slukket: Den mest simple årsag – hosten er slet ikke tændt eller er gået ned på grund af en hardwarefejl.

Non-Operational

En 'Non-Operational' status er mindre alvorlig, men kræver stadig handling. Her kan oVirt Engine godt kommunikere med VDSM-tjenesten på hosten, men hosten kan ikke udføre sine opgaver korrekt. Der er en konfigurationsfejl, som forhindrer den i at være et fuldt funktionelt medlem af klyngen. Almindelige årsager inkluderer:

• Lagerproblemer: Hosten har mistet forbindelsen til et eller flere storage domains. Uden adgang til lageret kan den ikke starte eller administrere virtuelle maskiner.
• Certifikatproblemer: SSL-certifikaterne, der bruges til sikker kommunikation mellem Engine og host, er udløbet eller korrupte.
• Klyngekonfiguration: Der er uoverensstemmelser i konfigurationen mellem hosten og den klynge, den tilhører (f.eks. forskellige CPU-typer uden korrekt opsætning).

Sammenligningstabel

For at give et hurtigt overblik er her en direkte sammenligning:

Trin-for-Trin Fejlfinding af en "Non-Responsive" Host

Lad os tage udgangspunkt i scenariet med et strømsvigt. Din host er nu 'Non-Responsive'. Her er en systematisk tilgang til at finde og løse problemet.

Trin 1: Grundlæggende Netværksdiagnostik

Start med det mest basale. Kan oVirt Engine overhovedet nå hosten på netværket? Log ind på din oVirt Engine-server via SSH og udfør disse simple tests:

• Ping hosten:ping din-host-ip-adresse. Hvis du ikke får svar, er der et fundamentalt netværksproblem. Tjek fysiske kabler, switches og om hosten rent faktisk er tændt og har bootet færdig. oVirt Engine venter typisk i to minutter, før den markerer en host som 'Non-Responsive', så giv den tid til at starte op.
• Tjek DNS: Hvis du bruger hostnavne, så verificer, at navneopløsning fungerer korrekt: nslookup din-host.dit-domæne.
• SSH-adgang: Prøv at logge ind på hosten med SSH: ssh root@din-host-ip-adresse. Hvis du kan logge ind, er netværket i orden, og problemet ligger sandsynligvis hos VDSM-tjenesten eller en firewall.

Trin 2: Verificer VDSM-tjenesten

Hvis du kan SSH'e til hosten, er næste skridt at tjekke status på VDSM. Det er hjertet i oVirt-hosten, som Engine kommunikerer med.

Kør følgende kommando på hosten:

systemctl status vdsm

Hvis tjenesten ikke kører ('inactive' eller 'failed'), så prøv at starte den manuelt:

systemctl start vdsm

Vent et øjeblik og tjek status igen. Hvis den fejler igen, skal du undersøge logfilerne for at finde årsagen. De primære logfiler for VDSM findes i /var/log/vdsm/, hvor vdsm.log er den vigtigste.

VIGTIGT: Undgå at genstarte VDSM-tjenesten (service vdsmd restart) på en aktiv host uden først at sætte den i vedligeholdelsestilstand via oVirt GUI. Hvis du gør det, kan oVirt Engine tro, at hosten er nede, og initiere en fencing-handling (en tvungen genstart via en ekstern enhed), hvilket kan føre til datatab eller korruption, især hvis hosten fungerer som SPM (Storage Pool Manager).

Trin 3: Kontroller Firewall-regler

En almindelig synder, især efter opdateringer eller ændringer i systemkonfigurationen, er firewallen. Både oVirt Engine og hosten skal kunne kommunikere over en række specifikke porte. Sørg for, at disse porte er åbne på din host:

Håndtering af en "Non-Operational" Host

Hvis din host i stedet er 'Non-Operational', er fejlsøgningen anderledes. Her ved du, at den basale kommunikation fungerer, men noget i konfigurationen er galt. Logfilerne på oVirt Engine (typisk /var/log/ovirt-engine/engine.log) er ofte det bedste sted at starte, da de vil indeholde fejlmeddelelser relateret til den specifikke host.

Case Study: Certifikatfejl

Et virkeligt eksempel fra logfiler kan vise en fejl som denne:

ERROR [org.ovirt.engine.core.vdsbroker.jsonrpc.JsonRpcVdsServer] Failed to get peer certification for host 'ovirt-node-02': SSL session is invalid

Denne fejlmeddelelse er krystalklar: der er et problem med SSL-certifikaterne. Dette kan ske, hvis certifikaterne er udløbet, eller hvis der er sket en fejl under en tidligere opdatering. Den mest effektive løsning er ofte at gen-enroll'e hosten. Dette indebærer at sætte hosten i vedligeholdelsestilstand, højreklikke på den i GUI'en og vælge 'Reinstall'. Dette vil ikke slette operativsystemet, men det vil køre installationsproceduren igen, generere nye certifikater og sikre, at konfigurationen er synkroniseret med Engine.

Den Sidste Udvej: Fjernelse og Gentilføjelse af en Host

Nu til det oprindelige spørgsmål: Hvad hvis intet virker, eller hosten er i en tilstand, hvor den ikke kan reddes? Er det sikkert at fjerne den fra klyngen? Svaret er ja, men det skal gøres korrekt.

Hvis hosten er permanent nede (f.eks. på grund af en hardwarefejl) og stadig vises som 'Non-Responsive', kan du ikke bare klikke 'Remove'. oVirt Engine vil nægte, fordi den ikke kender status på de virtuelle maskiner, der kørte på hosten. Den er bange for et 'split-brain'-scenarie.

Proceduren er som følger:

1. Højreklik på den 'Non-Responsive' host og vælg 'Confirm Host has been Rebooted'.
2. Dette er en manuel fencing-handling. Du bekræfter over for Engine, at du har sikret, at hosten er genstartet (eller permanent slukket), og at ingen VM'er kører på den længere.
3. Engine vil nu forsøge at rydde op. Denne proces kan tage flere minutter.
4. Når processen er færdig, vil host-status typisk ændre sig, og du vil nu have mulighed for at sætte den i vedligeholdelsestilstand og derefter fjerne den.

Dette bør kun bruges som en sidste udvej, når du er 100% sikker på, at hosten ikke kan komme online igen ved hjælp af almindelig fejlfinding.

Ofte Stillede Spørgsmål (FAQ)

Q: Hvad betyder "Image Locked" status for en VM?

A: Når en lager-intensiv handling udføres (f.eks. oprettelse/sletning af snapshots, flytning af disk), låses VM'ens disk image for at forhindre datakorruption. Hvis en VM forbliver i 'Image Locked'-status i lang tid, indikerer det typisk, at en lageroperation er gået i stå. Dette kræver ofte en undersøgelse af VDSM- og storage-logs for at finde årsagen.

Q: Hvordan kan jeg ændre VDSM's logningsniveau for mere detaljeret output?

A: Du kan redigere filen /etc/vdsm/logger.conf på den relevante host for at justere logningsniveauet. Dette kan være yderst nyttigt under kompleks fejlfinding, men husk at sætte det tilbage til standard efterfølgende for at undgå, at logfilerne fylder for meget.

Q: Min oVirt GUI viser, at en VM kører på host A, men jeg ved, den kører på host B. Hvorfor?

A: Dette kan ske, hvis der er en uoverensstemmelse mellem Engine's database og den faktiske tilstand i klyngen, især efter netværksproblemer. Kommandoen hosted-engine --vm-status, kørt fra en af dine hosts, vil ofte vise den sande placering af Hosted Engine VM'en. En genstart af ovirt-engine servicen kan nogle gange rette op på GUI'ens visning.