El LoM OCe14000 reporta el enlace activo con el cable desconectado, así que el teaming de ESXi nunca hace failover
Clúster pequeño de vSphere, dos enlaces ascendentes de 10G por host hacia un par de switches top-of-rack. Después de reiniciar el ToR para una actualización de firmware, parte de las VM de un host se quedaron sin respuesta y el vMotion falló en ambos uplinks, sin embargo ESXi nunca marcó nada como caído y los LED del adaptador siguieron encendidos todo el tiempo.
- Fujitsu Primergy RX2540 M1
- Adaptador LAN-on-motherboard Emulex OneConnect OCe14000 (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- Ópticas SFP+ hacia el ToR, teaming activo/en espera simple en el vSwitch
Lo que me convenció de que no es el switch: saqué la fibra del adaptador por completo y aun así sigue pareciendo activo.
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.6vYa probé:
- reasenté la óptica y la fibra, cambié el latiguillo
- moví el uplink al otro switch ToR, cuyo puerto sí cae como se espera
- reinicié los agentes de gestión en el host
Como el host cree que el uplink está activo, la política de teaming no tiene motivo para mover nada y las VM se quedan ancladas a un puerto muerto. ¿Es este un problema conocido de driver contra firmware en OneConnect, o debería mirar el hardware del LoM?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 6
Esa combinación es culpa tuya, y no aparece listada como pareja soportada para ESXi 6.0. El adaptador termina medio vivo: deja de mover tráfico pero sigue anunciando el puerto como conectado, así que la política de teaming nunca recibe el evento de caída que necesita para actuar. Por eso esto te llegó como un aislamiento parcial con el vMotion muerto en ambos uplinks en vez de un fallo honesto de la NIC; una tarjeta que muere correctamente es mucho más fácil de sobrevivir que una que miente.
Sube el driver a 11.2.1149.0. Ese es el nivel de elxnet cualificado contra el firmware 11.2.1194.36 en la lista de compatibilidad de VMware, así que estás moviendo el driver para que alcance al firmware en vez de retroceder la tarjeta. Verifícalo después con los dos comandos que ya tienes:
La línea del vib debería mostrar la versión nueva, y Link Status debería volver a seguir al cable una vez que el host esté de nuevo arriba. Pruébalo sacando la fibra con una VM corriendo en ese uplink antes de confiarle el clúster.
El hábito que vale la pena llevarse: en OneConnect el driver y el firmware se mueven como pareja, así que programa los dos juntos en vez de dejar que un paquete de mantenimiento adelante a uno de ellos por su cuenta. Comparar esas dos líneas cuesta un comando, y corresponde hacerlo mucho antes de empezar a sacar ópticas o culpar al switch.
Las dos líneas que publicaste son la parte interesante: firmware 11.2.1194.36 corriendo debajo de elxnet 10.2.309.6v. ¿Ese firmware llegó en algún momento con un paquete de mantenimiento del servidor, por separado del driver?
Comprueba esa pareja contra la lista de compatibilidad de ESXi 6.0, no contra el criterio de «lo más nuevo tiene que estar bien». OneConnect es una de las familias donde el driver y el firmware se cualifican como pareja, y una pareja desajustada no necesariamente falla de forma ruidosa, sino que funciona a medias, que es mucho peor.
También conviene decir si el segundo puerto del adaptador se comporta igual con su cable fuera.
Sí, el firmware llegó con un paquete de mantenimiento del servidor; el driver no se ha tocado desde que se montó el host.
Ambos puertos LoM se comportan igual: con el cable fuera, esxcli network nic get sigue reportando Link Status: Up, los LED se quedan encendidos, y el vSwitch mantiene el uplink en la lista de activos. El lado del switch está limpio y su puerto cae en el momento en que desconecto.
Así que lo único descuadrado en este host es la versión de elxnet frente al firmware 11.2.1194.36.
Familia distinta, misma lección. Un par de puertos FC Emulex LPe31000/LPe32000 que llevaban funcionando sin tocarse durante años dejaron de ver ningún LUN después de que un kernel de Proxmox pasara a 5.15.64 y luego a 5.15.74. El cableado y las ópticas nunca se tocaron, y el log decía:
Esa es una regresión de lpfc del lado del host, no un fallo óptico; apareció en kernels posteriores al 5.15.60. Fijar el kernel de arranque a una versión anterior fue la solución provisional que se mantuvo en producción:
El kernel 5.19 opcional también funcionó para quien no le importaba dejar la rama 5.15. Se suponía que la corrección llegaría en 5.15.77, pero nunca llegué a probar yo mismo esa build, así que tómalo como referencia de oídas. El punto se mantiene: cuando un enlace que antes funcionaba muere justo después de que algo cambió en el host, lee el registro de cambios del host antes de acercarte siquiera a los transceptores.
Añado la imagen especular de esto, porque entrena el mismo reflejo. Los indicadores son software, y el software se equivoca en ambas direcciones.
En las EX3400 y EX2300 hay un defecto de Junos, PR1428703, en el que los LED de los puertos SFP+ y SFP se quedan apagados mientras el enlace está realmente activo y pasando tráfico. La gente lo encontró al pasar de 15.1X53 a las ramas 18.1 y 19.x, sobre todo con DAC. La CLI no está de acuerdo con el panel:
reporta el LED como Green mientras que el físico está apagado. Algunas builds se reportaron como corregidas y en otras se siguió reportando LED apagados, así que yo no lo daría por cerrado del todo.
El tuyo está encendido sin enlace, ese está apagado con enlace. En cualquier caso, confía en el extremo remoto y en los contadores, nunca en el indicador.
El driver ya está en 11.2.1149.0 en ambos hosts. Con el cable desconectado, los LED se apagan, esxcli reporta el enlace caído, y el uplink en espera toma el relevo tal como siempre debió hacerlo; el vMotion corrió limpio por cada uplink por separado como prueba.
La pareja driver-firmware va a entrar en nuestra lista de verificación de mantenimiento de servidores para que el próximo paquete no vuelva a separarlos en silencio.