Bolehkan VPS Menjalankan Proxmox? Cara Semak Nested Virt

Jawapan ringkas

Nested virtualization ialah hypervisor yang berjalan di dalam mesin maya: VPS anda sudah pun menjadi tetamu, dan anda mahu ia menjadi hos kepada tetamu miliknya sendiri. Ia hanya berfungsi apabila hypervisor penyedia anda sengaja mendedahkan sambungan virtualisasi CPU kepada instans anda; semak /proc/cpuinfo untuk flag vmx (Intel) atau svm (AMD), dan jika kedua-duanya tidak muncul, tiada apa yang anda konfigurasi di dalam VPS akan membaikinya.

Satu perkara untuk menetapkan jangkaan: Docker tidak memerlukan semua ini. Kontena berkongsi kernel VPS anda dan tidak pernah menyentuh /dev/kvm. Jika matlamat sebenar adalah "menjalankan beberapa servis dalam kontena pada pelayan saya", anda sudah mempunyai apa yang diperlukan. Nested virtualization penting apabila anda mahukan kernel kedua, makmal Proxmox, tetamu Windows, Firecracker microVM, emulator Android, testbed Kubernetes yang terdiri daripada VM sebenar, atau CI runner yang memboot imej VM.

Apakah yang sebenarnya disarangkan

Tiga lapisan:

• L0, hypervisor penyedia, pada perkakasan fizikal. Anda tiada akses kepadanya.
• L1, VPS anda. Bagi L0, ini hanyalah tetamu.
• L2, VM yang anda ingin jalankan di dalam VPS anda.

Virtualisasi perkakasan ialah VT-x (flag vmx) berserta EPT pada Intel, atau AMD-V / SVM (svm) berserta RVI/NPT pada AMD. Hypervisor menggunakan arahan tersebut untuk memasuki mod tetamu dan membenarkan CPU menyemak dua jadual halaman (page tables) serentak.

Tiada satu pun yang direka bentuk untuk menjadi re-entrant, jadi penyarangan (nesting) diemulasikan: apabila L1 melaksanakan arahan VMX, ia memerangkap (trap) ke L0, yang menyelenggara struktur bayangan (shadow structures) untuk L2 bagi pihak L1. KVM melakukan ini dengan baik, tetapi L0 perlu melakukan kerja tambahan pada setiap exit, itulah sebabnya penyedia perlu membenarkannya secara eksplisit.

Dua syarat mesti dipenuhi untuk L2 yang dipecut (accelerated):

1. Modul KVM pada L0 dimuatkan dengan nested=1.
2. L0 memberikan VPS anda model CPU yang membawa flag tersebut, <cpu mode='host-passthrough'/> dalam libvirt, cpu: host dalam Proxmox, -cpu host dalam QEMU mentah. Model emulasi generik (qemu64, kvm64) menyembunyikan vmx walaupun penyarangan 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

Instans yang boleh digunakan akan mencetak vmx atau svm, kvm-ok menyatakan KVM acceleration can be used, dan /dev/kvm wujud sebagai root:kvm mod 660. Jika flag tersebut ada tetapi nod peranti tiada, muatkan modul secara manual dan baca log kernel:

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

Satu fail sering dipetik dan disalah tafsir secara meluas:

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

Di dalam VPS anda, itu adalah tetapan modul KVM anda, dan ia mengawal sama ada tetamu L2 boleh melakukan nesting tahap ketiga. Ia tidak menyatakan sama ada L0 telah mendayakan nesting untuk anda, /proc/cpuinfo dan kvm-ok menjawab perkara itu. Parameter nested ialah tombol yang anda tetapkan pada mesin yang anda miliki sepenuhnya:

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 semasa VM sedang berjalan, jadi matikan tetamu terlebih dahulu.

Mengapa kebanyakan hos VPS membiarkannya dimatikan

• Migrasi langsung. Memberikan anda vmx bermakna mendedahkan model CPU yang membawa flag tersebut, dan tetamu yang bergantung pada ciri CPU itu tidak boleh dimigrasikan dengan selamat ke mesin yang tidak mempunyai ciri tersebut. Hos yang mengosongkan nod dengan memigrasikan pelanggan akan kehilangan keupayaan itu sebaik sahaja ia mendayakan nesting.
• Permukaan serangan. Laluan VMX/SVM bersarang adalah antara kod yang paling rumit dalam lapisan virtualisasi kernel, dengan sejarah CVE yang sepadan.
• L0 mungkin bukan KVM. Jika systemd-detect-virt mencetak vmware, xen atau microsoft, peraturan nesting yang digunakan adalah peraturan tindanan tersebut, bukan KVM.

Tiada flag pada instans anda? Hubungi sokongan (sesetengahnya mendayakannya mengikut VM), pilih pelan yang mendokumentasikan nesting, atau beralih ke mesin berdedikasi. Selebih daripada panduan ini 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 bersiri mengambil masa, jadi mulakan ia di dalam shell yang berterusan: aliran kerja tmux yang mengekalkan sesi Claude Code pada VPS juga mengekalkan konsol virt-install agar kekal bersambung walaupun sambungan SSH terputus. Jika --os-variant debian13 ditolak, osinfo-db anda mendahului keluaran tersebut, 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 but tetamu selamat dengan virsh autostart guest1.

Bas virtio pada cakera dan NIC bukan sekadar hiasan: peranti IDE dan e1000 yang diemulasi memerangkap ke dalam hypervisor dengan lebih kerap berbanding baris gilir virtio, dan di bawah penyarangan (nesting), setiap perangkap dibayar dua kali ganda.

Rangkaian: bahagian yang sering ditinggalkan dalam tutorial

VPS anda mempunyai satu IP awam dan berada di sebalik fabrik yang menapis alamat MAC yang tidak dikenali. Dua akibat akan berlaku.

Bridging tetamu L2 ke rangkaian awam biasanya tidak akan berfungsi. Letakkan br0 pada NIC awam, berikan tetamu MAC sendiri, dan anda akan melihat ARP keluar tetapi tiada balasan; suis pembekal menggugurkan frame daripada MAC yang tidak pernah dipajakkan kepada anda. Jika itu simptom anda, berhenti menyahpepijat bridge; ini adalah mekanismenya.

Gunakan rangkaian NAT sebagai ganti. libvirt membekalkan default: virbr0, 192.168.122.0/24, pajakan dnsmasq, trafik keluar berfungsi serta-merta. Untuk trafik masuk, tamatkan TLS pada L1 dan lakukan proksi masuk, laluan sijil di bawah datang 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 itu kekal.

Antara muka pengurusan perlu dijauhkan daripada internet: VNC pada 5900 dan UI web Proxmox pada 8006 sepatutnya berada pada loopback, dicapai melalui terowong SSH (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) atau merentasi VPN WireGuard yang dihoskan sendiri ke dalam VPS, yang meletakkan keseluruhan julat tetamu 192.168.122.0/24 satu hop peribadi sahaja. Pastikan firewall terhad, sudo ufw allow 22,80,443/tcp, tiada yang lain. Jika tetamu kehilangan ketersambungan keluar sejurus selepas anda mendayakan ufw, punca biasa ialah DEFAULT_FORWARD_POLICY="DROP" dalam /etc/default/ufw, tetapkan ia kepada ACCEPT dan muat semula ufw.

Proxmox pada VPS

Proxmox VE 9 dibina berasaskan Debian 13, jadi ia dipasang pada VPS Debian dengan menambah repositori pve-no-subscription dan pakej proxmox-ve. Gunakan baris repositori dan keyring daripada dokumentasi semasa Proxmox; URL yang disalin daripada catatan blog lama akan menyebabkan pemasangan gagal. Sama ada Proxmox sesuai digunakan pada perkakasan sewaan perlu dipertimbangkan sebelum anda menghabiskan masa pada konfigurasi rangkaian di bawah, dan perbandingan kos dan keupayaan antara pelayan Proxmox di rumah dan VPS sewaan ialah versi perbincangan tersebut yang telah mengambil kira aspek kuasa dan perkakasan.

Pemasangan pakej bukanlah bahagian yang sukar. Proxmox menjangkakan vmbr0 dihubungkan (bridged) kepada NIC fizikal, yang akan terus menemui jalan buntu akibat penapisan MAC seperti yang dinyatakan di atas. Konfigurasi yang berfungsi pada VPS ialah vmbr0 yang menggunakan NAT atau penghalaan (routed) tanpa port fizikal yang dilampirkan, dengan tetamu berada pada julat IP peribadi, serta peraturan DNAT atau reverse proxy pada hos untuk sebarang perkhidmatan awam. Jika perkhidmatan yang menghadap ke awam adalah kontena dan bukannya VM, Traefik yang menguruskan berbilang aplikasi daripada satu fail Docker Compose meliputi tugas penghalaan yang sama dengan sijil automatik. Ambil snapshot /etc/network/interfaces terlebih dahulu: definisi bridge yang salah akan menyebabkan anda terkunci daripada mesin yang konsolnya mungkin tidak dapat diakses.

Prestasi, secara jujur

Nested adalah lebih perlahan berbanding single-level, dan mekanismenya adalah spesifik dan bukannya meluas: akses memori bukanlah punca kos, sebaliknya ia adalah exit. Dengan adanya EPT/NPT, L0 mengekalkan shadow page tables untuk L2 dan bacaan memori biasa berjalan pada kelajuan perkakasan. Perkara yang menjadi mahal ialah setiap operasi yang meninggalkan guest mode, I/O, timer interrupts, MMIO, dan inter-processor interrupts, kerana L2 exit dikendalikan oleh L0 dan mungkin dipantulkan semula melalui L1. Kerja yang terikat dengan CPU ke atas data yang sudah berada dalam RAM kelihatan hampir sama dengan native; apa-apa yang didominasi oleh syscalls, paket dan disk I/O akan terasa kesan lapisan tersebut.

Oleh itu: gunakan peranti virtio di mana-mana. Fail qcow2 anda pula berada pada cakera yang telah divirtualisasikan oleh penyedia, dengan dua lapisan thin-provisioning disusun, di mana cache=none pada cakera guest menghalang blok yang sama daripada berada dalam dua page cache serentak. Tiada nombor penanda aras 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. Semak /proc/cpuinfo dahulu.

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

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

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

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

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

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

Emulator Android: x86_64 emulation currently requires hardware acceleration! /dev/kvm sekali lagi, biasanya kes kumpulan.

Tiada ralat langsung, dan semuanya sangat perlahan. QEMU tanpa flag pemecut akan kembali kepada TCG, emulator perisiannya. Ia tepat tetapi perlahan, proses but yang diukur dalam saat menjadi minit. Berikan -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 ialah proses pada L1, dan OOM killer melayannya seperti proses lain. RAM L2 diambil daripada peruntukan tetap L1, tiada peminjaman daripada host.

Pengendalian: sandaran, naik taraf, had

Sandaran. Menyalin fail qcow2 tetamu yang sedang berjalan akan menghasilkan imej yang rosak. Sama ada virsh shutdown guest1 dan salin, atau ambil snapshot luaran (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) supaya penulisan dialihkan ke overlay semasa anda menyalin fail asas yang kini statik, kemudian gabungkan semula dengan virsh blockcommit. Pindahkan salinan tersebut keluar dari VPS; snapshot pada cakera yang sama tidak memberikan perlindungan.

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

Had penskalaan. Satu IP awam bermakna setiap servis L2 mencapai dunia luar melalui proksi atau peraturan DNAT pada L1. Migrasi langsung (live migration) tidak tersedia. Apabila berlaku perebutan CPU, laluan keluar bersarang (nested exit path) adalah perkara pertama yang terjejas. Selain itu, hypervisor dengan beberapa tetamu adalah mesin yang RAM-nya telah diperuntukkan sepenuhnya; VM bersarang tidak boleh melakukan overcommit melebihi peruntukan tetap. Apabila makmal anda melebihi kapasiti ini, penyelesaiannya bukanlah menambah tindanan bersarang yang lebih tinggi; sebaliknya, gunakan mesin khusus di mana anda adalah L0 dan semua kekangan ini tidak lagi terpakai.

FAQ

Adakah saya memerlukan nested virtualization 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 lancar. Nesting hanya penting apabila anda memerlukan kernel kedua: makmal Proxmox, tetamu Windows, Firecracker microVM, emulator Android, atau CI runner yang memuatkan imej VM.

Bagaimanakah cara untuk menyemak sama ada VPS saya menyokong nested virtualization?

Jalankan grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, kemudian kvm-ok daripada pakej cpu-checker. Instans yang boleh digunakan akan memaparkan vmx (Intel) atau svm (AMD), kvm-ok melaporkan KVM acceleration can be used, dan /dev/kvm wujud dengan kumpulan kvm serta 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 melumpuhkan nested virtualization?

Mendedahkan vmx bermaksud memberikan tetamu model CPU yang membawa flag tersebut, dan tetamu yang bergantung pada ciri CPU tersebut tidak boleh dipindahkan secara langsung (live-migrated) ke mesin yang CPU-nya tidak mempunyai ciri tersebut. Penyedia yang mengosongkan nod dengan memindahkan pelanggan akan kehilangan keupayaan ini. Laluan kod VMX/SVM nested juga mempunyai sejarah CVE yang panjang. Sesetengah hos masih membolehkannya bagi setiap VM atas permintaan, dan yang lain mendokumentasikan nesting sebagai ciri pelan.

VM nested saya tiada rangkaian pada public bridge. Apakah masalahnya?

Suis penyedia menggugurkan frame daripada alamat MAC yang tidak pernah dipajakkan kepada anda, jadi tetamu L2 yang dihubungkan ke NIC awam menghantar ARP dan tidak menerima sebarang balasan. Berhenti menyahpepijat br0, gunakan rangkaian NAT default libvirt (virbr0, 192.168.122.0/24), berikan tetamu pajakan statik, dan terbitkan sebarang kandungan awam melalui reverse proxy atau peraturan DNAT pada VPS itu sendiri.

Berapa perlaukah VM nested?

Kosnya terletak pada VM exits, bukan pada akses memori. Dengan EPT/NPT aktif, bacaan dan tulisan biasa di dalam L2 berjalan pada kelajuan perkakasan, manakala I/O, timer interrupts, MMIO dan IPI dikendalikan oleh L0 dan mungkin dilantun semula melalui L1. Kerja yang terikat dengan CPU (CPU-bound) ke atas data yang sudah ada dalam RAM kelihatan hampir seperti natif; beban kerja yang berat dengan syscall, paket dan cakera akan terasa di setiap lapisan. Gunakan peranti virtio di mana-mana dan cache=none pada cakera tetamu, kemudian ukur beban kerja anda sendiri.