Bolehkan run Proxmox dalam VPS?

Jawapan ringkas

Virtualisasi bersarang (nested virtualization) ialah hypervisor yang berjalan di dalam mesin maya: VPS anda sudah pun merupakan tetamu, dan anda mahu ia menghoskan tetamu sendiri. Ia hanya berfungsi apabila hypervisor pembekal anda mendedahkan sambungan virtualisasi CPU kepada instance anda secara sengaja — semak /proc/cpuinfo untuk flag vmx (Intel) atau svm (AMD), dan jika kedua-duanya tidak muncul, tiada konfigurasi di dalam VPS yang dapat menyelesaikannya.

Satu perkara penting: Docker tidak memerlukan semua ini. Container berkongsi kernel VPS anda dan tidak pernah menyentuh /dev/kvm. Jika matlamat sebenar anda adalah "menjalankan beberapa perkhidmatan dalam container di pelayan saya", anda sudah mempunyai apa yang diperlukan. Nesting penting apabila anda mahukan kernel kedua — makmal Proxmox, tetamu Windows, microVM Firecracker, emulator Android, tapak ujian Kubernetes dengan VM sebenar, atau runner CI yang memulakan imej VM.

Apa yang sebenarnya sedang di-nest

Tiga lapisan:

• L0 — hypervisor pembekal, pada perkakasan asal. Anda tidak mempunyai akses kepadanya.
• L1 — VPS anda. Bagi L0, ini hanyalah tetamu (guest).
• L2 — VM yang ingin anda jalankan di dalam VPS anda.

Virtualisasi perkakasan adalah VT-x (bendera vmx) berserta EPT pada Intel, AMD-V / SVM (svm) berserta RVI/NPT pada AMD. Hypervisor menggunakan arahan tersebut untuk memasuki mod tetamu dan membolehkan CPU memproses dua jadual halaman (page tables) secara serentak.

Kedua-duanya tidak direka untuk bersifat re-entrant, jadi nesting di-emulasi: apabila L1 melaksanakan arahan VMX, ia akan ditangkap (trap) ke L0, yang kemudiannya menyenggara struktur bayangan (shadow structures) untuk L2 bagi pihak L1. KVM melakukan perkara ini dengan baik, tetapi L0 perlu melakukan kerja tambahan pada setiap exit — sebab itulah pembekal perlu memilih untuk mengaktifkannya (opt in).

Dua syarat mesti dipenuhi untuk L2 yang dipercepatkan:

1. Modul KVM L0 dimuatkan dengan nested=1.
2. L0 memberikan model CPU kepada VPS anda yang mempunyai bendera tersebut — <cpu mode='host-passthrough'/> dalam libvirt, cpu: host dalam Proxmox, -cpu host dalam QEMU mentah. Model emulasi generik (qemu64, kvm64) menyembunyikan vmx walaupun nesting telah diaktifkan secara global.

Semak VPS anda dalam satu minit

# 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 yang boleh digunakan akan memaparkan vmx atau svm, kvm-ok menyatakan KVM acceleration can be used, dan /dev/kvm wujud sebagai mod root:kvm 660. Jika flag tersebut ada tetapi nod peranti tiada, muat modul secara manual dan baca log kernel:

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

Satu fail sering dipetik tetapi sering disalah tafsir:

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

Di dalam VPS anda, itu adalah tetapan modul KVM anda, dan ia menentukan sama ada tetamu L2 boleh melakukan nesting tahap ketiga. Ia tidak menyatakan sama ada L0 telah mengaktifkan nesting untuk anda — /proc/cpuinfo dan kvm-ok memberikan jawapan tersebut. Parameter nested adalah tetapan yang anda tetapkan pada mesin milik anda sendiri:

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

Penyingkiran modul ditolak jika VM sedang berjalan, jadi matikan tetamu terlebih dahulu.

Mengapa kebanyakan hos VPS mematikan fungsi ini

• Migrasi langsung. Memberikan vmx bermaksud mendedahkan model CPU yang mempunyai flag tersebut. Tetamu (guest) yang bergantung pada ciri CPU tersebut tidak boleh dimigrasi dengan selamat ke mesin yang CPU-nya tidak mempunyai ciri tersebut. Hos yang mengosongkan node dengan memigrasi pelanggan akan kehilangan keupayaan ini sebaik sahaja fungsi nesting diaktifkan.
• Permukaan serangan. Laluan nested VMX/SVM adalah antara kod paling rumit dalam lapisan virtualisasi kernel, dengan sejarah CVE yang berkaitan.
• L0 mungkin bukan KVM. Jika systemd-detect-virt mencetak vmware, xen atau microsoft, peraturan nesting adalah milik stack tersebut, bukan KVM.

Tiada flag pada instance anda? Hubungi sokongan (sesetengah hos mengaktifkannya mengikut per-VM), pilih pelan yang mendokumentasikan nesting, atau beralih ke mesin dedicated. Kandungan selebihnya mengandaikan anda mempunyai akses root pada mesin yang memaparkan flag tersebut.

Menjalankan tetamu L2 dengan 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'

Sesi grafik tidak diperlukan. Pemasangan siri akan berjalan untuk seketika, jadi mulakan ia di dalam shell yang kekal: aliran kerja tmux yang mengekalkan sesi Claude Code pada VPS yang sama mengekalkan konsol virt-install yang bersambung walaupun sambungan SSH terputus. Jika --os-variant debian13 ditolak, osinfo-db anda adalah versi lama — jalankan osinfo-query os dan pilih nama yang wujud. --cpu host-passthrough memajukan vmx ke dalam L2, hanya diperlukan jika L2 perlu melakukan virtualisasi seterusnya. Jadikan tetamu selamat untuk but dengan virsh autostart guest1.

Bas virtio pada cakera dan NIC bukan sekadar hiasan: peranti IDE dan e1000 yang diemulasi kerap masuk ke hypervisor berbanding barisan virtio, dan dalam keadaan nesting, setiap trap akan dikenakan kos dua kali ganda.

Rangkaian: bahagian yang sering diabaikan dalam tutorial

VPS anda mempunyai satu IP awam dan berada di belakang fabrik yang menapis alamat MAC yang tidak dikenali. Ini membawa dua kesan.

Menghubungkan (bridging) tetamu L2 ke rangkaian awam biasanya tidak akan berfungsi. Jika anda meletakkan br0 pada NIC awam dan memberikan tetamu alamat MAC sendiri, anda akan melihat ARP dihantar tetapi tiada maklum balas diterima — suis penyedia membuang bingkai (frames) daripada MAC yang tidak pernah diberikan kepada anda. Jika ini adalah simptom anda, berhenti menyahpepijat (debug) bridge tersebut; ini adalah mekanismenya.

Gunakan rangkaian NAT sebagai ganti. libvirt menyertakan default: virbr0, 192.168.122.0/24, dan pajakan (leases) dnsmasq; sambungan keluar berfungsi serta-merta. Untuk sambungan masuk, tamatkan TLS pada L1 dan gunakan proxy — laluan sijil di bawah diambil daripada mengeluarkan sijil Let's Encrypt dengan Certbot pada 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;
    }
}

Berikan tetamu pajakan statik terlebih dahulu (virsh net-edit default) supaya alamat dalam proxy_pass tersebut tidak berubah.

Antara muka pengurusan tidak boleh terdedah ke internet: VNC pada 5900 dan UI web Proxmox pada 8006 harus berada pada loopback, yang dicapai melalui terowong SSH (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) atau melalui VPN WireGuard hos-sendiri ke dalam VPS, yang meletakkan keseluruhan julat tetamu 192.168.122.0/24 satu lompatan peribadi sahaja. Kekalkan tembok api (firewall) yang sempit — sudo ufw allow 22,80,443/tcp, tiada lagi yang lain. Jika tetamu kehilangan sambungan keluar sejurus selepas anda mengaktifkan ufw, punca biasa ialah DEFAULT_FORWARD_POLICY="DROP" dalam /etc/default/ufw — tetapkannya kepada ACCEPT dan muat semula ufw.

Proxmox pada VPS

Proxmox VE 9 berasaskan Debian 13. Anda boleh memasangnya pada VPS Debian dengan menambah repositori pve-no-subscription dan pakej proxmox-ve. Gunakan baris repositori dan keyring daripada dokumentasi rasmi Proxmox yang terkini — URL yang disalin daripada hantaran blog lama akan menyebabkan pemasangan gagal.

Pakej bukanlah bahagian yang sukar. Proxmox memerlukan vmbr0 yang disambungkan melalui bridge ke NIC fizikal, yang akan menyebabkan masalah penapisan MAC seperti yang dinyatakan di atas. Konfigurasi yang berfungsi pada VPS ialah vmbr0 jenis NAT atau routed tanpa port fizikal, tetamu (guests) dalam julat peribadi, serta peraturan DNAT atau reverse proxy pada hos untuk sebarang akses awam. Jika perkhidmatan awam adalah dalam bentuk container dan bukannya VM, Traefik yang mengendalikan pelbagai aplikasi daripada satu fail Docker Compose boleh melakukan tugas penghalaan yang sama dengan sijil automatik. Buat snapshot /etc/network/interfaces terlebih dahulu: definisi bridge yang salah akan menyebabkan anda terkunci daripada mesin yang mungkin tidak mempunyai akses konsol.

Prestasi, secara jujur

Nested lebih perlahan daripada single-level, dan mekanismenya adalah khusus dan bukannya tersebar: kos bukan terletak pada akses memori, tetapi pada exit. Dengan kehadiran EPT/NPT, L0 mengekalkan shadow page tables untuk L2 dan pembacaan memori biasa berjalan pada kelajuan perkakasan. Operasi yang meninggalkan guest mode menjadi mahal — I/O, timer interrupts, MMIO, inter-processor interrupts — kerana setiap L2 exit dikendalikan oleh L0 dan mungkin dipantulkan semula melalui L1. Kerja berorientasikan CPU ke atas data yang sudah ada dalam RAM kelihatan hampir seperti native; apa-apa yang didominasi oleh syscalls, paket, dan disk I/O akan terasa kesan lapisan tersebut.

Jadi: gunakan peranti virtio di mana-mana. Dan fail qcow2 anda berada pada disk yang telah pun divisualisasikan oleh penyedia — dua lapisan thin-provisioning bertindan, di mana cache=none pada disk guest mengelakkan blok yang sama berada dalam dua page cache secara serentak. Tiada angka benchmark di sini: ukur beban kerja anda sendiri pada instance anda sendiri.

Mod kegagalan, dan rentetan yang akan anda lihat

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used daripada kvm-ok. Sama ada modul tidak dimuatkan, atau flag tidak didedahkan. Periksa /proc/cpuinfo terlebih dahulu.

kvm: disabled by bios dalam dmesg. Pada bare metal, aktifkan suis VT-x/SVM dalam firmware. Di dalam VPS, ini bermakna L0 tidak memberikan sambungan tersebut, dan apa-apa yang anda taip dalam guest tidak akan mengubahnya.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. CPU yang dilihat oleh kernel anda tidak mempunyai vmx — sekali lagi, ini adalah keputusan L0.

Could not access KVM kernel module: Permission denied. Isu kebenaran, bukan perkakasan. ls -l /dev/kvm sepatutnya menunjukkan group kvm, mode 660; tambahkan diri anda ke dalam group tersebut dan mulakan shell login yang baharu, kerana keahlian group tidak terpakai pada sesi yang sedang berjalan.

kvm: Device or resource busy apabila QEMU bermula. Hypervisor lain sedang memegang CPU: jalankan lsmod, cari vboxdrv atau modul VMware bersama kvm_intel, dan nyahmuat modul yang tidak anda mahukan.

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

Proxmox: KVM virtualisation configured, but not available. Guest mempunyai pilihan pecutan KVM yang ditanda pada host yang tidak dapat menyediakannya. Baiki nesting, atau nyah tanda dan terima emulasi.

Android emulator: x86_64 emulation currently requires hardware acceleration! /dev/kvm sekali lagi — biasanya isu group.

Tiada ralat langsung, dan semuanya sangat perlahan. QEMU tanpa flag accelerator akan beralih ke TCG, iaitu emulator perisiannya. Ia berfungsi dengan betul tetapi sangat perlahan — proses boot yang sepatutnya mengambil masa beberapa saat menjadi beberapa minit. Masukkan -accel kvm secara eksplisit, supaya QEMU berhenti dengan ralat dan bukannya melakukan emulasi secara senyap.

Guest hilang semasa sedang berjalan. Lihat dalam dmesg untuk Out of memory: Killed process ... qemu-system-x86_64. Guest L2 adalah satu proses pada L1, dan OOM killer melayannya seperti proses lain. RAM L2 diambil daripada peruntukan tetap L1 — tiada pinjaman daripada host.

Pengoperasian: sandaran, naik taraf, had

Sandaran. Menyalin qcow2 tetamu yang sedang berjalan akan menghasilkan imej yang rosak. Anda perlu sama ada menggunakan virsh shutdown guest1 dan menyalin, atau mengambil snapshot luaran (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) supaya penulisan dialihkan ke overlay semasa anda menyalin pangkalan yang kini statik, kemudian gabungkannya semula dengan virsh blockcommit. Hantar salinan tersebut keluar dari VPS — snapshot pada cakera yang sama tidak memberikan perlindungan.

Naik taraf. apt full-upgrade memasang modul kvm_intel/kvm_amd yang baharu, tetapi kernel yang sedang berjalan akan mengekalkan modul lama sehingga anda melakukan but semula. Kekalkan kernel sebelumnya yang telah dipasang dan jalankan semula kvm-ok selepas setiap perubahan kernel: hos yang kembali tanpa vmx hanya memerlukan satu entri but untuk berfungsi semula.

Had skalabiliti. Satu IP awam bermaksud setiap perkhidmatan L2 mencapai dunia luar melalui proksi atau peraturan DNAT pada L1. Migrasi langsung tidak tersedia. Di bawah persaingan CPU, laluan exit bersarang adalah perkara pertama yang terjejas. Dan hypervisor dengan beberapa tetamu adalah mesin yang RAM-nya telah habis digunakan — VM bersarang tidak boleh mengatasi had melalui overcommit daripada peruntukan tetap. Apabila makmal melampaui had tersebut, jawapannya bukan dengan menambah lapisan bersarang yang lebih tinggi; ia adalah kotak khusus di mana anda adalah L0 dan tiada perkara ini terpakai.

FAQ

Adakah saya memerlukan virtualisasi bersarang untuk menjalankan Docker pada VPS?

Tidak. Kontena berkongsi kernel VPS anda dan tidak pernah membuka /dev/kvm, jadi instans biasa tanpa flag vmx atau svm boleh menjalankan Docker dan Docker Compose dengan baik. Virtualisasi bersarang hanya diperlukan apabila anda mahukan kernel kedua: makmal Proxmox, tetamu Windows, microVM Firecracker, emulator Android, atau pelari CI yang memulakan imej VM.

Bagaimanakah cara untuk menyemak sama ada VPS saya menyokong virtualisasi bersarang?

Jalankan grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, kemudian kvm-ok daripada pakej cpu-checker. Instans yang boleh digunakan akan mencetak vmx (Intel) atau svm (AMD), kvm-ok melaporkan KVM acceleration can be used, dan /dev/kvm wujud dengan kumpulan kvm dan mod 660. Abaikan /sys/module/kvm_intel/parameters/nested untuk soalan ini — fail tersebut menerangkan modul KVM anda sendiri, bukan apa yang didedahkan oleh hypervisor penyedia kepada anda.

Mengapakah kebanyakan penyedia VPS menyahaktifkan virtualisasi bersarang?

Mendedahkan vmx bermaksud memberikan model CPU kepada tetamu yang mempunyai flag tersebut. Tetamu yang bergantung pada ciri CPU tersebut tidak boleh dipindahkan secara live (live-migrated) ke mesin yang CPU-nya tidak mempunyai ciri tersebut — penyedia yang memindahkan pelanggan antara nod akan mengelakkan perkara ini. Laluan kod VMX/SVM bersarang juga mempunyai sejarah CVE yang panjang. Sesetengah hos masih mengaktifkannya bagi setiap VM atas permintaan, manakala yang lain mendokumentasikan virtualisasi bersarang sebagai ciri pelan.

VM bersarang saya tiada rangkaian pada bridge awam. Apakah masalahnya?

Suis penyedia membuang bingkai (frames) daripada alamat MAC yang tidak pernah disewakan kepada anda. Oleh itu, tetamu L2 yang disambungkan (bridged) pada NIC awam akan menghantar ARP tetapi tidak menerima maklum balas. Berhenti menyahpepijat br0 — gunakan rangkaian NAT libvirt default (virbr0, 192.168.122.0/24), berikan tetamu sewaan statik, dan terbitkan apa-apa yang bersifat awam melalui reverse proxy atau peraturan DNAT pada VPS itu sendiri.

Berapakah tahap kelambatan VM bersarang?

Kos berlaku pada VM exits, bukan pada akses memori. Dengan EPT/NPT aktif, operasi baca dan tulis biasa di dalam L2 berjalan pada kelajuan perkakasan, manakala I/O, gangguan pemasa (timer interrupts), MMIO dan IPI dikendalikan oleh L0 dan mungkin dihantar semula melalui L1. Kerja berorientasikan CPU dengan data yang sudah ada dalam RAM kelihatan hampir seperti asal; beban kerja yang berat dengan syscall, paket, dan disk akan terasa setiap lapisan. Gunakan peranti virtio di mana-mana dan cache=none pada cakera tetamu, kemudian ukur beban kerja anda sendiri.