Two virtual machines can sit side by side in the UTM sidebar, look identical, and still disagree about whether USB passthrough exists at all. That isn’t a bug. UTM ships two completely different backends — QEMU and Apple Virtualization — and the choice you make on the first screen of the creation wizard quietly decides whether you can attach a USB device, add a second display, or mount a shared folder. Most “UTM can’t do X” questions turn out to be “this VM was built on the other backend” questions.
UTM’s documentation states each of these constraints plainly, but spreads them across six different pages, so the pattern is easy to miss. This page pulls them into one place, alongside the parts people actually search for: installing through Homebrew, getting USB devices into a guest, running more than one display, and sharing a folder with the host. Every claim below comes from UTM’s own docs or Homebrew’s cask definition, and refers to UTM 4.7.5, released 2026-01-03.
Installing UTM: Homebrew, App Store, or DMG
UTM is distributed three ways, and at 4.7.5 they are the same application. The Homebrew cask is the fastest route if you already have Homebrew:
brew install --cask utmThe cask installs UTM.app to /Applications and declares macOS 11 as its floor. There is a second thing it does that the official installation page never mentions, and it is the reason to prefer it.
UTM ships a command line tool called utmctl, buried inside the app bundle. UTM’s scripting documentation tells you to put it on your PATH by hand, with sudo:
sudo ln -sf /Applications/UTM.app/Contents/MacOS/utmctl /usr/local/bin/utmctlThe Homebrew cask already declares that binary as an artifact, linking UTM.app/Contents/MacOS/utmctl into your Homebrew prefix. Install through brew and utmctl is on your PATH the moment the download finishes — no sudo, no symlink, and it gets cleaned up if you ever uninstall. If you install from the App Store or the DMG instead, you are doing that symlink yourself.
utmctl wraps UTM’s AppleScript bridge, so it can list, start, stop, and suspend VMs from a shell script. Run it with no arguments for its help output and command list.
The other two routes: the Mac App Store lists “UTM Virtual Machines” from Turing Software LLC at $9.99, requiring macOS 11.3 or later, and GitHub offers the identical build as a free DMG. UTM’s own documentation is unusually candid here — the App Store build has no features left out, its only advantage is automatic updates, and buying it funds development. So $9.99 buys auto-updates and supports the project. It does not buy a better UTM.
The backend decides what your VM can do
Before any of the configuration below will make sense, this is the table worth internalizing. QEMU is the emulation-and-virtualization backend UTM was built on; Apple Virtualization is Apple’s own framework, available for macOS and Linux guests. They do not have the same feature set, and neither one is a superset of the other.
| Capability | QEMU backend | Apple Virtualization backend |
|---|---|---|
| USB sharing | Yes | Not supported |
| Multiple graphical displays | Yes | Not supported for macOS guests |
| Shared folder via VirtFS (9pfs) | Linux guests only | No |
| Shared folder via SPICE WebDAV | Windows and Linux guests | No |
| Shared folder via VirtioFS | No | Linux guests, macOS 12+ |
| Rosetta for x86_64 Linux binaries | No | Linux guests, macOS 13+ |
Read that as a decision, not trivia. Need a USB device inside the guest? That means QEMU, which forecloses Rosetta. Want Rosetta for Intel Linux binaries on Apple Silicon? That means Apple Virtualization, which forecloses USB passthrough. No configuration screen reconciles the two, and switching later means rebuilding the VM.
USB passthrough on macOS
USB sharing works only on the QEMU backend. Enabling it is genuinely simple: open the VM configuration and make sure “USB sharing” is checked. Start the VM, plug the device in, and a prompt offers to attach it. The USB button on the toolbar lists devices you can attach or detach at any point while the VM runs.
The part worth knowing before you spend an evening on it is the limitation UTM’s docs describe and most write-ups skip. Because macOS does not let an application capture a USB device without custom kernel drivers, UTM cannot perform a proper hardware reset on the device. The host configures the device first; only then does a software reset get sent and the guest sees it. The practical consequence, in the docs’ own framing, is that many devices will not work properly when captured by the virtual machine. Some cannot be captured at all — built-in Apple webcams and some external flash drives are named specifically.
This is a structural limit of USB on macOS, not a setting you have missed. If a device misbehaves in the guest, the honest first question is whether it can work at all — no amount of configuration moves it across that line.
Attaching can also be scripted through the AppleScript bridge, useful if a device needs to land in a VM on every boot:
tell application "UTM"
set device to first usb device
set vm to virtual machine named "Ubuntu"
connect device to vm
end tellRunning multiple displays
Multiple displays are configured by adding hardware, not by toggling a setting: in the VM configuration, add a new display device, one per screen you want. Serial devices in “Built-in Terminal” mode work too if what you want is extra consoles rather than extra framebuffers.
The detail that decides whether this works: the emulated display card you pick for the additional displays. UTM recommends virtio-gpu-pci, virtio-gpu-gl-pci, or secondary-vga, because several of the other display hardware options are designed to function only as the primary video device. Choose one of those and the second display never comes up, which reads like a broken feature rather than a hardware choice.
On macOS, each additional display opens in its own window when the VM starts. Close one by accident and it is not gone — click the display icon in the toolbar to bring it back. Apple Virtualization does not support multiple graphical displays for macOS guests, so this is QEMU territory.
Adjacent to this is dynamic resolution, which is what people often actually want when they say the display is wrong: the guest resizing to match the window. That needs “Auto resolution” checked in the configuration plus guest tools installed — spice-vdagent on Linux — and a reboot. It works on QEMU backend VMs with guest tools, and on Apple backend guests running macOS 14 or newer. Some Linux distributions have a known bug where the resolution refuses to follow the window anyway; forcing the window manager to re-read it usually clears that:
xrandr --output Virtual-1 --autoOne more display setting is worth flagging, because the intuitive choice is the wrong one. Retina Mode sounds like what you want on a Hi-DPI screen, but UTM recommends leaving it disabled: with it off, the host scales using efficient hardware scalers, while turning it on pushes scaling into the guest, which does it in software at higher memory and processing cost.
Shared folders between macOS and the guest
There are three directory sharing mechanisms, and picking the wrong one is the usual reason a shared folder never appears in the guest.
VirtFS — QEMU with a Linux guest
VirtFS requires 9pfs and VirtIO driver support in the guest, which rules out Windows, and it is meaningfully faster than the WebDAV alternative. It is the recommended option for Linux guests on QEMU. The share is exposed under the VirtFS tag share — that name comes from UTM and should not be changed. Add this to /etc/fstab in the guest:
# UTM Shared Folder
share /mnt/utm 9p trans=virtio,version=9p2000.L,rw,_netdev,nofail,auto 0 0Create the mount point with sudo mkdir /mnt/utm first. Two gotchas: the shared directory cannot be changed while the VM is powered on, and VirtFS and WebDAV sharing cannot be used at the same time.
The failure that sends people back to search is permissions — the mount appears, and then everything under it is access-denied unless you are root. The cause is not a broken mount. The directory inherits UID and GID from macOS, which numbers accounts differently than Linux: a typical macOS user is UID 502 with GID 20, while the guest user is usually 1000/1000. Nothing is wrong; the numbers simply don’t line up. UTM documents two ways out. The clean one is a bindfs mount in your home directory that remaps the IDs, added as a second fstab entry. The blunt one is sudo chown -R $USER /mnt/utm, which leaves host permissions untouched but writes a custom user.virtfs attribute onto every file to record guest ownership — which is why UTM advises against it if you are sharing something like your home folder.
SPICE WebDAV — QEMU with a Windows guest
SPICE WebDAV needs the SPICE guest tools installed and exposes the share as a WebDAV mount on the guest’s own localhost, typically port 9843. It has better Windows support than VirtFS but can perform worse on Linux. On Linux you would install spice-webdavd (or phodav on Arch) and mount http://127.0.0.1:9843 with something like davfs2.
On Windows the share shows up in “My Computer” as a network drive. When it doesn’t appear — a common enough complaint — there is a script for exactly that, shipped with the tools:
C:\Program Files\SPICE webdavd\map-drive.batVirtioFS — Apple Virtualization with a Linux guest
VirtioFS is the Apple backend’s answer and requires macOS 12 or later. Despite the names, VirtioFS is not VirtFS — different mechanism, different backend, and UTM’s docs call this out directly because the confusion is predictable. Mount it like this:
sudo mkdir /media/myshare
sudo mount -t virtiofs share /media/myshareFor macOS guests, shared directories only work when both host and guest are running macOS 13 or later.
Apple Silicon vs Intel: what actually differs
One rule explains most of the performance surprises: virtualization requires the guest architecture to match the host. That means x86_64 on Intel Macs and aarch64 on Apple Silicon. If the architectures don’t match, you get emulation instead — and UTM will not use virtualization even if it is enabled in the QEMU settings. An x86_64 VM on an M-series Mac is being emulated, and no setting turns that into virtualization.
That has a consequence people hit immediately and misread as a bug. Installing x86_64 Windows on an Apple Silicon Mac defaults to a single CPU core, while ARM64 Windows on Apple Silicon (or x86_64 on Intel) defaults to your system’s core count. The reason is memory ordering: emulating multiple x86_64 cores on an ARM64 host has to be done on a single core anyway, so extra cores would cost performance rather than add it. UTM exposes a “Force multicore” option in System settings — the docs are blunt that it comes at the cost of correctness, and that occasional odd crashes are the expected result. Windows needs at least 2 cores to install, which is precisely how people find this option.
Where cores are left blank or set to 0, UTM’s default is the number of performance cores on Apple Silicon and the number of physical cores on Intel. For strong-on-weak emulation the default is always 1.
Apple Silicon gets one capability Intel Macs don’t: Rosetta, on macOS 13 or later, running Intel Linux executables inside an Apple Silicon Linux VM on the Apple Virtualization backend. It’s enabled with “Enable Rosetta (x86_64 Emulation)” in the wizard, or in the Virtualization tab afterwards. The runtime arrives as a VirtioFS mount named rosetta, which you mount and then register as an x86_64 ELF handler with update-binfmts. One version-specific detail that is easy to get wrong: the --preserve flag should be no on macOS 13 and yes on newer versions. You also need x86_64 shared libraries in the guest, which means enabling multiarch or multilib for your distribution.
Windows 11 guests, and the licensing part
To be direct: regardless of how you obtain the installer, you need a valid license from Microsoft to run Windows. UTM’s guide says so in those terms, and it’s the step most tutorials leave out.
UTM points at CrystalFetch, a free macOS utility for legally obtaining current Windows builds from Microsoft. The architecture has to match your Mac — arm64 for Apple Silicon, amd64 for Intel — and getting this backwards produces a VM that boots into an EFI shell rather than the installer. In the wizard, choose Virtualize, then Windows, and leave both “Install Windows 10 or higher” and “Install drivers and SPICE tools” checked so the guest tools ISO mounts on a second drive and installs during setup.
Three failures are documented and worth knowing in advance. A BSOD reading SYSTEM_THREAD_EXCEPTION_NOT_HANDLED during install means the Windows build is too old — 21390 or higher is required. Networking that looks dead may not be: due to libslirp limitations ping does not work, so Windows can conclude it has no internet when it does. And Windows 11 24H2 has a compatibility issue with the graphics drivers on the guest tools ISO that lands you at a black screen — eject the guest ISO from the CD menu, reboot into the installer, and install the tools afterward.
If Windows 11 setup refuses to continue without a network connection, the old OOBE\BYPASSNRO trick has been blocked by Microsoft on newer builds. The current path in UTM’s docs is to press Shift+F10 for a command prompt and run start ms-cxh:localonly, which lets you create a local account and finish setup.
When to stop configuring
A fair amount of time gets spent tuning settings that were never the cause. If a USB device won’t behave, check whether it is capturable at all before touching the configuration — the host-side reset limitation is not something a checkbox fixes. If a second display never appears, look at the display card before the display count. If a shared folder mounts but denies access, that’s UID and GID arithmetic, not a permissions bug. And if the feature you want isn’t on the backend your VM was built with, the answer is a new VM rather than a deeper trawl through settings.
UTM is Apache-2.0 licensed, with its changelog and issue tracker open on GitHub. When behavior doesn’t match the documentation, that tracker is a more productive next stop than another round of toggles.