Je, VPS yangu inaweza kuendesha Firecracker microVMs?

Je, VPS yako inaweza kuendesha Firecracker microVMs?

VPS yako inaweza kuendesha Firecracker microVMs ikiwa tu inakupa /dev/kvm. Firecracker ni VMM (virtual machine monitor) iliyojengwa juu ya KVM (kernel-based virtual machine), ambayo ni safu ya uboreshaji wa mashine pepe (virtualisation) ndani ya Linux, na KVM inahitaji maelekezo ya virtualisation kutoka kwa CPU. Kwenye VPS, unapata maelekezo hayo tu ikiwa mtoa huduma atayapitisha kwenye mfumo wako wa mgeni (guest), na mipango mingi haifanyi hivyo.

Kwa hiyo, swali la kwanza si ni zana gani ya microVM ya kusakinisha. Swali ni kama mashine unayolipia tayari inaweza kuhifadhi moja. Hilo ni swali la hosting, na unaweza kulijibu ndani ya dakika moja hivi.

Kagua /dev/kvm kabla ya kusakinisha chochote

Tekeleza amri hizi tatu kwenye VPS yenyewe.

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

Sanduku linaloweza kuhifadhi microVMs hujibu hivi:

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

Mstari wa kwanza ni node ya kifaa cha KVM, inayomilikiwa na kundi la kvm. Mstari wa pili unasema mashine hii yenyewe ni mgeni (guest) inayofanya kazi chini ya KVM, jambo ambalo ni la kawaida na linalotarajiwa kwenye VPS. Mstari wa tatu huhesabu cores za CPU zinazoripoti bendera ya hardware virtualisation, vmx kwenye Intel na svm kwenye AMD. Hesabu iliyo juu ya sifuri ndani ya mgeni inamaanisha kuwa hypervisor inakupa uwezo wa nested virtualisation.

Kisha hakikisha kuwa mtumiaji wako anaweza kufungua kifaa hicho. Hii ni jaribio kutoka kwenye hati ya kuanza ya Firecracker yenyewe:

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

FAIL wakati node ipo ni tatizo la ruhusa badala ya tatizo la vifaa. Toa ruhusa kwa mtumiaji wako kwa kutumia sudo setfacl -m u:${USER}:rw /dev/kvm, au jiongeze kwenye kundi hilo kwa sudo usermod -aG kvm ${USER} kisha uingie tena kwenye mfumo.

Ubuntu pia inatoa zana ya ukaguzi inayofupisha yote haya katika mistari miwili ya matokeo:

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

Host inayofanya kazi huchapisha INFO: /dev/kvm exists na kisha KVM acceleration can be used. Host isiyoweza kufanya kazi huchapisha INFO: Your CPU does not support KVM extensions na kisha KVM acceleration can NOT be used. Kwenye mashine ya kimwili unaweza kuona INFO: KVM (vmx) is disabled by your BIOS badala yake, ambayo inaweza kurekebishwa kwenye firmware. Kwenye VPS ujumbe huo ni nadra, kwa sababu huangalii firmware halisi.

Kila jibu la /dev/kvm linamaanisha nini?

Node ipo na idadi ya flag ni zaidi ya sifuri. Una uwezo wa hardware virtualisation, kwa hivyo Firecracker itafanya kazi. Rukia sehemu ya sizing, kwa sababu kizuizi chako kilichobaki ni kumbukumbu badala ya vipengele vya CPU.

Node haipo, systemd-detect-virt inachapisha kvm au qemu, na idadi ya flag ni 0. VPS yako ni mashine pepe (virtual machine) ambayo mwenyeji wake (host) haijapitisha uwezo wa virtualisation. Hakuna unachoweza kusakinisha ndani ya guest kitakachobadilisha hili, kwa sababu flag ni sifa ya CPU pepe ambayo hypervisor imekujengea. sudo modprobe kvm_intel inafeli kwa modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, na sudo dmesg | grep -i kvm inarekodi ukosefu wa support ya hardware. Hii ni hali ya kawaida kwenye mipango ya VPS ya pamoja (shared VPS). Uliza mtoa huduma kama mpango wako una support ya nested virtualisation. Ikiwa jibu ni hapana, unahitaji hosting tofauti, si amri tofauti.

systemd-detect-virt inachapisha lxc, lxc-libvirt au openvz. Mpango wako ni container virtualisation, kwa hivyo unashiriki kernel ya mwenyeji. /dev/kvm haitaonekana kamwe, kwa sababu huna kernel yako mwenyewe ya kupakia module. Hakuna kifurushi kitakachorekebisha hili pia.

Flag zipo na node haipo. Module haijapakiwa tu. Tekeleza sudo modprobe kvm_intel (au kvm_amd kwenye AMD) na uangalie ls -l /dev/kvm tena. Ikiwa node itaonekana, andika jina la module kwenye /etc/modules-load.d/kvm.conf ili irudi baada ya reboot.

Uko kwenye arm64. vmx na svm ni majina ya x86, kwa hivyo idadi ya grep ni 0 kwenye kila mashine ya arm64, iwe inafanya kazi au la. Kwenye arm64, amini device node na jaribio la kusoma na kuandika badala yake.

Kwa nini utumie microVM badala ya container kwa kazi za wakala

Container ni mchakato (process) kwenye kernel yako, uliotengwa kwa kutumia namespaces na cgroups. Kuna kernel moja tu na ni yako, kwa hivyo kutoroka kwenye kiwango cha kernel (kernel level escape) kutakuweka kwenye host. MicroVM huwasha kernel yake yenyewe ndani ya mpaka wa hardware virtualisation, na huwasiliana na modeli ndogo ya kifaa kilichoigwa (emulated device model) badala ya kutumia mfumo mzima wa system calls wa host yako. Firecracker huweka modeli hiyo kuwa ndogo kwa makusudi, na huo ndio muundo wake wote: vifaa vichache vilivyoigwa humaanisha njia chache za kutokea.

Tofauti hiyo ni muhimu kwa wakala wa uandishi wa msimbo (coding agent), kwa sababu msimbo unaoendeshwa na wakala ni msimbo ambao hakuna mtu aliyeusoma kwanza. Hufunga vifurushi (packages), huendesha hati za ujenzi (build scripts), na hujaribu tena kwa kasi ya mashine wakati kitu kinaposhindwa. Kernel tofauti humaanisha kuwa hatua mbaya itaharibu mashine unayoweza kuifuta, na si kitu kingine chochote.

Sharti hili linatokana moja kwa moja na utaratibu huo. Kutengwa kwa maunzi (hardware isolation) kunahitaji hardware virtualisation, na hardware virtualisation ndicho kitu ambacho mpango wako wa VPS unaweza kukosa. Container haihitaji chochote kati ya hivyo, ndiyo sababu container huendeshwa kwenye kila mpango uliowahi kuuzwa.

Kwa hivyo wakati /dev/kvm haipo, container inayotumika kama VM ya muda kwa ajili ya mawakala wa uandishi wa msimbo inabaki kuwa jibu sahihi, na ni udhibiti wa kweli badala ya kuwa suluhisho la dharura. Container ya kutupwa, kwenye host isiyo na vitambulisho (credentials) unavyojali, inayorejeshwa kutoka kwenye snapshot kila inapofanya vibaya, huzuia mambo mengi yanayoweza kwenda vibaya. Vivyo hivyo kwa usanidi rahisi zaidi katika kuendesha wakala wa uandishi wa msimbo kwenye VPS. Tumia microVM wakati wakala ataendeshwa bila kusimamiwa, kwa saa nyingi, dhidi ya msimbo ambao hujaupitia, na wakati host ni mali yako ya kutoa.

Mahitaji ya mwenyeji wa wakala wa microVM

Nehemiah ni mfano wa sasa wa darasa hili: daemon ya Apache-2.0 inayompa AI mashine halisi ya Linux inapohitajika, microVM moja ya Firecracker kwa kila mashine. README yake inaeleza hitaji hilo bila kusita: "sanduku la Linux lenye /dev/kvm", na kwa usahihi zaidi "Ubuntu 24.04, x86_64 au arm64, lenye /dev/kvm (bare-metal, au VM yenye nested virtualization) unayoweza kuingia kwa root-SSH".

Usanidi ulioandikwa ni amri moja inayolenga sanduku hilo:

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 huendesha ukaguzi wa awali (preflight) kupitia SSH na kusimama mapema ikiwa sanduku si sahihi. Kukataa kwake kwa maunzi (hardware) kuna ujumbe huu:

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

Mfuatano huo wa kwanza ndio kiini cha chapisho hili. Kisakinishi huuliza swali lilelile ulilouliza hivi punde na ls -l /dev/kvm, na kwenye mipango mingi ya VPS hupata jibu lilelile la kukatisha tamaa.

Baada ya ukaguzi wa awali, ni usakinishaji wa sanduku zima: Firecracker na jailer yake, Go toolchain, kernel ya mgeni na mfumo wa faili wa root, picha ya Python ya mgeni, picha ya hiari ya desktop yenye kivinjari, na vitengo viwili vya systemd vilivyopewa majina nehemiahd.service na boring-net.service. Daemon hiyo kisha hujibu kwenye port 8080, na ukaguzi wa afya (health check) ulioshindwa huchapisha /healthz didn't return ok. SKIP_DESKTOP=1 huruka picha ya desktop, ambayo README inasema huchukua takriban dakika 8 kujenga.

Soma maonyo kabla ya kuweka amri hiyo

Inahitaji root SSH kwenye host mpya. Kisakinishi huandika vifurushi vya mfumo, systemd units na usanidi wa mtandao kama root. Ielekeze kwenye mashine ambayo uko tayari kuijenga upya kutoka mwanzo, si kwenye seva inayotumika kuendesha tovuti yako.

Daemon hufungua 0.0.0.0:8080 kwa chaguo-msingi. Mtu yeyote anayefikia port hiyo anaweza kuunda mashine, na mashine hizo hutumia model key uliyompa kisakinishi. Weka NEHEMIAH_TOKEN ili kuhitaji uthibitisho, au weka BIND_LOCALHOST=1 ili daemon ifungue 127.0.0.1 pekee na uifikie kupitia tunnel kwa kutumia ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. Ufunguo huu unahitaji uangalifu sawa na siri nyingine yoyote kwenye seva, kama ilivyoelezwa katika kuepuka kuweka siri kwenye AI agents.

Kila mashine ni kompyuta yenye ufikiaji wa Internet na agents zilizosakinishwa awali. README inaorodhesha claude, codex, cursor na pi ndani ya guest, kando ya node, python na git. Mradi huu unasema kuwa guests ziko nyuma ya egress firewall, na mpaka wa kutengwa ni wa kweli. Hata hivyo, guest bado hufikia mtandao kwa muundo wake, kwa sababu coding agent isiyoweza kupakua kifurushi haina faida. Panga kwa ajili ya hali hiyo badala ya kudhani kuna air gap.

Hakuna tagged release. Kufikia tarehe 10 Agosti 2026, hazina (repository) haina tags zozote, kwa hivyo cloning main itakupa chochote kilichowekwa asubuhi hiyo. Funga toleo kwenye commit mahususi, na usome script kabla haijafanya kazi kama root kwenye seva yako:

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

Hazina hii iliundwa mwishoni mwa Juni 2026, kwa hivyo ichukulie kama programu changa. Soma infra/setup.sh tena baada ya kila update unayovuta, kwa sababu kitu unachoidhinisha ni ufikiaji wa root kwenye mashine, siyo ongezeko la toleo la library.

Thibitisha KVM inafanya kazi kabla ya kuilaumu installer

Ikiwa usanidi utafeli na unataka kujua kama KVM ndiyo sababu, jaribu Firecracker peke yake. Hizi hapa ni hatua za kupakua kutoka kwa chanzo asilia:

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

Toleo lililochapishwa linathibitisha kuwa binary inalingana na usanifu wako na inafanya kazi. Hii haithibitishi ufikiaji wa KVM, kwa hivyo iunganishe na jaribio la kusoma na kuandika kwenye /dev/kvm kutoka awali. Kwa pamoja, majaribio haya mawili yanatenganisha tatizo la hosting na tatizo la packaging, jambo linalokuokoa kutokana na kutatua hitilafu kwenye installer ambayo ilikuwa sahihi tangu mwanzo.

Je, microVM kadhaa zinahitaji seva ya ukubwa gani?

Kila microVM hubeba kernel halisi ya guest pamoja na kumbukumbu unayotenga, na kumbukumbu hiyo hutengwa kwa muda wote ambao mashine hiyo inafanya kazi. Kwa hiyo, kadiria ukubwa wa host kulingana na ukubwa wa guest na idadi unayotaka kuendesha kwa wakati mmoja. Takwimu hapa chini ni za kihisabati, si vipimo halisi. Guest isiyo na kiolesura cha picha (headless) huchukua 1 GB, na guest ya desktop yenye kivinjari huchukua 2 GB. Host hutenga 2 GB kwa ajili yake yenyewe, daemon, na ujenzi wa image.

[
  {
    "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
  }
]

Mashine moja ya headless kwa wakati mmoja inahitaji takriban 3 GB, ambayo VPS ya ukubwa wa wastani inaweza kuhimili ikiwa inatoa KVM. Nne kati ya hizo zinahitaji 6 GB. Endesha 8 mashine za desktop na hesabu hiyo hiyo itahitaji 18 GB kabla ya kuhesabu hata gigabyte moja ya diski.

Diski ni namba ambayo hakuna anayeipangia. Host huhifadhi kernel ya guest, mfumo wa faili wa msingi (root filesystem), image moja kwa kila aina ya guest, na snapshot moja kwa kila mashine inayofanya kazi, na image ya desktop yenye kivinjari ndiyo kubwa zaidi. README haitoi takwimu ya diski, kwa hivyo fuatilia df -h / wakati wa ujenzi wa kwanza badala ya kuamini makadirio.

Hii ndiyo sababu jibu la kweli kwa swali "ni VPS ipi inayoendesha Firecracker" mara nyingi ni "darasa tofauti la mashine". Bare metal hukupa CPU flags bila hypervisor kuingilia kati, ambayo ndiyo biashara katika kuchagua kati ya VPS na seva iliyojitolea. Baadhi ya watoa huduma hutoa nested virtualisation kwenye mipango ya virtual, na nested virtualisation kwenye VPS inaelezea jinsi ya kuthibitisha hilo kabla ya kulipia. Ikiwa maunzi ni yako tayari, Proxmox dhidi ya VPS ya kawaida ni swali lilelile linaloulizwa kutoka upande wa hypervisor.

Seva pia ndiyo nusu ya bei nafuu. Kila mashine unayokabidhi kwa wakala hutumia model tokens kwa muda wote inapoendelea kufanya kazi, kwa hivyo microVM iliyokaa bila kazi hugharimu kumbukumbu, wakati ile inayofanya kazi hugharimu kumbukumbu na matumizi ya API. Mpango wa 1 GB hauwezi kuhimili host. Mpango unaoweza kuhimili host bado hautalipia ufunguo.

FAQ

Je, nitawezaje kujua kama VPS yangu inaweza kuendesha Firecracker?

Endesha ls -l /dev/kvm, systemd-detect-virt na grep -cE '\b(vmx|svm)\b' /proc/cpuinfo kwenye VPS. Kifaa (device node) kinachomilikiwa na kundi la kvm, pamoja na idadi ya flag inayozidi sifuri, inamaanisha Firecracker inaweza kufanya kazi. Kifaa kisichokuwepo na idadi ya 0 inamaanisha hypervisor haipitishi virtualisation, na sudo kvm-ok kutoka kwenye kifurushi cha cpu-checker inathibitisha hilo kwa KVM acceleration can NOT be used. Kwenye arm64, puuza idadi hiyo, kwa sababu vmx na svm ni majina ya x86.

Je, ninaweza kuwasha nested virtualisation kutoka ndani ya VPS yangu?

Hapana. Nested virtualisation huwashwa na mwenyeji (host), kwenye kernel module ya hypervisor yenyewe, na inakufikia kama CPU flag kwenye virtual processor uliyopewa. Ndani ya guest, sudo modprobe kvm_intel inarudisha modprobe: ERROR: could not insert 'kvm_intel': Operation not supported kwa sababu virtual CPU haina VMX ya kutumia. Chaguo zako ni mtoa huduma anayetoa nested virtualisation kwenye mpango wake, au mashine ambapo wewe ndiye unayemiliki hypervisor.

Je, container inatosha kuweka coding agent kwenye sandbox?

Mara nyingi ndiyo. Container inashiriki kernel yako, kwa hivyo kutoroka kwenye kiwango cha kernel kunaweza kufika kwenye host, lakini container inayoweza kufutwa kwenye mashine isiyo na credentials muhimu huondoa hatari nyingi unazokabiliana nazo. Chagua microVM wakati agent anafanya kazi bila kusimamiwa kwa muda mrefu dhidi ya code ambayo haijakaguliwa, na unapoweza kumpa host yenye /dev/kvm. Wakati huwezi, container unayoharibu baada ya kila kazi ni bora kuliko microVM ambayo huwezi kuianzisha.

Host ya microVM agent inahitaji RAM kiasi gani?

Anza na ukubwa wa guest. Guest moja isiyo na interface ya picha (headless) yenye 1 GB na akiba ya host ya 2 GB inahitaji takriban 3 GB kwa jumla, na 8 desktop guests zenye 2 GB kila moja zinahitaji takriban 18 GB. Disk ni kitu tofauti na ni rahisi kukidharau, kwa sababu host huhifadhi kernel, root filesystems, image moja kwa kila aina ya guest na snapshot kwa kila mashine inayofanya kazi.