Je, unaweza kuendesha Proxmox kwenye VPS?

Jibu fupi

Virtualization ya ndani (nested virtualization) ni hypervisor inayojiendesha ndani ya mashine ya kiprogramu (virtual machine): VPS yako tayari ni mgeni, na unataka iweke wenyeji wa wageni wengine. Inafanya kazi tu wakati hypervisor ya mtoa huduma wako inapotoa kwa makusudi uwezo wa virtualization wa CPU kwa instance yako — angalia /proc/cpuinfo kwa flag ya vmx (Intel) au svm (AMD), na ikiwa hakuna inayojitokeza, hakuna kitu utachokisanidi ndani ya VPS kitakachosaidia.

Angalizo la kwanza: Docker haihitaji lolote kati ya haya. Container zinashiriki kernel ya VPS yako na hazigusi /dev/kvm kamwe. Ikiwa lengo lako kuu ni "kuendesha huduma kadhaa kwenye container kwenye seva yangu", tayari unacho unachohitaji. Nesting ni muhimu unapotaka kernel ya pili — maabara ya Proxmox, mgeni wa Windows, microVM za Firecracker, emulator ya Android, mazingira ya majaribio ya Kubernetes ya VM halisi, au CI runners zinazozindua picha za VM.

Kinachofanyika ndani ya nesting

Tabaka tatu:

• L0 — hypervisor ya mtoa huduma, kwenye chuma (metal). Huna ufikiaji wake.
• L1 — VPS yako. Kwa L0, hii ni guest tu.
• L2 — VM unayotaka kuendesha ndani ya VPS yako.

Virtualization ya hardware ni VT-x (flag ya vmx) pamoja na EPT kwenye Intel, na AMD-V / SVM (svm) pamoja na RVI/NPT kwenye AMD. Hypervisor hutumia maelekezo hayo kuingia kwenye guest mode na kuruhusu CPU kupitia page tables mbili kwa wakati mmoja.

Hakuna iliyoundwa kwa ajili ya re-entrancy, hivyo nesting huigwa (emulated): L1 inapotekeleza VMX instruction, inatuma signal (trap) kwa L0, ambayo inadhibiti shadow structures kwa ajili ya L2 kwa niaba ya L1. KVM hufanya hivi vizuri, lakini L0 inafanya kazi ya ziada kwenye kila exit — ndiyo maana mtoa huduma lazima kuitumia kwa hiari.

Masharti mawili lazima yatimizwe kwa L2 yenye acceleration:

1. Moduli ya KVM ya L0 imepakiwa ikiwa na nested=1.
2. L0 inakupa VPS yenye CPU model inayobeba flag hiyo — <cpu mode='host-passthrough'/> kwenye libvirt, cpu: host kwenye Proxmox, na -cpu host kwenye raw QEMU. Model ya kawaida ya emulated (qemu64, kvm64) huficha vmx hata kama nesting imewashwa kimuundo (globally).

Check your VPS in one minute

# 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

A usable instance prints vmx or svm, kvm-ok says KVM acceleration can be used, and /dev/kvm exists as root:kvm mode 660. If the flag is there but the device node is not, load the module by hand and read the kernel log:

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

One file gets quoted constantly and is widely misread:

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

Inside your VPS that is the setting of your KVM module, and it governs whether an L2 guest could nest a third level. It says nothing about whether L0 enabled nesting for you — /proc/cpuinfo and kvm-ok answer that. The nested parameter is the knob you set on a machine you own outright:

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

Module removal is refused while a VM is running, so shut guests down first.

Kwa nini wasimamizi wengi wa VPS huacha ikiwa imezimwa

• Live migration. Kukupea vmx kunamaanisha kuonyesha aina ya CPU yenye flag hiyo. Guest inayotegemea vipengele hivyo vya CPU haiwezi kuhamishwa kwa usalama kwenye mashine ambayo CPU yake haina vipengele hivyo. Host inayohamisha wateja ili kupunguza mzigo kwenye node hupoteza uwezo huo mara tu inapowasha nesting.
• Attack surface. Njia za nested VMX/SVM ni miongoni mwa kodi tata zaidi kwenye tabaka la virtualization la kernel, na zina historia ya CVE.
• L0 inaweza isiwe KVM. Ikiwa systemd-detect-virt inaonyesha vmware, xen au microsoft, sheria za nesting ni za stack hiyo, si za KVM.

Je, huna flag kwenye instance yako? Waombe support (baadhi huwasha kwa kila VM), chagua mpango unaoelezea nesting, au hamia kwenye mashine ya dedicated. Sehemu inayofuata inachukulia kuwa una root kwenye mashine inayonyesha flag hiyo.

Kuendesha L2 guest kwa kutumia 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'

Hakuna kikao cha graphical kinachohitajika. Usakinishaji wa serial huchukua muda, hivyo anza ndani ya shell inayodumu: mchakato wa tmux unaofanya Claude Code sessions ziendelee kuishi kwenye VPS ule ule huunganisha console ya virt-install hata kama muunganisho wa SSH unakatika. Ikiwa --os-variant debian13 inakataliwa, osinfo-db yako ni ya kabla ya toleo hili — run osinfo-query os na uchague jina lililopo. --cpu host-passthrough hufanya forwarding ya vmx hadi ndani ya L2, inayohitajika tu ikiwa L2 inapaswa kufanya virtualization. Fanya guest iwe salama wakati wa kuwaka kwa kutumia virsh autostart guest1.

Bus ya virtio kwenye disk na NIC si mapambo: vifaa vya emulated IDE na e1000 hufanya trap kwenye hypervisor mara nyingi zaidi kuliko virtio queues, na chini ya nesting kila trap inalipiwa mara mbili.

Networking: sehemu ambayo mafunzo hupuuza

VPS yako ina IP moja ya umma na ipo nyuma ya mfumo unaochuja anwani za MAC zisizojulikana. Hii ina matokeo mawili.

Kuunganisha wageni wa L2 kwenye mtandao wa umma kwa kutumia bridging mara nyingi hakutafanya kazi. Weka br0 kwenye NIC ya umma, mpe mgeni anwani yake ya MAC, na utaona ARP ikitoka lakini hakuna kinachorudi — switch ya mtoa huduma inatupa paketi kutoka kwa MAC ambayo haikupewa. Ikiwa huu ndio tatizo lako, acha kutatua hitilafu kwenye bridge; huu ndio utaratibu.

Tumia mtandao wa NAT badala yake. libvirt inakuja na default: virbr0, 192.168.122.0/24, na upangaji wa dnsmasq, na mawasiliano ya nje hufanya kazi mara moja. Kwa mawasiliano ya ndani, malizia TLS kwenye L1 na tumia proxy — njia za cheti hapa chini zinatoka kwenye kutoa cheti cha Let's Encrypt kwa kutumia Certbot kwenye 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;
    }
}

Mpe mgeni upangaji wa kudumu (virsh net-edit default) ili anwani katika proxy_pass hiyo ibaki vilevile.

Interface za usimamizi hazipo kwenye internet: VNC kwenye 5900 na Proxmox web UI kwenye 8006 zinapaswa kuwa kwenye loopback, zinapatikana kupitia SSH tunnel (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) au kupitia WireGuard VPN inayojihosti ndani ya VPS, ambayo inaweka mfululizo mzima wa wageni wa 192.168.122.0/24 katika hatua moja ya ndani. Weka firewall iwe nyembamba — sudo ufw allow 22,80,443/tcp, hakuna kingine. Ikiwa wageni wanapoteza mawasiliano ya nje mara tu baada ya kuwasha ufw, chanzo cha kawaida ni DEFAULT_FORWARD_POLICY="DROP" katika /etc/default/ufw — iweke kuwa ACCEPT na uweke upya ufw.

Proxmox kwenye VPS

Proxmox VE 9 inatumia Debian 13, hivyo inafungwa kwenye Debian VPS kwa kuongeza repository ya pve-no-subscription na package ya proxmox-ve. Chukua mistari ya repository na keyring kutoka kwenye hati rasmi ya Proxmox — URL iliyochukuliwa kutoka kwenye blogu ya zamani itaharibu ufungaji.

Package siyo sehemu ngumu. Proxmox inahitaji vmbr0 iliyounganishwa na NIC ya kimwili, jambo ambalo linasababisha tatizo la MAC-filtering lililotajwa hapo juu. Njia inayofanya kazi kwenye VPS ni vmbr0 ya NAT au routed bila port ya kimwili, wageni (guests) kwenye mtandao wa ndani (private range), na sheria za DNAT au reverse proxy kwenye host kwa ajili ya huduma za nje. Pale ambapo huduma za nje ni container badala ya VM, Traefik inayofunika apps nyingi kutoka Docker Compose file moja inafanya kazi hiyo hiyo ya routing kwa kutumia vyeti (certificates) vya kiotomatiki. Fanya snapshot ya /etc/network/interfaces kwanza: utafungwa nje ya mashine ikiwa utafanya makosa kwenye utambulisho wa bridge na huenda usipate console.

Utendaji, kwa ukweli

Nested ni ya polepole kuliko single-level, na mchakato wake ni mahususi badala ya kuwa wa jumla: gharama kubwa haitokani na upatikanaji wa memory, bali inatokana na exits. Kwa uwepo wa EPT/NPT, L0 inatunza shadow page tables kwa ajili ya L2 na usomaji wa kawaida wa memory hufanyika kwa kasi ya hardware. Kitu kinachochukua muda ni kila operesheni inayotoka kwenye guest mode — I/O, timer interrupts, MMIO, inter-processor interrupts — kwa sababu L2 exit inashughulikiwa na L0 na inaweza kurudishwa kupitia L1. Kazi inayotegemea CPU juu ya data iliyopo kwenye RAM inaonekana kama native; chochote kinachotawaliwa na syscalls, packets na disk I/O kinahisi tabaka hizo.

Kwa hivyo: tumia virtio devices kila mahali. Na faili yako ya qcow2 inaishi kwenye disk ambayo mtoa huduma ameshaifanya kuwa virtual — tabaka mbili za thin-provisioning zimepangiwa, ambapo cache=none kwenye guest disk inazuia blocks zilezile kukaa kwenye page caches mbili kwa wakati mmoja. Hakuna namba za benchmark hapa: pima mzigo wako wa kazi kwenye instance yako mwenyewe.

Njia za kushindili, na maandishi utakayoyaona

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used kutoka kvm-ok. Moduli haijapakia, au flag haijawekwa wazi. Angalia /proc/cpuinfo kwanza.

kvm: disabled by bios katika dmesg. Kwenye bare metal, washa sehemu ya VT-x/SVM kwenye firmware. Ndani ya VPS, inamaanisha L0 haikupi extensions, na chochote unachojaza kwenye guest hakibadilishi hali hiyo.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. CPU ambayo kernel inaiona haina vmx — tena, ni uamuzi wa L0.

Could not access KVM kernel module: Permission denied. Ni masuala ya ruhusa, siyo hardware. ls -l /dev/kvm inapaswa kuonyesha group kvm, mode 660; jiunge kwenye group hiyo na ufungue login shell mpya, kwa sababu uanachama wa group haitumiki kwenye session inayokwenda tayari.

kvm: Device or resource busy wakati QEMU inapoanza. Hypervisor nyingine imeshikilia CPU: run lsmod, tafuta vboxdrv au VMware modules pamoja na kvm_intel, kisha pakua (unload) ile usiyoitaka.

/var/run/libvirt/libvirt-sock: No such file or directory kutoka virsh. Daemon imezimika: sudo systemctl enable --now libvirtd.

Proxmox: KVM virtualisation configured, but not available. Guest ina KVM acceleration iliyowashwa kwenye host ambayo haiwezi kuitoa. Rekebisha nesting, au izime na ukubali emulation.

Android emulator: x86_64 emulation currently requires hardware acceleration! /dev/kvm tena — mara nyingi ni suala la group.

Hakuna kosa lolote, na kila kitu kinaenda kwa mwendo wa mwendo wa konde. QEMU bila accelerator flag hutumia TCG, emulator yake ya programu. Inafanya kazi vizuri lakini ni polepole — kuwaka kwa sekunde kunakuwa dakika. Pass -accel kvm waziwazi, ili QEMU iache kwa kutoa kosa badala ya kuendelea na emulation kimya kimya.

Guest inapotea katikati ya utendaji. Angalia katika dmesg kwa ajili ya Out of memory: Killed process ... qemu-system-x86_64. Guest ya L2 ni process kwenye L1, na OOM killer inaichukulia kama process nyingine yoyote. RAM ya L2 inatoka kwenye allocation ya L1 — haina uwezo wa kuazima kutoka kwenye host.

Uendeshaji: backups, upgrades, limits

Backups. Kunakili faili ya qcow2 wakati guest inafanya kazi itasababisha picha (image) kuharibika. Tumia virsh shutdown guest1 na unakili, au chukua snapshot ya nje (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) ili maandishi yaandikwe kwenye overlay wakati unanakili faili ya msingi iliyo tuli, kisha rudisha kwa kutumia virsh blockcommit. Hakikisha nakala zinatumwa nje ya VPS — snapshot kwenye diski hiyo hiyo haitoi ulinzi wowote.

Upgrades. apt full-upgrade husakinisha moduli mpya za kvm_intel/kvm_amd, lakini kernel inayofanya kazi itaendelea kutumia zile za zamani hadi utakapowasha upya (reboot). Weka kernel ya awali ikiwa imesakinishwa na urudie kvm-ok baada ya kila mabadiliko ya kernel: host inayorejea bila vmx itakuwa na uwezo wa kufanya kazi tena kupitia ingizo moja la boot.

Mipaka ya ufanisi. IP moja ya umma inamaanisha kila huduma ya L2 inafikia ulimwengu kupitia proxy au sheria ya DNAT kwenye L1. Live migration haipatikani. Wakati wa msongamano wa CPU, njia ya nested exit ndiyo itakayohisi athari kwanza. Na hypervisor yenye guest kadhaa ni mashine ambayo RAM yake tayari imetumika — nested VMs haziwezi kutumia overcommit ili kuvuka mpangilio maalum wa rasilimali. Lab inapozidi uwezo huo, jibu si kuongeza matabaka ya nested; jibu ni mashine maalum ambapo wewe ni L0 na mambo haya hayatumiki.

FAQ

Do I need nested virtualization to run Docker on a VPS?

No. Containers share your VPS kernel and never open /dev/kvm, so a plain instance with no vmx or svm flag runs Docker and Docker Compose fine. Nesting only matters when you want a second kernel: a Proxmox lab, a Windows guest, Firecracker microVMs, an Android emulator, or CI runners that boot VM images.

How do I check whether my VPS supports nested virtualization?

Run grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, then kvm-ok from the cpu-checker package. A usable instance prints vmx (Intel) or svm (AMD), kvm-ok reports KVM acceleration can be used, and /dev/kvm exists with group kvm and mode 660. Ignore /sys/module/kvm_intel/parameters/nested for this question — that file describes your own KVM module, not what the provider's hypervisor exposed to you.

Why do most VPS providers disable nested virtualization?

Exposing vmx means handing the guest a CPU model that carries the flag, and a guest that depends on those CPU features cannot be live-migrated onto a machine whose CPU lacks them — a provider that drains nodes by moving customers around gives that up. The nested VMX/SVM code paths also carry a long CVE history. Some hosts still enable it per-VM on request, and others document nesting as a plan feature.

My nested VM has no network on the public bridge. What is wrong?

The provider's switch drops frames from a MAC address it never leased you, so an L2 guest bridged onto the public NIC sends ARP and hears nothing back. Stop debugging br0 — use libvirt's NAT default network (virbr0, 192.168.122.0/24), give the guest a static lease, and publish anything public through a reverse proxy or DNAT rule on the VPS itself.

How much slower is a nested VM?

The cost lands on VM exits, not on memory access. With EPT/NPT active, ordinary reads and writes inside L2 run at hardware speed, while I/O, timer interrupts, MMIO and IPIs are handled by L0 and may be bounced back through L1. CPU-bound work over data already in RAM looks close to native; syscall-, packet- and disk-heavy workloads feel every layer. Use virtio devices everywhere and cache=none on guest disks, then measure your own workload.