OCe14000 LoM melaporkan link up padahal kabelnya dicabut, jadi teaming ESXi tidak pernah failover
Cluster vSphere kecil, dua uplink 10G per host ke sepasang switch top-of-rack. Setelah ToR-nya di-reboot untuk update firmware, sebagian VM di satu host jadi diam dan vMotion gagal di kedua uplink - tapi ESXi tidak pernah menandai apa pun down dan LED adapternya tetap menyala sepanjang waktu.
- Fujitsu Primergy RX2540 M1
- Adapter Emulex OneConnect OCe14000 LAN-on-motherboard (VID 10df DID 0720 SVID 1734 SSID 120e)
- ESXi 6.0 U3
- Optik SFP+ ke ToR, teaming active/standby biasa di vSwitch
Yang meyakinkan saya kalau ini bukan switch-nya: saya cabut fiber-nya dari adapter sepenuhnya dan masih terlihat hidup.
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.6vYang sudah dicoba:
- pasang ulang optik dan fiber-nya, ganti patch lead
- pindahkan uplink-nya ke switch ToR yang lain, port-nya down seperti yang diharapkan
- restart management agent di host-nya
Karena host-nya percaya uplink-nya hidup, teaming policy-nya tidak punya alasan untuk memindahkan apa pun dan VM-nya tetap menempel di port yang mati. Apa ini masalah driver-versus-firmware yang sudah dikenal di OneConnect, atau saya harus curiga ke hardware LoM-nya?
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
Kombinasi itu salah kamu sendiri, dan itu tidak terdaftar sebagai pairing yang didukung untuk ESXi 6.0. Adapternya jadi setengah hidup: dia berhenti memindahkan traffic tapi terus mengiklankan port-nya sebagai connected, jadi teaming policy-nya tidak pernah dapat down event yang dia butuhkan untuk bertindak. Itu kenapa ini sampai ke kamu sebagai isolasi parsial dengan vMotion mati di kedua uplink, bukannya kegagalan NIC yang jujur - kartu yang mati dengan benar jauh lebih mudah diselamatkan daripada yang bohong.
Naikkan driver-nya ke 11.2.1149.0. Itu level elxnet yang qualified terhadap firmware 11.2.1194.36 di VMware compatibility list, jadi kamu menaikkan driver-nya supaya sesuai firmware-nya, bukan menurunkan kartunya kembali. Verifikasi sesudahnya dengan dua command yang sudah kamu punya:
Baris vib-nya harus menunjukkan versi baru, dan Link Status harus mengikuti kabelnya lagi begitu host-nya kembali up. Uji dengan mencabut fiber-nya sementara ada VM yang jalan di uplink itu, sebelum kamu percayakan ke cluster-nya.
Kebiasaan yang perlu dibawa pulang: di OneConnect driver dan firmware bergerak sebagai pasangan, jadi jadwalkan keduanya bersamaan, jangan biarkan satu maintenance bundle menyeret salah satunya maju sendirian. Membandingkan dua baris itu cuma butuh satu command, dan itu seharusnya dilakukan jauh sebelum kamu mulai mencabut optik atau menyalahkan switch-nya.
Dua baris yang kamu posting itu bagian yang menarik: firmware 11.2.1194.36 jalan di bawah elxnet 10.2.309.6v. Apa firmware itu datang lewat maintenance bundle server di suatu waktu, terpisah dari driver-nya?
Cek pairing itu terhadap compatibility list untuk ESXi 6.0, bukan terhadap asumsi "yang paling baru pasti aman". OneConnect salah satu keluarga di mana driver dan firmware itu qualified sebagai pasangan, dan pasangan yang tidak cocok tidak selalu gagal dengan berisik - dia setengah bekerja, yang jauh lebih buruk.
Perlu juga disebutkan apakah port kedua adapternya berperilaku sama waktu kabelnya dicabut.
Betul, firmware-nya masuk lewat maintenance bundle server; driver-nya belum pernah disentuh sejak host-nya dibangun.
Kedua port LoM-nya berperilaku identik: kabel dicabut, esxcli network nic get tetap melaporkan Link Status: Up, LED-nya tetap menyala, dan vSwitch-nya tetap menyimpan uplink itu di active list. Sisi switch-nya bersih dan port-nya langsung drop begitu saya cabut.
Jadi satu-satunya yang tidak sinkron di host ini adalah versi elxnet terhadap firmware 11.2.1194.36.
Keluarga yang berbeda, pelajaran yang sama. Sepasang port FC Emulex LPe31000/LPe32000 yang sudah berjalan tanpa disentuh selama bertahun-tahun berhenti melihat LUN apa pun setelah kernel Proxmox pindah ke 5.15.64 dan belakangan 5.15.74. Kabel dan optiknya tidak pernah disentuh, dan log-nya bilang:
Itu regresi lpfc di sisi host, bukan kegagalan optik; itu muncul di kernel-kernel setelah 5.15.60. Pin kernel boot-nya kembali adalah workaround yang bertahan di produksi:
Kernel opt-in 5.19 juga berhasil untuk orang-orang yang tidak keberatan meninggalkan branch 5.15. Perbaikannya seharusnya mendarat di 5.15.77, tapi saya sendiri belum sempat menjalankan build itu, jadi anggap saja ini kabar burung. Intinya tetap sama: kalau link yang tadinya bekerja mati persis setelah sesuatu berubah di host-nya, baca dulu change log host-nya sebelum mendekati transceiver mana pun.
Menambahkan gambar cerminnya, karena ini melatih refleks yang sama. Indikator itu software, dan software bisa salah ke dua arah.
Di EX3400 dan EX2300 ada defect Junos, PR1428703, di mana LED port SFP+ dan SFP tetap gelap padahal link-nya benar-benar up dan melewatkan traffic. Orang-orang menemukannya waktu pindah dari 15.1X53 ke train 18.1 dan 19.x, kebanyakan dengan DAC. CLI-nya tidak sepakat dengan panelnya:
melaporkan LED-nya Green padahal yang fisik mati. Sebagian build dilaporkan sudah fixed dan LED gelap masih terus dilaporkan di yang lain, jadi saya tidak akan bilang ini sudah beres bersih.
Punya kamu menyala tanpa link, yang itu gelap padahal ada link. Bagaimanapun juga, percayai ujung satunya dan counter-nya, jangan pernah percaya indikatornya.
Driver-nya sekarang di 11.2.1149.0 di kedua host. Waktu kabelnya dicabut, LED-nya mati, esxcli melaporkan link-nya down, dan uplink standby-nya mengambil alih seperti yang seharusnya dari awal - vMotion jalan bersih di tiap uplink secara terpisah sebagai tes.
Pasangan driver-dan-firmware ini masuk ke checklist maintenance server kami supaya bundle berikutnya tidak diam-diam memisahkan mereka lagi.