Patch and Verify a RHEL 9 VM

Patch a disposable RHEL 9 VM and verify its security advisory status.

Introduction

30 Second Summary

Critical fixes often look like ordinary package updates until you inspect the security evidence behind them. A safe practice machine lets you learn that judgment without touching a computer you rely on.

In this project, you will build a disposable virtual machine running Red Hat Enterprise Linux 9.8 with UTM. You will complete an evidence-based security patching cycle with DNF from advisory inspection through reboot verification.

What You'll Build

Your finished lab demonstrates a complete security-patching cycle from advisory evidence to a clean post-reboot check.

By the end of this project, you'll have:

  • A disposable RHEL lab where you can practise server patching without changing macOS.
  • A security triage workflow that opens a pending Red Hat Security Advisory with its severity, CVEs, affected package, and description.
  • Post-reboot proof showing your active kernel plus an empty pending-security-advisory list.
  • Secret Mission: Configure DNF Automatic to install future security updates through a systemd timer.

Are there any prerequisites?

You need a Mac with enough free capacity for a 4 GiB RAM and 30 GiB virtual-disk lab plus the RHEL installation media. No prior RHEL or DNF experience is required.

Before We Start

Before the hands-on work begins, commit to a disposable Red Hat Enterprise Linux 9 patching lab inside a virtual machine. The virtual machine leaves macOS unchanged while the guest keeps its own kernel, boot process, package database, and services.

Set Up Your RHEL 9 Lab VM

Security patching changes a running operating system. A virtual machine gives this lab its own kernel without changing macOS.

UTM will host Red Hat Enterprise Linux 9.8 on your Mac. Registration will unlock authorized DNF repositories inside the guest.

In this step, get ready to:
  • Install UTM 4.7.5 in /Applications.
  • Download the RHEL 9.8 DVD ISO that matches your Mac.
  • Build a registered RHEL Minimal Install virtual machine.
Install UTM 4.7.5

UTM is the virtual machine host for this lab. Version 4.7.5 provides the stable environment used throughout the project.

Why UTM Instead of a Container?

A normal Docker container shares its host's kernel. UTM hosts the entire RHEL guest with its own kernel.

That separation makes kernel installation plus reboot verification meaningful.

  • Press Cmd+Space to open macOS search.
  • Type Finder into the search field.
  • Press Enter to open Finder.

Finder opens so you can inspect the Mac's installed applications.

  • Navigate to /Applications in Finder.
  • Look for UTM.app in that folder.

The application list tells you whether UTM is already installed.

  • Display the macOS app information for UTM.app if the file exists.
  • Read the listed version number.

Choose the tab that matches the version you found.

✔️ The required version is installed

  • Press Cmd+Space to open macOS search.
  • Type UTM into the search field.
  • Press Enter to launch UTM.

UTM opens to its main window from /Applications/UTM.app.

ⓧ An older version is installed

The completed download appears in your Downloads folder.

  • Double-click UTM.dmg in your Downloads folder.

The mounted image opens with UTM.app ready to copy.

macOS may ask whether to replace the existing copy. Approving this replacement keeps the application at the same path.

  • Copy UTM.app from the mounted image into /Applications.
  • Approve the replacement if macOS asks for confirmation.

Finder now shows the updated application at /Applications/UTM.app.

  • Press Cmd+Space to open macOS search.
  • Type UTM into the search field.
  • Press Enter to launch UTM.

UTM opens to its main window with version 4.7.5 installed.

ⓧ UTM is not installed

The completed download appears in your Downloads folder.

  • Double-click UTM.dmg in your Downloads folder.

The mounted image opens with UTM.app ready to copy.

  • Copy UTM.app from the mounted image into /Applications.

Finder now shows the installed application at /Applications/UTM.app.

  • Press Cmd+Space to open macOS search.
  • Type UTM into the search field.
  • Press Enter to launch UTM.

UTM opens to its main window with version 4.7.5 installed.

That part is complete. UTM 4.7.5 is now open from /Applications/UTM.app.

Does UTM Fail to Open?

  • Confirm that the copy into /Applications finished.
  • Confirm that you launched /Applications/UTM.app instead of the copy inside the mounted image.

Ask for targeted help with the installation issue: Help me diagnose why UTM 4.7.5 does not open from /Applications/UTM.app on my Mac.

Download the matching RHEL 9.8 DVD ISO

A DVD ISO contains the installation media for the guest. Its processor architecture must match the Mac that runs UTM.

Registration uses your Red Hat credentials. The project never asks you to place those credentials in notes or screenshots.

  • Join the no-cost Red Hat Developer program.
  • Sign in to the RHEL download page with your Red Hat account.
  • Confirm that your account provides a no-cost RHEL subscription.

Your account now provides authorized access to the RHEL installation media.

  • Open the Apple menu in the corner of the screen.
  • Select About This Mac.

The system summary displays either a Chip field or a Processor field.

  • Use the displayed field to identify the Mac processor family.

Why Must the Architectures Match?

Native virtualization requires the guest architecture to match the host. Apple silicon uses aarch64.

Intel Macs use x86_64. Matching the architecture keeps the lab focused on RHEL administration.

The DVD ISO is a large download. A slow progress indicator is normal because download time depends on your internet connection.

Apple silicon

  • Select the Red Hat Enterprise Linux 9.8 aarch64 DVD ISO on the RHEL download page.
  • Start the DVD ISO download.

Your browser shows the download progress for the aarch64 image.

  • Wait for the browser to finish downloading the file.

The RHEL 9.8 aarch64 DVD ISO is now stored locally on your Mac.

Intel

  • Select the Red Hat Enterprise Linux 9.8 x86_64 DVD ISO on the RHEL download page.
  • Start the DVD ISO download.

Your browser shows the download progress for the x86_64 image.

  • Wait for the browser to finish downloading the file.

The RHEL 9.8 x86_64 DVD ISO is now stored locally on your Mac.

Build the registered RHEL VM

The ISO installs RHEL onto a virtual disk. UTM then boots that disk as an independent computer.

  • Click + in the UTM toolbar.
  • Select Virtualize.

The wizard now asks which type of guest you want to create.

  • Select Linux.
  • Click Continue.

The Linux setup screen is ready for the installation media.

  • Click Browse.
  • Select the downloaded RHEL 9.8 DVD ISO.

The wizard now shows the selected RHEL installation media.

  • Set the VM memory allocation to 4 GiB.
  • Click Continue.

The wizard advances to the storage configuration.

  • Set the virtual disk capacity to 30 GiB.
  • Click Continue.

The VM summary now reflects the lab's memory plus storage allocations.

  • Click Save to create the VM.
  • Click Run to boot the installation media.

The RHEL installer loads inside the UTM window. Your Mac remains unchanged outside the VM.

Minimal Install provides the operating system components needed for this administration lab. Registration connects the guest to authorized Red Hat content.

The registration screen handles sensitive account credentials. Keep the installer window out of screenshots while those fields are visible.

  • Select Minimal Install as the RHEL base environment.
  • Create the administrator credentials requested by the installer.

The installation summary now reflects the selected base environment plus administrator access.

  • Select Connect to Red Hat under Software.
  • Choose the Account option.

The registration screen now displays the Red Hat account fields.

  • Enter your Red Hat account credentials.
  • Submit the account details to complete registration.

The installer confirms that the guest is connected to Red Hat.

Installation is the slowest part of this step. A progress screen that sits quietly for several minutes is normal while packages copy to the virtual disk.

  • Start the installation from the completed summary.
  • Wait for the installer to report completion.

The longest setup task is complete. RHEL 9.8 is now installed on the VM's virtual disk.

The installer ISO remains attached as virtual installation media. Removing it makes the next boot use the installed virtual disk.

  • Stop the VM in UTM after the installer completes.
  • Open the VM's hardware settings from its UTM entry.

The virtual drive shows the attached RHEL installation media.

  • Remove the downloaded RHEL 9.8 DVD ISO from the virtual drive.
  • Close the VM settings.

The virtual disk is now the VM's boot source.

  • Start the VM in UTM.

You will see the installed RHEL login prompt instead of the installer.

  • Enter root as the username.
  • Enter the root password.

You are now working in a root terminal inside the installed RHEL guest.

Before you run the final check, picture the result that would prove registration worked.

  • Confirm repository access from the root terminal by running this command:
dnf repolist

What Does This Command Check?

  • The command asks DNF to list the repositories enabled for this RHEL guest.
  • A populated list proves that registration gives the guest access to Red Hat content.

The terminal lists enabled Red Hat repositories. This proves that the guest can retrieve signed package metadata.

No Repositories Listed?

  • Confirm that your Mac has an active internet connection.
  • Confirm that the VM has network access through UTM.
  • Confirm that the installer completed Red Hat account registration.

Ask for help with the repository check: Help me diagnose why dnf repolist does not show enabled Red Hat repositories in my registered RHEL 9.8 UTM virtual machine.

✔️ My lab matches

Your RHEL 9.8 VM boots from its virtual disk. Its root terminal can reach enabled Red Hat repositories.

ⓧ I'd like to double check the full setup

  • Confirm that UTM 4.7.5 is installed as /Applications/UTM.app.
  • Confirm that the downloaded RHEL 9.8 DVD ISO uses aarch64 on Apple silicon or x86_64 on Intel.
  • Confirm that the RHEL 9.8 lab VM has 4 GiB of RAM.
  • Confirm that the RHEL 9.8 lab VM has a 30 GiB virtual disk.
  • Confirm that RHEL uses the Minimal Install base environment.
  • Confirm that the guest is registered through Connect to Red Hat with the Account option.
  • Confirm that the installer ISO is removed from the virtual drive.
  • Confirm that the root terminal lists enabled Red Hat repositories.

Your registered RHEL 9.8 guest now boots from its virtual disk. Next, you will test why a generic update list cannot guide a security decision.

Review the Generic Update Baseline

Your registered RHEL 9.8 VM can already reach its enabled DNF repositories. That gives you a trusted source for checking available updates.

A general DNF package list can show pending work. It leaves out the evidence needed to rank security risk.

In this step, get ready to:
  • Reconfirm that the registered Red Hat repositories are reachable.
  • Display the generic package-update baseline.
  • Identify the security context missing from the baseline.
Check the Red Hat repositories again

Enabled repositories connect your registered VM to Red Hat package content. Rechecking them confirms that the update baseline comes from reachable sources.

  • Return to the root terminal in the RHEL guest from earlier.
  • Reconfirm the enabled repositories by running this command:
dnf repolist

What Does This Command Confirm?

  • The dnf repolist command asks DNF to list enabled software repositories.
  • The listed Red Hat repositories show which package sources are available to the guest.

You should see enabled Red Hat repository entries in the terminal. Your lab has a working package source for the baseline.

No Repository Entries?

  • Confirm that the UTM VM still has network access.
  • Confirm that the guest remains registered through the Red Hat account from the previous step.

Ask for help if the repository list stays empty: Help me diagnose why my registered RHEL 9.8 VM does not list enabled Red Hat repositories.

Capture the generic update baseline

An update baseline records the packages that have newer versions available. This first view tests how much security evidence a package-focused command provides.

Before you run this check, do you think a package list can explain which security risks should come first?

  • Display the currently available package updates by running this command:
dnf check-update

What Does This Baseline Contain?

  • Each package name identifies an installed component with an update available.
  • Each version shows the newer package build offered by the enabled repositories.
  • The result stays focused on package availability.

The terminal shows that package updates are available.

Full RHSA severity is absent from this output.

Detailed CVE information is absent. Advisory descriptions are absent too.

  • Keep this result visible in the root terminal.
  • Choose one package row from the result.
  • Identify the package name in the chosen row.
  • Identify the available version in the chosen row.
  • Confirm that the row does not include full RHSA severity.
  • Confirm that the output does not include CVE details.
  • Confirm that the output does not include advisory descriptions.

You have captured the intended shortfall. The generic baseline proves that updates exist without providing enough context for security prioritization.

Your generic update baseline is now recorded. Next, you will connect pending packages to security advisory evidence.

Inspect Security Advisories

The general update baseline proved that packages are waiting. Its package list leaves the reason for each change hidden.

The DNF advisory metadata connects those packages to Red Hat Security Advisories. The resulting details provide risk evidence before you change the VM.

In this step, get ready to:
  • List the pending security advisories.
  • Open the detailed record for one pending RHSA.
  • Gather the evidence needed to prioritize the advisory.
List pending security advisories

A pending advisory inventory narrows the repository metadata to security work. Each row gives you an RHSA identifier for a detailed lookup.

  • In the root terminal from earlier, list pending security updates by running this command:
dnf updateinfo list updates security

What Does This Command Show?

  • The dnf updateinfo list updates security command filters available updates to security advisories that are not installed.
  • Each result gives you an RHSA identifier for a deeper lookup.

You'll see one or more pending RHSA entries in the root terminal. Each entry represents an available security update.

No RHSA Entries Listed?

  • Confirm that the VM still has network access.
  • Confirm that the registered Red Hat repositories remain reachable.
  • Run the inventory command again.

If the list remains empty, help me check why no pending RHSAs appear.

  • Choose one RHSA identifier from the terminal output.
  • Record the selected identifier here: one RHSA identifier from your list.
Inspect one RHSA

The RHSA identifier opens the advisory behind the summary row. Its detail view supplies the evidence needed for a security-focused decision.

  • At the root prompt, type this command prefix without pressing Enter:
dnf updateinfo info

What Does This Command Do?

The dnf updateinfo info command selects the advisory detail view. Adding the selected RHSA identifier narrows the output to one advisory.

  • Press Space once.
  • Paste one RHSA identifier from your list after the command prefix.
  • Predict which security details this RHSA identifier will reveal.
  • Press Enter to run the completed advisory lookup.

You'll see Update ID near the top of the advisory. The type field shows Type: security.

Further down, you'll see the advisory severity. You'll also see its CVE information.

The package section names the affected package. The description explains the security risk.

Advisory Details Missing?

  • Compare the recorded RHSA identifier with the inventory output.
  • Remove any copied punctuation from the identifier.
  • Run the completed lookup again.

If the lookup still does not show the advisory, help me diagnose the RHSA lookup.

How to Read the Advisory

  • The Update ID identifies the advisory record.
  • The Type: security field confirms its security scope.
  • The severity signals the advisory's urgency.
  • The CVE identifiers connect the advisory to documented vulnerabilities.
  • The affected package names show which installed components need updates.
  • The description summarizes the security risk.
  • Locate the Update ID field.
  • Confirm that the type field shows Type: security.
  • Identify the advisory's severity.
  • Read the listed CVE identifiers.
  • Identify the affected package.
  • Read the advisory description.

You have closed the generic list's blind spot. The selected RHSA now provides evidence for a security-focused decision.

Your security advisory inventory is ready. Next, you'll use this evidence to apply only the updates that address security risks.

Apply Security-Only Updates

Your review of Red Hat Security Advisory metadata turned the general DNF package list into a prioritized maintenance plan. The inspected advisory gives this patch window a clear scope.

Installing only security updates keeps the change focused. Bug-fix updates plus enhancement updates stay outside this maintenance window.

In this step, get ready to:
  • Record the guest's running kernel before changing packages.
  • Install every currently available security update in one focused transaction.
  • Identify processes that may still use replaced components.
Record the running kernel

The kernel running in memory is the reference point for your later reboot check. A pre-update reading creates a baseline for that comparison.

  • Display the active kernel release by running this command:
uname -r

What Does This Command Show?

  • The uname -r command reports the kernel release currently running inside the guest.
  • This baseline lets you check whether a newer kernel becomes active after the later reboot.

The terminal prints the release string for the active kernel.

  • Record the displayed value here as your pre-update kernel version.
Install security-only updates

A package transaction calculates the package changes before anything is installed. The security filter limits this transaction to updates that address security advisories.

This change stays inside your disposable VM. Your Mac remains untouched.

  • Expect DNF to display a transaction summary before requesting approval.
  • Start the security-only transaction by running this command:
dnf update --security

What Does This Command Do?

  • The dnf update --security command resolves the security updates available from your enabled repositories.
  • The transaction summary gives you a final review point before installed packages change.
  • Review the package list in the transaction summary.
  • Enter y at the approval prompt.

DNF completes the transaction before returning to the root prompt.

The focused patch transaction is complete. Your disposable VM now has every security update that was available during this maintenance window.

Does the Security Transaction Stop?

  • Confirm the VM still has network access if DNF cannot download packages.
  • Confirm the registered Red Hat repositories remain reachable before retrying the transaction.

Help me diagnose the DNF security update transaction.

Check for processes that need restarting

Updated files can coexist with older components that processes already loaded into memory. The dnf needs-restarting check identifies processes that may require a manual restart.

Before you run the check, predict whether any process still uses replaced components.

  • Identify processes that may require a restart by running this command:
dnf needs-restarting

What Does This Command Check?

  • The dnf needs-restarting command checks running processes against components replaced by the update transaction.
  • Each returned entry identifies a process that may need manual attention.

The terminal lists any processes that may require a restart. An empty result means the check found no such process entries.

Does the Restart Check Fail?

  • Confirm that you typed needs-restarting with the hyphen in the correct position.
  • Confirm that the security transaction returned to the root prompt before retrying the check.

Help me diagnose the restart check.

Your pre-update kernel baseline plus the completed transaction define the maintenance record for this step. The restart check shows which running processes may still need attention.

The focused maintenance window is complete. Next, you will reboot the guest. You will then prove the patched state.

Reboot and Verify the Patched State

The security transaction replaced packages on disk. Running processes can still hold older code in memory.

A controlled reboot gives your RHEL guest a fresh boot cycle. The guest can then load the patched state into memory.

After login, the active kernel shows what the guest is running. A final DNF query reveals whether any security advisories remain pending.

In this step, get ready to:
  • Reboot the guest into its patched state.
  • Compare the active kernel with the pre-update value.
  • Confirm that no security advisories remain pending.
Reboot the RHEL guest

A reboot restarts the guest operating system. Your Mac remains outside this patch cycle.

Before you run this command, predict whether the guest terminal will stay connected during the reboot.

  • Reboot the RHEL guest by running this command:
systemctl reboot

What Does This Command Do?

  • The systemctl reboot command hands the controlled reboot to systemd.
  • The reboot stops running programs plus services before the guest shuts down.
  • The guest starts again immediately from its virtual disk.
  • Wait for the RHEL login prompt to return.

You will see the RHEL login prompt return. This confirms that the guest completed a full boot cycle.

  • Log back in as root.

The disruptive part is complete. You are back at a root terminal in the rebooted guest.

Does the Login Prompt Stay Away?

  • Return to UTM on your Mac.
  • Confirm that the RHEL VM is still running.
  • Select Run if the VM has stopped.

If the guest still does not return to its login prompt, help me diagnose the failed RHEL reboot.

Compare the active kernel

The kernel version changes only when the security transaction installs a newer kernel. An unchanged value can still be correct when no newer kernel was included.

Before you check, predict whether every security transaction must change the active kernel.

  • Check the active kernel after reboot by running this command:
uname -r

What Does This Command Show?

  • The uname -r command prints the kernel currently running after the reboot.
  • The result gives you a direct comparison point for the kernel value recorded before patching.
  • Compare the reported value with the kernel value you recorded before patching.

A changed value shows that a different kernel is active. An unchanged value is expected when the security transaction did not install a newer kernel.

Confirm the security advisory state

The final query checks enabled repository metadata for security updates that remain available but uninstalled. Each Red Hat Security Advisory entry would identify pending security work.

Before you run the final check, predict whether the pending advisory list will contain any RHSA entries.

  • Check for remaining security advisories by running this command:
dnf updateinfo list updates security

What Does This Check Prove?

  • The updates security filter limits the result to available security updates that are not installed.
  • Running the query after reboot checks the repository state after the patch transaction.

You should see no pending RHSA entries. This records that no security advisories are pending at this verification time.

You have completed the patch cycle. Your guest rebooted successfully with its active kernel identified plus its pending security state verified.

Do You Still See RHSA Entries?

Remaining RHSA entries mean the verified end state has not been reached.

  • Inspect every remaining RHSA before claiming that the patch cycle is complete.
  • Repeat the security-only update transaction from the previous step if the remaining advisories belong to this maintenance window.

If you need help interpreting the remaining entries, help me investigate my pending RHEL security advisories.

Secret mission

Automate Future Security Updates

Turn the manual patch cycle into a scheduled security control. Configure DNF Automatic for security updates. Prove its systemd timer is active.

Clean Up Your Resources

Clean Up Your Resources

Choose whether to keep your local lab available, shut down the guest for later, or remove its stored data. Everything here is free, but the virtual machine and installer ISO use space on your Mac.

Resources you used:

  • One registered Red Hat Enterprise Linux 9.8 lab VM in UTM 4.7.5 with a 30 GiB virtual disk.
  • One downloaded RHEL 9.8 DVD ISO for aarch64 or x86_64.
  • An enabled DNF Automatic installation timer managed by systemd inside the VM.

Keep everything running

No action is needed. Choose this if you want to keep practicing RHEL administration in the same lab.

  • Keep the RHEL 9.8 VM in UTM for future patch cycles.
  • Retain the matching DVD ISO in case you want to reinstall the guest.
  • Leave the automatic installation timer enabled for future security updates.

Pause - I'll come back to this later

Shut down the guest to release its assigned 4 GiB of memory. The virtual disk and automatic-update configuration stay ready for your next session.

  • Switch back to UTM from earlier.
  • Select the running RHEL 9.8 lab VM.
  • Use the power control in the VM window toolbar to request a guest shutdown.
  • Wait for the guest display to close.

You will see that the VM is no longer running. Its virtual disk and timer configuration remain stored in UTM.

Delete - I don't want to use this again

Deleting the VM is irreversible. Your Mac host and Red Hat Developer account stay untouched.

  • Switch back to UTM from earlier.
  • Shut down the RHEL 9.8 guest with the VM window power control if it is running.
  • Control-click the RHEL 9.8 lab VM card.
  • Select the context-menu option that deletes the selected VM.
  • Choose removal of the associated VM data in the confirmation window.
  • Confirm the deletion.

You will no longer see the VM card in UTM. This removes the virtual disk and the automatic-update configuration stored inside it.

  • Click the Finder icon in the Dock.
  • Enter .iso in Finder's search field.
  • Select the RHEL 9.8 DVD ISO that matches your Mac architecture.
  • Drag the selected DVD ISO to Trash in the Dock.
  • Control-click Trash in the Dock.
  • Choose the option that empties Trash.

The Finder search no longer shows the downloaded RHEL installer. UTM 4.7.5 remains installed at /Applications/UTM.app for future labs.

Nice Work!

Nice Work!

You did it! Your disposable Red Hat Enterprise Linux 9.8 lab now completes a verified security-patching cycle inside UTM.

You've learned how to:

  • Create a registered virtual machine that boots from its own virtual disk inside UTM.
  • Use DNF to expose the limits of a generic package update list. Inspect pending Red Hat Security Advisories to connect each fix with its severity plus CVEs.
  • Apply security-only updates during a focused maintenance window. Identify processes still using replaced components. Reboot the guest to verify its active kernel. Confirm an empty pending-advisory list after the guest returns.
  • Secret Mission: Configure DNF Automatic to install future security updates through an active systemd timer.

Ready to quiz yourself?