Disques Proxmox non détectés : checklist rapide HBA, BIOS et câblage

Playbook de diagnostic rapide (faire dans cet ordre)

0) Décidez ce que signifie « non détecté »

• Pas dans le BIOS/UEFI : matériel, alimentation, câblage, backplane, énumération HBA/PCIe.
• Dans le BIOS mais pas dans Linux : pilote/module kernel, bizarreries IOMMU, firmware cassé, erreurs PCIe AER.
• Dans Linux mais pas dans l’interface Proxmox : mauvais écran, partitions existantes, masquage par multipath, ZFS tenant les périphériques, permissions, ou c’est sous /dev/disk/by-id mais pas évident.

1) Commencez par la vérité du kernel

Exécutez ces trois commandes et n’improvisez pas encore :

1. dmesg -T | tail -n 200 (recherchez PCIe, SAS, SATA, NVMe, réinitialisations de lien)
2. lsblk -e7 -o NAME,TYPE,SIZE,MODEL,SERIAL,TRAN,HCTL (voyez ce que le kernel a créé)
3. lspci -nn | egrep -i 'sas|raid|sata|nvme|scsi' (confirmez que le contrôleur existe)

Décision : Si le contrôleur n’apparaît pas dans lspci, cessez d’accuser Proxmox. C’est le BIOS/le placement PCIe/l’allocation des lanes ou la carte est morte.

2) Si le contrôleur existe, vérifiez le pilote et le lien

• lspci -k -s <slot> → vérifiez « Kernel driver in use ».
• journalctl -k -b | egrep -i 'mpt3sas|megaraid|ahci|nvme|reset|timeout|aer' → trouvez la cartouche fumante.

Décision : Pas de pilote lié ? Chargez le module ou fixez le firmware/les réglages du BIOS. Réinitialisations/timeouts de lien ? suspectez câblage/backplane/expander/alimentation.

3) Rescannez avant de redémarrer

Rescannez SCSI/NVMe. Si les disques apparaissent après un rescan, vous avez appris quelque chose : hotplug, entraînement de lien, ou timing au démarrage.

4) Si les disques apparaissent mais sont « manquants » dans l’UI Proxmox

Allez en CLI et utilisez des identifiants stables. L’UI ne ment pas ; elle n’est juste pas votre commandant d’incident.

Décision : S’ils existent dans /dev/disk/by-id mais pas dans votre pool, c’est une histoire ZFS/import/partition, pas une détection.

Modèle mental pratique : où les disques peuvent disparaître

La détection des disques est une chaîne. Cassez un maillon et vous regarderez une liste vide.

Couche 1 : Alimentation et connectivité physique

Le disque a besoin d’alimentation, du connecteur correct et d’un backplane qui ne fait pas de danse interprétative. « Monter en rotation » n’est pas identique à « liaison de données établie ». Le SAS en particulier alimentera volontiers un disque tandis que le lien est tombé à cause d’une lane défectueuse.

Couche 2 : Interposer/backplane/expander et leur traduction

Les backplanes SAS peuvent inclure des expanders, multiplexeurs et logique « utile ». Une unique lane marginale peut faire disparaître un disque, ou pire, le faire osciller sous charge. Le SATA derrière des expanders SAS fonctionne—jusqu’à ce qu’il ne fonctionne plus, selon l’expander, le firmware du disque et le câblage.

Couche 3 : Firmware et mode de l’HBA/contrôleur

Les HBA peuvent fonctionner en vrai HBA (mode IT) ou faire semblant d’être un contrôleur RAID (mode IR/RAID). Proxmox + ZFS veut un passage direct. La personnalité RAID peut cacher des disques derrière des volumes virtuels, bloquer SMART et compliquer la récupération d’erreurs.

Couche 4 : Énumération PCIe et budget de lanes

Le contrôleur lui-même est un périphérique PCIe. Si la carte mère ne l’énumère pas, Linux non plus. Les réglages de bifurcation PCIe, le câblage du slot et le partage de lanes avec M.2/U.2 peuvent faire qu’un slot « physique x16 » soit électriquement x4—ou x0, si vous contrariez les dieux des lanes.

Couche 5 : Pilotes kernel Linux + création des nœuds

Même quand le matériel va bien, le kernel peut ne pas attacher le bon pilote, ou udev peut ne pas créer les nœuds comme attendu. Multipath peut cacher volontairement des chemins individuels. Un ancien initramfs peut manquer de modules. Les disques peuvent exister mais sous d’autres noms.

Couche 6 : Présentation du stockage par Proxmox

Proxmox VE est Debian sous une UI. Si Debian ne le voit pas, Proxmox ne le verra pas. Si Debian le voit mais que l’UI ne l’affiche pas où vous cherchez, c’est un problème de workflow, pas matériel.

Paraphrase d’une idée de John Allspaw : la fiabilité vient de la bonne réponse aux pannes, pas de faire comme si elles n’existaient pas.

Blague #1 : « Le mode RAID rendra ZFS heureux » revient à dire « j’ai mis un volant sur le grille-pain ; maintenant c’est une voiture ».

Faits et historique utiles au dépannage

• Le scan SCSI est ancien… et toujours là. Les piles SAS modernes et même certaines piles SATA reposent encore sur des scans d’hôtes SCSI, d’où le fait que les rescans peuvent « trouver » des disques sans redémarrage.
• Les HBAs SAS LSI sont devenus la référence. La lignée Broadcom/Avago/LSI compte, car la dénomination des pilotes (mpt2sas/mpt3sas) et les outils firmware s’appuient dessus.
• Le mode IT est devenu populaire parce que les systèmes de fichiers sont devenus plus intelligents. ZFS et systèmes similaires veulent une visibilité directe des disques. Les contrôleurs RAID étaient conçus pour une époque où le contrôleur gérait l’intégrité.
• SFF-8087 et SFF-8643 ressemblent à des « simples câbles » mais sont des systèmes de signal. Un mini-SAS partiellement enfiché peut alimenter des disques et tout de même échouer sur les voies de données. Ce n’est pas magique ; ce sont des paires différentielles et des tolérances.
• Les slots PCIe mentent par marketing. « Slot x16 » signifie souvent « connecteur x16 ». Électriquement, il peut être x8 ou x4 selon le routing CPU/carte mère.
• UEFI a changé le comportement des option ROM. Certaines cartes de stockage dépendent des option ROM pour les écrans d’énumération au démarrage ; les réglages UEFI peuvent masquer ces écrans sans changer ce que Linux voit.
• NVMe a apporté son propre chemin de détection. Les périphériques NVMe ne sont pas des « disques SCSI » et n’apparaîtront pas dans les outils HBA SAS ; ils utilisent le sous-système NVMe et l’entraînement du lien PCIe.
• Le passage SMART n’est pas garanti. Avec les contrôleurs RAID, les données SMART peuvent être bloquées ou nécessiter des outils vendor, ce qui modifie la façon dont vous vérifiez « l’existence » d’un disque.

Tâches pratiques (commandes + signification + décision)

Voici les tâches que j’exécute réellement quand un nœud dit « pas de disques ». Chaque tâche inclut ce que vous regardez et la décision que vous prenez.

Task 1: Confirm the controller is enumerated on 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]

Ce que cela signifie : La carte mère voit l’HBA/le contrôleur NVMe. S’il n’est pas ici, Linux ne verra jamais les disques qui en dépendent.

Décision : Dispositif manquant → réenficher la carte, changer de slot, vérifier les réglages PCIe dans le BIOS, désactiver les périphériques en conflit, vérifier l’alimentation des risers.

Task 2: Verify kernel driver binding

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

Ce que cela signifie : Le bon pilote est attaché. Si « Kernel driver in use » est vide, vous avez un problème de pilote/firmware/blacklist.

Décision : Pas de pilote lié → vérifiez modprobe, les logs kernel, Secure Boot, la compatibilité du firmware et si vous utilisez un kernel fournisseur bizarre.

Task 3: See what disks Linux created (don’t trust the UI yet)

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 -

Ce que cela signifie : S’il est dans lsblk, le kernel le voit. TRAN vous indique s’il s’agit de sas, sata, nvme.

Décision : Disques absents → descendez la pile : dmesg, câblage, expander, alimentation. Disques présents mais Proxmox « manquant » → probablement UI/workflow, multipath ou import ZFS.

Task 4: Check kernel logs for link resets/timeouts

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

Ce que cela signifie : « offline device », « timeout », « link down », spam AER = intégrité du signal, alimentation ou périphérique/contrôleur défaillant.

Décision : Timeouts sur plusieurs disques → câble/backplane/expander/HBA. Timeouts sur un seul disque → ce disque ou son emplacement.

Task 5: List storage controllers the kernel thinks exist

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

Ce que cela signifie : Confirme les adaptateurs hôtes. Si le driver HBA est chargé, il apparaît comme un host.

Décision : HBA absent ici mais présent dans lspci → le pilote ne s’est pas chargé ou a échoué à s’initialiser.

Task 6: Inspect SCSI hosts and rescan for devices

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

Ce que cela signifie : Force un scan de tous les hôtes SCSI. Si les disques apparaissent après cela, la détection est liée au timing/hotplug/expander.

Décision : Si les rescans « réparent » systématiquement, vérifiez le hotplug BIOS, le démarrage échelonné, le firmware expander et le firmware HBA.

Task 7: Check SATA/AHCI detection (onboard ports)

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)

Ce que cela signifie : « link down » sur un port avec un disque indique câblage/port désactivé dans le BIOS/alimentation.

Décision : Si les ports sont link down partout, vérifiez le mode SATA dans le BIOS (AHCI) et si la carte a désactivé des ports quand M.2 est utilisé.

Task 8: Enumerate NVMe devices and controller health

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

Ce que cela signifie : NVMe est présent comme son propre sous-système. Si nvme list est vide mais que lspci montre le contrôleur, cela peut être un problème de pilote, ASPM PCIe ou lien.

Décision : Liste vide → vérifiez journalctl -k pour des erreurs NVMe, les réglages BIOS de vitesse PCIe Gen et la bifurcation du slot (pour des adaptateurs multi-NVMe).

Task 9: Confirm stable disk identifiers (what you should use for 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

Ce que cela signifie : Ces identifiants survivent aux redémarrages et aux renommages de périphériques (sda devenant sdb après des changements matériels).

Décision : Si vos scripts de pool/import utilisent /dev/sdX, arrêtez. Migrez vers by-id/by-wwn avant que votre prochaine fenêtre de maintenance ne vous dévore.

Task 10: Check SMART visibility (tells you if you’re really seeing the disk)

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]

Ce que cela signifie : Si SMART fonctionne, vous avez probablement une vraie visibilité en pass-through. Si SMART échoue derrière un contrôleur RAID, vous aurez peut-être besoin d’autres types de périphériques ou d’outils vendor.

Décision : SMART bloqué + vous voulez ZFS → vérifiez le mode HBA IT ou un vrai HBA, pas la personnalité RAID.

Task 11: Detect if multipath is hiding your disks

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

Ce que cela signifie : Multipath peut présenter des disques comme /dev/dm-* et les /dev/sdX bruts ne sont que des chemins.

Décision : Si ce sont des disques locaux, multipath est une mauvaise configuration. Désactivez-le ou blacklistz les HBA locaux, sinon Proxmox/ZFS pourra utiliser des périphériques « bizarres ».

Task 12: Identify if you’re on a RAID controller with virtual disks

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

Ce que cela signifie : Si le modèle ressemble au contrôleur et que vous ne voyez qu’un seul « disque », vous regardez un disque virtuel, pas les disques physiques.

Décision : Pour ZFS : soit passez à un HBA / flashez le contrôleur en mode IT, soit acceptez que ZFS ne puisse pas gérer correctement les disques individuels.

Task 13: Check if BIOS disabled the slot or remapped 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

Ce que cela signifie : Lien rétrogradé à 2.5GT/s suggère des problèmes d’intégrité du signal, mauvais slot forcé, ou riser/câble défectueux.

Décision : Liens rétrogradés avec erreurs → essayez de forcer Gen3/Gen4 dans le BIOS, changez de slot, remplacez le riser, vérifiez l’enfichage.

Task 14: Proxmox-specific: confirm the kernel and modules match expectations

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

Ce que cela signifie : Confirme que vous utilisez le kernel Proxmox et que le module existe. Des kernels/initramfs non alignés peuvent mordre après des mises à jour.

Décision : Si le module est manquant ou le kernel incorrect, corrigez les paquets et régénérez l’initramfs avant de courir après des fantômes matériels.

HBA, BIOS/UEFI et PCIe : la scène du crime habituelle

Mode HBA : IT vs IR/RAID (et pourquoi Proxmox s’en soucie)

Si vous utilisez ZFS (comme beaucoup de boutiques Proxmox), vous voulez que l’HBA présente chaque disque physique directement à Linux. C’est le mode IT en termes LSI/Broadcom. Le mode RAID (IR) est une philosophie différente : le contrôleur abstrait les disques en volumes logiques. Cette abstraction casse plusieurs choses dont vous dépendez en opérations modernes :

• SMART/état précis par disque (souvent bloqué ou bizarre).
• Identités de disque prévisibles (les WWN peuvent être cachés ou remplacés).
• Surfaces d’erreur claires (les timeouts deviennent « le contrôleur dit non »).
• La capacité de ZFS à gérer la redondance et l’auto-réparation avec une visibilité complète.

De plus : les contrôleurs RAID ont souvent des caches d’écriture, des BBUs et des politiques utiles… jusqu’à ce qu’elles ne le soient plus. ZFS gère déjà sa propre cohérence. Deux capitaines aux commandes donnent le mal de mer.

Paramètres UEFI qui impactent silencieusement la détection

Le BIOS/UEFI peut cacher ou casser votre stockage sans messages d’erreur dramatiques. Les réglages les plus courants à auditer quand les disques disparaissent :

• Mode SATA : AHCI vs RAID. Sur serveurs, le mode RAID peut router les ports via une couche Intel RST-like que Linux ne gèrera peut-être pas comme vous l’attendez.
• Configuration des slots PCIe : vitesse Gen forcée vs Auto ; bifurcation x16 → x4x4x4x4 pour adaptateurs multi-NVMe.
• Option ROM policy : UEFI-only vs Legacy. Cela affecte surtout la visibilité au boot et les écrans de management, mais une mauvaise config peut masquer ce que vous pensez devoir apparaître avant le démarrage.
• IOMMU/VT-d/AMD-Vi : Pas généralement un casseur de détection disque, mais peut changer le comportement des périphériques en passthrough.
• Désactivation des stockages onboard : Certaines cartes désactivent des ports SATA lorsque des slots M.2 sont occupés, ou partagent des lanes avec des slots PCIe.

Partage de lanes PCIe : le « pourquoi mon slot a cessé de fonctionner ? » moderne

Les cartes mères sont des policiers du trafic. Mettez un NVMe dans un slot M.2 et votre HBA peut chuter de x8 à x4, ou le slot adjacent peut être désactivé. Ce n’est pas un « mauvais design ». C’est de l’économie et de la physique : les CPU ont un nombre fini de lanes et les vendeurs multiplexent selon leur feuille technique.

Si vous voyez un contrôleur présent mais instable (erreurs AER, lien down/up), les problèmes de lanes ou d’intégrité du signal sont très probables. Les risers, en particulier, aiment être « assez fonctionnels ».

Blague #2 : Un riser PCIe qui « fonctionne si vous ne touchez pas au châssis » est moins un composant et plus un style de vie.

Câblage, backplanes, expanders et « c’est bien enfiché »

Connecteurs Mini-SAS : pourquoi la défaillance partielle est courante

Les câbles SAS transportent plusieurs lanes. Un seul SFF-8643 peut porter quatre lanes SAS ; un backplane peut mapper les lanes à des baies individuelles. Si une lane lâche, vous ne perdez pas toujours tous les disques. Vous perdez « quelques baies », souvent dans un motif qui ressemble à un problème logiciel.

Règle pratique : si des disques manquent selon un motif répétitif (par ex. baies 1–4 OK, 5–8 mortes), suspectez un câble mini-SAS ou un port spécifique. Ne passez pas une heure dans udev pour un problème qui vit dans le cuivre.

Backplanes avec expanders : bien quand ça marche

Les expanders permettent de connecter beaucoup de disques à moins de ports HBA. Ils ajoutent aussi une couche qui peut contenir des bugs firmware, des bizarreries de négociation et une sensibilité aux disques SATA derrière des expanders SAS. Les symptômes incluent :

• Disques apparaissent après le boot mais disparaissent sous charge.
• Messages intermittents « device offlined ».
• Seuls certains modèles de disques se comportent mal.

Quand cela arrive, on ne « tune » pas Linux. On valide le firmware de l’expander, on échange les câbles, on isole en connectant moins de baies et on teste avec un modèle de disque connu bon.

Distribution d’alimentation et spin-up

Surtout dans les châssis denses, l’alimentation peut être le tueur silencieux. Les disques peuvent démarrer mais s’effondrer pendant la négociation du lien ou lorsque plusieurs disques démarrent simultanément. Certains HBA et backplanes supportent le spin-up échelonné. Certains non. Certains le supportent mais sont mal configurés.

Un signe révélateur est plusieurs disques qui tombent en même temps au démarrage ou pendant un scrub, puis réapparaissent plus tard. Ce n’est pas une « chose Proxmox ». C’est de l’alimentation ou du signal.

Vérifications physiques simples qui battent l’ingéniosité

• Réenfichez les deux extrémités des câbles mini-SAS. Ne « pressez pas doucement ». Déconnectez, inspectez, reconnectez fermement.
• Échangez les câbles entre un port connu bon et un suspect pour voir si le problème suit le câble.
• Déplacez un disque dans une autre baie. Si le disque fonctionne ailleurs, la baie/lane du backplane est suspecte.
• Si possible, connectez temporairement un disque directement à un port HBA (bypassez expander/backplane) pour isoler les couches.

Couche Linux/Proxmox : pilotes, udev, multipath et nœuds de périphérique

Présence du pilote n’est pas santé du pilote

Voir mpt3sas chargé ne garantit pas que le contrôleur s’est initialisé correctement. Un mismatch firmware peut produire une fonctionnalité partielle : le contrôleur s’énumère, mais pas de cibles ; ou les cibles s’énumèrent mais renvoient constamment des erreurs.

Les logs kernel comptent plus que la liste des modules. Si vous voyez des reset répétés, « firmware fault » ou des queues bloquées, traitez cela comme un incident réel : collectez les logs, stabilisez le matériel et envisagez des mises à jour firmware.

Multipath : utile jusqu’à ce que ce ne soit plus le cas

Multipath est conçu pour les SANs et le stockage à double chemin. Sur un nœud Proxmox avec des disques SAS locaux, c’est généralement accidentel et nuisible. Il peut masquer les périphériques attendus, ou créer des nœuds device-mapper que Proxmox/ZFS utilisera de façon incohérente si vous n’êtes pas explicite.

Si vous n’utilisez pas explicitement multipath pour du stockage partagé, vous voulez généralement le désactiver ou le configurer pour ignorer les disques locaux.

Nomination des périphériques : /dev/sdX est un piège

Linux assigne les noms /dev/sdX dans l’ordre de découverte. Ajoutez un contrôleur, réordonnez les câbles, ou changez les réglages de boot BIOS et l’ordre change. C’est ainsi que vous importez les mauvais disques, effacez le mauvais périphérique, ou créez un pool sur les mauvais membres.

Utilisez /dev/disk/by-id ou les WWN. Faites-en une politique. Votre futur vous remerciera en silence.

Quand Proxmox « n’affiche pas les disques » mais Linux oui

Réalités communes :

• Les disques ont d’anciennes partitions et l’UI Proxmox filtre ce qu’elle considère comme « disponible ».
• ZFS utilise déjà les disques (ils appartiennent à un pool importé ou à un pool obsolète). ZFS ne partagera pas poliment.
• Vous regardez au mauvais endroit : disques du nœud vs définitions de stockage vs vue datacenter.
• Multipath ou device-mapper présente des noms différents de ceux attendus.

Angle ZFS : pourquoi le « mode RAID » n’est pas votre ami

Proxmox intègre un support ZFS de première classe. ZFS suppose qu’il gère la redondance, les checksums et la réparation. Le RAID matériel suppose lui gérer la redondance et la récupération d’erreurs. En empilant les deux, vous créez un système où chaque couche prend des décisions sans information complète.

Ce qui « marche » mais est quand même mauvais

• Créer un énorme volume RAID0/RAID10 et mettre ZFS dessus : ZFS perd la visibilité par disque et ne peut pas isoler les membres défaillants.
• Utiliser le cache du contrôleur RAID avec ZFS et des écritures sync : vous pouvez tromper ZFS sur la durabilité si la politique de cache est unsafe.
• Supposer que le contrôleur remontera proprement les erreurs disque : il peut remapper, relancer ou masquer jusqu’à l’impossibilité.

Ce que vous devriez faire à la place

• Utilisez un HBA (ou flashez le contrôleur en mode IT) et présentez les disques bruts à ZFS.
• Utilisez des identifiants stables lors de la création des pools.
• Préférez des combinaisons firmware stables et éprouvées. Le bleeding edge est génial pour le labo, pas pour votre quorum de cluster.

Erreurs courantes : symptôme → cause → correctif

1) Symptom: HBA not in lspci

Cause : Carte non enfichée, slot mort, partage de lanes a désactivé le slot, riser défaillant, ou BIOS a désactivé ce slot.

Fix : Réenficher, essayer un autre slot, retirer le riser, vérifier « PCIe slot enable » dans le BIOS, vérifier le partage de lanes avec M.2/U.2, mettre à jour le BIOS si ancien.

2) Symptom: HBA in lspci but no disks in lsblk

Cause : Pilote non lié, mismatch firmware, HBA en mode requérant la stack vendor, câble/backplane cassé empêchant la découverte des cibles.

Fix : Vérifier lspci -k, consulter journalctl -k, rescanner les hôtes SCSI, échanger les câbles, valider firmware et mode HBA (IT pour ZFS).

3) Symptom: Some bays missing in a pattern

Cause : Une lane/câble/port SAS est en panne ; le mapping du backplane correspond à l’ensemble manquant.

Fix : Échanger le câble mini-SAS ; déplacer sur un autre port HBA ; réenficher le connecteur ; vérifier pins tordus/dommages.

4) Symptom: Disks appear after rescan but vanish after reboot

Cause : Timing hotplug, bizarreries d’expander, spin-up échelonné mal configuré, alimentation marginale au boot.

Fix : Mettre à jour firmware HBA/backplane/expander, activer le spin-up échelonné si supporté, vérifier l’alimentation et la distribution PSU, inspecter les logs de boot pour resets.

5) Symptom: NVMe not detected, but works in another machine

Cause : Slot désactivé à cause de réglages de bifurcation, PCIe Gen forcé trop haut/bas, partage de lanes avec SATA, ou l’adaptateur nécessite la bifurcation.

Fix : Définir la bifurcation correcte, mettre la vitesse PCIe sur Auto/Gen3/Gen4 appropriée, déplacer dans un slot attaché au CPU, mettre à jour le BIOS.

6) Symptom: Proxmox GUI doesn’t show disks, but lsblk does

Cause : Partitions existantes/métadonnées LVM, ZFS revendique déjà les disques, présentation multipath, ou vous regardez la mauvaise vue UI.

Fix : Utilisez la CLI pour confirmer by-id, vérifiez zpool status/zpool import, vérifiez multipath -ll, effacez les signatures uniquement quand vous êtes sûr.

7) Symptom: SMART fails with “cannot open device” behind controller

Cause : Abstraction du contrôleur RAID ; le passage SMART nécessite un type de périphérique spécial ou n’est pas supporté.

Fix : Utilisez HBA/mode IT pour ZFS ; sinon utilisez les outils vendor et acceptez les limites.

8) Symptom: Disks flap under load, ZFS sees checksum errors

Cause : Intégrité du signal câble/backplane/expander ou alimentation insuffisante ; parfois un disque empoisonne le bus.

Fix : Remplacez les câbles en premier, isolez en retirant des disques, vérifiez dmesg pour des resets, validez la santé du PSU et du backplane.

Checklists / plan étape par étape

Checklist A: “Installer can’t see any disks”

1. Entrez dans le BIOS/UEFI et confirmez que le contrôleur est activé et visible.
2. Confirmez que le mode SATA est AHCI (sauf si vous avez explicitement besoin du RAID pour un volume de boot).
3. Pour un HBA : vérifiez qu’il est en mode IT ou véritable HBA (pas MegaRAID volumes virtuels) si vous voulez ZFS.
4. Déplacez l’HBA dans un autre slot PCIe (préférez les slots attachés au CPU).
5. Démarrez un environnement de secours et lancez lspci et dmesg. S’il manque là aussi, c’est matériel.
6. Remplacez les câbles mini-SAS et réenfichez les connecteurs aux deux extrémités.
7. Si vous utilisez un backplane expander : faites un test en connexion directe avec un disque.

Checklist B: “Some disks missing behind HBA”

1. Lancez lsblk et identifiez quelles baies manquent ; cherchez des motifs.
2. Vérifiez les logs pour des resets de lien et périphériques offlined.
3. Rescannez les hôtes SCSI ; voyez si les disques manquants apparaissent.
4. Échangez le câble alimentant l’ensemble de baies manquant.
5. Déplacez le câble sur un autre port HBA ; voyez si l’ensemble manquant suit.
6. Déplacez un disque manquant dans une baie connue bonne ; s’il apparaît, la baie/lane est mauvaise.
7. Mettez à jour le firmware HBA si vous avez une révision problématique connue.

Checklist C: “Disks detected in Linux but not usable in Proxmox”

1. Confirmez les identifiants stables dans /dev/disk/by-id.
2. Vérifiez si ZFS propose un pool importable : zpool import.
3. Vérifiez si les disques ont des signatures : wipefs -n /dev/sdX (le -n est le drapeau sécurité ; conservez-le).
4. Vérifiez multipath : multipath -ll.
5. Décidez votre intention : importer des données existantes vs effacer et réutiliser.
6. Si vous effacez, faites-le délibérément et documentez quels WWN vous avez nettoyés.

Checklist D: “NVMe not showing up”

1. Confirmez le contrôleur dans lspci.
2. Vérifiez nvme list et les logs kernel pour des timeouts.
3. Inspectez le statut du lien PCIe (LnkSta) pour des rétrogradations.
4. Définissez la bifurcation correcte pour les adaptateurs multi-NVMe.
5. Déplacez le NVMe dans un autre slot et retestez.

Trois mini-histoires d’entreprise issues du terrain

Mini-story 1: The incident caused by a wrong assumption

L’équipe déployait un nouveau cluster Proxmox pour des workloads CI internes. Le plan de stockage était « simple » : huit disques SAS par nœud, miroirs ZFS, terminé. Les achats ont livré des serveurs avec un « contrôleur SAS RAID » au lieu du HBA demandé. Personne n’a paniqué parce que le contrôleur avait toujours « SAS » dans le nom et le BIOS montrait un gros disque logique.

Ils ont installé Proxmox sur ce volume logique et construit des pools ZFS sur ce que le contrôleur exposait. Ça a fonctionné quelques semaines, ce qui permet aux mauvaises hypothèses de devenir « décisions de conception ». Puis un disque a commencé à lâcher. Le contrôleur a remappé et relancé dans des modes que ZFS ne pouvait pas observer, et le nœud a commencé à se bloquer pendant les scrubs. Les logs étaient pleins de timeouts mais rien ne correspondait proprement à une baie physique.

Pendant la fenêtre de maintenance, quelqu’un a retiré le disque « en échec » selon l’UI du contrôleur. Le mauvais. Le contrôleur avait changé son numérotage interne après des remaps antérieurs, et la feuille de mapping était obsolète. Le volume logique a alors degradé différemment, ZFS s’est fâché, et le cluster a perdu une partie de capacité pendant la charge maximale.

La réparation fut peu glamour : remplacer le contrôleur RAID par un vrai HBA, reconstruire le nœud, et imposer une politique : ZFS obtient des disques bruts, identifiés par WWN, et le mapping baie→WWN est validé avec LEDs et numéros de série avant toute intervention. L’hypothèse « SAS égale HBA » était la cause racine et ça leur a coûté un week-end.

Mini-story 2: The optimization that backfired

Une autre équipe avait des problèmes de performance pendant les resilvers ZFS. Quelqu’un a suggéré « optimiser le câblage » en utilisant un seul backplane expander pour réduire les ports HBA et garder l’assemblage propre. Moins de câbles, moins de points de défaillance, non ?

En pratique, l’expander a introduit un comportement subtil : pendant des I/O intenses, quelques SSD SATA (utilisés comme vdevs spéciaux) perdaient intermittemment la connexion pendant quelques secondes, puis revenaient. Le HBA et le kernel loggaient des resets de lien, et ZFS marquait des périphériques comme défaillants ou dégradés selon le timing. Le symptôme ressemblait à « ZFS est instable » car les coupures étaient transitoires.

L’équipe a essayé de tuner les timeouts et les profondeurs de queue, parce que les ingénieurs aiment tourner des boutons et l’expander semblait « enterprise ». Le tuning a réduit les erreurs visibles mais n’a pas résolu la cause. Lors d’un vrai incident—redémarrage du nœud plus récupération simultanée de VM—les périphériques ont replafonné et le pool a refusé de s’importer proprement sans intervention manuelle.

Ils ont annulé l’« optimisation ». Connecter directement les SSD sensibles, garder l’expander pour les HDD massifs où la latence compte moins, et standardiser les modèles de disques derrière l’expander. La performance et le sommeil se sont améliorés. Parfois moins de câbles, c’est juste moins d’indices quand ça casse.

Mini-story 3: The boring but correct practice that saved the day

Une équipe avait l’habitude, jugée pédante, d’enregistrer chaque disque par WWN et emplacement de baie à l’installation. Ils tenaient une feuille simple : numéro de châssis, numéro de baie, numéro de série du disque, WWN, et l’appartenance prévue au vdev ZFS. Ils étiquetaient aussi les câbles par port HBA et connecteur backplane. Personne n’aimait le faire, mais c’était une politique.

Un an plus tard, un nœud commence à rapporter des erreurs de checksum intermittentes pendant les scrubs. Les logs suggèrent un lien instable, pas un disque qui meurt, mais la topologie du pool comprenait douze disques et un expander backplane. Dans l’ancien monde, cela aurait dégénéré en « retirer des disques jusqu’à ce que les erreurs s’arrêtent ». C’est comme ça qu’on crée de nouveaux incidents.

Au lieu de ça, ils ont corrélé le WWN affecté avec la baie. Les erreurs étaient toujours sur des disques dans les baies 9–12. Ça correspondait à un seul câble mini-SAS alimentant cette section du backplane. Ils ont changé le câble pendant une courte fenêtre de maintenance, relancé un scrub, et les erreurs ont disparu.

Sans drame. Sans devinettes. La pratique ennuyeuse d’inventaire a transformé un incident potentiellement compliqué en une réparation de 20 minutes avec une cause claire. La fiabilité est souvent juste de la tenue de registres avec conviction.

FAQ

1) Proxmox installer shows no disks. Is it always an HBA driver issue?

Non. Si lspci n’affiche pas le contrôleur, c’est BIOS/PCIe/matériel. Si le contrôleur apparaît mais pas les disques, alors cela peut être un pilote/firmware/câblage.

2) I see disks in BIOS but not in Linux. How is that possible?

Le BIOS peut montrer des volumes RAID virtuels ou un résumé du contrôleur sans exposer les targets à Linux. Ou Linux manque du bon module, ou le contrôleur échoue à s’initialiser au boot (vérifiez journalctl -k).

3) Do I need IT mode for Proxmox?

Si vous utilisez ZFS et voulez des opérations raisonnables, oui. Si vous insistez pour du RAID matériel, vous pouvez l’utiliser, mais vous choisissez alors un modèle opérationnel différent avec des outils différents.

4) Why do disks show up as /dev/dm-0 instead of /dev/sda?

Généralement multipath ou empilement device-mapper (LVM, dm-crypt). Pour des disques locaux que vous ne vouliez pas multipath, corrigez la config multipath ou désactivez-le.

5) My disks appear, but Proxmox GUI doesn’t list them as available. Are they broken?

Souvent ils ont des signatures existantes (anciens métadonnées ZFS/LVM/RAID) ou font déjà partie d’un pool importé. Vérifiez avec lsblk, wipefs -n et zpool import avant toute action destructive.

6) Can a bad SAS cable really cause only one disk to disappear?

Oui. Mini-SAS transporte plusieurs lanes ; selon le mapping du backplane, une lane défectueuse peut isoler une seule baie ou un sous-ensemble. Les motifs sont vos amis.

7) NVMe not detected: what’s the single most common BIOS mistake?

Mauvaise configuration de bifurcation pour des adaptateurs multi-NVMe, ou partage de lanes qui désactive le slot quand un autre M.2/U.2 est peuplé.

8) Should I force PCIe Gen speed to fix link issues?

Parfois forcer une Gen inférieure stabilise des liens instables (utile pour diagnostiquer), mais la vraie réparation est souvent l’enfichage, les risers, le câblage ou le choix du slot/carte mère.

9) How do I decide between “replace disk” and “replace cable/backplane”?

Si plusieurs disques montrent des erreurs sur le même port HBA/segment de backplane, suspectez le câble/backplane. Si un seul disque suit le disque à travers les baies, c’est le disque.

10) Is it safe to rescan SCSI hosts on a production node?

Généralement oui, mais faites-le avec conscience de la situation. Les rescans peuvent déclencher des événements de découverte et du bruit dans les logs. Évitez pendant des opérations sensibles de stockage si vous êtes déjà en dégradé.

Conclusion : prochaines étapes pratiques

Si Proxmox ne voit pas les disques, arrêtez de deviner et parcourez la chaîne : énumération PCIe → liaison du pilote → stabilité du lien → découverte des targets → identifiants stables → consommation par Proxmox/ZFS. Les gains rapides sont généralement physiques : enfichage, allocation de lanes et câbles. Les échecs les plus coûteux viennent du mauvais mode de contrôleur et d’un nommage de périphérique négligent.

1. Exécutez le playbook de diagnostic rapide et classez le domaine de défaillance en 10 minutes.
2. Collectez des preuves : lspci -k, lsblk et les logs kernel autour du moment de détection.
3. Standardisez : HBA/mode IT pour ZFS, noms by-id, et une carte baie→WWN.
4. Corrigez la cause racine, pas le symptôme : remplacez câbles/riser suspects, corrigez la bifurcation BIOS, mettez à jour le firmware avec méthode.
5. Après récupération, effectuez un scrub/resilver test et relisez les logs. Si vous ne vérifiez pas, vous n’avez pas réparé — vous avez juste arrêté de voir le problème.