اجرای Proxmox روی VPS: آیا Nested Virtualization ممکن است؟

پاسخ کوتاه

مجازی‌سازی تو در تو (Nested virtualization) به معنای اجرای یک هایپروایزر در داخل یک ماشین مجازی است: VPS شما در حال حاضر یک مهمان است و شما می‌خواهید که خودتان میزبان مهمان‌های دیگری باشید. این قابلیت تنها زمانی کار می‌کند که هایپروایزر ارائه‌دهندهٔ خدمات شما، به‌طور عمدی افزونه‌های مجازی‌سازی CPU را در اختیار instance شما قرار دهد. برای بررسی، /proc/cpuinfo را برای پرچم vmx (در اینتل) یا svm (در ای‌ام‌دی) چک کنید؛ اگر هیچ‌کدام ظاهر نشدند، هیچ پیکربندی‌ای در داخل VPS این مشکل را حل نخواهد کرد.

ابتدا یک نکته برای مدیریت انتظارات: Docker به هیچ‌کدام از این‌ها نیاز ندارد. کانتینرها از هسته (kernel) VPS شما استفاده می‌کنند و هرگز با /dev/kvm تعاملی ندارند. اگر هدف واقعی شما «اجرای چندین سرویس در کانتینر روی سرور» است، شما در حال حاضر ابزار لازم را در اختیار دارید. مجازی‌سازی تو در تو زمانی اهمیت پیدا می‌کند که بخواهید یک هستهٔ دوم، یک آزمایشگاه Proxmox، یک مهمان ویندوزی، میکرو ماشین‌های مجازی Firecracker، شبیه‌ساز اندروید، یک محیط تست Kubernetes متشکل از ماشین‌های مجازی واقعی، یا CI runnerهایی داشته باشید که ایمیج‌های ماشین مجازی را بوت می‌کنند.

چه چیزی در واقع در حال nesting است

سه لایه وجود دارد:

• L0، هایپروایزر ارائه‌دهنده، روی سخت‌افزار اصلی. شما به آن دسترسی ندارید.
• L1، همان VPS شما. برای L0، این فقط یک مهمان (guest) است.
• L2، ماشین مجازی (VM) که می‌خواهید داخل VPS خود اجرا کنید.

مجازی‌سازی سخت‌افزاری شامل VT-x (فلگ vmx) به همراه EPT در اینتل، و AMD-V / SVM (svm) به همراه RVI/NPT در AMD است. یک هایپروایزر از این دستورالعمل‌ها استفاده می‌کند تا وارد حالت مهمان شود و به CPU اجازه دهد همزمان دو جدول صفحه (page table) را پیمایش کند.

هیچ‌کدام از این‌ها برای بازگشت‌پذیری (re-entrant) طراحی نشده‌اند، بنابراین nesting شبیه‌سازی می‌شود: وقتی L1 یک دستور VMX مانند VMLAUNCH یا VMRESUME را اجرا می‌کند، به L0 تله (trap) می‌زند؛ L0 ساختارهای سایه (shadow structures) را برای L2 به نمایندگی از L1 نگهداری می‌کند. در CPUهایی که دارای VMCS shadowing هستند، دستورات VMREAD و VMWRITE مربوط به L1 می‌توانند بدون خروج (exit) پردازش شوند، که بخش بزرگی از این ترافیک را حذف می‌کند اما نه همه آن را. KVM این کار را به‌خوبی انجام می‌دهد، اما این L0 است که در هر خروج کار اضافه انجام می‌دهد؛ به همین دلیل است که ارائه‌دهنده باید این قابلیت را فعال کند.

وقتی L0 از نوع KVM باشد، برای داشتن یک L2 شتاب‌یافته (accelerated)، دو شرط باید همزمان برقرار باشند:

1. ماژول KVM در L0 با nested=1 بارگذاری شده باشد.
2. L0 به VPS شما یک مدل CPU بدهد که این فلگ را داشته باشد؛ <cpu mode='host-passthrough'/> در libvirt، cpu: host در Proxmox، و -cpu host در QEMU خام. یک مدل شبیه‌سازی‌شده عمومی (qemu64، kvm64) فلگ vmx را حتی زمانی که nesting به‌صورت سراسری فعال است، مخفی می‌کند.

سایر هایپروایزرها سوئیچ‌های خاص خود را دارند. برای نمونه، Hyper-V افزونه‌های مجازی‌سازی را برای یک هایپروایزر تو در تو (nested) در داخل VMهای خود شبیه‌سازی می‌کند، اما فقط در VMهایی که nesting در آن‌ها به‌صورت تک‌به‌تک فعال شده باشد.

بررسی 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

یک نمونه (instance) قابل‌استفاده، vmx یا svm را چاپ می‌کند، kvm-ok مقدار KVM acceleration can be used را نشان می‌دهد و /dev/kvm به عنوان root:kvm با حالت 660 وجود دارد. اگر فلگ موجود است اما گره دستگاه (device node) وجود ندارد، ماژول را به‌صورت دستی بارگذاری کرده و لاگ هسته (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 شما است و تعیین می‌کند که آیا یک guest لایه L2 می‌تواند یک لایه سوم را nest کند یا خیر. این فایل هیچ چیزی درباره اینکه آیا 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 در حال اجرا است رد می‌شود؛ بنابراین ابتدا guestها را خاموش کنید. اگر آن ماشین یک Proxmox host است، فعال‌سازی nested virtualization در Proxmox VE 9 همان تغییر در modprobe.d و همچنین تنظیم cpu: host برای هر VM را پوشش می‌دهد؛ این تنظیم باعث می‌شود flag داخل guest قابل مشاهده باشد.

چرا اکثر میزبان‌های VPS آن را غیرفعال می‌گذارند

• مهاجرت زنده (Live migration). ارائه vmx به شما به معنای نمایش یک مدل CPU است که این پرچم را حمل می‌کند، و یک مهمان (guest) که به این ویژگی‌های CPU وابسته است، نمی‌تواند به‌طور ایمن به ماشینی که فاقد این ویژگی‌هاست مهاجرت کند. میزبانی که با مهاجرت دادن مشتریان، گره‌ها (nodes) را تخلیه می‌کند، به محض فعال‌سازی nesting این قابلیت را از دست می‌دهد.
• سطح حمله (Attack surface). مسیرهای nested VMX/SVM از پیچیده‌ترین بخش‌های کد در لایه مجازی‌سازی هسته (kernel) هستند و تاریخچه‌ای از CVEها را به همراه دارند.
• لایه L0 ممکن است KVM نباشد. اگر systemd-detect-virt خروجی vmware، xen یا microsoft را نمایش دهد، قوانین nesting مربوط به آن پشته (stack) است، نه KVM.

پرچمی روی instance خود نمی‌بینید؟ از پشتیبانی بپرسید (برخی آن را برای هر VM به‌صورت جداگانه فعال می‌کنند)، طرحی را انتخاب کنید که nesting را مستند کرده باشد، یا به یک سرور اختصاصی (dedicated box) مهاجرت کنید. ادامه این مطلب فرض را بر این می‌گذارد که شما دسترسی root روی ماشینی دارید که این پرچم را نمایش می‌دهد.

اجرای یک guest سطح L2 با 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'

نیازی به session گرافیکی نیست. نصب از طریق سریال مدتی طول می‌کشد، بنابراین آن را در یک shell ماندگار اجرا کنید: همان گردش‌کار tmux که sessionهای Claude Code را روی یک VPS زنده نگه می‌دارد، یک کنسول virt-install را نیز در صورت قطع اتصال SSH متصل نگه می‌دارد. اگر --os-variant debian13 رد شد، به این دلیل است که osinfo-db شما قدیمی‌تر از این نسخه است؛ دستور osinfo-query os را اجرا کرده و نامی را انتخاب کنید که وجود دارد. --cpu host-passthrough قابلیت vmx را به L2 منتقل می‌کند؛ این کار تنها زمانی لازم است که L2 خود نیاز به مجازی‌سازی داشته باشد. با استفاده از virsh autostart guest1، بوت guest را ایمن کنید.

باس virtio برای دیسک و کارت شبکه صرفاً جنبه تزئینی ندارد: دستگاه‌های شبیه‌سازی‌شده IDE و e1000 بسیار بیشتر از صف‌های virtio باعث ایجاد trap در hypervisor می‌شوند. در حالت nesting، خروجی (exit) که L0 نمی‌تواند به‌تنهایی آن را تکمیل کند، به L1 منعکس می‌شود که مدیریت آن می‌تواند باعث ایجاد خروجی‌های بیشتری در سطح L1 شود.

شبکه: بخشی که در آموزش‌ها نادیده گرفته می‌شود

سرور مجازی (VPS) شما یک IP عمومی دارد و پشت شبکه‌ای قرار گرفته است که آدرس‌های MAC ناشناس را فیلتر می‌کند. این موضوع دو پیامد دارد.

پل‌زدن (Bridging) مهمان‌های L2 به شبکه عمومی معمولاً کار نمی‌کند. اگر br0 را روی کارت شبکه عمومی (NIC) قرار دهید و به مهمان یک MAC اختصاصی بدهید، خواهید دید که درخواست‌های ARP ارسال می‌شوند اما پاسخی دریافت نمی‌کنید؛ سوئیچ ارائه‌دهنده، فریم‌هایی را که از MACای ارسال شده که به شما اجاره نداده است، مسدود می‌کند. اگر با این مشکل مواجه شدید، عیب‌یابی پل را متوقف کنید؛ این ماهیت عملکرد شبکه است.

از شبکه NAT استفاده کنید. libvirt شامل default است: virbr0، 192.168.122.0/24، اجاره‌های dnsmasq، و ارتباط خروجی بلافاصله کار می‌کنند. برای ارتباط ورودی، TLS را در L1 خاتمه دهید و درخواست را پروکسی کنید؛ مسیرهای گواهی در ادامه از صدور گواهی 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 و رابط وب Proxmox روی پورت 8006 باید روی loopback باشند و از طریق تونل SSH (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) یا یک شبکه خصوصی WireGuard روی VPS به آن‌ها دسترسی پیدا کنید، که کل محدوده مهمان 192.168.122.0/24 را در یک گام خصوصی در دسترس قرار می‌دهد. فایروال را محدود نگه دارید، sudo ufw allow 22,80,443/tcp، و هیچ چیز دیگری را باز نگذارید. اگر مهمان‌ها بلافاصله پس از فعال‌سازی ufw اتصال خروجی خود را از دست دادند، مقصر معمولاً DEFAULT_FORWARD_POLICY="DROP" در /etc/default/ufw است؛ آن را روی ACCEPT تنظیم کرده و ufw را دوباره بارگذاری کنید.

اجرای Proxmox روی VPS

پایهٔ Proxmox VE 9 سیستم‌عامل Debian 13 است، بنابراین با افزودن مخزن pve-no-subscription و بستهٔ proxmox-ve روی یک VPS مبتنی بر Debian نصب می‌شود. خطوط مربوط به مخزن و keyring را مستقیماً از مستندات فعلی Proxmox دریافت کنید؛ استفاده از URLهای کپی‌شده از پست‌های وبلاگی قدیمی، فرآیند نصب را مختل می‌کند. پیش از آنکه یک شب را صرف پیکربندی شبکه کنید، ارزش دارد که بررسی کنید آیا اصلاً Proxmox برای سخت‌افزار اجاره‌ای مناسب است یا خیر؛ مقایسهٔ هزینه و قابلیت‌های یک سرور Proxmox خانگی با یک VPS اجاره‌ای نسخه‌ای از این پرسش است که محاسبات مربوط به توان مصرفی و سخت‌افزار در آن انجام شده است.

بخش دشوار کار، بسته‌ها نیستند. Proxmox انتظار دارد vmbr0 به یک کارت شبکه فیزیکی (NIC) متصل (bridge) باشد که مستقیماً به بن‌بست فیلترینگ MAC که پیش‌تر ذکر شد، ختم می‌شود. ساختاری که روی VPS کار می‌کند، یک vmbr0 مبتنی بر NAT یا مسیریابی است که به هیچ پورت فیزیکی متصل نیست؛ در این حالت، مهمان‌ها در یک رنج شبکه خصوصی قرار می‌گیرند و برای هر سرویس عمومی، از قوانین DNAT یا یک reverse proxy روی میزبان استفاده می‌شود. در مواردی که سرویس‌های عمومی به جای ماشین مجازی (VM)، کانتینر هستند، استفاده از Traefik برای مدیریت چندین برنامه از یک فایل Docker Compose همان وظیفه مسیریابی را با گواهی‌های خودکار انجام می‌دهد. ابتدا از /etc/network/interfaces اسنپ‌شات بگیرید: یک تعریف اشتباه برای bridge می‌تواند دسترسی شما را به ماشینی که ممکن است کنسول آن را در اختیار نداشته باشید، به‌طور کامل قطع کند.

عملکرد، بدون اغراق

مجازی‌سازی تو در تو (Nested) از حالت تک‌سطحی کندتر است و این افت عملکرد مکانیسم مشخصی دارد: هزینهٔ اصلی بر دوش خروج‌ها (exits) و ترجمهٔ آدرس است، نه دستورالعمل‌های عادی. با وجود EPT/NPT، لایه L0 جداول صفحه L1 برای L2 و جداول خودش را در یک جدول سایه (shadow table) ادغام می‌کند تا TLB hit با سرعت سخت‌افزاری اجرا شود. اما TLB miss هزینه بیشتری دارد: سخت‌افزار باید جدول صفحه مهمان و جدول سایه را همزمان پیمایش کند و هر تغییری که L1 در جداول خود ایجاد می‌کند، باعث یک خروج (exit) می‌شود تا L0 بتواند جدول سایه را همگام‌سازی کند. آنچه هزینه‌بر است، هر عملیاتی است که از حالت مهمان خارج می‌شود؛ مانند I/O، وقفه‌های تایمر، MMIO و وقفه‌های بین پردازنده‌ای، زیرا خروج L2 توسط L0 مدیریت شده و ممکن است دوباره از طریق L1 بازتاب یابد. کارهای متکی بر CPU با مجموعه داده‌های کوچک، سرعتی نزدیک به حالت بومی (native) دارند؛ اما مجموعه داده‌های بزرگ در حافظه، هزینه TLB miss را می‌پردازند و هر چیزی که تحت سلطه syscallها، بسته‌های شبکه و I/O دیسک باشد، تأثیر لایه‌ها را نشان می‌دهد.

بنابراین: همه‌جا از دستگاه‌های virtio استفاده کنید. فایل qcow2 شما روی دیسکی قرار دارد که ارائه‌دهنده قبلاً آن را مجازی‌سازی کرده است؛ یعنی دو لایه thin-provisioning روی هم قرار گرفته‌اند، جایی که cache=none روی دیسک مهمان مانع از آن می‌شود که بلوک‌های یکسان همزمان در دو page cache قرار بگیرند. اینجا هیچ عدد بنچمارکی وجود ندارد: بار کاری خود را روی نمونه (instance) خودتان اندازه‌گیری کنید.

حالت‌های شکست و پیام‌هایی که مشاهده خواهید کرد

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used از طرف kvm-ok. یا ماژول بارگذاری نشده است یا فلگ مربوطه در دسترس نیست. ابتدا /proc/cpuinfo را بررسی کنید.

kvm: disabled by bios در dmesg. روی سخت‌افزار فیزیکی (bare metal)، گزینه VT-x/SVM را در تنظیمات firmware فعال کنید. در محیط VPS، این پیام به این معناست که لایه L0 قابلیت‌های مجازی‌سازی را به شما ارائه نمی‌دهد و هیچ دستوری در سیستم‌عامل مهمان (guest) این وضعیت را تغییر نخواهد داد.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. پردازنده‌ای که هسته (kernel) شما می‌بیند فاقد vmx است؛ این نیز تصمیمی است که در لایه L0 گرفته شده است.

Could not access KVM kernel module: Permission denied. مشکل از مجوزهاست، نه سخت‌افزار. ls -l /dev/kvm باید گروه kvm و حالت 660 را نشان دهد؛ خودتان را به آن گروه اضافه کنید و یک نشست (shell) جدید باز کنید، زیرا عضویت در گروه برای نشست‌های در حال اجرا اعمال نمی‌شود.

kvm: Device or resource busy هنگام شروع QEMU. یک ماژول hypervisor دیگر پردازنده را در اختیار گرفته است: دستور 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. قابلیت شتاب‌دهنده KVM برای یک ماشین مجازی روی میزبانی فعال شده که قادر به ارائه آن نیست. قابلیت nesting را اصلاح کنید یا تیک آن را بردارید و شبیه‌سازی (emulation) را بپذیرید.

شبیه‌ساز Android: x86_64 emulation currently requires hardware acceleration! دوباره همان /dev/kvm، که معمولاً به دلیل مشکل عضویت در گروه است.

هیچ خطایی وجود ندارد اما همه‌چیز بسیار کند است. QEMU بدون فلگ شتاب‌دهنده به TCG (شبیه‌ساز نرم‌افزاری خود) بازمی‌گردد. این حالت صحیح است اما بسیار کند عمل می‌کند؛ زمان بوت که باید چند ثانیه باشد، به چند دقیقه می‌رسد. فلگ -accel kvm را صراحتاً ارسال کنید تا QEMU به‌جای شبیه‌سازی بی‌سروصدا، با خطا متوقف شود.

یک ماشین مجازی در حین اجرا ناپدید می‌شود. در dmesg به دنبال Out of memory: Killed process ... qemu-system-x86_64 بگردید. یک ماشین مجازی L2 در واقع یک پردازش در لایه L1 است و OOM killer با آن مانند سایر پردازش‌ها رفتار می‌کند. رم اختصاص‌یافته به L2 از سهمیه ثابت L1 تأمین می‌شود و امکان قرض گرفتن از میزبان (host) وجود ندارد.

عملیات: پشتیبان‌گیری، ارتقا، محدودیت‌ها

پشتیبان‌گیری. کپی کردن فایل qcow2 یک مهمان (guest) در حال اجرا، ریسک ایجاد یک تصویر ناسازگار را به همراه دارد، زیرا مهمان در حین خواندن شما، همچنان به نوشتن ادامه می‌دهد. یا دستور virsh shutdown guest1 را اجرا کنید، منتظر بمانید تا virsh domstate guest1 وضعیت shut off را گزارش دهد (دستور shutdown ممکن است پیش از توقف کامل مهمان بازگردد)، و سپس کپی کنید؛ یا یک snapshot خارجی (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) بگیرید تا عملیات نوشتن به یک overlay هدایت شود و شما بتوانید base ثابت را کپی کنید، سپس با virsh blockcommit guest1 vda --active --pivot آن را ادغام کنید. نسخه‌های پشتیبان را از VPS خارج کنید؛ snapshot روی همان دیسک، در برابر هیچ خطری محافظت ایجاد نمی‌کند.

ارتقا. دستور apt full-upgrade ماژول‌های جدید kvm_intel/kvm_amd را نصب می‌کند، اما هسته (kernel) در حال اجرا تا زمان reboot، از ماژول‌های قدیمی استفاده می‌کند. هسته قبلی را نصب نگه دارید و پس از هر تغییر در هسته، kvm-ok را دوباره اجرا کنید: میزبانی که بدون vmx بالا می‌آید، تنها با یک ورودی boot فاصله تا بازگشت به وضعیت کاری دارد.

محدودیت‌های مقیاس‌پذیری. داشتن یک IP عمومی به این معناست که هر سرویس L2 از طریق یک proxy یا یک قانون DNAT در L1 به دنیای خارج متصل می‌شود. مهاجرت زنده (Live migration) در این مدل امکان‌پذیر نیست. در شرایط رقابت بر سر CPU، مسیر خروج تو در تو (nested exit path) اولین بخشی است که دچار افت عملکرد می‌شود. همچنین، یک hypervisor با چندین مهمان، ماشینی است که RAM آن از پیش تخصیص یافته است؛ VMهای تو در تو نمی‌توانند با overcommit از محدودیت تخصیص ثابت فرار کنند. زمانی که یک آزمایشگاه از این مقیاس فراتر رفت، پاسخ، افزایش لایه‌های تو در تو نیست؛ بلکه استفاده از یک سرور اختصاصی است که در آن شما L0 هستید و هیچ‌کدام از این محدودیت‌ها اعمال نمی‌شود.

FAQ

آیا برای اجرای Docker روی VPS به nested virtualization نیاز دارم؟

خیر. کانتینرها از هسته (kernel) سیستم‌عامل VPS شما استفاده می‌کنند و هرگز /dev/kvm را باز نمی‌کنند، بنابراین یک نمونه معمولی بدون هیچ پرچم vmx یا svm می‌تواند Docker و Docker Compose را به‌خوبی اجرا کند. قابلیت nesting تنها زمانی اهمیت دارد که به هسته دوم نیاز داشته باشید: برای مثال در آزمایشگاه Proxmox، مهمان ویندوزی، microVMهای Firecracker، شبیه‌ساز اندروید یا CI runnerهایی که ایمیج‌های VM را بوت می‌کنند.

چگونه بررسی کنم که آیا VPS من از nested virtualization پشتیبانی می‌کند؟

دستور grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u و سپس kvm-ok را از بسته cpu-checker اجرا کنید. یک نمونه قابل‌استفاده، vmx (برای Intel) یا svm (برای AMD) را چاپ می‌کند، kvm-ok مقدار KVM acceleration can be used را گزارش می‌دهد و /dev/kvm با گروه kvm و دسترسی 660 وجود دارد. برای این پرسش، /sys/module/kvm_intel/parameters/nested را نادیده بگیرید؛ آن فایل ماژول KVM خودتان را توصیف می‌کند، نه آنچه که هایپروایزر ارائه‌دهنده به شما ارائه داده است.

چرا اکثر ارائه‌دهندگان VPS قابلیت nested virtualization را غیرفعال می‌کنند؟

ارائه vmx به این معناست که به مهمان مدلی از CPU داده شود که این پرچم را داشته باشد، و مهمانی که به این ویژگی‌های CPU وابسته است، نمی‌تواند به صورت زنده (live-migrate) به ماشینی که فاقد این ویژگی‌هاست منتقل شود؛ ارائه‌دهنده‌ای که با جابه‌جایی مشتریان، گره‌ها را تخلیه می‌کند، این قابلیت را از دست می‌دهد. مسیرهای کد nested VMX/SVM همچنین تاریخچه طولانی از CVEها دارند. برخی میزبان‌ها همچنان آن را در صورت درخواست برای هر VM فعال می‌کنند و برخی دیگر nesting را به عنوان یکی از ویژگی‌های طرح‌های خود مستند کرده‌اند.

VM تو در توی من روی bridge عمومی شبکه ندارد. مشکل چیست؟

سوییچ ارائه‌دهنده، فریم‌هایی را که از آدرس MAC اجاره‌نشده ارسال می‌شوند مسدود می‌کند، بنابراین یک مهمان L2 که روی NIC عمومی پل شده است، ARP ارسال می‌کند اما پاسخی دریافت نمی‌کند. عیب‌یابی br0 را متوقف کنید، از شبکه NAT در libvirt (default، virbr0، 192.168.122.0/24) استفاده کنید، به مهمان یک lease ایستا بدهید و هر سرویس عمومی را از طریق یک reverse proxy یا قانون DNAT روی خودِ VPS منتشر کنید.

یک VM تو در تو چقدر کندتر است؟

هزینه این کار به VM exitها و ترجمه آدرس‌ها مربوط می‌شود. با فعال بودن EPT/NPT، دستورالعمل‌ها و TLB hitها در لایه L2 با سرعت سخت‌افزار اجرا می‌شوند، اما TLB missها باعث پیمایش جداول صفحه اضافی می‌شوند و I/O، وقفه‌های تایمر، MMIO و IPIها توسط L0 مدیریت شده و ممکن است از طریق L1 بازگردانده شوند. کارهای متکی به CPU با مجموعه داده‌های کوچک، نزدیک به سرعت بومی (native) به نظر می‌رسند؛ اما کارهای سنگین در حافظه، syscallها، بسته‌های شبکه و دیسک، تأثیر هر لایه را نشان می‌دهند. از دستگاه‌های virtio در همه جا و cache=none روی دیسک‌های مهمان استفاده کنید و سپس بار کاری خود را اندازه‌گیری کنید.