هل يستطيع VPS لديك تشغيل Firecracker؟

هل يستطيع VPS لديك تشغيل أجهزة Firecracker الافتراضية المصغّرة؟

لا يستطيع VPS لديك تشغيل أجهزة Firecracker الافتراضية المصغّرة إلا إذا أتاح لك /dev/kvm. إن Firecracker هو VMM (مراقب جهاز افتراضي) مبني على KVM (الجهاز الافتراضي المعتمد على النواة)، وهي طبقة المحاكاة الافتراضية داخل Linux. ويحتاج KVM إلى تعليمات المحاكاة الافتراضية من وحدة المعالجة المركزية. في VPS، تحصل على هذه التعليمات فقط عندما يمررها مزود الخدمة إلى الضيف لديك، ومعظم الخطط لا تفعل ذلك.

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

تحقق من /dev/kvm قبل تثبيت أي شيء

نفّذ هذه الأوامر الثلاثة على VPS نفسه.

ls -l /dev/kvm
systemd-detect-virt
grep -cE '\b(vmx|svm)\b' /proc/cpuinfo

يُظهر الخادم القادر على استضافة microVMs نتيجة مشابهة للتالي:

crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
16

السطر الأول هو عقدة جهاز KVM، وتملكها المجموعة kvm. يوضح السطر الثاني أن هذا الجهاز ضيف يعمل بدوره تحت KVM، وهذا أمر طبيعي ومتوقع على VPS. يحصي السطر الثالث أنوية CPU التي تُبلغ عن علامة المحاكاة الافتراضية العتادية، وهي vmx على Intel وsvm على AMD. يعني ظهور عدد أكبر من الصفر داخل ضيف أن hypervisor يتيح لك المحاكاة الافتراضية المتداخلة.

تحقق بعد ذلك من قدرة مستخدمك على فتح الجهاز. هذا هو الاختبار الوارد في وثيقة البدء الخاصة بـFirecracker:

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

يعني FAIL مع وجود العقدة أن المشكلة في الأذونات وليست في العتاد. امنح مستخدمك صلاحية الوصول باستخدام sudo setfacl -m u:${USER}:rw /dev/kvm، أو أضف نفسك إلى المجموعة باستخدام sudo usermod -aG kvm ${USER} ثم سجّل الدخول مرة أخرى.

تتضمن Ubuntu أيضاً اختباراً يلخّص كل ذلك في سطرين من المخرجات:

sudo apt update && sudo apt install -y cpu-checker msr-tools
sudo kvm-ok

يعرض المضيف الذي يعمل INFO: /dev/kvm exists ثم KVM acceleration can be used. أما المضيف الذي لا يستطيع التشغيل فيعرض INFO: Your CPU does not support KVM extensions ثم KVM acceleration can NOT be used. على جهاز فعلي قد ترى بدلاً من ذلك INFO: KVM (vmx) is disabled by your BIOS، ويمكن إصلاح ذلك من إعدادات firmware. أما على VPS فهذه الرسالة نادرة، لأنك لا تتعامل مع firmware فعلي.

ماذا تعني كل نتيجة من نتائج /dev/kvm؟

العقدة موجودة وعدد الرايات أكبر من الصفر. لديك افتراضية عتادية، ولذلك سيعمل Firecracker. انتقل إلى قسم تحديد الموارد، لأن القيد المتبقي لديك يتعلق بالذاكرة لا بميزات CPU.

لا توجد عقدة، وتطبع systemd-detect-virt القيمة kvm أو qemu، وعدد الرايات هو 0. جهاز VPS لديك هو جهاز افتراضي، والمضيف لا يمرر الافتراضية إلى الجهاز الضيف. لا يغيّر أي شيء تثبّته داخل الجهاز الضيف هذه النتيجة، لأن الراية خاصية في وحدة CPU الافتراضية التي أنشأها hypervisor لك. يفشل sudo modprobe kvm_intel مع modprobe: ERROR: could not insert 'kvm_intel': Operation not supported، ويسجّل sudo dmesg | grep -i kvm غياب الدعم العتادي. هذه هي الحالة الشائعة في خطط VPS المشتركة. اسأل المزوّد عما إذا كانت الخطة تدعم الافتراضية المتداخلة. إذا كانت الإجابة لا، فأنت تحتاج إلى استضافة مختلفة، لا إلى أمر مختلف.

يطبع systemd-detect-virt القيمة lxc أو lxc-libvirt أو openvz. تعتمد خطتك على افتراضية الحاويات، ولذلك تشارك نواة المضيف. لن يظهر /dev/kvm مطلقاً، لأنك لا تملك نواة خاصة بك لتحميل وحدة فيها. ولا يمكن لأي حزمة إصلاح ذلك.

الرايات موجودة، لكن العقدة غير موجودة. الوحدة غير محمّلة فقط. شغّل sudo modprobe kvm_intel (أو kvm_amd على AMD)، ثم تحقّق من ls -l /dev/kvm مرة أخرى. إذا ظهرت العقدة، فاكتب اسم الوحدة في /etc/modules-load.d/kvm.conf لكي تُحمّل مجدداً بعد إعادة التشغيل.

تستخدم arm64. إنّ vmx وsvm اسمان خاصان بـx86، ولذلك يكون عدد grep هو 0 على كل جهاز arm64، سواء كان يعمل أم لا. في arm64، اعتمد على عقدة الجهاز وعلى اختبار القراءة والكتابة بدلاً من ذلك.

لماذا نستخدم microVM بدلاً من حاوية لتنفيذ مهام الوكيل

الحاوية هي عملية تعمل على نواتك، وتُعزل باستخدام namespaces وcgroups. توجد نواة واحدة، وهي نواتك، لذلك يؤدي أي تجاوز على مستوى النواة إلى الوصول إلى المضيف. تُقلع microVM بنواة خاصة بها داخل حدود المحاكاة الافتراضية العتادية، وتتصل بنموذج أجهزة صغير مُحاكى بدلاً من الاتصال بواجهة system call الكاملة للمضيف. يحافظ Firecracker على صغر هذا النموذج عمداً، وهذا هو جوهر التصميم: كلما قل عدد الأجهزة المُحاكىة، قل عدد المسارات الممكنة للخروج.

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

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

لذلك، عندما تكون /dev/kvm مفقودة، تظل آلة VM مؤقتة لوكلاء البرمجة القائمة على الحاويات هي الإجابة الصحيحة، وهي وسيلة تحكم فعلية وليست بديلاً شكلياً. توقف الحاوية المؤقتة، على مضيف لا يحتوي على بيانات اعتماد تهمك، والمستعادة من snapshot كلما تصرفت بشكل غير صحيح، معظم المشكلات التي تحدث فعلياً. وينطبق الأمر نفسه على الإعداد الأبسط الوارد في تشغيل coding agent على VPS. استخدم microVM عندما سيعمل الوكيل دون إشراف لساعات على شفرة لم تراجعها، وعندما يكون المضيف ملكك ويمكنك تخصيصه لذلك.

ما الذي يطلبه مضيف وكيل microVM

يمثّل Nehemiah مثالاً حديثاً على هذه الفئة: خدمة Apache-2.0 تمنح نظام AI آلة Linux حقيقية عند الطلب، مع microVM واحدة من Firecracker لكل آلة. يذكر README المتطلب بوضوح: «صندوق Linux يحتوي على /dev/kvm»، وبصياغة أدق: «Ubuntu 24.04، بمعمارية x86_64 أو arm64، مع /dev/kvm (على عتاد فعلي أو على VM تدعم المحاكاة الافتراضية المتداخلة) ويمكنك الوصول إليها عبر SSH بصلاحيات root».

يتكوّن الإعداد الموثّق من أمر واحد موجّه إلى ذلك الصندوق:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

ينفّذ infra/setup.sh فحصاً أولياً عبر SSH، ويتوقف مبكراً عندما تكون مواصفات الصندوق غير مناسبة. وتظهر رسالتا رفض العتاد كما يلي:

/dev/kvm missing — the box needs hardware/nested virtualization
box arch is ${ARCH}; nehemiahd needs x86_64 or aarch64

هذه السلسلة الأولى هي جوهر هذا المنشور. يطرح المثبّت السؤال نفسه الذي طرحته للتو باستخدام ls -l /dev/kvm، وتحصل في معظم خطط VPS على الإجابة المخيبة نفسها.

بعد اجتياز الفحص الأولي، يصبح التثبيت على الصندوق بأكمله: Firecracker وjailer الخاص به، وسلسلة أدوات Go، ونواة الضيف ونظام الملفات الجذري، وصورة ضيف Python، وصورة سطح مكتب اختيارية تتضمن متصفحاً، ووحدتا systemd بالاسمين nehemiahd.service وboring-net.service. يستجيب البرنامج الخدمي بعد ذلك على المنفذ 8080، ويطبع فحص الصحة الفاشل /healthz didn't return ok. يتجاوز SKIP_DESKTOP=1 صورة سطح المكتب، ويذكر README أنّ إنشاءها يستغرق نحو 8 دقائق.

اقرأ التحذيرات قبل لصق ذلك الأمر

يتطلب وصول SSH إلى root على مضيف جديد. يكتب برنامج التثبيت حزم النظام ووحدات systemd وإعدادات الشبكة بامتيازات root. وجّه هذا الأمر إلى جهاز مستعد لإعادة بنائه من الصفر، وليس إلى الخادم الذي يشغّل موقعك حالياً.

يربط البرنامج الخفي المنفذ 0.0.0.0:8080 افتراضياً. يمكن لأي شخص يصل إلى ذلك المنفذ إنشاء أجهزة، وستستهلك هذه الأجهزة مفتاح النموذج الذي سلّمته إلى برنامج التثبيت. اضبط NEHEMIAH_TOKEN لفرض المصادقة، أو اضبط BIND_LOCALHOST=1 كي يربط البرنامج الخفي 127.0.0.1 فقط، ثم صِل إليه عبر نفق باستخدام ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. احمِ المفتاح بالقدر نفسه الذي تحمي به أي سر آخر على الخادم، كما هو موضح في إبقاء الأسرار خارج وكلاء الذكاء الاصطناعي.

كل جهاز هو حاسوب متصل بالإنترنت ومزوّد بوكلاء مثبتين مسبقاً. يدرج ملف README كلاً من claude وcodex وcursor وpi داخل البيئة الضيفة، إلى جانب node وpython وgit. يذكر المشروع أن البيئات الضيفة تقع خلف جدار ناري للاتصالات الصادرة، وأن حد العزل نفسه فعلي. ومع ذلك، تصل البيئة الضيفة إلى الشبكة حسب التصميم، لأن وكيل البرمجة الذي لا يستطيع جلب حزمة لا فائدة منه. خطط لهذا الأمر بدلاً من افتراض وجود عزل تام عن الشبكة.

لا يوجد إصدار موسوم. اعتباراً من 10 August 2026، لا يحتوي المستودع على أي وسوم، لذا فإن استنساخ main سيجلب إليك ما أضيف في ذلك الصباح. ثبّت العملية على commit محدد، واقرأ البرنامج النصي قبل تشغيله بامتيازات root على خادمك:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.sh

أُنشئ المستودع في نهاية June 2026، لذا تعامل معه باعتباره برنامجاً حديثاً. اقرأ infra/setup.sh مرة أخرى بعد كل تحديث تجلبه، لأن ما توافق عليه هو وصول root إلى جهاز، وليس مجرد تحديث لإصدار مكتبة.

أثبت عمل KVM قبل أن تلقي اللوم على برنامج التثبيت

إذا فشل الإعداد وأردت معرفة ما إذا كان KVM هو السبب، فاختبر Firecracker بشكل مستقل. هذه هي خطوات التنزيل من المصدر الأساسي:

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz | tar -xz
./release-${latest}-${ARCH}/firecracker-${latest}-${ARCH} --version

يثبت عرض الإصدار أن الملف التنفيذي يطابق بنية نظامك ويعمل. لكنه لا يثبت إمكانية الوصول إلى KVM، لذلك نفّذ معه اختبار القراءة والكتابة على /dev/kvm المذكور سابقاً. يفصل الاختباران معاً بين مشكلة في الاستضافة ومشكلة في الحزمة، ويجنبانك تصحيح أخطاء برنامج تثبيت كان يعمل كما ينبغي طوال الوقت.

كم يحتاج الخادم إلى عدة microVMs؟

تحتوي كل microVM على نواة ضيف فعلية، إضافة إلى الذاكرة التي تخصصها لها. وتظل هذه الذاكرة محجوزة طوال فترة تشغيل الآلة. لذلك، حدّد حجم المضيف وفق حجم الضيف وعدد الضيوف الذين تريد تشغيلهم في الوقت نفسه. الأرقام أدناه حسابية وليست قياسات. يحتاج الضيف من دون واجهة رسومية إلى 1 GB، بينما يحتاج ضيف سطح المكتب الذي يشغّل متصفحاً إلى 2 GB. ويحتفظ المضيف باحتياطي ثابت قدره 2 GB لنفسه وللـdaemon وعمليات إنشاء الصور.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 3
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 6
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 10
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 18
  }
]

تحتاج آلة واحدة من دون واجهة رسومية في كل مرة إلى نحو 3 GB، ويمكن لـVPS متوسط الحجم استيعابها عندما يتيح لك KVM. وتحتاج أربع آلات إلى 6 GB. شغّل 8 من آلات سطح المكتب، وستحتاج وفق الحساب نفسه إلى 18 GB قبل احتساب أي مساحة تخزين.

مساحة القرص هي العنصر الذي لا يخطط له أحد. يخزّن المضيف نواة ضيف، ونظام ملفات root أساسياً، وصورة واحدة لكل نوع من الضيوف، ولقطة لكل آلة قيد التشغيل. وتكون صورة سطح المكتب التي تتضمن متصفحاً هي الأكبر. لا يذكر README مقداراً لمساحة القرص، لذلك راقب df -h / أثناء عملية الإنشاء الأولى بدلاً من الاعتماد على التخمين.

لهذا تكون الإجابة الصادقة عن سؤال «أي VPS يشغّل Firecracker؟» هي غالباً «فئة مختلفة من الآلات». يتيح لك bare metal استخدام أعلام CPU من دون وجود hypervisor في الطريق، وهذا هو المقابل في الاختيار بين VPS وخادم مخصص. يتيح بعض المزوّدين أيضاً المحاكاة الافتراضية المتداخلة في الخطط الافتراضية، ويشرح المحاكاة الافتراضية المتداخلة على VPS كيفية تأكيد توفرها قبل الدفع. وإذا كانت العتاد ملكاً لك مسبقاً، فإن Proxmox مقارنةً بـVPS عادي يطرح السؤال نفسه من جهة الـhypervisor.

الخادم هو أيضاً النصف الأرخص من التكلفة. تستهلك كل آلة تسلّمها إلى agent رموزاً من النموذج طوال فترة تشغيلها، لذلك تستهلك microVM الخاملة الذاكرة، بينما تستهلك microVM المشغولة الذاكرة وتكاليف API. لا يمكن لخطة بسعة 1 GB استيعاب المضيف. وحتى الخطة القادرة على استيعاب المضيف لن تغطي تكلفة المفتاح.

FAQ

كيف أتحقق من قدرة VPS لدي على تشغيل Firecracker؟

شغّل ls -l /dev/kvm وsystemd-detect-virt وgrep -cE '\b(vmx|svm)\b' /proc/cpuinfo على VPS. يعني وجود عقدة جهاز مملوكة للمجموعة kvm، مع عدد أعلام أكبر من الصفر، أن Firecracker يمكنه العمل. ويعني غياب العقدة مع عدد يساوي 0 أن الـhypervisor لا يمرر إمكانات المحاكاة الافتراضية، ويؤكد sudo kvm-ok من الحزمة cpu-checker ذلك باستخدام KVM acceleration can NOT be used. في arm64، تجاهل العدد، لأن vmx وsvm اسمان خاصان بمعمارية x86.

هل يمكنني تفعيل المحاكاة الافتراضية المتداخلة من داخل VPS؟

لا. يفعّل المضيف المحاكاة الافتراضية المتداخلة في وحدة kernel الخاصة بالـhypervisor، وتصل إليك على شكل CPU flag في المعالج الافتراضي المخصص لك. داخل الـguest، يعرض sudo modprobe kvm_intel القيمة modprobe: ERROR: could not insert 'kvm_intel': Operation not supported لأن وحدة المعالجة الافتراضية لا تحتوي على VMX يمكن استخدامها. خياراتك هي اختيار مزود يوفّر المحاكاة الافتراضية المتداخلة ضمن الخطة، أو استخدام آلة تملك فيها الـhypervisor.

هل تكفي الحاوية لعزل coding agent؟

غالباً نعم. تشارك الحاوية kernel الخاص بك، لذلك يصل escape على مستوى kernel إلى المضيف، لكن استخدام حاوية مؤقتة على آلة لا تحتوي على بيانات اعتماد مهمة يزيل معظم المخاطر الفعلية التي تواجهها. اختر microVM عندما يعمل agent دون إشراف لفترات طويلة على code لم تراجعه، وعندما تستطيع منحه مضيفاً يحتوي على /dev/kvm. وعندما يتعذر ذلك، تكون الحاوية التي تدمرها بعد كل مهمة أفضل من microVM لا تتمكن من تشغيلها أبداً.

ما مقدار RAM الذي يحتاج إليه مضيف agent يعمل داخل microVM؟

ابدأ من حجم الـguest. يحتاج guest واحد بلا واجهة رسومية بحجم 1 GB، مع حجز 2 GB للمضيف، إلى نحو 3 GB إجمالاً، بينما يحتاج 8 من guests بواجهة رسومية، بحجم 2 GB لكل منها، إلى نحو 18 GB. مساحة القرص منفصلة ويسهل تقديرها بأقل من المطلوب، لأن المضيف يحتفظ بـkernel، وأنظمة ملفات root، وصورة واحدة لكل نكهة guest، وsnapshot لكل آلة قيد التشغيل.