بصريات QLE2692 تعمل لكن Proxmox VE 6.2 لا يعرض أي LUNs: qla2xxx register_localport failed
أقوم بنقل زوج من مضيفات الافتراضية إلى تخزين Fibre Channel، وأحد المضيفين يرفض عرض أي LUN واحد بينما نفس الجهاز يعمل عندما تُسلَّم البطاقة لآلة افتراضية.
- QLogic QLE2692، مبنية على ISP2722، 16/32Gb FC، كلا المنفذين موصولان
- Fujitsu Eternus DX100 S5 على الطرف الآخر
- مضيف Proxmox VE 6.2، qla2xxx مضمّن في النواة على kernel 5.4
- نفس البطاقة تم تمريرها (passthrough) إلى آلة افتراضية Windows على ذلك المضيف
على المضيف، تعمل المنافذ وتُظهر البصريات ضوءًا، لكن لا تظهر أي أجهزة كتلة (block devices) أبدًا. يحتوي dmesg على هذا في كل مرة يهيّئ فيها التعريف:
qla2xxx: register_localport failed: ret=ffffffea
WARNING in qla_nvme_register_hba
ما فعلته بالفعل:
- بدّلت وحدات SFP+ وكابلات التوصيل بين المنفذين، لا تغيير على الإطلاق
- مرّرت البطاقة بأكملها إلى آلة افتراضية Windows: تظهر LUNs الخاصة بـDX100 هناك فورًا، لذا الكابلات والبصريات وجانب المصفوفة سليمة بوضوح
- تحققت من
lspci -k، qla2xxx مرتبط بكلا الوظيفتين ولا شيء آخر يتنافس على البطاقة
أنا لا أحاول حتى تشغيل NVMe عبر FC هنا، أريد فقط LUNs عادية من نوع FC على المضيف. هل يستحق الأمر تفكيك البصريات أكثر، أم أن هذه مشكلة في تعريف المضيف بشكل قاطع؟
Comments 5
قبل أن تلمس البصريات مرة أخرى، ضع التفاصيل المملة على الطاولة. انشر كتلة dmesg بأكملها بدلًا من هذين السطرين: كل ما يطبعه التعريف من الفحص (probe) فصاعدًا، حتى التحذير وما بعده. سطر التسجيل وحده لا يخبر أحدًا ما إذا كانت المنافذ أنهت التشغيل أو ماتت في منتصف التهيئة.
وقل ما إذا كانت المصفوفة تعرض أي شيء كـnamespaces من نوع NVMe، أم فقط LUNs عادية من نوع SCSI. الرسالة التي لصقتها تخرج من النصف الخاص بـNVMe في التعريف، لذا إذا لم تكن هناك أي namespaces في أي مكان في هذا الإعداد، فهذا يضيّق فعلًا ما الذي يفشل ولماذا تتأثر به بقية الحزمة.
لا توجد namespaces في أي مكان: المصفوفة تقدم LUNs عادية من نوع SCSI FC فقط، لا شيء في هذا النسيج (fabric) يتحدث NVMe، وهذا بالضبط سبب بدو الرسالة غريبة لي في المقام الأول.
كتلة dmesg قصيرة ومملة. التعريف يتحمّل، وكلا الوظيفتين تفحصان بنجاح، وتعمل المنافذ، ثم يظهر
register_localport failed: ret=ffffffeaمعWARNING in qla_nvme_register_hbaخلفه مباشرة. لا مهلات انتظار، لا إعادة ضبط، لا شيء عن النسيج بينهما. يتكرر لكلا المنفذين في كل عملية إقلاع، وبعده لا يظهر أي جهاز SCSI واحد على المضيف. نفس البطاقة بنفس الوحدات في الآلة الافتراضية الممرَّرة (passthrough) ترى LUNs فورًا.توقف عن النظر إلى الترانسيفرات، هذه مشكلة تعريف المضيف. qla2xxx المضمّن في النواة على 5.4 يفشل في تسجيل NVMe-FC أثناء تشغيل المحول، وهذا بالضبط
register_localport failed: ret=ffffffeaالذي تراه، ويترك منافذ FC غير قابلة للاستخدام في كل شيء آخر أيضًا. لهذا لا تظهر LUNs الخاصة بـSCSI العادية أبدًا رغم أنك لم تطلب NVMe-FC في أي مكان. التمرير (passthrough) يعمل لأن تعريف Windows لا علاقة له بأي من هذا الكود.الطريق العملي هو نواة مختلفة. نفس البطاقات تتصرف بشكل جيد على Proxmox 6.1 مع kernel 5.3، وتتصرف بشكل جيد مرة أخرى على 5.8، لذا اختر أيًا منهما يناسب خطط الترقية لديك، أقلعه، تحقق من اختفاء تحذير التسجيل من dmesg ثم أعد الفحص (rescan). عادة تستحق البناء مع HBA من نوع FC بشكل عام: ابحث في dmesg عن أخطاء من جانب التعريف قبل أن تشتبه بالوحدة، لأن تعريفًا يموت عند التهيئة يبدو تمامًا مثل لينك ميت عندما تحدّق في مصفوفة التخزين.
هذا كان الحل. أقلعت 5.8 على المضيف، اختفى تحذير التسجيل من dmesg وتعدّدت LUNs الخاصة بـDX100 على كلا المسارين دون أي تغييرات أخرى، نفس الكابلات، نفس الوحدات، نفس التقسيم إلى مناطق (zoning). للاكتمال، أعدت عقدة ثانية إلى 6.1 مع kernel 5.3 وتعمل هناك أيضًا، لذا العطل فعليًا محصور في 5.4 على هذا الجهاز. البطاقة والبصريات تبقى تمامًا كما هي، وأحتفظ بالوحدات الاحتياطية التي كنت قد طلبتها بالفعل.
تأكيد للنمط من زاوية مختلفة: واجهنا بالضبط هذا على Proxmox 7.1 تحت kernel 5.13، لذا 5.4 ليست الوحيدة المتأثرة ويستحق الأمر التحقق بعد أي انتقال للنواة.
Emulex ليست أفضل، بالمناسبة. منفذا LPe31000/LPe32000 اللذان عملا دون لمس لأشهر توقفا عن رؤية أي LUNs بعد انتقال النواة إلى 5.15.64 ثم 5.15.74، مع
Enable MI Mailbox x9b (x1/xbf) failed, rc:x10 mi:x2وَCMF is disabledفي السجل ولا هدف واحد يُعثر عليه بعد ذلك. الكابلات والبصريات لم تُمس، بالطبع. تلك تقع في lpfc ووصلت مع النوى بعد 5.15.60. طريقتان نجحتا للناس للخروج منها: تثبيت نواة الإقلاع حيث كانت لا تزال تعمل باستخدامproxmox-boot-tool kernel pin 5.15.60-2-pve، أو القفز إلى نواة 5.19 الاختيارية إذا كان ترك فرع 5.15 مقبولًا لديك. كان من المفترض أن يصل الإصلاح في 5.15.77، لكنني لم أُجرِّب ذلك الإصدار قط. المقصد هو أنه عندما يبدو لينك FC ميتًا مباشرة بعد الصيانة، انظر إلى النواة التي أقلعت إليها قبل أن تبدأ بطلب وحدات بديلة.