VMware’ın Broadcom tarafından satın alınmasının ardından ürün portföyü, lisanslama modeli ve paket yapısında önemli değişiklikler yaşandı. Özellikle yeni abonelik modelleri ve maliyetlerin yeniden şekillenmesi, birçok kurumun mevcut sanallaştırma altyapısını yeniden değerlendirmesine neden oldu.

Bu süreçte Sangfor, VergeIO, HPE VM Essentials gibi ticari ürünlerin yanı sıra KVM tabanlı açık kaynak çözümler ve özellikle Proxmox VE, VMware alternatifi arayan kurumların değerlendirdiği platformlar arasında önemli bir konuma geldi. Ancak alternatif bir hypervisor seçmek, dönüşüm projesinin yalnızca başlangıcıdır.

Asıl kritik aşama; yıllardır VMware üzerinde çalışan sanal makinelerin, servislerin ve uygulamaların yeni platforma kontrollü, ölçülebilir ve geri dönüşü mümkün olacak şekilde taşınmasıdır.

VMware’den Proxmox’a migration işlemini sadece: “VMDK dosyasını kopyalayıp VM’i açmak” olarak değerlendirmek oldukça risklidir. Başarılı bir migration projesinde sanal makinenin yanında işletim sistemi, sürücüler, network, storage, CPU özellikleri, UEFI/BIOS, TPM, uygulama bağımlılıkları, lisanslama, backup, monitoring ve rollback senaryoları da birlikte değerlendirilmelidir. Proxmox’un kendi migration dokümantasyonu da production sistemlere geçmeden önce test VM’leri ile migration yönteminin doğrulanmasını özellikle tavsiye etmektedir.

Migration Projesine VM Taşımak Olarak Değil, Platform Dönüşümü Olarak Bakın

VMware’den Proxmox’a geçişte yapılabilecek en önemli hata, mevcut VMware ortamını birebir Proxmox üzerinde yeniden oluşturmaya çalışmaktır. İki platformun mimarisi, network yaklaşımı, storage yönetimi, HA mekanizmaları, backup entegrasyonu ve sanal donanım modelleri birbirinden farklıdır. Bu nedenle migration öncesinde öncelikle hedef Proxmox mimarisi tasarlanmalıdır.

Örneğin; VMware tarafında kullanılan datastore yapısının Proxmox tarafında ZFS, Ceph, LVM-Thin, NFS, iSCSI veya farklı bir storage mimarisine nasıl karşılık geleceği belirlenmelidir. VMware Distributed Switch üzerinde bulunan VLAN’ların Proxmox Linux Bridge, Bond veya SDN tarafında nasıl karşılanacağı planlanmalıdır. vSphere HA yerine Proxmox HA kullanılacaksa cluster quorum yapısı ve fencing mantığı ayrıca değerlendirilmelidir.

Yani önce hedef platform hazırlanmalı, daha sonra VM’ler bu platforma taşınmalıdır.

İlk Adım: Mevcut VMware Ortamının Envanterini Çıkarın

Migration operasyonuna başlamadan önce bütün VM’lerin bir envanteri çıkarılmalıdır. Ancak bu envanter sadece; VM adı, CPU, RAM ve disk kapasitesinden oluşmamalıdır. Her VM için mümkün olduğunca aşağıdaki bilgilerin bilinmesi gerekir:

• İşletim sistemi ve sürümü
• CPU ve RAM miktarı
• Disk sayısı ve kapasiteleri
• Thin/Thick disk yapısı
• Storage Controller tipi
• Network adaptör tipi
• IP adresleri
• VLAN bilgileri
• MAC adresleri
• DNS ve Gateway bilgileri
• BIOS veya UEFI kullanımı
• Secure Boot durumu
• TPM/vTPM kullanımı
• BitLocker veya disk şifreleme durumu
• VMware Tools sürümü
• Snapshot durumu
• USB/GPU/PCI Passthrough kullanımı
• RDM veya paylaşımlı disk kullanımı
• Uygulamanın başka sunuculara bağımlılıkları
• Backup politikası
• Monitoring politikası
• Uygulama lisanslama yöntemi
• Kabul edilebilir downtime süresi

Bu çalışma migration sırasında karşılaşılabilecek sürprizlerin önemli bölümünü daha başlamadan ortadan kaldırır.

VM’leri Risk Seviyelerine Göre Gruplandırın

Bütün sanal makineleri aynı yöntemle ve aynı migration penceresinde taşımak doğru değildir. Örneğin basit bir standalone Linux Web Server ile SQL Server Cluster veya Domain Controller aynı risk seviyesinde değerlendirilmemelidir.

Risk	Örnek Sistemler	Yaklaşım
Düşük	Test sunucuları, basit Web Server, bağımsız Linux sistemler	Pilot migration
Orta	File Server, uygulama sunucuları, IIS, bağımsız SQL Server	Planlı migration + uygulama testi
Yüksek	Domain Controller, SQL Cluster, ERP, kritik DB, lisans sunucuları	Ayrıntılı runbook + rollback
Çok Yüksek	Vendor appliance, GPU/vTPM kullanan VM, paylaşımlı disk/cluster sistemleri	Vendor desteği ve özel migration yöntemi

Ben production ortamında öncelikle birkaç düşük riskli sistem seçerek pilot migration yapılmasını tavsiye ederim. Pilot çalışma sonrasında kurumun kendi standart migration prosedürü oluşturulabilir.

VMware Snapshot’larını Temizleyiniz.

Migration öncesinde kontrol edilmesi gereken ilk konulardan biri snapshot yapısıdır. Uzun süre açık kalan VMware snapshot’ları migration işlemini hem karmaşıklaştırabilir hem de ciddi şekilde yavaşlatabilir. Migration yapılacak VM üzerinde mümkünse aktif snapshot bulunmamalı ve VMware tarafındaki disk consolidation işlemleri tamamlanmış olmalıdır. Özellikle büyük VM’lerde migration öncesinde: Snapshot Manager → Delete / Consolidate kontrolünün yapılması faydalıdır.

Proxmox dokümantasyonu da snapshot bulunan VMware VM’lerinin import işlemlerinin önemli ölçüde daha yavaş olabileceğini belirtmektedir. Ancak burada çok önemli bir ayrım var: Snapshot backup değildir. Migration öncesinde snapshot almak, bağımsız bir backup bulunması gerekliliğini ortadan kaldırmaz.

Migration Öncesinde Mutlaka Restore Edilebilir Bir Backup Bulundurun

Migration operasyonunun B planı mutlaka olmalıdır. Tercihen migration öncesindeki son backup’ın yalnızca başarılı olduğu değil, restore edilebilir olduğu da doğrulanmalıdır. Özellikle kritik sistemlerde: Backup var mı? sorusundan daha önemli olan soru: Bu backup’tan gerçekten geri dönebiliyor muyuz? olmalıdır. Kaynak VMware VM’in migration sırasında değiştirilmesi mümkün olduğunca minimum seviyede tutulmalıdır. Rollback gerektiğinde kaynak VM’in tekrar açılabilmesi migration tasarımının temel şartlarından biridir.

VMware Tools ve VirtIO Driver Planlaması

VMware ortamında Windows ve Linux VM’lerde genellikle VMware Tools bulunmaktadır. Proxmox tarafına geçildiğinde bunun yerini ağırlıklı olarak: VirtIO Drivers + QEMU Guest Agent alacaktır. Proxmox, eski hypervisor’a özgü guest araçlarının kaldırılmasını ve VirtIO sürücülerinin migration öncesinde guest işletim sisteminde hazır bulunmasını tavsiye etmektedir. Ancak production migration operasyonlarında burada biraz daha kontrollü davranmak faydalıdır. VMware Tools’u migration işleminden çok önce kaldırmak rollback senaryosunu gereksiz yere zorlaştırabilir.

Benim tercih edeceğim yöntem VirtIO sürücülerini önceden hazırlamak, VMware Tools kaldırma işlemini ise cutover aşamasına yakın veya Proxmox tarafındaki ilk başarılı açılıştan sonra gerçekleştirmek olacaktır. Böylece migration başarısız olduğunda VMware tarafına dönüş daha kolay olur.

Windows Server Migrationlarında En Kritik Konu: Storage Controller

VMware’den Proxmox’a geçişte Windows Server tarafında en fazla problem yaşanan konulardan biri storage controller değişimidir. VMware üzerinde Windows VM;

• LSI Logic SAS
• LSI Logic Parallel
• VMware Paravirtual / PVSCSI
• SATA gibi bir controller kullanıyor olabilir. Proxmox tarafında ise performans açısından genellikle VirtIO SCSI Single tercih edilmektedir.

Ancak Windows içerisinde VirtIO SCSI sürücüsü yüklü değilse işletim sistemi yeni storage controller’ı tanıyamaz. Sonuç olarak boot diski görülemez ve sistem INACCESSIBLE_BOOT_DEVICE gibi bir BSOD hatasıyla açılmayabilir. Bu nedenle Windows migration projelerinde VirtIO sürücülerinin hazırlanması kritik öneme sahiptir. Proxmox da hedef VM için SCSI + VirtIO SCSI Single kullanımını önerirken gerekli VirtIO sürücülerinin guest işletim sisteminde bulunması gerektiğini açıkça belirtmektedir.

Windows Açılmıyorsa SATA Workaround

Migration tamamlandıktan sonra Windows VirtIO SCSI üzerinden açılmıyorsa oldukça kullanışlı bir yöntem bulunmaktadır. Boot disk geçici olarak SATA üzerinden bağlanabilir.

Akış temel olarak şu şekildedir Migration → Boot Diski SATA Olarak Bağla → Windows’u Aç → VirtIO Driver Yükle → Shutdown → Diski VirtIO SCSI’ye Taşı → Yeniden Aç Windows, SATA controller’ı doğal olarak tanıdığı için VM büyük ihtimalle açılacaktır. Windows açıldıktan sonra VirtIO ISO bağlanarak storage ve network sürücüleri kurulabilir. Daha sonra VM kapatılarak disk tekrar: VirtIO SCSI Single controller üzerine alınabilir. Proxmox’un resmi migration dokümantasyonu da gerekli VirtIO storage driver bulunmayan Windows VM’lerde ilk boot için IDE veya SATA kullanılabileceğini belirtmektedir.

Network Adaptör Değişimine Dikkat Ediniz !!!

VMware ortamlarında VMXNET3 oldukça yaygın kullanılmaktadır. Proxmox tarafında ise genel olarak tercih edilen network adaptörü: VirtIO olacaktır. Ancak Windows yeni network kartını farklı bir cihaz olarak algılayacaktır. Bu nedenle migration öncesinde aşağıdaki bilgilerin mutlaka kayıt altına alınmasını tavsiye ederim:

IP Address
Subnet Mask
Default Gateway
DNS
VLAN
MAC Address
Static Route

Windows üzerinde eski VMXNET3 kartına statik IP atanmışsa yeni VirtIO karta aynı IP verilirken: “Bu IP başka bir network adapter tarafından kullanılmaktadır.” benzeri uyarılar alınabilir. Bunun nedeni artık görünmeyen eski network adaptörünün Windows registry içerisinde bulunmaya devam etmesidir. Gerekirse eski hidden NIC temizlenmelidir. DHCP reservation kullanılıyorsa eski MAC adresinin korunması veya DHCP reservation’ın yeni VirtIO MAC adresine göre güncellenmesi gerekir. Proxmox da DHCP reservation kullanılan ortamlarda yeni MAC adresinin dikkate alınması gerektiğini belirtmektedir.

Sadece VM Network’ünü Değil Fiziksel Network’ü de Kontrol Ediniz

Migration öncesinde Proxmox tarafındaki; Bridge → Bond → Physical NIC → Switch Port → VLAN zinciri uçtan uca doğrulanmalıdır. Özellikle VLAN trunk kullanılan ortamlarda VMware port group VLAN ID ile Proxmox tarafındaki bridge/VLAN yapısının doğru eşleşmesi gerekir. Ayrıca Jumbo Frame kullanılıyorsa MTU değerlerinin sadece Proxmox host üzerinde değil, switch ve storage network dahil olmak üzere uçtan uca aynı olduğundan emin olunmalıdır. LACP kullanılan ortamlarda switch tarafındaki port-channel yapılandırmasının da Proxmox bond modeli ile uyumlu olması gerekir. Yanlış VLAN veya MTU yapılandırması VM açıldıktan sonra “network çalışmıyor” şeklinde yorumlanabilir ve gereksiz yere guest işletim sisteminde troubleshooting yapılmasına neden olabilir.

BIOS, UEFI ve Secure Boot Kontrolü

Kaynak VM’in hangi firmware ile çalıştığı mutlaka belirlenmelidir. VMware tarafındaki sistem Legacy BIOS kullanıyorsa Proxmox üzerinde genel olarak: SeaBIOS kullanılır. VM UEFI kullanıyorsa: OVMF (UEFI) seçilmelidir. UEFI sistemlerde ayrıca EFI Disk yapılandırmasının doğru olması gerekir. Proxmox dokümantasyonu, bazı işletim sistemlerinin standart UEFI boot path yerine kendilerine ait boot entry oluşturabileceğini ve migration sonrasında UEFI boot kaydının yeniden oluşturulmasının gerekebileceğini belirtmektedir.

Migration sırasında gereksiz yere; BIOS → UEFI, i440fx → Q35, SATA → VirtIO, NIC tipi, CPU tipi gibi bütün donanım özelliklerini aynı anda değiştirmek troubleshooting sürecini zorlaştırır. İlk hedef VM’i çalıştırmak olmalıdır. Optimizasyonlar daha sonra kontrollü şekilde yapılabilir.

vTPM ve BitLocker Konusu Kesinlikle Atlanmamalı

Modern Windows Server ve Windows Client sistemlerde gözden kaçırılabilecek en kritik konulardan biri vTPM ve BitLocker’dır. VMware üzerinde bulunan vTPM state bilgisinin doğrudan Proxmox’a taşınması mümkün olmayabilir. Proxmox migration dokümantasyonu bu nedenle full-disk encryption kullanılan VM’lerde recovery key’in hazır bulundurulmasını özellikle önermektedir. Migration öncesinde: BitLocker Recovery Key mutlaka güvenli bir yerde bulunmalıdır. Aksi halde teknik olarak başarılı bir disk migration işlemi sonrasında VM açılsa bile encrypted disk’e erişilemeyebilir.

CPU Uyumluluğu

Kaynak VMware host ve hedef Proxmox node’larının CPU özellikleri karşılaştırılmalıdır. Özellikle uygulamalar; AES, AVX, AVX2, SSE4.x gibi CPU instruction set’lerine bağımlı olabilir. Proxmox cluster içerisindeki bütün node’larda aynı CPU modeli bulunuyorsa: CPU Type = host yüksek performans açısından değerlendirilebilir. Ancak farklı CPU jenerasyonları bulunan veya ileride farklı donanımlar eklenecek cluster’larda host kullanmak live migration kabiliyetini kısıtlayabilir.

Bu durumda Proxmox’un önerdiği uygun: x86-64-vX CPU modellerinden biri tercih edilebilir. Özellikle Intel → AMD veya AMD → Intel geçişlerinde application ve CPU flag bağımlılıkları ayrıca test edilmelidir.

Uygulama Lisanslarını Unutmayınız !

Bu konu teknik migration projelerinde sık sık gözden kaçar.

Bazı uygulamalar lisanslarını;

• MAC Address
• CPU ID
• BIOS UUID
• Machine UUID
• Disk Serial
• Host ID

gibi donanım bilgilerine bağlayabilir. Hypervisor değiştiğinde bu değerlerin bir kısmı değişebilir. Sonuç olarak işletim sistemi sorunsuz açılır ancak uygulama: “License Invalid” hatası verebilir. Bu nedenle özellikle ERP, CAD, lisans sunucuları, endüstriyel uygulamalar, güvenlik ürünleri ve vendor appliance sistemlerinde migration öncesinde üretici desteği ve lisans davranışı mutlaka kontrol edilmelidir. Windows aktivasyonunun da sanal donanım değişikliğinden etkilenebileceği göz önünde bulundurulmalıdır.

Vendor Appliance Sistemlere Özellikle Dikkat

Bir VM’in teknik olarak Proxmox üzerinde açılması, üreticisinin Proxmox’u desteklediği anlamına gelmez.

Örneğin bazı; Firewall appliance, Backup appliance, Network management appliance, Database appliance, Security appliance ürünlerinin üreticileri yalnızca VMware veya Hyper-V ortamlarını resmi olarak destekleyebilir. Bu nedenle kritik appliance sistemleri taşımadan önce üreticinin support matrix dokümanı kontrol edilmelidir. Aksi halde migration başarılı olsa dahi ileride açılacak destek kaydında üretici destek vermeyebilir.

VMware vSAN ve Şifreli Diskler İçin Ayrı Plan Yapın

Proxmox’un VMware importer mekanizması birçok standart ESXi datastore senaryosunda oldukça kullanışlıdır. Ancak özel storage yapıları ayrıca değerlendirilmelidir. Proxmox’un migration dokümantasyonu, doğrudan importer yönteminde vSAN üzerinde bulunan VM disklerinin ve encrypted VM disklerinin sınırlamalara sahip olabileceğini belirtmektedir. Bu nedenle böyle ortamlarda güncel Proxmox sürümüne ait destek durumu proje öncesinde mutlaka kontrol edilmelidir. Gerekirse VM önce VMware tarafında standart bir datastore’a Storage vMotion ile taşınabilir ve migration daha sonra yapılabilir.

Migration İçin Hangi Yöntem Kullanılabilir?

VMware’den Proxmox’a geçiş için tek bir doğru yöntem yoktur. Ortamın büyüklüğüne, VM disk kapasitesine, downtime toleransına ve network hızına göre farklı yöntemler kullanılabilir. En yaygın seçenekler şunlardır:

1. Proxmox VE Import Wizard

Standart VMware ESXi ortamları için ilk değerlendirilmesi gereken yöntemlerden biridir. ESXi ortamı Proxmox tarafında import source olarak tanımlanabilir ve VM’ler doğrudan arayüz üzerinden aktarılabilir.

2. OVF / OVA Export – Import

VM VMware tarafından OVF/OVA olarak export edilerek Proxmox tarafına alınabilir. CLI tarafında örneğin;

qm importovf 100 Server.ovf local-zfs

kullanılabilir.

3. Manual VMDK Disk Import

VMDK dosyaları Proxmox’a taşındıktan sonra;

qm disk import 104 Server.vmdk local-zfs

gibi bir yöntemle import edilebilir.

4. Backup / Restore

Kullanılan backup ürününün Proxmox restore desteği bulunuyorsa oldukça iyi bir alternatif olabilir. Burada Veeam, NAKIVO, Commvault, Cohesity, Acronis veya kullanılan diğer ürünlerin mevcut sürümünün Proxmox desteği mutlaka üreticinin güncel compatibility matrix’i üzerinden doğrulanmalıdır.

5. Üçüncü Parti V2V Araçları

StarWind V2V Converter, Clonezilla, virt-v2v veya ticari migration ürünleri belirli projelerde kullanılabilir. Ancak hangi yöntemin kullanılacağına sadece “hangisi daha kolay?” sorusuyla karar verilmemelidir.

Asıl kriterler; Downtime, veri büyüklüğü, geri dönüş süresi, uygulama kritiklik seviyesi ve desteklenebilirlik olmalıdır.

Live Import Güzel Bir Özellik, Ancak “Zero Downtime” Değildir

Proxmox’un Live Import özelliği büyük diskli VM’lerde downtime süresini önemli ölçüde azaltabilir. Burada önemli bir yanlış anlaşılmaya dikkat etmek gerekir. Live Import, kaynak VMware VM’in çalışmaya devam ettiği gerçek anlamda bir cross-hypervisor live migration değildir. Kaynak VM kapatılır ve hedef Proxmox VM gerekli disk bloklarını ihtiyaç oldukça kaynak sistemden okuyarak daha erken çalıştırılabilir. Kalan veriler arka planda aktarılır. Proxmox geliştiricileri de bu yöntemde hızlı ve kararlı bir network bağlantısının önemli olduğunu belirtmektedir. Dolayısıyla özellikle WAN üzerinden veya kararsız network bağlantısı bulunan ortamlarda dikkatli olunmalıdır.

Linux VM’ler Genellikle Daha Kolaydır Ama Risksiz Değildir

Linux işletim sistemleri VirtIO sürücülerini uzun süredir kernel içerisinde barındırdığı için migration işlemleri genellikle Windows’a göre daha kolaydır. Ancak yine de aşağıdaki konular kontrol edilmelidir. Network interface adı değişebilir. Örneğin: ens192 yerine farklı bir interface adı oluşabilir.

Ayrıca /etc/netplan, NetworkManager veya /etc/network/interfaces içerisindeki interface tanımları kontrol edilmelidir. Eski veya özel Linux dağıtımlarında VirtIO modüllerinin initramfs içerisinde bulunması gerekebilir. Proxmox da Linux VM’lerde gerekli VirtIO sürücülerinin initramfs içerisinde olduğunun doğrulanmasını önermektedir. /etc/fstab içerisinde device name yerine UUID kullanılmayan eski sistemlerde disk sırasının değişmesi de boot problemlerine neden olabilir.

Domain Controller, SQL ve Cluster Sistemleri Ayrı Değerlendirin

Her sanal makine klasik V2V yöntemiyle taşınmak zorunda değildir. Özellikle:

Active Directory Domain Controller
SQL Server Cluster
Oracle
File Cluster
Database Cluster
Shared Disk kullanan sistemler için uygulama seviyesinde migration bazen daha güvenli olabilir. Örneğin yeni bir Proxmox VM oluşturup Active Directory tarafında yeni Domain Controller kurmak ve replikasyon ile geçiş yapmak, eski DC’yi V2V olarak taşımaktan daha temiz bir seçenek olabilir. Benzer şekilde kritik database sistemlerinde native database replication, log shipping veya Always On gibi uygulama seviyesindeki yöntemler daha düşük risk sağlayabilir.

Yani: “VM taşınabiliyor mu?” sorusundan önce; “Bu servisi taşımanın en güvenli yolu gerçekten VM migration mı?” sorusu sorulmalıdır.

Storage Kapasitesini Sadece Kullanılan Alan Üzerinden Hesaplamayın

Migration öncesinde hedef storage kapasitesi dikkatli hesaplanmalıdır. Örneğin VMware tarafında 4 TB provision edilmiş ancak yalnızca 800 GB kullanılan thin disk, kullanılan migration yöntemine bağlı olarak beklenenden daha fazla geçici storage alanına ihtiyaç duyabilir. OVA/OVF export/import sırasında kaynak dosya, temporary extraction alanı ve hedef disk için aynı anda storage kapasitesi gerekebilir. Bu nedenle özellikle büyük VM’lerde migration başlamadan önce: Kaynak boyut + geçici alan + hedef alan hesabı yapılmalıdır. Storage’ın migration sırasında %100 dolması ciddi problemlere yol açabilir.

Migration Sonrasında Performansı Tekrar Ölçün

VM’in açılması migration’ın tamamlandığı anlamına gelmez. VMware ve Proxmox’un disk, CPU ve network davranışları birebir aynı değildir. Migration öncesinde kritik VM’ler için mümkünse aşağıdaki performans değerlerinden baseline alınmalıdır: CPU kullanımı, Memory kullanımı, Disk latency, IOPS, Throughput, Network throughput, Application response time. Migration sonrasında aynı değerler tekrar ölçülmelidir. Böylece kullanıcıların: “Sistem sanki eskisinden daha yavaş.” gibi subjektif geri bildirimleri yerine ölçülebilir veriler üzerinden değerlendirme yapılabilir.

QEMU Guest Agent Kurulmalı

Migration tamamlandıktan sonra QEMU Guest Agent kurulması tavsiye edilir. QEMU Guest Agent, Proxmox host ile guest işletim sistemi arasındaki iletişimi geliştirir. Shutdown operasyonları, IP bilgisinin görüntülenmesi ve backup sırasında guest filesystem ile daha sağlıklı koordinasyon gibi fonksiyonlarda fayda sağlar. Proxmox da VM best practice kapsamında QEMU Guest Agent kullanımını tavsiye etmektedir.

Zaman Senkronizasyonunu Kontrol Edin

VMware Tools kaldırıldıktan sonra VMware Tools üzerinden sağlanan time synchronization mekanizması da ortadan kalkabilir. Bu nedenle migration sonrasında; Windows tarafında Windows Time / NTP, Linux tarafında chrony / systemd-timesyncd / NTP kontrol edilmelidir. Özellikle Domain Controller ve database sistemlerinde zaman farkları ciddi problemlere neden olabilir.

Backup ve Monitoring Yapısını Yeniden Oluşturun

Migration tamamlandıktan sonra eski VMware backup job’larının VM’i artık korumadığını unutmamak gerekir. VM Proxmox tarafına taşındıktan hemen sonra: backup politikası, retention, off-site kopya, restore testi yeniden yapılandırılmalıdır. Aynı durum monitoring için de geçerlidir. Eski vCenter üzerinden VM health alan monitoring sistemi Proxmox VM’i artık göremeyebilir. Bu nedenle monitoring, SIEM, backup, vulnerability scanner ve asset management gibi bütün entegrasyonlar yeniden kontrol edilmelidir.

Rollback Planı Migration Planından Önce Hazırlanmalı

Bir migration planının en kritik bölümü başarılı senaryo değil, başarısız senaryodur.

Örneğin:

22:00 – Uygulama erişimi kapatılır
22:05 – Servisler durdurulur
22:10 – Kaynak VMware VM shutdown
22:15 – Final backup kontrolü
22:20 – Migration başlatılır
23:30 – Proxmox VM boot
23:45 – Network kontrolü
00:00 – Application test
00:20 – Kullanıcı kabul testi
00:30 – Go / No-Go kararı

şeklinde önceden tanımlanmış bir çalışma planı bulunmalıdır. En önemlisi de: 00:30’dan sonra problem devam ediyorsa VMware tarafına geri dönülecek gibi net bir karar noktası belirlenmelidir. Aksi halde ekip saatlerce troubleshooting yaparken maintenance window sona erebilir.

Eski VMware VM’i Hemen Silmeyiniz.

Migration başarılı olduktan sonra kaynak VMware VM’in hemen silinmesini tavsiye etmem. Bunun yerine; VM kapalı durumda tutulabilir, network bağlantısı kesilebilir, ismi OLD_ veya MIGRATED_ gibi bir prefix ile değiştirilebilir. Belirlenen rollback süresi tamamlandıktan ve Proxmox tarafındaki backup doğrulandıktan sonra eski VM kaldırılabilir. Ancak eski ve yeni VM kesinlikle aynı anda production network üzerinde çalıştırılmamalıdır. Aksi halde duplicate IP, duplicate hostname ve uygulama veri tutarsızlıkları meydana gelebilir.

Migration Sonrası Kabul Testi Yapılmalı

Migration operasyonunun sonunda yalnızca: Ping başarılı. Windows açıldı. demek yeterli değildir. Kontroller en az dört seviyede yapılmalıdır: Infrastructure → Operating System → Application → User Önce Proxmox VM’in CPU, RAM, storage ve network tarafı doğrulanmalıdır. Daha sonra işletim sistemi logları incelenmelidir. Ardından SQL, IIS, ERP, File Server veya ilgili uygulama servisleri kontrol edilmelidir. Son olarak mümkünse uygulamayı gerçekten kullanan bir kullanıcı ile fonksiyon testi yapılmalıdır.

Benim Tavsiye Ettiğim Migration Yaklaşımı

Büyük bir VMware ortamında bütün VM’leri aynı hafta sonu taşımak yerine dalgalar halinde ilerlemek daha güvenlidir.

Wave 0 – Lab / Test : Migration yöntemi ve runbook doğrulanır.

Wave 1 – Düşük Risk : Test, development ve basit production sistemler taşınır.

Wave 2 – Orta Risk : Web, application ve file server sistemleri taşınır.

Wave 3 – Kritik Sistemler : Database, ERP ve kritik uygulamalar taşınır.

Wave 4 – Özel Sistemler : Cluster, appliance, GPU, TPM ve vendor bağımlılığı bulunan sistemler taşınır.

Her dalganın sonunda karşılaşılan problemler ve çözümleri runbook’a eklenir. Böylece migration ekibi her aşamada daha tecrübeli hale gelir.

VMware’den Proxmox VE’ye migration teknik olarak yapılabilir ve doğru planlandığında oldukça başarılı sonuçlar alınabilir. Ancak başarılı bir migration projesinin sırrı kullanılan conversion aracından çok hazırlık, test ve geri dönüş planıdır. Özellikle Windows Server sistemlerde: VirtIO sürücüleri, storage controller, network adaptörü, BIOS/UEFI, Secure Boot, TPM ve BitLocker konuları önceden kontrol edilmelidir. Bunun yanında uygulama lisansları, vendor desteği, backup, monitoring ve application bağımlılıkları da migration kapsamının bir parçası olarak değerlendirilmelidir. En önemli yaklaşım ise şudur:

Önce hedef Proxmox altyapısını doğru tasarlayın.
Sonra test edin.
Pilot VM’leri taşıyın.
Standart bir migration runbook oluşturun.
Production sistemleri dalgalar halinde taşıyın.
Her aşamada rollback imkanını koruyun.

Çünkü migration operasyonunda temel amaç yalnızca bir VM’i başka bir hypervisor üzerinde çalıştırmak değildir. Asıl amaç; servis kesintisini minimumda tutarak, veriyi kaybetmeden, performansı koruyarak ve gerektiğinde güvenli şekilde geri dönebilecek bir altyapı dönüşümü gerçekleştirmektir.