ESXi 6.7 til 8.0-oppdatering – fiks produksjonsserverkrasj

Sjekk maskinvarekompatibiliteten først

ESXi 6.7 nådde slutten av generell støtte 15. oktober 2022, så flyttingen er forsinket – men 6.7 til 8.0 er en større versjonsoppgradering, ikke en oppdatering. Mellom de to versjonene fjernet VMware VMKLinux-drivermodellen fullstendig (hver enhet trenger nå en innebygd driver) og pensjonerte en generasjon CPUer, nettverkskort og lagringskontrollere. En helt sunn 6.7-vert kan fortsatt være uoppgraderbar slik den står.

Før et vindu bestilles, sjekk VMware Compatibility Guide for din eksakte servermodell, CPU-familie, nettverkskort og lagringskontroller mot ESXi 8.0, og oppdater serverens fastvare (BIOS, lagringskontroller, NIC-er) til versjonene leverandøren viser for 8.0. Installatørens egen forhåndssjekk advarer også om utdaterte enheter - men å finne ut av det på konsollen ved midnatt er feil tid. Sjekk på papiret først.

Sikkerhetskopier vertskonfigurasjonen og VM-ene

Sikkerhetskopier vertskonfigurasjonen fra vertsskallet (aktiver SSH på verten først hvis den er av). Kommandoen returnerer en nedlastingskobling for konfigurasjonspakken – åpne den og lagre .tgz-filen et sted som ikke er på denne serveren:

vim-cmd hostsvc/firmware/backup_config

Bekreft deretter at VM-sikkerhetskopiene er aktuelle og at minst én gjenoppretting faktisk har blitt testet. Halvparten av alle lilla skjermer etter oppgradering sporer tilbake til fastvaren som den gamle hypervisoren tolererte – men krasjene du ikke kan angre er de uten sikkerhetskopi bak seg.

Planlegg vinduet og hold 8.0-lisensnøkkelen klar

Velg et vedlikeholdsspor og kunngjør det til brukerne – ingen skal være midt i vente når verten går ned. Skriv ned sekvensen med tider, og sett en hard tilbakeføringsfrist: punktet på natten etter at du slutter å feilsøke og ruller tilbake (trinn 7) i stedet for å spise hele vinduet. Send en avslutningsmelding når arbeidet er ferdig, så neste morgen ikke starter med rykter.

Få lisensen sortert før vinduet, ikke under det. Lisensnøkler er knyttet til hovedversjonen – en 8.0-vert vil ikke godta en 6.7-nøkkel, og uten en kjører den i evalueringsmodus i 60 dager. Under Broadcom kommer nøkler og nedlastinger fra Broadcom-støtteportalen mot din rettighet, så avtal tilgang på forhånd.

Rute A — Oppgrader ved å starte opp 8.0 ISO

Fortell brukerne, og sett verten i vedlikeholdsmodus – hver VM som slås av eller migreres til en annen vert. Oppgrader aldri en vert som fortsatt kjører produksjons-VM-er.

Start opp ESXi 8.0-installasjonsprogrammet fra ISO, velg disken som inneholder den eksisterende installasjonen, og velg Oppgrader ESXi, bevar VMFS-datalageret. Dette er ruten som vises på de fleste servere, og den som håndterer en stor versjon hopper rent fordi forhåndssjekkene vises på skjermen mens de går.

Rute B — Oppgrader fra Shell med esxcli

Depotruten går helt fra vertsskallet – ingen fysiske eller virtuelle medier – noe som gjør den til det praktiske valget for en ekstern vert. Verten går fortsatt inn i vedlikeholdsmodus først, nøyaktig som i rute A. Tillat HTTP-klienten gjennom vertsbrannmuren:

esxcli network firewall ruleset set -e true -r httpClient

List opp profilene som er tilgjengelige i VMwares nettbaserte depot, og noter det nøyaktige navnet på 8.0-standardprofilen:

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

Kjør deretter profiloppdateringen mot depotet, bruk det eksakte profilnavnet, og start verten på nytt når den er fullført:

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

Den samme ruten fungerer offline: kopier depotbunten ZIP til et datalager og pek -d-verdien mot den filen i stedet. Merk at profiloppdatering er oppgraderingskommandoen – den beholder din eksisterende konfigurasjon og tredjeparts VIB-er der de er kompatible; ikke erstatt profilinstallasjon, som erstatter bildet.

Etter omstart - Lisens, bekreft og slipp deretter

Når verten er sikkerhetskopiert på 8.0, bruk ESXi 8.0-lisensnøkkelen – 6.7-nøkkelen godtas ikke, og uten den nye nøkkelen tikker evalueringsklokken. Avslutt vedlikeholdsmodus, start en ikke-kritisk VM først og sjekk nettverket, lagringen og konsollen før du starter resten.

Arbeid gjennom selve verten neste gang: hendelsesloggen og maskinvarestatusen for driver- eller sensorklager, hver datalager som er montert, og innstillingene for administrasjonsnettverk er intakte. Slipp deretter serveren tilbake til brukerne, og send den avsluttende meldingen fra trinn 3.

Crash Playbook — Purple Screen og Shift+R Rollback

Hvis vertens lilla skjermer (PSOD) eller ikke vil starte opp etter oppgraderingen, arbeid i denne rekkefølgen. Først, fotografer den lilla skjermen før du berører noe. En PSOD er ​​VM-kjernen som stopper bevisst fordi fortsettelse ville risikere VM-ene – og skjermen er diagnosen: unntakstypen og modulen som er navngitt på den peker på årsaken, med et drivermodulnavn som indikerer et maskinvarestøtteproblem og en sidefeil som peker på minne eller fastvare.

For det andre, start på nytt én gang og se på. En enkelt forbigående lilla skjerm etter et førerskifte er data; en gjentakelse er en dom. De første mistenkte, i oppgraderingens egen rekkefølge: en ikke-støttet NIC eller lagringsadapter, firmware eldre enn kompatibilitetsguiden viser, eller en minnefeil den gamle versjonen aldri stresset.

For det tredje, rulle tilbake. ESXi installeres i to oppstartsbanker, og oppgraderingen lar den forrige 6.7-bygningen din være intakt i den alternative banken. Start verten på nytt, og ved oppstartsprompten, trykk Shift + R og bekreft – verten starter opp forrige 6.7-bygg, inkludert konfigurasjon, nøyaktig slik du forlot den. Hvis tilbakerullingen fungerer, har du kjøpt tid: fiks kompatibilitetsårsaken i dagslys og oppgrader igjen i et nytt vindu.

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

Den gjenopprettingskommandoen er den andre rømningsveien – den setter vertskonfigurasjonen fra trinn 2-pakken tilbake til en vert med samme versjon og bygg, for tilfeller der én oppstartsbank ikke er nok.