Introduction
Open almost any "how to create a VM in Proxmox" guide and you'll find Ubuntu, Debian, or maybe Windows. Arch Linux rarely gets a mention, which is a shame, because it runs great under Proxmox VE and a lot of homelab users end up wanting it sooner or later — usually after they've outgrown Ubuntu and want to actually understand what's running on their system instead of trusting an installer to do it for them.
Arch doesn't hold your hand. There's no graphical installer wizard, no "next, next, finish." You boot into a bare command line and build the system piece by piece: partition the disk, mount it, install the base packages, configure the bootloader. That sounds intimidating if you've never done it, but it's really just a sequence of maybe fifteen commands, and once you've done it once you'll understand Linux boot and package management a lot better than you did before.
This guide walks through the whole thing on Proxmox VE — from creating the VM with the right settings to getting a working, network-connected Arch install with the QEMU Guest Agent running, so Proxmox actually knows the VM's IP address and can shut it down cleanly instead of just cutting the power.
What You Will Learn
- What makes Arch Linux different from Ubuntu, Debian, or Fedora, and why some people prefer it
- How to configure a Proxmox VE virtual machine correctly for a UEFI-based Arch install
- How to partition, format, and mount a disk from the Arch live environment
- How to install the base system with
pacstrapand set up a working bootloader - How to install the QEMU Guest Agent so Proxmox can see the VM's IP and manage shutdowns properly
- The errors people actually run into with this specific combination, and how to get past them
What Is This Feature?
A virtual machine in Proxmox VE is a fully self-contained computer running inside your physical server. Proxmox uses KVM (Kernel-based Virtual Machine), a virtualization technology built directly into the Linux kernel, to give each VM its own virtual CPU, memory, disk, and network card. The guest operating system — in this case, Arch — has no idea it isn't running on real hardware.
Arch Linux itself is a independent, rolling-release Linux distribution. "Rolling release" means there are no version numbers like Ubuntu 24.04 or Debian 13 — you install it once, and from then on you just keep updating packages, forever, always landing on the latest stable versions. There's no big jump between major releases because there aren't any. Arch's package manager is pacman, and its base install is deliberately minimal: no desktop environment, no preinstalled utilities you didn't ask for. You add exactly what you want, nothing else.
Inside Proxmox, an Arch VM behaves like any other guest. It boots from an ISO you upload, gets virtual disks and a virtual NIC, and once installed it supports snapshots, backups, and the QEMU Guest Agent the same as an Ubuntu or Windows VM would.
Why Would You Use It?
Nobody ends up on Arch by accident — you generally arrive here on purpose, for one of a few reasons. Some people want the newest kernel and package versions available anywhere, since Arch tracks upstream releases closely instead of freezing package versions for years like Debian does. Some want the Arch Wiki, which is widely considered one of the best pieces of Linux documentation in existence, and useful even if you're running a completely different distro. And a lot of people just want to understand exactly what's installed on their system, because they built it themselves, one package at a time.
There's a practical homelab angle too. A minimal Arch VM makes a genuinely lightweight base for a single service — a small web app, a build server, a personal project — where you don't want Ubuntu's snap packages or Debian's older library versions getting in the way. And if you're already comfortable with LXC containers on Proxmox, running Arch as a full VM instead gives you a proper isolated kernel, which matters if the software you're running needs kernel modules a container can't provide.
Honestly, if you just want something that works with zero fuss, Ubuntu Server is still the easier choice. Arch is for when you want to learn, or when you specifically want a minimal, current, DIY system and don't mind the extra half hour it takes to set one up.
Prerequisites
Before you start, make sure you have the following ready:
- A working Proxmox VE 8.x or 9.x install with access to the web interface
- At least 20 GB of free storage for the VM's virtual disk, and around 2 GB of RAM to spare
- The latest Arch Linux ISO downloaded from archlinux.org — it's updated monthly, so grab a current one rather than reusing something old
- Basic comfort typing commands. You don't need to be a Linux expert, but this isn't a point-and-click install
- A stable network connection for the VM, since
pacstrapdownloads packages during install and won't work offline
Step-by-Step Tutorial
1. Upload the Arch ISO to Proxmox
In the Proxmox web interface, click your storage (usually local) in the left-hand tree, open the ISO Images tab, and click Upload. Select the Arch ISO you downloaded. Depending on your connection, uploading the roughly 1 GB file takes a couple of minutes.
2. Create the virtual machine
Click Create VM in the top right. On the General tab, give it a VMID and a name like arch-test. On the OS tab, select the ISO you just uploaded, and set Guest OS type to Linux, version 6.x - 2.6 Kernel (this covers any modern kernel, including Arch's).
3. Set the System tab correctly
This is the step people skip and regret later. Set Machine to q35 — it's a newer, more capable virtual chipset than the older i440fx default and handles PCIe passthrough better if you ever need it. Set BIOS to OVMF (UEFI). Arch's ISO boots in UEFI mode by default when the VM is configured for it, and it makes the bootloader step later far more predictable.
Once you switch to OVMF, Proxmox will ask you to add an EFI Disk — accept it, and put it on the same storage as your VM disk. Also check Qemu Agent on this tab; it doesn't do anything until you install the agent inside the VM later, but it saves you a step.
4. Configure the disk
On the Disks tab, set the bus to VirtIO Block or SCSI with the VirtIO SCSI single controller — both are paravirtualized drivers built for speed inside a VM, and Arch's kernel supports them out of the box, so there's no separate driver hunt like you'd get with Windows. 20 GB is plenty for a minimal install; bump it up if you're planning to install a desktop environment or a lot of software later. If your Proxmox storage is on SSD or NVMe, tick Discard so unused blocks get reclaimed properly.
5. Set CPU, memory, and network
On CPU, 2 cores is fine to start. Set the CPU type to host if you're not planning to migrate this VM to a different physical CPU later — it passes through your actual processor's features instead of a generic emulated one, which is faster. For Memory, 2048 MB is a comfortable minimum for a base install; you can lower it after setup if you want a truly minimal footprint. On Network, leave the model at VirtIO (paravirtualized) and the bridge at vmbr0 unless you've set up something custom.
Review the summary and click Finish. Don't start the VM automatically from this screen — start it from the VM list so you can open the console right away.
6. Boot the installer and check your network
Select the new VM, click Start, then Console. You'll land in a root shell inside the Arch live environment within a few seconds — no menus, no options screen, just a prompt. That's normal.
Check that networking came up automatically:
ping -c 3 archlinux.orgThe live ISO runs systemd-networkd with DHCP enabled by default, so on a VirtIO NIC this almost always works without any extra configuration. If it doesn't reply, run ip link to confirm the interface name, then bring it up manually — but on Proxmox with the default vmbr0 bridge this step rarely gives anyone trouble.
7. Confirm UEFI boot mode
ls /sys/firmware/efi/efivarsIf that directory lists a bunch of files instead of throwing "No such file or directory," you're booted in UEFI mode, which is what you want given the OVMF setting from step 3. If it's empty, go back and double-check the System tab — you likely still have BIOS (SeaBIOS) selected.
8. Partition the disk
Arch doesn't partition anything for you. Use fdisk (or cfdisk if you prefer a menu-driven view):
fdisk /dev/sdaCreate two partitions: a 512 MB EFI System Partition first, and a second partition using the rest of the disk for your root filesystem. In fdisk, that's roughly: g (new GPT table), n twice to create the two partitions, t to set the first partition's type to EFI System (type code 1), and w to write the changes.
9. Format and mount the partitions
mkfs.fat -F32 /dev/sda1
mkfs.ext4 /dev/sda2
mount /dev/sda2 /mnt
mount --mkdir /dev/sda1 /mnt/bootmkfs.fat -F32 formats the EFI partition as FAT32, which is the format UEFI firmware requires for the boot partition. mkfs.ext4 formats the root partition with ext4, a solid, well-tested default filesystem for a beginner install. Mounting /mnt/boot afterward means your bootloader files land in the right spot once you're inside the new system.
10. Install the base system
pacstrap -K /mnt base linux linux-firmware vim networkmanagerThis is the actual install step. pacstrap installs a working Arch base system into /mnt — the -K flag initializes a fresh pacman keyring inside the new install rather than reusing the live ISO's. base is the minimal set of core packages, linux is the kernel package, and linux-firmware covers hardware firmware blobs (mostly irrelevant in a VM, but standard practice to include). We're throwing in vim so you have a text editor once you reboot, and networkmanager so networking survives past the live environment.
11. Generate the fstab and chroot in
genfstab -U /mnt >> /mnt/etc/fstab
arch-chroot /mntgenfstab -U writes out /etc/fstab, the file that tells Linux which partitions to mount at boot and where — using UUIDs instead of device names like /dev/sda2, since device naming can shift around. arch-chroot then switches you into the new system on /mnt as if you'd already booted into it, which is what lets you configure everything from here on out.
12. Set the timezone, locale, and hostname
ln -sf /usr/share/zoneinfo/Region/City /etc/localtime
hwclock --systohcReplace Region/City with something like America/New_York or Europe/Berlin. hwclock --systohc syncs the VM's hardware clock to that timezone.
Next, open /etc/locale.gen, uncomment en_US.UTF-8 UTF-8 (or your preferred locale), then run:
locale-gen
echo "LANG=en_US.UTF-8" > /etc/locale.confSet a hostname:
echo "arch-vm" > /etc/hostnameand add a matching line to /etc/hosts so the system resolves its own name locally.
13. Set the root password and install the bootloader
passwdSet a password you'll actually remember — this is your only way in once the system reboots. Then install GRUB:
pacman -S grub efibootmgr
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfgefibootmgr lets GRUB register itself as a UEFI boot entry. The grub-install command installs GRUB's files into the EFI partition you mounted at /boot, and grub-mkconfig scans the system and writes the actual boot menu configuration, including the kernel you just installed.
14. Enable networking and the guest agent, then reboot
systemctl enable NetworkManager
pacman -S qemu-guest-agent
systemctl enable qemu-guest-agent
exit
umount -R /mnt
rebootThe QEMU Guest Agent is a small service that runs inside the VM and talks back to the Proxmox host — it's how Proxmox shows you the VM's actual IP address in the summary tab, and how a "shutdown" click cleanly powers off the OS instead of yanking the virtual power cord. Enabling it now saves you a second boot cycle later.
After reboot, the console will hang for a second on ISO removal — that's expected, since Proxmox's virtual CD drive doesn't always eject in time. Just go to Hardware on the VM, remove the CD/DVD drive (or set boot order so the disk comes first), and start it again if it tries to boot the installer a second time.
Commands Explained
| Command | What it actually does |
|---|---|
fdisk /dev/sda | Interactive disk partitioning tool — creates the GPT partition table and the two partitions this install needs. |
mkfs.fat -F32 | Formats a partition as FAT32, the required format for a UEFI EFI System Partition. |
pacstrap -K | Installs the base Arch system and any listed packages into a target directory, with a freshly initialized pacman keyring. |
genfstab -U | Auto-generates /etc/fstab using partition UUIDs rather than device paths. |
arch-chroot | Enters the new install as if it were the running system, so you can configure it directly. |
grub-mkconfig | Scans installed kernels and generates the actual GRUB boot menu file. |
qemu-guest-agent | Background service reporting VM status (IP address, disk usage) to the Proxmox host and handling clean shutdown requests. |
Common Errors
"No such file or directory" on /sys/firmware/efi/efivars. This means the VM booted in legacy BIOS mode, not UEFI. Shut it down, go to the System tab, and confirm BIOS is set to OVMF (UEFI), not SeaBIOS. You'll need to redo the ISO boot after fixing this — a disk already partitioned for BIOS boot won't work correctly under UEFI.
"failed to synchronize all databases" during pacstrap. Almost always a networking problem inside the live environment. Run ping archlinux.org first — if that fails, check the VM's network device is VirtIO and the bridge is correct, and confirm the physical host actually has internet access.
GRUB installs fine but the VM won't boot afterward, dropping to a UEFI shell instead. This usually means the EFI System Partition didn't get formatted or mounted correctly before grub-install ran. Boot the ISO again, mount your partitions as in step 9, and rerun the grub-install and grub-mkconfig commands — you don't need to reinstall the whole base system.
Black screen after boot, no login prompt. Give it a few extra seconds first — Arch's minimal install has none of Ubuntu's boot splash, so it can look stuck when it's actually just booting quietly. If it's genuinely frozen, check the VM's console type; switching the display to Standard VGA in Hardware settings fixes this in most cases where it doesn't.
Troubleshooting
If the VM's IP address isn't showing up in the Proxmox summary tab after your first boot, the guest agent probably isn't running yet. Log in and check:
systemctl status qemu-guest-agentIf it says inactive, run systemctl enable --now qemu-guest-agent and it should appear within a few seconds — no reboot required.
If networking doesn't come up automatically after the reboot into your installed system (as opposed to the live ISO, which handles this itself), check that NetworkManager is actually enabled and running:
systemctl status NetworkManager
nmtuinmtui gives you a simple text-based menu to connect to a wired or Wi-Fi connection if DHCP alone isn't picking anything up — though on a VirtIO NIC behind vmbr0, DHCP almost always works without intervention.
If the VM feels sluggish even though it's a minimal install, double check you actually set the CPU type to host and the disk bus to VirtIO back in setup — leaving these on their older defaults (like kvm64 and IDE) works, but noticeably slower, especially for disk I/O.
Best Practices
Take a snapshot right after the first successful boot, before you install anything else. Arch updates frequently, and a rolling-release system occasionally has a rough update — having a known-good snapshot to roll back to costs nothing and saves a full reinstall if a kernel update or bootloader change goes sideways.
If typing out fifteen manual commands isn't your idea of a good time, Arch also ships an official guided installer called archinstall, launched automatically or by typing archinstall at the live prompt. It asks you the same questions — disk, timezone, hostname, packages — and does the partitioning and pacstrap steps for you. It's a legitimate option, especially once you've done the manual process once and understand what's actually happening underneath it.
Keep the VM's package list updated regularly with pacman -Syu. Because Arch has no scheduled point releases, packages move fast, and letting updates pile up for months at a time is the single biggest cause of painful, multi-step upgrades on Arch. A VM you check in on every week or two stays easy to maintain.
Resist the urge to install a desktop environment on this VM unless you actually need one. Most Arch VMs in a homelab setting run headless — a web app, a small service, a build environment — and every extra package is one more thing to keep updated and one more thing that can break.
Frequently Asked Questions
Do I need a separate boot partition, or can I just use one big partition?
With UEFI, you need at least two: the FAT32 EFI System Partition and your root filesystem. You can't combine them, since the firmware specifically requires FAT32 for the ESP.
Can I use ZFS instead of ext4 for the root filesystem?
Yes, Arch supports ZFS through a community package, but it adds real setup complexity for a first install. Start with ext4, get comfortable with the process, and revisit ZFS later if you specifically need its snapshot or checksumming features.
Is BIOS (SeaBIOS) instead of UEFI a problem?
Not technically, but the steps in this guide assume UEFI. If you use SeaBIOS, you'd install GRUB in legacy mode and skip the EFI System Partition entirely — it works, but UEFI is the more current path and matches how Arch's own installer expects things.
Why isn't there a graphical installer like Ubuntu has?
Arch's philosophy is deliberately minimal and hands-on — the project expects you to understand and choose each piece of your system rather than accept defaults from an installer. It's more work upfront, and that's intentional.
Does the QEMU Guest Agent need to be installed before the first reboot?
No — you can install it any time after the base system is up. Doing it during the initial chroot session just saves you from having to reboot twice.
Conclusion
Once you've been through it, an Arch install stops feeling mysterious — it's really just partition, format, pacstrap, chroot, configure, bootloader, reboot. None of those steps are hard on their own; there are just more of them than Ubuntu makes you deal with, and each one teaches you something about how a Linux system actually boots.
You've now got a minimal, current, fully-understood Arch VM running under Proxmox VE, complete with the guest agent so Proxmox can see and manage it properly. From here, it's just pacman -S and whatever you actually want to build.