OCe14000 LoM reporta link up com o cabo removido, então o teaming do ESXi nunca faz failover
Cluster vSphere pequeno, dois uplinks 10G por host para um par de switches top-of-rack. Depois que o ToR foi reiniciado para uma atualização de firmware, parte das VMs num host ficou muda e o vMotion falhou nos dois uplinks - mas o ESXi nunca marcou nada como down e os LEDs do adaptador ficaram acesos o tempo todo.
- Fujitsu Primergy RX2540 M1
- adaptador LAN-on-motherboard Emulex OneConnect OCe14000 (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- ópticos SFP+ até o ToR, teaming ativo/standby simples no vSwitch
O que me convenceu de que não é o switch: tirei a fibra do adaptador por completo e ele continua parecendo vivo.
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.6vJá tentei:
- reencaixei o óptico e a fibra, troquei o cordão de patch
- movi o uplink para o outro switch ToR, cuja porta cai como esperado
- reiniciei os agentes de gerenciamento no host
Como o host acredita que o uplink está ativo, a política de teaming não tem motivo para mover nada e as VMs ficam presas numa porta morta. Isso é um problema conhecido de driver contra firmware no OneConnect, ou eu deveria estar olhando para o hardware do 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
Essa combinação é culpa sua, e ela não está listada como par suportado para o ESXi 6.0. O adaptador acaba meio vivo: para de mover tráfego, mas continua anunciando a porta como conectada, então a política de teaming nunca recebe o evento de down que precisa para agir. É por isso que isso chegou até você como um isolamento parcial com o vMotion morto nos dois uplinks, em vez de uma falha honesta de NIC - uma placa que morre direito é muito mais fácil de sobreviver do que uma que mente.
Suba o driver para 11.2.1149.0. Esse é o nível do elxnet qualificado contra o firmware 11.2.1194.36 na lista de compatibilidade da VMware, então você está movendo o driver para encontrar o firmware, não voltando a placa para trás. Confirme depois com os dois comandos que você já tem:
A linha do vib deve mostrar a versão nova, e o Link Status deve voltar a seguir o cabo assim que o host estiver de volta. Teste puxando a fibra com uma VM rodando naquele uplink antes de confiar o cluster a ele.
O hábito que vale a pena levar daqui: no OneConnect o driver e o firmware andam como um par, então agende os dois juntos em vez de deixar um pacote de manutenção arrastar só um deles para frente sozinho. Comparar essas duas linhas leva um comando, e isso vem bem antes de começar a puxar óptico ou culpar o switch.
As duas linhas que você postou são a parte interessante: firmware 11.2.1194.36 rodando por baixo do elxnet 10.2.309.6v. Esse firmware chegou com um pacote de manutenção do servidor em algum momento, separado do driver?
Confira esse par contra a lista de compatibilidade do ESXi 6.0, não contra a lógica de "o mais novo deve estar bom". OneConnect é uma das famílias onde driver e firmware são qualificados como par, e um par desencontrado não necessariamente falha alto - ele funciona pela metade, o que é bem pior.
Também vale dizer se a segunda porta do adaptador se comporta do mesmo jeito com o cabo fora.
Sim, o firmware entrou junto com um pacote de manutenção do servidor; o driver não é mexido desde que o host foi montado.
As duas portas do LoM se comportam identicamente: com o cabo fora, o esxcli network nic get continua reportando Link Status: Up, os LEDs ficam acesos, e o vSwitch mantém o uplink na lista de ativos. O lado do switch está limpo e a porta dele cai no instante em que eu desconecto.
Então a única coisa fora de sincronia nesse host é a versão do elxnet contra o firmware 11.2.1194.36.
Família diferente, mesma lição. Um par de portas FC Emulex LPe31000/LPe32000 que rodava sem ser mexido havia muito tempo parou de ver qualquer LUN depois que um kernel do Proxmox foi para 5.15.64 e depois 5.15.74. Cabeamento e óptico nunca foram tocados, e o log dizia:
Isso é uma regressão do lpfc do lado do host, não uma falha óptica; ela apareceu em kernels depois do 5.15.60. Fixar o kernel de boot para trás foi a solução alternativa que se sustentou em produção:
O kernel 5.19 opcional também funcionou para quem não se importava de sair do branch 5.15. A correção deveria chegar na 5.15.77, mas eu nunca cheguei a rodar essa build eu mesmo, então trate como boato. O ponto continua de pé: quando um link que costumava funcionar morre logo depois de algo mudar no host, leia o log de mudanças do host antes de chegar perto dos transceptores.
Acrescentando a imagem espelhada disso, porque treina o mesmo reflexo. Indicadores são software, e software erra nas duas direções.
No EX3400 e no EX2300 existe um defeito do Junos, PR1428703, em que os LEDs das portas SFP+ e SFP ficam apagados enquanto o link está genuinamente up e passando tráfego. As pessoas encontram isso saindo do 15.1X53 para os trens 18.1 e 19.x, principalmente com DAC. O CLI discorda do painel:
reporta o LED como Green enquanto o físico está apagado. Algumas builds foram reportadas como corrigidas e LEDs apagados continuaram sendo reportados em outras, então eu não chamaria isso de resolvido de forma limpa.
O seu está aceso sem link, aquele está apagado com link. De qualquer jeito, confie na outra ponta e nos contadores, nunca no indicador.
O driver está em 11.2.1149.0 nos dois hosts agora. Com o cabo puxado, os LEDs apagam, o esxcli reporta o link down, e o uplink standby assume do jeito que sempre deveria ter sido - o vMotion rodou limpo em cada uplink separadamente como teste.
O par driver-e-firmware está entrando no nosso checklist de manutenção de servidor para o próximo pacote não separar eles de novo silenciosamente.