Building a Rocky Linux 9.8 Template VM by Hand

Most of my lab runs on Ubuntu VMs built and updated through Packer, but a recent project called for a Rocky Linux template. Since this isn’t something I expect to repeat often, I didn’t want to invest time building out a Packer pipeline for it – I built the template manually in vSphere instead. Here’s the process I used, documented for the next time I (or you) need it.

Creating the VM

Start with a new VM in vSphere using these settings:

• Name: template-rocky98-minimal
• Compatibility: ESXi 8.0 U2 and later (vmx-21)
• Guest OS Family: Linux
• Guest OS Version: Rocky Linux (64-bit)

When customizing the hardware, the only change I made was bumping the hard disk from the default 16GB to 20GB. Everything else was left at its default.

Power on the VM and attach the Rocky-9.8-x86_64-minimal.iso installer image.

Installing Rocky Linux

From the boot menu, select Install Rocky Linux Minimal 9.8.

In the installer:

1. Confirm the automatic installation destination — it should default to the 20GB disk created earlier.
2. Create a user account:
   • Username: template-admin
   • Grant this user administrator privileges.
   • Require a password to use the account: VMware1!
   • Leave the root account disabled.
3. Begin the installation.

Post-Install Configuration

Once the install finishes and you’ve rebooted into the new system, run the following as root:

sudo -i

dnf update -y
dnf install open-vm-tools cloud-init -y

systemctl enable --now vmtoolsd

echo "ssh_pwauth: unchanged" | tee /etc/cloud/cloud.cfg.d/99-ssh-pwauth.cfg
rm -f /etc/ssh/ssh_host_*

shutdown -h now

A quick rundown of what this does:

• Updates the system and installs open-vm-tools and cloud-init (so future clones can be provisioned with customization specifications).
• Enables and starts the vmtoolsd service.
• Drops a cloud-init override so it doesn’t touch the SSH password-authentication setting on first boot of a cloned VM.
• Removes the host’s SSH host keys, so each VM cloned from this template generates its own unique keys on first boot instead of sharing the template’s.
• Shuts the VM down cleanly, ready for conversion.

Finalizing the Template

Before converting, add a VM note for future reference — something like:

2026-09-19: Created template

Then convert the VM to a template.

Updating the Template Later

If you ever need to make changes inside the guest OS, such as patching, adding packages, etc., you’ll need to convert the template back to a VM first. Before converting it back to a template again, repeat the cleanup steps so the next clone doesn’t inherit stale SSH configuration or host keys:

sudo -i

rm -f /etc/ssh/sshd_config.d/50-cloud-init.conf
rm -f /etc/ssh/ssh_host_*

shutdown -h now

Once it’s powered off, convert it back to a template.

Conclusion

That’s it! A simple, repeatable manual process for a template I don’t need to fully automate. If this becomes a more frequent need, it’d be a good candidate to eventually fold into the same Packer-based workflow I use for Ubuntu.