Wiedza - Artykuły
Image
O AUTORZE
Wojciech Kowasz
Interesuję się głównie serwerowymi technologiami Microsoftu, ale jestem otwarty na wszystkie dobre rozwiązania. Jako najmłodszy w Polsce zostałem MCSE+S. Teraz jestem inżynierem systemowym odpowiedzialnym za infrastrukturę hostingową m.in. dobrychprogramów, TechIT i Gamikaze. Po pracy jestem także miłośnikiem squasha i gitary klasycznej.
Typy publikacji
Inne publikacje
Image

Konwersja maszyn wirtualnych przy pomocy narzędzia XenConvert

19.10.2010 17:31, Autor: Wojciech Kowasz (Docent), Komentarze (5)

Wirtualizacja jest coraz popularniejsza i stosunkowo łatwo ją wdrożyć, gdy startujemy od zera – na wszystkich serwerach instalujemy wybrany hypervisor, a potem na nim już kolejne maszyny wirtualne z wybranymi systemami. Do tego dodajemy komponenty integracyjne, które usprawnią pracę systemu w środowisku wirtualnym i gotowe. Rzadko jednak zaczyna się od zera. Najczęściej by skorzystać z wirtualizacji trzeba przeprowadzić migrację istniejących systemów. Tutaj z pomocą przychodzą narzędzia do konwersji fizycznych systemów na wirtualne (P2V – physical to virtual) lub wirtualnych na wirtualne, ale innego producenta (V2V – virtual to virtual).

Ten ostatni wariant sprawdziliśmy niedawno na własnej skórze migrując całe nasze środowisko wirtualne pracujące na VMware ESXi na XenServer firmy Citrix. Okazuje się, że – wbrew pozorom – taka migracja jest równie prosta, jak instalacja całości od zera i pozwala zaoszczędzić mnóstwo czasu.

Do konwersji maszyn wirtualnych dowolnego producenta, a także migracji istniejących systemów fizycznych do formatu zgodnego z XenServer służy bezpłatne narzędzie XenConvert. Można je pobrać w wersji 32- i 64-bitowej. Jeśli naszym zamierzeniem jest konwersja fizycznego systemu, należy je zainstalować właśnie na tym systemie. Tym przypadkiem nie będziemy jednak zajmować się w tym artykule – my migrowaliśmy maszyny wirtualne z ESXi. W takim scenariuszu XenConvert można zainstalować gdzieś obok, na przykład na innym serwerze z systemem Windows albo nawet na notebooku administratora. Wystarczy, że ma on szybką łączność z hostami XenServer, na które będziemy importować skonwertowane maszyny.

Przygotowanie do migracji

Przed konwersją systemu na maszynie wirtualnej należy koniecznie odinstalować z niej komponenty integracyjne macierzystego hypervisora. Nie będą one oczywiście działać z hostem XenServer i mogą powodować problemy. Warto pamiętać, że odinstalowanie komponentów może wiązać się z utratą łączności maszyny z siecią, często bowiem komponenty integracyjne dostarczają sterowniki niezbędne dla syntetycznych kart sieciowych. Do deinstalacji można więc posłużyć się konsolą w konsoli administracyjnej hypervisora lub dodać jako drugą kartę sieciową typu podstawowego, niewymagającego wyrafinowanych sterowników.

Konwersja i kopiowanie

Po zainstalowaniu XenConvert uruchamiamy program jako administrator - jest to niezbędne, by można było zamontować w systemie skonwertowany dysk VHD. Zanim jednak zaczniemy cokolwiek konwertować możemy przyjrzeć się możliwościom programu, tym razem już konkretnie pod kątem migracji VMware – Citrix. Jedną z nich jest eksport maszyny wirtualnej do formatu OVF, a następnie wskazanie tego pliku w narzędziu XenConvert i przeprowadzenie konwersji. Jest to wygodne, bo odrazu konwertowana jest nie tylko konfiguracja maszyny, ale także wszystkie wirtualne dyski do niej podłączone. Niestety z tej opcji skorzystać nie mogliśmy, bo bezpłatny ESXi 4.0 nie umożliwiał eksportu do OVF. Jedyne, co mogliśmy zrobić to skopiować same pliki VMDK z dyskami maszyny wirtualnej. To jednak wystarczyło w zupełności – drugą dostępną metodą jest bowiem konwersja wszystkich plików VMDK oddzielnie, jeden po drugim.

Co XenConvert może zrobić ze skonwertowanymi danymi? XenServer obsługuje kilka typów dysków wirtualnych – jednym z nich jest na przykład format VHD stworzony przez Microsoft i wykorzystywany też przez Hyper-V. Jeśli wybierzemy taki format, XenConvert po prostu wygeneruje nam pliki dysków wirtualnych, które będziemy musieli przenieść do hosta XenServer. Drugą opcją jest skorzystanie z funkcji automatycznego importu skonwertowanych dysków na wybrany XenServer. Właśnie na ten drugi wariant się zdecydowaliśmy. W oknie wyboru serwera docelowego przed kontynuowaniem trzeba jeszcze tylko wpisać ścieżkę do folderu tymczasowego do dyspozycji narzędzia XenConvert.

Po wybraniu docelowego serwera pozostaje już tylko czekać – konwersja jest dość czasochłonna. Skonwertowanie maszyny wirtualnej z dyskiem 100 GB trwa około godziny, ale powinniśmy też zarezerwować czas na kopiowanie wyniku konwersji na serwer docelowy. Po pomyślnej konwersji maszyna wirtualna pojawi się w konsoli XenCenter i będzie można od razu ją uruchomić. Warto jednak wcześniej przejrzeć ustawienia wirtualnych procesorów, pamięci, sieci, a także upewnić się, że ustawienia dysków są poprawne. Co jednak zrobić, gdy do skonwertowania mamy kilka dysków wirtualnych w ramach jednej maszyny? Procedurę można powtórzyć – wtedy w konsoli XenCenter pojawi się druga maszyna o tej samej nazwie, zakończona sufiksem „_1”, „_2” itd. Maszynę taką możemy usunąć, ale – co ważne – bez usuwania wirtualnego dysku z magazynu. Następnie taki zwolniony dysk podpinamy jako drugi do właściwej, skonwertowanej wcześniej maszyny.

Po pierwszym uruchomieniu systemu należy oczywiście zainstalować komponenty integracyjne XenTools. Więcej informacji o narzędziu XenConvert, w tym informacje o konwersji maszyn fizycznych na wirtualne można znaleźć w oficjalnym podręczniku Citrix XenConvert Guide.

r    e    k    l    a    m    a

Komentarze

meto
(niezalogowany)
19.10.2010 19:37

meto (niezalogowany)
 

Swoją drogą kiedy migrowaliście z ESXi na XenServera? Czyżby były problemy z wydajnością storage w VMware? Rozmawiałem z LucasemAMD i mówił, że na HotZlocie temat wirtualizacji nie był poruszany, za to przy wdrożeniu ESXi było niezłe zamieszanie + akcja promocyjna Trilline.

 
Docent
19.10.2010 21:06

Docent
 

@meto:

Może tutaj znajdziesz nieco więcej informacji na temat powodów (a raczej głównego powodu):

http://www.techit.pl/MoimZdaniem/Wirtualna-Vyatta-...

Generalnie XenServer okazał się po prostu lepszy - kiedy zaczynaliśmy wirtualizować prawie dwa lata temu to był jeszcze w powijakach, ale teraz jest to znacznie bardziej dojrzały produkt. Nadal wiele mu brakuje "na szerokość" (inaczej mówiąc, nie jest wszechstronny), ale podstawowe zadania - uruchamianie maszyn - zdaje się realizować lepiej niż konkurencja. No i jest bezpłatny XenMotion ;)

 
rk
(niezalogowany)
19.10.2010 21:28

rk (niezalogowany)
 

Ciekawość: skąd taka zmiana? Czy to migracja testowa? Co przemawia na rzecz Citrix-a vs Vmware? Można usłyszeć parę słów porównania?

 
Docent
20.10.2010 12:42

Docent
 

@rk:

Nie, to migracja w pełni produkcyjna i już na stałe - o ile nie pojawi się znowu coś, co skłoni nas do kolejnej migracji ;) Na razie jesteśmy jednak bardzo zadowoleni, zwłaszcza że migracja nie była wcale tak czasochłonna, jak mogłoby się wydawać (całość zamknęła się w kilku dniach).

Co przemawia za XenServerem?

1) Funkcje, których bezpłatny ESXi nie posiada: migracja "na żywo", zarządzanie serwerami w pulach z poziomu jednej konsoli, integracja z Active Directory, wykresy i dane historyczne dostępne dłużej niż godzinę wstecz.

2) Przewaga wydajnościowa: nasze testy pokazały, że dyski wirtualne przechowywane na partycjach LVM w XenServerze cechują się o około 10-15% szybszym odczytem danych, choć zarządzanie (przenoszenie) jest faktycznie nieco bardziej kłopotliwe niż w przypadku plików VMDK na VMware. Przy założeniu jednak, że przenoszenie maszyn odbywa się automatycznie przy pomocy XenMotion i jest dostępny shared storage ten argument nie jest istotny.

To takie najciekawsze różnice, które mi przyszły do głowy w tej chwili. Dużym plusem może być też fakt, że w XenServerze można sobie pogrzebać w shellu jak w każdym Linuksie. W ESXi teoretycznie też można odblokować dostęp via SSH (XenServer oferuje dostęp do konsoli bez dodatkowych zabiegów), ale to już nie to samo - system jest zamknięty. XenServer bazuje na otwartym Xenie.

 
barto
(niezalogowany)
21.10.2010 13:47

barto (niezalogowany)
 

A co z backupem maszyn?
Jak to wygląda w Xenie?
Esxi miał np ghettovcb.sh.

 

Dodaj komentarz

Autor: