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

مختصر جواب

Nested virtualization سے مراد ایسا hypervisor ہے جو virtual machine کے اندر چل رہا ہو۔ آپ کا VPS پہلے ہی ایک guest ہے، اور آپ چاہتے ہیں کہ وہ اپنے guest systems بھی چلائے۔ یہ صرف اسی وقت کام کرتا ہے جب آپ کا provider اپنے hypervisor میں CPU کی virtualization extensions آپ کے instance کے لیے جان بوجھ کر expose کرے۔ /proc/cpuinfo میں vmx flag (Intel) یا svm (AMD) دیکھیں۔ اگر دونوں میں سے کوئی بھی موجود نہ ہو تو VPS کے اندر کوئی configuration اسے درست نہیں کر سکتی۔

پہلے ایک اہم وضاحت: Docker کو اس میں سے کسی چیز کی ضرورت نہیں۔ Containers آپ کے VPS کے kernel کو share کرتے ہیں اور کبھی /dev/kvm تک رسائی نہیں کرتے۔ اگر اصل مقصد "اپنے server پر containers میں کئی services چلانا" ہے تو آپ کے پاس پہلے ہی مطلوبہ سہولت موجود ہے۔ Nested virtualization اس وقت اہم ہوتی ہے جب آپ دوسرا kernel، Proxmox lab، Windows guest، Firecracker microVMs، Android emulator، حقیقی VMs پر مشتمل Kubernetes testbed، یا ایسے CI runners چلانا چاہتے ہوں جو VM images boot کرتے ہیں۔

اصل میں nested کیا جا رہا ہے

تین layers ہیں:

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

Hardware virtualization میں Intel پر VT-x، یعنی vmx flag، اور EPT شامل ہیں۔ AMD پر AMD-V / SVM، یعنی svm، اور RVI/NPT شامل ہیں۔ hypervisor ان instructions کے ذریعے guest mode میں داخل ہوتا ہے اور CPU کو بیک وقت دو page tables traverse کرنے دیتا ہے۔

ان دونوں کو re-entrant استعمال کے لیے ڈیزائن نہیں کیا گیا تھا، اس لیے nesting کو emulate کیا جاتا ہے۔ جب L1 کوئی VMX instruction execute کرتا ہے تو وہ L0 کو trap کرتی ہے۔ پھر L0، L1 کی طرف سے L2 کے لیے shadow structures برقرار رکھتا ہے۔ KVM یہ کام مؤثر طریقے سے کرتا ہے، لیکن ہر exit پر اضافی کام L0 ہی کرتا ہے۔ اسی لیے provider کو nesting کی اجازت دینی پڑتی ہے۔

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، nesting عالمی سطح پر enabled ہونے کے باوجود vmx کو hide کر دیتا ہے۔

ایک منٹ میں اپنے 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 mode 660 کے طور پر موجود ہوتا ہے۔ اگر flag موجود ہو لیکن device node نہ ہو تو module کو دستی طور پر load کریں اور kernel log پڑھیں:

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

ایک file کو مسلسل quote کیا جاتا ہے اور اسے بڑے پیمانے پر غلط سمجھا جاتا ہے:

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

آپ کے VPS کے اندر یہ آپ کے KVM module کی setting ہے، اور یہ طے کرتی ہے کہ آیا L2 guest تیسری سطح کو nest کر سکتا ہے۔ اس سے یہ معلوم نہیں ہوتا کہ L0 نے آپ کے لیے nesting فعال کی ہے یا نہیں؛ /proc/cpuinfo اور kvm-ok اس کا جواب دیتے ہیں۔ nested parameter وہ knob ہے جسے آپ اپنی مکمل ملکیت والی machine پر set کرتے ہیں:

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 removal مسترد کر دیا جاتا ہے، اس لیے پہلے guests کو بند کریں۔

زیادہ تر VPS میزبان اسے بند کیوں رکھتے ہیں

• Live migration۔ آپ کو vmx فراہم کرنے کا مطلب ایسا CPU model ظاہر کرنا ہے جس میں یہ flag موجود ہو۔ جن guest systems کو ان CPU features پر انحصار ہو، انہیں ایسے machine پر محفوظ طریقے سے migrate نہیں کیا جا سکتا جس کے CPU میں یہ features موجود نہ ہوں۔ جو host صارفین کے workloads کو migrate کر کے nodes خالی کرتا ہے، nesting فعال کرتے ہی یہ سہولت کھو دیتا ہے۔
• Attack surface۔ Nested VMX/SVM paths kernel کی virtualization layer میں موجود پیچیدہ ترین code میں شامل ہیں، اور ان کی CVE history بھی خاصی طویل ہے۔
• L0 ممکن ہے KVM نہ ہو۔ اگر systemd-detect-virt کا output vmware، xen یا microsoft ہو، تو nesting rules KVM کے نہیں بلکہ اسی stack کے ہوں گے۔

آپ کے instance میں flag موجود نہیں؟ Support سے پوچھیں، کیونکہ کچھ providers اسے فی-VM فعال کرتے ہیں؛ ایسا plan منتخب کریں جس میں nesting کی دستاویزی حمایت موجود ہو؛ یا dedicated box پر منتقل ہو جائیں۔ باقی تمام ہدایات اس مفروضے پر مبنی ہیں کہ machine پر root access ہے اور اس میں یہ flag ظاہر ہو رہا ہے۔

libvirt کے ساتھ L2 guest چلانا

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 کی ضرورت نہیں ہے۔ Serial installation کچھ وقت لیتی ہے، اس لیے اسے persistent shell کے اندر شروع کریں: وہی tmux workflow جو VPS پر Claude Code sessions کو فعال رکھتا ہے، SSH connection منقطع ہونے کے بعد بھی virt-install console کو منسلک رکھتا ہے۔ اگر --os-variant debian13 مسترد ہو تو آپ کا osinfo-db release سے پرانا ہے۔ osinfo-query os چلائیں اور ایسا نام منتخب کریں جو موجود ہو۔ --cpu host-passthrough، vmx کو L2 تک forward کرتا ہے۔ یہ صرف اس وقت ضروری ہے جب L2 کو خود مزید virtualization چلانی ہو۔ virsh autostart guest1 کے ذریعے guest کو boot کے لیے محفوظ بنائیں۔

Disk اور NIC پر virtio bus محض ظاہری چیز نہیں ہے: emulated IDE اور e1000 devices، virtio queues کے مقابلے میں hypervisor میں کہیں زیادہ مرتبہ trap کرتے ہیں، اور nesting کے دوران ہر trap کی لاگت دو مرتبہ ادا ہوتی ہے۔

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

آپ کے VPS کے پاس ایک public IP ہے اور یہ ایسے network fabric کے پیچھے ہے جو نامعلوم MAC addresses کو filter کرتا ہے۔ اس کے دو نتائج نکلتے ہیں۔

L2 guests کو public network پر bridge کرنا عموماً کام نہیں کرے گا۔ br0 کو public NIC پر رکھیں، guest کو اپنا MAC دیں، تو آپ دیکھیں گے کہ ARP requests باہر جاتی ہیں لیکن کوئی جواب واپس نہیں آتا۔ provider کا switch ایسے MAC سے آنے والے frames خارج کر دیتا ہے جسے اس نے آپ کو lease نہیں کیا۔ اگر آپ کی علامت یہی ہے تو bridge کی debugging روک دیں؛ مسئلہ یہی mechanism ہے۔

اس کے بجائے NAT network استعمال کریں۔ libvirt کے ساتھ default موجود آتا ہے: virbr0، 192.168.122.0/24، dnsmasq leases، اور outbound connectivity فوراً کام کرتی ہے۔ Inbound traffic کے لیے TLS کو L1 پر terminate کریں اور اسے proxy کے ذریعے اندر بھیجیں۔ ذیل میں certificate paths Nginx پر Certbot کے ساتھ Let's Encrypt certificate جاری کرنا سے لیے گئے ہیں:

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

پہلے guest کے لیے static lease مقرر کریں (virsh net-edit default) تاکہ proxy_pass میں موجود address تبدیل نہ ہو۔

Management interfaces کو internet سے دور رکھیں: 5900 پر VNC اور 8006 پر Proxmox web UI کو loopback پر رکھیں۔ ان تک SSH tunnel (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) کے ذریعے یا VPS میں self-hosted WireGuard VPN کے ذریعے رسائی حاصل کریں۔ اس سے پورا 192.168.122.0/24 guest range ایک private hop کے فاصلے پر آ جاتا ہے۔ Firewall کو محدود رکھیں: sudo ufw allow 22,80,443/tcp، اور کچھ نہیں۔ اگر ufw فعال کرنے کے فوراً بعد guests کی outbound connectivity ختم ہو جائے تو عام وجہ DEFAULT_FORWARD_POLICY="DROP" میں /etc/default/ufw ہوتی ہے۔ اسے ACCEPT پر مقرر کریں اور ufw reload کریں۔

VPS پر Proxmox

Proxmox VE 9 کے بنیادی نظام کے طور پر Debian 13 استعمال کرتا ہے، اس لیے اسے Debian VPS پر انسٹال کرنے کے لیے pve-no-subscription repository اور proxmox-ve package شامل کریں۔ Repository اور keyring کی سطور Proxmox کی موجودہ official documentation سے لیں۔ کسی پرانی blog post سے کاپی کیا گیا URL انسٹالیشن ناکام کر سکتا ہے۔ VPS کرائے پر لینے سے پہلے یہ طے کرنا مفید ہے کہ rented hardware پر Proxmox استعمال کرنا مناسب بھی ہے یا نہیں۔ ورنہ نیٹ ورکنگ کی ذیل کی configuration پر پوری شام صرف ہو سکتی ہے۔ گھر میں Proxmox box اور کرائے کے VPS کے درمیان لاگت اور صلاحیت کا موازنہ اسی سوال کا ایسا جائزہ ہے جس میں بجلی اور hardware کا حساب پہلے ہی شامل ہے۔

Packages اصل مشکل نہیں ہیں۔ Proxmox کو توقع ہوتی ہے کہ vmbr0 ایک physical NIC سے bridged ہو۔ یہ صورت اوپر بیان کیے گئے MAC-filtering کے dead end تک براہ راست پہنچتی ہے۔ VPS پر قابلِ عمل ترتیب یہ ہے کہ physical port سے منسلک کیے بغیر NAT'd یا routed vmbr0 استعمال کیا جائے، guests کو private range میں رکھا جائے، اور public services کے لیے host پر DNAT rules یا reverse proxy استعمال کیا جائے۔ جہاں public-facing services VMs کے بجائے containers ہوں، وہاں ایک Docker Compose file سے متعدد apps کے سامنے Traefik چلانا automatic certificates کے ساتھ یہی routing کام انجام دیتا ہے۔ پہلے snapshot /etc/network/interfaces لیں۔ bridge کی غلط definition ایسی machine سے آپ کا access ختم کر سکتی ہے جس کا console شاید آپ کے پاس نہ ہو۔

کارکرد، دیانت داری کے ساتھ

Nested کارکردگی میں single-level سے سست ہے، اور اس کی وجہ عمومی نہیں بلکہ مخصوص ہے: لاگت memory access پر نہیں، بلکہ exits پر آتی ہے۔ EPT/NPT موجود ہوں تو L0، L2 کے لیے shadow page tables برقرار رکھتا ہے اور عام memory reads hardware speed پر چلتی ہیں۔ مہنگا ہر وہ operation ہوتا ہے جو guest mode سے باہر نکلتا ہے، مثلاً I/O، timer interrupts، MMIO اور inter-processor interrupts۔ L2 exit کو L0 handle کرتا ہے اور ممکن ہے کہ اسے L1 کے ذریعے واپس reflect کیا جائے۔ RAM میں پہلے سے موجود data پر CPU-bound کام native کارکردگی کے قریب رہتا ہے؛ لیکن syscalls، packets اور disk I/O پر منحصر کام میں یہ layers نمایاں محسوس ہوتی ہیں۔

اس لیے ہر جگہ virtio devices استعمال کریں۔ آپ کی qcow2 file ایسی disk پر موجود ہوتی ہے جسے provider پہلے ہی virtualize کر چکا ہے۔ یوں thin-provisioning کی دو layers ایک دوسرے پر قائم ہوتی ہیں، اور guest disk پر cache=none کے باعث وہی blocks بیک وقت دو page caches میں موجود رہ سکتے ہیں۔ یہاں benchmark کے اعداد و شمار نہیں دیے گئے: اپنی instance پر اپنے workload کی پیمائش کریں۔

خرابی کی صورتیں اور ظاہر ہونے والے پیغامات

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used، kvm-ok کی جانب سے۔ یا تو module load نہیں ہوا، یا flag دستیاب نہیں کیا گیا۔ پہلے /proc/cpuinfo چیک کریں۔

kvm: disabled by bios، dmesg میں۔ bare metal پر firmware میں VT-x/SVM toggle فعال کریں۔ VPS کے اندر اس کا مطلب ہے کہ L0 آپ کو extensions فراہم نہیں کر رہا؛ guest میں آپ جو بھی درج کریں، اس سے یہ مسئلہ حل نہیں ہوگا۔

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

Could not access KVM kernel module: Permission denied۔ مسئلہ hardware کا نہیں، permissions کا ہے۔ ls -l /dev/kvm میں group kvm اور mode 660 دکھائی دینے چاہییں؛ خود کو اس group میں شامل کریں اور نیا login shell شروع کریں، کیونکہ group membership پہلے سے چلنے والے session پر لاگو نہیں ہوتی۔

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

virsh کی جانب سے /var/run/libvirt/libvirt-sock: No such file or directory۔ daemon بند ہے: sudo systemctl enable --now libvirtd۔

Proxmox: KVM virtualisation configured, but not available. کسی ایسے host پر guest کے لیے KVM acceleration فعال ہے جو اسے فراہم نہیں کر سکتا۔ nesting درست کریں، یا اسے غیر فعال کر کے emulation قبول کریں۔

Android emulator: x86_64 emulation currently requires hardware acceleration! دوبارہ /dev/kvm؛ عموماً مسئلہ group کا ہوتا ہے۔

کوئی error نہیں، لیکن سب کچھ انتہائی سست ہے۔ accelerator flag کے بغیر QEMU، TCG یعنی اپنے software emulator پر واپس چلا جاتا ہے۔ یہ درست طریقے سے کام کرتا ہے، لیکن سست ہے؛ جو boot چند seconds میں مکمل ہوتا ہے، اسے minutes لگ سکتے ہیں۔ -accel kvm واضح طور پر دیں، تاکہ QEMU خاموشی سے emulation کرنے کے بجائے error کے ساتھ رک جائے۔

Guest دورانِ اجرا غائب ہو جاتا ہے۔ dmesg میں Out of memory: Killed process ... qemu-system-x86_64 تلاش کریں۔ L2 guest، L1 پر ایک process ہوتا ہے، اور OOM killer اسے کسی بھی دوسرے process کی طرح سمجھتا ہے۔ L2 کی RAM، L1 کی مقررہ allocation میں سے آتی ہے؛ host سے اضافی RAM ادھار نہیں لی جاتی۔

اسے چلانا: backups، upgrades، limits

Backups۔ چلتے ہوئے guest کی qcow2 کاپی کرنے سے image خراب ہو جاتی ہے۔ یا تو virsh shutdown guest1 کریں اور پھر کاپی بنائیں، یا external snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) لیں تاکہ کاپی کے دوران writes ایک overlay میں منتقل ہو جائیں اور اس وقت static base کی کاپی بن سکے؛ پھر اسے virsh blockcommit کے ذریعے واپس شامل کریں۔ کاپیاں VPS سے باہر منتقل کریں؛ اسی disk پر موجود snapshot کسی failure سے تحفظ نہیں دیتا۔

Upgrades۔ apt full-upgrade نئے kvm_intel/kvm_amd modules install کرتا ہے، لیکن running kernel reboot ہونے تک پرانے modules استعمال کرتا رہتا ہے۔ پچھلا kernel installed رکھیں اور ہر kernel change کے بعد kvm-ok دوبارہ چلائیں: اگر host vmx کے بغیر واپس آتا ہے تو اسے دوبارہ چلانے کے لیے صرف ایک boot entry درکار ہوگی۔

Where this stops scaling۔ ایک public IP کا مطلب ہے کہ ہر L2 service proxy یا L1 پر DNAT rule کے ذریعے دنیا تک پہنچتی ہے۔ Live migration دستیاب نہیں ہے۔ CPU contention کے دوران nested exit path سب سے پہلے متاثر ہوتا ہے۔ مزید یہ کہ کئی guests والا hypervisor ایسی machine ہے جس کی RAM آپ پہلے ہی مختص کر چکے ہیں؛ nested VMs ایک fixed allocation سے نکلنے کے لیے overcommit نہیں کر سکتیں۔ جب lab اس حد سے آگے بڑھ جائے تو حل زیادہ بلند nested stack نہیں ہے؛ حل ایک dedicated box ہے جہاں آپ L0 ہوں، اور ان میں سے کوئی پابندی لاگو نہ ہو۔

FAQ

کیا Docker کو VPS پر چلانے کے لیے 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 کو support کرتا ہے؟

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

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

vmx expose کرنے کا مطلب guest کو ایسا CPU model دینا ہے جس میں یہ flag موجود ہو۔ ایسی CPU features پر منحصر guest کو ایسے machine پر live-migrate نہیں کیا جا سکتا جس کے CPU میں یہ features موجود نہ ہوں۔ جو provider customers کو nodes کے درمیان منتقل کر کے nodes کو drain کرتا ہے، وہ یہ سہولت ختم کر دیتا ہے۔ Nested VMX/SVM code paths میں CVEs کی طویل history بھی موجود ہے۔ کچھ hosts اب بھی request پر ہر VM کے لیے اسے enable کرتے ہیں، جبکہ دیگر nesting کو plan feature کے طور پر document کرتے ہیں۔

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

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

Nested VM کتنی سست ہوتی ہے؟

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