Storage & Datastores
A datastore is where Cockpit keeps your virtual disks and ISO files. The most important choice you make about a datastore is its scope — whether it belongs to one host or is shared by all of them — because that choice decides which advanced features your VMs can use.
Local vs shared datastores
| Local datastore | Shared datastore | |
|---|---|---|
| Reachable by | One host only | Every host in the cluster |
| Backed by | The host's own disks | NFS, iSCSI, Fibre Channel, or a clustered filesystem (OCFS2) |
| Best for | Simple, fast, single-host workloads | Migration, High Availability, and clustered workloads |
| Live migration | Slower (the disk must be copied too) | Fast (only memory moves; the disk stays put) |
Why shared storage matters
Several of Cockpit's most useful features work best — or only — when a VM's disks sit on a shared datastore that every host can reach:
- Fast live migration — Because all hosts already see the disk, moving a running VM only needs to transfer its memory. See DRS & HA.
- High Availability restarts — When a host fails, another host can start the VM immediately because it can already reach the disk.
- Automatic load balancing (DRS) — DRS only relocates VMs whose disks are entirely on shared storage.
- Clusters across hosts — Kubernetes clusters and other multi-host workloads can place nodes anywhere.
TIP
If you plan to use migration, HA, DRS, or Kubernetes across multiple hosts, put those VMs on a shared datastore. Local datastores are fine for standalone workloads that stay on one host.
Working with datastores
Creating a datastore — Use the Add Datastore wizard to build a local or shared datastore. It guides you through choosing scope (local vs. shared) and type (local directory, local disk, NFS, or clustered OCFS2), then collects the source and mount details for that type. See Creating & Managing Datastores for the full walkthrough.
Managing a datastore — From the datastore view you can:
- Monitor capacity — See total, used, and available space.
- Refresh — Rescan the datastore so Cockpit's view matches the files actually present.
- Start / Stop — Bring a datastore online or offline. Stopping it makes its disks unavailable to VMs.
- Delete — Remove a datastore. You can optionally choose to erase the disk files it contains; without that option, only the registration is removed and the files are left in place.
Types of shared storage
Cockpit supports several ways to provide shared storage. Your administrator sets these up once; afterwards they appear as ordinary datastores you can place VMs on.
File-based shared storage (NFS)
The simplest shared storage. An NFS server exports a folder that every host mounts. Good general-purpose shared storage and the easiest to set up. Kubernetes clusters can also use an NFS datastore to give applications shared, movable storage.
Block storage over the network (iSCSI)
For higher performance, hosts can connect to shared block storage (a SAN) over the network using iSCSI. Cockpit can bind several network links to the same storage for multipathing, which provides redundancy and better throughput — if one network path fails, storage keeps working over the others.
Clustered filesystem (OCFS2) and shared groups
When several hosts read and write the same block device at once, they must coordinate so they never overwrite each other's data. Cockpit handles this with a clustered filesystem (OCFS2) and a shared group — an O2CB cluster — that keeps the hosts in sync.
WARNING
A clustered datastore is only safe to use while its shared group is active and synchronized on all participating hosts. Cockpit manages this coordination for you — do not mount or write to a clustered datastore whose shared group is not fully online, as doing so can corrupt the data for everyone.
The shared group tracks which hosts are members, checks their heartbeats, and lets an administrator add or remove hosts, choose a heartbeat mode, start or stop the coordination service, and place a host into maintenance so planned network work doesn't fence it. As an end user placing VMs, you simply see the result: a shared datastore that all hosts can use safely.
Administrators set this up and operate it from the Shared Group tab on a datacenter — and must do so before an OCFS2 datastore can be created. See Managing the Shared Group (OCFS2) for the full workflow.
Related topics
- Creating & Managing Datastores — the Add Datastore wizard, step by step.
- Managing the Shared Group (OCFS2) — set up and operate the O2CB cluster for clustered datastores.
- DRS & High Availability — features that depend on shared storage.
- Kubernetes Provisioner — using shared datastores for cluster nodes and NFS storage for applications.
- Virtual Networking — the networks that carry your storage and VM traffic.