Storage pools

The storage pool is where machine disks, cached images, and data volumes live. A host with a disk that can hold a pool needs one before it can create anything. On a host where no disk can, machine disks live on the system filesystem instead; that is a supported configuration, not a setup step left unfinished.

Creating a pool

Pool creation runs the same way whether you start it in the setup wizard or later from the Storage page. The host scans its disks and reports what it found before you choose anything.

1. Choose what matters. The default flow asks one question: protection against a disk failure, total capacity, or keeping things separate. An answer is enough to get a plan; you never name a device or a layout to get one.

2. Review this plan. The plan comes back with the list of devices that will be erased and the risks it carries. Nothing has happened yet at this point.

3. Apply storage plan. You confirm the exact device list and risks from the review, and the host builds the pool.

Advanced layout replaces the first step with four of its own: Pool structure, Assign disks, RAID layout, and Review. It is the same planner with the decisions exposed rather than inferred, and it ends at the same review and confirmation.

Apply erases the listed disks

Everything on the devices named in the review is destroyed. Confirmation has to match the plan exactly, so a plan you have not actually read cannot be applied by accident.

If the disks change between the review and the apply, the plan is rejected and you review again. That is deliberate: a stale plan could name a device that is no longer the one you looked at.

While it runs

Apply reports progress as it works through wiping, building, formatting, and mounting. Ordinary work that writes to storage waits until it is finished.

If it fails and the failure is retryable, resume it. If the outcome is uncertain, the host stops and asks you to re-check first: it will observe and report before it touches anything again, rather than guessing at a half-built pool.

Managing an existing pool

Action	What it does
Re-mount (keep data)	Take over a pool that already exists on the disks, without destroying what is on them
Add disk	Grow an existing pool onto more space
Dissolve this pool	Tear the pool down
Rescan hardware	Look again for disks that were added after the host was set up

Two of those four actions destroy data

Add disk wipes the disk you are adding before it joins the pool. The existing data on the pool is untouched, but anything already on the new disk is not part of the deal. The dialog will not proceed without that confirmation.

Dissolve this pool tears the pool down and returns its disks to empty: the volumes, the filesystem, and every machine disk and data volume stored on them. It is refused while any machine exists on the host, and it asks you to type the pool’s volume group and logical volume, as vg/lv, to run. It is not a way to reclaim space from a machine you meant to keep.

What a pool is made of

A Virtainer Free pool is a volume group over the disks you chose, one logical volume taking all of the remaining space, and an XFS filesystem on top. Machine disks and data volumes are files inside it.

The pool itself is not overcommitted: there is no thin pool to watch, and admission is measured against the sizes you ask for rather than what the files have grown to, because a machine whose disk cannot grow when it writes is a worse failure than a host that refuses to create it. The files inside the pool are thin, though: creating a disk passes no preallocation, so a qcow2 file writes metadata only and a raw one is created sparse, and physical space is allocated as the guest writes rather than when the disk is created.

Hosts without a poolable disk

A host whose only disk is the system disk has no pool and does not need one. The Storage page says where storage lives and lists each disk with the reason it cannot hold a pool. Plug a disk in and rescan, and the pool builder becomes available again. Decide before the first machine, though: once machine records exist, planning a pool is blocked.

Disk health

The Storage page reports each disk’s health, and warns you early when a disk starts reporting problems. Check it after any unexpected reboot.

Capacity planning

Three segments consume the pool, and it is worth sizing for all of them:

• Instance disks: what machines have written on top of the image they were built from. A disk built from an image shares that image’s blocks on a copy-on-write pool, so the shared part is counted once, under Base images, rather than once per machine. Each disk is booked against the pool at the size the disk was created with, which is the larger of the size you asked for and the image’s own capacity, not at what the image happens to weigh, so a 100 GiB disk made from a 2 GiB image reserves 100 GiB of the pool even while it is nearly empty.
• Data volumes, one file each, whatever the machine attached to them does.
• Base images: the cached images, whether they were pulled for a classic VM or built for an AppVM; both live in one directory on the pool and count here.

Snapshots are not a segment of their own. They live inside the disk files, so their data already counts as instance disks and data volumes. See Snapshots.

Under 10% free the host refuses new snapshots and starts deleting cached base images to claw space back, so keep the pool above that floor.