VPS में Proxmox चलाना: क्या यह संभव है?

संक्षिप्त उत्तर

Nested virtualization का अर्थ है एक virtual machine के अंदर hypervisor चलाना: आपका VPS पहले से ही एक guest है, और आप चाहते हैं कि वह अपने स्वयं के guests को host करे। यह केवल तभी काम करता है जब आपके provider का hypervisor जानबूझकर आपके instance के लिए CPU के virtualization extensions को expose करता है — vmx flag (Intel) या svm (AMD) के लिए /proc/cpuinfo की जाँच करें। यदि इनमें से कोई भी दिखाई नहीं देता है, तो VPS के अंदर की कोई भी configuration इसे ठीक नहीं कर पाएगी।

एक महत्वपूर्ण बात: Docker को इनमें से किसी की आवश्यकता नहीं है। Containers आपके VPS kernel को share करते हैं और कभी भी /dev/kvm का उपयोग नहीं करते हैं। यदि आपका वास्तविक लक्ष्य "मेरे server पर containers में कई services चलाना" है, तो आपके पास पहले से ही आवश्यक चीजें मौजूद हैं। Nesting की आवश्यकता तब होती है जब आप एक second kernel चाहते हों — जैसे Proxmox lab, Windows guest, Firecracker microVMs, Android emulator, real VMs का Kubernetes testbed, या VM images को boot करने वाले CI runners।

वास्तव में क्या नेस्ट (nest) हो रहा है

तीन लेयर्स:

• L0 — मेटल पर प्रोवाइडर का hypervisor. आपके पास इसका एक्सेस नहीं है.
• L1 — आपका VPS. L0 के लिए यह केवल एक guest है.
• L2 — वह VM जिसे आप अपने VPS के अंदर चलाना चाहते हैं.

Hardware virtualization Intel पर VT-x (vmx flag) और EPT है, और AMD पर AMD-V / SVM (svm) और RVI/NPT है. एक hypervisor guest mode में जाने और CPU को एक साथ दो page tables पर चलने देने के लिए इन instructions का उपयोग करता है.

इनमें से कोई भी re-entrant होने के लिए डिज़ाइन नहीं किया गया है, इसलिए nesting को emulate किया जाता है: जब L1 कोई VMX instruction निष्पादित करता है, तो वह L0 पर trap करता है, जो L1 की ओर से L2 के लिए shadow structures बनाए रखता है. KVM इसे अच्छी तरह से करता है, लेकिन हर exit पर L0 को अतिरिक्त काम करना पड़ता है — यही कारण है कि प्रोवाइडर को इसे opt in करना पड़ता है.

Accelerated L2 के लिए दोनों शर्तें पूरी होनी चाहिए:

1. L0 का KVM module nested=1 के साथ loaded है.
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 globally चालू हो.

एक मिनट में अपने 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 का बार-बार उल्लेख किया जाता है और उसे अक्सर गलत समझा जाता है:

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

आपके VPS के अंदर यह आपके KVM module की setting है, और यह नियंत्रित करता है कि क्या एक L2 guest तीसरे level को nest कर सकता है। यह इस बारे में कुछ नहीं बताता कि क्या L0 ने आपके लिए nesting enable की है — /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 को shut down करें।

अधिकांश VPS होस्ट इसे बंद क्यों रखते हैं

• Live migration. vmx प्रदान करने का अर्थ है एक ऐसे CPU मॉडल को उजागर करना जिसमें यह flag मौजूद है। यदि कोई guest OS उन CPU features पर निर्भर है, तो उसे ऐसे machine पर सुरक्षित रूप से migrate नहीं किया जा सकता जिसमें वे features न हों। जो host customers को migrate करके nodes खाली करते हैं, वे nesting enable करते ही यह सुविधा खो देते हैं।
• Attack surface. Nested VMX/SVM paths kernel के virtualization layer के सबसे जटिल code में से एक हैं, जिनमें कई CVEs दर्ज हैं।
• L0 may not be KVM. यदि systemd-detect-virt vmware, xen या microsoft प्रिंट करता है, तो nesting rules उस stack के हैं, KVM के नहीं।

यदि आपके instance पर flag नहीं है, तो support से पूछें (कुछ providers इसे per-VM enable करते हैं), ऐसा plan चुनें जो nesting को document करता हो, या 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'

किसी graphical session की आवश्यकता नहीं है। Serial install कुछ समय तक चलता है, इसलिए इसे एक persistent shell के अंदर शुरू करें: वही tmux workflow जो VPS पर Claude Code sessions को जीवित रखता है एक virt-install console को SSH connection टूटने पर भी जोड़े रखता है। यदि --os-variant debian13 को reject कर दिया जाता है, तो आपका osinfo-db release से पुराना है — osinfo-query os चलाएं और एक ऐसा नाम चुनें जो मौजूद हो। --cpu host-passthrough vmx को L2 में forward करता है, इसकी आवश्यकता केवल तभी होती है जब L2 को स्वयं virtualize करना हो। virsh autostart guest1 के साथ guest को boot-safe बनाएं।

Disk और NIC पर virtio bus केवल दिखावे के लिए नहीं है: emulated IDE और e1000 devices, virtio queues की तुलना में hypervisor में कहीं अधिक बार trap करते हैं, और nesting के दौरान हर trap की कीमत दोगुनी चुकानी पड़ती है।

Networking: वह हिस्सा जिसे tutorials छोड़ देते हैं

आपके VPS में एक public IP होता है जो एक ऐसे fabric के पीछे होता है जो unknown MAC addresses को filter करता है। इसके दो परिणाम होते हैं।

L2 guests को public network पर bridge करना आमतौर पर काम नहीं करेगा। यदि आप public NIC पर br0 रखते हैं और guest को उसका अपना MAC देते हैं, तो ARP request बाहर जाएगी लेकिन कोई response नहीं आएगा — provider का switch उन frames को drop कर देता है जो उस MAC से आते हैं जिसे उसने आपको lease नहीं किया है। यदि आपको यह समस्या आ रही है, तो bridge को debug करना बंद करें; यह इस system का तरीका है।

इसके बजाय NAT network का उपयोग करें। libvirt में default शामिल है: virbr0, 192.168.122.0/24, और dnsmasq leases, जिससे outbound connectivity तुरंत काम करने लगती है। Inbound traffic के लिए, L1 पर TLS terminate करें और फिर proxy करें — नीचे दिए गए certificate paths issuing a Let's Encrypt certificate with Certbot on 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;
    }
}

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) के माध्यम से या self-hosted WireGuard VPN into the VPS के माध्यम से एक्सेस किया जा सकता है, जो पूरे 192.168.122.0/24 guest range को एक private hop की दूरी पर रखता है। Firewall को सीमित रखें — sudo ufw allow 22,80,443/tcp, इसके अलावा कुछ नहीं। यदि ufw enable करने के तुरंत बाद guests की outbound connectivity खत्म हो जाती है, तो इसका सामान्य कारण /etc/default/ufw में DEFAULT_FORWARD_POLICY="DROP" है — इसे ACCEPT पर set करें और ufw को reload करें।

VPS पर Proxmox

Proxmox VE 9 के अंदर Debian 13 होता है। इसे Debian VPS पर pve-no-subscription repository और proxmox-ve package जोड़कर install किया जा सकता है। Repository और keyring की lines Proxmox के official documentation से ही लें — किसी पुराने blog post से URL copy करने पर installation fail हो जाएगा।

Packages सबसे कठिन हिस्सा नहीं हैं। Proxmox को vmbr0 चाहिए जो physical NIC से bridged हो, लेकिन इससे ऊपर बताई गई MAC-filtering की समस्या आती है। VPS के लिए सही तरीका NAT'd या routed vmbr0 का उपयोग करना है जिसमें कोई physical port न हो। इसमें guests एक private range में होते हैं, और public services के लिए host पर DNAT rules या reverse proxy का उपयोग किया जाता है। यदि public-facing services VMs के बजाय containers हैं, तो एक Docker Compose file से multiple apps को manage करने वाला Traefik automatic certificates के साथ वही routing कार्य कर सकता है। सबसे पहले Snapshot /etc/network/interfaces लें: bridge की गलत definition आपको machine से बाहर कर सकती है, और आपके पास उसका console access भी नहीं होगा।

Performance का वास्तविक विवरण

Nested virtualization, single-level की तुलना में धीमा है। इसका कारण विशिष्ट है: लागत memory access के कारण नहीं, बल्कि exits के कारण आती है। EPT/NPT के उपयोग से, L0, L2 के लिए shadow page tables बनाए रखता है और सामान्य memory reads hardware की गति से चलते हैं। वास्तविक लागत तब आती है जब कोई operation guest mode को छोड़ता है — जैसे I/O, timer interrupts, MMIO, और inter-processor interrupts — क्योंकि L2 exit को L0 द्वारा handle किया जाता है और इसे L1 के माध्यम से वापस भेजा जा सकता है। यदि कार्य CPU-bound है और data पहले से RAM में है, तो performance 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 numbers नहीं दिए गए हैं: अपने स्वयं के instance पर अपने workload को मापें।

Failure modes, aur aapko dikhne wali strings

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used kvm-ok se. Ya toh module loaded nahi hai, ya flag exposed nahi hai. Pehle /proc/cpuinfo check karein.

dmesg mein kvm: disabled by bios. Bare metal par, firmware mein VT-x/SVM toggle ko on karein. VPS ke andar iska matlab hai ki L0 aapko extensions nahi de raha hai, aur guest mein aap jo bhi type karenge usse yeh badlega nahi.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. Aapka kernel jis CPU ko dekh raha hai usmein vmx nahi hai — yeh bhi ek L0 decision hai.

Could not access KVM kernel module: Permission denied. Yeh hardware nahi, permissions ki samasya hai. ls -l /dev/kvm mein group kvm aur mode 660 dikhna chahiye; khud ko us group mein add karein aur ek naya login shell start karein, kyunki group membership pehle se chal rahe session par apply nahi hoti.

QEMU start hote waqt kvm: Device or resource busy. Koi dusra hypervisor module CPU ko hold kar raha hai: lsmod chalayein, vboxdrv ya VMware modules ko kvm_intel ke saath check karein, aur jis module ki zaroorat nahi hai use unload kar dein.

virsh se /var/run/libvirt/libvirt-sock: No such file or directory. Daemon band hai: sudo systemctl enable --now libvirtd.

Proxmox: KVM virtualisation configured, but not available. Ek guest mein KVM acceleration tick hai, lekin host ise provide nahi kar sakta. Nesting fix karein, ya ise untick karke emulation ka upyog karein.

Android emulator: x86_64 emulation currently requires hardware acceleration! Phir se /dev/kvm — aam taur par group ki samasya.

Koi error nahi, aur sab kuch bahut slow hai. Bina accelerator flag ke QEMU, TCG (software emulator) ka upyog karta hai. Yeh sahi hai par bahut slow hai — seconds mein hone wala boot ab minutes mein hoga. -accel kvm ko explicitly pass karein, taaki QEMU chupchap emulate karne ke bajaye error ke saath ruk jaye.

Run ke beech mein guest gayab ho jata hai. dmesg mein Out of memory: Killed process ... qemu-system-x86_64 check karein. L2 guest, L1 par ek process hai, aur OOM killer ise kisi bhi dusre process ki tarah treat karta hai. L2 RAM, L1 ke fixed allocation se aati hai — host se koi udhaar nahi milta.

संचालन: backups, upgrades, limits

Backups. चलते हुए guest के qcow2 को कॉपी करने से image corrupt हो जाती है। या तो virsh shutdown guest1 का उपयोग करके copy करें, या external snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) लें ताकि copy करते समय writes एक overlay पर divert हो जाएं, फिर virsh blockcommit के साथ इसे वापस fold कर दें। Copies को VPS से बाहर भेजें — एक ही disk पर snapshot होने से कोई सुरक्षा नहीं मिलती।

Upgrades. apt full-upgrade नए kvm_intel/kvm_amd modules install करता है, लेकिन running kernel पुराने modules को तब तक रखता है जब तक आप reboot न कर लें। पिछले kernel को installed रखें और हर kernel change के बाद kvm-ok को फिर से चलाएं: यदि host vmx के बिना वापस आता है, तो इसे फिर से काम करने के लिए केवल एक boot entry की आवश्यकता होगी।

Scaling की सीमाएं। एक public IP का अर्थ है कि प्रत्येक L2 service, L1 पर एक proxy या DNAT rule के माध्यम से दुनिया से जुड़ती है। Live migration उपलब्ध नहीं है। CPU contention के दौरान, nested exit path पर सबसे पहले प्रभाव पड़ता है। और कई guests वाले hypervisor में RAM पहले ही खर्च हो चुकी होती है — nested VMs fixed allocation से अधिक overcommit नहीं कर सकते। जब lab का आकार बढ़ जाता है, तो समाधान एक और ऊँचा nested stack नहीं है; बल्कि एक dedicated box है जहाँ आप L0 हैं और इनमें से कोई भी नियम लागू नहीं होता।

FAQ

क्या VPS पर Docker चलाने के लिए मुझे nested virtualization की आवश्यकता है?

नहीं। Containers आपके VPS kernel को साझा करते हैं और कभी भी /dev/kvm नहीं खोलते हैं। इसलिए, बिना vmx या svm flag वाले plain instance पर 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 package से kvm-ok चलाएँ। एक usable instance vmx (Intel) या svm (AMD) प्रिंट करता है, kvm-ok, KVM acceleration can be used रिपोर्ट करता है, और /dev/kvm, group kvm और mode 660 के साथ मौजूद होता है। इस प्रश्न के लिए /sys/module/kvm_intel/parameters/nested को अनदेखा करें — वह file आपके स्वयं के KVM module का विवरण देती है, न कि उस hypervisor का जो provider ने आपको दिया है।

अधिकांश VPS providers nested virtualization को disable क्यों करते हैं?

vmx को expose करने का अर्थ है guest को ऐसा CPU model देना जिसमें वह flag हो। यदि कोई guest उन CPU features पर निर्भर है, तो उसे ऐसी machine पर live-migrate नहीं किया जा सकता जिसका CPU उन्हें सपोर्ट नहीं करता — जो provider ग्राहकों को move करके nodes खाली करते हैं, वे इस सुविधा को छोड़ देते हैं। Nested VMX/SVM code paths का एक लंबा CVE history भी है। कुछ hosts अनुरोध करने पर per-VM इसे enable करते हैं, और अन्य nesting को एक planned feature के रूप में document करते हैं।

मेरे nested VM में public bridge पर network नहीं है। समस्या क्या है?

Provider का switch उन frames को drop कर देता है जो उस MAC address से आते हैं जिसे उन्होंने आपको lease नहीं किया है। इसलिए, public NIC पर bridged L2 guest, ARP भेजता है लेकिन उसे कोई response नहीं मिलता। br0 को debug करना बंद करें — libvirt के NAT default network (virbr0, 192.168.122.0/24) का उपयोग करें, guest को एक static lease दें, और किसी भी public content को VPS पर ही reverse proxy या DNAT rule के माध्यम से publish करें।

एक nested VM कितना धीमा होता है?

इसका प्रभाव VM exits पर पड़ता है, memory access पर नहीं। EPT/NPT active होने पर, L2 के अंदर ordinary reads और writes hardware speed पर चलते हैं, जबकि I/O, timer interrupts, MMIO और IPIs को L0 द्वारा handle किया जाता है और वे L1 के माध्यम से वापस आ सकते हैं। RAM में मौजूद data पर होने वाला CPU-bound work native के करीब दिखता है; syscall-, packet- और disk-heavy workloads में हर layer का असर महसूस होता है। हर जगह virtio devices और guest disks पर cache=none का उपयोग करें, फिर अपने workload को measure करें।