Proxmox: помилка входу iSCSI — тарґет доступний, але LUN відсутній — як виправити

Що насправді означає «тарґет доступний, але немає LUN»

iSCSI — це дві окремі проблеми, що ходять під одним плащем:
транспорт (чи можу я дістатися порталу тарґета та автентифікуватися?) і
представлення (чи насправді тарґет представляє мені блочний пристрій, тобто LUN?).

«Тарґет доступний» означає, що відкриття працює або принаймні TCP-з’єднання на 3260 працює. Це не означає, що вам дозволено бачити LUN.
Часто це означає, що ви успішно поговорили з демоном тарґета, але він вирішив — правильно чи ні — що ви повинні отримати нуль пристроїв.

Заплутана частина: ініціатори, тарґети й графічні інтерфейси описуватимуть «немає LUN для вас» по-різному:

• Вхід не вдався: тарґет відхиляє сесію (невідповідність CHAP, IQN не дозволений, неправильна група порталів, невідповідний метод автентифікації).
• Вхід успішний, але диска немає: сесія встановлена, але LUN masking/ACL/мапінг перешкоджає відображенню будь-якого LUN-а.
• Диск з’являється, потім зникає: неправильне налаштування multipath, таймаути, флапінг шляхів або дивності ALUA/TPG.
• Proxmox показує сховище «OK», але нічого не придатне: ви додали iSCSI-строкаж, але забули другий шар (LVM/LVM-thin/ZFS поверх нього), або LUN — тільки для читання.

Ваше завдання — вирішити, який шар «бреше» вам. Потім виправляєте той шар, а не весь стек «на всякий випадок».

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

Якщо ви на виклику, потрібен шлях до істини за хвилини, а не духовна подорож по GUI.
Ось послідовність, що найшвидше знайде вузьке місце.

1) Перевірте, що тарґет дійсно доступний на правильній IP та порті

Переконайтеся, що ви дістаєтеся до потрібного порталу (правильний VLAN, правильний інтерфейс, без сюрпризів NAT), і що 3260 відкритий.
Якщо це провалюється — інше не має значення.

2) Виконайте discovery з вузла Proxmox за допомогою iscsiadm

Якщо discovery не працює — це DNS/маршрутизація/фаєрвол/налаштування порталу. Якщо discovery вдається — рухайтеся далі.

3) Залогінтесь вручну і перевірте сесії

Якщо вхід не вдається: CHAP, IQN ACL, метод автентифікації або невідповідність групи порталів.
Якщо вхід успішний: перевірте, чи було змеплено будь-які SCSI-пристрої.

4) Шукайте LUN-и: SCSI-скан + блочні пристрої

Якщо у вас є iSCSI-сесія, але немає /dev/sdX (або немає multipath-пристрою), тарґет не представляє LUN цьому ініціатору.
Це майже завжди LUN masking, відсутній мапінг або запис ACL, що вказує на неправильний IQN ініціатора.

5) Підтвердіть, що Proxmox налаштований для правильного типу сховища

Proxmox «iSCSI» сам по собі не є тим місцем, де живуть диски VM, якщо лише ви не робите прямі LUN-и. Більшість впроваджень поєднують iSCSI з LVM або LVM-thin.
Не «виправляйте» iSCSI, коли реальна проблема в очікуванні, що iSCSI поводиться як NFS.

6) Якщо є multipath — перевірте його перед тим, як винити масив

Ідеально змеплений LUN може все одно зникати через зломані налаштування multipath.
Переконайтеся, що бачите стабільні шляхи і один змеплений пристрій.

Цікаві факти (і трохи історії), що допомагають дебажити

• iSCSI стандартизований у 2004 році (RFC 3720). Це досить старо, щоб орендувати машину, що пояснює, чому багато масивів досі мають спадкові налаштування за замовчуванням.
• Discovery і login — різні кроки: SendTargets discovery може працювати навіть коли login заборонено ACL-ами.
• LUN masking існував до iSCSI: така ідея була й для Fibre Channel. Ваша проблема «немає LUN» — класична, просто у мережевому вигляді.
• Ідентичність ініціатора — це IQN (або EUI). IP допомагають, але тарґети зазвичай авторизують по IQN, бо IP брешуть, а DHCP — хаос.
• CHAP — опціональний, і багато середовищ досі працюють без нього — зазвичай тому, що хтось вирішив «ми в приватному VLAN» і потім забув його тримати приватним.
• ALUA існує через політику контролерів зберігання: деякі шляхи «оптимізовані», деякі — «неоптимізовані», і multipath потребує підказок, щоб уникнути повільних шляхів.
• Порт iSCSI за замовчуванням — 3260, але деякі прилади підтримують кілька порталів і біндінг портів; ви можете бути «доступні» на одному порталі і змеплені на іншому.
• Linux open-iscsi зберігає node records під /etc/iscsi/. Така стійкість зручна, доки не починає шкодити — застарілі записи викликають сучасні аварії.
• Proxmox не створює файлову систему на iSCSI LUN автоматично. Він залізе і залишить вас з питанням «що далі?».

Ментальна модель: портали, тарґети, сесії, LUN-и, ACL

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

Портал

Портал — це пара IP:порт, до якої ви підключаєтесь, зазвичай TCP 3260. Масиви зберігання можуть виставляти кілька порталів (на контролер, на VLAN, на інтерфейс).
«Доступний тарґет» часто означає «портал доступний».

Target IQN

Тарґет — це те, у що ви входите, ідентифікується IQN-ом, наприклад iqn.2020-01.example:storage.lun01.
Один тарґет може представляти кілька LUN-ів — або ж жодного — залежно від мапінгу.

Initiator IQN

Ваш вузол Proxmox (ініціатор) також має IQN, який знаходиться в /etc/iscsi/initiatorname.iscsi.
Тарґети зазвичай використовують цей IQN в ACL. Якщо IQN не збігається точно — ви для них чужинець.

Сесія vs LUN

Сесія — це увійдене з’єднання. LUN — це фактичний логічний блок SCSI, представлений через цю сесію.
Ви можете мати сесію з нульовими LUN-ами. Це не «зламана мережа», це «зламаний мапінг».

CHAP і ACL: дві замки, різні ключі

CHAP відповідає на питання «хто ви?», ACL відповідають «чи дозволено вам бачити цей LUN?». Ви можете пройти одне й провалити інше.
Деякі тарґети також мають автентифікацію по-порталу — бо один замок ніколи не був достатній.

Шарування сховища в Proxmox

Proxmox може:

• Використовувати iSCSI як транспорт для LVM або LVM-thin (найпоширеніше).
• Використовувати iSCSI для прямого призначення LUN-ів в VM (менш поширене, крихке).
• Комбінувати iSCSI з multipath (поширено у серйозних середовищах).

Якщо ви очікуєте, що iSCSI тарґет буде схожий на NFS «місце для файлів», ви будете ганятися за невірною проблемою годинами.

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

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

Завдання 1: Підтвердіть, який initiator IQN використовує Proxmox

cr0x@server:~$ cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1993-08.org.debian:01:9d3a3b21f9a7

Значення: Цей IQN — ваша ідентичність для тарґета. Якщо в ACL тарґета вказано інший IQN (поширено після клонування вузлів),
ви зможете або залогінитись і не побачити LUN-ів, або вас взагалі відкинуть.

Рішення: Порівняйте цей рядок точно з об’єктом ініціатора/хоста на тарґеті. Виправте ACL на тарґеті або змініть IQN ініціатора (рідко).

Завдання 2: Перевірте, що служба iSCSI запущена

cr0x@server:~$ systemctl status iscsid --no-pager
● iscsid.service - Open-iSCSI
     Loaded: loaded (/lib/systemd/system/iscsid.service; enabled)
     Active: active (running) since Thu 2025-12-26 09:12:01 UTC; 1h 3min ago

Значення: Якщо iscsid не запущений, discovery/login можуть поводитися непослідовно, особливо під час автоматичного старту.

Рішення: Якщо він inactive/failed — перегляньте логи і виправте службу перед редагуванням конфігурації сховища.

Завдання 3: Підтвердьте базову доступність до правильного IP порталу

cr0x@server:~$ ping -c 2 10.10.20.50
PING 10.10.20.50 (10.10.20.50) 56(84) bytes of data.
64 bytes from 10.10.20.50: icmp_seq=1 ttl=64 time=0.410 ms
64 bytes from 10.10.20.50: icmp_seq=2 ttl=64 time=0.392 ms

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

Значення: ICMP працює. Це не доказ успіху iSCSI, але відкидає найпростіші проблеми з маршрутизацією.

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

Завдання 4: Підтвердіть доступність TCP/3260

cr0x@server:~$ nc -vz 10.10.20.50 3260
Connection to 10.10.20.50 3260 port [tcp/iscsi-target] succeeded!

Значення: Портал доступний на транспортному рівні.

Рішення: Якщо це не вдається — перевірте правила фаєрвола, слухаючі IP на сторінці сховища та чи не потрапили ви на неправильний VLAN/інтерфейс.

Завдання 5: Виконайте discovery з ініціатора

cr0x@server:~$ iscsiadm -m discovery -t sendtargets -p 10.10.20.50
10.10.20.50:3260,1 iqn.2023-10.lab:truenas.target01

Значення: Тарґет відповідає на discovery і рекламує IQN тарґета.

Рішення: Якщо discovery нічого не повертає — виправте налаштування порталу/discovery на тарґеті. Якщо повертає тарґет — переходьте до входу.

Завдання 6: Спробуйте вручну залогінитися і подивіться реальну помилку

cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 --login
Logging in to [iface: default, target: iqn.2023-10.lab:truenas.target01, portal: 10.10.20.50,3260]
Login to [iface: default, target: iqn.2023-10.lab:truenas.target01, portal: 10.10.20.50,3260] successful.

Значення: Сесія встановлена. Чудово. Тепер перевірте, чи з’явилися LUN-и.

Рішення: Якщо ви бачите «authorization failure» або «login failed» — переходьте до перевірки CHAP/IQN ACL.

Завдання 7: Перелічіть iSCSI-сесії (чи дійсно є сесія?)

cr0x@server:~$ iscsiadm -m session
tcp: [1] 10.10.20.50:3260,1 iqn.2023-10.lab:truenas.target01 (non-flash)

Значення: Якщо тут порожньо — ви не залогінені. Якщо присутнє — проблема «немає LUN» швидше за все в мапінгу/ACL.

Рішення: При наявній сесії припиніть модифікувати правила фаєрвола і почніть перевіряти презентацію LUN.

Завдання 8: Перевірте kernel-повідомлення про результати SCSI-discovery

cr0x@server:~$ dmesg -T | tail -n 25
[Thu Dec 26 10:18:44 2025] scsi host12: iSCSI Initiator over TCP/IP
[Thu Dec 26 10:18:44 2025] scsi 12:0:0:0: Direct-Access     LIO-ORG  lun01            4.0  PQ: 0 ANSI: 5
[Thu Dec 26 10:18:44 2025] sd 12:0:0:0: Attached scsi generic sg3 type 0
[Thu Dec 26 10:18:44 2025] sd 12:0:0:0: [sdc] 209715200 512-byte logical blocks: (107 GB/100 GiB)
[Thu Dec 26 10:18:44 2025] sd 12:0:0:0: [sdc] Write Protect is off
[Thu Dec 26 10:18:44 2025] sd 12:0:0:0: [sdc] Mode Sense: 43 00 00 00
[Thu Dec 26 10:18:44 2025] sd 12:0:0:0: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA

Значення: Це щасливий випадок: тарґет представив LUN і Linux створив /dev/sdc.

Рішення: Якщо ви бачите сесію, але немає рядків «Direct-Access», тарґет представляє нуль LUN-ів. Виправляйте мапінг/ACL на тарґеті.

Завдання 9: Перелічіть блочні пристрої і підтвердіть існування iSCSI-диска

cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,MODEL,SERIAL,TRAN
NAME     SIZE TYPE MODEL            SERIAL               TRAN
sda     447.1G disk Samsung_SSD     S6Z2NX0R123456       sata
├─sda1      1G part                                   sata
└─sda2  446.1G part                                   sata
sdc       100G disk LIO-ORG_lun01    1234567890abcdef   iscsi

Значення: Диск з TRAN = iscsi існує. Якщо жоден не з’являється — у вас немає LUN-а.

Рішення: Якщо диск є, але Proxmox не може його використовувати — піднімайтеся в стек (multipath, LVM, конфігурація Proxmox storage).

Завдання 10: Перевірте SCSI-шлях та ID LUN

cr0x@server:~$ lsscsi -tv
[12:0:0:0] disk LIO-ORG  lun01 4.0 /dev/sdc
  state=running

Значення: Ви бачите кортеж host:bus:target:lun. Якщо бачите host-и, але немає записів LUN — знову: мапінг.

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

Завдання 11: Перевірте node records open-iscsi (застаріла конфігурація кусає)

cr0x@server:~$ iscsiadm -m node
iqn.2023-10.lab:truenas.target01 10.10.20.50:3260,1 default

Значення: Node records зберігаються. Якщо ви змінили CHAP-облікові дані на тарґеті, але не тут — вхід назавжди буде невдалим з упевненістю.

Рішення: Якщо запис вказує на старі портали або неправильний iface — оновіть або видаліть node record і повторно виконайте discovery.

Завдання 12: Перевірте CHAP-налаштування для node

cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 -o show | egrep 'auth|username|password'
node.session.auth.authmethod = CHAP
node.session.auth.username = proxmox01
node.session.auth.password = ********

Значення: Метод автентифікації і користувач встановлені. Якщо тарґет очікує «None», а ви примушуєте CHAP — вхід провалиться. Якщо паролі відрізняються — вхід провалиться.

Рішення: Вирівняйте конфігурацію ініціатора з налаштуваннями тарґета. Не «перевіряйте випадкові комбінації»; ставтеся до цього як до SSH-ключів, а не торгового автомата.

Завдання 13: Виправте CHAP-значення (і знайте, що ви їх змінили)

cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 --op=update -n node.session.auth.authmethod -v CHAP
cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 --op=update -n node.session.auth.username -v proxmox01
cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 --op=update -n node.session.auth.password -v 'CorrectHorseBatteryStaple'

Значення: Ви оновили персистентний node record.

Рішення: Повторно залогіньтесь і перевірте сесії та LUN-и. Якщо LUN і далі відсутній — причина в мапінгу/ACL, а не в CHAP.

Завдання 14: Вийдіть і зайдіть знову (чистий стан)

cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 --logout
Logging out of session [sid: 1, target: iqn.2023-10.lab:truenas.target01, portal: 10.10.20.50,3260]
Logout of [sid: 1, target: iqn.2023-10.lab:truenas.target01, portal: 10.10.20.50,3260] successful.
cr0x@server:~$ iscsiadm -m node -T iqn.2023-10.lab:truenas.target01 -p 10.10.20.50 --login
Logging in to [iface: default, target: iqn.2023-10.lab:truenas.target01, portal: 10.10.20.50,3260]
Login to [iface: default, target: iqn.2023-10.lab:truenas.target01, portal: 10.10.20.50,3260] successful.

Значення: Ви примусили нові переговори та рескан.

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

Завдання 15: Якщо очікується multipath — підтвердіть, що він не причина «зникнення» LUN

cr0x@server:~$ systemctl status multipathd --no-pager
● multipathd.service - Device-Mapper Multipath Device Controller
     Loaded: loaded (/lib/systemd/system/multipathd.service; enabled)
     Active: active (running) since Thu 2025-12-26 09:20:10 UTC; 55min ago

Значення: Демон multipath запущений.

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

Завдання 16: Перевірте multipath-мапінг

cr0x@server:~$ multipath -ll
mpatha (36001405f2a3b4c5d6e7f890123456789) dm-3 LIO-ORG,lun01
size=100G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=1 status=active
| `- 12:0:0:0 sdc 8:32 active ready running
`-+- policy='service-time 0' prio=1 status=enabled
  `- 13:0:0:0 sdd 8:48 active ready running

Значення: У вас один multipath-пристрій (/dev/mapper/mpatha) підкріплений двома шляхами. Це бажаний стан.

Рішення: Використовуйте multipath-пристрій для LVM/LVM-thin; уникайте використання /dev/sdc напряму, інакше ви створите майбутній вибір-життя-або-смерті.

Завдання 17: Перевірте дублікати SCSI-пристроїв, коли multipath не налаштований

cr0x@server:~$ ls -l /dev/disk/by-path/ | egrep 'iscsi|ip-10.10.20'
lrwxrwxrwx 1 root root  9 Dec 26 10:19 ip-10.10.20.50:3260-iscsi-iqn.2023-10.lab:truenas.target01-lun-0 -> ../../sdc
lrwxrwxrwx 1 root root  9 Dec 26 10:19 ip-10.10.20.51:3260-iscsi-iqn.2023-10.lab:truenas.target01-lun-0 -> ../../sdd

Значення: Два портали, два /dev/sdX пристрої. Без multipath це два незалежні диски з точки зору Linux, навіть якщо це один LUN.

Рішення: Увімкніть і налаштуйте multipath перед створенням LVM або файлових систем, інакше ви ризикуєте зіпсувати дані.

Завдання 18: Перевірте посилання конфігурації сховища Proxmox

cr0x@server:~$ grep -nE 'iscsi|lvm|lun|portal|target' /etc/pve/storage.cfg
12:iscsi: iscsi-san
13:        portal 10.10.20.50
14:        target iqn.2023-10.lab:truenas.target01
15:lvmthin: vmdata
16:        vgname vg_iscsi_vmdata
17:        thinpool data
18:        content images,rootdir

Значення: Proxmox розділяє iSCSI-транспорт (стаза «iscsi») від фактичного VM-сховища (LVM-thin на VG).

Рішення: Якщо у вас лише stanza iSCSI, але немає шару LVM/LVM-thin/ZFS — це неповна конфігурація, а не баг входу.

Завдання 19: Підтвердіть існування volume group на iSCSI/multipath-пристрої (якщо використовуєте LVM)

cr0x@server:~$ pvs
PV                  VG              Fmt  Attr PSize   PFree
/dev/mapper/mpatha  vg_iscsi_vmdata lvm2 a--  100.00g 20.00g

Значення: LVM бачить диск і він використовується як PV, що означає — LUN видимий і стабільний.

Рішення: Якщо pvs нічого не показує — або немає LUN-а, або немає multipath-пристрою, або ви не ініціалізували диск. Виберіть правильне виправлення.

Завдання 20: Подивіться логи iSCSI за реальну причину відмови

cr0x@server:~$ journalctl -u iscsid -n 80 --no-pager
Dec 26 10:05:11 server iscsid[1243]: iSCSI daemon started
Dec 26 10:06:02 server iscsid[1243]: connection1:0 login rejected: Initiator failed authentication with target
Dec 26 10:06:02 server iscsid[1243]: connection1:0 login failed to authenticate with target iqn.2023-10.lab:truenas.target01

Значення: Помилка автентифікації. Це CHAP або невідповідність режиму автентифікації на тарґеті, а не «немає мапінгу LUN».

Рішення: Виправте CHAP-облікові дані та метод автентифікації перш ніж займатися мапінгом LUN.

Особливості Proxmox: iSCSI-строкажі проти LVM поверх iSCSI (і де люди губляться)

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

Патерн A (поширений): iSCSI + LVM-thin

Ви підключаєте хост до LUN-а, потім будуєте LVM VG і thin pool поверх нього. Proxmox зберігає диски VM як логічні томи.
Це шлях, яким йдуть більшість, бо він ефективний, підтримуваний і відносно передбачуваний.

Якщо ви бачите «тарґет доступний, але немає LUN», ви застрягли в самому низу: Proxmox навіть не бачить блочний пристрій, щоб створити PV.

Патерн B (менш поширений): прямий LUN на VM

Ви представляєте декілька LUN-ів і змеплюєте їх напряму, часто для баз даних або коли потрібні нативні знімки/реплікація від масиву.
Це вимагає дисциплінованого мапінгу LUN і найменування, інакше ви приєднаєте невірний LUN до невірної VM і матимете поганий вечір.

Кластер Proxmox: кожен вузол має бути дозволений

Якщо ви в кластері і хочете, щоб будь-який вузол міг запускати VM, кожен вузол має бачити одне й те саме бекенд-сховище.
«Працює на node1» — це пастка. Це означає лише те, що IQN node1 внесено до ACL тарґета.

Жарт №1: iSCSI — як офісна безпека: ваш бейдж працює чудово до моменту, коли перестає, а потім це раптом ваша проблема.

Де ламається: реальні кореневі причини помилок «login failed» і «немає LUN»

1) Невірний initiator IQN (або клоновані вузли з однаковими IQN)

Вузли Proxmox, створені з шаблонів, часто успадковують однаковий InitiatorName. Тарґети бачать два хости, що претендують на однакову ідентичність.
У найкращому випадку один працює, інший вигнано. У гіршому — вони по черзі крадуть сесію й ви отримуєте переривчасті таймаути сховища.

Виправляйте це, генеруючи унікальні IQN для кожного вузла і оновлюючи ACL тарґета відповідно. Не «дозволяйте всім ініціаторам» бездумно, якщо вам важливі пояснення потім.

2) Невідповідність CHAP або CHAP вмикається на одній стороні, але не на другій

Масиви та стеки тарґетів відрізняються: деякі вимагають CHAP на рівні тарґета, деякі — на порталі, деякі — на групі ініціаторів. Proxmox зберігає CHAP в node record.
Якщо хтось оновив облікові дані на масиві й забув оновити Proxmox — відмова гарантована.

3) LUN існує, але не змеплено для цього ініціатора (класика)

Адмін тарґета створив том/екстент і навіть тарґет IQN. Але він не змепив LUN до групи хостів/ініціаторів або змепив до неправильної групи.
Discovery бачить тарґет, вхід може вдаватись, і ви все одно бачите нуль пристроїв.

Це найпоширеніша причина «тарґет доступний, але немає LUN». І це найпростіше виправити, саме тому це так дратує.

4) Невідповідність груп порталів / біндінг мережі

Багато масивів мають кілька portal group. Ви можете логінитись на 10.10.20.50, але мапінг LUN застосований до portal group на 10.10.30.50.
Або тарґет прив’язаний до одного інтерфейсу, а discovery потрапляє на іншу сервісну IP, яка той тарґет не обслуговує.

5) ALUA/multipath-дивності, що виглядають як «немає LUN»

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

6) Застарілі записи initiator, що вказують на стару конфігурацію тарґета

Якщо ви змінили IQN тарґета, портали або вимоги автентифікації, open-iscsi може продовжувати пробувати старі налаштування.
Видалення і повторне discovery node records іноді — найчистіше вирішення — обережно, у вікні обслуговування і з розумінням, які VM використовують LUN.

7) Proxmox очікує LVM-thin, а ви представили LUN з уже існуючою файловою системою

Ви можете представити LUN, на якому вже є щось (старі метадані LVM, залишкові розділи). Proxmox може відмовитись ініціалізувати, або — що гірше — ви ініціалізуєте невірний диск.
Якщо ви мігруєте — будьте явними щодо плану: імпорт чи реініціалізація.

Цитата (переказана ідея) від Werner Vogels (Amazon): «Все постійно ламається; проєктуйте й експлуатуйте з цим припущенням.» — Werner Vogels, переказана ідея

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

Симптом: Discovery працює, вхід провалюється з «authorization failure»

Коренева причина: Невідповідність CHAP або тарґет вимагає CHAP, а ініціатор встановлений на None (або навпаки).

Виправлення: Узгодьте метод автентифікації і облікові дані з обох сторін. Перевірте з journalctl -u iscsid і iscsiadm -m node -o show.

Симптом: Вхід успішний, iscsiadm -m session показує сесію, але lsblk не показує iSCSI-диска

Коренева причина: LUN не змеплено для цього initiator IQN, або LUN masking забороняє доступ.

Виправлення: На тарґеті змепіть LUN/екстент до правильної групи ініціаторів/ACL і переконайтесь, що ID LUN увімкнено. Потім виконати rescan або повторний логін.

Симптом: Працює на одному вузлі Proxmox, на іншому в тому ж кластері — ні

Коренева причина: ACL тарґета включає лише один initiator IQN. Або вузли мають однаковий IQN через клонування.

Виправлення: Надайте кожному вузлу унікальний initiator IQN і додайте всі вузли до групи ініціаторів тарґета. Перевірте сесії з кожного вузла.

Симптом: З’являються два диски для одного LUN (/dev/sdc і /dev/sdd), Proxmox плутається

Коренева причина: Два портали без multipath; Linux бачить два незалежні SCSI-пристрої.

Виправлення: Налаштуйте multipath правильно і використовуйте /dev/mapper/mpathX пристрої для LVM. Заблокуйте локальний диск від multipath.

Симптом: LUN з’являється, потім зникає через хвилини або під навантаженням

Коренева причина: Невідповідність MTU/jumbo frames, флапінг шляхів або надто агресивні таймаути.

Виправлення: Перевірте MTU наскрізь, перевірте лічильники свічів і перегляньте таймаути iSCSI. Стабілізуйте мережу перш ніж тонко налаштовувати продуктивність.

Симптом: Proxmox UI показує iSCSI-сховище «OK», але ви не можете створити VM-диски там

Коренева причина: Ви додали тільки iSCSI-транспорт, але не створили LVM/LVM-thin поверх нього (або не змепили LUN).

Виправлення: Переконайтесь, що iSCSI LUN існує як блочний пристрій, потім створіть PV/VG/thinpool і додайте LVM-thin в Proxmox.

Симптом: Вхід не вдається тільки після перезавантаження

Коренева причина: Проблеми з порядком запуску, неправильний бінд інтерфейсу, або відсутні node.startup налаштування для iSCSI.

Виправлення: Переконайтесь, що мережа піднята перед iSCSI-login, і встановіть автоматичний старт node де потрібно. Підтвердіть через systemd-логи.

Симптом: Ви бачите LUN, але він тільки для читання

Коренева причина: Режим мапінгу тільки для читання на тарґеті, експорт зі знімка/клона або конфлікти SCSI-резервацій.

Виправлення: Виправте режим мапінгу на масиві; перевірте наявність стійких резервувань якщо задіяний кластер.

Три корпоративні міні-історії з передової

Інцидент через неправильне припущення: «Discovery означає, що воно змеплено»

Середня компанія мігрувала з NFS на iSCSI заради «кращої продуктивності» (що було правдою, але неповною). Адмін сховища створив тарґет,
подав його на правильному VLAN і надіслав IQN команді віртуалізації. Вони додали його в Proxmox і побачили тарґет у discovery.
Всі заспокоїлися. Звісно, вікно технічного обслуговування перетворилося на понаднормову роботу.

Вузли Proxmox могли залогінитись, але ніколи не з’являвся LUN. Команда віртуалізації вирішила, що це баг ініціатора, бо «ми можемо дістатись тарґета».
Вони годину налаштовували CHAP, перезапускали служби і повторно додавали сховище в GUI — операційний еквівалент струшування принтера.

Справжня проблема: LUN існував, але був змеплений до групи ініціаторів, що містила неправильний IQN — старий ESXi хост з виведеного кластера.
Discovery усе ще повертав тарґет, бо discovery було відкрите. Вхід працював, бо CHAP вимкнено. Але LUN masking зробив свою роботу і нічого не показав.

Виправлення зайняло дві хвилини: додати правильні initiator IQN-и до мапінгу і зробити рескан. Урок тривав довше:
перестаньте використовувати успішне discovery як доказ доступного сховища. Розглядайте його як DNS: корисний, але не авторитетний.

Оптимізація, що обернулась проти: jumbo frames без терпіння

Інша команда мала iSCSI в роботі, але хотіла менше CPU і кращу пропускну здатність. Хтось увімкнув MTU 9000 на NIC-ах сховища і NIC-ах Proxmox.
Вони не чіпали свічі, бо свічі «вже конфігуровані для jumbo десь». Те «десь» виявилося іншим набором портів.

Результат не був миттєвим. Це найгірше. Discovery працювало. Вхід працював. LUN-и з’являлись.
Під навантаженням — бекапи VM, перевірки дисків або завантажена база — шляхи почали падати. Multipath переключався, потім знову, потім помічав шляхи як dead.
VM зависали так, ніби це були баги гостьової ОС.

Команда гналася за примарами: версії ядра Proxmox, налаштування multipath, «можливо масив перевантажений». Тим часом мережні лічильники казали нудну правду:
фрагментація, втрата пакетів і періодичне чорніння великих кадрів. iSCSI чутливий до втрат і стрибків латентності; це блоковий I/O, а не випадкова копія файлу.

Виправлення було не гламурним: забезпечити сталий MTU наскрізь, або тримати MTU 1500 всюди. Вони обрали другий варіант для простоти,
і продуктивність лишилася прийнятною — бо стабільність швидша за теоретичну швидкість.

Нудна, але правильна практика, що врятувала день: явні групи хостів і pre-flight тест

Дисциплінована команда мала правило: кожен новий вузол Proxmox має пройти storage pre-flight перед приєднанням до кластера.
Pre-flight включав перевірку унікального initiator IQN, підтвердження, що він є в групі ініціаторів масиву, та логін на всі портали.
Вони також вимагали тестового LUN-мепінгу, який можна безпечно приєднати і від’єднати.

Якось заміна вузла приїхала в терміновому режимі. Він був зібраний зі старого образу. iSCSI IQN дублювався.
Якби вони додали його прямо до кластера, він змагався б із наявним вузлом за сесії і, ймовірно, спричинив би ресети шляхів.

Pre-flight це відразу виявив. Вони генерували новий initiator IQN, оновили мапінг групи хостів і тільки тоді приєднали вузол.
Ніякого простою. Ніякої драми. Кращий інцидент — це той, за який вам не приходить оповіщення.

Жарт №2: Єдина річ більш наполеглива, ніж iSCSI node records — це людина, що наполягає «в лабораторії працювало».

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

Покроково: виправити «тарґет доступний, але немає LUN» (найпоширеніший випадок)

1. Підтвердьте стан сесії:
   запустіть iscsiadm -m session. Якщо немає сесії — у вас проблема входу; переходьте до кроків по автентифікації/ACL.
2. Підтвердьте initiator IQN:
   перевірте /etc/iscsi/initiatorname.iscsi. Переконайтесь, що він точно збігається з ACL тарґета.
3. Перевірте наявність LUN-пристроїв:
   запустіть lsblk -o NAME,TRAN,MODEL,SIZE і dmesg -T. Якщо немає iSCSI-диска — у вас проблема мапінгу.
4. Виправте мапінг на тарґеті:
   змепіть LUN/екстент до групи ініціаторів, що містить IQN(и) ваших вузлів Proxmox. Переконайтесь, що ID LUN увімкнено і не фільтрується.
5. Повторний вхід або рескан:
   logout/login з iscsiadm. Підтвердіть появу блочного пристрою.
6. Лише після цього налаштовуйте шари Proxmox:
   створіть PV/VG/thinpool, якщо використовуєте LVM-thin, потім додайте LVM-thin у Proxmox.

Покроково: виправити «login failed» (клас помилок auth/ACL)

1. Підтвердьте TCP-доступність: nc -vz <portal> 3260.
2. Підтвердьте discovery: iscsiadm -m discovery -t sendtargets -p <portal>.
3. Прочитайте логи демона: journalctl -u iscsid -n 100 і зафіксуйте точну причину.
4. Перевірте CHAP-конфіг: iscsiadm -m node -o show і узгодьте з налаштуваннями тарґета.
5. Перевірте, чи дозволено initiator IQN: перевірте ACL/групу хостів на тарґеті. Не покладайтеся на IP-правила, якщо вам не подобається неоднозначність.
6. Видаліть застарілі node-entries за потреби: видаляйте лише релевантний node record, повторно відкрийте discovery і налаштуйте автентифікацію.

Покроково: готовність Proxmox-кластера для iSCSI

1. Кожен вузол має унікальний IQN (перевірити на кожному вузлі).
2. ACL тарґета включає всі IQN вузлів, що можуть запускати VM.
3. Multipath налаштований, якщо у вас кілька порталів/контролерів.
4. Використовуйте стабільні імена пристроїв: надавайте перевагу WWID multipath або /dev/disk/by-id посиланням; уникайте сирих /dev/sdX.
5. Тестуйте відмовостійкість: відключіть один шлях і переконайтесь, що I/O триває (обережно, з безпечним тестовим томом).

FAQ

1) Чому я можу відкрити discovery тарґета, але не бачу жодних LUN-ів?

Тому що discovery — це лише «які тарґети тут існують?». Видимість LUN-ів контролюється мапінгом і ACL. Discovery може бути відкритим, поки LUN-и заблоковані.

2) Якщо вхід успішний, хіба це не доводить, що LUN змеплено?

Ні. Вхід доводить, що сесія встановлена. Мапінг LUN — це окремий крок. Сесія з нульовими LUN-ами — нормальний стан, якщо masking забороняє доступ.

3) Proxmox каже, що iSCSI-сховище онлайн, але я не можу зберігати там образи VM. Чому?

Proxmox «iSCSI» зазвичай — лише визначення транспорту. Вам зазвичай потрібен LVM або LVM-thin зверху, щоб зберігати диски VM.
Додайте iSCSI тарґет, потім створіть VG/thin pool і додайте LVM-thin у Proxmox.

4) Чи потрібен мені multipath?

Якщо у вас кілька портів/контролерів і ви очікуєте відмовостійкість — так. Без multipath ви можете отримати дублікати пристроїв або збої шляхів, що виглядають як випадкові проблеми з дисками.
Якщо у вас справді один портал і один шлях — multipath необов’язковий, але часто використовується для уніфікації конфігурацій.

5) Який найшвидший спосіб довести, що це проблема мапінгу, а не Proxmox?

На вузлі: якщо iscsiadm -m session показує сесію, але lsblk не показує iSCSI-диска і dmesg не показує приєднання SCSI-диска,
тарґет не представляє LUN-и для вас. Це мапінг/ACL.

6) Чи можуть два вузли Proxmox мати однаковий initiator IQN?

Не рекомендовано. Деякі тарґети потерпають це довго, поки не перестають. Ви отримаєте крадіжки сесій, дивні поведінки резервацій і переривчасті ресети.
Робіть IQN унікальними для кожного вузла, завжди.

7) Чи варто використовувати CHAP?

Так, якщо можете. Це не досконала захист, але перешкоджає випадковому перехресному доступу між ініціаторами і тарґетами в спільних мережах.
Якщо ви відмовляєтесь від CHAP — компенсуйте це суворою VLAN-ізоляцією і дисципліною ACL.

8) Я змінив CHAP-облікові дані на масиві. Чому Proxmox цього не підхопив?

open-iscsi зберігає налаштування node. Потрібно оновити node record (або повторно виконати discovery і налаштувати заново).
Перевірте з iscsiadm -m node -o show.

9) Чому я бачу LUN як /dev/sdc при одному завантаженні, а як /dev/sdd при іншому?

Linux динамічно привласнює імена /dev/sdX. Використовуйте /dev/disk/by-id або multipath-пристрої для стійкої конфігурації, а не сирі /dev/sdX.

10) Чи може «немає LUN» бути спричинено самим Proxmox?

Рідко. Proxmox використовує Linux iSCSI-стек. Якщо Linux не бачить LUN — Proxmox теж не побачить. Зосередьтеся на конфігурації ініціатора/тарґета, а не на UI.

Висновок: наступні кроки, щоб уникнути повторення

Коли Proxmox каже «iSCSI login failed» або ви маєте доступний тарґет без LUN-ів, стримуйте бажання метушитися.
Доведіть, який шар падає: транспорт, автентифікація чи презентація.

• По-перше: перевірте досяжність і discovery (nc, iscsiadm -m discovery).
• По-друге: підтвердіть вхід і прочитайте реальну помилку (iscsiadm --login, journalctl -u iscsid).
• По-третє: перевірте презентацію LUN (dmesg, lsblk, lsscsi).
• Потім: тільки після появи блочного пристрою — створюйте шар Proxmox (LVM/LVM-thin) і, при потребі, multipath.

Операційно, найкраще виправлення — політика: унікальні IQN для кожного вузла, явні групи ініціаторів на тарґеті та pre-flight перевірка перед приєднанням вузла до кластера.
Це нудно. Це працює. Production зазвичай віддає перевагу цим двом якостям.