Images and templates

A classic VM boots from a cloud image: a prepared Linux disk image with cloud-init inside. Virtainer Free keeps a local cache of those images and copies from the cache every time you create a VM.

VM images

The VM images page under Compute lists what this host has cached, grouped as a tree: distribution, then release, then the individual builds.

Only the distribution level is expanded by default. A release row stays folded but still carries its own counts, so you can see how many builds it has, how many are on disk, and how much space they take without opening it.

Opening a release row shows the newest build on that line together with every copy this host already holds. Builds that are neither the newest nor present locally are collected behind +N older builds, so what you have is never hidden from you.

Only local copies can be deleted

A group with nothing cached has its selection checkbox disabled, because there is nothing there to remove. A checkbox that did nothing when clicked would read as a broken control rather than an empty group.

There are two ways to add an image:

• From the image catalog. Browse the published Linux cloud images and pull the one you want. The host downloads it once and verifies its checksum.
• From a URL or an upload. Point the host at a qcow2 image you already have.

Once an image is cached, creating a VM from it does not touch the network.

Watching a download

Downloads happen on the host, not in your browser, so the page reports on them directly. Start a URL import and the dialog closes: the transfer moves to the list as its own row, with a progress bar, the current rate, and an estimate of the time remaining. When it finishes, the real image row replaces it.

The rate is the number worth watching. It is what tells a slow mirror apart from a stalled one. If the server does not report a total size, you get bytes downloaded and the rate without an invented percentage.

Images are copied, never shared

Creating a VM makes a full private copy of the cached image. There is no chain back to the original, so the cached image is never modified, and deleting a cached image cannot damage a VM that was built from it.

Each VM’s disk is a full copy, so plan pool capacity by the number of VMs, not by the number of distinct images.

Templates

A template is a saved set of create-form settings: the first-boot configuration, the shape of the machine, and the options you would otherwise retype. One Templates page under Compute holds templates for both classic VMs and AppVMs.

1. Open Templates under Compute and create one.
2. Fill in the settings you want to reuse.
3. Pick that template when you create a machine, and adjust anything per machine.

A template is applied at creation time. It fills the form in, and editing the template later does not reach back into machines that were already created from it.

Creating several machines at once

Choosing a template also unlocks creating more than one machine in a single pass. How many sets the count, and Number from sets where the numbering starts, so running the same template again later appends to an existing group instead of colliding with the names you already used. With static addressing, IP step controls the spacing between them.

Two rules are checked before anything is created: the hostname must contain an {n} sequence token, and a static starting address must be given as CIDR.

AppVMs can be created several at a time too. They do not step static addresses, and a blank hostname is fine there because each machine derives a distinct name of its own.

Raw cloud-config

If the form does not cover what you need, a VM template can carry your own #cloud-config document, which is appended to the configuration Virtainer Free generates. Use it for the parts that are genuinely yours; let the form handle hostname, users, and networking so the console and the guest agree on what was set.