VPS پر Proxmox چل سکتے ہیں؟ nested virtualization چیک

مختصر جواب

نیسٹڈ ورچولائزیشن کا مطلب ہے کہ ایک ہائپروائزر کسی ورچول مشین کے اندر چل رہا ہے۔ آپ کا VPS پہلے ہی ایک گیسٹ ہے، اور آپ اسے اپنے گیسٹس کو ہوسٹ کرنا چاہتے ہیں۔ یہ تب ہی کام کرتا ہے جب آپ کے فراہم کنندہ کا ہائپروائزر جان بوجھ کر CPU کے ورچولائزیشن ایکسٹینشنز کو آپ کی انسٹنس تک بھیجے۔ /proc/cpuinfo میں vmx flag (Intel) یا svm (AMD) کے لیے چیک کریں۔ اگر کوئی بھی نظر نہ آئے، تو VPS کے اندر آپ جو بھی کنفیگر کریں گے اس سے کوئی فرق نہیں پڑے گا۔

پہلے ایک بات واضح کر لیں: Docker کو اس میں سے کچھ بھی نہیں چاہیے۔ کنٹینرز آپ کے VPS کرنیل کو استعمال کرتے ہیں اور کبھی /dev/kvm کو استعمال نہیں کرتے۔ اگر اصل مقصد "میرے سرور پر کنٹینرز میں کئی سروسز چلانا" ہے، تو آپ کے پاس پہلے ہی ضروری چیزیں موجود ہیں۔ نیسٹنگ اس وقت اہم ہو جاتی ہے جب آپ کو دوسرا کرنیل چاہیے — جیسے Proxmox لیب، Windows گیسٹ، Firecracker microVMs، Android ایمولیٹر، حقیقی VMs پر مشتمل Kubernetes ٹیسٹ بیڈ، یا CI رنرز جو VM امیجز بوٹ کرتے ہیں۔

دراصل کیا nesting کیا جا رہا ہے

تین تہہ:

• L0 — فراہم کنندہ کا hypervisor، براہ راست ہارڈویئر پر۔ آپ کی اس تک کوئی رسائی نہیں ہے۔
• L1 — آپ کا VPS۔ L0 کے لیے یہ صرف ایک guest ہے۔
• L2 — وہ VM جسے آپ اپنے VPS کے اندر چلانا چاہتے ہیں۔

ہارڈویئر virtualization انٹیل پر VT-x (یعنی vmx flag) اور EPT ہے، جبکہ AMD پر AMD-V / SVM (svm) اور RVI/NPT ہے۔ ایک hypervisor ان ہدایات کا استعمال guest mode میں داخل ہونے اور CPU کو ایک ساتھ دو page tables چلانے کے لیے کرتا ہے۔

ان میں سے کوئی بھی re-entrant ہونے کے لیے ڈیزائن نہیں کیا گیا تھا، اس لیے nesting کی نقل کی جاتی ہے: جب L1 ایک VMX instruction چلاتا ہے تو یہ L0 میں trap ہو جاتا ہے، جو L1 کی طرف سے L2 کے لیے shadow structures کو برقرار رکھتا ہے۔ KVM یہ کام اچھی طرح کرتا ہے، لیکن یہ L0 ہے جو ہر exit پر اضافی کام کرتا ہے — اسی لیے فراہم کنندہ کو اس کی اجازت دینے کا انتخاب کرنا پڑتا ہے۔

ایک accelerated L2 کے لیے دونوں شرائط کا پوری ہونا ضروری ہے:

1. L0 کا KVM module nested=1 کے ساتھ load ہو۔
2. L0 آپ کے VPS کو ایک ایسا CPU model دے جس میں وہ flag موجود ہو — libvirt میں <cpu mode='host-passthrough'/>، Proxmox میں cpu: host، اور raw QEMU میں -cpu host۔ کوئی generic emulated model (qemu64، kvm64) vmx کو چھپا دیتا ہے، یہاں تک کہ جب 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

ایک قابل استعمال انسٹنس 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 guest تیسرے لیول کو nest کر سکتا ہے۔ یہ اس بارے میں کچھ نہیں بتاتا کہ آیا L0 نے آپ کے لیے nesting فعال کی ہے — /proc/cpuinfo اور kvm-ok اس کا جواب دیتے ہیں۔ nested parameter وہ knob ہے جسے آپ اپنی ملکیت والی مشین پر سیٹ کرتے ہیں:

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

VM چلنے کے دوران module کے ہٹانے سے انکار کر دیا جاتا ہے، اس لیے پہلے guests کو بند کریں۔

اکثر VPS ہوسٹس اسے کیوں بند رکھتے ہیں

• لائیو مائگریشن۔ آپ کو vmx دینے کا مطلب ہے کہ ایک ایسا CPU ماڈل ظاہر ہوگا جس میں یہ فلیگ موجود ہوگا، اور ایک گیسٹ جو ان CPU فیچرز پر منحصر ہو، اسے محفوظ طریقے سے کسی ایسی مشین پر منتقل نہیں کیا جا سکتا جس کے CPU میں یہ فیچرز نہ ہوں۔ جو ہوسٹ کسٹمرز کو منتقل کر کے نوڈز خالی کرتا ہے، وہ یہ سہولت نیسٹنگ فعال کرتے ہی اس وقت کھو دیتا ہے۔
• ایٹیک سطح۔ نیسٹڈ VMX/SVM پاتھ کرنل کی ورچوئلائزیشن لیئر کے سب سے پیچیدہ کوڈ میں شامل ہیں، اور ان کی CVE ہسٹری بھی اسی کے مطابق ہے۔
• L0 کا KVM ہونا ضروری نہیں۔ اگر systemd-detect-virt کا آؤٹ پٹ vmware، xen یا microsoft ہو، تو نیسٹنگ کے قواعد اسی اسٹیک کے ہوں گے، KVM کے نہیں۔

آپ کی انسٹانس پر فلیگ موجود نہیں ہے؟ سپورٹ سے رابطہ کریں (کچھ اسے فی-VM فعال کر دیتے ہیں)، ایسا پلن منتخب کریں جس میں نیسٹنگ کی دستاویز ہو، یا ایک ڈیڈیکیٹڈ باکس پر منتقل ہو جائیں۔ اس مضمون کا باقی حصہ اس بات کا فرض کرتا ہے کہ آپ کے پاس کسی ایسی مشین پر روٹ رسائی ہے جو یہ فلیگ دکھاتی ہے۔

libvirt کے ساتھ ایک L2 گیسٹ چلانا

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'

کوئی گرافیکل سیشن ضروری نہیں ہے۔ ایک سیریل انسٹالیشن کچھ دیر تک چلتی ہے، اس لیے اسے ایک مستقل شل کے اندر شروع کریں: وہی tmux ورک فلو جو ایک VPS پر Claude Code سیشنز کو زندہ رکھتا ہے ایک منقطع ہونے والے SSH کنکشن کے بعد بھی virt-install کنسول کو منسلک رکھتا ہے۔ اگر --os-variant debian13 مسترد ہو جائے، تو آپ کا osinfo-db اس ریلیز سے پرانا ہے — osinfo-query os چلائیں اور ایک ایسا نام منتخب کریں جو موجود ہو۔ --cpu host-passthrough vmx کو L2 میں نیچے بھیجتا ہے، جو صرف اس وقت ضروری ہے جب L2 کو باری باری ورچولائز کرنا ہو۔ گیسٹ کو virsh autostart guest1 کے ساتھ بوت-سیف بنائیں۔

ڈسک اور NIC پر virtio بس محض سجاوٹ نہیں ہے: ایمولیٹڈ IDE اور e1000 ڈیوائزز ہائپروائزر میں virtio قطاروں سے کہیں زیادہ بار ٹریپ ہوتے ہیں، اور نسٹنگ کے تحت ہر ٹریپ کی قیمت دوگنی ادا کی جاتی ہے۔

نیٹ ورکنگ: وہ حصہ جو سبق خاکے چھوڑ دیتے ہیں

آپ کے VPS کا ایک پبلک IP ہے اور یہ ایک ایسے نیٹ ورک ڈھانچے کے پیچھے ہے جو نامعلوم MAC پتوں کو فلٹر کرتا ہے۔ اس کے دو نتائج ہیں۔

L2 گیسٹ کو پبلک نیٹ ورک پر برج کرنا عموماً کام نہیں کرتا۔ br0 کو پبلک NIC پر لگائیں، گیسٹ کو اس کا اپنا MAC دیں، اور آپ دیکھیں گے کہ ARP باہر جاتا ہے اور کچھ واپس نہیں آتا — فراہم کنندہ کا سوئچ ان فریمز کو ڈراپ کر دیتا ہے جن کا MAC اس نے آپ کو کبھی لیز نہیں کیا۔ اگر آپ کی خرابی کا یہ علامت ہے، تو برج ڈیبگ کرنا چھوڑ دیں؛ یہ اس کا طریقہ کار ہے۔

اس کے بجائے NAT نیٹ ورک استعمال کریں۔ libvirt میں default شامل ہے: virbr0، 192.168.122.0/24، dnsmasq لیزز، اور آؤٹ باؤنڈ فوراً کام کرتا ہے۔ ان باؤنڈ کے لیے، L1 پر TLS ختم کریں اور اندر پراکسی کریں — نیچے دیے گئے سرٹیفکیٹ پاتھ Certbot اور Nginx کے ساتھ Let's Encrypt سرٹیفکیٹ جاری کرنا سے آئے ہیں:

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;
    }
}

پہلے گیسٹ کو ایک اسٹیٹک لیز دیں (virsh net-edit default) تاکہ اس proxy_pass میں پتہ مستقل رہے۔

انتظامی انٹرفیسز کو انٹرنیٹ سے دور رکھیں: 5900 پر VNC اور 8006 پر Proxmox ویب UI کو لوپ بیک پر رکھنا چاہیے، جن تک SSH سرنگ (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) کے ذریعے یا VPS میں خود میزبانی کردہ WireGuard VPN کے پار رسائی حاصل کی جاتی ہے، جو پورے 192.168.122.0/24 گیسٹ ریجن کو ایک پرائیویٹ ہوپ کے فاصلے پر رکھتا ہے۔ فائر وال کو محدود رکھیں — sudo ufw allow 22,80,443/tcp، اور کچھ نہیں۔ اگر آپ کے ufw فعال کرنے کے فوراً بعد گیسٹس کی آؤٹ باؤنڈ کنیکٹیویٹی ختم ہو جاتی ہے، تو عام مجرم /etc/default/ufw میں DEFAULT_FORWARD_POLICY="DROP" ہے — اسے ACCEPT پر سیٹ کریں اور ufw کو دوبارہ لوڈ کریں۔

VPS پر Proxmox

Proxmox VE 9 اندر سے Debian 13 ہے، اس لیے یہ ایک Debian VPS پر pve-no-subscription ریپوزیٹری اور proxmox-ve پیکیج شامل کر کے انسٹال ہو جاتا ہے۔ ریپوزیٹری اور keyring کی لائنیں Proxmox کی اپنی موجودہ دستاویزات سے لیں۔ کسی پرانے بلاگ پوسٹ سے کاپی کردہ URL انسٹالیشن کو ناکام بنا دیتا ہے۔

پیکیجز مشکل حصہ نہیں ہیں۔ Proxmox vmbr0 کو ایک فزیکل NIC سے برج کرنے کی توقع کرتا ہے، جس کا سامنا اوپر بیان کردہ MAC فلٹرنگ کے مسئلے سے ہوتا ہے۔ VPS پر کام کرنے والا ڈھانچہ ایک NAT شدہ یا روٹڈ vmbr0 ہے جس سے کوئی فزیکل پورٹ منسلک نہیں ہے، گیسٹس پرائیویٹ رینج پر ہوتے ہیں، اور کسی بھی پبلک سروس کے لیے ہوسٹ پر DNAT قواعد یا ریورس پراکسی موجود ہوتی ہے۔ جہاں پبلک سروسز VMs کی بجائے کنٹینرز ہوں، وہاں ایک Docker Compose فائل سے متعدد ایپس کے سامنے Traefik اسی روٹنگ کا کام آٹومیٹک سرٹیفکیٹس کے ساتھ مکمل کرتا ہے۔ سب سے پہلے /etc/network/interfaces اسنیپ شاٹ لیں: غلط برج وضاحت آپ کو ایسی مشین سے لاک آؤٹ کر دیتی ہے جس کا کنسول آپ کے پاس نہیں ہو سکتا۔

کارکردگی، صاف الفاظ میں

نیسٹڈ ورچوئلائزیشن سنگل لیول سے سست ہے، اور اس کا طریقہ مخصوص ہے، بکھرا ہوا نہیں: لاگت میموری تک رسائی پر نہیں آتی، بلکہ ایگزٹس پر آتی ہے۔ EPT/NPT موجود ہونے پر، L0 برائے L2 شیڈو پیج ٹیبلز برقرار رکھتا ہے اور عام میموری ریڈز ہارڈویئر کی رفتار سے چلتی ہیں۔ جو مہنگا پڑتا ہے وہ وہ ہر عمل ہے جو گیسٹ موڈ سے باہر نکلتا ہے — I/O، ٹائمر انٹرپٹس، MMIO، انٹر پروسیسر انٹرپٹس — کیونکہ ایک L2 ایگزٹ L0 کے ذریعے ہینڈل کیا جاتا ہے اور L1 کے ذریعے واپس بھیجا جا سکتا ہے۔ RAM میں پہلے سے موجود ڈیٹا پر CPU-bound کام تقریباً native لگتا ہے؛ جو کچھ بھی syscalls، پیکیٹس اور ڈسک I/O پر مبنی ہو وہ تمام تہوں کا احساس دلاتا ہے۔

لہٰذا: ہر جگہ virtio آلات استعمال کریں۔ اور آپ کی qcow2 فائل اس ڈسک پر موجود ہے جسے فراہم کنندہ پہلے ہی ورچوئلائز کر چکا ہے — دو thin-provisioning تہیں اسٹیک ہوئی ہیں، جہاں گیسٹ ڈسک پر cache=none اس بات کو روکتا ہے کہ ایک ہی بلاکس ایک وقت میں دو پیج کیشز میں موجود ہوں۔ یہاں کوئی بنچ مارک اعداد نہیں ہیں: اپنی انسٹانس پر اپنا ورک لوڈ خود ناپیں۔

ناکامی کی صورتیں، اور آپ کو نظر آنے والے اسٹرنگز

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used از طرف kvm-ok۔ یا تو ماڈیول لوڈ نہیں ہوا، یا فلیگ ظاہر نہیں ہو رہا۔ پہلے /proc/cpuinfo چیک کریں۔

kvm: disabled by bios میں dmesg۔ بری میٹل پر، فرم ویئر میں VT-x/SVM ٹوگل کو آن کریں۔ VPS کے اندر اس کا مطلب ہے کہ L0 آپ کو ایکسٹینشنز فراہم نہیں کر رہا، اور گیسٹ میں آپ جو بھی ٹائپ کریں گے اس سے کوئی تبدیلی نہیں آئے گی۔

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported۔ آپ کرنل جو CPU دیکھتا ہے اس میں vmx نہیں ہے — یہ بھی ایک L0 فیصلہ ہے۔

Could not access KVM kernel module: Permission denied۔ یہ اجازت کا مسئلہ ہے، ہارڈ ویئر کا نہیں۔ ls -l /dev/kvm میں گروپ kvm، موڈ 660 نظر آنا چاہیے؛ خود کو اس گروپ میں شامل کریں اور ایک نئی لاگن شیل شروع کریں، کیونکہ گروپ رکنیت پہلے سے چل رہے سیشن پر لاگو نہیں ہوتی۔

kvm: Device or resource busy جب QEMU شروع ہوتا ہے۔ ایک اور ہائپروائزر ماڈیول CPU پر قابض ہے: lsmod چلائیں، vboxdrv یا VMware ماڈیولز کو kvm_intel کے ساتھ تلاش کریں، اور جسے نہیں چاہیے اسے ان لوڈ کر دیں۔

/var/run/libvirt/libvirt-sock: No such file or directory از طرف virsh۔ ڈیمن ڈاؤن ہے: sudo systemctl enable --now libvirtd۔

Proxmox: KVM virtualisation configured, but not available. ایک گیسٹ نے اس ہوسٹ پر KVM ایکسلریشن کا ٹک لگایا ہے جو اسے فراہم نہیں کر سکتا۔ نسٹنگ ٹھیک کریں، یا ٹک ہٹا کر ایمولیشن قبول کریں۔

اینڈرائیڈ ایمولیٹر: x86_64 emulation currently requires hardware acceleration! /dev/kvm دوبارہ — عام طور پر یہ گروپ والی صورت ہے۔

کوئی ایرر نہیں، اور سب کچھ انتہائی سست ہے۔ بغیر ایکسلریٹر فلیگ کے QEMU TCG پر واپس چلا جاتا ہے، جو اس کا سافٹ ویئر ایمولیٹر ہے۔ یہ درست ہے اور سست ہے — سیکنڈ میں ناپا جانے والا بوٹ منٹس میں ناپا جانے لگتا ہے۔ -accel kvm کو واضح طور پر پاس کریں، تاکہ QEMU خاموشی سے ایمولیٹ کرنے کے بجائے ایرر کے ساتھ رک جائے۔

ایک گیسٹ رن کے دوران غائب ہو جاتا ہے۔ Out of memory: Killed process ... qemu-system-x86_64 کے لیے dmesg میں دیکھیں۔ ایک L2 گیسٹ L1 پر ایک پروسیس ہے، اور OOM کلر اسے کسی اور پروسیس کی طرح Treat کرتا ہے۔ L2 کی RAM L1 کی مقررہ الاٹمنٹ سے نکلتی ہے — ہوسٹ سے کوئی قرض نہیں لیا جاتا۔

اسے چلانا: بیک اپس، اپ گریڈز، حدود

بیک اپس۔ چلتی ہوئی گیسٹ کی qcow2 کاپی کرنے سے خراب امیج ملتی ہے۔ یا تو virsh shutdown guest1 کریں اور کاپی کریں، یا بیرونی اسنیپ شاٹ لیں (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) تاکہ کاپی کے دوران لکھائیاں اوورلے کی طرف بہہ جائیں جبکہ اب جامد بیس کاپی ہو، پھر اسے virsh blockcommit سے واپس ملا دیں۔ کاپیاں VPS سے باہر بھیج دیں — اسی ڈسک پر اسنیپ شاٹ کچھ کی حفاظت نہیں کرتا۔

اپ گریڈز۔ apt full-upgrade نئے kvm_intel/kvm_amd ماڈیولز انسٹال کرتا ہے، مگر چلتا ہوا کرنل پرانے ماڈیولز ہی رکھتا ہے یہاں تک کہ آپ ری بوت کریں۔ پچھلا کرنل انسٹال رکھیں اور ہر کرنل تبدیلی کے بعد kvm-ok دوبارہ چلائیں: ایک میزبان جو vmx کے بغیر واپس آتا ہے وہ پھر کام کرنے سے صرف ایک بوٹ انٹری دور ہوتا ہے۔

یہ کہاں اسکیل کرنا بند کرتا ہے۔ ایک پبلک IP کا مطلب ہے کہ ہر L2 سروس دنیا تک L1 پر پراکسی یا DNAT رول کے ذریعے پہنچتی ہے۔ لائیو مائیگریشن دستیاب نہیں ہے۔ CPU کے تنازعے کے تحت نسٹڈ ایگزٹ پاتھ سب سے پہلے متاثر ہوتا ہے۔ اور ایک ہائپروائزر جس میں کئی گیسٹس ہوں وہ ایسی مشین ہے جس کا RAM آگے ہی خرچ کر چکے ہیں — نسٹڈ VMs مقرر الاٹمنٹ سے باہر نکل کر اوورکومٹ نہیں کر سکتے۔ جب کوئی لیب اس سے بڑھ جاتا ہے، تو جواب ایک اونچا نسٹڈ اسٹیک نہیں ہے؛ بلکہ ایک مخصوص باکس ہے جہاں آپ L0 ہیں اور یہ سب کچھ لاگو نہیں ہوتا۔

FAQ

کیا VPS پر Docker چلانے کے لیے مجھے nested virtualization کی ضرورت ہے؟

نہیں۔ Containers آپ کے VPS kernel کو شیئر کرتے ہیں اور کبھی /dev/kvm کو نہیں کھولتے۔ اس لیے ایک عام instance جس میں vmx یا svm flag نہیں ہے، وہ Docker اور Docker Compose باآسانی چلاتا ہے۔ Nesting صرف اس وقت اہم ہوتا ہے جب آپ کو دوسرا kernel درکار ہو: ایک Proxmox lab، ایک Windows guest، Firecracker microVMs، ایک Android emulator، یا CI runners جو VM images کو boot کرتے ہیں۔

میں کیسے چیک کروں کہ میرا VPS nested virtualization کی معاونت کرتا ہے یا نہیں؟

grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u چلائیں، پھر cpu-checker پیکیج سے kvm-ok چلائیں۔ ایک قابل استعمال instance vmx (Intel) یا svm (AMD) پرنٹ کرتا ہے، kvm-ok رپورٹ کرتا ہے KVM acceleration can be used، اور /dev/kvm موجود ہوتا ہے جس میں group kvm اور mode 660 ہے۔ اس سوال کے لیے /sys/module/kvm_intel/parameters/nested کو نظر انداز کریں — وہ فائل آپ کے اپنے KVM module کی وضاحت کرتی ہے، نہ کہ provider کے hypervisor نے آپ کو جو کچھ فراہم کیا تھا۔

زیادہ تر VPS providers nested virtualization کو کیوں disable کرتے ہیں؟

vmx کو ظاہر کرنے کا مطلب ہے guest کو ایک ایسا CPU model دینا جس میں وہ flag موجود ہو، اور ایک ایسا guest جو ان CPU features پر انحصار کرتا ہے اسے live-migrate نہیں کیا جا سکتا اس مشین پر جس کے CPU میں یہ features نہیں ہیں — ایک provider جو گاہکوں کو منتقل کر کے nodes خالی کرتا ہے، وہ یہ سہولت کھو دیتا ہے۔ Nested VMX/SVM code paths کی CVE کی تاریخ بھی طویل رہی ہے۔ کچھ hosts اب بھی درخواست پر فی VM اسے enable کرتے ہیں، اور دیگر nesting کو ایک پلان فیچر کے طور پر دستاویز کرتے ہیں۔

میرے nested VM میں public bridge پر کوئی network نہیں ہے۔ کیا مسئلہ ہے؟

Provider کا switch ان frames کو drop کر دیتا ہے جو کسی ایسے MAC address سے آتی ہیں جو اس نے کبھی آپ کو لیز نہیں کیا۔ اس لیے ایک L2 guest جسے public bridge پر bridge کیا گیا ہے، ARP بھیجتا ہے اور جواب میں کچھ نہیں پاتا۔ br0 کو ڈیبگ کرنا چھوڑیں — libvirt کا NAT default network استعمال کریں (virbr0، 192.168.122.0/24)، guest کو ایک static lease دیں، اور VPS خود پر کسی reverse proxy یا DNAT rule کے ذریعے کوئی بھی public چیز شائع کریں۔

ایک nested VM کتنا سست ہوتا ہے؟

اس کا نقصان VM exits پر پڑتا ہے، memory access پر نہیں۔ EPT/NPT فعال ہونے کے ساتھ، L2 کے اندر عام reads اور writes hardware کی رفتار سے چلتے ہیں، جبکہ I/O، timer interrupts، MMIO اور IPIs کا انتظام L0 کرتا ہے اور انہیں L1 کے ذریعے واپس بھیجا جا سکتا ہے۔ RAM میں پہلے سے موجود data پر CPU-bound کام native کے قریب لگتا ہے؛ syscall، packet اور disk-heavy workloads ہر layer کا احساس کرتے ہیں۔ ہر جگہ virtio devices استعمال کریں اور guest disks پر cache=none، پھر اپنے workload کی پیمائش کریں۔