SSD Nodes Learn Hosting plans →
मार्गदर्शक Matt Connorद्वारे Matt Connor · अपडेटेड 2026-08-07

VPS वर nested virtualization वापरून Proxmox चालेल का?

बहुतेक VPS मध्ये vmx flag लपवलेला असतो. kvm-ok ने एका मिनिटात तपासा; KVM किंवा Proxmox guest सुरू करताना दिसणारे अचूक error strings आणि मर्यादा जाणून घ्या.

थोडक्यात

Nested virtualization म्हणजे virtual machine च्या आत चालणारा hypervisor. तुमचा VPS आधीच एक guest आहे आणि त्यावर स्वतःचे guests चालवायचे आहेत. हे तेव्हाच कार्य करते जेव्हा तुमच्या provider चा hypervisor CPU मधील virtualization extensions तुमच्या instance साठी जाणीवपूर्वक उपलब्ध करून देतो. /proc/cpuinfo मध्ये vmx flag (Intel) किंवा svm (AMD) आहे का ते तपासा. यापैकी कोणतेही दिसत नसेल, तर VPS च्या आत केलेली कोणतीही configuration ही समस्या सोडवू शकत नाही.

सुरुवातीला एक अपेक्षा स्पष्ट करूया: Docker ला यापैकी कशाचीही आवश्यकता नाही. Containers तुमचा VPS kernel share करतात आणि /dev/kvm ला कधीही थेट वापरत नाहीत. "माझ्या server वर containers मध्ये अनेक सेवा चालवायच्या आहेत" हा खरा उद्देश असल्यास, तुमच्याकडे आवश्यक सर्वकाही आधीपासूनच आहे. दुसरा kernel, Proxmox lab, Windows guest, Firecracker microVMs, Android emulator, प्रत्यक्ष VMs असलेले Kubernetes testbed किंवा VM images boot करणारे CI runners चालवायचे असतील, तेव्हा nesting उपयुक्त ठरते.

प्रत्यक्षात कोणते स्तर nested केले जात आहेत

तीन स्तर आहेत:

  • L0, physical server वरील provider चा hypervisor. तुम्हाला याचा प्रवेश नाही.
  • L1, तुमचा VPS. L0 साठी हा केवळ एक guest आहे.
  • L2, तुमच्या VPS मध्ये चालवायचे असलेले VM.

Hardware virtualization म्हणजे Intel वर VT-x (vmx flag) आणि EPT, तसेच AMD वर AMD-V / SVM (svm) आणि RVI/NPT. Hypervisor या instructions वापरून guest mode मध्ये प्रवेश करतो आणि CPU ला एकाच वेळी दोन page tables वाचू देतो.

यापैकी कोणतीही रचना re-entrant वापरासाठी तयार केलेली नाही. त्यामुळे nesting चे emulation केले जाते: L1 ने VMX instruction execute केल्यावर तो L0 कडे trap होतो. त्यानंतर L0, L1 च्या वतीने L2 साठी shadow structures सांभाळतो. KVM हे काम चांगल्या प्रकारे करते. मात्र प्रत्येक exit वेळी अतिरिक्त काम L0 ला करावे लागते. म्हणून provider ने nesting साठी स्पष्टपणे परवानगी देणे आवश्यक असते.

Accelerated L2 साठी खालील दोन्ही अटी पूर्ण झाल्या पाहिजेत:

  1. L0 चा KVM module nested=1 सह loaded असला पाहिजे.
  2. L0 ने तुमच्या VPS ला हा flag असलेला CPU model दिला पाहिजे: libvirt मध्ये <cpu mode='host-passthrough'/>, Proxmox मध्ये cpu: host आणि raw QEMU मध्ये -cpu host. Generic emulated model (qemu64, kvm64) nesting जागतिक स्तरावर enabled असले तरी 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 mode 660 म्हणून उपलब्ध असते. flag दिसत असेल, पण device node उपलब्ध नसेल, तर module manually 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 ला तिसरा स्तर nested पद्धतीने चालवता येईल का, हे ती नियंत्रित करते. L0 ने तुमच्यासाठी nesting enable केले आहे की नाही, हे ती सांगत नाही. त्यासाठी /proc/cpuinfo आणि kvm-ok हे तपासा. nested parameter म्हणजे तुमच्या पूर्ण मालकीच्या machine वर सेट करायचा पर्याय:

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 प्रदाते हे बंद का ठेवतात

  • Live migration. तुम्हाला vmx उपलब्ध करून देणे म्हणजे तो flag असलेले CPU model उघड करणे. त्या CPU features वर अवलंबून असलेले guest, ही features नसलेल्या CPU असलेल्या मशीनवर सुरक्षितपणे migrate करता येत नाही. ग्राहकांचे nodes migrate करून host रिकामा करणारा प्रदाता nesting enable केल्यावर ही क्षमता गमावतो.
  • Attack surface. Nested VMX/SVM paths हे kernel च्या virtualization layer मधील सर्वाधिक गुंतागुंतीच्या code पैकी आहेत. त्यांच्याशी संबंधित CVE history देखील मोठी आहे.
  • L0 कदाचित KVM नसेल. जर systemd-detect-virt ने vmware, xen किंवा microsoft दाखवले, तर nesting rules KVM च्या नसून त्या stack च्या असतात.

तुमच्या instance वर flag नाही? Support कडे विचारा. काही प्रदाते ते प्रत्येक VM साठी enable करतात. Nesting documented असलेला plan निवडा किंवा dedicated box वर migrate करा. पुढील भागात flag दाखवणाऱ्या मशीनवर root access असल्याचे गृहीत धरले आहे.

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 install काही काळ चालते, त्यामुळे ते persistent shell मध्ये सुरू करा: VPS वरील Claude Code sessions चालू ठेवणारा तोच tmux workflow SSH connection तुटल्यानंतरही virt-install console जोडलेली ठेवतो. --os-variant debian13 नाकारले गेल्यास, तुमची osinfo-db release पेक्षा जुनी आहे. osinfo-query os चालवा आणि उपलब्ध असलेले नाव निवडा. --cpu host-passthrough vmx L2 मध्ये पुढे पाठवते; L2 ला पुढे virtualization करायचे असल्यासच ते आवश्यक आहे. virsh autostart guest1 वापरून guest boot-safe करा.

Disk आणि NIC वरील virtio bus केवळ सजावटीसाठी नाही. Emulated IDE आणि e1000 devices virtio queues च्या तुलनेत hypervisor मध्ये अधिक वेळा trap करतात. Nesting मध्ये प्रत्येक trap ची किंमत दोनदा मोजावी लागते.

नेटवर्किंग: ट्युटोरियलमध्ये वगळला जाणारा भाग

तुमच्या VPS कडे एक public IP आहे आणि अज्ञात MAC addresses फिल्टर करणाऱ्या नेटवर्क fabric मागे तो चालतो. याचे दोन परिणाम होतात.

L2 guests ना public network वर bridge करणे सहसा कार्य करत नाही. Public NIC वर br0 ठेवा आणि guest ला स्वतःचा MAC द्या. त्यानंतर ARP विनंत्या बाहेर जाताना दिसतील, पण कोणतेही उत्तर येणार नाही. Provider चा switch त्याने lease न केलेल्या MAC कडून आलेले frames टाकून देतो. हेच तुमचे लक्षण असल्यास bridge debugging थांबवा; यामागील यंत्रणा हीच आहे.

त्याऐवजी NAT network वापरा. libvirt default पुरवते: virbr0, 192.168.122.0/24, dnsmasq leases आणि लगेच कार्यरत outbound connectivity. Inbound traffic साठी L1 वर TLS termination करा आणि proxy द्वारे traffic आत पाठवा. खालील 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 enable केल्यानंतर guests ची outbound connectivity लगेच बंद झाली, तर नेहमीचे कारण /etc/default/ufw मधील DEFAULT_FORWARD_POLICY="DROP" असते. ते ACCEPT वर सेट करा आणि ufw reload करा.

VPS वर Proxmox

Proxmox VE 9 अंतर्गत Debian 13 वर आधारित आहे. त्यामुळे pve-no-subscription repository आणि proxmox-ve package जोडून ते Debian VPS वर install करता येते. Repository आणि keyring च्या ओळी Proxmox च्या सध्याच्या अधिकृत documentation मधून घ्या. जुन्या blog post मधून कॉपी केलेली URL वापरल्यास install अपयशी ठरते. Proxmox rented hardware वर चालवणे योग्य आहे का, हा निर्णय खालील networking configuration वर संपूर्ण संध्याकाळ खर्च करण्यापूर्वी घ्या. घरातील Proxmox मशीन आणि rented VPS यांच्यातील खर्च व क्षमतेची तुलना हा त्या प्रश्नाचा असा आढावा आहे, ज्यात वीज आणि hardware चे गणित आधीच केलेले आहे.

Packages हा कठीण भाग नाही. Proxmox ला vmbr0 physical NIC शी bridged स्वरूपात जोडलेले अपेक्षित असते. त्यामुळे वर नमूद केलेल्या MAC-filtering अडथळ्याला थेट सामोरे जावे लागते. VPS वर कार्य करणारी रचना म्हणजे physical port शी जोडलेले नसलेले NAT'd किंवा routed vmbr0, private range वरील guests आणि public सेवांसाठी host वर DNAT rules किंवा reverse proxy. Public-facing सेवा VM ऐवजी containers असतील, तर एकाच Docker Compose file मधून अनेक अॅप्ससमोर Traefik ठेवणे हे automatic certificates सह तेच routing काम करते. प्रथम /etc/network/interfaces snapshot घ्या. चुकीची bridge definition केल्यास ज्या मशीनचा console access कदाचित उपलब्ध नसेल, त्या मशीनमधून तुमचा access बंद होऊ शकतो.

प्रामाणिकपणे सांगायचे झाल्यास कामगिरी

एकाच स्तराच्या तुलनेत nested रचना धीमी असते. त्यामागील कारण अस्पष्ट नसून विशिष्ट आहे: खर्च memory access मुळे होत नाही; exits मुळे होतो. EPT/NPT उपलब्ध असल्यास, L0, L2 साठी shadow page tables राखतो आणि सामान्य memory reads हार्डवेअरच्या वेगाने चालतात. खर्चिक ठरणाऱ्या गोष्टी म्हणजे 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 file अशा disk वर असते, जिचे virtualization provider ने आधीच केलेले असते. त्यामुळे thin-provisioning चे दोन स्तर एकावर एक येतात आणि cache=none मुळे guest disk वरील तेच blocks एकाच वेळी दोन page caches मध्ये राहणे थांबते. येथे benchmark चे आकडे दिलेले नाहीत. तुमच्या स्वतःच्या instance वर तुमचे स्वतःचे workload मोजा.

अपयशाच्या स्थिती आणि दिसणारे संदेश

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used kvm-ok कडून. एकतर module लोड केलेले नाही किंवा flag उघड केलेला नाही. प्रथम /proc/cpuinfo तपासा.

kvm: disabled by bios dmesg मध्ये. Bare metal वर firmware मधील VT-x/SVM toggle बदला. VPS मध्ये याचा अर्थ L0 तुम्हाला extensions देत नाही असा होतो. Guest मध्ये तुम्ही टाइप केलेल्या कोणत्याही command ने हे बदलत नाही.

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 सुरू करा, कारण आधीपासून सुरू असलेल्या session ला group membership लागू होत नाही.

QEMU सुरू होताना kvm: Device or resource busy दिसते. दुसरा hypervisor module CPU ताब्यात घेत आहे. lsmod चालवा. vboxdrv किंवा kvm_intel सोबत 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 वर fallback होते. TCG हा त्याचा software emulator आहे. तो योग्यरीत्या काम करतो, पण धीमा आहे. काही सेकंदांत होणारे boot होण्यासाठी काही मिनिटे लागू शकतात. -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 उधार घेतली जात नाही.

ऑपरेशन: बॅकअप, अपग्रेड आणि मर्यादा

बॅकअप. चालू guest ची qcow2 कॉपी केल्यास image corrupt होते. एकतर virsh shutdown guest1 करून कॉपी घ्या, किंवा external snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) तयार करा. त्यामुळे कॉपी करताना writes overlay कडे वळतात आणि आता स्थिर असलेल्या base ची कॉपी करता येते. त्यानंतर virsh blockcommit वापरून ते पुन्हा एकत्र करा. या कॉपी VPS च्या बाहेर पाठवा. त्याच disk वर असलेला snapshot कोणत्याही disk failure पासून संरक्षण देत नाही.

अपग्रेड. apt full-upgrade नवीन kvm_intel/kvm_amd modules install करते. मात्र reboot करेपर्यंत चालू kernel जुने modules वापरतो. मागील kernel install ठेवावा आणि प्रत्येक kernel बदलानंतर kvm-ok पुन्हा चालवावे. vmx शिवाय host पुन्हा सुरू झाला, तरी तो पुन्हा कार्यरत करण्यासाठी फक्त एक boot entry निवडणे पुरेसे ठरते.

ही रचना कुठे विस्तारक्षम राहत नाही. एकच public IP असल्यामुळे प्रत्येक L2 service proxy किंवा L1 वरील DNAT rule मार्फत जगाशी जोडली जाते. Live migration उपलब्ध नसते. CPU contention झाल्यावर nested exit path वर सर्वप्रथम परिणाम होतो. अनेक guests असलेला hypervisor म्हणजे त्याची RAM तुम्ही आधीच वाटून वापरलेली मशीन होय; fixed allocation मधून nested VMs overcommit करून सुटका करू शकत नाहीत. Lab ची गरज यापेक्षा वाढल्यावर उपाय म्हणजे अधिक उंच nested stack नव्हे. त्याऐवजी dedicated box वापरा, जिथे तुम्ही L0 असाल आणि यापैकी कोणतीही मर्यादा लागू होणार नाही.

FAQ

Docker चालवण्यासाठी VPS वर nested virtualization आवश्यक आहे का?

नाही. Containers तुमचा VPS kernel सामायिक करतात आणि कधीही /dev/kvm उघडत नाहीत. त्यामुळे vmx किंवा svm flag नसलेला साधा instance Docker आणि Docker Compose व्यवस्थित चालवतो. दुसरा kernel चालवायचा असल्यासच nesting आवश्यक ठरते: Proxmox lab, Windows guest, Firecracker microVMs, Android emulator किंवा VM images boot करणारे CI runners.

माझा VPS nested virtualization समर्थित करतो का हे कसे तपासावे?

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 नोंदलेले असते. तसेच /dev/kvm हे kvm group आणि 660 mode सह उपलब्ध असते. या प्रश्नासाठी /sys/module/kvm_intel/parameters/nested कडे दुर्लक्ष करा. ती file provider च्या hypervisor ने तुम्हाला कोणती सुविधा दिली हे दाखवत नाही; ती तुमच्या स्वतःच्या KVM module चे वर्णन करते.

बहुतेक VPS providers nested virtualization अक्षम का ठेवतात?

vmx उघड करणे म्हणजे हा flag असलेला CPU model guest ला देणे. या CPU features वर अवलंबून असलेला guest अशा machine वर live-migrate करता येत नाही, जिच्या CPU मध्ये ही features नाहीत. Provider ग्राहकांना nodes दरम्यान हलवून nodes रिकामे करत असल्यास ही सुविधा त्याला गमवावी लागते. Nested VMX/SVM code paths शी संबंधित CVE चा इतिहासही मोठा आहे. काही hosts विनंतीनुसार प्रत्येक VM साठी ती सुविधा enable करतात. इतर providers nesting ही plan feature म्हणून documented करतात.

माझ्या nested VM ला public bridge वर network उपलब्ध नाही. काय चुकीचे आहे?

Provider चा switch अशा MAC address कडून आलेले frames drop करतो, जो MAC address त्याने तुम्हाला lease केलेला नसतो. त्यामुळे public NIC वर bridge केलेला L2 guest ARP पाठवतो, परंतु कोणतेही उत्तर मिळत नाही. br0 चे debugging करणे थांबवा. त्याऐवजी libvirt चे NAT default network (virbr0, 192.168.122.0/24) वापरा, guest ला static lease द्या आणि public सेवा VPS वरील reverse proxy किंवा DNAT rule द्वारे प्रकाशित करा.

Nested VM किती धीम्या गतीने चालते?

याचा परिणाम memory access वर नसून VM exits वर होतो. EPT/NPT सक्रिय असल्यास L2 मधील सामान्य reads आणि writes hardware speed ने चालतात. मात्र I/O, timer interrupts, MMIO आणि IPIs L0 कडून हाताळले जातात आणि L1 मधून पुन्हा पाठवले जाऊ शकतात. RAM मध्ये आधीच असलेल्या data वर चालणारे CPU-bound काम native कामगिरीच्या जवळ राहते. syscall-, packet- आणि disk-heavy workloads मध्ये प्रत्येक virtualization layer चा परिणाम जाणवतो. सर्वत्र virtio devices वापरा आणि guest disks वर cache=none लागू करा. त्यानंतर तुमच्या स्वतःच्या workload चे मोजमाप करा.

#nested-virtualization#kvm#proxmox#vps#qemu#libvirt