VPS पर Proxmox और Nested Virtualization कैसे चलाएं?

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

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

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

असल में क्या nested किया जा रहा है

तीन layers हैं:

• L0, physical machine पर provider का hypervisor। आपको इसकी access नहीं है।
• 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 पढ़ने देने के लिए करता है।

इनमें से किसी को भी re-entrant होने के लिए design नहीं किया गया था, इसलिए nesting को emulate किया जाता है: जब L1 VMLAUNCH या VMRESUME जैसे VMX instruction को execute करता है, तो वह L0 में trap होता है। L0, L1 की ओर से L2 के लिए shadow structures maintain करता है। VMCS shadowing वाले CPU पर L1 के VMREAD और VMWRITE को exit के बिना serve किया जा सकता है। इससे उस traffic का बड़ा हिस्सा हट जाता है, लेकिन बाकी traffic बना रहता है। KVM यह काम अच्छी तरह करता है, लेकिन हर exit पर अतिरिक्त काम L0 ही करता है। इसी कारण provider को इसके लिए opt in करना पड़ता है।

जब L0, KVM हो, तो accelerated L2 के लिए दोनों conditions पूरी होनी चाहिए:

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) nesting globally enabled होने पर भी vmx को hide कर देता है।

अन्य hypervisors में इसके लिए अपना switch होता है। उदाहरण के लिए, Hyper-V अपने VMs के अंदर nested hypervisor के लिए virtualization extensions को emulate करता है, लेकिन केवल उन VMs में जिनमें nesting को individually enabled किया गया हो।

एक मिनट में अपने 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 के रूप में मौजूद होता है। यदि 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 removal अस्वीकार किया जाता है, इसलिए पहले सभी guests को shut down करें। यदि वह मशीन Proxmox host है, तो Proxmox VE 9 में nested virtualization सक्षम करना उसी modprobe.d बदलाव के साथ प्रति-VM cpu: host setting भी बताता है, जिससे guest के अंदर यह flag दिखाई देता है।

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

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

क्या आपके instance पर कोई flag नहीं है? support से पूछें (कुछ इसे प्रति-VM enable करते हैं), ऐसा plan चुनें जो nesting का दस्तावेजीकरण करता हो, या dedicated box पर migrate करें। बाकी का यह लेख यह मानकर चलता है कि आपके पास ऐसी 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 के अंदर शुरू करें: वही VPS पर Claude Code sessions को चालू रखने वाला tmux workflow dropped SSH connection के बाद भी virt-install console को connected रखता है। यदि --os-variant debian13 reject हो, तो आपका 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 के दौरान L0 जिस exit को स्वयं पूरा नहीं कर सकता, वह L1 तक reflect होता है। वहाँ उसे handle करने से L1 के अपने अतिरिक्त exits भी उत्पन्न हो सकते हैं।

नेटवर्किंग: वह हिस्सा जिसे ट्यूटोरियल छोड़ देते हैं

आपके VPS का एक public IP होता है और यह एक ऐसे फैब्रिक के पीछे स्थित होता है जो अज्ञात MAC addresses को फ़िल्टर करता है। इसके दो परिणाम होते हैं।

L2 guests को public network पर bridge करना आमतौर पर काम नहीं करेगा। public NIC पर br0 लगाएँ, guest को उसका अपना MAC दें, और आप देखेंगे कि ARP बाहर तो जाता है लेकिन वापस कुछ नहीं आता; प्रदाता का स्विच उन MAC से आने वाले frames को ड्रॉप कर देता है जिन्हें उसने आपको lease नहीं किया है। यदि आपके साथ यही समस्या है, तो bridge को debug करना बंद करें; यह इसी तंत्र के कारण है।

इसके बजाय NAT network का उपयोग करें। libvirt में default आता है: virbr0, 192.168.122.0/24, dnsmasq leases, outbound तुरंत काम करता है। Inbound के लिए, L1 पर TLS 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 को इंटरनेट से दूर रखें: 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 खो जाती है, तो इसका सामान्य कारण /etc/default/ufw में DEFAULT_FORWARD_POLICY="DROP" होता है, इसे ACCEPT पर सेट करें और ufw को reload करें।

VPS पर Proxmox

Proxmox VE 9 के आधार में Debian 13 होता है, इसलिए इसे Debian VPS पर pve-no-subscription रिपॉजिटरी और proxmox-ve पैकेज जोड़कर इंस्टॉल किया जाता है। रिपॉजिटरी और कीरिंग की लाइनों को Proxmox के वर्तमान आधिकारिक दस्तावेज़ों से ही लें, क्योंकि पुराने ब्लॉग पोस्ट से कॉपी किया गया URL इंस्टॉलेशन को खराब कर सकता है। नीचे दिए गए नेटवर्किंग सेटअप पर समय बिताने से पहले यह तय कर लेना उचित है कि क्या Proxmox को किराए के हार्डवेयर पर चलाना सही है, और घर पर Proxmox बॉक्स और किराए के VPS के बीच लागत और क्षमता की तुलना इस प्रश्न का वह संस्करण है जिसमें बिजली और हार्डवेयर का गणित पहले ही किया जा चुका है।

पैकेज इंस्टॉल करना कठिन हिस्सा नहीं है। Proxmox को एक फिजिकल NIC से जुड़े vmbr0 ब्रिज की आवश्यकता होती है, जो सीधे ऊपर बताए गए MAC-filtering के गतिरोध तक ले जाता है। VPS पर जो तरीका काम करता है, वह बिना किसी फिजिकल पोर्ट से जुड़ा NAT'd या routed vmbr0 है, जिसमें गेस्ट एक प्राइवेट रेंज में होते हैं, और सार्वजनिक सेवाओं के लिए होस्ट पर DNAT नियम या रिवर्स प्रॉक्सी का उपयोग किया जाता है। जहाँ सार्वजनिक रूप से दिखने वाली सेवाएं VM के बजाय कंटेनर हैं, वहां एक Docker Compose फ़ाइल से कई ऐप्स को संभालने वाला Traefik स्वचालित प्रमाणपत्रों के साथ वही रूटिंग कार्य पूरा करता है। सबसे पहले /etc/network/interfaces का स्नैपशॉट लें: एक गलत ब्रिज परिभाषा आपको उस मशीन से बाहर कर सकती है जिसका कंसोल आपके पास शायद न हो।

प्रदर्शन, ईमानदार आकलन

Nested virtualization single-level virtualization से धीमी होती है। इसका कारण विशिष्ट है, व्यापक नहीं: इसकी लागत exits और address translation पर आती है, सामान्य instructions पर नहीं। EPT/NPT उपलब्ध होने पर L0, L2 की page tables और अपनी page tables को एक shadow table में मिला देता है। इसलिए TLB hit hardware speed पर चलता है। TLB miss की लागत अधिक होती है: hardware guest की page table और shadow table को साथ-साथ walk करता है। L1 अपनी page tables में जो भी बदलाव करता है, उससे exit होता है, ताकि L0 shadow table को फिर से synchronize कर सके। Guest mode से बाहर जाने वाली हर operation महँगी होती है। इसमें I/O, timer interrupts, MMIO और inter-processor interrupts शामिल हैं। L2 exit को L0 संभालता है और वह इसे L1 के रास्ते वापस भेज सकता है। छोटे working set पर CPU-bound work native performance के करीब रहता है। बड़े in-memory working set को TLB misses की लागत चुकानी पड़ती है। Syscalls, packets और disk I/O पर निर्भर workload में virtualization की सभी layers का प्रभाव महसूस होता है।

इसलिए हर जगह virtio devices का उपयोग करें। साथ ही, आपकी qcow2 file उस disk पर रहती है जिसे provider पहले ही virtualize कर चुका है। इस तरह two thin-provisioning layers stacked रहती हैं। cache=none guest disk पर होने पर वही blocks एक ही समय में दो page caches में मौजूद नहीं रहते। यहाँ benchmark numbers नहीं दिए गए हैं। अपने workload को अपनी instance पर स्वयं measure करें।

विफलता के प्रकार और दिखाई देने वाले स्ट्रिंग्स

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used जो kvm-ok से आता है। या तो मॉड्यूल लोड नहीं है, या फ्लैग एक्सपोज़ नहीं है। पहले /proc/cpuinfo की जाँच करें।

kvm: disabled by bios जो dmesg में मिलता है। Bare metal पर, firmware में 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। यह हार्डवेयर नहीं, बल्कि अनुमतियों (permissions) की समस्या है। ls -l /dev/kvm को group kvm और mode 660 दिखाना चाहिए; खुद को उस ग्रुप में जोड़ें और एक नया लॉगिन शेल शुरू करें, क्योंकि ग्रुप मेंबरशिप पहले से चल रहे सेशन पर लागू नहीं होती है।

kvm: Device or resource busy जब QEMU शुरू होता है। कोई अन्य हाइपरवाइजर मॉड्यूल CPU को होल्ड किए हुए है: lsmod चलाएं, kvm_intel के साथ vboxdrv या VMware मॉड्यूल देखें, और जिसे आप नहीं चाहते उसे अनलोड करें।

/var/run/libvirt/libvirt-sock: No such file or directory जो virsh से आता है। डेमन डाउन है: sudo systemctl enable --now libvirtd।

Proxmox: KVM virtualisation configured, but not available. एक गेस्ट में KVM एक्सेलेरेशन टिक किया गया है, लेकिन होस्ट इसे प्रदान नहीं कर सकता। नेस्टिंग को ठीक करें, या टिक हटा दें और एमुलेशन स्वीकार करें।

Android emulator: 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 killer इसे किसी अन्य प्रोसेस की तरह ही ट्रीट करता है। L2 RAM, L1 के फिक्स्ड एलोकेशन से आती है, होस्ट से कोई उधार नहीं लिया जा सकता।

इसे चलाना: backups, upgrades और limits

Backups। चल रहे guest की qcow2 कॉपी करने पर inconsistent image बन सकती है, क्योंकि पढ़े जाने के दौरान guest लगातार लिखता रहता है। या तो virsh shutdown guest1 चलाएँ, virsh domstate guest1 के shut off रिपोर्ट करने तक प्रतीक्षा करें (shutdown command के लौटने के बाद भी guest का stop होना जारी रह सकता है), और फिर कॉपी करें; या external snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) लें, ताकि कॉपी किए जा रहे अब-static base पर writes करने के बजाय overlay में जाएँ। इसके बाद virsh blockcommit guest1 vda --active --pivot से changes को base में merge करें। कॉपियाँ VPS से बाहर रखें; उसी disk पर मौजूद snapshot किसी disk 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 की जरूरत होगी।

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

FAQ

Docker को VPS पर चलाने के लिए क्या nested virtualization आवश्यक है?

नहीं। Containers आपके VPS kernel को share करते हैं और कभी /dev/kvm नहीं खोलते। इसलिए vmx या svm flag के बिना सामान्य instance पर Docker और Docker Compose ठीक से चलते हैं। Nesting केवल तब आवश्यक है जब आपको दूसरा kernel चाहिए: Proxmox lab, Windows guest, Firecracker microVMs, Android emulator या VM images boot करने वाले CI runners के लिए।

मेरा VPS nested virtualization support करता है या नहीं, यह कैसे जाँचूँ?

grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u चलाएँ, फिर cpu-checker package से 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 को अनदेखा करें। वह file आपके अपने KVM module का विवरण देती है, provider के hypervisor द्वारा आपको उपलब्ध कराई गई सुविधाओं का नहीं।

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

vmx expose करने का अर्थ guest को वह flag वाला CPU model देना है। इन CPU features पर निर्भर guest को ऐसे machine पर live-migrate नहीं किया जा सकता जिसके CPU में ये features नहीं हैं। Customers को nodes के बीच स्थानांतरित करके drain करने वाला provider यह सुविधा छोड़ देता है। Nested VMX/SVM code paths में CVE का लंबा इतिहास भी है। कुछ hosts request पर प्रत्येक VM के लिए इसे enable करते हैं। अन्य providers nesting को plan feature के रूप में document करते हैं।

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

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

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

इसका overhead VM exits और address translation पर आता है। EPT/NPT active होने पर L2 के भीतर instructions और TLB hits hardware speed पर चलते हैं। लेकिन TLB miss होने पर अतिरिक्त page tables walk की जाती हैं। I/O, timer interrupts, MMIO और IPIs को L0 handle करता है और वे L1 के माध्यम से वापस भेजे जा सकते हैं। छोटे working set वाला CPU-bound work native performance के करीब रहता है। बड़े in-memory working sets और syscall-, packet- तथा disk-heavy workloads में प्रत्येक layer का overhead महसूस होता है। हर जगह virtio devices इस्तेमाल करें और guest disks पर cache=none चलाएँ। इसके बाद अपने workload को measure करें।