Broadcom’un VMware lisanslama modelinde yaptığı radikal değişikliklerin ardından, kurumsal veri merkezlerinde VMware vSphere’den KVM tabanlı platformlara (Proxmox VE, OLVM, OpenStack) geçiş projeleri hız kazandı. Ancak 32Gbps Fibre Channel SAN üniteleri (Pure Storage, NetApp) üzerinde çalışan yüzlerce sanal makineyi ve çok terabaytlık veritabanlarını taşırken en büyük engel sanal makineleri kopyalamak değil; minimum kesinti süresi (downtime), initramfs sürücü uyumsuzlukları ve paylaşımlı SAN LUN mimarisinin yeniden kurgulanmasıdır.
Bugünkü yazımızda, kurumsal bir vSphere kümesinden Proxmox VE / KVM ortamına geçiş yaparken karşılaşacağınız teknik tuzakları ve sahada kanıtlanmış göç (migration) adımlarını inceliyoruz.
1. En Büyük Mimari Fark: VMFS-6 vs. Paylaşımlı LVM (Shared LVM)
VMware dünyasından gelen sistem mühendislerinin Proxmox VE veya saf KVM’e geçerken yaşadığı ilk kültür şoku Dosya Sistemi (Clustered File System) katmanıdır.
- VMware ESXi (VMFS-6): SAN üzerinden tüm sunuculara paylaştırılan tek bir LUN, VMFS-6 ile formatlanır. Kümedeki tüm ESXi sunucuları bu dosya sistemini aynı anda görür; Thin Provisioning ve yerel Snapshot işlemleri doğrudan VMFS katmanında çözülür.
- Proxmox VE / KVM (FC SAN Üzerinde): Klasik Fibre Channel veya iSCSI SAN LUN’larını Proxmox kümesine bağladığınızda, standart kurumsal yöntem LUN üzerine Paylaşımlı LVM (Thick LVM on Multipath) kurmaktır (
Shared=Yes). Proxmox, aynı LUN üzerindeki farklı Logical Volume’ları (LV) farklı KVM düğümlerinde kilit çakışması olmadan çalıştırır ve Live Migration yapar.
Kritik Fark: Paylaşımlı Thick LVM üzerinde doğrudan hipervizör katmanında LVM-Thin kullanılamaz (meta veri kilitleme / locking mimarisi tek düğüm içindir). Eğer FC SAN üzerinde anlık görüntü (Snapshot) ve Thin Provisioning istiyorsanız; ya bu işlemleri Storage Array API entegrasyonu / SAN seviyesinde çözmeli ya da blok depolamayı Ceph / ZFS over iSCSI katmanına taşımalısınız.
2. Göç Öncesi Altın Kural: initramfs İçine VirtIO Sürücülerini Gömün!
VMware üzerinde çalışan bir Linux (RHEL, Rocky, CentOS, Ubuntu) veya Windows sanal makinesini doğrudan Proxmox’a taşıyıp başlattığınızda karşılaşılan en klasik hata dracut-initqueue timeout – /dev/mapper/rl-root does not exist veya Windows’ta INACCESSIBLE_BOOT_DEVICE mavi ekranıdır.
Sebep: Sanal makine VMware üzerinde VMware PVSCSI (vmw_pvscsi) ve VMXNET3 (vmxnet3) sürücüleriyle açılmaya alışmıştır. Özellikle RHEL/CentOS türevlerinde dracut, sadece o an sunucuda takılı olan donanımın sürücüsünü initramfs imajına dahil eder.
A. RHEL / Rocky / CentOS / Oracle Linux VM’lerde Göç Öncesi Hazırlık
VM hala VMware üzerinde çalışırken (kesinti penceresinden önce) aşağıdaki komutla KVM VirtIO blok ve ağ sürücülerini önyükleme imajına zorla ekleyin:
# 1. Mevcut initramfs içinde virtio sürücülerinin olup olmadığını kontrol edin
lsinitrd /boot/initramfs-$(uname -r).img | grep virtio
# 2. Eğer yoksa, dracut yapılandırmasına virtio modüllerini kalıcı olarak ekleyin
echo 'add_drivers+=" virtio virtio_blk virtio_scsi virtio_net virtio_pci "' | sudo tee /etc/dracut.conf.d/virtio.conf
# 3. Initramfs imajını yeniden oluşturun
sudo dracut -f -v(Not: Ubuntu/Debian sistemlerde varsayılan MODULES=most ayarı sayesinde virtio_scsi genellikle initrd.img içinde hazır gelir, ancak yine de lsinitramfs ile doğrulamak iyi bir pratiktir).
B. Ağ Arayüzü İsim Değişikliği (ens192 -> ens18) Tuzağı
Linux çekirdeğinin Predictable Network Interface Names mekanizması, PCIe veri yolu adresine göre ağ kartına isim verir. VMware’de ens160 veya ens192 olan ağ kartınız, KVM üzerinde ens18 veya enp6s18 adına dönüşür ve sunucu açıldığında IP alamaz!
- Kesin Çözüm: Göç öncesinde
/etc/netplan/veya/etc/NetworkManager/system-connections/yapılandırmasında arayüzü isme göre değil, MAC adresine (match: macaddress) göre eşleştirin ve KVM’de VM oluştururken aynı MAC adresini koruyun.
| Göç Yöntemi | Kesinti Süresi (Downtime) | Nasıl Çalışır? | En Uygun Senaryo |
|---|---|---|---|
| 1. Proxmox Native ESXi Import Wizard | Orta / Düşük | ESXi API üzerinden vmdk’yı FUSE ile bağlar; veriyi arka planda kopyalarken VM’i KVM üzerinde hemen açabilir (Live Restore benzeri). | Standart uygulama sunucuları (50GB – 500GB diskli VM’ler). |
| 2. SAN RDM / Doğrudan Blok Aktarımı (dd / qemu-img) | Düşük | Aynı SAN switch fabric’ine bağlı ESXi ve KVM hostlar arasında blok kopyalama veya Raw LUN (RDM) bağlantısının kesilip KVM’e doğrudan bağlanması. | Devasa (5TB+) dosya sunucuları veya RDM disk kullanan sistemler. |
| 3. Uygulama Katmanı Replikasyonu (Patroni / Galera / Log Shipping) | Sıfıra Yakın (Saniyeler) | VM taşınmaz! KVM üzerinde temiz sunucu kurulur, mevcut VMware’deki DB kümesine Replica/Node olarak eklenir ve Switchover yapılır. | Tier-1 Veritabanları (PostgreSQL, MySQL, OpenSearch, Kafka). |
Kritik Tavsiye: Veritabanlarını Asla VMDK Kopyalayarak Taşımayın!
Üzerinde yoğun I/O olan bir PostgreSQL, Percona XtraDB veya OpenSearch sunucusunu hipervizör seviyesinde disk dönüştürerek (vmdk -> raw/qcow2) taşımak yerine; Proxmox üzerinde XFS/LVM ve çekirdek ayarları optimize edilmiş yeni bir Linux VM ayağa kaldırıp replikasyon (Streaming Replication / IST-SST / Shard Rebalancing) ile veriyi senkronize edin. Ardından sadece VIP/DNS değiştirerek 2-3 saniye kesintiyle geçişi tamamlayın.
4. VMware Tools Temizliği ve qemu-guest-agent Geçişi
Sanal makine KVM üzerinde ayağa kalktıktan sonra yapılan önemli hatalardan biri open-vm-tools servisini içeride çalışır bırakmaktır. Bunun yerine hipervizörün VM’i sağlıklı dondurabilmesi (fsfreeze ile tutarlı yedek alma) ve IP bilgilerini okuyabilmesi için qemu-guest-agent devreye alınmalıdır:
# Ubuntu / Debian üzerinde geçiş:
sudo apt purge -y open-vm-tools && sudo apt install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent
# RHEL / Rocky / AlmaLinux üzerinde geçiş:
sudo dnf remove -y open-vm-tools && sudo dnf install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent