Migracja z VMware na Hyper-V

Po co przenosić się na hipernadzorcę, za który już zapłaciliście

Na serwerach stoi Windows Server, kupiony razem ze sprzętem, a obok niego utrzymywana jest druga platforma wirtualizacji z własną subskrypcją i własną datą odnowienia. Ta druga platforma robi to samo, co rola wliczona w system, który firma i tak opłaciła, a maszyny gościnne w większości i tak pracują na Windowsie, więc licencje serwerowe kupowane są po raz drugi.

Powód, dla którego ten temat wrócił, jest handlowy: oferta odnowienia po zmianie modelu licencjonowania VMware bywa dla małego środowiska wyższa niż wartość serwerów, na których to wszystko chodzi. Drugi powód jest rzadszy i sensowny. Osoba prowadząca Waszą domenę zna konsolę, konta i język poleceń Microsoftu, więc platforma po tej samej stronie skraca czas reakcji dokładnie wtedy, gdy coś nie działa.

Kiedy nie warto tego robić

Nie zaczynamy od migracji, tylko od policzenia, czy ma sens. Trzy sytuacje, po których kończymy rozmowę na wycenie odnowienia albo na innej platformie.

Producent Waszej aplikacji wspiera wyłącznie VMware. Program zwykle uruchomi się i tam, i tam, ale ryzykiem nie jest start, tylko zdanie, które usłyszycie przy zgłoszeniu awarii w środku sezonu.

Park gościnny stoi w większości na Linuksie. Za takie systemy nie płacicie Microsoftowi nic, więc licencja hosta przestaje być czymś, co i tak macie, a wtedy sensowniej postawić platformę zbudowaną wokół Linuksa. Tę drogę opisaliśmy przy migracji na Proxmox, a samo porównanie platform przy Proxmoksie i VMware.

Maszyny mają być pulpitami z systemem biurkowym. To zupełnie inna licencja niż serwerowa i licencja Windows Server jej nie obejmuje, więc firma płaci potem za prawo do tego, co już działa.

Co dokładnie zmienia się w środowisku

Migracja dotyczy sześciu warstw i tylko pierwsza z nich to pliki maszyn. Reszta to rzeczy, które patrzą na środowisko z zewnątrz, i to na nich zwykle stoi większość pracy.

Warstwa	Co było na vSphere	Co jest po przenosinach
Dyski maszyn	pliki VMDK na magazynie VMFS	pliki VHDX na wolumenie hosta albo klastra
Narzędzia w gościu	VMware Tools	usługi integracyjne Windows, sterowniki w dystrybucjach Linuksa
Przenoszenie maszyn	vMotion	migracja na żywo między hostami klastra
Konsola	vCenter Server	Failover Cluster Manager i Windows Admin Center
Kopie	zadania czytające hosty ESXi	te same zadania przepięte na hosty Hyper-V
Automatyzacja	skrypty PowerCLI	polecenia PowerShell modułu wirtualizacji

Wiersz ostatni bywa niedoszacowany. Skrypty, które co noc robiły porządek w migawkach albo raportowały zajętość, trzeba napisać jeszcze raz, a nie przekleić, i lepiej zaplanować to przed przełączeniem niż tydzień po nim.

Jak dzielimy pracę na okna serwisowe

Zaczynamy od spisu maszyn razem z systemem, który w nich stoi, i od policzenia rdzeni fizycznych hostów. Z tych dwóch liczb wychodzi edycja licencji, a nie z liczby maszyn, które planujecie uruchomić na starcie. Decyzja zapada przed zakupem czegokolwiek, bo zamiana edycji po fakcie oznacza kupowanie tego samego drugi raz.

Potem idą hosty: rola wirtualizacji, oddzielona sieć zarządzania, przełącznik wirtualny i dyski maszyn wyprowadzone poza wolumen systemowy. Ostatni punkt wygląda na drobiazg do dnia, w którym host przestaje wstawać, bo jedna maszyna zjadła miejsce na dysku systemowym.

Pierwsza przechodzi maszyna nieprodukcyjna. Mierzymy na niej czas kopiowania i sprawdzamy zachowanie systemu po zmianie sprzętu wirtualnego, żeby harmonogram dla reszty opierał się na pomiarze. Dalej przenosimy od najmniej krytycznych do najważniejszych, a kontroler domeny zostawiamy na koniec i nigdy nie jako jedyny egzemplarz na jedynym hoście.

Trzy rzeczy sprawdzamy zawsze przed przełączeniem: aktywację systemu po zmianie sprzętu, pamięć dynamiczną wyłączoną tam, gdzie system gościa jej nie znosi, oraz wykluczenia dla plików dysków w ochronie antywirusowej hosta. Skanowanie pliku, do którego maszyna zapisuje w tej samej chwili, kończy się spadkiem wydajności, a bywa, że uszkodzeniem tego pliku.

Co zostaje po ostatniej przeniesionej maszynie

Działające środowisko, dokumentacja hostów, klastra i sieci, protokół z odtworzenia jednej maszyny z datą oraz jednostronicowa instrukcja startu po zaniku zasilania z kolejnością maszyn. Do tego konta imienne na hostach zamiast wspólnego hasła i konsola zarządzania wyprowadzona poza sieć, w której stoją komputery księgowości.

Hosty ESXi zostają nietknięte do dnia odbioru. Dostępy są Wasze, więc dalsze utrzymanie maszyn możecie zlecić nam albo poprowadzić samodzielnie, a wybór platformy dla nowego środowiska opisaliśmy przy wirtualizacji serwerów.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026