तुमचा VPS Firecracker microVMs चालवू शकतो का?

तुमचा VPS Firecracker microVMs चालवू शकतो का?

तुमचा VPS Firecracker microVMs तेव्हाच चालवू शकतो, जेव्हा तो तुम्हाला /dev/kvm देतो. Firecracker हा KVM (kernel-based virtual machine) वर आधारित VMM (virtual machine monitor) आहे. KVM हा Linux मधील virtualisation layer आहे. KVM ला CPU कडून virtualisation instructions आवश्यक असतात. VPS मध्ये या instructions तेव्हाच उपलब्ध होतात, जेव्हा provider त्या तुमच्या guest पर्यंत pass through करतो. बहुतेक plans मध्ये ही सुविधा नसते.

म्हणून पहिला प्रश्न कोणते 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

microVMs होस्ट करू शकणारा सिस्टम असा प्रतिसाद देतो:

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

पहिली ओळ KVM device node दाखवते. त्याचा मालक kvm group आहे. दुसरी ओळ सांगते की हे machine स्वतः KVM अंतर्गत चालणारे guest आहे. VPS वर हे सामान्य आणि अपेक्षित आहे. तिसरी ओळ hardware virtualisation flag नोंदवणाऱ्या CPU cores ची संख्या दाखवते. Intel वर हा flag vmx आणि AMD वर svm असतो. Guest मध्ये ही संख्या शून्यापेक्षा जास्त असल्यास hypervisor तुमच्यासाठी nested virtualisation उपलब्ध करून देत आहे.

यानंतर तुमचा user device उघडू शकतो का ते तपासा. ही चाचणी 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 मध्ये जोडा आणि पुन्हा login करा.

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 count शून्यापेक्षा जास्त आहे. तुमच्याकडे hardware virtualisation आहे, त्यामुळे Firecracker चालेल. Sizing section कडे जा, कारण तुमची उर्वरित मर्यादा CPU features नसून memory आहे.

नोड नाही, systemd-detect-virt हे kvm किंवा qemu दाखवते आणि flag count 0 आहे. तुमचा VPS हा असा virtual machine आहे ज्याचा host virtualisation passthrough देत नाही. Guest मध्ये तुम्ही काहीही install केले तरी हे बदलत नाही, कारण हा flag hypervisor ने तुमच्यासाठी तयार केलेल्या virtual CPU चा गुणधर्म आहे. sudo modprobe kvm_intel हे modprobe: ERROR: could not insert 'kvm_intel': Operation not supported सह fail होते आणि sudo dmesg | grep -i kvm मध्ये hardware support उपलब्ध नसल्याची नोंद होते. Shared VPS plans मध्ये ही सर्वसाधारण स्थिती आहे. तुमच्या provider कडे plan nested virtualisation support करतो का ते विचारा. उत्तर no असल्यास, तुम्हाला वेगळी hosting हवी; वेगळी command नाही.

systemd-detect-virt हे lxc, lxc-libvirt किंवा openvz दाखवते. तुमचा plan container virtualisation वापरतो, त्यामुळे तुम्ही host चे kernel share करता. /dev/kvm कधीही दिसणार नाही, कारण module load करण्यासाठी तुमच्याकडे स्वतःचे kernel नाही. कोणतेही package हे ठीक करू शकत नाही.

Flags उपलब्ध आहेत आणि नोड नाही. Module load केलेले नाही. sudo modprobe kvm_intel चालवा (किंवा AMD वर kvm_amd) आणि पुन्हा ls -l /dev/kvm तपासा. नोड दिसल्यास, reboot नंतरही module load होण्यासाठी module चे नाव /etc/modules-load.d/kvm.conf मध्ये लिहा.

तुम्ही arm64 वर आहात. vmx आणि svm ही x86 नावे आहेत, त्यामुळे कार्यरत असो वा नसो, प्रत्येक arm64 machine वर grep count 0 असतो. arm64 वर device node तसेच read आणि write test यांच्या आधारे निर्णय घ्या.

एजंटच्या कामासाठी container ऐवजी microVM का?

Container हा तुमच्या kernel वर चालणारा process असतो. तो namespaces आणि cgroups यांच्या मदतीने वेगळा ठेवला जातो. kernel एकच असतो आणि तो तुमचाच असतो. त्यामुळे kernel स्तरावरील escape झाल्यास तो host पर्यंत पोहोचतो. microVM हार्डवेअर virtualisation boundary च्या आत स्वतःचा kernel boot करते. ती तुमच्या host च्या संपूर्ण system call surface ऐवजी लहान emulated device model शी संवाद साधते. Firecracker हे model जाणीवपूर्वक लहान ठेवते. हाच त्याचा मुख्य design आहे: emulated devices कमी असतील, तर बाहेर पडण्याचे मार्गही कमी असतात.

हा फरक coding agent साठी महत्त्वाचा आहे. कारण agent चालवणारा code आधी कोणीही तपासलेला नसतो. तो packages install करतो, build scripts चालवतो आणि काही अयशस्वी झाल्यास machine speed ने पुन्हा प्रयत्न करतो. स्वतंत्र kernel असल्यास चुकीच्या step मुळे delete करता येणाऱ्या machine चे नुकसान होते, इतर कशाचे नाही.

ही requirement थेट या mechanism मधून येते. Hardware isolation साठी hardware virtualisation आवश्यक असते. Hardware virtualisation हीच सुविधा तुमच्या VPS plan मध्ये उपलब्ध नसेल. Container ला यापैकी कशाचीही गरज नसते. म्हणूनच आतापर्यंत विकल्या गेलेल्या प्रत्येक plan वर containers चालतात.

म्हणून /dev/kvm उपलब्ध नसताना, container-आधारित coding agents साठी disposable VM हाच योग्य पर्याय राहतो. तो केवळ तडजोडीचा पर्याय नसून वास्तविक control आहे. ज्यावर तुम्हाला महत्त्वाची credentials ठेवायची नाहीत अशा host वरील throwaway container चुकीचे वर्तन केल्यावर snapshot मधून restore केल्यास प्रत्यक्षात होणाऱ्या बहुतेक समस्या थांबवता येतात. VPS वर coding agent चालवणे या अधिक साध्या setup बाबतही हेच लागू होते. Agent unattended पद्धतीने अनेक तास, तुम्ही review न केलेल्या code विरुद्ध चालणार असेल आणि host तुमच्या नियंत्रणात असेल, तेव्हा microVM वापरा.

microVM agent host ला काय आवश्यक आहे

Nehemiah हे या वर्गाचे सध्याचे उदाहरण आहे: Apache-2.0 परवान्याखालील daemon, जो मागणीनुसार AI ला एक वास्तविक Linux मशीन उपलब्ध करून देतो. प्रत्येक मशीनसाठी एक Firecracker microVM वापरला जातो. 10 August 2026 रोजी त्याच्या README मध्ये ही आवश्यकता स्पष्टपणे नमूद केली होती: "/dev/kvm असलेला Linux box". अधिक अचूकपणे, "/dev/kvm असलेला Ubuntu 24.04, x86_64 किंवा arm64 — bare-metal किंवा nested virtualization असलेला VM — ज्यामध्ये तुम्ही root-SSH करू शकता".

त्यानंतर यात बदल झाला. 11 August 2026 रोजी प्रकल्पाने self-serve setup docs काढून त्याऐवजी managed-host runbook दिले. 11 October 2026 रोजी तपासलेल्या README मध्ये ती आवश्यकता किंवा one-command install यापैकी काहीही नव्हते. आता hosts signed release artifacts मधून infra/latitude/provision.sh असलेल्या Latitude.sh bare-metal servers वर provision केले जातात. हा approved hosts साठी operator-run manual मार्ग आहे. त्यानंतर प्रकल्पाचे control plane त्या hosts ना enroll करते. Runbook मधील canary अजूनही usable /dev/kvm नसलेला host नाकारतो. त्यामुळे आवश्यकता नाहीशी झालेली नाही. ती bare metal कडे हलवली आहे.

हा बदल होईपर्यंत documented 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

सध्याच्या main वर हा command आता काहीही install करत नाही. infra/setup.sh ला descoped म्हणून चिन्हांकित केले आहे. तो पहिल्याच टप्प्यावर self-serve bootstrap यापुढे समर्थित नसल्याचा संदेश देऊन बंद होतो. त्यापूर्वी कोणताही preflight किंवा install टप्पा चालत नाही. README नुसार जुने self-serve installers आता managed runbook कडे निर्देश देऊन बंद होतात.

हा post ज्या commit वर प्रथम लिहिला गेला, त्या वेळी infra/setup.sh SSH द्वारे preflight चालवत असे आणि box चुकीचा असल्यास लवकर थांबत असे. त्याचे hardware संबंधी दोन नकार संदेश असे होते:

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

या post चा मुख्य मुद्दा पहिल्या string मध्ये आहे. तुम्ही ls -l /dev/kvm वापरून नुकताच विचारलेला तोच प्रश्न installer विचारत असे. बहुतेक VPS plans वर त्याला त्याच निराशाजनक उत्तर मिळत असे. Managed runbook मध्येही हा प्रश्न विचारला जातो.

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. Health check अयशस्वी झाल्यास /healthz didn't return ok छापले जात असे. SKIP_DESKTOP=1 desktop image वगळत असे. त्या तारखेच्या README नुसार ती image तयार होण्यासाठी सुमारे 8 minutes लागत. सध्याच्या main मधून यापैकी कोणतेही steps, messages किंवा switches चालत नाहीत. मात्र daemon default नुसार port 8080 वर अजूनही प्रतिसाद देतो.

तुम्ही ती command paste करण्यापूर्वी मर्यादा वाचा

नवीन host वर root SSH आवश्यक होते. Self-serve installer ने root म्हणून system packages, systemd units आणि network configuration लिहिले. तरीही तुम्ही तो unsupported commit चालवणार असाल, तर काहीही नसल्यापासून पुन्हा तयार करण्यास तुम्ही तयार असलेल्या machine कडे तो निर्देशित करा. आधीच तुमची site चालवत असलेल्या server वर तो चालवू नका.

Daemon default स्वरूपात 0.0.0.0:8080 वर bind होतो. त्या port पर्यंत पोहोचणारा कोणीही machines तयार करू शकतो आणि त्या machines host ला दिलेली model key वापरतात. Authentication आवश्यक करण्यासाठी NEHEMIAH_TOKEN सेट करा. किंवा NEHEMIAH_ADDR=127.0.0.1:8080 सेट करा. Daemon -addr 127.0.0.1:8080 देखील स्वीकारतो. त्यामुळे तो फक्त 127.0.0.1 वर bind होईल आणि ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP वापरून tunnel मार्फत तुम्ही त्याच्यापर्यंत पोहोचू शकाल. जुन्या installer's BIND_LOCALHOST=1 switch ला daemon वाचत नाही. त्यामुळे त्या script बाहेर त्याचा काहीही परिणाम होत नाही. Box वरील इतर कोणत्याही secret प्रमाणे या key चीही काळजीपूर्वक हाताळणी करा, जसे AI agents पासून secrets दूर ठेवणे.

प्रत्येक machine हा internet access असलेला आणि agents preinstalled असलेला computer आहे. README मध्ये guest च्या आत node, python आणि git सोबत claude, codex, cursor आणि pi दिले आहेत. Project नुसार guests egress firewall च्या मागे असतात आणि isolation boundary प्रत्यक्षात लागू असते. तरीही guest design नुसार network पर्यंत पोहोचतो, कारण package fetch करू न शकणारा coding agent निरुपयोगी असतो. Air gap आहे असे गृहीत धरण्याऐवजी त्यासाठी आधीच नियोजन करा.

Tagged release उपलब्ध नाही. 11 October 2026 पर्यंत repository मध्ये tags किंवा releases नाहीत. त्यामुळे main clone केल्यास त्या सकाळपर्यंत repository मध्ये आलेला code मिळतो. सध्या तो managed-only code आहे. Commit pin करा. Self-serve installer मागे घेण्याच्या आदल्या दिवशी, 10 August 2026 रोजी हा post लिहिला गेला तेव्हा खालील commit वापरला होता. त्यामुळे त्यातील infra/setup.sh अजूनही install होते. Project आता हा मार्ग support करत नाही. त्यामुळे तुमच्या server वर root म्हणून script चालवण्यापूर्वी ती वाचा:

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

Repository June 2026 च्या शेवटी तयार झाले आणि सहा आठवड्यांनी त्याचे self-serve install मागे घेण्यात आले. त्यामुळे supported path तुमच्या अपेक्षेनुसार बदलू शकतो, असे गृहीत धरून हे नवीन software समजा. यापेक्षा नवीन काहीही pull करण्यापूर्वी README आणि runbook पुन्हा वाचा. कारण तुम्ही मंजूर करत आहात ती machine ला root access आहे, library version bump नाही.

इन्स्टॉलरला दोष देण्यापूर्वी KVM कार्यरत आहे हे सिद्ध करा

सेटअप अयशस्वी झाल्यास आणि त्यामागचे कारण KVM आहे का हे जाणून घ्यायचे असल्यास, Firecracker स्वतंत्रपणे तपासा. खाली upstream download steps दिल्या आहेत:

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

आवृत्ती print होणे म्हणजे binary तुमच्या architecture शी जुळते आणि चालते, हे सिद्ध होते. मात्र KVM access सिद्ध होत नाही. त्यामुळे आधीच्या /dev/kvm वरील read आणि write test सोबत ही चाचणी करा. या दोन्ही चाचण्या hosting problem आणि packaging problem यांमध्ये फरक स्पष्ट करतात. त्यामुळे सुरुवातीपासून योग्य असलेल्या installer चे debugging करण्याचा अनावश्यक वेळ वाचतो.

अनेक microVMs साठी किती क्षमतेचा सर्व्हर आवश्यक आहे?

प्रत्येक microVM मध्ये प्रत्यक्ष guest kernel असतो आणि तुम्ही त्याला दिलेली memory मशीन सुरू असेपर्यंत राखून ठेवली जाते. त्यामुळे एकाच वेळी चालवायच्या मशीनची संख्या आणि प्रत्येक guest चा आकार यावरून host चे sizing करा. खालील आकडे मोजणीवर आधारित आहेत; ते प्रत्यक्ष मोजमाप नाहीत. Headless guest साठी 1 GB आणि browser असलेल्या desktop guest साठी 2 GB धरा. Host स्वतःसाठी, daemon साठी आणि image builds साठी 3 GB राखून ठेवतो. ही daemon ची default reserve आहे (NEHEMIAH_MEM_RESERVE_MB, 3072 MB). या reserve मध्ये वापर होईल अशा नवीन machine ला daemon boot करू देत नाही. त्यामुळे कमी क्षमतेचा host memory संपण्याऐवजी capacity limit वर पोहोचतो.

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 4
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 7
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 11
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 19
  }
]

एका वेळी एक headless machine चालवण्यासाठी सुमारे 4 GB आवश्यक आहेत. KVM उपलब्ध असलेला मध्यम क्षमतेचा VPS हे धारण करू शकतो. चार machines साठी 7 GB आवश्यक आहेत. 8 desktop machines चालवल्यास, एकही GB disk मोजण्यापूर्वीच त्याच मोजणीनुसार 19 GB आवश्यक ठरतात.

Disk ही अशी गरज आहे जिचे नियोजन अनेकदा केले जात नाही. Host वर guest kernel, base root filesystem, प्रत्येक guest flavour साठी एक image आणि चालू असलेल्या प्रत्येक machine साठी एक snapshot साठवला जातो. Browser असलेली desktop image सर्वांत मोठी असते. README मध्ये disk साठी कोणताही आकडा दिलेला नाही. त्यामुळे अंदाजावर अवलंबून राहण्याऐवजी पहिल्या build दरम्यान df -h / वर लक्ष ठेवा.

म्हणूनच "Firecracker कोणता VPS चालवतो?" या प्रश्नाचे प्रामाणिक उत्तर अनेकदा "वेगळ्या प्रकारचा machine" असे असते. Bare metal मध्ये hypervisor मधील अडथळ्याशिवाय CPU flags उपलब्ध असतात. हा VPS आणि dedicated server मधील निवडीचा trade-off आहे. काही providers virtual plans वर nested virtualisation उपलब्ध करून देतात. पैसे देण्यापूर्वी ते कसे पडताळायचे हे VPS वरील nested virtualisation मध्ये दिले आहे. Hardware आधीच तुमच्या मालकीचे असल्यास, plain VPS च्या तुलनेत Proxmox हा hypervisor च्या बाजूने विचारलेला तोच प्रश्न आहे.

Server हा खर्चाचा स्वस्त भाग आहे. Agent कडे दिलेली प्रत्येक machine चालू असेपर्यंत model tokens वापरते. त्यामुळे idle microVM memory खर्च करते, तर busy microVM memory सोबत API spend देखील वाढवते. 1 GB plan host धारण करू शकत नाही. Host धारण करू शकणारा plan असला तरी 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 पुढे देत नाही. 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 नाही. या परिस्थितीत nested virtualisation देणारा plan असलेला provider निवडा किंवा hypervisor तुमच्या नियंत्रणाखाली असलेली machine वापरा.

Coding agent ला sandbox करण्यासाठी container पुरेसा आहे का?

बहुतेक वेळा होय. Container तुमचा kernel share करतो. त्यामुळे kernel स्तरावरील escape host पर्यंत पोहोचू शकतो. परंतु महत्त्वाची credentials नसलेल्या machine वर disposable container वापरल्यास प्रत्यक्षातील बहुतेक धोका कमी होतो. Agent दीर्घकाळ unattended पद्धतीने unreviewed code वर चालत असेल आणि तुम्ही त्याला /dev/kvm असलेला host देऊ शकत असाल, तर microVM निवडा. हे शक्य नसल्यास, प्रत्येक task नंतर नष्ट करता येणारा container, कधीही boot न करता येणाऱ्या microVM पेक्षा अधिक उपयुक्त आहे.

MicroVM agent host साठी किती RAM आवश्यक आहे?

Guest च्या आकारापासून सुरुवात करा. 1 GB RAM असलेल्या एका headless guest साठी 3 GB host reserve धरल्यास एकूण सुमारे 4 GB आवश्यक आहे. प्रत्येकी 2 GB असलेल्या 8 desktop guests साठी सुमारे 19 GB आवश्यक आहे. Disk स्वतंत्र आहे आणि तिची गरज सहज कमी मोजली जाते, कारण host वर kernel, root filesystems, प्रत्येक guest flavour साठी एक image आणि प्रत्येक running machine साठी एक snapshot ठेवावा लागतो.