Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Migracja maszyny wirtualnej spod ESXi na HyperV

Trafiło mi się ostatnio nietypowe zadanie - migracja maszyny wirtualnej ze środowiska ESXi (VMware) do microsoftowego HyperV. Operacja na pozór prosta, jednak po drodze okazało się, że nie pozbawiona problemów. Postanowiłem choć pokrótce opisać ten proces dla czytelników Dobrych Programów - może komuś w przyszłości to się przyda.

Chodziło konkretnie o przeniesienie maszyny z Ubuntu Server (wersja 14.04 choć nie ma to znaczenia) działającego pod ESXi na platformę HyperV. Dlaczego? Tego nie wiem i po prawdzie na potrzeby tego wpisu nie jest to istotne. W każdym razie sprawa wydawała się banalna - istnieje bowiem coś takiego jak Microsoft Virtual Machine Converter (Zdjęcie 1)

Niestety, okazało się, że maszyny fizyczne z VMware ESXi oraz Microsoft HyperV nie znajdują się w tych samych lokalizacjach i konwersja "w locie" w postaci opcji "Migrate to HyperV" nie będzie możliwa (Zdjęcie 2)

Nic to, należało więc udać się do miejsca gdzie stała pierwsza maszyna i wyeksportować wirtualne Ubuntu. No to zaczynamy. Odpalamy klienta VMware vSphere i z menu "File" wybieramy oczywiście "Export" a następnie "Export OVF template" (Zdjęcie 3)

Ważna sprawa! Eksport maszyny wirtualnej możliwy jest wyłącznie wtedy, kiedy jest ona wyłączona. Jeżeli więc jest to jakiś serwer produkcyjny i nie ma dla niego zastępstwa, prace należy wykonywać wtedy, kiedy nikt z niego nie korzysta (czyli zapewne w którąś z weekendowych nocy ;) ). Czas eksportu zależy oczywiście od objętości maszyny wirtualnej - w tym przypadku wspomniany Ubuntu Server służył jako środowisko do webaplikacji i zajmował niecałe 30gb. Eksport nie trwał więc długo i zajął mniej więcej godzinę (Zdjęcie 4)

Może dodam jeszcze, że ja korzystałem z wersji 5.5.0 klienta vSphere (Zdjęcie 5). Wspominam o tym gdyż już po całej migracji dowiedziałem się, że niby były problemy z eksportem maszyn z wersji wcześniejszych ale nie jestem w stanie tego potwierdzić.

Tak czy owak ja nie miałem żadnych kłopotów i po godzinie w katalogu docelowym miałem trzy pliki o rozszerzeniach:

  • .mf
  • .ovf
  • .vmdk

Dla naszych potrzeb liczy się w zasadzie jedynie ten ostatni, który zawiera dysk maszyny wirtualnej w formacie vmdk. Plik z rozszerzeniem .ovf może się okazać przydatny jeżeli zapomnimy jakie były parametry fizyczne wirtualnego serwera tzn. ilość pamięci RAM, porty itd. Ja spisałem to sobie na kartce, zresztą wymagania Ubuntu Server nie były jakieś specjalnie duże.

W każdym razie po eksporcie należy zgrać pliki na jakiś nośnik i udać się z nim do miejsca gdzie czeka już maszyna z HyperV.

Niestety, nie będzie to takie proste jak myślicie :) Wprawdzie w HyperV (Zdjęcie 6), jest opcja importu, niestety microsoftowy klient wymaga dysku w postaci pliku .vhd a nie .vmdk - cóż, takie życie.

Co robić? Odpowiedź brzmi - konwertować!

Na stronie firmy 2Tware znajdziemy doskonały program do konwersji dysków z formatu .vmdk na .vhd - co ważne, program jest darmowy a nazywa się 2Tware Convert VHD Free 1.0.4. Gorąco polecam bo ten mały programik nie wymaga instalacji i działa wyjątkowo szybko! (Zdjęcie 7)

Sposób jego użycia nie nastręczy nikomu żadnych trudności. Jedyne wymagane parametry to źródło czyli ścieżka do naszego pliku z dyskiem w postaci formatu .vmdk oraz katalog docelowy gdzie zapisany zostanie plik w formacie .vhd (Zdjęcie 8)

Convert VHD działa wyjątkowy szybko i 30gb plik "przerobił" w niecałe pół godziny (na zwykłym desktopie z core2duo, 4gb pamięci i zwykłym talerzowym dyskiem 5400rpm. Nie sprawdzałem ale zakładam, że na lepszym sprzęcie oraz wydajniejszym dysku (SSD) trwałoby to znacznie krócej. Na marginesie chciałbym dodać, że dzieło firmy 2Tware potrafi również konwertować dyski fizyczne do postaci .vhd.

W każdym razie w efekcie otrzymujemy gotowy plik w akceptowanym przez HyperV formacie (Zdjęcie 9)

Nie pozostało już nic innego jak utworzyć nową wirtualną maszynę w HyperV i zamontować do niej stworzony co dopiero dysk.

Z menu "Akcja" wybieramy "Nowe" -> "Maszyna wirtualna" i rozpoczynamy konfigurowanie naszej maszyny (Zdjęcie 10)

Poszczególne etapy prezentuję na poniższych zdjęciach - myślę, że komentarz jest zbędny, tym bardziej, że wszystko robi się intuicyjnie. Dodam jedynie, że przy definiowaniu ilości pamięci (w tym przypadku 1gb) warto zaznaczyć opcję "Użyj pamięci dynamicznej dla tej maszyny wirtualnej" - jeżeli zaistnieje taka potrzeba hypervisor przyzna maszynie więcej pamięci niż to jest określone w opcji "Pamięć początkowa".

Wprawne oko adminów odkryje zapewne, że hostem dla HyperV jest Windows Server 2012 R2, stąd i w opcjach wyboru karty sieciowej pojawia się wirtualny przełącznik. Co to takiego? Na tą chwilę nie jest to ważne, mam pomysł na artykuł w którym w przyszłości postaram się wszystko dokładnie wyjaśnić.

No cóż, gotowe. Spróbujmy uruchomić nasz Ubuntu Server już z HyperV - zaznaczamy naszą nową maszynę wirtualną i albo robimy dwuklik albo z menu "Akcja" wybieramy "Połącz" a następnie "Uruchom" (Zdjęcie 16)

Po krótkiej chwili pojawi się nam linuksowa konsola (Zdjęcie 17)

Spróbujmy się zalogować - niech będzie, że na "roota" :) (Zdjęcie 18)

Działa? Działa! :D

Słowem podsumowania dodam tylko, że w nowym miejscu trzeba oczywiście sprawdzić adresowanie bo każda lokalizacja może mieć swoją a wyeksportowany serwer zachowuje adres ze swojej natywnej sieci. W razie potrzeby wystarczy tylko zmienić ustawienia sieciowe (IP, maska, brama).

Podobnie w przypadku przenoszenia serwera (lub jego klonowania) w obrębie jednego lan'u, trzeba pamiętać o podmianie adresu IP nowej maszyny bo nagle może okazać się, że w sieci lokalnej mamy dwie maszyny o tym samym ip'ku :)

 

windows porady serwery

Komentarze

0 nowych
Pudel89   7 #1 22.08.2016 12:10

Trafiłeś w to co za niedługo sam będę robił. Dzięki wielkie za ten wpis. :)
Programik ten sam kiedyś używałem, faktycznie robiłem nim VHD by montować w Windowsie i działa całkiem sprawnie.

Jack_Daniels   7 #2 22.08.2016 12:21

Może ktoś zauważył że darmowy okres na ESXi kończy się :D

  #3 22.08.2016 12:53

Czyli w skrócie bez problemów. Wyeksportowałeś, przekonwertowałeś i działa... Tak czytałem i spodziewałem się jakichś ciekawych problemów, a tu nic :)

sagraelski   6 #4 22.08.2016 13:01

@Jack_Daniels: Nie nie - to nie była wersja 60 dniowa, mieli licencję. Ostatecznie jednak nie dowiedziałem się czemu przenoszą.

mmm777   4 #5 22.08.2016 13:17

Ostatnio ciekawostką przy konwersji z VirtualBoxa na HyperV była brak (W10) oprogramowania integrującego, szczęśliwie w internecie było “vmguest.iso”.
Powód: po Anniversary Update uruchomienie maszyny w VB kończyło się bluescreenem.

microsoft_to_syf_^^   1 #6 22.08.2016 17:04

@sagraelski:

Czy po konwersji jesteś pewny integralności danych ?



Przy okazji..
Czy próbowałeś "qemu-img" ?

Przykład użycia:
"qemu-img convert -O vpc input.vmdk output.vhd"

bachus   19 #7 22.08.2016 17:09

Ja tylko dodam, że warto sprawdzić, czy nie trzeba ustawić dla danej maszyny tego samego adresu MAC - czasem to ma znaczenie (wtedy to już konkretnie trzeba uważać, aby dwie maszyny (klon i źródło) nie znalazły się jednocześnie w sieci włczone.

sagraelski   6 #8 23.08.2016 06:09

@microsoft_to_syf_^^: Nie, nie próbowałem. Była opcja z powershellem gdyby ConvertVHD nie dał rady. Jako takiej integralności nie sprawdzałem - system działał, usługi dzialały - bazy do mysql i tak kopiowali z ręki, na tą chwilę wszytko ładnie "paca". BTW! Fajny nick!!! :D

Pudel89   7 #9 23.08.2016 08:31

@sagraelski: A może mieli darmową licencję?
Teraz prosty serwer na ESXi da się zrobić na free licencji. Obsługuje wtedy nawet 2 x fizyczne CPU i znośnie działa.
Ograniczenia są w zablokowanym API i chyba przydzielaniu vCPU maszynom.

  #10 23.08.2016 13:53

O ludzie, nie ma to jak sobie skomplikować zadanie. Ale tak to jest jak się korzysta z tylko znanych sobie narzędzi. Poniżej ogólny przepis na przeniesienie dowolnego Linuksa z jednego miejsca w drugie (niezależnie czy są to fizyczne czy wirtualne maszyny).
1. Przygotowanie parametrów docelowego serwera - przy okazji można poprawić układ dysków (mniejsze lub większe partycje, rozbicie na kilka dysków czy umieszczenie wszystkiego na jednym dysku) czy też zmienić system plików.
2. Uruchomić Live CD z Linuksem na źródłowej i docelowej maszynie. Na źródłowej maszynie uruchomić serwer SSH (preferowane, bo transmisja będzie szyfrowana) lub serwer rsync; skonfigurować odpowiednie adresy IP i podmontować odpowiednio partycje (np. pod katalogiem /target).
3. Na docelowej maszynie uruchomić kopiowanie plików z wykorzystaniem rsync z takimi parametrami:
rsync -avH --progress --numeric-ids ip_zrodlo://target /target
4. Poprawić na docelowej maszynie wpisy w pliku /target/etc/fstab i MAC karty sieciowej w /target/etc/udev/rules.d/70-persistent-net.rules (tak jest w Debianie).
5. Odświeżyć konfigurację gruba i ponownie go zainstalować.

System przeniesiony :)

Ok, ktoś kto nie zna się na Linuksie to może wyglądać jak czarna magia, ale z kilku dostępnych sposobów ten jest najelastyczniejszy, głównie ze względu na poprawę układy dysków i partycji. I nie jest wcale tak trudny (o ile się trochę wie co robi), a na pewno nie trzeba się bawić w konwersję wirtualnych dysków.

sagraelski   6 #11 24.08.2016 12:53

@kanar123 (niezalogowany): Obie maszyny były w różnych lokalizacjach i nie było między nimi połączenia. Więc w tym wypadku chyba jedynie dd albo jakaś clonezilla? W każdym razie pomysł godny rozważenia przy innej okazji.

Autor edytował komentarz w dniu: 24.08.2016 12:53
przemor25   14 #12 25.08.2016 21:23

Dobry wpis. Trudno "się pogubić" mając taką ściągawkę :)