SSD Nodes Learn
מדריכים Matt Connorמאת Matt Connor · עודכן 2026-07-24

האם אפשר להריץ Proxmox על VPS?

בדוק אם ה-vmx flag זמין באמצעות הפקודה kvm-ok. נלמד איך לזהות אם הספק שלך חוסם Nested virtualization ואיך להריץ Proxmox או KVM בתוך ה-VPS שלך.

התשובה הקצרה

וירטואליזציה מקוטבת (Nested virtualization) היא hypervisor הפועל בתוך מכונה וירטואלית: ה-VPS שלך הוא כבר אורח (guest), ואתה רוצה שהוא יארח אורחים משלו. זה עובד רק כאשר ה-hypervisor של הספק שלך חושף במכוון את הרחבות ה-virtualization של ה-CPU לאינסטנס שלך — בדוק את /proc/cpuinfo עבור הדגל vmx (Intel) או svm (AMD). אם אף אחד מהם לא מופיע, שום הגדרה בתוך ה-VPS לא תפתור זאת.

נקודת ייחוס חשובה: Docker אינו זקוק לאף אחד מהדברים הללו. קונטיינרים משתפים את ה-kernel של ה-VPS שלך ולא נוגעים ב-/dev/kvm. אם המטרה היא "להריץ מספר שירותים בקונטיינרים על השרת שלי", כבר יש לך את מה שאתה צריך. וירטואליזציה מקוטבת רלוונטית כאשר אתה זקוק ל-kernel שני — מעבדת Proxmox, אורח Windows, microVMs של Firecracker, אמולטור Android, סביבת בדיקות Kubernetes של VMs אמיתיים, או runners של CI המריצים VM images.

מה בפועל נעשה לו קינון (Nesting)

שלוש שכבות:

  • L0 — ה-hypervisor של הספק, על ה-metal. אין לך גישה אליו.
  • L1 — ה-VPS שלך. עבור L0, זהו רק guest.
  • L2 — ה-VM שברצונך להריץ בתוך ה-VPS שלך.

וירטואליזציית חומרה היא VT-x (ה-flag ‏vmx) בתוספת EPT ב-Intel, ו-AMD-V / SVM (‏svm) בתוספת RVI/NPT ב-AMD. ה-hypervisor משתמש בפקודות אלו כדי להיכנס למצב guest וכדי לאפשר ל-CPU לעבור על שתי טבלאות דפים (page tables) בו-זמנית.

אף אחת מהן לא תוכננה לעבודה רкурסיבית (re-entrant), לכן הקינון מבוצע באמצעות אמולציה: כאשר L1 מבצעת פקודת VMX היא נתקעת (traps) ב-L0, שמנהל את מבני ה-shadow עבור L2 בשם L1. KVM מבצע זאת בצורה טובה, אך L0 מבצע עבודה נוספת בכל exit — וזו הסיבה שהספק חייב לאפשר זאת באופן מפורש (opt in).

שני תנאים חייבים להתקיים עבור L2 מואץ:

  1. מודול ה-KVM של L0 טעון עם nested=1.
  2. L0 מספק ל-VPS שלך מודל CPU הכולל את ה-flag — <cpu mode='host-passthrough'/> ב-libvirt, cpu: host ב-Proxmox, ו--cpu host ב-QEMU גולמי. מודל אמולציה גנרי (qemu64, kvm64) מסתיר את vmx גם כאשר הקינון מופעל גלובלית.

בדקו את ה-VPS שלכם תוך דקה אחת

# 1. Are you in a VM, and under what?
systemd-detect-virt          # kvm, vmware, xen, microsoft, or "none" on metal

# 2. Does the CPU expose the extensions to you?
grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u
lscpu | grep -i -E 'virtual|hypervisor'

# 3. The definitive check
sudo apt update && sudo apt install -y cpu-checker
kvm-ok

# 4. The device node the whole stack depends on
ls -l /dev/kvm

מופע תקין מדפיס את vmx או svm, kvm-ok מציג את KVM acceleration can be used, ו-/dev/kvm קיים במצב root:kvm של 660. אם ה-flag קיים אך ה-device node אינו קיים, טענו את ה-module ידנית וקראו את ה-kernel log:

sudo modprobe kvm_intel     # or kvm_amd
sudo dmesg | tail -n 20

קובץ אחד מצוטט לעיתים קרובות אך מפורש לעיתים קרובות באופן שגוי:

cat /sys/module/kvm_intel/parameters/nested   # Y or N

בתוך ה-VPS שלכם, זהו ההגדרה של ה-KVM module שלכם, והוא קובע האם אורח L2 יוכל לבצע nesting ברמה שלישית. הוא אינו מציין האם L0 הפעיל nesting עבורכם — /proc/cpuinfo ו-kvm-ok עונים על כך. הפרמטר nested הוא הכפתור שאתם מגדירים במכונה שבבעלותכם המלאה:

echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

הסרת ה-module נחסמת כאשר VM נמצא במצב פעיל, לכן כבו תחילה את ה-guests.

Why most VPS hosts leave it off

  • Live migration. מתן vmx חושף דגם CPU הכולל את ה-flag. אם ה-guest תלוי בתכונות CPU אלו, לא ניתן להעביר אותו בבטחה למכונה שבה ה-CPU אינו תומך בהן. ספק המבצע migration של לקוחות בין nodes ויתור על יכולת זו ברגע שהוא מאפשר nesting.
  • Attack surface. נתיבי ה-nested VMX/SVM הם מהקוד המורכב ביותר בשכבת ה-virtualization של ה-kernel, ויש להם היסטוריה של CVE.
  • L0 may not be KVM. אם systemd-detect-virt מדפיס את vmware, xen או microsoft, חוקי ה-nesting שייכים ל-stack הזה ולא ל-KVM.

אם אין flag ב-instance שלך? פנה לתמיכה (חלקם מאפשרים זאת per-VM), בחר תוכנית שתומכת ב-nesting, או עבור לשרת dedicated. שאר המדריך מניח שיש לך root במכונה שמציגה את ה-flag.

הרצת L2 guest באמצעות libvirt

sudo apt install -y qemu-system-x86 libvirt-daemon-system virtinst ovmf
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt,kvm "$USER"   # log out and back in

virt-install \
  --name guest1 \
  --memory 2048 \
  --vcpus 2 \
  --cpu host-passthrough \
  --disk path=/var/lib/libvirt/images/guest1.qcow2,size=20,format=qcow2,bus=virtio \
  --network network=default,model=virtio \
  --os-variant debian13 \
  --location https://deb.debian.org/debian/dists/trixie/main/installer-amd64/ \
  --graphics none \
  --console pty,target_type=serial \
  --extra-args 'console=ttyS0,115200n8'

אין צורך בסשן גרפי. התקנה דרך serial נמשכת זמן מה, לכן מומלץ להפעיל אותה בתוך shell קבוע: אותו workflow tmux שמשאיר סשנים של Claude Code פעילים ב-VPS שומר על קונסול virt-install מחובר גם לאחר ניתוק SSH. אם --os-variant debian13 נדחה, ה-osinfo-db שלך ישן יותר מהגרסה המדוברת — הרץ את osinfo-query os ובחר שם קיים. --cpu host-passthrough מעביר את vmx אל תוך ה-L2, וזה נחוץ רק אם ה-L2 חייב לבצע וירטואליזציה נוספת. הפוך את ה-guest לבטוח להפעלה (boot-safe) באמצעות virsh autostart guest1.

ה-bus של ה-virtio בדיסק וב-NIC אינו רק קישוט: מכשירי IDE ו-e1000 מוקשers (emulated) גורמים ל-traps ל-hypervisor בתדירות גבוהה בהרבה מאשר תורים של virtio, ובמצב nesting כל trap נגבה פעמיים.

Networking: החלק שחסר במדריכים

ל-VPS שלך יש כתובת IP ציבורית אחת והוא נמצא מאחורי רשת (fabric) המסננת כתובות MAC לא מוכרות. יש לכך שתי השלכות.

חיבור (Bridging) של אורחים ב-L2 לרשת הציבורית בדרך כלל לא יעבוד. אם תגדיר את br0 על ה-NIC הציבורי ותקצה לאורח כתובת MAC משלו, תראה שפקודות ARP נשלחות אך שום דבר לא חוזר — המתג (switch) של הספק מDROP את ה-frames מכתובת MAC שלא הוקצתה עבורך. אם זהו התסmind, הפסק לדבג את ה-bridge; זהו מנגנון הרשת.

השתמש ברשת NAT במקום. libvirt מספק את default: virbr0, 192.168.122.0/24, ו-dnsmasq leases, מה שמאפשר תקשורת יוצאת באופן מיידי. עבור תקשורת נכנסת, בצע TLS termination ב-L1 והשתמש ב-proxy — נתיבי ה-certificate להלן מגיעים מתוך הנפקת תעודת Let's Encrypt עם Certbot ב-Nginx:

server {
    listen 443 ssl;
    server_name lab.example.com;

    ssl_certificate     /etc/letsencrypt/live/lab.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lab.example.com/privkey.pem;

    location / {
        proxy_pass http://192.168.122.50:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

הקצה לאורח static lease ראשוני (virsh net-edit default) כדי שהכתובת בתוך ה-proxy_pass תישאר קבועה.

ממשקי ניהול נשארים מחוץ לאינטרנט: VNC בפורט 5900 וממשק ה-web UI של Proxmox בפורט 8006 צריכים להיות על ה-loopback, וניתן לגשת אליהם דרך SSH tunnel (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) או דרך WireGuard VPN המארח עצמית אל ה-VPS, מה שמציב את כל טווח ה-192.168.122.0/24 של האורחים ב-hop פרטי אחד בלבד. שמור על חומת אש (firewall) מצומצמת — sudo ufw allow 22,80,443/tcp, ולא יותר. אם האורחים מאבדים תקשורת יוצאת מיד לאחר הפעלת ufw, הגורם הנפוץ הוא DEFAULT_FORWARD_POLICY="DROP" בתוך /etc/default/ufw — הגדר אותו ל-ACCEPT וטען מחדש את ufw.

Proxmox ב-VPS

Proxmox VE 9 מבוסס על Debian 13, לכן התקנתו על Debian VPS מתבצעת על ידי הוספת ה-repository של pve-no-subscription והחבילה proxmox-ve. יש להעתיק את שורות ה-repository וה-keyring מהתיעוד הרשמי והעדכני של Proxmox — שימוש בכתובת URL מפוסט ישן בבלוג יגרום לכשל בהתקנה.

החבילות אינן החלק המורכב. Proxmox מצפה ל-vmbr0 המחובר ב-bridge לכרטיס רשת פיזי (NIC), מה שמוביל ישירות למגבלת ה-MAC-filtering שהוזכרה לעיל. המבנה שעובד ב-VPS הוא vmbr0 בשיטת NAT או מנותב (routed) ללא פורט פיזי מחובר, עם מכונות אורחים בטווח (range) פרטי, ושימוש בכללי DNAT או ב-reverse proxy על המארח עבור שירותים ציבוריים. במקרים שבהם השירותים הציבוריים הם containers ולא VMs, Traefik המקשר בין אפליקציות מרובות מקובץ Docker Compose אחד מבצע את אותה עבודת ניתוב עם תעודות (certificates) אוטומטיות. יש לבצע snapshot ל-/etc/network/interfaces לפני תחילת הפעולה: הגדרת bridge שגויה תחסום את הגישה למכונה שייתכן ואין לך גישה לקונסולה שלה.

ביצועים, בכנות

Nested Virtualization איטי יותר מ-single-level, והסיבה לכך היא ספציפית ולא כללית: העלות אינה נובעת מגישה לזיכרון, אלא מ-exits. כאשר מופעלים EPT/NPT, ה-L0 שומר shadow page tables עבור ה-L2, וקריאות זיכרון רגילות מתבצעות במהירות החומרה. הפעולות היקרות הן כל פעולה היוצאת ממצב guest — I/O, timer interrupts, MMIO, inter-processor interrupts — מכיוון ש-L2 exit מטופל על ידי ה-L0 ועשוי לעבור דרך ה-L1. עומס עבודה מבוסס CPU על נתונים שנמצאים ב-RAM נראה קרוב לביצועי native; כל דבר שבו ה-syscalls, חבילות רשת (packets) ו-disk I/O הם הגורם הדומיננטי, יחוש בתחושת השכבות.

לכן: השתמשו ב-virtio devices בכל מקום. וקובץ ה-qcow2 שלכם נמצא על דיסק שהספק כבר עשה לו virtualization — שתי שכבות של thin-provisioning, כאשר cache=none בדיסק של ה-guest מונע חזרה של אותם blocks בתוך שני page caches בו-זמנית. אין כאן נתוני benchmark: מדדו את עומס העבודה שלכם על ה-instance שלכם.

Failure modes, and the strings you will see

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used מ-kvm-ok. או שהמודול אינו טעון, או שה-flag אינו חשוף. בדקו תחילה את /proc/cpuinfo.

kvm: disabled by bios ב-dmesg. במחשב פיזי (bare metal), הפכו את ה-toggle של VT-x/SVM ב-firmware. בתוך VPS המשמעות היא ש-L0 אינו מעביר לכם את ההרחבות, ושום דבר שתקלידו בתוך ה-guest לא ישנה זאת.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. ל-CPU שה-kernel רואה אין vmx — שוב, החלטה של L0.

Could not access KVM kernel module: Permission denied. בעיית הרשאות, לא חומרה. ls -l /dev/kvm אמור להציג את הקבוצה kvm ואת ה-mode 660; הוסיפו את עצמכם לקבוצה זו והפעילו shell login חדש, מכיוון שחברות בקבוצה אינה חלה על סשן פעיל.

kvm: Device or resource busy כאשר QEMU מתחיל. hypervisor אחר מחזיק ב-CPU: הריצו את lsmod, חפשו את vboxdrv או את מודולי VMware לצד kvm_intel, והורידו (unload) את המודול שאינכם רוצים.

/var/run/libvirt/libvirt-sock: No such file or directory מ-virsh. ה-daemon כבוי: sudo systemctl enable --now libvirtd.

Proxmox: KVM virtualisation configured, but not available. ל-guest יש KVM acceleration מסומן ב-host שאינו יכול לספק זאת. תקנו את ה-nesting, או בטלו את הסימון ואשרו emulation.

Android emulator: x86_64 emulation currently requires hardware acceleration! שוב /dev/kvm — בדרך כלל בעיית קבוצה.

אין שגיאה כלל, והכל איטי מאוד. QEMU ללא accelerator flag חוזר ל-TCG, ה-software emulator שלו. זה תקין וזה איטי — עלייה (boot) שנמדדת בשניות הופכת לזו שנמדדת בדקות. העבירו את -accel kvm במפורש, כדי ש-QEMU ייעצר עם שגיאה במקום לבצע emulation בשקט.

guest נעלם באמצע ריצה. חפשו ב-dmesg את Out of memory: Killed process ... qemu-system-x86_64. guest מסוג L2 הוא תהליך בתוך L1, וה-OOM killer מתייחס אליו כמו לכל תהליך אחר. ה-RAM של L2 נלקח מההקצאה הקבועה של L1 — אין אפשרות לשאול מה-host.

Operating it: backups, upgrades, limits

Backups. העתקת קובץ qcow2 של guest פעיל ת produces תמונה פגומה. יש להשתמש ב-virsh shutdown guest1 ולבצע copy, או ליצור snapshot חיצוני (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) כך שכל הכתיבות יופנו ל-overlay בזמן שאתם מעתיקים את ה-base הסטטי, ולאחר מכן לאחד אותם באמצעות virsh blockcommit. יש להעביר את העתקים מחוץ ל-VPS — snapshot שנשמר על אותו דיסק אינו מספק הגנה.

Upgrades. הפקודה apt full-upgrade מתקינה מודולים חדשים של kvm_intel/kvm_amd, אך ה-kernel הפעיל שומר על המודולים הישנים עד לביצוע reboot. יש להשאיר את ה-kernel הקודם מותקן ולהריץ מחדש את kvm-ok לאחר כל שינוי kernel: host שחוזר ללא vmx נמצא מרחק reboot אחד בלבד מפעילות תקינה.

Where this stops scaling. כתובת IP ציבורית אחת פירושה שכל שירות L2 מגיע לעולם דרך proxy או כלל DNAT ב-L1. Live migration אינו זמין. תחת CPU contention, נתיב ה-nested exit הוא הדבר הראשון שחווה ירידה בביצועים. hypervisor עם מספר guests הוא מכונה שבה ה-RAM כבר נוצל במלואו — VM nested לא יכול להתגבר על הקצאה קבועה באמצעות overcommit. כאשר מעבדת (lab) גדלה מעבר לכך, הפתרון אינו הוספת שכבת nesting נוספת; הפתרון הוא מכונה ייעודית שבה אתם ה-L0 וכל המגבלות הללו אינן תקפות.

FAQ

Do I need nested virtualization to run Docker on a VPS?

No. Containers share your VPS kernel and never open /dev/kvm, so a plain instance with no vmx or svm flag runs Docker and Docker Compose fine. Nesting only matters when you want a second kernel: a Proxmox lab, a Windows guest, Firecracker microVMs, an Android emulator, or CI runners that boot VM images.

How do I check whether my VPS supports nested virtualization?

Run grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, then kvm-ok from the cpu-checker package. A usable instance prints vmx (Intel) or svm (AMD), kvm-ok reports KVM acceleration can be used, and /dev/kvm exists with group kvm and mode 660. Ignore /sys/module/kvm_intel/parameters/nested for this question — that file describes your own KVM module, not what the provider's hypervisor exposed to you.

Why do most VPS providers disable nested virtualization?

Exposing vmx means handing the guest a CPU model that carries the flag, and a guest that depends on those CPU features cannot be live-migrated onto a machine whose CPU lacks them — a provider that drains nodes by moving customers around gives that up. The nested VMX/SVM code paths also carry a long CVE history. Some hosts still enable it per-VM on request, and others document nesting as a plan feature.

My nested VM has no network on the public bridge. What is wrong?

The provider's switch drops frames from a MAC address it never leased you, so an L2 guest bridged onto the public NIC sends ARP and hears nothing back. Stop debugging br0 — use libvirt's NAT default network (virbr0, 192.168.122.0/24), give the guest a static lease, and publish anything public through a reverse proxy or DNAT rule on the VPS itself.

How much slower is a nested VM?

The cost lands on VM exits, not on memory access. With EPT/NPT active, ordinary reads and writes inside L2 run at hardware speed, while I/O, timer interrupts, MMIO and IPIs are handled by L0 and may be bounced back through L1. CPU-bound work over data already in RAM looks close to native; syscall-, packet- and disk-heavy workloads feel every layer. Use virtio devices everywhere and cache=none on guest disks, then measure your own workload.

#nested-virtualization#kvm#proxmox#vps#qemu#libvirt