استكشاف الأخطاء وإصلاحها عند تجاوز فشل الجهاز الظاهري VMware أو الجهاز الفعلي إلى Azure

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

فشل تجاوز الفشل مع معرّف الخطأ 28031

لم يتمكن "استرداد الموقع" من إنشاء تجاوز فشل الجهاز الظاهري في Azure. يمكن أن يحدث ذلك نتيجة أحد الأسباب التالية:

  • لا تتوفر مساحة كافية لإنشاء الجهاز الظاهري: يمكنك التحقق من المساحة المتوفرة من خلال الانتقال إلى "Subscription" -> "Usage + quotas". يمكنك فتح "new support request" لزيادة المساحة المتوفرة.

  • محاولة تجاوز الفشل الأجهزة الظاهرية من عائلات مختلفة الحجم في نفس مجموعة التوفر. تأكد من اختيار عائلة بنفس الحجم لجميع الأجهزة الظاهرية في نفس مجموعة التوفر. تغيير الحجم عن طريق الانتقال إلى إعدادات "Compute" للجهاز الظاهري ثم إعادة محاولة تجاوز الفشل.

  • هناك نهج على الاشتراك يمنع إنشاء جهاز ظاهري. تغيير النهج للسماح بإنشاء جهاز ظاهري ثم إعادة محاولة تجاوز الفشل.

فشل تجاوز الفشل مع معرّف الخطأ 28092

لم يتمكن "استرداد الموقع" من إنشاء واجهة شبكة للجهاز الظاهري متجاوز الفاشل. تأكد من توفر مساحة متوفرة كافية لإنشاء واجهات شبكة في الاشتراك. يمكنك التحقق من المساحة المتاحة من خلال الانتقال إلى "Subscription" -> "Usage + quotas". يمكنك فتح "new support request" لزيادة المساحة المتوفرة. إذا كانت لديك مساحة متوفرة كافية، فقد تكون هذه مشكلة متقطعة، حاول تشغيل العملية مرة أخرى. إذا استمرت المشكلة حتى بعد المحاولات، فاترك تعليقاً في نهاية هذا المستند.

فشل تجاوز الفشل مع معرّف الخطأ 70038

لم يتمكن "استرداد الموقع" من إنشاء تجاوز فشل الجهاز الظاهري الكلاسيكي في Azure. يمكن أن يحدث ذلك بسبب:

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

فشل تجاوز الفشل مع معرّف الخطأ 170010

لم يتمكن "استرداد الموقع" من إنشاء تجاوز فشل الجهاز الظاهري في Azure. يمكن أن يحدث ذلك بسبب فشل نشاط داخلي لملء بيانات الجهاز الظاهري المحلي.

لإظهار أي جهاز في Azure، تتطلب بيئة Azure أن تكون بعض برامج التشغيل في حالة بدء التشغيل وأن تكون خدمات مثل DHCP في حالة التشغيل التلقائي. وبالتالي، فإن نشاط ملء البيانات، في وقت تجاوز الفشل، يحول نوع بدء التشغيل من برامج تشغيل الجهاز atapi وintelide وstorflt وvmbus وstorvsc لبدء التمهيد. كما أنه يحول نوع بدء التشغيل لعدد قليل من الخدمات مثل DHCP إلى البدء التلقائي. يمكن أن يفشل هذا النشاط بسبب مشكلات خاصة بالبيئة.

لتغيير نوع بدء تشغيل برامج تشغيل الجهاز Windows Guest OS يدويا، اتبع الخطوات التالية:

  1. تنزيل البرنامج النصي بدون ملء بيانات وقم بتشغيله على النحو التالي. يتحقق هذا البرنامج النصي مما إذا كان الجهاز الظاهري يتطلب ملء بيانات.

    .\Script-no-hydration.ps1

    يعطي النتيجة التالية إذا كان ملء بيانات مطلوباً:

    REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0
    
    This system doesn't meet no-hydration requirement.
    

    في حالة تلبية الجهاز الظاهري لمتطلبات عدم ملء بيانات، سيعطي البرنامج النصي النتيجة "هذا النظام يلبي متطلبات عدم ملء بيانات". في هذه الحالة، تكون جميع برامج التشغيل والخدمات في الحالة كما هو مطلوب بواسطة Azure ولا يلزم ملء بيانات على الجهاز الظاهري.

  2. قم بتشغيل البرنامج النصي بدون استخدام على النحو التالي إذا كان الجهاز الظاهري لا يفي بمتطلبات عدم ملء بيانات.

    .\Script-no-hydration.ps1 -set

    سيؤدي ذلك إلى تحويل نوع بدء التشغيل من برامج تشغيل الجهاز وسيعطي النتيجة كما هو موضح أدناه:

    REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc           start =  3 expected value =  0
    
    Updating registry:  REGISTRY::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\storvsc   start =  0
    
    This system is now no-hydration compatible.
    

غير قادر على الاتصال / RDP / SSH بالجهاز الظاهري متجاوز الفشل بسبب الاتصال الزر المعتم على الجهاز الظاهري

للحصول على إرشادات مفصّلة لاستكشاف الأخطاء وإصلاحها حول مشكلات RDP، يرجى الاطلاع على وثائقنا هنا.

للحصول على إرشادات مفصّلة لاستكشاف الأخطاء وإصلاحها حول مشكلات SSH، يرجى الاطلاع على وثائقنا هنا.

إذا كان الزر Connect على الجهاز الظاهري متجاوز الفشل في Azure معتماً ولم تكن متصلاً بـ Azure عبر اتصال Express Route أو اتصال VPN من موقع إلى موقع، فعندئذ،

  1. انتقل إلى "Virtual machine">"Networking"، ثم انقر فوق اسم واجهة الشبكة المطلوبة. Screenshot shows the Networking page for a virtual machine with the network interface name selected.
  2. انتقل إلى "Ip Configurations"، ثم انقر فوق حقل الاسم الخاص بتكوين IP المطلوب. Screenshot shows the I P configurations page for the network interface with the I P configuration name selected.
  3. لتمكين عنوان IP العام، انقر فوق "Enable". Enable IP
  4. انقر فوق "Configure required settings">"Create new". Create new
  5. أدخل اسم العنوان العام، واختر الخيارات الافتراضية "SKU""assignment"، ثم انقر على "OK".
  6. الآن، لحفظ التغييرات التي تم إجراؤها، انقر على "Save".
  7. أغلق اللوحات وانتقل إلى قسم "Overview" من الجهاز الظاهري للاتصال/RDP.

تعذر الاتصال / RDP / SSH - زر VM Connect متوفر

إذا كان الزر Connect على الجهاز الظاهري متجاوز الفشل في Azure متوفراً (غير معتم)، فتحقق من "Boot diagnostics" على الجهاز الظاهري وتحقق من وجود أخطاء كما هو موضح في هذه المقالة.

  1. إذا لم يبدأ تشغيل الجهاز الظاهري، فحاول تجاوز الفشل إلى نقطة استرداد أقدم.

  2. إذا لم يكن التطبيق الموجود داخل الجهاز الظاهري قيد التشغيل، فحاول تجاوز الفشل في الوصول إلى نقطة استرداد متناسقة مع التطبيق.

  3. إذا كان الجهاز الظاهري متصلاً بالمجال، فتأكد من أن وحدة التحكم بالمجال تعمل بدقة. يمكن القيام بذلك باتباع الخطوات التالية المحددة:

    أ. إنشاء جهاز ظاهري جديد في نفس الشبكة.

    ب. تأكد من أنه قادر على الاتصال بنفس المجال الذي من المتوقع أن يظهر عليه الجهاز الظاهري متجاوز الفشل.

    ج. إذا كانت وحدة التحكم بالمجال لا تعمل بدقة، فحاول تسجيل الدخول إلى الجهاز الظاهري متجاوز الفشل باستخدام حساب مسؤول محلي.

  4. إذا كنت تستخدم خادم DNS مخصصاً، فتأكد من إمكانية الوصول إليه. يمكن القيام بذلك باتباع الخطوات التالية المحددة:

    أ. إنشاء جهاز ظاهري جديد في نفس الشبكة و

    ب. تحقق مما إذا كان الجهاز الظاهري قادراً على إجراء تحليل الاسم باستخدام خادم DNS المخصص

ملاحظة

يتطلب تمكين أي إعداد بخلاف "Boot Diagnostics" تثبيت Azure VM Agent في الجهاز الظاهري قبل تجاوز الفشل

غير قادر على فتح وحدة التحكم التسلسلية بعد تجاوز فشل جهاز يستند إلى UEFI في Azure

إذا كنت قادراً على الاتصال بالجهاز باستخدام RDP ولكن لا يمكنك فتح وحدة التحكم التسلسلية، فاتبع الخطوات التالية:

  • إذا كان نظام تشغيل الجهاز Red Hat أو Oracle Linux 7.*/8.0، فقم بتشغيل الأمر التالي على جهاز Azure الظاهري لتجاوز الفشل باستخدام أذونات الجذر. أعد تشغيل الجهاز الظاهري بعد الأمر.

    grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
    
  • إذا كان نظام تشغيل الجهاز هو CentOS 7.*، فقم بتشغيل الأمر التالي على جهاز Azure الظاهر لتجاوز الفشل باستخدام أذونات الجذر. أعد تشغيل الجهاز الظاهري بعد الأمر.

    grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
    

رسالة إيقاف تشغيل غير متوقعة (معرّف الحدث 6008)

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

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

غير قادر على تحديد مخزن البيانات

تتم الإشارة إلى هذه المشكلة عندما لا تتمكن من رؤية مخزن البيانات في مدخل Azure عند محاولة إعادة حماية الجهاز الظاهري الذي واجه تجاوز الفشل. وذلك لأنه لم يتم التعرف على الهدف الرئيسي كجهاز ظاهري ضمن vCenters مضاف إلى Azure Site Recovery.

لمزيد من المعلومات حول إعادة حماية جهاز ظاهري، راجع إعادة حماية الأجهزة وإرجاع مواردها إلى موقع محلي بعد تجاوز الفشل إلى Azure.

لحل الخطأ:

قم بإنشاء الهدف الرئيسي يدوياً في vCenter الذي يدير جهاز المصدر. سيكون مخزن البيانات متاحاً بعد اكتشاف vCenter التالي وتحديث عمليات التصميم.

ملاحظة

يمكن أن تستغرق عمليات اكتشاف التصميم وتحديثها ما يصل إلى 30 دقيقة لإكمالها.

فشل تسجيل Linux Master Target مع CS بخطأ TLS 35

فشل تسجيل Azure Site Recovery Master Target مع خادم التكوين بسبب تمكين الوكيل المصدق على الهدف الرئيسي.

يُشار إلى هذا الخطأ بواسطة السلاسل التالية في سجل التثبيت:

RegisterHostStaticInfo encountered exception config/talwrapper.cpp(107)[post] CurlWrapper Post failed : server : 10.38.229.221, port : 443, phpUrl : request_handler.php, secure : true, ignoreCurlPartialError : false with error: [at curlwrapperlib/curlwrapper.cpp:processCurlResponse:231]   failed to post request: (35) - SSL connect error. 

لحل الخطأ:

  1. على الجهاز الظاهري لخادم التكوين، افتح موجه الأوامر وتحقق من إعدادات الوكيل باستخدام الأوامر التالية:

    cat /etc/environment echo $http_proxy echo $https_proxy

  2. إذا أظهر ناتج الأوامر السابقة أن إعدادات http_proxy أو https_proxy محددة، فاستخدم أحد الأساليب التالية لإلغاء حظر اتصالات الهدف الرئيسي مع خادم التكوين:

    • قم بتنزيل أداة PsExec.

    • استخدم الأداة للوصول إلى سياق مستخدم النظام وتحديد ما إذا كان عنوان الوكيل قد تم تكوينه أم لا.

    • إذا تم تكوين الوكيل، فافتح IE في سياق مستخدم النظام باستخدام أداة PsExec.

      psexec -s -i "%programfiles%\Internet Explorer\iexplore.exe"

    • للتأكد من أن ملقم الهدف الرئيسي يمكنه الاتصال بخادم التكوين:

      • تعديل إعدادات الوكيل في Internet Explorer لتجاوز عنوان IP للخادم الهدف الرئيسي من خلال الوكيل.
        أو
      • تعطيل الوكيل على الملقم الهدف الرئيسي.

الخطوات التالية

إذا كنت بحاجة إلى مزيد من المساعدة، فانشر استعلامك على صفحة الأسئلة والأجوبة لـ Microsoft& "لاسترداد الموقع" أو اترك تعليقا في نهاية هذا المستند. لدينا مجتمع نشط يجب أن يكون قادراً على مساعدتك.