الانتقال إلى المحتوى
AR
احصل على NexCMP مجاناً

الترحيل · VMware

ترحيل أجهزة VMware الافتراضية إلى Apache CloudStack

يمكن لـ Apache CloudStack استيراد الأجهزة الافتراضية من VMware vCenter وتحويلها إلى KVM بدءاً من الإصدار 4.19. يتطلب تنفيذ ذلك بأمان إجراء حصر شامل، وتحديد منطقة مستهدفة، وإجراء اختبار تجريبي، ووضع خطة انتقال نهائي لكل خادم. خلال الـ 30 يوم عمل المشمولة في NexCMP Source، ينجز مهندس خبير هذا العمل معك دون أي تكلفة إضافية.

احصل على NexCMP مجاناًمشاهدة العرض التوضيحي

مشمول مع NexCMP Source ($499 لمرة واحدة)، وليس مع NexCMP Free. إن VMware وWHMCS وHostBill وBlesta وPaymenter وStackBill وVirtualizor وApache CloudStack هي علامات تجارية لمالكيها المعنيين. NexCMP مستقل وليس تابعاً لهم أو معتمداً من قبلهم.

المشكلة: مغادرة VMware دون فقدان السيطرة

الانتقال إلى Apache CloudStack يعني أن كل جهاز افتراضي يغير منصته: أقراصه وبطاقات الشبكة وبرامج التشغيل وعناوينه غالباً. وإذا تم ذلك بتسرع، فهنا تفشل الأجهزة في الإقلاع، أو يفقد العملاء إمكانية الوصول، أو تتوقف التراخيص عن العمل.

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

إذا كنت تبيع الأجهزة الافتراضية للعملاء، فلعملية النقل جانب ثانٍ: يجب أن ينتهي الأمر بربط الأجهزة بالعملاء والخطط والأسعار الصحيحة في نظام الفوترة الخاص بك. NexCMP هي طبقة الفوترة وبوابة العملاء فوق CloudStack، ويتولى المهندس نفسه كلا الجانبين.

ما يدعمه CloudStack نفسه

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

  • A. التحويل إلى KVM باستخدام virt-v2v

    ما توثقه CloudStack
    بدءاً من الإصدار 4.19، يمكن للمسؤول تحديد جهاز VM من VMware في مركز بيانات vCenter حالي أو خارجي واستيراده إلى عنقود KVM، تحت Tools،‏ Import-Export Instances. يتم تصدير الـ VM وتحويله باستخدام virt-v2v واستيراد أقراصه بتنسيق QCOW2. يضيف التوثيق الأخير مسار تدفق معتمداً على VDDK إلى جانب المسار المعتمد على OVF؛ كما أضاف الإصدار 4.22 التحويل المباشر إلى مجمع تخزين، وأضاف الإصدار 4.22.1 تحديد نظام التشغيل الضيف استناداً إلى نظام التشغيل الضيف المصدر.
    القيود المذكورة في التوثيق
    لا يتم تثبيت virt-v2v بواسطة عميل CloudStack ويجب تثبيته على كل مضيف KVM، وإلا فسيفشل التحويل. النجاح ليس مضموناً ويعتمد على نظام التشغيل الضيف وأنظمة الملفات، لذا يوصي التوثيق بالاختبار قبل الاستخدام في بيئة الإنتاج. يحصل الـ VM المستورد على نوع نظام التشغيل الضيف الافتراضي CentOS 4.5 (32-bit) في 4.19 ويجب تعديله بعد ذلك.

    Source: Apache CloudStack — استيراد أجهزة VMware الافتراضية إلى KVM · تاريخ الوصول 2026-10-19

  • B. الاستيراد في مكانه (Instances غير مدارة)

    ما توثقه CloudStack
    بالنسبة لعناقيد vSphere التي تعد مضيفاتها بالفعل جزءاً من CloudStack، يقوم listUnmanagedInstances بسرد أجهزة VM، بينما يضعها importUnmanagedInstance تحت إدارة CloudStack. بدأ سرد Instances غير المدارة الخاصة بـ VMware في 4.14، وإلغاء إدارتها في 4.15، والاستيراد عبر واجهة المستخدم في 4.16.
    القيود المذكورة في التوثيق
    يجب أن تكون الشبكة المستهدفة موجودة بالفعل في CloudStack، ويجب إضافة وحدة التخزين كتخزين أساسي. كما يجب ربط أقراص البيانات بعروض الأقراص، وتتسبب الأنواع المختلطة من وحدات التحكم بالأقراص أو بطاقات الشبكة في حدوث خطأ. لا يمكن استيراد VM قيد التشغيل إلا إذا تطابق VLAN الخاص بالشبكة وعرض Compute؛ وإلا فيجب إيقافه أولاً.

    Source: Apache CloudStack — حول Import Export Instances · تاريخ الوصول 2026-10-19

ينطبق المسار A عندما تكون الوجهة KVM. وتحدد وثائق NexCMP نفسها تقنية KVM كمشرف جهاز افتراضي تم اختباره، لذلك نخطط للمسار A ما لم يكن تصميمك يُبقي على مضيفات VMware تحت إدارة CloudStack. تحقق من إصدار CloudStack الذي تشغله: فالصفحات المذكورة أعلاه تصف سلوكاً مختلفاً بين الإصدار 4.19 والإصدار الأخير.

ما يتم نقله وما يتطلب الاهتمام

  • الأقراص

    ما يحدث
    يتم تحويلها إلى QCOW2 واستيرادها إلى مجمع التخزين الأساسي للوجهة (المسار A)، أو ربطها بعروض أقراص CloudStack (المسار B).
    نقاط هامة
    في المسار B، لا يتم تغيير حجم القرص إذا كان عرض القرص الخاص به أكبر. ويكون التخزين المؤقت أثناء التحويل في المسار A تخزيناً ثانوياً بشكل افتراضي؛ ولا يمكن استخدام التخزين الأساسي له إلا إذا كان NFS.

    Source: Apache CloudStack — استيراد أجهزة VMware الافتراضية إلى KVM · تاريخ الوصول 2026-10-19

  • الشبكات

    ما يحدث
    يجب أن تكون الشبكات موجودة في CloudStack قبل الاستيراد. يقوم سكريبت استكشاف بسرد شبكات vCenter المتصل بها جهاز VM واحد على الأقل، حتى يمكن إنشاء الشبكات المطابقة.
    نقاط هامة
    لا يستطيع virt-v2v إعادة تكوين إعدادات شبكة النظام الضيف أو تغيير عنوان MAC الخاص به. وإذا كان النطاق الفرعي المستهدف مختلفاً، فسيحتاج النظام الضيف إلى تعديلات بعد التحويل.

    Source: libguestfs — دليل virt-v2v · تاريخ الوصول 2026-10-19

  • أنظمة Linux الضيفة

    ما يحدث
    يمكن استيراد جهاز VM يعمل بنظام Linux قيد التشغيل عبر المسار A: حيث يستنسخه CloudStack قبل التصدير، مما يتيح تحويله في حالة متسقة بعد الانهيار (crash-consistent).
    نقاط هامة
    توصي وثائق CloudStack بإيقاف تشغيل أجهزة Linux الافتراضية أولاً. لا تُثبّت أداة virt-v2v نوى جديدة أو برامج تشغيل، وتُحذّر إذا كان دعم virtio مفقوداً، لذا يجب أن يستوفي نظام الضيف متطلبات الحد الأدنى للإصدار قبل التحويل.

    Source: libguestfs — دليل virt-v2v · تاريخ الوصول 2026-10-19

  • أنظمة Windows الضيفة

    ما يحدث
    يجب إيقاف تشغيلها بطريقة سليمة قبل الاستيراد عبر المسار A. تُجلب برامج تشغيل virtio من حزمة virtio-win وتُثبّت عند أول إقلاع؛ قد يُعيد Windows التشغيل أربع مرات أو أكثر بعد الإقلاع الأول.
    نقاط هامة
    تؤدي ميزة Fast Startup أو وضع الإسبات إلى منع التحويل، كما أن وجود قرص النظام على Dynamic Disk غير مدعوم. يتطلب استيراد Windows توفر برامج تشغيل virtio على خادم التحويل.

    Source: libguestfs — دليل virt-v2v · تاريخ الوصول 2026-10-19

  • VMware Tools

    ما يحدث
    تحاول أداة virt-v2v إزالة VMware Tools.
    نقاط هامة
    يُشير الدليل إلى أن الإزالة لا تعمل بشكل موثوق على Windows، حيث قد يتعين إزالة Tools بطريقة أخرى.

    Source: libguestfs — دليل virt-v2v · تاريخ الوصول 2026-10-19

  • نوع نظام التشغيل الضيف

    ما يحدث
    يحصل الجهاز الافتراضي المستورد على نوع افتراضي لنظام التشغيل الضيف.
    نقاط هامة
    في الإصدار 4.19 يكون CentOS 4.5 (32-bit) ويجب تغييره يدوياً؛ بينما يستطيع الإصدار 4.22.1 مطابقته من نظام التشغيل الضيف المصدر إذا توفرت مخططات المطابقة.

    Source: Apache CloudStack — استيراد أجهزة VMware الافتراضية إلى KVM · تاريخ الوصول 2026-10-19

  • الفوترة والعملاء

    ما يحدث
    يتم إعداد الخطط والأسعار وحسابات العملاء في NexCMP، ورَبْط كل جهاز تم نقله بالعميل المناسب.
    نقاط هامة
    يتم الاتفاق عليه في الأسبوع 1 وفقاً لإصدار CloudStack لديك. هذا من مهام NexCMP وليس ميزة في CloudStack.

الخطة، أسبوعاً بأسبوع

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

  1. الأسبوع 1 — الجرد والقرارات

    عبر صلاحية الوصول للقراءة فقط إلى vCenter، نقوم بجرد جميع الأجهزة الافتراضية: نظام التشغيل الضيف، الأقراص، بطاقات الشبكة، شبكات VLAN، اللقطات (Snapshots)، حالة التشغيل، والتبعيات المتبادلة. نحدد المسار A أو B، ونعرّف مراحل النقل، مع تحديد الأجهزة التي تتطلب عناية خاصة مثل أنظمة Windows الضيفة، والأقراص الكبيرة، وأي أجهزة مرتبطة بترخيص ثابت.

  2. الأسبوع 2 — بناء بيئة الهدف

    يتم فحص منطقة CloudStack أو إنشاؤها: خوادم KVM المضيفة، وحدات التخزين، والشبكات المطابقة لتلك الموجودة في VMware. نقوم بتثبيت virt-v2v على خوادم KVM (وnbdkit على خوادم Ubuntu المضيفة)، وتجهيز برامج تشغيل virtio لنظام Windows، وفتح مسارات الشبكة بين خوادم التحويل وvCenter وESXi. إذا كنت تبيع الأجهزة، يتم تثبيت NexCMP وربطه مع CloudStack في الأسبوع نفسه.

  3. الأسبوع 3 — المرحلة التجريبية

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

  4. الأسبوعان 4 و5 — مراحل الترحيل

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

  5. الأسبوع 6 — التحويل النهائي والتسليم

    يتم نقل آخر الأجهزة، وتعديل تاريخ الفوترة إذا كنت تبيعها، وتطبيق تغييرات DNS. نوثّق جميع الخطوات المنفذة، ونراجع إجراءات تعزيز الأمان والنسخ الاحتياطية (Backups)، ونبقى متاحين لدعم عملية النقل حتى نهاية الـ 30 يوم عمل.

مخطط عام فقط. تُحدد الخطة الفعلية بناءً على مخرجات الأسبوع 1، والالتزام الزمني الوحيد المحدد في العرض هو 30 يوم عمل.

المخاطر وكيفية الحد منها

لا تخلو أي عملية ترحيل من المخاطر، ولا نعد بانعدام فترات التوقف تماماً. إليك ما قد يطرأ وكيف نتعامل معه.

  • مدة التوقف لكل جهاز

    لا يمكن تحويل أجهزة Windows أثناء تشغيلها، بينما يتم تحويل جهاز Linux قيد التشغيل بحالة اتساق التعطل (crash-consistent). لا تُحدد CloudStack المدة التي يستغرقها التحويل. نقيس هذه المدة في المرحلة التجريبية، ثم نتفق على نافذة توقف لكل مجموعة من الأجهزة.

  • عدم نجاح عملية التحويل

    ينص CloudStack على أن النجاح غير مضمون ويعتمد على النظام الضيف. نحن نختبر كل نوع من الأنظمة الضيفة في المرحلة التجريبية قبل أي مرحلة نقل، ويبقى الجهاز الأصلي دون أي تعديل حتى يتم التحقق من الجهاز الجديد.

  • برامج التشغيل وVMware Tools

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

  • عناوين IP وعناوين MAC وDNS

    تحتفظ الأنظمة الضيفة بعناوين MAC وتكوينات الشبكة الخاصة بها، لذا فإن أي تغيير في الشبكة الفرعية المستهدفة يتطلب تعديلات داخل النظام الضيف. نقوم بجرد جميع العناوين في الأسبوع 1، وتخفيض قيم DNS TTL قبل التحويل النهائي وإبلاغ عملائك مسبقاً.

  • تراخيص برامج النظام الضيف

    قد تكون تراخيص Windows والبرمجيات التجارية داخل الأجهزة الافتراضية مرتبطة بالمنصة القديمة. ندرجها ضمن قائمة الجرد حتى تتمكن من التحقق من الشروط مع كل مزود قبل عملية النقل.

  • عمليات التحويل المنقطعة

    توضح وثائق CloudStack أن إعادة تشغيل خوادم الإدارة أثناء الترحيل تؤدي إلى مقاطعته وضرورة إعادة عملية الاستيراد من البداية. نقوم بجدولة المراحل بعيداً عن أوقات الصيانة ونتجنب إعادة التشغيل أثناء تنفيذ أي مرحلة.

  • التحول في الفوترة وإمكانية التراجع

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

توزيع المسؤوليات

  • صلاحية وصول للقراءة فقط إلى vCenter وقائمة بالأجهزة التي تعتبرها بالغة الأهمية

    ما يقوم به الخبير
    حصر جميع أجهزة VM وتخطيط مراحل النقل

  • صلاحية الوصول إلى بيئة CloudStack ومضيفات KVM، أو العتاد اللازم لبنائها

    ما يقوم به الخبير
    تجهيز المنطقة والشبكات ومضيفات التحويل

  • حزم VDDK وvirtio المطلوبة لمسار التحويل المختار، إذا كان الموردون يشترطون تنزيلها بنفسك

    ما يقوم به الخبير
    تثبيتها واختبارها على مضيفات التحويل

  • فترات التوقف المتفق عليها وتوجيه الإشعارات إلى عملائك

    ما يقوم به الخبير
    تنفيذ المرحلة التجريبية ومراحل النقل، وفحص كل جهاز بعدها

  • قرارات التسعير الخاصة بك، إذا كنت تقدم الأجهزة للبيع

    ما يقوم به الخبير
    إعداد الخطط والعملاء والفوترة في NexCMP وإدارة فترة التشغيل المتوازي

ما ستحصل عليه خلال 30 يوم عمل

ترحيل البيانات مشمول ضمن ترقية NexCMP Source: دفعة واحدة بقيمة $499 تشمل الكود المصدري بالكامل (خادم Rust، وبوابة ولوحة تحكم Vue، وعميل عقد Go، وأداة CLI، وسكربتات البناء)، وحق التعديل وبناء نسختك الخاصة بلا قيود، و12 شهراً من التحديثات المصدرية الجديدة، وجميع التطبيقات، بالإضافة إلى 30 يوم عمل من التعاون المستمر مع مهندس خبير.

خلال تلك الـ 30 يوم عمل، يقوم المهندس الخبير بترحيل بيئتك من VMware إلى Apache CloudStack دون أي تكلفة إضافية. كما يمكن استخدام نفس المدة، بدلاً من ذلك أو بالإضافة إليه، للترحيل من WHMCS أو أي نظام آخر، أو للإعداد الكامل من الألف إلى الياء وبناء تطبيقاتك. يبدأ احتساب الوقت عند بدء العمل مع الخبير ويظهر في صفحة الترخيص الخاصة بك. ويستمر دعم الترحيل طوال هذه الـ 30 يوماً.

لا تشمل خطة NexCMP Free هذه الخدمة؛ فالخطة المجانية متاحة مجاناً لمدة عام واحد بكافة الوحدات وبدون دعم فني (تقتصر على إصلاح أخطاء الكود المصدري فقط)، وتتجدد بسعر $99 سنوياً.

الترحيل من VMware إلى CloudStack — الأسئلة الشائعة

ما هي التكلفة؟
الترحيل مشمول ضمن ترقية NexCMP Source مقابل دفعة لمرة واحدة بقيمة $499. يشمل السعر الكود المصدري، و12 شهراً من التحديثات المصدرية الجديدة، وجميع التطبيقات، و30 يوم عمل بالتعاون مع مهندس خبير. ولا يتضمن العرض أي رسوم بالساعة.
هل هذا مشمول في NexCMP Free؟
لا. الترحيل متاح فقط مع NexCMP Source. توفر خطة NexCMP Free كافة الوحدات لمدة عام كامل لكنها لا تتضمن دعماً فنياً، وتقتصر على إصلاح أخطاء الكود المصدري، وتتجدد بسعر $99 سنوياً.
ما هي إصدارات CloudStack وVMware المدعومة؟
توضح وثائق CloudStack أن التحويل من VMware إلى KVM متاح بدءاً من الإصدار 4.19 دون تحديد إصدارات vSphere المدعومة؛ وتوصي الصفحة الأخيرة باستخدام VDDK 8 لبيئات vSphere 7 و8. وتشير وثائق NexCMP إلى أن الإصدار 4.23 هو إصدار CloudStack الذي تم اختباره. تحقق من الإصدار الذي تستخدمه، وسنقوم بتأكيد كلا الإصدارين في الأسبوع 1.
هل ستتعرض أجهزتي الافتراضية للتوقف عن العمل؟
نعم، سيتوقف كل جهاز عن العمل لبعض الوقت، ولا نعد بانعدام التوقف تماماً. يجب إيقاف تشغيل أجهزة Windows بصورة آمنة قبل الاستيراد. كما يمكن استيراد جهاز Linux قيد التشغيل ولكنه يُحوّل في حالة متسقة بعد الانهيار، لذا نفضل إيقاف تشغيله أولاً في العادة. تحدد المرحلة التجريبية الوقت المطلوب وفترات التوقف.
هل يمكن تحويل جميع أجهزة VM؟
ليس بالضرورة. توضح CloudStack أن نجاح التحويل غير مضمون ويعتمد على نظام التشغيل الضيف وأنظمة الملفات. كما تُدرج virt-v2v بعض حالات Windows كعوامل مانعة للتحويل، مثل وجود قرص النظام على قرص ديناميكي أو تمكين بدء التشغيل السريع. ولهذا السبب نختبر كل نوع من الأنظمة الضيفة قبل بدء مراحل الترحيل.
هل يتعين علي الاحتفاظ بـ VMware بعد الانتهاء؟
ليس بالنسبة للأجهزة التي تم نقلها. نحن نحتفظ بالنسخ الأصلية مطفأة حتى تؤكد اكتمال عملية النقل، ومن ثم تقرر متى تتخلص منها. أما ترخيص بيئة VMware نفسها فهو شأن يعود إليك وإلى الشركة المزودة لها.
ما الذي أحتاج إلى تقديمه؟
صلاحية وصول للقراءة فقط إلى vCenter، والوصول إلى بيئة CloudStack ومضيفات KVM الخاصة بها، وفترات التوقف المتفق عليها، وتعيين شخص يمكنه الإجابة عن الأسئلة المتعلقة بالأجهزة. عندما يطلب المورّد تنزيل حزمة مثل VDDK بنفسك، يتعين عليك توفيرها.

المصادر والملاحظات

تستند البيانات الفنية إلى وثائق Apache CloudStack الرسمية ودليل virt-v2v. تتغير الوثائق بين الإصدارات، لذا يرجى التحقق من الإصدار الذي تشغله. البيان الخاص بالإصدار 4.19 مأخوذ من وثائق 4.19، والتي تفتتح صفحة VMware-to-KVM بعبارة 'As of CS 4.19'. تُعد VMware وWHMCS وHostBill وBlesta وPaymenter وStackBill وVirtualizor وApache CloudStack علامات تجارية لمالكيها المعنيين. NexCMP مستقلة وليست تابعة لهم أو معتمدة منهم.

انتقل من VMware برفقة مهندس إلى جانبك

قم بالترقية إلى NexCMP Source مقابل $499 وابدأ فترة 30 يوم عمل الخاصة بك، أو تواصل أولاً مع [email protected] للاستفسار عن بيئتك.

احصل على NexCMP مجاناًتواصل مع المبيعاتمشاهدة العرض التوضيحي

آخر تحديث: