Manual

Storage

An SR stores VM disk images. A Host reaches it through a PBD; a VM reaches a disk through a VBD. Choose local storage for Host-local capacity or shared storage when multiple Hosts need the same disks. Before provisioning, identify the backing directory, export, block device or replicated capacity and verify what will be erased.

Inspect and create an SR

Open System, Storage to inspect SRs and their Host connections. You can create local-ext, NFS, iSCSI, NVMe-oF and LINSTOR repositories. Choose the kind that matches the storage service or device you have prepared.

For a directory already backed by the intended filesystem:

hv sr list --pool POOL
hv sr create --pool POOL --host HOST --name local-data --kind local-ext --root /srv/hv/disks
hv sr show local-data --pool POOL

The path is on the selected Host, not the CLI workstation. Local storage is not shared. For NFS, prepare an export reachable by the Hosts:

hv sr create --pool POOL --host HOST --name shared-data --kind nfs --nfs-server 192.0.2.20 --path /exports/hv
hv sr show shared-data --pool POOL
hv sr scan shared-data --pool POOL

Inspect PBDs on every Host that will use the SR. An SR record alone does not prove each attachment works. Scanning refreshes inventory; it does not repair corrupted data. Use the CLI reference to select connection options and open the command help for the chosen storage kind.

Choose storage for production

Suppose production contains web-01 on hv-01, and you plan to add hv-02 for maintenance. The local SR created during installation is a useful starting point for a single Host. It remains local when the second Host joins. Before relying on migration, decide how the destination will access every disk that web-01 needs; see live migration.

For an NFS example, prepare the export on 192.0.2.20 and create shared-data using the command above. The address and export path are examples, not a storage service supplied by hv. Check the storage server's access rules for each participating Host. Then inspect the PBD connections from both hv-01 and hv-02, rather than treating a successful connection from the first Host as sufficient.

Create or use a test VM on that SR and check that the guest can write and read its own data. Inspect its disk attachment and the SR's free space. If a later Host cannot reach the same storage, fix its connectivity or attachment before moving a workload to it. Recreating the SR while another Host still uses it risks confusing an access problem with a provisioning task.

For block storage, identify the exact device or target before creation. A familiar-looking device name is not enough to authorize formatting. Keep a record of which physical capacity backs each SR so that a future replacement or removal can be reviewed against the correct disks. The CLI reference explains how to obtain operation-specific help for the chosen storage kind.

Set up LINSTOR

LINSTOR manages replicated disks through DRBD. hv can configure its controller and satellites on Hosts; the controller runs in dom0, not in a controller VM. Before setup, choose eligible Hosts, a free disk on each, the controller Host and the replica count. On a public Pool, first verify the mesh.

Open System, LINSTOR, Setup, then Set up LINSTOR. Select the Hosts and disks, Controller host, Replicas and Storage repository name. Review and type the disk-path confirmation before submitting: every selected disk is erased and becomes an LVM thin pool. Follow the resulting Task and inspect node/resource status before putting VM data on the SR.

A one-Host configuration is possible but does not provide independent Host redundancy. Plan recovery of the selected controller Host separately; do not rely on automatic controller failover. Host removal and teardown are destructive and are refused while resources remain unless explicitly forced; forcing removal destroys the disks those resources back.

Disks and snapshots

Use a VM's Storage tab to inspect its attachments, and the Project's Disks list for owned disks. VHD disks have a 2 TiB format limit. Provision physical capacity for data, Snapshots and growth, not just the displayed virtual size.

The Snapshots tab records point-in-time VM state. A disk-only Snapshot does not capture application consistency by itself. Reverting replaces current state with the selected point; preserve work that must survive before confirming. Snapshots on the same SR are not a substitute for an independent backup.

For example, take a Snapshot of web-01 before an application change only after deciding how to make the application's data consistent. Record what the point represents so that another administrator can distinguish it from a later successful deployment. If you revert, work written after that point may be lost. Preserve anything that must survive before confirming the operation.

A Snapshot and its original disks can fail together when they share the same storage. Use an independent backup for recovery from that failure, and test its restore. Review physical usage as Snapshots accumulate; the guest's configured disk size does not tell you how much room remains for future writes and Snapshot growth.

Verify and resolve problems

After attaching or moving a disk, inspect the Task result, new inventory reference and the VM's actual access. Check free space, PBD attachment, export reachability and backing-device identity when I/O fails. Never delete a parent VHD to recover space: children may depend on it.

hv sr forget removes inventory registration, while hv sr destroy destroys repository data. Neither repairs a temporary mount outage. Inspect dependencies and recoverable backups before removal. For migrations, verify storage availability on the destination as described in live migration.