bisakah menjalankan Proxmox di VPS?

Jawaban singkat

Virtualisasi bersarang (nested virtualization) adalah hypervisor yang berjalan di dalam mesin virtual: VPS Anda sudah merupakan tamu (guest), dan Anda ingin VPS tersebut menampung tamu lainnya. Fitur ini hanya berfungsi jika hypervisor penyedia layanan Anda secara sengaja mengekspos ekstensi virtualisasi CPU ke instans Anda — periksa /proc/cpuinfo untuk flag vmx (Intel) atau svm (AMD). Jika keduanya tidak muncul, konfigurasi apa pun di dalam VPS tidak akan dapat memperbaikinya.

Satu hal penting: Docker tidak membutuhkan fitur ini. Kontainer berbagi kernel VPS Anda dan tidak pernah menyentuh /dev/kvm. Jika tujuan utama Anda adalah "menjalankan beberapa layanan dalam kontainer di server saya", Anda sudah memiliki semua yang dibutuhkan. Virtualisasi bersarang diperlukan jika Anda membutuhkan kernel kedua — seperti lab Proxmox, tamu Windows, microVM Firecracker, emulator Android, lingkungan pengujian Kubernetes dengan VM asli, atau runner CI yang melakukan booting pada citra VM.

Apa yang sebenarnya di-nesting

Tiga lapisan:

• L0 — hypervisor penyedia layanan, berjalan langsung di perangkat keras. Anda tidak memiliki akses ke sini.
• L1 — VPS Anda. Bagi L0, ini hanyalah sebuah guest.
• L2 — VM yang ingin Anda jalankan di dalam VPS Anda.

Virtualisasi perangkat keras adalah VT-x (flag vmx) plus EPT pada Intel, serta AMD-V / SVM (svm) plus RVI/NPT pada AMD. Hypervisor menggunakan instruksi tersebut untuk masuk ke guest mode dan memungkinkan CPU menelusuri dua page table secara bersamaan.

Keduanya tidak dirancang untuk bersifat re-entrant, sehingga nesting dilakukan melalui emulasi: saat L1 mengeksekusi instruksi VMX, hal ini akan memicu trap ke L0, yang kemudian mengelola shadow structures untuk L2 atas nama L1. KVM melakukan ini dengan baik, namun L0 harus melakukan pekerjaan tambahan pada setiap exit — itulah sebabnya penyedia layanan harus mengaktifkannya secara opsional.

Dua kondisi harus terpenuhi untuk mendapatkan L2 yang terakselerasi:

1. Modul KVM pada L0 dimuat dengan nested=1.
2. L0 memberikan model CPU ke VPS Anda yang memiliki flag tersebut — <cpu mode='host-passthrough'/> pada libvirt, cpu: host pada Proxmox, -cpu host pada QEMU mentah. Model emulasi generik (qemu64, kvm64) menyembunyikan vmx meskipun nesting telah diaktifkan secara global.

Periksa VPS Anda dalam satu menit

# 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 dapat digunakan akan mencetak vmx atau svm, kvm-ok akan menyatakan KVM acceleration can be used, dan /dev/kvm ada sebagai mode root:kvm 660. Jika flag tersedia tetapi node perangkat tidak ada, muat modul secara manual dan baca log kernel:

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

Satu file sering dikutip namun sering salah dipahami:

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

Di dalam VPS Anda, itu adalah pengaturan modul KVM Anda, dan itu mengatur apakah tamu L2 dapat melakukan nesting level ketiga. File tersebut tidak menjelaskan apakah L0 mengaktifkan nesting untuk Anda — /proc/cpuinfo dan kvm-ok menjawab hal tersebut. Parameter nested adalah pengaturan yang Anda tentukan 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

Penghapusan modul ditolak saat VM sedang berjalan, jadi matikan tamu terlebih dahulu.

Mengapa sebagian besar penyedia VPS menonaktifkannya

• Live migration. Memberikan vmx berarti mengekspos model CPU yang memiliki flag tersebut. Guest yang bergantung pada fitur CPU tersebut tidak dapat dimigrasi dengan aman ke mesin yang CPU-nya tidak memilikinya. Host yang mengosongkan node dengan memigrasi pelanggan akan kehilangan kemampuan ini saat mengaktifkan nesting.
• Attack surface. Jalur nested VMX/SVM adalah salah satu kode paling rumit pada lapisan virtualisasi kernel, dengan riwayat CVE yang relevan.
• L0 mungkin bukan KVM. Jika systemd-detect-virt mencetak vmware, xen, atau microsoft, aturan nesting mengikuti stack tersebut, bukan KVM.

Flag tidak ada pada instance Anda? Hubungi dukungan (beberapa mengaktifkannya per-VM), pilih paket yang mendokumentasikan nesting, atau pindah ke server dedicated. Sisa panduan ini mengasumsikan akses root pada mesin yang menampilkan flag tersebut.

Menjalankan guest 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 grafis tidak diperlukan. Instalasi serial membutuhkan waktu lama, jadi jalankan di dalam shell yang persisten: workflow tmux yang menjaga sesi Claude Code tetap aktif di VPS yang sama akan menjaga konsol virt-install tetap terhubung meskipun koneksi SSH terputus. Jika --os-variant debian13 ditolak, osinfo-db Anda lebih lama dari versi rilis — jalankan osinfo-query os dan pilih nama yang tersedia. --cpu host-passthrough meneruskan vmx ke dalam L2, hanya diperlukan jika L2 harus melakukan virtualisasi secara berurutan. Gunakan virsh autostart guest1 agar guest aman saat booting.

Bus virtio pada disk dan NIC bukan sekadar hiasan: perangkat IDE dan e1000 emulasi melakukan trap ke hypervisor jauh lebih sering daripada antrean virtio, dan pada kondisi nesting, setiap trap akan memakan biaya dua kali lipat.

Networking: bagian yang dilewati tutorial

VPS Anda memiliki satu IP publik dan berada di belakang fabric yang memfilter alamat MAC yang tidak dikenal. Hal ini menyebabkan dua konsekuensi.

Menghubungkan guest L2 ke jaringan publik biasanya tidak akan berhasil. Jika Anda memasang br0 pada NIC publik dan memberikan MAC sendiri ke guest, Anda akan melihat ARP terkirim tetapi tidak ada balasan — switch penyedia membuang frame dari MAC yang tidak pernah mereka berikan kepada Anda. Jika ini masalah yang Anda alami, berhentilah melakukan debugging pada bridge; ini adalah mekanisme sistemnya.

Gunakan jaringan NAT sebagai gantinya. libvirt menyertakan default: virbr0, 192.168.122.0/24, dan lease dnsmasq, sehingga koneksi keluar langsung berfungsi. Untuk koneksi masuk, terminasi TLS pada L1 dan lakukan proxy — jalur sertifikat di bawah ini berasal dari penerbitan sertifikat 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 guest lease statis terlebih dahulu (virsh net-edit default) agar alamat pada proxy_pass tersebut tetap tetap.

Antarmuka manajemen tetap tidak terhubung ke internet: VNC pada port 5900 dan Proxmox web UI pada port 8006 harus berada pada loopback, yang diakses melalui SSH tunnel (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) atau melalui VPN WireGuard mandiri ke VPS, yang menempatkan seluruh rentang guest 192.168.122.0/24 dalam satu lompatan privat. Jaga firewall tetap ketat — sudo ufw allow 22,80,443/tcp, tidak ada yang lain. Jika guest kehilangan konektivitas keluar segera setelah Anda mengaktifkan ufw, penyebab umumnya adalah DEFAULT_FORWARD_POLICY="DROP" pada /etc/default/ufw — atur ke ACCEPT dan muat ulang ufw.

Proxmox pada VPS

Proxmox VE 9 berbasis Debian 13, sehingga dapat diinstal pada Debian VPS dengan menambahkan repositori pve-no-subscription dan paket proxmox-ve. Gunakan baris repositori dan keyring dari dokumentasi resmi Proxmox — URL yang disalin dari postingan blog lama akan menyebabkan instalasi gagal.

Masalah utama bukan pada paketnya. Proxmox memerlukan vmbr0 yang terhubung ke NIC fisik, yang akan menyebabkan masalah pemfilteran MAC seperti yang dijelaskan sebelumnya. Konfigurasi yang berhasil pada VPS adalah vmbr0 dengan NAT atau routing tanpa port fisik yang terhubung, tamu berada dalam rentang privat, serta menggunakan aturan DNAT atau reverse proxy pada host untuk layanan publik. Jika layanan publik berupa container dan bukan VM, Traefik yang mengelola banyak aplikasi dari satu file Docker Compose dapat menangani tugas routing yang sama dengan sertifikat otomatis. Lakukan snapshot /etc/network/interfaces terlebih dahulu: definisi bridge yang salah dapat menyebabkan Anda terkunci dari mesin yang tidak memiliki akses konsol.

Performa, secara jujur

Nested lebih lambat daripada single-level, dan mekanismenya bersifat spesifik, bukan difus: biaya tambahan bukan terletak pada akses memori, melainkan pada exit. Dengan adanya EPT/NPT, L0 mempertahankan shadow page tables untuk L2 dan pembacaan memori biasa berjalan pada kecepatan hardware. Operasi yang keluar dari guest mode menjadi mahal — I/O, timer interrupts, MMIO, inter-processor interrupts — karena L2 exit ditangani oleh L0 dan dapat diteruskan kembali melalui L1. Beban kerja CPU-bound pada data yang sudah ada di RAM terlihat mendekati native; beban kerja yang didominasi oleh syscall, paket, dan disk I/O akan merasakan dampak dari lapisan tersebut.

Jadi: gunakan perangkat virtio di mana saja. Dan file qcow2 Anda berada pada disk yang sudah divisualisasikan oleh penyedia layanan — dua lapisan thin-provisioning yang bertumpuk, di mana cache=none pada disk guest mencegah blok yang sama berada di dua page cache secara bersamaan. Tidak ada angka benchmark di sini: ukur beban kerja Anda sendiri pada instance Anda sendiri.

Mode kegagalan, dan string yang akan Anda lihat

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used dari kvm-ok. Modul tidak dimuat, atau flag tidak diekspos. Periksa /proc/cpuinfo terlebih dahulu.

kvm: disabled by bios di dmesg. Pada bare metal, aktifkan toggle VT-x/SVM di firmware. Di dalam VPS, ini berarti L0 tidak memberikan ekstensi tersebut, dan perintah apa pun di guest tidak akan mengubah hal itu.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. CPU yang dilihat kernel tidak memiliki vmx — ini adalah keputusan L0.

Could not access KVM kernel module: Permission denied. Masalah izin, bukan perangkat keras. ls -l /dev/kvm harus menunjukkan grup kvm, mode 660; tambahkan diri Anda ke grup tersebut dan buka shell login baru, karena keanggotaan grup tidak berlaku pada sesi yang sedang berjalan.

kvm: Device or resource busy saat QEMU dimulai. Hypervisor lain sedang menggunakan CPU: jalankan lsmod, cari vboxdrv atau modul VMware selain kvm_intel, lalu hapus modul yang tidak Anda inginkan.

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

Proxmox: KVM virtualisation configured, but not available. Guest mengaktifkan akselerasi KVM pada host yang tidak dapat menyediakannya. Perbaiki nesting, atau matikan fitur tersebut dan gunakan emulasi.

Android emulator: x86_64 emulation currently requires hardware acceleration! /dev/kvm lagi — biasanya masalah grup.

Tidak ada error sama sekali, dan semuanya sangat lambat. QEMU tanpa flag akselerator akan beralih ke TCG, emulator perangkat lunaknya. Ini berjalan dengan benar tetapi lambat — proses boot yang seharusnya hitungan detik menjadi hitungan menit. Gunakan -accel kvm secara eksplisit, agar QEMU berhenti dengan error alih-alih melakukan emulasi secara diam-diam.

Guest hilang saat sedang berjalan. Periksa dmesg untuk Out of memory: Killed process ... qemu-system-x86_64. Guest L2 adalah sebuah proses pada L1, dan OOM killer memperlakukannya seperti proses lainnya. RAM L2 diambil dari alokasi tetap L1 — tidak ada peminjaman dari host.

Cara pengoperasian: backup, upgrade, batasan

Backup. Menyalin file qcow2 dari guest yang sedang berjalan akan menghasilkan image yang korup. Gunakan virsh shutdown guest1 dan salin, atau ambil snapshot eksternal (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) agar proses tulis dialihkan ke overlay saat Anda menyalin base yang sudah statis, lalu gabungkan kembali dengan virsh blockcommit. Kirim salinan tersebut keluar dari VPS — snapshot pada disk yang sama tidak memberikan perlindungan apa pun.

Upgrade. apt full-upgrade menginstal modul kvm_intel/kvm_amd baru, tetapi kernel yang sedang berjalan tetap menggunakan modul lama hingga Anda melakukan reboot. Tetap instal kernel sebelumnya dan jalankan kembali kvm-ok setelah setiap perubahan kernel: host yang kembali tanpa vmx hanya berjarak satu entri boot untuk dapat berfungsi kembali.

Batasan skalabilitas. Satu IP publik berarti setiap layanan L2 menjangkau dunia melalui proxy atau aturan DNAT pada L1. Live migration tidak tersedia. Di bawah beban CPU (CPU contention), jalur nested exit adalah hal pertama yang terdampak. Dan hypervisor dengan beberapa guest adalah mesin yang RAM-nya sudah habis terpakai — VM nested tidak dapat melakukan overcommit untuk mengatasi alokasi tetap. Jika sebuah lab melampaui kapasitas tersebut, solusinya bukan menambah tumpukan nested; solusinya adalah perangkat khusus di mana Anda adalah L0 dan semua batasan ini tidak berlaku.

FAQ

Apakah saya memerlukan nested virtualization untuk menjalankan Docker di VPS?

Tidak. Container berbagi kernel VPS Anda dan tidak pernah membuka /dev/kvm. Instance standar tanpa flag vmx atau svm dapat menjalankan Docker dan Docker Compose dengan baik. Nesting hanya diperlukan jika Anda membutuhkan kernel kedua: lab Proxmox, guest Windows, Firecracker microVMs, emulator Android, atau runner CI yang melakukan boot pada image VM.

Bagaimana cara memeriksa apakah VPS saya mendukung nested virtualization?

Jalankan grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, lalu kvm-ok dari paket cpu-checker. Instance yang mendukung akan mencetak vmx (Intel) atau svm (AMD). kvm-ok akan melaporkan KVM acceleration can be used, dan /dev/kvm tersedia dengan group kvm dan mode 660. Abaikan /sys/module/kvm_intel/parameters/nested untuk pertanyaan ini — file tersebut mendeskripsikan modul KVM Anda sendiri, bukan apa yang diekspos oleh hypervisor penyedia layanan kepada Anda.

Mengapa sebagian besar penyedia VPS menonaktifkan nested virtualization?

Mengekspos vmx berarti memberikan model CPU yang memiliki flag tersebut kepada guest. Guest yang bergantung pada fitur CPU tersebut tidak dapat dimigrasikan secara live ke mesin dengan CPU yang tidak memilikinya — penyedia layanan yang memindahkan pelanggan antar node akan menghindari hal ini. Jalur kode VMX/SVM nested juga memiliki riwayat CVE yang panjang. Beberapa host masih mengaktifkannya per-VM berdasarkan permintaan, dan yang lainnya mencantumkan nesting sebagai fitur berbayar.

VM nested saya tidak memiliki jaringan pada bridge publik. Apa masalahnya?

Switch penyedia layanan membuang frame dari alamat MAC yang tidak pernah disewakan kepada Anda. Oleh karena itu, guest L2 yang di-bridge ke NIC publik akan mengirim ARP tetapi tidak menerima balasan. Berhenti melakukan debugging pada br0 — gunakan jaringan NAT libvirt default (virbr0, 192.168.122.0/24), berikan guest sebuah lease statis, dan publikasikan layanan publik melalui reverse proxy atau aturan DNAT pada VPS itu sendiri.

Seberapa lambat VM nested?

Penurunan performa terjadi pada VM exits, bukan pada akses memori. Dengan EPT/NPT aktif, operasi baca dan tulis biasa di dalam L2 berjalan pada kecepatan hardware. Namun, I/O, timer interrupts, MMIO, dan IPI ditangani oleh L0 dan mungkin dikembalikan melalui L1. Beban kerja yang bergantung pada CPU dengan data yang sudah ada di RAM akan terasa mendekati performa native; beban kerja yang berat pada syscall, paket, dan disk akan merasakan setiap lapisan. Gunakan perangkat virtio di mana saja dan cache=none pada disk guest, lalu ukur beban kerja Anda sendiri.