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 Apache-2.0 yang menyediakan mesin Linux sebenar kepada AI atas permintaan, satu microVM Firecracker bagi setiap mesin. Setakat 10 Ogos 2026, README projek tersebut 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".

Perkara itu telah berubah. Pada 11 Ogos 2026, projek tersebut menggantikan dokumentasi persediaan layan diri dengan buku panduan hos terurus, dan README yang disemak pada 11 Oktober 2026 tidak lagi memaparkan baris keperluan tersebut atau pemasangan satu arahan. Hos kini diperuntukkan daripada artifak keluaran yang ditandatangani ke pelayan bare-metal Latitude.sh dengan infra/latitude/provision.sh, satu laluan manual yang dikendalikan oleh operator untuk hos yang diluluskan, yang kemudiannya didaftarkan oleh satah kawalan projek tersebut. Ujian canary dalam buku panduan masih menolak hos yang tidak mempunyai /dev/kvm yang boleh digunakan, jadi keperluan tersebut tidak hilang. Ia beralih kepada bare-metal.

Sehingga perubahan itu berlaku, 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

Pada main semasa, arahan tersebut tidak lagi memasang apa-apa. infra/setup.sh ditandakan sebagai tidak lagi dalam skop dan keluar pada langkah pertamanya dengan mesej bahawa butstrap layan diri tidak lagi disokong, sebelum sebarang langkah pra-penerbangan atau pemasangan dijalankan. README menyatakan bahawa pemasang layan diri yang terdahulu kini keluar dengan penunjuk kepada buku panduan terurus.

Pada komit yang digunakan semasa catatan ini mula ditulis, infra/setup.sh menjalankan pra-penerbangan melalui SSH dan berhenti lebih awal apabila 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 catatan ini. Pemasang tersebut bertanyakan soalan yang sama seperti yang anda baru tanyakan dengan ls -l /dev/kvm, dan pada kebanyakan pelan VPS, ia mendapat jawapan mengecewakan yang sama. Buku panduan terurus juga bertanyakan soalan yang sama.

Melepasi pra-penerbangan, ia merupakan pemasangan keseluruhan kotak: 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. Pemeriksaan kesihatan yang gagal mencetak /healthz didn't return ok, dan SKIP_DESKTOP=1 melangkau imej desktop, yang menurut README pada tarikh tersebut mengambil masa kira-kira 8 minit untuk dibina. Tiada satu pun daripada langkah, mesej atau suis tersebut dijalankan daripada main semasa. Daemon itu sendiri masih menjawab pada port 8080 secara lalai.

Baca amaran sebelum anda menampal arahan tersebut

Ia memerlukan akses root SSH pada hos baharu. Pemasang layan diri tersebut menulis pakej sistem, unit systemd dan konfigurasi rangkaian sebagai root. Jika anda tetap menjalankan commit yang tidak disokong itu, halakan ia ke mesin yang anda sanggup bina semula dari awal, bukan pada pelayan yang sudah menjalankan laman web anda.

Daemon tersebut mengikat 0.0.0.0:8080 secara lalai. Sesiapa sahaja yang mencapai port tersebut boleh mencipta mesin, dan mesin-mesin itu akan menggunakan kunci model yang anda berikan kepada hos. Tetapkan NEHEMIAH_TOKEN untuk mewajibkan pengesahan, atau tetapkan NEHEMIAH_ADDR=127.0.0.1:8080 (daemon juga menerima -addr 127.0.0.1:8080) supaya ia 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. Suis BIND_LOCALHOST=1 pemasang lama tidak dibaca oleh daemon, jadi ia tidak berfungsi di luar skrip tersebut. Kunci ini memerlukan penjagaan yang sama seperti mana-mana rahsia lain pada mesin, seperti dalam menyimpan 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 tetamu berada di belakang firewall keluar, 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 mengandaikan jurang udara (air gap).

Tiada tagged release. Setakat 11 Oktober 2026, repositori ini tidak mempunyai tag dan tiada release, jadi melakukan clone pada main akan memberikan anda apa sahaja yang dimasukkan pada pagi itu, dan hari ini ia adalah kod managed-only. Pin pada commit tertentu. Yang di bawah adalah commit yang digunakan semasa catatan ini ditulis pada 10 Ogos 2026, sehari sebelum pemasang layan diri ditarik balik, jadi infra/setup.sh miliknya masih boleh dipasang. Projek ini tidak lagi menyokong laluan tersebut, jadi baca skrip sebelum ia berjalan 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 akhir Jun 2026 dan menarik balik pemasangan layan diri enam minggu kemudian, jadi anggap ia sebagai perisian baharu yang laluan sokongannya boleh berubah pada bila-bila masa. Sebelum anda menarik apa-apa yang lebih baharu, baca semula README dan runbook, 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 keperluan pelayan untuk beberapa microVM?

Setiap microVM mengandungi kernel tetamu sebenar berserta memori yang anda peruntukkan, dan memori tersebut dikunci selagi mesin itu berjalan. Oleh itu, tentukan saiz hos berdasarkan saiz tetamu dan jumlah 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 mengekalkan 3 GB sebagai simpanan tetap untuk kegunaan sistem, daemon, dan pembinaan imej, iaitu rizab lalai daemon (NEHEMIAH_MEM_RESERVE_MB, 3072 MB). Daemon akan menolak untuk memulakan mesin baharu yang akan menggunakan rizab tersebut, jadi hos yang bersaiz kecil akan mencapai kapasiti maksimum dan bukannya kehabisan memori.

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

Satu mesin headless pada satu masa memerlukan kira-kira 4 GB, yang boleh ditampung oleh VPS bersaiz sederhana apabila ia menyediakan KVM. Empat mesin sedemikian memerlukan 7 GB. Jalankan 8 mesin desktop dan pengiraan aritmetik yang sama memerlukan 19 GB sebelum anda mengira walau 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. 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" sering kali 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 merangkumi cara untuk mengesahkannya sebelum anda membayar. Jika perkakasan itu 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 boleh 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, 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 mengembalikan 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 kepada ejen pengekodan?

Selalunya ya. Container berkongsi kernel anda, jadi pelarian tahap kernel boleh mencapai hos, tetapi container pakai buang pada mesin yang tidak menyimpan kelayakan berharga 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 memberikannya hos dengan /dev/kvm. Apabila anda tidak boleh, container yang anda musnahkan selepas setiap tugasan adalah lebih baik daripada microVM yang anda tidak pernah berjaya boot.

Berapakah jumlah RAM yang diperlukan oleh hos ejen microVM?

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