آیا VPS من از Firecracker microVM پشتیبانی می‌کند؟

آیا VPS شما می‌تواند Firecracker microVM را اجرا کند؟

VPS شما تنها در صورتی می‌تواند Firecracker microVM را اجرا کند که دسترسی به /dev/kvm را برای شما فراهم کرده باشد. Firecracker یک VMM (مانیتور ماشین مجازی) است که بر پایه KVM (ماشین مجازی مبتنی بر هسته) ساخته شده است؛ KVM لایه مجازی‌سازی درون لینوکس است و برای کارکرد، به دستورالعمل‌های مجازی‌سازی از سمت CPU نیاز دارد. در یک VPS، شما تنها زمانی این دستورالعمل‌ها را دریافت می‌کنید که ارائه‌دهنده، آن‌ها را به سیستم‌عامل مهمان شما منتقل (pass-through) کند، که اکثر پلن‌های میزبانی چنین قابلیتی ندارند.

بنابراین، پرسش نخست این نیست که کدام ابزار microVM را نصب کنید. پرسش اصلی این است که آیا ماشینی که بابت آن هزینه پرداخت می‌کنید، اصلاً توانایی میزبانی آن را دارد یا خیر. این یک مسئله مربوط به میزبانی است و شما می‌توانید در کمتر از یک دقیقه پاسخ آن را بیابید.

بررسی /dev/kvm پیش از نصب هر چیزی

این سه دستور را مستقیماً روی VPS اجرا کنید.

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

پاسخ سیستمی که قابلیت میزبانی microVMها را دارد، به این صورت است:

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

خط اول، گره دستگاه KVM است که مالکیت آن در اختیار گروه kvm قرار دارد. خط دوم نشان می‌دهد که این ماشین خود یک guest است که تحت KVM اجرا می‌شود؛ این وضعیت در VPSها عادی و مورد انتظار است. خط سوم تعداد هسته‌های CPU را می‌شمارد که پرچم مجازی‌سازی سخت‌افزاری، یعنی vmx در اینتل و svm در AMD را گزارش می‌کنند. تعداد بیش از صفر در داخل یک guest به این معناست که هایپروایزر، قابلیت nested virtualisation را برای شما فعال کرده است.

سپس بررسی کنید که کاربر شما اجازه باز کردن این دستگاه را دارد یا خیر. این همان تست مستندات شروع به کار 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} خود را به گروه مربوطه اضافه کرده و دوباره وارد سیستم شوید.

اوبونتو همچنین ابزاری برای بررسی دارد که تمام این موارد را در دو خط خلاصه می‌کند:

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 چیست؟

گره وجود دارد و تعداد پرچم‌ها (flag count) بیشتر از صفر است. شما مجازی‌سازی سخت‌افزاری دارید، بنابراین Firecracker اجرا خواهد شد. به بخش تعیین اندازه بروید، زیرا محدودیت باقی‌مانده شما حافظه است، نه ویژگی‌های CPU.

گره وجود ندارد، systemd-detect-virt مقدار kvm یا qemu را چاپ می‌کند و تعداد پرچم‌ها 0 است. VPS شما یک ماشین مجازی است که میزبان آن، قابلیت مجازی‌سازی را عبور نمی‌دهد. هیچ چیزی که داخل guest نصب کنید این وضعیت را تغییر نمی‌دهد، زیرا این پرچم ویژگیِ CPU مجازی است که هایپروایزر برای شما ساخته است. sudo modprobe kvm_intel با خطای modprobe: ERROR: could not insert 'kvm_intel': Operation not supported شکست می‌خورد و sudo dmesg | grep -i kvm عدم پشتیبانی سخت‌افزاری را ثبت می‌کند. این وضعیت در پلن‌های VPS اشتراکی رایج است. از ارائه‌دهنده بپرسید که آیا پلن شما از مجازی‌سازی تو در تو (nested virtualisation) پشتیبانی می‌کند یا خیر. اگر پاسخ منفی است، شما به میزبانی متفاوتی نیاز دارید، نه دستور متفاوتی.

systemd-detect-virt مقدار lxc، lxc-libvirt یا openvz را چاپ می‌کند. پلن شما مجازی‌سازی کانتینری است، بنابراین شما از هسته (kernel) میزبان به‌صورت اشتراکی استفاده می‌کنید. /dev/kvm هرگز ظاهر نخواهد شد، زیرا شما هسته اختصاصی خود را ندارید که بتوانید ماژولی را در آن بارگذاری کنید. هیچ بسته‌ای نیز این مشکل را حل نمی‌کند.

پرچم‌ها وجود دارند اما گره موجود نیست. ماژول به‌سادگی بارگذاری نشده است. دستور sudo modprobe kvm_intel (یا kvm_amd در پردازنده‌های AMD) را اجرا کنید و دوباره ls -l /dev/kvm را بررسی کنید. اگر گره ظاهر شد، نام ماژول را در /etc/modules-load.d/kvm.conf بنویسید تا پس از راه‌اندازی مجدد (reboot) دوباره بارگذاری شود.

شما روی arm64 هستید. vmx و svm نام‌های x86 هستند، بنابراین تعداد grep در هر دستگاه arm64، چه فعال باشد و چه نباشد، 0 است. در arm64، به گره دستگاه و تست خواندن و نوشتن اعتماد کنید.

چرا برای کار عامل (agent) از microVM استفاده کنیم و نه container

یک container در واقع فرآیندی روی هسته (kernel) سیستم‌عامل شماست که با استفاده از namespaces و cgroups محدود شده است. در این حالت تنها یک هسته وجود دارد که همان هسته سیستم شماست؛ بنابراین، فرار از سطح هسته منجر به دسترسی به میزبان (host) می‌شود. یک microVM هسته اختصاصی خود را در یک مرز مجازی‌سازی سخت‌افزاری بوت می‌کند و به جای تعامل با کل سطح فراخوانی‌های سیستم (system call surface) میزبان، با یک مدل دستگاه شبیه‌سازی‌شده کوچک ارتباط برقرار می‌کند. Firecracker این مدل را عمداً کوچک نگه می‌دارد و کل فلسفه طراحی آن همین است: دستگاه‌های شبیه‌سازی‌شده کمتر، به معنای راه‌های خروجی کمتر است.

این تفاوت برای یک عامل کدنویسی اهمیت دارد، زیرا کدی که عامل اجرا می‌کند کدی است که پیش از آن توسط کسی بازبینی نشده است. این عامل بسته‌ها را نصب می‌کند، اسکریپت‌های build را اجرا می‌کند و هنگام بروز خطا، با سرعت ماشین دوباره تلاش می‌کند. داشتن یک هسته مجزا به این معناست که یک گام اشتباه فقط به ماشینی آسیب می‌زند که می‌توانید آن را حذف کنید و هیچ چیز دیگری تحت تأثیر قرار نمی‌گیرد.

این الزام مستقیماً از مکانیزم آن ناشی می‌شود. ایزولاسیون سخت‌افزاری به مجازی‌سازی سخت‌افزاری نیاز دارد و مجازی‌سازی سخت‌افزاری دقیقاً همان چیزی است که ممکن است در طرح VPS شما ارائه نشود. یک container به هیچ‌کدام از این‌ها نیاز ندارد و به همین دلیل است که containerها روی هر طرحی که تا به حال فروخته شده، اجرا می‌شوند.

بنابراین وقتی /dev/kvm در دسترس نیست، استفاده از ماشین مجازی یک‌بارمصرف برای عامل‌های کدنویسی مبتنی بر container همچنان پاسخ مناسب است و این یک کنترل واقعی محسوب می‌شود، نه یک جایگزین ضعیف. یک container یک‌بارمصرف، روی میزبانی که هیچ اعتبارنامه (credential) مهمی در آن نگهداری نمی‌شود و هر زمان که دچار اختلال شد از روی یک snapshot بازیابی می‌شود، جلوی اکثر مشکلاتی که واقعاً رخ می‌دهند را می‌گیرد. همین موضوع در مورد تنظیمات ساده‌تر در اجرای عامل کدنویسی روی VPS نیز صادق است. زمانی به سراغ microVM بروید که عامل قرار است ساعت‌ها بدون نظارت، روی کدی که بازبینی نکرده‌اید اجرا شود و زمانی که میزبان کاملاً در اختیار شماست.

آنچه یک عامل microVM از میزبان می‌خواهد

Nehemiah نمونه‌ای کنونی از این کلاس است: یک daemon با مجوز Apache-2.0 که در صورت تقاضا، یک ماشین لینوکس واقعی را در اختیار یک هوش مصنوعی قرار می‌دهد؛ به ازای هر ماشین، یک microVM از نوع Firecracker. فایل README آن، پیش‌نیاز را بدون هیچ ابهامی بیان می‌کند: «یک جعبه لینوکسی با /dev/kvm»، و دقیق‌تر اینکه: «Ubuntu 24.04، معماری x86_64 یا arm64، همراه با /dev/kvm (سخت‌افزار bare-metal یا یک VM با قابلیت nested virtualization) که بتوانید با دسترسی root از طریق SSH به آن وارد شوید».

پیکربندی مستندشده، تنها یک دستور است که باید روی آن جعبه اجرا شود:

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 یک بررسی پیش‌نیاز (preflight) از طریق 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، همان پاسخ ناامیدکننده را دریافت می‌کند.

پس از عبور از مرحله preflight، نصب روی کل سیستم انجام می‌شود: Firecracker و jailer آن، یک toolchain زبان Go، یک هسته (kernel) مهمان و فایل‌سیستم ریشه، یک image مهمان پایتون، یک image اختیاری دسکتاپ به همراه مرورگر، و دو unit از نوع systemd با نام‌های nehemiahd.service و boring-net.service. سپس daemon روی پورت 8080 پاسخ می‌دهد و در صورت شکست در بررسی سلامت (health check)، پیام /healthz didn't return ok چاپ می‌شود. گزینه SKIP_DESKTOP=1 از ساخت image دسکتاپ صرف‌نظر می‌کند؛ فرآیندی که طبق گفتهٔ README، حدود 8 دقیقه زمان می‌برد.

پیش از اجرای دستور، هشدارها را بخوانید

این ابزار به دسترسی root از طریق SSH روی یک میزبان تازه نیاز دارد. نصب‌کننده، بسته‌های سیستمی، unitهای systemd و پیکربندی شبکه را با دسترسی root می‌نویسد. آن را روی ماشینی اجرا کنید که آمادگی دارید از صفر بازسازی کنید، نه روی سروری که هم‌اکنون سایت شما را میزبانی می‌کند.

این daemon به‌صورت پیش‌فرض روی 0.0.0.0:8080 گوش می‌دهد. هر کسی که به این پورت دسترسی داشته باشد می‌تواند ماشین ایجاد کند و آن ماشین‌ها از کلید مدلی که به نصب‌کننده داده‌اید استفاده خواهند کرد. برای اجبار به احراز هویت، NEHEMIAH_TOKEN را تنظیم کنید یا BIND_LOCALHOST=1 را به‌گونه‌ای قرار دهید که daemon فقط روی 127.0.0.1 گوش دهد و شما از طریق تونل با ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP به آن دسترسی پیدا کنید. این کلید به همان مراقبتی نیاز دارد که سایر اسرار موجود در سیستم نیاز دارند، همان‌طور که در محافظت از اسرار در برابر عوامل هوش مصنوعی آمده است.

هر ماشین، یک کامپیوتر با دسترسی به اینترنت و عوامل (agents) از پیش نصب‌شده است. فایل README مواردی مانند claude، codex، cursor و pi را در داخل guest، در کنار node، python و git فهرست کرده است. این پروژه بیان می‌کند که guestها پشت یک فایروال خروجی (egress firewall) قرار دارند و مرز جداسازی واقعی است. با این حال، guest طبق طراحی به شبکه دسترسی دارد، زیرا یک عامل کدنویسی که نتواند بسته‌ای را دریافت کند، بی‌فایده است. به‌جای فرض کردن وجود air gap، برای این موضوع برنامه‌ریزی کنید.

هیچ نسخه تگ‌شده‌ای (tagged release) وجود ندارد. تا تاریخ 10 August 2026، مخزن هیچ تگی ندارد، بنابراین clone کردن main هر چیزی که همان صبح به مخزن اضافه شده باشد را دریافت می‌کند. روی یک commit خاص قفل کنید (pin) و پیش از اجرای اسکریپت با دسترسی 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 را به‌صورت مستقل تست کنید. این‌ها مراحل دریافت نسخه upstream هستند:

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 که پیش‌تر ذکر شد، ترکیب کنید. این دو تست در کنار هم، مشکل میزبانی (hosting) را از مشکل بسته‌بندی (packaging) جدا می‌کنند؛ این کار شما را از عیب‌یابی بیهوده نصب‌کننده‌ای که از ابتدا به‌درستی کار می‌کرده است، نجات می‌دهد.

چند microVM به چه میزان منابع سرور نیاز دارند؟

هر microVM شامل یک هسته سیستم‌عامل مهمان واقعی به همراه حافظه‌ای است که به آن اختصاص می‌دهید؛ این حافظه تا زمانی که ماشین در حال اجراست، اشغال می‌ماند. بنابراین، ظرفیت میزبان (host) را بر اساس مجموع حافظه مهمان‌ها و تعداد آن‌ها به‌طور هم‌زمان محاسبه کنید. ارقام زیر محاسباتی هستند و نه اندازه‌گیری‌های عملی. یک مهمان بدون رابط گرافیکی (headless) به 1 GB و یک مهمان دسکتاپ با مرورگر به 2 GB حافظه نیاز دارد. میزبان نیز 2 GB حافظه ثابت برای خود، daemon و ساخت imageها کنار می‌گذارد.

[
  {
    "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
  }
]

یک ماشین headless در هر لحظه به حدود 3 GB حافظه نیاز دارد که یک VPS میان‌رده با قابلیت KVM می‌تواند آن را تأمین کند. چهار ماشین از این نوع به 6 GB نیاز دارند. اگر 8 ماشین دسکتاپ را اجرا کنید، همین محاسبات عدد 18 GB را پیش از محاسبه حتی یک گیگابایت فضای دیسک نشان می‌دهد.

دیسک همان منبعی است که هیچ‌کس برای آن برنامه‌ریزی نمی‌کند. میزبان باید هسته مهمان، فایل‌سیستم ریشه پایه، یک image برای هر نوع مهمان، یک snapshot برای هر ماشین در حال اجرا و image دسکتاپ (که به دلیل وجود مرورگر حجیم است) را ذخیره کند. فایل README هیچ عددی برای دیسک ارائه نمی‌دهد، بنابراین به‌جای تکیه بر حدس و گمان، در طول اولین build، خروجی df -h / را زیر نظر بگیرید.

به همین دلیل است که پاسخ صادقانه به این پرسش که «کدام VPS برای اجرای Firecracker مناسب است»، اغلب «کلاس متفاوتی از ماشین» است. سخت‌افزار Bare metal پرچم‌های CPU را بدون دخالت hypervisor در اختیار شما قرار می‌دهد، که این موضوع نقطه تعادل در انتخاب بین VPS و سرور اختصاصی است. برخی ارائه‌دهندگان، قابلیت nested virtualisation را در پلن‌های مجازی ارائه می‌دهند و nested virtualisation روی VPS توضیح می‌دهد که چگونه پیش از پرداخت هزینه، این قابلیت را تأیید کنید. اگر سخت‌افزار متعلق به خودتان است، مقایسه Proxmox با یک VPS معمولی همان پرسش از دیدگاه hypervisor است.

سرور بخش ارزان ماجراست. هر ماشینی که به یک agent می‌سپارید، تا زمانی که فعال است، توکن‌های مدل مصرف می‌کند؛ بنابراین یک microVM بیکار فقط هزینه حافظه دارد، اما یک microVM فعال هم هزینه حافظه و هم هزینه API را به شما تحمیل می‌کند. یک پلن 1 GB نمی‌تواند میزبان را میزبانی کند. پلنی هم که بتواند میزبان را اجرا کند، لزوماً هزینه کلید API را پوشش نمی‌دهد.

FAQ

چگونه بررسی کنم که آیا VPS من می‌تواند Firecracker را اجرا کند؟

دستورات ls -l /dev/kvm، systemd-detect-virt و grep -cE '\b(vmx|svm)\b' /proc/cpuinfo را روی VPS اجرا کنید. وجود یک device node که متعلق به گروه kvm باشد، به همراه تعداد flag بیشتر از صفر، به این معنی است که Firecracker می‌تواند اجرا شود. نبود این node و تعداد 0 به این معنی است که hypervisor قابلیت مجازی‌سازی را عبور نمی‌دهد و sudo kvm-ok از بسته cpu-checker این موضوع را با KVM acceleration can NOT be used تأیید می‌کند. در معماری arm64، از این تعداد صرف‌نظر کنید، زیرا vmx و svm نام‌های مربوط به x86 هستند.

آیا می‌توانم مجازی‌سازی تو در تو (nested virtualisation) را از داخل VPS خود فعال کنم؟

خیر. مجازی‌سازی تو در تو توسط میزبان (host) و در ماژول هستهٔ خودِ hypervisor فعال می‌شود و به صورت یک CPU flag روی پردازندهٔ مجازی که به شما اختصاص داده شده، در دسترس قرار می‌گیرد. در داخل guest، دستور sudo modprobe kvm_intel مقدار modprobe: ERROR: could not insert 'kvm_intel': Operation not supported را برمی‌گرداند زیرا CPU مجازی هیچ VMX برای استفاده ندارد. گزینه‌های شما استفاده از ارائه‌دهنده‌ای است که مجازی‌سازی تو در تو را در طرح خود ارائه می‌دهد، یا استفاده از ماشینی که در آن شما مالک hypervisor هستید.

آیا یک container برای sandbox کردن یک coding agent کافی است؟

اغلب بله. یک container هستهٔ سیستم‌عامل شما را به اشتراک می‌گذارد، بنابراین فرار از سطح هسته (kernel level escape) به میزبان می‌رسد، اما یک container یک‌بارمصرف روی ماشینی که هیچ اعتبارنامهٔ ارزشمندی ندارد، بیشتر ریسک‌های واقعی شما را از بین می‌برد. زمانی که یک agent برای مدت طولانی بدون نظارت روی کدهای بررسی‌نشده اجرا می‌شود و می‌توانید میزبانی با /dev/kvm به آن اختصاص دهید، از microVM استفاده کنید. زمانی که نمی‌توانید، یک container که پس از هر وظیفه آن را نابود می‌کنید، بهتر از یک microVM است که هرگز موفق به بوت کردن آن نمی‌شوید.

یک میزبان agent از نوع microVM به چه مقدار RAM نیاز دارد؟

از اندازهٔ guest شروع کنید. یک guest بدون رابط گرافیکی با 1 GB رم و 2 GB رزرو برای میزبان، در مجموع به حدود 3 GB رم نیاز دارد و 8 عدد guest دسکتاپ با 2 GB رم برای هر کدام، به حدود 18 GB رم نیاز خواهند داشت. فضای دیسک جداگانه است و دست‌کم گرفتن آن آسان است، زیرا میزبان یک هسته، فایل‌سیستم‌های root، یک image برای هر نوع guest و یک snapshot برای هر ماشین در حال اجرا را نگه می‌دارد.