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

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

---

الإصدار 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 يُبقى حياً ويُعاد إنشاؤه عند الحاجة، فيكتمل النقل النهائي بثبات. (لم تتأثر الترحيلات الباردة قط.)