How to Run the Virtual OS Museum on macOS with UTM in 2025

How-To Guide·Jun 16, 2026·14 min read

Prerequisites Checklist Before You Begin

Before you download anything, make sure your Mac meets the minimum bar. The Virtual OS Museum is a densely packed Linux VM containing over 1,700 pre-installed operating systems — from the Manchester Baby (1948) to contemporary releases — and it will tax a low-spec machine noticeably.

| Requirement | Minimum | Recommended | |---|---|---| | macOS version | Ventura 13.0 | Sequoia 15.x | | UTM version | 4.0 | 4.5+ | | Free disk space | 60 GB | 100 GB+ | | RAM | 8 GB | 16 GB | | CPU | Intel Core i5 / M1 | Apple M2 or later |

Checklist:

[ ] macOS Ventura 13.0 or later installed
[ ] UTM 4.x downloaded from mac.getutm.app or the Mac App Store
[ ] At least 60 GB free on an internal NVMe SSD (100 GB+ strongly preferred)
[ ] 8 GB RAM minimum; 16 GB if you plan to run multiple OS sessions
[ ] zstd command-line tool available (installable via Homebrew)
[ ] Virtual OS Museum VM image downloaded from virtualosmuseum.org

Note: The museum image is distributed as a single Linux VM compatible with QEMU, VirtualBox, and UTM. On macOS, UTM is the officially recommended path, especially on Apple Silicon where it can use the native Apple Virtualization framework for the Linux host layer.

Estimated time: 45–90 minutes (dominated by download and extraction time depending on your connection).

Step 1: Installing UTM on macOS

UTM is the only mature, actively maintained QEMU frontend for macOS that supports both Apple Silicon virtualization and x86 emulation in the same app. You need it installed and verified before touching the museum image.

Installing UTM via the Mac App Store vs Direct Download

UTM is available two ways, and the difference matters:

Mac App Store version — sandboxed, auto-updates, costs a few dollars (the paid version funds development). Sandboxing restricts certain QEMU command-line passthrough features.
Direct download from mac.getutm.app — free, fully open-source, no sandbox, full QEMU access. This is what the Virtual OS Museum documentation recommends because the museum's launcher scripts use advanced QEMU flags.

Install via Homebrew (easiest for developers):

brew install --cask utm

Verify the installation:

# UTM is a GUI app; check the bundle version directly
defaults read /Applications/UTM.app/Contents/Info.plist CFBundleShortVersionString
# Expected output: 4.5.x or similar

Enabling Virtualization Extensions on Apple Silicon

On Apple Silicon, UTM can use Apple's Hypervisor framework for ARM Linux VMs, which gives near-native performance for the museum's Linux host layer. This is enabled per-VM in UTM's settings (covered in Step 2). No system-level toggle is needed on macOS — unlike enabling Hyper-V on Windows.

On Intel Macs, UTM falls back to QEMU's TCG (software) emulator for anything non-x86. This is significantly slower for emulated architectures like 68k or SPARC inside the museum.

Note: If you're on an Intel Mac running Ventura or later, make sure Intel VT-x is enabled. It almost certainly is by default; you can confirm by running sysctl kern.hv_support — a result of 1 means hardware virtualization is available.

Step 2: Importing the Virtual OS Museum VM Image into UTM

The museum image is large (expect 20–50 GB compressed depending on the version) and arrives as a .zst (Zstandard) or .zip archive. Extraction before import is mandatory — UTM cannot read compressed archives directly.

Extracting the Downloaded Archive

Install zstd if you haven't already:

brew install zstd

Decompress the museum image:

zstd -d virtualosmuseum.img.zst -o virtualosmuseum.img

This will take several minutes. The -d flag decompresses; the -o flag specifies the output filename. You should end up with a .img or .qcow2 file.

Importing the .utm or .qcow2 Image File into UTM

UTM supports two import paths:

If the museum ships a .utm bundle: Double-click the file in Finder. UTM opens and adds the VM automatically.
If you have a raw .qcow2 or .img file: Open UTM → click the + button → choose Create a New Virtual Machine → select Emulate (not Virtualize, unless you're on Apple Silicon running ARM Linux) → set the OS to Linux → skip the ISO step → under Storage, remove the default drive and add your existing .qcow2 by choosing Import Drive.

Configuring VM Memory and CPU Settings

Once imported, select the VM in UTM's sidebar, click Edit, and adjust:

CPU Cores: Set to at least 4. The inner QEMU sub-emulators that run each historic OS need headroom.
Memory: Set to 4096 MB (4 GB) minimum. 8 GB is better if your Mac has 16 GB total.
Display: Leave at default QEMU VGA or VirtIO GPU; you can tweak this later.

Note: On Apple Silicon, if the museum image is an ARM64 Linux build, switch the backend to Apple Virtualization under QEMU → Use Apple Virtualization for dramatically better performance. If it's x86-64 Linux, keep the QEMU backend — Apple Virtualization only works for matching architectures.

Step 3: First Boot and Navigating the Museum Interface

The Virtual OS Museum is not a single OS — it's a Linux VM acting as a container that launches individual operating systems on demand via nested QEMU instances. Understanding this layered architecture prevents a lot of confusion.

Understanding the Linux Host VM That Wraps the Museum

When you boot the museum in UTM, you're booting a Linux distribution (typically a minimal Debian or Arch-based setup) that serves as the management layer. This Linux VM owns the disk containing all 1,700+ OS images and the scripts that configure and launch them. You interact with it primarily through its graphical launcher menu, not through a raw Linux desktop.

Using the One-Click Launcher Menu to Browse OS Categories

After boot, the launcher presents a categorized menu. OSes are organized by:

Decade: 1940s–1950s, 1960s, 1970s, 1980s, 1990s, 2000s, 2010s, Present
Architecture: x86/x86-64, Motorola 68k, SPARC, PDP-11, VAX, MIPS, PowerPC, ARM, and others
Vendor/Platform: Microsoft, Apple, Sun, DEC, IBM, Commodore, Atari, and dozens more

The oldest entry is the Manchester Baby (1948 SSEM), a simulation of the world's first stored-program computer. The launcher UI uses arrow keys and Enter for navigation in terminal mode, or mouse clicks in graphical mode.

Searching for a Specific OS by Name or Era

The launcher includes a search function — press / or look for the Search menu item. Type a partial name like sunos or bsd 4 and the list filters in real time. This is significantly faster than scrolling through 1,700 entries manually.

Note: Some entries are standalone applications (early word processors, compilers) rather than full OS boots. These are clearly labeled in the launcher with an [APP] prefix.

Step 4: Launching Individual Operating Systems

Each OS launch inside the museum is essentially a new QEMU process spawned by the launcher script, with pre-configured disk images, CPU models, and memory allocations tailored to that specific OS. This is the nested emulation stack in action.

Running a Classic OS (e.g., MS-DOS 6.22 or Windows 3.1)

Select MS-DOS 6.22 from the launcher and press Enter. Under the hood, the launcher script executes something equivalent to:

qemu-system-i386 \
  -cpu pentium \
  -m 64 \
  -drive file=/museum/dos/msdos622.qcow2,format=qcow2,if=ide \
  -boot c \
  -vga std \
  -display gtk \
  -no-reboot

The -cpu pentium flag ensures period-accurate CPU behavior. The -m 64 allocates 64 MB of RAM — more than DOS ever saw on real hardware, but stable for emulation. You don't need to type this command yourself; the launcher handles it. It's shown here so you understand what's happening and can customize it if needed.

Running a UNIX Variant (e.g., SunOS or BSD 4.3)

SPARC-based OSes like SunOS 4.1 use qemu-system-sparc, while VAX-based BSD 4.3 uses qemu-system-vax. The museum bundles all required QEMU system binaries inside the Linux VM, so you don't need to install anything extra.

Switching Between Running OS Sessions Without Rebooting

The museum launcher supports running multiple OS instances concurrently. Each spawns in its own window. To switch back to the launcher without killing a running OS, use UTM's keyboard grab/release shortcut: Control + Option (by default). This releases the mouse and keyboard from the active VM window so you can interact with the macOS host or the launcher menu.

Note: The full nested emulation stack is: macOS → UTM/QEMU → Linux Museum VM → inner QEMU process → target OS. Each layer adds latency. On Apple Silicon with the Virtualization framework handling the Linux layer, the macOS→Linux hop is near-zero cost, so only the inner QEMU emulation is the bottleneck.

Step 5: Configuring Shared Folders and Networking

Getting files in and out of the museum VM, and giving vintage OSes network access where possible, requires a few extra configuration steps.

Enabling UTM Shared Directory to Transfer Files

In UTM, edit the museum VM → go to Sharing → enable Share Directory and point it at a folder on your Mac (e.g., ~/Documents/museum-transfers). UTM uses VirtioFS to expose this folder inside the Linux VM.

Inside the running Linux museum VM, mount it:

mount -t virtiofs share /mnt/host

You can now copy files between your Mac and the museum VM at full disk speed. This is useful for dropping disk images of OSes you want to add, or extracting files from museum OS instances.

Setting Up NAT Networking for OSes That Support TCP/IP

In UTM's Network settings for the museum VM, the default Shared Network (NAT) mode is sufficient for Linux itself to reach the internet. Inside the museum, individual emulated OSes that support TCP/IP (generally anything from the late 1980s onward) can be bridged through the Linux VM's network using QEMU's usermode networking (-netdev user).

Limitations: Which Emulated OSes Cannot Use Host Networking

| Category | Network Support | Notes | |---|---|---| | Pre-1985 OSes (CP/M, DOS early versions, Manchester Baby) | None | Predate TCP/IP entirely | | Mid-era UNIX variants (SunOS 3.x, BSD 4.2) | Limited | May need manual IP config | | Windows 95/98, macOS 8-9 | Yes (NAT) | Works with QEMU usermode | | Modern Linux guests (inside museum) | Full | Bridge or NAT both work |

Note: For OSes where networking is unavailable, the museum launcher will grey out the network option automatically. Don't try to force it — the vintage OS has no TCP/IP stack to configure.

Common Issues and Fixes

Error: 'Could Not Open Disk Image' on VM Boot

Cause: macOS APFS creates sparse files by default, and QEMU sometimes cannot correctly read a sparsely-allocated .qcow2 on APFS volumes, particularly after a failed extraction.

Fix: Re-convert the image with explicit metadata pre-allocation:

qemu-img convert -p -O qcow2 -o preallocation=metadata input.qcow2 output.qcow2

The -p flag shows progress. Replace input.qcow2 with your original file. Use the resulting output.qcow2 as the VM disk in UTM. This ensures QEMU can map the image structure correctly regardless of APFS sparse file behavior.

Error: Extreme Slowness When Running Nested Emulators on Intel Mac

Cause: On Intel Macs, the Linux museum VM runs under QEMU TCG (software emulation) for any non-x86 guest, and even x86 guests lack the Apple Virtualization framework acceleration available on Apple Silicon. Nested QEMU instances compound this — you're emulating a CPU inside an emulated CPU.

Fix: There's no complete fix, but mitigations help:

Enable KVM acceleration if your Intel Mac supports it (check: sysctl kern.hv_support should return 1).
In UTM, set the backend to QEMU and enable Use Hypervisor in CPU settings.
Limit concurrent running OS sessions to one or two.
Accept that 68k/SPARC/PDP emulation will always be slower on Intel vs. Apple Silicon.

Error: Display Resolution Stuck at 800×600 Inside the Museum VM

Cause: The VirtIO GPU driver isn't loaded in the Linux museum VM, so it falls back to a basic SVGA mode.

Fix: Inside the Linux museum VM terminal, check if virtio-gpu is loaded:

lsmod | grep virtio_gpu
# If no output, load it:
modprobe virtio_gpu

Then in UTM's VM settings, change the display from QEMU SVGA to VirtIO GPU. After reboot, the Linux VM should negotiate a higher resolution. You can also set a fixed resolution in UTM's display settings under Resolution.

Error: UTM Crashes on Import of Large .qcow2 Image on macOS Sequoia

Cause: A known issue in some UTM 4.x releases where importing .qcow2 files over ~30 GB triggers a memory pressure crash on macOS Sequoia, related to how UTM validates the image before import.

Fix: Instead of using UTM's GUI import, manually place the .qcow2 file in a UTM VM bundle:

# Create a UTM bundle directory manually
mkdir -p ~/Library/Containers/com.utmapp.UTM/Data/Documents/VirtualOSMuseum.utm/Images/
cp virtualosmuseum.qcow2 ~/Library/Containers/com.utmapp.UTM/Data/Documents/VirtualOSMuseum.utm/Images/

Then create a minimal config.plist or duplicate an existing VM bundle and replace its disk image path. This bypasses the GUI importer entirely.

Performance Tips for Running 1,700+ OSes Smoothly on macOS

The museum is usable out of the box, but a few tuning choices make a meaningful difference between choppy and smooth.

Tuning UTM CPU and Memory Beyond Defaults

UTM's default memory allocation is conservative. For the museum VM, set RAM to at least 4 GB, ideally 8 GB. For CPU count, match your Mac's performance core count minus one (leave one for macOS). On an M2 Pro with 10 cores, allocate 8 cores to the VM.

Also enable Force Multicore in UTM's QEMU CPU settings — this allows QEMU to use multiple host threads for a single emulated CPU, which helps with workloads like booting a SPARC OS that hammer a single virtual core.

Using Apple Virtualization Framework vs. QEMU Backend

| Feature | Apple Virtualization | QEMU Backend | |---|---|---| | Performance (ARM Linux guest) | Near-native | 40-70% of native | | x86 guest support | No | Yes | | Rosetta 2 x86 in Linux guest | Yes (macOS 13+) | No | | Advanced QEMU flags | No | Yes | | Stability | Very high | High | | Recommended for museum | ARM image only | x86 image or Intel Mac |

If the museum ships an ARM64 Linux image (check the download page), use Apple Virtualization. If it's x86-64 only, use QEMU backend regardless of your hardware.

Storing the VM Image on an SSD vs. External Drive

Always store the museum VM on your Mac's internal NVMe SSD. The image is accessed constantly during OS launches — each sub-emulator opens a separate .qcow2 file from within the Linux VM. An external USB 3.0 drive adds 10–30ms of additional latency per disk read, which compounds badly for vintage OSes that load from slow virtual disks.

Note: Before experimenting with settings or launching unfamiliar OSes, take a UTM snapshot of the museum VM: select the VM → VM menu → Snapshot → Take Snapshot. This lets you roll back instantly if an inner OS corrupts the museum's shared state.

FAQ: Virtual OS Museum on macOS with UTM

Q: Can I run the Virtual OS Museum on macOS without UTM using VirtualBox?

Yes — the Virtual OS Museum explicitly supports VirtualBox and ships a compatible image format. However, VirtualBox on Apple Silicon is still maturing as of 2025, and its x86 emulation performance on M-series Macs is noticeably worse than UTM's QEMU backend. For Intel Macs, VirtualBox is a reasonable alternative. For Apple Silicon, UTM is the strongly preferred option per the museum's own documentation, both for performance and compatibility with the bundled launcher scripts.

Q: Is the Virtual OS Museum free to download and use?

Yes. The Virtual OS Museum is free — the schema.org metadata on virtualosmuseum.org explicitly lists the price as $0 USD. The project is created and maintained by Andrew Warkentin, a Canadian OS/emulator developer and OS historian. You can support the project financially via Patreon or Ko-fi if you find it useful, but payment is entirely optional. The full VM image and all bundled OS installations are available at no charge from virtualosmuseum.org.

Q: How do I add my own OS installation to the museum VM?

The museum uses a QEMU-based extension model. Inside the Linux museum VM, each OS entry is defined by a launcher script in a structured directory tree. To add your own, boot the museum VM, mount a host folder via VirtioFS (as described in Step 5), copy your .qcow2 OS disk image in, then create a launcher script modeled on an existing entry in the same directory. The script invokes qemu-system-* with the appropriate architecture, CPU, memory, and drive flags. Consult the museum's README (available on the downloads page and in the GitLab repository at gitlab.com/virtualosmuseum) for the exact directory structure and naming conventions expected by the launcher UI.