Proxmox i macierz SAN (iSCSI, Fibre Channel) – snapshoty, multipath i pułapki współdzielonego LVM

Kto przenosi się z VMware na Proxmoksa i zostawia sobie macierz, może trafić na dwie niespodzianki. Pierwsza: na dyskach maszyn leżących na macierzy nie da się zrobić snapshotu, choć w vSphere było to oczywiste. Druga dotyczy klastra: po restarcie jednego węzła tworzenie albo migracja maszyny potrafi skończyć się błędem „Device or resource busy”. Obie sprawy Proxmox VE rozwiązał w wersji 9.0 (sierpień 2025), ale pierwsze rozwiązanie wciąż ma status technology preview. Poniżej opis stanu w wersji 9.2 na podstawie dokumentacji producenta (odczyt: 14 października 2026 r.).

Jak Proxmox widzi macierz

Macierz podłączona przez iSCSI, Fibre Channel albo SAS udostępnia LUN-y, czyli surowe urządzenia blokowe. Protokół iSCSI nie ma interfejsu do zakładania i usuwania wolumenów, więc Proxmox nie może poprosić macierzy o nowy dysk dla maszyny. Dokumentacja zaleca dlatego jeden duży LUN i na nim LVM. Proxmox dzieli grupę woluminów na dyski maszyn, a jeśli magazyn jest oznaczony jako współdzielony (shared), pilnuje blokad w całym klastrze. Dzięki temu maszyny migrują między węzłami na żywo bez kopiowania dysków.

Na współdzielonym LUN-ie działa tylko zwykły („gruby”) LVM. LVM-thin, który na lokalnych dyskach daje snapshoty i klony połączone, według dokumentacji nie może być współdzielony między węzłami.

Możliwości jest kilka i różnią się tym, co dostajesz:

• LVM na LUN-ie (iSCSI, FC, SAS): magazyn współdzielony, snapshoty maszyn od wersji 9.0 jako łańcuch wolumenów (technology preview). Ten wariant zaleca dokumentacja.
• LUN podany wprost maszynie (iSCSI): współdzielony, bez snapshotów, każdy dysk zakładasz ręcznie na macierzy.
• ZFS over iSCSI: współdzielony, ze snapshotami, ale tylko wtedy, gdy po drugiej stronie jest ZFS i target LIO, IET, istgt albo Comstar dostępny przez SSH. Zwykła macierz się nie nadaje.
• NFS (np. z macierzy, która go udostępnia): współdzielony, snapshoty przez qcow2. Wewnętrzne snapshoty qcow2 blokują działającą maszynę, a na NFS bywają bardzo wolne.

Lista obejmuje tylko wbudowane wtyczki. FC i SAS nie mają osobnej wtyczki: system widzi LUN jak lokalny dysk, a Proxmox korzysta z LVM ułożonego na nim.

Problem 1: brak snapshotów na współdzielonym LVM

W wersjach do 8.x włącznie snapshotów na takim magazynie nie było. Proxmox nie używa natywnych snapshotów LVM, bo jak pisze dokumentacja, aktywny snapshot spowalnia zapisy w całej grupie woluminów. Z tego samego powodu na zwykłym LVM nie ma klonów połączonych.

Kopie zapasowe maszyn działały mimo to. Tryb snapshot w kopiach Proxmoksa to dla maszyn wirtualnych kopia na żywo wykonywana przez QEMU i według dokumentacji nie wymaga snapshotów od magazynu. Brak snapshotów boli więc przy aktualizacjach i zmianach („zrób snapshot, zaktualizuj, w razie czego cofnij”), a nie przy backupie. Inaczej jest z kontenerami: kopia kontenera w trybie snapshot wymaga magazynu ze snapshotami. Różnicę między snapshotem a kopią opisuje wpis Snapshot to nie backup.

Co zmieniła wersja 9.0: snapshoty jako łańcuch wolumenów

Proxmox VE 9.0 dodał do magazynu LVM opcję snapshot-as-volume-chain. Przy snapshocie bieżący stan dysku zostaje zapisany pod nazwą snapshotu, a maszyna pisze dalej do nowego wolumenu, który odwołuje się do poprzedniego i przechowuje tylko różnice. Do łączenia warstw służy format qcow2, ale tylko jego mechanizm łańcucha. Snapshotami zarządza Proxmox, nie macierz, więc działa to z każdą macierzą blokową, niezależnie od producenta.

Przed włączeniem warto znać ograniczenia opisane w dokumentacji i notatkach do wydań:

• Status technology preview, czyli wsparcie „best effort”. W wersji 9.2 nadal tak jest. Na publicznej mapie rozwoju Proxmoksa wyjście z tej fazy jest zapisane jako cel, bez daty.
• Tylko nowe dyski. Włączenie opcji nie zmienia dysków, które już leżą na magazynie.
• Tylko maszyny wirtualne, nie kontenery.
• Wersja maszyny QEMU co najmniej 10. Maszyna ze starszą wersją nie wystartuje z takim dyskiem; od wersji 9.1 Proxmox zgłasza to od razu przy starcie.
• Snapshot zajmuje pełny rozmiar dysku po stronie Proxmoksa, bo wolumeny snapshotów są grube. Faktyczne zużycie na macierzy będzie mniejsze tylko wtedy, gdy LUN jest cienki (thin provisioning) i macierz obsługuje discard. Przy grubym LUN-ie każdy snapshot dysku 500 GB to kolejne 500 GB.
• Maszyny z TPM (np. Windows 11): od wersji 9.2 snapshot można zrobić i usunąć na żywo, ale najnowszego snapshotu nie da się usunąć, gdy maszyna działa.

Opcję włącza się w /etc/pve/storage.cfg przy magazynie LVM (snapshot-as-volume-chain 1). Notatki do wydań 9.1 i 9.2 nadal wymieniają poprawki tej funkcji, m.in. blokad przy snapshotach na współdzielonym LVM i wycofywania snapshotu z wiersza poleceń. Na produkcji przetestuj ją najpierw na mniej ważnej maszynie i trzymaj Proxmoksa w aktualnej wersji.

Problem 2: klaster z macierzą i błąd „Device or resource busy”

Drugi kłopot dotyczył klastrów i jest opisany w zgłoszeniu nr 4997 w bugzilli Proxmoksa (z października 2023 r.). LVM domyślnie aktywuje każdy wolumen logiczny, gdy tylko go zobaczy, na przykład po starcie serwera albo po zalogowaniu do targetu iSCSI. Na współdzielonym LUN-ie oznaczało to, że restartowany węzeł aktywował u siebie dyski maszyn działających na innych węzłach. Skutki opisane w zgłoszeniu:

• po usunięciu maszyny na węźle zostawało martwe urządzenie device-mappera i ponowne utworzenie maszyny o tym samym numerze kończyło się błędem „Device or resource busy”;
• tak samo mogła się wysypać migracja maszyny na żywo; zgłaszający potwierdził to na Proxmoksie 7 i 8.

Obejście polegało na ręcznym usunięciu pozostałości poleceniem dmsetup remove. Od wersji 9.0 Proxmox zakłada nowe wolumeny z wyłączoną autoaktywacją i sam je aktywuje, gdy są potrzebne.

Ważne przy aktualizacji z 8 do 9: zmiana dotyczy tylko nowych wolumenów. Dla istniejących dysków Proxmox dostarcza skrypt /usr/share/pve-manager/migrations/pve-lvm-disable-autoactivation, a narzędzie pve8to9 podpowiada, kiedy go uruchomić. Instrukcja aktualizacji przy współdzielonym LVM „zdecydowanie zaleca” jego uruchomienie. Klaster podniesiony do 9.x bez tego kroku nadal ma stare dyski z autoaktywacją.

Problem 3: multipath trzeba ustawić samemu

Macierz podłącza się zwykle dwiema ścieżkami, żeby awaria karty, kabla albo przełącznika nie zatrzymała maszyn. Proxmox tego nie robi automatycznie: pakietu multipath-tools nie ma w domyślnej instalacji, a konfiguracji nie replikuje klaster, więc każdy węzeł ustawia się osobno. Wiki Proxmoksa (przewodnik „Multipath”) zaleca:

• ścieżki w osobnych domenach awarii, przy iSCSI dwie karty sieciowe, każda w innej sieci i na innym przełączniku;
• dla iSCSI skrócenie node.session.timeo.replacement_timeout w /etc/iscsi/iscsid.conf z domyślnych 120 do 15 sekund;
• dopisanie WWID każdego LUN-u do /etc/multipath/wwids (multipath -a WWID) i pozostawienie opcji find_multipaths na wartości „strict”, żeby multipath nie zakładał niepotrzebnych urządzeń;
• multipath.conf według zaleceń producenta macierzy; gdy producent ich nie podaje, pusty plik i ustawienia domyślne;
• LVM na całym LUN-ie, nie na partycji: na partycji multipath może w ogóle nie złożyć urządzenia;
• dla FC i SAS pakiet multipath-tools-boot i update-initramfs -u -k all po każdej zmianie w wwids albo multipath.conf.

Ostatni punkt łatwo przeoczyć. Dyski FC i SAS są widoczne już na wczesnym etapie startu, zanim powstanie urządzenie multipath. LVM łapie wtedy jedną konkretną ścieżkę (np. /dev/sdc) zamiast urządzenia multipath i wypisuje ostrzeżenie „Device mismatch detected”. Maszyny działają, dopóki ta jedna ścieżka nie padnie.

Stan ścieżek sprawdza multipath -ll: każdy LUN powinien mieć wszystkie ścieżki w stanie „active ready running”. Proxmox zapowiada na mapie rozwoju lepszą integrację multipath z FC i iSCSI, ale dziś to konfiguracja ręczna.

Lista kontrolna: macierz pod klaster Proxmox VE 9

• LUN cienki (thin provisioning) z obsługą discard, jeśli planujesz snapshoty; zamapowany do wszystkich węzłów.
• Dwie ścieżki w osobnych domenach awarii; multipath-tools na każdym węźle, WWID w /etc/multipath/wwids, multipath.conf od producenta macierzy.
• FC/SAS: multipath-tools-boot i odświeżony initramfs. iSCSI: replacement_timeout = 15.
• LVM (nie LVM-thin) na urządzeniu /dev/mapper/…, magazyn oznaczony jako shared. Przy iSCSI magazyn iSCSI z content none jako bazowy, żeby nikt nie podpiął LUN-u wprost do maszyny.
• Po aktualizacji z 8.x: pve8to9 i skrypt wyłączający autoaktywację.
• Snapshoty: świadoma decyzja o snapshot-as-volume-chain (technology preview), maszyny w wersji QEMU 10 lub nowszej, test na mniej ważnej maszynie.
• Kopie zapasowe niezależnie od macierzy, najlepiej na osobny serwer Proxmox Backup Server. Snapshot na macierzy zginie razem z nią.

Macierz czy Ceph albo ZFS

Jeśli macierz już stoi i ma wsparcie producenta, opisany układ działa i od wersji 9 daje snapshoty. Kupując sprzęt pod nowy klaster, porównaj go z Ceph na samych węzłach albo z ZFS z replikacją. Snapshoty i klony mają tam pełne wsparcie, bez statusu technology preview, ale stawiają inne wymagania sprzętowe (co najmniej trzy węzły i osobna sieć 10 Gbps dla Ceph, dużo RAM-u dla ZFS). Rachunek opisuje wpis Serwer do Proxmox VE, a różnice między rodzajami pamięci – ZFS vs LVM-thin vs Ceph. Przy przenoszeniu maszyn z vSphere przyda się też lista 7 pułapek migracji VMware → Proxmox.

Jeśli chcesz podłączyć konkretną macierz do Proxmoksa albo ocenić, czy ją zostawić po migracji z VMware, umów konsultację albo zobacz usługi wdrożeniowe.

Źródła (odczyt 14.10.2026)

• Proxmox VE: Storage – typy magazynów, LVM, LVM-thin, iSCSI, ZFS over iSCSI (dokumentacja 9.2.13)
• Proxmox VE: Backup and Restore – tryby kopii
• Proxmox VE Wiki: Multipath (edycja z 15.09.2026)
• Proxmox VE Wiki: Roadmap – notatki do wydań 9.0, 9.1, 9.2 i plany
• Proxmox VE Wiki: Upgrade from 8 to 9 – autoaktywacja LVM
• Proxmox Bugzilla: zgłoszenie 4997 – autoaktywacja współdzielonego LVM