Хранилище Proxmox недоступно: лечить backend, не Remove storage

Короткий ответ

Красный storage в Proxmox — это недоступный backend, а не команда удалить его из датацентра. Снимите pvesm status, жив ли pve-cluster (/etc/pve/storage.cfg), затем тип: LVM-thin, каталог, NFS, iSCSI, ZFSpool. Не делайте pvesm remove и не lvremove тома vm-101-disk-0, чтобы «пересоздать хранилище».

Сначала докажите, что данные на диске ещё есть (lvs, zfs list, ls каталога). GUI без списка образов не равен уничтоженным томам.

Симптомы и как отличить

Типичная картина:

• Datacenter → Storage: local-lvm / NFS серые;
• Start VM 101 — storage not online;
• pvesm list local-lvm ошибка;
• после ребута pve1 не активируется VG.

Отличия:

Возможные причины

1. pve-cluster не смонтировал storage.cfg — все типы «пропали» разом.
2. VG pve не активирован, thin pool не в V state.
3. rpool не импортирован, zfspool storage offline.
4. Сеть до NFS/iSCSI, после этого — см. профильные статьи.
5. Неверный nodes pve1 в storage.cfg после rename узла.
6. Права/путь directory storage, диск не примонтирован в /mnt.

Диагностика

pveversion
systemctl status pve-cluster --no-pager
pvesm status
cat /etc/pve/storage.cfg
pvecm status

Пустой или недоступный storage.cfg — чините pmxcfs, не LVM.

Для LVM:

pvs
vgs
lvs -a
lsblk

Для ZFS:

zpool status rpool
zfs list -r rpool

Для directory: mount | grep -E 'pve|mnt' и права каталога из path в cfg.

Решение

Сценарий A. pmxcfs

systemctl restart pve-cluster
pvesm status

Если нет кворума, /etc/pve read-only — quorum. Активация storage всё равно требует живой cfg.

Сценарий B. local-lvm / VG не активен

vgchange -ay pve
lvs
pvesm status

Если PV пропал — диск, контроллер, случайный wipefs. Не vgcreate pve на диске с существующими LV.

Заполненный thin — отдельная процедура, не remove.

Сценарий C. ZFS storage

Импортируйте rpool (см. импорт), затем:

zpool status rpool
pvesm status

Storage типа zfspool смотрит на dataset, не на «папку в GUI».

Сценарий D. Directory / backup disk не смонтирован

Верните строку в /etc/fstab, mount /mnt/backup, проверьте path в storage.cfg. Не указывайте новый пустой диск как тот же path, если на старом лежали vzdump.

Сценарий E. Ограничение nodes

В storage.cfg параметр nodes pve1 скрывает storage на pve2. Для shared NFS это ошибка конфига, не поломка массива. Добавьте узел явно, не удаляя секцию storage.

Инвентарь томов до любых GUI-действий

Пока storage красный, снимите карту «какая VM на каком volume». Это защищает от remove.

grep -R "scsi0:\|virtio0:\|sata0:" /etc/pve/qemu-server/ | sort
pvesm list local-lvm
pvesm list local
test -r /etc/pve/storage.cfg && awk '/^[^ ]/{print}' /etc/pve/storage.cfg

Сверяйте content в cfg: images для дисков VM, iso/backup/vztmpl для прочего. Storage с content backup не должен внезапно стать единственным местом дисков 101. Флаг shared 1 на LVM, который физически local к pve1, даёт ложное ощущение, что pve2 увидит тома — миграция тогда падает, а GUI «как будто shared».

Если pvesm status на pve1 зелёный, а на pve2 красный — это не «надо remove на втором», а доступность backend с того узла (iSCSI login, NFS export, ZFS import). Чините доступ, не дублируйте секцию storage с новым id.

После возврата online не запускайте сразу массовый Start всех VM: сначала 101 как канарейка, затем остальные. Иначе тонкий пул, едва ожив, снова упрётся в IO.

Как проверить, что проблема устранена

pvesm status
pvesm list local-lvm | grep 101
qm config 101
qm start 101
qm status 101

Все нужные storage active. Том vm-101-disk-0 в списке. VM стартует. В GUI содержимое ISO/backup на месте. lvs/zfs list совпадают с тем, что было до инцидента по размерам томов.

На pve1 после ремонта не забудьте pvesm status ещё раз через 30–60 секунд: pvestatd обновляет состояние не мгновенно. Ложный inactive сразу после vgchange -ay не повод снова трогать storage.cfg.

Если не помогло

• Один узел видит storage, второй нет: сеть, nodes, firewall, не «битый LVM».
• pvesm status ok, qm start нет тома: опечатка volume в 101.conf.
• После замены HBA изменились /dev/sdX: используйте /dev/disk/by-id в LVM/ZFS, не буквы.
• Ceph/RBD (если есть): не лечится командами local-lvm; смотрите мониторы Ceph отдельно.
• Подозрение, что LV удалили: stop, ищите backup PBS/vzdump, не lvcreate с тем же именем как «восстановление».

Профилактика

• Мониторинг pvesm status на каждом узле.
• Не держать единственные диски VM на самом хрупком NFS без кэша.
• Документировать, какой storage shared, какой local на pve1.
• Перед отключением полки — drain VM.
• Регулярный health-check.

FAQ

Чем Disable отличается от Remove в GUI?

Disable скрывает использование. Remove убирает запись storage. Данные на массиве могут остаться, но PVE перестанет их учитывать. Для ремонта Disable иногда уместен, Remove — нет.

Нужно ли pvesm set local-lvm --disable 0?

Если кто-то выключил storage галкой — да, это безопаснее remove. Сначала прочитайте текущие опции pvesm config local-lvm.

Почему local жив, а local-lvm нет?

Разные бэкенды: каталог на корне vs LVM. Корень мог загрузиться при мёртвом VG.

Можно ли переименовать storage, чтобы сбросить ошибку?

Переименование ломает все scsi0: oldname:... в конфигах VM. Не как метод ремонта.

Storage красный только в GUI, CLI зелёный?

Кэш браузера или другой узел в выпадающем списке. Смотрите pvesm status на том pve1, где VM.