วิธีเช็คว่า VPS ของคุณรองรับ Firecracker microVM หรือไม่

VPS ของคุณสามารถรัน Firecracker microVM ได้หรือไม่

VPS ของคุณจะรัน Firecracker microVM ได้ก็ต่อเมื่อผู้ให้บริการมอบ /dev/kvm ให้กับคุณเท่านั้น Firecracker เป็น VMM (virtual machine monitor) ที่สร้างขึ้นบน KVM (kernel-based virtual machine) ซึ่งเป็นเลเยอร์การทำ virtualisation ภายใน Linux และ KVM จำเป็นต้องใช้คำสั่ง virtualisation จาก CPU ในการทำงาน บน VPS คุณจะได้รับคำสั่งเหล่านี้ก็ต่อเมื่อผู้ให้บริการส่งผ่าน (pass through) มายัง guest ของคุณ ซึ่งแผนบริการส่วนใหญ่ไม่ได้เปิดใช้งานคุณสมบัตินี้

ดังนั้น คำถามแรกจึงไม่ใช่ว่าจะติดตั้งเครื่องมือ microVM ตัวใด แต่เป็นคำถามว่าเครื่องที่คุณจ่ายเงินเช่าอยู่นั้นสามารถโฮสต์ microVM ได้หรือไม่ ซึ่งเป็นประเด็นเรื่องการโฮสต์ที่คุณสามารถตรวจสอบคำตอบได้ภายในเวลาไม่ถึงหนึ่งนาที

ตรวจสอบ /dev/kvm ก่อนดำเนินการติดตั้งใดๆ

ให้รันคำสั่งทั้งสามนี้บน VPS โดยตรง

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

เครื่องที่สามารถโฮสต์ microVM ได้จะแสดงผลลัพธ์ดังนี้:

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

บรรทัดแรกคือ device node ของ KVM ซึ่งเป็นเจ้าของโดยกลุ่ม kvm บรรทัดที่สองระบุว่าเครื่องนี้เป็น guest ที่รันอยู่ภายใต้ KVM ซึ่งเป็นเรื่องปกติและคาดการณ์ได้สำหรับ VPS บรรทัดที่สามนับจำนวนคอร์ CPU ที่รายงานสถานะ hardware virtualisation flag คือ vmx สำหรับ Intel และ svm สำหรับ AMD หากจำนวนมากกว่าศูนย์ภายใน guest หมายความว่า hypervisor ได้เปิดใช้งาน nested virtualisation ให้คุณแล้ว

จากนั้นให้ตรวจสอบว่าผู้ใช้ของคุณสามารถเปิดอุปกรณ์ดังกล่าวได้หรือไม่ นี่คือการทดสอบจากเอกสารเริ่มต้นใช้งานของ Firecracker:

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

FAIL ในขณะที่ node มีอยู่จริง แสดงว่าเป็นปัญหาเรื่องสิทธิ์การเข้าถึง ไม่ใช่ปัญหาด้านฮาร์ดแวร์ ให้สิทธิ์การเข้าถึงแก่ผู้ใช้ของคุณด้วย sudo setfacl -m u:${USER}:rw /dev/kvm หรือเพิ่มตัวคุณเองเข้าในกลุ่มด้วย sudo usermod -aG kvm ${USER} แล้วล็อกอินใหม่อีกครั้ง

Ubuntu มีเครื่องมือตรวจสอบที่สรุปผลทั้งหมดนี้ไว้ในผลลัพธ์สองบรรทัด:

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

โฮสต์ที่ใช้งานได้จะแสดง INFO: /dev/kvm exists ตามด้วย KVM acceleration can be used ส่วนโฮสต์ที่ใช้งานไม่ได้จะแสดง INFO: Your CPU does not support KVM extensions ตามด้วย KVM acceleration can NOT be used สำหรับเครื่องที่เป็น physical machine คุณอาจพบ INFO: KVM (vmx) is disabled by your BIOS แทน ซึ่งสามารถแก้ไขได้ใน firmware แต่สำหรับ VPS ข้อความนี้พบได้น้อยมาก เนื่องจากคุณไม่ได้เข้าถึง firmware จริงๆ

ความหมายของผลลัพธ์จาก /dev/kvm แต่ละกรณี

โหนดมีอยู่จริงและจำนวน flag มากกว่าศูนย์ คุณมีฮาร์ดแวร์สำหรับการทำ virtualisation ดังนั้น Firecracker จะทำงานได้ ให้ข้ามไปที่ส่วนการกำหนดขนาด (sizing) เนื่องจากข้อจำกัดที่เหลือของคุณคือหน่วยความจำ ไม่ใช่ฟีเจอร์ของ CPU

ไม่มีโหนด, systemd-detect-virt แสดงผล kvm หรือ qemu และจำนวน flag เป็น 0 VPS ของคุณเป็น virtual machine ที่โฮสต์ไม่ได้ส่งผ่าน (pass-through) ความสามารถด้าน virtualisation มาให้ สิ่งที่คุณติดตั้งภายใน guest จะไม่สามารถแก้ไขปัญหานี้ได้ เพราะ flag เป็นคุณสมบัติของ virtual CPU ที่ hypervisor สร้างขึ้นมาให้คุณ sudo modprobe kvm_intel จะล้มเหลวด้วย modprobe: ERROR: could not insert 'kvm_intel': Operation not supported และ sudo dmesg | grep -i kvm จะบันทึกว่าขาดการสนับสนุนจากฮาร์ดแวร์ นี่เป็นกรณีที่พบบ่อยในแผน VPS แบบ shared ให้สอบถามผู้ให้บริการว่าแผนของคุณรองรับ nested virtualisation หรือไม่ หากคำตอบคือไม่ คุณจำเป็นต้องเปลี่ยนโฮสต์ ไม่ใช่เปลี่ยนคำสั่ง

systemd-detect-virt แสดงผล lxc, lxc-libvirt หรือ openvz แผนของคุณเป็นการทำ virtualisation แบบ container ดังนั้นคุณจึงใช้ kernel ร่วมกับโฮสต์ /dev/kvm จะไม่มีวันปรากฏขึ้น เพราะคุณไม่มี kernel ของตัวเองที่จะโหลดโมดูลเข้าไปได้ และไม่มีแพ็กเกจใดที่แก้ไขปัญหานี้ได้เช่นกัน

มี flag อยู่แต่ไม่มีโหนด โมดูลยังไม่ได้ถูกโหลด ให้รัน sudo modprobe kvm_intel (หรือ kvm_amd สำหรับ AMD) แล้วตรวจสอบ ls -l /dev/kvm อีกครั้ง หากโหนดปรากฏขึ้น ให้เขียนชื่อโมดูลลงใน /etc/modules-load.d/kvm.conf เพื่อให้โมดูลกลับมาทำงานใหม่หลังจากรีบูต

คุณกำลังใช้งานบน arm64 vmx และ svm เป็นชื่อสำหรับ x86 ดังนั้นจำนวน grep จึงเป็น 0 บนเครื่อง arm64 ทุกเครื่อง ไม่ว่าเครื่องจะทำงานปกติหรือไม่ก็ตาม สำหรับ arm64 ให้เชื่อถือที่ตัว device node และการทดสอบอ่าน/เขียนแทน

เหตุผลที่ควรใช้ microVM แทน container สำหรับงานของ agent

Container คือ process หนึ่งบน kernel ของคุณ ซึ่งถูกจำกัดขอบเขตด้วย namespaces และ cgroups โดยใช้ kernel ร่วมกับ host ดังนั้นหากเกิดการเจาะทะลุระดับ kernel จะส่งผลกระทบโดยตรงต่อ host ทันที ในขณะที่ microVM จะบูต kernel ของตัวเองขึ้นมาภายในขอบเขตของการทำ hardware virtualisation และสื่อสารกับอุปกรณ์จำลองขนาดเล็กแทนที่จะเข้าถึง system call ทั้งหมดของ host โดยตรง Firecracker ออกแบบมาให้โมเดลดังกล่าวมีขนาดเล็กที่สุดเท่าที่จะเป็นไปได้ ซึ่งเป็นหัวใจสำคัญของการออกแบบ เพราะยิ่งมีอุปกรณ์จำลองน้อยลง ช่องทางในการหลุดออกไปจาก VM ก็ยิ่งน้อยลงตามไปด้วย

ความแตกต่างนี้มีความสำคัญอย่างยิ่งสำหรับ coding agent เนื่องจากโค้ดที่ agent นำไปรันคือโค้ดที่ไม่มีใครตรวจสอบมาก่อน มันจะทำการติดตั้งแพ็กเกจ รัน build script และลองใหม่ด้วยความเร็วสูงเมื่อเกิดข้อผิดพลาด การแยก kernel ออกมาหมายความว่าหากเกิดความผิดพลาดขึ้น มันจะสร้างความเสียหายได้เพียงแค่เครื่องที่สามารถลบทิ้งได้เท่านั้น และไม่ส่งผลกระทบต่อส่วนอื่น

ข้อกำหนดนี้เป็นผลโดยตรงจากกลไกการทำงาน การแยกส่วนในระดับฮาร์ดแวร์จำเป็นต้องใช้ hardware virtualisation ซึ่งเป็นสิ่งที่ VPS ทั่วไปอาจไม่ได้เตรียมไว้ให้ ในขณะที่ container ไม่จำเป็นต้องใช้สิ่งเหล่านี้เลย จึงเป็นเหตุผลว่าทำไม container ถึงรันได้บนทุกแพ็กเกจที่วางจำหน่าย

ดังนั้นเมื่อ /dev/kvm ไม่พร้อมใช้งาน การใช้ disposable VM for coding agents ที่เป็นแบบ container จึงยังคงเป็นคำตอบที่ถูกต้อง และถือเป็นการควบคุมที่มีประสิทธิภาพจริงไม่ใช่เพียงทางเลือกสำรอง Container ที่ใช้แล้วทิ้งบน host ที่ไม่มีข้อมูลสำคัญ และสามารถกู้คืนจาก snapshot ได้ทุกเมื่อที่เกิดปัญหา จะช่วยป้องกันความเสี่ยงส่วนใหญ่ที่อาจเกิดขึ้นจริงได้ เช่นเดียวกับการตั้งค่าแบบพื้นฐานใน running a coding agent on a VPS คุณควรเลือกใช้ microVM เมื่อต้องรัน agent ทิ้งไว้โดยไม่มีผู้ดูแลเป็นเวลาหลายชั่วโมงกับโค้ดที่คุณยังไม่ได้ตรวจสอบ และเมื่อ host นั้นเป็นเครื่องที่คุณมีสิทธิ์ควบคุมโดยสมบูรณ์

สิ่งที่โฮสต์ของ microVM agent ต้องการ

Nehemiah เป็นตัวอย่างปัจจุบันของซอฟต์แวร์ประเภทนี้ ซึ่งเป็น daemon ภายใต้สัญญาอนุญาต Apache-2.0 ที่ทำหน้าที่จัดเตรียมเครื่อง Linux จริงให้กับ AI ตามคำขอ โดยใช้ Firecracker microVM หนึ่งเครื่องต่อหนึ่งการใช้งาน ไฟล์ README ของโครงการระบุความต้องการไว้อย่างชัดเจนว่า "เครื่อง Linux ที่มี /dev/kvm" และระบุเจาะจงยิ่งขึ้นว่า "Ubuntu 24.04, x86_64 หรือ arm64 ที่มี /dev/kvm (แบบ bare-metal หรือ VM ที่เปิดใช้งาน nested virtualization) ซึ่งคุณสามารถเข้าถึงด้วยสิทธิ์ root ผ่าน SSH ได้"

ขั้นตอนการติดตั้งที่ระบุไว้ใช้คำสั่งเดียวสำหรับรันบนเครื่องดังกล่าว:

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 จะทำการตรวจสอบเบื้องต้น (preflight) ผ่าน SSH และหยุดการทำงานทันทีหากเครื่องไม่ตรงตามเงื่อนไข โดยมีข้อความปฏิเสธการทำงานเกี่ยวกับฮาร์ดแวร์สองรายการดังนี้:

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

ข้อความแรกนั้นคือประเด็นสำคัญของบทความนี้ ตัวติดตั้งจะถามคำถามเดียวกับที่คุณเพิ่งถามด้วย ls -l /dev/kvm และบน VPS ส่วนใหญ่คุณจะได้รับคำตอบที่น่าผิดหวังแบบเดียวกัน

หลังจากผ่านการตรวจสอบเบื้องต้นแล้ว ระบบจะทำการติดตั้งแบบเต็มรูปแบบ: Firecracker และ jailer ของมัน, Go toolchain, guest kernel และ root filesystem, Python guest image, desktop image (ทางเลือก) ที่มาพร้อมเบราว์เซอร์ และ systemd unit สองรายการชื่อ nehemiahd.service และ boring-net.service จากนั้น daemon จะเริ่มทำงานบนพอร์ต 8080 และหาก health check ล้มเหลวจะแสดงข้อความ /healthz didn't return ok ทั้งนี้ SKIP_DESKTOP=1 จะข้ามการสร้าง desktop image ซึ่ง README ระบุว่าใช้เวลาสร้างประมาณ 8 นาที

อ่านข้อควรระวังก่อนคัดลอกคำสั่งไปใช้

โปรแกรมต้องการสิทธิ์ root SSH บนโฮสต์ใหม่ ตัวติดตั้งจะเขียน system packages, systemd units และการตั้งค่าเครือข่ายในฐานะ root ให้ชี้โปรแกรมไปยังเครื่องที่คุณพร้อมจะล้างข้อมูลใหม่ทั้งหมด ไม่ใช่เซิร์ฟเวอร์ที่รันเว็บไซต์ของคุณอยู่แล้ว

Daemon จะผูกกับ 0.0.0.0:8080 โดยค่าเริ่มต้น ใครก็ตามที่เข้าถึงพอร์ตนั้นได้จะสามารถสร้างเครื่องใหม่ได้ และเครื่องเหล่านั้นจะใช้ model key ที่คุณมอบให้ตัวติดตั้ง ให้ตั้งค่า NEHEMIAH_TOKEN เพื่อบังคับการยืนยันตัวตน หรือตั้งค่า BIND_LOCALHOST=1 เพื่อให้ daemon ผูกกับ 127.0.0.1 เท่านั้น แล้วเข้าถึงผ่าน tunnel ด้วย ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP กุญแจนี้ควรได้รับการดูแลเช่นเดียวกับความลับอื่นๆ บนเครื่อง ตามที่ระบุไว้ใน การเก็บความลับให้ห่างจาก AI agents

ทุกเครื่องคือคอมพิวเตอร์ที่เข้าถึงอินเทอร์เน็ตได้และมีการติดตั้ง agent ไว้ล่วงหน้า ไฟล์ README ระบุ claude, codex, cursor และ pi ไว้ภายใน guest ควบคู่ไปกับ node, python และ git โครงการระบุว่า guest จะอยู่หลัง egress firewall และขอบเขตการแยกส่วนนั้นมีอยู่จริง แต่ guest ยังคงเข้าถึงเครือข่ายได้ตามการออกแบบ เพราะ coding agent ที่ไม่สามารถดึงแพ็กเกจได้นั้นไม่มีประโยชน์ ให้วางแผนรับมือเรื่องนี้แทนที่จะคาดหวังว่าจะมี air gap

ไม่มีการทำ tagged release ณ วันที่ 10 สิงหาคม 2026 repository นี้ไม่มี tag ใดๆ เลย ดังนั้นการ clone main จะทำให้คุณได้สิ่งที่เพิ่งอัปเดตเข้ามาในเช้าวันนั้น ให้ล็อกเวอร์ชันไว้ที่ commit และอ่านสคริปต์ก่อนที่จะรันด้วยสิทธิ์ root บนเซิร์ฟเวอร์ของคุณ:

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

Repository นี้ถูกสร้างขึ้นเมื่อปลายเดือนมิถุนายน 2026 ดังนั้นให้ถือว่าเป็นซอฟต์แวร์ใหม่ ให้กลับไปอ่าน infra/setup.sh อีกครั้งหลังจากการอัปเดตทุกครั้งที่คุณดึงมา เนื่องจากสิ่งที่คุณกำลังอนุมัติคือการให้สิทธิ์ root เข้าถึงเครื่อง ไม่ใช่แค่การอัปเดตเวอร์ชันของไลบรารีทั่วไป

พิสูจน์ว่า KVM ทำงานได้ก่อนจะโทษตัวติดตั้ง

หากการติดตั้งล้มเหลวและคุณต้องการทราบว่าเป็นเพราะ KVM หรือไม่ ให้ทดสอบ Firecracker แยกต่างหาก นี่คือขั้นตอนการดาวน์โหลดจากต้นทาง:

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

การพิมพ์เวอร์ชันออกมาเป็นการพิสูจน์ว่าไฟล์ binary ตรงกับสถาปัตยกรรมของคุณและสามารถทำงานได้ แต่มันไม่ได้พิสูจน์ว่าเข้าถึง KVM ได้ ดังนั้นให้จับคู่กับการทดสอบการอ่านและเขียนบน /dev/kvm ที่ทำไปก่อนหน้านี้ การทำทั้งสองอย่างร่วมกันจะช่วยแยกปัญหาด้านโฮสติ้งออกจากปัญหาด้านแพ็กเกจ ซึ่งช่วยให้คุณไม่ต้องเสียเวลาดีบั๊กตัวติดตั้งที่ทำงานถูกต้องอยู่แล้ว

microVM หลายตัวต้องการทรัพยากรเซิร์ฟเวอร์เท่าใด

microVM แต่ละตัวจะรัน guest kernel จริงควบคู่ไปกับหน่วยความจำที่คุณจัดสรรให้ ซึ่งหน่วยความจำส่วนนี้จะถูกจองไว้ตลอดเวลาที่เครื่องทำงาน ดังนั้นให้คำนวณขนาดของโฮสต์จากขนาดของ guest และจำนวนที่คุณต้องการรันพร้อมกัน ตัวเลขด้านล่างนี้เป็นการคำนวณเชิงคณิตศาสตร์ ไม่ใช่การวัดผลจริง guest แบบไม่มีหน้าจอ (headless) ใช้หน่วยความจำ 1 GB ส่วน guest แบบเดสก์ท็อปที่มีเบราว์เซอร์ใช้ 2 GB โดยโฮสต์จะสำรองหน่วยความจำไว้ 2 GB สำหรับตัวโฮสต์เอง, daemon และการ 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
  }
]

เครื่องแบบ headless หนึ่งเครื่องต้องการหน่วยความจำประมาณ 3 GB ซึ่ง VPS ขนาดกลางที่มี KVM สามารถรองรับได้ หากต้องการรัน 4 เครื่องพร้อมกันจะใช้ 6 GB หากรันเครื่องเดสก์ท็อปจำนวน 8 เครื่อง การคำนวณแบบเดียวกันจะต้องการหน่วยความจำ 18 GB โดยที่ยังไม่นับรวมพื้นที่ดิสก์

พื้นที่ดิสก์คือสิ่งที่ไม่มีใครวางแผนไว้ล่วงหน้า โฮสต์ต้องจัดเก็บ guest kernel, base root filesystem, image หนึ่งชุดต่อ guest แต่ละประเภท, snapshot หนึ่งชุดต่อเครื่องที่รันอยู่ และ image แบบเดสก์ท็อปที่มีเบราว์เซอร์ซึ่งมีขนาดใหญ่ ไฟล์ README ไม่ได้ระบุตัวเลขพื้นที่ดิสก์ไว้ ดังนั้นให้ตรวจสอบ df -h / ระหว่างการ build ครั้งแรกแทนการคาดเดา

นี่คือเหตุผลที่คำตอบที่ตรงไปตรงมาสำหรับคำถามที่ว่า "VPS รุ่นไหนรัน Firecracker ได้" มักจะเป็น "เครื่องคนละระดับกัน" การใช้ bare metal จะทำให้คุณได้รับ CPU flags โดยไม่มี hypervisor มาขวาง ซึ่งเป็นข้อแลกเปลี่ยนในการ เลือกระหว่าง VPS กับ dedicated server ผู้ให้บริการบางรายเปิดให้ใช้งาน nested virtualisation บนแผนแบบ virtual ได้ และเนื้อหาเรื่อง nested virtualisation บน VPS จะอธิบายวิธีตรวจสอบก่อนที่คุณจะชำระเงิน หากคุณมีฮาร์ดแวร์อยู่แล้ว การเปรียบเทียบ Proxmox กับ VPS ทั่วไป ก็เป็นคำถามเดียวกันในมุมมองของ hypervisor

เซิร์ฟเวอร์เป็นเพียงส่วนที่มีค่าใช้จ่ายต่ำกว่า ทุกเครื่องที่คุณส่งให้ agent จะมีการใช้ model tokens ตลอดเวลาที่เครื่องทำงาน ดังนั้น microVM ที่ไม่ได้ใช้งานจะเสียค่าหน่วยความจำ ส่วนเครื่องที่ทำงานหนักจะเสียทั้งค่าหน่วยความจำและค่า API แผนบริการขนาด 1 GB ไม่สามารถรองรับโฮสต์ได้ และแผนที่รองรับโฮสต์ได้ก็ยังไม่รวมค่าใช้จ่ายของ key

FAQ

ฉันจะตรวจสอบได้อย่างไรว่า VPS ของฉันสามารถรัน Firecracker ได้หรือไม่

ให้รันคำสั่ง ls -l /dev/kvm, systemd-detect-virt และ grep -cE '\b(vmx|svm)\b' /proc/cpuinfo บน VPS หากพบ device node ที่มีกลุ่ม kvm เป็นเจ้าของ และมีค่า flag count มากกว่าศูนย์ แสดงว่า Firecracker สามารถทำงานได้ หากไม่พบ node ดังกล่าวและมีค่า count เป็น 0 แสดงว่า hypervisor ไม่ได้ส่งผ่านฟังก์ชัน virtualisation มาให้ ซึ่งคำสั่ง sudo kvm-ok จากแพ็กเกจ cpu-checker จะยืนยันเรื่องนี้ด้วย KVM acceleration can NOT be used สำหรับสถาปัตยกรรม arm64 ให้เพิกเฉยต่อค่า count เนื่องจาก vmx และ svm เป็นชื่อเฉพาะของ x86

ฉันสามารถเปิดใช้งาน nested virtualisation จากภายใน VPS ได้หรือไม่

ไม่ได้ การเปิดใช้งาน nested virtualisation ต้องทำโดยโฮสต์ใน kernel module ของ hypervisor เท่านั้น และคุณจะได้รับสิทธิ์นั้นในรูปแบบของ CPU flag บน virtual processor ที่ได้รับจัดสรรมา ภายใน guest นั้น sudo modprobe kvm_intel จะส่งค่ากลับเป็น modprobe: ERROR: could not insert 'kvm_intel': Operation not supported เนื่องจาก virtual CPU ไม่มี VMX ให้ใช้งาน ทางเลือกของคุณคือการใช้ผู้ให้บริการที่รองรับ nested virtualisation ในแพ็กเกจที่เลือก หรือใช้เครื่องที่คุณเป็นเจ้าของ hypervisor เอง

container เพียงพอสำหรับการทำ sandbox ให้กับ coding agent หรือไม่

โดยส่วนใหญ่แล้วเพียงพอ container ใช้ kernel ร่วมกับโฮสต์ของคุณ ดังนั้นการหลุดรอดในระดับ kernel อาจส่งผลถึงโฮสต์ได้ แต่การใช้ container แบบใช้แล้วทิ้งบนเครื่องที่ไม่มีข้อมูลรับรอง (credentials) ที่สำคัญ จะช่วยลดความเสี่ยงส่วนใหญ่ที่คุณต้องเผชิญได้จริง ให้เลือกใช้ microVM เมื่อต้องรัน agent ทิ้งไว้โดยไม่มีผู้ดูแลเป็นเวลานานกับโค้ดที่ยังไม่ได้ตรวจสอบ และเมื่อคุณสามารถจัดเตรียมโฮสต์ที่มี /dev/kvm ให้ได้ แต่หากทำไม่ได้ การใช้ container ที่คุณทำลายทิ้งหลังจบงานทุกครั้ง ย่อมดีกว่าการใช้ microVM ที่คุณไม่สามารถจัดการให้บูตขึ้นมาได้

โฮสต์สำหรับ microVM agent ต้องการ RAM เท่าใด

ให้เริ่มคำนวณจากขนาดของ guest โดย guest แบบไม่มีหน้าจอ (headless) ขนาด 1 GB ที่มีการสำรอง RAM บนโฮสต์ไว้ 2 GB จะต้องการ RAM รวมประมาณ 3 GB และสำหรับ desktop guest จำนวน 8 เครื่องที่เครื่องละ 2 GB จะต้องการ RAM ประมาณ 18 GB ส่วนพื้นที่ดิสก์นั้นแยกต่างหากและมักจะประเมินต่ำเกินไปได้ง่าย เนื่องจากโฮสต์ต้องเก็บ kernel, root filesystems, อิมเมจสำหรับ guest แต่ละประเภท และ snapshot สำหรับเครื่องที่กำลังทำงานอยู่ทุกเครื่อง