Renaming and copying

msl rename <instance> <new name>
msl clone  <instance> <new name>

Rename moves everything: the disk, accounts, files, resource settings, sandbox gates, per-app graphics and launch commands, port forwards, the lot. Clone makes a second instance from the first — its disk is an instant copy, so it costs almost nothing until the two start to differ.

Both need the instance stopped#

Copying a filesystem while something is writing to it captures it mid-write, which is the same corruption as two instances sharing one disk. So both refuse a running instance and say so.

Renaming cannot carry saved memory#

A rename is refused while an instance has hibernated memory or a snapshot, and the reason is worth knowing: a guest's network address is derived from its name, and macOS will not restore a saved virtual machine whose address has changed. Renaming anyway would produce an unhelpful error on the next start, so MSL asks you to start it once — which uses the saved state up — and delete any snapshots first.

A clone is unaffected: the original keeps its name, and the copy starts cold.

What a clone keeps, and what it does not#

The copy keeps the original's SSH host key until the guest makes a new one, so msl ssh may warn about a changed key the first time.

Launchpad and the Dock#

Renaming removes the instance's generated app shortcuts and Dock pins rather than rewriting them. A generated app launches an instance by name, so one left pointing at a name that no longer exists would quietly bring that instance back as an empty new one. Open the Applications tab after a rename and they are scanned again.

Under a policy#

Rules are written about instance names, so renaming or cloning out of a rule would be a way around it. MSL refuses that, and names the capability:

ERROR refused by MSL Admin Portal: instance.delete is denied for 'Ubuntu'
but not for 'Ubuntu2', so this would be a way around it

Moving into a more restricted name is fine — that takes things away, not back.