# Storage: LVM-thin → ZFS, and the path to Ceph

## Why move off LVM-thin

Neither ZFS nor LVM-thin is shared storage — both are node-local. HA needs
a VM's disk reachable from more than one node so it can restart elsewhere
on host failure. LVM-thin has no answer for that. ZFS does, via
replication; Ceph does natively.

## Two paths to HA-capable storage

| | ZFS + replication | Ceph |
|---|---|---|
| Nodes required | 1+ (replication needs 2+ targets) | 3+ |
| Consistency | Async — snapshot-based, as often as every minute | Sync — real shared storage |
| Data loss on failover | Whatever changed since last replication cycle | ~None |
| Network needs | Normal cluster link | Fast dedicated network (see `03-networking.md`) |
| Overhead | Low | Higher RAM/CPU/disk |

Starting point: **ZFS + replication**. Revisit Ceph once 3 nodes exist or
zero-RPO failover is worth the overhead.

## Migration plan (old hardware → new hardware)

Don't convert the old LVM-thin box in place. Rebuild fresh on new
hardware with ZFS from the installer (mirror if 2+ disks), then move VMs:

1. On the old host: `vzdump` each VM to a backup file (external drive,
   NFS share, or PBS if available).
2. Copy backups to the new host.
3. `qmrestore` onto the new ZFS storage — disks land as ZVOLs.

Alternative if both hosts can see each other on the network: temporarily
cluster them and use the GUI "Migrate" with a storage move (offline only
— live migration doesn't cross storage types).

## Later: handing Ceph-earmarked disks over

Once nodes 2 and 3 are up and the Ceph-earmarked disks (see
`01-hardware-node1.md`) can be pooled 3-node minimum:

1. Wipe any temporary ZFS pool on those disks.
2. Initialize Ceph across the 3 nodes.
3. Create OSDs directly on the raw disks (no ZFS/RAID underneath).
4. Migrate VMs that need zero-RPO failover from the ZFS-replicated tier
   onto Ceph-backed storage.