Dobór storage w Proxmox VE:
ZFS, LVM, NFS i Ceph

Dwie klasy: plik vs blok

Storage plikowy (POSIX) trzyma dowolną treść: obrazy, ISO, szablony, backup, snippet. ZFS jest tu najbardziej rozbudowany — snapshoty i klony. Storage blokowy trzyma duże obrazy raw; ISO i kopie zwykle tam nie wchodzą. Ceph RADOS to rozproszony blok, prezentowany jako RBD.

Konfiguracja siedzi w /etc/pve/storage.cfg i jest wspólna dla węzłów klastra. Shared storage jest dostępny z każdego węzła fizycznie; local jest skonfigurowany wszędzie, ale zawartość jest inna na każdym hoście.

Tabela typów (pvesm)

Przypisy z podręcznika: snapshoty qcow2 na NFS potrafią zablokować działającą VM i na dużych dyskach trwać minuty albo godziny. Typy ze snapshotami wspierają też thin provisioning. Jeśli storage się zapełni, goście dostają błędy IO — overprovision trzeba obserwować. Shared w tabeli oznacza, że węzły widzą ten sam obraz fizycznie; local jest w storage.cfg wszędzie, ale zawartość jest per host. To rozróżnienie decyduje, czy live migration kopiuje pamięć, czy cały wolumen.

ZFS lokalny i LVM-thin

ZFS (zfspool): obrazy VM jako zvol (blok). Snapshoty i klony natywnie. Nie jest shared — live migration dysku wymaga --with-local-disks (kopiuje wolumen). Świetny na węzeł z NVMe, na PBS i tam, gdzie chcesz checksumy i scrub.

LVM-thin: lokalny thin pool, snapshoty tak, shared nie. Instalator PVE często tworzy local-lvm. LVM „gruby” na współdzielonym LUN (iSCSI/FC) służy do pocięcia LUN na wirtualne dyski; od PVE 9 snapshoty jako łańcuch wolumenów.

NFS, iSCSI i Ceph

NFS: shared, elastyczny content. Snapshoty przez qcow2 albo łańcuch — z zastrzeżeniem wydajności. Dobra półka na ISO i szablony; produkcyjne dyski VM tylko gdy macierz i sieć to udźwigną.

iSCSI / FC: LUN + LVM, shared, multipath zwykle wymagany. Snapshoty od PVE 9 jako łańcuch (technology preview w dokumentacji 9).

Ceph RBD: shared, snapshoty, HCI albo osobne OSD. Porównanie z vSAN: vSAN vs Ceph. CephFS zostawiamy na ISO, backup i CT, nie jako jedyny datastore dysków VM.

Snapshoty jako łańcuch wolumenów

Od Proxmox VE 9 snapshoty jako łańcuch wolumenów działają na storage blokowym, który sam z siebie nie umiał w snapshoty (iSCSI, FC). Warstwy to osobne wolumeny. Dokumentacja oznacza to jako technology preview. Wewnętrzne snapshoty qcow2 nadal blokują VM przy tworzeniu i usuwaniu.

Jak wybieramy w projekcie

• 3+ węzły, HCI, live migrate bez kopii dysku: Ceph RBD.
• Macierz już jest: NFS albo iSCSI/FC + LVM.
• Jeden–dwa węzły, NVMe, snapshoty lokalne: ZFS; HA i tak potrzebuje kworum (QDevice) i planu na dysk przy failover.
• Kopie: plugin pbs, nie katalog na tym samym ZFS co VM — patrz backup ransomware.
• Btrfs: w tabeli pvesm jest technology preview (best-effort). Nie kładziemy na nim produkcji.

Multipath, overprovision, PBS

Podręcznik pvesm przy iSCSI/FC: LVM tnie LUN na wirtualne dyski, a multipath jest zwykle wymagany w klastrze. Bez niego path failover wygląda jak „dysk zniknął”. Thin provisioning jest przy typach ze snapshotami — gdy storage się zapełni, goście dostają błędy IO. Overprovision obserwujemy, nie „zostawiamy na później”.

Plugin pbs jest shared i nie trzyma snapshotów VM w sensie qcow2 — to cel kopii. Katalog na tym samym ZFS co dyski VM nie jest 3-2-1. Btrfs w tabeli pvesm ma status technology preview (best-effort) — nie kładziemy na nim produkcji. ZFS over iSCSI jest w tabeli jako shared ze snapshotami; to osobny backend, nie „zwykły” zfspool.

Live migration a typ storage

Shared (NFS, RBD, iSCSI/FC) — live migration kopiuje pamięć, nie dysk. Lokalny ZFS/LVM-thin — --with-local-disks kopiuje wolumen przez sieć klastra; na dużym zvol to minuty. HA po padzie węzła nie przenosi lokalnego ZFS magicznie na sąsiada. Szczegóły flag: migracja na żywo. HCI vs vSAN: vSAN vs Ceph.

Typy treści w pvesm

Podręcznik pvesm przypisuje storageowi listę content: images (dyski VM), rootdir (kontenery), iso, vztmpl, backup, snippets, import. Nie każdy plugin przyjmuje każdą treść: LVM/RBD to przede wszystkim obrazy blokowe; ISO i vzdump idą na katalog, NFS albo CephFS. PBS ma własny plugin i nie jest półką na ISO.

W projekcie rozdzielamy: dyski VM na RBD/ZFS/LVM, ISO i szablony na NFS albo CephFS, kopie na PBS. Mieszanie backupu z dyskami VM na tym samym zfspool łamie 3-2-1, nawet gdy snapshoty ZFS „wyglądają jak kopia”.