ESXi 6.7 hanggang 8.0 Update - Ayusin ang Pag-crash ng Server ng Produksyon

Suriin muna ang Hardware Compatibility

Naabot ng ESXi 6.7 ang katapusan ng pangkalahatang suporta noong Oktubre 15, 2022, kaya overdue na ang paglipat — ngunit ang 6.7 hanggang 8.0 ay isang major-version upgrade, hindi isang patch. Sa pagitan ng dalawang bersyon ay ganap na inalis ng VMware ang modelo ng driver ng VMKLinux (kailangan na ngayon ng bawat device ng katutubong driver) at nagretiro ng isang henerasyon ng mga CPU, network adapter at storage controller. Ang isang ganap na malusog na 6.7 host ay maaari pa ring hindi ma-upgrade habang ito ay nakatayo.

Bago mag-book ng anumang window, tingnan ang VMware Compatibility Guide para sa iyong eksaktong modelo ng server, pamilya ng CPU, network adapter at storage controller laban sa ESXi 8.0, at i-update ang server firmware (BIOS, storage controller, NICs) sa mga bersyon na inilista ng vendor para sa 8.0. Ang sariling pre-check ng installer ay nagbabala din tungkol sa mga hindi na ginagamit na device — ngunit ang pag-alam sa console sa hatinggabi ay ang maling oras. Check mo muna sa papel.

I-back Up ang Host Configuration at ang mga VM

I-back up ang configuration ng host mula sa host shell (paganahin muna ang SSH sa host kung naka-off ito). Ang command ay nagbabalik ng download link para sa configuration bundle — buksan ito at i-save ang .tgz file sa isang lugar na wala sa server na ito:

vim-cmd hostsvc/firmware/backup_config

Pagkatapos ay kumpirmahin na ang mga pag-backup ng VM ay kasalukuyan at na hindi bababa sa isang pagpapanumbalik ay aktwal na nasubok. Kalahati ng lahat ng post-upgrade na mga purple na screen ay bumabalik sa firmware na pinahintulutan ng lumang hypervisor — ngunit ang mga pag-crash na hindi mo maa-undo ay ang mga walang backup sa likod ng mga ito.

Planuhin ang Window at Panatilihing Handa ang 8.0 License Key

Pumili ng maintenance slot at i-anunsyo ito sa mga user — walang sinuman ang dapat na mid-save kapag bumaba ang host. Isulat ang pagkakasunud-sunod nang may mga oras, at magtakda ng hard rollback deadline: ang punto sa gabi pagkatapos mong ihinto ang pag-debug at i-roll back (Hakbang 7) sa halip na kainin ang buong window. Magpadala ng pangwakas na mensahe kapag tapos na ang trabaho, upang ang susunod na umaga ay hindi magsimula sa mga alingawngaw.

Kunin ang lisensya bago ang window, hindi sa panahon nito. Ang mga susi ng lisensya ay nakatali sa pangunahing bersyon — ang isang 8.0 host ay hindi tatanggap ng isang 6.7 na key, at kung wala ito ay tatakbo ito sa evaluation mode sa loob ng 60 araw. Sa ilalim ng Broadcom, ang mga susi at pag-download ay nagmumula sa portal ng suporta ng Broadcom laban sa iyong karapatan, kaya ayusin ang pag-access na iyon nang maaga.

Ruta A — Mag-upgrade sa pamamagitan ng Pag-boot ng 8.0 ISO

Sabihin sa mga user, pagkatapos ay ilagay ang host sa mode ng pagpapanatili — tuwing nagsasara o lumilipat ang VM sa ibang host. Huwag kailanman mag-upgrade ng host na nagpapatakbo pa rin ng mga production VM.

I-boot ang installer ng ESXi 8.0 mula sa ISO, piliin ang disk na naglalaman ng kasalukuyang pag-install, at piliin ang I-upgrade ang ESXi, preserve ang VMFS datastore. Ito ang rutang ipinapakita sa karamihan ng mga server, at ang isa na humahawak sa isang malaking bersyon ay tumalon nang malinis dahil lumilitaw ang mga paunang pagsusuri sa screen habang nagpapatuloy ito.

Ruta B — Mag-upgrade mula sa Shell gamit ang esxcli

Ang ruta ng depot ay ganap na tumatakbo mula sa host shell — walang pisikal o virtual na media — na ginagawa itong praktikal na pagpipilian para sa isang malayong host. Ang host ay napupunta pa rin sa maintenance mode muna, eksakto tulad ng sa Ruta A. Payagan ang HTTP client sa pamamagitan ng host firewall:

esxcli network firewall ruleset set -e true -r httpClient

Ilista ang mga profile na available sa online na depot ng VMware, at tandaan ang eksaktong pangalan ng 8.0 standard na profile:

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

Pagkatapos ay patakbuhin ang pag-update ng profile laban sa depot, gamit ang eksaktong pangalan ng profile, at i-reboot ang host kapag nakumpleto na ito:

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

Gumagana offline ang parehong ruta: kopyahin ang depot bundle ZIP sa isang datastore at ituro na lang ang -d value sa file na iyon. Tandaan na ang update ng profile ay ang upgrade command — pinapanatili nito ang iyong kasalukuyang configuration at mga third-party na VIB kung saan magkatugma ang mga ito; huwag palitan ang pag-install ng profile, na pumapalit sa larawan.

Pagkatapos ng Reboot — Lisensya, I-verify, Pagkatapos Bitawan

Kapag ang host ay naka-back up sa 8.0, ilapat ang iyong ESXi 8.0 license key — ang 6.7 key ay hindi tinatanggap, at kung wala ang bagong key, ang orasan ng pagsusuri ay titigil. Lumabas sa maintenance mode, pagkatapos ay magsimula muna ng isang hindi kritikal na VM at suriin ang network, storage at console nito bago simulan ang iba.

Susunod na magtrabaho sa mismong host: ang log ng kaganapan at katayuan ng hardware para sa mga reklamo ng driver o sensor, bawat naka-mount na datastore, at buo ang mga setting ng network ng pamamahala. Pagkatapos lamang i-release ang server pabalik sa mga user, at ipadala ang pansarang mensahe mula sa Hakbang 3.

Ang Crash Playbook — Purple Screen at ang Shift+R Rollback

Kung ang host ay purple-screens (PSOD) o hindi mag-boot nang kapaki-pakinabang pagkatapos ng pag-upgrade, gumana sa ganitong pagkakasunud-sunod. Una, kunan ng larawan ang purple na screen bago hawakan ang anuman. Ang PSOD ay ang VMkernel na sinasadyang huminto dahil ang pagpapatuloy ay magdudulot ng panganib sa mga VM — at ang screen ay ang diagnosis: ang uri ng pagbubukod at ang module na pinangalanan dito ay tumuturo sa dahilan, na may pangalan ng module ng driver na nagsasaad ng problema sa suporta sa hardware at isang page fault na tumuturo sa memorya o firmware.

Pangalawa, i-reboot nang isang beses at manood. Ang nag-iisang lumilipas na purple na screen pagkatapos ng pagbabago ng driver ay data; ang paulit-ulit ay isang hatol. Ang mga unang pinaghihinalaan, sa sariling pagkakasunud-sunod ng pag-upgrade: isang hindi sinusuportahang NIC o storage adapter, firmware na mas luma kaysa sa mga listahan ng gabay sa compatibility, o isang memory error na hindi kailanman binibigyang diin ng lumang bersyon.

Ikatlo, i-roll back. Ang ESXi ay nag-i-install sa dalawang boot bank, at ang pag-upgrade ay iniiwan ang iyong nakaraang 6.7 build na buo sa kahaliling bangko. I-reboot ang host at, sa boot prompt, pindutin ang Shift + R at kumpirmahin — bino-boot ng host ang nakaraang 6.7 build, kasama ang configuration, nang eksakto kung paano mo ito iniwan. Kung gumagana ang rollback, bumili ka ng oras: ayusin ang dahilan ng compatibility sa liwanag ng araw at mag-upgrade muli sa isang bagong window.

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

Ang restore command na iyon ay ang pangalawang ruta ng pagtakas — ibinabalik nito ang configuration ng host mula sa Step 2 bundle sa isang host ng parehong bersyon at build, para sa mga kaso kung saan hindi sapat ang isang boot bank.