Aynı işletim sistemini onuncu kez kurup aynı paketleri tekrar tekrar yüklüyorsanız, yanlış bir iş akışındasınız demektir. Proxmox VM şablonu tam olarak bu tekrarı ortadan kaldırmak için vardır: bir makineyi bir kez düzgün kurar, temizler, şablona dönüştürürsünüz; sonrasında yeni sunucu ihtiyacı bir kurulum değil, otuz saniyelik bir klonlama işlemine dönüşür.
Bu rehberde temel bir imajı nasıl hazırlayacağınızı, şablona dönüştürmeden önce hangi izleri temizlemeniz gerektiğini, linked clone ile full clone arasındaki gerçek farkı ve klondan sonra mutlaka düzeltmeniz gereken makine kimliği, SSH anahtarı ve ağ ayarlarını göstereceğim. Sonda da klonlamanın sessizce yanlış gitmesine yol açan tuzakları toplayacağım — bunların çoğu haftalar sonra "iki sunucu aynı IP'yi alıyor" şeklinde geri döner.
Şablon Nedir, Klonlamadan Farkı Ne#
Proxmox'ta bir şablon (template), salt okunur işaretlenmiş bir sanal makinedir. Şablona dönüştürülmüş bir makine artık başlatılamaz ve diski değiştirilemez; tek işlevi klonlara kaynak olmaktır. Bu kısıt bir eksiklik değil, güvenlik önlemidir: temel imajınızın kazara başlatılıp kirletilmesini engeller.
Klonlama iki farklı biçimde yapılır ve aralarındaki fark, depolama davranışında yatar. Full clone (tam klon) kaynak diski baştan sona kopyalar; ortaya kaynağından tamamen bağımsız, kendi disk alanını kaplayan bir makine çıkar. Linked clone (bağlı klon) ise kopyalama yapmaz; yalnızca kaynağa referans veren bir katman oluşturur ve sadece değişen blokları kendi alanına yazar. Bu yüzden linked clone saniyeler içinde oluşur ve başlangıçta neredeyse hiç yer kaplamaz.
| Ölçüt | Full clone | Linked clone |
|---|---|---|
| Oluşma süresi | Disk boyutuna göre dakikalar | Saniyeler |
| Başlangıç disk kullanımı | Kaynağın tamamı kadar | Neredeyse sıfır |
| Kaynağa bağımlılık | Yok | Var — şablon silinemez |
| Başka düğüme taşıma | Serbest | Kısıtlı |
| Depolama gereksinimi | Her tip | Yalnızca anlık görüntü destekleyen tipler |
| Uygun kullanım | Üretim sunucuları | Test, geliştirme, kısa ömürlü makineler |
Linked clone'un en önemli kısıtı şudur: kaynak şablon silinemez ve taşınamaz. Onlarca linked clone üreten bir şablonu yanlışlıkla silmeye kalkarsanız Proxmox izin vermez, ama şablonun bulunduğu depolamada bir sorun çıkarsa tüm klonlar birden etkilenir. Bu yüzden üretim iş yüklerinde full clone tercih edilir; linked clone ise test ve geliştirme ortamlarında paha biçilmezdir.
Temel İmajı Hazırlama#
Şablonun kalitesi, klonların kalitesini belirler. Kötü hazırlanmış bir temel imaj, ürettiği her makineye aynı sorunu miras bırakır. Bu yüzden imajı hazırlarken sırayı şöyle kurun:
- Sade bir kurulum yapın. Minimal paket seti seçin; ihtiyaç duymadığınız hiçbir servisi kurmayın. Sonradan eklemek, sonradan sökmekten kolaydır.
- Disk denetleyicisini VirtIO SCSI yapın. Sonradan değiştirmek konuk tarafında sürücü sorunları çıkarır.
- Guest agent'ı kurun ve etkinleştirin. Proxmox'un konuk hakkında IP, dosya sistemi ve kapatma bilgisi alabilmesi buna bağlıdır.
- Güncellemeleri yapın, ama imajı çok "taze" tutmaya çalışmayın — klondan sonra zaten güncelleme çalıştıracaksınız.
- İzleri temizleyin. Bu adım en kritik olanıdır ve aşağıda ayrı bir bölümde ele alacağım.
Temel bir Debian/Ubuntu imajında yapılacak hazırlık şöyle görünür:
# Konuk sistem içinde - temel hazırlık
apt-get update && apt-get -y upgrade
apt-get -y install qemu-guest-agent cloud-init
systemctl enable qemu-guest-agent
# Zaman senkronizasyonu ve temel araçlar
apt-get -y install chrony curl ca-certificates
systemctl enable chrony
Ana makine tarafında ise makinenin kritik ayarlarını doğrulayın:
# Şablon adayı 9000 numaralı makinenin ayarları
qm set 9000 --agent enabled=1 # guest agent'ı Proxmox tarafında da aç
qm set 9000 --scsihw virtio-scsi-single
qm set 9000 --ostype l26 # Linux 2.6+ konuk
qm config 9000 | grep -E "agent|scsihw|ostype|net0"
Guest agent'ı neden bu kadar önemsediğimi merak ediyorsanız — klonlanmış makinenin IP'sini Proxmox arayüzünde görmek, düzgün kapatmak ve tutarlı yedek almak tamamen buna bağlıdır. Ayrıntı için QEMU Guest Agent kurulumu yazısına bakabilirsiniz.
Şablona Dönüştürmeden Önce Temizlik#
Bu bölümü atlarsanız klonlarınız birbirinin kopyası olur — ve bazı şeylerin kopya olması ciddi sorun yaratır. Temizlenmesi gereken izler şunlardır:
| İz | Sorun | Temizlik |
|---|---|---|
/etc/machine-id | Aynı kimlik, DHCP çakışması ve günlük karışması | Dosyayı boşalt |
| SSH host anahtarları | Tüm klonlar aynı parmak izini sunar | Sil, ilk açılışta yeniden üretilsin |
| Kalıcı ağ kuralları | Yeni MAC yeni arayüz adı alır, ağ açılmaz | 70-persistent-net.rules sil |
| Kabuk geçmişi | Kurulum sırasında yazılan parolalar | history -c, dosyaları sil |
| Cloud-init durumu | Klon "zaten yapılandırıldım" sanar | cloud-init clean |
| APT önbelleği / günlükler | Boş yere büyük imaj | Temizle |
Bunların hepsini kapatmadan önce tek seferde uygulayın:
# Konuk sistem içinde, kapatmadan HEMEN ÖNCE çalıştırın
cloud-init clean --logs # cloud-init durumunu sıfırla
truncate -s 0 /etc/machine-id # boşalt, SİLME - systemd dosyanın varlığını bekler
rm -f /var/lib/dbus/machine-id
ln -s /etc/machine-id /var/lib/dbus/machine-id
rm -f /etc/ssh/ssh_host_* # host anahtarları ilk açılışta yeniden üretilir
rm -f /etc/udev/rules.d/70-persistent-net.rules
apt-get clean
rm -rf /var/lib/apt/lists/*
find /var/log -type f -exec truncate -s 0 {} \; # günlükleri sıfırla
history -c && rm -f /root/.bash_history
shutdown -h now
machine-id satırındaki ayrıntı önemlidir: dosyayı silmeyin, boşaltın. systemd açılışta boş bir machine-id görürse yenisini üretir; dosya tamamen yoksa bazı dağıtımlarda önyükleme sorunları çıkar. Aynı machine-id'yi taşıyan iki makine, DHCP sunucusundan aynı IP'yi talep edebilir — "klonladım, iki sunucu aynı IP'yi alıyor" şikâyetinin en yaygın sebebi tam olarak budur.
Makine kapandıktan sonra şablona dönüştürme tek komuttur:
# 9000 numaralı makineyi şablona dönüştür (geri dönüşü yoktur)
qm template 9000
# Doğrulama - "template: 1" satırını görmelisiniz
qm config 9000 | grep template
Klonlama ve Klon Sonrası Ayarlar#
Şablon hazır olduğunda yeni makine üretmek tek satıra iner. Full clone ve linked clone komutları yalnızca --full bayrağıyla ayrılır:
# Linked clone - saniyeler içinde, neredeyse yer kaplamadan
qm clone 9000 151 --name web-test-01
# Full clone - bağımsız kopya, hedef depolamayı belirtebilirsiniz
qm clone 9000 152 --name web-prod-01 --full --storage local-lvm
# Klonun ayarlarını gözden geçir
qm config 152 | grep -E "name|net0|memory|cores|scsi0"
Klon oluştuktan sonra Proxmox bazı şeyleri otomatik halleder, bazılarını halletmez. Otomatik olan: yeni bir VMID, yeni bir MAC adresi ve yeni bir UUID. Sizin yapmanız gereken: makine adı, kaynak boyutlandırma ve — cloud-init kullanmıyorsanız — konuk içindeki hostname ile statik IP ayarı.
# Klona uygun kaynakları ver
qm set 152 --memory 4096 --cores 2 --name web-prod-01
# Diski büyütmek gerekiyorsa (küçültmek MÜMKÜN DEĞİLDİR)
qm resize 152 scsi0 +20G
# Cloud-init kullanıyorsanız ağ ve kullanıcı ayarları da tek satırda
qm set 152 --ipconfig0 ip=185.12.34.56/24,gw=185.12.34.1
Disk büyütmeyle ilgili kritik nokta: qm resize yalnızca sanal diski büyütür; konuk içindeki bölüm ve dosya sistemi otomatik büyümez. Cloud-init kurulu bir imajda bu genellikle ilk açılışta halledilir, değilse konuk içinde growpart ve resize2fs çalıştırmanız gerekir. Bölümleme mantığına yabancıysanız disk bölümleme: fdisk ve parted yazısı bu adımı netleştirir.
Klondan sonra ağ ve kullanıcı ayarlarını elle yapmak istemiyorsanız doğru araç cloud-init'tir; şablon + cloud-init birleşimi, tek komutla tamamen hazır bir sunucu üretmenizi sağlar. Bu akışın tamamı için cloud-init ile otomatik VM kurulumu yazısına bakın.
Şablonu Güncel Tutma Stratejisi#
Şablonlar bayatlar. Altı ay önce hazırladığınız bir imajdan üretilen her makine, ilk açılışta yüzlerce paket güncellemesi indirmek zorunda kalır ve güvenlik açığı olan bir çekirdekle bir süre çalışır. Şablonu güncel tutmanın iki yöntemi vardır.
Birinci yöntem: şablonu klonlayıp güncelleyip yeni şablon üretmek. Şablonlar başlatılamadığı için doğrudan güncelleyemezsiniz; onun yerine geçici bir full clone alır, açar, günceller, temizler, kapatır ve onu yeni şablon yaparsınız. Sürüm numarasını isme yazmak takip etmeyi kolaylaştırır:
# Mevcut şablondan geçici çalışma makinesi üret
qm clone 9000 9001 --name debian-base-yeni --full
qm start 9001
# ... güncelle, temizle, kapat ...
qm template 9001
qm set 9001 --name debian12-base-2026-08
İkinci yöntem: şablonu betikle sıfırdan üretmek. Dağıtımların yayımladığı bulut imajlarını indirip qm importdisk ile içeri alarak her seferinde taze bir şablon oluşturursunuz. Bu yaklaşım tekrarlanabilir olduğu için uzun vadede daha sağlamdır ve yapılandırma yönetimi araçlarıyla iyi eşleşir; Ansible ile sunucu otomasyonu yazısındaki yaklaşımı şablon üretimine de uygulayabilirsiniz.
Hangi yöntemi seçerseniz seçin, iki alışkanlık edinin: şablon adına tarih yazın ve eski şablonu hemen silmeyin. Yeni şablondan üretilen ilk makineler sorunsuz çalıştığında eskisini kaldırırsınız. Linked clone kullanıyorsanız zaten eski şablonu silemezsiniz — ona bağlı klonlar var oldukça Proxmox buna izin vermez.
Sık Yapılan Hatalar#
En yaygın hata, temizlik adımını atlamaktır. Klonlar aynı machine-id, aynı SSH host anahtarı ve aynı cloud-init durumuyla doğar. Sonuç: DHCP çakışmaları, SSH istemcilerinde "host key changed" uyarıları ve cloud-init'in ilk açılış görevlerini hiç çalıştırmaması. Bu sorunlar klonlama anında değil, günler sonra ortaya çıktığı için sebebi bulmak zordur.
İkinci hata, linked clone'u üretimde kullanmaktır. Test ortamında harikadır ama üretimde şablonu depolama açısından tek hata noktası hâline getirir, klonu başka düğüme taşımanızı zorlaştırır ve zamanla performans açısından ek katman yaratır. Üretim makinelerini --full ile klonlayın.
Üçüncü hata, şablonu çok yüklü hazırlamaktır. "Nasılsa lazım olur" diyerek veritabanı, web sunucusu, izleme ajanı ve on tane araç kurulmuş bir temel imaj, ürettiği her makineye gereksiz yüzey ve gereksiz güncelleme yükü bindirir. Şablon minimal olmalı, farklılaşma cloud-init ya da yapılandırma yönetimiyle sağlanmalıdır.
Dördüncü hata, diski gereğinden büyük tanımlamaktır. Sanal diski sonradan büyütebilirsiniz ama küçültmek pratikte mümkün değildir. Şablonu makul bir boyutta (örneğin 16-20 GB) tutun; ihtiyacı olan klonda qm resize ile büyütün.
Beşinci hata, şablonu yedeklemeyi unutmaktır. Şablon da bir makinedir ve vzdump ile yedeklenmelidir. Onlarca linked clone'un dayandığı bir şablonu kaybetmek, tek bir makineyi kaybetmekten çok daha pahalıdır.
Sıkça Sorulan Sorular#
Linked clone mu full clone mu kullanmalıyım#
Kısa cevap: üretim için full clone, test ve geliştirme için linked clone. Linked clone saniyeler içinde oluşur ve neredeyse yer kaplamaz, bu yüzden kısa ömürlü makineler için idealdir. Ama kaynağa bağımlıdır: şablonu silemez, klonu serbestçe başka düğüme taşıyamazsınız. Üretim sunucularının bağımsız olmasını istersiniz, bu yüzden orada tam kopya tercih edilir.
Şablonu sonradan değiştirebilir miyim#
Doğrudan değiştiremezsiniz; şablonlar başlatılamaz ve salt okunurdur. Standart yöntem, şablondan geçici bir full clone alıp onu açmak, güncellemeleri ve değişiklikleri yapmak, temizlik adımlarını uygulayıp kapatmak ve o makineyi yeni şablona dönüştürmektir. Eski şablonu, yeni şablondan üretilen makineler sorunsuz çalışana kadar silmeyin.
Klonlanan makinelerin IP'si neden çakışıyor#
Neredeyse her zaman sebep, temizlenmemiş /etc/machine-id dosyasıdır. Modern DHCP istemcileri istemci kimliğini bu değerden türetir; aynı kimliği sunan iki makine, DHCP sunucusundan aynı kiralamayı ister. Çözüm, şablona dönüştürmeden önce dosyayı truncate -s 0 /etc/machine-id ile boşaltmaktır. Zaten klonlanmış makinelerde aynı komutu çalıştırıp yeniden başlatmak sorunu giderir.
Şablondan kaç klon üretebilirim#
Teknik bir üst sınır yoktur; sınırı depolama alanınız ve düğümün kaynakları belirler. Linked clone kullanıyorsanız her klon başlangıçta neredeyse yer kaplamaz, ama zamanla değişen bloklar biriktikçe büyürler — yani "yüz linked clone bedava" değildir. Full clone'da ise her klon kaynağın tamamı kadar yer kaplar; disk planlamanızı buna göre yapın.
Şablonu başka Proxmox düğümüne nasıl taşırım#
En temiz yol vzdump ile şablonun yedeğini alıp hedef düğümde geri yüklemek ve orada tekrar qm template çalıştırmaktır. Küme (cluster) yapısındaysanız ve şablon paylaşımlı depolamadaysa zaten tüm düğümlerden erişilebilir. Linked clone'ları olan bir şablonu taşımaya kalkışmayın; önce klonları full clone'a dönüştürmeniz gerekir.
Windows makineler için de şablon kullanabilir miyim#
Evet, mantık aynıdır ama temizlik adımı farklıdır: Linux'taki machine-id temizliğinin karşılığı, Windows'ta sysprep aracıyla makineyi genelleştirmektir. Sysprep çalıştırılmadan klonlanan Windows makineler aynı SID değerini paylaşır ve bu, etki alanına katılma başta olmak üzere birçok sorun çıkarır. Ayrıca şablona dönüştürmeden önce VirtIO sürücülerini ve guest agent'ı kurmuş olmanız gerekir.
Kapanış#
Şablon ve klonlama, sanallaştırmadan alacağınız verimin büyük kısmını tek başına açıklar: kurulumu bir kez yapar, sonrasında sunucuyu üretirsiniz. Aklınızda kalması gereken dört alışkanlık şunlar: şablonu minimal tutun, şablona dönüştürmeden önce machine-id, SSH anahtarları ve cloud-init durumunu mutlaka temizleyin, üretim makinelerini full clone ile üretin ve şablonunuza tarih yazıp düzenli olarak tazeleyin.
Bu akışı kendi altyapınızda kurmak istiyorsanız tam root erişimli VDS ve sanal sunucu paketlerimizle kendi Proxmox düğümünüzü çalıştırabilir, iç içe sanallaştırma gerektiren senaryolar için nested sunucu seçeneğine bakabilirsiniz. Şablon yönetimi, yedekleme ve güncelleme döngüsünü devretmek isterseniz sunucu yönetimi ve yedekleme hizmetlerimiz bu işi sizin yerinize üstlenir.