Proxmox «Unable to activate storage»: правильно діагностуйте LVM, NFS і CIFS

October 19, 2025 • February 3, 2026 • Читання: 6 хв • Views: 10

Було корисно?

Ви натискаєте на ВМ, запускаєте «Start», а Proxmox відповідає еквівалентом плечима: unable to activate storage. Раптом ваш кластер більше не схожий на «гіперконвергентну інфраструктуру», а швидше на «чат, у якому ніхто не відповідає».

Ця помилка — не одна конкретна проблема. Це симптом. Правильний підхід — перестати гадати, визначити, який бекенд сховища дає збій (LVM vs NFS vs CIFS), а потім підтвердити режим відмови декількома дисциплінованими командами. Ви виправите все швидше — і перестанете ламати це після наступного ребуту.

Що насправді означає «unable to activate storage» у Proxmox

У Proxmox «storage» — це плагінна абстракція над дуже різними реаліями: локальна LVM volume group, змонтований NFS-експорт, CIFS-монт, iSCSI LUN, ZFS-пули, директорії тощо. Коли Proxmox каже, що не може «активувати» сховище, це зазвичай означає одне з наступного:

Бекенд відсутній (VG не знайдено, монтування не відбулося, шлях відсутній).
Бекенд присутній, але непридатний (права доступу, застарілий дескриптор, тільки для читання, неправильні опції, помилка автентифікації).
Proxmox не може виконати крок активації (відсутній інструмент, команда повертає помилку, порядок запуску сервісів, конфлікт блокувань).
Вузол думає, що він відповідальний, коли це не так (невідповідність конфігурації кластера, вузько-специфічні визначення сховища для вузла, симптоми split-brain).

Ключ — ставитися до цього як до інциденту SRE: визначити зону ураження (один вузол чи всі), ізолювати проблемний бекенд, зібрати докази, а потім змінювати тільки одну змінну за раз.

Цитата, яку варто мати на стіні:

«Надія — не стратегія.» — General Gordon R. Sullivan

Трасування проблем зі сховищем — це місце, куди йде надія помирати. Це добре. Воно змушує вас вимірювати.

Жарт №1: Відмови сховища схожі на дітей: чим голосніше вони кричать, тим більша ймовірність, що причина — щось базове, на що ви не подивилися.

Швидкий плейбук діагностики (перший/другий/третій)

Якщо ви на виклику і потребуєте швидкого сигналу, не починайте з редагування випадкових конфігів Proxmox. Зробіть так:

Перший крок: підтвердьте масштаб і точний ідентифікатор сховища

Це один вузол чи кілька?
Це один запис сховища чи всі?
Чи це тільки запуск ВМ, чи також запуск контейнерів та бекапи?

Мета: назвати збійне сховище точно (його storage ID у Proxmox) і визначити уражені вузли.

Другий крок: перевірте істину на рівні ОС (монти/VG/шляхи), а не відчуття GUI

Для NFS/CIFS: чи дійсно воно змонтовано в очікуваному шляху?
Для LVM: чи існує VG і видимі LV?
Для всього: чи можете ви читати/писати в шлях від root?

Мета: доведіть, чи бекенд існує і чи доступний з shell вузла.

Третій крок: погляньте в логи завдань Proxmox і journal для точного рядка помилки

Proxmox обгортає помилки бекенда. Повідомлення-обгортка рідко є рішенням.
Знайдіть підлягаючу команду, яка впала (mount, vgchange, lvcreate тощо).

Мета: отримати точний рядок помилки: «permission denied», «no such device», «protocol not supported», «unknown filesystem type», «wrong fs type», «stale file handle», «timed out». Цей рядок визначає наступний крок.

Цікаві факти та контекст (бо історія повторюється)

LVM2 став стандартом у Linux після уроків від LVM1 і вендорських volume manager-ів; він стабільний, але активація залежить від виявлення пристроїв і таймінгів udev.
NFSv3 — це в основному статeless, через що він може «працювати», поки раптом не перестане, а потім дивно відновиться; NFSv4 змінив модель на стан-керовані сесії.
«Stale file handle» — класика NFS, що походить десятиліттями; по суті клієнт тримає посилання на інод, якого сервер більше не визнає.
SMB1 (CIFS) був проблемою безпеки, і сучасні системи часто його вимикають; невідповідність при узгодженні діалекту SMB — тихий винуватець помилок монтовання.
systemd змінив порядок монтувань для багатьох адміністраторів, що звикли до sysvinit; те, що «працювало під час завантаження» раніше, тепер може падати, якщо не вказати залежності.
Кластерні файлові системи й спільне сховище — різні проблеми; Proxmox може ділитися конфігурацією через corosync, але ваше сховище все одно має бути доступним і консистентним.
Multipath і LVM не завжди одразу ладнають; якщо ви активуєте VG на неправильних підлеглих пристроях, можна отримати дублікати PV або «несумісність пристроїв».
Тюнінг NFS може зламати коректність, коли люди експериментують з кешуванням чи тайм-аутами; найшвидша бага — все ж бага.

Тріаж: визначення бекенду й масштабу відмови

Перш ніж занурюватися глибоко: визначте, який тип сховища Proxmox намагається активувати. Записи сховища Proxmox живуть у конфігу кластера, але активація відбувається на кожному вузлі. Саме тому один вузол може падати, а інші — працювати.

Практичне правило: якщо Proxmox storage — «Directory», «NFS» або «CIFS», відмови зазвичай відповідають проблемам монтування або прав доступу. Якщо сховище — «LVM» або «LVM-thin», відмови пов’язані з виявленням пристроїв, активацією VG або блокуваннями.

Також вирішіть, чи ви в режимі «відновлення сервісу», чи в режимі «фінансової криміналістики». У режимі відновлення ви надаєте пріоритет запуску ВМ, не погіршуючи наступну відмову. У криміналістиці ви зберігаєте докази і менше змінюєте систему. Оберіть одне; не переключайтеся кожні 10 хвилин.

LVM: відмови активації, що виглядають як проблеми Proxmox

Відмови LVM часто нудні й локальні: вузол не бачить блочного пристрою, VG не активна або LVM плутається, який пристрій є «реальним» PV. Proxmox повідомляє «unable to activate storage», бо з його точки зору плагін LVM не може виконати своє завдання.

Типові категорії відмов LVM

VG не знайдено: PV-пристрій відсутній (диск пропав, iSCSI не залогінився, multipath не готовий).
VG існує, але неактивний: активація не відбулась під час завантаження або зірвалась через блокування.
Дублікати PV: той самий LUN видно через кілька шляхів без правильної конфігурації multipath.
Проблеми thin pool: метадані thin заповнені, пул тільки для читання або активація заблокована через помилки.
Проблеми фільтрів: device filters у lvm.conf виключають реальні пристрої, тож виявлення неконсистентне.

Що означає «активувати» для LVM у термінах Proxmox

Для LVM-thin Proxmox очікує, що volume group буде знайдена і thin pool LV активований. Він виконає LVM-команди під капотом. Якщо ці команди повертають ненульовий статус, Proxmox видасть узагальнену помилку.

Якщо ви виправляєте LVM, ваше перше питання має бути: «Чи вузол бачить блочний пристрій, і чи погоджується з цим LVM?» А не «Що говорить GUI?»

NFS: монтування, що не вдається, зависає або бреше

NFS популярний у Proxmox через простоту: змонтуйте експорт і використовуйте його як директорію. Він також виходить із ладу так, що це виглядає як баг Proxmox, тоді як справжня причина — мережа, DNS, фаєрвол, налаштування експорту або узгодження версії.

Категорії відмов NFS, що викликають «unable to activate storage»

Монтування не відбувається: неправильна адреса сервера, неправильний шлях експорту, фаєрвол, заблоковані RPC-сервіси.
Монтування є, але тільки для читання: опції експорту або серверні карти доступу (root squash, мапінг UID).
Stale file handle: серверні зміни (ремонт файлової системи, фейловер, промоція снапшоту) інвалідовують дескриптори.
Тайм‑аути, що виглядають як зависання: NFS I/O зависає і блокує завдання Proxmox, через що вузол відчувається «повільним», а не «вимкненим».
Неправильна версія NFS: клієнт пробує v4, а сервер підтримує тільки v3 (або навпаки), або v4 вимагає іншої структури експорту.

У випадку NFS «активація» — це по суті «переконатися, що монтування присутнє і відповідає». Монтувальний пункт, що існує, але не відповідає, гірший за чистий провал, бо він змушує процеси зависати в незнімному стані I/O.

CIFS/SMB: автентифікація, діалекти та жорстока радість прав доступу

CIFS у Proxmox — це просто «змонтоване SMB-шер і використовується як директорія». Отже всі нюанси SMB стають вашою проблемою: узгодження діалекту (SMB2/3), NTLM vs Kerberos, довіра домену, ротація паролів і семантика прав власності файлів.

Категорії відмов CIFS

Помилки автентифікації: неправильні облікові дані, прострочений пароль, проблеми з доменом, зміни політик NTLM.
Невідповідність діалекту: сервер вимкнув старі версії SMB; клієнт за замовчуванням використовує інші; загострення безпеки ламає монтування.
Странності з мапінгом прав: змонтовано, але root не може записувати через ACL сервера або опції монтування.
DFS/referrals: ви змонтували шлях, що перенаправляє, і тепер він не працює.
«Працює вручну, але падає в Proxmox»: бо Proxmox використовує конкретні опції монтування або читає облікові дані з файлу з невірними правами.

Жарт №2: Права SMB як офісна політика: всі наполягають, що це «просто», а потім нічого не працює, поки Карен не дасть добро.

Практичні завдання: команди, очікувані виводи та рішення (12+)

Ці завдання впорядковані приблизно від «швидкого сигналу» до «глибокої діагностики». Виконуйте їх на ураженому вузлі спочатку. Якщо це кластер — порівняйте робочий вузол з тим, що падає — дифінг реальності недооцінений.

Завдання 1: Підтвердити, яке сховище Proxmox вважає збійним

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active       1024000000        12345678       987654321        1.2%
nfs-backup        nfs     inactive              0               0               0          0%
lvm-thin          lvmthin inactive              0               0               0          0%

Що це означає: «inactive» тут — це погляд Proxmox, а не діагноз. Воно показує, на які storage ID слід зосередитися (наприклад, nfs-backup, lvm-thin).

Рішення: Виберіть один збійний storage ID і слідуйте відповідному розділу бекенду. Не намагайтеся одночасно «шотганити» все.

Завдання 2: Перевірити визначення сховища так, як його бачить Proxmox

cr0x@server:~$ pvesm config nfs-backup
nfs-backup: nfs
        export /exports/proxmox-backup
        path /mnt/pve/nfs-backup
        server 10.20.30.40
        content backup,iso
        options vers=4.1

Що це означає: Ви отримуєте авторитетний mountpoint і параметри server/export, які Proxmox буде використовувати.

Рішення: Переконайтеся, що mountpoint існує і чи змонтовано його, а також перевірте мережеву досяжність до IP/hostname сервера.

Завдання 3: Переглянути логи завдань Proxmox для точної помилки

cr0x@server:~$ tail -n 60 /var/log/pve/tasks/active
UPID:pve01:0000A1B2:0001C3D4:676D0F00:vzdump::root@pam:
UPID:pve01:0000A1B3:0001C3D5:676D0F10:mount::root@pam:storage=nfs-backup:

cr0x@server:~$ journalctl -u pvedaemon -u pvestatd -u pve-storage -n 200 --no-pager
Dec 26 10:11:12 pve01 pvestatd[1234]: storage 'nfs-backup' is not online
Dec 26 10:11:13 pve01 pvedaemon[2345]: storage activate failed: mount error(13): Permission denied

Що це означає: Ви полюєте за підлягаючим errno: тут це permission denied (error(13)) з семантикою типу CIFS або контролю доступу на сервері.

Рішення: Стоп. «Permission denied» не вирішується ребутом. Перевірте облікові дані/права експорту на сервері.

Завдання 4: Перевірити стан mountpoint (NFS/CIFS/dir)

cr0x@server:~$ findmnt /mnt/pve/nfs-backup
TARGET             SOURCE                    FSTYPE OPTIONS
/mnt/pve/nfs-backup 10.20.30.40:/exports/proxmox-backup nfs4   rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2

Що це означає: Якщо findmnt не повертає нічого — воно не змонтовано. Якщо воно повертає NFS/CIFS, але система все ще дає помилку, монтування може бути застарілим або мати неправильні права.

Рішення: Якщо незмонтовано — зробіть контрольоване монтування і зафіксуйте точну помилку. Якщо змонтовано — перевірте швидкість I/O.

Завдання 5: Протестувати читання/запис і швидко виявити «зависле монтування»

cr0x@server:~$ timeout 5 bash -c 'ls -la /mnt/pve/nfs-backup >/dev/null; echo OK'
OK

Що це означає: Якщо ця команда тайм‑аутиться, монтування зависло. Це проблема мережі/сервера (або мертвої сесії), а не Proxmox.

Рішення: Для завислих монтувань не запускайте бекапи «щоб подивитися, чи пройде». Виправте з’єднання або безпечно відмонтуйте/перемонтуйте.

Завдання 6: Перевірити базову мережеву досяжність (не ускладнюйте)

cr0x@server:~$ ping -c 2 10.20.30.40
PING 10.20.30.40 (10.20.30.40) 56(84) bytes of data.
64 bytes from 10.20.30.40: icmp_seq=1 ttl=63 time=0.482 ms
64 bytes from 10.20.30.40: icmp_seq=2 ttl=63 time=0.455 ms

--- 10.20.30.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms

Що це означає: Ping не доводить здоров’я NFS/SMB, але його провал — сильна підказка, що ви копаєте не в той шар.

Рішення: Якщо ping падає — перевірте маршрутизацію/VLAN/фаєрвол перед тим, як міняти конфігурацію сховища.

Завдання 7: NFS-специфічно: перевірити, чи видимі експортовані шари з клієнта

cr0x@server:~$ showmount -e 10.20.30.40
Export list for 10.20.30.40:
/exports/proxmox-backup 10.20.30.0/24

Що це означає: Якщо експорт не в списку (або showmount таймаутиться), проблема на стороні сервера: експорти/RPC-сервіси/фаєрвол.

Рішення: Виправте конфіг експорту NFS або правила фаєрвола на сервері; не «ремонтуйте» Proxmox для сервера, що відмовляє.

Завдання 8: NFS-специфічно: спроба ручного монтування з явною версією/опціями

cr0x@server:~$ umount /mnt/pve/nfs-backup 2>/dev/null || true
cr0x@server:~$ mount -t nfs -o vers=4.1,proto=tcp,timeo=600,retrans=2 10.20.30.40:/exports/proxmox-backup /mnt/pve/nfs-backup
cr0x@server:~$ dmesg | tail -n 8
[123456.789012] nfs: server 10.20.30.40 OK

Що це означає: Ручне монтування ізолює Proxmox від рівня. Якщо ручне монтування не вдається — проблема в бекенді. Якщо вдається — порівняйте опції з конфігом Proxmox.

Рішення: Якщо ручне монтування працює тільки з іншою опцією vers= або опціями, оновіть опції сховища в Proxmox відповідно.

Завдання 9: CIFS-специфічно: перевірити права і вміст файлу з обліковими даними

cr0x@server:~$ ls -l /etc/pve/priv/storage/cifs-prod.pw
-rw------- 1 root root 64 Dec 26 09:55 /etc/pve/priv/storage/cifs-prod.pw
cr0x@server:~$ sed -n '1,5p' /etc/pve/priv/storage/cifs-prod.pw
username=svc_proxmox
password=REDACTED
domain=CORP

Що це означає: Proxmox очікує, що файли з обліковими даними читає тільки root. Неправильні права можуть спричиняти невдачі монтовання або витік секретів.

Рішення: Якщо права не 600, виправте їх. Якщо пароль змінився — оновіть файл і розгляньте процедуру ротації паролів.

Завдання 10: CIFS-специфічно: ручне монтування з явним діалектом SMB і параметром безпеки

cr0x@server:~$ umount /mnt/pve/cifs-prod 2>/dev/null || true
cr0x@server:~$ mount -t cifs //fileserver01/proxmox -o credentials=/etc/pve/priv/storage/cifs-prod.pw,vers=3.0,sec=ntlmssp,uid=0,gid=0,file_mode=0660,dir_mode=0770 /mnt/pve/cifs-prod
cr0x@server:~$ findmnt /mnt/pve/cifs-prod
TARGET           SOURCE                    FSTYPE OPTIONS
/mnt/pve/cifs-prod //fileserver01/proxmox  cifs   rw,relatime,vers=3.0,sec=ntlmssp,cache=strict,username=svc_proxmox,uid=0,gid=0,file_mode=0660,dir_mode=0770

Що це означає: Якщо додавання vers=3.0 виправляє проблему, сервер, ймовірно, вимкнув старі діалекти. Якщо sec= важливий — політика домену змінилася.

Рішення: Вирівняйте опції сховища Proxmox з тим, що реально працює, і погодьтеся з командою файлового сервера, щоб вони не «загартовували» вас у простої.

Завдання 11: LVM: перевірити, чи існують VG і thin pool

cr0x@server:~$ vgs
  VG         #PV #LV #SN Attr   VSize    VFree
  pve        1   7   0  wz--n-  930.00g  12.00g
  vg_vmdata  1   2   0  wz--n-    3.64t  120.00g

cr0x@server:~$ lvs -a -o +devices vg_vmdata
  LV          VG        Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  thinpool    vg_vmdata twi-aotz--  3.40t             62.10  4.20                             /dev/sdb(0)
  thinpool_tmeta vg_vmdata ewi-aotz-- 8.00g                                                   /dev/sdb(870912)
  thinpool_tdata vg_vmdata ewi-aotz-- 3.40t                                                   /dev/sdb(2048)

Що це означає: VG існує, і thin pool активний (twi-a). Якщо ви бачите twi--- без a, він не активний. Якщо VG відсутній — підлягаючий блочний пристрій невидимий або не виявляється.

Рішення: Якщо VG відсутній: перевірте диски/iSCSI/multipath. Якщо thin pool неактивний: спробуйте активацію і вивчіть помилки.

Завдання 12: LVM: спробувати контрольовану активацію і знімати помилки

cr0x@server:~$ vgchange -ay vg_vmdata
  1 logical volume(s) in volume group "vg_vmdata" now active

Що це означає: Успішна активація відбувається негайно й явно. Якщо вона провалюється, LVM покаже причину (блокування, відсутні PV, дублі).

Рішення: Якщо активація вдається, перевірте знову pvesm status. Якщо ні — слідуйте рядку помилки, не імпровізуйте.

Завдання 13: LVM: виявити відсутні PV або дублікати шляхів пристроїв

cr0x@server:~$ pvs -o+pv_uuid,pv_name,vg_name,dev_size
  PV         VG        Fmt  Attr PSize  PFree  PV UUID                                DevSize
  /dev/sdb   vg_vmdata lvm2 a--  3.64t 120.00g 9Hk3vS-9Qb8-1x2c-7y5n-ABCD-ef01-2345  3.64t

Що це означає: Якщо ви бачите той самий PV UUID на кількох пристроях (поширене при неправильній конфігурації multipath), LVM відмовиться працювати або поводитиметься непередбачувано.

Рішення: Налаштуйте multipath так, щоб використовувався лише один шлях (зазвичай /dev/mapper/mpathX), потім оновіть фільтри LVM за потреби.

Завдання 14: Перевірити журнали kernel і systemd навколо монтувань і LVM

cr0x@server:~$ journalctl -b -p warning..alert --no-pager | tail -n 60
Dec 26 09:42:01 pve01 systemd[1]: mnt-pve-nfs\x2dbackup.mount: Mount process exited, code=exited, status=32/n/a
Dec 26 09:42:01 pve01 kernel: CIFS: VFS: cifs_mount failed w/return code = -13
Dec 26 09:42:02 pve01 lvm[987]: device-mapper: thin: Data device (dm-3) discard granularity larger than a block: disabling discards

Що це означає: systemd дає коди виходу, kernel логи показують коди повернення монтовання, а LVM дає підказки device-mapper, що можуть вказувати на проблеми блочного шару.

Рішення: Якщо unit монтування systemd впав — перевірте опції монтування і порядок; якщо CIFS повернув код -13 — це права; якщо kernel показує I/O помилки — зупиніться і розслідуйте диск/мережу.

Завдання 15: Підтвердити, що Proxmox може активувати тепер (і це зберігається)

cr0x@server:~$ pvesm set nfs-backup --disable 0
cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
nfs-backup        nfs     active        2048000000       123456789      1920000000       6.0%

Що це означає: Це підтверджує, що плагін сховища Proxmox бачить і може використовувати бекенд знову.

Рішення: Запустіть одну ВМ і виконайте легку операцію зі сховищем (створіть невеликий диск, перегляньте бекапи). Переконайтеся, що це витримує ребут, якщо проблема була в порядку запуску.

Типові помилки: симптом → корінь проблеми → виправлення

1) «Сховище неактивне» тільки на одному вузлі

Симптом: Кластер показує сховище офлайн на pve02, а на pve01 все гаразд.

Корінь проблеми: Локальна проблема вузла: мережевий маршрут, монтування відсутнє, iSCSI сесія не залогінена або диск відсутній.

Виправлення: Діагностуйте на проблемному вузлі з findmnt/vgs; порівняйте з робочим вузлом; виправте мережу/монтування/iSCSI перш ніж чіпати конфігурацію кластера.

2) NFS-монтування є, але операції Proxmox зависають

Симптом: Запуск ВМ, бекап або «переглянути сховища» зупиняється; SSH іноді повільний; процеси не вбиваються.

Корінь проблеми: Зависле NFS I/O; монтування «існує», але не відповідає через сервер/мережу.

Виправлення: Використовуйте тест timeout; перевірте мережу; після відновлення з’єднання розгляньте перемонтування. Уникайте «soft» монтувань для сховищ ВМ — корупція гірша.

3) CIFS-монтування впало після ротації пароля

Симптом: «mount error(13): Permission denied» раптово після місяців стабільності.

Корінь проблеми: Поменявся пароль сервісного облікового запису; файл облікових даних застарів; або політика домену змінила вимоги автентифікації.

Виправлення: Оновіть файл облікових даних; переконайтеся в правах 600; зафіксуйте vers=3.0 і sec=ntlmssp, якщо це вимагає політика.

4) LVM-thin неактивний після ребуту

Симптом: Після перезавантаження сховище LVM неактивне; ручний vgchange -ay виправляє.

Корінь проблеми: Порядок завантаження: підлеглий пристрій з’являється пізно (multipath, iSCSI), тому активація LVM під час завантаження пропускає його.

Виправлення: Забезпечте запуск iSCSI/multipath перед активацією LVM; виправте виявлення пристроїв; уникайте «активації через ребути» як стратегії.

5) «Volume group not found», але диски на місці

Симптом: vgs не показує VG; але lsblk відображає диск.

Корінь проблеми: Фільтр пристроїв LVM виключає його; або PV-підписи знаходяться на іншому шляху пристрою.

Виправлення: Перегляньте /etc/lvm/lvm.conf фільтри; стандартизуйте стабільні шляхи пристроїв (by-id, mapper для multipath).

6) NFS-експорт працює з однієї підмережі, але не з іншої

Симптом: Один вузол монтує; інший отримує «access denied by server».

Корінь проблеми: Обмеження доступу експорту за IP/підмережею; новий вузол у іншому VLAN; очікування зворотного DNS.

Виправлення: Виправте список доступу експорту на сервері; тримайте Proxmox-вузли в очікуваних підмережах; уникайте покладання на зворотний DNS, якщо можна.

7) CIFS монтується вручну, але Proxmox і далі вважає його неактивним

Симптом: Ви можете змонтувати шар, але плагін Proxmox все одно повідомляє inactive.

Корінь проблеми: Невідповідність шляху монтування, різні опції або Proxmox очікує його під /mnt/pve/<storageid>.

Виправлення: Підтвердіть pvesm config path; забезпечте монтування саме в цей шлях; уникайте саморобних монтувань поза очікуваними директоріями Proxmox, якщо ви не розумієте наслідків.

8) «Stale file handle» після робіт по сховищу

Симптом: NFS-шлях існує; операції падають зі stale handle; іноді вирішується перемонтуванням.

Корінь проблеми: Серверна файлова система змінилася, експорт перемаплено або фейловер перемістив бекенд без збереження консистентності інодів.

Виправлення: Координуйте роботи; перемонтуйте клієнти; забезпечте, щоб HA/failover зберігала ідентичність експорту, коли це можливо.

Три корпоративні міні-історії з полів зберігання

Інцидент від неправильної припущення: «Це баг Proxmox»

У них був невеликий кластер Proxmox і «надійний» NFS-шер для бекапів. Одного понеділка бекапи впали з «unable to activate storage». Перша реакція команди була план оновлення Proxmox, бо GUI сказав, що сховище неактивне і отже Proxmox щось поламав.

Тим часом NFS-сервер перенесли за нові правила фаєрвола. Ping працював. DNS працював. Навіть SSH працював. Цього було достатньо, щоб усі припустили, що сховище теж працюватиме. Але ні. Фаєрвол блокував трафік, пов’язаний з NFS, і спроби монтування таймаутились.

Оновлення відклали, коли хтось нарешті запустив showmount -e і воно зависло. Це була підказка. Не «Proxmox storage inactive», а «вузол не може поговорити з тим NFS-сервером». Виправлення — правило фаєрвола і перемонтування. Бекапи відновились.

Неприятний урок був не про порти NFS. Він був про процес: у них не було playbook першого реагування, тож всі за замовчуванням «змінювали додаток», а не «доказували залежність».

Оптимізація, що обернулась боком: тюнінг NFS як гоночний болід

Інша організація використовувала NFS для ISO і шаблонів контейнерів. Було нормально. Потім хтось вирішив «оптимізувати» агресивними опціями: короткі тайм‑аути, «soft» монтування і різні кеші, бо «це ж просто ISO-сховище».

Декілька тижнів працювало. Потім мережевий глюк під час витягання шаблону. Поведінка «soft» повернула I/O помилки в стеці замість очікуваного відновлення. Результат — не просто зірване завантаження шаблону, а часткові файли, що виглядали валідними й потім використовувалися.

Тепер у них був heisenbug: контейнери іноді не стартували, іноді стартували з відсутніми файлами, а шар зберігання весь час здавався «активним». Коли перевірили цілісність файлів, знайшли пошкоджені артефакти, які тихо кешувалися й повторно використовувалися.

Виправлення — повернення до розумних дефолтів: «hard» монтування для всього, що впливає на коректність, явне фіксування версії NFS і політика, що «оптимізація вимагає плану відкату». Тюнінг продуктивності без тестів відмов — це просто азартна гра з додатковими кроками.

Нудна, але правильна практика, що врятувала день: порівняння вузлів і логування реальної помилки

Середня компанія тримала LVM-thin на multipath-підключеному сховищі. Одного ранку після зміни firmware сховища один вузол не міг активувати LVM. Решта кластера була в порядку. Почався панік. Звинувачували вендора сховища. Звинувачували гіпервізорну команду. Усі відточували улюблений вид упевненості.

Інженер на виклику зробив щось глибоко неефектне: порівняв робочий вузол з проблемним. Та ж версія Proxmox. Та сама конфігурація сховища. Вони запустили pvs і помітили: проблемний вузол бачив LUN одночасно як /dev/sdX і як /dev/mapper/mpathY. Дублікати PV-підписів. LVM відмовлявся активувати, бо не міг гарантувати, що не спричинить корупцію.

Інженер не намагався «форсувати» нічого. Вони виправили multipath так, щоб був лише mapper-пристрій, потім підправили фільтри LVM, щоб ігнорувати сирі /dev/sd* шляхи для цього SAN. Активація пройшла. Ніяких втрат даних. Ніяких героїчних дій.

День врятували дві практики: завжди фіксувати реальний рядок помилки і завжди робити diff робочого і проблемного вузла перед змінами в продакшні. Це нудно. Але так ви рятуєте вихідні.

Контрольні списки / покроковий план

Чеклист A: Перші 10 хвилин (зупинити кровотечу)

Запустіть pvesm status і визначте збійні storage ID та їх типи.
Перегляньте логи завдань і journal для підлягаючої помилки: journalctl -u pvedaemon -u pvestatd -u pve-storage.
Для NFS/CIFS: перевірте наявність монтування через findmnt і відгук через timeout.
Для LVM: перевірте видимість VG/LV через vgs/lvs.
Якщо це тільки один вузол: порівняйте з робочим вузлом перед будь-якими змінами.

Чеклист B: Покроково для NFS

Підтвердіть конфіг Proxmox: pvesm config <storageid>.
Перевірте поточне монтування: findmnt <path>.
Переконайтеся, що експорт видимий: showmount -e <server>.
Ручне монтування з явною версією: mount -t nfs -o vers=4.1 ....
Протестуйте I/O: створіть і видаліть невеликий файл у монтуванні.
Якщо бачите stale handles: перемонтуйте і координуйте роботи з власником NFS-сервера щодо поведінки фейловера.

Чеклист C: Покроково для CIFS

Підтвердіть конфіг Proxmox і шлях монтування.
Переконайтеся, що файл облікових даних існує і має 600.
Ручне монтування з явними vers= і sec= опціями.
Перегляньте kernel-логи на предмет кодів CIFS: dmesg | tail.
Перевірте права на запис, створивши файл від root у монтуванні.
Після виправлення перезавантажте перегляд сховища Proxmox, перевіривши pvesm status; не покладайтесь на кеш GUI.

Чеклист D: Покроково для LVM

Перевірте наявність VG: vgs. Якщо відсутній — дивіться на блочний шар (диски/iSCSI/multipath).
Перевірте стан LV/thin pool: lvs -a -o +devices.
Спробуйте активацію: vgchange -ay <vg>.
Якщо підозрюєте дублікати: pvs -o+pv_uuid і виправте multipath/LVM фільтри.
Перевірте використання thin pool; якщо метадані заповнені — виправте це перед створенням нових томів.
Коли стабільно, перевірте стійкість через ребут (порядок завантаження, залежності сервісів).

FAQ

1) Чому Proxmox каже «unable to activate storage» без деталей?

Тому що це обгорткова помилка від шару плагіну сховища. Справжні деталі виводяться у логи завдань і системні журнали. Завжди дивіться journalctl і логи задач Proxmox.

2) Чи можна просто перезавантажити вузол, щоб вирішити проблеми активації?

Іноді так, але це погана звичка. Ребути можуть приховати змагання при завантаженні (iSCSI/multipath) і ускладнити діагностику періодичних NFS-проблем. Ребутуйте тільки після того, як зафіксували рядок помилки.

3) Монтування NFS присутнє, але Proxmox все одно повідомляє inactive — чому?

Якщо монтування застаріле або не відповідає, Proxmox може позначити його офлайн, бо виклики статистики таймаутяться або повертають помилки. Використайте тест через timeout, щоб виявити зависання.

4) Який найшвидший спосіб визначити, LVM vs NFS vs CIFS — у чому проблема?

pvesm status покаже тип сховища. Далі перевірте стан на рівні ОС: findmnt для NFS/CIFS, vgs/lvs для LVM.

5) Чи варто використовувати CIFS для дисків ВМ?

У продакшні я уникаю цього для дисків ВМ. Семантика CIFS і варіабельність затримок можуть створювати неприємні крайні випадки. Використовуйте його для ISO/бекапів, якщо потрібно, і тестуйте поведінку при відмовах.

6) Що означає «stale file handle» в операційному сенсі?

Клієнт посилає посилання на серверний об’єкт, який більше не має тієї ж ідентичності. Зазвичай це відбувається після серверних змін файлової системи або фейловера. Часто потрібне перемонтування; запобігти цьому можна, забезпечивши стабільну бекенд-ідентичність експорту.

7) Мій LVM VG відсутній після ребута, але диск на місці. Чому?

LVM може фільтрувати пристрій або бачити його під іншим шляхом. Multipath також може показувати дублі. Перевірте через pvs і стандартизуйте іменування пристроїв.

8) Який найбезпечніший спосіб виправити зависле NFS-монтування?

Спочатку відновіть мережу/сервер, якщо можливо. Потім відмонтуйте і перемонтуйте. Будьте обережні: процеси можуть висіти в D-state; примусові відмонтування можуть бути руйнівними. Віддавайте перевагу плановому перемонтуванню в контрольованому вікні, якщо залучений I/O ВМ.

9) Чому один вузол Proxmox монтує CIFS, а інший — ні?

Різні встановлені пакети, різний DNS, різний час синхронізації (Kerberos) або відмінності в ядрі/модулях. Порівняйте опції монтування і перевірте коди повернення в dmesg на обох вузлах.

10) Як запобігти цьому в майбутньому?

Зробіть монтування й активацію LVM детерміністичними: фіксуйте версії протоколів, забезпечте порядок запуску сервісів (iSCSI/multipath перед LVM), моніторте відгук mount point (не тільки «чи змонтовано»), використовуйте моніторинг thin pool metadata та журналів ядра на предмет повторюваних помилок монтування. Документуйте залежності сховища, бо вони мають значення.

Висновок: наступні кроки, що запобігають повторенню

«Unable to activate storage» — це Proxmox, що повідомляє: бекенд не пройшов базову перевірку реальності. Ставтеся до цього відповідно. Ідентифікуйте storage ID, перевірте істину на рівні ОС, а потім використовуйте логи, щоб визначити підлягаючий рядок помилки. Виправляйте бекенд, а не інтерфейс.

Наступні кроки, що окупляться:

Напишіть односторінковий runbook для вашого середовища з точними storage ID, mountpoint і очікуваними опціями NFS/CIFS.
Стандартизуйте монтування: явна версія NFS, явний SMB-діалект/безпека, послідовні шляхи під /mnt/pve.
Зробіть порядок завантаження явним, коли сховище залежить від iSCSI/multipath, щоб активація LVM не змагалася з всесвітом.
Моніторьте правильне: відгук mount point (не тільки «чи змонтовано»), використання метаданих thin pool і повторювані помилки монтування в ядрі.

Зробіть це — і наступного разу, коли Proxmox пожалкується, це буде п’ятихвилинне виправлення, а не післяобіднє ритуальне перезавантаження і рулетка звинувачень.