Migracja z VMware do chmury: plan, metody i pułapki

Blog WebDisk · kategoria: Chmura publiczna · czas czytania: ~10 minut

W skrócie:- Po przejęciu VMware przez Broadcom zmienił się model licencjonowania i program partnerski, więc przy odnowieniu wsparcia coraz więcej firm przelicza alternatywy. Najczęściej rozważaną jest KVM zarządzany przez Apache CloudStack – bo model pracy jest bliski temu, co administrator zna z vCenter.- Dwie drogi: przenieść maszyny i sieci do chmury publicznej WebDisk albo postawić CloudStack u siebie, z naszym wsparciem. Obie da się prowadzić etapami, równolegle do działającego vSphere.- Techniczne sedno to trzy metody (OVA/OVF, konwersja dysków do qcow2, synchronizacja na poziomie systemu), jedna klasyczna pułapka (sterowniki virtio) i jedna rzecz nie do pominięcia: plan wycofania. >Nie pracujesz z terminalem? Pomiń bloki poleceń – kolejność prac, pułapki i checklista są opisane słowami.

Rozmowa zwykle zaczyna się tak samo: dział IT dostaje ofertę odnowienia wsparcia dla vSphere, patrzy na warunki, patrzy na budżet i po raz pierwszy od lat zadaje sobie pytanie „a czy musimy?”. Po przejęciu VMware przez Broadcom (transakcja domknięta pod koniec 2023 roku) zmieniło się kilka rzeczy naraz: portfolio skonsolidowano w duże pakiety, licencje wieczyste ustąpiły miejsca subskrypcjom, a przebudowa programu partnerskiego w 2024 roku zmieniła listę firm, które mogą sprzedawać i odnawiać licencje. Skutek finansowy zależy od konkretnego kontraktu, nie od artykułu na blogu – dlatego zamiast procentów dostajesz tu plan działania na wypadek, gdyby Twoje własne wyliczenia wyszły niekorzystnie.

W tym artykule pokazujemy, co przenieść i w jakiej kolejności, trzema metodami przeniesienia maszyny, oraz gdzie migracje najczęściej się wykładają – z checklistą jednej maszyny i planem wycofania. Tekst jest dla zespołów IT stojących przed odnowieniem wsparcia vSphere: administratorów, którzy będą to robić, i osób, które muszą oszacować ryzyko i budżet.

Dwie ścieżki: nasza chmura albo CloudStack u Ciebie

Ścieżka pierwsza – chmura publiczna. Przenosisz maszyny i sieci do chmury publicznej WebDisk, przestajesz utrzymywać własny hypervisor (hypervisor – oprogramowanie uruchamiające maszyny wirtualne na fizycznym serwerze) i zarządzasz środowiskiem z panelu WebDisk Cloud. Klaster Kubernetes odtwarzasz w nowym środowisku – u nas jako usługę WebDisk K8s – przenosząc obciążenia i wolumeny, nie maszyny. Rozliczenie jest miesięczne, za wykupioną pulę zasobów, z publicznym cennikiem w złotówkach – więc porównanie kosztów robi się na Twoich liczbach: sumie vCPU, RAM, pojemności i transferu, zestawionej z pełnym kosztem własnej serwerowni, razem z energią, odtworzeniem sprzętu i czasem ludzi.

Ścieżka druga – CloudStack we własnej serwerowni. Zostajesz na swoim sprzęcie, ale zdejmujesz z niego zależność licencyjną: Apache CloudStack to wolne oprogramowanie (licencja Apache 2.0) rozwijane przez fundację Apache. Naszą rolą jest wtedy wsparcie, a jego zakres – projekt, wdrożenie, przeniesienie maszyn, szkolenie zespołu – ustalamy indywidualnie. Obie ścieżki da się połączyć – część środowiska u siebie, część u nas; sposób połączenia obu lokalizacji ustalamy w projekcie.

Warto nazwać rzecz po imieniu: jeśli nie wybierzesz świadomie warstwy otwartej, wymieniasz tylko jedno uzależnienie na drugie – o czym pisaliśmy w tekście o uzależnieniu od dostawcy.

Dlaczego CloudStack jest naturalną alternatywą dla vSphere?

Dla administratora vSphere CloudStack jest łagodnym lądowaniem – z konkretnych powodów, nie z sympatii:

Model operacyjny jest znajomy. Hierarchia stref, podów, klastrów i hostów odwzorowuje to, co w vCenter nazywa się datacenter → cluster → host, a praca toczy się w jednym panelu webowym. CloudStack jest monolityczny, więc wdraża się i utrzymuje prościej niż platformy złożone z kilkunastu komponentów.
Jeden orkiestrator, wiele hypervisorów. CloudStack zarządza KVM, ale też VMware vSphere czy XCP-ng. To otwiera wariant przejścia o najmniejszym ryzyku odwrotu: uruchamiasz CloudStack obok działającego vSphere, wpinasz istniejący klaster jako zasób i migrujesz maszyny stopniowo.
Tryb uproszczony dla on-premise. Strefę można uruchomić bez wirtualizacji sieci – instancje trafiają wprost do współdzielonej sieci na Twoich VLAN-ach, co firmom z poukładaną adresacją oszczędza całą warstwę złożoności. Klastry Kubernetes mają zaś własną usługę platformy: control plane zakłada CloudStack, a Ty wgrywasz do niego swoje obciążenia i dane. Jeśli wolisz oddać utrzymanie klastra, mamy wsparcie techniczne dla Kubernetesa.
Storage. Nasza platforma opiera się na Ceph – jako magazyn blokowy dla maszyn i jako magazyn obiektowy zgodny z S3. Pojemność dokłada się przez dodawanie węzłów, bez przestoju maszyn.

Lekturą uzupełniającą jest publiczny przewodnik „VMware to Apache CloudStack Migration Guide” firmy ShapeBlue, mocno zaangażowanej w rozwój CloudStacka.

Co przenieść najpierw, a co na końcu?

Najczęstszy błąd to zacząć od maszyny, na której ktoś zna się najlepiej – czyli od tej najważniejszej. Kolejność, która się broni, jest odwrotna:

Inwentaryzacja. Eksport listy maszyn z vCenter: vCPU, RAM, dyski i ich realne zapełnienie, adresy IP i MAC, wersja systemu, firmware (starszy BIOS czy nowszy UEFI – tryb, w którym maszyna się uruchamia), agenty, licencje wiązane ze sprzętem. Ten arkusz jest podstawą harmonogramu.
Mapa zależności. Co z czym rozmawia i po jakich portach. Maszyna przeniesiona bez swojej bazy danych to nie migracja, tylko awaria z opóźnionym zapłonem.
Fundament w nowym środowisku. Najpierw sieć (VPC, podsieci, reguły, NAT, połączenie z Twoją siecią), potem DNS, tożsamość i dostęp, backup i monitoring. Dopiero na tym stawia się maszyny.
Fala zerowa – jedna maszyna nieprodukcyjna. Cel jest proceduralny: zmierzyć, ile realnie trwa transfer i konwersja, i przećwiczyć wycofanie na czymś, czego nie szkoda.
Fala pierwsza – usługi bezstanowe. Serwery aplikacyjne, front-endy, maszyny pomocnicze. Przełączenie (ang. cutover) jest tanie, bo dane nie migrują z maszyną.
Fala druga – dane. Duże wolumeny warto „zasiać” wcześniej (kopia pełna z wyprzedzeniem, w oknie tylko różnica), a archiwa przenieść od razu do magazynu obiektowego, zamiast wozić je w wirtualnym dysku.
Fala ostatnia – systemy krytyczne, już na przećwiczonej procedurze.

Przed pierwszą falą zrób kopię zapasową poza oboma środowiskami – migracja to jedyny moment, gdy te same dane istnieją w dwóch miejscach i oba są w ruchu (o zasadach opowiada tekst o backupie w chmurze, a o magazynach klasy WORM – czyli takich, w których zapisanej kopii nie da się nadpisać ani skasować przed terminem – tekst o S3 Object Lock).

Jak przenieść maszynę wirtualną z VMware na KVM? Trzy metody

Metoda A – eksport OVA/OVF (OVA i OVF to standardowe formaty eksportu maszyny wirtualnej do pliku). Klasyka: maszyna jest wyłączana, eksportowana do jednego pliku i importowana po drugiej stronie. Przewidywalna, ale wymaga pełnego okna serwisowego i miejsca na dwie kopie dysku.

# eksport maszyny z vSphere do OVA (ovftool, z hosta mającego dostęp do vCenter)
ovftool --noSSLVerify \
vi://uzytkownik@vcenter.firma.local/Datacenter/vm/app-01 \
./app-01.ova

Metoda B – konwersja dysków. Format VMware (VMDK) zamieniasz na format natywny dla KVM (QCOW2 lub RAW) i rejestrujesz jako szablon albo wolumen.

# rozpakowanie OVA i konwersja dysku VMDK -> QCOW2
tar -xvf app-01.ova # -> app-01.ovf, app-01-disk1.vmdk
qemu-img convert -p -f vmdk -O qcow2 app-01-disk1.vmdk app-01.qcow2
qemu-img info app-01.qcow2 # kontrola: format i rozmiar wirtualny

Bezpieczniejszy wariant to virt-v2v: konwertuje obraz i przy okazji wstrzykuje do systemu gościa sterowniki potrzebne pod KVM – czyli załatwia największą pułapkę z następnej sekcji. Jest jeden warunek: przy maszynach z Windows sterowniki virtio-win muszą być zainstalowane na maszynie, na której konwertujesz. Bez nich konwersja się uda, a system i tak nie wstanie.

# konwersja + przygotowanie systemu gościa pod KVM w jednym kroku
virt-v2v -i ova app-01.ova -o local -os /var/tmp/wynik -of qcow2

Gotowy obraz wystawiasz pod adresem HTTP(S) i rejestrujesz w CloudStacku jako szablon (formularz „Register template” w panelu albo register template w cloudmonkey – format QCOW2, hypervisor KVM). Nowsze wydania potrafią też pobrać maszynę wprost z vCenter i przekonwertować ją na KVM bez ręcznego przenoszenia plików; dostępność zależy od wersji, więc sprawdź to na swoim wdrożeniu, zanim ułożysz harmonogram.

Metoda C – synchronizacja na poziomie systemu. Zamiast wozić dysk, stawiasz w nowym środowisku czystą maszynę, instalujesz oprogramowanie i przenosisz dane. Nie ciągniesz wtedy za sobą starych sterowników, pozostałości po VMware Tools ani historii uaktualnień.

# pierwszy przebieg — na żywo, źródło nadal pracuje
rsync -aHAX --numeric-ids --info=progress2 root@stara-vm:/srv/ /srv/

# przebieg domykający — w oknie serwisowym, po zatrzymaniu usług;
# przenosi już tylko różnicę, dlatego okno jest krótkie
rsync -aHAX --numeric-ids --delete root@stara-vm:/srv/ /srv/

W praktyce: A dla prostych, pojedynczych maszyn; B dla appliance’ów – gotowych maszyn od producenta oprogramowania, których nie postawisz z instalatora; C dla wszystkiego, co zbudujesz od nowa – i wszędzie tam, gdzie liczy się krótkie okno.

Pułapki, które zjadają okno serwisowe

Sterowniki virtio. Numer jeden na liście. Virtio to rodzina sterowników, którymi maszyna wirtualna rozmawia z dyskiem i siecią pod KVM. Windows bez wcześniej zainstalowanych sterowników virtio nie wstanie (klasyczny błąd zatrzymania „inaccessible boot device”); Linux z initramfs – małym systemem startowym w pamięci, ładowanym zanim wstanie właściwy dysk – zbudowanym bez modułów virtio zatrzyma się na braku dysku. Lekarstwo jest proste, o ile zastosujesz je przed wyłączeniem maszyny źródłowej: doinstaluj sterowniki i przebuduj initramfs, albo użyj virt-v2v – pod warunkiem, że na maszynie, na której konwertujesz, są zainstalowane sterowniki virtio-win; bez nich konwersja się uda, a Windows i tak nie wstanie.
Nazwy interfejsów sieciowych. Nowy typ karty to nowa nazwa interfejsu (ens192 potrafi zmienić się w ens3). Konfiguracja przypięta do starej nazwy albo do adresu MAC oznacza maszynę, która wstaje bez sieci. Przejrzyj netplan, pliki ifcfg i reguły udev przed przeniesieniem.
Adresy MAC, licencje i snapshoty. Część oprogramowania wiąże licencję z MAC-iem, UUID maszyny albo numerem seryjnym płyty – zrób listę takich systemów wcześnie, bo przelicencjonowanie załatwia się przed migracją, nie w oknie serwisowym. Maszyny z łańcuchem snapshotów migruj zaś dopiero po skonsolidowaniu: eksport z aktywnym łańcuchem to najkrótsza droga do obrazu, który się nie uruchamia.
VMware Tools, UEFI i fstab. VMware Tools odinstaluj przed migracją, po drugiej stronie zainstaluj qemu-guest-agent. Maszyna startująca w UEFI musi trafić na instancję w UEFI (niezgodność objawia się „czarnym ekranem bez powodu”), a fstab – plik z listą dysków montowanych przy starcie systemu – opisany nazwami urządzeń zamiast identyfikatorami UUID to pewna awaria startu, gdy zmieni się kontroler dyskowy.
Czas transferu i DNS. Czas kopiowania policz zawczasu – pojemność przez realną przepustowość łącza; kilkadziesiąt terabajtów to nie zadanie na weekend. A TTL rekordów DNS – czyli czas, przez jaki serwery i przeglądarki trzymają w pamięci starą odpowiedź – obniż na dobę przed przełączeniem, bo inaczej przełączenie trwa tyle, ile najdłuższa pamięć podręczna po drodze – i wycofanie dokładnie tyle samo.

Plan testów i wycofania

Migracja bez zdefiniowanego wycofania to nie migracja, tylko zakład. Minimum do wpisania w procedurę:

Kryteria akceptacji (zanim ruch pójdzie na nowe środowisko): system wstaje po dwóch restartach; konsola z panelu działa; adresacja, trasy i DNS zgodne z projektem; usługa przechodzi test end-to-end (nie „proces działa”, tylko „użytkownik wykonał operację”); wydajność dysku porównana ze stanem sprzed migracji; backup wykonał się i został odtworzony próbnie; monitoring – Twój albo uzgodniony z nami – widzi maszynę i alarmuje.

Wycofanie: maszyna źródłowa zostaje wyłączona, ale nietknięta przez uzgodniony czas (rozsądne minimum to dwa tygodnie stabilnej pracy). Zdefiniuj punkt bez powrotu – moment, w którym w nowym środowisku pojawiają się zapisy, których nie ma w starym: do tego momentu odwrót jest darmowy, po nim wymaga migracji danych z powrotem. Ustal też osobę ogłaszającą decyzję i twardą godzinę, o której zapada („jeśli o 4:00 nie mamy zielonego testu, wracamy”) – o trzeciej w nocy nikt nie chce być tym, kto pierwszy zaproponuje odwrót.

Po przełączeniu od razu upewnij się, że maszyna jest objęta Twoim monitoringiem – a jeśli chcesz, żeby zawieszony system restartował się sam, uzbrój w niej watchdoga (reakcją jest twardy reset, nie naprawa).

Checklista jednej maszyny

T-14: inwentaryzacja i zależności · przelicencjonowanie tam, gdzie licencja wisi na sprzęcie · sterowniki virtio dograne na źródle · próbny restore backupu
T-2: konsolidacja snapshotów · sieć odpięta od nazw interfejsów i MAC-ów · pierwszy przebieg kopiowania „na żywo” · weryfikacja obrazu po konwersji
T-1: obniżony TTL w DNS · rozesłane okno serwisowe · pisemne kryteria akceptacji i godzina decyzji o wycofaniu
T-0: zatrzymanie usług · przebieg domykający dane · start maszyny docelowej · test end-to-end · przełączenie ruchu
T+1: backup i monitoring potwierdzone · maszyna źródłowa wyłączona, ale zachowana · dokumentacja i adresacja zaktualizowane

Czego migracja z VMware nie załatwi?

Nie każda funkcja ma odpowiednik jeden do jednego. Automatyczne równoważenie obciążenia klastra czy rozproszona zapora z NSX-a mają w świecie KVM/CloudStack własne, ale inne rozwiązania. Zamiast szukać kalki, sprawdź, który z nich faktycznie u Ciebie pracuje.
Klastry Kubernetes buduje się od nowa. Migracji podlegają manifesty, obrazy i dane na wolumenach – nie węzły. Zaplanuj to jako osobny projekt, nie jako jedną z fal przenoszenia maszyn.
Hypervisor to nie cała platforma. Backup, monitoring i zarządzanie tożsamością trzeba odtworzyć świadomie – to zwykle większa część projektu niż samo przeniesienie dysków.
Migracja kosztuje jednorazowo: czas ludzi, okna serwisowe, ryzyko. Postaw ten koszt obok oszczędności na licencjach, zanim zrobi to za Ciebie biznes.
Zostając na własnym sprzęcie, zostajesz operatorem chmury. Wolne oprogramowanie zdejmuje opłatę licencyjną, nie obowiązki: aktualizacje, wymianę dysków, pojemność, dyżury.

Częste pytania

Czy muszę migrować wszystko naraz? Nie – i lepiej, żebyś nie migrował. CloudStack zarządza jednocześnie KVM i vSphere, więc oba środowiska mogą pracować równolegle przez cały okres przejściowy, a przełączanie odbywa się falami.

Czy da się przenieść maszyny z Windows? Tak, pod warunkiem wcześniejszego przygotowania sterowników virtio na źródle – albo użycia virt-v2v, który zrobi to podczas konwersji, o ile na maszynie konwertującej są zainstalowane sterowniki virtio-win (bez nich konwersja się uda, a Windows i tak nie wstanie). Licencje systemu i aplikacji sprawdź osobno – bywają wiązane ze sprzętem.

Czym różnią się trzy metody przeniesienia maszyny: OVA/OVF, konwersja dysku i synchronizacja danych? Eksport OVA/OVF przenosi całą maszynę jednym plikiem – jest przewidywalny, ale wymaga pełnego okna serwisowego i miejsca na dwie kopie dysku. Konwersja dysków (VMDK do QCOW2, najlepiej narzędziem virt-v2v, które przy okazji wstrzykuje sterowniki) sprawdza się przy appliance’ach, których nie postawisz z instalatora. Synchronizacja na poziomie systemu – czysta maszyna w nowym środowisku plus przeniesienie samych danych – daje najkrótsze okno i nie ciągnie za sobą pozostałości po VMware.

Dlaczego Windows albo Linux nie startuje po migracji z VMware na KVM? Najczęstszy powód to brak sterowników virtio: Windows kończy błędem zatrzymania „inaccessible boot device”, a Linux z initramfs zbudowanym bez modułów virtio zatrzymuje się na braku dysku. Dwaj pozostali podejrzani to niezgodność trybu startu (maszyna UEFI uruchomiona jako BIOS) oraz fstab opisany nazwami urządzeń zamiast identyfikatorami UUID. Lekarstwo stosuje się przed wyłączeniem maszyny źródłowej: doinstalowanie sterowników i przebudowa initramfs albo konwersja przez virt-v2v.

Czy moje dane zostaną w Europie? Tak. Infrastruktura, na której świadczymy usługi, znajduje się na terytorium Polski – deklaruje to nasza Polityka prywatności; ten sam dokument opisuje wyjątki (dane analityczne i rozliczeniowe przetwarzane przez dostawców spoza EOG na standardowych klauzulach umownych). Umowę powierzenia (DPA) wraz z listą podwykonawców udostępniamy klientom na życzenie. Dlaczego dla części organizacji to argument rozstrzygający, opisaliśmy w tekście o polskiej chmurze obliczeniowej.

Chcemy zostać u siebie. Pomożecie? Tak – zakres (projekt, wdrożenie CloudStacka na Twoim sprzęcie, przeniesienie maszyn, szkolenie zespołu) ustalamy indywidualnie. CloudStack jest wolnym oprogramowaniem, więc po zakończeniu projektu środowisko pozostaje Twoje.

Podsumowanie

Migracja z VMware nie jest trudna technicznie – jest trudna organizacyjnie. Konwersja dysku to kilka poleceń; o tym, czy przełączenie skończy się o drugiej w nocy, czy o szóstej rano, decydują harmonogram fal, mapa zależności, sterowniki przygotowane z wyprzedzeniem i uzgodniony moment odwrotu. A jeśli rachunek jest wciąż otwarty i obok CloudStacka przeliczasz też hiperskalerów, pomoże Ci zestawienie hiperskaler czy polska chmura.

Najtańszym pierwszym krokiem jest rozmowa i test na jednej maszynie: przechodzimy przez Twój arkusz inwentaryzacyjny, pokazujemy, jak wygląda praca w panelu, i mówimy wprost, co przeniesie się gładko, a co będzie wymagało pracy. Napisz do nas albo zobacz chmurę publiczną WebDisk.

Migracja z VMware do WebDisk Cloud: co przenieść, w jakiej kolejności i czym to zrobić