VPS üzerinde iç içe sanallaştırma ve Proxmox kurulumu

Kısa cevap

İç içe sanallaştırma (nested virtualization), bir sanal makine içerisinde çalışan hipervizördür: VPS'niz zaten bir konuk sistemdir ve siz onun üzerinde kendi konuklarınızı çalıştırmak istersiniz. Bu özellik, yalnızca sağlayıcınızın hipervizörü CPU'nun sanallaştırma uzantılarını örneğinize kasıtlı olarak açtığında çalışır; /proc/cpuinfo içerisinde vmx bayrağını (Intel için) veya svm (AMD için) kontrol edin. Eğer bunlardan hiçbiri görünmüyorsa, VPS içerisinde yapacağınız hiçbir yapılandırma sorunu çözmeyecektir.

Öncelikle bir beklenti yönetimi: Docker için bunların hiçbirine gerek yoktur. Konteynırlar VPS çekirdeğinizi paylaşır ve asla /dev/kvm ile etkileşime girmez. Eğer asıl amaç "sunucumda konteynırlar üzerinde birkaç servis çalıştırmak" ise, zaten ihtiyacınız olan her şeye sahipsiniz demektir. İç içe sanallaştırma; ikinci bir çekirdek, Proxmox laboratuvarı, Windows konuk sistemi, Firecracker microVM'leri, Android emülatörü, gerçek sanal makinelerden oluşan bir Kubernetes test ortamı veya sanal makine imajlarını boot eden CI çalıştırıcıları istediğinizde önem kazanır.

Aslında ne iç içe geçirilmektedir

Üç katman mevcuttur:

• L0, sağlayıcının fiziksel donanım üzerindeki hipervizörü. Buraya erişiminiz yoktur.
• L1, sizin VPS'iniz. L0 için bu sadece bir konuktur.
• L2, VPS'inizin içinde çalıştırmak istediğiniz sanal makinedir.

Donanım sanallaştırması; Intel tarafında VT-x (vmx bayrağı) ve EPT, AMD tarafında ise AMD-V / SVM (svm) ve RVI/NPT bileşenlerinden oluşur. Bir hipervizör, konuk moduna geçmek ve işlemcinin aynı anda iki sayfa tablosunu işlemesini sağlamak için bu komutları kullanır.

Hiçbiri yeniden girişli (re-entrant) olacak şekilde tasarlanmadığından, iç içe geçirme emüle edilir: L1 bir VMX komutu çalıştırdığında L0'a bir tuzak (trap) gönderilir ve L0, L1 adına L2 için gölge yapıları yönetir. KVM bunu başarılı bir şekilde yapar, ancak her çıkışta L0 fazladan işlem yükü altına girer; bu nedenle sağlayıcının bu özelliği onaylaması gerekir.

Hızlandırılmış bir L2 için iki koşulun aynı anda sağlanması gerekir:

1. L0'ın KVM modülü nested=1 ile yüklenmiş olmalıdır.
2. L0, VPS'inize bu bayrağı taşıyan bir CPU modeli vermelidir; bu, libvirt içinde <cpu mode='host-passthrough'/>, Proxmox içinde cpu: host, ham QEMU içinde ise -cpu host olarak tanımlanır. Genel bir emüle edilmiş model (qemu64, kvm64), iç içe geçirme küresel 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

Kullanılabilir bir örnek vmx veya svm çıktısı verir, kvm-ok komutu KVM acceleration can be used değerini döndürür ve /dev/kvm dosyası root:kvm modunda 660 olarak mevcuttur. Eğer bayrak mevcut ancak aygıt düğümü yoksa, modülü manuel olarak yükleyin ve çekirdek günlüğünü okuyun:

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

Bir dosya sürekli alıntılanır ve yaygın olarak yanlış yorumlanır:

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

VPS'nizin içinde yer alan bu ayar sizin KVM modülünüzün ayarıdır ve bir L2 konuğun üçüncü bir seviyeyi iç içe çalıştırıp çalıştıramayacağını yönetir. L0 katmanının sizin için iç içe sanallaştırmayı etkinleştirip etkinleştirmediği hakkında hiçbir bilgi vermez; bu sorunun cevabını /proc/cpuinfo ve kvm-ok verir. nested parametresi, tamamen size ait olan bir makinede ayarladığınız kontrol düğmesidir:

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

Bir sanal makine çalışırken modülün kaldırılması reddedilir, bu nedenle önce konukları kapatın.

Çoğu VPS sağlayıcısının bu özelliği neden kapalı tuttuğu

• Canlı taşıma (Live migration). Size vmx sunmak, bu bayrağı taşıyan bir CPU modelini dışa açmak anlamına gelir. Bu CPU özelliklerine bağımlı olan bir konuk sistem, bu özelliklere sahip olmayan bir makineye güvenli bir şekilde taşınamaz. Müşterilerini başka düğümlere taşıyarak boşaltma yapan bir ana makine, iç içe sanallaştırmayı (nesting) etkinleştirdiği anda bu yeteneğini kaybeder.
• Saldırı yüzeyi. İç içe geçmiş VMX/SVM yolları, çekirdeğin sanallaştırma katmanındaki en karmaşık kodlar arasındadır ve buna uygun bir CVE geçmişine sahiptir.
• L0 katmanı KVM olmayabilir. Eğer systemd-detect-virt komutu vmware, xen veya microsoft çıktısını veriyorsa, geçerli olan iç içe sanallaştırma kuralları KVM'nin değil, ilgili yığının kurallarıdır.

Örneğinizde bayrak görünmüyor mu? Destek ekibiyle görüşün (bazı sağlayıcılar bunu VM bazında etkinleştirir), iç içe sanallaştırmayı belgeleyen bir plan seçin veya fiziksel bir sunucuya geçin. Bu kılavuzun geri kalanı, bayrağı gösteren bir makinede root yetkisine sahip olduğunuz 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 bir oturuma gerek yoktur. Seri kurulum bir süre devam eder, bu nedenle kurulumu kalıcı bir kabuk içinde başlatın: Claude Code oturumlarını bir VPS üzerinde canlı tutan tmux iş akışı, bir SSH bağlantısı koptuğunda da virt-install konsolunun bağlı kalmasını sağlar. Eğer --os-variant debian13 reddedilirse, osinfo-db sürümünüz güncel değildir; osinfo-query os komutunu çalıştırın ve mevcut bir isim seçin. --cpu host-passthrough, vmx değerini L2 içine iletir; bu yalnızca L2'nin de sanallaştırma yapması gerekiyorsa gereklidir. virsh autostart guest1 ile konuğun güvenli önyükleme yapmasını sağlayın.

Disk ve NIC üzerindeki virtio veri yolu bir süs değildir: öykünülmüş IDE ve e1000 aygıtları, virtio kuyruklarına kıyasla hipervizöre çok daha sık takılır ve iç içe sanallaştırma (nesting) durumunda her takılma maliyeti iki katına çıkar.

Ağ yönetimi: eğitimlerin atladığı kısım

VPS'niz tek bir genel IP adresine sahiptir ve bilinmeyen MAC adreslerini filtreleyen bir ağ yapısının arkasında yer alır. Bu durum iki sonucu beraberinde getirir.

L2 misafirlerini genel ağa köprülemek (bridging) genellikle çalışmaz. Genel ağ arayüzüne br0 yerleştirip misafir sisteme kendi MAC adresini atarsanız, ARP isteklerinin dışarı çıktığını ancak hiçbir yanıt gelmediğini görürsünüz; sağlayıcının anahtarı (switch), kendisine kiralanmamış bir MAC adresinden gelen çerçeveleri (frame) düşürür. Belirtiniz buysa, köprü yapılandırmasında hata ayıklamayı bırakın; mekanizma bu şekildedir.

Bunun yerine NAT ağını kullanın. libvirt, default ile birlikte gelir: virbr0, 192.168.122.0/24, dnsmasq kiralamaları ve hemen çalışan dışa dönük bağlantılar. Gelen trafik için TLS sonlandırmasını L1 katmanında yapın ve proxy ile içeri aktarın; aşağıdaki sertifika yolları Nginx üzerinde Certbot ile Let's Encrypt sertifikası oluşturma rehberinden 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;
    }
}

Öncelikle misafir sisteme statik bir kiralama (virsh net-edit default) atayın, böylece proxy_pass içindeki adres sabit kalır.

Yönetim arayüzlerini internete kapalı tutun: 5900 portundaki VNC ve 8006 portundaki Proxmox web arayüzü loopback üzerinde kalmalıdır. Bunlara bir SSH tüneli (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) üzerinden veya VPS'ye self-hosted WireGuard VPN ile erişin; bu yöntem tüm 192.168.122.0/24 misafir ağını tek bir özel sıçrama (hop) mesafesine getirir. Güvenlik duvarını dar tutun, sadece sudo ufw allow 22,80,443/tcp açık kalsın. Eğer ufw'yi etkinleştirdikten hemen sonra misafir sistemler dışa dönük bağlantılarını kaybederse, bunun yaygın nedeni /etc/default/ufw içindeki DEFAULT_FORWARD_POLICY="DROP" ayarıdır; bunu ACCEPT olarak ayarlayın ve ufw'yi yeniden yükleyin.

VPS üzerinde Proxmox

Proxmox VE 9 temelinde Debian 13 barındırır, bu nedenle Debian tabanlı bir VPS üzerine kurulumu pve-no-subscription deposu ve proxmox-ve paketi eklenerek gerçekleştirilir. Depo ve anahtarlık satırlarını Proxmox'un güncel dokümantasyonundan alın; eski bir blog gönderisinden kopyalanan URL kurulumun başarısız olmasına neden olur. Proxmox'un kiralanmış bir donanım üzerinde çalıştırılmasının mantıklı olup olmadığı, aşağıdaki ağ yapılandırmasına vakit harcamadan önce değerlendirilmelidir; evdeki bir Proxmox sunucusu ile kiralanmış bir VPS arasındaki maliyet ve yetenek karşılaştırması, güç ve donanım hesaplamaları önceden yapılmış bir analiz sunar.

Paketlerin kurulumu zor kısım değildir. Proxmox, fiziksel bir ağ kartına (NIC) köprülenmiş bir vmbr0 yapısı bekler, bu da yukarıda bahsedilen MAC filtreleme engeline takılır. VPS üzerinde çalışan yapı, fiziksel bir porta bağlı olmayan NAT'lı veya yönlendirmeli bir vmbr0, özel bir IP aralığında çalışan konuk makineler ve herkese açık servisler için ana makine üzerinde DNAT kuralları veya bir reverse proxy kullanımıdır. Halka açık servisler VM yerine container olarak çalışıyorsa, tek bir Docker Compose dosyası üzerinden birden fazla uygulamayı yöneten Traefik, otomatik sertifikalarla aynı yönlendirme işini görür. İşleme başlamadan önce /etc/network/interfaces ile snapshot alın: hatalı bir köprü tanımı, konsol erişiminizin olmayabileceği bir makinede kilitli kalmanıza neden olabilir.

Performans, dürüst bir bakış

İç içe sanallaştırma (nested virtualization), tek seviyeli sanallaştırmaya göre daha yavaştır ve bu durumun mekanizması yaygın bir kanının aksine bellek erişiminden ziyade işlemci çıkışlarına (exits) dayanır. EPT/NPT mevcut olduğunda, L0 katmanı L2 için gölge sayfa tablolarını (shadow page tables) korur ve standart bellek okuma işlemleri donanım hızında gerçekleşir. Maliyetli olan işlemler; I/O, zamanlayıcı kesmeleri, MMIO, işlemciler arası kesmeler gibi konuk modundan çıkışı gerektiren her türlü operasyondur; çünkü bir L2 çıkışı L0 tarafından işlenir ve L1'e geri yansıtılması gerekebilir. RAM'de halihazırda bulunan veriler üzerinde yapılan CPU yoğunluklu işler yerel (native) performansa yakın seyreder; ancak sistem çağrıları, paket trafiği ve disk I/O işlemlerinin baskın olduğu her türlü iş yükü katmanların etkisini hissettirir.

Bu nedenle: her yerde virtio aygıtlarını kullanın. Ayrıca qcow2 dosyanız, sağlayıcının halihazırda sanallaştırdığı bir disk üzerinde bulunuyorsa, iki ince provizyon (thin-provisioning) katmanı üst üste binmiş demektir; bu durumda konuk disk üzerindeki cache=none kullanımı, aynı blokların iki farklı sayfa önbelleğinde (page cache) aynı anda tutulmasını engeller. Burada herhangi bir kıyaslama verisi sunulmamıştır: kendi iş yükünüzü kendi örneğiniz üzerinde ölçün.

Hata modları ve karşılaşacağınız dizgeler

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used, kvm-ok kaynağından. Modül yüklenmemiş veya bayrak (flag) dışa aktarılmamış olabilir. Öncelikle /proc/cpuinfo kontrol edilmelidir.

dmesg içinde kvm: disabled by bios. Fiziksel sunucularda (bare metal), firmware üzerinden VT-x/SVM ayarını etkinleştirin. Bir VPS içinde bu durum, L0 katmanının size bu uzantıları sağlamadığı anlamına gelir; konuk (guest) sistemde yapacağınız hiçbir değişiklik bunu düzeltmeyecektir.

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

Could not access KVM kernel module: Permission denied. Donanım değil, izin sorunudur. ls -l /dev/kvm, kvm grubunu ve 660 modunu göstermelidir; kendinizi bu gruba ekleyin ve yeni bir oturum kabuğu başlatın, çünkü grup üyeliği halihazırda çalışan oturumlara uygulanmaz.

QEMU başlarken kvm: Device or resource busy. Başka bir hipervizör modülü işlemciyi tutmaktadır: lsmod komutunu çalıştırın, kvm_intel yanında vboxdrv veya VMware modüllerini arayın ve istemediğiniz modülü kaldırın.

virsh kaynağından /var/run/libvirt/libvirt-sock: No such file or directory. Servis (daemon) çalışmıyor: sudo systemctl enable --now libvirtd komutunu kullanın.

Proxmox: KVM virtualisation configured, but not available. Bir konuk sistem, KVM hızlandırmasını sağlayamayan bir ana makinede (host) bu özelliği etkinleştirmiştir. İç içe sanallaştırmayı (nesting) düzeltin veya özelliği devre dışı bırakıp emülasyonu kabul edin.

Android emulator: x86_64 emulation currently requires hardware acceleration! Yine /dev/kvm durumu; genellikle grup izinleri ile ilgilidir.

Hiçbir hata yok ancak her şey çok yavaş. Hızlandırıcı bayrağı olmayan QEMU, yazılım emülatörü olan TCG'ye geri döner. Doğru çalışır ancak yavaştır; saniyeler süren bir önyükleme süreci dakikalar sürmeye başlar. -accel kvm bayrağını açıkça belirtin; böylece QEMU sessizce emülasyon yapmak yerine bir hata ile duracaktır.

Konuk sistem çalışma sırasında kayboluyor. dmesg içinde Out of memory: Killed process ... qemu-system-x86_64 ifadesini arayın. Bir L2 konuğu, L1 üzerinde bir süreçtir (process) ve OOM killer onu diğer süreçler gibi değerlendirir. L2 belleği, L1'in sabit tahsisinden karşılanır; ana makineden ödünç alma yapılmaz.

İşletim: yedeklemeler, yükseltmeler, limitler

Yedeklemeler. Çalışan bir konuğun qcow2 dosyasını kopyalamak bozuk bir imaj oluşturur. Ya virsh shutdown guest1 komutunu kullanıp kopyalayın ya da harici bir anlık görüntü (snapshot) alın (virsh snapshot-create-as guest1 snap1 --disk-only --atomic). Böylece yazma işlemleri bir katmana (overlay) yönlendirilirken siz statik hale gelen taban imajı kopyalayabilir ve ardından virsh blockcommit ile işlemi birleştirebilirsiniz. Kopyaları VPS dışına gönderin; aynı disk üzerindeki bir anlık görüntü hiçbir şeye karşı koruma sağlamaz.

Yükseltmeler. apt full-upgrade yeni kvm_intel/kvm_amd modüllerini yükler, ancak çalışan çekirdek siz yeniden başlatana kadar eskilerini kullanmaya devam eder. Önceki çekirdeği yüklü tutun ve her çekirdek değişikliğinden sonra kvm-ok komutunu tekrar çalıştırın: vmx olmadan açılan bir ana makine, çalışan bir sisteme dönmek için yalnızca bir önyükleme girişi uzağınızdadır.

Ölçeklemenin sınırları. Tek bir genel IP adresi, her L2 servisinin dünyaya bir proxy veya L1 üzerindeki bir DNAT kuralı aracılığıyla ulaşması anlamına gelir. Canlı taşıma (live migration) bu yapıda mümkün değildir. CPU çekişmesi durumunda, iç içe geçmiş çıkış yolu (nested exit path) ilk etkilenen kısımdır. Birden fazla konuğa sahip bir hipervizör, RAM'ini zaten harcamış olduğunuz bir makinedir; iç içe geçmiş sanal makineler, sabit bir tahsisatın ötesine geçerek aşırı taahhütte (overcommit) bulunamazlar. Bir laboratuvar bu yapıyı aştığında çözüm, daha büyük bir iç içe geçmiş yığın oluşturmak değildir; çözüm, L0 seviyesinde olduğunuz ve bunların hiçbirinin geçerli olmadığı özel bir fiziksel sunucudur.

FAQ

Bir VPS üzerinde Docker çalıştırmak için iç içe sanallaştırmaya (nested virtualization) ihtiyacım var mı?

Hayır. Container'lar VPS çekirdeğinizi paylaşır ve asla /dev/kvm açmazlar; bu nedenle vmx veya svm bayrağı olmayan standart bir sunucu, Docker ve Docker Compose'u sorunsuz çalıştırır. İç içe sanallaştırma yalnızca ikinci bir çekirdeğe ihtiyaç duyduğunuzda gereklidir: Proxmox laboratuvarı, Windows konuk işletim sistemi, Firecracker microVM'ler, Android emülatörü veya VM imajlarını önyükleyen CI çalıştırıcıları gibi.

VPS'imin iç içe sanallaştırmayı destekleyip desteklemediğini nasıl kontrol ederim?

Önce grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, ardından cpu-checker paketinden kvm-ok komutunu çalıştırın. Kullanılabilir bir sunucu vmx (Intel) veya svm (AMD) çıktısı verir, kvm-ok komutu KVM acceleration can be used değerini 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 kendi KVM modülünüzü tanımlar, sağlayıcının hipervizörünün size sunduğu özellikleri değil.

Çoğu VPS sağlayıcısı neden iç içe sanallaştırmayı devre dışı bırakır?

vmx özelliğini sunmak, konuk işletim sistemine bu bayrağı taşıyan bir CPU modeli vermek demektir. Bu CPU özelliklerine bağımlı olan bir konuk işletim sistemi, bu özelliklere sahip olmayan bir makineye canlı olarak taşınamaz (live-migration). Müşterilerini farklı düğümlere taşıyarak sunucuları boşaltan bir sağlayıcı bu yetenekten vazgeçmiş olur. İç içe VMX/SVM kod yolları ayrıca uzun bir CVE geçmişine sahiptir. Bazı sağlayıcılar talep üzerine VM bazında bu özelliği açar, bazıları ise bunu bir plan özelliği olarak dokümante eder.

İç içe sanallaştırılmış VM'imin genel köprü (public bridge) üzerinde ağı yok. Sorun nedir?

Sağlayıcının anahtarı (switch), kendisine kiralamadığınız bir MAC adresinden gelen çerçeveleri (frame) düşürür. Bu nedenle genel ağ kartına (NIC) köprülenmiş bir L2 konuğu ARP isteği gönderir ancak yanıt alamaz. br0 üzerinde hata ayıklamayı bırakın, libvirt'in NAT default ağını (virbr0, 192.168.122.0/24) kullanın, konuk işletim sistemine statik bir kiralama atayın ve genel erişime açık her şeyi VPS üzerinde bir reverse proxy veya DNAT kuralı ile yayınlayın.

İç içe sanallaştırılmış bir VM ne kadar yavaştır?

Maliyet bellek erişiminde değil, VM çıkışlarında (VM exits) oluşur. EPT/NPT aktifken, L2 içindeki olağan okuma ve yazma işlemleri donanım hızında çalışır; ancak G/Ç, zamanlayıcı kesmeleri, MMIO ve IPI işlemleri L0 tarafından yönetilir ve L1 üzerinden geri dönebilir. RAM'deki veriler üzerinde yapılan CPU yoğunluklu işler yerel hıza yakın görünür; sistem çağrısı, paket ve disk yoğunluklu iş yükleri ise her katmanı hisseder. Her yerde virtio aygıtlarını ve konuk disklerinde cache=none kullanın, ardından kendi iş yükünüzü ölçün.