Hyper-V Live Migration Hataları: Nedenleri ve Çözümleri

Canlı geçiş (live migration) çalışırken kimse fark etmez. Bozulduğunda ise genellikle bakım penceresinin ortasında, host’u boşaltmanız gereken anda karşınıza çıkar. Aşağıda canlı geçişin başarısız olduğu ya da dakikalarca sürdüğü durumları belirtiye göre ayırıyoruz; her biri için konsolda ilk bakılacak yeri, olası nedenleri ve kalıcı çözümü veriyoruz. Hedef, çalışan bir Hyper-V ortamını işleten sistem yöneticileri.

Canlı geçiş hangi aşamalardan geçer

Hatanın hangi aşamada oluştuğunu bilmeden yapılan teşhis tahmindir. Süreç dört adımdır:

1. Kurulum: Kaynak host hedefe bağlanır, kimlik doğrulama yapılır, hedefte VM’in yapılandırması ve boş bir “iskelet” VM oluşturulur. Hedefte bellek ayrılır.
2. Bellek kopyalama: VM çalışmaya devam ederken bellek sayfaları hedefe kopyalanır. Bu sırada değişen (kirlenen) sayfalar izlenir ve tekrar gönderilir; yineleme, kalan değişiklik kümesi küçülene kadar sürer.
3. Durum aktarımı: VM kaynakta çok kısa süre duraklatılır, son kirli sayfalar ve işlemci/cihaz durumu aktarılır.
4. Devir: Depolama erişimi hedefe geçer, VM hedefte devam eder, ağ tarafında MAC adresinin yeni konumu için switch’lere bildirim gönderilir.

Failover Cluster’da VM dosyaları paylaşımlı depolamada (CSV veya SMB) durduğu için yalnızca bellek ve durum taşınır. Küme dışı “shared nothing” geçişte sanal diskler de ağ üzerinden kopyalanır; süre disk boyutuyla orantılı uzar. Hata ayıklamaya başlamadan sistem altyapısında hangi senaryoda olduğunuzu netleştirin. İki yolun kimlik doğrulama ve ağ gereksinimleri farklıdır.

Belirtiye göre ilk teşhis

İlk iş, hatanın hangi aşamada oluştuğunu bulmaktır. Olay günlükleri ve Compare-VM ön kontrolü birlikte kullanılır; hangi kanala neden bakılacağı aşağıda.

# Son 2 saatte Hyper-V kanallarındaki hata ve uyarılar
$start = (Get-Date).AddHours(-2)
Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-Hyper-V-VMMS-Admin',
            'Microsoft-Windows-Hyper-V-High-Availability-Admin',
            'Microsoft-Windows-Hyper-V-Worker-Admin'
  Level = 2,3; StartTime = $start } |
  Select-Object TimeCreated, LogName, Id, Message | Format-List

# Küme günlüğü (son 30 dakika, yerel saat)
Get-ClusterLog -Destination C:\Temp -TimeSpan 30 -UseLocalTime

Compare-VM, geçişi gerçekten başlatmadan hedef host’ta VM’i neyin engelleyeceğini raporlar. Küme dışı geçişlerde ilk çalıştırılacak komut budur:

$r = Compare-VM -Name APP01 -DestinationHost HV02
$r.Incompatibilities | Format-Table MessageId, Message -AutoSize

Çıktıda işlemci uyumsuzluğu, eksik sanal switch, yapılandırma sürümü veya erişilemeyen dosya yolu gibi nedenler açıkça listelenir. Kümede “Validate Cluster” raporundaki Hyper-V yapılandırma testleri benzer bir ön kontrol sağlar. Rapor okunmadan yeniden deneme yapılmaz.

İşlemci uyumluluğu

Çalışan bir VM, başlatıldığı host’taki işlemcinin komut seti özelliklerini görür ve kullanır. Hedef host’un işlemcisi daha eski nesilse VM’in kullandığı bir özellik hedefte bulunmayabilir; geçiş “VM, hedef bilgisayarda desteklenmeyen işlemciye özgü özellikler kullanıyor” anlamındaki hatayla reddedilir. Sahada bu tablo neredeyse her zaman kümeye yeni nesil bir sunucu eklendikten sonra çıkar.

Çözüm, VM için işlemci uyumluluk modunu açmaktır. Mod, VM’e görünen özellikleri ortak bir alt kümeye indirir ve VM kapalıyken ayarlanır:

Stop-VM -Name APP01
Set-VMProcessor -VMName APP01 -CompatibilityForMigrationEnabled $true
Start-VM -Name APP01

Dikkat edilecek noktalar:

• Uyumluluk modu yalnızca aynı üreticinin işlemcileri arasında çalışır; Intel ve AMD host’lar arasında canlı geçiş mümkün değildir. Bu durumda VM kapatılarak taşınır.
• Yeni komut seti uzantılarını yoğun kullanan iş yüklerinde (ör. vektör işlemleri) uyumluluk modu performansı etkileyebilir. Ayarı tüm VM’lere toplu basmak yerine farklı nesil host’lar arasında gezmesi gereken VM’lerde kullanın.
• Windows Server 2025 ve Azure Local’de, kümedeki düğümlerin ortak özellik kümesini dinamik olarak hesaplayan yeni bir işlemci uyumluluğu modu bulunur. Ortamınızın sürümündeki parametreleri Microsoft dokümantasyonundan doğrulayarak kullanın.

Aynı aileden bir engel de VM yapılandırma sürümüdür. Daha yeni bir Windows Server host’ta yükseltilmiş yapılandırma sürümüne sahip VM, bu sürümü desteklemeyen eski host’a geçemez. Desteklenen sürümleri Get-VMHostSupportedVersion ile görürsünüz. Karma sürümlü kümelerde (rolling upgrade) tüm düğümler yükseltilene kadar Update-VMVersion çalıştırmayın. Geri dönüşü yoktur.

Kimlik doğrulama: Kerberos ve CredSSP

Küme dışı canlı geçişlerde (shared nothing dahil) kaynak host’un hedefe kimlik doğrulaması gerekir. Hyper-V iki yöntem sunar:

CredSSP ile geçiş yalnızca kaynak host’a doğrudan (konsol veya RDP ile) oturum açıldığında çalışır. Yönetim istasyonundaki Hyper-V Yöneticisi’nden veya Windows Admin Center’dan başlatılan geçiş “double hop” sorunu yüzünden başarısız olur. Credential Guard etkin host’larda da CredSSP ile kimlik bilgisi aktarımı engellenir. Uzaktan yönetilen ortamlar için kalıcı çözüm Kerberos’tur:

1. Active Directory’de her Hyper-V host’un bilgisayar nesnesinde, “Delegation” sekmesinde “bu bilgisayara yalnızca belirtilen hizmetlere yetki devri için güven” ve “Yalnızca Kerberos kullan” seçilir.
2. Diğer her host için cifs ve Microsoft Virtual System Migration Service hizmetleri eklenir.
3. Her host’ta kimlik doğrulama türü Kerberos olarak ayarlanır.

Enable-VMMigration
Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos
Get-VMHost | Select-Object VirtualMachineMigrationEnabled,
  VirtualMachineMigrationAuthenticationType, VirtualMachineMigrationPerformanceOption

Yetkilendirme değişikliğinin devreye girmesi için Kerberos biletlerinin yenilenmesi gerekir. Değişiklikten sonraki ilk denemede hata alırsanız host’ları sırayla yeniden başlatmak veya klist purge -li 0x3e7 ile bilgisayar hesabının bilet önbelleğini temizlemek çözer. Failover Cluster üzerinden başlatılan geçişlerde bu yetkilendirme gerekmez; küme kendi iletişimini kullanır.

Ağ ve sanal switch uyumsuzlukları

Sahada en sık gördüğümüz yapılandırma hatası, VM ağ adaptörünün bağlı olduğu sanal switch adının hedef host’ta bulunmamasıdır. Hyper-V eşleştirmeyi switch adına göre yapar; “SETswitch” ile “SET-Switch” farklı switch’lerdir. Tek bir tire geçişi durdurur. Kümede tüm düğümlerde switch adları birebir aynı olmalıdır. Küme dışı geçişte Compare-VM raporu üzerinden adaptörü hedef switch’e bağlayarak geçişi tamamlayabilirsiniz:

$r = Compare-VM -Name APP01 -DestinationHost HV02
$r.Incompatibilities[0].Source | Connect-VMNetworkAdapter -SwitchName "SETswitch"
Compare-VM -CompatibilityReport $r   # tekrar kontrol
Move-VM -CompatibilityReport $r

Diğer ağ kaynaklı nedenler:

• Geçiş ağı seçimi: Küme dışı host’ta Add-VMMigrationNetwork ile tanımlı alt ağa hedeften ulaşılamıyorsa geçiş zaman aşımına uğrar. Kümede Failover Cluster Manager’daki “Live Migration Settings” ile seçilen ağlar kullanılır; yönetim ağının en üst sırada durması yavaş geçişlerin klasik nedenidir.
• Güvenlik duvarı: Canlı geçiş için TCP 6600, SMB performans seçeneğinde TCP 445 iki yönde açık olmalıdır.
• MTU tutarsızlığı: Host’ta jumbo frame açık, aradaki switch’te kapalıysa küçük paketlerle yapılan kurulum başarılı olur, büyük bellek aktarımı sırasında geçiş takılır veya düşer. ping -f -l 8972 ile uçtan uca doğrulayın.
• Depolama yolu: Kümede VM’e host’un yerel diskinden bağlanmış bir ISO, yerel diske yazılan checkpoint veya Smart Paging dosyası geçişi engeller. VM ayarlarındaki tüm dosya yollarının CSV veya paylaşımlı SMB üzerinde olduğunu kontrol edin. Unutulmuş ISO en sık rastlanandır.
• Hedefte yetersiz bellek: Hedef host VM’in Startup belleğini ayıramıyorsa geçiş kurulum aşamasında reddedilir.

Host ağını baştan doğru kurmak için Hyper-V SET sanal ağ tasarımı yazısına bakabilirsiniz.

Geçiş bitiyor ama çok yavaş

Geçiş başarıyla tamamlanıyor ama çok uzun sürüyorsa, sorun genellikle bant genişliği ile VM’in bellek değiştirme hızı arasındaki dengededir. Sürekli yoğun yazan bir VM, hat yetersizse kopyalama yinelemelerini bitiremez. Bant genişliği yetmez. Yineleme sonsuza uzar.

Set-VMHost -VirtualMachineMigrationPerformanceOption SMB
Set-VMHost -MaximumVirtualMachineMigrations 2 -MaximumStorageMigrations 2
Set-VMHost -UseAnyNetworkForMigration $false
Add-VMMigrationNetwork 10.0.30.0/24

Eşzamanlı geçiş sayısını artırmak toplam boşaltma süresini her zaman kısaltmaz; bant genişliği paylaşıldığı için tekil geçişler uzar ve yoğun VM’ler tamamlanamayabilir. Değişiklikten önce bir host’u boşaltma süresini ölçün, değişiklikten sonra aynı ölçümü tekrarlayın. Ölçmeden yapılan ayar, ayar değildir.

Hata–neden–çözüm tablosu

Bu kontrolleri periyodik bakıma bağlamanın pratik yolu, bakım penceresinden önce her host’tan bir test VM’ini tüm düğümlere geçirmektir; sorun bakım gecesi değil, önceki gün ortaya çıkar. Düzenli bakım ve sorun giderme desteği için teknik destek ve periyodik bakım, mimari gözden geçirme için sanallaştırma ve veri yönetimi sayfalarımıza bakabilirsiniz. Küme tasarımındaki önkoşullar Hyper-V failover cluster planlama yazısında; Microsoft’un küme dışı geçiş için host hazırlama adımları Microsoft Learn dokümanında yer alır.

Sık sorulan sorular

Intel ve AMD işlemcili host’lar arasında canlı geçiş yapılabilir mi?

Hayır. İşlemci uyumluluk modu yalnızca aynı üreticinin farklı nesil işlemcileri arasında çalışır. Intel ve AMD host’lar arasında VM’in kapatılıp taşınması (soğuk geçiş) gerekir.

Kerberos kısıtlı yetkilendirmesi kümede de gerekli mi?

Failover Cluster Manager veya küme cmdlet’leriyle başlatılan geçişlerde gerekmez; küme kendi iletişimini kullanır. Küme dışı host’lar arasındaki (shared nothing dahil) geçişlerde kimlik doğrulama türü Kerberos seçildiyse gereklidir. Geçişi kaynak host’a oturum açmadan, uzaktan başlatmanın yolu da budur.

Canlı geçiş için hangi portlar açık olmalı?

Canlı geçiş varsayılan olarak TCP 6600 kullanır. SMB performans seçeneği seçildiyse TCP 445 de gerekir; VM dosyaları bir SMB paylaşımında duruyorsa da 445 erişimi şarttır. Kuralları Windows Güvenlik Duvarı’ndaki hazır Hyper-V kurallarıyla açmak, elle port kuralı yazmaktan daha az hata üretir.

Compression ile SMB seçeneklerinden hangisi daha hızlı?

10 GbE altındaki hatlarda, host’ta boş işlemci kapasitesi varsa Compression genellikle daha iyi sonuç verir. 10 GbE ve üzeri, özellikle RDMA destekli ağlarda SMB seçeneği SMB Multichannel ve SMB Direct sayesinde daha hızlıdır ve CPU yükünü azaltır. Karar vermeden önce kendi ortamınızda bir host boşaltma süresini ölçün.