Guide

Migrating a Linux VM to Velo Workspaces From UTM, Fusion, or Parallels

Apple's Virtualization.framework — what Velo Workspaces is built on — only attaches raw disk images. Every other hypervisor uses its own container format. Here's the actual conversion path, with the one command that matters and the mistakes that waste an hour if you don't know about them first.

By Gaoliang Luo · Published September 23, 2026

The constraint this whole guide is about

VZDiskImageStorageDeviceAttachment — the API Velo Workspaces and every other Virtualization.framework app use to attach a disk to a VM — reads raw disk images and nothing else. No QCOW2, no VMDK, no VHD or VHDX. Velo's own New Workspace Wizard will let you pick a file in any of those formats, detect what it actually is by reading its header rather than trusting the file extension, and tell you plainly what to do about it:

"This is a [format] disk image, which Apple's Virtualization framework cannot read — it attaches raw images only. Convert it first with: qemu-img convert -O raw source destination.img"

This guide is that command, expanded per source hypervisor, with the file-location and format details each one needs to actually work on the first try.

Scope: Linux guests only

This covers migrating a Linux VM. Velo Workspaces doesn't run Windows guests currently — see why, and where to go instead if that's what you're migrating. macOS guests aren't covered by this either, since UTM, VMware Fusion, and Parallels each handle a macOS guest's disk differently from a Linux one's plain filesystem.

Before you start: install qemu-img

All three conversions below use QEMU's own qemu-img tool — the reference implementation for every one of these formats, which is exactly why the app's own error message points at it rather than at a bundled converter. Install it via Homebrew:

brew install qemu

qemu-img ships as part of the qemu formula; there's no separate package for it. Confirm it installed with qemu-img --version.

One more thing worth knowing before you run a conversion: a raw image is the disk's full allocated size written out sector-for-sector, not the compressed size the source format may have been using. Make sure you have free disk space at least equal to the guest's configured disk size before converting — a 64 GB QCOW2 that's only 8 GB on disk today still produces a 64 GB raw file.

From UTM

UTM's QEMU backend stores a Linux VM's disk as QCOW2. Right-click the .utm file in Finder, choose Show Package Contents, and look inside the Data/ folder for a .qcow2 file (if UTM was installed from the Mac App Store, the bundle itself lives under UTM's own sandboxed container rather than wherever you see it in Finder — Show Package Contents finds it either way).

qemu-img convert -f qcow2 -O raw "/path/to/VMName.utm/Data/disk.qcow2" destination.img

From VMware Fusion

Right-click the .vmwarevm bundle, Show Package Contents, and look for a .vmdk file. This is the one place to slow down: VMware sometimes stores a disk as one monolithic .vmdk, and sometimes as a small text-based descriptor file (a few KB) plus separate data files named like diskname-s001.vmdk, diskname-s002.vmdk, and so on. Always point qemu-img at the descriptor file — the small one, often just the plain diskname.vmdk — never at the numbered extent files directly. The descriptor references all the extents internally, and qemu-img follows those references and produces one complete raw file; pointing it at an extent file directly gives you a truncated, unusable image.

qemu-img convert -f vmdk -O raw "/path/to/VMName.vmwarevm/Virtual Disk.vmdk" destination.img

From Parallels Desktop

Parallels' bundle structure nests one level deeper: a .pvm bundle contains a .hdd package, which contains the actual data file, named something like disk-0.hdd.0.{uuid}.hds. Show Package Contents on the .pvm, then again on the .hdd inside it, to find the .hds file.

qemu-img convert -f parallels "/path/to/VMName.pvm/disk.hdd/disk-0.hdd.0.{uuid}.hds" -O raw destination.img

Honest caveat: QEMU's Parallels-format reader is less battle-tested than its QCOW2 or VMDK support — it's mostly documented in forensics and disk-recovery contexts rather than routine VM migration. If the conversion above errors or produces something that won't boot, convert the disk to Parallels' own "Plain" (uncompressed, fixed-size) format first with Parallels' own prl_disk_tool convert --hdd /path/to/disk.hdd --plain, then retry the qemu-img command against the resulting file.

Importing the converted image into Velo Workspaces

With a .img file in hand, create a new workspace in Velo Workspaces and choose it as the disk image when the wizard asks — the same import path the app's own error message above is guiding you toward in the first place. What comes across is the disk's actual contents: your installed packages, your files, your configuration. What doesn't: hypervisor-specific settings like shared folders, snapshots, or custom device configuration from UTM, Fusion, or Parallels — those live in each app's own VM definition, not on the disk itself, so they need to be reconfigured in Velo Workspaces directly.

One thing that usually doesn't need manual fixing: Linux mounts its filesystems by UUID, not by device path, so a guest built under QEMU's virtio devices generally boots fine under Apple's own virtio-based storage and network devices without editing /etc/fstab. If it doesn't come up cleanly on first boot, check the serial console output before assuming the disk conversion itself failed — it's more often a display or boot-loader question than a filesystem one.

Related reading: what a VM on Apple Silicon actually is, the full comparison against Parallels and UTM, and the real device inventory behind the VM you're migrating into. Or download Velo Workspaces and try it yourself.