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

VPS मध्ये Proxmox चालवता येईल का?

तुमच्या VPS मध्ये nested virtualization आहे की नाही हे kvm-ok कमांड वापरून तपासा. Intel किंवा AMD flags उपलब्ध नसल्यास Proxmox चालवणे शक्य नाही.

थोडक्यात उत्तर

Nested virtualization म्हणजे virtual machine च्या आत चालणारा hypervisor होय: तुमचा VPS आधीच एक guest आहे आणि तुम्हाला त्यामध्ये स्वतःचे guests होस्ट करायचे आहेत. जेव्हा तुमच्या provider चा hypervisor जाणीवपूर्वक CPU चे virtualization extensions तुमच्या instance ला उपलब्ध करून देतो, तेव्हाच हे काम करते — Intel साठी vmx flag किंवा AMD साठी svm flag साठी /proc/cpuinfo तपासा. जर दोन्हीपैकी काहीही आढळले नाही, तर VPS च्या आत तुम्ही काहीही कॉन्फिगर केले तरी ते सुधारेल असे नाही.

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

प्रत्यक्षात काय नेस्टेड (nested) आहे

तीन स्तर (layers):

  • L0 — फिजिकल हार्डवेअरवरील प्रोव्हायडरचा 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 emulated असते: जेव्हा L1 एखादी VMX instruction एक्झिक्यूट करते, तेव्हा ती L0 कडे ट्रॅप होते; L0 मग L1 च्या वतीने L2 साठी shadow structures मेंटेन करते. KVM हे उत्तमरित्या करते, परंतु प्रत्येक exit वेळी L0 ला अतिरिक्त काम करावे लागते — म्हणूनच प्रोव्हायडरला यासाठी opt in करावे लागते.

Accelerated L2 साठी खालील दोन्ही अटी पूर्ण होणे आवश्यक आहे:

  1. L0 चा KVM module nested=1 सह लोड केलेला असावा.
  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) सुरू असतानाही 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 तुम्ही स्वतःच्या मालकीच्या मशीनवर सेट करण्याचा पर्याय आहे:

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 सक्षम केल्यामुळे CPU मॉडेलमधील विशिष्ट flag उघड होतो. जर guest OS ला त्या CPU features ची आवश्यकता असेल, तर त्या features नसलेल्या मशीनवर त्याचे सुरक्षितपणे migration करणे अशक्य होते. जर होस्ट ग्राहकांना migrate करून nodes रिकाम्या करत असेल, तर nesting enable केल्यामुळे ही सुविधा वापरता येत नाही.
  • Attack surface. nested VMX/SVM paths हे kernel च्या virtualization layer मधील अत्यंत गुंतागुंतीचे code आहेत आणि त्यांच्याशी संबंधित अनेक CVE history आहे.
  • L0 may not be KVM. जर systemd-detect-virt ने vmware, xen किंवा microsoft प्रिंट केले, तर nesting चे नियम त्या stack चे असतील, KVM चे नाहीत.

तुमच्या instance वर flag दिसत नसेल, तर support ला विचारा (काही होस्ट per-VM हे सक्षम करतात), nesting ची माहिती असलेला plan निवडा, किंवा dedicated box कडे वळा. यापुढील माहिती ही 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'

यासाठी कोणत्याही graphical session ची गरज नाही. serial install काही वेळ चालते, म्हणून ते persistent shell मध्ये सुरू करा: tmux workflow ज्याप्रमाणे Claude Code sessions VPS वर जिवंत ठेवतात, त्याचप्रमाणे तो virt-install console SSH connection तुटले तरी जोडलेला ठेवतो. जर --os-variant debian13 नाकारले गेले, तर तुमचा osinfo-db रिलीजच्या आधीचा आहे — osinfo-query os चालवा आणि अस्तित्वात असलेले नाव निवडा. --cpu host-passthrough हे vmx L2 मध्ये forward करते, याची गरज फक्त तेव्हाच लागते जेव्हा L2 ला स्वतः virtualization करायचे असते. 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 च्या मागे असतो जे अज्ञात MAC addresses फिल्टर करते. याचे दोन परिणाम होतात.

L2 guests ला public network वर bridge करणे सहसा यशस्वी होत नाही. जर तुम्ही public NIC वर br0 वापरले आणि guest ला स्वतःचा MAC दिला, तर ARP request बाहेर जाईल पण प्रतिसाद मिळणार नाही — provider चा switch अशा MAC कडून येणारे frames ड्रॉप करतो जो तुम्हाला कधीही lease केलेला नाही. जर तुम्हाला ही समस्या येत असेल, तर bridge debug करणे थांबवा; हीच सिस्टमची कार्यपद्धती आहे.

त्याऐवजी NAT network वापरा. libvirt मध्ये default उपलब्ध आहे: virbr0, 192.168.122.0/24, आणि dnsmasq leases; यामुळे outbound connectivity लगेच सुरू होते. Inbound connectivity साठी, 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 इंटरनेटवर ठेवू नका: 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 वर सेट करा आणि ufw reload करा.

VPS वर Proxmox

Proxmox VE 9 हे अंतर्गत Debian 13 वर आधारित आहे. त्यामुळे, pve-no-subscription repository आणि proxmox-ve package जोडून ते Debian VPS वर इंस्टॉल करता येते. Repository आणि keyring च्या ओळी Proxmox च्या अधिकृत documentation मधून घ्या — जुन्या ब्लॉग पोस्टवरून घेतलेला URL वापरल्यास installation fail होऊ शकते.

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

Performance, honest assessment

Nested virtualization हे single-level पेक्षा संथ असते. याचे कारण विखुरलेले नसून विशिष्ट आहे: खर्च memory access मध्ये नसून exits मध्ये असतो. EPT/NPT उपलब्ध असल्यास, L0 कडून L2 साठी shadow page tables राखले जातात आणि सामान्य memory reads hardware च्या वेगाने चालतात. खर्च वाढतो ती प्रत्येक क्रिया ज्यामुळे guest mode मधून बाहेर पडावे लागते — जसे की I/O, timer interrupts, MMIO, आणि inter-processor interrupts — कारण L2 exit L0 द्वारे हाताळले जाते आणि ते पुन्हा L1 द्वारे प्रतिबिंबित होऊ शकते. RAM मध्ये असलेल्या डेटावर आधारित CPU-bound काम हे native च्या जवळ जाणारे वाटते; परंतु syscalls, packets आणि disk I/O वर अवलंबून असलेल्या कामांवर या layers चा परिणाम जाणवतो.

थोडक्यात: सर्वत्र virtio devices वापरा. आणि तुमची qcow2 file अशा disk वर असते जी provider ने आधीच virtualize केलेली असते — येथे दोन thin-provisioning layers एकत्र असतात, जिथे guest disk वरील cache=none एकाच वेळी दोन page caches मध्ये असणारे blocks थांबवते. येथे कोणतेही benchmark numbers दिलेले नाहीत: तुमच्या स्वतःच्या instance वर तुमच्या स्वतःच्या workload चे मोजमाप करा.

Failure modes, and the strings you will see

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

kvm: disabled by bios in 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 सुरू करा, कारण आधीच सुरू असलेल्या session मध्ये group membership लागू होत नाही.

kvm: Device or resource busy when QEMU starts. दुसरा hypervisor module CPU वापरत आहे: lsmod चालवा, vboxdrv किंवा VMware modules सोबत kvm_intel शोधा, आणि नको असलेला module unload करा.

/var/run/libvirt/libvirt-sock: No such file or directory from virsh. Daemon बंद आहे: sudo systemctl enable --now libvirtd.

Proxmox: KVM virtualisation configured, but not available. Guest मध्ये KVM acceleration चालू आहे, परंतु host ते देऊ शकत नाही. Nesting दुरुस्त करा किंवा emulation साठी ते बंद करा.

Android emulator: x86_64 emulation currently requires hardware acceleration! पुन्हा /dev/kvm — सहसा group मुळे ही समस्या येते.

No error at all, and everything is glacial. QEMU मध्ये accelerator flag नसेल तर ते TCG (software emulator) वापरते. हे योग्य आहे पण अत्यंत संथ आहे — boot process सेकंदांऐवजी मिनिटांत चालतो. -accel kvm स्पष्टपणे पास करा, जेणेकरून QEMU शांतपणे emulation करण्याऐवजी error दाखवून थांबेल.

A guest vanishes mid-run. dmesg मध्ये Out of memory: Killed process ... qemu-system-x86_64 तपासा. L2 guest हा L1 वरील एक process असतो आणि OOM killer त्याच्याशी इतर processes प्रमाणेच वागते. L2 RAM ही L1 च्या निश्चित allocation मधून येते — host कडून अतिरिक्त RAM मिळत नाही.

Operating it: backups, upgrades, limits

Backups. चालू असलेल्या guest चा qcow2 copy केल्यास image corrupt होते. एकतर virsh shutdown guest1 वापरून copy करा, किंवा external snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) घ्या; यामुळे writes overlay कडे वळवले जातात आणि तुम्ही static base copy करू शकता, त्यानंतर virsh blockcommit वापरून ते पुन्हा fold करा. या copies VPS च्या बाहेर पाठवा — एकाच disk वरील snapshot कडून कोणताही फायदा होत नाही.

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

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

FAQ

VPS वर Docker चालवण्यासाठी मला 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 ला सपोर्ट करतो की नाही हे मी कसे तपासेन?

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

बहुतेक VPS providers nested virtualization का disable करतात?

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

माझ्या nested VM ला public bridge वर network का मिळत नाहीये?

Provider चा switch अशा MAC address कडून येणारे frames ड्रॉप करतो जो त्यांनी तुम्हाला कधीही 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 द्वारे हाताळले जातात आणि ते L1 मधून परत येऊ शकतात. RAM मधील डेटावर आधारित CPU-bound काम native च्या जवळ जाणारे वाटते; परंतु syscall-, packet- आणि disk-heavy workloads मध्ये प्रत्येक layer चा परिणाम जाणवतो. सर्वत्र virtio devices आणि guest disks वर cache=none वापरा, त्यानंतर तुमच्या workload चे मोजमाप करा.

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