ملاحظات الإصدار لـ Condensa

يسجّل هذا السجل التحديثات والميزات الجديدة وإصلاحات الأخطاء في Condensa.

---

الإصدار 1.9.4 (أكتوبر 2026)

اختيار جهاز افتراضي من VMware يختار الآن ذلك الجهاز دائمًا، حتى عندما يكون لجهاز آخر معرّف BIOS UUID نفسه.

• لم يعد جهازان افتراضيان لهما BIOS UUID نفسه يظهران كجهاز واحد. قد يحتفظ الجهاز الافتراضي المنسوخ في vSphere بمعرّف BIOS UUID الخاص بمصدره. في جميع الإصدارات السابقة، كان اختيار أيٍّ من جهازين كهذين يحدد كليهما، ويأخذ الترحيل أيهما أجاب به vCenter، فيتعذّر ترحيل أحدهما. يعرّف Condensa الآن كل جهاز افتراضي من VMware بمعرّف instance UUID الخاص به، الذي يحافظ vSphere على تفرّده.
• لا يمكن ترحيل جهاز افتراضي يشارك BIOS UUID إلى Awanio CEP. يبحث مستورد أقراص CEP عن الأجهزة الافتراضية بمعرّف BIOS UUID ولا يستطيع التمييز بين هذه الأجهزة. يضع المعالج على الجهاز وسم Duplicate BIOS UUID ويذكر اسم توأمه. امنح أحدهما BIOS UUID جديدًا في vSphere، أو رحّله إلى هدف Vapor أو Cockpit.
• تستمر عمليات الترحيل التي أُنشئت بإصدار سابق في العمل بعد التحديث. إذا كان الجهاز الافتراضي في ترحيل كهذا يشارك BIOS UUID مع جهاز آخر، يُرفض الترحيل مع ذكر الاسمين بدلًا من بدئه على أحدهما؛ أنشئ الترحيل من جديد.

---

الإصدار 1.9.3 (أكتوبر 2026)

الترحيل الذي يتوقف بعد أن أطفأ Condensa المصدر يعيد عبء العمل الآن.

• يُعاد تشغيل الجهاز الافتراضي المصدر عندما لا يكتمل الترحيل. في جميع الإصدارات السابقة، كان ترحيل VMware الدافئ الذي يفشل أو يُلغى عند الانتقال يترك الجهاز الافتراضي المصدر مطفأً، وكان الترحيل من Awanio CEP يترك ضيف المصدر متوقفاً بالطريقة نفسها — فيبقى عبء العمل متوقفاً على الجانبين حتى يشغّله أحد يدوياً. أصبح Condensa يعيد تشغيل المصدر ويسجّل ذلك في سجل الترحيل، ما دام الـ VM الهدف لم يُطلب بعد. ويشمل ذلك أيضاً الترحيل الذي انقطع بسبب إعادة تشغيل Condensa. أما المصدر الذي أوقفته بنفسك من أجل الانتقال اليدوي، أو الذي كان مطفأً من البداية، فيُترك كما هو.
• بعد طلب الـ VM الهدف، يبقى المصدر مطفأً. قد تكون النسخة موجودة بالفعل على الهدف، ولا يجوز أبداً تشغيل نسختين من الضيف نفسه. يذكر سجل الترحيل أن المصدر تُرك مطفأً، ويطلب منك التحقق من الهدف وحذف أي نسخة هناك قبل تشغيل المصدر.
• إلغاء الترحيل الدافئ لم يعد يترك نقاط تحقق Condensa على الجهاز الافتراضي المصدر. كان الإلغاء يترك كل لقطات condensa-warm-*؛ أما الآن فتُحذف كما في أي نهاية أخرى للترحيل.
• إلغاء الترحيل من Awanio CEP يغلق التصدير على موقع المصدر. كان التصدير ورمز التنزيل الخاص به يبقيان صالحين لساعات بعد الإلغاء؛ أما الآن فيُغلقان بمجرد أن يتوقف الهدف عن القراءة منهما.

---

الإصدار 1.9.2 (سبتمبر 2026)

أصبحت الإعدادات التي تحدد ما يحدث لكل جهاز افتراضي في خطوة واحدة، وتذكر المراجعة ما غيّرته.

• لم يعد إلغاء الترحيل يحذف الأجهزة الافتراضية التي رُحّلت بالفعل. في جميع الإصدارات السابقة، كان إلغاء دفعة في منتصفها يحذف أيضًا أقراص (PVC) الأجهزة التي اكتمل ترحيلها إلى Awanio CEP، فتبقى تلك الأجهزة بلا تخزين. أصبح الإلغاء الآن يوقف الأجهزة التي لا تزال قيد التنفيذ فقط؛ وتحتفظ الأجهزة المكتملة بأقراصها، ويذكر سجل الترحيل عدد ما احتُفظ به. حدّث قبل إلغاء دفعة رُحّل بعض أجهزتها بالفعل.
• تذكر المراجعة كل تغيير على مستوى الجهاز الافتراضي. كان الجهاز الذي تغييره الوحيد هو New MAC address، أو إلغاء الشبكة الافتراضية، أو مسار افتراضي، أو عنوان مثبّت، أو VPC يظهر بصيغة vm-demo — دون أي وصف بعد الشرطة. جميعها موصوفة الآن، ولا تظهر الشرطة إلا عند وجود ما يُذكر.
• انتقل خيار Power on the VM after migration إلى خطوة Mapping. فهو الإعداد الافتراضي لكل جهاز افتراضي في الترحيل، ومفاتيح كل جهاز التي يسري عليها موجودة في الخطوة نفسها — وكان نص المساعدة نفسه يوجّهك لتغييرها هناك. أصبحت خطوة Basic Info مخصصة لمكان وصول الترحيل فقط: المزوّد والمضيف ومجمع التخزين والمؤسسة والمشروع.
• أصبح Manual cutover إعدادًا لكامل الترحيل. يمكن لأهداف Vapor وCockpit طلبه مرة واحدة بدل فتح بطاقة كل جهاز افتراضي. ينتظر الترحيل الدافئ بعدها أن توقف كل جهاز من داخل نظام التشغيل بدل إيقاف المصدر تلقائيًا. ولا يتأثر الترحيل البارد.
• يمكن لتعديل ترحيل متوقف تغيير كلا الإعدادين. كان إعدادا التشغيل والتحويل الافتراضيان هما الإعدادين الوحيدين في Mapping اللذين يُهملان بصمت عند الحفظ.
• يمكن الآن منح واجهة لجهاز افتراضي لا يوجد لديه ما يُربط. تُوصَل الشبكة الهدف لكل واجهة مصدر، لذا فإن الجهاز الذي تكون واجهته الوحيدة هي شبكة pod في المصدر — أو الذي لا يملك أي واجهة — لم يكن يصل إليها أبدًا: كان يصل بشبكة pod وحدها دون أي توضيح. أصبحت بطاقته في خطوة Mapping توفّر Attach an interface on لتسمية الشبكة الهدف التي تُمنح له. ولا يُضاف شيء ما لم تطلبه، لكل جهاز افتراضي.
• يمكن منح الجهاز الافتراضي عدة واجهات مضافة، لكل منها عنوانها ومسارها الافتراضي. يطلب Attach an interface on نوع الشبكة أولًا، ثم الشبكة، ثم عنوان IP اختياريًا وSet as default route — مثل مربع Create Network في الموقع نفسه. لا تُعرض الشبكة المستخدمة مسبقًا في ذلك الجهاز مرة أخرى، ولا يمكن إلا لواجهة واحدة في كل جهاز حمل المسار الافتراضي.
• لم يعد المعالج يفرض الشبكة الافتراضية على مثل هذا الجهاز. كان يرفض المتابعة ما لم تُعِد تفعيل Create default network، بينما كانت البطاقة نفسها تذكر بحق أن الوصول دون شبكة أمر مسموح ويمكن توصيله لاحقًا على الهدف.
• يفشل الآن الترحيل الذي يتعذّر جلب قرصه بدل أن يبقى قيد التشغيل إلى الأبد. عندما كان المصدر يرفض كل تنزيل للقرص (401 أو 403 أو 404 أو 410) في ثلاث إعادات تشغيل للمستورد، أو عندما تُغلق نافذة التصدير في المصدر، كان الترحيل يبقى Running بينما يعيد المستورد المحاولة على الهدف بلا نهاية. أصبح الآن يفشل مع سبب يذكر المصدر وما يجب فعله، ويزيل القرص المستورد جزئيًا من الهدف. ويستمر إعادة المحاولة مع المصدر البطيء أو الذي يتعذّر الوصول إليه مؤقتًا. كما يزيل الآن الترحيل الذي أنهاه إعادة تشغيل Condensa أقراصه المستوردة جزئيًا من الهدف، بدل ترك مستورديها قيد التشغيل.
• يُكتشف الآن قبل النقل مزوّد VMware الذي لم تعد بصمة SSL المخزّنة له مطابقة للمضيف. إعادة تثبيت ESXi أو ترقيته تعيد توليد شهادة المضيف، فكان كل نقل عبر VDDK يفشل بـ VixDiskLib_Open: … Unknown error بينما تستمر اللقطات وتتبّع التغييرات وقائمة الأجهزة في العمل. تُقارن البصمة الآن بالشهادة التي يقدّمها المضيف قبل فتح القرص: مع تفعيل Allow insecure connection تُستخدم بصمة المضيف الحالية ويذكر سجل الترحيل أن المخزّنة قديمة؛ ومع تعطيله يتوقف الترحيل قبل إنشاء أي شيء ويذكر القيمتين وتاريخ سريان الشهادة الجديدة. ويبلّغ Test Connection في المزوّد عن عدم التطابق نفسه، فتُكتشف الشهادة المستبدلة من صفحة Providers لا من قرص فاشل.
• يمكن الآن تحديد Keep the final snapshot on the source VM لكل جهاز افتراضي على حدة. كان هذا الإعداد الافتراضي الوحيد في Mapping بلا مفتاح لكل جهاز، فكانت الدفعة إما تحتفظ بنقطة استعادة على كل جهاز أو على أي منها. تحمل بطاقة كل جهاز الآن المفتاح، وتذكر المراجعة الأجهزة المختلفة، ويظهر الخيار أيضًا عند إعادة فتح الترحيل عبر Edit and retry حيث كان مفقودًا من قبل. ما يُحتفظ به لا يزال نقطة التحقق التي أنشأها Condensa فقط؛ أما اللقطات التي لم ينشئها فلا تُمس أبدًا.
• يُحدَّد الترحيل الدافئ أو البارد الآن من حالة الطاقة عند بدء الترحيل لا عند إنشائه. كان الترحيل المُعدّ والجهاز متوقف ثم المُبدوء بعد تشغيله يسلك المسار البارد ويفشل على قرص يحتجزه الجهاز العامل. يُسأل المصدر الآن عند البدء (VMware وProxmox)، ويذكر سجل الترحيل اختلاف الإجابة عن المسجّل، ويبقى المسجّل ساريًا إن تعذّر الوصول إلى المصدر.
• أصبح لخطوة Select VMs زر Refresh list. كان تشغيل جهاز أو إيقافه أو تفعيل تتبّع التغييرات أثناء فتح المعالج يستلزم إغلاق الحوار وإعادة كل الإجابات. تُقرأ القائمة الآن في مكانها مع الاحتفاظ بالاختيارات.
• يمكن بدء الترحيل المنتظر من صفحته. تحمل بطاقة الحالة في Migration Details زر Start Migration بدل إعادتك إلى قائمة Actions في الصف؛ ويظهر الرفض أسفل الزر.
• لم يعد القرص المنتظر يجعل تقدّم الترحيل يظهر "size unknown". أثناء نسخ القرص الأول لجهاز ما، كانت الأقراص المنتظرة خلفه تُعدّ غير قابلة للقياس فلا يعرض شريط الترحيل نسبة رغم أن القرص الجاري يبلّغ عنها.
• يفشل الآن الترحيل عندما لا يتّسع القرص على الهدف بدل نسخه مرة بعد مرة. عندما كانت المساحة الحرة في تخزين الهدف أصغر من القرص — مثلًا بسبب حصة أو حد للتخزين — كان المستورد ينسخ القرص كاملًا حتى 100% ثم يبدأ من 0% من جديد، ويبقى الترحيل Running لساعات. أصبح الآن يفشل مع ذكر حجم القرص والمساحة الحرة على الهدف، ويزيل القرص المستورد جزئيًا. ارفع الحد أو حرّر مساحة على الهدف، ثم ابدأ الترحيل مرة أخرى.

يتطلب إلغاء الشبكة الافتراضية Awanio CEP 3.9.0 أو أحدث

يتطلب إيقاف Create default network في الترحيل إلى Awanio CEP إصدار CEP 3.9.0 أو أحدث — وهو الإصدار الظاهر أسفل القائمة الجانبية في لوحة تحكم CEP. يواصل CEP الأقدم إرفاق الشبكة الافتراضية، ويذكر سجل الترحيل ذلك. تعمل الواجهات المضافة وربط الشبكات مع الإصدارات الأقدم.

لم تعد خطوة Mapping تحتوي على Target Network لكامل الترحيل

تُربط واجهات كل جهاز افتراضي في بطاقته الخاصة. لا تُنشأ الواجهة غير المربوطة، وتذكر البطاقة ذلك. لإرسال شبكة مصدر إلى المكان نفسه في كل الأجهزة دفعة واحدة، استخدم Per-network mapping فوق البطاقات. يحتفظ الترحيل المحفوظ قبل 1.9.2 مع Target Network بها: عند فتحه للتعديل تظهر تلك الشبكة على واجهات كل جهاز.

---

الإصدار 1.9.1 (سبتمبر 2026)

يوضّح معالج الترحيل الآن سبب تعذّر ترحيل جهاز افتراضي، ويمكن لهدف CEP ترك الجهاز الافتراضي المُرحَّل متوقفًا عن التشغيل.

• الجهاز الافتراضي الذي لا يمكن ترحيله يذكر السبب أسفل صفّه. لم يكن من الممكن تحديد جهاز VMware افتراضي قيد التشغيل مع تعطيل CBT ودون لقطة (snapshot)، ومع ذلك كان صفّه يعرض شارة Warm ولا يظهر السبب إلا في تلميح الأداة. أصبح يعرض الآن Needs CBT مع كتابة السبب أسفل الصف: فعّل CBT أو أوقف تشغيل الجهاز الافتراضي.
• يتم شرح القرص الذي لا يُبلغ vCenter عن حجمه. كان هذا الجهاز الافتراضي يظهر بحجم 0 GB، ومنذ الإصدار 1.9.0 كان ترحيله يُرفض دون ذكر السبب. يذكر المعالج الآن السبب الظاهر في تخطيط ملفات الجهاز الافتراضي — مثل ملف واصف القرص (descriptor) بحجم 0 بايت — مع مسار الملف وحجم ملف البيانات، ويضع على الجهاز الافتراضي علامة Unreadable disk. الإصلاح يتم من جهة vSphere: أصلح القرص أو استبدله، ثم أعد تحميل القائمة.
• أهداف CEP: اختر ما إذا كان الجهاز الافتراضي يُشغَّل بعد الترحيل. كان كل جهاز افتراضي يُرحَّل إلى Awanio CEP يُشغَّل تلقائيًا. أصبح خيار Power on the VM after migration، المتاح مسبقًا لأهداف Vapor وCockpit، متاحًا الآن لـ CEP أيضًا — كقيمة افتراضية للترحيل، ولكل جهاز افتراضي في خطوة Mapping.
• عرض الأجهزة الافتراضية للمزوّد. يؤدي النقر على بطاقة المزوّد إلى فتح تفاصيله والأجهزة الافتراضية التي يحتويها — VMware (لكل مركز بيانات) وProxmox وAwanio CEP وملفات OVA/VHD المرفوعة وVapor وCockpit — مع الحالة وvCPU والذاكرة والتخزين وعنوان IP ونظام التشغيل، بقدر ما يُبلغ عنه المزوّد. يمكن للمسؤولين تعديل المزوّد من هناك والعودة باستخدام Back.
• يعمل Test Connection عند تعديل مزوّد دون إعادة كتابة سرّه. منذ الإصدار 1.1.5، كان ترك كلمة المرور أو السر أو رمز API فارغًا — كما يدعو النموذج للإبقاء على القيمة المحفوظة — يجعل Test Connection يفشل برسالة مثل vendor vapor requires an API token قبل اختبار أي شيء. أصبح الاختبار الآن يستخدم السر المحفوظ. إذا غيّرت عنوان المزوّد أو حسابه، فأدخل السر مجددًا: لا يُرسَل السر المحفوظ إلى خادم آخر.
• أهداف Vapor: يُكتشف اسم الجهاز الافتراضي المستخدَم مسبقًا قبل النقل. كانت عملية الترحيل إلى مضيف Vapor الذي يستخدم اسم الجهاز الافتراضي الهدف مسبقًا تنفّذ نقل القرص بالكامل ثم تفشل في إنشاء الجهاز. أصبحت الآن تتوقف قبل النقل، وتذكر اسم الجهاز، وتطلب إعادة تسميته أو إزالة الجهاز الموجود.

لم يعد النقر على بطاقة المزوّد يفتح نموذج التعديل

يفتح النقر تفاصيل المزوّد. استخدم Edit على البطاقة أو في صفحة التفاصيل لتعديل المزوّد.

---

الإصدار 1.9.0 (سبتمبر 2026)

الترحيل الذي لا يمكن إتمامه على نحو صحيح صار يتوقف قبل أن يبدأ، بدل أن يفشل لاحقاً برسالة لا تدلّ على شيء. أربعة من حالات الفشل في هذا الإصدار كانت تبدو للمشغّل مشكلات مختلفة — قرص يُعرض فارغاً، واستيراد مرفوض، وخطأ اتصال لا يذكر أي قرص — وكلٌّ منها كان ينتهي بعيداً عن سببه. صارت تُبلَّغ الآن حيث تقع، مع ذكر اسم الجهاز الافتراضي والقرص.

• تُقرأ أحجام الأقراص من الحقل الذي يملؤه vSphere فعلاً. كان القرص يُدرج بحجم 0 GB في قائمة اختيار الأجهزة بينما حجمه 100 GB في المصدر، لأن الحجم كان يُقرأ من حقل أهملته VMware منذ vSphere 5.5 ولم تعد تملؤه دائماً.
• القرص الذي يتعذّر قراءة حجمه يُرفض مع ذكر اسمه. كان مثل هذا القرص يُمنح حجماً وجهته 1 GiB. مع قرص كبير يفشل الاستيراد داخل أداة الاستيراد دون أي ذكر للحجم، ومع قرص صغير قد يكتمل ويسلّمك جهازاً افتراضياً قرصه ليس القرص الذي رحّلته.
• يُقارَن الحجم النهائي بقرص المصدر قبل تسجيل الاستيراد نجاحاً. فإن ثبت أنه أصغر، يُبلَّغ عن القرص بوصفه فاشلاً مع ذكر الحجمين، لا بوصفه نجاحاً لا يستطيع أحد التصرّف بناءً عليه.
• تُحَلّ بصمة SSL التي يحتاجها استيراد VMware قبل أن يبدأ أي شيء. كان الاستيراد يفشل برسالة spec.source.VDDK source VDDK is not valid التي لا تسمّي الحقل المعطوب ولا المزوّد، ولا تصل إلا بعد أن يكون الترحيل قد بدأ وأعاد المحاولة. المزوّد المعلَّم بأنه غير موثّق تُقرأ بصمته من المضيف، أما المزوّد المفترض التحقّق منه فيُرفض مع ذكر اسمه، ومع الإشارة إلى نقطة النهاية التي تُنتج القيمة.
• تُكتشف الأقراص القائمة على اللقطات والصيغ القديمة. الجهاز الذي يستخدم قرصه فرق لقطة (SEsparse) أو صيغة sparse أو flat قديمة لم يكن يُقرأ له مسار، فيفشل الاستيراد برسالة server has no export named '' التي لا تذكر جهازاً ولا قرصاً ولا ملفاً. تُقرأ الآن كل الأقراص القائمة على ملفات، أياً كانت صيغتها.
• عطل الشبكة صار يوضّح شبكة مَن. تعمل أداة استيراد الأقراص داخل العنقود الوجهة، وتحلّ الأسماء عبر DNS الخاص بالعنقود، وتتصل من شبكته — فالمصدر الذي يصله Condensa، بما في ذلك مصدر نجح اختبار اتصاله للتو، قد يظلّ غير قابل للوصول من هناك. صار هذا العطل يقول ذلك، ويفرّق بين اسم لم يُحلّ ونقطة نهاية لم تُجب.

قد تُرفض الآن عمليات ترحيل كانت تبدأ من قبل

هذا مقصود. الترحيل الذي يتعذّر تحديد حجمه أو عنوانه بدقّة كان يبدأ ويعمل ثم يفشل في مكان ما لاحقاً — أو، في أسوأ الأحوال، يكتمل بقرص أصغر من المصدر. صار يُرفض الآن عند النقطة التي لا يزال بالإمكان فيها تسمية الجهاز والقرص.

إن رُفض ترحيل كان يعمل سابقاً، فالرسالة تذكر الجهاز والقرص. أعد فحص جهاز المصدر أولاً: تُقرأ الأحجام والمسارات من جديد في كل مرة، وهذه القراءة نفسها هي ما يصلحه هذا الإصدار.

الاستيراد الذي تبلّغ أداة الاستيراد عن نجاحه قد يُسجَّل الآن فاشلاً. بشرط وجود دليل موجب فقط: أن يكون الحجمان معلومين، وأن يكون الحجم أصغر من قرص المصدر. أما حين يكون الحجم مجهولاً ببساطة، فيقول Condensa ذلك، ولا يحوّل معلومة ناقصة إلى حكم في أي من الاتجاهين.

الاستيراد عبر واجهة migration-disk الخاصة بالمنصّة لا يمكن التحقّق من حجمه بعد

لا تبلّغ هذه الواجهة عن حجم الحجم المخصَّص، لذا يظلّ الاستيراد عبرها مقبولاً بناءً على تقرير أداة الاستيراد. ولا يذكر Condensa هذا إلا حين يكون حجم المصدر مجهولاً هو الآخر — أي حين لم يحدّد أحدٌ قط كم ينبغي أن يكون حجم القرص، فيصبح المشغّل هو الوحيد القادر على التأكّد.

---

الإصدار 1.8.1 (سبتمبر 2026)

لم يعد فحص التحديث يخلط بين "تعذّر النظر" و"أنت على الأحدث". فالتثبيت المبني من المصدر يبلّغ عن نسخته بصيغة مثل 1.8.0+g94ca213، والجزء الزائد بيانات بناء، وهو جزء مشروع من رقم النسخة ينصّ المعيار على تجاهله عند تحديد أي إصدار أحدث. ولم يكن Condensa يتجاهله، بل كان يعجز عن قراءة النسخة أصلاً، فلا يقارن شيئاً، ثم يبلّغ بأن "Condensa is up to date — you are on the newest published release" بينما إصدار أحدث قائم على البوابة.

• صارت النسخ الحاملة لبيانات البناء تُقرأ قراءة صحيحة، فيُعرض على مثل هذا التثبيت من التحديثات ما يُعرض على غيره.
• وصارت النسخة التمهيدية — 1.8.0-rc1 — تقع دون الإصدار الذي تفضي إليه.
• وحين تتعذّر قراءة نسخة فعلاً، يقول الحوار ذلك ويسمّي النسخة التي لم يستطع مقارنتها، بدل عرضها خبراً ساراً. فلم يعد الفحص الذي لم يقع يُقدَّم نتيجةً سليمة.

أما التثبيتات المُنزَّلة من بوابة المؤسسات فلم تتأثر أصلاً. فهي تبلّغ برقم نسخة مجرّد، وكانت المقارنة تصحّ فيه دائماً. وإنما يبلغ هذا الإصلاح التثبيتات المبنية من المصدر، وهي أيضاً طريقة الموقع المعزول في بناء نسخته.

التثبيت الذي يعرض نسخة مثل 1.8.0+g94ca213 يحتاج ترقية يدوية واحدة

لا يبلغ هذا الإصدار مثل ذلك التثبيت من تلقاء نفسه: فهو متوقف للسبب ذاته الذي يصلحه هذا الإصدار، ومن ثمّ لن يُعرض عليه هو الآخر. رقّه يدوياً مرة واحدة، ويعمل التحديث التلقائي بعدها.

sudo systemctl stop condensa
curl -fLo /tmp/condensa.tar.gz <رابط التنزيل من بوابة المؤسسات>
sudo tar -xzf /tmp/condensa.tar.gz -C /usr/local/bin condensa
sudo systemctl start condensa

ولا يُعاد ضبط شيء: المزوّدون وبيانات الاعتماد وسجل الترحيلات والسرّان يبقون كما هم. تحقق من النسخة بعد ذلك — ينبغي أن يطبع condensa -version الرقم المجرّد 1.8.1.

---

الإصدار 1.8.0 (سبتمبر 2026)

يمكن أن يُطلب من الترحيل الدافئ ترك لقطته الأخيرة على الجهاز المصدر. كل نقطة تحقق يأخذها الترحيل الدافئ على مصدر VMware هي من صنعه، وتُحذف جميعها عند انتهائه. وهذا هو الأصل الصحيح — فلقطة VMware تُنمّي قرصاً تفاضلياً ما بقيت — غير أنه لا يترك ما يُعاد إليه إن تبيّن لاحقاً أن الوجهة خاطئة.

• احتفظ باللقطة الأخيرة على الجهاز المصدر، معطّل افتراضياً، في خطوة Mapping لمصادر VMware. تبقى نقطة التحقق الأخيرة نقطةَ استرجاع للحالة التي بُنيت منها الوجهة بالضبط.
• وتُعاد تسميتها إلى condensa-migrated-<التاريخ>-<الترحيل>. وهذا لبّ الميزة لا زينتها: إذ يمسح Condensa في مستهل كل تشغيل دافئ كل ما يحمل اسم condensa-warm-*، فلقطة محفوظة بذلك الاسم سيحذفها الترحيل التالي للجهاز نفسه. أما بعد إعادة التسمية فهي لك.
• أما نقاط التحقق المأخوذة أثناء النسخ فتُحذف كما كانت. فهي آلية عمل الترحيل الدافئ لا بقايا منه، والاحتفاظ بها يعني تكديس أقراص تفاضلية على جهاز ما يزال يخدم مستخدميه.
• ولا يُحتفظ بشيء إن لم ينتج عن التشغيل جهاز. فنقطة تحقق من ترحيل لم يحطّ ليست نقطة استرجاع.
• والكلفة عليك أن تقبلها. فاللقطة المحفوظة تُنمّي قرصاً تفاضلياً حتى تحذفها، واللقطات المنسية سبب معروف لامتلاء المخازن. ويعيد سجل الترحيل ذكر اسم اللقطة المحفوظة كي تجدها لاحقاً.

واللقطات التي لم يُنشئها Condensa تبقى غير ممسوسة في الحالين، والترحيل البارد لا يأخذ لقطة أصلاً.

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

---

الإصدار 1.7.0 (سبتمبر 2026)

صارت أقراص الترحيل تحمل اسم الضيف، داخل مجلد خاص بها. كان القرص فيما مضى يحطّ ملفاً مسطحاً باسم الترحيل الذي أنشأه — condensa-m119-vm123-disk0.qcow2. فمخزن البيانات الذي يضم عدة ترحيلات كان يُقرأ كقائمة أرقام ترحيل، ولا شيء في التخزين يدل على الجهاز المالك لكل قرص. وكان تغيير اسم جهاز في المعالج يترك أقراصه على الاسم القديم.

• يحصل كل ضيف على مجلد باسمه، وتحمل الأقراص داخله اسم الضيف أيضاً: /pool/centos-7/centos-7-disk0.qcow2.
• يتبع الاسم اسم الوجهة، فتغيير اسم الجهاز في خطوة Mapping يغيّر اسم مجلده وكل قرص فيه.
• أما الوجهة التي لا تستطيع حفظ أقراص الضيف في مجلد فتبقى على الاسم المسطح السابق وتُرحّل تماماً كما كانت. لا شيء يحتاج إلى ترقية مسبقة، وتظهر تسمية المجلدات من تلقاء نفسها متى دعمتها الوجهة.

يُرفض في النموذج أي اقتران بين مصدر ووجهة لا يستطيع Condensa الترحيل بينهما. كان اختياره مسموحاً، ثم يفشل الترحيل في منتصف الطريق برسالة عن مشرف افتراضي لا صلة له بما اختير — فمصدر Awanio CEP موجّه إلى مضيف Vapor كان يبلّغ بأن أحد المزوّدين ليس مزوّد VMware.

• يذكر المعالج الآن الوجهات التي يبلغها المصدر فعلاً، قبل أن يبدأ أي شيء.
• مصدر Awanio CEP يبلغ وجهة Awanio CEP. وسائر المصادر تبلغ سائر الوجهات.

تُمنح الوجهة التي تنزّل قرصاً من Condensa سلطةَ التصديق الخاصة بـ Condensa. وحيث يقدّم Condensa شهادة خاصة، كان ذلك التنزيل يفشل بخطأ سلطة غير معروفة، ولم يكن من سبيل سوى تركيب الشهادة الجذرية يدوياً على كل مضيف وجهة.

• يرسل Condensa سلطته الخاصة مع طلب التنزيل. لا يُعدَّل شيء على مضيف الوجهة، ويبقى التحقق من الشهادة قائماً.

صار العنوان الذي تتصل عبره الوجهة بـ Condensa إعداداً في المزوّد. كان يُستنتج من الخادم. أما المواقع التي تبلغ فيها الوجهةُ Condensa على عنوان غير الذي يستعمله المشغّل فكانت تحتاج متغيّر بيئة على الخادم لتصحيحه.

• في نموذج مزوّد الوجهة حقل Disk stream address. وإن تُرك فارغاً بقي السلوك السابق كما هو.

صار الترحيل إلى موقع Awanio CEP ينقل من الضيف أكثر بكثير.

• تربط خطوة Mapping واجهاتِ المصدر بشبكات موقع الوجهة، لكل جهاز على حدة حين تختلف، عبر قائمة قابلة للبحث بدل الإدخال الحر.
• تُحفظ عناوين MAC حيث يحفظها الموقع، ولا تُطلب حيث يستعملها الموقع أصلاً. ويبلّغ الترحيل بالجواب الذي تلقّاه بدل افتراضه.
• يحتفظ الضيف باسم مضيفه ووسومه من المصدر، وبوصول الجذر، وبمفاتيح مضيف SSH.
• يمكن رفض شبكة الـ pod ونقل المسار الافتراضي إلى الشبكة المربوطة.
• والضيف الذي لم تكن لمصدره شبكة يحطّ كذلك. يقول الترحيل ذلك على كل وجهة بدل أن يمنعه.
• ومصدر CEP ذو الشهادة الخاصة يسمّي سلطته على مزوّد الوجهة، ويظهر فحص الشهادة في خطوة Review قبل البدء لا كإخفاق بعده.

تغييرات أصغر.

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

---

الإصدار 1.6.2 (أغسطس 2026)

لم تعد الترحيلات الدافئة تحذف لقطات لم تُنشئها. كانت حتى الآن تحذف كل لقطة على الجهاز المصدر، مرتين في كل تشغيل — وأول هذين الحذفين يقع قبل نسخ أي بيانات. فالمشغّل الذي أخذ لقطة كشبكة أمان قبل الترحيل كان يفقدها في الخطوة الأولى، ثم يبدأ النسخ بعد ذلك.

• لا يُحذف سوى نقاط التحقق المسماة condensa-warm-*. وما عداها يبقى كما هو تماماً.
• يذكر سجل الترحيل كم نقطة تحقق خاصة به أزال، ويصرّح بأن اللقطات الأخرى لم تُمس، فيصير الحد مرئياً لا مفترضاً.
• تبقى لقطتك سواء نجح الترحيل أم أخفق.

إن كنت تحتفظ بلقطة قبل الترحيل ثم وجدتها مفقودة بعده، فهذا هو السبب. ولا شيء يحتاج إلى ضبط — فالسلوك السابق لم يكن مما يُتاح إيقافه اختيارياً.

يُفحص تتبّع التغييرات على كل قرص قبل نقل أي بيانات. يسجّل vSphere تتبّع التغييرات في موضعين: واحد على الجهاز وآخر على كل قرص، ووحده الإعداد الخاص بالقرص يقرّر ما إذا كان القرص قادراً على الإبلاغ عن كتله المتغيّرة. وكان Condensa يقرأ إعداد الجهاز وحده، فقد يُبلّغ بأن التتبّع جاهز، ثم ينقل دقائق، ثم يخفق على قرص لم يكن قادراً على ذلك أصلاً.

• صار الفحص يجري في الثواني الأولى ويسمّي القرص بعنوانه على الناقل — scsi0:0 — لا برقم جهاز داخلي.
• وإن لم يكن القرص جاهزاً، تذكر الرسالة ما يحلّ ذلك عادةً: أوقف الجهاز وشغّله مرة واحدة ليسري الإعداد، أو رحّل ذلك الجهاز على البارد.
• أما الترحيلات الدافئة التي كانت تعمل فلا تتأثر.

شريط التحديث يعيد تحميل الصفحة من تلقاء نفسه. كان تثبيت تحديث من شريط لوحة التحكم يطلب منك إعادة التحميل بعد ثوانٍ. صار الآن ينتظر إعادة التشغيل ويعيد التحميل بنفسه، كما تفعل نافذة About أصلاً، ويقول ذلك صراحةً إن طالت إعادة التشغيل أكثر من المتوقع.

---

الإصدار 1.6.1 (أغسطس 2026)

تُبلّغ الترحيلات الدافئة الآن عن مستوى الاتساق الذي تحقّق فعلاً. طلبُ لقطة quiesced من vSphere دون أن يعود خطأ ليس كأن تكون اللقطة quiesced بالفعل: فالطلب ينجح على guest لا تعمل فيه VMware Tools، وتبقى اللقطة crash-consistent. صار Condensa يقرأ الراية من الـ hypervisor ويُبلّغ بما يجده.

• تُوصف النسخة بأنها application-consistent فقط عندما يذكر vSphere أن اللقطة كانت quiesced.
• صار crash-consistent يُذكر صراحةً بدل أن يمرّ في صمت، ويُسمّي السجل ما الذي يغيّره — تشغيل VMware Tools داخل الـ guest. كان الصمت يُقرأ سابقاً على أنه الإجابة الأفضل.
• وإن تعذّرت قراءة الراية أصلاً، قال السجل ذلك بدل أن ينحاز إلى أحد الجوابين.

يهمّ هذا أكثر ما يهمّ لقواعد البيانات ولكل ما يفترض نقطة زمنية متسقة. النسخة crash-consistent صالحة للاستعمال في الغالب؛ وما يترك المسؤول مندهشاً في أسوأ لحظة هو أن يُقال له إنها application-consistent وهي ليست كذلك.

لم تعد حالة التحديث تَعِد بما لا يستطيع الـ host تقديمه. التثبيت الذي لا يملك مكوّن المحدِّث صار يقول ذلك عند فحص التحديثات، بدل أن يقبل الطلب ثم ينتظر إعادة تشغيل لن يقوم بها أحد.

---

الإصدار 1.6.0 (أغسطس 2026)

يمكن الآن تثبيت (pin) هوية أي provider. الشهادات الموقّعة ذاتياً على عناوين IP مجرّدة وضعٌ اعتيادي في التثبيتات المحلية والمعزولة عن الإنترنت، لا مجرد اختصار مخبري — ومع ذلك كانت الطريقة الوحيدة للوصول إليها حتى الآن هي قبول كل شهادة، وهو ما يقبل شهادة المهاجم أيضاً. يمنحك التثبيت الخيار الذي كان غائباً بين هذين الطرفين: بلا حاجة إلى certificate authority، وبلا ثقة عمياء بأي شيء.

تثبيتات 1.3.1–1.5.1 تحتاج تحديثاً يدوياً مرة واحدة

في الإصدارات من 1.3.1 إلى 1.5.1 لا يُكمل زر Install update عمله: تظل النافذة في الانتظار وتعرض "the restart is taking longer than expected" أو خطأً في نظام الملفات. أما التثبيتات على 1.3.0 وما قبله فلا تتأثر.

رقِّ تلك التثبيتات يدوياً مرة واحدة. أوقف الخدمة، واستبدل الملف التنفيذي بالملف الوارد في هذا الإصدار، ثم شغّلها من جديد:

sudo systemctl stop condensa
curl -fLo /tmp/condensa.tar.gz <رابط التنزيل من بوابة المؤسسات>
sudo tar -xzf /tmp/condensa.tar.gz -C /usr/local/bin condensa
sudo systemctl start condensa

لا شيء يُعاد ضبطه: يبقى الـ providers وبيانات الاعتماد وسجل الترحيلات وكلا الـ secret دون تغيير. اعتباراً من 1.6.0 يعمل الزر من جديد، وتُثبِّت الإصدارات اللاحقة نفسها. الخطوات الكاملة في Updating.

الميزات الجديدة

• ثلاثة مستويات لأمان الاتصال، معروضة معاً. يستبدل كل نموذج provider مربع الاختيار المفرد «allow insecure connection» باختيار بين التحقق عبر certificate authority، وتثبيت هذا الـ endpoint، وتخطّي التحقق. تُعرض الثلاثة جنباً إلى جنب لأن القرار مقارنة في جوهره — فمربع اختيار واحد جعل «تخطّي التحقق» يبدو وكأنه الخيار المخصص للشهادات الموقّعة ذاتياً، وهذا الاعتقاد بالذات هو ما يترك الاتصال بلا حماية.
• تُعرض البصمة قبل أن تقبلها. عند اختيار ثبّت هذا الـ endpoint يقرأ النظام ما يقدّمه الخادم ويعرض بصمته وsubject وissuer ومدة الصلاحية والأسماء، فيُتخذ القرار بناءً على ما هو موجود فعلاً. قارنها بما يبلغ عنه الخادم نفسه قبل القبول — فقراءة البصمة من الاتصال الذي تنوي تثبيته وحده لا تثبت شيئاً إن كان ذلك الاتصال مُعترَضاً أصلاً.
• تجديد الشهادة لا يكسر التثبيت. يثبّت Condensa المفتاح العام للخادم لا شهادته، لذا فإن إعادة الإصدار — رقم تسلسلي جديد، صلاحية جديدة، عنوان إضافي في القائمة — تبقى الهوية نفسها. ولا ينشأ عدم تطابق إلا عند مفتاح جديد فعلاً، وعندها تعرض الرسالة البصمتين جنباً إلى جنب ليميّز الإنسان بين خادم أُعيد تنصيبه ومنتحِل.
• مفاتيح SSH host الخاصة بـ Proxmox تُثبَّت على حدة. تُقرأ بيانات القرص على الـ node عبر SSH لا عبر واجهة Proxmox البرمجية، لذا لا تقول شهادة الواجهة شيئاً عن ذلك الاتصال. يتضمن نموذج Proxmox حقل SSH host key خاصاً به، مع الأمر ssh-keygen -lf لتأكيد البصمة على الـ node نفسه.

الإصلاحات

• كان فحص مساحة التخزين المؤقت يقدّر بناءً على الحجم المعلن للوحدة التخزينية لا على ما تحتويه فعلاً، فاحتُسب قرص سعته 40 GiB لا يحوي سوى أقل من غيغابايت واحد على أنه 80 GiB ثم رُفض. وبالقياس على ضيف حقيقي، انخفض التقدير من 82.0 GiB إلى 3.9 GiB.
• لم يكن النقل المتوقف يبلّغ عن أي شيء يمكن للمشغّل التصرف بناءً عليه. صار الفشل يحمل السبب الذي أعطاه الخادم الهدف بدلاً من ترحيل توقف بلا تفسير.
• كان اسم قرص Proxmox المُجهَّز يُكتب مرتين في سجل الترحيل.
• صار الجهاز الافتراضي (appliance) يحتفظ بمفتاحه عند إعادة إصدار شهادته الخاصة. كان التجديد يغيّر هوية الجهاز، وهو تحديداً ما لا يحتمله التثبيت.
• كان الحقلان المتبقيان في معالج الترحيل — target organization وtarget project — يسلكان سلوكاً مختلفاً عن بقية الحقول: لا كتابة للتصفية ولا تنقّل بلوحة المفاتيح. صارا الآن متوافقين مع بقية النموذج.

عند الترقية

• لا تتغير الـ providers القائمة. الـ provider الذي كان يسمح بالاتصالات غير الآمنة يبقى كذلك؛ ولا شيء يبدأ برفض اتصال كان يقبله من قبل.
• التثبيت اختياري لكل provider، ويمكن إلغاؤه بمسح البصمة المثبّتة.
• في Proxmox، ما يزال الترحيل عبر SSH يتطلب تخطّي التحقق إلى أن تثبّت مفتاح SSH host الخاص بالـ node. وبمجرد تثبيته يزول هذا الشرط.

---

الإصدار 1.5.1 (أغسطس 2026)

صارت التثبيتات تعرف أين تجد تحديثاتها.

الإصلاحات

• كان التثبيت الذي لا مصدر تحديث مضبوطاً له يبلّغ بأن فحص التحديثات التلقائي معطّل، ويذكر اسم متغير بيئة لمن يفتح نافذة About. وكان ذلك ينطبق على معظم التثبيتات لا على قلة استثنائية: إذ كان الإعداد يُكتب عند إنشاء تثبيت جديد فقط، فلم يصل قط إلى موقع رُقّي في مكانه، ولا إلى خادم شُغّل يدوياً. صارت تغذية الإصدارات مضمّنة في الملف التنفيذي، فتُوجد دون الحاجة إلى ضبط أي شيء — ولا تعرض النافذة الفحص كمعطّل إلا إذا عطّله أحدهم عمداً.

عند الترقية

• ما يزال CONDENSA_UPDATE_URL له الأسبقية حيثما ضُبط، وضبطه على قيمة فارغة ما يزال يعطّل فحص التحديثات. على أي موقع يجب ألا يصل إلى الإنترنت أن يتأكد من أن تلك القيمة فارغة قبل الترقية: فالتثبيت الذي كان صامتاً لمجرد أن شيئاً لم يُضبط سيبدأ بفحص الإصدارات فور وصوله إلى 1.5.1.

---

الإصدار 1.5.0 (أغسطس 2026)

ينضم Awanio CEP إلى VMware وProxmox VE كمصدر للترحيل. تنتقل الأنظمة الضيفة من موقع Awanio CEP إلى آخر — لدمج المواقع، أو الانتقال إلى عنقودك الخاص، أو مغادرة مزوّد. لا يحتاج الموقع المصدر إلى أي تغيير: تكفي الـ endpoints الموجودة لديه أصلاً، وهذا ما يجعل المسار صالحاً تجاه منصة لا تديرها أنت. ابدأ من Awanio CEP كمصدر.

الميزات الجديدة

• ترحيل بارد من CEP إلى CEP. ينشر الموقع المصدر أقراص الضيف، ويتولى الـ importer الخاص بالعنقود الهدف جلبها مباشرة. ينظّم Condensa العملية دون أن ينقل بايتاً واحداً، فلا يحتاج هذا المسار إلى عنوان عام. يُوقَف الضيف العامل أولاً ويُترك متوقفاً؛ والنسخة المُرحَّلة هي ما تشغّله على الهدف.
• تُقاس نافذة التصدير من حجم العمل، وتُغلق بانتهائه. يطلب Condensa مدة مشتقة من إجمالي حجم الأقراص لا رقماً ثابتاً، ويرفض الضيف الأكبر من أن ينتهي ضمنها — قبل إيقاف أي شيء — ثم يغلق التصدير عند انتهاء الترحيل ويُبطل رمز التنزيل بدلاً من تركه فعّالاً حتى انقضاء المدة.
• تقدّم حقيقي، ونقل ينجو من الانقطاع. تُجلب الأقراص بصيغة تُبلغ عن حجمها، فيحسب الشريط نسبة صحيحة بدل الجمود عند الصفر، ويستأنف النقل المنقطع من حيث توقف بدلاً من إعادة القرص من بدايته.

الإصلاحات

• كان تقدّم الترحيل يُحتسب عند الانتهاء فقط، فيظل الشريط عند 0% طوال النقل ثم يقفز إلى النجاح. صار يُحدَّث مع كل استعلام، في قائمة الترحيلات وفي شاشة التفاصيل على حد سواء.
• حين يتعذر على النقل فعلاً الإبلاغ عن الإجمالي، صار الشريط يكتب size unknown ويتحرك ذهاباً وإياباً بدل ادعاء 0% مضلّل.
• تُدرج الأنظمة الضيفة بالاسم الذي يعرضه موقعها. كان الإدراج باسم المضيف يُظهر النسخة المُرحَّلة باسم أصلها — صفّان متطابقان لا يفرّق بينهما المشغّل إلا بحالة التشغيل.
• صار جرد الضيوف من موقع CEP يمرّ على الموقع كاملاً بدل التوقف عند العشرة الأوائل، ويجمع كل وحدة تخزين لا قرص الإقلاع وحده، ويقرأ العناوين بكل الأشكال التي يبلّغ بها الموقع، ويعود إلى الفهرس حين لا يسجّل الضيف نوع نظام تشغيل.

مسارات الترحيل المدعومة

المصدر	الهدف	Cold	Warm
VMware vSphere / ESXi	Awanio CEP	✓	✓ ¹
VMware vSphere / ESXi	Awanio Vapor (خادم واحد)	✓	✓ ²
VMware vSphere / ESXi	Awanio Cockpit (أسطول)	✓	✓ ²
Proxmox VE	Awanio Vapor (خادم واحد)	✓	✓
Proxmox VE	Awanio Cockpit (أسطول)	✓	✓
Proxmox VE	Awanio CEP	—	—
Awanio CEP	Awanio CEP	✓	— ³
Awanio CEP	Awanio Vapor أو Cockpit	—	—

¹ يحتاج الـ VM المصدر إلى تفعيل changed-block tracking (CBT) ووجود snapshot مسبقة. ² يتطلب تثبيت toolchain الخاص بـ VDDK على الخادم الهدف؛ كما يمنح VDDK الترحيلات الباردة مساراً مباشراً أسرع. ³ لا ينشر KubeVirt أقراص الضيف إلا وهو متوقف، ولا يوفّر changed-block tracking، لذا لا توجد نسخة دافئة من هذا المسار.

قبل الترقية

• يجب أن يعمل الهدف من نوع CEP ببنية منصّة تقبل أقراص الترحيل. على بنية أقدم يتوقف الترحيل عند أول قرص برسالة تذكر الـ endpoint — رقِّ الهدف لا المصدر.
• لا يحتاج المصدر من نوع CEP إلى شيء: لا وكيل ولا ضبط ولا إعادة تشغيل. وأمام مصدر أقدم ينتهي التصدير بنفسه بدل إغلاقه مبكراً، ويذكر السجل ذلك.
• يجب أن تصل عُقد العنقود الهدف إلى واجهة الموقع المصدر البرمجية — لا يكفي أن يصل Condensa إلى الموقعين، لأن العُقد هي التي تجلب القرص بنفسها.
• لا شيء يتغير في ترحيلات VMware أو Proxmox.

---

الإصدار 1.4.1 (أغسطس 2026)

صارت ترحيلات Proxmox تجري بالكامل داخل شبكة خاصة. يُحوَّل الترحيل البارد على عُقدة Proxmox نفسها ويُكتب مباشرة في تخزين الهدف، عبر القناة المصادَق عليها قصيرة العمر ذاتها التي يستخدمها الترحيل الدافئ. ينظّم Condensa العملية لكنه لم يعد ينقل القرص — ولم يعد يحتاج إلى عنوان عام لمصادر Proxmox إطلاقاً.

الميزات الجديدة

• تسير الترحيلات الباردة من العُقدة إلى الهدف مهما كانت صيغة وحدة التخزين. تُحوَّل وحدات qcow2 وraw على حد سواء على العُقدة ولا تحطّ إلا على الهدف — بلا مساحة مؤقتة على Condensa، ولا تعبر الكتل الفارغة الشبكة، فتنتقل الوحدة شبه الفارغة بسرعة وتصل رفيعة (thin). ويعمل الأمر ذاته مع خادم Vapor واحد ومع أسطول Cockpit.
• يمكن تثبيت نطاق منافذ الترحيل على الهدف. في Vapor 3.0.2 اضبطه من Host → System → Migration؛ فتصبح قاعدة الجدار الناري بين عُقدة Proxmox والخادم الهدف نطاقاً صغيراً واحداً بدل نطاق المنافذ العابرة كله. وقاعدة واحدة تغطي الآن الدافئ والبارد، لأن كليهما يستخدم القناة نفسها.
• المسار الشبكي المحجوب التفافة لا فشل. قبل أن تتحرك أي بيانات، تُسأل العُقدة إن كانت تصل إلى منفذ الهدف. فإن لم تصل ذكر السجل ذلك — مع العنوان والسبب المرجّح — واستمر الترحيل عبر مسار بديل يحمله Condensa. وذلك المسار البديل وحده هو ما يستخدم CONDENSA_PUBLIC_URL.

مسارات الترحيل المدعومة

المصدر	الهدف	Cold	Warm
VMware vSphere / ESXi	Awanio CEP	✓	✓ ¹
VMware vSphere / ESXi	Awanio Vapor (خادم واحد)	✓	✓ ²
VMware vSphere / ESXi	Awanio Cockpit (أسطول)	✓	✓ ²
Proxmox VE	Awanio Vapor (خادم واحد)	✓	✓
Proxmox VE	Awanio Cockpit (أسطول)	✓	✓
Proxmox VE	Awanio CEP	—	—

¹ يحتاج الـ VM المصدر إلى تفعيل changed-block tracking (CBT) ووجود snapshot مسبقة. ² يتطلب تثبيت toolchain الخاص بـ VDDK على الخادم الهدف؛ كما يمنح VDDK الترحيلات الباردة مساراً مباشراً أسرع.

قبل الترقية

• تحتاج ترحيلات Proxmox إلى Awanio Vapor 3.0.2 أو أحدث على الخادم الهدف، وإلى Awanio Cockpit 3.0.1 أو أحدث أمام الأسطول. رقِّ Vapor من صفحة التحديث الخاصة به قبل الترحيل.
• CONDENSA_PUBLIC_URL لم يعد مطلوباً لمصادر Proxmox. وما يزال يُستخدم في ترحيلات VMware الباردة بلا VDDK، وفي مسار Proxmox البديل الموصوف أعلاه.
• لا شيء يتغير في ترحيلات VMware.

---

الإصدار 1.4.0 (أغسطس 2026)

ينضم Proxmox VE إلى VMware كمصدر للترحيل. تنتقل الأنظمة الضيفة من Proxmox VE إلى خادم واحد يديره Awanio Vapor، أو إلى أسطول يديره Awanio Cockpit. ابدأ من Proxmox VE كمصدر.

الميزات الجديدة

• الترحيل من Proxmox VE، دافئاً أو بارداً. لا تختار الوضع بنفسك: الضيف العامل يُنسخ حياً ويُنقل بتوقف يُقاس بأجزاء من الثانية، والضيف المُطفأ يُنسخ مباشرة. ولا شيء يلزم تفعيله في جانب Proxmox — لا changed-block tracking ولا snapshot تؤخذ يدوياً. وبعد نجاح النقل يُترك الضيف المصدر متوقفاً مؤقتاً لا محذوفاً، فتتحقق من الـ VM الجديد قبل التخلي عن القديم.
• تصل كل واجهة شبكة، لا الأولى فحسب. يحتفظ الضيف متعدد الواجهات بها جميعاً، كل منها بعنوان MAC الذي كان لها في المصدر، وبطراز المحوّل حيثما استطاع الهدف توفيره — فتظل الإعدادات داخل الضيف التي ترتبط بعنوان MAC أو باسم الواجهة عاملة.
• وجّه كل شبكة مصدر إلى وجهة مختلفة. حين تقع الأنظمة الضيفة التي اخترتها على أكثر من جسر مصدر، يسأل المعالج عن الشبكة الهدف التي يصير إليها كل جسر. اربط اثنين منفصلين للحفاظ على الفصل الذي يتوقعه الضيف، أو اربط أحدهما بلا شيء لترك تلك الواجهات خارج الـ VM الجديد.
• أعد محاولة ترحيل فاشل في مكانه. أعد تشغيله من قائمة إجراءات الصف؛ وتبقى المحاولة السابقة في السجل.
• تدفقات الأقراص الحية مشفّرة، بلا إعداد. الترحيل الدافئ إلى أسطول Cockpit محميّ بـ TLS متبادل. يصدر الهدف الشهادات بنفسه، ويضع Condensa نصيب المصدر منها على عُقدة Proxmox طوال مدة الترحيل ثم يزيله بعده.

التحسينات

• الترحيل البارد لوحدة qcow2 لم يعد يحتاج مساحة مؤقتة إطلاقاً — إذ يتدفق من عُقدة Proxmox إلى الهدف أثناء القراءة. أما الوحدات المخزّنة بصيغة raw ‏(LVM-thin وZFS وCeph RBD) فما تزال تمرّ عبر Condensa، وصارت تُفحص قبل البدء: يُرفض مقدّماً أي ترحيل لن يتسع مع ذكر مقدار النقص، ولا يعمل إلا واحد في كل مرة، فتصطف الأنظمة الضيفة الكبيرة بدل ملء القرص معاً.
• الترحيل الدافئ إلى هدف على شبكة أخرى. اضبط CONDENSA_TARGET_WARM_ADDRESS حين يكون العنوان الذي تعرف به شبكةُ الإدارة الخادمَ الهدف غير العنوان الذي يستطيع المصدر الوصول إليه. انظر الترحيل الدافئ إلى أسطول Cockpit.
• تُبلَّغ المشكلات قبل العمل لا بعده. إن كان الهدف سيرفض التنزيل من هذا Condensa، أو كانت عُقدة Proxmox لا تصل إلى منفذ disk-stream على الهدف، قال الترحيل ذلك عند البداية — مع ذكر العنوان وما ينبغي تغييره — بدلاً من قوله بعد ساعة من النسخ. انظر ما الذي يجب أن يصل إلى ماذا.
• النقل الدافئ متسق على مستوى التطبيقات حيثما أمكن. مع تشغيل qemu-guest-agent داخل الضيف تُجمَّد أنظمة ملفاته للحظة النقل؛ وبدونه يكون النقل متسقاً على مستوى الانهيار، ويذكر السجل أيّ الحالتين وقعت.

إصلاح الأخطاء

• يعرض الترحيل المنتهي وقت انتهائه. كان الترحيل الناجح يعرض «Completed at: In Progress» بجوار شارته الخضراء، ولم يكن الملغى يسجّل وقت انتهاء إطلاقاً.
• لم يعد النقل الطويل يُخلط بالنقل المتعثّر. كان القرص الكبير الذي يُنسخ على ما يرام قد يُعدّ فاشلاً قبل دقائق من اكتماله.
• يعيد الترحيل الدافئ موارد الضيف المصدر إليه. كان الترحيل الدافئ الفاشل أو الملغى يترك جهاز كتل مسجّلاً داخل الضيف المصدر العامل، فيمنع كل محاولة لاحقة على القرص نفسه — ولا يزيله إلا إعادة تشغيل الضيف، وهو بالضبط ما وُجد الترحيل الدافئ لتفاديه.
• يحتفظ الـ VM المُرحَّل بناقل القرص الذي يتوقعه ضيفه، فيجد الضيف الذي لا تحمل صورة إقلاعه سوى مشغّل تخزين واحد قرصه الجذري.
• تذكر قائمة الترحيلات المصدر الحقيقي. كانت كل عملية ترحيل تُوسم بأنها قادمة من VMware أياً كان مصدرها الفعلي.

قبل الترقية

• يحتاج الترحيل الدافئ إلى أسطول Cockpit إلى Awanio Vapor 3.0.1 أو أحدث وAwanio Cockpit 3.0.1 أو أحدث في جانب الهدف.
• راجع ما الذي يجب أن يصل إلى ماذا قبل تخطيط قواعد الجدار الناري: فالجهاز الذي يحمل القرص يختلف باختلاف المصدر والهدف والأسلوب، وهو ما يحدد القاعدة التي تحتاجها.
• لا شيء في هذا الإصدار يغيّر سلوك تثبيت قائم. وCONDENSA_TARGET_WARM_ADDRESS اختياري وقيمته الافتراضية هي ما كان Condensa يفعله من قبل.

---

الإصدار 1.3.2 (يوليو 2026)

إصدار صيانة لا يغيّر شيئاً في طريقة سير الترحيلات: يصحّح مسار النشر المستخدَم في توصيل تحديثات Condensa.

---

الإصدار 1.3.1 (يوليو 2026)

إصدار موثوقية لترحيلات VMware للأنظمة الافتراضية الكبيرة ومتعددة الأقراص وطويلة التشغيل.

إصلاح الأخطاء

• أنظمة BIOS متعددة الأقراص تُقلع بلا تدخل يدوي: صار الـ VM المُرحَّل ذو الأقراص المتعددة (إقلاع legacy/BIOS) يُقلع مباشرة — إذ يوضع قرص نظام التشغيل أولاً تلقائياً، فلم تعد بحاجة إلى تصحيح ترتيب الإقلاع يدوياً بعد الترحيل.
• الترحيلات الطويلة تبقى متصلة: لم يعد الترحيل الذي يمتد طويلاً — أقراص كبيرة أو نقل دافئ — يفشل قرب نهايته بخطأ «session is not authenticated». فالاتصال بـ VMware يُبقى حياً ويُعاد إنشاؤه عند الحاجة، فيكتمل النقل النهائي بثبات. (لم تتأثر الترحيلات الباردة قط.)