Notes de X4VI3RG

Proxmox injoignable : quand la carte réseau Intel I219 se fige

· 7 min de lecture

#proxmox#homelab#réseau#linux#troubleshooting

Sommaire

Samedi matin, mon hyperviseur Proxmox ne répond plus. Pas de ping, pas de SSH, pas d'interface web, et toutes les VMs semblent mortes. Je redémarre la machine au bouton, tout revient. Reste à comprendre ce qui s'est passé, et surtout comment éviter de redémarrer la prochaine fois.

Le contexte

  • Un mini-PC sous Proxmox VE (kernel 7.0.14-x-pve), avec la carte réseau Intel I219 intégrée (driver e1000e).
  • Une seule interface physique, eno1, bridgée dans vmbr0 pour toutes les VMs et les conteneurs.
  • Un backup vzdump nocturne vers un NAS en NFS.
  • Quelques services exposés sur Internet via un reverse proxy qui tourne dans une VM.

Architecture réseau de l'hôte pendant l'incident

Toute la machine dépend d'une seule carte. Si elle se bloque, l'hôte et toutes ses VMs disparaissent du réseau d'un coup, même s'ils tournent parfaitement.

Lire les logs du boot précédent

Le réflexe de base après un reboot forcé est d'aller voir ce que le système a écrit avant l'arrêt :

journalctl -b -1 -n 200 --no-pager

La sortie est sans ambiguïté. Le même bloc revient toutes les 2 secondes :

kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:
  TDH                  <59>
  TDT                  <e3>
  next_to_use          <e3>
  next_to_clean        <58>
  ...
  PHY 1000BASE-T Status  <3800>

Viennent ensuite, logiquement :

pvestatd: storage 'NAS-BACKUP' is not online

Puis mon appui sur le bouton :

systemd-logind: Power key pressed short.
systemd-logind: Powering off...

Ce que ça veut dire

  • Le serveur n'avait pas planté. Le kernel, le stockage et les VMs tournaient. Seule la carte réseau était bloquée.
  • Hardware Unit Hang signifie que la file d'émission (TX) de la carte est figée : la tête (TDH) et la queue (TDT) du ring buffer ne bougent plus, et plus aucun paquet ne sort.
  • Le NAS « offline » n'est qu'une conséquence, puisqu'il est joignable via cette même carte.
  • L'arrêt a été propre : les VMs ont reçu un shutdown normal.

C'est un problème bien connu des contrôleurs Intel I219 avec le driver e1000e, en particulier sous Proxmox, et souvent associé aux fonctions d'offload matériel (TSO/GSO).

Chercher le déclencheur

Quand le premier hang est-il apparu ?

journalctl -b -1 | grep -m1 "Hardware Unit Hang"
# → 07:20:49

Le backup démarre à 01:00, donc à première vue il n'y a pas de lien. Mais en cherchant la fin de la tâche :

journalctl -b -1 --since "01:00" | grep -iE "vzdump|end task" | tail

On ne trouve aucun end task pour le vzdump. Le backup tournait encore à 07:20, après plus de 6 heures.

Chronologie de l'incident

C'est un transfert long et soutenu vers le NAS, exactement le genre de charge qui fait caler cette carte. Les 10 minutes précédant le hang ne montrent rien d'anormal (man-db, cron horaire) : le déclencheur est le trafic, invisible dans le journal.

Un indice dans le registre PHY

Sur le tout premier hang, une valeur diffère des suivants :

PHY 1000BASE-T Status  <38ff>   # premier hang
PHY 1000BASE-T Status  <3800>   # tous les suivants

Les 8 bits de poids faible de ce registre forment le compteur d'idle errors du lien gigabit. ff signifie qu'il est saturé : des erreurs au niveau physique ont eu lieu juste avant le blocage. C'est une piste matérielle à ne pas négliger (câble, port du switch).

ethtool eno1 | grep -E "Speed|Duplex|Link detected"
ethtool -S eno1 | grep -iE "err|crc|drop|miss|fifo" | grep -v ": 0"

Écarter un piratage

Avec des services exposés sur Internet, la question se pose. Rien ne va dans ce sens :

  • un Hardware Unit Hang est un bug driver ou matériel, pas quelque chose qu'on déclenche à distance sur commande ;
  • last et les logs SSH ne montrent aucune connexion pendant toute la durée du boot concerné ;
  • aucun process ni événement suspect avant le hang.

Seule réserve : un afflux massif de trafic (scan, DDoS) pourrait charger la carte et précipiter le bug. Ce ne serait pas une intrusion, juste un déclencheur de plus. Pour le vérifier, il faut les logs du reverse proxy. S'il n'écrit pas de fichiers, comme NPMplus par défaut, on passe par docker logs :

C=$(docker ps -qf name=npm)
docker logs $C --since "2026-10-24T05:10:00Z" --until "2026-10-24T05:21:00Z" 2>&1 | wc -l

docker logs raisonne en UTC : 07:10 heure de Paris (CEST) correspond à 05:10 UTC.

Au passage, quelques bonnes pratiques d'hygiène :

  • SSH root par clé uniquement (PermitRootLogin prohibit-password) ;
  • l'interface Proxmox (:8006) jamais exposée publiquement, seulement depuis le LAN ou un VPN ;
  • restreindre au VPN les proxy hosts qui n'ont pas besoin d'être publics.

Le correctif : désactiver l'offload

La solution standard consiste à désactiver TSO, GSO et GRO sur l'interface :

ethtool -K eno1 tso off gso off gro off

Pour la rendre persistante, dans /etc/network/interfaces :

iface eno1 inet manual
        post-up /usr/sbin/ethtool -K eno1 tso off gso off gro off

ifreload -a
ethtool -k eno1 | grep -E "segmentation|receive-offload"

À 1 Gb/s, l'impact sur les performances est négligeable.

Si le problème revient, voici les crans suivants, du plus léger au plus radical :

  1. désactiver aussi le checksum offload : ethtool -K eno1 rx off tx off ;
  2. désactiver l'Energy Efficient Ethernet : ethtool --set-eee eno1 eee off ;
  3. ajouter pcie_aspm=off à la ligne de commande du kernel ;
  4. épingler un kernel antérieur (proxmox-boot-tool kernel pin <version>) ;
  5. changer de carte réseau (PCIe ou USB dédiée).

Débloquer sans redémarrer

Le serveur tourne, seule la carte est bloquée. On peut donc la réinitialiser à chaud.

À la main, depuis la console locale

# 1. Reset du lien
ip link set eno1 down; sleep 2; ip link set eno1 up

# 2. Si insuffisant : recharger le driver puis le bridge
modprobe -r e1000e && modprobe e1000e && ifreload -a

Les VMs continuent de tourner pendant l'opération, elles perdent seulement le réseau quelques secondes.

Automatiquement, avec un watchdog

Un petit script ping la passerelle et répare tout seul si elle ne répond plus. Dans /usr/local/sbin/nic-watchdog.sh :

#!/bin/bash
GW=192.168.1.1   # passerelle en dur : la route peut disparaître pendant le hang
ping -c3 -W2 "$GW" >/dev/null && exit 0

logger -t nic-watchdog "passerelle $GW injoignable, reset de eno1"
ip link set eno1 down; sleep 2; ip link set eno1 up; sleep 10
ping -c3 -W2 "$GW" >/dev/null && { logger -t nic-watchdog "OK après reset du lien"; exit 0; }

logger -t nic-watchdog "échec, rechargement de e1000e"
modprobe -r e1000e && modprobe e1000e && sleep 5 && ifreload -a

chmod +x /usr/local/sbin/nic-watchdog.sh
echo '* * * * * root /usr/local/sbin/nic-watchdog.sh' > /etc/cron.d/nic-watchdog

Exécuté toutes les minutes, il ramène le réseau en 1 à 2 minutes au pire. Pour suivre ses interventions :

journalctl -t nic-watchdog

Un accès de secours en WiFi

Si la machine a une carte WiFi, elle peut servir d'accès d'administration hors bande, indépendant de eno1 (en pointillés violets sur le schéma d'architecture).

Deux pièges :

  1. Pas de bridge : le WiFi ne peut pas être ajouté à vmbr0. Il sert uniquement à administrer l'hôte, pas les VMs.
  2. Le routage : pendant un Hardware Unit Hang, eno1 reste « UP ». Le kernel continue donc d'envoyer les réponses par la carte morte, même si la requête est arrivée par le WiFi. Il faut du policy routing.
apt install wpasupplicant firmware-iwlwifi   # nécessite non-free-firmware
wpa_passphrase "MonSSID" "motdepasse"        # pour obtenir le hash du PSK

Dans /etc/network/interfaces :

auto wlp2s0
iface wlp2s0 inet static
        address 192.168.1.51/24
        wpa-ssid MonSSID
        wpa-psk  <hash>
        post-up   ip rule add from 192.168.1.51 table 100
        post-up   ip route add 192.168.1.0/24 dev wlp2s0 src 192.168.1.51 table 100
        post-up   ip route add default via 192.168.1.1 dev wlp2s0 table 100
        pre-down  ip rule del from 192.168.1.51 table 100

Il ne faut pas de ligne gateway, pour éviter deux routes par défaut. Le SSH et l'interface web (:8006) répondent alors aussi sur l'IP WiFi.

Autre option sur les machines pro équipées de vPro : Intel AMT donne une console et un reset à distance, même quand l'OS n'a plus de réseau.

En résumé

Symptôme Cause Réponse
Hôte injoignable, VMs « mortes » File TX de l'I219 figée (Hardware Unit Hang) ethtool -K eno1 tso off gso off gro off
Déclenché pendant un long backup NFS Charge réseau soutenue Offload désactivé et persistant
Idle errors sur le lien PHY Câble ou port suspect Changer de câble, tester un autre port
Reboot nécessaire pour récupérer Pas d'accès hors bande Watchdog cron + accès WiFi de secours

La leçon principale : avant d'appuyer sur le bouton, vérifier si c'est vraiment l'hôte qui est mort. Ici, la machine tournait parfaitement. Il lui manquait juste une carte réseau qui veuille bien envoyer ses paquets.