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 host ya wakala wa microVM

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

Hali hiyo imebadilika tangu wakati huo. Mnamo 11 Agosti 2026, mradi huo ulibadilisha nyaraka zake za usanidi wa self-serve na kuweka runbook ya managed-host, na README iliyokaguliwa tarehe 11 Oktoba 2026 haina tena mstari huo wa mahitaji au ule usakinishaji wa amri moja. Sasa hosts huandaliwa kutoka kwa signed release artifacts kwenye seva za bare-metal za Latitude.sh zenye infra/latitude/provision.sh, njia ya mwongozo inayotumiwa na opereta kwa hosts zilizoidhinishwa ambazo control plane ya mradi huo huzisajili. Canary ya runbook bado inakataa host isiyo na /dev/kvm inayoweza kutumika, kwa hivyo hitaji hilo halijaondoka. Limehamia kwenye bare metal.

Hadi mabadiliko hayo, usanidi uliokuwa umeandikwa ulikuwa amri moja iliyolenga 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

Kwenye main ya sasa, amri hiyo haisakinishi chochote. infra/setup.sh imewekwa alama ya descoped na inajifunga kwenye hatua yake ya kwanza ikiwa na ujumbe kwamba bootstrap ya self-serve haitumiki tena, kabla ya hatua yoyote ya preflight au usakinishaji kuanza. README inasema kuwa visakinishi vya awali vya self-serve sasa vinajifunga na kutoa maelekezo ya kufuata runbook ya managed.

Kwenye commit ambayo chapisho hili liliandikwa kwayo, infra/setup.sh ilifanya preflight kupitia SSH na kusimama mapema wakati sanduku lilikuwa si sahihi. Kukataa kwake kwa maunzi kulikuwa na ujumbe huu:

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

Mstari huo wa kwanza ndio kiini cha chapisho hili. Kisakinishi kiliuliza swali lilelile ulilouliza wewe na ls -l /dev/kvm, na kwenye mipango mingi ya VPS kilipata jibu lilelile la kukatisha tamaa. Runbook ya managed nayo pia inauliza swali hilo.

Baada ya preflight, ilikuwa ni usakinishaji wa sanduku zima: Firecracker na jailer wake, Go toolchain, kernel ya mgeni na root filesystem, picha ya mgeni ya Python, picha ya hiari ya desktop yenye kivinjari, na vitengo viwili vya systemd vilivyoitwa nehemiahd.service na boring-net.service. Health check iliyofeli ilichapisha /healthz didn't return ok, na SKIP_DESKTOP=1 iliruka picha ya desktop, ambayo README ya tarehe hiyo ilisema ilichukua takriban dakika 8 kujenga. Hakuna hatua, ujumbe, au swichi hizo zinazofanya kazi kutoka kwa main ya sasa. Daemon yenyewe bado inajibu kwenye port 8080 kwa chaguo-msingi.

Soma maonyo kabla ya ku-paste amri hiyo

Ilihitaji root SSH kwenye host mpya. Kisakinishi cha self-serve kiliandika vifurushi vya mfumo, systemd units na usanidi wa mtandao kama root. Ikiwa utaendesha commit hiyo isiyoungwa mkono, ielekeze kwenye mashine ambayo uko tayari kuijenga upya kutoka mwanzo, si kwenye seva inayohudumia tovuti yako tayari.

Daemon hufunga 0.0.0.0:8080 kwa chaguo-msingi. Mtu yeyote anayefikia port hiyo anaweza kuunda mashine, na mashine hizo hutumia model key uliyopa host. Weka NEHEMIAH_TOKEN ili kuhitaji uthibitishaji, au weka NEHEMIAH_ADDR=127.0.0.1:8080 (daemon pia hukubali -addr 127.0.0.1:8080) ili ifunge 127.0.0.1 pekee na uifikie kupitia tunnel kwa kutumia ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. Swichi ya BIND_LOCALHOST=1 ya kisakinishi cha zamani haisomwi na daemon, kwa hivyo haifanyi kazi nje ya script hiyo. Ufunguo huo unastahili uangalifu sawa na siri nyingine yoyote kwenye kisanduku, kama ilivyo katika kuhifadhi siri nje ya mawakala wa AI.

Kila mashine ni kompyuta yenye ufikiaji wa internet na mawakala waliosakinishwa awali. README huorodhesha claude, codex, cursor na pi ndani ya guest, kando ya node, python na git. Mradi unasema kuwa guests hukaa nyuma ya egress firewall, na mpaka wa kutengwa wenyewe ni halisi. Guest bado hufikia mtandao kwa muundo wake, kwa sababu wakala wa kuandika msimbo (coding agent) asiyeweza kuchota kifurushi hana faida. Panga kwa ajili ya hilo badala ya kudhani kuna air gap.

Hakuna tagged release. Kufikia 11 Oktoba 2026 hazina (repository) haina tags wala releases, kwa hivyo cloning main inakupa chochote kilichowasili asubuhi hiyo, na leo hiyo ni msimbo wa managed-only pekee. Pin kwenye commit. Ile iliyo hapa chini ni commit ambayo chapisho hili liliandikwa dhidi yake mnamo 10 Agosti 2026, siku moja kabla ya kisakinishi cha self-serve kuondolewa, kwa hivyo infra/setup.sh yake bado inasakinisha. Mradi hauhimili tena njia hiyo, kwa hivyo soma script kabla haijaendeshwa kama root kwenye seva yako:

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

Hazina hiyo iliundwa mwishoni mwa Juni 2026 na kuondoa usakinishaji wake wa self-serve wiki sita baadaye, kwa hivyo ichukulie kama programu changa ambayo njia yake inayoungwa mkono inaweza kubadilika chini yako. Kabla ya kuvuta kitu chochote kipya, soma README na runbook tena, kwa sababu kitu unachoidhinisha ni ufikiaji wa root kwenye mashine, si ongezeko la toleo la maktaba.

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.

Ni kiasi gani cha seva kinachohitajika kwa microVM kadhaa?

Kila microVM hubeba kernel halisi ya mgeni pamoja na kumbukumbu unayoiwekea, na kumbukumbu hiyo hutengwa kwa muda wote ambao mashine hiyo inafanya kazi. Kwa hiyo, kadiria ukubwa wa seva pangishi (host) kulingana na ukubwa wa mgeni na idadi unayotaka kuendesha kwa wakati mmoja. Takwimu hapa chini ni za kihisabati, si vipimo halisi. Mgeni asiye na kiolesura (headless) huchukua 1 GB na mgeni mwenye desktop na kivinjari huchukua 2 GB. Seva pangishi hutenga 3 GB kwa ajili yake yenyewe, daemon, na ujenzi wa image, ambayo ndiyo hifadhi ya kawaida ya daemon (NEHEMIAH_MEM_RESERVE_MB, 3072 MB). Daemon hukataa kuwasha mashine mpya ambayo ingeingilia hifadhi hiyo, hivyo seva pangishi ndogo hufikia uwezo wake wa juu badala ya kuishiwa na kumbukumbu.

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

Mashine moja isiyo na kiolesura kwa wakati mmoja inahitaji takriban 4 GB, ambayo VPS ya ukubwa wa wastani inaweza kuhimili ikiwa inatoa KVM. Nne kati ya hizo zinahitaji 7 GB. Endesha mashine 8 za desktop na hesabu hiyo hiyo inahitaji 19 GB kabla ya kuhesabu hata gigabyte moja ya diski.

Diski ni namba ambayo hakuna mtu anayepanga kwa ajili yake. Seva pangishi huhifadhi kernel ya mgeni, mfumo wa faili wa mizizi (root filesystem), image moja kwa kila aina ya mgeni na snapshot moja kwa kila mashine inayofanya kazi, na image ya desktop yenye kivinjari ndiyo kubwa zaidi. README haitoi takwimu ya diski, kwa hiyo 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 inakupa CPU flags bila hypervisor kuingilia kati, ambayo ndiyo biashara ya kubadilishana 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 gharama nafuu. Kila mashine unayompa wakala hutumia model tokens kwa muda wote inapoendelea kufanya kazi, kwa hiyo microVM iliyokaa bila kazi inagharimu kumbukumbu wakati ile inayofanya kazi inagharimu kumbukumbu na matumizi ya API. Mpango wa 1 GB hauwezi kuhimili seva pangishi. Mpango unaoweza kuhimili seva pangishi bado hautalipia ufunguo (key).

FAQ

Je, nitawezaje kuthibitisha kama VPS yangu inaweza kuendesha Firecracker?

Tekeleza 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 kuwa Firecracker inaweza kufanya kazi. Kifaa kisichokuwepo chenye idadi ya 0 inamaanisha kuwa 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 kufikia host, lakini container inayoweza kufutwa kwenye mashine isiyo na credentials muhimu huondoa hatari nyingi unazokabiliana nazo. Chagua microVM wakati agent inafanya kazi bila kusimamiwa kwa muda mrefu dhidi ya code isiyokaguliwa, na unapoweza kuipa host yenye /dev/kvm. Wakati huwezi kufanya hivyo, 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 (headless) ya 1 GB yenye akiba ya host ya 3 GB inahitaji takriban 4 GB kwa jumla, na guest za desktop 8 za 2 GB kila moja zinahitaji takriban 19 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.