Docs · Reference

The VM bundle

A machine is a folder. What is inside it, what is safe to copy, and what to commit.

A 1VMTool machine is not a database row or an opaque blob — it is a directory with a .vm extension that you can inspect, copy and move.

dev.vm/
  config.json         the definition — commit it
  disk.asif           primary disk, sparse
  snapshots/
    index.json
    a1c2/disk.asif

Machines live in a library folder in your home directory by default. Point ONEVM_HOME somewhere else — an external SSD, say — and the whole library moves with it.

config.json

The machine's definition: guest type, engine, CPU, memory, disk, network, shared folders, input and graphics settings. It is plain JSON and it is the file to commit if you want a machine definition in version control alongside the project it serves.

1vm config dev          # print it
1vm get dev             # list every dotted key

Because the definition is separate from the disk, sharing a machine's shape with a colleague costs a few kilobytes. They run 1vm create against it and install their own guest.

The disk

Sparse, so it grows as the guest writes rather than being allocated up front — a 256 GiB disk on a machine that has written 9 GiB occupies about 9 GiB. The file name differs per engine because the two use different disk formats; 1vm du reports the honest numbers across the library.

Snapshots

snapshots/ holds the tree. Each snapshot is an APFS clone that shares blocks with the live disk until one of them diverges, which is why a fresh snapshot adds almost nothing and why du distinguishes allocated from on disk from reclaimable.

Copying a machine

Because it is a folder, copying it works — but prefer 1vm clone, which uses the same clone primitive and finishes instantly rather than duplicating bytes:

1vm clone dev test              # linked, shares blocks
1vm clone dev test --full       # independent copy
1vm archive dev                 # compress a stopped machine; run again to restore

Do not edit a running machine's files

Settings changes go through 1vm set, which validates them and applies them live where the engine supports it. Editing config.json under a running machine is the one way to get the host and guest to disagree about what the machine is.