Proxmox no detecta discos: lista rápida para HBA, BIOS y cableado

Playbook de diagnóstico rápido (hacer en este orden)

0) Decide qué significa “no detectado”

• No en BIOS/UEFI: hardware, alimentación, cableado, backplane, enumeración HBA/PCIe.
• En BIOS pero no en Linux: controlador/kernel módulo, peculiaridades de IOMMU, firmware roto, errores PCIe AER.
• En Linux pero no en la UI de Proxmox: pantalla equivocada, particiones existentes, multipath ocultando, ZFS reteniendo dispositivos, permisos, o está bajo /dev/disk/by-id pero no es obvio.

1) Empieza con la verdad del kernel

Ejecuta estos tres y no improvises todavía:

1. dmesg -T | tail -n 200 (buscar PCIe, SAS, SATA, NVMe, reinicios de enlace)
2. lsblk -e7 -o NAME,TYPE,SIZE,MODEL,SERIAL,TRAN,HCTL (ver qué creó el kernel)
3. lspci -nn | egrep -i 'sas|raid|sata|nvme|scsi' (confirmar que el controlador existe)

Decisión: Si el controlador no aparece en lspci, deja de culpar a Proxmox. Es BIOS/PCIe asiento/asignación de lanes o la tarjeta está muerta.

2) Si el controlador existe, verifica el driver y el enlace

• lspci -k -s <slot> → verificar “Kernel driver in use”.
• journalctl -k -b | egrep -i 'mpt3sas|megaraid|ahci|nvme|reset|timeout|aer' → encontrar la bala humeante.

Decisión: ¿Ningún driver enlazado? Carga el módulo o arregla firmware/configuración BIOS. ¿Reinicios/timeouts del enlace? sospecha cableado/backplane/expander/alimentación.

3) Reescanear antes de reiniciar

Reescanea SCSI/NVMe. Si los discos aparecen tras un rescan, aprendiste algo: hotplug, entrenamiento de enlace o tiempos de arranque.

4) Si los discos aparecen pero “faltan” en la UI de Proxmox

Ve al CLI y usa identificadores estables. La UI no miente; sólo no es tu comandante de incidentes.

Decisión: Si existen en /dev/disk/by-id pero no en tu pool, es una historia de ZFS/importación/particionado, no de detección.

Un modelo mental práctico: dónde pueden desaparecer los discos

La detección de discos es una cadena. Rompe cualquier eslabón y mirarás una lista vacía.

Capa 1: Alimentación y conectividad física

El disco necesita alimentación, el conector correcto y un backplane que no haga danza interpretativa. “Arranca” no es lo mismo que “enlace de datos establecido”. SAS en especial alimentará un disco mientras el enlace está caído por una lane mala.

Capa 2: Interposer/backplane/expander y su traducción

Los backplanes SAS pueden incluir expanders, multiplexores y lógica “útil”. Una sola lane marginal puede dejar caer un disco, o peor, hacerlo oscilar bajo carga. SATA detrás de expanders SAS funciona—hasta que no, dependiendo del expander, firmware del disco y cableado.

Capa 3: Firmware y modo del HBA/controlador

Los HBA pueden funcionar como HBAs reales (modo IT) o hacerse pasar por controladoras RAID (IR/modo RAID). Proxmox + ZFS quiere pase directo. La personalidad RAID puede ocultar discos detrás de volúmenes virtuales, bloquear SMART y complicar la recuperación ante errores.

Capa 4: Enumeración PCIe y presupuesto de lanes

El propio controlador es un dispositivo PCIe. Si la placa base no lo enumera, Linux tampoco podrá. La bifurcación de PCIe, el cableado del slot y el compartir lanes con M.2/U.2 pueden hacer que un slot “físico x16” sea eléctricamente x4—o x0, si enfadas a los dioses de las lanes.

Capa 5: Drivers del kernel Linux + creación de nodos

Incluso cuando el hardware está bien, el kernel puede no enlazar el driver correcto, o udev puede no crear nodos como esperas. Multipath puede ocultar intencionalmente rutas individuales. Un initramfs antiguo puede faltar módulos. Los discos pueden existir pero con nombres distintos.

Capa 6: Presentación de almacenamiento en Proxmox

Proxmox VE es Debian bajo una UI. Si Debian no lo ve, Proxmox no puede. Si Debian lo ve pero la UI no lo muestra donde buscas, es un problema de flujo de trabajo, no de hardware.

Parafraseando a John Allspaw: la fiabilidad viene de responder bien a la falla, no de fingir que no existe.

Chiste #1: “El modo RAID hará feliz a ZFS” es como decir “le puse un volante a la tostadora; ahora es un coche”.

Hechos e historia interesantes que realmente ayudan a depurar

• El escaneo SCSI es antiguo… y sigue aquí. Las pilas SAS modernas e incluso algunas SATA todavía dependen de escaneos de host SCSI, por eso los rescans pueden “encontrar” discos sin reiniciar.
• Los HBAs SAS de LSI se convirtieron en estándar. La línea Broadcom/Avago/LSI importa porque los nombres de drivers (mpt2sas/mpt3sas) y las herramientas de firmware siguen esa genealogía.
• El modo IT se popularizó porque los sistemas de archivos se volvieron más inteligentes. ZFS y sistemas similares quieren visibilidad directa del disco. Las controladoras RAID se pensaron en una era donde el controlador manejaba la integridad.
• SFF-8087 y SFF-8643 parecen “solo cables” pero son sistemas de señal. Un mini-SAS parcialmente insertado puede alimentar discos y aun así fallar en las lanes de datos. No es magia; son pares diferenciales y tolerancias.
• Los slots PCIe mienten por marketing. “Slot x16” a menudo significa “conector x16”. Eléctricamente puede ser x8 o x4 según el CPU y la placa.
• UEFI cambió el comportamiento de los option ROM. Algunas tarjetas de almacenamiento dependen de option ROMs para pantallas de enumeración en arranque; las configuraciones UEFI pueden ocultar esas pantallas sin cambiar lo que Linux ve.
• NVMe trajo su propia vía de detección. Los dispositivos NVMe no son “discos SCSI” y no aparecerán en herramientas HBA SAS; usan el subsistema NVMe y el entrenamiento de enlace PCIe.
• El paso de SMART no está garantizado. Con controladoras RAID, los datos SMART pueden estar bloqueados o requerir herramientas del proveedor, lo que cambia cómo verificas “que el disco existe”.

Tareas prácticas (comandos + significado + decisión)

Estas son las tareas que realmente ejecuto cuando un nodo dice “no hay discos”. Cada una incluye qué buscas y la decisión que tomas.

Task 1: Confirmar que el controlador está enumerado en PCIe

cr0x@server:~$ lspci -nn | egrep -i 'sas|raid|sata|scsi|nvme'
03:00.0 Serial Attached SCSI controller [0107]: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 [1000:0097] (rev 02)
01:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co Ltd NVMe SSD Controller [144d:a808]

Qué significa: La placa base ve el HBA/controlador NVMe. Si no está aquí, Linux nunca verá los discos detrás.

Decisión: Dispositivo ausente → vuelve a insertar la tarjeta, cambia de slot, revisa configuraciones PCIe en BIOS, desactiva dispositivos en conflicto, verifica alimentación a risers.

Task 2: Verificar el enlace del driver del kernel

cr0x@server:~$ lspci -k -s 03:00.0
03:00.0 Serial Attached SCSI controller: Broadcom / LSI SAS3008 PCI-Express Fusion-MPT SAS-3 (rev 02)
	Subsystem: Broadcom / LSI SAS9300-8i
	Kernel driver in use: mpt3sas
	Kernel modules: mpt3sas

Qué significa: El driver correcto está enlazado. Si “Kernel driver in use” está vacío, tienes un problema de driver/firmware/blacklist.

Decisión: No hay driver enlazado → revisa modprobe, logs del kernel, Secure Boot, compatibilidad de firmware y si estás usando un kernel de proveedor extraño.

Task 3: Ver qué discos creó Linux (no confíes en la UI aún)

cr0x@server:~$ lsblk -e7 -o NAME,TYPE,SIZE,MODEL,SERIAL,TRAN,HCTL
NAME    TYPE  SIZE MODEL              SERIAL        TRAN HCTL
sda     disk  3.6T ST4000NM0035-1V4    ZC123ABC      sas  3:0:0:0
sdb     disk  3.6T ST4000NM0035-1V4    ZC123DEF      sas  3:0:1:0
nvme0n1 disk  1.8T Samsung SSD 990 PRO S6Z1NZ0R12345 nvme -

Qué significa: Si está en lsblk, el kernel lo ve. TRAN te dice si es sas, sata, nvme.

Decisión: Discos ausentes → bajar por la pila: dmesg, cableado, expander, alimentación. Discos presentes pero Proxmox “faltan” → probablemente UI/flujo, multipath o importación ZFS.

Task 4: Revisar logs del kernel por reinicios/timeouts de enlace

cr0x@server:~$ journalctl -k -b | egrep -i 'mpt3sas|megaraid|ahci|nvme|reset|timeout|aer|link down' | tail -n 60
Dec 26 10:12:01 server kernel: mpt3sas_cm0: log_info(0x31120101): originator(PL), code(0x12), sub_code(0x0101)
Dec 26 10:12:01 server kernel: sd 3:0:1:0: rejecting I/O to offline device
Dec 26 10:12:03 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: 0000:03:00.0
Dec 26 10:12:03 server kernel: nvme nvme0: I/O 42 QID 5 timeout, aborting

Qué significa: “offline device”, “timeout”, “link down”, spam AER = integridad de señal, alimentación, o dispositivo/controlador fallando.

Decisión: Timeouts en múltiples discos → cable/backplane/expander/HBA. Timeouts en un disco → ese disco o su slot.

Task 5: Listar controladoras de almacenamiento que el kernel reconoce

cr0x@server:~$ lsscsi -H
[0]    ata_piix
[2]    mpt3sas
[3]    nvme

Qué significa: Confirma adaptadores host. Si el driver del HBA está cargado, aparece como host.

Decisión: HBA ausente aquí pero presente en lspci → el driver no cargó o falló al inicializarse.

Task 6: Inspeccionar hosts SCSI y reescanear dispositivos

cr0x@server:~$ ls -l /sys/class/scsi_host/
total 0
lrwxrwxrwx 1 root root 0 Dec 26 10:10 host0 -> ../../devices/pci0000:00/0000:00:17.0/ata1/host0/scsi_host/host0
lrwxrwxrwx 1 root root 0 Dec 26 10:10 host2 -> ../../devices/pci0000:00/0000:03:00.0/host2/scsi_host/host2

cr0x@server:~$ for h in /sys/class/scsi_host/host*/scan; do echo "- - -" > "$h"; done

Qué significa: Fuerza un escaneo de todos los hosts SCSI. Si los discos aparecen después, la detección es por tiempo/hotplug/comportamiento del expander.

Decisión: Si los rescans consistentemente “lo arreglan”, revisa hotplug del BIOS, spin-up escalonado, firmware del expander y firmware del HBA.

Task 7: Comprobar detección SATA/AHCI (puertos integrados)

cr0x@server:~$ dmesg -T | egrep -i 'ahci|ata[0-9]|SATA link' | tail -n 40
[Thu Dec 26 10:10:12 2025] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
[Thu Dec 26 10:10:13 2025] ata1: SATA link down (SStatus 0 SControl 300)
[Thu Dec 26 10:10:13 2025] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

Qué significa: “link down” en un puerto con disco significa cableado/puerto deshabilitado en BIOS/alimentación.

Decisión: Si los puertos están link down en todo el tablero, revisa modo SATA en BIOS (AHCI), y si la placa deshabilita SATA cuando hay M.2 poblado.

Task 8: Enumerar dispositivos NVMe y estado del controlador

cr0x@server:~$ nvme list
Node             SN               Model                          Namespace Usage                      Format           FW Rev
---------------- ---------------- -------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1      S6Z1NZ0R12345    Samsung SSD 990 PRO 2TB        1         1.80  TB / 2.00  TB        512   B +  0 B   5B2QJXD7

Qué significa: NVMe está presente como su propio subsistema. Si nvme list está vacío pero lspci muestra el controlador, puede ser driver, ASPM de PCIe o problemas de enlace.

Decisión: Lista vacía → revisar journalctl -k para errores NVMe, configuraciones BIOS de velocidad PCIe y bifurcación de slots (para adaptadores multi-NVMe).

Task 9: Confirmar identificadores estables de disco (lo que debes usar para ZFS)

cr0x@server:~$ ls -l /dev/disk/by-id/ | egrep -i 'wwn|nvme|scsi' | head
lrwxrwxrwx 1 root root  9 Dec 26 10:15 nvme-Samsung_SSD_990_PRO_2TB_S6Z1NZ0R12345 -> ../../nvme0n1
lrwxrwxrwx 1 root root  9 Dec 26 10:15 scsi-35000c500a1b2c3d4 -> ../../sda
lrwxrwxrwx 1 root root  9 Dec 26 10:15 scsi-35000c500a1b2c3e5 -> ../../sdb
lrwxrwxrwx 1 root root  9 Dec 26 10:15 wwn-0x5000c500a1b2c3d4 -> ../../sda

Qué significa: Estos IDs sobreviven a reinicios y renombres de dispositivo (sda que pasa a sdb tras cambios de hardware).

Decisión: Si tus scripts de pool/import usan /dev/sdX, deja de hacerlo. Migra a by-id/by-wwn antes de tu próxima ventana de mantenimiento te coma.

Task 10: Comprobar visibilidad SMART (te dice si realmente ves el disco)

cr0x@server:~$ smartctl -a /dev/sda | head -n 20
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-4-pve] (local build)
=== START OF INFORMATION SECTION ===
Model Family:     Seagate Exos 7E8
Device Model:     ST4000NM0035-1V4
Serial Number:    ZC123ABC
LU WWN Device Id: 5 000c50 0a1b2c3d4
Firmware Version: SN03
User Capacity:    4,000,787,030,016 bytes [4.00 TB]

Qué significa: Si SMART funciona, probablemente tienes visibilidad de passthrough real. Si SMART falla detrás de una controladora RAID, puede que necesites otro tipo de dispositivo o utilidades del proveedor.

Decisión: SMART bloqueado + quieres ZFS → verifica HBA en modo IT o HBA real, no personalidad RAID.

Task 11: Detectar si multipath está ocultando tus discos

cr0x@server:~$ multipath -ll
mpatha (3600508b400105e210000900000490000) dm-0 IBM,2810XIV
size=1.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:0 sda 8:0  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:0 sdb 8:16 active ready running

Qué significa: Multipath puede presentar discos como /dev/dm-* y los /dev/sdX crudos son solo paths.

Decisión: Si son discos locales, multipath es una mala configuración. Desactívalo o ignora HBAs locales, de lo contrario Proxmox/ZFS puede ver dispositivos “extraños”.

Task 12: Identificar si estás en una controladora RAID con discos virtuales

cr0x@server:~$ lspci -nn | egrep -i 'megaraid|raid'
04:00.0 RAID bus controller [0104]: Broadcom / LSI MegaRAID SAS-3 3108 [1000:005d] (rev 02)

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,MODEL
NAME  TYPE  SIZE MODEL
sda   disk  7.3T LSI MR9361-8i

Qué significa: Si el modelo parece la controladora y solo ves un “disco”, estás viendo un disco virtual, no discos físicos individuales.

Decisión: Para ZFS: o cambias a un HBA / flasheas a modo IT, o aceptas que ZFS no podrá gestionar discos individuales correctamente.

Task 13: Comprobar si el BIOS deshabilitó el slot o remapeó lanes

cr0x@server:~$ dmidecode -t baseboard | egrep -i 'Manufacturer|Product|Version'
Manufacturer: Supermicro
Product Name: X11SPH-NCTF
Version: 1.02

cr0x@server:~$ lspci -vv -s 03:00.0 | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 8GT/s, Width x8
LnkSta: Speed 2.5GT/s (downgraded), Width x8

Qué significa: Link degradado a 2.5GT/s sugiere problemas de integridad de señal, slot de generación equivocada forzando, o riser/cable malo.

Decisión: Links degradados con errores → intenta forzar Gen3/Gen4 en BIOS, cambia de slot, reemplaza riser, revisa el asiento físico.

Task 14: Específico de Proxmox: confirmar kernel y módulos

cr0x@server:~$ uname -r
6.8.12-4-pve

cr0x@server:~$ modinfo mpt3sas | egrep -i 'filename|version|firmware'
filename:       /lib/modules/6.8.12-4-pve/kernel/drivers/scsi/mpt3sas/mpt3sas.ko
version:        44.100.00.00
firmware:       mpt3sas_fw.bin

Qué significa: Confirma que usas el kernel de Proxmox y el módulo existe. Kernels/initramfs descoordinados pueden morder tras actualizaciones.

Decisión: Si falta el módulo o el kernel es incorrecto, arregla paquetes y regenera initramfs antes de perseguir fantasmas de hardware.

HBA, BIOS/UEFI y PCIe: la escena del crimen habitual

Modo HBA: IT vs IR/RAID (y por qué a Proxmox le importa)

Si estás usando ZFS (y muchas instalaciones Proxmox lo hacen), quieres que el HBA presente cada disco físico directamente a Linux. Eso es el modo IT en términos LSI/Broadcom. El modo RAID (IR) es otra filosofía: el controlador abstrae discos en volúmenes lógicos. Esa abstracción rompe varias cosas de las que dependes en operaciones modernas:

• SMART/estado preciso por disco (a menudo bloqueado o extraño).
• Identidades de disco predecibles (WWNs pueden ocultarse o reemplazarse).
• Superficies de error claras (los timeouts pueden convertirse en “el controlador dice no”).
• La capacidad de ZFS para gestionar redundancia y autocorrección con visibilidad completa.

Además: las controladoras RAID suelen tener cachés de escritura, BBUs y políticas que son geniales hasta que no lo son. ZFS ya hace su propia historia de consistencia. No necesitas dos capitanes dirigiendo un barco. Te marearás.

Configuraciones UEFI que impactan silenciosamente la detección

BIOS/UEFI puede ocultar o romper tu almacenamiento sin mensajes dramáticos. Las configuraciones más comunes a auditar cuando los discos desaparecen:

• Modo SATA: AHCI vs RAID. En servidores, RAID puede enrutar puertos por una capa tipo Intel RST que Linux puede no manejar como esperas.
• Configuración de slot PCIe: velocidad Gen forzada vs auto; bifurcación x16 → x4x4x4x4 para adaptadores multi-NVMe.
• Política de option ROM: solo UEFI vs Legacy. Esto afecta sobre todo la visibilidad de arranque y pantallas de gestión, pero una mala configuración puede ocultar lo que esperas ver en pre-boot.
• IOMMU/VT-d/AMD-Vi: No suele romper la detección de discos, pero puede cambiar el comportamiento de dispositivos con setups de passthrough.
• Deshabilitado de almacenamiento onboard: Algunas placas deshabilitan puertos SATA cuando hay M.2 ocupadas, o comparten lanes con slots PCIe.

Compartir lanes PCIe: el “por qué mi slot dejó de funcionar” moderno

Las placas base son los agentes de tráfico. Mete un NVMe en una ranura M.2 y tu HBA puede caer de x8 a x4, o el slot adyacente puede deshabilitarse. Esto no es “mal diseño”. Es economía y física: los CPUs tienen lanes finitas, y los fabricantes multiplexan de formas que requieren leer la letra pequeña.

Si ves un controlador presente pero inestable (errores AER, link down/up), problemas de lane o integridad de señal están muy en juego. Los risers, especialmente, adoran estar “casi bien”.

Chiste #2: Un riser PCIe que “funciona si no tocas el chasis” es menos un componente y más una elección de estilo de vida.

Cableado, backplanes, expanders y las mentiras de “está bien insertado”

Conectores Mini-SAS: por qué la falla parcial es común

Los cables SAS transportan múltiples lanes. Un solo SFF-8643 puede llevar cuatro lanes SAS; un backplane puede mapear lanes a bahías individuales. Si una lane falla, no siempre pierdes todos los discos. Pierdes “algunas bahías”, a menudo en un patrón que parece software.

Regla práctica: si faltan discos en un patrón repetitivo de bahías (por ejemplo, bahías 1–4 bien, 5–8 muertas), sospecha de un cable mini-SAS o puerto específico. No pases una hora en udev por un problema que vive en cobre.

Backplanes con expanders: geniales cuando funcionan

Los expanders permiten conectar muchos discos a menos puertos HBA. También añaden una capa que puede tener bugs de firmware, peculiaridades de negociación y sensibilidad con discos SATA detrás de expanders SAS. Los síntomas incluyen:

• Los discos aparecen después del arranque pero desaparecen bajo carga.
• Mensajes intermitentes de “device offlined”.
• Sólo algunos modelos de disco se comportan mal.

Cuando eso ocurre, no “tunees Linux”. Valida el firmware del expander, cambia cables, aisla conectando menos bahías y prueba con un modelo de disco conocido bueno.

Alimentación y spin-up

Especialmente en chasis densos, la alimentación puede ser el asesino silencioso. Los discos pueden girar pero sufrir caídas de tensión durante el entrenamiento de enlace o cuando muchos discos arrancan simultáneamente. Algunos HBAs y backplanes soportan spin-up escalonado. Otros no. Algunos lo soportan y vienen mal configurados.

Una señal reveladora es múltiples discos cayendo al mismo tiempo durante el arranque o scrub, luego reapareciendo más tarde. Eso no es cosa de “Proxmox”. Es alimentación o señal.

Comprobaciones físicas simples que superan a la inteligencia

• Vuelve a insertar ambos extremos de los cables mini-SAS. No “presiones suavemente”. Desconecta, inspecciona, reconecta firmemente.
• Intercambia cables entre puertos conocidos buenos y sospechosos para ver si el problema sigue al cable.
• Mueve un disco a otra bahía. Si el disco funciona en otro sitio, la bahía/lane del backplane es sospechosa.
• Si puedes, conecta temporalmente un disco directamente a un puerto HBA (evita el expander/backplane) para aislar capas.

Capa Linux/Proxmox: controladores, udev, multipath y nodos de dispositivo

La presencia del driver no es salud del driver

Ver mpt3sas cargado no garantiza que el controlador se inicializara correctamente. Incompatibilidades de firmware pueden producir funcionalidad parcial: el controlador se enumera, pero no aparecen targets; o los targets aparecen pero fallan constantemente.

Los logs del kernel importan más que las listas de módulos. Si ves reinicios repetidos, “firmware fault” o colas atascadas, trátalo como un incidente real: recoge logs, estabiliza hardware y considera actualizaciones de firmware.

Multipath: útil hasta que no lo es

Multipath está diseñado para SANs y almacenamiento con rutas duales. En un nodo Proxmox con discos SAS locales, suele ser accidental y dañino. Puede ocultar los dispositivos que esperas, o crear nodos device-mapper que Proxmox/ZFS usen de forma inconsistente si no eres deliberado.

Si no usas multipath explícitamente para almacenamiento compartido, por lo general quieres desactivarlo o configurarlo para ignorar discos locales.

Nombrado de dispositivos: /dev/sdX es una trampa

Linux asigna nombres /dev/sdX en orden de descubrimiento. Añade un controlador, reordena cables o cambia configuraciones de arranque y el orden cambia. Así es como importas discos equivocados, borras el dispositivo incorrecto o construyes un pool con miembros erróneos.

Usa /dev/disk/by-id o WWNs. Hazlo política. Tu yo futuro te lo agradecerá en silencio.

Cuando Proxmox “no muestra discos” pero Linux sí

Realidades comunes:

• Los discos tienen particiones antiguas y la UI de Proxmox filtra lo que considera “disponible”.
• ZFS ya está usando los discos (pertenecen a un pool importado o a un pool huérfano). ZFS no comparte amablemente.
• Estás mirando en el lugar equivocado: discos del nodo vs definiciones de almacenamiento vs vista del datacenter.
• Multipath o device-mapper presentan nombres diferentes a los que esperas.

Ángulo ZFS: por qué el “modo RAID” no es tu amigo

Proxmox incluye soporte ZFS de primera clase. ZFS asume que él está a cargo de la redundancia, checksums y curación. La RAID por hardware asume ella está a cargo de la redundancia y recuperación ante errores. Cuando apilas ambas, creas un sistema donde cada capa toma decisiones sin la información completa.

Lo que “funciona” pero sigue siendo incorrecto

• Crear un gran volumen RAID0/RAID10 y poner ZFS encima: ZFS pierde visibilidad por disco y no puede aislar miembros que fallan.
• Usar caché de controladora con ZFS y writes sync: puedes mentirle a ZFS sobre durabilidad si la política de caché es insegura.
• Asumir que el controlador mostrará errores de disco claramente: puede remapear, reintentar u ocultar hasta que ya no pueda.

Qué deberías hacer en su lugar

• Usa un HBA (o flashea el controlador a modo IT) y presenta discos crudos a ZFS.
• Usa identificadores estables al crear pools.
• Prefiere combinaciones de firmware aburridas y bien probadas. Lo bleeding edge está bien para laboratorio, no para tu quórum de clúster.

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

1) Síntoma: HBA no aparece en lspci

Causa raíz: Tarjeta no insertada, slot muerto, compartir lanes deshabilitó el slot, riser fallando o BIOS deshabilitó ese slot.

Solución: Reinsertar, probar otro slot, quitar riser, comprobar “PCIe slot enable” en BIOS, revisar sharing de lanes con M.2/U.2, actualizar BIOS si está anticuado.

2) Síntoma: HBA en lspci pero no hay discos en lsblk

Causa raíz: Driver no enlazado, incompatibilidad de firmware, HBA en modo que requiere stack de proveedor, cable/backplane roto impidiendo descubrimiento de targets.

Solución: Verificar lspci -k, revisar journalctl -k, reescanear hosts SCSI, cambiar cables, validar firmware y modo del HBA (IT para ZFS).

3) Síntoma: Algunas bahías faltan en un patrón

Causa raíz: Una lane/cable/puerto SAS caída; el mapeo del backplane coincide con el conjunto faltante.

Solución: Intercambiar cable mini-SAS; mover al otro puerto HBA; reinsertar el conector; comprobar pines doblados/daños.

4) Síntoma: Los discos aparecen tras un rescan pero desaparecen después de reiniciar

Causa raíz: Timing de hotplug, peculiaridades del expander, spin-up escalonado mal configurado, alimentación marginal en el arranque.

Solución: Actualizar firmware HBA/backplane/expander, habilitar spin-up escalonado si está soportado, verificar PSU y distribución de energía, revisar logs de arranque por resets.

5) Síntoma: NVMe no detectado, pero funciona en otra máquina

Causa raíz: Slot deshabilitado por configuraciones de bifurcación, PCIe Gen forzado muy alto/bajo, compartir lanes con SATA, o el adaptador necesita bifurcación.

Solución: Establecer bifurcación correcta, poner velocidad PCIe en Auto/Gen3/Gen4 según corresponda, mover a slot conectado al CPU, actualizar BIOS.

6) Síntoma: La GUI de Proxmox no muestra discos, pero lsblk sí

Causa raíz: Particiones existentes/metadata LVM, ZFS ya los reclama, presentación por multipath, o estás viendo la vista equivocada de la UI.

Solución: Usa CLI para confirmar by-id, revisa zpool status/zpool import, mira multipath -ll, borra firmas solo cuando estés seguro.

7) Síntoma: SMART falla con “cannot open device” detrás de la controladora

Causa raíz: Abstracción de controladora RAID; el paso de SMART requiere tipo de dispositivo especial o no está soportado.

Solución: Usar HBA/modo IT para ZFS; de lo contrario usar herramientas del proveedor y aceptar las limitaciones.

8) Síntoma: Discos oscilan bajo carga, ZFS detecta errores de checksum

Causa raíz: Integridad de señal en cable/backplane/expander o alimentación insuficiente; a veces un disco está envenenando el bus.

Solución: Reemplaza cables primero, aísla quitando discos, revisa dmesg por resets, valida salud de PSU y del backplane.

Listas de verificación / plan paso a paso

Checklist A: “El instalador no ve discos”

1. Entra en BIOS/UEFI y confirma que el controlador está habilitado y visible.
2. Confirma que el modo SATA es AHCI (a menos que necesites RAID explícitamente para un volumen de arranque).
3. Para HBA: verifica que esté en modo IT o HBA real (no volúmenes virtuales MegaRAID) si quieres ZFS.
4. Mueve el HBA a otro slot PCIe (preferir slots conectados al CPU).
5. Arranca un entorno rescue y ejecuta lspci y dmesg. Si falta allí, es hardware.
6. Cambia cables mini-SAS y vuelve a insertar conectores en ambos extremos.
7. Si usas backplane con expander: prueba una conexión directa con un disco.

Checklist B: “Algunos discos faltan detrás del HBA”

1. Ejecuta lsblk e identifica qué bahías faltan; busca patrones.
2. Revisa logs por reinicios de enlace y dispositivos offline.
3. Reescanea hosts SCSI; mira si aparecen los discos faltantes.
4. Cambia el cable que alimenta el conjunto de bahías faltantes.
5. Mueve el cable a otro puerto HBA; mira si el conjunto faltante se mueve.
6. Mueve un disco faltante a una bahía conocida buena; si aparece, la bahía/lane es mala.
7. Actualiza firmware del HBA si corres una versión conocida problemática.

Checklist C: “Discos detectados en Linux pero no utilizables en Proxmox”

1. Confirma IDs estables en /dev/disk/by-id.
2. Comprueba si ZFS ve un pool importable: zpool import.
3. Revisa si los discos tienen firmas: wipefs -n /dev/sdX (el -n es la bandera de seguridad; úsala).
4. Revisa multipath: multipath -ll.
5. Decide tu intención: importar datos existentes vs borrar y reutilizar.
6. Si vas a borrar, hazlo deliberadamente y documenta qué WWNs borraste.

Checklist D: “NVMe no aparece”

1. Confirma el controlador en lspci.
2. Revisa nvme list y logs del kernel por timeouts.
3. Inspecciona estado del enlace PCIe (LnkSta) por degradaciones.
4. Configura la bifurcación correcta para adaptadores multi-NVMe.
5. Mueve el NVMe a otro slot y vuelve a probar.

Tres micro-historias corporativas desde las trincheras

Micro-historia 1: El incidente causado por una suposición equivocada

El equipo estaba desplegando un nuevo clúster Proxmox para cargas internas de CI. El plan de almacenamiento era “simple”: ocho discos SAS por nodo, espejos ZFS, listo. Compras entregaron servidores con una “controladora SAS RAID” en lugar del HBA solicitado. Nadie se alarmó porque la controladora todavía tenía “SAS” en el nombre y la BIOS mostraba un enorme disco lógico.

Instalaron Proxmox en ese volumen lógico y construyeron pools ZFS sobre lo que la controladora exponía. Funcionó unas semanas, que es como las malas suposiciones se promueven a “decisiones de diseño”. Entonces un disco empezó a fallar. La controladora remapeó y reintentó de formas que ZFS no podía observar, y el nodo empezó a atascarse durante scrubs. Los logs estaban llenos de timeouts pero nada que mapease claramente a una bahía física.

Durante la ventana de mantenimiento, alguien sacó el disco “fallado” según la UI de la controladora. El equivocado. La controladora había cambiado su numeración interna tras remapeos previos, y la hoja de mapeo estaba obsoleta. Ahora el volumen lógico se degradó de otra forma, ZFS se enfureció y el clúster perdió capacidad durante carga pico.

La solución fue poco glamorosa: reemplazar la controladora RAID por un HBA real, reconstruir el nodo y aplicar una política: ZFS obtiene discos crudos, identificados por WWN, y el mapeo de bahías se valida con LEDs y números de serie antes de extraer hardware. La suposición “SAS equivale a HBA” fue la causa raíz y les costó un fin de semana.

Micro-historia 2: La optimización que salió mal

Otro equipo tuvo problemas de rendimiento durante resilvers de ZFS. Alguien sugirió “optimizar el cableado” usando un solo backplane con expander para reducir puertos HBA y mantener el montaje ordenado. Menos cables, menos puntos de fallo, ¿cierto?

En la práctica, el expander introdujo un comportamiento sutil: durante I/O intenso, un par de SSDs SATA (usados como vdevs especiales) se desconectaban intermitentemente por segundos y luego volvían. El HBA y el kernel registraban reinicios de enlace, y ZFS marcaba dispositivos como faulted o degradados según el timing. El síntoma parecía “ZFS inestable” porque las caídas eran transitorias.

El equipo intentó ajustar timeouts y profundidades de cola, porque a los ingenieros les gustan los potenciómetros y el expander parecía “enterprise”. El ajuste redujo errores obvios pero no resolvió el problema subyacente. Bajo un incidente real—reinicio del nodo más recuperación simultánea de VMs—los dispositivos volvieron a oscilar y el pool no quiso importarse sin intervención manual.

Revirtieron la “optimización”. Conectaron directamente los SSDs sensibles, dejaron el expander para los HDDs masivos donde la latencia importaba menos, y estandarizaron modelos de disco detrás del expander. El rendimiento y la tranquilidad mejoraron. A veces menos cables son solo menos pistas cuando se rompe algo.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un equipo tenía la costumbre pedante: cada disco se registraba por WWN y ubicación de bahía en la instalación. Mantenían una hoja simple: serial del chasis, número de bahía, serial del disco, WWN y la pertenencia prevista al vdev ZFS. También etiquetaban cables por puerto HBA y conector de backplane. Nadie disfrutaba hacerlo, pero era política.

Un año después, un nodo reportó errores de checksum intermitentes durante scrubs. Los logs sugerían un enlace inestable, no un disco fallando, pero la topología del pool incluía doce discos y un expander de backplane. En el mundo sin inventario, eso habría degenerado en “sacar discos hasta que paren los errores”. Así se crean nuevos incidentes.

En su lugar, correlacionaron el WWN afectado con la bahía. Los errores siempre estaban en discos de las bahías 9–12. Eso coincidía con un único cable mini-SAS que alimentaba esa sección del backplane. Cambiaron el cable en una ventana corta y el scrub posterior eliminó los errores.

Sin drama. Sin adivinanzas. La práctica de inventario aburrida convirtió un incidente potencialmente complicado en una reparación de 20 minutos con causa raíz clara. La fiabilidad suele ser simplemente llevar registros con convicción.

Preguntas frecuentes

1) El instalador de Proxmox no muestra discos. ¿Siempre es problema de driver HBA?

No. Si lspci no muestra el controlador, es BIOS/PCIe/hardware. Si el controlador aparece pero no hay discos, puede ser driver/firmware/cableado.

2) Veo discos en BIOS pero no en Linux. ¿Cómo es posible?

La BIOS puede mostrar volúmenes lógicos RAID o un resumen del controlador sin exponer targets a Linux. O Linux carece del módulo correcto, o el controlador falla al inicializar durante el arranque (revisa journalctl -k).

3) ¿Necesito modo IT para Proxmox?

Si usas ZFS y quieres operaciones sensatas, sí. Si insistes en RAID por hardware, puedes usarlo, pero eliges un modelo operativo distinto con herramientas distintas.

4) ¿Por qué los discos aparecen como /dev/dm-0 en vez de /dev/sda?

Usualmente multipath o device-mapper (LVM, dm-crypt). Para discos locales que no pretendes multipath, corrige la configuración de multipath o desactívalo.

5) Mis discos aparecen, pero la GUI de Proxmox no los lista como disponibles. ¿Están rotos?

A menudo tienen firmas existentes (ZFS/LVM/RAID) o ya forman parte de un pool importado. Verifica con lsblk, wipefs -n y zpool import antes de hacer algo destructivo.

6) ¿Un cable SAS malo puede realmente causar que sólo un disco desaparezca?

Sí. Mini-SAS lleva múltiples lanes; según el mapeo del backplane, una falla de lane puede aislar una bahía o un subconjunto. Los patrones te ayudan a diagnosticar.

7) NVMe no detectado: ¿cuál es el error de BIOS más común?

Configuraciones de bifurcación incorrectas al usar adaptadores multi-NVMe, o compartir lanes que deshabilitan el slot cuando otra M.2/U.2 está poblada.

8) ¿Debo forzar la velocidad PCIe Gen para arreglar problemas de enlace?

A veces forzar una velocidad Gen inferior estabiliza enlaces inestables (útil para diagnóstico), pero la solución real suele ser asiento, risers, cableado o elección de slot en la placa.

9) ¿Cómo decido entre “reemplazar disco” y “reemplazar cable/backplane”?

Si múltiples discos muestran errores en el mismo puerto HBA/segmento de backplane, sospecha cable/backplane. Si un disco sigue a sí mismo a través de bahías, es el disco.

10) ¿Es seguro reescanear hosts SCSI en un nodo en producción?

Generalmente sí, pero con conciencia situacional. Los rescans pueden disparar eventos de descubrimiento y mucho ruido en los logs. Evítalos durante operaciones de almacenamiento sensibles si ya estás degradado.

Conclusión: próximos pasos prácticos

Si Proxmox no puede ver discos, deja de adivinar y recorre la cadena: enumeración PCIe → enlace del driver → estabilidad del enlace → descubrimiento de targets → IDs estables → consumo por Proxmox/ZFS. Las victorias más rápidas suelen ser físicas: asiento, asignación de lanes y cables. Los fallos más caros vienen del modo de controlador equivocado y del nombrado de dispositivos descuidado.

1. Ejecuta el playbook de diagnóstico rápido y clasifica el dominio de fallo en 10 minutos.
2. Recoge evidencias: lspci -k, lsblk y logs del kernel alrededor del tiempo de detección.
3. Estandariza: HBA/modo IT para ZFS, nombrado por-id y un mapa de bahía a WWN.
4. Arregla la causa raíz, no el síntoma: reemplaza cables/risers sospechosos, corrige bifurcación BIOS, actualiza firmware con criterio.
5. Tras la recuperación, haz un scrub/resilver de prueba y revisa logs. Si no verificas, no lo arreglaste—solo dejaste de verlo.