Nested Virtualization Nedir, Nasıl Etkinleştirilir

Bir sanal makinenin içinde Hyper-V rolünü açmaya çalıştığında ya da bir VDS üzerinde Docker Desktop kurmak istediğinde büyük ihtimalle şu mesajla karşılaştın: "Bu platform sanallaştırmayı desteklemiyor." Makinenin CPU'su modern, host'ta sanallaştırma açık, her şey yerinde görünüyor ama misafir işletim sistemi donanım sanallaştırma özelliklerini göremiyor. Çözüm, nested virtualization — yani iç içe sanallaştırma — özelliğini bilinçli olarak açmaktan geçiyor.

Bu yazıda iç içe sanallaştırmanın gerçekte ne olduğunu, CPU tarafında neyin gerekli olduğunu, KVM/Proxmox, VMware ESXi, Hyper-V ve masaüstü hipervizörlerinde nasıl etkinleştirileceğini, performans olarak ne ödediğini ve hangi özelliklerin bu modda çalışmadığını anlatacağım. Komutlar gerçek ve doğrudan uygulanabilir; sonunda da bu ayarı açtıktan sonra insanların en sık takıldığı noktaları topladım.

İç İçe Sanallaştırma Tam Olarak Nedir#

Terminoloji üç katman üzerinden konuşulur ve bunu oturtmak konuyu ciddi biçimde kolaylaştırır:

• L0 — fiziksel donanımın üzerinde çalışan hipervizör. ESXi host'un, Proxmox düğümün ya da Hyper-V sunucun.
• L1 — L0'ın çalıştırdığı sanal makine. Normalde burada bir işletim sistemi olur; iç içe sanallaştırmada burada bir hipervizör çalışır.
• L2 — L1'in içinde çalışan sanal makine. Asıl hedefin genellikle budur.

Normal şartlarda L0, donanımın sanallaştırma özelliklerini (Intel VT-x veya AMD-V) kendisi kullanır ve misafirlerine göstermez. Misafir işletim sistemi CPU özelliklerine baktığında sanallaştırma bayrağını göremez, dolayısıyla kendi hipervizörünü çalıştıramaz. İç içe sanallaştırma açıldığında L0, bu özellikleri L1'e sanallaştırarak sunar: L1 kendi sanal makinelerini yönetiyormuş gibi davranır, ama gerçekte her ayrıcalıklı işlem L0 tarafından yakalanıp yorumlanır.

İşin zor kısmı burada. CPU'nun sanallaştırma birimi tek katman için tasarlanmıştır; iki katmanı desteklemek, L0'ın L1'in tüm sanal makine kontrol yapılarını gölgelemesi (VMCS shadowing) ve bellek çevirisini iki kez yapması anlamına gelir. Modern işlemcilerde bu iş için donanım desteği var, yoksa maliyet kabul edilemez seviyeye çıkardı.

Donanım Tarafında Ne Gerekir#

İki şey lazım: temel sanallaştırma uzantısı ve ikinci seviye bellek çevirisi. İkincisi olmadan iç içe sanallaştırma teorik olarak mümkün olsa da kullanılabilir hızda değildir.

Linux host'ta desteğin var olup olmadığını tek komutla görürsün:

# CPU sanallaştırma bayrağı var mı (vmx = Intel, svm = AMD)
grep -E -o 'vmx|svm' /proc/cpuinfo | sort -u

# Intel'de iç içe sanallaştırma modül düzeyinde açık mı
cat /sys/module/kvm_intel/parameters/nested
# Y veya 1 dönmeli

# AMD'de
cat /sys/module/kvm_amd/parameters/nested

Komut hiçbir çıktı vermiyorsa iki ihtimal var: CPU gerçekten desteklemiyor ya da BIOS/UEFI'de sanallaştırma kapalı. İkincisi çok daha yaygındır; BIOS'ta ilgili ayarı açıp makineyi tamamen elektrikten keserek yeniden başlat.

KVM ve Proxmox Üzerinde Etkinleştirme#

KVM tarafında iç içe sanallaştırma modül parametresiyle kontrol edilir. Kalıcı hâle getirmek için modprobe yapılandırmasına yazman gerekir:

# Intel işlemcide kalıcı olarak aç
echo "options kvm_intel nested=1" | sudo tee /etc/modprobe.d/kvm-nested.conf

# AMD işlemcide
echo "options kvm_amd nested=1" | sudo tee /etc/modprobe.d/kvm-nested.conf

# Modülü yeniden yükle (üzerinde çalışan VM olmamalı)
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

# Doğrula
cat /sys/module/kvm_intel/parameters/nested

Modül kullanımdaysa kaldırılamaz; o durumda tüm sanal makineleri kapatıp tekrar dene ya da host'u yeniden başlat.

İkinci ve atlanması çok kolay adım, sanal makinenin CPU modelidir. Varsayılan olarak birçok kurulumda misafire genel bir CPU modeli sunulur ve bu model sanallaştırma bayrağını içermez. Misafirin bayrağı görebilmesi için CPU tipini host'un gerçek modeline geçirmen gerekir:

# Proxmox: VM'in CPU tipini host'a çevir
qm set 100 --cpu host

# Yapılandırmayı doğrula
qm config 100 | grep cpu

# Misafir içinde bayrağın göründüğünü kontrol et (VM açıldıktan sonra)
grep -E -o 'vmx|svm' /proc/cpuinfo | sort -u

cpu host ayarının bir bedeli var: sanal makine artık host CPU'sunun tam özellik setine bağlanır, dolayısıyla farklı nesil bir CPU'ya sahip başka bir düğüme canlı göç etmesi engellenebilir. Küme kuruyorsan bunu baştan planla.

VMware ESXi Üzerinde Etkinleştirme#

ESXi'de ayar sanal makine düzeyindedir ve makine kapalıyken yapılır. Host Client ya da vCenter üzerinden:

1. Sanal makineyi kapat.
2. Edit Settings → CPU bölümünü aç.
3. Hardware virtualization başlığındaki "Expose hardware assisted virtualization to the guest OS" kutusunu işaretle.
4. Kaydet ve makineyi başlat.

Aynı ayarı doğrudan yapılandırma dosyasına da yazabilirsin; komut satırından çalışıyorsan bu daha hızlıdır:

# VM'in vmx dosyasına parametreyi ekle (makine kapalıyken)
echo 'vhv.enable = "TRUE"' >> /vmfs/volumes/datastore1/web01/web01.vmx

# Değişikliğin görünmesi için VM'i yeniden kaydet
vim-cmd vmsvc/reload <VMID>

Sanal makinenin donanım sürümünün yeterince yeni olması gerekir; çok eski bir donanım sürümünde bu seçenek görünmez, makineyi önce yükseltmen gerekir. ESXi kurulumunun kendisiyle ilk kez uğraşıyorsan VMware ESXi kurulumu yazısı temel adımları anlatıyor.

Hyper-V Üzerinde Etkinleştirme#

Hyper-V'de ayar PowerShell ile yapılır ve birkaç ek kısıt getirir. Makine kapalı olmalıdır:

# Sanal makineyi kapat
Stop-VM -Name "lab01"

# İç içe sanallaştırmayı aç
Set-VMProcessor -VMName "lab01" -ExposeVirtualizationExtensions $true

# Dinamik bellek KAPALI olmalı, sabit bellek ver
Set-VMMemory -VMName "lab01" -DynamicMemoryEnabled $false -StartupBytes 8GB

# İç makinelerin (L2) ağa çıkabilmesi için MAC sahteciliğine izin ver
Set-VMNetworkAdapter -VMName "lab01" -MacAddressSpoofing On

# Makineyi başlat ve ayarı doğrula
Start-VM -Name "lab01"
Get-VMProcessor -VMName "lab01" | Select-Object Name, ExposeVirtualizationExtensions

MAC sahteciliği satırını atlama. L2 makinelerin paketleri, L1'in sanal ağ kartından farklı MAC adresleriyle çıkar; varsayılan olarak Hyper-V bunu güvenlik gereği engeller ve iç makinelerin ağı hiç çalışmaz. "Sanal makine kuruldu ama internete çıkmıyor" şikâyetinin bu senaryodaki karşılığı neredeyse her zaman budur.

Hyper-V'de iç içe sanallaştırma açık olan bir sanal makinede bazı özellikler kullanılamaz: dinamik bellek, çalışırken bellek boyutu değiştirme, canlı göç ve bazı kontrol noktası senaryoları devre dışı kalır. Bu, üretim iş yüklerini böyle bir makineye koymamak için yeterli bir sebeptir. Hyper-V rolünün kurulumunu Windows Server'da Hyper-V kurulumu yazısında ayrıntısıyla anlattım.

Masaüstü Hipervizörleri ve Bulut Sağlayıcıları#

Masaüstü tarafında ayar oldukça basittir:

# VirtualBox: iç içe donanım sanallaştırmasını aç (makine kapalıyken)
VBoxManage modifyvm "lab01" --nested-hw-virt on

# Ayarı doğrula
VBoxManage showvminfo "lab01" | grep -i "nested"

VMware Workstation'da aynı işi arayüzden yaparsın: sanal makine ayarlarında Processors bölümündeki "Virtualize Intel VT-x/EPT or AMD-V/RVI" kutusunu işaretlemek yeterlidir. İki ürünün genel karşılaştırmasını VirtualBox ve VMware Workstation karşılaştırması yazısında bulabilirsin.

Bulut ve barındırma tarafında durum farklıdır ve burası çok soru alan bir konu: çoğu sağlayıcı sanal sunucularında iç içe sanallaştırmayı varsayılan olarak kapalı tutar. Sebebi hem performans hem güvenliktir; L1'e sanallaştırma yetkisi vermek hipervizörün saldırı yüzeyini genişletir. Bu yüzden standart bir VPS üzerinde Hyper-V rolü ya da KVM kurmayı denediğinde çalışmaz. Bu ihtiyacın varsa ya fiziksel bir makineye ya da bu özelliğin açıkça etkinleştirildiği bir ürüne yönelmen gerekir; bizde bu senaryo için nested sunucu paketleri var ve dedicated sunucu tarafında zaten tam donanım kontrolü sende olur.

Performans Maliyeti ve Sınırlar#

İç içe sanallaştırma bedava değildir. Maliyetin büyüklüğü tamamen iş yükünün karakterine bağlıdır:

Pratik sonuç şu: L2 içinde bir derleme işi ya da bir hesaplama çalıştırmak makul hızda olur, ama L2 içinde yoğun bir veritabanı çalıştırmak belirgin biçimde yavaştır. Bu yüzden iç içe sanallaştırma bir üretim mimarisi değil, bir laboratuvar ve test aracıdır.

Kaynak planlaması yaparken de üç katmanın da payı olduğunu unutma. L1'e verdiğin bellek, L2'lerin toplam belleğinden fazla olmalıdır; L1 hipervizörünün kendisi de bellek tüketir. CPU tarafında ise aşırı dağıtımın ne yaptığını CPU overcommit nedir yazısında ayrıntılı anlattım — iç içe kurulumlarda o etki iki kat hissedilir.

Sık Yapılan Hatalar#

CPU modelini varsayılanda bırakmak. Modül parametresini açıp CPU tipini host yapmayı unutursan misafir yine sanallaştırma bayrağını görmez. En sık yapılan hata budur.

Makine açıkken ayar yapmaya çalışmak. Hem KVM modül parametresi hem ESXi ve Hyper-V ayarları makine kapalıyken uygulanır. Açıkken yapılan değişiklik ya reddedilir ya da bir sonraki açılışa kadar etkisiz kalır.

Hyper-V'de MAC sahteciliğini açmamak. İç makineler kurulur, açılır ama ağa çıkamaz. Saatlerce ağ yapılandırmasında hata arayan çok kişi gördüm.

Dinamik belleği kapatmamak. Hyper-V bu modda dinamik belleği desteklemez; ayarı kapatmadan makineyi başlatmaya çalışırsan hata alırsın.

Bulut sunucusunda çalışmasını beklemek. Sağlayıcı özelliği açmadıysa hiçbir ayar işe yaramaz; sorunu misafir tarafında aramak zaman kaybıdır. Önce grep -E -o 'vmx|svm' /proc/cpuinfo çıktısına bak; boşsa konu sende değil.

Üretim yükünü L2'ye koymak. Test amaçlı kurulan bir iç içe ortam zamanla üretim gibi kullanılmaya başlanır ve performans şikâyetleri gelir. Bu mimari kalıcı iş yükleri için tasarlanmadı.

Sıkça Sorulan Sorular#

İç içe sanallaştırma her CPU'da çalışır mı#

Son on yılın sunucu ve masaüstü işlemcilerinin büyük çoğunluğu gerekli özellikleri destekler; Intel tarafında VT-x ve EPT, AMD tarafında AMD-V ve NPT gerekir. Çok eski işlemcilerde ikinci seviye bellek çevirisi bulunmadığı için özellik ya hiç çalışmaz ya da kullanılamayacak kadar yavaş olur. Desteği doğrulamanın en hızlı yolu host üzerinde CPU bayraklarına bakmaktır.

Neden VPS'imde çalışmıyor#

Çoğu barındırma sağlayıcısı, sanal sunucularında iç içe sanallaştırmayı kapalı tutar. Bunun sebebi hem performans kaybı hem de hipervizörün saldırı yüzeyini genişletmemektir. Bu durumda misafir içinde yapacağın hiçbir ayar sonucu değiştirmez, çünkü CPU sanallaştırma bayrağı sana hiç sunulmamıştır. İhtiyacın varsa özelliği açıkça destekleyen bir ürüne ya da fiziksel sunucuya geçmen gerekir.

Performans kaybı ne kadar olur#

Tek bir rakam vermek doğru olmaz çünkü kayıp tamamen iş yüküne bağlıdır. Saf hesaplama yapan işlerde fark küçüktür; yoğun disk ve ağ işlemi yapan, sık sistem çağrısı üreten iş yüklerinde ise belirgin biçimde hissedilir çünkü her işlem iki sanallaştırma katmanından geçer. Genel kural: laboratuvar ve eğitim için gayet kullanışlı, üretim veritabanı için uygun değil.

Docker çalıştırmak için buna ihtiyacım var mı#

Linux üzerinde Docker konteynerleri çalıştırmak için iç içe sanallaştırmaya ihtiyacın yoktur; konteynerler ayrı bir çekirdek değil, aynı çekirdeği paylaşan izole süreçlerdir. İhtiyaç, Docker'ın bir sanal makine içinde çalıştığı senaryolarda doğar: Windows üzerinde WSL2 tabanlı Docker Desktop ya da macOS'taki sanal makine tabanlı çalıştırma gibi. Yani Linux VDS'inde Docker sorunsuz çalışır, Windows sanal makinesinde Docker Desktop için özelliğe ihtiyacın olur.

Etkinleştirdikten sonra canlı göç yapabilir miyim#

Platforma göre değişir ama genel eğilim kısıtlayıcıdır. Hyper-V'de iç içe sanallaştırma açık bir makine canlı göç edemez. KVM tarafında CPU tipini host yapman gerektiği için, makine yalnızca aynı CPU nesline sahip düğümlere taşınabilir. Bu yüzden iç içe sanallaştırma kullanan makineleri, esnek biçimde taşınması gereken üretim iş yüklerinden ayrı tutmak doğru olur.

Ayarı açtım ama misafir hâlâ göremiyor, ne yapmalıyım#

Sırayla üç şeyi kontrol et. Birincisi, host üzerinde modül parametresinin gerçekten etkin olduğunu doğrula (/sys/module/kvm_intel/parameters/nested). İkincisi, sanal makinenin CPU modelinin host'un gerçek modeline ayarlandığından emin ol — genel CPU modelleri sanallaştırma bayrağını taşımaz. Üçüncüsü, ayarı yaptıktan sonra makineyi tamamen kapatıp yeniden başlattığını doğrula; yeniden başlatma tek başına yetmez, güç döngüsü gerekir.

Kapanış#

İç içe sanallaştırma, doğru kurgulandığında bir laboratuvarı olağanüstü esnek hâle getiren bir özellik. Aklında kalması gereken dört şey: özellik hem host düzeyinde (modül parametresi ya da VM ayarı) hem misafir CPU modeli düzeyinde açılmalıdır, biri eksikse çalışmaz; Hyper-V'de MAC sahteciliği ve sabit bellek zorunludur; performans kaybı G/Ç yoğun işlerde ciddidir, bu yüzden üretim yükü için uygun değildir; ve bulut sunucularında özellik çoğunlukla sağlayıcı tarafından kapalıdır.

Bu senaryoyu gerçekten çalıştırmak istiyorsan altında uygun bir platform olması gerekir. İç içe sanallaştırmanın açık geldiği nested sunucu paketlerimiz doğrudan bu iş için hazırlandı; tam donanım kontrolü istersen dedicated sunucu tarafına bakabilirsin. Sıradan iş yükleri için VDS ve bulut sunucu paketlerimiz yeterlidir; kurulum ve bakım yükünü paylaşmak istersen sunucu yönetimi hizmetimiz devreye girer.