Maaari bang Magpatakbo ng Proxmox sa VPS?

Ang maikling sagot

Ang nested virtualization ay isang hypervisor na tumatakbo sa loob ng virtual machine: guest na ang iyong VPS, at gusto mo itong mag-host ng sarili nitong mga guest. Gumagana lamang ito kapag sadyang inilalantad ng hypervisor ng provider ang virtualization extensions ng CPU sa iyong instance. Tingnan ang /proc/cpuinfo para sa vmx flag (Intel) o svm (AMD). Kung wala ang alinman sa mga ito, walang configuration sa loob ng VPS ang makapag-aayos nito.

Una, linawin natin ang isang mahalagang expectation: Hindi kailangan ng Docker ang alinman dito. Ibinabahagi ng mga container ang kernel ng iyong VPS at hindi kailanman gumagamit ng /dev/kvm. Kung ang tunay na layunin ay “magpatakbo ng maraming serbisyo sa mga container sa server ko,” mayroon ka na ng kailangan mo. Mahalaga ang nesting kapag kailangan mo ng ikalawang kernel, Proxmox lab, Windows guest, Firecracker microVMs, Android emulator, Kubernetes testbed ng mga aktuwal na VM, o CI runners na nagbo-boot ng mga VM image.

Ano talaga ang naka-nest

Tatlong layer:

• L0, ang hypervisor ng provider na tumatakbo sa physical server. Wala kang access dito.
• L1, ang VPS mo. Para sa L0, guest lamang ito.
• L2, ang VM na gusto mong patakbuhin sa loob ng VPS mo.

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

Hindi idinisenyo ang alinman sa mga ito para sa re-entrant na paggamit, kaya ine-emulate ang nesting: kapag nag-execute ang L1 ng VMX instruction, nagta-trap ito sa L0. Pinapanatili naman ng L0 ang shadow structure para sa L2 sa ngalan ng L1. Mahusay itong ginagawa ng KVM, pero ang L0 ang nagsasagawa ng karagdagang trabaho sa bawat exit. Kaya kailangang i-enable ito ng provider.

Dapat parehong matugunan ang dalawang kondisyon para sa accelerated na L2:

1. Naka-load ang KVM module ng L0 gamit ang nested=1.
2. Binibigyan ng L0 ang VPS mo ng CPU model na may ganitong flag: <cpu mode='host-passthrough'/> sa libvirt, cpu: host sa Proxmox, at -cpu host sa raw QEMU. Itinatago ng generic na emulated model (qemu64, kvm64) ang vmx kahit globally enabled ang nesting.

Suriin 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 gumaganang instance ay naglalabas ng vmx o svm, ang kvm-ok ay nagsasabing KVM acceleration can be used, at umiiral ang /dev/kvm na may root:kvm mode na 660. Kung naroon ang flag pero wala ang device node, i-load nang manual ang module at basahin ang kernel log:

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

May isang file na palaging binabanggit at madalas na mali ang pagbasa:

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

Sa loob ng iyong VPS, setting ito ng iyong KVM module. Tinutukoy nito kung maaaring mag-nest ang isang L2 guest ng ikatlong level. Wala itong sinasabi kung pinagana ng L0 ang nesting para sa iyo. /proc/cpuinfo at kvm-ok ang sumasagot dito. Ang nested parameter ang itinatakda mo sa machine na ganap mong pagmamay-ari:

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

Tinatanggihan ang pag-remove ng module habang tumatakbo ang isang VM, kaya i-shut down muna ang mga guest.

Bakit karaniwang naka-off ito sa karamihan ng VPS host

• Live migration. Ang pagbibigay sa iyo ng vmx ay nangangahulugang inilalantad ang CPU model na may ganitong flag. Ang guest na nakadepende sa mga CPU feature na ito ay hindi ligtas na mai-migrate sa machine na walang mga ito. Kapag nagda-drain ng node ang isang host sa pamamagitan ng pagmi-migrate ng mga customer, nawawala ang opsyong iyon sa sandaling i-enable nito ang nesting.
• Attack surface. Ang nested VMX/SVM path ay kabilang sa mga pinakamasalimuot na bahagi ng code sa virtualization layer ng kernel, at makikita ito sa kasaysayan ng mga CVE.
• Maaaring hindi KVM ang L0. Kung nagpi-print ang systemd-detect-virt ng vmware, xen, o microsoft, ang mga panuntunan sa nesting ay nakadepende sa virtualization stack na iyon, hindi sa KVM.

Walang flag sa iyong instance? Makipag-ugnayan sa support; may ilang provider na nag-e-enable nito per-VM. Maaari ka ring pumili ng plan na may dokumentadong suporta sa nesting o lumipat sa dedicated box. Ipinapalagay ng mga susunod na hakbang na may root access ka sa 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 ng graphical session. Matagal ang serial install, kaya simulan ito sa loob ng persistent shell: ang parehong tmux workflow na nagpapanatiling buhay sa mga Claude Code session sa isang VPS ay nagpapanatili ng virt-install console kahit maputol ang SSH connection. Kung rejected ang --os-variant debian13, mas luma ang osinfo-db kaysa sa release; patakbuhin ang osinfo-query os at pumili ng umiiral na pangalan. Ipinapasa ng --cpu host-passthrough ang vmx pababa sa L2; kailangan lamang ito kung kailangan ding magpatakbo ng virtualization ang L2. Gawing ligtas sa pag-boot ang guest gamit ang virsh autostart guest1.

Hindi dekorasyon ang virtio bus sa disk at NIC: mas madalas mag-trap sa hypervisor ang emulated IDE at e1000 devices kaysa sa virtio queues, at sa nested virtualization, dalawang beses binabayaran ang bawat trap.

Networking: ang bahaging nilalaktawan ng mga tutorial

May isang public IP ang iyong VPS at nasa likod ito ng isang fabric na nagfi-filter ng mga hindi kilalang MAC address. Dalawang resulta ang sumusunod.

Karaniwang hindi gagana ang pag-bridge ng mga L2 guest papunta sa public network. Ilagay ang br0 sa public NIC, bigyan ang guest ng sarili nitong MAC, at makikita mong lumalabas ang ARP pero walang bumabalik. Ibinabagsak ng switch ng provider ang mga frame mula sa MAC na hindi nito ipinaupa sa iyo. Kung ito ang iyong nakikitang sintomas, itigil ang pag-debug sa bridge; ito ang mekanismo.

Sa halip, gamitin ang NAT network. Kasama sa libvirt ang default: virbr0, 192.168.122.0/24, at mga lease ng dnsmasq; agad na gagana ang outbound connectivity. Para sa inbound traffic, i-terminate ang TLS sa L1 at i-proxy papasok. Ang mga path ng certificate 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;
    }
}

Magtakda muna ng static lease para sa guest (virsh net-edit default) upang manatiling pareho ang address sa proxy_pass.

Huwag ilantad sa internet ang mga management interface: dapat nasa loopback ang VNC sa 5900 at ang Proxmox web UI sa 8006. I-access ang mga ito gamit ang 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 isang private hop ang layo. Panatilihing makitid ang firewall: sudo ufw allow 22,80,443/tcp, at wala nang iba. Kung mawawalan ng outbound connectivity ang mga guest agad pagkatapos mong i-enable ang ufw, ang karaniwang sanhi ay DEFAULT_FORWARD_POLICY="DROP" sa /etc/default/ufw. Itakda ito sa ACCEPT at i-reload ang ufw.

Proxmox sa isang VPS

Ang Proxmox VE 9 ay Debian 13 sa ilalim, kaya ini-install ito sa isang Debian VPS sa pamamagitan ng pagdaragdag ng pve-no-subscription repository at proxmox-ve package. Kunin ang mga repository at keyring line mula sa kasalukuyang opisyal na documentation ng Proxmox. Kapag URL mula sa lumang blog post ang kinopya, maaaring mabigo ang installation. Dapat munang pagpasiyahan kung ang Proxmox ay angkop ba talaga sa rented hardware bago gugulin ang isang gabi sa networking configuration sa ibaba. Ang paghahambing ng gastos at kakayahan ng Proxmox box sa bahay at rented VPS ang bersyon ng tanong na ito na may nakahandang pagsusuri sa power at hardware requirements.

Hindi ang packages ang mahirap na bahagi. Inaasahan ng Proxmox na naka-bridge ang vmbr0 sa isang physical NIC, na direktang humahantong sa MAC-filtering dead end sa itaas. Ang gumaganang setup sa isang VPS ay isang NAT'd o routed na vmbr0 na walang nakakabit na physical port, may mga guest sa private range, at may DNAT rules o reverse proxy sa host para sa anumang public service. Kung containers ang mga public-facing service sa halip na VMs, sinasaklaw ng Traefik na nagfa-front ng maraming app mula sa isang Docker Compose file ang parehong routing task at awtomatiko nitong pinamamahalaan ang certificates. Gumawa muna ng snapshot ng /etc/network/interfaces. Kapag mali ang bridge definition, maaari kang mawalan ng access sa machine na maaaring wala kang console access.

Pagganap, inilahad nang tapat

Mas mabagal ang nested kaysa single-level, at tiyak ang pinagmumulan ng overhead: hindi memory access ang pangunahing nagkakahalaga; exits ang dahilan. Kapag available ang EPT/NPT, pinapanatili ng L0 ang shadow page tables para sa L2 at tumatakbo sa hardware speed ang mga karaniwang memory read. Nagiging magastos ang bawat operation na lumalabas sa guest mode—I/O, timer interrupts, MMIO, at inter-processor interrupts—dahil hina-handle ng L0 ang L2 exit at maaari itong i-reflect pabalik sa L1. Ang CPU-bound na trabaho sa data na nasa RAM na ay halos native ang performance; pero ramdam ang mga layer sa workload na pangunahing nakadepende sa syscalls, packets, at disk I/O.

Kaya: gumamit ng virtio devices sa lahat ng kailangan. Nasa disk na na-virtualize na ng provider ang iyong qcow2 file, kaya may dalawang thin-provisioning layer na magkapatong; dito, cache=none sa guest disk ang pumipigil na sabay na mapunta ang parehong blocks sa dalawang page cache. Walang benchmark numbers dito: sukatin ang sarili mong workload sa sarili mong instance.

Mga failure mode at mga string na makikita mo

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used mula sa kvm-ok. Maaaring hindi naka-load ang module o hindi naka-expose ang flag. Suriin muna ang /proc/cpuinfo.

kvm: disabled by bios sa dmesg. Sa bare metal, i-enable ang VT-x/SVM toggle sa firmware. Sa loob ng VPS, nangangahulugan itong hindi ipinapasa sa iyo ng L0 ang mga extension, at walang mababago ang anumang ita-type mo sa guest.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. Walang vmx ang CPU na nakikita ng kernel mo. Muli, desisyon ito 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. Idagdag ang sarili mo sa group na iyon at magsimula ng bagong login shell, dahil hindi naa-apply ang group membership sa session na tumatakbo na.

kvm: Device or resource busy kapag nagsisimula ang QEMU. May ibang hypervisor module na gumagamit sa CPU. Patakbuhin ang lsmod, hanapin ang vboxdrv o mga VMware module kasama ng kvm_intel, at i-unload ang module na hindi mo gustong gamitin.

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

Proxmox: KVM virtualisation configured, but not available. Naka-enable ang KVM acceleration ng isang guest sa host na hindi ito kayang ibigay. Ayusin ang nesting, o i-disable ito at tanggapin ang emulation.

Android emulator: x86_64 emulation currently requires hardware acceleration! /dev/kvm muli, karaniwan ay group case ito.

Walang error, pero napakabagal ng lahat. Kapag walang accelerator flag ang QEMU, nagfa-fallback ito sa TCG, ang software emulator nito. Tama ang resulta nito pero mabagal. Ang boot na karaniwang sinusukat sa segundo ay nagiging minuto. Ibigay nang tahasan ang -accel kvm upang huminto ang QEMU na may error sa halip na tahimik na mag-emulate.

Nawawala ang guest habang tumatakbo. Tingnan ang dmesg para sa Out of memory: Killed process ... qemu-system-x86_64. Ang L2 guest ay isang process sa L1, kaya tinatrato ito ng OOM killer na parang iba pang process. Kinukuha ang L2 RAM mula sa fixed allocation ng L1; hindi ito humihiram mula sa host.

Pagpapatakbo nito: backups, upgrades, at limits

Backups. Kapag kinopya mo ang qcow2 ng guest habang tumatakbo ito, magkakaroon ka ng corrupt na image. Alinman sa virsh shutdown guest1 at kumopya, o kumuha ng external snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) upang ilihis ang mga write sa isang overlay habang kinokopya mo ang static nang base, pagkatapos ay isama itong muli gamit ang virsh blockcommit. Ilipat ang mga kopya palabas ng VPS. Walang napoprotektahan ang snapshot na nasa parehong disk.

Upgrades. Nag-i-install ang apt full-upgrade ng mga bagong kvm_intel/kvm_amd module, pero mananatiling ginagamit ng tumatakbong kernel ang mga luma hanggang mag-reboot ka. Panatilihing naka-install ang dating kernel at patakbuhin muli ang kvm-ok pagkatapos ng bawat pagbabago sa kernel. Kapag bumalik ang host nang walang vmx, isang boot entry lang ang kailangan para gumana itong muli.

Saan hindi na ito nagso-scale. Dahil iisa ang public IP, lahat ng L2 service ay kumokonekta sa mundo sa pamamagitan ng proxy o DNAT rule sa L1. Hindi kasama rito ang live migration. Kapag may CPU contention, ang nested exit path ang unang makakaranas ng epekto. Ang hypervisor na may ilang guest ay isang machine na nakalaan na ang RAM. Hindi malalampasan ng nested VM ang fixed allocation sa pamamagitan ng overcommit. Kapag lumaki na nang higit dito ang isang lab, hindi mas mataas na nested stack ang solusyon. Dedicated box ang kailangan, kung saan ikaw ang L0 at hindi naaangkop ang mga limitasyong ito.

FAQ

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

Hindi. Nakikigamit ang mga container ng kernel ng iyong VPS at hindi kailanman nagbubukas ng /dev/kvm, kaya maayos na nagpapatakbo ng Docker at Docker Compose ang isang plain instance na walang vmx o svm flag. Mahalaga lamang ang nesting kapag kailangan mo ng pangalawang kernel: isang Proxmox lab, Windows guest, Firecracker microVMs, Android emulator, o CI runners na nagbo-boot ng mga VM image.

Paano ko susuriin kung sinusuportahan ng aking VPS ang nested virtualization?

Patakbuhin ang grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, pagkatapos ay ang kvm-ok mula sa cpu-checker package. Ang usable na instance ay nagpi-print ng vmx (Intel) o svm (AMD), iniuulat ng kvm-ok ang KVM acceleration can be used, at umiiral ang /dev/kvm na may group na 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 inilantad sa iyo ng hypervisor ng provider.

Bakit dini-disable ng karamihan ng VPS provider ang nested virtualization?

Ang paglalantad ng vmx ay nangangahulugang pagbibigay sa guest ng CPU model na may ganitong flag. Hindi maaaring i-live-migrate ang guest na umaasa sa mga CPU feature na ito sa isang machine na walang mga ito. Isinasakripisyo ito ng provider na naglilipat-lipat ng mga customer sa pagitan ng mga node upang ma-drain ang mga ito. May mahaba ring kasaysayan ng CVE ang nested VMX/SVM code path. Pinapagana pa rin ito ng ilang host sa bawat-VM na request, at inililista naman ng iba ang nesting bilang feature ng plan.

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

Ibinabagsak ng switch ng provider ang mga frame mula sa MAC address na hindi nito ipinaupa sa iyo. Dahil dito, walang natatanggap na tugon ang isang L2 guest na naka-bridge sa public NIC matapos itong magpadala ng ARP. Itigil ang pag-debug sa br0. Gamitin ang NAT default network ng libvirt (virbr0, 192.168.122.0/24), magtalaga ng static lease sa guest, at i-publish ang anumang public service sa pamamagitan ng reverse proxy o DNAT rule sa mismong VPS.

Gaano kabagal ang nested VM?

Sa VM exits napupunta ang overhead, hindi sa memory access. Kapag aktibo ang EPT/NPT, tumatakbo sa hardware speed ang mga ordinaryong read at write sa loob ng L2. Samantala, pinangangasiwaan ng L0 ang I/O, timer interrupt, MMIO, at IPI, at maaaring ibalik ang mga ito sa L1. Ang CPU-bound na trabaho sa data na nasa RAM na ay halos katumbas ng native performance. Ramdam naman ng syscall-, packet-, at disk-heavy workload ang bawat layer. Gamitin ang mga virtio device sa lahat ng bahagi at cache=none sa mga guest disk, pagkatapos ay sukatin ang sarili mong workload.