لماذا توقفت Windows VM عن الإقلاع بعد نقلها إلى سيرفر جديد؟ دليل تشخيص وإصلاح المشكلة في Proxmox 2026

تُعد عمليات نقل الآلات الافتراضية (Virtual Machines) بين خوادم Proxmox من المهام اليومية في بيئات الاستضافة الحديثة، سواءً بهدف ترقية العتاد، الانتقال إلى خوادم أحدث، تحسين الأداء، أو تنفيذ أعمال الصيانة الدورية. وفي معظم الحالات تتم عملية النقل بنجاح كامل دون أي تأثير على أنظمة التشغيل أو البيانات.

لكن في بعض الأحيان يواجه مدير النظام مشكلة مزعجة تتمثل في توقف Windows VM عن الإقلاع بعد نقلها إلى سيرفر جديد، رغم أن عملية النقل أو الاستعادة تمت بنجاح ولم تظهر أي أخطاء واضحة أثناء التنفيذ.

هذه المشكلة قد تسبب توقف الخدمات، وتعطل مواقع العملاء، وتأخير المشاريع، خاصة عندما تكون الآلة الافتراضية المستضافة تحتوي على تطبيقات إنتاجية أو قواعد بيانات أو خدمات استضافة مهمة.

في هذا الدليل العملي سنشرح الأسباب الحقيقية التي قد تؤدي إلى عدم إقلاع Windows VM بعد Migration أو Restore داخل Proxmox، بالإضافة إلى خطوات التشخيص والإصلاح التي يستخدمها مهندسو البنية التحتية في بيئات الاستضافة الاحترافية.

لماذا قد تفشل Windows VM في الإقلاع بعد النقل؟

عند تثبيت Windows Server أو Windows 11 داخل Proxmox يتم إنشاء مجموعة من الإعدادات المرتبطة بالآلة الافتراضية نفسها وليس فقط بالقرص الصلب.

تشمل هذه الإعدادات:

• نوع BIOS
• إعدادات UEFI
• EFI Disk
• TPM State
• نوع متحكم التخزين
• نوع المعالج الافتراضي
• Secure Boot
• Boot Order

وعند نقل الآلة الافتراضية إلى خادم جديد قد يتم تغيير أحد هذه العناصر بشكل غير مقصود، مما يؤدي إلى فقدان القدرة على الإقلاع.

العلامات الشائعة للمشكلة

عادة تظهر المشكلة بإحدى الصور التالية:

• شاشة سوداء بعد بدء التشغيل.
• رسالة No Bootable Device.
• رسالة Boot Failed.
• دخول النظام إلى Automatic Repair.
• إعادة تشغيل متكررة دون الوصول إلى Windows.
• ظهور شاشة BitLocker Recovery.
• توقف النظام عند شعار Windows.

كل هذه الأعراض تشير غالباً إلى مشكلة في إعدادات الإقلاع أو توافق مكونات VM بعد النقل.

السبب الأول: اختلاف BIOS بين الخادم القديم والجديد

من أكثر الأسباب انتشاراً في بيئات Proxmox.

يوجد نوعان رئيسيان من BIOS داخل الآلات الافتراضية:

• SeaBIOS
• OVMF (UEFI)

إذا تم تثبيت Windows باستخدام OVMF ثم تم إنشاء VM جديدة على السيرفر الجديد باستخدام SeaBIOS فلن يتمكن النظام من العثور على ملفات الإقلاع.

والعكس صحيح أيضاً.

طريقة التحقق

من واجهة Proxmox:

VM → Options → BIOS

يجب أن يكون نوع BIOS مطابقاً تماماً للآلة الأصلية.

السبب الثاني: فقدان EFI Disk أثناء عملية النقل

عند استخدام UEFI يتم تخزين ملفات الإقلاع داخل EFI Disk.

في بعض عمليات الاستعادة اليدوية أو عند استيراد الأقراص فقط قد يتم نسيان إضافة EFI Disk.

النتيجة تكون مباشرة:

• النظام لا يجد ملفات الإقلاع.
• ظهور Boot Failure.
• عدم التعرف على Windows.

كيف تتأكد من وجوده؟

من داخل إعدادات VM:

Hardware → EFI Disk

إذا لم يكن موجوداً فغالباً هذه هي المشكلة.

السبب الثالث: TPM State غير موجود

مع Windows Server 2022 وWindows Server 2025 وWindows 11 أصبح TPM جزءاً مهماً من عملية التشغيل.

إذا تم حذف TPM State أو لم يتم نقله مع الآلة الافتراضية فقد يرفض النظام الإقلاع أو يطلب مفاتيح استرداد BitLocker.

خصوصاً إذا كانت خاصية التشفير مفعلة.

السبب الرابع: تغيير نوع وحدة التخزين

أثناء إنشاء VM جديدة وربط القرص القديم بها قد يتم اختيار نوع مختلف من وحدات التخزين.

على سبيل المثال:

الخادم القديم:

VirtIO SCSI

الخادم الجديد:

SATA

أو:

IDE

في هذه الحالة قد يفشل Windows في تحميل تعريف التخزين الأساسي.

وتظهر رسالة شهيرة:

INACCESSIBLE_BOOT_DEVICE

وهي من أكثر أخطاء Windows شيوعاً بعد عمليات Migration.

السبب الخامس: خطأ في ترتيب الإقلاع

أحياناً يتم إنشاء أقراص إضافية أثناء عملية النقل أو الاستعادة.

فيحاول النظام الإقلاع من قرص فارغ بدلاً من قرص النظام.

التحقق

VM → Options → Boot Order

تأكد أن قرص Windows الأساسي موجود في المرتبة الأولى.

السبب السادس: مشاكل Secure Boot

بعض نسخ Windows الحديثة تعتمد على Secure Boot أثناء التثبيت.

إذا كان النظام يعمل سابقاً مع Secure Boot وتم تعطيل الميزة بعد النقل فقد يرفض النظام الإقلاع.

لذلك يجب التأكد من تطابق إعدادات Secure Boot بين البيئتين.

السبب السابع: اختلاف إعدادات المعالج

في بعض عمليات النقل بين خوادم مختلفة جذرياً قد يسبب تغيير نوع المعالج مشاكل غير متوقعة.

مثال:

• الانتقال من Intel Xeon إلى AMD EPYC.
• الانتقال بين أجيال مختلفة من المعالجات.

في هذه الحالات يفضل استخدام:

CPU Type = Host

أو استخدام نوع CPU موحد عبر جميع الخوادم في الكلاستر.

خطوات التشخيص الاحترافية

قبل التفكير بإعادة تثبيت Windows يجب تنفيذ خطوات التشخيص التالية:

مراجعة إعدادات الآلة الافتراضية

تحقق من:

• BIOS
• EFI Disk
• TPM
• Boot Order
• CPU Type
• Storage Controller

في كثير من الحالات يتم اكتشاف المشكلة خلال دقائق من مراجعة هذه العناصر فقط.

التأكد من سلامة القرص

من السيرفر:

qm config VMID

ثم:

pvesm list STORAGE

أو:

zfs list

للتأكد من أن القرص موجود ولم يتعرض لأي مشكلة أثناء النقل.

فحص الأقسام

يمكن استخدام:

virt-filesystems --long -h --all -a disk.img

أو:

guestfish

للتأكد من أن أقسام Windows ما تزال سليمة.

إذا كانت الأقسام ظاهرة بشكل طبيعي فغالباً المشكلة ليست في البيانات نفسها وإنما في عملية الإقلاع.

استخدام أدوات إصلاح Windows

قم بتركيب ISO الخاص بـ Windows Server.

ثم:

Repair your Computer

بعدها:

Startup Repair

أو:

Command Prompt

وتنفيذ:

bootrec /fixmbr
bootrec /scanos
bootrec /rebuildbcd

لإعادة إنشاء ملفات الإقلاع.

دراسة حالة حقيقية

خلال عملية ترقية البنية التحتية في إحدى بيئات الاستضافة تم نقل Windows Server VM إلى خادم جديد مزود بمعالجات AMD EPYC وأقراص NVMe Enterprise.

بعد اكتمال عملية النقل ظهرت رسالة Boot Failure رغم أن جميع البيانات كانت موجودة.

تم فحص الأقراص والتأكد من سلامتها بالكامل.

بعد مراجعة إعدادات الآلة الافتراضية تبين أن الخادم الجديد تم إنشاؤه بإعدادات BIOS مختلفة عن الإعدادات الأصلية، بالإضافة إلى غياب EFI Disk المرتبط بالنظام.

بعد إعادة ضبط إعدادات OVMF وإضافة EFI Disk واستعادة ترتيب الإقلاع عاد النظام للعمل فوراً دون أي فقدان للبيانات أو الحاجة إلى إعادة تثبيت Windows.

أفضل الممارسات قبل نقل Windows VM

لتجنب هذه المشكلة مستقبلاً يوصى دائماً بتوثيق الإعدادات التالية قبل أي Migration:

• BIOS Type
• EFI Disk
• TPM State
• CPU Type
• Storage Controller
• Secure Boot
• Boot Order

كما يفضل أخذ نسخة احتياطية كاملة قبل تنفيذ أي عملية نقل أو ترقية.

كيف تساعد البنية التحتية القوية في تقليل المخاطر؟

كلما كانت البنية التحتية أكثر استقراراً وتجانساً كانت احتمالية حدوث مشاكل بعد النقل أقل.

ولهذا تعتمد مرام هوست على خوادم حديثة مزودة بمعالجات AMD EPYC وأقراص NVMe Enterprise وشبكات عالية السرعة لتوفير بيئة مستقرة للآلات الافتراضية وعمليات الترحيل والصيانة.

كما يتم اختبار عمليات Migration قبل تنفيذها على الأنظمة الإنتاجية لضمان استمرارية الخدمة وتقليل وقت التوقف إلى أدنى حد ممكن.

الخلاصة

عندما تتوقف Windows VM عن الإقلاع بعد نقلها إلى سيرفر جديد فإن السبب لا يكون غالباً تلف البيانات أو فشل عملية النقل نفسها، بل يكون مرتبطاً بإعدادات الإقلاع ومكونات الآلة الافتراضية مثل BIOS وEFI وTPM ونوع متحكم التخزين.

التشخيص المنهجي ومراجعة الإعدادات الأساسية يوفر ساعات طويلة من العمل ويمنع إعادة تثبيت النظام دون داعٍ. وفي معظم الحالات يمكن استعادة الخدمة خلال دقائق بمجرد اكتشاف العنصر المفقود أو الإعداد المختلف بين الخادمين.

لهذا السبب تُعد مراجعة إعدادات VM قبل وبعد النقل واحدة من أهم الممارسات الاحترافية في إدارة بيئات Proxmox خلال عام 2026.