द्वारे Matt Connor 2026-08-10 · अपडेटेड 2026-08-13

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

Q: माझे VPS Firecracker चालवू शकते का हे कसे तपासावे?

VPS वर ls -l /dev/kvm, systemd-detect-virt आणि grep -cE '\b(vmx|svm)\b' /proc/cpuinfo चालवा. kvm गटाच्या मालकीचा 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 नावे आहेत.

Firecracker साठी /dev/kvm आवश्यक आहे, पण बहुतेक VPS plans ते उपलब्ध करून देत नाहीत. तीन कमांडमध्ये तपासा, निकाल समजा आणि ते नसल्यास पुढे काय करायचे ते जाणून घ्या.

तुमचा 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 वापरा.

मायक्रोVM एजंट होस्टला आवश्यक असणाऱ्या गोष्टी

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

दस्तऐवजीकरणातील setup command त्या box वर चालवायची आहे:

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 योग्य नसल्यास सुरुवातीलाच थांबतो. हार्डवेअरविषयक त्याचे दोन नकार संदेश असे आहेत:

/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 नुसार ती image build होण्यासाठी सुमारे 8 minutes लागतात.

ही command paste करण्यापूर्वी सावधगिरीच्या सूचना वाचा

यासाठी नव्या host वर root SSH आवश्यक आहे. Installer system packages, systemd units आणि network configuration root म्हणून लिहितो. ज्या मशीनला पूर्णपणे नव्याने तयार करण्याची तुमची तयारी आहे, त्याच मशीनकडे तो निर्देशित करा. तुमची site आधीपासून चालणाऱ्या server कडे तो निर्देशित करू नका.

Daemon डीफॉल्टनुसार 0.0.0.0:8080 वर bind होतो. त्या port पर्यंत पोहोचणारा कोणताही व्यक्ती machines तयार करू शकतो. त्या machines साठी installer ला दिलेली model key वापरली जाते. प्रमाणीकरण आवश्यक करण्यासाठी 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 द्वारे तुम्ही त्याच्यापर्यंत पोहोचाल. या key ची सुरक्षितता box वरील इतर कोणत्याही secret प्रमाणेच जपा, जसे AI agents पासून secrets दूर ठेवणे.

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

Tagged release उपलब्ध नाही. 10 August 2026 रोजी repository मध्ये एकही tag नव्हता. त्यामुळे cloning main केल्यास त्या सकाळपर्यंत 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 पुन्हा वाचा, कारण तुम्ही मंजूर करत असलेली गोष्ट root access असलेली machine आहे, केवळ 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 असते. मशीन चालू असेपर्यंत ही memory राखून ठेवली जाते. त्यामुळे एकाच वेळी चालवायच्या microVMs ची संख्या आणि प्रत्येक guest चा आकार यानुसार host चा आकार ठरवा. खालील आकडे मोजणीवर आधारित आहेत; ते प्रत्यक्ष मोजमाप नाहीत. Headless guest साठी 1 GB आणि browser असलेल्या desktop guest साठी 2 GB memory द्या. Host स्वतःसाठी, daemon साठी आणि image builds साठी स्थिर 2 GB राखून ठेवतो.

ChartHost RAM for concurrent microVMs, arithmetic not measurement

label

guests

guest_ram_gb

host_ram_gb

1 headless guest

4 headless guests

4 desktop guests

8 desktop guests

The data behind this chart

[
  {
    "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 मोजण्यापूर्वीच या मोजणीनुसार 18 GB आवश्यक ठरतात.

हे आकडे कसे मोजले

Guest memory ला एकाच वेळी चालणाऱ्या guests च्या संख्येने गुणा करा आणि त्यात host साठी स्थिर 2 GB राखीव memory जोडा. सर्व 4 rows मध्ये प्रत्येक guest साठी हीच दोन आकारमानं वापरली आहेत. ही राखीव memory operating system, daemon आणि guest मध्ये browser install करणाऱ्या image build साठी आहे. Snapshots आणि cached images हे memory ऐवजी disk वर साठवले जातात. त्यामुळे या मोजणीत त्यांचा समावेश नाही. Machines चालू असताना host वर free -m वापरून स्वतःच्या guests ची memory वापर मोजा. Host swap वापरू लागला की तो वेगवान राहत नाही. microVMs वापरण्याचे मुख्य कारणच fast boot आहे.

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

म्हणून "which VPS runs Firecracker" या प्रश्नाचे प्रामाणिक उत्तर अनेकदा "वेगळ्या class चे machine" असे असते. Hypervisor मध्ये अडथळा नसल्यामुळे bare metal वर 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 गटाच्या मालकीचा 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 निवडा किंवा hypervisor वर तुमचे पूर्ण नियंत्रण असलेले machine वापरा.

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

बहुतेक वेळा होय. Container तुमचे kernel सामायिक करते. त्यामुळे 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 आकाराचा एक headless guest आणि host साठी 2 GB reserve मिळून एकूण सुमारे 3 GB आवश्यक असतात. प्रत्येकी 2 GB असलेले 8 desktop guests चालवण्यासाठी सुमारे 18 GB आवश्यक असतात. Disk स्वतंत्र आहे आणि त्याचा अंदाज सहज कमी धरला जातो, कारण host वर kernel, root filesystems, प्रत्येक guest flavour साठी एक image आणि प्रत्येक चालू machine साठी एक snapshot ठेवावा लागतो.

#firecracker#kvm #nested-virtualization #ai-agents #sandboxing