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 चलाना चाहते हैं।

वास्तव में नेस्टिंग क्या है

तीन परतें:

• L0, प्रदाता का हाइपरवाइजर, जो सीधे हार्डवेयर पर है। आपकी इस तक कोई पहुँच नहीं है।
• L1, आपका VPS। L0 के लिए यह केवल एक गेस्ट है।
• L2, वह VM जिसे आप अपने VPS के अंदर चलाना चाहते हैं।

हार्डवेयर वर्चुअलाइजेशन Intel पर VT-x (vmx फ्लैग) और EPT है, जबकि AMD पर AMD-V / SVM (svm) और RVI/NPT है। एक हाइपरवाइजर इन निर्देशों का उपयोग गेस्ट मोड में प्रवेश करने और CPU को एक साथ दो पेज टेबल को प्रोसेस करने देने के लिए करता है।

इनमें से कोई भी re-entrant होने के लिए डिज़ाइन नहीं किया गया था, इसलिए नेस्टिंग को एमुलेट (emulate) किया जाता है: जब L1 कोई VMX निर्देश निष्पादित करता है, तो यह L0 पर ट्रैप हो जाता है, जो L1 की ओर से L2 के लिए शैडो स्ट्रक्चर बनाए रखता है। KVM इसे अच्छी तरह से करता है, लेकिन हर exit पर L0 को अतिरिक्त काम करना पड़ता है, यही कारण है कि प्रदाता को इसके लिए अनुमति देनी पड़ती है।

एक्सेलेरेटेड L2 के लिए दो शर्तों का पूरा होना आवश्यक है:

1. L0 का KVM मॉड्यूल nested=1 के साथ लोड होना चाहिए।
2. L0 आपके VPS को ऐसा CPU मॉडल दे जिसमें यह फ्लैग हो, libvirt में <cpu mode='host-passthrough'/>, Proxmox में cpu: host, और raw QEMU में -cpu host। एक सामान्य एमुलेटेड मॉडल (qemu64, kvm64) vmx को छिपा देता है, भले ही नेस्टिंग वैश्विक स्तर पर चालू हो।

एक मिनट में अपने 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 को हटाना अस्वीकार कर दिया जाता है, इसलिए पहले guests को बंद (shut down) करें।

अधिकांश 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 के भीतर शुरू करें: वही tmux workflow जो VPS पर Claude Code sessions को जीवित रखता है एक virt-install console को SSH connection टूटने के बाद भी attached रखता है। यदि --os-variant debian13 अस्वीकार कर दिया जाता है, तो आपका osinfo-db इस release से पुराना है, osinfo-query os चलाएं और एक ऐसा नाम चुनें जो मौजूद हो। --cpu host-passthrough, vmx को L2 में forward करता है, जिसकी आवश्यकता केवल तभी होती है जब L2 को बारी-बारी से virtualize करना हो। virsh autostart guest1 के साथ guest को boot-safe बनाएं।

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

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

आपके 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 वर्चुअलाइजेशन सिंगल-लेवल की तुलना में धीमा होता है, और इसका कारण विशिष्ट है: लागत मेमोरी एक्सेस में नहीं, बल्कि exits में होती है। EPT/NPT के मौजूद होने पर, L0, L2 के लिए shadow page tables को बनाए रखता है और सामान्य मेमोरी रीड हार्डवेयर की गति से चलते हैं। जो प्रक्रिया महंगी हो जाती है, वह है guest mode से बाहर निकलने वाला हर ऑपरेशन, जैसे I/O, timer interrupts, MMIO, और inter-processor interrupts, क्योंकि L2 exit को L0 द्वारा हैंडल किया जाता है और इसे वापस L1 के माध्यम से रिफ्लेक्ट किया जा सकता है। RAM में पहले से मौजूद डेटा पर CPU-bound काम native गति के करीब दिखता है; लेकिन जो भी काम syscalls, packets और disk I/O पर निर्भर है, उसमें परतों का प्रभाव महसूस होता है।

इसलिए: हर जगह virtio devices का उपयोग करें। और आपकी qcow2 फाइल उस डिस्क पर रहती है जिसे प्रदाता ने पहले ही वर्चुअलाइज़ कर रखा है, जहाँ दो thin-provisioning परतें एक-दूसरे के ऊपर होती हैं, और guest disk पर cache=none का उपयोग करने से एक ही ब्लॉक दो page caches में एक साथ नहीं रहते। यहाँ कोई बेंचमार्क नंबर नहीं दिए गए हैं: अपने स्वयं के instance पर अपने workload को मापें।

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

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 के फिक्स्ड एलोकेशन से आती है, होस्ट से कोई उधार नहीं लिया जा सकता।

इसका संचालन: बैकअप, अपग्रेड और सीमाएं

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

अपग्रेड। apt full-upgrade नए kvm_intel/kvm_amd modules को install करता है, लेकिन जब तक आप reboot नहीं करते, running kernel पुराने modules का ही उपयोग करता रहता है। पिछले kernel को install रहने दें और हर kernel बदलाव के बाद kvm-ok को फिर से चलाएं: यदि कोई host vmx के बिना वापस आता है, तो वह केवल एक boot entry की दूरी पर फिर से काम करने की स्थिति में होता है।

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

FAQ

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

नहीं। Containers आपके VPS kernel को साझा करते हैं और कभी भी /dev/kvm को open नहीं करते हैं, इसलिए बिना किसी 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) print करेगा, kvm-ok में KVM acceleration can be used दिखाई देगा, और /dev/kvm, kvm group और 660 mode के साथ मौजूद होगा। इस प्रश्न के लिए /sys/module/kvm_intel/parameters/nested को अनदेखा करें, वह file आपके स्वयं के KVM module का वर्णन करती है, न कि उस चीज़ का जिसे provider के hypervisor ने आपको expose किया है।

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

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

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

Provider का switch उन MAC addresses से आने वाले 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 की गति पर चलते हैं, जबकि I/O, timer interrupts, MMIO और IPIs को L0 द्वारा संभाला जाता है और उन्हें L1 के माध्यम से वापस भेजा जा सकता है। RAM में पहले से मौजूद data पर CPU-bound कार्य native के करीब दिखते हैं; syscall-, packet- और disk-heavy workloads हर परत पर प्रभाव महसूस करते हैं। हर जगह virtio devices और guest disks पर cache=none का उपयोग करें, फिर अपने workload को मापें।