VPS của bạn có chạy được Firecracker không?

VPS của bạn có chạy được Firecracker microVM không?

VPS của bạn chỉ chạy được Firecracker microVM nếu nhà cung cấp cấp cho bạn /dev/kvm. Firecracker là một VMM (virtual machine monitor) xây dựng trên KVM (kernel-based virtual machine), lớp ảo hóa bên trong Linux. KVM cần các instruction ảo hóa từ CPU. Trên VPS, bạn chỉ có các instruction này khi nhà cung cấp chuyển tiếp chúng vào guest của bạn, nhưng phần lớn gói dịch vụ không hỗ trợ.

Vì vậy, câu hỏi đầu tiên không phải là nên cài công cụ microVM nào. Câu hỏi là máy bạn đang thuê có thực sự host được microVM hay không. Đây là vấn đề thuộc về hạ tầng hosting và bạn có thể kiểm tra trong khoảng một phút.

Kiểm tra /dev/kvm trước khi cài bất kỳ thứ gì

Chạy 3 lệnh sau trực tiếp trên VPS.

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

Một máy có thể chạy microVM sẽ trả về như sau:

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

Dòng đầu tiên là device node KVM, thuộc group kvm. Dòng thứ hai cho biết máy này bản thân đang là guest chạy trên KVM. Đây là trạng thái bình thường và được mong đợi trên VPS. Dòng thứ ba đếm số CPU core báo cáo hardware virtualisation flag, vmx trên Intel và svm trên AMD. Giá trị lớn hơn 0 bên trong guest nghĩa là hypervisor đang bật nested virtualisation cho bạn.

Sau đó kiểm tra xem user của bạn có thể mở device này hay không. Đây là phép kiểm tra trong tài liệu getting started của Firecracker:

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

FAIL trong khi node vẫn tồn tại nghĩa là có vấn đề về quyền, không phải vấn đề phần cứng. Cấp quyền truy cập cho user của bạn bằng sudo setfacl -m u:${USER}:rw /dev/kvm, hoặc thêm user của bạn vào group bằng sudo usermod -aG kvm ${USER} rồi đăng nhập lại.

Ubuntu cũng có một phép kiểm tra tóm tắt tất cả nội dung này trong 2 dòng output:

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

Host hoạt động sẽ in INFO: /dev/kvm exists, sau đó là KVM acceleration can be used. Host không hoạt động sẽ in INFO: Your CPU does not support KVM extensions, sau đó là KVM acceleration can NOT be used. Trên máy vật lý, bạn có thể thấy INFO: KVM (vmx) is disabled by your BIOS thay vào đó. Lỗi này có thể sửa trong firmware. Trên VPS, thông báo đó hiếm gặp vì bạn không truy cập firmware thật.

Mỗi kết quả của /dev/kvm có ý nghĩa gì?

Node tồn tại và số lượng flag lớn hơn 0. Máy có hardware virtualisation, nên Firecracker sẽ chạy được. Chuyển đến phần sizing, vì giới hạn còn lại là bộ nhớ chứ không phải tính năng CPU.

Không có node, systemd-detect-virt in ra kvm hoặc qemu, và số lượng flag là 0. VPS của bạn là một virtual machine nhưng host không truyền virtualisation xuống guest. Không có gì bạn cài bên trong guest có thể thay đổi điều này, vì flag là thuộc tính của virtual CPU do hypervisor tạo cho bạn. sudo modprobe kvm_intel fail với modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, và sudo dmesg | grep -i kvm ghi nhận hardware support bị thiếu. Đây là trường hợp phổ biến trên các gói VPS dùng chung. Hỏi nhà cung cấp xem gói có hỗ trợ nested virtualisation không. Nếu không, bạn cần đổi loại hosting, không phải đổi command.

systemd-detect-virt in ra lxc, lxc-libvirt hoặc openvz. Gói của bạn dùng container virtualisation, nên bạn dùng chung kernel của host. /dev/kvm sẽ không bao giờ xuất hiện, vì bạn không có kernel riêng để load module vào. Không có package nào khắc phục được việc này.

Các flag có nhưng node không tồn tại. Module chỉ chưa được load. Chạy sudo modprobe kvm_intel (hoặc kvm_amd trên AMD) rồi kiểm tra lại ls -l /dev/kvm. Nếu node xuất hiện, ghi tên module vào /etc/modules-load.d/kvm.conf để module được load lại sau khi reboot.

Bạn đang dùng arm64. vmx và svm là tên dành cho x86, nên số lượng grep luôn là 0 trên mọi máy arm64, dù máy có hoạt động hay không. Trên arm64, hãy dựa vào device node và kiểm tra đọc ghi thay thế.

Vì sao dùng microVM thay vì container cho tác vụ của agent

Container là một tiến trình chạy trên kernel của bạn, được cô lập bằng namespace và cgroup. Chỉ có một kernel và đó là kernel của bạn, nên nếu thoát khỏi kernel thì tiến trình sẽ xâm nhập được vào host. microVM khởi động một kernel riêng bên trong ranh giới ảo hóa phần cứng. Nó giao tiếp với một mô hình thiết bị giả lập nhỏ thay vì toàn bộ bề mặt system call của host. Firecracker cố ý giữ mô hình này ở mức tối thiểu. Đây là toàn bộ thiết kế: càng ít thiết bị giả lập thì càng ít đường thoát.

Điểm khác biệt này quan trọng với coding agent, vì code mà agent chạy là code chưa được ai đọc trước. Agent cài package, chạy build script và tự retry ở tốc độ của máy khi có lỗi. Kernel riêng nghĩa là một bước sai chỉ làm hỏng một máy mà bạn có thể xóa, không ảnh hưởng đến phần còn lại.

Yêu cầu này xuất phát trực tiếp từ cơ chế hoạt động. Cô lập bằng phần cứng cần hardware virtualization, nhưng hardware virtualization có thể không được gói VPS của bạn cung cấp. Container không cần tính năng này. Vì vậy, container chạy được trên mọi gói từng được bán.

Do đó, khi /dev/kvm bị thiếu, VM dùng một lần cho coding agent dựa trên container vẫn là lựa chọn đúng. Đây là một biện pháp kiểm soát thực sự, không phải phương án tạm bợ. Một container dùng một lần trên host không chứa credential quan trọng, được khôi phục từ snapshot mỗi khi hoạt động bất thường, sẽ ngăn chặn phần lớn các sự cố thực tế. Điều tương tự cũng đúng với cách thiết lập đơn giản hơn trong chạy coding agent trên VPS. Hãy dùng microVM khi agent sẽ chạy không giám sát trong nhiều giờ trên code bạn chưa review, và khi host thuộc quyền kiểm soát của bạn.

Yêu cầu của host chạy microVM agent

Nehemiah là một ví dụ hiện tại trong nhóm này: một daemon Apache-2.0 cấp cho AI một máy Linux thật theo nhu cầu, với một Firecracker microVM cho mỗi máy. README nêu rõ yêu cầu: “một máy Linux có /dev/kvm”, cụ thể hơn là “Ubuntu 24.04, x86_64 hoặc arm64, có /dev/kvm (bare-metal hoặc VM có nested virtualization) để bạn có thể SSH bằng root vào đó”.

Cách cài đặt được tài liệu hướng dẫn là chạy một command trên máy đó:

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 chạy kiểm tra trước qua SSH và dừng ngay nếu máy không đáp ứng yêu cầu. Hai thông báo từ chối phần cứng là:

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

Chuỗi đầu tiên chính là điểm mấu chốt của bài viết này. Installer đặt đúng câu hỏi mà bạn vừa đặt bằng ls -l /dev/kvm, và trên hầu hết gói VPS, nó nhận được cùng một câu trả lời đáng thất vọng.

Sau bước kiểm tra trước, đây là quá trình cài đặt toàn bộ trên máy: Firecracker và jailer của nó, Go toolchain, kernel và root filesystem của guest, Python guest image, một desktop image tùy chọn có trình duyệt, cùng hai systemd unit có tên nehemiahd.service và boring-net.service. Sau đó daemon lắng nghe trên port 8080. Nếu health check thất bại, nó in ra /healthz didn't return ok. SKIP_DESKTOP=1 bỏ qua desktop image. README cho biết quá trình build image này mất khoảng 8 phút.

Đọc các điểm cần lưu ý trước khi dán lệnh đó

Lệnh này yêu cầu SSH root trên một host mới. Installer ghi các system package, systemd unit và cấu hình mạng với quyền root. Hãy trỏ nó vào một máy mà bạn sẵn sàng rebuild từ đầu, không phải server đang chạy website của bạn.

Daemon bind vào 0.0.0.0:8080 theo mặc định. Bất kỳ ai truy cập được cổng đó đều có thể tạo machine, và các machine đó sẽ sử dụng model key bạn đã cung cấp cho installer. Đặt NEHEMIAH_TOKEN để yêu cầu authentication, hoặc đặt BIND_LOCALHOST=1 để daemon chỉ bind vào 127.0.0.1, rồi truy cập qua tunnel bằng ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. Hãy bảo vệ key như mọi secret khác trên máy, tương tự như giữ secret ngoài các AI agent.

Mỗi machine là một computer có quyền truy cập Internet và đã cài sẵn agent. README liệt kê claude, codex, cursor và pi bên trong guest, cùng với node, python và git. Project cho biết guest nằm sau egress firewall, và boundary isolation là có thật. Tuy vậy, guest vẫn truy cập được network theo thiết kế, vì coding agent không thể fetch package thì không có tác dụng. Hãy lập kế hoạch cho điều đó thay vì giả định hệ thống là air gap.

Không có release được tag. Tính đến ngày 10 August 2026, repository hoàn toàn không có tag, nên clone main sẽ lấy đúng những gì được đưa vào repository trong buổi sáng hôm đó. Hãy pin vào một commit và đọc script trước khi cho script chạy với quyền root trên server:

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

Repository được tạo vào cuối June 2026, vì vậy hãy xem đây là software còn mới. Đọc lại infra/setup.sh sau mỗi lần pull update, vì thứ bạn đang phê duyệt là quyền root vào một máy, không phải việc nâng version của một library.

Xác nhận KVM hoạt động trước khi đổ lỗi cho trình cài đặt

Nếu quá trình thiết lập thất bại và bạn muốn biết KVM có phải là nguyên nhân hay không, hãy tự kiểm tra Firecracker. Đây là các bước tải xuống từ upstream:

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

Lệnh in ra version xác nhận binary phù hợp với architecture của bạn và có thể chạy. Lệnh này không xác nhận quyền truy cập KVM, vì vậy hãy kết hợp với bài kiểm tra read và write trên /dev/kvm ở phần trước. Hai bước này giúp phân biệt sự cố từ hosting với sự cố đóng gói, nhờ đó bạn không phải debug một trình cài đặt vốn hoạt động đúng.

Cần bao nhiêu tài nguyên máy chủ cho vài microVM?

Mỗi microVM chứa một guest kernel thực và dùng lượng memory bạn cấp cho nó. Lượng memory này được giữ trong suốt thời gian máy chạy. Vì vậy, hãy tính cấu hình host dựa trên kích thước guest và số lượng máy bạn muốn chạy đồng thời. Các con số dưới đây là phép tính, không phải số liệu đo thực tế. Guest không có giao diện đồ họa dùng 1 GB, còn guest desktop có browser dùng 2 GB. Host giữ lại cố định 2 GB cho chính nó, daemon và việc build 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
  }
]

Một máy không có giao diện đồ họa chạy mỗi lần cần khoảng 3 GB. Một VPS tầm trung có thể đáp ứng mức này nếu được cấp KVM. Bốn máy cần 6 GB. Chạy 8 máy desktop thì phép tính tương tự cần 18 GB, chưa tính một GB disk nào.

Disk là phần thường bị bỏ sót khi lập kế hoạch. Host lưu guest kernel, base root filesystem, một image cho mỗi loại guest và một snapshot cho mỗi máy đang chạy. Image desktop có browser là image chiếm nhiều dung lượng nhất. README không đưa ra con số disk, vì vậy hãy theo dõi df -h / trong lần build đầu tiên thay vì dựa vào ước tính.

Đây là lý do câu trả lời trung thực cho câu hỏi "VPS nào chạy được Firecracker" thường là "một loại máy khác". Bare metal cung cấp các CPU flag mà không bị hypervisor can thiệp. Đây là điểm cần cân nhắc khi chọn giữa VPS và dedicated server. Một số nhà cung cấp có bật nested virtualisation trên các gói máy ảo. Nested virtualisation trên VPS hướng dẫn cách xác nhận tính năng này trước khi thanh toán. Nếu phần cứng đã thuộc quyền sử dụng của bạn, Proxmox so với VPS thông thường cũng là câu hỏi tương tự nhưng xét từ phía hypervisor.

Server cũng chỉ là phần chi phí thấp. Mỗi máy bạn giao cho một agent sẽ tiêu tốn model token trong suốt thời gian chạy. Vì vậy, một microVM nhàn rỗi vẫn tốn memory, còn microVM đang hoạt động tốn cả memory và chi phí API. Gói 1 GB không thể chứa host. Một gói đủ chứa host vẫn không tự trả được chi phí key.

FAQ

Làm cách nào để kiểm tra VPS có thể chạy Firecracker hay không?

Chạy ls -l /dev/kvm, systemd-detect-virt và grep -cE '\b(vmx|svm)\b' /proc/cpuinfo trên VPS. Một device node thuộc group kvm, cùng với số lượng flag lớn hơn 0, cho biết Firecracker có thể chạy. Nếu node không tồn tại và số lượng bằng 0, hypervisor không truyền khả năng virtualisation vào guest. sudo kvm-ok trong package cpu-checker xác nhận điều này bằng KVM acceleration can NOT be used. Trên arm64, bỏ qua số lượng vì vmx và svm là tên dùng trên x86.

Có thể bật nested virtualisation từ bên trong VPS không?

Không. Host bật nested virtualisation trong kernel module riêng của hypervisor. Tính năng này được truyền đến bạn dưới dạng CPU flag trên virtual processor được cấp. Bên trong guest, sudo modprobe kvm_intel trả về modprobe: ERROR: could not insert 'kvm_intel': Operation not supported vì virtual CPU không có VMX để sử dụng. Bạn có thể chọn provider cung cấp nested virtualisation trong plan, hoặc một máy mà bạn sở hữu hypervisor.

Container có đủ để sandbox coding agent không?

Thường là đủ. Container dùng chung kernel với host, nên kernel-level escape có thể truy cập host. Tuy nhiên, một container dùng tạm trên máy không lưu credential quan trọng sẽ loại bỏ phần lớn rủi ro thực tế. Hãy chọn microVM khi agent chạy unattended trong thời gian dài với code chưa được review, và khi bạn có thể cấp cho nó một host có /dev/kvm. Nếu không thể, container bị xóa sau mỗi task vẫn tốt hơn microVM mà bạn không bao giờ khởi động được.

Host chạy agent trong microVM cần bao nhiêu RAM?

Bắt đầu từ kích thước guest. Một guest headless có 1 GB RAM và host reserve 2 GB cần tổng cộng khoảng 3 GB. 8 desktop guest, mỗi guest có 2 GB, cần khoảng 18 GB. Disk là phần riêng và thường dễ bị ước tính thiếu, vì host phải giữ kernel, root filesystem, một image cho mỗi loại guest và một snapshot cho mỗi máy đang chạy.