MacVisor GA

Updates and moving to a new Mac

How MacVisor updates, what to do with suspended VMs first, updating a Mac you reach only over SSH, moving from a beta to the general release, and moving MacVisor, your VMs and your license to a new Mac.

How updates arrive

MacVisor updates itself through Sparkle. Settings → Updates controls it:

  • By default MacVisor checks once a day and asks before installing an update. Install and Relaunch installs it.
  • With Download and install updates automatically on, it downloads updates in the background and installs them when you quit.
  • MacVisor → Check for Updates… checks now.

Every update is signed and verified against MacVisor's signing key before it installs. Each MacVisor 27 license includes every MacVisor 27.x update. See Pricing and licensing.

If you installed MacVisor with Homebrew, Sparkle still updates it. To update through Homebrew instead, run brew upgrade --cask --greedy macvisor: MacVisor updates itself, so brew upgrade on its own leaves it alone.

Before you update: shut VMs down, don't suspend them

An update doesn't stop running VMs. Each keeps running on the runner it started with until you shut it down.

A suspended VM, or a live snapshot taken before the update, may not restore after it: saved memory restores only on the virtual hardware it was saved with, and an update can change that hardware. The disk is never affected. Such a VM starts from its disk instead, as after a power cut, and a live snapshot's disk still restores.

So before you update, shut down the VMs you have suspended: resume each and shut it down, or keep its session and accept that it may start from disk. When you choose Install and Relaunch with VMs suspended, MacVisor names them and asks first. Running VMs can stay running.

This holds for every update: a session saved by one version isn't promised to restore in the next. The same goes for a macOS update on the Mac: saved memory only restores on the macOS release that saved it. See When a saved session won't restore.

After an update

  • The background service restarts on the new version by itself when the app relaunches. If mvz service status says it still runs an older build, run mvz service restart. Work in progress finishes first, and running VMs keep running.
  • VMs started before the update keep their old runner until they shut down. If an action says a VM "can't do this yet", shut it down and start it again.
  • Custom networks. An update's network changes finish once every VM on a custom network has been stopped and started again. Until then, MacVisor's network process from before the update keeps serving them, and every VM you start meanwhile. So stop them all first, then start them: restarting them one at a time keeps the old process. A VM whose network has to be made afresh meanwhile won't start, and its error says this. The dashboard's Background Service panel and mvz service status say so too, and name the VMs on custom networks that are still running.
  • The guest agent updates itself in Linux and Windows guests, and in macOS guests MacVisor set up. The Overview shows Update Agent for any other. See Guest tools.
  • Background items. If macOS asks to approve MacVisor's background items again after an update, MacVisor tries to register them again by itself on its first launch. If macOS still asks, switch MacVisor on in System Settings → General → Login Items & Extensions, and the Setup Assistant offers Register Again. While the helper that holds the license doesn't answer, a Mac it licensed stays licensed for up to three days after its last answer, and Settings → License says until when.

Updating a Mac you reach only over SSH

Sparkle runs in the app, so a headless Mac updates in one of three ways:

  • With Homebrew: brew upgrade --cask --greedy macvisor, then mvz service restart.
  • By hand: quit the app if it's open (osascript -e 'quit app "MacVisor"'), replace /Applications/MacVisor.app with the new version from the download page, keeping the same location, then run mvz service restart. The mvz links follow the app, so they need nothing.
  • Over Screen Sharing: open MacVisor and use Check for Updates….

Then check:

mvz version            # the CLI's version, from the new app
mvz service status     # the service's build, and anything still waiting
mvz license            # the license, checked again after an update

Shut suspended VMs down first, as above: restoring a saved session also needs the Mac's screen unlocked, which it rarely is on a headless Mac. If macOS wants MacVisor's background items approved again, someone has to do it at the Mac or over Screen Sharing.

From a beta to the general release

Updating from a public beta keeps your VMs, templates, networks and settings. What else changes:

  • Licenses. Activations made through Polar in the early betas moved to ScaleNinja's licensing server by themselves. A beta's free-trial key doesn't carry over: the Mac gets its free trial instead. Licenses bought during the beta keep everything they were sold with. See If you activated during the beta.
  • Saved sessions. Shut VMs down before you update, as above.
  • macOS VMs made before beta 6 use the password macvisor, not a random one. Change it in any VM other people can reach.
  • macOS VMs set up before 27.0.0 beta 4 lack the file that lets MacVisor shut them down over SSH when the agent isn't connected. See Run and control VMs.
  • Windows VMs made in a beta use the automatic pixel density, unless you chose a density for them, and keep Windows' visual effects as they are until you turn on Reduce Visual Effects. See Windows 11 guests.

Moving to a new Mac

Your VMs are ordinary files, so moving is copying them, setting up what lives outside them again, and moving the license.

  1. On the old Mac, shut every VM down. A suspended session doesn't move.
  2. Move the license. Click Deactivate on This Mac… in Settings → License, or run mvz license deactivate. Then activate the key on the new Mac. If the old Mac is gone, activate on the new one and choose Move to This Mac. See Moving a license to another Mac.
  3. Copy the storage locations. Copy each location's folder (~/VMs by default) to the new Mac, with its Templates folder: VMs made from cloud images, and other linked clones, read their disks from the templates and VMs they were made from. On the new Mac, put the folder at ~/VMs, or add it as a storage location. An external drive can move as it is. ASIF disks stay sparse when copied.
  4. Recreate your custom networks on the new Mac, with the same names, before you start the VMs: networks belong to the Mac, not to the VMs. A VM whose network is missing joins the Default MacVisor Network instead. Add reservations and firewall rules again. See Custom networks.
  5. Bring your SSH keys (~/.ssh), which your Linux VMs authorise, and ~/.macvisor, which holds MacVisor's own SSH key: VMs made without a key of yours, macOS guests whose agent MacVisor updates, and FreeBSD VMs use it.

The first time the new Mac sees each VM, it resets the settings that point outside the VM, as for an import: shared folders and external disk images are removed, captured USB devices are cleared, Start at Login and High Availability are turned off, and port forwards listen on 127.0.0.1 only. It does this once: set them again where you need them, and they stay. See Importing a package.

To move only a few VMs, use Export… on the old Mac, then double-click the exported package on the new one and choose Import, or use mvz export and mvz import. An imported VM gets a new identity: a new id, MAC addresses and machine identifier, so its addresses change. Linked clones, including every VM made from a cloud image, can't be exported until you flatten them with mvz flatten <vm>.

What stays behind on the old Mac, and what each file holds, is in What is stored where.