ESXi 6.7 til 8.0-opdatering - Ret produktionsservernedbrud

Tjek først hardwarekompatibiliteten

ESXi 6.7 nåede slutningen af generel support den 15. oktober 2022, så flytningen er forsinket - men 6.7 til 8.0 er en større versionsopgradering, ikke en patch. Mellem de to versioner fjernede VMware VMKLinux-drivermodellen fuldstændigt (hver enhed har nu brug for en indbygget driver) og pensionerede en generation af CPU'er, netværksadaptere og lagercontrollere. En perfekt sund 6.7-vært kan stadig være uopgraderbar, som den står.

Før et vindue reserveres, skal du tjekke VMware-kompatibilitetsvejledningen for din nøjagtige servermodel, CPU-familie, netværksadaptere og lagercontroller mod ESXi 8.0, og opdatere serverens firmware (BIOS, lagercontroller, NIC'er) til de versioner, som leverandøren angiver for 8.0. Installatørens egen forhåndskontrol advarer også om forældede enheder - men det er det forkerte tidspunkt at finde ud af det på konsollen ved midnat. Tjek først på papiret.

Sikkerhedskopier værtskonfigurationen og VM'erne

Sikkerhedskopier værtskonfigurationen fra værtsskallen (aktiver SSH på værten først, hvis den er slået fra). Kommandoen returnerer et downloadlink til konfigurationspakken – åbn den og gem .tgz-filen et sted, der ikke er på denne server:

vim-cmd hostsvc/firmware/backup_config

Bekræft derefter, at VM-sikkerhedskopierne er aktuelle, og at mindst én gendannelse faktisk er blevet testet. Halvdelen af ​​alle lilla skærme efter opgradering sporer tilbage til firmware, som den gamle hypervisor tolererede - men de nedbrud, du ikke kan fortryde, er dem uden backup bag dem.

Planlæg vinduet, og hold 8.0-licensnøglen klar

Vælg en vedligeholdelsesplads, og meddel det til brugerne – ingen bør være midt i vente, når værten går ned. Skriv sekvensen ned med tider, og indstil en hård rollback-deadline: det tidspunkt på natten, hvorefter du stopper med fejlretningen og ruller tilbage (trin 7) i stedet for at spise hele vinduet. Send en afsluttende besked, når arbejdet er færdigt, så næste morgen ikke starter med rygter.

Få licensen sorteret før vinduet, ikke under det. Licensnøgler er bundet til hovedversionen - en 8.0-vært accepterer ikke en 6.7-nøgle, og uden en kører den i evalueringstilstand i 60 dage. Under Broadcom kommer nøgler og downloads fra Broadcoms supportportal mod din berettigelse, så aftal adgangen på forhånd.

Rute A — Opgrader ved at starte 8.0 ISO

Fortæl brugerne det, og sæt værten i vedligeholdelsestilstand - hver VM lukkes ned eller migreres til en anden vært. Opgrader aldrig en vært, der stadig kører produktions-VM'er.

Start ESXi 8.0-installationsprogrammet fra ISO, vælg den disk, der indeholder den eksisterende installation, og vælg Opgrader ESXi, bevar VMFS-datalageret. Dette er den rute, der vises på de fleste servere, og den, der håndterer en stor version, hopper rent, fordi forhåndskontrollen vises på skærmen, mens den går.

Rute B — Opgrader fra Shell med esxcli

Depotruten kører udelukkende fra værtsskallen - ingen fysiske eller virtuelle medier - hvilket gør den til det praktiske valg for en fjernvært. Værten går stadig i vedligeholdelsestilstand først, nøjagtig som i rute A. Tillad HTTP-klienten gennem værtsfirewallen:

esxcli network firewall ruleset set -e true -r httpClient

List de tilgængelige profiler i VMwares onlinedepot, og noter det nøjagtige navn på 8.0-standardprofilen:

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

Kør derefter profilopdateringen mod depotet ved at bruge det nøjagtige profilnavn, og genstart værten, når den er færdig:

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

Den samme rute fungerer offline: Kopier depotbundtet ZIP til et datalager og peg i stedet -d værdien på den fil. Bemærk, at profilopdatering er opgraderingskommandoen — den beholder din eksisterende konfiguration og tredjeparts VIB'er, hvor de er kompatible; erstatte ikke profilinstallation, som erstatter billedet.

Efter genstart - Licens, bekræft, og slip derefter

Når værten er sikkerhedskopieret på 8.0, anvend din ESXi 8.0-licensnøgle - 6.7-nøglen accepteres ikke, og uden den nye nøgle tikker evalueringsuret. Afslut vedligeholdelsestilstand, start derefter én ikke-kritisk VM først og tjek dens netværk, lager og konsol, før du starter resten.

Arbejd derefter gennem selve værten: hændelsesloggen og hardwarestatus for driver- eller sensorklager, hvert datalager monteret og indstillingerne for administrationsnetværk intakte. Slip først derefter serveren tilbage til brugerne, og send den afsluttende besked fra trin 3.

The Crash Playbook — Purple Screen og Shift+R Rollback

Hvis værten lilla-skærme (PSOD) eller ikke vil starte nyttigt efter opgraderingen, skal du arbejde i denne rækkefølge. Først skal du fotografere den lilla skærm, før du rører ved noget. En PSOD er, at VMkernel stopper bevidst, fordi fortsættelse ville risikere VM'erne - og skærmen er diagnosen: undtagelsestypen og det modul, der er navngivet på den, peger på årsagen, med et drivermodulnavn, der angiver et hardware-supportproblem og en sidefejl, der peger på hukommelse eller firmware.

For det andet, genstart én gang og se. En enkelt forbigående lilla skærm efter et driverskift er data; en gentagelse er en dom. De første mistænkte, i opgraderingens egen rækkefølge: en ikke-understøttet NIC eller lagringsadapter, firmware, der er ældre end kompatibilitetsguiden, eller en hukommelsesfejl, den gamle version aldrig understregede.

For det tredje, rul tilbage. ESXi installeres i to opstartsbanker, og opgraderingen efterlader din tidligere 6.7-bygning intakt i den alternative bank. Genstart værten, og ved opstartsprompten skal du trykke på Shift + R og bekræft - værten starter den forrige 6.7-build, inklusive konfiguration, præcis som du forlod den. Hvis tilbagerulningen virker, har du købt tid: ret kompatibilitetsårsagen i dagslys og opgrader igen i et nyt vindue.

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

Denne gendannelseskommando er den anden escape-rute – den sætter værtskonfigurationen fra trin 2-pakken tilbage på en vært af den samme version og build, i de tilfælde, hvor én bootbank ikke er nok.