VMware’den Hyper-V’ye Sanal Makine Taşıma: Araçlar ve Adımlar

Platform kararı verildi; şimdi onlarca, bazen yüzlerce sanal makineyi VMware vSphere’den Hyper-V’ye veri kaybetmeden ve kabul edilebilir kesintiyle taşımanız gerekiyor. Taşımayı zorlaştıran şey dönüşüm aracı değil; atlanan snapshot, initramfs’te olmayan bir sürücü, gizli kalan eski ağ kartıdır. Bu rehber dönüşüm yöntemlerini, Generation 1/2 seçimini, Windows ve Linux VM’lerde sahada en çok karşılaşılan sürücü ve ağ sorunlarını, dalga planını ve taşıma sonrası kontrolleri sırasıyla veriyor.

Taşıma öncesi envanter ve bağımlılık analizi

Taşınacak sistem altyapısındaki her VM için aşağıdaki bilgileri tek tabloda toplayın. Dalga planı da geri dönüş kararı da bu tablodan çıkar:

• İşletim sistemi ve sürümü, firmware tipi (BIOS veya EFI), disk bölümleme şeması (MBR/GPT)
• vCPU, bellek, disk sayısı ve boyutları, thin/thick provisioning, mevcut snapshot’lar
• Ağ kartı sayısı, VLAN’lar, statik IP, DNS ve ağ geçidi; MAC adresine bağlı lisans var mı
• Bağımlı olduğu ve ona bağımlı sistemler (veritabanı, uygulama sunucusu, dosya paylaşımı)
• RDM (Raw Device Mapping), USB passthrough, paylaşımlı disk (MSCS/WSFC kümesi) gibi özel yapılandırmalar
• İzin verilen kesinti süresi ve işin sahibi

Bu verinin büyük kısmı PowerCLI ile tek betikte çıkar:

Get-VM | Select-Object Name, PowerState, NumCpu, MemoryGB,
  @{N='Firmware';E={$_.ExtensionData.Config.Firmware}},
  @{N='GuestOS';E={$_.ExtensionData.Config.GuestFullName}},
  @{N='DiskGB';E={($_ | Get-HardDisk | Measure-Object CapacityGB -Sum).Sum}},
  @{N='Snapshots';E={($_ | Get-Snapshot).Count}} |
  Export-Csv .\vm-envanter.csv -NoTypeInformation -Encoding UTF8

Snapshot’ı olan VM’i dönüşümden önce konsolide edin. Etmezseniz dönüştürdüğünüz disk zincirin yalnızca bir parçası olabilir ve eksik veriyi ancak uygulama açıldığında fark edersiniz. RDM ve paylaşımlı diskli VM’ler ayrı tasarım ister: Hyper-V tarafındaki karşılıkları pass-through disk, konuktan doğrudan iSCSI bağlantısı ya da paylaşılan VHDX/VHD Set olabilir. Envanterde “özel” sütunu boş değilse o VM pilot dalgaya girmez.

Dönüşüm yöntemleri karşılaştırması

Microsoft Virtual Machine Converter (MVMC) yıllar önce emekliye ayrıldı. Bugün kullanılan başlıca yöntemler şunlar:

Yedekten geri yükleme, yedekleme ürününüz destekliyorsa (ör. Veeam Backup & Replication’ın VMware yedeğini Hyper-V’ye geri yükleme özelliği) en pratik yoldur. Yedek mevcut yedekleme ve felaket kurtarma düzeninde zaten alınıyordur, disk formatı geri yükleme sırasında dönüştürülür ve kaynak VM’e dokunulmaz. Özelliğin sizin sürümünüzde desteklendiğini ve hangi konuk işletim sistemlerini kapsadığını üretici dokümantasyonundan doğrulayın.

Disk dönüştürmede açık kaynak qemu-img yaygın kullanılır. Dönüştürmeyi VM kapalıyken ve tutarlı bir disk üzerinde yapın. Descriptor (vm.vmdk) ile veri dosyası (vm-flat.vmdk) aynı klasörde olmalı; yalnız flat dosyayı kopyalamak sahada sık yapılan bir hatadır:

qemu-img convert -p -f vmdk -O vhdx -o subformat=dynamic vm.vmdk vm.vhdx

Dönüştürülen VHDX’in bütünlüğünü Hyper-V hostunda kontrol edin:

Test-VHD -Path D:\VMs\app01\app01.vhdx
Get-VHD  -Path D:\VMs\app01\app01.vhdx | Select-Object VhdFormat, VhdType, Size, FileSize

Domain controller’ı dönüştürmeyin; yeni bir DC kurup rolleri taşıyın. Dönüştürülmüş kopya ile kaynak DC’nin yanlışlıkla aynı anda açılması ya da kopyanın snapshot’tan alınması USN geri alma (USN rollback) sorununa yol açabilir. Yeni DC kurmak bu riski baştan kapatır.

Generation 1 mi Generation 2 mi

Generation 2 VM UEFI ile açılır, Secure Boot ve vTPM destekler, önyükleme diski SCSI denetleyicisindedir. Generation 1 BIOS emülasyonu kullanır ve IDE denetleyiciden önyükler. Seçimi kaynak VM’in firmware’i belirler:

• VMware’de EFI firmware ve GPT diskli VM → Generation 2
• VMware’de BIOS firmware ve MBR diskli VM → Generation 1 (ya da önce GPT’ye dönüştürüp Generation 2)

Windows’ta MBR diski GPT’ye çevirmek için MBR2GPT.exe kullanılabilir. Aracın desteklediği işletim sistemi sürümlerini ve önkoşullarını (en fazla üç bölüm, sistem bölümü vb.) önceden kontrol edin, işlemi yedeği alınmış bir kopya üzerinde yapın. Generation, VM oluşturulduktan sonra değiştirilemez. Yanlış seçim yeniden kurulum demektir.

Windows VM taşıma adımları

1. Kaynakta hazırlık: IP yapılandırmasını kaydedin (ipconfig /all çıktısı), bekleyen güncellemeleri bitirin, yerel yönetici parolasını doğrulayın. Konsolda parola bilmeden kalmak kesim penceresini yer.
2. VMware Tools’u kaynakta kaldırın: Hyper-V üzerinde kaldırmayı denemek, yükleyici VMware ortamını bulamadığı için sorun çıkarabilir. Kaldırma VMXNET3 sürücüsünü de götürdüğünden VM ağ bağlantısını kaybeder; bu adımı vSphere konsolundan, kesim penceresinin son adımı olarak yapın ve ardından gelen yeniden başlatmayı süreye ekleyin.
3. VM’i kapatın ve dönüştürün (yedekten geri yükleme veya disk dönüştürme).
4. Hyper-V’de VM’i oluşturun ve diski bağlayın:

   New-VM -Name app01 -Generation 2 -MemoryStartupBytes 8GB `
     -VHDPath D:\VMs\app01\app01.vhdx -SwitchName vSwitch-Prod -Path D:\VMs
   Set-VMProcessor -VMName app01 -Count 4
   Set-VMNetworkAdapterVlan -VMName app01 -Access -VlanId 120
   Set-VMFirmware -VMName app01 -FirstBootDevice (Get-VMHardDiskDrive -VMName app01)

5. İlk açılış: Windows Server 2016 ve sonrası Hyper-V integration services bileşenlerini işletim sistemiyle birlikte getirir. Ağ kartı yeni aygıt olarak görüneceği için statik IP’yi yeniden girin.
6. Gizli eski ağ kartını temizleyin: Aygıt Yöneticisi’nde gizli aygıtları gösterip eski VMXNET3 adaptörünü kaldırın. Kaldırmazsanız aynı IP’yi atarken “başka bir adaptörde kullanılıyor” uyarısı alırsınız.
7. Lisans ve etkinleştirme: Donanım değiştiği için Windows etkinleştirmesini ve MAC adresine bağlı uygulama lisanslarını kontrol edin. Gerekirse VM’e statik MAC adresi atayın.

Linux VM’lerde dikkat edilecekler

Güncel Linux çekirdekleri Hyper-V sürücülerini (hv_vmbus, hv_storvsc, hv_netvsc) içerir. Sorun genellikle sürücünün yokluğu değil, initramfs içinde bulunmamasıdır. VMware üzerinde üretilmiş initramfs disk denetleyicisi sürücüsünü içermiyorsa VM Hyper-V’de kök dosya sistemini bulamaz ve dracut acil kabuğuna düşer. Konsolda bu ekranı gördüyseniz sebep büyük ihtimalle budur. Önlem kaynakta, taşımadan önce alınır:

# RHEL, Rocky, AlmaLinux
dracut -f --add-drivers "hv_vmbus hv_storvsc hv_netvsc"

# Debian, Ubuntu
printf "hv_vmbus\nhv_storvsc\nhv_netvsc\n" >> /etc/initramfs-tools/modules
update-initramfs -u

Diğer kontrol noktaları:

• fstab: Diskleri /dev/sdX yerine UUID veya etiketle bağlayın; denetleyici değişince aygıt sırası değişebilir.
• Ağ arayüzü adı: ens192 gibi adlar Hyper-V’de farklı olacaktır (çoğunlukla eth0). Netplan, NetworkManager veya ifupdown yapılandırmasını yeni ada göre güncelleyin; yoksa VM açılır ama ağa çıkmaz.
• open-vm-tools paketini kaldırın. Hyper-V yardımcı servisleri için RHEL ailesinde ve Debian’da hyperv-daemons, Ubuntu’da linux-cloud-tools-virtual paketi kurulabilir.
• Eski dağıtımlarda Hyper-V desteği sınırlı olabilir; Microsoft’un Hyper-V’de desteklenen Linux ve FreeBSD sanal makineleri sayfasından kontrol edin.

Dalga planı ve kesim penceresi

Taşımayı tek seferde değil, dalgalar halinde yapın:

1. Pilot dalga: Kritik olmayan, farklı işletim sistemlerinden birer VM. Amaç süreci ve araçları doğrulamak.
2. Bağımsız iş yükleri: Bağımlılığı az olan altyapı sunucuları, test ortamları.
3. Uygulama grupları: Birbirine bağımlı sunucular aynı pencerede birlikte taşınır. Gecikmeye duyarlı uygulama ile veritabanı uzun süre farklı platformlarda kalmamalı.
4. Kritik sistemler: Ayrı pencere, ayrı geri dönüş planı.

Her VM için kesinti süresini bir pilot dönüşümle ölçün; süre büyük ölçüde disk boyutuna ve depolama/ağ hızına bağlıdır. Tahminle pencere açmayın. Geri dönüş planı basit olmalı: kaynak VM silinmez, yalnız kapatılır ve ağ kartı bağlantısı kesilir; sorun çıkarsa Hyper-V VM kapatılır, kaynak yeniden açılır. Kaynak VM’ler belirlenen gözlem süresinden sonra silinir.

Taşıma sonrası doğrulama kontrol listesi

• VM açılıyor, olay günlüğünde (System) sürücü veya disk hatası yok
• Integration services durumu doğru: Get-VMIntegrationService -VMName app01
• IP, DNS, ağ geçidi ve VLAN doğru; DNS kaydı güncel
• Uygulama servisleri çalışıyor, iş sahibi işlevsel test yaptı
• Windows etkinleştirmesi ve uygulama lisansları geçerli
• VM yedekleme işine eklendi ve ilk yedek başarıyla tamamlandı
• VM izleme sistemine eklendi, eski VMware kaydı izlemeden çıkarıldı
• Kümedeyse yüksek erişilebilirlik rolü eklendi ve bir canlı geçiş testi yapıldı

İlk yedeği ve bir test geri yüklemeyi taşımadan hemen sonra yapın. Yedek işinin “başarılı” görünmesi yetmez. Doğrulanmış yedek yaklaşımı için 3-2-1-1-0 kuralı ve geri yükleme testi yazısına bakın. Canlı geçiş testinde hata alırsanız Hyper-V live migration hataları rehberi belirtiye göre teşhis adımlarını veriyor. Hedef platform henüz netleşmediyse önce VMware sonrası platform seçimi yazısını okuyun. Planlama ve taşıma sürecinde sanallaştırma ve veri yönetimi hizmetimiz kapsamında birlikte çalışabiliriz.

Sık sorulan sorular

VMware Tools’u taşımadan önce mi sonra mı kaldırmalıyım?

Mümkünse önce, kaynak VMware ortamında kaldırın. Hyper-V üzerinde kaldırma denemesi, yükleyici VMware ortamını bulamadığı için başarısız olabilir ve elle temizlik gerektirir.

Generation 1 VM’i sonradan Generation 2’ye çevirebilir miyim?

Hayır, Hyper-V’de generation değeri VM oluşturulduktan sonra değişmez. Generation 2 istiyorsanız diski GPT’ye dönüştürün, yeni bir Generation 2 VM oluşturun ve diski ona bağlayın.

Linux VM Hyper-V’de açılırken kök dosya sistemini bulamıyor, neden?

En sık sebep, initramfs içinde Hyper-V depolama sürücüsünün (hv_storvsc) olmamasıdır. Taşımadan önce kaynakta initramfs’i bu sürücüyle yeniden oluşturmak ve fstab’da UUID kullanmak sorunu önler.

Domain controller’ı dönüştürerek taşımak güvenli mi?

Önerilmez. Kopya ile kaynağın aynı anda açılması USN geri alma sorununa yol açabilir. Yeni bir domain controller kurup replikasyonun tamamlanmasını bekleyin, ardından eski DC’yi düzgün biçimde kaldırın.