Omarchy in a VM: VirtualBox, VMware and Parallels decisions

A virtual machine is useful for learning Omarchy without replacing your daily system. It presents virtual hardware to the installer. A successful VM does not prove your laptop’s Wi-Fi, GPU or suspend support; a failed virtual graphics configuration does not prove the same computer cannot run Omarchy natively.

This is a preparation and diagnosis guide, not a claim of tested Omarchy certification by all three vendors. The standard image discussed here is the x86-64 release path in the official installation guide.

Choose the architecture before the application

Virtualization usually runs a guest with the host’s architecture. Emulation translates a different architecture and has different performance and device limits. An ARM Linux guest able to run an individual x86 application is not the same as booting an entire x86 operating system.

Host and platform	Relationship to the reviewed Intel ISO	Decision
Intel/AMD Windows or Linux, VirtualBox	Same architecture; check supported host version and virtualization availability	Reasonable configuration path to investigate
Intel/AMD Windows or Linux, VMware Workstation	Same architecture; check the vendor’s host requirements	Investigate firmware and virtual graphics separately
Intel Mac, VMware Fusion or Parallels	Same architecture	Use an EFI Linux guest configuration
Apple Silicon, VirtualBox	VirtualBox 7.2 ARM hosts require ARM guests	Cannot use this x86 ISO through ordinary virtualization
Apple Silicon, VMware Fusion	Fusion supports ARM guests, not x86 operating systems	An ARM guest is not this Omarchy installation
Apple Silicon, Parallels Intel emulator	Preview emulation with edition, resource and device restrictions	An experiment, not a dependable daily Omarchy route

These architecture limits are documented by Oracle, Broadcom and Parallels. Read Mac support if deciding between native installation and virtualization.

A deliberate initial VM configuration

First verify the ISO. Create a new, disposable guest with its own virtual disk; do not attach a physical disk containing your host’s data. Choose a 64-bit Linux profile compatible with the image, manual installation where the vendor’s unattended flow does not recognize Omarchy, and UEFI/EFI firmware. Follow the official installation path’s guest Secure Boot requirements inside the VM.

Allocate CPU and RAM with enough left for the host. Choose virtual disk capacity around applications and projects, and check physical free space on the host. This guide does not invent a tested minimum specification. Use NAT networking initially: it reduces dependence on bridge configuration and the network’s treatment of an extra machine.

Keep the initial display setup simple: one virtual monitor, a manageable resolution and the vendor’s Linux guest graphics configuration. Record the selected controller and acceleration setting. If black-screen diagnosis requires changing one of them, shut down first and change one variable, rather than changing RAM, firmware, controller and tools simultaneously.

Inside a VM there are two distinct firmware policies: host firmware controls whether the hypervisor can run; guest firmware controls whether the ISO can boot. An error about a missing host virtualization driver is not fixed by changing the guest desktop.

VirtualBox: establish a bootable guest first

Use the current version’s settings to enable EFI and attach the ISO to the virtual optical drive. Verify that the new virtual disk is the installation target. Oracle’s user guide describes installation and Guest Additions; it does not establish universal Omarchy Wayland integration.

Treat these as separate milestones:

1. Firmware sees the ISO and reaches the installer.
2. Installation completes on the virtual disk.
3. With the ISO detached, the installed disk boots.
4. The desktop can open a terminal and reconnect the network.
5. Optional host integration is tested individually.

If clipboard or automatic resizing fails at stage five, do not reinstall a guest that already passed stages one through four. Check the additions version, relevant guest services and the specific integration’s support for the guest session. A vendor feature list is not a promise that every X11-era integration works identically in Hyprland.

VMware: distinguish tools from graphics drivers

Workstation and Fusion expose different host platforms, so choose a product matching the host before applying a Linux tutorial. Configure the new guest for EFI and the appropriate 64-bit Linux image. Avoid changing the firmware type of an already installed guest as a casual black-screen fix; its existing boot layout may depend on the original firmware.

For Linux guest integration, Broadcom recommends distribution-provided open-vm-tools. The upstream project distinguishes tools from drivers already supplied by Linux and documents desktop integration components. Installing tools does not manufacture working GPU acceleration, and a service running does not prove clipboard or shared folders work in a particular Wayland session.

Start by checking what is already installed rather than installing a legacy Tools archive:

pacman -Q open-vm-tools
systemctl status vmtoolsd.service --no-pager

“Package not found” is an inventory result; “unit not found” is a service result. Follow the current package/vendor instructions for the integration you actually need. Shared folders, clipboard and window resizing should each get their own acceptance test. Do not pass a folder containing your only backup into a disposable guest.

Parallels: Intel Mac and Apple Silicon are different routes

On an Intel Mac, create a Linux VM from the image and inspect its hardware settings before the first boot; use the EFI firmware configuration described in the vendor’s Intel VM guidance.

On Apple Silicon, Parallels documents an early-preview Intel emulator in eligible editions, not ordinary x86 virtualization. The reviewed guidance describes one virtual CPU, an 8 GB maximum, no USB or audio, and Linux Tools problems. Creating new Linux guests is described as unstable; Omarchy is not listed as a verified guest. These limitations make it unsuitable for judging Omarchy’s normal performance or audio/USB support. They also mean older advice saying “Parallels can never run Intel guests on ARM” is too categorical.

If you deliberately experiment, record the exact Parallels version, edition and emulator mode. Stop at an unsupported-device boundary rather than chasing guest configuration changes for a device the emulator does not provide.

Troubleshoot by the first failed milestone

Symptom	Narrow the investigation
Hypervisor refuses to start the VM	Host architecture, host virtualization facilities, driver and vendor host support
“No bootable medium”	ISO attached, optical boot selection, image integrity and guest firmware
Installer cannot see a disk	Virtual disk/controller attachment; do not attach host physical storage as a shortcut
Installed system repeatedly enters installer	Detach ISO and select the installed virtual disk
Black screen after boot	Guest graphics stage, controller/acceleration configuration and logs; retain a working VM copy
Super shortcuts affect the host	Keyboard capture and host shortcuts; use the hypervisor’s release-key instructions
Internet works, clipboard does not	Separate networking from guest-tools/session integration
Disk-full error despite large virtual capacity	Host free space as well as guest free space

Once the installed guest works, take a powered-off VM snapshot or clone before experiments. It captures a different boundary from Omarchy’s system snapshots. Know whether memory is included and where the VM files live. Keep important documents outside the disposable VM, with independent backups. Your support report should include host CPU/OS, hypervisor version, guest image version, EFI setting, graphics controller and first failed milestone.