האם ה-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 הוא דוגמה עכשווית למחלקה זו: daemon ברישיון Apache-2.0 המספק לבינה מלאכותית מכונת Linux אמיתית לפי דרישה, תוך שימוש ב-microVM מסוג Firecracker לכל מכונה. נכון ל-10 באוגוסט 2026, ה-README שלו הציג את הדרישה ללא סייגים: "מכונת Linux עם /dev/kvm", וליתר דיוק "Ubuntu 24.04, בגרסת x86_64 או arm64, עם /dev/kvm (שרת bare-metal, או VM עם nested virtualization) שניתן להתחבר אליו ב-SSH כ-root".

מאז המצב השתנה. ב-11 באוגוסט 2026 החליף הפרויקט את תיעוד ההתקנה העצמית ב-runbook למארחים מנוהלים, וה-README שנבדק ב-11 באוקטובר 2026 כבר אינו כולל את שורת הדרישה הזו או את פקודת ההתקנה הבודדת. מארחים מוקצים כעת מתוך ארטיפקטים חתומים של גרסאות אל שרתי bare-metal של Latitude.sh עם infra/latitude/provision.sh; זהו מסלול ידני המופעל על ידי מפעיל עבור מארחים מאושרים, שאותם ה-control plane של הפרויקט רושם לאחר מכן. ה-canary של ה-runbook עדיין מסרב לעבוד עם מארח ללא /dev/kvm תקין, כך שהדרישה לא נעלמה. היא עברה ל-bare metal.

עד לשינוי ההוא, ההתקנה המתועדת כללה פקודה אחת המופנית לאותה מכונה:

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

ב-main הנוכחי, פקודה זו אינה מתקינה דבר. infra/setup.sh מסומן כ-descoped ומסיים את פעולתו כבר בשלב הראשון עם הודעה ש-bootstrap בשירות עצמי אינו נתמך עוד, וזאת לפני הרצת שלבי בדיקה מקדימה או התקנה כלשהם. ה-README מציין שמתקיני השירות העצמי הקודמים מסתיימים כעת עם הפניה ל-runbook המנוהל.

ב-commit שעליו נכתב פוסט זה לראשונה, 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 הוא קיבל את אותה תשובה מאכזבת. ה-runbook המנוהל שואל זאת גם הוא.

לאחר הבדיקה המקדימה, מדובר היה בהתקנה על המכונה כולה: Firecracker וה-jailer שלו, כלי פיתוח של Go, ליבת אורח (guest kernel) ומערכת קבצים של root, תמונת אורח של Python, תמונת שולחן עבודה אופציונלית עם דפדפן, ושתי יחידות systemd בשם nehemiahd.service ו-boring-net.service. בדיקת תקינות שנכשלה הדפיסה /healthz didn't return ok, ו-SKIP_DESKTOP=1 דילג על תמונת שולחן העבודה, שעל פי ה-README מאותו תאריך, בנייתה ארכה כ-8 דקות. אף אחד מהשלבים, ההודעות או המתגים הללו אינו רץ מתוך main הנוכחי. ה-daemon עצמו עדיין מאזין כברירת מחדל בפורט 8080.

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

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

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

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

אין גרסה מתויגת (tagged release). נכון ל-11 באוקטובר 2026, ל-repository אין תגיות ואין גרסאות משוחררות, כך שביצוע clone ל-main יביא לך את מה שהוטמע באותו בוקר, והיום זהו הקוד המנוהל בלבד. בצע pin ל-commit ספציפי. ה-commit להלן הוא זה שעליו נכתב פוסט זה ב-10 באוגוסט 2026, יום לפני שהסרת את מתקין ה-self-serve, ולכן ה-infra/setup.sh שלו עדיין מתקין. הפרויקט כבר לא תומך בנתיב הזה, לכן קרא את הסקריפט לפני שהוא רץ כ-root על השרת שלך:

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

ה-repository נוצר בסוף יוני 2026 והסיר את התקנת ה-self-serve שישה שבועות לאחר מכן, לכן התייחס אליו כאל תוכנה צעירה שהנתיב הנתמך שלה עלול להשתנות תחת רגליך. לפני שאתה מושך משהו חדש יותר, קרא שוב את ה-README ואת ה-runbook, כיוון שהדבר שאתה מאשר הוא גישת 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 אורח אמיתי בתוספת הזיכרון שהוקצה לו, וזיכרון זה נתפס כל עוד המכונה פועלת. לכן, יש לקבוע את גודל המארח לפי גודל האורחים ומספרם המתוכנן בו-זמנית. הנתונים להלן הם חישובים אריתמטיים, לא מדידות בפועל. אורח ללא ממשק גרפי (headless) צורך 1 GB, ואורח עם ממשק שולחן עבודה ודפדפן צורך 2 GB. המארח שומר לעצמו נפח קבוע של 3 GB עבור צרכיו, עבור ה-daemon ועבור בניית תמונות (images), וזהו הרזרבה המוגדרת כברירת מחדל ב-daemon (NEHEMIAH_MEM_RESERVE_MB, 3072 MB). ה-daemon יסרב להפעיל מכונה חדשה אם היא תנגוס ברזרבה זו, כך ששרת קטן מדי יגיע לקיבולת המקסימלית במקום לסבול ממחסור בזיכרון.

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

מכונה אחת ללא ממשק גרפי דורשת כ-4 GB, נפח ששרת VPS בינוני יכול לספק כאשר הוא מאפשר גישה ל-KVM. ארבע מכונות כאלו דורשות 7 GB. הרצת 8 מכונות שולחן עבודה לפי אותו חישוב דורשת 19 GB, וזאת עוד לפני שחישבנו גיגה-בייט אחד של דיסק.

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

זו הסיבה שהתשובה הכנה לשאלה "איזה VPS מריץ Firecracker" היא לעיתים קרובות "סוג אחר של מכונה". שרת פיזי (bare metal) מספק את ה-CPU flags ללא hypervisor בדרך, וזהו השיקול ב-בחירה בין VPS לשרת ייעודי. ספקים מסוימים אכן מאפשרים virtualisation מקונן בתוכניות וירטואליות, ו-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 flag) במעבד הווירטואלי שהוקצה לכם. בתוך ה-guest, הפקודה sudo modprobe kvm_intel תחזיר modprobe: ERROR: could not insert 'kvm_intel': Operation not supported מכיוון שלמעבד הווירטואלי אין VMX לשימוש. האפשרויות שלכם הן ספק שמציע וירטואליזציה מקוננת בתוכנית, או מכונה שבה אתם הבעלים של ה-hypervisor.

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

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

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

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