Every Proxmox tutorial about installing a Linux VM seems to cover Ubuntu, and a good chunk cover Debian too. Fedora barely gets a mention, which is odd, because it's one of the most widely used distributions on the planet and a genuinely good fit for a Proxmox VM. If you've ever wanted to run Fedora Server in a VM — to test something before it lands in RHEL, to match a Fedora Workstation setup you already use, or just because you like staying close to upstream — this walks you through the whole thing on Proxmox VE 9.2.
We'll use Fedora Server 44, the current release as of this writing, and go from downloading the ISO all the way to a fully updated VM with the QEMU guest agent running and Cockpit reachable in a browser. If you've never touched Fedora before, don't worry — the installer looks different from Ubuntu's, and we'll explain each screen as we go.
What You Will Learn
- How to get the right Fedora Server ISO and get it into Proxmox
- How to configure a VM in the Create VM wizard specifically for a Fedora guest
- How to get through Fedora's Anaconda installer, which works differently from Ubuntu's Subiquity installer
- Why Fedora ships with SELinux and firewalld active out of the box, and what that means for you
- How to install the QEMU guest agent and enable Cockpit, Fedora Server's built-in web admin console
- What actually goes wrong during this process, and how to fix it
What Is This Feature?
Fedora Server is the server-focused edition of Fedora Linux, sponsored by Red Hat and built by the Fedora Project community. It uses the same package manager, dnf, and the same security tooling as Red Hat Enterprise Linux and CentOS Stream, because Fedora is where a lot of that technology gets tested first. If a feature is going to show up in RHEL two years from now, there's a decent chance it showed up in Fedora first.
Unlike Ubuntu or Debian, which follow long-term-support cycles measured in years, Fedora releases a new major version roughly every 13 months, and each release only gets security updates for about 13 months after that. That's a real tradeoff: you get newer kernels, newer systemd, newer everything — but you also need to actually keep up with upgrades, or you fall out of support fast.
Why Would You Use It?
A few reasons people reach for Fedora specifically instead of Ubuntu or Debian:
- You're testing software against what RHEL or CentOS Stream will eventually ship, and you want a close preview.
- You already run Fedora Workstation on your desktop and like having the same package manager and defaults in your VMs.
- You want practice with SELinux in enforcing mode, because production RHEL systems run that way and Ubuntu's AppArmor won't teach you the same skills.
- You want Cockpit, Fedora Server's web-based admin panel, without installing anything extra.
Honestly, if you just want a VM that stays quiet and never demands attention, Debian is the easier choice — its release cycle is slower and its defaults are more forgiving. Fedora is for when you want to be closer to the edge on purpose.
Prerequisites
- Proxmox VE 8.x or 9.x installed and reachable through the web UI (this guide uses 9.2)
- Admin access to the Proxmox web interface, or SSH/shell access to the host
- At least 20 GB of free space on the storage you'll use for the VM disk
- At least 2 vCPU cores and 4 GB of RAM free for the VM — Fedora Server's minimum is technically lower, but 4 GB makes updates and Cockpit far more comfortable
- A network bridge already configured on the host (
vmbr0in most default setups) - The Fedora Server ISO, either downloaded to your own machine or ready to fetch directly on the Proxmox host
Step-by-Step Tutorial
Step 1: Download the Fedora Server ISO
Head to fedoraproject.org/server/download and grab the x86_64 DVD ISO for the current release (Fedora Server 44 at the time of writing, roughly 2.1 GB). There's also a smaller network-install ISO if your Proxmox host has a fast internet connection and you'd rather pull packages during setup instead of from the DVD image. For a first VM, stick with the full DVD ISO — it's more forgiving if your network drops mid-install.
Step 2: Upload the ISO to Proxmox
In the Proxmox web UI, click your storage that supports ISO images (usually local) in the left-hand tree, open the ISO Images tab, and click Upload. Pick the file you downloaded and wait for it to finish — a 2 GB file takes a few minutes on most home connections. If your Proxmox host has internet access itself, you can skip the upload entirely and use Download from URL with the direct ISO link from the Fedora download page instead, which is faster since the file never touches your local machine.
Step 3: Start the Create VM Wizard
Click Create VM in the top-right corner. On the General tab, give it a VM ID (Proxmox suggests the next free one automatically) and a name like fedora-server. Leave Start at boot unchecked for now — you can turn that on later once the VM is actually working.
Step 4: OS Tab
Select Use CD/DVD disc image file (iso), choose the storage where you uploaded the ISO, and pick the Fedora Server ISO from the dropdown. Under Guest OS, set Type to Linux and Version to 6.x - 2.6 Kernel. That version label is a catch-all for any recent Linux kernel — Proxmox doesn't need to know it's Fedora specifically, just that it's a modern Linux guest.
Step 5: System Tab
This is where Fedora VMs benefit from a couple of non-default settings. Set Machine to q35 instead of the older i440fx — q35 emulates a newer chipset with PCIe support, and Fedora's kernel handles it without any extra fuss. Set BIOS to OVMF (UEFI), which adds an EFI disk automatically when you save. UEFI boot is the modern standard and Fedora's installer expects it by default on new installs. While you're on this tab, check the Qemu Agent box — this tells Proxmox to expect the guest agent, which we'll install inside the VM in a later step.
Step 6: Disks Tab
Set the bus to VirtIO SCSI single and give it at least 32 GB — Fedora Server itself only needs a few gigabytes, but you'll want headroom for updates, logs, and whatever you actually install. Turn on Discard if your underlying storage is SSD-backed and supports TRIM; it lets the VM tell Proxmox when blocks are freed, which keeps thin-provisioned storage from bloating over time.
Step 7: CPU Tab
Set Cores to 2. For Type, choose host if this VM will only ever run on this one Proxmox node — it passes through your actual CPU's feature set for the best performance. If you might live-migrate it to a different node later, use a more generic type like x86-64-v2-AES instead, so the VM doesn't rely on CPU features the destination node might lack.
Step 8: Memory Tab
4096 MB is a comfortable starting point. Leave Ballooning Device enabled if you want Proxmox to be able to reclaim idle memory from this VM under host pressure — for a single test VM it rarely matters, but there's no real reason to turn it off.
Step 9: Network Tab
Bridge should already default to vmbr0, which is fine for most setups. Leave the model as VirtIO (paravirtualized) — Fedora's kernel has the VirtIO network driver built in already, so there's no separate driver to install like there is on Windows.
Step 10: Confirm and Start
Review the summary screen, click Finish, select the new VM in the left panel, and click Start. Open the console (the >_ Console button) to watch it boot into the installer.
Step 11: Walk Through Anaconda, Fedora's Installer
Fedora uses an installer called Anaconda, and it works a bit differently from Ubuntu's Subiquity. Instead of stepping through screens in a fixed order, Anaconda gives you a single Installation Summary hub with several sections, and you visit each one before you're allowed to start the install:
- Installation Destination — select your virtual disk and choose Automatic partitioning unless you have a specific layout in mind. You have to open this screen and click Done even if you're keeping the defaults, or Anaconda won't let you proceed.
- Network & Host Name — the network device should already show as connected via DHCP. Set your hostname here now, since changing it after install means editing
/etc/hostnameby hand later. - Root Password and User Creation — unlike Ubuntu, Fedora lets you set a root password directly and separately create a regular user. Create at least one regular user and check Make this user administrator so it gets sudo access.
Once every section shows a summary instead of a warning icon, click Begin Installation. It usually takes five to eight minutes inside a VM, depending on your storage speed.
Step 12: Reboot and Remove the ISO
When installation finishes, click Reboot System. Before it boots back into the installer by mistake, go to the VM's Hardware tab in Proxmox, double-click the CD/DVD drive, and set it to Do not use any media. This is the step people forget most often, and it's why VMs sometimes boot straight back into the Fedora installer after what looked like a successful install.
Step 13: Log In and Update
Log in at the console with the regular user you created, then run:
sudo dnf update -yOn a fresh install this usually pulls somewhere between 100 and 400 MB of updates. Reboot afterward with sudo reboot if it updated the kernel, which it usually does.
Step 14: Install the QEMU Guest Agent
The guest agent lets Proxmox get an accurate IP address, do clean shutdowns instead of hard power-offs, and take consistent snapshots. Install and enable it with:
sudo dnf install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agentBack in the Proxmox Summary tab for this VM, you should now see a real IP address under the IPs section within a few seconds, instead of a blank field.
Step 15: Enable Cockpit (Optional but Worth It)
Fedora Server ships with Cockpit already installed — it's a web-based dashboard for managing the machine without SSH. It's just not turned on by default. Enable it with:
sudo systemctl enable --now cockpit.socketThen open https://<your-vm-ip>:9090 in a browser and log in with the same user account. You'll see live CPU and memory graphs, systemd service management, log viewing, and a terminal, all without leaving the browser. It's genuinely useful for a headless VM you don't want to SSH into for every small check.
Commands Explained
| Command | What It Does |
|---|---|
sudo dnf update -y | Updates all installed packages to their latest versions without prompting for confirmation on each one. |
sudo dnf install -y qemu-guest-agent | Installs the QEMU guest agent package from Fedora's repositories. |
sudo systemctl enable --now <service> | Enables a systemd service to start on boot and starts it immediately in the same command. |
sudo firewall-cmd --list-all | Shows the active firewalld zone and which ports or services are currently allowed through. |
sestatus | Reports whether SELinux is enabled, and whether it's in enforcing or permissive mode. |
hostnamectl | Shows or sets the system's hostname and related identity information. |
nmcli device status | Lists network interfaces and their connection state, useful when a static IP isn't applying the way you expect. |
Common Errors
"No bootable device found" after install. This almost always means the ISO is still mounted as the boot device. Go back to the VM's Hardware tab, edit the CD/DVD drive, and set it to no media, then check the boot order under Options to make sure the virtual disk is listed first.
Anaconda won't let you click "Begin Installation." One of the hub sections still has a warning icon, most commonly Installation Destination. Open it, confirm the disk selection, and click Done — the warning clears and the button becomes active.
Cockpit loads a blank page or times out on port 9090. Either the socket isn't enabled yet (systemctl status cockpit.socket will tell you), or firewalld is blocking it. Cockpit actually opens its own port through firewalld automatically when enabled via cockpit.socket, so if it's still blocked, check sudo firewall-cmd --list-all for a stray rule.
"Permission denied" on a file that should be readable. This is frequently SELinux, not standard Unix permissions. If you moved or created a file in an unusual way (copied it with scp into a service directory, for example), it may have the wrong SELinux context even though the file permissions look correct.
Troubleshooting
If a service won't start and the error in journalctl -xe looks like a permissions problem but the file permissions themselves look fine, check sudo ausearch -m avc -ts recent for SELinux denials. Don't reach for setenforce 0 to make the problem disappear — that turns off SELinux enforcement system-wide, and you'll just hit the same denial again the moment you turn it back on. Instead, run restorecon -Rv /path/to/directory to reset the file's context to what the policy expects, which fixes the vast majority of these cases in one shot.
If the VM's IP address isn't showing up in the Proxmox Summary tab even after installing the guest agent, double-check that you actually checked the Qemu Agent box back on the System tab during VM creation. If you skipped it, edit the VM's Options tab, enable it there, and reboot the VM — Proxmox won't query an agent it doesn't think exists.
If dnf update hangs or times out completely, it's usually a networking issue rather than a Fedora problem — check that the VM actually got a DHCP lease with ip a, and that your Proxmox bridge has a working path to the internet.
Best Practices
- Take a snapshot before running
sudo dnf system-upgradeto move to a new Fedora release — cross-release upgrades are usually smooth, but a snapshot means a bad one costs you nothing. - Stick with q35 and UEFI for new Fedora VMs rather than the older i440fx/SeaBIOS combination; it matches what Fedora expects and avoids odd edge cases with newer kernels.
- Don't disable SELinux to make a problem go away. Use
restoreconor, for a genuinely new policy exception,audit2allowto build a targeted rule. - Mark your calendar for Fedora's roughly 13-month support window per release. Running
dnf updateforever without ever runningdnf system-upgradewill eventually leave you on an unsupported version with no security patches. - If Cockpit is enabled, treat its login the same as SSH access — same password hygiene, and consider it another reason to keep the VM behind your LAN rather than exposed to the internet.
Frequently Asked Questions
Do I need to install VirtIO drivers separately, like on Windows?
No. Fedora's kernel already includes VirtIO drivers for disk, network, and memory ballooning. There's nothing extra to download or install.
Should I use the Fedora Server ISO or the Fedora Workstation ISO?
Use Server for a VM you'll manage headless over SSH or Cockpit. Workstation installs a full GNOME desktop and wants considerably more RAM and disk just to feel responsive — overkill unless you specifically need a graphical desktop inside the VM.
Is SELinux going to constantly get in my way?
Less than its reputation suggests. Standard package installs and typical service configuration work fine out of the box. It mostly surfaces when you move files around in nonstandard ways or bind a service to an unusual port — both fixable without turning SELinux off.
How long will this Fedora release actually be supported?
Roughly 13 months from release, and Fedora typically keeps two releases maintained at once. Plan on upgrading with dnf system-upgrade at least once a year to stay inside the support window.
Can I turn this VM into a template afterward?
Yes, the same way you would with any other Linux VM — shut it down, right-click it in the Proxmox tree, and choose Convert to Template. Just be aware Fedora doesn't ship a first-boot customization tool as commonly used as cloud-init on a standard ISO install, so cloning it repeatedly will carry over the original hostname and SSH host keys unless you reset them manually or build the template from a cloud image instead.
Conclusion
Fedora Server isn't a hard VM to run on Proxmox — the wizard settings are nearly identical to any other modern Linux guest, and the only real differences show up in the installer itself and in a couple of Fedora-specific tools like SELinux and Cockpit. If you've been sticking to Ubuntu or Debian purely out of habit, it's worth spinning up a Fedora VM at least once, if only to get comfortable with a slightly different set of defaults before you meet them on a production RHEL box somewhere down the line.