ينبغي التعامل مع هذا التقرير الصادر في سبتمبر 2025 على أنه عطل تاريخي خاص بإصدار ZVM التجريبي، لا على أنه استنتاج حالي بأن «ZVM لا يعمل». كان المستخدم يشغّل ZimaOS 1.4.4-beta1، وكان يرى بشكل متكرر فشل بدء تشغيل الجهاز الافتراضي مع رسالة داخلية client socket is closed. اختبر Zima-Giorgio جهازًا افتراضيًا يعمل بنظام Ubuntu على الإصدار التجريبي نفسه، وقال إنه عمل بشكل طبيعي، لذا لم تكن المشكلة عامة في جميع عمليات تثبيت 1.4.4-beta1.
الجزء المفيد من المناقشة هو تضييق نطاق التشخيص. كان KVM محمّلًا، وكانت شبكة libvirt الافتراضية ومجمّع التخزين نشطين، ولم تُجدِ إعادة ضبط إعدادات libvirt نفعًا. وأظهرت السجلات اللاحقة virtqemud مع فشل الاتصال بمقبس شبكة libvirt ثم إلغاء تفعيله.
لم تكن إعادة تشغيل libvirt-guests هي الطبقة الصحيحة
أعاد المستخدم الأصلي تشغيل libvirt-guests.serviceأشار أحد المشاركين في المجتمع إلى أن هذه الخدمة تتولى أساسًا سلوك حفظ الضيوف واستعادتهم عند إيقاف تشغيل المضيف؛ وليست عفريت QEMU/libvirt الأساسي الذي يشغّل الجهاز الافتراضي.
لذلك، لم تُثبت إعادة التشغيل الناجحة هناك أن حزمة الأجهزة الافتراضية كانت سليمة.
كان تسريع KVM العتادي متاحًا
تحقق المستخدم من الوحدات المحمّلة، ووجد كليهما kvm و kvm_intelوقد استبعد ذلك سببًا شائعًا: عدم توفر دعم المحاكاة الافتراضية بالكامل على مستوى النواة.
كانت الشبكة الافتراضية ومجمّعات التخزين نشطة
كما فحصت المناقشة شبكة libvirt الافتراضية ومجمّع التخزين. وأُفيد بأن كليهما نشط ويمكن الوصول إليه.
مما جعل فقدان تخزين الأجهزة الافتراضية أو عدم نشاط شبكة NAT أقل احتمالًا باعتباره السبب الرئيسي.
لم تؤدِّ إعادة ضبط إعدادات libvirt بالكامل إلى حل المشكلة
حذف صاحب المنشور الأصلي الإعدادات الموجودة ضمن /etc/libvirt و /var/lib/libvirt وظل الفشل يتكرر. كانت تلك خطوة تشخيصية مدمرة، ولا ينبغي الترويج لها كحل أول حالي.
في نظام إنتاج حديث، انسخ تعريفات الأجهزة الافتراضية وصور الأقراص احتياطيًا قبل تعديل حالة libvirt.
أشار السجل اللاحق إلى virtqemud ومقبس شبكة
ثم نشر المستخدم رسالة خطأ أكثر فائدة: virtqemud فشل الاتصال بمقبس ضمن /var/run/libvirt/...، وبعد ذلك أُوقفت الخدمة. ولذلك يُرجح أن تكون رسالة واجهة المستخدم حول إغلاق مقبس العميل عرضًا ثانويًا لمشكلة البرنامج الخفي في الواجهة الخلفية.
قد يتسبب برنامج خفي يعرض «تم الخروج بنجاح» في تعطل التطبيق
تُفعَّل عدة برامج خفية من libvirt عبر المقابس، وقد تتوقف عند الخمول؛ لذلك فإن ظهور الحالة «غير نشطة» وحده لا يثبت وجود عطل. لكن في هذه الحالة، جعل فشل اتصال المقبس الصريح، إلى جانب سجلات إنهاء الجهاز الافتراضي، تفاعل الواجهة الخلفية موضع شك.
فسّر حالة systemd بالاقتران مع خطأ libvirt/QEMU الفعلي، وليس بالاعتماد على سطر حالة واحد بمعزل عن السياق.
لم تتمكن IceWhale من إعادة إنتاج العطل في بيئة الاختبار الخاصة بها
قال Zima-Giorgio إن جهازًا افتراضيًا يعمل بنظام Ubuntu عمل بصورة طبيعية على الإصدار 1.4.4-beta1، وطلب معرفة نوع نظام التشغيل وإرفاق لقطات شاشة أو فيديو. وهذا حدّ رسمي مهم: فالمصدر يعرض عطلًا حقيقيًا لدى مستخدم، لكنه لا يثبت وجود انقطاع مؤكد على نطاق الإصدار التجريبي بأكمله.
صعّد المستخدم المشكلة باعتبارها خللًا في الإصدار التجريبي على GitHub
نقل صاحب المنشور السجلات التفصيلية ومقطع فيديو إلى متتبّع GitHub الخاص بـ IceWhale، لأن رفع الملفات في المنتدى كان صعبًا. وكان المصدر المرفق مقطع فيديو، وليس لقطة شاشة ثابتة من المنتدى.
لا يعرض موضوع المنتدى العام مذكرة إصدار أو تصحيحًا نهائيًا يحدد سببًا جذريًا واحدًا مؤكدًا.
لا تطبّق تعديلات الخدمات الخاصة بالإصدار 1.4.4-beta1 على ZimaOS الحالي
إن ZimaOS الحالي يتجاوز هذا الإصدار التجريبي بفارق كبير. وقد تختلف حزم libvirt وواجهة ZVM ودعم الصور وسلوك خدمة systemd جميعًا.
عند مواجهة عطل حالي مشابه، اجمع خطأ الجهاز الافتراضي وإصدار ZimaOS الحالي وحالة KVM وحالة شبكة libvirt وتخزينها وسجلات QEMU قبل تغيير ملفات النظام.
تغيّر العطل مع جمع المستخدم أدلة أفضل
كانت النظرية الأولية ببساطة أن الإصدار التجريبي من ZVM يحتوي على خلل أعمق، لأن إعادة تشغيل إحدى الخدمات لم تُجدِ نفعًا. وأثبتت الجولة التالية وجود KVM وسلامة الشبكة والتخزين الافتراضيين. ولم يظهر خطأ المقبس داخل virtqemud يصبح مرئيًا.
يُعد هذا التسلسل نموذجًا جيدًا لاستكشاف أخطاء المحاكاة الافتراضية وإصلاحها: تجنّب الانتقال مباشرةً من خطأ عام في واجهة المستخدم إلى إعادة تثبيت برنامج مراقبة الأجهزة الافتراضية. عطّل تسريع الأجهزة وطبقات التخزين والشبكة والخدمات بالتتابع.
يعتمد virtqemud على بقية حزمة libvirt المعيارية
أشار الفشل المسجّل إلى مقبس شبكة libvirt. في libvirt المعياري الحديث، يمكن أن تعمل إدارة QEMU وإدارة الشبكة والتسجيل ووظائف أخرى في شياطين ومقابس منفصلة. لذلك قد يكون عفريت QEMU موجودًا، لكنه يفشل في الاتصال بعفريت الشبكة الذي يحتاج إليه.
يساعد هذا في تفسير سبب تعطل جهاز افتراضي رغم أن KVM ومجمّع التخزين بدوا طبيعيين.
أظهرت سجلات QEMU إنهاء الضيوف
أظهرت سجلات QEMU الخاصة بالمستخدم مرارًا أن عمليات الضيوف كانت تُنهى بالإشارة 15 من virtqemud. ويدعم ذلك فكرة أن ضيوف الأجهزة الافتراضية كانوا يُنهون بواسطة مكدس التحكم في المحاكاة الافتراضية، لا أنهم كانوا يتعطلون بسبب صورة Windows أو Linux تالفة.
اختبر المستخدم أيضًا عدة صور ISO ولاحظ السلوك نفسه، ما يضعف أكثر تفسير «وسائط التثبيت التالفة».
ينبغي مقارنة التراجع في الإصدار التجريبي بالإصدار المستقر قبل إجراء إصلاحات مدمرة
اقترح أحد ردود المجتمع العودة إلى القناة المستقرة إذا كانت الأجهزة الافتراضية مطلوبة فورًا. وهذا حدّ تشخيصي معقول لفشل خاص بالإصدار التجريبي: إذا عمل الجهاز الافتراضي نفسه والعتاد نفسه على الإصدار المستقر، يصبح الإصدار التجريبي المتغير الأبرز.
لا يتضمن النقاش الأصلي تأكيدًا نهائيًا من صاحب المنشور الأصلي بشأن التراجع، لذلك تظل هذه استراتيجية تشخيصية وليست إصلاحًا موثقًا في المصدر.
عند حدوث عطل حالي في ZVM، احتفظ بأول خطأ في الواجهة الخلفية
غالبًا ما تظهر رسائل واجهة المستخدم مثل «مقبس العميل مغلق» بعد وقوع الحدث المهم في الواجهة الخلفية. التقط سجلات النظام وQEMU في اللحظة المحددة للنقر على «بدء»، واحتفظ بأقدم خطأ بدلًا من الاكتفاء برسالة الحالة النهائية.
يقلل هذا من خطر اعتبار عرض لاحق في السلسلة السبب الجذري.
الأسئلة الشائعة التاريخية حول إصدار ZVM التجريبي
هل كان KVM مفقودًا في الحالة الأصلية؟
لا. أكد المستخدم أن وحدات KVM محمّلة.
هل أدى إعادة ضبط إعدادات libvirt إلى حل المشكلة؟
لا.
هل تأكدت المشكلة على كل نظام يعمل بالإصدار 1.4.4-beta1؟
لا. قال Zima-Giorgio إن جهازًا افتراضيًا للاختبار يعمل بنظام Ubuntu عمل بشكل طبيعي على الإصدار التجريبي نفسه.
ما أقوى مؤشر من الواجهة الخلفية؟
virtqemud سجّل فشلًا في الاتصال بمقبس شبكة libvirt قبل إلغاء التفعيل.
