Sanal Makinede Sanal Makine Çalıştırma

Elinde bir sanal sunucu var ve onun içinde kendi sanal makinelerini çalıştırmak istiyorsun: belki üç düğümlü bir Kubernetes laboratuvarı kuracaksın, belki bir müşteri ortamını birebir taklit edeceksin, belki de bir eğitim için katılımcı başına izole makineler hazırlıyorsun. Sanal makinede sanal makine çalıştırmak teknik olarak mümkün, ama işin başında bilmen gereken üç şey var: ortamın buna izin verip vermediği, kaynakları üç katman arasında nasıl böleceğin ve iç makineleri ağa nasıl çıkaracağın.

Bu yazıda konunun teorisine değil doğrudan uygulamasına odaklanacağım. Ortam desteğini nasıl doğrulayacağını, kaynak planını gerçek bir örnekle nasıl kuracağını, bir Linux sunucu üzerinde KVM ile baştan sona nasıl laboratuvar kuracağını, iç makinelerin ağ sorununu nasıl çözeceğini ve hangi durumlarda bu yolu hiç seçmemen gerektiğini anlatacağım. Özelliğin donanım tarafındaki mekaniğini ve platform ayarlarını nested virtualization nedir yazısında ayrıntısıyla ele aldım; burada onu veri kabul edip devam ediyorum.

Bunu Neden Yapmak İstersin#

Herkesin ihtiyacı aynı değil ve senaryo, sonraki tüm kararları belirliyor:

Bu listede olmayan bir şey var: üretim iş yükü. İç içe kurulumda her disk ve ağ işlemi iki sanallaştırma katmanından geçer; bu, gerçek kullanıcı trafiği taşıyan bir servis için kabul edilebilir bir maliyet değildir. Bu yolu bir laboratuvar aracı olarak düşün.

Önce Şunu Kontrol Et: Ortamın İzin Veriyor mu#

Kurulum komutlarına geçmeden önce yapman gereken tek bir kontrol var ve bu kontrol sonucu olumsuzsa geri kalan her adım zaman kaybı. Sanal sunucunun içinde şunu çalıştır:

# CPU sanallaştırma bayrağı görünüyor mu (vmx = Intel, svm = AMD)
grep -E -o 'vmx|svm' /proc/cpuinfo | sort -u

# Daha okunaklı bir kontrol aracı
sudo apt update && sudo apt install -y cpu-checker
sudo kvm-ok

Beklediğin çıktı şuna benzer:

# kvm-ok başarılı çıktısı:
# INFO: /dev/kvm exists
# KVM acceleration can be used

İlk komut boş dönüyor ya da kvm-ok "KVM acceleration can NOT be used" diyorsa, üzerinde bulunduğun sanal sunucuya iç içe sanallaştırma özelliği verilmemiş demektir. Bu, misafir içinde çözebileceğin bir sorun değildir — kararı barındıran hipervizör verir. Barındırma sağlayıcılarının çoğu bu özelliği hem performans hem güvenlik gerekçesiyle kapalı tutar, bu yüzden standart bir VPS'te çalışmaması normaldir. Özelliğin açık geldiği bir ürüne ihtiyacın varsa nested sunucu paketlerimiz doğrudan bu senaryo için hazırlandı; tam donanım kontrolü istiyorsan dedicated sunucu tarafında zaten sınır yok.

Kendi fiziksel makinen ya da kendi hipervizörün varsa özelliği açman gerekir; hangi platformda hangi ayarın yapıldığını nested virtualization nedir yazısında adım adım bulabilirsin.

Kaynak Planlaması: Üç Katmanı Nasıl Böleceksin#

En sık yapılan planlama hatası, iç makinelerin toplam kaynağını dış makinenin toplam kaynağına eşitlemek. Oysa aradaki katmanın kendi tüketimi var ve bunu hesaba katmazsan iç makineler açılır ama her şey takas alanında sürünür.

Gerçek bir örnek üzerinden gidelim. 8 vCPU ve 16 GB belleği olan bir sunucun var ve üzerinde üç düğümlü bir laboratuvar kurmak istiyorsun:

CPU tarafında iç makinelere toplamda dış makinenin çekirdek sayısından fazla vCPU atayabilirsin; buna aşırı dağıtım (overcommit) denir ve makul oranlarda sorun çıkarmaz. Ancak iç içe kurulumda bu etki iki kat hissedilir, çünkü zaten dış makinenin kendisi de paylaşılan bir kaynak üzerinde çalışıyor olabilir. Sınırların nerede olduğunu CPU overcommit nedir yazısında ayrıntılı anlattım.

Bellek konusunda ise aşırı dağıtım yapma. Bellek CPU gibi zaman paylaşımıyla bölünemez; verdiğin bellek gerçekten harcanır ve tükendiğinde sistem takas alanına düşer.

Disk tarafında qcow2 gibi ince sağlanan (thin) formatlar kullanacaksan, tanımladığın toplam sanal disk boyutunun fiziksel diskten büyük olabileceğini unutma. Makineler doldukça disk beklenmedik bir anda biter ve hepsi birden yazamaz hâle gelir. Doluluk takibini nasıl yapacağını disk kullanımı df, du ve ncdu yazısında bulabilirsin.

Hangi Hipervizörü İçeriye Kurmalı#

İç katmanda çalıştıracağın hipervizör seçimi, dış işletim sistemine ve amacına bağlı:

• KVM + libvirt — Linux sunucu üzerinde en doğal seçim. Çekirdeğin parçası olduğu için ek bir katman kurmuş olmazsın, komut satırından tam kontrol verir ve betikle otomatikleştirmesi kolaydır. Sunucu laboratuvarları için önerdiğim yol budur.
• VirtualBox — Grafik arayüz istiyorsan ya da masaüstü alışkanlıkların varsa. Sunucuda başsız (headless) çalıştırabilirsin ama KVM'e göre ek bir katman ve ek bakım demektir.
• Hyper-V — Dış makinen Windows Server ise doğal seçim. Rolü açmadan önce iç içe sanallaştırma ayarının ve MAC sahteciliğinin yapıldığından emin olman gerekir.
• Konteyner (LXC / Docker) — Aslında hipervizör değil ama çoğu senaryoda aradığın şey bu. Ayrı çekirdek gerektirmeyen bir izolasyon yeterliyse, iç içe sanallaştırmanın tüm maliyetinden kurtulursun.

Masaüstü hipervizörlerini karşılaştırmak istiyorsan VirtualBox ve VMware Workstation karşılaştırması yazısı iki ürünü yan yana koyuyor.

Adım Adım: Linux Sunucu Üzerinde KVM Laboratuvarı#

Ortamın desteklediğini doğruladıysan kurulum oldukça kısa. Debian/Ubuntu ailesi için:

# Gerekli paketleri kur
sudo apt update
sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients \
                    virtinst bridge-utils cloud-image-utils

# Servisi başlat ve açılışta etkinleştir
sudo systemctl enable --now libvirtd

# Kendi kullanıcını yetkilendir (oturumu kapatıp açman gerekir)
sudo usermod -aG libvirt,kvm "$USER"

# Kurulumun sağlıklı olduğunu doğrula
virsh list --all
virsh net-list --all

Varsayılan NAT ağı bazı kurulumlarda pasif gelir; iç makinelerin internete çıkabilmesi için onu başlatman gerekir:

# Varsayılan NAT ağını başlat ve açılışta otomatik hâle getir
sudo virsh net-start default
sudo virsh net-autostart default

# Ağ detayını gör (IP aralığı ve köprü adı)
sudo virsh net-dumpxml default

Şimdi ilk iç makineyi kurabilirsin. Konsol üzerinden metin tabanlı kurulum, sunucu ortamında en pratik yoldur:

# ISO'dan yeni bir sanal makine kur
sudo virt-install \
  --name lab-web01 \
  --memory 4096 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/lab-web01.qcow2,size=25,format=qcow2 \
  --cdrom /var/lib/libvirt/images/ubuntu-server.iso \
  --network network=default,model=virtio \
  --os-variant ubuntu22.04 \
  --graphics none \
  --console pty,target_type=serial

Kurulum bittikten sonra günlük yönetim virsh ile yapılır:

# Makineleri listele
sudo virsh list --all

# Başlat, düzgün kapat, konsola bağlan (çıkış: Ctrl + ])
sudo virsh start lab-web01
sudo virsh shutdown lab-web01
sudo virsh console lab-web01

# Kaynak bilgisi ve IP adresi
sudo virsh dominfo lab-web01
sudo virsh domifaddr lab-web01

# Açılışta otomatik başlasın
sudo virsh autostart lab-web01

# Anlık görüntü al ve geri dön
sudo virsh snapshot-create-as lab-web01 kurulum-sonrasi
sudo virsh snapshot-revert lab-web01 kurulum-sonrasi

Anlık görüntüleri laboratuvarda özgürce kullan ama uzun süre bırakma; zincir büyüdükçe disk şişer ve performans düşer. Nedenini sanal makine snapshot yönetimi yazısında ayrıntısıyla anlattım.

Ağ: İç Makineleri Dışarı Nasıl Çıkarırsın#

Bu, iç içe kurulumların en çok vakit kaybettiren kısmı. İki temel seçenek var ve barındırma ortamında biri genellikle çalışmaz.

NAT (varsayılan) — İç makineler özel bir alt ağda (tipik olarak 192.168.122.0/24) yaşar, internete dış makinenin IP'si üzerinden çıkar. Dışarıdan doğrudan erişilemezler; erişim için port yönlendirmesi tanımlarsın. Barındırma ortamlarında çalışan yöntem budur.

Köprü (bridge) — İç makineler doğrudan fiziksel ağa katılır ve kendi IP'lerini alır. Kendi donanımında sorunsuz çalışır, ancak barındırma sağlayıcıları güvenlik gereği sanal sunucunun ağ portunda bilinmeyen MAC adreslerini filtreler; bu durumda iç makinelerin paketleri sessizce düşer. "Bridge kurdum ama iç makine IP almıyor" şikâyetinin en yaygın sebebi budur ve çözümü NAT'a dönmektir.

NAT modunda bir iç makinenin web sunucusunu dışarı açmak için:

# Dış dünyadan 8080 portuna geleni iç makinenin 80 portuna yönlendir
sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 \
     -j DNAT --to-destination 192.168.122.10:80

# İletim kuralını ekle
sudo iptables -A FORWARD -p tcp -d 192.168.122.10 --dport 80 -j ACCEPT

# Kuralların kalıcı olması için (Debian/Ubuntu)
sudo apt install -y iptables-persistent
sudo netfilter-persistent save

İç makinenin IP'sinin her açılışta değişmemesi için libvirt'in DHCP tarafında sabit kiralama tanımlaman işini kolaylaştırır; sudo virsh net-edit default ile ağ tanımına makinenin MAC adresine bağlı sabit bir IP ekleyebilirsin. Alt ağ planı yaparken subnet hesaplayıcı aracımızı kullanabilirsin.

Ne Zaman Yapmamalısın: Alternatifler#

İç içe sanallaştırmaya girişmeden önce şu üç alternatifi gerçekten değerlendir; çoğu zaman ihtiyacını daha ucuza ve daha hızlı karşılarlar.

Konteynerler. Amacın izole servisler çalıştırmaksa ve hepsi Linux ise, ayrı bir çekirdeğe ihtiyacın yok demektir. LXC ya da Docker ile aynı izolasyonu neredeyse sıfır ek yükle elde edersin. Üç düğümlü bir uygulama laboratuvarı, üç konteynerle çok daha hızlı kurulur ve çok daha az kaynak yer.

Birden fazla küçük sunucu. Gerçek ağ davranışını, ayrı IP'leri ve gerçek ayrı makineleri test etmen gerekiyorsa, üç küçük VDS ya da bulut sunucu kiralamak hem daha performanslı hem yönetimi daha basit olur. Laboratuvar bittiğinde silersin.

Fiziksel makine. Hipervizör davranışını, PCI cihaz geçişini ya da donanım seviyesi özellikleri test ediyorsan iç içe kurulum zaten yanıltıcı sonuçlar verir. Bu durumda dedicated sunucu ya da colocation doğru cevaptır.

İç içe sanallaştırmayı, bu üçünün hiçbirinin karşılamadığı bir ihtiyacın olduğunda seç: tek bir makine üzerinde, birbirinden tam çekirdek düzeyinde izole, farklı işletim sistemleri çalıştırman gerektiğinde.

Sorun Giderme ve Sık Yapılan Hatalar#

"KVM acceleration can NOT be used" — Ortam desteklemiyor ya da BIOS'ta sanallaştırma kapalı. Kendi donanımındaysan BIOS'u kontrol et; barındırılan bir sunucudaysan sağlayıcı özelliği açmamış demektir.

"Could not access KVM kernel module: Permission denied" — Kullanıcın kvm ve libvirt gruplarında değil. usermod komutunu çalıştırdıktan sonra oturumu kapatıp açman gerekir; aynı oturumda etkili olmaz.

Her şey çalışıyor ama çok yavaş — Muhtemelen KVM hızlandırması yerine tam yazılım emülasyonuna (TCG) düşmüşsündür. sudo virsh capabilities | grep -i kvm çıktısında KVM alanının göründüğünü ve makinenin domain type='kvm' olarak tanımlandığını doğrula.

İç makine ağa çıkamıyor — Önce varsayılan ağın çalıştığını (virsh net-list) kontrol et. Köprü modu kullanıyorsan barındırma ortamının MAC filtresine takılıyor olabilirsin; NAT'a geç.

Disk aniden doldu — İnce sağlanan diskler zamanla gerçek boyutlarına yaklaşır. Toplam tanımlı disk boyutunu fiziksel diskten büyük tuttuysan bu kaçınılmazdır. Doluluğu izle ve anlık görüntüleri temizle.

Dış makine yeniden başladığında iç makineler açılmıyor — virsh autostart tanımlamayı unutmuşsundur. Laboratuvarın kalıcı olmasını istiyorsan bunu her makine için ayarla.

İç içe iç içe denemek — L2 içinde bir hipervizör daha çalıştırmak teorik olarak mümkün olsa da performans kullanılamaz seviyeye düşer ve platform desteği belirsizdir. İki katmanda kal.

Sıkça Sorulan Sorular#

VDS'imde sanal makine çalıştırabilir miyim#

Sağlayıcının iç içe sanallaştırmayı açık sunması gerekir. Standart sanal sunucularda bu özellik genellikle kapalıdır, çünkü hem performans maliyeti vardır hem de hipervizörün saldırı yüzeyini genişletir. Kontrolü tek komutla yapabilirsin: sunucuda grep -E -o 'vmx|svm' /proc/cpuinfo boş dönüyorsa özellik sana verilmemiştir ve misafir içindeki hiçbir ayar bunu değiştirmez.

Kaç sanal makine sığdırabilirim#

Sınırı bellek belirler. Dış makinenin işletim sistemine, hipervizör süreçlerine ve disk önbelleğine toplamda birkaç gigabayt ayırdıktan sonra kalanı iç makinelere bölersin. 16 GB belleğe sahip bir sunucuda 4 GB'lık üç makine rahat çalışır; dördüncüyü eklemek sistemi takas alanına iter. CPU tarafında ölçülü aşırı dağıtım yapabilirsin ama bellekte asla.

Performans ne kadar düşer#

İş yüküne bağlı. Saf hesaplama yapan işler iç makinede makul hızda çalışır; yoğun disk ve ağ trafiği üreten işler ise belirgin biçimde yavaşlar, çünkü her işlem iki sanallaştırma katmanından geçer. Bu yüzden iç içe kurulum test, eğitim ve laboratuvar için uygundur; gerçek kullanıcı trafiği taşıyan bir servis için değil.

Docker için de aynı şey gerekli mi#

Hayır. Linux üzerinde Docker konteynerleri ayrı bir çekirdek çalıştırmaz, aynı çekirdeği paylaşan izole süreçlerdir; bu yüzden sıradan bir sanal sunucuda sorunsuz çalışırlar. İç içe sanallaştırmaya ihtiyaç, Docker'ın kendisinin bir sanal makine içinde çalıştığı Windows ve macOS senaryolarında doğar. Linux sunucunda Docker kurmak için hiçbir ek özelliğe gerek yoktur.

İç makinelere dışarıdan nasıl bağlanırım#

En yaygın ve barındırma ortamlarında çalışan yöntem NAT ile port yönlendirmesidir: dış makinenin belirli bir portuna geleni iç makinenin ilgili portuna yönlendirirsin. Alternatif olarak dış makine üzerinde bir ters vekil sunucu (reverse proxy) çalıştırıp isteğe göre farklı iç makinelere dağıtabilirsin. Köprü modu her makineye kendi IP'sini verir ama barındırma ortamlarında MAC filtresi yüzünden çoğunlukla çalışmaz.

Bu kurulumu nasıl yedeklerim#

İki katmanı ayrı düşün. İç makinelerin disk imajlarını (/var/lib/libvirt/images/) ve tanım dosyalarını (virsh dumpxml <makine> > makine.xml) düzenli olarak dış bir hedefe kopyala. Anlık görüntüler yedek yerine geçmez; aynı diskte dururlar. Dış makinenin tamamını yedeklemek istiyorsan sunucu düzeyinde bir yedekleme akışı kurman gerekir; Borg ile sunucu yedekleme yazısı bu iş için pratik bir yol gösterir.

Kapanış#

Sanal makine içinde sanal makine çalıştırmak, doğru senaryoda muazzam esneklik veren bir laboratuvar tekniğidir. Aklında kalması gereken dört şey: kuruluma başlamadan önce kvm-ok ile ortamın destekleyip desteklemediğini doğrula, çünkü destek yoksa geri kalan her adım boşa gider; kaynakları dağıtırken dış katmanın kendi tüketimine pay bırak ve bellekte asla aşırı dağıtım yapma; barındırılan ortamlarda köprü yerine NAT ve port yönlendirmesi kullan; ve bu kurulumu bir laboratuvar aracı olarak tut, üretim yükünü buraya taşıma.

İç içe sanallaştırmanın açık geldiği bir sunucuya ihtiyacın varsa nested sunucu paketlerimiz doğrudan bu iş için yapılandırıldı. Gerçek ayrı makinelerle çalışmayı tercih edersen birkaç küçük VDS ya da bulut sunucu kiralamak çoğu laboratuvar için daha pratik olur; donanım seviyesinde test yapacaksan dedicated sunucu tarafına bakabilir, kurulum ve bakım yükünü paylaşmak istersen sunucu yönetimi hizmetimizi değerlendirebilirsin.