حلّ المجتمع

الانتقال من OpenMediaVault إلى ZimaOS: أبقِ جهاز OMV NAS متصلًا، وانقل الملفات بأمان، وافصل بين VT-x وVT-d

An October 2025 question from an OpenMediaVault user with a 256 GB boot drive, two 16 TB Btrfs-mirrored disks, 32 GB RAM and an Intel i5-2310 with VT-x but no VT-d. They asked whether apps or VMs would still work, whether the existing Btrfs mirror could be adopted, and whether a faster Ryzen ZimaOS box could simply use the OMV NAS as network storage. The thread contains no community reply, so current guidance comes from present ZimaOS documentation.

الإجابة الأكثر أمانًا على هذا الموضوع المصدر الذي لم يُجب عنه هي: لا تجعل مرآة OMV Btrfs الحالية أول ما تُجرّب عليه. أبقِ OpenMediaVault متصلًا بالإنترنت، وثبّت ZimaOS على النظام المنفصل الذي تريد تقييمه، واربط مشاركات OMV بوصفها وحدة تخزين عبر الشبكة المحلية، ثم انسخ البيانات على مراحل. وبذلك تحافظ على NAS القديم بوصفه خدمة عاملة ومسارًا للرجوع أثناء اختبار تطبيقات ZimaOS والمشاركات والنسخ الاحتياطية.

ويصبح سؤال وحدة المعالجة المركزية أسهل عند تقسيمه إلى طبقات. يُعد VT-x ميزة المحاكاة الافتراضية العتادية الأساسية للأجهزة الافتراضية العادية التي تعمل بمعمارية x86. أما VT-d/IOMMU فهو مهم أساسًا عندما تريد تمرير أجهزة PCIe فعلية مباشرةً إلى نظام ضيف. ولا تتطلب تطبيقات Docker ميزة VT-d. لذلك يمكن لمعالج i5-2310 من حقبة 2011 تشغيل الحاويات، وقد يشغّل أيضًا أجهزة افتراضية عادية، لكن تمرير الأجهزة والأداء العام للأجهزة الافتراضية يمثلان حدودًا منفصلة.

تطبيقات Docker لا تتطلب VT-d

تعمل تطبيقات متجر ZimaOS على هيئة حاويات Docker. وهي تشارك نواة النظام المضيف، ولا تحتاج إلى تمرير الأجهزة العتادية إليها لمجرد تشغيلها.

قد يكون معالج i5 القديم بطيئًا مع التطبيقات الأثقل، لكن عدم توفر VT-d لا يعني «عدم إمكانية تشغيل التطبيقات». ففي الحاويات العادية، تكون الذاكرة العشوائية وسرعة التخزين وحِمل المعالج الناتج عن التطبيق أكثر أهمية.

يمكن لـ VT-x دعم الأجهزة الافتراضية العادية

تفصل إرشادات التخطيط الحالية للأجهزة الافتراضية في ZimaOS بين المحاكاة الافتراضية الأساسية باستخدام KVM/QEMU وبين تمرير أجهزة PCIe/البطاقات الرسومية. وتحتاج أنظمة Linux/Windows الضيفة العادية إلى مسار محاكاة افتراضية يعمل، وإلى قدر كافٍ من موارد المعالج والذاكرة العشوائية على المضيف.

استخدم دليل أجهزة ZimaOS الافتراضية الحالي.

يُستخدم VT-d أساسًا لتمرير الأجهزة

إذا كان يجب على نظام ضيف التحكم مباشرةً في بطاقة رسومية أو وحدة تحكم HBA أو بطاقة شبكة PCIe أو جهاز مشابه، تصبح IOMMU/VT-d مهمة. وقد يعتمد تمرير أجهزة USB أيضًا على كيفية إتاحة المضيف لوحدات تحكم USB والأجهزة، وعلى واجهة ZVM المستخدمة.

لا تخلط بين «إقلاع الجهاز الافتراضي» و«إمكانية تخصيص كل جهاز فعلي للجهاز الافتراضي».

لا تفترض أن ZimaOS سيتبنى مرآة Btrfs الحالية في OMV في مكانها

كان لدى المستخدم المذكور في المصدر مرآة Btrfs مكوّنة من قرصين وتتم إدارتها بواسطة OMV. وتركّز وثائق التخزين الحالية في ZimaOS على إنشاء مساحات تخزين ZimaOS وإدارتها من خلال سير عمل التخزين الخاص به. ولا تقدم الوثائق ضمانًا عامًا بإمكانية استيراد تخطيطات RAID عشوائية موجودة مسبقًا في OMV Btrfs دون إتلافها.

إذا كانت محركات الأقراص بسعة 16 تيرابايت تحتوي على النسخة الوحيدة من البيانات المهمة، فاتركها تحت إدارة OMV إلى أن يتم نسخ البيانات احتياطيًا أو نسخها بشكل مستقل.

مسار الترحيل الرسمي الحالي هو النسخ عبر الشبكة

توصي إرشادات IceWhale الحالية للانتقال من NAS آخر بإبقاء NAS القديم متصلًا بالإنترنت، وإتاحة مشاركاته، وإضافته في ملفات ZimaOS بوصفه وحدة تخزين عبر الشبكة المحلية، ثم نسخ البيانات إلى مساحة تخزين ZimaOS الجديدة.

استخدم الاستراتيجية الحالية للانتقال من NAS آخر. وينطبق مفهوم الترحيل عبر SMB نفسه على مشاركات OMV.

يمكن لصندوق ZimaOS المزود بمعالج Ryzen أسرع استخدام OMV كوحدة تخزين عبر الشبكة

يُعد البديل المذكور في المصدر — تشغيل التطبيقات والأجهزة الافتراضية على صندوق Ryzen 9 مع استمرار OMV في تقديم الأقراص بسعة 16 تيرابايت — انتقالًا منطقيًا منخفض المخاطر. ويمكن لـ ZimaOS تركيب وحدات التخزين عبر الشبكة من خلال الملفات، بينما يظل NAS القديم صاحب سلطة التخزين.

سيكون الحد العملي هو اتصال 1GbE الموجود في صندوق OMV: أي معدل نقل عبر الشبكة من فئة الجيجابت تقريبًا، بغض النظر عن بطاقة الشبكة 2.5GbE الموجودة في صندوق Ryzen.

يُعد USB JBOD خيارًا، لكنه يغيّر نموذج الأعطال

يدعم ZimaOS حاليًا محركات أقراص USB بوصفها وحدات تخزين مستقلة، كما يدعمها في سير عمل التخزين المدعوم. ويمنح نقل محركات الأقراص الصلبة إلى حاوية USB ZimaOS تحكمًا مباشرًا بها، لكن جسر الحاوية وUSB سيصبحان جزءًا من مسار التخزين.

وبالنسبة إلى RAID المهم الذي يعمل باستمرار، قيّم تمرير SMART، وثبات تعداد الأجهزة، وتوفير الطاقة، والتبريد، وسلوك الجسر قبل نقل أقراص الإنتاج.

ترتيب أكثر أمانًا للترحيل

  1. انسخ بيانات OMV احتياطيًا؛
  2. ثبّت ZimaOS على عتاد أو وحدة تخزين منفصلة؛
  3. اختبر التطبيقات وجهازًا افتراضيًا ممثلًا واحدًا؛
  4. ركّب OMV بوصفه وحدة تخزين عبر الشبكة المحلية؛
  5. انسخ مجموعة فرعية وتحقق من الأذونات والمجاميع الاختبارية؛
  6. أنشئ مساحة تخزين ZimaOS النهائية بشكل منفصل؛
  7. انسخ البيانات المتبقية؛
  8. أبقِ OMV سليمًا إلى أن يتم التحقق من عمليات الاستعادة والنسخ الاحتياطية.

الأسئلة الشائعة حول الانتقال من OMV إلى ZimaOS

هل يعني عدم توفر VT-d عدم إمكانية تشغيل تطبيقات Docker؟

لا. لا تتطلب تطبيقات Docker ميزة VT-d.

هل يعني عدم توفر VT-d عدم إمكانية تشغيل الأجهزة الافتراضية العادية؟

ليس بالضرورة. يمكن لـ VT-x دعم الأجهزة الافتراضية العادية المُسرّعة عتاديًا؛ أما VT-d فهو متطلب أساسي لتمرير الأجهزة المتقدم.

هل ينبغي أن أسمح لـ ZimaOS بإعادة إنشاء RAID القديم الخاص بـ OMV قبل نسخ البيانات؟

ليس إذا كان يحتوي على النسخة الوحيدة من البيانات. أبقِ NAS القديم سليمًا، وابدأ بالترحيل عبر الشبكة.