Your first VM

You have a node that booted and answered hoster host info. This is the shortest path from there to a machine you can log into.

Four commands, and one of them is optional. Everything here is the CLI on the host; the same operations exist in Control Center, and neither is the second-class path.

1 · Find a template

Guests are clones of a template dataset, so a template has to exist before anything can be deployed from it. See what the image repository publishes:

hoster vm template list-online

The build definitions for these images are open — you can read exactly how any of them was produced before you run it. The Downloads page lists the same catalogue with direct archive links.

2 · Pull it

hoster vm template pull almalinux9

That resolves the image, downloads it, and extracts it into a template-almalinux9 dataset on your first VM dataset. It is one command doing the whole job — if you have seen a two-step … | bash version of this, that is the older flow.

Flags worth knowing:

A template is nothing more than a dataset named template-<something> containing a raw disk0.img. Bring your own by converting an image to raw, dropping it into a dataset named that way, and deploying with --os-template <something> — see Building your own template for what the image has to support, and for publishing a catalogue of your own.

3 · Deploy

hoster vm deploy --os-template almalinux9 --name my-first-vm --start-when-ready

This is the part that is worth watching the clock on. The deploy is a ZFS clone, not a copy, so it returns in well under a second and the time does not grow with the size of the image. --start-when-ready boots it as soon as it is built; without it, deploy and start are separate steps.

Add --debug-timings to see where the time actually went:

hoster vm deploy --os-template almalinux9 --name timing-test --debug-timings

Sizing it

The defaults are deliberately small — 2 CPU cores and 2G of RAM — because the common case is a machine you are about to throw away. Size it at deploy time:

hoster vm deploy --os-template almalinux9 --name build-runner \
  --cpu-cores 8 --ram 16G --os-disk-size 200G --production

The address is chosen for you

You do not pick an IP unless you want to. The node assigns the next free address from the internal network’s range — the one set on installer screen 10 — and its DNS knows the guest by name from that point on.

4 · Get inside it

hoster vm list
hoster vm info my-first-vm
hoster vm console my-first-vm

console attaches to the guest’s serial console, which is the honest way in: it works before networking does, so it is also how you debug a guest that did not come up.

For SSH, the templates are cloud-init configured and the installer put the host’s own public key (/root/.ssh/id_ed25519.pub) into the host configuration, so it is injected into guests as they are built. From the node, the guest is reachable by name.

If cloud-init needs to run again — you changed the key, or the guest was cloned from something that had already been seeded — hoster vm ci-reset my-first-vm regenerates it.

Taking a snapshot before you break something

Snapshots are instant and cost only the blocks that change afterwards, which is what makes them worth taking casually:

hoster vm snapshot create my-first-vm --type custom --keep 10
hoster vm snapshot list my-first-vm

--type is one of custom, frequent, hourly, daily, weekly or monthly, and --keep is how many of that type to retain when the new one is made. The scheduler uses the same types, so a snapshot you take by hand and one taken on a schedule are the same kind of object with the same retention rules — which also means a hand-taken daily will be pruned by the daily job. See Snapshots, replication and the scheduler to put this on a timer, and note that a fresh node has none set up.

To roll back, clone a snapshot into a new guest rather than mutating the original:

hoster vm snapshot list my-first-vm
hoster vm clone <snapshot-name> recovered-vm

Stopping and removing

hoster vm stop my-first-vm
hoster vm destroy my-first-vm

stop asks the guest to shut down. --force sends quit to the QEMU monitor and --kill terminates the process outright — reach for those in that order, and only when the guest is not listening.

destroy removes the guest and its dataset. That is the point at which the sub-second deploy stops being a party trick and starts changing how you work: a machine you can rebuild in a second is a machine you are willing to delete.

Next

• MicroVMs — the same lifecycle for container workloads, with a real kernel boundary instead of a shared one.
• Changing a guest after deploy — resizing the disk, sharing a folder in, re-addressing it, and which of the choices above you cannot revisit.
• Snapshots, replication and the scheduler — making the snapshots automatic, and getting a copy off the machine.
• Getting into a guest — the console, the generated credentials, and why SSH is the second thing to try.
• Why Hoster — what clustering adds once one guest is not the whole story.