ESXi 6.7 naar 8.0 Update - Crash van de productieserver oplossen
Het volledige ESXi 6.7 naar 8.0 upgradeplan voor een productieserver: compatibiliteitscontrole, back-up van de hostconfiguratie, de ISO- en esxcli-depotroutes, licentiesleutels, het crash-playbook - en de Shift+R-rollback die de nacht redt.
📑Hoofdstukken
- Waarom 6.7 moet verdwijnen: einde van de ondersteuning, en waarom dit een upgrade van de hoofdversie is en geen patch
- Gate 1 — bewijs dat de serverhardware nog steeds wordt ondersteund op ESXi 8.0
- Gate 2: maak een back-up van de hostconfiguratie en bevestig de VM-back-ups
- Plan de onderhoudsperiode, kondig deze aan en stel een harde terugdraaideadline in
- Onderhoudsmodus: elke VM wordt afgesloten of gemigreerd voordat de host wordt aangeraakt
- Route A: start de 8.0 ISO en upgrade, met behoud van de VMFS-datastore
- Route B — de esxcli-depotupdate vanuit de hostshell
- Na het opnieuw opstarten: de 8.0-licentiesleutel en de verificatiecontroles
- Het crash-playbook: een paars scherm lezen, de eerste controles en het terugdraaien van Shift+R
📋 Overzicht en stapsgewijze handleiding
Controleer eerst de hardwarecompatibiliteit
ESXi 6.7 bereikte het einde van de algemene ondersteuning op 15 oktober 2022, dus de overstap is al te laat. Maar 6.7 naar 8.0 is een upgrade naar de hoofdversie en geen patch. Tussen de twee versies heeft VMware het VMKLinux-drivermodel volledig verwijderd (elk apparaat heeft nu een native driver nodig) en een generatie CPU's, netwerkadapters en opslagcontrollers buiten gebruik gesteld. Een perfect gezonde 6.7-host kan in zijn huidige vorm nog steeds niet worden geüpgraded.
Voordat een venster wordt geboekt, controleert u de VMware-compatibiliteitsgids voor uw exacte servermodel, CPU-familie, netwerkadapters en opslagcontroller ten opzichte van ESXi 8.0, en updatet u de firmware van de server (BIOS, opslagcontroller, NIC's) naar de versies die de leverancier vermeldt voor 8.0. De voorafgaande controle van het installatieprogramma waarschuwt ook voor verouderde apparaten, maar het is het verkeerde moment om daar om middernacht achter te komen op de console. Controleer eerst op papier.
Maak een back-up van de hostconfiguratie en de VM's
Maak een back-up van de hostconfiguratie vanuit de hostshell (schakel eerst SSH in op de host als deze is uitgeschakeld). De opdracht retourneert een downloadlink voor de configuratiebundel. Open deze en sla het .tgz-bestand ergens op dat niet op deze server staat:
vim-cmd hostsvc/firmware/backup_config
Bevestig vervolgens dat de VM-back-ups actueel zijn en dat ten minste één herstel daadwerkelijk is getest. De helft van alle paarse schermen na de upgrade is terug te voeren op firmware die de oude hypervisor tolereerde, maar de crashes die je niet ongedaan kunt maken, zijn crashes zonder back-up.
Plan het venster en houd de 8.0-licentiesleutel bij de hand
Kies een onderhoudsinterval en kondig dit aan de gebruikers aan. Niemand mag halverwege de opslag zijn als de host uitvalt. Schrijf de reeks op met tijden, en stel een harde rollback-deadline in: het punt in de nacht waarna u stopt met debuggen en terugdraait (stap 7) in plaats van het hele venster op te eten. Stuur een slotbericht als het werk klaar is, zodat de volgende ochtend niet met geruchten begint.
Zorg ervoor dat de licentie vóór de periode wordt geregeld, niet tijdens de periode. Licentiesleutels zijn gekoppeld aan de hoofdversie: een 8.0-host accepteert geen 6.7-sleutel, en zonder deze draait deze in evaluatiemodus gedurende 60 dagen. Onder Broadcom komen sleutels en downloads van het Broadcom-ondersteuningsportaal waar u recht op heeft, dus regel die toegang vooraf.
Route A — Upgrade door de 8.0 ISO op te starten
Vertel het de gebruikers en zet de host in de onderhoudsmodus: elke VM wordt afgesloten of gemigreerd naar een andere host. Upgrade nooit een host waarop nog productie-VM's draaien.
Start het ESXi 8.0-installatieprogramma op vanaf de ISO, selecteer de schijf waarop de bestaande installatie staat en kies ESXi upgraden, VMFS-gegevensopslag behouden. Dit is de route die op de meeste servers wordt weergegeven, en degene die een grote versie afhandelt, springt netjes omdat de voorafgaande controles gaandeweg op het scherm verschijnen.
Route B — Upgrade vanaf de Shell met esxcli
De depotroute loopt volledig vanuit de hostshell – geen fysieke of virtuele media – waardoor het de praktische keuze is voor een externe host. De host gaat nog steeds eerst naar de onderhoudsmodus, precies zoals in Route A. Laat de HTTP-client door de hostfirewall:
esxcli network firewall ruleset set -e true -r httpClient
Maak een lijst van de profielen die beschikbaar zijn in het online depot van VMware en noteer de exacte naam van het 8.0-standaardprofiel:
esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
Voer vervolgens de profielupdate uit op het depot, met behulp van de exacte profielnaam, en start de host opnieuw op wanneer deze is voltooid:
esxcli software profile update -d <depot-url> -p <exact-profile-name>
Dezelfde route werkt offline: kopieer de depotbundel ZIP naar een datastore en wijs in plaats daarvan de waarde -d naar dat bestand. Merk op dat profile update het upgradecommando is — het houdt uw bestaande configuratie en VIB's van derden waar ze compatibel zijn; vervang niet profile install, die de afbeelding vervangt.
Na het opnieuw opstarten: licentie verlenen, verifiëren en vervolgens vrijgeven
Zodra de host een back-up heeft van 8.0, past u uw ESXi 8.0-licentiesleutel toe. De 6.7-sleutel wordt niet geaccepteerd en zonder de nieuwe sleutel tikt de evaluatieklok. Sluit de onderhoudsmodus af, start eerst één niet-kritieke VM en controleer het netwerk, de opslag en de console voordat u de rest start.
Werk vervolgens via de host zelf: het gebeurtenislogboek en de hardwarestatus voor klachten over stuurprogramma's of sensoren, elke datastore geactiveerd en de beheernetwerk instellingen intact. Geef de server pas daarna weer vrij aan de gebruikers en stuur het slotbericht uit stap 3.
Het Crash Playbook – Paars scherm en Shift+R Rollback
Als de host paarse schermen (PSOD) geeft of niet goed wil opstarten na de upgrade, werk dan in deze volgorde. Fotografeer eerst het paarse scherm voordat je iets aanraakt. Een PSOD is dat de VMkernel opzettelijk stopt omdat doorgaan de VM's in gevaar zou brengen - en het scherm is de diagnose: het uitzonderingstype en de module die erop wordt genoemd wijzen op de oorzaak, waarbij de naam van de drivermodule een hardware-ondersteuningsprobleem aangeeft en een paginafout die naar geheugen of firmware wijst.
Ten tweede: start één keer opnieuw op en kijk. Een enkel tijdelijk paars scherm na een stuurprogrammawissel is data; een herhaling is een oordeel. De eerste vermoedt, in volgorde van de upgrade: een niet-ondersteunde NIC of opslagadapter, firmware die ouder is dan de compatibiliteitsgids vermeldt, of een geheugenfout die de oude versie nooit benadrukte.
Ten derde, terugdraaien. ESXi wordt geïnstalleerd in twee opstartbanken, en de upgrade laat je vorige 6.7-build intact in de alternatieve bank. Start de host opnieuw op en druk bij de opstartprompt op Shift + R en bevestig. De host start de vorige versie van 6.7 op, inclusief de configuratie, precies zoals u deze hebt achtergelaten. Als het terugdraaien werkt, heb je tijd gekocht: verhelp de compatibiliteitsoorzaak bij daglicht en upgrade opnieuw in een nieuw venster.
vim-cmd hostsvc/firmware/restore_config <bundle-path>
Dat herstelcommando is de tweede ontsnappingsroute: het zet de hostconfiguratie uit de stap 2-bundel terug op een host van dezelfde versie en build, voor de gevallen waarin één opstartbank niet genoeg is.
🏷️Variabelen en trefwoorden voor zoeken op onderwerp
🎙️ Volledig transcript: tik om uit te vouwen
__TOK_36__
__TOK_37__
__TOK_38__
❓ Veelgestelde vragen
Is deze tutorial 100% gratis te volgen?
__TOK_39__
Kunnen beginners deze handleiding volgen?
__TOK_40__
Waar kan ik vragen stellen als ik vastloop?
__TOK_41__