Introduction
If you've spent any time on r/homelab or a Proxmox forum, you've probably seen someone recommend Rocky Linux as their go-to server OS. It's not as flashy as Ubuntu, and it doesn't get the constant blog coverage that Debian does, but it's quietly become one of the most common guest operating systems running on Proxmox hosts. There's a reason for that: Rocky Linux is a free, community-driven rebuild of Red Hat Enterprise Linux, and a lot of people want RHEL's stability and long support window without paying for a Red Hat subscription.
Creating a Rocky Linux VM in Proxmox VE isn't difficult, but it has a few quirks that don't show up when you're installing Ubuntu or Debian. The installer looks different, the default firewall behaves differently, and the package manager isn't apt. None of that is a problem once you know what to expect, and that's what this guide walks through: getting a clean Rocky Linux VM running on Proxmox VE, from downloading the ISO to having a fully updated, guest-agent-aware virtual machine you can actually use.
What You Will Learn
- What Rocky Linux is and why it's popular for servers and homelabs
- How to download the right ISO and get it onto your Proxmox host
- How to configure a new VM in the Proxmox creation wizard with sensible settings
- How to get through the Rocky Linux (Anaconda) installer without surprises
- How to install and enable the QEMU Guest Agent so Proxmox can talk to the VM properly
- Common errors people hit on this specific combination, and how to fix them
What Is This Feature?
A virtual machine in Proxmox VE is a complete, isolated computer that runs on top of your physical server. It has its own virtual CPU, RAM, disk, and network card, and as far as the operating system inside it is concerned, it's running on real hardware. Proxmox uses KVM, a virtualization technology built into the Linux kernel, to make that illusion convincing enough that you can install almost any x86-64 operating system inside it, including Rocky Linux.
Rocky Linux itself is a downstream rebuild of Red Hat Enterprise Linux (RHEL). When Red Hat changed how it distributes RHEL's source code a few years back, a group of former CentOS developers created Rocky Linux specifically to keep a free, binary-compatible alternative alive. It uses dnf as its package manager instead of Debian's apt, ships with SELinux enabled by default for extra access control, and follows RHEL's release cycle closely, which means long support windows and infrequent, predictable changes. That combination is exactly why it ends up running on so many home servers and small business boxes.
Why Would You Use It?
The honest answer is stability. Rocky Linux doesn't chase the newest kernel or the newest package versions the way Ubuntu's interim releases do. Once a major version ships, it stays on a consistent set of package versions for years, only getting security patches and bug fixes. If you're running something like Nextcloud, a Kubernetes node, or a database server that you don't want to babysit every six months, that predictability matters more than having the latest software.
It's also the natural landing spot for anyone coming from CentOS, which stopped receiving full updates in 2021. If you learned Linux administration on CentOS or RHEL at work, Rocky Linux feels immediately familiar — same commands, same file layout, same tools like firewalld and SELinux that you already know how to work with.
None of that means Rocky Linux is the right choice for everything. If you want the newest kernel for hardware support, or you're following tutorials that assume Ubuntu, you'll have an easier time elsewhere. Rocky earns its spot on servers you want to set up once and mostly leave alone.
Rocky Linux vs Ubuntu Server: Quick Comparison
| Rocky Linux | Ubuntu Server |
|---|---|
| Package manager: dnf/yum | Package manager: apt |
| RHEL-compatible, long stable release cycle | Faster-moving, newer packages sooner |
| SELinux enabled by default | AppArmor enabled by default |
| Best for: production-style servers, RHEL shops, long uptime | Best for: general homelab use, widest tutorial coverage |
Prerequisites
- A working Proxmox VE 8.x or 9.x host with at least 20GB of free storage and 2GB of RAM to spare for the new VM
- A downloaded Rocky Linux ISO (this guide uses the x86_64 Minimal ISO, roughly 1.5GB — the DVD ISO works too, it's just an 8GB download you don't need for a server install)
- Access to the Proxmox web interface, and either console access or SSH to the host to upload the ISO
- Basic comfort with a Linux terminal — you'll spend some time in the VM's console during and after install
One decision worth making before you start: which ISO to grab. Rocky Linux publishes a Minimal ISO, a DVD ISO, and a Boot ISO. The DVD ISO bundles every package group and lets you install fully offline, at the cost of an 8GB download. The Minimal ISO strips that down to a small base system and is what most people actually want for a server VM — you'll add whatever packages you need afterward with dnf. The Boot ISO is smaller still but needs a live internet connection during install to pull packages, which adds a point of failure you don't need. For this guide, grab the Minimal ISO from rockylinux.org/download.
Step-by-Step Tutorial
Step 1: Upload the ISO to Proxmox
In the Proxmox web UI, click your storage (usually local) in the left-hand tree, then open the ISO Images tab. Click Upload and select the Rocky Linux ISO you downloaded. On a typical home connection this takes a few minutes for the Minimal ISO. If your Proxmox host has internet access itself, you can skip the local upload entirely and use Download from URL instead, pasting in the direct link from the Rocky Linux download page — that's usually faster since the file goes straight from Rocky's mirrors to your host instead of through your browser.
Step 2: Start the Create VM Wizard
Click Create VM in the top-right corner of the Proxmox UI. You'll go through several tabs:
- General: Give the VM a Name (something like
rocky-server) and let Proxmox assign the next available VM ID. - OS: Select the storage where you uploaded the ISO, then pick the Rocky Linux ISO from the list. Set Type to Linux and Version to the closest match — Rocky Linux 9 maps to "6.x - 2.6 Kernel" or newer depending on your Proxmox version; picking any recent Linux kernel option here is fine, since it only tunes minor defaults.
- System: Leave Machine as
q35and BIOS as SeaBIOS unless you specifically need UEFI (some newer ISOs prefer OVMF — either works for Rocky). Check the box for Qemu Agent now, even though you haven't installed the agent inside the VM yet; this just tells Proxmox to expect it. - Disks: Set the disk size to at least 20GB for a general-purpose server. Use the VirtIO SCSI single controller with a SCSI disk — VirtIO is a set of paravirtualized drivers that let the guest talk to virtual hardware far more efficiently than emulating a real disk controller, and it's the default Proxmox expects. Tick Discard if your underlying storage is an SSD or supports thin provisioning, so deleted files inside the VM can actually free up space on the host.
- CPU: 2 cores is plenty to start. Set Type to
hostif all your VMs run on this same physical machine, since it exposes the full instruction set of your actual CPU to the guest for better performance. - Memory: 2048MB minimum, 4096MB if you plan to run anything heavier than a basic web or file server.
- Network: Leave the bridge as
vmbr0(or whichever bridge connects to your LAN) and set Model to VirtIO (paravirtualized) rather than the emulated Intel E1000 — it's noticeably faster and Rocky Linux's kernel supports it out of the box. - Confirm: Review the summary and click Finish. Don't check "Start after created" just yet if you want to double-check anything first — otherwise it's fine to let it boot straight away.
Step 3: Run the Rocky Linux Installer
Select the new VM, click Start, then open its Console tab. Rocky Linux boots into Anaconda, the same graphical installer RHEL and Fedora use. From the boot menu, choose Install Rocky Linux and give it a moment to load the installer environment.
Anaconda's main screen lists several sections you need to visit before the Begin Installation button becomes clickable:
- Installation Destination: select your virtual disk, leave "Automatic" partitioning selected unless you have a specific layout in mind, and click Done.
- Software Selection: pick a base environment. For most VMs, Minimal Install is the right call — it keeps the footprint small and you add packages later as you need them. If you want a desktop environment for testing, "Server with GUI" works too, but that's rare for a Proxmox guest.
- Network & Hostname: turn the network interface on (it's off by default in the installer) and set a hostname here if you want one baked in from the start.
- Root Password / User Creation: set a root password, and it's worth creating a regular user account here too, with the "Make this user administrator" box checked if you want sudo access without extra setup afterward.
Click Begin Installation. It typically takes five to ten minutes for a Minimal install on a VM with a couple of vCPUs. When it finishes, click Reboot System.
Step 4: Remove the ISO and Boot Into Rocky Linux
Before the VM restarts (or right after, if it already has), go to the VM's Hardware tab, select the CD/DVD Drive, click Edit, and set it to Do not use any media. If you skip this, the VM may try to boot the installer ISO again on reboot instead of the disk you just installed to.
Log in with the root account or the regular user you created. From here you're in a normal Rocky Linux shell, ready for the last bit of setup.
Step 5: Install the QEMU Guest Agent
The guest agent is a small service that runs inside the VM and lets Proxmox do things it otherwise can't — report the VM's actual IP address in the Proxmox UI, shut down cleanly instead of a hard power-off, and take consistent snapshots. Install it with:
dnf install -y qemu-guest-agent
systemctl enable --now qemu-guest-agent
You already checked the Qemu Agent box back in Step 2, so Proxmox is expecting it — this just makes it actually run. Go to the VM's Summary tab in Proxmox afterward, and within a minute or two you should see its IP address show up.
Step 6: Update the System
Finish with a full update, since the ISO's packages are frozen at release time and there are almost always patches waiting:
dnf update -y
Reboot if the kernel got updated (dnf will tell you), and you've got a current, working Rocky Linux VM.
Commands Explained
dnf install -y qemu-guest-agent— installs the guest agent package;-yjust skips the confirmation prompt.systemctl enable --now qemu-guest-agent— enables the service so it starts on every boot, and--nowalso starts it immediately without waiting for a reboot.dnf update -y— pulls and installs every available package update, including security patches, from Rocky's repositories.sestatus— a diagnostic command (not required, but useful) that shows whether SELinux is enforcing, permissive, or disabled, along with the current policy.
Common Errors
- The VM boots straight back into the installer after finishing setup. This means the CD/DVD drive is still set to the ISO. Go to Hardware, edit the CD/DVD Drive, and set it to "Do not use any media," then reset the VM.
- No IP address shows up on the Summary tab. Almost always means the guest agent isn't installed or isn't running yet. SSH in (if you can reach it another way) or check the console and run
systemctl status qemu-guest-agent— if it's not active, the enable command from Step 5 either didn't run or failed. - Shutting down from the Proxmox UI just power-cycles the VM instead of shutting down cleanly. Same root cause as above — without the guest agent running, Proxmox can't send a proper shutdown signal, so "Shutdown" from the UI falls back to a hard stop after a timeout.
- dnf update fails with a mirror or repository error right after install. Check that the VM's network is actually up with
ip a— the Anaconda installer sometimes leaves the interface disabled if you didn't explicitly toggle it on during the Network & Hostname screen. - A service you just installed can't bind to its port, or SELinux denies something in the logs. SELinux is doing exactly what it's designed to do — blocking anything that doesn't match its policy, even legitimate services running on non-standard ports or paths. Check
journalctl -xefor "avc: denied" entries and usesemanage portorrestoreconto fix the context, rather than disabling SELinux outright.
Troubleshooting
If the VM won't boot at all after install, the first thing to check is the boot order and disk controller. Open the VM's Hardware tab and confirm the SCSI or VirtIO disk you created during install is still attached and set as the boot device — this is more of an issue if you changed disk settings mid-setup than on a first attempt.
For networking problems, start on the Proxmox side before touching the VM. Confirm the bridge (vmbr0 or whatever you chose) is actually up on the host with ip a, and that the VM's network device in its Hardware tab is attached to that same bridge. Once you've confirmed that, move inside the VM and check nmcli device status to see whether the interface has an IP at all.
If SELinux is the suspected culprit for something not working, don't jump straight to setenforce 0 to disable it — that's diagnostic, not a fix, and leaving it off long-term removes a real layer of protection. Use it temporarily to confirm SELinux is the cause, then put it back to enforcing with setenforce 1 and fix the actual policy or context issue.
Best Practices
Take a snapshot right after the initial setup and update are done, before you install anything else. That gives you a clean rollback point if a later change breaks something, and it costs almost nothing in storage since nothing has diverged yet.
If you expect to spin up more than one Rocky Linux VM, convert this one into a template once it's fully patched and configured with the guest agent (right-click the VM, choose Convert to template). Cloning a template is much faster than repeating the ISO install every time, and it guarantees every clone starts from the same known-good state.
Leave SELinux enforcing unless you have a specific, well-understood reason to change it. It's one of the actual advantages of choosing Rocky Linux over a distribution that doesn't have it enabled by default, and most "SELinux is blocking my app" problems have a real fix that doesn't involve turning it off.
Keep the Minimal install habit going after the OS is up, too. Install only the packages you actually need for whatever the VM is going to do — a smaller footprint means fewer things to patch and fewer places for something to go wrong.
Frequently Asked Questions
Should I use Rocky Linux or AlmaLinux?
Both are free RHEL rebuilds and functionally very close. Rocky Linux has a larger community and slightly wider adoption in homelabs; AlmaLinux has strong backing from CloudLinux. Either is a reasonable choice — pick one and don't overthink it.
Do I need the DVD ISO instead of the Minimal ISO?
Only if you want to install without any internet access at all, or you're installing a desktop environment during setup. For a typical server VM, the Minimal ISO plus dnf install afterward is smaller and just as capable.
Why does the installer look different from Ubuntu's?
Rocky Linux uses Anaconda, the RHEL/Fedora installer, while Ubuntu uses its own installer (Subiquity on the server ISO). They cover the same ground — disk, network, users — just with a different layout and workflow.
Can I use cloud-init instead of the ISO installer?
Yes — Rocky Linux publishes a cloud-init-ready image you can use to build a Proxmox VM template without going through Anaconda at all. That's a faster path if you're deploying several VMs, but it's a different workflow from the manual install covered in this guide.
Does Rocky Linux cost anything to run in Proxmox?
No. Rocky Linux itself is free and open source with no subscription requirement. You'd only pay if you separately bought commercial support from a third party, which most homelab and small business users never need.
Conclusion
Once you've done it once, spinning up a Rocky Linux VM in Proxmox becomes routine — the Anaconda installer and dnf take a little getting used to if you're coming from Ubuntu or Debian, but nothing about it is harder, just different. The guest agent step trips up more people than the install itself, so if a VM ever seems unresponsive to shutdown commands or won't show its IP, that's the first place to look.
From here, a template is the natural next step if you're planning more than one Rocky Linux VM — clone it, boot it, and skip the installer entirely on every VM after this first one.