Pilotes HP pour ESXi vs Paquets droppés

Alors que l’on s’apprêtait à mettre en production des nouvelles lames BL465c G7 dans des châssis HP c7000 hébergeant des ESXi qui ont été installés avec l’image ISO HP customisée (disponible ici, cette image contient en natif les pilotes nécessaires pour la prise en charge de tous les périphériques présents dans les générations 7 et 8 des serveurs HP, notamment les cartes FCoE OnBoard FlexFabric), on a commencé à avoir des remontées d’alarmes sur les paquets droppés (grâce aux fameuses alarmes « croissants-baguette » d’hypervisor disponibles ici : Alarmes vCenter pour les network packets dropped) :

Ces alertes sont apparues alors qu’il n’y avait aucune VM hébergée par ces serveurs, donc potentiellement très peu de trafic réseau. Puisque presque tout troubleshooting passe par l’outil esxtop on a fait un tour  dans le contexte réseau (touche ‘n’) :

Ce qui était bizarre c’est qu’on ne voyait aucun paquet droppé en envoi (compteur %DRPTX) ou en réception (compteur %DRPRX) alors que le graphe de performance du vCenter en affichait.

Vu que le compteur du vCenter est un compteur en summation (ie compteur calculé à partir de valeurs récupérées sur une plage de temps), on a voulu s’assurer que les compteurs esxtop restaient à zéro. On a donc lancé un jeu d’esxtop en mode batch (qui redirige les résultats dans un fichier externe), et en important ces résultats dans un perfmon, on a bien vu qu’a aucun moment les compteurs esxtop ont dépassé 0 …

On vous passe tous les tests infructueux pour trouver d’où pourrait venir cette différence d’interprétation entre les compteurs esxtop et le graphe de performance vCenter. Dans un ultime essai de comprendre d’où cela aurait pu venir, nous avons réalisé une capture de trame depuis l’un des ESXi ayant le problème (aucune VM ne tournait dessus, le serveur était en mode maintenance) via la commande tcpdump-uw :

tcpdump-uw -i vmk0 -s 1514 -w traffic.pcap

Cette commande permet de lancer une capture de trame réseau en n’écoutant que sur l’interface vmk0 (-i vmk0), en capturant toute la trame réseau (-s 1514 pour une trame normale ou -s 9014 pour une trame Jumbo Frames) et en sauvegardant les trames au format pcap pour pouvoir les ouvrir par la suite dans WireShark.

Malheureusement, après une longue étude des trames récupérées, rien n’apparaissaient comme suspect, ou avec une mauvaise destination qui aurait pu être droppé par la vmnic …

Dans une dernière recherche de cause, vu que l’image HP pour ESXi venait juste de sortir (à peine quelques semaines), on s’est demandé si le problème n’aurait pas pu venir des pilotes embarqués. OK, la version était supportée par HP, mais on se rappelle d’anciennes expériences douloureuses avec des pilotes pour cartes Flex10 générant des PSOD ou des pertes aléatoires de connexions, donc bon :p

En comparant via la commande ethtool des lames installées il y a quelques mois et les nouvelles lames (avec la même configuration matérielle), on voit effectivement une différence au niveau de la version utilisée (le pilote et le firmware étant les mêmes), sur une ancienne lame, la version est en 2.102.518.0 :

Alors que les nouvelles lames sont en version 4.1.334.0 :

Nous avons donc effectuer un downgrade du pilote ESXi des cartes OnBoard FlexFabric pour revenir vers la même version que les autres lames pour pouvoir comparer.

Cela s’effectue via la commande esxupdate, on récupère tout d’abord le nom du package installé correspondant au pilote :

esxupdate query --vib-view | grep -i be2net

Ensuite, on supprime ce package :

esxupdate -b cross_oem-vmware-esx-drivers-net-be2net_400.4.1.334.0-1vmw.2.17.249663 remove

Puis on installe le package avec la version voulue (le bundle a été mis sur un datastore pour un accès simplifié depuis le serveur ESXi) :

esxupdate --bundle=/vmfs/volumes/d3a29a6f-aa4be900/SVE-be2net-2.102.518.0-offline_bundle-329992.zip update

Note: Il faut redémarrer le serveur pour que cela soit effectif

Une fois cela fait, plus aucun paquet droppé, même avec du load important !

Moralité, tester, tester, toujours tester avant de mettre en production (et cela pour tous les composants, CPU, mémoire, disques, etc…) ! Et bien connaitre son infra pour savoir exactement ce qui se passe dessus (encore merci aux alarmes « croissants-baguette » de Super Hypervisor !)

2 comments

Laisser un commentaire

Required fields are marked *.