pwedeng mag-Proxmox sa VPS?

Ang maikling sagot

Ang nested virtualization ay isang hypervisor na tumatakbo sa loob ng isang virtual machine: ang iyong VPS ay isa nang guest, at gusto mo itong maging host para sa sarili nitong mga guest. Gumagana lamang ito kung ang hypervisor ng iyong provider ay sadyang nag-e-expose ng CPU virtualization extensions sa iyong instance — i-check ang /proc/cpuinfo para sa vmx flag (Intel) o svm (AMD). Kung hindi lumitaw ang alinman sa mga ito, walang configuration sa loob ng VPS ang makakaayos nito.

Isang paunang paalala: Hindi kailangan ng Docker ang alinman sa mga ito. Ang mga container ay gumagamit ng kernel ng iyong VPS at hindi kailanman gumagamit ng /dev/kvm. Kung ang layunin ay "magpatakbo ng ilang services sa mga container sa aking server", mayroon ka nang sapat na resources. Mahalaga ang nesting kung kailangan mo ng pangalawang kernel — gaya ng Proxmox lab, Windows guest, Firecracker microVMs, Android emulator, Kubernetes testbed ng mga totoong VM, o mga CI runner na nagba-boot ng mga VM image.

Ano ang tunay na naka-nest

Tatlong layer:

• L0 — ang hypervisor ng provider, sa mismong hardware. Wala kang access dito.
• L1 — ang iyong VPS. Para sa L0, ang L1 ay isang guest lamang.
• L2 — ang VM na gusto mong patakbuhin sa loob ng iyong VPS.

Ang hardware virtualization ay VT-x (ang vmx flag) plus EPT sa Intel, at AMD-V / SVM (svm) plus RVI/NPT sa AMD. Ginagamit ng hypervisor ang mga instruction na ito para pumasok sa guest mode at para payagan ang CPU na mag-walk ng dalawang page table nang sabay.

Hindi idinisenyo ang mga ito para sa re-entrancy, kaya emulated ang nesting: kapag nag-execute ang L1 ng VMX instruction, magtra-trap ito sa L0, na siyang nagpapanatili ng mga shadow structure para sa L2 para sa L1. Mahusay ang KVM sa paggawa nito, pero ang L0 ang gumagawa ng extra na trabaho sa bawat exit — kaya kailangan ng provider na mag-opt in.

Dapat matugunan ang dalawang kondisyon para sa accelerated L2:

1. Ang KVM module ng L0 ay loaded na may nested=1.
2. Ang L0 ay nagbibigay sa iyong VPS ng CPU model na may flag na ito — <cpu mode='host-passthrough'/> sa libvirt, cpu: host sa Proxmox, at -cpu host sa raw QEMU. Ang generic emulated model (qemu64, kvm64) ay nagtatago ng vmx kahit naka-on ang nesting sa buong system.

I-check ang iyong VPS sa loob ng isang minuto

# 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

Ang isang usable instance ay naglalabas ng vmx o svm, ang kvm-ok ay nagsasabing KVM acceleration can be used, at ang /dev/kvm ay umiiral bilang root:kvm mode 660. Kung naroon ang flag pero wala ang device node, i-load ang module nang manual at basahin ang kernel log:

sudo modprobe kvm_intel     # or kvm_amd
sudo dmesg | tail -n 20

Isang file ang madalas gamitin at madalas ding ma-misinterpret:

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

Sa loob ng iyong VPS, ito ang setting ng iyong KVM module, at ito ang nagtatakda kung ang isang L2 guest ay maaaring mag-nest ng pangatlong level. Hindi nito sinasabi kung enabled ang nesting para sa iyo ng L0 — ang /proc/cpuinfo at kvm-ok ang sumasagot doon. Ang nested parameter ang setting na maaari mong i-adjust sa machine na direktang pagmamay-ari mo:

echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

Hindi pinapayagan ang pag-remove ng module habang may tumatakbong VM, kaya i-shutdown muna ang mga guest.

Bakit madalas itong naka-off sa mga VPS host

• Live migration. Ang pagbibigay ng vmx ay nangangahulugang expose ang isang CPU model na may flag na ito. Ang guest na umaasa sa mga CPU feature na iyon ay hindi maaaring i-migrate nang ligtas sa isang machine na walang ganoong CPU features. Ang host na naglilipat ng mga customer sa ibang nodes ay mawawalan ng kakayahang ito kapag i-enable ang nesting.
• Attack surface. Ang mga nested VMX/SVM path ay kabilang sa pinakakomplikadong code sa virtualization layer ng kernel, at mayroon itong kasaysayan ng mga CVE.
• Maaaring hindi KVM ang L0. Kung ang systemd-detect-virt ay nag-print ng vmware, xen, o microsoft, ang nesting rules ay sa stack na iyon, hindi sa KVM.

Walang flag sa iyong instance? Magtanong sa support (ang iba ay ina-enable ito per-VM), pumili ng plan na may dokumentasyon para sa nesting, o lumipat sa isang dedicated box. Ang natitirang bahagi ng tutorial na ito ay nag-a-assume na may root access ka sa isang machine na nagpapakita ng flag.

Pagpapatakbo ng L2 guest gamit ang libvirt

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'

Hindi kailangan ang graphical session. Matagal ang serial install, kaya simulan ito sa loob ng isang persistent shell: ang tmux workflow na nagpapanatili sa Claude Code sessions na buhay sa VPS ay nagpapanatili ng virt-install console kahit maputol ang SSH connection. Kung ma-reject ang --os-variant debian13, masyadong luma ang iyong osinfo-db — patakbuhin ang osinfo-query os at pumili ng pangalang umiiral na. I-forward ng --cpu host-passthrough ang vmx papunta sa L2; kailangan lang ito kung kailangang mag-virtualize ng L2. Gawing boot-safe ang guest gamit ang virsh autostart guest1.

Ang virtio bus sa disk at NIC ay hindi dekorasyon: mas madalas mag-trap sa hypervisor ang emulated IDE at e1000 devices kumpara sa virtio queues, at sa ilalim ng nesting, ang bawat trap ay may dobleng gastos.

Networking: ang bahaging madalas laktawan sa mga tutorial

Ang VPS mo ay may isang public IP at nasa likod ng isang fabric na nagfi-filter ng mga unknown MAC addresses. May dalawang epekto nito.

Hindi karaniwang gagana ang pag-bridge ng L2 guests sa public network. Kapag inilagay mo ang br0 sa public NIC at binigyan ang guest ng sariling MAC, makikita mong maglalabas ng ARP pero walang babalik — i-do-drop ng switch ng provider ang mga frame mula sa isang MAC na hindi naman naka-lease sa iyo. Kung ito ang nararanasan mong symptom, huwag nang i-debug ang bridge; ito ang mismong mechanism.

Gamitin ang NAT network sa halip. Kasama sa libvirt ang default: virbr0, 192.168.122.0/24, at dnsmasq leases, kaya gagana agad ang outbound connection. Para sa inbound, i-terminate ang TLS sa L1 at i-proxy ito — ang mga certificate paths sa ibaba ay mula sa pag-issue ng Let's Encrypt certificate gamit ang Certbot sa 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;
    }
}

Bigyan muna ang guest ng static lease (virsh net-edit default) para hindi magbago ang address sa proxy_pass na iyon.

Ang mga management interface ay dapat manatiling offline sa internet: ang VNC sa 5900 at ang Proxmox web UI sa 8006 ay dapat nasa loopback, na ina-access via SSH tunnel (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) o sa pamamagitan ng self-hosted WireGuard VPN papunta sa VPS, na naglalagay sa buong 192.168.122.0/24 guest range sa isang private hop lang ang layo. Panatilihing limitado ang firewall — sudo ufw allow 22,80,443/tcp, wala nang iba. Kung nawalan ng outbound connectivity ang mga guest pagkatapos i-enable ang ufw, ang karaniwang sanhi ay DEFAULT_FORWARD_POLICY="DROP" sa /etc/default/ufw — i-set ito sa ACCEPT at i-reload ang ufw.

Proxmox sa isang VPS

Ang Proxmox VE 9 ay nakabase sa Debian 13. Maaari itong i-install sa isang Debian VPS sa pamamagitan ng pagdagdag ng pve-no-subscription repository at ng proxmox-ve package. Gamitin ang repository at keyring lines mula sa official documentation ng Proxmox — magdudulot ng error sa install kung ang URL ay galing sa lumang blog post.

Hindi mahirap ang pag-install ng mga package. Ang Proxmox ay nangangailangan ng vmbr0 na naka-bridge sa isang physical NIC, na magreresulta sa MAC-filtering error na nabanggit sa itaas. Ang configuration na gumagana sa VPS ay isang NAT'd o routed vmbr0 na walang nakakabit na physical port. Ang mga guest ay dapat nasa private range, at gumamit ng DNAT rules o reverse proxy sa host para sa anumang public service. Kung ang mga public-facing services ay mga container sa halip na VM, ang Traefik fronting multiple apps from one Docker Compose file ay kayang gawin ang parehong routing job na may automatic certificates. Mag-snapshot muna ng /etc/network/interfaces: ang maling bridge definition ay maaaring mag-lock sa access sa machine kung wala kang console access.

Performance, stated honestly

Mas mabagal ang Nested kaysa sa single-level. Ang dahilan ay hindi ang memory access, kundi ang mga exit: ang cost ay nasa exits. Dahil may EPT/NPT, gumagamit ang L0 ng shadow page tables para sa L2, kaya ang ordinaryong memory reads ay tumatakbo sa hardware speed. Nagiging mahal ang bawat operation na lumalabas sa guest mode — I/O, timer interrupts, MMIO, at inter-processor interrupts — dahil ang L2 exit ay hinahawakan ng L0 at maaaring bumalik sa pamamagitan ng L1. Ang CPU-bound work sa data na nasa RAM na ay halos katulad ng native; ang anumang trabahong maraming syscalls, packets, at disk I/O ay ramdam ang epekto ng mga layers.

Kaya: gumamit ng virtio devices sa lahat ng dako. Ang iyong qcow2 file ay nasa disk na virtualized na ng provider — dalawang thin-provisioning layers ang nakasalansan, kung saan ang cache=none sa guest disk ay pinipigilan ang parehong blocks na nasa dalawang page cache nang sabay. Walang benchmark numbers dito: sukatin ang sarili mong workload sa sarili mong instance.

Failure modes, at ang mga strings na makikita mo

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used mula sa kvm-ok. Maaaring hindi loaded ang module, o hindi exposed ang flag. I-check muna ang /proc/cpuinfo.

kvm: disabled by bios sa dmesg. Sa bare metal, i-on ang VT-x/SVM toggle sa firmware. Sa loob ng VPS, ibig sabihin nito ay hindi ibinibigay ng L0 ang mga extensions, at walang magagawa ang anumang i-type sa guest.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. Ang CPU na nakikita ng kernel ay walang vmx — isa itong desisyon ng L0.

Could not access KVM kernel module: Permission denied. Permissions ang problema, hindi hardware. Dapat ipakita ng ls -l /dev/kvm ang group na kvm at mode na 660; i-add ang sarili sa group na iyon at mag-start ng bagong login shell, dahil hindi awtomatikong nag-a-apply ang group membership sa kasalukuyang session.

kvm: Device or resource busy kapag nag-start ang QEMU. May ibang hypervisor module na gumagamit ng CPU: i-run ang lsmod, hanapin ang vboxdrv o VMware modules kasama ang kvm_intel, at i-unload ang hindi kailangan.

/var/run/libvirt/libvirt-sock: No such file or directory mula sa virsh. Down ang daemon: sudo systemctl enable --now libvirtd.

Proxmox: KVM virtualisation configured, but not available. May guest na naka-tick ang KVM acceleration sa host na hindi ito kayang ibigay. Ayusin ang nesting, o i-untick ito at tanggapin ang emulation.

Android emulator: x86_64 emulation currently requires hardware acceleration! /dev/kvm muli — kadalasan ay dahil sa group.

Walang error, pero napakabagal ng lahat. Kapag walang accelerator flag ang QEMU, gagamitin nito ang TCG, ang software emulator nito. Tama ang configuration pero mabagal — ang boot na dating seconds ay magiging minutes. I-pass ang -accel kvm nang direkta para mag-error ang QEMU sa halip na tahimik na mag-emulate.

Biglang nawawala ang guest habang tumatakbo. I-check ang dmesg para sa Out of memory: Killed process ... qemu-system-x86_64. Ang L2 guest ay isang process sa L1, at ituturing ito ng OOM killer na parang kahit anong ibang process. Ang RAM ng L2 ay galing sa fixed allocation ng L1 — walang pwedeng hiramin mula sa host.

Operating it: backups, upgrades, limits

Backups. Ang pagkopya ng qcow2 ng isang running guest ay magreresulta sa corrupt na image. Gamitin ang virsh shutdown guest1 at i-copy, o kaya ay kumuha ng external snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) para ang mga writes ay mapunta sa isang overlay habang kinokopya ang static base, pagkatapos ay i-fold ito pabalik gamit ang virsh blockcommit. I-transfer ang mga kopya palabas ng VPS — ang snapshot sa parehong disk ay walang proteksyon.

Upgrades. Nag-i-install ang apt full-upgrade ng mga bagong kvm_intel/kvm_amd modules, pero mananatili ang lumang modules sa running kernel hanggang sa mag-reboot ka. Panatilihing installed ang nakaraang kernel at i-run muli ang kvm-ok pagkatapos ng bawat kernel change: ang host na bumalik nang walang vmx ay isang boot entry na lang ang layo para muling gumana.

Where this stops scaling. Ang isang public IP ay nangangahulugang ang bawat L2 service ay dadaan sa proxy o DNAT rule sa L1 para maabot ang mundo. Hindi available ang live migration. Sa ilalim ng CPU contention, ang nested exit path ang unang makakaranas ng slowdown. Ang hypervisor na may maraming guests ay isang machine na ubos na ang RAM — hindi makaka-overcommit ang mga nested VM para malampasan ang fixed allocation. Kapag lumampas na ang isang lab sa limitasyong ito, ang solusyon ay hindi mas mataas na nested stack; ito ay isang dedicated box kung saan ikaw ang L0 at hindi na applicable ang lahat ng ito.

FAQ

Kailangan ko ba ng nested virtualization para magpatakbo ng Docker sa VPS?

Hindi. Ibinabahagi ng mga container ang kernel ng iyong VPS at hindi kailanman nagbubukas ng /dev/kvm. Dahil dito, gumagana nang maayos ang Docker at Docker Compose sa isang plain instance na walang vmx o svm flag. Ang nesting ay mahalaga lamang kung kailangan mo ng pangalawang kernel: gaya ng Proxmox lab, Windows guest, Firecracker microVMs, Android emulator, o mga CI runner na nagbo-boot ng mga VM image.

Paano ko malalaman kung ang VPS ko ay may suporta para sa nested virtualization?

I-run ang grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, pagkatapos ay kvm-ok mula sa cpu-checker package. Ang isang usable na instance ay magpi-print ng vmx (Intel) o svm (AMD), mag-uulat ang kvm-ok ng KVM acceleration can be used, at ang /dev/kvm ay mag-e-exist sa grupong kvm at mode na 660. Huwag pansinin ang /sys/module/kvm_intel/parameters/nested para sa tanong na ito — inilalarawan ng file na iyon ang sarili mong KVM module, hindi ang ibinigay ng hypervisor ng provider sa iyo.

Bakit madalas i-disable ng mga VPS provider ang nested virtualization?

Ang pag-expose ng vmx ay nangangahulugang binibigyan ang guest ng CPU model na may flag na iyon. Ang isang guest na umaasa sa mga CPU feature na iyon ay hindi maaaring i-live-migrate sa isang machine na walang ganoong CPU — kaya isinusuko ito ng mga provider na naglilipat ng mga customer sa iba't ibang nodes. Ang mga nested VMX/SVM code path ay mayroon ding mahabang kasaysayan ng mga CVE. May ilang host na nag-e-enable nito per-VM kapag may request, at ang iba naman ay itinuturing ang nesting bilang isang plan feature.

Walang network ang aking nested VM sa public bridge. Ano ang mali?

I-drop ng switch ng provider ang mga frame mula sa isang MAC address na hindi naman naka-lease sa iyo. Dahil dito, ang isang L2 guest na naka-bridge sa public NIC ay magpapadala ng ARP ngunit walang matatanggap na sagot. Itigil ang pag-debug sa br0 — gamitin ang NAT default network ng libvirt (virbr0, 192.168.122.0/24), bigyan ang guest ng static lease, at i-publish ang anumang public service sa pamamagitan ng reverse proxy o DNAT rule sa mismong VPS.

Gaano kabagal ang isang nested VM?

Ang epekto ay nasa VM exits, hindi sa memory access. Kapag active ang EPT/NPT, ang mga ordinaryong read at write sa loob ng L2 ay tumatakbo sa hardware speed, habang ang I/O, timer interrupts, MMIO, at IPIs ay hinahawakan ng L0 at maaaring bumalik sa pamamagitan ng L1. Ang CPU-bound na trabaho sa data na nasa RAM na ay halos katulad ng native; ang mga workload na heavy sa syscall, packet, at disk ay ramdam ang bawat layer. Gumamit ng virtio devices sa lahat ng dako at cache=none sa mga guest disk, pagkatapos ay i-measure ang sarili mong workload.