KVM ile Linux Üzerinde Sanallaştırma

Tek bir fiziksel sunucunun üzerinde birbirinden tamamen yalıtılmış, kendi çekirdeğini çalıştıran, farklı işletim sistemleri barındıran onlarca ayrı makine düşünün. Sattığımız her sanal sunucunun, bulut panelinde tek tıkla açtığınız her VDS'in arkasında işte tam olarak bu teknoloji vardır: KVM. Türkçesiyle "Çekirdek Tabanlı Sanal Makine" olan KVM, Linux çekirdeğinin bir parçası olarak çalışır ve modern işlemcilerin donanım sanallaştırma yeteneklerini doğrudan kullanarak, neredeyse fiziksel sunucu hızında sanal makineler çalıştırmanızı sağlar.

Bu rehberde KVM'in nasıl çalıştığını, işlemcinizin sanallaştırmaya uygun olup olmadığını nasıl kontrol edeceğinizi, libvirt ve virsh araçlarıyla yönetim katmanını nasıl kurduğunuzu, virt-install ile sıfırdan bir sanal makineyi nasıl oluşturacağınızı, qcow2 disk imajlarını, köprü ağı ve kaynak atamayı adım adım ele alacağız. Yıllardır barındırma altyapısı işleten bir sistem yöneticisinin bakış açısıyla, teoriyi minimumda tutup elinizi klavyeye götürecek gerçek komutlarla ilerleyeceğiz.

KVM Nedir ve Neden Çekirdeğin İçinde Yaşar#

KVM, 2007 yılında Linux çekirdeğine (kernel 2.6.20) dahil edilmiş bir sanallaştırma altyapısıdır. Diğer bazı hipervizörlerin aksine ayrı, bağımsız bir yazılım katmanı değildir; bir çekirdek modülü olarak yüklenir ve Linux'un kendisini bir "tip 1" (bare-metal) hipervizöre dönüştürür. Bu, KVM'in en büyük avantajıdır: zamanlayıcı, bellek yönetimi, sürücüler gibi olgunlaşmış tüm çekirdek altyapısını olduğu gibi devralır. Ayrı bir hipervizör işletim sistemi öğrenmek yerine, zaten bildiğiniz Linux'u yönetirsiniz.

KVM üç ana parçadan oluşur. kvm.ko çekirdek modülü sanallaştırmanın çekirdek tarafını yönetir; işlemciye özel kvm-intel.ko veya kvm-amd.ko modülü donanım komutlarını devreye alır. Kullanıcı alanında ise geleneksel olarak QEMU çalışır; QEMU sanal makinenin donanımını (disk denetleyicisi, ağ kartı, ekran, USB) taklit eder, KVM ise CPU ve bellek işlemlerini doğrudan gerçek donanıma yaptırır. Yani QEMU "çevre birimlerini" canlandırırken, ağır iş yükü olan işlemci komutları hiç yavaşlamadan fiziksel çekirdeğe iner.

Bu mimarinin pratik sonucu şudur: bir KVM sanal makinesi içindeki bir hesaplama, ana makinedeki bir işlemle neredeyse aynı hızda koşar. Aradaki fark yüzde birkaç seviyesindedir. İşte bu yüzden ciddi barındırma sağlayıcıları, oyun sunucularından veritabanı iş yüklerine kadar performansın önemli olduğu her yerde KVM tercih eder. Clou.TR'nin sanal sunucu ve VDS altyapısı da bütünüyle KVM temellidir; müşteriye sunulan kaynaklar paylaşımlı değil, tahsis edilmiş çekirdek sanallaştırmasıdır.

Donanım Sanallaştırma Desteğini Kontrol Etmek#

KVM çalışabilmek için işlemcinizin donanım sanallaştırma uzantılarını desteklemesini ister: Intel işlemcilerde bu teknolojinin adı VT-x, AMD tarafında ise AMD-V'dir. Neredeyse tüm son on yılın sunucu ve masaüstü işlemcileri bunu destekler, ancak bazı BIOS/UEFI arayüzlerinde varsayılan olarak kapalı gelir. İlk yapmanız gereken bu desteğin hem donanımda var olduğunu hem de etkin olduğunu doğrulamaktır.

En hızlı kontrol, işlemcinin bayraklarına bakmaktır. Aşağıdaki komut sıfırdan büyük bir sayı döndürüyorsa işlemciniz destekliyor demektir:

# vmx (Intel) veya svm (AMD) bayraklarını say
egrep -c '(vmx|svm)' /proc/cpuinfo

# Hangi bayrağın olduğunu görmek için
grep -oE '(vmx|svm)' /proc/cpuinfo | sort -u

Sonuç sıfır çıkıyorsa iki olasılık vardır: ya BIOS/UEFI'de sanallaştırma kapalıdır ya da zaten bir sanal makine içindesinizdir (ki bu durumda "iç içe sanallaştırma" konusuna geleceğiz). Kurulumu bir adım öteye taşımadan önce, dağıtımların sunduğu kvm-ok yardımcısını da çalıştırmanızı öneririm:

# Debian/Ubuntu üzerinde
sudo apt install cpu-checker -y
sudo kvm-ok
# Beklenen çıktı: "KVM acceleration can be used"

Modüllerin gerçekten yüklü olduğunu görmek için:

lsmod | grep kvm
# kvm_intel  ...  veya  kvm_amd  ...
# kvm        ...

Eğer kvm_intel yüklü ama iç içe sanallaştırma ile boğuşuyorsanız, /sys/module/kvm_intel/parameters/nested dosyasının değerine bakın; Y olması gerekir. Bu ön kontrolleri atlamak, ilerideki "VM açılmıyor" hatalarının en yaygın kaynağıdır, o yüzden bu adıma zaman ayırın.

libvirt ve virsh ile Yönetim Katmanı#

KVM'i çıplak QEMU komutlarıyla da kullanabilirsiniz ama bu, uzun ve hataya açık komut satırları demektir. Sektörde standart olan yöntem, bir soyutlama katmanı olan libvirt kullanmaktır. libvirt, arka planda çalışan bir servis (libvirtd) ve sanal makineleri XML tanımlarıyla saklayan bir yönetim API'sidir. Onun sayesinde sanal makineleri, ağları ve depolama havuzlarını tutarlı, betiğe dökülebilir komutlarla yönetirsiniz. Komut satırı istemcisi ise virsh'tir.

Önce gerekli paketleri kuralım. Debian/Ubuntu ailesinde:

sudo apt update
sudo apt install -y qemu-kvm libvirt-daemon-system \
  libvirt-clients bridge-utils virtinst
sudo systemctl enable --now libvirtd

# Kendi kullanıcınızı yetkilendirin (sudo'suz virsh için)
sudo usermod -aG libvirt,kvm $USER
# Oturumu kapatıp açın ki grup üyeliği geçerli olsun

RHEL, AlmaLinux veya Rocky tarafında paket adları biraz değişir:

sudo dnf install -y qemu-kvm libvirt virt-install bridge-utils
sudo systemctl enable --now libvirtd

Kurulum bittikten sonra virsh ile bağlantıyı test edin. En çok kullanacağınız komutları bir tabloda toplayalım:

virsh ile birlikte gelen virt-manager grafik arayüzünü de masaüstü ortamlarda kullanabilirsiniz, fakat bir sunucuda çoğu iş komut satırından yürür ve bu, işlemlerinizi otomasyona taşımanızın da tek yoludur.

virt-install ile İlk Sanal Makineyi Oluşturmak#

Yönetim katmanı hazır olduğuna göre artık bir sanal makine kurabiliriz. virt-install aracı, bir işletim sistemini otomatik veya etkileşimli olarak kuran, ardından libvirt'e kaydeden komuttur. Klasik yaklaşım bir ISO imajından kurmaktır. Diyelim ki bir Ubuntu Server ISO'muz var ve buna 2 çekirdek, 4 GB bellek, 25 GB disk ayırmak istiyoruz:

sudo virt-install \
  --name web01 \
  --vcpus 2 \
  --memory 4096 \
  --disk path=/var/lib/libvirt/images/web01.qcow2,size=25,format=qcow2 \
  --cdrom /var/lib/libvirt/isos/ubuntu-24.04-live-server-amd64.iso \
  --os-variant ubuntu24.04 \
  --network bridge=br0,model=virtio \
  --graphics none \
  --console pty,target_type=serial

Buradaki her bayrağın anlamı önemli. --os-variant doğru değere ayarlandığında libvirt, o işletim sistemine en uygun sanal donanımı (disk sürücüsü, saat kaynağı vb.) seçer; desteklenen değerleri osinfo-query os ile görebilirsiniz. model=virtio ise ağ kartını yarı-sanallaştırılmış virtio sürücüsüyle sunar; taklit edilen eski bir donanım yerine virtio kullanmak, disk ve ağ performansını gözle görülür biçimde artırır. Bu ipucu göründüğünden daha değerlidir: KVM'de disk için virtio yerine sata ya da ağ için e1000 bırakmak, boşu boşuna performans kaybettirir.

Bulut ortamlarında ISO ile tek tek kurmak yerine, çoğunlukla dağıtımların hazır cloud image'leri kullanılır. Bunlar cloud-init destekli, dakikalar yerine saniyeler içinde açılan hazır disklerdir:

# Hazır bir bulut imajından hızlı VM (cloud-init ile)
virt-install \
  --name db01 --vcpus 4 --memory 8192 \
  --disk /var/lib/libvirt/images/db01.qcow2,backing_store=/var/lib/libvirt/images/noble-server-cloudimg-amd64.img \
  --import \
  --os-variant ubuntu24.04 \
  --network bridge=br0,model=virtio \
  --graphics none --console pty,target_type=serial \
  --cloud-init user-data=./user-data.yaml

--import bayrağı, "yeni kurulum yapma, bu hazır diski doğrudan aç" demektir. cloud-init dosyası ise ilk açılışta kullanıcı, SSH anahtarı ve paketleri otomatik ayarlar. Bu, altyapıyı elle kurmak yerine kod olarak tanımlamanın (Infrastructure as Code) ilk basamağıdır.

Sanal Disk Yönetimi ve qcow2 Formatı#

Sanal makinelerin diskleri, ana makinede birer dosyadır. KVM dünyasında en yaygın format qcow2 (QEMU Copy-On-Write versiyon 2)'dir ve ham raw formata göre birçok üstünlüğü vardır. En önemlisi "thin provisioning": diske 100 GB tahsis etseniz bile dosya, gerçekten yazılan veri kadar yer kaplar. Ayrıca qcow2 anlık görüntü (snapshot), sıkıştırma ve şifreleme destekler.

Diskleri qemu-img aracıyla yönetirsiniz. Sık kullanılan işlemler:

# Yeni bir 40 GB qcow2 disk oluştur
qemu-img create -f qcow2 /var/lib/libvirt/images/app01.qcow2 40G

# Diskin gerçek boyutunu ve tahsisini gör
qemu-img info /var/lib/libvirt/images/app01.qcow2

# Diski büyüt (VM kapalıyken; içeride partition/FS ayrıca büyütülmeli)
qemu-img resize /var/lib/libvirt/images/app01.qcow2 +20G

# Kalıcı bir anlık görüntü al
qemu-img snapshot -c temiz-kurulum /var/lib/libvirt/images/app01.qcow2

# Anlık görüntüleri listele
qemu-img snapshot -l /var/lib/libvirt/images/app01.qcow2

Snapshot'lar, bir güncelleme veya riskli değişiklik öncesinde geri dönüş noktası oluşturmak için paha biçilmezdir. Ancak bir uyarı: anlık görüntüler yedek değildir. Diskin bulunduğu fiziksel depolama arızalanırsa snapshot'larla birlikte kaybolurlar. Bu yüzden her ciddi kurulumda snapshot'ı hızlı geri dönüş için, gerçek yedekleme çözümünü ise felaket kurtarma için birlikte kullanmanızı öneririm. İkisi birbirinin yerine geçmez.

Performans açısından bir not daha: qcow2 esnektir ama en yüksek disk performansı gereken (yoğun veritabanı gibi) iş yüklerinde raw format veya doğrudan LVM birimleri kullanmak birkaç yüzde daha hızlı olabilir. Çoğu senaryoda qcow2'nin esnekliği bu küçük farka değer; kararınızı iş yükünüze göre verin.

Köprü Ağ Kurulumu ve Kaynak Atama#

Varsayılan olarak libvirt, sanal makineleri NAT arkasında bir özel ağa (virbr0, genellikle 192.168.122.0/24) yerleştirir. Bu, dışarı çıkabilen ama dışarıdan doğrudan erişilemeyen makineler için yeterlidir. Ancak sanal makinenizin ağda gerçek bir cihaz gibi, kendi genel IP'siyle görünmesini istiyorsanız köprü (bridge) kullanmanız gerekir. Köprü ağı, sanal makinenin ağ kartını fiziksel arayüzle aynı katmana bağlar; VM, ağın geri kalanı için ayrı bir fiziksel makineden ayırt edilemez.

Netplan kullanan modern Ubuntu sistemlerinde bir köprü şöyle tanımlanır:

# /etc/netplan/01-bridge.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
  bridges:
    br0:
      interfaces: [eno1]
      dhcp4: no
      addresses: [203.0.113.10/24]
      routes:
        - to: default
          via: 203.0.113.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

Değişikliği sudo netplan apply ile uygularsınız; artık virt-install komutundaki --network bridge=br0 bu köprüyü kullanır. Bir sunucuda köprüyü uzaktan kurarken dikkatli olun: yanlış yapılandırma erişiminizi kesebilir, o yüzden konsol erişimi olan bir ortamda çalışın.

Kaynak atama tarafında KVM oldukça esnektir. Bir sanal makinenin çekirdek ve belleğini çalışırken bile ayarlayabilirsiniz:

# Çalışan VM'e anlık bellek ata (maksimum sınır dahilinde)
virsh setmem web01 6144M --live

# vCPU sayısını canlı olarak değiştir
virsh setvcpus web01 4 --live

# Belleğin en fazla ne kadar olabileceğini gör
virsh dominfo web01

Burada kritik bir kavram CPU overcommit (aşırı tahsis)'tir. Sanallaştırmanın gücü, fiziksel çekirdek sayısından daha fazla vCPU dağıtabilmenizden gelir; çünkü her VM aynı anda %100 CPU kullanmaz. Ancak bunu abartırsanız, yani 8 çekirdekli bir makineye toplam 40 vCPU dağıtır ve hepsi yoğun çalışırsa, "CPU steal" denen bekleme süreleri ortaya çıkar ve tüm makineler yavaşlar. Ciddi bir barındırma sağlayıcısı overcommit oranını dikkatle sınırlar; müşteriye "tahsisli" olarak sunulan kaynak, gerçekten ayrılmış çekirdek anlamına gelir. Bu ince ayarları kendiniz yönetmek istemiyorsanız, sunucu yönetimi hizmetimiz tam olarak bu dengeyi kurar.

KVM, Konteyner Farkı ve İç İçe Sanallaştırma#

Sıkça sorulan bir soru: "KVM sanal makinesi mi kullanayım yoksa Docker konteyneri mi?" İkisi farklı katmanlarda çalışır ve rakip değil, tamamlayıcıdır. KVM tam bir sanallaştırmadır: her VM kendi çekirdeğini çalıştırır, kendi işletim sistemine sahiptir ve ana makineden güçlü biçimde yalıtılmıştır. Konteynerler ise işletim sistemi düzeyinde sanallaştırmadır; hepsi ana makinenin çekirdeğini paylaşır, çok daha hafiftir ve saniyeler yerine milisaniyeler içinde açılır. Konu daha ayrıntılı olarak Docker nedir başlangıç rehberi yazımızda ele alınıyor.

Aradaki temel farkları tabloyla özetleyelim:

Pratikte en yaygın kurulum ikisini birlikte kullanır: bir KVM sanal makinesi (örneğin bir VDS) açar, güvenlik sınırını orada çizersiniz; sonra o VM'in içinde Docker ile uygulamalarınızı konteynerlerde çalıştırırsınız. Böylece hem VM'in güçlü yalıtımını hem konteynerin hafifliğini elde edersiniz. Paylaşımlı hosting ile VPS arasındaki farkları merak ediyorsanız shared ve VPS hosting karşılaştırması yazısı bu kararı netleştirir.

Son olarak iç içe sanallaştırma (nested virtualization) konusuna değinelim. Bu, bir sanal makinenin içinde yeni sanal makineler çalıştırmaktır; test ortamları ve CI/CD altyapıları için kullanışlıdır. KVM bunu destekler ama bir katman daha eklendiği için performans düşer ve her sağlayıcı bunu açık bırakmaz. Ana makinede modülü etkinleştirmek için:

# Intel için nested'ı aç
echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

# Doğrula: Y dönmeli
cat /sys/module/kvm_intel/parameters/nested

İç içe sanallaştırmayı üretim iş yükleri için değil, laboratuvar ve öğrenme amaçlı düşünmenizi öneririm; ek katmanın getirdiği yavaşlama ciddi yükler için uygun değildir.

Sıkça Sorulan Sorular#

KVM ile VMware veya VirtualBox arasındaki fark nedir?#

Üçü de sanal makineler çalıştırır ancak konumları farklıdır. KVM, Linux çekirdeğinin bir parçası olan ve donanım sanallaştırmayı doğrudan kullanan bir tip 1 hipervizördür; sunucu ortamlarının açık kaynak standardıdır. VMware ürünleri ticari ve lisanslıdır, kurumsal özellikleriyle öne çıkar. VirtualBox ise daha çok masaüstü ve geliştirici testleri için tasarlanmış, kullanımı kolay ama performansı sunucu iş yükleri için daha düşük bir tip 2 hipervizördür. Bir sunucuda kalıcı, performanslı sanallaştırma istiyorsanız KVM'in maliyet ve hız dengesi genellikle en mantıklısıdır.

KVM sanal makinesi ne kadar performans kaybettirir?#

Modern KVM kurulumlarında CPU ve bellek performansı, fiziksel makineye çok yakındır; hesaplama yükünde fark genellikle yüzde birkaç seviyesindedir çünkü işlemci komutları doğrudan donanıma iner. Asıl fark disk ve ağda ortaya çıkabilir, ama virtio sürücülerini kullandığınızda bu da minimuma iner. Performans kaybının büyüdüğü asıl durum, aşırı kaynak tahsisi (overcommit) yapılıp fiziksel makinenin gerçekten yetersiz kaldığı senaryolardır; kaynakları dengeli dağıttığınızda KVM neredeyse şeffaf çalışır.

Sanal makineye ayırdığım diski sonradan büyütebilir miyim?#

Evet, ancak iki aşamalı bir iştir. Önce ana makinede qemu-img resize disk.qcow2 +20G komutuyla sanal diski büyütürsünüz; bu yalnızca dosya kapasitesini artırır. Ardından sanal makinenin içine girip, işletim sistemindeki bölümü (partition) ve dosya sistemini growpart ve resize2fs gibi araçlarla genişletmeniz gerekir. İkinci adımı atlarsanız disk büyümüş görünür ama işletim sistemi eski boyutu kullanmaya devam eder. Bu işlemi yapmadan önce mutlaka bir yedek veya snapshot almanızı öneririm.

Köprü ağ ile NAT ağ arasında hangisini seçmeliyim?#

Sanal makinenizin dışarıdan doğrudan erişilebilir, kendi genel IP'sine sahip gerçek bir sunucu gibi davranmasını istiyorsanız köprü (bridge) ağı kullanın; barındırma sağladığınız senaryoların çoğu budur. Yalnızca dışarı çıkması yeterli olan, dışarıdan erişilmesine gerek olmayan yardımcı makineler (örneğin bir dahili derleme sunucusu) için NAT ağı hem daha kolay hem daha güvenlidir çünkü VM varsayılan olarak internete kapalı kalır. Kararı, makinenin dışarıdan erişilmesi gerekip gerekmediğine göre verin.

İşlemcim sanallaştırmayı desteklemiyor görünüyorsa ne yapmalıyım?#

Önce egrep -c '(vmx|svm)' /proc/cpuinfo çıktısının sıfır olup olmadığına bakın. Sıfırsa en yaygın neden, BIOS/UEFI ayarlarında sanallaştırmanın (Intel VT-x ya da AMD-V) kapalı olmasıdır; makineyi yeniden başlatıp bu ayarı açmanız çoğu zaman sorunu çözer. Eğer zaten bir sanal sunucu içindeyseniz, iç içe sanallaştırma sağlayıcı tarafından kapatılmış olabilir. Fiziksel işlemci gerçekten desteklemiyorsa (çok eski donanım) KVM çalışamaz; bu durumda donanım sanallaştırma sunan bir sunucu kiralamak en pratik yoldur.

Kapanış#

KVM, Linux'un içine gömülü olması sayesinde hem güçlü hem de öğrenmesi keyifli bir sanallaştırma teknolojisidir. Donanım desteğini doğrulamaktan libvirt kurmaya, virt-install ile ilk makineyi açmaktan qcow2 disklerini ve köprü ağını yönetmeye kadar attığınız her adım, aslında modern bulut altyapısının temel yapı taşlarını elle inşa etmek demektir. Bu birikim, ister kendi test laboratuvarınızı kurun ister müşterilerinize hizmet verin, uzun vadede sizi çok ileri taşır.

Tüm bu kurulum ve bakımla uğraşmadan, hazır ve yönetimli bir KVM altyapısına geçmek isterseniz Clou.TR yanınızda. Tahsisli çekirdeklerle çalışan KVM tabanlı VDS ve sanal sunucu paketlerimizle dakikalar içinde kendi yalıtılmış sunucunuza sahip olur; dilerseniz sunucu yönetimi hizmetimizle overcommit, ağ ve yedekleme gibi ince ayarları bize bırakırsınız. Projenize en uygun yapılandırmayı birlikte kuralım.