Deploy RHEL 9 VM from vSphere Template

Deploy a customized RHEL 9 VM from a vSphere template to a tagged VLAN.

Introduction

30 Second Summary

A copied server can power on while still carrying the original machine's name or network settings. That hidden overlap can break connectivity or create an identity conflict in a shared lab.

In this project, you will turn an existing Red Hat Enterprise Linux 9 VM template into a repeatable VMware vSphere deployment workflow. You will launch a virtual machine with its own hostname and static IPv4 settings on an approved VLAN.

What You'll Build

You'll watch a fresh RHEL 9 VM boot with the exact identity and network settings approved for your lab.

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

  • A baseline clone that boots on the selected port group while exposing its inherited hostname or source-network settings.
  • A reusable deployment workflow that asks for each VM's hostname and static IPv4 settings when you launch it.
  • Clear deployment evidence that connects successful vSphere tasks to the VM's hostname, default route, and DNS settings.
  • Secret Mission: Move the working VM to the alternate VLAN and restore connectivity by updating its NetworkManager profile with nmtui and checking it with nmcli.

Are there any prerequisites?

You need a Windows workstation with administrator access to vSphere Client plus sudo access inside an existing RHEL 9 inventory template. The lab must provide enabled RHEL repositories, an approved port group for VLAN 214 or VLAN 215, and one reserved static IPv4 address with gateway and DNS values.

Before We Start

Before any hands-on work begins, commit to the deployment you are about to make. This checkpoint ties your source template to an approved network identity with a clear purpose.

Record the Lab Network Inputs

A reusable VM template needs one approved network plan before it can assign an identity safely. A VLAN number by itself leaves the guest identity undefined.

The vSphere Client provides the source placement plus target port group details. NetworkManager inside the Project 1 Red Hat Enterprise Linux 9 VM provides the guest-side reference.

This step ties those sources to the reserved IPv4 address. The completed worksheet captures every value needed for a safe deployment.

In this step, get ready to:
  • Record the source template placement plus its operating-system disk attachment.
  • Map the approved target port group to its VLAN plus complete IPv4 settings.
  • Inspect the Project 1 VM network state from its console.
Record the source template placement

The source template carries its existing virtual hardware into future deployments. Recording its placement gives you a known starting point before any conversion or cloning work.

  • Select the existing RHEL 9 source template in the vSphere Client inventory.
  • Record its inventory name as your source template.
  • Record its current port group as your source port group.
  • Record its datastore as your datastore.
  • Record its compute resource as your compute resource.
  • Inspect the template hardware to locate the operating-system disk.
  • Confirm the operating-system disk is attached at SCSI 0:0.
  • Mark the disk attachment as SCSI 0:0 in the lab worksheet.

Why Does SCSI 0:0 Matter?

vSphere Linux guest customization expects the guest operating-system disk at SCSI 0:0. Recording that attachment now rules out a hardware-layout problem before you prepare the template.

Is the Disk Attached Somewhere Else?

Record the current attachment without moving the disk. Confirm that you selected the approved source template before continuing.

Ask for help interpreting the template hardware.

Map the approved VLAN to IPv4 settings

The target port group determines which virtual Ethernet segment receives the VM traffic. The guest network plan supplies the address information used inside RHEL.

  • Select each approved candidate port group in the vSphere Client inventory.
  • Inspect the configured VLAN ID for each candidate.
  • Identify the candidate mapped to the approved target of 214 or 215.
  • Record the exact port group name as your approved target port group.
  • Record its configured VLAN as 214 or 215.

How Do the Two Network Layers Fit Together?

The vSphere virtual switch tags traffic with the VLAN configured on the port group. It delivers that traffic to the attached VM.

RHEL uses its own IPv4 configuration for the address. It uses a default gateway for off-subnet traffic.

DNS settings resolve names inside the guest. The worksheet keeps both network layers tied to the same approved plan.

  • Record the reserved main-deployment address as your reserved main IPv4 address.
  • Record the approved prefix as /24.
  • Record the approved gateway as your default gateway.
  • Record the approved DNS server as your IPv4 DNS server.
  • Record the approved search domain as your DNS search domain.
  • Record the unique deployment hostname as your unique deployment hostname.
Inspect the Project 1 guest network

The existing Project 1 VM provides a working guest-side reference. Its device state plus current network settings show what a complete RHEL configuration contains.

  • Select the existing Project 1 RHEL 9 VM in the vSphere Client inventory.
  • Open the VM console.
  • Log in with your sudo-enabled RHEL account.

Before you run these checks, do you expect the existing VM to match every value reserved for the new deployment?

  • Inspect the guest network baseline by running these commands:
nmcli device status
nmcli connection show
ip route show default
cat /etc/resolv.conf
hostnamectl status --static

What Do These Commands Check?

  • The nmcli device status command reports the virtual NIC state. It also identifies the active connection.
  • The nmcli connection show command lists the NetworkManager connection profiles.
  • The ip route show default command displays the IPv4 default gateway.
  • The cat /etc/resolv.conf command displays the active DNS nameserver plus search entries.
  • The hostnamectl status --static command displays the static hostname.
  • Record the command results in the lab worksheet.
  • Compare the observed guest settings with the reserved main-deployment values.
  • Confirm the worksheet includes device state plus connection profiles.
  • Confirm the worksheet includes a default route plus DNS settings.
  • Confirm the worksheet includes the current static hostname.

You will see the VM network devices plus its NetworkManager profiles. You will also see its current route, DNS configuration, and static hostname.

Together, those outputs prove that the worksheet describes a complete guest configuration. The target port group entry proves that the matching vSphere network layer is recorded.

Missing Network Details?

If a command returns no useful network data, confirm that the console belongs to the existing Project 1 VM. Record any missing route or DNS value before changing the guest.

Help me diagnose missing RHEL network details.

✔️ Awesome, I've got everything!

Your worksheet now captures the source template, approved target network, reserved guest identity, and Project 1 VM reference state. Keep it available for the deployment steps that follow.

ⓧ I'd like to double check the full code

This step creates a worksheet plus verified inventory state. Compare your results with these target artifacts.

  • Existing RHEL 9 source template: Existing inventory template identified in vSphere. Its current placement and hardware details are recorded in the lab worksheet.
  • Lab worksheet: Records the source RHEL 9 template, source port group, datastore, compute resource, SCSI 0:0 disk placement, approved target port group name, target VLAN ID 214 or 215, reserved main IPv4 address, /24 prefix, gateway, DNS server, DNS search domain, and unique deployment hostname.
  • Project 1 RHEL 9 VM: Existing VM inspected from its console. NetworkManager device status, connection profiles, default route, DNS settings, and static hostname are recorded in the lab worksheet.

You have removed the guesswork from the deployment. Next, you will use the recorded plan to expose what a plain template clone leaves unchanged.

Test a Plain Template Clone

Your lab worksheet now connects the source template to an approved network identity. Those recorded values give you a reliable baseline for testing what a plain clone actually inherits.

A port group in vSphere Client places a virtual network adapter on a specific VLAN. This step tests whether that placement also updates the hostname and network settings inside Red Hat Enterprise Linux 9.

In this step, get ready to:
  • Deploy a temporary clone without guest operating system customization.
  • Boot the clone through the vSphere console.
  • Prove whether port-group placement changes the guest settings recorded in your worksheet.
Deploy the baseline clone

Deploying from a VM template copies its virtual hardware and configured properties. You will change the network placement while leaving guest customization disabled, which isolates the effect of the port group.

  • Switch back to the vSphere Client session from earlier.
  • Find the existing RHEL 9 source template recorded in your lab worksheet.
  • Right-click the source template.
  • Select New VM from This Template.

You should see the deployment wizard identify the source template you selected.

  • Enter your temporary baseline VM name in the VM name field.
  • Select the compute resource recorded in your worksheet.

The wizard should now show your temporary VM name and the recorded compute resource.

  • Select the datastore recorded in your worksheet.
  • Set the virtual network adapter to the approved target port group from your worksheet.

The hardware summary should show the approved VLAN 214 or VLAN 215 port group beside the virtual network adapter.

  • Keep Customize the operating system cleared in the clone options.
  • Finish the deployment.

The deployment creates a separate baseline VM while preserving the source template.

  • Wait for the deployment task to report successful completion.
  • Select your temporary baseline VM name in the inventory.
  • Confirm that its virtual network adapter shows the approved target port group.

Did the clone deployment fail?

Check that you selected the source template and placement values recorded in your worksheet. A permissions or capacity problem in the selected compute resource or datastore may require help from your lab administrator.

Ask for help with diagnosing the failed template deployment.

Boot through the vSphere console

Remote access depends on the guest having a usable address and route. The vSphere console gives you direct access even when the clone's network configuration does not match its new placement.

  • Select your temporary baseline VM name in the inventory.
  • Use the VM power control to start the baseline VM.

You should see the VM status change to powered on.

  • Open the baseline VM through the vSphere console.
  • Sign in with your existing RHEL account.

That first boot is your visible win. The clone is running on the approved port group and remains accessible through the console.

Does the baseline VM fail to boot?

Confirm that the clone task completed successfully. Check that the operating-system disk is still attached at SCSI 0:0.

Ask for help with troubleshooting the baseline VM boot.

Compare the guest settings

The worksheet contains the hostname and static network values intended for the final deployment. You can now compare those values with the clone's actual NetworkManager profile and active DNS configuration.

Before you run these checks, do you think the guest settings changed when you selected the new port group?

  • Inspect the baseline clone from its console by running these commands:
hostnamectl status --static
nmcli connection show
ip route show default
cat /etc/resolv.conf

What do these checks reveal?

  • The first command displays the clone's static hostname.
  • The second command lists its NetworkManager connection profiles.
  • The third command displays its IPv4 default route.
  • The fourth command displays its active DNS search and nameserver entries.

You should see the template identity or source-network values instead of the reserved deployment values from your worksheet. This mismatch is the intended result.

What does the mismatch prove?

The vSphere port group controls the virtual Ethernet segment used by the VM. It does not rewrite the hostname or static IPv4 settings inside RHEL.

NetworkManager still holds the copied guest configuration. A reusable deployment needs both network placement and guest customization to agree.

Do the commands show unexpected values?

Confirm that you are signed in to the temporary baseline VM through its own console. Compare the displayed hostname and network values with both the source settings and the reserved deployment values in your worksheet.

Ask for help with interpreting the baseline clone results.

  • Record the clone's static hostname in your lab worksheet.
  • Record the clone's NetworkManager connection profile in your lab worksheet.
  • Record the clone's default route in your lab worksheet.
  • Record the clone's DNS configuration in your lab worksheet.
  • Compare the recorded results with the reserved deployment values.
  • Record that the port group changed while the guest identity or source-network settings remained stale.
  • Use the VM power control in vSphere Client to power off the baseline VM.
  • Confirm that the baseline VM status shows powered off.

The powered-off baseline VM now preserves clear evidence of the mismatch. Your worksheet captures exactly what the port-group change did and what it left untouched.

You have exposed the gap that makes a plain clone unsuitable for repeatable server deployment. Next, you will prepare a RHEL 9 template that can accept guest customization from vCenter.

Prepare the RHEL 9 Template

The baseline clone proved that selecting a new port group in the vSphere Client leaves the RHEL 9 guest identity unchanged.

Guest customization needs Open VM Tools, Perl, NetworkManager, and D-Bus tools inside the image. You will add those prerequisites before cloning the prepared VM into a reusable template.

In this step, get ready to:
  • Convert the original source template into a virtual machine.
  • Install and verify the Linux guest customization prerequisites.
  • Create the powered-off RHEL9-GOSC-Ready template.
Convert the source template to a VM

An inventory template must become a virtual machine before you can update its guest operating system. This conversion changes the original inventory object in place.

What changes during conversion?

Changing the source object can feel risky. The conversion does not create a copy, so the final part of this step creates a new reusable template from the prepared VM.

  • Use the lab worksheet to locate the existing RHEL 9 source template in the vSphere Client inventory.
  • Right-click the source template.
  • Select Convert to Virtual Machine.
  • Choose the normal compute resource recorded in the lab worksheet.
  • Complete the conversion.

What did the conversion do?

The source object is now a virtual machine that can boot into RHEL 9. The powered-off temporary baseline VM remains unchanged.

  • Read the source hostname from the baseline results in your lab worksheet.
  • Confirm that no running VM uses the recorded source hostname.
  • Read the source static address from the baseline results in your lab worksheet.
  • Confirm that no running VM uses the recorded source static address.
  • Power on the converted source VM from its inventory actions.
  • Open the converted source VM console from its vSphere Client page.
  • Sign in with your sudo-enabled RHEL account.

Good progress. You should reach a RHEL shell prompt without creating a hostname or address conflict in the lab.

Cannot convert or start the source VM?

  • Confirm that you selected the inventory template recorded in the lab worksheet.
  • Confirm that the compute resource matches the source template placement recorded earlier.
  • Check that the temporary baseline VM remains powered off.

Ask for help with converting or starting the RHEL 9 source template.

Install and verify customization prerequisites

The default Linux customization engine depends on VMware Tools and Perl. Minimal RHEL installations can also be missing the D-Bus utility that customization needs.

The DNF transaction may take a few minutes while it resolves dependencies from the enabled repositories. It displays a transaction summary before installing the packages.

  • Prepare to approve the transaction by entering y when DNF asks for confirmation.
  • Install the customization prerequisites by running:
sudo dnf install open-vm-tools perl NetworkManager NetworkManager-tui dbus-tools

What do these packages provide?

  • The open-vm-tools package lets vCenter Server coordinate guest customization inside RHEL.
  • The perl package supports the default Linux customization engine.
  • The NetworkManager package manages the guest network profile.
  • The NetworkManager-tui package provides the text interface used for console-based network recovery.
  • The dbus-tools package provides the utility used to ensure the machine ID.

You should see DNF complete the transaction with each package installed or already present.

Package installation failed?

  • Confirm that the VM can reach the enabled RHEL repositories.
  • Check that your account has sudo access.
  • Review the package name shown beside the failure before retrying the installation command.

Ask for help with a RHEL 9 DNF installation error.

  • Enable Open VM Tools at boot by running:
sudo systemctl enable vmtoolsd.service

Why enable the service?

The vmtoolsd.service service runs Open VM Tools when a deployed VM starts. Enabling it prepares future clones to receive customization instructions.

You should return to the shell prompt without an error.

Service unit unavailable?

  • Confirm that the package installation completed successfully.
  • Check the package verification results in the next command for a missing Open VM Tools package.

Ask for help with enabling vmtoolsd.service on RHEL 9.

Before you check, which five package names do you expect the query to return?

  • Verify the installed package names and versions by running:
rpm -q open-vm-tools perl NetworkManager NetworkManager-tui dbus-tools

What does this check prove?

The package query reports the installed name and version for each prerequisite. A missing-package result identifies the exact dependency that still needs attention.

You should see one installed package result for each of the five prerequisites.

Seeing a missing package?

  • Match the missing result to the package list above.
  • Run the package installation command again after resolving repository access.
  • Repeat the package query until all five packages return installed versions.

Ask for help with a missing RHEL customization package.

  • Verify that NetworkManager can see the virtual NIC by running:
nmcli device status

What does the device check show?

The device table lists each network interface with its type and current state. It also identifies the active connection when one is present.

You should see a row for the VM's virtual NIC.

Virtual NIC missing from the table?

  • Confirm that the VM still has a virtual network adapter in its vSphere hardware.
  • Confirm that the NetworkManager package appeared in the package query results.
  • Compare the virtual hardware with the source details recorded in the lab worksheet.

Ask for help with a virtual NIC missing from nmcli.

  • Ensure that RHEL has a valid machine ID by running:
sudo dbus-uuidgen --ensure=/etc/machine-id

Why ensure the machine ID?

The D-Bus utility ensures that /etc/machine-id exists before guest customization runs. Missing D-Bus tooling can stop hostname and network changes from completing.

The command should return control to the shell prompt without an error.

Machine ID check failed?

  • Confirm that the dbus-tools package appeared in the package query results.
  • Confirm that your account can use sudo.
  • Retry the command after installing the missing package.

Ask for help with ensuring the RHEL machine ID.

Clone the prepared VM to a template

A powered-off source gives the clone task a stable guest state. The new template preserves the prerequisite packages and machine identity preparation for later deployments.

  • Power off the prepared source VM from its vSphere Client inventory actions.
  • Confirm that the prepared source VM shows a powered-off state.
  • Right-click the prepared source VM.
  • Select Clone.
  • Select Clone to Template.
  • Enter RHEL9-GOSC-Ready as the template name.
  • Choose the compute resource recorded in the lab worksheet.
  • Choose the datastore recorded in the lab worksheet.

What does the clone preserve?

The template clone contains the installed guest customization packages. It also preserves the enabled Open VM Tools service and valid machine ID.

  • Complete the clone wizard.

The clone task may take a few minutes while vCenter copies the prepared VM. A task that remains in progress during that copy is expected.

Before you inspect the task, do you expect the new inventory object to appear as a reusable template or a powered-on VM?

  • Select the prepared source VM in the vSphere Client inventory.
  • Open Monitor.
  • Open Tasks and Events.
  • Select Tasks.
  • Expand the clone task after it finishes.
  • Confirm that the clone task completed successfully.
  • Select RHEL9-GOSC-Ready in the inventory.
  • Confirm that RHEL9-GOSC-Ready is a powered-off template.

That is the preparation complete. Your RHEL9-GOSC-Ready template now carries every Linux guest customization prerequisite from this step.

Clone task did not complete?

  • Expand the failed clone task to read its recorded details.
  • Confirm that the selected compute resource matches the lab worksheet.
  • Confirm that the selected datastore matches the lab worksheet.
  • Confirm that the prepared source VM is powered off before retrying.

Ask for help with a failed vSphere clone-to-template task.

Your reusable RHEL 9 image is ready. Next, you will create the customization specification that supplies a unique hostname and static IPv4 settings during deployment.

Create the Linux Customization Specification

Your powered-off RHEL9-GOSC-Ready template now has the guest-side prerequisites for guest customization. The next deployment still needs a unique identity.

Hard-coding one server's hostname or address would make that deployment setup disposable. A reusable customization specification collects deployment-specific values while keeping the shared network pattern.

In this step, get ready to:
  • Create a reusable traditional Linux customization specification.
  • Set the deployment identity behavior for each cloned VM.
  • Define the static IPv4 pattern from your approved worksheet.
Create the Linux specification

The specification stores the reusable choices that vCenter applies during deployment. Its name also makes the intended operating system clear when you select it later.

  • In the vSphere Client from earlier, select Policies and Profiles from the main menu.
  • Select VM Customization Specifications in the left navigation.

You should see the inventory of customization specifications available in your vCenter environment.

  • Start New VM Guest Customization Specification from the specifications toolbar.
  • Enter RHEL9-LinuxPrep-Static as the specification name.

The wizard now identifies the specification with the reusable name you will select during future deployments.

  • Select Linux as the guest operating system.
  • Choose traditional guest customization for the specification.

The specification now uses the traditional Linux customization path. Raw cloud-init data remains outside this workflow.

Why Use Traditional LinuxPrep?

The traditional LinuxPrep path matches the prerequisites already installed in RHEL9-GOSC-Ready.

Raw cloud-init data requires a separate metadata workflow. Keeping that path out of this specification preserves the shorter reusable flow for this lab.

Configure deployment-time identity

Each clone needs its own hostname. A deployment-time prompt lets one specification serve many VMs without storing one permanent identity.

  • Move to the Computer name page in the wizard.
  • Select Enter a name in the Clone/Deploy wizard.

The computer name now stays open for each clone. The specification can serve many VMs without reusing one hostname.

  • Select your lab's approved time zone.
  • Confirm the Customization script area is empty.

The identity settings now use the selected lab time zone. No customization script runs during deployment.

Configure IPv4 settings and save

A port group places the virtual NIC on the selected VLAN. The specification supplies the guest's Layer 3 network values.

Keeping these layers separate lets the template deploy safely with an approved network identity.

  • Move to the Network page in the wizard.
  • Select Manually select custom settings.

The network page now uses explicit settings instead of inheriting the source template's configuration.

  • Configure the network mapping for IPv4.
  • Select Prompt the user for an IPv4 address when the specification is used.

The deployment wizard now collects the IPv4 address plus gateway. The approved prefix for this workflow is /24.

  • Enter the approved IPv4 DNS server from your lab worksheet.
  • Enter the approved DNS search domain from your lab worksheet.

Those shared DNS values stay inside the specification. Every deployment receives the same approved resolver pattern.

  • Open Ready to complete.

You should see a Linux specification named RHEL9-LinuxPrep-Static. Its summary should show deployment-time identity plus manual IPv4 customization.

  • Save the specification from Ready to complete.

You have the reusable piece in place: RHEL9-LinuxPrep-Static stores the shared network pattern while leaving each server's identity open.

Before you check the list, do you expect the saved entry to be reusable for more than one VM?

  • Return to VM Customization Specifications to verify the saved entry.

You should see RHEL9-LinuxPrep-Static listed as a saved Linux specification. The review you completed confirms that it requests a computer name plus IPv4 values during deployment.

Specification Missing or Incorrect?

  • Return to VM Customization Specifications to confirm you are viewing the same vCenter inventory.
  • Reopen New VM Guest Customization Specification if the previous wizard remained incomplete.
  • Check the specification name for an exact match with RHEL9-LinuxPrep-Static.

Help me troubleshoot a missing or incorrectly configured Linux customization specification in vSphere Client.

Your reusable Linux customization specification is ready. Next, you will deploy RHEL9-GOSC-Ready with a unique hostname plus the approved static IPv4 settings.

Deploy and Verify the Customized VM

Your reusable Linux customization specification is ready to turn the prepared VM template into a uniquely configured server. The final deployment must prove that the inventory placement matches the guest configuration.

The VMware vSphere Client records the deployment across the selected VLAN. Inside the Red Hat Enterprise Linux guest, NetworkManager provides the evidence that the approved network settings reached the operating system.

In this step, get ready to:
  • Deploy a final VM from RHEL9-GOSC-Ready using RHEL9-LinuxPrep-Static.
  • Review the related deployment tasks and events in vSphere Client.
  • Verify the guest hostname and static network configuration from the console.
Deploy from the prepared template

The prepared template supplies the guest software. The saved specification supplies the deployment-specific identity and network settings.

  • In your existing vSphere Client session, right-click RHEL9-GOSC-Ready in the inventory.
  • Select New VM from This Template.
  • Enter a clear inventory name for the final VM: your final VM name.
  • Select the compute resource recorded in your lab worksheet.

The wizard should now show your new VM name. It should also show the worksheet's compute resource.

  • Select the datastore recorded in your lab worksheet.
  • Attach the virtual NIC to the worksheet-approved port group for VLAN 214 or VLAN 215.

The hardware summary should now show the approved port group beside the virtual NIC. This confirms the VM is placed on the intended Ethernet segment.

  • On Select clone options, select Customize the operating system.
  • Continue to Customize guest OS.

The customization page connects this deployment to the reusable specification you prepared earlier.

  • Choose Select an existing specification.
  • Select RHEL9-LinuxPrep-Static.

The selected specification should now appear as the customization source for the final VM.

  • On User settings, enter the unique deployment hostname from your worksheet.
  • Enter the reserved main static IPv4 address from your worksheet.

The deployment now has its unique guest identity. It also has its reserved address.

  • Enter the /24 prefix recorded in your worksheet.
  • Enter the default gateway recorded in your worksheet.

The DNS server and DNS search domain already come from RHEL9-LinuxPrep-Static. The wizard combines those reusable values with the settings you entered for this VM.

  • Review the deployment summary against your completed lab worksheet.
  • Click Finish to start the deployment.

The first start can include several automatic restarts while Linux finalization scripts run. Repeated console reconnects are expected during this process.

  • Wait for the deployment task to complete successfully.
  • Open the VM's vSphere console.

You should reach the guest login prompt after the customization restarts finish. The successful boot confirms that the customized VM can start on the selected port group.

Review the deployment history

A working console proves that the guest booted. The vSphere task and event history shows whether the platform completed the deployment workflow successfully.

  • Select your final VM name in the vSphere inventory.
  • Open Monitor.
  • Under Tasks and Events, select Tasks.
  • Expand the deployment task to review its status and related details.

The deployment task should show successful completion. Its details should identify your final VM as the target.

  • Select Events under Monitor.
  • Expand the related deployment event to review its details.

The event history should align with the completed deployment task. Together, these records provide vCenter-side evidence for the provisioning workflow.

Verify the customized guest

The final proof comes from inside the guest. These checks compare its identity and active network state with the approved values in your worksheet.

  • Return to the vSphere console for the final VM.
  • Sign in with your sudo-enabled account.

Before you run the checks, do you expect this VM to show the worksheet values or the stale settings seen on the baseline clone?

  • Verify the guest identity and network state by running these commands:
hostnamectl status --static
nmcli device status
nmcli -f ALL connection show
ip route show default
cat /etc/resolv.conf

What do these checks prove?

  • The hostnamectl status --static output shows whether the guest received the worksheet's unique hostname.
  • The nmcli device status output shows whether the virtual NIC is connected.
  • The nmcli -f ALL connection show output exposes the active profile and its detailed IPv4 configuration.
  • The ip route show default output identifies the active default gateway.
  • The cat /etc/resolv.conf output shows the active DNS server and search domain.

The static hostname should match the worksheet. NetworkManager should show the virtual NIC as connected with the reserved main address.

The default route should use the worksheet gateway. The resolver file should show the approved DNS server and DNS search domain.

That closes the loop from the baseline mismatch. Your final VM now has the approved identity and network configuration on the intended VLAN.

Customization values do not match?

A mismatch means the guest customization process needs closer inspection. Start with vSphere evidence before changing the network profile manually.

  • Inspect the guest customization log at /var/log/vmware-imc/toolsDeployPkg.log.
  • Compare the recorded failure with the package checks completed on the prepared source VM.
  • Review the detailed active profile from the nmcli -f ALL connection show output above.
  • Use nmtui from the console to restore the worksheet's approved IPv4 settings before retrying from RHEL9-GOSC-Ready.

The template remains your clean retry point. A corrected deployment should reproduce the worksheet values without inheriting the baseline clone's stale identity.

Help me trace a failed Linux guest customization from vSphere tasks to the guest log and NetworkManager profile.

Secret mission

Secret Mission: Move the VM to the Alternate VLAN

Your RHEL 9 VM works on one lab VLAN. Can you migrate it to the alternate segment and restore connectivity from the vSphere console while proving that both networking layers agree?

Clean Up Your Resources

Clean Up Your Resources

Your existing vSphere lab has no additional licensing charge for these resources. However, the virtual machines and template continue to consume datastore capacity until you remove them.

Decide whether to keep the deployment path available, pause the final VM for later, or delete every resource created or converted during this project.

Resources you used:

  • Temporary baseline VM, currently powered off.
  • Prepared source VM converted from the original source template, currently powered off.
  • Prepared RHEL9-GOSC-Ready template.
  • Saved RHEL9-LinuxPrep-Static customization specification.
  • Final customized RHEL 9 VM, currently running on the alternate approved VLAN port group.

Keep everything running

Keep the reusable deployment resources if you plan to provision more RHEL 9 VMs. The temporary baseline has already served its purpose.

  • Leave the final customized VM available on the alternate approved VLAN port group.
  • Keep the prepared source VM powered off as a fallback image.
  • Keep the RHEL9-GOSC-Ready template for future deployments.
  • Keep the RHEL9-LinuxPrep-Static customization specification for future deployments.
  • Keep the lab worksheet with the reserved main and alternate network values.
  • Delete the powered-off temporary baseline VM from the vSphere Client inventory using the permanent datastore deletion action.
  • Confirm that the temporary baseline VM no longer appears in the inventory.

Pause - I'll come back to this later

Power off the final VM to release active compute resources while preserving every reusable artifact. Your prepared source VM and temporary baseline VM are already powered off.

  • Select the final customized VM in the vSphere Client inventory.
  • Power off the final customized VM using its power controls.
  • Confirm that the final customized VM shows a powered-off state.
  • Leave the prepared source VM powered off.
  • Leave the temporary baseline VM powered off.
  • Retain the RHEL9-GOSC-Ready template.
  • Retain the RHEL9-LinuxPrep-Static customization specification.
  • Confirm that the main and alternate static addresses remain reserved in your lab records.

Delete - I don't want to use this again

Deletion is permanent. Your existing Project 1 RHEL 9 VM remains outside this cleanup because these actions target only resources created or converted during this project.

  • Confirm that no future deployment depends on the RHEL9-GOSC-Ready template.
  • Confirm that no future deployment depends on the RHEL9-LinuxPrep-Static customization specification.
  • Power off the final customized VM from the vSphere Client inventory.
  • Delete the powered-off temporary baseline VM using the inventory action that permanently removes its datastore files.
  • Delete the powered-off prepared source VM using the inventory action that permanently removes its datastore files.
  • Delete the powered-off final customized VM using the inventory action that permanently removes its datastore files.
  • Delete the RHEL9-GOSC-Ready template using the inventory action that permanently removes its datastore files.
  • Open Policies and Profiles in vSphere Client.
  • Select VM Customization Specifications.
  • Select RHEL9-LinuxPrep-Static.
  • Remove the selected specification using the page's delete control.
  • Confirm that RHEL9-LinuxPrep-Static no longer appears in the specifications list.
  • Return to the vSphere Client inventory to confirm that the baseline VM, prepared source VM, final customized VM, and RHEL9-GOSC-Ready template no longer appear.

Nice Work!

Nice Work!

You did it! You built a repeatable RHEL 9 provisioning workflow in VMware vSphere. You can now demonstrate how virtual network placement works with guest operating system customization.

You've learned how to:

  • Prepare a reusable customization-ready template with Open VM Tools, Perl, NetworkManager, nmtui, and D-Bus tooling for Linux guest customization.
  • Create a reusable LinuxPrep specification called RHEL9-LinuxPrep-Static. It collects a unique hostname plus approved static IPv4 settings during each deployment.
  • Deploy a customized VM to an approved VLAN port group. You verified its hostname, active network connection, default route, and DNS configuration. You also traced guest customization through vSphere tasks plus /var/log/vmware-imc/toolsDeployPkg.log.
  • Complete the optional Secret Mission by moving the working VM to the alternate VLAN. You restored connectivity by updating its NetworkManager profile with the alternate static IPv4 configuration.

Ready to quiz yourself?