Kennisbank / RHEL 8 naar 9 migratie

RHEL 8 naar 9 met Leapp: voorbereiding, lifecycle en migratie

Auteur: DEWOLF.IT

Een RHEL 8 naar 9 migratie begint met een supportbaar upgradepad en een aantoonbaar herstelplan. Leapp helpt bij de technische overgang; applicatiecompatibiliteit, contentvoorziening en acceptatie blijven onderdelen van het migratieontwerp.

Scope: RHEL 8 → 9; minor releases, architectuur, kanaal en Leapp-versie bepalen het ondersteunde pad.

Toepassing. RHEL 8 naar RHEL 9 op een ondersteunde combinatie van bronrelease, doelrelease, architectuur en contentkanaal. De voorbeelden zijn inventarisatie en een migratiesjabloon, geen universeel uitvoerscript.

Probleem en achtergrond: een major upgrade is een ketenwijziging

Een major upgrade verandert meer dan de kernel. Applicaties kunnen afhankelijk zijn van runtimes, crypto-instellingen, drivers en libraries. Maak daarom eerst een afhankelijkhedenlijst: welke componenten zijn door Red Hat geleverd, welke door een leverancier en welke lokaal gebouwd? Leg per component vast wie compatibiliteit met de gekozen RHEL 9-release bevestigt.

Kies bewust tussen in-place upgraden en opnieuw uitrollen. In-place kan zinvol zijn bij een goed begrepen configuratie met een ondersteund Leapp-pad. Opnieuw uitrollen maakt het makkelijker om configuratie en workload los te trekken van historisch gegroeide uitzonderingen. Vergelijk beide op herstelbaarheid, benodigde downtime, dataoverdracht en de testlast voor het team.

1. Stel lifecycle en supportvoorwaarden vast

Een RHEL-major lifecycle, een minor-releasekanaal en de lifecycle van een Application Stream zijn verschillende afspraken. EUS is een aanvullend aanbod voor geselecteerde minor releases, met voorwaarden en een begrensde periode. Een release-lock alleen levert geen EUS-rechten op. Controleer entitlement, repositorykanaal en de supporttermijn van iedere gebruikte runtime afzonderlijk. Zie de officiële RHEL lifecycle-policy.

cat /etc/redhat-release
uname -m
rpm -q kernel leapp-upgrade
sudo subscription-manager release --show
sudo subscription-manager repos --list-enabled
sudo dnf repolist --enabled
sudo dnf module list --enabled

Deze controles laten onder meer de bronrelease, architectuur, release-lock, ingeschakelde repositories en modulaire streams zien. Een niet-geïnstalleerd leapp-upgrade-pakket wordt als zodanig gemeld. Inventariseer daarnaast software van derden, kernelmodules, lokale RPM’s en excludes/versionlocks. Vergelijk die lijst met de applicatie- en leveranciersdocumentatie.

2. Controleer het actuele Leapp-pad

De Red Hat-planningsdocumentatie bepaalt de toegestane bron- en doelreleases en beperkingen. Controleer die matrix vlak voor de migratie. Cloud/RHUI, SAP, FIPS en afwijkende storage- of encryptieconfiguraties kunnen aanvullende instructies hebben. Leg het gekozen pad vast in het change-record; ‘RHEL 8 naar 9’ is daarvoor niet nauwkeurig genoeg.

Zorg vóór de assessment dat de bronhost aan de voorgeschreven patchstand voldoet, en dat de vereiste Leapp-pakketten en bron- en doelrepositories beschikbaar zijn. Bij Satellite moet de host de daarvoor benodigde content daadwerkelijk kunnen consumeren. Meng geen repositories voor verschillende major releases buiten de gedocumenteerde upgradeprocedure.

3. Verzamel een baseline en test herstel

df -hT
lsblk -f
findmnt
systemctl --failed
sudo ss -lntup
sudo dnf versionlock list

versionlock vereist de bijbehorende DNF-plugin. Noteer welke processen en poorten bij de baseline horen, zodat je later afwijkingen kunt verklaren. Controleer vrije ruimte voor onder meer /, /var en /boot volgens de upgradehandleiding. Sla ook netwerk-, storage-, monitoring- en authenticatieconfiguratie op in de hersteladministratie.

Een VM-snapshot is alleen een bruikbaar herstelmiddel als de toepassing consistent kan worden teruggezet en alle betrokken disks en externe systemen in het plan passen. Test een restore, leg het herstelmoment vast en bepaal hoe je schrijftoegang tijdens de migratie begrenst. Denk vooral aan databases en gedeelde storage: een oude VM met nieuwe externe data kan een inconsistente toestand opleveren.

4. Lees de assessment als werkvoorraad

# Vul uitsluitend een doelrelease uit het ondersteunde pad in.
TARGET_MINOR='VERVANG_DOOR_ONDERSTEUNDE_9_MINOR'
sudo leapp preupgrade --target "$TARGET_MINOR"
sudo less /var/log/leapp/leapp-report.txt
sudo less /var/log/leapp/answerfile

Dit sjabloon bevat bewust geen vastgepinde minor release. De Leapp-upgradehandleiding beschrijft de parameters, rapportbestanden en verdere uitvoering. preupgrade voert de assessment uit en kan pakketten, metadata en tijdelijke upgrade-artefacten ophalen of aanmaken; het is geen major OS-upgrade en geen garantie dat de applicatie daarna werkt.

Behandel inhibitors als blokkerend, maar beoordeel ook waarschuwingen. Koppel elke bevinding aan een eigenaar, een onderbouwde actie en een controle. Vul antwoorden niet blind in: een bevestiging in de answerfile vertegenwoordigt een keuze waarvan de gevolgen moeten zijn begrepen. Herhaal de assessment na de correcties en bewaar het laatste rapport bij het change-record.

5. Upgrade en accepteer in afzonderlijke stappen

Voer leapp upgrade en de voorgeschreven reboot pas uit na een geslaagde generale repetitie, een goedgekeurd onderhoudsvenster en een getest herstelplan. Gebruik dezelfde doelrelease en relevante kanaal-/repositoryopties als in de assessment. Zorg voor consoletoegang; een remote shell alleen is onvoldoende voor een mislukte boot.

cat /etc/redhat-release
uname -r
systemctl --failed
sudo dnf repolist --enabled
sudo journalctl -b -p warning
getenforce

Valideer daarna functioneel: authenticatie, DNS, mounts, applicatietransacties, agents, backups en monitoring. Vergelijk responstijden en foutpercentages met de baseline. Spreek vooraf een acceptatiedeadline af en een criterium voor terugzetten. Dat voorkomt dat een ogenschijnlijk gezonde host uren later alsnog buiten het herstelvenster valt.

Enterprise-aandachtspunten en valkuilen

Werk in representatieve pilotgroepen en behoud bewijs per host. Een succesvolle pilot met alleen standaardpakketten zegt weinig over een host met extra drivers of een eigen runtime. Laat leveranciersvalidatie, contentbeschikbaarheid en functionele acceptatie expliciet onderdeel zijn van het besluit.

Leapp is geen generieke downgradevoorziening. Plan herstel via restore of heruitrol, inclusief data. Verwijder oude repositories, tijdelijke uitzonderingen en release-locks pas wanneer de post-upgradehandleiding en het doelkanaal dat voorschrijven. Neem de nieuwe host ook op in het normale patchproces.

Bronnen en versiecontrole

Technische referenties geraadpleegd op 30 september 2026. Controleer bij uitvoering de documentatie en manpages van de geïnstalleerde versie.

RHEL lifecycle en Extended Update Support
Upgradeplanning en ondersteunde voorwaarden
Leapp assessment, uitvoering en troubleshooting

Gerelateerde artikelen

Red Hat Satellite: gecontroleerd patchen met content views
Ansible voor RHEL: idempotent beheer met inventory en roles
Enterprise Linux-beheer: tmp, journald, NFS en versionlock

Ondersteuning bij jouw platform

Wil je deze aanpak vertalen naar jouw omgeving? Bekijk Migratie & Lifecycle of neem contact op met DEWOLF.IT.