کیا آپ کا VPS Firecracker microVMs چلا سکتا ہے؟

کیا آپ کا VPS، Firecracker microVMs چلا سکتا ہے؟

آپ کا VPS، Firecracker microVMs صرف اسی صورت چلا سکتا ہے جب وہ آپ کو /dev/kvm فراہم کرے۔ Firecracker ایک VMM (virtual machine monitor) ہے جو KVM (kernel-based virtual machine) پر مبنی ہے۔ KVM، Linux کے اندر موجود virtualization layer ہے، اور اسے CPU کی virtualization instructions درکار ہوتی ہیں۔ VPS پر یہ instructions آپ کو صرف اس وقت ملتی ہیں جب provider انہیں آپ کے guest تک منتقل کرے، اور زیادہ تر plans ایسا نہیں کرتے۔

اس لیے پہلا سوال یہ نہیں ہے کہ کون سا microVM tool install کرنا ہے۔ پہلے یہ معلوم کریں کہ جس machine کے لیے آپ پہلے ہی ادائیگی کر رہے ہیں، کیا وہ کم از کم ایک microVM host کر سکتی ہے۔ یہ hosting سے متعلق سوال ہے، اور آپ تقریباً ایک منٹ میں اس کا جواب حاصل کر سکتے ہیں۔

انسٹالیشن سے پہلے /dev/kvm چیک کریں

VPS پر یہ تینوں commands خود چلائیں۔

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

جو مشین microVMs چلا سکتی ہو، اس کا output اس طرح ہوگا:

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

پہلی لائن KVM device node دکھاتی ہے، جس کی ملکیت kvm group کے پاس ہے۔ دوسری لائن بتاتی ہے کہ یہ مشین خود KVM کے تحت چلنے والی guest ہے۔ VPS پر یہ معمول کی اور متوقع بات ہے۔ تیسری لائن ان CPU cores کی تعداد دکھاتی ہے جو hardware virtualisation flag رپورٹ کرتے ہیں: Intel پر vmx اور AMD پر svm۔ guest کے اندر صفر سے زیادہ count کا مطلب ہے کہ hypervisor نے آپ کے لیے nested virtualisation فعال کی ہوئی ہے۔

اب چیک کریں کہ آپ کا user اس device کو کھول سکتا ہے۔ یہ وہ test ہے جو Firecracker کی اپنی getting started دستاویز میں دیا گیا ہے:

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

اگر node موجود ہو اور FAIL آئے تو مسئلہ permissions کا ہے، hardware کا نہیں۔ sudo setfacl -m u:${USER}:rw /dev/kvm کے ذریعے اپنے user کو access دیں، یا sudo usermod -aG kvm ${USER} کے ذریعے خود کو group میں شامل کریں اور دوبارہ login کریں۔

Ubuntu ایک ایسا check بھی فراہم کرتا ہے جو ان سب باتوں کا خلاصہ output کی دو lines میں دیتا ہے:

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

درست کام کرنے والا host پہلے INFO: /dev/kvm exists اور پھر KVM acceleration can be used print کرتا ہے۔ جو host کام نہیں کر سکتا، وہ پہلے INFO: Your CPU does not support KVM extensions اور پھر KVM acceleration can NOT be used print کرتا ہے۔ physical machine پر اس کے بجائے INFO: KVM (vmx) is disabled by your BIOS نظر آ سکتا ہے، جسے firmware میں درست کیا جا سکتا ہے۔ VPS پر یہ message کم ہی آتا ہے، کیونکہ آپ حقیقی firmware نہیں دیکھ رہے ہوتے۔

ہر /dev/kvm جواب کا کیا مطلب ہے؟

نوڈ موجود ہے اور flag count صفر سے زیادہ ہے۔ آپ کے پاس hardware virtualisation موجود ہے، اس لیے Firecracker چل جائے گا۔ sizing section پر جائیں، کیونکہ اب آپ کی باقی پابندی CPU features کے بجائے memory ہے۔

نوڈ موجود نہیں، systemd-detect-virt سے kvm یا qemu ظاہر ہوتا ہے، اور flag count 0 ہے۔ آپ کا VPS ایک virtual machine ہے، لیکن اس کا host virtualisation کو guest تک منتقل نہیں کر رہا۔ 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 plans میں یہ عام صورت ہے۔ provider سے پوچھیں کہ آیا plan nested virtualisation کو support کرتا ہے۔ اگر جواب نفی میں ہو تو آپ کو مختلف hosting درکار ہے، مختلف command نہیں۔

systemd-detect-virt سے lxc، lxc-libvirt یا openvz ظاہر ہوتا ہے۔ آپ کا plan container virtualisation استعمال کرتا ہے، اس لیے آپ host کا kernel share کرتے ہیں۔ /dev/kvm کبھی ظاہر نہیں ہوگا، کیونکہ آپ کے پاس اپنا kernel نہیں ہے جس میں module load کیا جا سکے۔ کوئی package بھی اس مسئلے کو حل نہیں کرتا۔

flags موجود ہیں لیکن نوڈ موجود نہیں۔ module صرف load نہیں ہوا۔ sudo modprobe kvm_intel چلائیں، یا AMD پر kvm_amd چلائیں، اور دوبارہ ls -l /dev/kvm چیک کریں۔ اگر نوڈ ظاہر ہو جائے تو module کا نام /etc/modules-load.d/kvm.conf میں درج کریں، تاکہ reboot کے بعد یہ دوبارہ load ہو جائے۔

آپ arm64 استعمال کر رہے ہیں۔ vmx اور svm x86 کے نام ہیں، اس لیے ہر arm64 machine پر grep count 0 ہوگا، خواہ machine کام کر رہی ہو یا نہیں۔ arm64 پر device node اور read اور write test پر اعتماد کریں۔

ایجنٹ کے کام کے لیے container کے بجائے microVM کیوں

container آپ کے kernel پر چلنے والا process ہوتا ہے جسے namespaces اور cgroups سے محدود کیا جاتا ہے۔ اس میں ایک ہی kernel ہوتا ہے، اور وہ آپ کا ہوتا ہے، اس لیے kernel-level escape host تک پہنچ جاتا ہے۔ microVM hardware virtualisation boundary کے اندر اپنا kernel boot کرتا ہے، اور آپ کے host کے مکمل system call surface کے بجائے ایک چھوٹے emulated device model سے رابطہ کرتا ہے۔ Firecracker اس model کو جان بوجھ کر محدود رکھتا ہے، اور یہی اس کا بنیادی design ہے: کم emulated devices کا مطلب باہر نکلنے کے کم راستے ہیں۔

یہ فرق coding agent کے لیے اہم ہے، کیونکہ agent جو code چلاتا ہے اسے پہلے کسی نے review نہیں کیا ہوتا۔ یہ packages install کرتا ہے، build scripts چلاتا ہے، اور failure کی صورت میں machine کی رفتار سے دوبارہ کوشش کرتا ہے۔ الگ kernel کا مطلب ہے کہ غلط step سے صرف وہ machine متاثر ہوتی ہے جسے آپ delete کر سکتے ہیں، اور کچھ نہیں۔

یہ requirement براہ راست mechanism سے نکلتی ہے۔ Hardware isolation کے لیے hardware virtualisation درکار ہے، اور hardware virtualisation عین وہ سہولت ہے جو آپ کے VPS plan میں موجود نہ ہو۔ container کو اس میں سے کسی چیز کی ضرورت نہیں ہوتی، اسی لیے containers ہر اس plan پر چلتے ہیں جو کبھی فروخت کیا گیا ہو۔

لہذا جب /dev/kvm موجود نہ ہو، تو container-based coding agents کے لیے disposable VM بدستور درست جواب رہتی ہے، اور یہ محض متبادل نہیں بلکہ حقیقی control ہے۔ ایسے host پر موجود throwaway container جس میں آپ کے لیے اہم کوئی credentials نہ ہوں، اور جو خراب رویے کی صورت میں snapshot سے بحال کیا جائے، ان بیشتر مسائل کو روک دیتا ہے جو عملی طور پر پیش آتے ہیں۔ یہی بات VPS پر coding agent چلانے کے زیادہ سادہ setup پر بھی لاگو ہوتی ہے۔ microVM اس وقت استعمال کریں جب agent unattended طور پر کئی گھنٹوں تک ایسے code پر چلنے والا ہو جس کا آپ نے review نہ کیا ہو، اور host آپ کے اختیار میں ہو۔

مائیکرو VM ایجنٹ میزبان سے کیا تقاضا کرتا ہے

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 checks چلاتا ہے اور 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 plans پر اسے وہی مایوس کن جواب ملتا ہے۔

preflight کے بعد یہ مکمل box install کرتا ہے: Firecracker اور اس کا jailer، Go toolchain، guest kernel اور root filesystem، Python guest image، browser والی optional desktop image، اور nehemiahd.service اور boring-net.service نام کی دو systemd units۔ اس کے بعد daemon port 8080 پر درخواستیں وصول کرتا ہے، اور health check ناکام ہونے پر /healthz didn't return ok دکھاتا ہے۔ SKIP_DESKTOP=1 desktop image کو چھوڑ دیتا ہے؛ README کے مطابق اسے build ہونے میں تقریباً 8 minutes لگتے ہیں۔

اس command کو paste کرنے سے پہلے احتیاطی نکات پڑھیں

اسے نئے host پر root SSH درکار ہے۔ Installer system packages، systemd units اور network configuration کو root کے طور پر لکھتا ہے۔ اسے ایسی machine پر چلائیں جسے آپ مکمل طور پر دوبارہ build کرنے کے لیے تیار ہوں، نہ کہ اس server پر جہاں آپ کی site پہلے سے چل رہی ہے۔

Daemon بطور default 0.0.0.0:8080 پر bind ہوتا ہے۔ جو بھی اس port تک پہنچ سکتا ہے، machines بنا سکتا ہے، اور وہ machines installer کو دی گئی model key استعمال کرتی ہیں۔ authentication لازم کرنے کے لیے NEHEMIAH_TOKEN set کریں، یا BIND_LOCALHOST=1 set کریں تاکہ daemon صرف 127.0.0.1 پر bind ہو اور آپ ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP کے ذریعے tunnel سے اس تک پہنچیں۔ اس key کو host پر موجود کسی بھی دوسرے secret کی طرح محفوظ رکھیں، جیسا کہ AI agents سے secrets باہر رکھنا۔

ہر machine internet access رکھنے والا computer ہے، جس میں agents پہلے سے installed ہیں۔ README میں guest کے اندر node، python اور git کے ساتھ claude، codex، cursor اور pi بھی درج ہیں۔ Project کے مطابق guests egress firewall کے پیچھے رہتے ہیں، اور isolation boundary حقیقی ہے۔ Guest پھر بھی design کے مطابق network تک پہنچتا ہے، کیونکہ ایسا coding agent جو package fetch نہ کر سکے، بے فائدہ ہے۔ Air gap فرض کرنے کے بجائے اسی بنیاد پر منصوبہ بنائیں۔

کوئی tagged release موجود نہیں ہے۔ 10 August 2026 تک repository میں کوئی tags نہیں ہیں، اس لیے main clone کرنے سے آپ کو وہی code ملے گا جو اسی صبح repository میں شامل ہوا ہو۔ کسی commit پر pin کریں، اور script کو server پر root کے طور پر چلنے سے پہلے پڑھیں:

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 کے کام کرنے کی تصدیق کریں

اگر setup ناکام ہو جائے اور آپ جاننا چاہیں کہ اس کی وجہ KVM ہے یا نہیں، تو Firecracker کو الگ سے test کریں۔ یہ upstream download کے مراحل ہیں:

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

چھاپا گیا version اس بات کی تصدیق کرتا ہے کہ binary آپ کے architecture سے مطابقت رکھتی ہے اور چلتی ہے۔ یہ KVM access کی تصدیق نہیں کرتا، اس لیے اسے پہلے بیان کردہ /dev/kvm پر read اور write test کے ساتھ استعمال کریں۔ دونوں tests مل کر hosting problem اور packaging problem میں فرق واضح کرتے ہیں۔ اس طرح آپ ایسے installer کو debug کرنے سے بچ جاتے ہیں جو ابتدا ہی سے درست تھا۔

متعدد microVMs کے لیے سرور کو کتنے وسائل درکار ہیں؟

ہر microVM میں ایک حقیقی guest kernel اور آپ کی مختص کردہ memory ہوتی ہے، اور جب تک machine چلتی رہتی ہے یہ memory مختص رہتی ہے۔ اس لیے host کا سائز guest کے سائز اور بیک وقت چلنے والی machines کی تعداد کے مطابق طے کریں۔ ذیل کے اعداد arithmetic پر مبنی ہیں، پیمائش پر نہیں۔ ایک headless guest کو 1 GB اور browser والے desktop guest کو 2 GB دیں۔ host اپنے لیے، daemon اور image builds کے لیے مزید 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 فراہم کرنے والا mid-size VPS اسے چلا سکتا ہے۔ چار machines کے لیے 6 GB درکار ہوں گے۔ 8 desktop machines چلانے کے لیے، ایک بھی GB disk شامل کیے بغیر، اسی arithmetic کے مطابق 18 GB درکار ہوں گے۔

Disk وہ وسیلہ ہے جسے عموماً کوئی منصوبہ بندی میں شامل نہیں کرتا۔ host ایک guest kernel، base root filesystem، ہر guest flavour کے لیے ایک image، اور ہر running machine کے لیے ایک snapshot محفوظ کرتا ہے۔ Browser والی desktop image سب سے بڑی ہوتی ہے۔ README میں disk کی مقدار نہیں دی گئی، اس لیے پہلے build کے دوران df -h / کو monitor کریں، اندازے پر بھروسا نہ کریں۔

اسی لیے اس سوال کا دیانت دار جواب کہ "کون سا VPS Firecracker چلا سکتا ہے؟" اکثر "مختلف درجے کی machine" ہوتا ہے۔ Bare metal آپ کو hypervisor کی مداخلت کے بغیر CPU flags فراہم کرتا ہے۔ یہی VPS اور dedicated server کے درمیان انتخاب کا بنیادی trade-off ہے۔ کچھ providers virtual plans پر nested virtualisation بھی فراہم کرتے ہیں، اور VPS پر nested virtualisation میں ادائیگی سے پہلے اس کی تصدیق کا طریقہ بتایا گیا ہے۔ اگر hardware پہلے ہی آپ کی ملکیت ہے تو Proxmox اور plain VPS کا تقابل اسی سوال کو hypervisor کے نقطۂ نظر سے بیان کرتا ہے۔

Server صرف کم لاگت والا حصہ ہے۔ آپ agent کو جو machine دیتے ہیں، وہ جب تک چلتی رہتی ہے model tokens استعمال کرتی ہے۔ اس لیے idle microVM بھی memory خرچ کرتی ہے، جبکہ مصروف microVM memory کے ساتھ API spend بھی بڑھاتی ہے۔ 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 گروپ کی ملکیت والا device node، اور zero سے زیادہ flag count، اس بات کی علامت ہے کہ Firecracker چل سکتا ہے۔ اگر node موجود نہ ہو اور count 0 ہو تو hypervisor virtualisation کو پاس نہیں کر رہا۔ cpu-checker package کا sudo kvm-ok، KVM acceleration can NOT be used کے ذریعے اس کی تصدیق کرتا ہے۔ arm64 پر count کو نظر انداز کریں، کیونکہ vmx اور svm x86 کے نام ہیں۔

کیا میں اپنے VPS کے اندر سے nested virtualisation فعال کر سکتا ہوں؟

نہیں۔ nested virtualisation host فعال کرتا ہے، یعنی hypervisor کے اپنے kernel module میں۔ یہ آپ تک فراہم کیے گئے virtual processor کے CPU flag کی صورت میں پہنچتی ہے۔ 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 شیئر کرتا ہے، اس لیے kernel level escape host تک پہنچ سکتا ہے۔ تاہم ایسی machine پر disposable container، جس میں کوئی قیمتی credential موجود نہ ہو، آپ کو درپیش زیادہ تر حقیقی خطرات ختم کر دیتا ہے۔ جب agent طویل وقت تک unattended حالت میں unreviewed code پر کام کرے اور آپ اسے /dev/kvm والا host دے سکیں، تو microVM منتخب کریں۔ جب یہ ممکن نہ ہو، تو ہر task کے بعد destroy کیا جانے والا container ایسے microVM سے بہتر ہے جسے آپ boot ہی نہ کر سکیں۔

microVM agent host کو کتنی RAM درکار ہوتی ہے؟

guest size سے آغاز کریں۔ 1 GB کا ایک headless guest، جس کے لیے host پر 2 GB reserve ہو، مجموعی طور پر تقریباً 3 GB چاہتا ہے۔ 2 GB کے حساب سے 8 desktop guests کے لیے تقریباً 18 GB درکار ہوتے ہیں۔ Disk الگ ہوتی ہے اور اس کی ضرورت کو کم سمجھنا آسان ہے، کیونکہ host میں kernel، root filesystems، ہر guest flavour کے لیے ایک image، اور ہر running machine کے لیے ایک snapshot محفوظ رہتا ہے۔