क्या आपका VPS Firecracker microVMs चला सकता है?

क्या आपका VPS Firecracker microVMs चला सकता है?

आपका VPS Firecracker microVMs केवल तभी चला सकता है यदि वह आपको /dev/kvm प्रदान करता है। Firecracker एक VMM (virtual machine monitor) है जो KVM (kernel-based virtual machine) पर आधारित है, जो Linux के भीतर का वर्चुअलाइजेशन लेयर है, और KVM को CPU से वर्चुअलाइजेशन निर्देशों की आवश्यकता होती है। VPS पर आपको ये निर्देश तभी मिलते हैं जब प्रदाता उन्हें आपके guest तक पास करता है, और अधिकांश plans ऐसा नहीं करते हैं।

इसलिए पहला प्रश्न यह नहीं है कि कौन सा microVM टूल इंस्टॉल करना है। प्रश्न यह है कि क्या वह मशीन जिसके लिए आप पहले से भुगतान कर रहे हैं, वह इसे होस्ट कर सकती है या नहीं। यह होस्टिंग से संबंधित प्रश्न है, और आप इसका उत्तर लगभग एक मिनट में दे सकते हैं।

किसी भी चीज़ को install करने से पहले /dev/kvm की जाँच करें

VPS पर ही ये तीन commands चलाएँ।

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

MicroVMs को host कर सकने वाला बॉक्स इस तरह उत्तर देता है:

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 के भीतर शून्य से अधिक की गिनती का अर्थ है कि 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 में जोड़ें और फिर से login करें।

Ubuntu में एक check भी होता है जो इस सब का सारांश दो पंक्तियों के 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 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 पर वह संदेश दुर्लभ है, क्योंकि आप वास्तविक firmware नहीं देख रहे होते हैं।

हर /dev/kvm उत्तर का क्या अर्थ है?

नोड मौजूद है और फ्लैग काउंट शून्य से अधिक है। आपके पास हार्डवेयर वर्चुअलाइजेशन है, इसलिए Firecracker चलेगा। सीधे साइजिंग सेक्शन पर जाएं, क्योंकि आपकी मुख्य बाधा CPU फीचर्स के बजाय मेमोरी है।

कोई नोड नहीं है, systemd-detect-virt प्रिंट करता है kvm या qemu, और फ्लैग काउंट 0 है। आपका VPS एक वर्चुअल मशीन है जिसका होस्ट वर्चुअलाइजेशन को पास नहीं कर रहा है। गेस्ट के अंदर आप जो कुछ भी इंस्टॉल करेंगे, वह इसे नहीं बदलेगा, क्योंकि फ्लैग उस वर्चुअल CPU की विशेषता है जिसे हाइपरवाइजर ने आपके लिए बनाया है। sudo modprobe kvm_intel, modprobe: ERROR: could not insert 'kvm_intel': Operation not supported के साथ विफल हो जाता है, और sudo dmesg | grep -i kvm हार्डवेयर सपोर्ट की कमी को रिकॉर्ड करता है। शेयरर्ड VPS प्लान पर यह एक सामान्य स्थिति है। अपने प्रदाता से पूछें कि क्या प्लान नेस्टेड वर्चुअलाइजेशन का समर्थन करता है। यदि उत्तर नहीं है, तो आपको अलग होस्टिंग की आवश्यकता है, न कि किसी अलग कमांड की।

systemd-detect-virt प्रिंट करता है lxc, lxc-libvirt या openvz। आपका प्लान कंटेनर वर्चुअलाइजेशन है, इसलिए आप होस्ट के कर्नल को साझा करते हैं। /dev/kvm कभी दिखाई नहीं देगा, क्योंकि आपके पास मॉड्यूल लोड करने के लिए अपना कोई कर्नल नहीं है। कोई भी पैकेज इसे ठीक नहीं कर सकता।

फ्लैग मौजूद हैं और नोड नहीं है। मॉड्यूल बस लोड नहीं हुआ है। sudo modprobe kvm_intel (या AMD पर kvm_amd) चलाएं और फिर से ls -l /dev/kvm की जाँच करें। यदि नोड दिखाई देता है, तो मॉड्यूल का नाम /etc/modules-load.d/kvm.conf में लिखें ताकि रीबूट के बाद यह वापस आ जाए।

आप arm64 पर हैं। vmx और svm x86 नाम हैं, इसलिए हर arm64 मशीन पर grep काउंट 0 होता है, चाहे वह काम कर रही हो या नहीं। arm64 पर, डिवाइस नोड और रीड-राइट टेस्ट पर भरोसा करें।

एजेंट के काम के लिए 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 चलाता है उसे पहले किसी ने नहीं पढ़ा होता। यह packages install करता है, build scripts चलाता है, और किसी चीज के विफल होने पर machine की गति से उसे फिर से प्रयास करता है। एक अलग kernel का मतलब है कि एक गलत कदम केवल उस machine को नुकसान पहुँचाता है जिसे आप delete कर सकते हैं, और किसी अन्य चीज को नहीं।

यह आवश्यकता सीधे इस mechanism से उत्पन्न होती है। Hardware isolation के लिए hardware virtualisation की आवश्यकता होती है, और hardware virtualisation ही वह चीज है जो शायद आपके VPS plan में न हो। Container को इसकी कोई आवश्यकता नहीं होती, यही कारण है कि containers हर बेचे गए plan पर चलते हैं।

इसलिए जब /dev/kvm अनुपलब्ध हो, तो container-आधारित coding agents के लिए disposable VM ही सही उत्तर बना रहता है, और यह एक सांत्वना पुरस्कार के बजाय एक वास्तविक नियंत्रण है। एक ऐसा throwaway container, जो ऐसे host पर हो जिसमें आपके काम की कोई credentials न हों, और जिसे गलत व्यवहार करने पर snapshot से restore किया जा सके, उन अधिकांश समस्याओं को रोकता है जो वास्तव में होती हैं। यही बात VPS पर coding agent चलाने के सरल setup के लिए भी सच है। MicroVM का उपयोग तब करें जब कोई agent बिना निगरानी के, घंटों तक, ऐसे code पर काम करेगा जिसे आपने review नहीं किया है, और जब host पूरी तरह से आपके नियंत्रण में हो।

एक microVM agent host की आवश्यकताएं

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

दस्तावेजीकृत सेटअप उस बॉक्स पर लक्षित एक कमांड है:

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 जांच चलाता है और बॉक्स के गलत होने पर जल्दी रुक जाता है। इसके दो हार्डवेयर अस्वीकृति संदेश इस प्रकार हैं:

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

वह पहली स्ट्रिंग ही इस पोस्ट का मुख्य उद्देश्य है। इंस्टॉलर वही सवाल पूछता है जो आपने अभी ls -l /dev/kvm के साथ पूछा था, और अधिकांश VPS प्लान पर इसे वही निराशाजनक उत्तर मिलता है।

Preflight के बाद यह एक पूर्ण बॉक्स इंस्टॉलेशन है: Firecracker और इसका jailer, एक Go toolchain, एक guest kernel और root filesystem, एक Python guest image, एक वैकल्पिक डेस्कटॉप image जिसमें ब्राउज़र हो, और nehemiahd.service तथा boring-net.service नामक दो systemd units। इसके बाद daemon पोर्ट 8080 पर उत्तर देता है, और एक विफल health check /healthz didn't return ok प्रिंट करती है। SKIP_DESKTOP=1 डेस्कटॉप image को छोड़ देता है, जिसे README के अनुसार बनने में लगभग 8 मिनट लगते हैं।

उस कमांड को पेस्ट करने से पहले सावधानियां पढ़ें

इसे एक नए होस्ट पर root SSH की आवश्यकता है। इंस्टॉलर root के रूप में सिस्टम पैकेज, systemd यूनिट्स और नेटवर्क कॉन्फ़िगरेशन लिखता है। इसे ऐसी मशीन पर चलाएं जिसे आप पूरी तरह से रीबिल्ट करने के लिए तैयार हों, न कि उस सर्वर पर जो पहले से आपकी साइट चला रहा है।

डेमन डिफ़ॉल्ट रूप से 0.0.0.0:8080 पर बाइंड होता है। जो कोई भी उस पोर्ट तक पहुँचता है, वह मशीनें बना सकता है, और वे मशीनें उस मॉडल की का उपयोग करती हैं जो आपने इंस्टॉलर को दिया है। प्रमाणीकरण (authentication) की आवश्यकता के लिए NEHEMIAH_TOKEN सेट करें, या BIND_LOCALHOST=1 सेट करें ताकि डेमन केवल 127.0.0.1 पर बाइंड हो और आप उस तक ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP के माध्यम से टनल बनाकर पहुँच सकें। यह की (key) बॉक्स पर मौजूद किसी भी अन्य सीक्रेट के समान ही सुरक्षा की हकदार है, जैसा कि AI एजेंटों से सीक्रेट्स को सुरक्षित रखना में बताया गया है।

प्रत्येक मशीन इंटरनेट एक्सेस और पहले से इंस्टॉल किए गए एजेंटों वाला एक कंप्यूटर है। README में गेस्ट के अंदर node, python और git के साथ-साथ claude, codex, cursor और pi सूचीबद्ध हैं। प्रोजेक्ट का कहना है कि गेस्ट एक एग्रेस फ़ायरवॉल (egress firewall) के पीछे रहते हैं, और आइसोलेशन बाउंड्री वास्तविक है। गेस्ट अभी भी डिज़ाइन के अनुसार नेटवर्क तक पहुँचता है, क्योंकि एक कोडिंग एजेंट जो पैकेज फ़ेच नहीं कर सकता, वह बेकार है। एयर गैप (air gap) मान लेने के बजाय इसकी योजना बनाएं।

इसका कोई टैग्ड रिलीज़ नहीं है। 10 अगस्त 2026 तक रिपॉजिटरी में कोई टैग नहीं है, इसलिए main को क्लोन करने पर आपको वही मिलेगा जो उस सुबह अपडेट हुआ था। एक कमिट (commit) पर पिन करें, और अपने सर्वर पर root के रूप में चलने से पहले स्क्रिप्ट को पढ़ें:

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

रिपॉजिटरी जून 2026 के अंत में बनाई गई थी, इसलिए इसे नया सॉफ़्टवेयर मानें। हर बार अपडेट लेने के बाद infra/setup.sh को फिर से पढ़ें, क्योंकि आप जिस चीज़ को मंजूरी दे रहे हैं वह मशीन का root एक्सेस है, न कि लाइब्रेरी वर्शन का अपडेट।

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

एक printed version यह सिद्ध करता है कि binary आपके architecture से मेल खाता है और चलता है। यह KVM access को सिद्ध नहीं करता है, इसलिए इसे पहले बताए गए /dev/kvm पर read और write परीक्षण के साथ जोड़ें। ये दोनों मिलकर hosting की समस्या को packaging की समस्या से अलग करते हैं, जिससे आप उस installer को debug करने से बच जाते हैं जो वास्तव में सही था।

कई microVMs के लिए कितने बड़े सर्वर की आवश्यकता होती है?

प्रत्येक microVM में एक वास्तविक guest kernel और आपके द्वारा आवंटित memory होती है। यह memory तब तक आरक्षित रहती है जब तक machine चलती है। इसलिए, host का आकार guest के आकार और एक साथ चलने वाली मशीनों की संख्या के आधार पर तय करें। नीचे दिए गए आंकड़े गणितीय हैं, वास्तविक माप नहीं। एक headless guest को 1 GB और browser वाले desktop guest को 2 GB की आवश्यकता होती है। Host स्वयं के लिए, daemon के लिए और image builds के लिए 2 GB memory अलग रखता है।

[
  {
    "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 संभाल सकता है। ऐसी चार मशीनों के लिए 6 GB की आवश्यकता होती है। यदि आप 8 desktop machines चलाते हैं, तो इसी गणित के अनुसार आपको 18 GB की आवश्यकता होगी, जिसमें disk का उपयोग अभी शामिल नहीं है।

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 के बीच चयन करते समय मुख्य विचार होता है। कुछ प्रदाता virtual plans पर nested virtualisation की सुविधा देते हैं, और VPS पर nested virtualisation लेख में भुगतान करने से पहले इसे verify करने का तरीका बताया गया है। यदि hardware पहले से ही आपका है, तो Proxmox बनाम सामान्य VPS का प्रश्न hypervisor के दृष्टिकोण से समान है।

सर्वर का खर्च तो बस एक छोटा हिस्सा है। आप जिस भी machine को agent को सौंपते हैं, वह चलते समय model tokens खर्च करती है। इसलिए, एक idle microVM memory खर्च करती है, जबकि एक busy 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 मौजूद है और flag count शून्य से अधिक है, तो इसका मतलब है कि Firecracker चल सकता है। यदि node गायब है और count 0 है, तो इसका अर्थ है कि hypervisor वर्चुअलाइजेशन को पास नहीं कर रहा है, और cpu-checker पैकेज की 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 प्रदान करता हो, या ऐसी मशीन लें जहाँ आप स्वयं hypervisor के स्वामी हों।

क्या कोडिंग एजेंट को सैंडबॉक्स करने के लिए एक container पर्याप्त है?

अक्सर हाँ। एक container आपके kernel को साझा करता है, इसलिए kernel स्तर का escape host तक पहुँच सकता है, लेकिन ऐसी मशीन पर एक disposable container जिसमें कोई मूल्यवान क्रेडेंशियल नहीं हैं, आपके सामने आने वाले अधिकांश जोखिम को समाप्त कर देता है। जब कोई एजेंट बिना निगरानी के लंबे समय तक अपरीक्षित कोड पर चलता है, और जब आप उसे /dev/kvm वाला host दे सकते हैं, तब microVM चुनें। जब आप ऐसा नहीं कर सकते, तो हर कार्य के बाद नष्ट किया जाने वाला container उस microVM से बेहतर है जिसे आप कभी boot ही नहीं कर पाते।

microVM एजेंट host को कितनी RAM की आवश्यकता होती है?

Guest के आकार से शुरुआत करें। 2 GB host reserve के साथ 1 GB का एक headless guest कुल मिलाकर लगभग 3 GB RAM चाहता है, और 2 GB प्रत्येक वाले 8 desktop guests को लगभग 18 GB की आवश्यकता होती है। डिस्क का उपयोग अलग है और इसे कम आंकना आसान है, क्योंकि host एक kernel, root filesystems, प्रत्येक guest प्रकार के लिए एक image और हर चल रही मशीन के लिए एक snapshot रखता है।