আপনার VPS কি Firecracker microVM চালাতে পারবে?

আপনার VPS কি Firecracker microVM চালাতে পারে?

আপনার VPS-এ Firecracker microVM চালানো যাবে শুধু যদি এতে /dev/kvm থাকে। Firecracker হলো KVM (kernel-based virtual machine)-এর ওপর তৈরি একটি VMM (virtual machine monitor)। KVM হলো Linux-এর ভেতরের virtualisation layer, এবং এটি CPU থেকে virtualisation instruction প্রয়োজন। VPS-এ এই instruction তখনই পাওয়া যায়, যখন provider সেগুলো আপনার guest-এ pass through করে। অধিকাংশ plan-এ তা করা হয় না।

তাই প্রথম প্রশ্নটি কোন microVM tool install করবেন, তা নয়। আপনি যে machine-এর জন্য ইতিমধ্যে অর্থ দিচ্ছেন, সেটি আদৌ একটি microVM host করতে পারে কি না, সেটিই প্রথমে জানতে হবে। এটি hosting-এর বিষয়। প্রায় এক মিনিটেই এর উত্তর পাওয়া যায়।

কিছু ইনস্টল করার আগে /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 device node নির্দেশ করে, যার মালিক kvm group। দ্বিতীয় লাইনটি জানায় যে এই মেশিন নিজেই KVM-এর অধীনে চলা একটি guest। VPS-এ এটি স্বাভাবিক এবং প্রত্যাশিত। তৃতীয় লাইনটি এমন CPU core-এর সংখ্যা গণনা করে, যেগুলো hardware virtualisation flag প্রকাশ করে: Intel-এ vmx এবং AMD-এ svm। guest-এর ভেতরে শূন্যের বেশি সংখ্যা থাকলে বোঝা যায় যে hypervisor আপনাকে nested virtualisation ব্যবহারের সুযোগ দিচ্ছে।

এরপর যাচাই করুন, আপনার user device-টি open করতে পারে কি না। এটি Firecracker-এর নিজস্ব getting started document-এ ব্যবহৃত পরীক্ষা:

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

node বিদ্যমান থাকা অবস্থায় FAIL দেখা গেলে এটি hardware সমস্যা নয়, permission সমস্যা। sudo setfacl -m u:${USER}:rw /dev/kvm ব্যবহার করে নিজের user-কে access দিন, অথবা sudo usermod -aG kvm ${USER} ব্যবহার করে নিজেকে group-এ যোগ করুন এবং আবার log in করুন।

Ubuntu-তেও এমন একটি পরীক্ষা আছে, যা দুই লাইনের output-এ এসব তথ্যের সারাংশ দেখায়:

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

সঠিকভাবে কাজ করা host প্রথমে INFO: /dev/kvm exists এবং পরে KVM acceleration can be used দেখায়। কাজ না করা host প্রথমে INFO: Your CPU does not support KVM extensions এবং পরে KVM acceleration can NOT be used দেখায়। Physical machine-এ এর পরিবর্তে INFO: KVM (vmx) is disabled by your BIOS দেখা যেতে পারে। Firmware-এ পরিবর্তন করে এটি ঠিক করা যায়। VPS-এ এই বার্তা বিরল, কারণ সেখানে আপনি প্রকৃত firmware পরীক্ষা করছেন না।

প্রতিটি /dev/kvm ফলাফলের অর্থ কী?

নোডটি আছে এবং flag-এর সংখ্যা শূন্যের বেশি। আপনার hardware virtualisation আছে, তাই Firecracker চলবে। Sizing section-এ যান, কারণ আপনার বাকি সীমাবদ্ধতা CPU feature নয়, memory।

কোনো নোড নেই, systemd-detect-virt থেকে kvm বা qemu প্রিন্ট হয়, এবং flag-এর সংখ্যা 0। আপনার VPS একটি virtual machine, যার host virtualisation pass through করছে না। guest-এর ভেতরে কিছু install করলেও এটি পরিবর্তন হবে না, কারণ flag-টি hypervisor আপনার জন্য তৈরি করা virtual CPU-এর বৈশিষ্ট্য। sudo modprobe kvm_intel, modprobe: ERROR: could not insert 'kvm_intel': Operation not supported সহ ব্যর্থ হয়, এবং sudo dmesg | grep -i kvm অনুপস্থিত hardware support নথিভুক্ত করে। Shared VPS plan-এ এটি সাধারণ ঘটনা। nested virtualisation সমর্থিত কি না, provider-কে জিজ্ঞাসা করুন। উত্তর না হলে আপনার প্রয়োজন ভিন্ন hosting, ভিন্ন command নয়।

systemd-detect-virt থেকে lxc, lxc-libvirt বা openvz প্রিন্ট হয়। আপনার plan container virtualisation ব্যবহার করছে, তাই আপনি host-এর kernel ভাগ করে ব্যবহার করছেন। /dev/kvm কখনও দেখা যাবে না, কারণ module load করার জন্য আপনার নিজস্ব kernel নেই। কোনো package দিয়েও এটি ঠিক করা যাবে না।

Flag আছে, কিন্তু নোড নেই। Module-টি শুধু load করা হয়নি। sudo modprobe kvm_intel চালান (AMD হলে kvm_amd) এবং আবার ls -l /dev/kvm পরীক্ষা করুন। নোড দেখা গেলে module-এর নাম /etc/modules-load.d/kvm.conf-এ লিখুন, যাতে reboot-এর পরেও এটি ফিরে আসে।

আপনি arm64 ব্যবহার করছেন। vmx এবং svm হলো x86-এর নাম, তাই কাজ করছে বা করছে না—সব arm64 machine-এ grep-এর সংখ্যা 0 হবে। arm64-এ device node এবং read ও write test-এর ফলাফলের ওপর নির্ভর করুন।

কোডিং agent-এর কাজের জন্য container নয়, microVM কেন

একটি container হলো আপনার kernel-এ চলা একটি process, যাকে namespaces ও cgroups দিয়ে সীমাবদ্ধ রাখা হয়। এখানে একটি kernel থাকে এবং সেটি আপনার নিয়ন্ত্রণে, তাই kernel-level escape হলে তা host-এ পৌঁছে যায়। একটি microVM hardware virtualisation boundary-এর ভেতরে নিজস্ব kernel চালু করে এবং আপনার host-এর সম্পূর্ণ system call surface-এর পরিবর্তে একটি ছোট emulated device model-এর সঙ্গে যোগাযোগ করে। Firecracker এই model-টি ইচ্ছাকৃতভাবে ছোট রাখে। এটাই এর মূল নকশা: emulated device কম হলে বেরিয়ে আসার পথও কম থাকে।

এই পার্থক্য coding agent-এর ক্ষেত্রে গুরুত্বপূর্ণ, কারণ agent যে code চালায়, তা আগে কেউ পড়ে দেখেনি। এটি package install করে, build script চালায় এবং কোনো কিছু ব্যর্থ হলে machine-এর গতিতে আবার চেষ্টা করে। আলাদা kernel থাকলে কোনো ভুল পদক্ষেপ এমন একটি machine-এর ক্ষতি করে, যেটি আপনি মুছে ফেলতে পারেন। অন্য কিছুর ক্ষতি হয় না।

প্রয়োজনীয়তাটি সরাসরি এই mechanism থেকেই আসে। Hardware isolation-এর জন্য hardware virtualisation প্রয়োজন, আর আপনার VPS plan-এ hardware virtualisation নাও থাকতে পারে। Container-এর জন্য এর কোনোটিই দরকার হয় না। এ কারণেই অতীতে বিক্রি হওয়া প্রতিটি plan-এ container চালানো যায়।

তাই যখন /dev/kvm অনুপস্থিত থাকে, container-ভিত্তিক coding agent-এর জন্য disposable VM-ই সঠিক পছন্দ থাকে। এটি কেবল বিকল্প নয়, একটি বাস্তব control। এমন একটি host-এ রাখা throwaway container, যেখানে আপনার গুরুত্বপূর্ণ কোনো credential নেই, এবং সমস্যা হলে snapshot থেকে পুনরুদ্ধার করা হয়—বাস্তবে যে সমস্যাগুলো ঘটে, তার অধিকাংশই থামাতে পারে। VPS-এ coding agent চালানো-এর সরল setup-এর ক্ষেত্রেও একই কথা প্রযোজ্য। যখন কোনো agent unattended অবস্থায় ঘণ্টার পর ঘণ্টা এমন code-এর ওপর চলবে, যা আপনি review করেননি, এবং host-টি আপনার নিয়ন্ত্রণে থাকবে, তখন microVM ব্যবহার করুন।

একটি microVM agent host-এর প্রয়োজনীয়তা

Nehemiah এই শ্রেণির একটি বর্তমান উদাহরণ: এটি Apache-2.0 লাইসেন্সের একটি daemon, যা প্রয়োজন অনুযায়ী একটি AI-কে বাস্তব Linux machine দেয়—প্রতিটি machine-এর জন্য একটি Firecracker microVM। এর README-তে প্রয়োজনটি স্পষ্টভাবে লেখা আছে: "/dev/kvm-সহ একটি Linux box", এবং আরও নির্দিষ্টভাবে "Ubuntu 24.04, x86_64 বা arm64, যাতে /dev/kvm থাকে (bare-metal অথবা nested virtualization-সহ একটি VM), এবং যেখানে আপনি root-SSH করতে পারেন"।

নথিভুক্ত setup-এ ওই box লক্ষ্য করে একটি command চালানো হয়:

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-এর মাধ্যমে preflight পরীক্ষা চালায় এবং box-এর configuration সঠিক না হলে শুরুতেই থেমে যায়। hardware-সংক্রান্ত দুটি প্রত্যাখ্যানের বার্তা হলো:

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

প্রথম string-টিই এই পোস্টের মূল বিষয়। installer আপনি ls -l /dev/kvm দিয়ে যে প্রশ্নটি করেছেন, সেটিই করে। অধিকাংশ VPS plan-এ এটি একই হতাশাজনক উত্তর পায়।

preflight পেরিয়ে গেলে এটি পুরো box-এ install হয়: Firecracker এবং তার jailer, একটি Go toolchain, একটি guest kernel ও root filesystem, একটি Python guest image, browser-সহ একটি ঐচ্ছিক desktop image, এবং nehemiahd.service ও boring-net.service নামের দুটি systemd unit। এরপর daemon port 8080-এ সাড়া দেয়, আর health check ব্যর্থ হলে /healthz didn't return ok দেখায়। SKIP_DESKTOP=1 desktop image বাদ দেয়। README অনুযায়ী, এই image build হতে প্রায় 8 মিনিট সময় লাগে।

কমান্ডটি পেস্ট করার আগে সীমাবদ্ধতাগুলো পড়ুন

এটি নতুন host-এ root SSH চায়। Installer root হিসেবে system package, systemd unit এবং network configuration লেখে। এমন একটি machine নির্বাচন করুন যেটি প্রয়োজনে সম্পূর্ণ নতুন করে তৈরি করতে পারবেন। ইতিমধ্যে আপনার site চালায় এমন server-এ এটি চালাবেন না।

Daemon-টি ডিফল্টভাবে 0.0.0.0:8080-এ bind করে। যে কেউ ওই port-এ পৌঁছাতে পারলে machine তৈরি করতে পারে, এবং সেই machine-গুলো installer-কে দেওয়া model key ব্যবহার করে। Authentication বাধ্যতামূলক করতে NEHEMIAH_TOKEN সেট করুন। অথবা BIND_LOCALHOST=1 সেট করুন, যাতে daemon শুধু 127.0.0.1-এ bind করে এবং আপনি ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP দিয়ে tunnel-এর মাধ্যমে এতে পৌঁছান। Box-এ থাকা অন্য যেকোনো secret-এর মতো এই key-ও একই সতর্কতায় সংরক্ষণ করুন, যেমন AI agent-এর বাইরে secret রাখা।

প্রতিটি machine হলো Internet access-সহ একটি computer, যেখানে agent আগে থেকেই installed থাকে। README-তে guest-এর ভিতরে node, python এবং git-এর পাশাপাশি claude, codex, cursor এবং pi-এর তালিকা আছে। Project বলছে, guest-গুলো egress firewall-এর পেছনে থাকে এবং isolation boundary-টি বাস্তব। তবু guest নকশা অনুযায়ী network-এ পৌঁছাতে পারে, কারণ package fetch করতে না পারা coding agent কোনো কাজে আসে না। Air gap আছে ধরে নেওয়ার পরিবর্তে এই বিষয়টি মাথায় রেখে পরিকল্পনা করুন।

কোনো tagged release নেই। 10 August 2026 অনুযায়ী repository-তে কোনো tag নেই। তাই cloning করলে main থেকে ওই সকালে repository-তে যুক্ত হওয়া যেকোনো পরিবর্তন পাবেন। একটি commit-এ pin করুন এবং server-এ root হিসেবে script চালানোর আগে সেটি পড়ুন:

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

Repository-টি June 2026-এর শেষে তৈরি হয়েছে। তাই এটিকে নতুন software হিসেবে বিবেচনা করুন। প্রতিটি update pull করার পরে infra/setup.sh আবার পড়ুন। কারণ আপনি যে অনুমোদন দিচ্ছেন তা হলো একটি machine-এ root access, কোনো library version bump নয়।

ইনস্টলারকে দোষ দেওয়ার আগে 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

সংস্করণ দেখালে প্রমাণ হয় যে binary-টি আপনার architecture-এর সঙ্গে সামঞ্জস্যপূর্ণ এবং চালানো যাচ্ছে। এতে KVM access প্রমাণ হয় না। তাই এর সঙ্গে আগে উল্লেখ করা /dev/kvm-এ read ও write test চালান। এই দুই পরীক্ষার ফল একসঙ্গে দেখলে hosting সমস্যা এবং packaging সমস্যা আলাদা করা যায়। ফলে এমন installer debug করতে হয় না, যা আসলে সঠিকভাবেই কাজ করছিল।

একাধিক microVM চালাতে কতটা server প্রয়োজন?

প্রতিটি microVM-এ একটি পূর্ণ guest kernel এবং আপনি নির্ধারণ করা memory থাকে। মেশিন চালু থাকা পর্যন্ত সেই memory বরাদ্দ থাকে। তাই host-এর আকার নির্ধারণ করুন guest-এর আকার এবং একসঙ্গে চালাতে চাওয়া guest-এর সংখ্যা অনুযায়ী। নিচের হিসাবগুলো arithmetic, পরিমাপ করা মান নয়। headless guest-এর জন্য 1 GB এবং browser-সহ desktop guest-এর জন্য 2 GB ধরা হয়েছে। host নিজের জন্য, daemon-এর জন্য এবং image build-এর জন্য অতিরিক্ত 2 GB সংরক্ষণ করে।

[
  {
    "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 machine একসঙ্গে চালাতে প্রায় 3 GB প্রয়োজন। KVM দেওয়া হলে একটি মাঝারি আকারের VPS এটি চালাতে পারে। চারটি machine-এর জন্য 6 GB প্রয়োজন। 8-টি desktop machine চালালে, একটি GB disk-এর হিসাবও ধরার আগে একই arithmetic অনুযায়ী 18 GB প্রয়োজন হবে।

Disk হলো এমন খরচ, যার পরিকল্পনা অনেকেই করেন না। host-এ guest kernel, একটি base root filesystem, প্রতিটি guest flavour-এর জন্য একটি image এবং প্রতিটি চলমান machine-এর জন্য একটি snapshot সংরক্ষণ করা হয়। Browser-সহ desktop image-টিই বড়। README-তে disk-এর কোনো নির্দিষ্ট পরিমাণ দেওয়া নেই। তাই অনুমানের ওপর নির্ভর না করে প্রথম build-এর সময় df -h / monitor করুন।

এই কারণেই "কোন VPS Firecracker চালাতে পারে" প্রশ্নের সৎ উত্তর প্রায়ই হয় "ভিন্ন শ্রেণির machine"। Hypervisor-এর বাধা ছাড়া bare metal আপনাকে প্রয়োজনীয় CPU flag দেয়। এটিই VPS এবং dedicated server-এর মধ্যে নির্বাচন করার trade-off। কিছু provider virtual plan-এ nested virtualisation সমর্থন করে। অর্থপ্রদানের আগে এটি কীভাবে নিশ্চিত করবেন, তা VPS-এ nested virtualisation-এ ব্যাখ্যা করা হয়েছে। Hardware যদি ইতিমধ্যে আপনার থাকে, তাহলে plain VPS-এর পরিবর্তে Proxmox একই প্রশ্নকে hypervisor-এর দিক থেকে বিবেচনা করে।

Server খরচের সস্তা অংশও বটে। কোনো agent-কে দেওয়া প্রতিটি machine যতক্ষণ চলে, ততক্ষণ model token ব্যবহার করে। তাই idle microVM memory খরচ করে, আর ব্যস্ত microVM memory-এর পাশাপাশি API খরচও বাড়ায়। 1 GB plan host চালাতে পারবে না। যে plan host চালাতে পারে, সেটিও key-এর খরচ পরিশোধ করবে না।

FAQ

VPS Firecracker চালাতে পারবে কি না কীভাবে পরীক্ষা করব?

VPS-এ ls -l /dev/kvm, systemd-detect-virt এবং grep -cE '\b(vmx|svm)\b' /proc/cpuinfo চালান। kvm group-এর মালিকানাধীন একটি device node এবং শূন্যের বেশি flag count থাকলে Firecracker চালানো সম্ভব। node না থাকা এবং count 0 হলে hypervisor virtualisation pass through করছে না। cpu-checker package-এর sudo kvm-ok কমান্ডের KVM acceleration can NOT be used output এটি নিশ্চিত করে। arm64-এ count উপেক্ষা করুন, কারণ vmx এবং svm হলো x86 নাম।

আমার VPS-এর ভেতর থেকে nested virtualisation চালু করতে পারি কি?

না। Nested virtualisation host চালু করে, hypervisor-এর নিজস্ব kernel module-এ। এরপর এটি আপনাকে দেওয়া virtual processor-এর CPU flag হিসেবে guest-এ পৌঁছায়। Guest-এর ভেতরে sudo modprobe kvm_intel, modprobe: ERROR: could not insert 'kvm_intel': Operation not supported ফেরত দেয়, কারণ virtual CPU-তে ব্যবহারের জন্য VMX নেই। আপনার বিকল্প হলো এমন provider বেছে নেওয়া, যার plan-এ nested virtualisation আছে, অথবা এমন machine ব্যবহার করা যেখানে hypervisor আপনার নিয়ন্ত্রণে।

Coding agent-কে sandbox করার জন্য container কি যথেষ্ট?

অনেক ক্ষেত্রে যথেষ্ট। Container আপনার kernel share করে। তাই kernel-level escape হলে host-এ পৌঁছানো সম্ভব। তবে মূল্যবান credential না থাকা machine-এ disposable container ব্যবহার করলে বাস্তবে যে ঝুঁকির মুখোমুখি হন, তার বেশিরভাগই কমে যায়। Agent যখন দীর্ঘ সময় unattended অবস্থায় unreviewed code-এর ওপর কাজ করে এবং আপনি তাকে /dev/kvm-সহ একটি host দিতে পারেন, তখন microVM বেছে নিন। এটি সম্ভব না হলে, প্রতিটি task-এর পরে ধ্বংস করে দেওয়া যায় এমন container এমন microVM-এর চেয়ে ভালো, যেটি আপনি কখনও boot করাতে পারবেন না।

MicroVM agent host-এর কত RAM প্রয়োজন?

Guest-এর size দিয়ে হিসাব শুরু করুন। 1 GB-এর একটি headless guest এবং host-এর জন্য 2 GB reserve মিলিয়ে মোট প্রায় 3 GB প্রয়োজন। 2 GB করে 8 desktop guest-এর জন্য প্রায় 18 GB প্রয়োজন। Disk-এর হিসাব আলাদা এবং সহজেই কম ধরে ফেলা হয়। কারণ host-এ একটি kernel, root filesystem, প্রতিটি guest flavour-এর জন্য একটি image এবং প্রতিটি চলমান machine-এর জন্য একটি snapshot রাখতে হয়।