האם ה-VPS שלכם תומך בהרצת Firecracker microVMs?

האם ה-VPS שלכם מסוגל להריץ Firecracker microVMs?

ה-VPS שלכם יכול להריץ Firecracker microVMs רק אם הוא מספק לכם /dev/kvm. הכלי Firecracker הוא VMM (ראשי תיבות של virtual machine monitor) הבנוי על גבי KVM (ראשי תיבות של kernel-based virtual machine), שכבת הווירטואליזציה בתוך Linux, ו-KVM זקוק להוראות וירטואליזציה מה-CPU. ב-VPS אתם מקבלים את ההוראות הללו רק כאשר הספק מעביר אותן (pass-through) למכונה האורחת שלכם, ורוב התוכניות אינן עושות זאת.

לכן, השאלה הראשונה אינה באיזה כלי microVM כדאי להתקין. השאלה היא האם המכונה שאתם כבר משלמים עליה מסוגלת לארח אחד כזה בכלל. זוהי שאלת אירוח, ותוכלו לענות עליה בתוך כדקה.

בדיקת /dev/kvm לפני התקנה

הריצו את שלוש הפקודות הבאות ישירות על ה-VPS.

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

שרת שמסוגל לארח microVMs יציג פלט כזה:

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

השורה הראשונה היא ה-device node של KVM, הנמצא בבעלות הקבוצה kvm. השורה השנייה מציינת שהמכונה עצמה היא אורחת (guest) הרצה תחת KVM, וזהו מצב תקין וצפוי ב-VPS. השורה השלישית סופרת את ליבות המעבד המדווחות על דגל הווירטואליזציה החומרתית, vmx ב-Intel ו-svm ב-AMD. ספירה הגדולה מאפס בתוך אורח משמעותה שה-hypervisor מאפשר לכם nested virtualisation.

לאחר מכן, ודאו שהמשתמש שלכם יכול לפתוח את ההתקן. זהו הבדיקה מתוך מסמך ה-getting started של Firecracker:

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

FAIL כאשר הצומת קיים מעיד על בעיית הרשאות ולא על בעיית חומרה. העניקו גישה למשתמש שלכם באמצעות 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. במכונה פיזית ייתכן שתראו במקום זאת INFO: KVM (vmx) is disabled by your BIOS, דבר שניתן לתיקון ב-firmware. ב-VPS הודעה זו נדירה, כיוון שאינכם ניגשים ל-firmware אמיתי.

מה המשמעות של כל תשובה עבור /dev/kvm?

הצומת קיים וספירת ה-flag גדולה מאפס. יש לך וירטואליזציה מבוססת חומרה, לכן Firecracker יפעל. דלג לסעיף הגדרת הגדלים, כיוון שהמגבלה שנותרה לך היא זיכרון ולא יכולות מעבד.

אין צומת, systemd-detect-virt מדפיס kvm או qemu, וספירת ה-flag היא 0. ה-VPS שלך הוא מכונה וירטואלית שהמארח שלה אינו מעביר אליה וירטואליזציה. שום דבר שתתקין בתוך ה-guest לא ישנה זאת, כיוון שה-flag הוא תכונה של המעבד הווירטואלי שה-hypervisor בנה עבורך. sudo modprobe kvm_intel נכשל עם modprobe: ERROR: could not insert 'kvm_intel': Operation not supported, ו-sudo dmesg | grep -i kvm מתעד את היעדר התמיכה בחומרה. זהו המקרה הנפוץ בתוכניות VPS שיתופיות. שאל את הספק אם התוכנית תומכת ב-nested virtualisation. אם התשובה היא לא, אתה זקוק לאירוח אחר, לא לפקודה אחרת.

systemd-detect-virt מדפיס lxc, lxc-libvirt או openvz. התוכנית שלך היא וירטואליזציה מבוססת מכולות (container), לכן אתה חולק את ה-kernel של המארח. /dev/kvm לעולם לא יופיע, כיוון שאין לך kernel משלך כדי לטעון לתוכו מודול. שום חבילה לא תתקן זאת.

ה-flags קיימים והצומת אינו קיים. המודול פשוט לא טעון. הרץ את sudo modprobe kvm_intel (או kvm_amd ב-AMD) ובדוק שוב את ls -l /dev/kvm. אם הצומת מופיע, כתוב את שם המודול ב-/etc/modules-load.d/kvm.conf כדי שיחזור לאחר reboot.

אתה עובד על arm64. vmx ו-svm הם שמות של x86, לכן ספירת ה-grep היא 0 בכל מכונת arm64, בין אם היא עובדת ובין אם לא. ב-arm64, הסתמך על ה-device node ועל בדיקת הקריאה והכתיבה במקום זאת.

מדוע להשתמש ב-microVM ולא ב-container עבור סוכן (agent)

קונטיינר הוא תהליך שרץ על ה-kernel שלכם, מבודד באמצעות namespaces ו-cgroups. קיים kernel אחד והוא שלכם, לכן פריצה ברמת ה-kernel משמעותה גישה למארח (host). לעומת זאת, microVM מאתחל kernel משלו בתוך גבול וירטואליזציה חומרתי, והוא מתקשר עם מודל התקנים מדומים מצומצם במקום עם כל ממשק ה-system call של המארח. Firecracker שומר על המודל הזה קטן במכוון, וזהו לב התכנון: פחות התקנים מדומים פירושם פחות דרכי יציאה.

ההבדל הזה קריטי עבור סוכן תכנות, כיוון שהקוד שהסוכן מריץ הוא קוד שאף אחד לא קרא לפני כן. הוא מתקין חבילות, מריץ סקריפטים של build, ומנסה שוב במהירות מכונה כאשר משהו נכשל. kernel נפרד מבטיח שצעד שגוי יפגע רק במכונה שניתן למחוק, ולא בשום דבר אחר.

הדרישה נובעת ישירות מהמנגנון. בידוד חומרתי דורש וירטואליזציה חומרתית, וזה בדיוק הדבר שייתכן שתוכנית ה-VPS שלכם לא מספקת. קונטיינר אינו זקוק לכך כלל, וזו הסיבה שקונטיינרים רצים על כל תוכנית אירוח שקיימת.

לכן, כאשר /dev/kvm חסר, ה-VM חד-פעמי לסוכני תכנות מבוסס הקונטיינרים נותר הפתרון הנכון, והוא מהווה אמצעי בקרה ממשי ולא פרס ניחומים. קונטיינר חד-פעמי, על מארח שאינו מכיל אישורים שחשובים לכם, אשר משוחזר מ-snapshot בכל פעם שהוא מתנהג בצורה לא תקינה, מונע את רוב התקלות בפועל. אותו הדבר נכון לגבי ההגדרה הפשוטה יותר ב-הרצת סוכן תכנות על VPS. בחרו ב-microVM כאשר סוכן ירוץ ללא השגחה, במשך שעות, מול קוד שלא עבר סקירה, וכאשר המארח נמצא בשליטתכם המלאה.

מה דורש סוכן של microVM מהמארח

Nehemiah הוא דוגמה עכשווית למחלקה זו: דמון ברישיון Apache-2.0 שמספק לבינה מלאכותית מכונת Linux אמיתית לפי דרישה, כאשר כל מכונה היא microVM מסוג Firecracker. קובץ ה-README שלו מציג את הדרישה ללא סייגים: "מכונת Linux עם /dev/kvm", וליתר דיוק "Ubuntu 24.04, בגרסת x86_64 או arm64, עם /dev/kvm (שרת bare-metal, או VM עם nested virtualization) שניתן להתחבר אליו ב-SSH כ-root".

ההתקנה המתועדת מבוצעת באמצעות פקודה אחת המופנית לאותה מכונה:

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 שלו, שרשרת כלים (toolchain) של Go, ליבת אורח (guest kernel) ומערכת קבצים ראשית, תמונת אורח של Python, תמונת שולחן עבודה אופציונלית עם דפדפן, ושתי יחידות systemd בשמות nehemiahd.service ו-boring-net.service. הדמון מאזין לאחר מכן בפורט 8080, ובדיקת תקינות (health check) שנכשלה מדפיסה /healthz didn't return ok. הפרמטר SKIP_DESKTOP=1 מדלג על תמונת שולחן העבודה, שלפי ה-README לוקח כ-8 דקות לבנות אותה.

קראו את האזהרות לפני הדבקת הפקודה

הכלי דורש גישת root ב-SSH למכונה חדשה. תוכנית ההתקנה כותבת חבילות מערכת, יחידות systemd והגדרות רשת כ-root. הפעילו אותה על מכונה שאתם מוכנים להתקין מחדש מאפס, ולא על שרת שכבר מריץ את האתר שלכם.

ה-daemon מאזין כברירת מחדל ל-0.0.0.0:8080. כל מי שיגיע לפורט הזה יוכל ליצור מכונות, ומכונות אלו ינצלו את ה-model key שהזנתם למתקין. הגדירו את NEHEMIAH_TOKEN כדי לדרוש אימות, או הגדירו את BIND_LOCALHOST=1 כך שה-daemon יאזין ל-127.0.0.1 בלבד, ותוכלו לגשת אליו דרך מנהרה עם ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP. המפתח דורש את אותה רמת זהירות כמו כל סוד אחר על השרת, כפי שמוסבר ב-שמירה על סודות מחוץ לסוכני AI.

כל מכונה היא מחשב עם גישה לאינטרנט וסוכנים מותקנים מראש. ה-README מפרט את claude, codex, cursor ו-pi בתוך ה-guest, לצד node, python ו-git. הפרויקט מציין שה-guests נמצאים מאחורי firewall יוצא, וגבול הבידוד עצמו אמיתי. ה-guest עדיין ניגש לרשת כחלק מהתכנון, מכיוון שסוכן תכנות שלא יכול למשוך חבילה הוא חסר תועלת. תכננו בהתאם במקום להניח שמדובר ב-air gap.

אין גרסאות מתויגות (tagged release). נכון ל-10 באוגוסט 2026, במאגר אין תיוגים כלל, לכן ביצוע clone ל-main יביא לכם את מה שהועלה באותו בוקר. קבעו גרסה לפי commit, וקראו את הסקריפט לפני שהוא רץ כ-root על השרת שלכם:

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

המאגר נוצר בסוף יוני 2026, לכן התייחסו אליו כאל תוכנה צעירה. קראו שוב את infra/setup.sh לאחר כל עדכון שאתם מושכים, כיוון שהדבר שאתם מאשרים הוא גישת root למכונה, ולא עדכון גרסה של ספרייה.

וודאו ש־KVM עובד לפני שמאשימים את תוכנית ההתקנה

אם ההתקנה נכשלת ואתם רוצים לדעת אם KVM הוא הגורם לכך, בדקו את Firecracker באופן עצמאי. אלו הם שלבי ההורדה מהמקור (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

גרסה מודפסת מוכיחה שהקובץ הבינארי תואם לארכיטקטורה שלכם ורץ כראוי. היא אינה מוכיחה גישה ל־KVM, לכן בצעו אותה בשילוב עם בדיקת הקריאה והכתיבה ב־/dev/kvm שבוצעה קודם לכן. יחד, שתי הבדיקות מפרידות בין בעיית אירוח לבין בעיית אריזה, מה שחוסך מכם ניפוי שגיאות בתוכנית התקנה שהייתה תקינה מלכתחילה.

כמה משאבי שרת נדרשים עבור מספר microVM?

כל microVM מריץ kernel של אורח (guest) יחד עם הזיכרון שהוקצה לו, וזיכרון זה נשאר תפוס כל עוד המכונה פועלת. לכן, יש לקבוע את גודל המארח (host) לפי גודל האורחים ומספרם המתוכנן בו-זמנית. הנתונים להלן הם חישובים אריתמטיים, לא מדידות בפועל. אורח ללא ממשק גרפי (headless) צורך 1 GB, ואורח עם ממשק שולחן עבודה ודפדפן צורך 2 GB. המארח שומר לעצמו נפח קבוע של 2 GB עבור מערכת ההפעלה, ה-daemon ובניית אימג'ים.

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

מכונה אחת ללא ממשק גרפי דורשת כ-3 GB, נפח ששרת VPS בינוני יכול להכיל אם הוא מספק גישה ל-KVM. ארבע מכונות כאלו דורשות 6 GB. הרצת 8 מכונות עם ממשק שולחן עבודה דורשת, לפי אותו חישוב, 18 GB, עוד לפני שחישבנו אפילו גיגה-בייט אחד של שטח דיסק.

שטח הדיסק הוא המשאב שאף אחד לא מתכנן מראש. המארח מאחסן kernel של אורח, מערכת קבצים בסיסית (root filesystem), אימג' אחד לכל סוג אורח ו-snapshot לכל מכונה פעילה; האימג' של שולחן העבודה עם הדפדפן הוא הגדול מביניהם. ה-README לא מספק נתון לגבי שטח דיסק, לכן עקבו אחר df -h / במהלך הבנייה הראשונה במקום להסתמך על הערכות.

זו הסיבה שהתשובה הכנה לשאלה "איזה VPS מריץ Firecracker" היא לעיתים קרובות "סוג אחר של מכונה". שרת פיזי (bare metal) מספק את דגלי ה-CPU ללא hypervisor בדרך, וזהו השיקול ב-בחירה בין VPS לשרת ייעודי. ספקי שירות מסוימים אכן מאפשרים וירטואליזציה מקוננת (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, יחד עם מונה דגלים הגדול מאפס, מעידים על כך ש-Firecracker יכול לרוץ. צומת חסר עם מונה 0 מציין שה-hypervisor אינו מעביר וירטואליזציה, ו-sudo kvm-ok מחבילת cpu-checker מאשר זאת באמצעות KVM acceleration can NOT be used. ב-arm64, התעלמו מהמונה, כיוון ש-vmx ו-svm הם שמות השמורים ל-x86.

האם אני יכול להפעיל וירטואליזציה מקוננת (nested virtualisation) מתוך ה-VPS שלי?

לא. וירטואליזציה מקוננת מופעלת על ידי המארח (host), במודול ה-kernel של ה-hypervisor, והיא מגיעה אליכם כדגל CPU במעבד הווירטואלי שהוקצה לכם. בתוך ה-guest, הפקודה sudo modprobe kvm_intel תחזיר modprobe: ERROR: could not insert 'kvm_intel': Operation not supported כיוון של-CPU הווירטואלי אין VMX לשימוש. האפשרויות שלכם הן ספק המציע וירטואליזציה מקוננת בתוכנית השירות, או מכונה שבה אתם הבעלים של ה-hypervisor.

האם מכולה (container) מספיקה כדי לבצע sandbox לסוכן קידוד?

לרוב כן. מכולה חולקת את ה-kernel שלכם, לכן פריצה ברמת ה-kernel תגיע למארח, אך מכולה חד-פעמית על מכונה שאינה מחזיקה אישורים רגישים מסירה את רוב הסיכונים שאתם עומדים בפניהם בפועל. בחרו ב-microVM כאשר סוכן רץ ללא השגחה לפרקי זמן ארוכים מול קוד שלא עבר סקירה, וכאשר באפשרותכם לספק לו מארח עם /dev/kvm. כאשר אינכם יכולים, מכולה שאתם משמידים לאחר כל משימה עדיפה על microVM שלעולם לא תצליחו להעלות.

כמה זיכרון RAM דרוש למארח של סוכני microVM?

התחילו מגודל ה-guest. אורח אחד ללא ממשק גרפי (headless) בנפח 1 GB עם רזרבה של 2 GB למארח דורש כ-3 GB בסך הכל, ו-8 אורחים עם ממשק שולחני בנפח 2 GB כל אחד דורשים כ-18 GB. הדיסק הוא רכיב נפרד שקל להמעיט בערכו, כיוון שהמארח מחזיק kernel, מערכות קבצים של root, תמונה אחת לכל סוג אורח ו-snapshot עבור כל מכונה פעילה.