Rynek wirtualizacji zmienił się w ciągu ostatnich dwóch lat na tyle, że wiele firm zaczęło na poważnie szukać alternatyw dla VMware. Jeśli czytałeś nasz poprzedni wpis o XCP-ng vs Proxmox, wiesz już, dlaczego stawiamy na XCP-ng. Jeśli nie czytałeś, w skrócie: XCP-ng to hiperwizor klasy enterprise oparty na otwartym kodzie, ten sam Xen, który napędza infrastrukturę Amazona. Bezpieczny, stabilny, bez płatnej bariery dostępu.
Ale samo przekonanie to za mało. Pytanie brzmi: jak to zrobić? Czy trzeba być guru linuksowym z dyplomem z architektury systemów? Czy da się przez to przejść bez tygodniowego przestoju i nocnych telefonów?
Odpowiedź: tak, da się. I poniżej pokazujemy jak.
Spis treści
Zanim zaczniesz: kilka słów o tym, co się zmienia
Przechodzisz z jednego ekosystemu do drugiego. Filozofia jest podobna, terminologia jest trochę inna. Dlatego zanim wejdziemy w szczegóły, szybkie tłumaczenie pojęć:
| Co znasz z VMware | Odpowiednik w XCP-ng |
| ESXi (hiperwizor) | XCP-ng (hiperwizor) |
| vCenter (zarządzanie) | Xen Orchestra (XO) |
| Datastore (magazyn danych) | Storage Repository (SR) |
| VMDK (format dysku VM) | VHD (format dysku VM) |
| VMware Tools | XCP-ng Guest Tools |
| vSphere API | Xen Orchestra REST API |
Xen Orchestra to webowy panel zarządzania dla XCP-ng, odpowiednik vCenter w świecie VMware. Działa w przeglądarce, bez specjalnych wtyczek. W przeciwieństwie do XCP-ng, który jest w pełni otwarty, Xen Orchestra dostępna jest w wersji komercyjnej, choć dla chętnych istnieje też możliwość uruchomienia jej samodzielnie ze źródeł. Jeśli znasz vCenter, Xen Orchestra nie będzie Ci obca.
Faza 0: Przygotowanie środowiska VMware
Zanim cokolwiek ruszysz, poświęć chwilę na porządki po stronie VMware. To nie jest zbędna biurokracja. To właśnie tutaj eliminujesz 90% potencjalnych problemów.
Krok 1: Usuń zalegające snapshoty
Przejrzyj swoje maszyny wirtualne w vCenter i usuń zalegające snapshoty. Migracja działa najlepiej na czystym dysku bazowym, bez zbędnych warstw. Obecność snapshotów może znacząco skomplikować proces, dlatego warto się ich pozbyć zanim zaczniesz.
Krok 2: Odinstaluj VMware Tools
To sterowniki, które pozwalają VMware komunikować się z systemem operacyjnym maszyny. Po przejściu na XCP-ng będą niepotrzebne, a podczas migracji mogą powodować konflikty w Windows (niepotrzebne wpisy w rejestrze dotyczące kontrolerów dysków i sieci). Jeśli zapomnisz, da się je odinstalować później, ale lepiej to zrobić przed.
Krok 3: Linux z dracutem: przebuduj initramfs przed migracją
Dotyczy systemów używających dracuta: RHEL, CentOS, Fedora, Rocky Linux, AlmaLinux i pochodnych.
W najnowszych wersjach Linuxa obraz rozruchowy (initramfs) jest budowany przy instalacji ze sterownikami dostosowanymi do danego środowiska, więc po migracji może nie zawierać sterowników do innych typów dysków. Dlatego przed migracją zalecamy wygenerowanie nowego initramfs ze wszystkimi sterownikami:
dracut --regenerate-all --force --no-hostonly
Powyższa komenda generuje nowy obraz i jest w pełni bezpieczna dla uruchomionego systemu. Ważna uwaga: komenda nie wyświetla żadnych komunikatów podczas działania ani po zakończeniu. Jeśli nie widzisz żadnych błędów, wszystko wykonało się poprawnie.
Zrobienie tego po fakcie wymaga uruchamiania maszyny w trybie ratunkowym z zewnętrznego ISO (da się, ale po co).
Krok 3.5: Zabezpiecz dostęp lokalny
Zanim zaczniesz migrację, upewnij się, że masz działające konto lokalne na każdej migrowanej maszynie: konto root na Linuxie lub konto lokalnego administratora na Windowsie. Po migracji sieć może przez chwilę nie działać tak jak powinna, a dostęp lokalny pozwoli Ci zalogować się do maszyny i spokojnie rozwiązać problem bez presji czasu. Nie zawsze będzie Ci to potrzebne, ale jeśli kiedyś będzie, zaoszczędzi sporo nerwów
Krok 4: Sprawdź konfigurację sieci
Krok 4: Sprawdź konfigurację sieci
To najczęstsze źródło niespodzianek po migracji. Przed startem zweryfikuj:
- VLAN-y: czy sieć w XCP-ng ma te same identyfikatory co w VMware? Każda sieć VLAN w XCP-ng powinna być przypisana do właściwego interfejsu fizycznego i mieć ten sam tag, którego używała maszyna źródłowa.
- MTU: jeśli używasz Jumbo Frames (MTU 9000), docelowa sieć w XCP-ng musi mieć zgodne ustawienie. Niezgodność MTU nie zawsze daje oczywiste objawy. Czasem kończy się po prostu dziwnymi problemami z łącznością, spadkami wydajności albo niestabilnym działaniem usług.
- Adresy MAC i nazwy interfejsów: po migracji adres MAC zwykle zostaje zachowany, co jest wygodne i pozwala uniknąć części dodatkowej pracy. Mimo to warto to zweryfikować przed pierwszym uruchomieniem maszyny, szczególnie jeśli korzystasz z DHCP z rezerwacją albo masz reguły sieciowe powiązane z konkretnym adresem MAC.
Nawet jeśli adres MAC pozostanie taki sam, system operacyjny i tak zauważy zmianę wirtualnej karty sieciowej oraz jej sterownika. Skutki są różne w zależności od systemu:
Windows: system wykryje nową kartę sieciową i zainstaluje ją jako nowe urządzenie. Stara karta z VMware może zostać w systemie jako ukryte „urządzenie widmo” w rejestrze. Jeśli masz statyczny adres IP wpisany ręcznie, Windows może zaprotestować przy próbie przypisania go do nowej karty. Rozwiązanie: usuń ukryte urządzenia z Menedżera Urządzeń przed ponownym przypisaniem adresu IP.
Linux: zmiana nazwy interfejsu sieciowego jest możliwa, ale nie jest nieunikniona. Zależy to od wersji systemu, używanego schematu nazewnictwa i od tego, jak system rozpozna nową wirtualną kartę po zmianie hiperwizora. W praktyce najlepiej założyć, że nazwa interfejsu może być inna niż wcześniej i sprawdzić to zaraz po pierwszym uruchomieniu maszyny.
Jeśli masz statyczny adres IP, sprawdź pliki konfiguracyjne sieci po starcie systemu. W zależności od dystrybucji może to oznaczać aktualizację ustawień w Netplanie, NetworkManagerze albo w klasycznych plikach konfiguracyjnych, tak aby wskazywały właściwy interfejs. Nie zawsze będzie to konieczne, ale warto to zweryfikować od razu.
Jeśli korzystasz z DHCP z rezerwacją, zachowanie oryginalnego adresu MAC zwykle sprawia, że serwer DHCP rozpozna maszynę jako to samo urządzenie i przydzieli jej ten sam adres IP. To najprostsza ścieżka.
Krok 5: Sprawdź dostępne miejsce na dyskach
W VMware większość dysków pracuje w trybie thin provisioning: dysk zajmuje tyle miejsca, ile faktycznie zapisanych danych, a nie tyle ile zadeklarowano. XCP-ng zachowuje ten tryb, ale tylko jeśli docelowy dysk jest odpowiedniego typu. Jeśli wybierzesz LVM, każdy dysk zostanie od razu zalokowany w pełnym, zadeklarowanym rozmiarze. Przed migracją upewnij się, że masz na to wystarczająco miejsca.
Faza 1: Połączenie i uruchomienie transferu
Krok 1: Połącz Xen Orchestra z vCenter
Zaloguj się do Xen Orchestra. Z menu głównego wybierz Import → From VMware. Wprowadź dane do vCenter (lub bezpośrednio do hosta ESXi) i kliknij Connect.
XO potrzebuje dostępu przez port 443 (HTTPS) i port 902 (NBD, czyli Network Block Device). Ten drugi jest kluczowy: to właśnie przez NBD dane dyskowe przesyłane są bezpośrednio z ESXi z maksymalną prędkością sieci.
Jeśli połączenie działa, widzisz listę swoich maszyn wirtualnych.
Krok 2: Uruchom Planned Warm Migration
Tu dzieje się właśnie to, co wyróżnia XCP-ng. Większość narzędzi do migracji wymaga zatrzymania maszyny. XCP-ng oferuje Planned Warm Migration: Twoja produkcja działa przez cały czas trwania transferu, a Ty sam decydujesz, kiedy nastąpi finalne przełączenie.
W Xen Orchestra wybierz maszynę do migracji (możesz wskazać kilka naraz), docelową pulę (Pool), magazyn danych (SR), sieć oraz typ systemu, który migrujesz, żeby XCP-ng wiedziało w jaki sposób uruchomić maszynę.
Pozostaw parametr „Stop the source VM” odznaczony. Kliknij Import.
XO robi snapshot maszyny po stronie VMware i zaczyna przesyłać dane. Oryginalna maszyna pracuje normalnie: klienci nic nie widzą, usługi się nie zatrzymują. Dla dużych maszyn ten etap może trwać kilka godzin. Spokojnie go zostaw, możesz zamknąć przeglądarkę i wrócić później.
Kiedy transfer się skończy, na liście VM w panelu XO zobaczysz wyłączoną maszynę o tej samej nazwie co oryginał. Produkcja w VMware nadal działa. Teraz masz dwie opcje.
Faza 2: Co po transferze?
Opcja 1: Najpierw test, potem produkcja
Migracja między dwoma różnymi hiperwizorami to coś więcej niż przeniesienie maszyny z punktu A do punktu B. Zmienia się cały wirtualny sprzęt pod spodem. Test przed finalnym przełączeniem daje pewność, że nie będzie niespodziankek w oknie serwisowym.
Po zakończeniu transferu w panelu XO pojawi się gotowa, ale wyłączona maszyna wirtualna. Sklonuj ją i uruchom klon jako kopię testową.
Ważne: przed uruchomieniem upewnij się, że karta sieciowa klonu jest podpięta do odizolowanej sieci testowej, a nie do produkcyjnej. Inaczej w sieci pojawią się dwie maszyny z tym samym adresem IP.
Pamiętaj też, że kopia uruchamia się w stanie, jakby nastąpił twardy restart zasilania. System może przy starcie sprawdzać spójność dysków, to normalne.
Sprawdź czy system uruchamia się bez błędów, czy kluczowe usługi startują poprawnie i czy XCP-ng Guest Tools instaluje się prawidłowo.
Po udanych testach usuń klon. Oryginalna maszyna pozostaje nienaruszona i gotowa do przełączenia. Jeśli coś pójdzie nie tak na klonie, nie tracisz przesłanych danych i nie zaczynasz transferu od nowa.
Opcja 2: Od razu finalne przełączenie produkcyjne
Jeśli Faza 0 była zrobiona porządnie i masz zaufanie do procesu, możesz pominąć test i od razu przejść do przełączenia.
W Xen Orchestra powtórz te same kroki co w Fazie 1, Krok 2, z jedną zmianą: tym razem zaznacz parametr „Stop the source VM” i kliknij Import.
XO prześle wyłącznie dane zmienione od czasu pierwszego snapshota. To zwykle kilka do kilkunastu minut, w zależności od tego, ile zmieniło się na maszynie od początku transferu. Następnie uruchom maszynę na XCP-ng.
Maszyna źródłowa w VMware pozostaje nienaruszona do czasu, aż sam ją usuniesz. Masz pełną możliwość powrotu, jeśli coś pójdzie nie tak.
Więcej szczegółów technicznych znajdziesz w oficjalnej dokumentacji Xen Orchestra oraz na forum XCP-ng.
Faza 3: Weryfikacja po migracji
Krok 1: Zainstaluj XCP-ng Guest Tools
To pierwszy krok po uruchomieniu maszyny na XCP-ng. Bez tych sterowników maszyna działa, ale poniżej swoich możliwości. Guest Tools zastępują emulowane sterowniki parawirtualizowanymi i znacznie poprawiają wydajność operacji dyskowych i sieciowych.
Instalacja w Linuksie:
# Zainstaluj pakiet xe-guest-utilities z repozytorium XCP-ng
Zgodnie z dokumentacją, w przypadku maszyn z systemem Windows zalecane jest pobranie i instalacja najnowszych dostępnych sterowników i agenta z https://github.com/xcp-ng/win-pv-drivers/releases.
Krok 2: Sprawdź działanie systemu
Kiedy maszyna wystartuje, zanim przywrócisz pełny ruch produkcyjny zweryfikuj:
- czy system uruchomił się bez błędów,
- czy sieć działa i maszyna ma właściwy adres IP,
- czy kluczowe usługi odpowiadają.
Co zrobić, gdy coś nie działa?
BSOD w Windows (INACCESSIBLE_BOOT_DEVICE)
Niebieski ekran z tym kodem to klasyk przy migracjach Windowsa między hiperwizorami. Przyczyna jest prosta: po przeniesieniu na XCP-ng system próbuje wystartować z nowym wirtualnym kontrolerem dysku, do którego nie ma załadowanych sterowników. Efekt: Windows nie może zamontować dysku systemowego i wywala błąd.
Kilka sposobów żeby temu zapobiec:
- Odinstaluj VMware Tools przed migracją. To podstawowy krok, który eliminuje konflikty sterowników i usług.
- Włącz uniwersalne sterowniki dysków w rejestrze. Dotyczy starszych systemów, np. Windows Server 2008.
- Zmień kontroler na SATA przed migracją (opcjonalnie). W VMware dodaj nowy kontroler SATA, przepnij na niego dysk systemowy i uruchom system, żeby załadował sterowniki. Dopiero potem rozpocznij migrację.
- Sprawdź tryb bootowania (BIOS vs UEFI). Upewnij się, że w zakładce Advanced w Xen Orchestra tryb bootowania odpowiada dokładnie temu z VMware. Uruchomienie maszyny instalowanej w trybie Legacy BIOS na docelowym UEFI zawsze skończy się błędem.
- Wymuś tryb awaryjny. Wejdź w środowisko odzyskiwania systemu Windows (WinRE), przejdź do opcji zaawansowanych i wybierz uruchomienie w trybie awaryjnym. Windows ładuje wtedy tylko podstawowe sterowniki. Jeśli system wystartuje, zrestartuj go normalnie. Jest duża szansa, że tym razem załaduje się poprawnie i będziesz mógł zainstalować XCP-ng Guest Tools.
Linux nie uruchamia się: błąd braku dysku
Jeśli pominąłeś Krok 3 w Fazie 0, initramfs nie zawiera sterowników Xen. Uruchom maszynę z ISO w trybie ratunkowym, zaloguj się jako root i wykonaj:
dracut --regenerate-all --force --no-hostonly
Sieć po migracji nie odpowiada
Sprawdź MTU na całej ścieżce (fizyczny interfejs PIF → Network → karta sieciowa VM). Jeden niezgodny element wystarczy, żeby pakiety zaczęły się fragmentować, a objawy wyglądają jak problem z wydajnością, nie z konfiguracją sieci
Dasz radę sam?
Jeśli sprawnie poruszasz się po vCenter i nie boisz się interfejsu webowego, to tak. Xen Orchestra prowadzi przez cały proces, nie musisz pisać skryptów ani schodzić do wiersza poleceń.
Wyjątki istnieją: bardzo stare systemy operacyjne, niestandardowa topologia sieciowa, klastry wysokiej dostępności. Tu warto mieć kogoś doświadczonego obok. Nie dlatego, że to niemożliwe samodzielnie, ale dlatego, że przy środowisku produkcyjnym margines błędu jest inny. Drobny szczegół, jak nazwa interfejsu sieciowego albo niezgodność MTU, potrafi zablokować start maszyny.
Jeśli chcesz to zrobić, ale wolisz mieć pewność, wiemy co sprawdzić zanim zaczniesz i co zrobić, jeśli coś pójdzie nie tak. Napisz do nas.
