Le LoM OCe14000 signale un lien up alors que le câble est retiré, donc le teaming ESXi ne bascule jamais
Petit cluster vSphere, deux uplinks 10G par hôte vers une paire de switches top-of-rack. Après le redémarrage du ToR pour une mise à jour de firmware, une partie des VM sur un hôte est devenue silencieuse et vMotion a échoué sur les deux uplinks - pourtant ESXi n'a jamais rien marqué down et les LED de l'adaptateur sont restées allumées tout du long.
- Fujitsu Primergy RX2540 M1
- Adaptateur Emulex OneConnect OCe14000 intégré à la carte mère (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- optiques SFP+ vers le ToR, teaming actif/standby simple sur le vSwitch
Ce qui m'a convaincu que ce n'est pas le switch : j'ai complètement retiré la fibre de l'adaptateur et il a toujours l'air vivant.
esxcli network nic get -n vmnic2 (cable physically removed)
Link Status: Up
Firmware Version: 11.2.1194.36
esxcli software vib list | grep elxnet
elxnet 10.2.309.6vDéjà essayé :
- réinséré l'optique et la fibre, échangé le cordon de brassage
- déplacé l'uplink vers l'autre switch ToR, dont le port passe down comme attendu
- redémarré les agents de gestion sur l'hôte
Comme l'hôte croit que l'uplink est vivant, la politique de teaming n'a aucune raison de bouger quoi que ce soit et les VM restent épinglées à un port mort. Est-ce un problème connu de driver contre firmware sur OneConnect, ou devrais-je regarder du côté du matériel LoM ?
Comments 6
Cette combinaison est de votre fait, et elle n'est pas listée comme paire supportée pour ESXi 6.0. L'adaptateur finit à moitié vivant : il arrête de faire passer le trafic mais continue à annoncer le port comme connecté, donc la politique de teaming n'obtient jamais l'événement down dont elle a besoin pour agir. C'est pourquoi ça vous est arrivé comme une isolation partielle avec vMotion mort sur les deux uplinks au lieu d'une panne franche de carte réseau - une carte qui meurt proprement est bien plus facile à survivre qu'une qui ment.
Montez le driver à 11.2.1149.0. C'est le niveau elxnet qualifié avec le firmware 11.2.1194.36 dans la liste de compatibilité VMware, donc vous faites avancer le driver pour rejoindre le firmware plutôt que de faire régresser la carte. Vérifiez ensuite avec les deux commandes que vous avez déjà :
La ligne vib devrait montrer la nouvelle version, et Link Status devrait à nouveau suivre le câble une fois l'hôte redémarré. Testez-le en retirant la fibre avec une VM tournant sur cet uplink avant de faire confiance au cluster.
L'habitude à retenir : sur OneConnect, le driver et le firmware avancent en paire, donc planifiez les deux ensemble plutôt que de laisser un bundle de maintenance en faire avancer un seul de son côté. Comparer ces deux lignes prend une commande, et ça a sa place bien avant de commencer à retirer des optiques ou à accuser le switch.
Les deux lignes que vous avez postées sont la partie intéressante : firmware 11.2.1194.36 tournant sous elxnet 10.2.309.6v. Ce firmware est-il arrivé à un moment donné avec un bundle de maintenance serveur, séparément du driver ?
Vérifiez cette paire par rapport à la liste de compatibilité pour ESXi 6.0, pas par rapport à « le plus récent doit forcément aller ». OneConnect fait partie des familles où driver et firmware sont qualifiés en paire, et une paire mal assortie ne tombe pas nécessairement en panne bruyamment - elle fonctionne à moitié, ce qui est bien pire.
Utile aussi de dire si le second port de l'adaptateur se comporte de la même façon avec son câble retiré.
Oui, le firmware est arrivé avec un bundle de maintenance serveur ; le driver n'a pas été touché depuis la construction de l'hôte.
Les deux ports LoM se comportent de façon identique : câble retiré, esxcli network nic get rapporte toujours Link Status: Up, les LED restent allumées, et le vSwitch garde l'uplink dans la liste active. Le côté switch est propre et son port tombe dès que je débranche.
Donc la seule chose désaccordée sur cet hôte, c'est la version elxnet par rapport au firmware 11.2.1194.36.
Famille différente, même leçon. Une paire de ports FC Emulex LPe31000/LPe32000 qui tournaient sans y toucher depuis des lustres a cessé de voir des LUN après qu'un noyau Proxmox est passé à la 5.15.64 puis à la 5.15.74. Câblage et optiques jamais touchés, et le journal disait :
C'est une régression lpfc côté hôte, pas un défaut optique ; elle est apparue dans les noyaux après la 5.15.60. Bloquer le noyau de démarrage sur une version antérieure était le contournement qui a tenu en production :
Le noyau optionnel 5.19 a aussi fonctionné pour ceux qui ne voyaient pas d'inconvénient à quitter la branche 5.15. La correction était censée arriver dans la 5.15.77, mais je n'ai jamais eu l'occasion de faire tourner ce build moi-même, donc prenez ça comme une rumeur. Le point reste valable : quand un lien qui fonctionnait meurt juste après qu'un changement a eu lieu sur l'hôte, lisez le journal des changements de l'hôte avant d'approcher les transceivers.
J'ajoute l'image miroir de tout ça, parce que ça entraîne le même réflexe. Les indicateurs sont du logiciel, et le logiciel se trompe dans les deux sens.
Sur EX3400 et EX2300, il y a un défaut Junos, PR1428703, où les LED des ports SFP+ et SFP restent éteintes alors que le lien est réellement up et fait passer du trafic. Les gens l'ont rencontré en passant de la 15.1X53 aux branches 18.1 et 19.x, surtout avec du DAC. La CLI est en désaccord avec le panneau :
signale la LED comme Green alors que la physique est éteinte. Certains builds ont été signalés comme corrigés et des LED éteintes ont continué à être signalées sur d'autres, donc je ne dirais pas que c'est proprement clos.
La vôtre est allumée sans lien, celle-là est éteinte avec un lien. Dans les deux cas, faites confiance à l'autre bout et aux compteurs, jamais à l'indicateur.
Le driver est maintenant en 11.2.1149.0 sur les deux hôtes. Câble retiré, les LED s'éteignent, esxcli rapporte le lien down, et l'uplink standby prend le relais comme ça aurait toujours dû être le cas - vMotion a tourné proprement sur chaque uplink séparément en test.
La paire driver-et-firmware va entrer dans notre checklist de maintenance serveur pour que le prochain bundle ne les sépare pas discrètement à nouveau.