Linked clones - MacVisor Docs

A linked clone forks a VM without copying its disk. The source's disk becomes an immutable base both VMs read, and each writes to its own ASIF layer on top. Creating one is instant and costs no disk space, whether the source disk is 60 GB or 600 GB.

The sealed base disk at the bottom, with the source VM's and each linked clone's writable overlay stacked on top of it; writes land in the overlay and reads fall through to the base.

It is the cheap way to get ten copies of a prepared guest for a test matrix, a review environment per branch, or a fleet of CI workers from one golden image. It is also how every VM made from a cloud image works: the downloaded image is the base, kept as a template, and each VM is a linked clone of it.

Create one

Right-click a stopped VM and choose Linked Clone…, or run mvz clone <vm> <name> --linked. The source must:

have an ASIF boot disk; convert a raw disk first (see Storage and sharing);
be stopped, because sealing rewrites what the VM writes through;
have no suspended session, because saved memory refers to the unsealed disk.

A clone can itself be cloned, to any depth.

What sealing changes for the source

Forking rewrites the source too: its disk becomes a read-only base and it gets a fresh layer of its own. The guest notices nothing, but the VM is no longer one self-contained disk file.

Operation	VM that has been forked from	Linked clone
Start, stop, suspend, snapshot	Yes	Yes
Resize the boot disk	Grow only	Grow only
Clone (full copy)	Yes	No
Convert to a template	Yes	No
Export the bundle	Yes	No; `mvz flatten` first
Create a VM from one of its snapshots	No; revert, then clone	No
Delete the VM	After its clones are deleted	Yes
Revert to a snapshot	After its clones are deleted	Yes

MacVisor refuses each of these by name rather than produce a template or export that only works while its ancestor happens to be present.

Deleting in the right order

The base lives in the source's bundle. Deleting or reverting it while a clone reads through it would leave the clone unbootable, so MacVisor refuses and names the dependants. Delete the clones first.

Getting the layer back

Delete the last clone and the source gets its layer back for free: nothing else reads it, so the fork is undone. That needs the source not to have run since the fork and to have no snapshots taken while it was forked, since those read through the layer too. When clones have come and gone in other combinations, a VM can be left with layers nothing reads; its Overview says how much space they hold, with Flatten Disk to merge them. mvz flatten <vm> does the same for a stopped VM with no snapshots, and is also what makes a linked clone exportable.

A clone in the Trash doesn't count as reading the layer. Once its source has the layer back, or has written to that disk since, a clone you put back from the Trash won't start, and importing it is refused: it would read through a disk that is no longer the one it was made on, and MacVisor says so. Copy what you need out of a linked clone before you delete it.

Linked clones, full clones, and templates

	Linked clone	Full clone	Template
Disk cost	None; it shares the base	A copy of the disk	A copy per VM created
Speed	Instant	As fast as the disk copies	As fast as the disk copies
Independent of its source	No	Yes	Yes
Can be exported or moved alone	No	Yes	Yes
Best for	Many short-lived VMs from one base	A VM you want to keep and move	A catalogue entry you stamp copies from

Use a template when the copies should outlive or travel away from the original. Use linked clones when you want many at once and can delete them in order.

From the command line: mvz clone <vm> <name> is a full copy, --linked a linked clone, --snapshot <id> a copy of the VM as it was then; mvz flatten <vm> makes a layered disk self-contained again.