Uppdatering ESXi 6.7 till 8.0 - Åtgärda produktionsserverkrasch

Kontrollera först maskinvarukompatibiliteten

ESXi 6.7 nådde slutet av det allmänna stödet den 15 oktober 2022, så flytten är försenad – men 6.7 till 8.0 är en stor versionsuppgradering, inte en patch. Mellan de två versionerna tog VMware bort VMKLinux-drivrutinsmodellen helt (varje enhet behöver nu en inbyggd drivrutin) och pensionerade en generation av processorer, nätverksadaptrar och lagringskontroller. En helt frisk 6.7-värd kan fortfarande vara ouppgraderbar som den ser ut.

Innan något fönster bokas, kontrollera VMware Compatibility Guide för din exakta servermodell, CPU-familj, nätverkskort och lagringskontroller mot ESXi 8.0, och uppdatera serverns firmware (BIOS, lagringskontroller, NIC) till de versioner som leverantören listar för 8.0. Installatörens egen förkontroll varnar också för föråldrade enheter - men att ta reda på det vid konsolen vid midnatt är fel tidpunkt. Kolla på papper först.

Säkerhetskopiera värdkonfigurationen och virtuella datorer

Säkerhetskopiera värdkonfigurationen från värdskalet (aktivera SSH på värden först om den är avstängd). Kommandot returnerar en nedladdningslänk för konfigurationspaketet — öppna det och spara .tgz-filen någonstans som inte finns på den här servern:

vim-cmd hostsvc/firmware/backup_config

Bekräfta sedan att VM-säkerhetskopiorna är aktuella och att minst en återställning faktiskt har testats. Hälften av alla lila skärmar efter uppgradering går tillbaka till firmware som den gamla hypervisorn tolererade – men krascharna som du inte kan ångra är de som inte har någon backup bakom sig.

Planera fönstret och håll 8.0-licensnyckeln redo

Välj en underhållsplats och meddela den för användarna – ingen ska vara mitt i räddningen när värden går ner. Skriv ner sekvensen med tider och ställ in en hård återställningstid: den punkt på natten efter vilken du slutar felsöka och rullar tillbaka (steg 7) istället för att äta upp hela fönstret. Skicka ett avslutande meddelande när arbetet är klart, så nästa morgon inte börjar med rykten.

Få licensen sorterad före fönstret, inte under det. Licensnycklar är knutna till huvudversionen — en 8.0-värd accepterar inte en 6.7-nyckel, och utan en körs den i utvärderingsläge i 60 dagar. Under Broadcom kommer nycklar och nedladdningar från Broadcoms supportportal mot din rättighet, så ordna åtkomsten i förväg.

Rutt A — Uppgradera genom att starta upp 8.0 ISO

Berätta för användarna och ställ sedan värden i underhållsläge – varje virtuell dator som stängs av eller migreras till en annan värd. Uppgradera aldrig en värd som fortfarande kör produktions-VM.

Starta ESXi 8.0-installationsprogrammet från ISO, välj disken som innehåller den befintliga installationen och välj Uppgradera ESXi, bevara VMFS-dataarkivet. Detta är rutten som visas på de flesta servrar, och den som hanterar en stor version hoppar rent eftersom förkontrollerna visas på skärmen allt eftersom.

Rutt B — Uppgradera från skalet med esxcli

Depåvägen går helt och hållet från värdskalet – inga fysiska eller virtuella media – vilket gör den till det praktiska valet för en fjärrvärd. Värden går fortfarande in i underhållsläge först, precis som i rutt A. Tillåt HTTP-klienten genom värdbrandväggen:

esxcli network firewall ruleset set -e true -r httpClient

Lista profilerna som är tillgängliga i VMwares onlinedepå och notera det exakta namnet på 8.0-standardprofilen:

esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Kör sedan profiluppdateringen mot depån med det exakta profilnamnet och starta om värden när den är klar:

esxcli software profile update -d <depot-url> -p <exact-profile-name>

Samma rutt fungerar offline: kopiera depåpaketet ZIP till en databutik och rikta -d-värdet mot den filen istället. Observera att profiluppdatering är uppgraderingskommandot – det behåller din befintliga konfiguration och tredje parts VIB där de är kompatibla; ersätt inte profilinstallation, som ersätter bilden.

Efter omstarten - Licens, verifiera och släpp sedan

När värden är säkerhetskopierad på 8.0, använd din ESXi 8.0-licensnyckel – 6.7-nyckeln accepteras inte, och utan den nya nyckeln tickar utvärderingsklockan. Avsluta underhållsläget, starta sedan en icke-kritisk virtuell dator först och kontrollera dess nätverk, lagring och konsol innan du startar resten.

Arbeta genom själva värden härnäst: händelseloggen och maskinvarustatus för förar- eller sensorklagomål, varje datalager monterad och inställningarna för hanteringsnätverket intakta. Släpp sedan tillbaka servern till användarna och skicka det avslutande meddelandet från steg 3.

Crash Playbook — Purple Screen och Shift+R Rollback

Om värden lila-skärmar (PSOD) eller inte kommer att starta upp med hjälp efter uppgraderingen, arbeta i denna ordning. Fotera först den lila skärmen innan du rör vid något. En PSOD är att VM-kärnan stoppar avsiktligt eftersom att fortsätta skulle riskera virtuella datorer – och skärmen är diagnosen: undantagstypen och modulen som nämns på den pekar på orsaken, med ett drivrutinsmodulnamn som indikerar ett hårdvarusupportproblem och ett sidfel som pekar på minne eller firmware.

För det andra, starta om en gång och titta. En enda övergående lila skärm efter ett förarbyte är data; en upprepande är en dom. De första misstänkta, i uppgraderingens egen ordning: ett nätverkskort eller lagringsadapter som inte stöds, firmware som är äldre än kompatibilitetsguidens listor eller ett minnesfel som den gamla versionen aldrig betonade.

För det tredje, rulla tillbaka. ESXi installeras i två startbanker, och uppgraderingen lämnar din tidigare 6.7-byggnad intakt i den alternativa banken. Starta om värden och vid startprompten trycker du på Shift + R och bekräftar – värden startar den tidigare 6.7-versionen, inklusive konfiguration, precis som du lämnade den. Om återställningen fungerar har du köpt tid: fixa kompatibilitetsorsaken i dagsljus och uppgradera igen i ett nytt fönster.

vim-cmd hostsvc/firmware/restore_config <bundle-path>

Det återställningskommandot är den andra utrymningsvägen — det sätter tillbaka värdkonfigurationen från steg 2-paketet till en värd av samma version och build, för de fall där en startbank inte räcker.