ద్వారా మీ VPSలో Firecracker microVMలు నడుస్తాయా? ఇలా చెక్ చేయండి
/dev/kvm లేకపోతే Firecracker పనిచేయదు. VPSలో మూడు ఆదేశాలతో తనిఖీ చేసి, ఫలితాన్ని అర్థం చేసుకోండి. అది కనిపించకపోతే ఏం చేయాలో కూడా తెలుసుకోండి.
మీ VPS Firecracker microVMలను నడపగలదా?
మీ VPS మీకు /dev/kvm అందిస్తేనే Firecracker microVMలను నడపగలదు. Firecracker అనేది KVM (kernel-based virtual machine)పై నిర్మించిన VMM (virtual machine monitor). KVM అనేది Linuxలోని virtualisation layer. దీనికి CPU నుంచి virtualisation instructions అవసరం. VPSలో provider ఆ instructions ను మీ 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/cpuinfomicroVMs ను హోస్ట్ చేయగల యంత్రం ఇలా సమాధానం ఇస్తుంది:
crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
16మొదటి పంక్తి KVM device node ను చూపిస్తుంది. దానికి యాజమాన్య group kvm కు ఉంటుంది. రెండో పంక్తి, ఈ యంత్రం కూడా KVM కింద నడుస్తున్న guest అని చూపిస్తుంది. VPS లో ఇది సాధారణం, ఆశించినదే. మూడో పంక్తి, hardware virtualisation flag ను నివేదిస్తున్న CPU cores సంఖ్యను చూపిస్తుంది. Intel పై ఇది vmx, AMD పై svm. Guest లో ఈ సంఖ్య సున్నా కంటే ఎక్కువగా ఉంటే, hypervisor మీకు nested virtualisation ను అందిస్తున్నదని అర్థం.
తర్వాత మీ user device ను open చేయగలదో లేదో తనిఖీ చేయండి. ఇది Firecracker స్వంత getting started పత్రంలో ఉన్న పరీక్ష:
[ -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 ను guest కు 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 plans లో ఇది సాధారణ పరిస్థితి. మీ plan nested virtualisation కు మద్దతు ఇస్తుందా అని provider ను అడగండి. సమాధానం no అయితే, వేరే command కాదు, వేరే hosting అవసరం.
systemd-detect-virt ద్వారా lxc, lxc-libvirt లేదా openvz ముద్రితమవుతుంది. మీ plan container virtualisation ఉపయోగిస్తోంది. అందువల్ల మీరు host యొక్క kernel ను పంచుకుంటున్నారు. /dev/kvm ఎప్పటికీ కనిపించదు. మీ వద్ద module ను load చేయడానికి ప్రత్యేక kernel లేదు. ఏ package install చేసినా ఇది పరిష్కారం కాదు.
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 అనేది namespaces మరియు cgroups ద్వారా వేరుచేసిన మీ kernel పై నడిచే ఒక process. Kernel ఒక్కటే ఉంటుంది, అది మీ hostదే. కాబట్టి kernel స్థాయి escape జరిగితే అది hostకి చేరుతుంది. microVM hardware virtualisation boundary లో తన స్వంత kernelను boot చేస్తుంది. ఇది host యొక్క పూర్తి system call surfaceకు బదులుగా చిన్న emulated device modelతో మాట్లాడుతుంది. Firecracker ఆ modelను ఉద్దేశపూర్వకంగా చిన్నదిగా ఉంచుతుంది. ఇదే దాని ప్రధాన రూపకల్పన. Emulated devices తక్కువగా ఉంటే బయటకు వెళ్లే మార్గాలు కూడా తక్కువగా ఉంటాయి.
Coding agent విషయంలో ఈ తేడా ముఖ్యమైనది. Agent అమలు చేసే codeను ముందుగా ఎవరూ పరిశీలించి ఉండకపోవచ్చు. అది packages install చేస్తుంది, build scripts నడుపుతుంది, ఏదైనా విఫలమైతే machine speedతో మళ్లీ ప్రయత్నిస్తుంది. ప్రత్యేక kernel ఉండటం వల్ల తప్పు step వల్ల మీరు తొలగించగల machine మాత్రమే దెబ్బతింటుంది. మరేదీ ప్రభావితం కాదు.
ఈ అవసరం నేరుగా mechanism నుంచే వస్తుంది. Hardware isolationకు hardware virtualisation అవసరం. మీ VPS plan ఆ సదుపాయాన్ని ఇవ్వకపోవచ్చు. Containerకు ఇవేవీ అవసరం లేదు. అందుకే ఇప్పటివరకు అందించిన ప్రతి planలో containers నడుస్తాయి.
కాబట్టి /dev/kvm అందుబాటులో లేకపోతే, container ఆధారిత coding agents కోసం తాత్కాలికంగా ఉపయోగించి తొలగించగల VM సరైన ఎంపికగానే ఉంటుంది. అది కేవలం ప్రత్యామ్నాయం కాదు; వాస్తవ నియంత్రణ. మీకు అవసరమైన credentials ఏవీ లేని hostపై ఉంచిన తాత్కాలిక containerను, సమస్య వచ్చినప్పుడల్లా snapshot నుంచి restore చేస్తే, వాస్తవంగా జరిగే చాలా సమస్యలను ఆపవచ్చు. VPSపై coding agent నడపడం లోని సరళమైన setupకూ ఇదే వర్తిస్తుంది. Agent unattendedగా గంటల పాటు, మీరు సమీక్షించని codeపై నడవాల్సి వచ్చినప్పుడు, అలాగే hostను మీరు స్వయంగా అందించగలిగినప్పుడు microVMను ఎంచుకోండి.
మైక్రోవీఎం ఏజెంట్ హోస్ట్కు అవసరమైనవి
Nehemiah ఈ తరగతికి చెందిన ప్రస్తుత ఉదాహరణ. ఇది Apache-2.0 లైసెన్స్గల daemon. అవసరమైనప్పుడు AIకి వాస్తవ Linux machine ను అందిస్తుంది. ప్రతి machine కోసం ఒక Firecracker microVM ను నడుపుతుంది. దీని README అవసరాన్ని స్పష్టంగా పేర్కొంటుంది: "/dev/kvm కలిగిన Linux box", ఇంకా నిర్దిష్టంగా చెప్పాలంటే "/dev/kvm కలిగిన Ubuntu 24.04, x86_64 లేదా arm64 (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_IPinfra/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ఈ మొదటి string ఈ post యొక్క ప్రధాన విషయం. మీరు ls -l /dev/kvm తో ఇప్పుడే అడిగిన అదే ప్రశ్నను installer అడుగుతుంది. చాలా 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 ను print చేస్తుంది. SKIP_DESKTOP=1 desktop image ను దాటవేస్తుంది. README ప్రకారం ఆ image build కావడానికి సుమారు 8 minutes పడుతుంది.
ఆ command ను paste చేయడానికి ముందు జాగ్రత్తలను చదవండి
దీనికి కొత్త host పై root SSH అవసరం. Installer system packages, systemd units మరియు network configuration ను root హక్కులతో రాస్తుంది. ఏమీ లేని స్థితి నుంచి rebuild చేయడానికి మీరు సిద్ధంగా ఉన్న machine కు మాత్రమే దీన్ని సూచించండి. ఇప్పటికే మీ site ను నడుపుతున్న server పై దీన్ని అమలు చేయవద్దు.
Daemon డిఫాల్ట్గా 0.0.0.0:8080 పై bind అవుతుంది. ఆ port కు చేరగల ఎవరైనా machines సృష్టించగలరు. ఆ machines installer కు మీరు ఇచ్చిన model key ను ఉపయోగిస్తాయి. Authentication తప్పనిసరి చేయడానికి NEHEMIAH_TOKEN ను సెట్ చేయండి. లేదా daemon 127.0.0.1 కు మాత్రమే bind అయ్యేలా BIND_LOCALHOST=1 ను సెట్ చేసి, ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP తో tunnel ద్వారా దాన్ని చేరుకోండి. ఈ key ను system లోని ఇతర secrets మాదిరిగానే జాగ్రత్తగా రక్షించాలి. దీనికి AI agents నుండి secrets ను దూరంగా ఉంచడం చూడండి.
ప్రతి machine internet access మరియు ముందుగానే install చేసిన agents కలిగిన computer. Guest లో node, python మరియు git తో పాటు claude, codex, cursor మరియు pi కూడా ఉన్నాయని README పేర్కొంటుంది. Guests egress firewall వెనుక ఉంటాయని project చెబుతోంది. Isolation boundary కూడా వాస్తవమైనదే. అయినప్పటికీ guest ఉద్దేశపూర్వకంగా network ను చేరుతుంది, ఎందుకంటే package ను fetch చేయలేని coding agent ఉపయోగకరం కాదు. Air gap ఉందని ఊహించకుండా దీనికి తగిన ప్రణాళిక రూపొందించండి.
Tagged release ఏదీ లేదు. 10 August 2026 నాటికి repository లో tags ఏవీ లేవు. అందువల్ల main ను clone చేస్తే ఆ ఉదయం repository లో చేరిన code మీకు లభిస్తుంది. ఒక commit కు pin చేయండి. మీ server పై root హక్కులతో script అమలు కావడానికి ముందు దాన్ని చదవండి:
git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.shRepository 2026 June చివరలో సృష్టించబడింది. కాబట్టి దీన్ని కొత్త software గా పరిగణించండి. మీరు ప్రతి update ను pull చేసిన తర్వాత infra/setup.sh ను మళ్లీ చదవండి. ఎందుకంటే మీరు ఆమోదిస్తున్నది machine కు root access, library version bump కాదు.
Installerను నిందించే ముందు KVM పనిచేస్తుందో నిర్ధారించండి
Setup విఫలమైతే, దానికి KVM కారణమా అని తెలుసుకోవడానికి Firecrackerను స్వతంత్రంగా పరీక్షించండి. ఇవి 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ను కూడా అమలు చేయండి. ఈ రెండు పరీక్షలు కలిసి hosting సమస్యను packaging సమస్య నుంచి వేరు చేస్తాయి. దీని వల్ల మొదటి నుంచీ సరిగ్గానే పనిచేసిన installerను అనవసరంగా debug చేయాల్సిన అవసరం ఉండదు.
అనేక microVMలకు ఎంత server వనరులు అవసరం?
ప్రతి microVMలో నిజమైన guest kernel మరియు మీరు కేటాయించిన memory ఉంటాయి. Machine నడుస్తున్నంతకాలం ఆ memory వినియోగానికి కేటాయించబడి ఉంటుంది. అందువల్ల host పరిమాణాన్ని guest పరిమాణం మరియు ఒకేసారి నడపాలనుకునే guestల సంఖ్య ఆధారంగా నిర్ణయించాలి. కింది సంఖ్యలు measurements కాదు; ఇవి arithmetic ఆధారంగా లెక్కించినవి. Headless guestకు 1 GB, browser ఉన్న desktop guestకు 2 GB కేటాయించాలి. Host తన కోసం, daemon కోసం, image builds కోసం అదనంగా స్థిరంగా 2 GB ఉంచుకుంటుంది.
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 దీనిని నిర్వహించగలదు. నాలుగు machineలకు 6 GB అవసరం. 8 desktop machineలను నడిపితే, ఒక్క GB diskను కూడా లెక్కలోకి తీసుకోకముందే అదే arithmetic ప్రకారం 18 GB అవసరం అవుతుంది.
ఈ సంఖ్యలు ఎలా లెక్కించబడ్డాయి
Guest memoryను ఒకేసారి నడిచే guestల సంఖ్యతో గుణించి, host కోసం స్థిరమైన 2 GB reserveను కలిపాం. మొత్తం 4 rowsలో guestకు ఉపయోగించే ఈ రెండు పరిమాణాలనే వర్తింపజేశాం. Operating system, daemon, guestలో browserను install చేసే image build కోసం reserve ఉపయోగపడుతుంది. Snapshots మరియు cached images memory కాకుండా diskను ఉపయోగిస్తాయి. అందువల్ల ఈ arithmeticలో అవి లేవు. Machineలు నడుస్తున్నప్పుడు hostపై free -m ఉపయోగించి మీ guestల నిజమైన వినియోగాన్ని కొలవండి. Host swap ఉపయోగించడం ప్రారంభిస్తే అది ఇక వేగంగా ఉండదు. MicroVMలను ఉపయోగించడానికి ప్రధాన కారణం fast boot కావడం వల్ల ఇది ముఖ్యమైనది.
ఎవరూ ముందుగా ప్రణాళిక చేయని వనరు disk. Host guest kernel, base root filesystem, ప్రతి guest flavourకు ఒక image, నడుస్తున్న ప్రతి machineకు ఒక snapshotను నిల్వ చేస్తుంది. Browser ఉన్న desktop image వీటిలో పెద్దది. READMEలో diskకు సంబంధించిన సంఖ్య లేదు. అందువల్ల ఊహపై ఆధారపడకుండా మొదటి build సమయంలో df -h /ను గమనించండి.
అందుకే “ఏ VPSలో Firecracker నడుస్తుంది?” అనే ప్రశ్నకు నిజాయితీగల సమాధానం తరచుగా “వేరే తరగతికి చెందిన machine” అవుతుంది. Hypervisor అడ్డంకి లేకుండా bare metal మీకు అవసరమైన 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ను వినియోగిస్తుంది; busy microVM memoryతో పాటు API ఖర్చును కూడా పెంచుతుంది. 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 లేదు. ఈ plan లో nested virtualisation అందించే provider ను ఎంచుకోవాలి లేదా hypervisor మీ స్వాధీనంలో ఉన్న machine ను ఉపయోగించాలి.
coding agent ను sandbox చేయడానికి container సరిపోతుందా?
చాలా సందర్భాల్లో సరిపోతుంది. container మీ kernel ను పంచుకుంటుంది. అందువల్ల kernel-level escape host కు చేరుతుంది. అయితే విలువైన credentials ఏవీ లేని machine పై ఉపయోగించి, పని పూర్తయ్యాక తొలగించే container మీరు ఎదుర్కొనే ఎక్కువ ప్రమాదాన్ని తొలగిస్తుంది. agent పర్యవేక్షణ లేకుండా ఎక్కువసేపు, పరిశీలించని code పై నడుస్తున్నప్పుడు, అలాగే దానికి /dev/kvm ఉన్న host ఇవ్వగలిగినప్పుడు microVM ను ఎంచుకోండి. అలా చేయలేనప్పుడు, boot చేయలేని microVM కంటే ప్రతి task తర్వాత తొలగించే container మెరుగైనది.
microVM agent host కు ఎంత RAM అవసరం?
guest పరిమాణం నుంచి ప్రారంభించండి. 1 GB ఉన్న ఒక headless guest కు, host reserve 2 GB తో కలిపి మొత్తం సుమారు 3 GB అవసరం. 2 GB చొప్పున ఉన్న 8 desktop guests కు సుమారు 18 GB అవసరం. Disk దీనికి వేరు. దాని అవసరాన్ని తక్కువగా అంచనా వేయడం సులభం, ఎందుకంటే host లో kernel, root filesystems, ప్రతి guest flavour కు ఒక image, అలాగే నడుస్తున్న ప్రతి machine కు ఒక snapshot నిల్వ ఉంటాయి.