Jinsi ya kuendesha Proxmox kwenye VPS kwa usahihi

Jibu fupi

Nested virtualization ni hypervisor inayofanya kazi ndani ya virtual machine: VPS yako tayari ni mgeni (guest), na unataka iweze kuhifadhi wageni wake yenyewe. Hii hufanya kazi tu pale hypervisor ya mtoa huduma wako inapofichua kwa makusudi viendelezi vya virtualization vya CPU kwenye instance yako; kagua /proc/cpuinfo kwa ajili ya flag ya vmx (Intel) au svm (AMD), na kama hakuna inayonekana, hakuna usanidi utakaofanya ndani ya VPS utakaoweza kurekebisha hilo.

Jambo moja la kuzingatia kwanza: Docker haihitaji yoyote kati ya haya. Containers hushiriki kernel ya VPS yako na hazigusi kamwe /dev/kvm. Ikiwa lengo halisi ni "kuendesha huduma kadhaa kwenye containers kwenye seva yangu", tayari unayo unayohitaji. Nesting ni muhimu pale unapotaka kernel ya pili, maabara ya Proxmox, mgeni wa Windows, Firecracker microVMs, emulator ya Android, Kubernetes testbed ya VMs halisi, au CI runners zinazowasha VM images.

Ni nini hasa kinachowekwa ndani ya kingine (nested)

Kuna matabaka matatu:

• L0, hypervisor ya mtoa huduma, iliyo kwenye maunzi (bare metal). Huna ufikiaji wowote kwake.
• L1, VPS yako. Kwa L0, hii ni mgeni (guest) tu.
• L2, mashine pepe (VM) unayotaka kuiendesha ndani ya VPS yako.

Uboreshaji wa maunzi (hardware virtualization) ni VT-x (bendera ya vmx) pamoja na EPT kwenye Intel, au AMD-V / SVM (svm) pamoja na RVI/NPT kwenye AMD. Hypervisor hutumia maelekezo hayo kuingia katika hali ya mgeni (guest mode) na kuruhusu CPU kuchakata jedwali mbili za kurasa (page tables) kwa wakati mmoja.

Hakuna hata moja iliyoundwa ili iweze kujirudia (re-entrant), kwa hivyo uwekaji wa ndani (nesting) huigwa: wakati L1 inapotekeleza maelekezo ya VMX, inanaswa na L0, ambayo hutunza miundo ya kivuli (shadow structures) kwa ajili ya L2 kwa niaba ya L1. KVM hufanya hivi vizuri, lakini ni L0 inayofanya kazi ya ziada katika kila kutoka (exit), ndiyo maana mtoa huduma lazima akubali (opt in) utendaji huu.

Masharti mawili lazima yatimie ili L2 iweze kuharakishwa (accelerated):

1. Moduli ya KVM ya L0 lazima ipakiwe na nested=1.
2. L0 lazima ipe VPS yako modeli ya CPU inayobeba bendera hiyo, <cpu mode='host-passthrough'/> katika libvirt, cpu: host katika Proxmox, -cpu host katika QEMU ya kawaida. Modeli ya jumla iliyoigwa (qemu64, kvm64) huficha vmx hata kama nesting imewashwa kimataifa.

Kagua VPS yako ndani ya dakika moja

# 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 inayoweza kutumika huchapisha vmx au svm, kvm-ok husema KVM acceleration can be used, na /dev/kvm ipo kama root:kvm katika mode 660. Ikiwa flag ipo lakini node ya kifaa haipo, pakia moduli hiyo kwa mkono na usome logi ya kernel:

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

Faili moja hunukuliwa mara kwa mara na husomwa vibaya sana:

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

Ndani ya VPS yako, huo ndio mpangilio wa moduli yako ya KVM, na hudhibiti kama mgeni wa L2 anaweza kuweka kiwango cha tatu. Haisemi chochote kuhusu kama L0 imewezesha nesting kwa ajili yako; /proc/cpuinfo na kvm-ok hujibu hilo. Parameter ya nested ndiyo kitufe unachoweka kwenye mashine unayomiliki kikamilifu:

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

Kuondoa moduli hukataliwa wakati VM inafanya kazi, kwa hivyo zima wageni (guests) kwanza.

Kwa nini watoa huduma wengi wa VPS huizima

• Live migration. Kukupa vmx inamaanisha kufichua CPU model yenye flag hiyo, na guest inayotegemea sifa hizo za CPU haiwezi kuhamishwa kwa usalama kwenda kwenye mashine ambayo CPU yake haina sifa hizo. Host anayehamaisha wateja kwa kuhamisha mashine zao (draining nodes) hupoteza uwezo huo pindi anapowasha nesting.
• Attack surface. Njia za nested VMX/SVM ni miongoni mwa sehemu tata zaidi za code katika virtualization layer ya kernel, na zina historia ya CVE zinazoendana na utata huo.
• L0 inaweza kuwa si KVM. Ikiwa systemd-detect-virt inatoa matokeo ya vmware, xen au microsoft, sheria za nesting ni za stack hiyo, si za KVM.

Huna flag kwenye instance yako? Wasiliana na support (wengine huiwasha kwa kila VM), chagua plan inayoelezea nesting, au hama kwenda kwenye dedicated box. Sehemu iliyobaki ya mwongozo huu inachukulia kuwa una root kwenye mashine inayoonyesha flag hiyo.

Kuendesha mgeni wa L2 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 haja ya session ya picha (graphical session). Ufungaji wa serial huchukua muda, kwa hivyo uanzishe ndani ya shell inayodumu: workflow ya tmux inayoweka session za Claude Code hai kwenye VPS huweka console ya virt-install ikiwa imeunganishwa hata kama muunganisho wa SSH utakatika. Ikiwa --os-variant debian13 itakataliwa, osinfo-db yako imepitwa na wakati, endesha osinfo-query os na uchague jina lililopo. --cpu host-passthrough husambaza vmx ndani ya L2, jambo linalohitajika tu ikiwa L2 lazima iweze kufanya virtualization yenyewe. Fanya mgeni awe salama wakati wa boot kwa kutumia virsh autostart guest1.

Basi la virtio kwenye diski na NIC si mapambo: vifaa vya IDE na e1000 vilivyoigizwa (emulated) huingia kwenye hypervisor mara nyingi zaidi kuliko foleni za virtio, na chini ya nesting, kila uingiliaji (trap) hulipiwa mara mbili.

Networking: sehemu ambayo mafunzo huruka

VPS yako ina IP moja ya umma na inakaa nyuma ya mfumo unaochuja anwani za MAC zisizojulikana. Matokeo mawili yanajitokeza.

Kutumia Bridging L2 kwa wageni kwenye mtandao wa umma mara nyingi hakutafanya kazi. Weka br0 kwenye NIC ya umma, mpe mgeni MAC yake mwenyewe, na utaona ARP ikitoka lakini hakuna kinachorudi; switch ya mtoa huduma inatupa fremu kutoka kwa MAC ambayo haijawahi kukodishwa kwako. Ikiwa hiyo ndiyo dalili yako, acha kufuatilia hitilafu kwenye bridge; huu ndio utaratibu wake.

Tumia mtandao wa NAT badala yake. libvirt inakuja na default: virbr0, 192.168.122.0/24, dnsmasq inatoa leases, na mawasiliano ya nje hufanya kazi mara moja. Kwa mawasiliano ya ndani, malizia TLS kwenye L1 na ufanye 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 lease ya kudumu kwanza (virsh net-edit default) ili anwani iliyo kwenye proxy_pass isibadilike.

Interface za usimamizi zisikae kwenye mtandao: VNC kwenye 5900 na Proxmox web UI kwenye 8006 zinapaswa kuwa kwenye loopback, zikifikika kupitia SSH tunnel (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) au kupitia WireGuard VPN inayojiendesha yenyewe ndani ya VPS, ambayo inafanya safu nzima ya wageni ya 192.168.122.0/24 kuwa hatua moja ya kibinafsi. Weka firewall ikiwa imefungwa, sudo ufw allow 22,80,443/tcp, hakuna kingine. Ikiwa wageni wanapoteza muunganisho wa nje mara tu baada ya kuwasha ufw, mhalifu wa kawaida ni DEFAULT_FORWARD_POLICY="DROP" kwenye /etc/default/ufw, iweke kuwa ACCEPT na uanzishe upya ufw.

Proxmox kwenye VPS

Proxmox VE 9 inatumia Debian 13 kama msingi wake, kwa hivyo inasakinika kwenye VPS ya Debian kwa kuongeza hazina ya pve-no-subscription na kifurushi cha proxmox-ve. Chukua mistari ya hazina na keyring kutoka kwenye nyaraka za sasa za Proxmox; URL iliyonakiliwa kutoka kwenye blogu ya zamani itafanya usakinishaji kufeli. Je, Proxmox inafaa kuwekwa kwenye maunzi yaliyokodiwa ni jambo la kuzingatia kabla ya kutumia jioni nzima kwenye usanidi wa mtandao hapa chini, na ulinganisho wa gharama na uwezo kati ya seva ya Proxmox ya nyumbani na VPS ya kukodi ni toleo la swali hilo ambalo tayari limefanyiwa hesabu za nishati na maunzi.

Vifurushi si sehemu ngumu. Proxmox inatarajia vmbr0 iwe imefanyiwa bridging kwenye NIC halisi, jambo ambalo linakwama moja kwa moja kwenye kizuizi cha MAC-filtering kilichotajwa hapo juu. Muundo unaofanya kazi kwenye VPS ni vmbr0 iliyofanyiwa NAT au routing bila port halisi kuunganishwa, huku wageni wakiwa kwenye masafa ya kibinafsi, na sheria za DNAT au reverse proxy kwenye host kwa ajili ya huduma zozote za umma. Pale ambapo huduma zinazoelekea kwa umma ni containers badala ya VMs, Traefik inayohudumia programu nyingi kutoka faili moja ya Docker Compose inashughulikia kazi hiyo hiyo ya routing ikiwa na vyeti vya kiotomatiki. Chukua snapshot ya /etc/network/interfaces kwanza: ufafanuzi mbaya wa bridge utakufulia nje ya mashine ambayo huenda huna console yake.

Utendaji, kwa uaminifu

Uwekaji wa nested ni polepole kuliko kiwango kimoja, na utaratibu huu una sababu mahususi badala ya kuwa wa jumla: ufikiaji wa kumbukumbu si mahali ambapo gharama hujitokeza, bali ni kwenye exits. Kwa kuwepo kwa EPT/NPT, L0 hudumisha shadow page tables kwa ajili ya L2 na usomaji wa kawaida wa kumbukumbu huenda kwa kasi ya maunzi. Kinachokuwa na gharama kubwa ni kila operesheni inayotoka kwenye guest mode, I/O, timer interrupts, MMIO, na inter-processor interrupts, kwa sababu L2 exit hushughulikiwa na L0 na inaweza kurudishwa nyuma kupitia L1. Kazi inayotegemea CPU kwa data iliyopo tayari kwenye RAM inaonekana karibu na kasi ya asili; chochote kinachotawaliwa na syscalls, pakiti za mtandao na disk I/O huhisi tabaka hizo.

Kwa hiyo: tumia virtio devices kila mahali. Na faili lako la qcow2 linakaa kwenye diski ambayo mtoa huduma ameshaifanya kuwa virtual, tabaka mbili za thin-provisioning zikiwa zimepangwa, ambapo cache=none kwenye diski ya guest huzuia 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 kufeli, na ujumbe utakaouona

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used kutoka kvm-ok. Aidha moduli haijapakiwa, au flag haijawekwa wazi. Kagua /proc/cpuinfo kwanza.

kvm: disabled by bios katika dmesg. Kwenye seva ya kawaida (bare metal), washa VT-x/SVM katika firmware. Ndani ya VPS, hii inamaanisha L0 haikupi extensions hizo, na hakuna amri unayoweza kuandika kwenye guest itakayobadilisha hilo.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. CPU inayoonekana na kernel yako haina vmx, hii pia ni uamuzi wa L0.

Could not access KVM kernel module: Permission denied. Hili ni suala la ruhusa, si maunzi. ls -l /dev/kvm inapaswa kuonyesha kundi kvm, mode 660; jiongeze kwenye kundi hilo na uanzishe login shell mpya, kwa sababu uanachama wa kundi hautumiki kwenye session inayoendelea.

kvm: Device or resource busy wakati QEMU inapoanza. Hypervisor nyingine inashikilia CPU: endesha lsmod, tafuta vboxdrv au moduli za VMware pamoja na kvm_intel, kisha ondoa (unload) ile usiyoihitaji.

/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, kwa kawaida ni suala la kundi (group).

Hakuna error yoyote, na kila kitu ni chepesi sana. QEMU bila flag ya accelerator inarudi kwenye TCG, emulator yake ya programu. Inafanya kazi kwa usahihi lakini ni polepole, boot inayochukua sekunde inakuwa ya dakika. Weka -accel kvm wazi, ili QEMU isimame na kutoa error badala ya kufanya emulation kimya kimya.

Guest inapotea katikati ya kazi. Angalia katika dmesg kwa ajili ya Out of memory: Killed process ... qemu-system-x86_64. L2 guest ni mchakato (process) kwenye L1, na OOM killer inaitendea kama mchakato mwingine wowote. RAM ya L2 inatoka kwenye allocation iliyopangwa ya L1, hakuna kukopa kutoka kwa host.

Uendeshaji: nakala rudufu, maboresho, na vikwazo

Nakala rudufu (Backups). Kunakili faili ya qcow2 ya mgeni (guest) anayefanya kazi kutakupa picha iliyoharibika. Ama virsh shutdown guest1 kisha unakili, au chukua snapshot ya nje (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) ili uandikaji uelekezwe kwenye overlay wakati unanakili msingi uliotulia, kisha uunganishe tena kwa kutumia virsh blockcommit. Hamisha nakala hizo nje ya VPS; snapshot iliyo kwenye diski ileile haitoi ulinzi wowote.

Maboresho (Upgrades). apt full-upgrade husakinisha moduli mpya za kvm_intel/kvm_amd, lakini kernel inayofanya kazi huendelea kutumia zile za zamani hadi utakapofanya reboot. Weka kernel ya awali ikiwa imesakinishwa na uendeshe tena kvm-ok baada ya kila mabadiliko ya kernel: seva inayorejea bila vmx inaweza kurejeshwa katika hali ya kufanya kazi kwa kubadili tu chaguo moja la boot.

Wakati mfumo huu unapofikia kikomo. IP moja ya umma inamaanisha kila huduma ya L2 hufikia ulimwengu kupitia proxy au sheria ya DNAT kwenye L1. Uhamiaji wa moja kwa moja (live migration) hauwezekani. Chini ya msongamano wa CPU, njia ya nested exit ndiyo ya kwanza kuathirika. Na hypervisor yenye wageni kadhaa ni mashine ambayo tayari umetumia RAM yake yote; VM zilizopangwa (nested VMs) haziwezi kutumia overcommit ili kukwepa mgao uliowekwa. Maabara inapokua na kuzidi uwezo huu, jibu si kuongeza tabaka za nested; ni kupata seva maalum ambapo wewe ni L0 na mambo haya hayahusiki.

FAQ

Je, ninahitaji nested virtualization ili kuendesha Docker kwenye VPS?

Hapana. Containers hushiriki kernel ya VPS yako na hazifungui /dev/kvm, kwa hivyo instance ya kawaida isiyo na vmx au svm flag huendesha Docker na Docker Compose bila tatizo. Nesting ni muhimu tu unapotaka kernel ya pili: maabara ya Proxmox, Windows guest, Firecracker microVMs, Android emulator, au CI runners zinazowasha VM images.

Ninawezaje kujua kama VPS yangu inasaidia nested virtualization?

Endesha grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, kisha kvm-ok kutoka kwenye kifurushi cha cpu-checker. Instance inayoweza kutumika huchapisha vmx (Intel) au svm (AMD), kvm-ok huripoti KVM acceleration can be used, na /dev/kvm ipo ikiwa na group kvm na mode 660. Puuza /sys/module/kvm_intel/parameters/nested kwa swali hili, faili hilo huelezea KVM module yako mwenyewe, si kile ambacho hypervisor ya mtoa huduma imekufungulia.

Kwa nini watoa huduma wengi wa VPS huzima nested virtualization?

Kufungua vmx kunamaanisha kumpa guest CPU model yenye flag hiyo, na guest inayotegemea sifa hizo za CPU haiwezi kuhamishwa (live-migrate) kwenda kwenye mashine ambayo CPU yake haina sifa hizo; mtoa huduma anayehamaisha wateja ili kusafisha nodes hupoteza uwezo huo. Njia za msimbo za nested VMX/SVM pia zina historia ndefu ya CVE. Baadhi ya hosts bado huiwasha kwa kila VM ukiiomba, na wengine huorodhesha nesting kama kipengele cha mpango fulani.

Nested VM yangu haina mtandao kwenye public bridge. Nini tatizo?

Switch ya mtoa huduma hupoteza (drop) frames kutoka kwa MAC address ambayo haijakukodisha, kwa hivyo L2 guest iliyounganishwa kwenye public NIC hutuma ARP na haipati jibu. Acha kufanya debugging ya br0, tumia mtandao wa NAT default wa libvirt (virbr0, 192.168.122.0/24), mpe guest static lease, na uchapishe chochote cha umma kupitia reverse proxy au DNAT rule kwenye VPS yenyewe.

Nested VM huwa polepole kwa kiasi gani?

Gharama hutokea kwenye VM exits, si kwenye ufikiaji wa kumbukumbu (memory access). EPT/NPT ikiwa imewashwa, usomaji na uandikaji wa kawaida ndani ya L2 huenda kwa kasi ya vifaa (hardware speed), wakati I/O, timer interrupts, MMIO na IPI hushughulikiwa na L0 na zinaweza kurudishwa kupitia L1. Kazi zinazotegemea CPU kwa data iliyo tayari kwenye RAM huonekana karibu na kasi ya asili; kazi nzito za syscall, pakiti na diski huhisi kila safu. Tumia vifaa vya virtio kila mahali na cache=none kwenye diski za guest, kisha pima mzigo wako wa kazi.