VPS üzerinde Proxmox çalıştırılır mı?

Kısa cevap

Nested virtualization, bir sanal makine içinde çalışan bir hypervisor'dır: VPS'iniz zaten bir konuktur ve kendi konuklarını barındırması istenmektedir. Bu işlem, yalnızca sağlayıcınızın hypervisor'ı CPU sanallaştırma uzantılarını instance'ınıza bilerek açtığında çalışır — vmx flag'i için /proc/cpuinfo (Intel) veya svm (AMD) kontrol edilmelidir; eğer ikisi de görünmüyorsa, VPS içinde yapılan hiçbir yapılandırma sorunu çözmeyecektir.

Öncelikle bir beklenti netleştirmesi: Docker bunlardan hiçbirine ihtiyaç duymaz. Konteynerlar VPS kernel'ını paylaşır ve /dev/kvm ile hiçbir şekilde etkileşime girmez. Eğer asıl hedef "sunucumda konteynerlar içinde birkaç servis çalıştırmak" ise, ihtiyacınız olan şeye zaten sahipsiniz. Nesting işlemi, bir ikinci kernel istendiğinde önem kazanır — Proxmox laboratuvarı, bir Windows konuğu, Firecracker microVM'leri, bir Android emülatörü, gerçek VM'lerden oluşan bir Kubernetes test ortamı veya VM imajlarını başlatan CI runner'lar gibi.

Aslında iç içe geçen nedir

Üç katman:

• L0 — fiziksel makinedeki sağlayıcı hypervisor'ı. Bu katmana erişiminiz yoktur.
• L1 — VPS'iniz. L0 için bu sadece bir guest'tir.
• L2 — VPS'iniz içinde çalıştırmak istediğiniz VM.

Donanım sanallaştırması; Intel üzerinde VT-x (vmx flag'i) ve EPT, AMD üzerinde ise AMD-V / SVM (svm) ve RVI/NPT kullanır. Bir hypervisor, guest mode'a girmek ve CPU'nun aynı anda iki page table üzerinden ilerlemesini sağlamak için bu komutları kullanır.

Hiçbiri re-entrant olacak şekilde tasarlanmamıştır, bu nedenle nesting emüle edilir: L1 bir VMX komutu çalıştırdığında, L1 adına L2 için shadow yapılarını koruyan L0'a trap yapılır. KVM bunu başarılı bir şekilde yapar, ancak her exit işleminde L0 ek iş yükü üstlenir; bu nedenle sağlayıcının bu özelliği seçmesi (opt in) gerekir.

Hızlandırılmış bir L2 için şu iki koşulun her ikisi de sağlanmalıdır:

1. L0'ın KVM modülü nested=1 ile yüklenmiş olmalıdır.
2. L0, VPS'inize ilgili flag'i taşıyan bir CPU modeli vermelidir — libvirt'te <cpu mode='host-passthrough'/>, Proxmox'ta cpu: host, ham QEMU'da ise -cpu host. Genel bir emüle edilmiş model (qemu64, kvm64), nesting global olarak açık olsa bile vmx özelliğini gizler.

VPS durumunuzu bir dakikada kontrol edin

# 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

Çalışan bir instance vmx veya svm çıktısı verir, kvm-ok ise KVM acceleration can be used çıktısını üretir. /dev/kvm cihazı, root:kvm modunda 660 olarak mevcuttur. Eğer flag mevcut olmasına rağmen device node bulunmuyorsa, modülü manuel olarak yükleyin ve kernel loglarını inceleyin:

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

Sürekli alıntılanan ancak yaygın olarak yanlış anlaşılan bir dosya şudur:

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

VPS içerisindeki bu ayar, sizin KVM modülünüze aittir ve bir L2 guest'in üçüncü bir seviyeyi nest edip edemeyeceğini belirler. Bu ayar, L0'ın sizin için nesting özelliğini etkinleştirip etkinleştirmediği hakkında bilgi vermez; bu sorunun cevabını /proc/cpuinfo ve kvm-ok verir. nested parametresi, doğrudan sahibi olduğunuz bir makinede ayarlayabileceğiniz parametredir:

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

Bir VM çalışırken modülün kaldırılması reddedilir; bu nedenle önce guest sistemleri kapatın.

Çoğu VPS sağlayıcısının bunu kapalı tutma nedenleri

• Live migration. vmx özelliğinin sağlanması, ilgili flag'e sahip bir CPU modelinin açığa çıkması anlamına gelir. Bu CPU özelliklerine bağımlı bir guest, bu özelliklerin bulunmadığı bir makineye güvenli bir şekilde migrate edilemez. Müşterileri migrate ederek node kapasitesini optimize eden bir host, nesting özelliğini etkinleştirdiği anda bu yeteneği kaybeder.
• Attack surface. Nested VMX/SVM yolları, kernel'ın sanallaştırma katmanındaki en karmaşık kodlar arasındadır ve buna bağlı bir CVE geçmişine sahiptir.
• L0 may not be KVM. Eğer systemd-detect-virt çıktısı vmware, xen veya microsoft ise, nesting kuralları KVM'e değil, o stack'e aittir.

Instance üzerinde flag görünmüyorsa; destek ekibine danışın (bazıları VM başına etkinleştirir), nesting özelliğini belgeleyen bir plan seçin veya dedicated bir sunucuya geçin. Bu dokümanın geri kalanı, flag gösteren bir makinede root yetkisine sahip olunduğu varsayımıyla hazırlanmıştır.

libvirt ile L2 konuk çalıştırma

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'

Grafiksel oturuma ihtiyaç yoktur. Seri kurulum bir süre devam eder, bu nedenle işlemi kalıcı bir kabuk içinde başlatın: Claude Code oturumlarını VPS üzerinde canlı tutan tmux iş akışı ile aynı yöntem, kopan bir SSH bağlantısında virt-install konsoluna bağlı kalmanızı sağlar. Eğer --os-variant debian13 reddedilirse, osinfo-db sürümünüz sürümden eskidir; osinfo-query os komutunu çalıştırın ve mevcut bir isim seçin. --cpu host-passthrough, vmx trafiğini L2 içine iletir; bu yalnızca L2'nin kendi içinde sanallaştırma yapması gerektiğinde gereklidir. Konuğu virsh autostart guest1 ile güvenli önyükleme (boot-safe) moduna getirin.

Disk ve NIC üzerindeki virtio veri yolu sadece görsel bir öğe değildir: emüle edilmiş IDE ve e1000 cihazları, virtio kuyruklarına kıyasla hipervizöre çok daha sık trap (yakalama) gönderir ve iç içe sanallaştırma (nesting) altında her trap iki kat maliyet oluşturur.

Ağ Yapılandırması: Eğitimlerde atlanan bölüm

VPS cihazınızın bir adet genel IP adresi vardır ve bilinmeyen MAC adreslerini filtreleyen bir ağ yapısının arkasında yer alır. Bu durum iki sonuca yol açar.

L2 konuk makineleri genel ağa köprülemek (bridging) genellikle çalışmayacaktır. Kamuya açık NIC üzerine br0 tanımlayıp konuk makineye kendi MAC adresini verirseniz, ARP paketlerinin gönderildiğini ancak yanıt gelmediğini göreceksiniz; sağlayıcının anahtarı (switch), size tahsis edilmemiş bir MAC adresinden gelen paketleri düşürür. Eğer bu sorunu yaşıyorsanız, köprü yapılandırmasını incelemeyi bırakın; sorun bu mekanizmadan kaynaklanmaktadır.

Bunun yerine NAT ağını kullanın. libvirt ile birlikte default: virbr0, 192.168.122.0/24 ve dnsmasq kiralama özellikleri gelir; bu sayede dışa giden bağlantılar hemen çalışır. Gelen bağlantılar için TLS işlemini L1 katmanında sonlandırın ve proxy kullanarak iletin; aşağıdaki sertifika yolları Nginx üzerinde Certbot ile Let's Encrypt sertifikası oluşturma içeriğinden alınmıştır:

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;
    }
}

Adresin proxy_pass içerisinde sabit kalması için konuk makineye önce statik bir kiralama (virsh net-edit default) tanımlayın.

Yönetim arayüzleri internete kapalı tutulmalıdır: 5900 portundaki VNC ve 8006 portundaki Proxmox web arayüzü loopback üzerinde kalmalı; bunlara bir SSH tüneli (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) veya VPS'e self-hosted WireGuard VPN aracılığıyla erişilmelidir. Bu yöntem, tüm 192.168.122.0/24 konuk aralığını tek bir özel yönlendirme (hop) uzağa taşır. Güvenlik duvarını kısıtlı tutun — sadece sudo ufw allow 22,80,443/tcp açık olmalı, başka hiçbir şey değil. Eğer ufw etkinleştirildikten hemen sonra konuk makineler dış bağlantı yeteneğini kaybederse, bunun yaygın sebebi /etc/default/ufw içindeki DEFAULT_FORWARD_POLICY="DROP" ayarıdır — bu ayarı ACCEPT olarak değiştirin ve ufw'yi yeniden yükleyin.

VPS üzerinde Proxmox

Proxmox VE 9, temelinde Debian 13 kullanır. Bu nedenle, pve-no-subscription deposu ve proxmox-ve paketi eklenerek bir Debian VPS üzerine kurulabilir. Depo ve keyring satırlarını Proxmox'un kendi güncel dokümantasyonundan alın; eski bir blog yazısından kopyalanan bir URL kurulumun hata vermesine neden olur.

Paketler zorlu kısım değildir. Proxmox, fiziksel bir NIC'e köprülenmiş (bridged) bir vmbr0 bekler; bu durum yukarıda belirtilen MAC filtreleme sorununa yol açar. VPS üzerinde çalışan yöntem; fiziksel bir port bağlı olmayan, NAT uygulanmış veya yönlendirilmiş bir vmbr0 yapısıdır. Misafir makineler özel bir aralıkta bulunmalıdır. Dış dünyaya açık servisler için ana makinede DNAT kuralları veya bir reverse proxy kullanılmalıdır. Dış dünyaya açık servisler VM yerine container ise, tek bir Docker Compose dosyasından birden fazla uygulamayı yöneten Traefik, otomatik sertifikalarla aynı yönlendirme işlevini görür. Önce /etc/network/interfaces snapshot alın: hatalı bir bridge tanımı, konsol erişimi olmayan bir makinede sistemin kilitlenmesine neden olur.

Performans, dürüstçe

Nested yapı, tek seviyeli yapıdan daha yavaştır ve maliyetin kaynağı yaygın değil, spesifiktir: maliyet bellek erişiminden değil, çıkışlardan (exits) kaynaklanır. EPT/NPT mevcut olduğunda, L0, L2 için gölge sayfa tablolarını (shadow page tables) tutar ve standart bellek okumaları donanım hızında gerçekleşir. Maliyetli olan, konuk modundan (guest mode) ayrılan her işlemdir; I/O, zamanlayıcı kesmeleri (timer interrupts), MMIO ve işlemciler arası kesmeler (inter-processor interrupts) bu kapsamdadır. Çünkü bir L2 çıkışı L0 tarafından işlenir ve L1 üzerinden geri yansıtılabilir. RAM içindeki veriler üzerinde yapılan CPU odaklı işler yerel performansa yakındır; syscall, paket ve disk I/O işlemlerinin yoğun olduğu durumlarda ise katmanlar hissedilir.

Sonuç olarak: her yerde virtio cihazları kullanılmalıdır. qcow2 dosyanız, sağlayıcının halihazırda sanallaştırdığı bir disk üzerinde bulunur; burada iki ince yapılandırmalı (thin-provisioning) katman üst üste biner ve konuk diskindeki cache=none, aynı blokların aynı anda iki sayfa önbelleğinde (page cache) bulunmasını engeller. Burada benchmark verisi verilmemiştir: kendi iş yükünüzü kendi örneğiniz üzerinde ölçünüz.

Hata modları ve göreceğiniz dizeler

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used (kvm-ok kaynaklı). Modül yüklenmemiş olabilir veya flag dışarı açılmamış olabilir. Önce /proc/cpuinfo kontrol edilmelidir.

kvm: disabled by bios (dmesg içinde). Bare metal sistemlerde, firmware üzerindeki VT-x/SVM seçeneğini aktif hale getirin. Bir VPS içinde bu durum, L0'ın uzantıları sağlamadığı anlamına gelir; konuk işletim sisteminde yapılan hiçbir işlem bunu değiştirmez.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. Çekirdeğin gördüğü CPU, vmx özelliğine sahip değildir; bu durum yine bir L0 kararıdır.

Could not access KVM kernel module: Permission denied. Donanım değil, yetki sorunudur. ls -l /dev/kvm çıktısında grup kvm ve mod 660 görülmelidir; kendinizi bu gruba ekleyin ve yeni bir login shell başlatın, çünkü grup üyeliği halihazırda çalışan oturumlara uygulanmaz.

QEMU başlatılırken kvm: Device or resource busy. Başka bir hypervisor modülü CPU'yu meşgul ediyor: lsmod komutunu çalıştırın, vboxdrv veya VMware modüllerinin yanı sıra kvm_intel olup olmadığını kontrol edin ve istemediğiniz modülü kaldırın.

virsh kaynaklı /var/run/libvirt/libvirt-sock: No such file or directory. Daemon çalışmıyor: sudo systemctl enable --now libvirtd.

Proxmox: KVM virtualisation configured, but not available. Bir konuk, bu özelliği sağlayamayan bir host üzerinde KVM hızlandırması seçili olarak çalışıyor. Nesting ayarını düzeltin veya seçeneği kaldırarak emülasyonu kabul edin.

Android emulator: x86_64 emulation currently requires hardware acceleration! Yine /dev/kvm — genellikle grup kaynaklı bir sorun.

Hiçbir hata yok, ancak her şey çok yavaş. Hızlandırıcı flag'i olmayan QEMU, yazılımsal emülatörü olan TCG'ye geri döner. Bu durum teknik olarak doğrudur ancak yavaştır; saniyeler süren bir açılış dakikalar sürebilir. QEMU'nun sessizce emüle etmek yerine hata vererek durması için -accel kvm parametresini açıkça belirtin.

Çalışma sırasında konuk işletim sistemi kayboluyor. dmesg içinde Out of memory: Killed process ... qemu-system-x86_64 durumunu kontrol edin. Bir L2 konuğu, L1 üzerinde bir süreçtir ve OOM killer bunu diğer süreçler gibi ele alır. L2 RAM'i, L1'in sabit tahsisinden kullanılır; host'tan ödünç alma yapılamaz.

İşletim: yedeklemeler, yükseltmeler, limitler

Yedeklemeler. Çalışan bir guest'in qcow2 dosyasını kopyalamak bozuk bir imaj oluşturur. Ya virsh shutdown guest1 ve kopyala yöntemini kullanın ya da dış bir snapshot (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) alın; böylece siz statik hale gelen base dosyayı kopyalarken yazma işlemleri bir overlay dosyasına yönlendirilir, ardından virsh blockcommit ile birleştirilir. Kopyaları VPS dışına aktarın; aynı disk üzerindeki bir snapshot hiçbir şeye karşı koruma sağlamaz.

Yükseltmeler. apt full-upgrade yeni kvm_intel/kvm_amd modüllerini yükler, ancak çalışan kernel siz sistemi yeniden başlatana kadar eski modülleri tutmaya devam eder. Önceki kernel'ı yüklü tutun ve her kernel değişikliğinden sonra kvm-ok komutunu tekrar çalıştırın: vmx olmadan yeniden başlatılan bir host, tekrar çalışabilmek için sadece bir boot entry uzaklığındadır.

Ölçeklendirme sınırı. Tek bir public IP, her L2 servisinin L1 üzerindeki bir proxy veya DNAT kuralı aracılığıyla dünyaya ulaşması anlamına gelir. Live migration bu yapıda mevcut değildir. CPU contention durumunda, nested exit yolu etkilenen ilk bileşendir. Birden fazla guest barındıran bir hypervisor'da RAM kullanımı zaten tükenmiştir; nested VM'ler sabit bir tahsisat içinden overcommit yaparak çıkamazlar. Bir laboratuvar bu sınırları aştığında, çözüm daha derin bir nested stack kurmak değildir; çözüm, L0 olduğunuz ve bunların hiçbirinin geçerli olmadığı dedicated bir makinedir.

FAQ

VPS üzerinde Docker çalıştırmak için nested virtualization gerekli mi?

Hayır. Konteynerlar VPS çekirdeğini paylaşır ve /dev/kvm açmazlar. Bu nedenle, vmx veya svm flag'i bulunmayan standart bir instance üzerinde Docker ve Docker Compose sorunsuz çalışır. Nesting işlemi yalnızca ikinci bir çekirdek istendiğinde gereklidir: Proxmox laboratuvarı, Windows guest, Firecracker microVM'ler, Android emülatörü veya VM imajlarını boot eden CI runner'lar.

VPS'imin nested virtualization destekleyip desteklemediğini nasıl kontrol ederim?

cpu-checker paketinden grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u ve ardından kvm-ok komutlarını çalıştırın. Kullanılabilir bir instance; Intel için vmx veya AMD için svm yazdırır, kvm-ok değeri KVM acceleration can be used raporlar ve /dev/kvm dosyası kvm grubu ve 660 modu ile mevcuttur. Bu soru için /sys/module/kvm_intel/parameters/nested dosyasını dikkate almayın; bu dosya sağlayıcının hypervisor'ının size sunduğu özellikleri değil, kendi KVM modülünüzü tanımlar.

Çoğu VPS sağlayıcısı neden nested virtualization özelliğini devre dışı bırakır?

vmx özelliğinin sunulması, guest makineye bu flag'i taşıyan bir CPU modeli verilmesi anlamına gelir. Bu CPU özelliklerine bağımlı bir guest makine, bu özelliklere sahip olmayan bir makineye live-migrate edilemez. Müşterileri taşıyarak node'ları boşaltan sağlayıcılar bu özelliği devre dışı bırakır. Ayrıca nested VMX/SVM kod yolları uzun bir CVE geçmişine sahiptir. Bazı hostlar talep üzerine VM başına bu özelliği etkinleştirir, diğerleri ise nesting işlemini planlı bir özellik olarak belgeler.

Nested VM'imin public bridge üzerinde ağ bağlantısı yok. Sorun nedir?

Sağlayıcının switch'i, size hiç kiralanmamış bir MAC adresinden gelen frame'leri düşürür. Bu nedenle, public NIC üzerine bridge edilmiş bir L2 guest, ARP gönderir ancak yanıt alamaz. br0 hata ayıklama işlemini bırakın; libvirt'in NAT default ağını (virbr0, 192.168.122.0/24) kullanın, guest makineye statik bir lease tanımlayın ve tüm public trafiği VPS üzerinde bir reverse proxy veya DNAT kuralı üzerinden yayınlayın.

Nested VM ne kadar yavaştır?

Performans kaybı bellek erişiminden değil, VM exit işlemlerinden kaynaklanır. EPT/NPT aktif olduğunda, L2 içindeki olağan okuma ve yazma işlemleri donanım hızında gerçekleşir; ancak I/O, timer interrupt'ları, MMIO ve IPI'lar L0 tarafından işlenir ve L1 üzerinden geri dönebilir. RAM içindeki verilerle yapılan CPU odaklı işler yerel performansa yakın görünür; syscall, paket ve disk yoğunluklu iş yükleri ise her katmanda yavaşlama hisseder. Her yerde virtio cihazlarını ve guest disklerinde cache=none kullanın, ardından kendi iş yükünüzü ölçün.