MacVisor Beta

Cloud images and macOS installers

The signed catalogue of Linux cloud images and macOS installers, how downloads are verified and cached, and what cloud-init sets up in a new VM.

MacVisor ships a catalogue of Linux distribution cloud images and macOS installers. You 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 Templates section of the sidebar and mvz images show the same catalogue.

How the catalogue is verified

  • The catalogue is signed and ships inside MacVisor. It says where each image comes from and how to check it.
  • Every image is downloaded over HTTPS and compared with the vendor's own checksum before it is used. Entries that name a fixed build carry that build's digest in the catalogue. Entries that point at the vendor's "latest" build — Ubuntu, Debian, Rocky Linux, AlmaLinux — are checked against the vendor's checksum list fetched at download time, so a new vendor build is accepted and a corrupted or altered download is refused.
  • macOS installers are Apple's own IPSW restore images from Apple's CDN, checked against their SHA-256. A local .ipsw you add is validated as a restore image for virtual Macs before it joins the list.

A download that fails verification is discarded and the task says so. Nothing is installed from an unverified file.

Linux images

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

ImageId (aliases)SourceBuild
Ubuntu 26.04 LTSubuntu-26.04 (ubuntu, ubuntu-lts)cloud-images.ubuntu.comTracks the vendor's newest build
Ubuntu 24.04 LTSubuntu-24.04cloud-images.ubuntu.comTracks the vendor's newest build
Debian 13 (trixie)debian-13 (debian)cloud.debian.orgTracks the vendor's newest build
Debian 12 (bookworm)debian-12cloud.debian.orgTracks the vendor's newest build
Fedora 44fedora-44 (fedora)download.fedoraproject.orgFixed build, 44-1.7
Fedora 43fedora-43download.fedoraproject.orgFixed build, 43-1.6
Rocky Linux 10rocky-10 (rocky)dl.rockylinux.orgTracks the vendor's newest build
Rocky Linux 9rocky-9dl.rockylinux.orgTracks the vendor's newest build
AlmaLinux 10almalinux-10 (alma, almalinux)repo.almalinux.orgTracks the vendor's newest build
AlmaLinux 9almalinux-9repo.almalinux.orgTracks the vendor's newest build
Oracle Linux 10oraclelinux-10 (oracle, oraclelinux)yum.oracle.comFixed build, 10 Update 1
Oracle Linux 9oraclelinux-9yum.oracle.comFixed build, 9 Update 8
CentOS Stream 10centos-stream-10 (centos, centos-stream)cloud.centos.orgFixed build, 20260930.0
openSUSE Leap 16.0opensuse-leap-16.0 (opensuse, leap)download.opensuse.orgFixed build, 18.72
Alpine Linux 3.24.1alpine-3.24 (alpine)dl-cdn.alpinelinux.orgFixed 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 — MacVisor virtualises ARM64 only.

macOS installers

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

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 the Templates folder of the storage location. Every VM made from it is a linked clone of that template, so it stores only its own changes and a second VM from the same image costs nothing to create.
  • create reuses the template it finds. images pull fetches a newer build when the vendor has one (the "tracks" entries) and otherwise leaves the template alone. VMs already made from the earlier template keep reading it.
  • images add <file> takes files you already have: a qcow2, raw, or .xz disk image becomes a template; an .ipsw joins the installers after a check that it is a macOS restore image. In the app, the + button next to the Templates search does the same, and dropping a file onto the Templates list works too.
  • images rm moves a template to the Trash; it is refused while VMs are made from it. Given a downloaded installer's id, it trashes the IPSW.
  • The New VM form offers the same catalogue: choose Linux → Cloud Image or macOS, pick an entry, and anything not yet downloaded is fetched when you click Create.

Where things live

PathWhat
<storage location>/Templates/Cloud-image templates, beside templates you converted from VMs
<storage location>/Templates/Downloads/<file>.partialA download in progress, or one that was interrupted
~/Library/Application Support/MacVisor/InstallersDownloaded macOS installers (IPSW), with their own Downloads folder
~/Library/Application Support/MacVisor/RuntimeCacheContainer runtime payloads shared with new VMs

Of each macOS version only the newest build is kept: when a newer 27.x arrives, the older 27.x IPSW goes. The Templates section lists installers alongside templates.

Downloads: resume and cancel

A download is a task. The task pane shows its size, speed, and time remaining, and hovering it shows the URL. Downloads survive interruptions, cancellation — mvz tasks cancel <task-id>, or the task's cancel button — and MacVisor restarts: the partial file stays in the Downloads folder, visible on purpose, and the next create or images pull of the same image carries on from where it stopped. A partial download nobody returns to is removed after two weeks.

What cloud-init sets up

On its first boot a VM made from a cloud image is configured by cloud-init with what MacVisor rendered for it:

  • 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 the keys you name with --ssh-key, or none with --no-ssh-keys. The VM's host key is pinned under ~/.macvisor/ssh/.
  • The MacVisor agent, unless --no-agent.
  • A container runtime — containerd with nerdctl by default, or Docker, Podman, k3s, or 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 — your home folder, read-only, at the same path as on the Mac (--no-home to skip), and optionally a project folder read-write, also at the same path (--project <dir>).
  • 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 automatically to 127.0.0.1 on the Mac (--no-forward to skip), and 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.

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

Signing in

GuestAccountHow
Linux from a cloud imageYour Mac user name, with your SSH keysmvz shell <vm>
macOS 27 and later with automatic setupmac, password macvisor — or the account you chose in the form or with --usermvz shell <vm>, once Remote Login is on (--ssh)
macOS 26 and earlierWhatever you set up in Setup AssistantThe VM window; shell after you turn on Remote Login yourself

On a macOS 27 guest made with automatic setup and Remote Login, MacVisor installs the MacVisor Agent itself after the first boot — over SSH, with the account's password — and authorises your SSH keys at the same time, so mvz shell does not ask for a password. Connect before that has finished and it asks for the password once. That setup runs from the VM runner across the local network, so it needs the Local Network permission granted during first-run setup — without it the guest boots normally but the agent is not installed and your keys are not authorised. The New VM form remembers the last account name and password you used. The default password is public; change it inside any guest other people can reach.

Names

<vm>.macvisor resolves on the Mac to the VM's address: ssh dev.macvisor after mvz ssh-config --install, curl http://dev.macvisor:8080. The admin helper installs /etc/resolver/macvisor, and the service answers those lookups. Inside the guest, 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.