Proxmox iSCSI inicio de sesión falló: target accesible pero sin LUN — cómo solucionarlo

Qué significa realmente “target accesible pero sin LUN”

iSCSI son dos problemas separados bajo un mismo abrigo:
transporte (¿puedo alcanzar el portal del target y autenticarme?) y
presentación (¿me presenta el target realmente un dispositivo de bloque, es decir, un LUN?).

“Target accesible” significa que el descubrimiento funciona o al menos que la conexión TCP al puerto 3260 funciona. No significa que tengas permiso para ver un LUN.
A menudo significa que has hablado con el demonio del target, pero este ha decidido—correcta o incorrectamente—que debes obtener cero dispositivos.

La parte confusa: iniciadores, targets y GUIs describen “sin LUN para ti” de formas distintas:

• Login falla: el target rechaza la sesión (desajuste CHAP, IQN no permitido, grupo de portal equivocado, método de autenticación distinto).
• Login exitoso, sin disco: la sesión está activa pero el enmascaramiento/mapeo de LUN/ACL impide que se exponga cualquier LUN.
• El disco aparece y luego desaparece: mala configuración de multipath, timeouts, fluctuación de rutas, o rarezas de ALUA/TPG.
• Almacenamiento en Proxmox “OK” pero nada usable: añadiste un almacenamiento iSCSI pero olvidaste la capa superior (LVM/LVM-thin/ZFS sobre él), o el LUN está en modo solo lectura.

Tu trabajo es decidir qué capa te está engañando. Entonces arreglas esa capa, no toda la pila “por si acaso”.

Guion de diagnóstico rápido (haz esto primero)

Si estás de guardia, quieres un camino a la verdad que tome minutos, no un viaje espiritual por GUIs.
Aquí está la secuencia que encuentra el cuello de botella más rápido.

1) Verifica que el target sea realmente alcanzable en la IP y puerto correctos

Comprueba que estás alcanzando el portal previsto (VLAN correcta, interfaz correcta, sin sorpresa de NAT), y que 3260 está abierto.
Si esto falla, nada más importa.

2) Descubre targets desde el nodo Proxmox con iscsiadm

Si el descubrimiento falla, es DNS/ruteo/firewall/configuración del portal. Si el descubrimiento tiene éxito, continúa.

3) Inicia sesión manualmente y verifica las sesiones

Si el login falla: CHAP, ACL de IQN, método de autenticación o desajuste de grupo de portal.
Si el login tiene éxito: inspecciona si se mapearon dispositivos SCSI.

4) Busca LUNs: escaneo SCSI + dispositivos de bloque

Si tienes una sesión iSCSI pero no /dev/sdX (o ningún dispositivo de multipath), el target no te está presentando un LUN.
Eso casi siempre es enmascaramiento de LUN, mapeo faltante o una entrada ACL que existe pero apunta al IQN de iniciador equivocado.

5) Confirma que Proxmox está configurado para el tipo de almacenamiento correcto

El almacenamiento “iSCSI” en Proxmox por sí solo no es donde viven los discos de VM a menos que hagas LUNs directos. La mayoría de despliegues emparejan iSCSI con LVM o LVM-thin.
No “arregles” iSCSI cuando el problema real es que esperabas que iSCSI se comportara como NFS.

6) Si hay multipath involucrado, verifícalo antes de culpar al array

Un LUN perfectamente mapeado aún puede desaparecer detrás de ajustes rotos de multipath.
Confirma que ves rutas estables y un dispositivo mapeado.

Hechos interesantes (y un poco de historia) que te ayudan a depurar

• iSCSI se estandarizó en 2004 (RFC 3720). Eso tiene suficiente antigüedad como para alquilar un coche, lo que explica por qué muchos arrays siguen con valores por defecto heredados.
• Descubrimiento e inicio de sesión son pasos distintos: SendTargets discovery puede funcionar incluso cuando el login está prohibido por ACLs.
• El enmascaramiento de LUN precede a iSCSI: la misma idea existía en Fibre Channel. Tu problema de “sin LUN” es clásico, solo que sobre Ethernet.
• La identidad del iniciador es el IQN (o EUI). Las IP ayudan, pero los targets normalmente autorizan por IQN porque las IPs mienten y DHCP es caos.
• CHAP es opcional, y muchos entornos aún funcionan sin él—generalmente porque alguien decidió “estamos en una VLAN privada” y luego olvidó mantenerla privada.
• ALUA existe porque los controladores de almacenamiento son políticos: algunas rutas son “optimizadas” y otras “no optimizadas”, y multipath necesita pistas para evitar rutas lentas.
• El puerto por defecto de iSCSI es 3260, pero algunos appliances soportan múltiples portals y binding de puertos; puedes ser “alcanzable” en un portal y estar mapeado en otro.
• Linux open-iscsi guarda registros de nodo bajo /etc/iscsi/. Esa persistencia es conveniente hasta que no lo es—los registros obsoletos causan incidentes muy modernos.
• Proxmox no crea mágicamente un sistema de ficheros en un LUN iSCSI. Conectará con gusto y aún te dejará con “¿y ahora qué?”.

Modelo mental: portals, targets, sesiones, LUNs, ACLs

Al depurar, usa un vocabulario estricto. Evita las conversaciones de “lo arreglamos” donde nadie acuerda qué es “eso”.

Portal

Un portal es un par IP:puerto al que te conectas, típicamente TCP 3260. Los arrays pueden exponer múltiples portals (por controlador, por VLAN, por interfaz).
“Target alcanzable” a menudo significa “portal alcanzable”.

Target IQN

El target es la entidad a la que inicias sesión, identificada por un IQN como iqn.2020-01.example:storage.lun01.
Un target puede exponer múltiples LUNs—o ninguno—dependiendo del mapeo.

Iniciador IQN

Tu nodo Proxmox (el iniciador) también tiene un IQN, que se encuentra en /etc/iscsi/initiatorname.iscsi.
Los targets usan comúnmente ese IQN en las listas de control de acceso (ACLs). Si el IQN no coincide exactamente, eres un extraño.

Sesión vs LUN

Una sesión es una conexión con login. Un LUN es una unidad lógica SCSI presentada a través de esa sesión.
Puedes tener una sesión con cero LUNs. Eso no es “red rota”; es “mapeo roto”.

CHAP y ACLs: dos cerraduras, llaves distintas

CHAP responde “¿quién eres?”; las ACLs responden “¿estás permitido ver este LUN?”. Puedes pasar una y fallar la otra.
Algunos targets también tienen configuraciones de autenticación por portal—porque una cerradura nunca fue suficiente.

Capas de almacenamiento en Proxmox

Proxmox puede:

• Usar iSCSI como transporte para LVM o LVM-thin (lo más común).
• Usar iSCSI para asignación directa de LUN a VMs (menos común, más frágil).
• Combinar iSCSI con multipath (común en entornos serios).

Si esperas que un target iSCSI aparezca como NFS “un lugar para poner archivos”, perseguirás el problema equivocado durante horas.

Tareas prácticas: comandos, salidas y decisiones (12+)

A continuación hay comprobaciones concretas que puedes ejecutar en un nodo Proxmox. Cada una incluye: el comando, qué significa la salida y qué decisión tomar a continuación.
Ejecútalas como root o con privilegios equivalentes.

Task 1: Confirma qué IQN de iniciador usa Proxmox

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

Significado: Ese IQN es tu identidad frente al target. Si la ACL del target está configurada para un IQN distinto (común después de clonar nodos),
iniciarás sesión pero no verás LUNs, o serás rechazado de plano.

Decisión: Compara esta cadena exacta con el objeto iniciador/host del target. Arregla la ACL del target o cambia intencionadamente el IQN del iniciador (raro).

Task 2: Verifica que el servicio iSCSI esté en ejecución

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

Significado: Si iscsid no está en ejecución, el descubrimiento/login puede comportarse de forma inconsistente, especialmente con arranque automático.

Decisión: Si está inactivo/fallido, inspecciona logs y arregla el servicio antes de tocar la configuración de almacenamiento.

Task 3: Valida la alcanzabilidad básica al IP del portal correcto

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

Significado: ICMP funciona. Eso no prueba el éxito de iSCSI, pero descarta el problema de ruteo más básico.

Decisión: Si el ping falla, arregla ruteo/VLAN/MTU/firewall antes de cualquier otra cosa.

Task 4: Confirma que TCP/3260 es alcanzable

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

Significado: El portal es alcanzable a nivel de transporte.

Decisión: Si esto falla, revisa reglas de firewall, IPs donde escucha el almacenamiento, y si estás golpeando la VLAN/interfaz equivocada.

Task 5: Ejecuta descubrimiento desde el iniciador

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

Significado: El target responde al descubrimiento y anuncia un IQN de target.

Decisión: Si el descubrimiento no devuelve nada, arregla la configuración del portal/discovery del target. Si devuelve un target, procede al login.

Task 6: Intenta un login manual y ve el error real

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.

Significado: Sesión establecida. Genial. Ahora comprueba si aparecen LUNs.

Decisión: Si obtienes “authorization failure” o “login failed”, ve directamente a comprobar CHAP/IQN y ACLs.

Task 7: Lista sesiones iSCSI (¿realmente tienes una?)

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

Significado: Si esto está vacío, no estás logueado. Si aparece, el problema de “sin LUN” probablemente sea mapeo/ACL.

Decisión: Con una sesión presente, deja de tocar reglas de firewall y empieza a verificar la presentación de LUNs.

Task 8: Revisa mensajes del kernel para resultados de descubrimiento SCSI

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

Significado: Este es el caso feliz: el target presentó un LUN y Linux creó /dev/sdc.

Decisión: Si ves la sesión pero no líneas “Direct-Access”, el target está presentando cero LUNs. Arregla el mapeo/ACL en el target.

Task 9: Enumera dispositivos de bloque y confirma que existe el disco 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

Significado: Existe un disco con TRAN = iscsi. Si no aparece ninguno, no tienes un LUN.

Decisión: Si el disco existe pero Proxmox no puede usarlo, sube por la pila (multipath, LVM, configuración de almacenamiento en Proxmox).

Task 10: Verifica IDs de SCSI path y LUN

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

Significado: Puedes ver la tupla host:bus:target:lun. Si ves hosts pero sin entradas de LUN, otra vez: mapeo.

Decisión: Si el LUN existe pero tiene tamaño incorrecto, para—alguien mapeó la extensión/volumen equivocado.

Task 11: Revisa los registros de nodo de open-iscsi (la configuración obsoleta duele)

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

Significado: Los registros de nodo persisten. Si cambiaste credenciales CHAP en el target pero no aquí, el login fallará eternamente con confianza.

Decisión: Si el registro apunta a portals antiguos o iface equivocado, actualiza o borra el registro de nodo y redescubre.

Task 12: Inspecciona ajustes CHAP para un nodo

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 = ********

Significado: El método de auth y el nombre de usuario están establecidos. Si el target espera “None” y fuerzas CHAP, el login falla. Si las contraseñas difieren, el login falla.

Decisión: Alinea la configuración del iniciador con la del target. No “pruebes combinaciones al azar”; trátalo como claves SSH, no como una máquina expendedora.

Task 13: Corrige valores CHAP (y recuerda que los cambiaste)

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'

Significado: Has actualizado el registro persistente de nodo.

Decisión: Vuelve a iniciar sesión y verifica sesiones y LUNs. Si aún no hay LUN, el culpable es el mapeo/ACL en el target, no CHAP.

Task 14: Cierra sesión y vuelve a iniciar (estado limpio)

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.

Significado: Forzaste una nueva negociación y un re-scan.

Decisión: Si la sesión aparece pero el LUN sigue ausente, deja de tocar la configuración del iniciador y arregla el mapeo en el lado del target.

Task 15: Si esperas multipath, confirma que no sea la razón por la que tu LUN “desapareció”

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

Significado: El daemon de multipath está en ejecución.

Decisión: Si no está en ejecución pero tienes múltiples portals, puedes obtener dispositivos duplicados o paths que flaquean; arregla multipath antes de poner LVM encima.

Task 16: Inspecciona el mapeo de 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

Significado: Tienes un único dispositivo multipath (/dev/mapper/mpatha) respaldado por dos rutas. Eso es lo que quieres.

Decisión: Usa el dispositivo multipath para LVM/LVM-thin; evita usar /dev/sdc directamente o provocarás fallos más adelante.

Task 17: Revisa dispositivos SCSI duplicados cuando no hay 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

Significado: Dos portals, dos dispositivos /dev/sdX. Sin multipath, eso son dos discos independientes desde la perspectiva de Linux, aunque sean el mismo LUN.

Decisión: Habilita y configura multipath antes de crear LVM o sistemas de ficheros, o acabarás corrompiendo algo con entusiasmo.

Task 18: Revisa referencias en la configuración de almacenamiento de 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

Significado: Proxmox separa el transporte iSCSI (el bloque “iscsi”) de la unidad real para VM (LVM-thin en un VG).

Decisión: Si solo tienes el bloque iSCSI pero ninguna capa LVM/LVM-thin/ZFS encima, esa es una configuración incompleta, no un bug de login.

Task 19: Confirma que exista un volume group en el dispositivo iSCSI/multipath (si usas LVM)

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

Significado: LVM ve el disco y se está usando como PV, lo cual implica que el LUN es visible y estable.

Decisión: Si pvs no muestra nada, o no tienes LUN, o no hay dispositivo multipath, o no lo inicializaste. Elige la solución correcta.

Task 20: Mira los logs de iSCSI para la razón real del rechazo

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

Significado: Fallo de autenticación. Eso es CHAP o desajuste del modo de auth en el target, no “mapeo de LUN”.

Decisión: Arregla credenciales CHAP y el método de auth primero; solo entonces preocúpate por el mapeo de LUN.

Específicos de Proxmox: iSCSI vs LVM sobre iSCSI (y dónde se pierden las personas)

Proxmox te da suficiente cuerda para montar un almacenamiento sólido—o para crear un nudo que consuma tiempo.
La interfaz de Proxmox facilita añadir “iSCSI” y asumir que ya está todo. No lo está, a menos que estés haciendo LUNs en bruto por VM.

Patrón A (común): iSCSI + LVM-thin

Conectas el host a un LUN, luego construyes un VG LVM y un thin pool encima. Proxmox almacena discos de VM como volúmenes lógicos.
Este es el camino que la mayoría toma porque es eficiente, soportado y relativamente predecible.

Si ves “target accesible pero sin LUN”, estás atascado en el nivel más bajo: Proxmox ni siquiera puede ver el dispositivo de bloque para crear el PV.

Patrón B (menos común): LUN directo por VM

Presentas múltiples LUNs y los mapeas directamente, a menudo para bases de datos o cuando quieres snapshots/replicación nativos del array.
Esto requiere un mapeo y un naming disciplinados, de lo contrario adjuntarás el LUN equivocado a la VM equivocada y tendrás una mala tarde.

Ángulo de clúster Proxmox: todos los nodos deben estar permitidos

Si estás en un clúster y quieres que cualquier nodo ejecute la VM, cada nodo debe poder ver el mismo almacenamiento de respaldo.
“Funciona en node1” es una trampa. Solo significa que el IQN del iniciador de node1 está en la ACL del target.

Broma #1: iSCSI es como la seguridad de oficina—tu tarjeta funciona perfectamente hasta que deja de hacerlo, y entonces mágicamente es tu problema.

Dónde falla: las causas raíz detrás de “login failed” y “no LUN”

1) IQN de iniciador incorrecto (o nodos clonados con IQNs idénticos)

Los nodos Proxmox creados desde plantillas a menudo heredan el mismo InitiatorName. Los targets ven dos hosts reclamando la misma identidad.
Mejor caso, uno funciona y el otro queda fuera. Peor caso, se roban la sesión alternativamente y tienes tiempos de espera intermitentes del almacenamiento.

Arréglalo generando IQNs únicos por nodo y actualizando las ACLs del target en consecuencia. No “permitas todos los iniciadores” a menos que te guste dar explicaciones luego.

2) Desajuste CHAP o CHAP requerido en un lado pero no en el otro

Arrays y stacks de target difieren: algunos requieren CHAP por target, otros por portal, otros por grupo de iniciadores. Proxmox guarda CHAP en el registro de nodo.
Si alguien rota credenciales en el array y olvida actualizar Proxmox, la falla es determinística.

3) El LUN existe pero no está mapeado a este iniciador (clásico)

El administrador del target creó el volumen/extent e incluso creó el IQN del target. Pero no mapeó el LUN al host/grupo de iniciadores correcto, o lo mapeó al grupo equivocado.
El descubrimiento ve el target, el login puede tener éxito, y aún así obtienes cero dispositivos.

Esta es la causa número uno de “target accesible pero sin LUN”. También es la más fácil de arreglar, por eso resulta tan irritante.

4) Desajuste de grupo de portal / binding de red

Muchos arrays tienen múltiples portal groups. Puedes estar logueando en 10.10.20.50 pero el mapeo de LUN aplica al portal group en 10.10.30.50.
O el target está ligado a una interfaz y el descubrimiento está golpeando otro IP de servicio que no sirve ese target.

5) Rarezas ALUA/multipath que parecen “sin LUN”

Si multipath está parcialmente configurado, puedes ver dispositivos brevemente y luego perderlos. Proxmox puede mostrar almacenamiento degradado o que desaparece.
Esto no es “sin LUN”, pero a menudo se diagnostica así por error.

6) Registros de iniciador obsoletos que apuntan a una configuración antigua del target

Si cambiaste nombres de IQN del target, portals o requisitos de autenticación, open-iscsi puede seguir intentando las configuraciones antiguas.
Borrar y volver a descubrir registros de nodo a veces es la solución más limpia—hazlo con cuidado, en una ventana de mantenimiento, y sabiendo qué VMs usan el LUN.

7) Proxmox espera LVM-thin pero presentaste un LUN con un sistema de ficheros existente

Puedes presentar un LUN que ya tiene algo encima (metadatos LVM antiguos, particiones sobrantes). Proxmox puede negarse a inicializarlo, o peor, puedes inicializar el disco equivocado.
Si estás migrando, sé explícito sobre el plan: importar vs reinicializar.

Cita (idea parafraseada) de Werner Vogels (Amazon): “Everything fails all the time; design and operate with that assumption.” — Werner Vogels, idea parafraseada

Errores comunes: síntoma → causa raíz → solución

Síntoma: El descubrimiento funciona, el login falla con “authorization failure”

Causa: Desajuste CHAP o el target requiere CHAP pero el iniciador está en None (o viceversa).

Solución: Alinea el método de autenticación y las credenciales en ambos lados. Verifica con journalctl -u iscsid y iscsiadm -m node -o show.

Síntoma: Login tiene éxito, iscsiadm -m session muestra sesión, pero lsblk no muestra disco iSCSI

Causa: No hay LUN mapeado a este IQN de iniciador, o el enmascaramiento de LUN lo niega.

Solución: En el target, mapea el LUN/extent al grupo de iniciadores/ACL correcto y asegúrate de que el ID de LUN esté habilitado. Luego rescanea o vuelve a iniciar sesión.

Síntoma: Funciona en un nodo Proxmox, falla en otro del mismo clúster

Causa: La ACL del target incluye solo un IQN de iniciador. O los nodos comparten el mismo IQN por clonación.

Solución: Dale a cada nodo un IQN único y añade todos los IQNs de los nodos al grupo de iniciadores del target. Valida sesiones desde cada nodo.

Síntoma: Aparecen dos discos para el mismo LUN (/dev/sdc y /dev/sdd), Proxmox se confunde

Causa: Dos portals sin multipath; Linux ve dos dispositivos SCSI independientes.

Solución: Configura multipath correctamente y usa dispositivos /dev/mapper/mpathX para LVM. Haz blacklist del disco local de arranque.

Síntoma: El LUN aparece y luego desaparece tras minutos o bajo carga

Causa: Desajuste de MTU/jumbo frames, flapping de rutas, o timeouts demasiado agresivos.

Solución: Valida MTU extremo a extremo, revisa contadores de switches y revisa timeouts de iSCSI. Estabiliza la red antes de tunear rendimiento.

Síntoma: UI de Proxmox muestra iSCSI “OK”, pero no puedes crear discos de VM allí

Causa: Añadiste solo el transporte iSCSI pero no creaste LVM/LVM-thin encima (o no mapeaste ningún LUN).

Solución: Asegúrate de que el LUN iSCSI exista como dispositivo de bloque, luego crea un VG y thin pool y añádelo como LVM-thin en Proxmox.

Síntoma: Login falla solo después de un reinicio

Causa: Problemas de orden de arranque, binding a interfaz de red equivocada, o ajustes node.startup para iSCSI mal configurados.

Solución: Asegura que la red esté arriba antes del login iSCSI, y configura el inicio automático del nodo donde proceda. Confirma con logs de systemd.

Síntoma: Ves el LUN, pero está en solo lectura

Causa: Mapeo en el target en modo solo lectura, export de snapshot/clone, o conflictos de reservas SCSI.

Solución: Corrige el modo de mapeo en el array; revisa reservas persistentes si hay clustering involucrado.

Tres micro-historias corporativas desde el terreno

Incidente causado por una suposición errónea: “Descubrir significa que está mapeado”

Una empresa mediana migró de NFS a iSCSI por “mejor rendimiento” (cierto, pero incompleto). El administrador de almacenamiento creó un target,
lo presentó en la VLAN correcta y envió el IQN al equipo de virtualización. Lo añadieron en Proxmox y vieron el target en descubrimiento.
Todos se relajaron. Naturalmente, la ventana de mantenimiento se convirtió inmediatamente en horas extras.

Los nodos Proxmox podían iniciar sesión, pero nunca apareció un LUN. El equipo de virtualización asumió que era un bug del iniciador porque “podemos alcanzar el target”.
Pasaron una hora alternando ajustes CHAP, reiniciando servicios y reañadiendo almacenamiento en la GUI, que es el equivalente operativo de sacudir una impresora.

El problema real: el LUN existía, pero estaba mapeado a un grupo de iniciadores que contenía el IQN equivocado—un host ESXi antiguo de un clúster retirado.
El descubrimiento seguía devolviendo el target porque el descubrimiento estaba abierto. El login funcionó porque CHAP estaba deshabilitado. Pero el enmascaramiento de LUN hizo su trabajo y no mostró nada.

La solución tomó dos minutos: añade los IQNs iniciadores correctos al mapeo y rescanea. La lección duró más:
deja de usar el éxito del descubrimiento como prueba de almacenamiento usable. Trátalo como DNS: útil, no autoritativo.

Optimización que salió mal: jumbo frames sin paciencia

Otro equipo tenía iSCSI funcionando, pero querían menor CPU y mejor throughput. Alguien activó MTU 9000 en las NICs de almacenamiento y en las NICs de Proxmox.
No tocaron los switches porque “ya estaban configurados para jumbo en alguna parte”. Ese “en alguna parte” era un conjunto distinto de puertos.

El resultado no fue una falla inmediata. Eso es lo peor. El descubrimiento funcionó. El login funcionó. Los LUNs aparecieron.
Bajo carga—backups de VM, scrubs de disco o una base de datos ocupada—las rutas empezaron a caer. Multipath fallaba al conmutar, luego volvía, luego marcaba rutas como muertas.
Las VMs se congelaron de maneras que parecían fallos del SO invitado.

El equipo persiguió fantasmas: versiones de kernel de Proxmox, ajustes de multipath, “quizá el array está sobrecargado”. Mientras tanto, los contadores de red decían la verdad aburrida:
fragmentación, pérdidas y enrutamiento intermitente de tramas grandes. iSCSI es sensible a pérdidas y picos de latencia; es I/O de bloques, no una copia de archivos casual.

La solución fue poco glamurosa: aplica MTU consistente extremo a extremo, o ejecuta MTU 1500 en todas partes. Eligieron la segunda opción por simplicidad,
y el rendimiento se mantuvo aceptable—porque estable es más rápido que teórico.

Práctica correcta y aburrida que salvó el día: grupos de hosts explícitos y prueba preflight

Un equipo más disciplinado tenía una regla: cada nuevo nodo Proxmox debe pasar una preflight de almacenamiento antes de unirse al clúster.
La preflight incluía verificar un IQN iniciador único, confirmar que aparece en el grupo de iniciadores del array y hacer login a todos los portals.
También requerían un mapeo de LUN de prueba que pudiera adjuntarse y desprenderse de forma segura.

Un día, un nodo de reemplazo llegó en apuros. Se construyó desde una imagen vieja. El IQN iSCSI estaba duplicado.
Si lo hubieran añadido directamente al clúster, habría competido por sesiones con el nodo existente y probablemente causado resets de rutas.

La preflight lo detectó de inmediato. Regeneraron el IQN iniciador, actualizaron el mapeo del host group, y solo entonces unieron el nodo.
Sin caída. Sin drama. El mejor incidente es el que nunca te hacen sonar el pager.

Broma #2: Lo único más persistente que los registros de nodo iSCSI es la persona que insiste “funcionó en el laboratorio.”

Listas de verificación / plan paso a paso

Paso a paso: arreglar “target accesible pero sin LUN” (caso más común)

1. Confirma el estado de la sesión:
   ejecuta iscsiadm -m session. Si no hay sesión, tienes un problema de login; salta a los pasos de auth/ACL.
2. Confirma el IQN del iniciador:
   revisa /etc/iscsi/initiatorname.iscsi. Asegúrate de que coincida exactamente con la ACL del target.
3. Busca dispositivos LUN:
   ejecuta lsblk -o NAME,TRAN,MODEL,SIZE y dmesg -T. Si no hay disco iSCSI, tienes un problema de mapeo.
4. Arregla el mapeo en el target:
   mapea el LUN/extent al grupo de iniciadores que incluya el IQN(s) de tus nodos Proxmox. Asegura que el ID de LUN esté habilitado y no filtrado.
5. Vuelve a iniciar sesión o rescanea:
   logout/login con iscsiadm. Confirma que el dispositivo de bloque aparece.
6. Sólo entonces configura las capas de Proxmox:
   crea PV/VG/thinpool si usas LVM-thin, luego añade LVM-thin en Proxmox.

Paso a paso: arreglar “login failed” (fallos de auth/ACL)

1. Confirma alcanzabilidad TCP: nc -vz <portal> 3260.
2. Confirma descubrimiento: iscsiadm -m discovery -t sendtargets -p <portal>.
3. Lee los logs del demonio: journalctl -u iscsid -n 100 y captura la razón exacta.
4. Verifica configuración CHAP: iscsiadm -m node -o show y alínea con los ajustes del target.
5. Verifica que el IQN iniciador esté permitido: revisa ACL/grupo de hosts del target. No confíes en reglas basadas en IP salvo que te guste la ambigüedad.
6. Elimina entradas de nodo obsoletas si es necesario: borra sólo el registro de nodo relevante, redescubre y reconfigura auth.

Paso a paso: preparación del clúster Proxmox para iSCSI

1. Cada nodo tiene un IQN único (verifica en cada nodo).
2. La ACL del target incluye todos los IQNs de los nodos que puedan ejecutar VMs.
3. Multipath está configurado si tienes múltiples portals/controladores.
4. Usa nombres de dispositivo estables: prefiere WWID de multipath o enlaces /dev/disk/by-id; evita /dev/sdX crudos.
5. Prueba failover: desactiva una ruta y confirma que I/O continúa (con cuidado, usando un volumen de prueba seguro).

Preguntas frecuentes

1) ¿Por qué puedo descubrir el target pero no ver ningún LUN?

Porque el descubrimiento es solo “¿qué targets existen aquí?”. La visibilidad de LUN está controlada por mapeo y ACLs. El descubrimiento puede estar abierto mientras los LUNs están bloqueados.

2) Si el login tiene éxito, ¿no demuestra que el LUN está mapeado?

No. El login demuestra que estableciste una sesión. El mapeo de LUN es un paso separado. Una sesión con cero LUNs es normal cuando el enmascaramiento lo niega.

3) Proxmox dice que el almacenamiento iSCSI está en línea, pero no puedo almacenar imágenes de VM allí. ¿Por qué?

El almacenamiento “iSCSI” de Proxmox suele ser solo la definición de transporte. Normalmente necesitas LVM o LVM-thin encima para almacenar discos de VM.
Añade el target iSCSI, luego construye un VG/thin pool y añade una entrada LVM-thin.

4) ¿Necesito multipath?

Si tienes múltiples puertos/controladores de almacenamiento y esperas redundancia, sí. Sin multipath puedes obtener dispositivos duplicados o fallos de ruta que parecen problemas aleatorios de disco.
Si realmente tienes un único portal y un único camino, multipath es opcional pero aún común en builds estandarizados.

5) ¿Cuál es la forma más rápida de demostrar que esto es un problema de mapeo, no de Proxmox?

Desde el nodo: si iscsiadm -m session muestra una sesión pero lsblk no muestra disco iSCSI y dmesg no muestra attach SCSI,
el target no te está presentando LUNs. Eso es mapeo/ACL.

6) ¿Pueden dos nodos Proxmox compartir el mismo IQN de iniciador?

No lo hagas. Algunos targets lo toleran hasta que dejan de hacerlo. Tendrás robo de sesión, reservas comportándose mal y resets intermitentes del almacenamiento.
Haz IQNs únicos por nodo, siempre.

7) ¿Debería usar CHAP?

Sí, si puedes. No es una seguridad perfecta, pero evita el cruce casual entre iniciadores y targets en redes compartidas.
Si omites CHAP, compensa con aislamiento de VLAN estricto y disciplina en las ACLs.

8) Cambié credenciales CHAP en el array. ¿Por qué Proxmox no lo detectó?

open-iscsi persiste ajustes de nodo. Debes actualizar el registro de nodo (o redescubrir y reconfigurar).
Verifica con iscsiadm -m node -o show.

9) ¿Por qué veo el LUN como /dev/sdc en un arranque y /dev/sdd en otro?

Linux asigna nombres /dev/sdX dinámicamente. Usa /dev/disk/by-id o dispositivos de multipath, no /dev/sdX crudos, en cualquier configuración persistente.

10) ¿“Sin LUN” alguna vez lo causa Proxmox en sí?

Rara vez. Proxmox usa la pila iSCSI de Linux. Si Linux no ve un LUN, Proxmox tampoco. Enfócate en la configuración iniciador/target, no en la UI.

Conclusión: pasos siguientes para evitar recurrencias

Cuando Proxmox dice “iSCSI login failed” o tienes un target alcanzable sin LUN, resiste la tentación de thrashear.
Demuestra la capa que está fallando: transporte, autenticación o presentación.

• Primero: valida alcanzabilidad y descubrimiento (nc, iscsiadm -m discovery).
• Segundo: valida el login y lee el error real (iscsiadm --login, journalctl -u iscsid).
• Tercero: valida la presentación de LUN (dmesg, lsblk, lsscsi).
• Luego: solo después de que exista el dispositivo de bloque, construye la capa de almacenamiento en Proxmox (LVM/LVM-thin) y, si hace falta, multipath.

Operacionalmente, la mejor solución es una política: IQNs únicos por nodo, grupos de iniciadores explícitos en el target y una preflight antes de unir cualquier nodo al clúster.
Es aburrido. Funciona. A la producción tiende a gustarle esas dos cualidades.