Cara Semak Sokongan Firecracker microVM pada VPS

Bolehkah VPS anda menjalankan Firecracker microVM?

VPS anda hanya boleh menjalankan Firecracker microVM jika ia menyediakan /dev/kvm. Firecracker ialah VMM (virtual machine monitor) yang dibina berasaskan KVM (kernel-based virtual machine), iaitu lapisan virtualisasi di dalam Linux, dan KVM memerlukan arahan virtualisasi daripada CPU. Pada VPS, anda hanya mendapat arahan tersebut apabila penyedia melalukannya (pass-through) kepada tetamu anda, dan kebanyakan pelan tidak menyediakannya.

Oleh itu, soalan pertama bukanlah alat microVM mana yang perlu dipasang. Soalannya ialah sama ada mesin yang anda bayar sekarang mampu menjadi hos untuknya atau tidak. Ini ialah soalan berkaitan pengehosan, dan anda boleh menjawabnya dalam masa kira-kira satu minit.

Semak /dev/kvm sebelum anda memasang apa-apa

Jalankan tiga perintah ini pada VPS itu sendiri.

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

Kotak yang boleh mengehoskan microVM akan memberi respons seperti ini:

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

Baris pertama ialah nod peranti KVM, yang dimiliki oleh kumpulan kvm. Baris kedua menyatakan bahawa mesin ini sendiri merupakan tetamu yang berjalan di bawah KVM, yang merupakan perkara biasa dan dijangkakan pada VPS. Baris ketiga mengira teras CPU yang melaporkan flag virtualisasi perkakasan, vmx pada Intel dan svm pada AMD. Kiraan melebihi sifar di dalam tetamu bermakna hypervisor mendedahkan virtualisasi bersarang (nested virtualisation) kepada anda.

Kemudian, pastikan pengguna anda boleh membuka peranti tersebut. Ini adalah ujian daripada dokumen permulaan Firecracker sendiri:

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

FAIL semasa nod wujud adalah masalah kebenaran dan bukannya masalah perkakasan. Berikan akses kepada pengguna anda sendiri dengan sudo setfacl -m u:${USER}:rw /dev/kvm, atau tambahkan diri anda ke dalam kumpulan tersebut dengan sudo usermod -aG kvm ${USER} dan log masuk semula.

Ubuntu juga menyediakan semakan yang meringkaskan semua ini dalam dua baris output:

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

Hos yang berfungsi akan mencetak INFO: /dev/kvm exists dan kemudian KVM acceleration can be used. Hos yang tidak berfungsi akan mencetak INFO: Your CPU does not support KVM extensions dan kemudian KVM acceleration can NOT be used. Pada mesin fizikal, anda mungkin melihat INFO: KVM (vmx) is disabled by your BIOS sebaliknya, yang boleh dibaiki dalam firmware. Pada VPS, mesej tersebut jarang berlaku kerana anda tidak melihat firmware sebenar.

Apakah maksud setiap jawapan /dev/kvm?

Nod wujud dan kiraan flag melebihi sifar. Anda mempunyai virtualisasi perkakasan, jadi Firecracker akan berjalan. Teruskan ke bahagian saiz, kerana kekangan anda yang seterusnya ialah memori dan bukannya ciri CPU.

Tiada nod, systemd-detect-virt mencetak kvm atau qemu, dan kiraan flag ialah 0. VPS anda ialah mesin maya yang hosnya tidak membenarkan virtualisasi melaluinya. Tiada apa-apa yang anda pasang di dalam guest akan mengubah perkara ini, kerana flag tersebut adalah sifat CPU maya yang dibina oleh hypervisor untuk anda. sudo modprobe kvm_intel gagal dengan modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, dan sudo dmesg | grep -i kvm merekodkan ketiadaan sokongan perkakasan. Ini adalah kes biasa pada pelan VPS kongsi. Tanya penyedia sama ada pelan tersebut menyokong virtualisasi bersarang (nested virtualisation). Jika jawapannya tidak, anda memerlukan hosting lain, bukan arahan lain.

systemd-detect-virt mencetak lxc, lxc-libvirt atau openvz. Pelan anda ialah virtualisasi kontena, jadi anda berkongsi kernel hos. /dev/kvm tidak akan muncul, kerana anda tidak mempunyai kernel sendiri untuk memuatkan modul. Tiada pakej yang boleh membaiki perkara ini.

Flag ada tetapi nod tiada. Modul tersebut hanya tidak dimuatkan. Jalankan sudo modprobe kvm_intel (atau kvm_amd pada AMD) dan semak ls -l /dev/kvm sekali lagi. Jika nod muncul, tulis nama modul ke dalam /etc/modules-load.d/kvm.conf supaya ia kembali selepas but semula.

Anda berada pada arm64. vmx dan svm ialah nama x86, jadi kiraan grep adalah 0 pada setiap mesin arm64, sama ada ia berfungsi atau tidak. Pada arm64, percayai nod peranti serta ujian baca dan tulis sebagai gantinya.

Mengapa menggunakan microVM dan bukan container untuk kerja ejen

Container ialah proses pada kernel anda, yang dipisahkan dengan namespaces dan cgroups. Terdapat satu kernel dan ia adalah milik anda, jadi pelarian pada tahap kernel akan terus menjejaskan hos. Sebuah microVM memulakan kernelnya sendiri di dalam sempadan virtualisasi perkakasan, dan ia berhubung dengan model peranti emulasi yang kecil dan bukannya dengan keseluruhan permukaan panggilan sistem (system call) hos anda. Firecracker mengekalkan model tersebut supaya sengaja dikecilkan, yang merupakan keseluruhan reka bentuknya: lebih sedikit peranti emulasi bermakna lebih sedikit jalan keluar.

Perbezaan itu penting bagi ejen pengekodan, kerana kod yang dijalankan oleh ejen adalah kod yang tidak dibaca oleh sesiapa pun terlebih dahulu. Ia memasang pakej, ia menjalankan skrip binaan, dan ia mencuba semula pada kelajuan mesin apabila sesuatu gagal. Kernel yang berasingan bermakna langkah yang buruk hanya merosakkan mesin yang boleh anda padamkan, dan tiada yang lain.

Keperluan tersebut terhasil secara langsung daripada mekanismenya. Pengasingan perkakasan memerlukan virtualisasi perkakasan, dan virtualisasi perkakasan adalah perkara yang mungkin tidak disediakan oleh pelan VPS anda. Container tidak memerlukan sebarang virtualisasi, itulah sebabnya container boleh dijalankan pada setiap pelan yang pernah dijual.

Jadi apabila /dev/kvm tiada, VM pakai buang untuk ejen pengekodan berasaskan container kekal sebagai jawapan yang tepat, dan ia merupakan kawalan sebenar dan bukannya sekadar pilihan alternatif. Container pakai buang, pada hos yang tidak menyimpan sebarang kelayakan yang anda pentingkan, yang dipulihkan daripada snapshot apabila ia berkelakuan tidak sepatutnya, akan menghentikan kebanyakan perkara yang sebenarnya boleh menjadi masalah. Perkara yang sama berlaku pada persediaan yang lebih ringkas dalam menjalankan ejen pengekodan pada VPS. Gunakan microVM apabila ejen akan berjalan tanpa pengawasan, selama berjam-jam, terhadap kod yang belum anda semak, dan apabila hos tersebut adalah milik anda sepenuhnya.

Keperluan hos ejen microVM

Nehemiah merupakan contoh semasa bagi kelas ini: daemon berlesen Apache-2.0 yang menyediakan mesin Linux sebenar kepada AI atas permintaan, dengan satu microVM Firecracker bagi setiap mesin. README-nya menyatakan keperluan tersebut tanpa berselindung: "sebuah kotak Linux dengan /dev/kvm", dan lebih tepat lagi "Ubuntu 24.04, x86_64 atau arm64, dengan /dev/kvm (bare-metal, atau VM dengan virtualisasi bersarang) yang boleh diakses melalui root-SSH".

Persediaan yang didokumentasikan adalah satu arahan yang ditujukan kepada kotak tersebut:

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 menjalankan pemeriksaan pra-pelancaran (preflight) melalui SSH dan berhenti lebih awal jika kotak tersebut tidak menepati syarat. Dua penolakan perkakasan yang dipaparkannya berbunyi:

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

Rentetan pertama itu adalah inti pati utama hantaran ini. Pemasang tersebut bertanyakan soalan yang sama seperti yang anda baru ajukan dengan ls -l /dev/kvm, dan pada kebanyakan pelan VPS, ia mendapat jawapan mengecewakan yang sama.

Melepasi peringkat pra-pelancaran, ia merupakan pemasangan penuh pada kotak tersebut: Firecracker dan jailer-nya, rantaian alat Go, kernel tetamu dan sistem fail root, imej tetamu Python, imej desktop pilihan dengan pelayar, serta dua unit systemd yang dinamakan nehemiahd.service dan boring-net.service. Daemon tersebut kemudiannya menjawab pada port 8080, dan pemeriksaan kesihatan yang gagal akan mencetak /healthz didn't return ok. SKIP_DESKTOP=1 melangkau imej desktop, yang menurut README mengambil masa kira-kira 8 minit untuk dibina.

Baca amaran sebelum anda menampal arahan tersebut

Ia memerlukan akses root SSH pada hos baharu. Pemasang menulis pakej sistem, unit systemd dan konfigurasi rangkaian sebagai root. Halakan ia kepada mesin yang anda sanggup bina semula dari awal, bukan pada pelayan yang sudah menjalankan tapak web anda.

Daemon ini mengikat 0.0.0.0:8080 secara lalai. Sesiapa sahaja yang mencapai port tersebut boleh mencipta mesin, dan mesin tersebut akan menggunakan kunci model yang anda berikan kepada pemasang. Tetapkan NEHEMIAH_TOKEN untuk memerlukan pengesahan, atau tetapkan BIND_LOCALHOST=1 supaya daemon hanya mengikat 127.0.0.1 dan anda mencapainya melalui terowong dengan ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. Kunci tersebut memerlukan penjagaan yang sama seperti mana-mana rahsia lain pada kotak tersebut, seperti dalam menjaga rahsia daripada ejen AI.

Setiap mesin ialah komputer dengan akses internet dan ejen yang diprapasang. README menyenaraikan claude, codex, cursor dan pi di dalam tetamu, di samping node, python dan git. Projek ini menyatakan bahawa tetamu berada di belakang firewall egress, dan sempadan pengasingan itu sendiri adalah nyata. Tetamu masih mencapai rangkaian mengikut reka bentuk, kerana ejen pengekodan yang tidak boleh mengambil pakej adalah tidak berguna. Rancang untuk perkara itu dan jangan menganggap adanya jurang udara (air gap).

Tiada keluaran bertag (tagged release). Setakat 10 Ogos 2026, repositori tersebut tidak mempunyai sebarang tag, jadi melakukan cloning main akan memberikan anda apa sahaja yang dimuat naik pada pagi itu. Pin pada commit tertentu, dan baca skrip sebelum ia dijalankan sebagai root pada pelayan anda:

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

Repositori ini dicipta pada penghujung Jun 2026, jadi anggap ia sebagai perisian baharu. Baca infra/setup.sh semula selepas setiap kemas kini yang anda tarik, kerana perkara yang anda luluskan ialah akses root kepada mesin, bukan sekadar peningkatan versi pustaka.

Pastikan KVM berfungsi sebelum menyalahkan pemasang

Jika persediaan gagal dan anda ingin mengetahui sama ada KVM puncanya, uji Firecracker secara berasingan. Berikut adalah langkah muat turun daripada sumber asal:

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

Versi yang dicetak membuktikan binari tersebut sepadan dengan seni bina anda dan boleh dijalankan. Ia tidak membuktikan akses KVM, jadi gabungkan dengan ujian baca dan tulis pada /dev/kvm daripada langkah sebelum ini. Kedua-duanya secara bersama memisahkan masalah pengehosan daripada masalah pakej, yang menyelamatkan anda daripada menyahpepijat pemasang yang sebenarnya berfungsi dengan betul.

Berapakah kapasiti pelayan yang diperlukan untuk beberapa microVM?

Setiap microVM mengandungi kernel tetamu sebenar berserta memori yang anda peruntukkan, dan memori tersebut akan dikunci selagi mesin itu berjalan. Oleh itu, tentukan saiz hos berdasarkan saiz tetamu dan bilangan mesin yang anda mahu jalankan serentak. Angka di bawah adalah pengiraan aritmetik, bukan ukuran sebenar. Tetamu tanpa antara muka grafik (headless) memerlukan 1 GB, manakala tetamu desktop dengan pelayar web memerlukan 2 GB. Hos perlu menyimpan 2 GB secara tetap untuk kegunaan sendiri, daemon, dan pembinaan imej.

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

Satu mesin headless pada satu masa memerlukan kira-kira 3 GB, yang boleh ditampung oleh VPS bersaiz sederhana apabila ia menyediakan KVM. Empat mesin tersebut memerlukan 6 GB. Jalankan 8 mesin desktop dan pengiraan yang sama memerlukan 18 GB sebelum anda mengira walaupun satu gigabait cakera.

Cakera adalah perkara yang sering tidak dirancang. Hos menyimpan kernel tetamu, sistem fail root asas, satu imej bagi setiap jenis tetamu, dan satu snapshot bagi setiap mesin yang berjalan; imej desktop dengan pelayar web adalah yang paling besar. Fail README tidak memberikan angka cakera, jadi pantau df -h / semasa pembinaan pertama daripada mempercayai anggaran.

Inilah sebabnya jawapan jujur kepada soalan "VPS manakah yang menjalankan Firecracker" selalunya adalah "kelas mesin yang berbeza". Bare metal memberikan anda flag CPU tanpa hypervisor yang menghalang, yang merupakan pertukaran dalam memilih antara VPS dan pelayan berdedikasi. Sesetengah penyedia memang mendedahkan virtualisasi bersarang (nested virtualisation) pada pelan maya, dan virtualisasi bersarang pada VPS menerangkan cara untuk mengesahkannya sebelum anda membayar. Jika perkakasan sudah menjadi milik anda, Proxmox berbanding VPS biasa adalah soalan yang sama yang ditanya dari sisi hypervisor.

Pelayan juga merupakan bahagian yang murah. Setiap mesin yang anda berikan kepada ejen akan menggunakan token model selagi ia berjalan, jadi microVM yang melahu menelan kos memori manakala yang sibuk menelan kos memori dan perbelanjaan API. Pelan 1 GB tidak dapat menampung hos. Pelan yang mampu menampung hos tetap tidak akan membayar kunci tersebut.

FAQ

Bagaimanakah cara untuk menyemak sama ada VPS saya boleh menjalankan Firecracker?

Jalankan ls -l /dev/kvm, systemd-detect-virt dan grep -cE '\b(vmx|svm)\b' /proc/cpuinfo pada VPS tersebut. Node peranti yang dimiliki oleh kumpulan kvm, berserta kiraan flag melebihi sifar, bermakna Firecracker boleh dijalankan. Node yang tiada dengan kiraan 0 bermakna hypervisor tidak melalukan virtualisasi, dan sudo kvm-ok daripada pakej cpu-checker mengesahkannya dengan KVM acceleration can NOT be used. Pada arm64, abaikan kiraan tersebut kerana vmx dan svm adalah nama untuk x86.

Bolehkah saya mendayakan virtualisasi bersarang (nested virtualisation) dari dalam VPS saya?

Tidak. Virtualisasi bersarang dihidupkan oleh hos, di dalam modul kernel hypervisor itu sendiri, dan ia sampai kepada anda sebagai flag CPU pada pemproses maya yang diberikan kepada anda. Di dalam guest, sudo modprobe kvm_intel akan memulangkan modprobe: ERROR: could not insert 'kvm_intel': Operation not supported kerana CPU maya tidak mempunyai VMX untuk digunakan. Pilihan anda ialah penyedia yang menawarkan virtualisasi bersarang pada pelan tersebut, atau mesin di mana anda memiliki hypervisornya.

Adakah container mencukupi untuk melakukan sandbox terhadap ejen pengekodan?

Selalunya ya. Container berkongsi kernel anda, jadi pelarian (escape) pada tahap kernel akan sampai ke hos, namun container pakai buang pada mesin yang tidak menyimpan kelayakan (credentials) penting akan menghapuskan kebanyakan risiko yang anda hadapi sebenarnya. Pilih microVM apabila ejen berjalan tanpa pengawasan untuk tempoh yang lama terhadap kod yang tidak disemak, dan apabila anda boleh memberikan hos dengan /dev/kvm. Apabila anda tidak boleh berbuat demikian, container yang anda musnahkan selepas setiap tugasan adalah lebih baik daripada microVM yang anda tidak pernah berjaya butkan.

Berapakah jumlah RAM yang diperlukan oleh hos ejen microVM?

Mulakan daripada saiz guest. Satu guest tanpa kepala (headless) pada 1 GB dengan rizab hos 2 GB memerlukan kira-kira 3 GB secara keseluruhan, dan 8 guest desktop pada 2 GB setiap satu memerlukan kira-kira 18 GB. Storan cakera adalah berasingan dan mudah dipandang rendah, kerana hos menyimpan kernel, sistem fail root, satu imej bagi setiap jenis guest dan satu snapshot bagi setiap mesin yang sedang berjalan.