Kategoria: virtualization

disk2vhd na wersji core

przy uruchomieniu disk2vhd na w2k8 R2 od razu pojawia się ‘missing vssapi.dll’. kwestią jest wersja x64 a standardowo próbuje dostępu do 32bit biblioteki. proste rozwiązanie:

set path=c:windowssyswow64;%path%

a potem już disk2vhd śmiga jak trzeba.

ps. próbowałem stworzyć ‘livecd’ z disk2vhd – tak, aby można było zfałhadekować offlineowy serwer. niestety na żadnym WinPE – nawet w DaRTS – nie jest uruchamiany podsystem obsługi vhd ): póki co nie mam pojęcia czy da się [i jak] stworzyć WinPE z obsługą VHD.

eN.

Migration attempt failed

problemy z live migration są ohydne do debugowania. poza krótkim opisem ‘migration attempt failed’ i enigmatycznym wpisie w eventvwr, który w najlepszym przypadq podpowie ‘error on source/destionation’ nie wiadomo nic więcej. pozostaje zbadanie całej konfiguracji krok-po-kroq. BUEEE.

najczęstszą przyczyną są błędy w nazewnictwie – np. sieci wirtualnych. literówki, brak jakiejś spacji etc. dość łatwo to przetestować po prostu podłączając do innej sieci i sprawdzić czy działa.

doczytałem o problemie z przesyceniem łącza dla LiveMigration – dlatego MS zaleca aż dwa dedykowane połączenia bezpośrednie między węzłami – oddzielne na LM i oddzielne na CSV i Hearbeat.

trafiłem na bardziej wredny problem ale trywialny w rozwiązaniu:
wszystko hula jak trzeba, maszyny używane od jakiegoś czasu, więc żadne literówki nie wchodzą w grę. na wszelki wypadek porobiłem testy migracji – maszyny, które mają pojedyncze dyski migrują się bez problemu… kłopot z migracją był tylko z maszynami, które miały podłączone dodatkowe dyski na drugim CSV. już chciałem się wściekać, że “to głupie LM nie obsługuje dwóch CSV”… ale zauważyłem, że w interfejsie brakuje informacji o powiązaniu z drugim CSV:

a rozwiązanie jest tak proste:

• po każdej zmianie wykonanej z poziomu Hyper-V Manager – bez względu czy dotyczy dysków, sieciówek czy czegokolwiek – należy odświeżyć konfigurację na klastrze.

w widoq maszyny wirtualnej RMB –> more actions –> refresh virtual machine configuration.

**UPDATE

i jeszcze jeden LoL http://blogs.msdn.com/b/robertvi/archive/2011/06/07/problems-with-live-migration.aspx

eN.

iSCSI na guest’cie. optymalizacja

można wyobrazić sobie dwa modele podłączenia dysku  iSCSI z danymi do maszyny wirtualnej:

• oba dyski dostępne są jako vhd na hosta i z tego poziomu podpięte do guesta
• dysk systemowy jest widoczny dla hosta a dysk z danymi jest dostępny via iSCSI i mountowany z poziomu guesta

jaka jest różnica?

różnica będzie polegać na kilku elementach: optymalizacji wykorzystania sieci, gdzie wchodzi przepustowość, i MPIO oraz wykorzystania pewnych mechanizmów – np. snpshotów, a to wiąże się z backupami. różni się również przenaszalność/elastyczność.

Scenariusz 1 – oba dyski jako vhd

niewątpliwie jest bardziej standardowym scenariuszem. dysk systemowy i dysk z danymi są w postaci VHD widoczne na poziomie hosta. zazwyczaj takie dyski będą albo lokalnie na serwerze albo na macierzy. bardziej interesujący jest przypadek z macierzą:

• jasna sprawa, że w takiej konfiguracji cała optymalizacja będzie realizowana z poziomu hosta. tutaj musi być odpowiednio skonfigurowane np. MPIO
• najważniejszą kwestią jest przepustowość sieci. jeśli maszyn wirtualnych jest wiele – a tak zazwyczaj jest, to (zakładając, że to konfiguracja Hyper-V z Cluster Shared Volume) wykorzystywane jest pojedyncze połączenie dla wszystkich maszyn. można zatem próbować kombinować z różnymi mechanizmami agregacji – czy to teaming kart sieciowych czy LACP. gdzieś na stronach MS można znaleźć, że Microsoft iSCSI nie obsługuje MPIO dla kart w teamingu, ale nie potwierdzam tego w praktyce i znalazłem podobne opinie na innych blogach.
• druga kwestia to mechanizmu snapshotów – macierz ma zazwyczaj swoje mechanizmy a Windows ma swoje [VSS dla systemu oraz snapshoty dla Hyper-v]. i tu zaczyna się trochę kombinowania – który mechanizm da najlepsze wyniki i jak to skonfigurować. aplikacje backupujące będą odwoływać się do VSS Hyper-V. jeśli tylko producent dostarcza odpowiednie sterowniki, można jednym snapshotem z poziomu macierzy zrobić wszystkie maszyny – warto zwrócić się do producenta maszyny o informacje czy jest to wspierane i jak to skonfigurować, ponieważ zysk może być duży.
• jest to rozwiązanie bardzo przenaszalne – ponieważ pliki vhd łatwo skopiować, podmountować itp, itd. w związku z czym łatwo zarządza się całym dyskiem jako pojedynczym plikiem.

Scenariusz 2 – dysk z danymi jako iSCSI

w pewnych sytuacjach może jednak być potrzeba innej optymalizacji. dysk z danymi może być jako volumen na macierzy udostępniany via iSCSI. jak wygląda optymalizacja i potencjalny zysk:

• daje to dużą dynamikę w alokacji przepustowości sieci, ponieważ można dedykować konkretny interfejs sieciowy dla konkretnego guesta (albo kilq) mapując go z poziomu Hyper-V i wykorzystać do połączenia iSCSI
• inaczej też wyglądają wtedy możliwości snapshotowania – host oczywiście nie dostanie się do takiego dysku a więc mechaznimy backupu muszą być optymalizowanie na poziomie guesta lub macierzy. nie da się w takim wypadku skorzystać ze sterowników macierzy dla Hyper-V.
• przenaszalność jest ograniczona – co prawda volumen można za pomocą iSCSI połączyć na dowolnym hoście, ale wszelkie mechanizmy dostępowe/zarządzania przenoszą się na macierz.
• olbrzymim zyskiem jest możliwość bardzo łatwej i bardzo szybkiej zmiany wielkości partycji danych – w przypadku vhd taka operacja zajmie wiele godzi, w tym scenariuszu – kilka sekund.

które lepsze?

w większości przypadków – scenariusz 1. daje to zoptymalizowane wykorzystanie sieci oraz potencjalnie – wsparcie mechanizmów snapshotowania z poziomu hosta przez macierz. jednak jeśli przyrost danych jest nie do przewidzenia lub konieczne jest dedykowane łącze zapewniające 1oo% przepustowości sieci – w takim wypadku scenariusz 2 staje się bardzo zachęcający.

eN.

system backupu na maszynie wirtualnej

scenariusz: chcemy zwirtualizaować serwer backupów.

problem: podstawowy problem to obsługa sterowników/urządzeń. oczywiście w przypadq backupu dyskowego nie ma problemów – mamy do dyspozycji kilka opcji. albo po prostu podłączenie dysq pass-through albo iSCSI. w przypadku napędu taśmowego nie jest tak łatwo. VMWare częściowo wspiera takie rozwiązania, pozwalając na bezpośrednie przekierowanie obsługi urządzenia do systemu guesta – nie mam w tej kwestii doświadczeń, poczytałem sobie tylko, że nie wszystko jest obsługiwane, ale szczegółów nie znam,

co w przypadku Hyper-V? jest bardziej uniwersalny sposób – iSCSI. tak, tak. nie służy tylko do dysków – przecież to pełna obsługa SCSI przez TCP/IP a więc czemu by nie opublikować urządzenia taśmowego po iSCSI?

zredefiniowany problem: jak znaleźć odpowiedni iSCSI Target? jest wiele darmowych produktów – choćby Microsoftowy – ale większość pozwala wyłącznie na tworzenie targetów do dysków wirtualnych. bardziej zaawansowane pozwalały na publikację plików ISO jako targety, fizycznych dysków etc. jednak ze znalezieniem takiego, który wspiera napędy taśmowe – był problem.

sięgnąłem po StarWinda – ponieważ to AFAIK najbardziej zaawansowany software iSCSI Target. nie myliłem się – w pełni obsługuje takie rozwiązanie. problem polega na tym, że pojedyncza licencja kosztuje ok. $1.ooo. to trochę dużo – zwłaszcza, że nie mam zamiaru wykorzystywać go do celu tworzenia wielkiego SANa, a tylko opublikować jedno urządzenie. q mojej uciesze na stronie z darmowymi produktami jest “Tape Redirector” – uproszczony iSCSI Target, stworzony właśnie w tym celu, i to za free!  

instalacja: aby zassać program trzeba mieć konto StarWind – weryfikacja danych jest na tyle niemiła, że nie przyjmuje nawet maila z publicznej skrzynki – musi to być konto korporacyjne. aplikacja instaluje się łatwo i przyjemnie i jest tak intuicyjna, że nie ma co się rozwodzić. jedyny problem – interfejs z jakiś powodów przekłamuje numer portu, dodając 1 – standardowy port tego targetu to 33268 a wszędzie pokazuje 33269.

po odpaleniu inicjatora po stronie systemu guesta i skonfigurowaniu połączenia, w urządzeniach pięknie pokazuje się odpowiednie urządzenie.

niespodzianką był komunikat podczas próby instalacji sterowników urządzenia na guescie, iż nie są wspierane w środowisq wirtualnym. szczęśliwie była również opcja ‘extract’ i po ręcznej instalacji samego sterownika, całość zahulała jak należy (: zresztą BE ma swoje własne sterowniki i niechętnie współpracuje z tymi dostarczanymi przez producenta – a więc najlepiej nie instalować!

na próbę zainstalowałem Backup Exec 2o12 w wersji trial. przetestowałem backup, inwentaryzację, restore – wydje się, że wszystko działa jak należy. można wirtualizować!

wydajność: to oczywiste, ale na wszelki wypadek – aby uzyskać odpowiednią wydajność rozwiązania należy odpowiednio skonfigurować środowisko wirtualne. karta sieciowa dla powinna być dedykowana dla rozwiązania. bez żadnej szczególnej konfiguracji miałem 93MBps.

eN.