Sanal Disk Formatları: qcow2, raw ve vmdk

Bir sanal makine oluştururken karşınıza çıkan "disk formatı" seçimi, sonradan değiştirmesi zahmetli olan az sayıdaki karardan biridir. qcow2 mü raw mı sorusu ilk bakışta teknik bir ayrıntı gibi görünür ama anlık görüntü alabilmenizi, disk alanınızın nasıl kullanılacağını ve yoğun yük altında ne kadar hız alacağınızı doğrudan belirler. Yanlış seçim çoğu zaman hemen fark edilmez; aylar sonra "snapshot alamıyorum" ya da "disk beklediğimden çok yer kaplıyor" şeklinde geri döner.

Bu yazıda üç yaygın sanal disk formatını — qcow2, raw ve vmdk — mimarileri, yetenekleri ve gerçek performans karakterleriyle karşılaştıracağım. Hangi depolama tipinde hangisinin kullanılabildiğini, qemu-img ile aralarında nasıl dönüştürme yapacağınızı ve bakım komutlarını göstereceğim. Sonda da format seçiminden kaynaklanan klasik sorunları ve çözümlerini toplayacağım.

Üç Format, Üç Farklı Tasarım#

raw, adının söylediği şeydir: diskin ham bayt bayt kopyası. Hiçbir üstveri, hiçbir başlık, hiçbir katman yoktur. Konuk diskin 4096. baytına yazdığında dosyanın 4096. baytına yazılır. Bu basitlik, formatı olabilecek en hızlı seçenek yapar — ek yük tam olarak sıfırdır. Bedeli ise özelliklerin yokluğudur: dosyanın kendisi anlık görüntü, sıkıştırma ya da şifreleme sunmaz.

qcow2 (QEMU Copy-On-Write, sürüm 2) bir kap formatıdır. İçinde bir başlık, iki seviyeli bir referans tablosu (L1/L2) ve veri kümeleri (cluster) bulunur. Konuk bir bloğa yazdığında qcow2 önce o bloğun tahsis edilip edilmediğine bakar; edilmemişse yeni bir küme ayırır ve tabloyu günceller. Bu dolaylılık, ince tahsis, dahili anlık görüntü, taban imaj (backing file) ve sıkıştırma gibi yeteneklerin tamamının kaynağıdır.

vmdk, VMware'in disk formatıdır. QEMU/KVM okuyup yazabilir ama bu formatın doğal evi VMware ürünleridir. KVM tarafında vmdk kullanmanın tek makul sebebi, bir VMware ortamından gelen imajı geçici olarak çalıştırmaktır; kalıcı çözüm onu qcow2 ya da raw'a dönüştürmektir.

qcow2'nin Gerçek Maliyeti Ne Kadar#

"qcow2 yavaştır" cümlesi eski ölçümlerden kalma bir efsanedir. Modern QEMU sürümlerinde, uygun küme boyutu ve önceden ayrılmış üstveriyle qcow2, raw'a çok yaklaşır. Ek yük iki yerden gelir: yazma sırasında yeni küme tahsisi ve L2 tablosu güncellemesi. Bir kez tahsis edilmiş bölgeye yapılan yazmalar ise neredeyse raw kadar hızlıdır.

Bu yüzden qcow2'nin en yavaş göründüğü an, diskin ilk kez doldurulduğu andır. Bir kıyaslama testini boş bir qcow2 üzerinde çalıştırıp "qcow2 yavaş" sonucuna varmak, gerçek hayatta göreceğiniz performansı yansıtmaz. Ölçümü ısıtma turundan sonra tekrarlayın.

Tahsis maliyetini büyük ölçüde ortadan kaldırmanın yolu, imajı oluştururken üstveriyi önceden ayırmaktır:

# Üstveriyi önceden ayır - yazma sırasındaki L2 güncellemesini büyük ölçüde azaltır
qemu-img create -f qcow2 -o preallocation=metadata,cluster_size=64k disk.qcow2 100G

# Tam ön tahsis - neredeyse raw performansı, ama alanın tamamını hemen kaplar
qemu-img create -f qcow2 -o preallocation=falloc disk.qcow2 100G

# raw imaj oluşturma (seyrek dosya olarak)
qemu-img create -f raw disk.raw 100G

# İmajın bilgilerini gör
qemu-img info disk.qcow2
# virtual size: 100 GiB
# disk size: 1.2 GiB          <-- gerçekte kapladığı yer
# cluster_size: 65536

cluster_size ayarı da performansı etkiler. Varsayılan 64 KB çoğu iş yükü için dengelidir; çok büyük diskler ve sıralı yükler için 128 KB veya 256 KB üstveri yükünü azaltır, buna karşılık küçük rastgele yazmalarda yazma büyümesi (write amplification) yaratır. Özel bir ihtiyacınız yoksa varsayılanı değiştirmeyin.

Disk formatının yanında denetleyici seçimi de en az onun kadar belirleyicidir; VirtIO SCSI yerine IDE kullanan bir makinede hangi formatı seçtiğinizin pratikte önemi kalmaz. Bu konuda VirtIO sürücüleri ve disk performansı yazısına bakmanızı öneririm.

Depolama Tipi Formatı Belirler#

Proxmox gibi platformlarda format seçimi tamamen size bırakılmaz; depolama tipi hangi formatların mümkün olduğunu sınırlar. Bunu bilmemek, "neden qcow2 seçemiyorum" sorusunun en yaygın sebebidir.

Tablodaki en önemli çıkarım şudur: blok tabanlı depolamalarda (LVM-thin, ZFS, Ceph) format her zaman raw'dır ve bu bir kayıp değildir. Anlık görüntü, ince tahsis ve alan verimliliğini bu kez formatın kendisi değil, altındaki depolama katmanı sağlar. Yani "raw seçtim, artık snapshot alamam" endişesi yalnızca dizin tabanlı depolama için geçerlidir.

Pratik karar kuralı basittir: dosya tabanlı depolama (dizin, NFS) kullanıyorsanız qcow2 seçin — özellikleri format sağlamak zorunda. Blok tabanlı depolama kullanıyorsanız zaten raw kullanacaksınız ve özellikleri depolamadan alacaksınız. İnce tahsisin nasıl çalıştığını ve hangi katmanda yapıldığını merak ediyorsanız thin provisioning nedir yazısı bu ayrımı ayrıntılandırıyor.

Formatlar Arası Dönüştürme#

qemu-img convert üç formatın arasında serbestçe dönüştürme yapar. En sık ihtiyaç duyulan senaryo, bir VMware ortamından gelen vmdk imajını KVM tarafına almaktır.

# vmdk -> qcow2 (VMware'den gelen imajı KVM'e taşıma)
qemu-img convert -p -f vmdk -O qcow2 kaynak.vmdk hedef.qcow2

# qcow2 -> raw (blok depolamaya taşımadan önce)
qemu-img convert -p -f qcow2 -O raw disk.qcow2 disk.raw

# raw -> qcow2, sıkıştırmalı (arşivleme için)
qemu-img convert -p -c -f raw -O qcow2 disk.raw arsiv.qcow2

# Dönüşümü doğrula
qemu-img info hedef.qcow2
qemu-img check hedef.qcow2

-p ilerleme çubuğu gösterir; büyük diskler saatler sürebildiği için faydalıdır. -c yalnızca qcow2 hedefinde çalışır ve sıkıştırılmış imaj üretir — arşiv için harikadır ama çalışan bir makine için önerilmez, çünkü her okuma açma maliyeti getirir.

Proxmox'ta bir imajı içeri almanın standart yolu qm importdisk komutudur; format dönüşümünü de kendisi yapar:

# İmajı doğrudan makineye aktar (hedef depolamanın formatına dönüştürerek)
qm importdisk 250 /var/lib/vz/dump/kaynak.vmdk local-lvm

# Aktarılan diski bağla
qm set 250 --scsi0 local-lvm:vm-250-disk-0 --scsihw virtio-scsi-single

⚠️ Dönüştürme sırasında en sık yapılan hata, kaynak makinenin çalışır durumda olmasıdır. Çalışan bir diskin imajını almak, fişi çekilmiş bir sunucunun görüntüsünü almakla aynıdır ve dosya sistemi tutarsız çıkabilir. Kaynağı kapatın ya da en azından tutarlı bir anlık görüntüden dönüştürün.

Bakım: qcow2 Dosyaları Neden Büyür#

qcow2 imajları zamanla, konuktaki gerçek veri miktarından bağımsız olarak büyür. Sebep basittir: konuk bir dosyayı sildiğinde qcow2 o kümeleri geri vermez; yalnızca dosya sistemi seviyesinde boş işaretlenir. Bir sonraki yazma o alanı tekrar kullanır ama dosya boyutu küçülmez.

Bu büyümeyi kontrol altında tutmanın iki yolu vardır. Birincisi, TRIM zincirini uçtan uca açık tutmaktır:

# Ana makinede: disk seçeneklerinde discard açık olmalı
qm set 250 --scsi0 local-lvm:vm-250-disk-0,discard=on,ssd=1

# Konuk içinde: periyodik trim servisini etkinleştir
systemctl enable --now fstrim.timer
systemctl status fstrim.timer --no-pager

# Elle çalıştırıp ne kadar alan bildirildiğini gör
fstrim -av
# /: 12.4 GiB (13314838528 bytes) trimmed

İkinci yol, imajı çevrimdışı olarak sıkıştırmaktır. Makine kapalıyken qemu-img sıfır blokları atarak imajı yeniden yazar:

# Makine KAPALIYKEN imajı yeniden yazarak küçült
qemu-img convert -O qcow2 disk.qcow2 disk-yeni.qcow2
mv disk-yeni.qcow2 disk.qcow2

# Bütünlük kontrolü ve onarım
qemu-img check disk.qcow2
qemu-img check -r all disk.qcow2   # bulunan hataları onarmayı dener

Küçültmeden önce konuk içinde boş alanı sıfırlarsanız kazanç çok daha büyük olur (dd if=/dev/zero of=/bosluk.bin; sync; rm /bosluk.bin), ama bu işlem diskinizi geçici olarak tamamen doldurur — ana makinede yeterli alan olduğundan emin olun. Disk doluluğunu takip etmek için disk kullanımı: df, du ve ncdu yazısındaki araçlar işinizi görür; ana makinenin dolması durumunda ne olduğunu ise disk dolu: no space left çözümü yazısında ele aldım.

Sık Yapılan Hatalar#

Blok depolamada qcow2 aramak. LVM-thin ya da ZFS kullanıyorsanız Proxmox size qcow2 seçeneği sunmaz ve bu doğrudur; anlık görüntüyü depolama katmanı sağlar. Bunu bir eksiklik sanıp dizin tabanlı depolamaya geçmek, çoğu durumda performanstan kaybettirir.

Dosya boyutuna bakıp panik yapmak. ls -lh bir seyrek dosyanın görünen boyutunu gösterir, gerçekte kapladığı yeri değil. Doğru komut du -h ya da qemu-img info'daki "disk size" satırıdır. 100 GB görünen bir imaj diskte 3 GB kaplıyor olabilir.

İç içe anlık görüntü zinciri biriktirmek. qcow2 dahili anlık görüntüler tutabilir ama her katman okuma yolunu uzatır. Onlarca snapshot biriktirmiş bir imaj hem yavaşlar hem de yönetilemez hâle gelir. Anlık görüntüleri geçici güvenlik ağı olarak kullanın, yedekleme yerine geçirmeyin.

Anlık görüntüyü yedek sanmak. Bu, listenin en pahalı hatası. Anlık görüntü, imajın kendisiyle aynı diskte durur; disk arızalanırsa ikisi birden gider. Gerçek yedek, başka bir ortama alınmış kopyadır. Disk sağlığını izlemek için disk arızası tespiti: SMART ve RAID yazısına, sunucu dışı yedekleme için Borg ile sunucu yedekleme yazısına bakabilirsiniz.

Diski gereğinden büyük tanımlamak. Sanal diski büyütmek kolaydır, küçültmek pratikte mümkün değildir (konuk içinde bölüm küçültme, sonra imaj küçültme — riskli ve zahmetli bir zincir). İnce tahsis kullanıyorsanız zaten fazladan alan hemen kaplanmaz, ama yine de makul bir boyutla başlayıp ihtiyaç oldukça büyütmek daha sağlıklıdır.

Sıkça Sorulan Sorular#

qcow2 mi raw mı kullanmalıyım#

Depolama tipiniz cevabı büyük ölçüde veriyor. Dizin ya da NFS gibi dosya tabanlı bir depolamadaysanız qcow2 kullanın: anlık görüntü, ince tahsis ve taban imaj gibi yetenekleri yalnızca o sağlar. LVM-thin, ZFS ya da Ceph gibi blok tabanlı bir depolamadaysanız raw kullanacaksınız ve aynı yetenekleri depolama katmanından alacaksınız. Saf performans arıyorsanız ve özellik gerekmiyorsa raw her zaman bir tık öndedir.

qcow2 gerçekten yavaş mı#

Modern QEMU sürümlerinde hayır. Ölçülebilir fark genellikle yüzde birkaç seviyesindedir ve büyük kısmı yeni blok tahsisi anında ortaya çıkar; bir kez tahsis edilmiş alana yazma neredeyse raw kadar hızlıdır. preallocation=metadata ile oluşturursanız bu farkı da büyük ölçüde kapatırsınız. "qcow2 yavaş" algısı çoğunlukla boş bir imaj üzerinde yapılan ısıtmasız kıyaslamalardan geliyor.

vmdk formatını KVM'de kullanabilir miyim#

Kullanabilirsiniz, QEMU vmdk okuyup yazabilir. Ancak kalıcı bir çözüm olarak önermiyorum: vmdk'nın birçok alt türü var ve hepsi KVM tarafında aynı olgunlukta desteklenmiyor. VMware'den gelen bir imajı bir kez çalıştırmak için idare eder; doğru yaklaşım qemu-img convert ile qcow2 ya da raw'a dönüştürüp devam etmektir.

Disk formatını sonradan değiştirebilir miyim#

Evet, ama makineyi kapatmanız gerekir. qemu-img convert ile dönüştürüp makine yapılandırmasındaki disk satırını yeni dosyayı gösterecek şekilde güncellersiniz. Proxmox'ta daha pratik bir yol var: diski farklı bir depolamaya taşımak (Move Disk), hedef depolamanın desteklediği formata otomatik dönüştürür. Her iki durumda da işlemden önce yedek alın.

qcow2 dosyam neden konuktaki veriden büyük#

Çünkü konuk bir dosyayı sildiğinde qcow2 o kümeleri otomatik geri vermez; alan yalnızca dosya sistemi seviyesinde boş işaretlenir. Çözüm, TRIM zincirini açmaktır: ana makinede disk seçeneklerine discard=on ekleyin, konukta fstrim.timer servisini etkinleştirin. Zaten şişmiş bir imajı küçültmek için makineyi kapatıp qemu-img convert ile yeniden yazmanız gerekir.

Anlık görüntü ile yedek arasındaki fark nedir#

Anlık görüntü, imajın belirli bir andaki durumuna dönebilmenizi sağlayan bir işaretçidir ve aynı diskte durur. Disk arızalanır ya da depolama havuzu bozulursa hem imaj hem anlık görüntü birlikte kaybolur. Yedek ise verinin başka bir ortama alınmış bağımsız kopyasıdır. Anlık görüntüyü riskli bir güncelleme öncesi geçici güvenlik ağı olarak kullanın; yedekleme yerine asla geçirmeyin.

Kapanış#

Sanal disk formatı seçimi, aslında "özellikleri hangi katman sağlasın" sorusunun cevabıdır. Aklınızda kalması gereken dört şey şunlar: dosya tabanlı depolamada qcow2, blok tabanlı depolamada raw kullanın; qcow2'yi preallocation=metadata ile oluşturup performans endişesini büyük ölçüde kapatın; TRIM zincirini uçtan uca açık tutarak imajların şişmesini önleyin; ve anlık görüntüyü hiçbir zaman yedek yerine koymayın.

Depolama katmanını kendiniz kurup yönetmek istiyorsanız tam root erişimli VDS ve sanal sunucu paketlerimiz uygun bir başlangıç noktası olur; daha yüksek ve öngörülebilir disk performansı gerektiren iş yükleri için dedicated sunucu tarafına bakabilirsiniz. Yedeklerin düzenli alındığından ve geri yüklenebildiğinden emin olmak isterseniz yedekleme ve sunucu yönetimi hizmetlerimiz bu döngüyü üstlenir.