Actualizare ESXi 6.7 la 8.0 - Remediați blocarea serverului de producție
Planul complet de upgrade ESXi 6.7 la 8.0 pentru un server de producție: verificarea compatibilității, copierea de rezervă a configurației gazdei, rutele ISO și esxcli depot, cheile de licență, manualul de blocare - și derularea Shift+R care salvează noaptea.
📑Capitole
- De ce trebuie să dispară versiunea 6.7 — sfârșitul asistenței și de ce aceasta este o actualizare a versiunii majore, nu un patch
- Poarta 1 — dovediți că hardware-ul serverului este încă acceptat pe ESXi 8.0
- Poarta 2 — faceți o copie de rezervă a configurației gazdei și confirmați copiile de rezervă ale VM
- Planificați fereastra de întreținere — anunțați-o și setați un termen limită de retragere completă
- Modul de întreținere — fiecare VM s-a oprit sau a migrat înainte ca gazda să fie atinsă
- Ruta A — porniți ISO 8.0 și faceți upgrade, păstrând depozitul de date VMFS
- Ruta B — actualizarea esxcli depot din shell-ul gazdei
- După repornire — cheia de licență 8.0 și verificările de verificare
- Manualul de blocare — citirea unui ecran violet, primele verificări și derularea Shift+R
📋 Prezentare generală și Ghid pas cu pas
Verificați mai întâi compatibilitatea hardware
ESXi 6.7 a ajuns la sfârșitul suportului general pe 15 octombrie 2022, așa că mutarea este întârziată, dar de la 6.7 la 8.0 este o actualizare majoră a versiunii, nu un patch. Între cele două versiuni, VMware a eliminat în întregime modelul de driver VMKLinux (orice dispozitiv are acum nevoie de un driver nativ) și a retras o generație de procesoare, adaptoare de rețea și controlere de stocare. O gazdă 6.7 perfect sănătoasă poate fi încă neactualizată așa cum este.
Înainte de a rezerva orice fereastră, verificați Ghidul de compatibilitate VMware pentru modelul dvs. exact de server, familia CPU, adaptoarele de rețea și controlerul de stocare față de ESXi 8.0 și actualizați firmware-ul de server (BIOS, controler de stocare, NIC) la versiunile pe care le listează furnizorul pentru 8.0. Verificarea prealabilă a instalatorului avertizează, de asemenea, despre dispozitivele depreciate – dar aflarea de la consolă la miezul nopții este momentul greșit. Verificați mai întâi pe hârtie.
Faceți o copie de rezervă a configurației gazdei și a mașinilor virtuale
Faceți o copie de rezervă a configurației gazdei din shell-ul gazdei (activați mai întâi SSH pe gazdă dacă este dezactivat). Comanda returnează un link de descărcare pentru pachetul de configurare — deschideți-l și salvați fișierul .tgz undeva care nu este pe acest server:
vim-cmd hostsvc/firmware/backup_config
Apoi confirmați că backup-urile VM sunt actuale și că cel puțin o restaurare a fost testată. Jumătate din toate ecranele mov post-upgrade se regăsesc până la firmware-ul pe care îl tolera vechiul hypervisor – dar blocările pe care nu le puteți anula sunt cele fără backup în spate.
Planificați fereastra și păstrați cheia de licență 8.0 gata
Alegeți un slot de întreținere și anunțați-l utilizatorilor — nimeni nu ar trebui să fie la mijloc de salvare când gazda se defectează. Scrieți secvența cu timpi și setați un termen limită de derulare greu: punctul din noapte după care opriți depanarea și derulați înapoi (Pasul 7) în loc să consumați toată fereastra. Trimiteți un mesaj de închidere când lucrarea este terminată, astfel încât a doua zi dimineața să nu înceapă cu zvonuri.
Sortați licența înaintea ferestrei, nu în timpul acesteia. Cheile de licență sunt legate de versiunea majoră — o gazdă 8.0 nu va accepta o cheie 6.7, iar fără una rulează în modul de evaluare timp de 60 de zile. În cadrul Broadcom, cheile și descărcările provin de la portalul de asistență Broadcom în baza dreptului dvs., așa că aranjați acel acces în avans.
Ruta A — Actualizați prin pornirea ISO 8.0
Spuneți utilizatorilor, apoi puneți gazda în modul de întreținere - fiecare VM s-a oprit sau a migrat la o altă gazdă. Nu actualizați niciodată o gazdă care încă rulează mașini virtuale de producție.
Porniți programul de instalare ESXi 8.0 din ISO, selectați discul care conține instalarea existentă și alegeți Actualizați ESXi, păstrați depozitul de date VMFS. Aceasta este ruta afișată pe majoritatea serverelor, iar cea care se ocupă de o versiune mare sare curat, deoarece preverificările apar pe ecran pe măsură ce se desfășoară.
Route B — Upgrade de la Shell cu esxcli
Ruta de depozit rulează în întregime din shell-ul gazdei - fără suport fizic sau virtual - ceea ce o face alegerea practică pentru o gazdă la distanță. Gazda intră în continuare în modul de întreținere mai întâi, exact ca în Ruta A. Permiteți clientului HTTP să treacă prin firewall-ul gazdei:
esxcli network firewall ruleset set -e true -r httpClient
Listați profilurile disponibile în depozitul online al VMware și notați numele exact al profilului standard 8.0:
esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
Apoi rulați actualizarea profilului împotriva depozitului, folosind numele exact al profilului și reporniți gazda când se finalizează:
esxcli software profile update -d <depot-url> -p <exact-profile-name>
Aceeași rută funcționează offline: copiați pachetul de depozit ZIP într-un depozit de date și îndreptați în schimb valoarea -d către acel fișier. Rețineți că actualizarea profilului este comanda de actualizare - vă păstrează configurația existentă și VIB-urile de la terți acolo unde sunt compatibile; nu înlocuiți instalarea profilului, care înlocuiește imaginea.
După repornire — Licență, Verificare, Apoi Eliberare
Odată ce gazda revine la versiunea 8.0, aplicați cheia de licență ESXi 8.0 — cheia 6.7 nu este acceptată, iar fără noua cheie, ceasul de evaluare bifează. Ieșiți din modul de întreținere, apoi porniți mai întâi o VM necritică și verificați-i rețeaua, stocarea și consola înainte de a porni restul.
În continuare, lucrați prin gazda în sine: jurnalul de evenimente și starea hardware pentru reclamațiile pentru driver sau senzori, fiecare magazin de date montat și setările rețelei de gestionare intacte. Abia apoi eliberați serverul înapoi utilizatorilor și trimiteți mesajul de închidere de la Pasul 3.
Crash Playbook — Ecran violet și Shift+R Rollback
Dacă gazda purple-screen (PSOD) sau nu va porni util după actualizare, lucrați în această ordine. Mai întâi, fotografiați ecranul violet înainte de a atinge ceva. Un PSOD înseamnă că VMkernel-ul se oprește în mod deliberat, deoarece continuarea ar risca VM-urile - iar ecranul este diagnosticul: tipul de excepție și modulul numit pe ea indică cauza, cu un nume de modul driver indicând o problemă de suport hardware și o eroare de pagină care indică către memorie sau firmware.
În al doilea rând, reporniți o dată și urmăriți. Un singur ecran violet tranzitoriu după o schimbare a driverului reprezintă date; unul care se repetă este un verdict. Primii suspecți, în ordinea proprie a upgrade-ului: o NIC sau un adaptor de stocare neacceptat, un firmware mai vechi decât listele ghidului de compatibilitate sau o eroare de memorie pe care versiunea veche nu a subliniat-o niciodată.
În al treilea rând, derulați înapoi. ESXi se instalează în două bănci de pornire, iar upgrade-ul lasă intactă versiunea anterioară 6.7 în banca alternativă. Reporniți gazda și, la promptul de pornire, apăsați Shift + R și confirmați - gazda pornește versiunea anterioară 6.7, inclusiv configurația, exact așa cum ați lăsat-o. Dacă rollback-ul funcționează, ați câștigat timp: remediați cauza compatibilității la lumina zilei și actualizați din nou într-o fereastră nouă.
vim-cmd hostsvc/firmware/restore_config <bundle-path>
Acea comandă de restaurare este a doua rută de evadare — pune configurația gazdei din pachetul Pasul 2 înapoi pe o gazdă cu aceeași versiune și construcție, pentru cazurile în care o singură bancă de pornire nu este suficientă.
🏷️Variabile și cuvinte cheie pentru căutarea subiectelor
🎙️ Transcriere completă — atingeți pentru a extinde
__TOK_36__
__TOK_37__
__TOK_38__
❓ Întrebări frecvente
Este acest tutorial 100% gratuit de urmat?
__TOK_39__
Pot începătorii să urmeze acest ghid?
__TOK_40__
Unde pot pune întrebări dacă rămân blocat?
__TOK_41__