Docs / SimpleVirt HCI storage

SimpleVirt HCI: one datastore, honest health, and where your data lives

SimpleVirt HCI pools the local disks of a cluster's hosts into replicated shared storage. This page explains what you see, what is underneath, and how the console tells you about maintenance and risk.

One datastore

A SimpleVirt HCI cluster has one datastore, named after its storage pool (for example simplevirt-hci). It holds both things you keep on shared storage:

  • VM disks — the virtual disks of your VMs, stored as replicated block storage.
  • Files & ISOs — the ISO library, uploads and anything you browse from the datastore's Files tab.

You choose the datastore when you create a VM, attach an ISO or add a disk; you never pick between "block" and "file" storage. SimpleVirt sends VM disks to the block part and ISOs and files to the file part for you.

Underneath, the two parts are separate on purpose. VM disks stay on block storage because HA needs its single-writer fence and its speed; files live on a shared file system. The console merges them into one entry, and it does so only in how it presents them: nothing on your hosts or in the storage cluster was renamed or moved, so a cluster set up before this change keeps working as it was, with its VMs and attached ISOs untouched.

If the file part is missing or attached on only some hosts, the datastore says so — for example Files & ISOs: attached on 2 of 3 hosts — and offers the repair. It never shows a healthy state it cannot prove.

If Files says The shared file storage is not attached on the host serving this request, that host's shared file system did not mount when it was accessed. Nothing was written and VM disks are not affected. Press Retry (it attaches on access), and if it stays this way use Repair file storage, which re-mounts it on every member host. The datastore's Files & ISOs row shows how many hosts really have it mounted, so a store no host can write to is never described as attached.

You will see the datastore in three places:

  • the Storage view and the inventory tree (one entry, with the number of hosts that reach it);
  • the cluster's Datastores tab, under a SimpleVirt HCI heading, above any NFS datastores you declared. HCI is discovered from the hosts, not declared, so it has no Remove button here;
  • the cluster's SimpleVirt HCI tab, Datastores page, as one card with a VM disks row and a Files & ISOs row and a single capacity figure.

Removing HCI storage is done only from the SimpleVirt HCI tab's Danger zone, where you type the cluster name. A datastore's own Delete and Unmount actions are refused for HCI pools.

Health that understands maintenance

The Health page groups every finding by what it affects (cluster, hosts and disks, data, network, capacity), says what it means, why it matters and what to do, and has a Retest button that takes a fresh reading.

When you put a host into maintenance, some degradation is expected: that host's copies are offline on purpose. SimpleVirt knows which hosts are in maintenance and classifies each finding:

  • Expected — every affected disk belongs to a host in maintenance. The badge reads Maintenance, the finding carries an Expected chip, and the page explains it (redundancy is reduced while simplevirt-02 is in maintenance; copies resync automatically when it returns). Repair is not offered for what will fix itself.
  • Unexpected — anything else. A failed disk on a host that is not in maintenance stays red, even while another host is in maintenance. A host in maintenance that is still up with only some of its disks down has a real disk failure, not the plan, so that is unexpected too. A problem is never hidden behind maintenance.

Data that cannot be served is never "expected". Maintenance that runs longer than a day, or a host that fails to come back cleanly, is reported as unexpected.

After the host returns, the Data & Resync page shows the resync until every copy is back and the status returns to healthy. While the host is away it says waiting for it to return, not a rebuild that is not happening.

Protection that cannot be talked out of

  • Entering maintenance on a host is refused when it would leave any placement group with fewer than its minimum copies — including when another host is already in maintenance and still serving. The message names the host and how many disks would stop serving I/O.
  • A pool configured to accept writes with a single copy is not treated as safe to take a host away from; raise its protection first, or force the operation knowing the risk.
  • Raise protection (including any grow or "add disks" that would change an existing pool's protection), removing a disk and decommissioning a host are refused while a host is in a fresh maintenance window, and while the storage cluster's own state is unreadable. Raising protection is also refused whenever the live status shows a disk down or any placement group not active and clean. Try again when the host is back. A host that has been in maintenance for over a day, has stopped answering for longer than the outage window, or did not finish its restart cleanly no longer blocks: it is shown as a warning, so a host that died in maintenance can still be decommissioned. The host an operation targets never blocks itself.

On Hosts & Disks, each host shows If this host goes offline: safe, or not safe with the VMs that would be affected, plus whether the cluster can tolerate one more failure. The reading is dated; an old or missing reading shows Unknown, never safe.

Virtual Objects: where each copy lives

The Virtual Objects page lists every virtual disk (and the file store) on the cluster with its owner VM, size, protection policy (for example 3 copies · min 2 · host-separated) and compliance:

Compliance Meaning
Compliant Every placement group has all its copies, on different hosts.
Reconciling Copies are being created or moved; nothing is missing for long.
Reduced availability Some data has fewer copies than the policy asks. Data is served, with less margin.
Inaccessible Some data cannot be served right now.
Unknown The reading is missing or partial; SimpleVirt will not guess.

Expand an object to see how many copies each host holds and whether hosts are separated as the policy requires, and load a sampled physical placement (which disks hold which copy). A virtual disk is spread across the pool's placement groups, so one short group can affect every disk in that pool — compliance is therefore reported per pool and shown on each disk.

The page always says how old its reading is. If it is stale, partial, or an older host does not yet support the placement view, it says exactly that instead of showing an empty or green list.

This page is part of the SimpleVirt 1.0.0 documentation set. The same guides ship inside the appliance images at /usr/share/doc/simplevirt.