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

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

---

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