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

Сначала восстановите iSCSI-сессию с pve1 на portal (плейсхолдер 10.0.10.30:3260): discovery, login, CHAP, затем видимость LUN и multipath. PVE storage (LVM на LUN или iscsi+lvm) оживёт после блока, не после vgcreate. Не инициализируйте LUN в GUI и не wipefs, пока lvs может показать vm-101-disk-0.

ICMP до СХД не равен iSCSI. Нужен TCP 3260 и успешный login.

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

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

  • pvesm status красный для LVM/iSCSI;
  • iscsiadm -m session пусто;
  • lsblk без привычного mpatha / sdb;
  • VM на SAN в D-state или не стартуют.

Отличия:

Что видноДругая проблемаКуда смотреть
NFS, не iSCSINAS fileNFS offline
Сессия есть, VG полныйthinLVM-thin
Сессия моргает, высокий waitканал/очередьIO wait
Только GUI, CLI сессия живаpvesm/cfgХранилище

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

  1. Portal недоступен: VLAN, firewall 3260, неверный IP.
  2. CHAP: сменили секрет на СХД, на pve1 старый.
  3. IQN узла не в ACL LUN.
  4. После ребута нет node.startup = automatic.
  5. Multipath: кривой bindings, черный список, один path flapping.
  6. LVM filter не видит mpath, VG не активируется.

Диагностика

pveversion
pvesm status
grep -A12 -E '^iscsi:|^lvm' /etc/pve/storage.cfg
iscsiadm -m session -P 1

Discovery и порт:

nc -vz 10.0.10.30 3260
iscsiadm -m discovery -t sendtargets -p 10.0.10.30

Если discovery пустой — сеть/portal, не CHAP (CHAP чаще на login).

dmesg | grep -iE 'iscsi|multipath|sd[a-z]' | tail
multipath -ll
pvs -o+uuid
lvs

Сверьте WWID LUN с документацией СХД. Смена WWID после клонирования LUN — новый диск для LVM, не «тот же VG».

Решение

Сценарий A. Нет TCP 3260

Чините маршрутизацию management-сети pve1 (10.0.10.11) до портала. Firewall: разрешить 3260/tcp к СХД, не disable firewall хоста навсегда.

Сценарий B. Discovery есть, login fails (CHAP)

Обновите CHAP user/secret в GUI storage / iscsid. Секрет в заявке не светите в общем чате. Повтор:

iscsiadm -m node -p 10.0.10.30 --login
iscsiadm -m session -P 1

Сценарий C. Login есть, LUN нет

ACL на СХД: IQN инициатора pve1 (см. /etc/iscsi/initiatorname.iscsi) должен совпадать с зарегистрированным. После маппинга rescan:

iscsiadm -m session --rescan
lsblk -o NAME,SIZE,WWN,TRAN

Сценарий D. Multipath

Добейтесь одного mpatha на LUN. Не собирайте VG на sd* при включённом multipathd. Если VG «пропал»:

vgscan
vgchange -ay
pvesm status

Сценарий E. Сессия не поднимается после ребута

Включите автологин node (node.startup = automatic для нужного target) так, как принято в вашем образе PVE 8, проверьте iscsid enabled. Не добавляйте второй iSCSI storage на тот же portal «с новым именем» — получите двойной login.

Фильтр LVM и rescan после login

После успешного login LUN может не стать PV, если global_filter в /etc/lvm/lvm.conf отвергает sd*/mpath. На PVE фильтр часто заточен под локальный VG pve и внешние multipath. Сверьте, виден ли PV:

lvmdevices 2>/dev/null || true
pvs -a
ls -l /dev/mapper/
iscsiadm -m session -P 3 | grep -E 'Target|Lun|Attached'

session -P 3 показывает, какой scsi-диск привязан к LUN. Если Attached scsi disk нет — проблема SCSI layer/ACL, не LVM. После правки ACL на СХД всегда rescan сессии, не reboot pve1 как первый шаг.

CHAP secrets в iscsid и в GUI PVE должны совпадать. Два разных секрета на discovery и login (если СХД так требует) документируйте; «один пароль везде» на части массивов не работает.

Не включайте node.startup = automatic на чужой target, найденный discovery в чужой VLAN: узел начнёт логиниться куда не надо после ребута. Оставляйте autostart только для WWN/IQN вашего LUN.

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

iscsiadm -m session -P 1
multipath -ll
pvs
lvs | grep 101
pvesm status
qm status 101

Сессия Logged in. WWID стабилен. PV на mpath (если multipath). pvesm active. VM 101 стартует или уже running без D-state. Ребут pve1 в окно — сессия возвращается сама (проверьте один раз).

После login сохраните вывод iscsiadm -m session -P 1 в заявку вместе с IQN из /etc/iscsi/initiatorname.iscsi. Без этих двух строк следующий дежурный снова начнёт с wipefs.

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

  • Login циклический: неверный CHAP, часы (реже), дубликат IQN другого хоста — два инициатора с одним IQN рвут сессию.
  • Высокий latency: очередь, 1 Гбит, кэш write-back СХД — не «чините» увеличением outstanding без понимания.
  • LUN read-only на СХД: snapshot/replica, не PVE.
  • Кластер: LUN должен быть доступен узлам, которым разрешён start VM; иначе миграция.
  • После замены СХД-контроллера сменился portal IP — обновите discovery, не создавайте параллельный target на старый IP.

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

  • Уникальный InitiatorName на каждый узел.
  • Два portal/path + рабочий multipath до продакшена.
  • Мониторинг сессий iscsiadm и pvesm.
  • CHAP не в git.
  • Документ: какой VG на каком WWID, какие VMID на нём.

FAQ

PVE storage тип iscsi vs LVM поверх iSCSI?

iscsi отдаёт raw LUN в VM (passthrough). Для многих VM на одном LUN обычно LVM/LVM-thin на этом LUN. Смотрите storage.cfg, не угадывайте.

Нужен ли node.session.timeo.replacement_timeout крутить при обрыве?

Сначала сеть и второй path. Заниженный timeout рвёт IO раньше, чем multipath переключится.

Можно ли логиниться с GUI и CLI одновременно дважды?

Двойной login в одну сессию путает. Один стек: либо PVE сам, либо вы отлаживаете iscsiadm, потом оставьте автологин согласованным.

systemctl restart iscsid на живых VM?

Рванёт IO. Только если сессии уже мертвы или VM остановлены.

Чем это отличается от NFS stale?

Блочное устройство vs файл. На iSCSI порча — VG/FS гостей; не лечится umount NFS.