If you own a Mac and you've been reading about Proxmox VE, you've probably noticed that almost every install guide out there assumes you're sitting in front of a Windows PC, a Linux box, or a spare server. Mac users get a footnote at best, usually something like "VMware Fusion doesn't support this on Apple Silicon" and nothing else. That's not much help if the only machine on your desk is a MacBook.
The good news is you don't need to buy hardware, and you don't need Boot Camp, which doesn't even exist anymore on Apple Silicon. You can run Proxmox VE right inside a free app called UTM, whether you're on an M-series Mac or an older Intel one. The catch is that the two chip types behave very differently once you're inside Proxmox VE itself, and nobody explains that part clearly. This guide does.
What You Will Learn
- What UTM actually is, and why it can run Proxmox VE on both Apple Silicon and Intel Macs when other Mac virtualization apps can't
- The real difference between "Emulate" and "Virtualize" mode in UTM, and which one your Mac needs
- How to build a UTM virtual machine correctly for Proxmox VE 9.2, step by step
- How to reach the Proxmox VE web interface from Safari or Chrome once it's running
- What actually works in this setup and what doesn't, especially on Apple Silicon, so you're not surprised later
What Is This Feature?
UTM is a free, open-source virtualization app for macOS, built on top of QEMU. QEMU is the same virtualization engine that powers Proxmox VE's own VM system, so in a strange way you're about to run a smaller version of Proxmox VE's engine just to get Proxmox VE booted in the first place.
Here's the part that trips people up: Apple Silicon Macs (the M1 through M4 chips) use the ARM64 processor architecture. Proxmox VE only ships for x86-64, the architecture Intel and AMD processors use. Those two instruction sets are not compatible at the hardware level, so an M-series Mac can't run x86-64 code natively, full stop.
UTM works around this with two different modes:
- Virtualize mode uses Apple's Hypervisor.framework to run a guest OS that matches your Mac's own architecture, with near-native speed. This only works when guest and host architecture match.
- Emulate mode uses QEMU's software emulation (called TCG) to translate x86-64 instructions into ARM64 ones on the fly, or vice versa. This works across architectures, but every single instruction has to be translated in software, which is slow.
On an Intel Mac, x86-64 Proxmox VE matches the host architecture, so UTM can use Virtualize mode and you get solid, close-to-native performance. On an Apple Silicon Mac, there's no way around it: you're stuck with Emulate mode, and Proxmox VE will run noticeably slower. Not unusably slow for exploring the interface, but slow enough that you shouldn't expect it to feel like a real server.
Why Would You Use It?
Mostly because it's free and you already own the hardware. UTM costs nothing from its website, has no account requirement, and the app itself is under 50 MB. Compare that to needing a license, a NUC, or an old desktop tower taking up space under your desk.
It's also a genuinely good way to learn the Proxmox VE web interface before you commit real hardware to it. You can click through the datacenter view, create a test VM, spin up an LXC container (a lightweight, OS-level virtual environment that shares the host's kernel instead of emulating its own hardware, which is why containers start in seconds instead of minutes), and get comfortable with where things live in the menus.
I'll be upfront about where this setup falls apart. On Apple Silicon, don't expect to create fast, hardware-accelerated VMs inside your nested Proxmox VE — the CPU flags that KVM needs (Intel VT-x) simply aren't there under emulation, so any VM you build inside it will run in QEMU's own software fallback too, two layers of emulation deep. LXC containers fare much better here since they don't need those CPU extensions at all. On an Intel Mac, hardware acceleration for Proxmox VE itself works well, but whether nested KVM works for VMs created inside it is inconsistent and depends on your macOS version — don't build a workflow around it.
Prerequisites
- A Mac running macOS 13 Ventura or later (UTM technically supports back to macOS 11, but networking and performance are noticeably better on 13+)
- Any Apple Silicon Mac (M1 or newer) or Intel Mac from roughly 2015 onward
- 16 GB of total system RAM is a comfortable starting point — you'll be handing 6 to 8 GB of that to the VM alone, and macOS needs headroom on top of it. 8 GB total system RAM can work if you keep the VM's allocation modest
- At least 40 GB of free disk space for the virtual disk and installer
- UTM, downloaded from its official site
- The Proxmox VE 9.2 ISO (about 1.7 GB) from the official Proxmox download page — it's built on Debian 13.5 "Trixie" with kernel 6.17, QEMU 11.0, and LXC 7.0 under the hood
Quick way to check your chip: click the Apple logo in the top-left corner, choose About This Mac, and look at the Chip line. If it says "Apple M1/M2/M3/M4," you're on Apple Silicon. If it says "Intel," you're on an Intel Mac.
Step-by-Step Tutorial
Step 1: Install UTM
Download UTM from its official website (mac.getutm.app) and drag it into your Applications folder. If you use Homebrew, brew install --cask utm does the same thing from Terminal. UTM is also on the Mac App Store for about $10, which just supports the developer and gives you automatic updates — functionally it's the same app either way.
Step 2: Download the Proxmox VE ISO
Grab the Proxmox VE 9.2 ISO installer from proxmox.com's download page. It lands in your Downloads folder as a roughly 1.7 GB file. You don't need to burn it to a USB drive or do anything special to it — UTM mounts ISO files directly.
Step 3: Create a new virtual machine
Open UTM and click the + button (or Add a New Virtual Machine). You'll be asked to start from scratch, and you want Virtualize or Emulate — not the pre-built Windows/Linux templates further down that list.
- On an Intel Mac, choose Virtualize.
- On an Apple Silicon Mac, choose Emulate.
On the next screen, pick Linux as the operating system. If you chose Emulate, UTM will ask which architecture to emulate — select x86_64. This is the step people miss most often, and skipping it means the VM won't boot the Proxmox installer at all.
Step 4: Point it at the ISO and set resources
Under Boot ISO Image, browse to the Proxmox VE ISO you downloaded. On the Hardware screen, set memory to at least 6144 MB (6 GB) — 8192 MB if your Mac can spare it — and give it 4 CPU cores if you're on Virtualize mode, or as many cores as you're comfortable dedicating (6 to 8 if available) if you're on Emulate mode, since software translation is CPU-hungry and more cores genuinely helps here.
On the Storage screen, set the virtual disk to at least 32 GB — 64 GB gives you more room to create a test VM or two later without babysitting free space.
Step 5: Set the network mode
Before finishing, open the VM's network settings (or edit them after creation under the VM's Devices tab). Shared Network is the simplest choice: your Mac and the VM can reach each other directly without extra setup, since this uses UTM's own QEMU-based networking rather than Apple's Virtualization framework networking, which has known issues reaching guests from the host. If you'd rather have the Proxmox VM show up on your home network with an IP from your router, use Bridged (Advanced) and pick your active interface — macOS will prompt you for a local network permission the first time you do this.
While you're in the network settings, set the emulated network card to virtio-net-pci if it isn't already selected. Debian's kernel (which Proxmox VE is built on) has solid VirtIO driver support out of the box, and it performs noticeably better than the older rtl8139 emulation some templates default to.
Step 6: Boot and run the Proxmox VE installer
Save the VM and start it. You'll land in the same graphical Proxmox VE installer you'd see on real hardware. Choose Install Proxmox VE (Graphical), accept the license, and pick the virtual disk you created as the target.
Stick with the default ext4 filesystem rather than ZFS. ZFS wants direct, low-level access to physical disks to do its job properly — checksumming, self-healing, all of it — and a virtual disk sitting on top of your Mac's own APFS filesystem defeats most of that purpose while adding overhead you don't need for a test lab.
Work through the remaining screens: country, time zone, keyboard layout, a root password, an email address for notifications (anything works here), and the network configuration, which the installer usually pre-fills correctly if DHCP is working. Confirm the summary and let it install — expect 5 to 10 minutes on Virtualize mode, and anywhere from 15 to 40 minutes on Emulate mode depending on your Mac's core count. That's normal, not a hang.
Step 7: Reboot and remove the ISO
When installation finishes, the installer prompts you to reboot. Before it boots back into Proxmox VE, make sure the ISO gets unmounted — UTM sometimes handles this automatically, but if you land back in the installer menu instead of Proxmox VE, go to the VM's CD/DVD drive in its settings and eject the image manually, then restart the VM.
Step 8: Open the web interface
After it boots, the console shows a line like https://192.168.64.4:8006/ (the exact address depends on which network mode you picked in Step 5). Copy that address into Safari or Chrome on your Mac — not inside the UTM console window. Your browser will flag the certificate as untrusted, which is expected on a fresh install; click through the warning. Log in as root with the password you set, and leave the realm as Linux PAM standard authentication.
Commands Explained
| Command | What it does |
|---|---|
ip a | Run inside the VM's console if the IP shown at boot looks wrong or the address changed. Lists every network interface and its assigned address. |
pveversion -v | Prints the exact Proxmox VE build and package versions you're running — useful for confirming the install actually landed on 9.2 and for pasting into forum posts if something's off. |
qemu-img snapshot -c cleaninstall proxmox.qcow2 | Run from Terminal on your Mac, not inside the VM, with the VM shut down. Creates a named snapshot of the virtual disk. UTM doesn't expose a snapshot button in its interface, but the qcow2 disk format it uses supports this natively through Terminal. |
Common Errors
- Black screen after clicking Play, nothing ever boots. Almost always an architecture mismatch — you picked Virtualize on an Apple Silicon Mac, or forgot to select x86_64 under Emulate mode in Step 3.
- The install crawls at a snail's pace and seems frozen. Check Activity Monitor on your Mac. If QEMU is pinning every core, that's Emulate mode working as intended, just slowly. Give it time, or lower your expectations for how many cores you allocated versus what your Mac actually has spare.
- No network adapter detected during install, or no IP address assigned. Usually the network card model. Go back to the VM's Devices settings and switch it to virtio-net-pci, then restart the VM.
- Boots straight back into the installer after reboot. The ISO is still mounted as the first boot device. Eject it from the CD/DVD drive settings and reboot again.
- Browser says "This site can't provide a secure connection" instead of just warning about the certificate. That's a different problem than the usual self-signed cert warning — it means nothing is listening on port 8006 yet, which almost always means the VM hasn't finished booting or the network mode isn't actually reaching your Mac.
Troubleshooting
If the web interface never loads no matter how long you wait, go back to Shared Network mode temporarily, even if you'd rather use Bridged. Shared Network is the more reliable of the two for a first attempt, since Bridged mode depends on your specific Wi-Fi or Ethernet setup cooperating with macOS's local network permissions, and troubleshooting that shouldn't be the first hurdle you hit.
If performance feels unbearable on an Apple Silicon Mac, close every other resource-heavy app before you start the VM — browsers with dozens of tabs open are the usual culprit eating RAM you meant to give the VM. Also double check you allocated more than 2 CPU cores; Emulate mode genuinely needs the extra cores to keep up.
If you get logged out of the web interface immediately after logging in, or see certificate errors that won't go away no matter how many times you click through, it's often the Mac's clock and the VM's clock drifting apart during a long, slow Emulate-mode install. Shut the VM down, let it sit for a minute, and boot it again — Proxmox VE syncs time on boot and this usually clears up on its own.
Best Practices
Take a qcow2 snapshot with the qemu-img snapshot command right after your first successful login, while the disk is small and clean. It only takes a few seconds and gives you something to fall back to instead of reinstalling from scratch every time you break something testing a config.
Don't rely on this as your only Proxmox VE environment if you're trying to learn things that depend on real virtualization performance — GPU passthrough, heavy VM workloads, storage benchmarking, that kind of thing. It's genuinely great for learning the interface, practicing backups, and getting comfortable with LXC containers, and genuinely bad for judging how fast Proxmox VE actually is.
Keep the VM's memory allocation fixed rather than adjusting it constantly between boots. Proxmox VE's own background services assume a stable amount of RAM to work with, and shrinking it after the fact tends to cause services to restart or behave oddly until the next reboot.
Frequently Asked Questions
Can I use VirtualBox instead of UTM on a Mac?
VirtualBox dropped support for Apple Silicon entirely, so on an M-series Mac, UTM is really the only practical free option left. On an Intel Mac, VirtualBox still works and the setup is similar to UTM's Virtualize mode.
Will this run fast enough for daily use?
On an Intel Mac with Virtualize mode, yes, close to what you'd get on real hardware. On Apple Silicon with Emulate mode, no — treat it as a learning environment, not something you'd host actual services on long-term.
Can I passthrough my Mac's GPU to a VM inside this nested Proxmox VE?
No. There's no physical PCIe device for a nested Proxmox VE to see through two layers of virtualization, and Apple's own GPU doesn't work like a discrete PCIe card you can hand off anyway.
Does UTM cost anything?
The direct download from UTM's website is completely free. The Mac App Store version costs a small one-time fee for automatic updates and to support development, but it's the identical app.
Why not just use VMware Fusion instead?
VMware Fusion doesn't support running an x86-64 guest on Apple Silicon at all — its Apple Silicon build only runs ARM64 guests. UTM's Emulate mode is really the only route to Proxmox VE on an M-series Mac.
Conclusion
UTM gets you a working Proxmox VE 9.2 install on a Mac you already own, Intel or Apple Silicon, without buying hardware or paying for a license. The Intel path feels close to a real install; the Apple Silicon path is slower by nature of software emulation, and it's worth going in with that expectation set correctly rather than discovering it mid-install.
Either way, you'll come out the other side knowing your way around the Proxmox VE interface, comfortable creating an LXC container or two, and in a much better position to decide whether it's worth putting on real hardware next.