Cloud images and macOS installers

MacVisor ships a catalogue of Linux cloud images and macOS installers. Name one (ubuntu, debian-13, macos-27) and MacVisor downloads it once, verifies it, and keeps it for every VM you make from it. The sidebar's Templates section and mvz images show the same catalogue.

How the catalogue is verified

• The catalogue is signed and ships inside MacVisor. It names each image's source and how to check it.
• Every download is HTTPS and compared with the vendor's checksum before use. Fixed-build entries carry the digest in the catalogue; entries that track the vendor's newest build (Ubuntu, Debian, Rocky Linux, AlmaLinux) are checked against the vendor's checksum list fetched at download time.
• macOS installers are Apple's own IPSWs from Apple's CDN, checked against their SHA-256. A local .ipsw you add is validated as a restore image for virtual Macs first.

A download that fails verification is discarded, and the task says so.

Linux images

All images are ARM64. Use the id or an alias with mvz create and mvz images pull.

Image	Id (aliases)	Source	Build
Ubuntu 26.04 LTS	ubuntu-26.04 (ubuntu, ubuntu-lts)	cloud-images.ubuntu.com	Tracks the vendor's newest build
Ubuntu 24.04 LTS	ubuntu-24.04	cloud-images.ubuntu.com	Tracks the vendor's newest build
Debian 13 (trixie)	debian-13 (debian)	cloud.debian.org	Tracks the vendor's newest build
Debian 12 (bookworm)	debian-12	cloud.debian.org	Tracks the vendor's newest build
Fedora 44	fedora-44 (fedora)	download.fedoraproject.org	Fixed build, 44-1.7
Fedora 43	fedora-43	download.fedoraproject.org	Fixed build, 43-1.6
Rocky Linux 10	rocky-10 (rocky)	dl.rockylinux.org	Tracks the vendor's newest build
Rocky Linux 9	rocky-9	dl.rockylinux.org	Tracks the vendor's newest build
AlmaLinux 10	almalinux-10 (alma, almalinux)	repo.almalinux.org	Tracks the vendor's newest build
AlmaLinux 9	almalinux-9	repo.almalinux.org	Tracks the vendor's newest build
Oracle Linux 10	oraclelinux-10 (oracle, oraclelinux)	yum.oracle.com	Fixed build, 10 Update 1
Oracle Linux 9	oraclelinux-9	yum.oracle.com	Fixed build, 9 Update 8
CentOS Stream 10	centos-stream-10 (centos, centos-stream)	cloud.centos.org	Fixed build, 20260930.0
openSUSE Leap 16.0	opensuse-leap-16.0 (opensuse, leap)	download.opensuse.org	Fixed build, 18.72
Alpine Linux 3.24.1	alpine-3.24 (alpine)	dl-cdn.alpinelinux.org	Fixed build, 3.24.1

Fixed-build entries move forward when the catalogue is updated; "tracks" entries follow the vendor. x86 images are not offered and would not boot.

macOS installers

Installer	Id (aliases)	Source
macOS Golden Gate 27.0.1	macos-27 (macos)	Apple
macOS Tahoe 26.6.2	macos-26	Apple
macOS Sequoia 15.6.1	macos-15	Apple
macOS Sonoma 14.6.1	macos-14	Apple
The newest macOS this Mac supports	macos-latest	Apple is asked which build that is, and it is downloaded from the same CDN

Distribution and Apple logos are trademarks of their respective owners.

Automatic first-boot setup (account, automatic login, Remote Login, agent install) needs a macOS 27 guest. Older guests install the same way but go through Setup Assistant by hand; see Create VMs and templates.

create, pull and add

mvz create ubuntu dev              # downloads the image the first time, then makes the VM
mvz images pull debian-13          # fetch ahead of first use
mvz images pull macos-26           # a macOS installer, for later VMs
mvz images add ~/Downloads/custom.qcow2
mvz images add ~/Downloads/UniversalMac_26.6.2_25G83_Restore.ipsw
mvz images rm "Fedora 43"
mvz images rm macos-26             # trashes the IPSW

• A Linux image becomes a template the first time it is used: downloaded, verified, converted to ASIF, and placed in <location>/Templates. Every VM made from it is a linked clone, so it stores only its own changes.
• create reuses the template it has. images pull fetches a newer build for the "tracks" entries and otherwise leaves the template alone; VMs made from the earlier template keep reading it.
• images add <file> takes files you already have: a qcow2, raw, or .xz image becomes a template; an .ipsw joins the installers after validation. In the app, the + button next to the Templates search does the same, as does dropping a file on the list.
• images rm trashes a template, and is refused while VMs are made from it. Given an installer's id, it trashes the IPSW.
• The New VM form offers the same catalogue; anything not yet downloaded is fetched when you click Create.

Where things live

An installer you download from the Templates list or with mvz images pull, or add with mvz images add or the + button, stays until you remove it. One fetched along the way to create a VM gives way to a newer build: when a newer 27.x arrives, the older 27.x IPSW goes to the Trash.

Downloads: resume and cancel

A download is a task with size, speed, and time remaining; hover it for the URL. Interrupted, cancelled (mvz tasks cancel <task-id> or the pane's button), or cut off by a MacVisor restart, it keeps its partial file in the Downloads folder and carries on at the next create or images pull of the same image. One cut off by a restart of the background service also picks up again by itself; one you cancelled stays stopped. A partial nobody returns to is removed after two weeks.

A download that won't fit in the free space is refused before it starts, with how much to free. One that fills the volume anyway stops and keeps what it got, and carries on from there once you have made room and pull again.

What cloud-init sets up

On its first boot, a VM made from a cloud image gets:

• Your account: the same user name and UID as on the Mac, so files in shared folders belong to you on both sides.
• Your SSH keys: every public key in ~/.ssh and your SSH agents, or those you name with --ssh-key, or none with --no-ssh-keys. The account has no password, so a key is the only way in. With no key at all, mvz create offers to make ~/.ssh/id_ed25519, and the New VM form has Create SSH Key; without one, MacVisor's own key (~/.macvisor/ssh/id_ed25519) is authorised, which mvz shell and exec use but plain ssh doesn't. The VM's host key is pinned under ~/.macvisor/ssh/.
• The MacVisor agent, unless --no-agent.
• A container runtime, if you choose one (--runtime <name>, or Containers in the New VM form): containerd with nerdctl, Docker, Podman, or k3s (a pinned release, v1.36.5+k3s1, whose installer is checked against a known checksum). The default is none. Docker and Podman VMs get a docker context on the Mac; a k3s VM's API server is forwarded to 127.0.0.1:6443 (mvz kubeconfig <vm> --save).
• Shared folders, if you ask for them: your home folder read-only at the same path (--home, or Share my home folder (read-only) in the form), and a project folder read-write, also at the same path (--project <dir>). The default is none.
• Rosetta, when it is installed on the Mac, so x86-64 Linux programs run.
• Networking: DHCP on every adapter, the TCP and UDP ports the guest listens on forwarded to 127.0.0.1 on the Mac (--no-forward to skip), and host.mvz.internal (or host.macvisor.internal) for the Mac. The VM joins the Default MacVisor Network unless --network says otherwise.
• Your own #cloud-config or script, applied after MacVisor's, from --user-data <file> or the New VM form.

The New VM form starts with no runtime and the home folder not shared. After that it remembers the runtime and home-folder choice you made last, for the next Linux VM. mvz create never remembers: give --runtime and --home every time.

mvz wait <vm> returns when cloud-init has finished; mvz shell <vm> connects as soon as SSH answers, even before that. Growing the disk with mvz set <vm> --disk <GiB> grows the filesystem at the next boot.

Runtimes by distribution

Every image was run through each runtime in October 2026. Every runtime works on every catalogue image except those below; the New VM form leaves them out, and mvz create refuses them with a message listing the runtimes the image offers.

On both Oracle Linux releases the UEK kernel has no virtiofs, so shared folders are not available: the New VM form says so and the VM is made without them. First boots take 5 to 10 minutes on Oracle's mirrors.

Ubuntu 26.04 and Debian 13 get passt for rootless Podman networking. Give k3s VMs 4 GiB or more and keep balloon targets above half the configured memory: a 3 GiB k3s guest ballooned to 1 GiB stops answering.

Signing in

On a macOS 27 guest with automatic setup and Remote Login, MacVisor installs the agent itself after the first boot, over SSH with the account's password, and authorises your SSH keys, so mvz shell asks for no password. Connect before that has finished and it asks once. Once the agent is in, MacVisor turns SSH password logins off, so the guest takes keys only, as cloud-image Linux VMs always do. This runs from the VM runner over the local network, so it needs the Local Network permission from first-run setup; without it the guest boots normally but the agent and your keys are not installed. The default password is public: change it inside any guest other people can reach.

Names

<vm>.mvz resolves on the Mac to the VM's address: ssh dev.mvz after mvz ssh-config --install, or curl http://dev.mvz:8080. <vm>.macvisor works too. The admin helper installs /etc/resolver/mvz and /etc/resolver/macvisor, and the service answers the lookups. Inside the guest, host.mvz.internal (and host.macvisor.internal) is the Mac. While a Docker or Podman VM runs, its Docker API is forwarded to ~/.macvisor/run/<id>.docker.sock through the agent: docker --context macvisor-<vm> ps.