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

Zaczynamy przygodę z Cisco VIRL, cz.2 — „daleka droga do celu"

W poprzednim wpisie opisałem proces myślowy jaki powinien przejść każdy zainteresowany instalacją symulatora sieci Cisco VIRL. Ten wpis opisuje dalsze kroki dla tych, którzy zdecydowali się na instalację symulatora w postaci maszyny wirtualnej. A skoro mamy maszynę wirtualną to musimy mieć tez hypervisora.

Nie lubię się powtarzać wiec napisze krótko: dokumentacja VIRL jasno określa, że produkt Cisco poprawnie działa tylko pod nadzorem któregoś z szerokiej gamy produktów VMware.

Jako przysłowiowy biedny student oczywiście rozglądam się zawsze za bezpłatnymi rozwiązaniami – koniecznie legalnymi. Okazuje się, że VMware nie ma oferty edukacyjnej ale w niczym to nie szkodzi, bo już podstawowy dostęp pozwala na szeroki wybór legalnego i darmowego oprogramowania.

Jak szaleć to szaleć. Skoro chcemy nauczyć się czegoś z zakresu sieci (po to przecież zakupiliśmy licencję VIRL) to może warto upiec dwie pieczenie na jednym ogniu i nauczyć się również czegoś o „poważnym” hypervisorze jakim jest vSphere(ESXi)?
Ja tak właśnie pomyślałem i w pierwszej kolejności postanowiłem spróbować zainstalować VIRL na vSphere.

Decyzja zapadła – czas podjąć stosowne kroki. Po pierwsze powinniśmy założyć darmowe konto na portalu VMware (bezbolesny proces). Po drugie musimy wyszukać na portalu którąś z interesujących nas wersji vSphere (przypominam że oficjalna dokumentacja VIRL zaleca używanie wersji 5.1U2, 5.5U1 lub 6.0). ESXi w najnowszej edycji 6.0 możemy ściągnąć w wersji Trial na 60 dni. Mnie to nie zadowalało więc znalazłem na stronie instalkę do wersji 5.5U1 zupełnie za darmo. Dokładnie o to chodziło – po chwili mam obraz iso który mogę wypalić na płycie lub USB. Ok – mogę instalować hypervisora na moim sprzęcie.

Instalacja ESXi… podejście pierwsze, nie ostatnie

W poprzednim wpisie przedstawiłem Wam parę możliwości, co do wyboru tego, gdzie fizycznie zainstalujemy sobie VIRLa. Teraz opisuję proces instalacji na komputerze stacjonarnym złożonym przeze mnie pod kątem udawania pełnoprawnego serwera (procesor z serii E3 i dużo RAMu). Jeżeli ktoś poszedł w inną stronę i zakupił sobie jakiś używany serwerek to powinien mieć łatwiej.

Uruchamiamy instalator ESXi z nośnika, przechodzimy przez pierwsze ekrany z licencją i innymi informacjami i …. lipa. Zgadzam się na postanowienia licencji – pojawia się ekran jakiegoś skanowania i zaraz znowu wyskakuje okno z zapisami licencji. Szybkie rozeznanie sytuacji i wyciągam pierwszy wniosek – instalator ESXi nie wyszukuje mojego dysku. Nie są to moje pierwsze próby z różnymi systemami więc wiem co należy zrobić – wejść do BIOSu i zmienić ustawienia dotyczące ustawienia kontrolera dysków – pamiętajcie, że wszelkie ustawienia AUTO są podejrzane jako te sprawiające problemy. Najlepiej zmienić tryb pracy na właściwy dla naszej płyty głównej/dysku – najczęściej będzie to po prostu SATA. Jeżeli ktoś chce używać macierzy RAID to powinien sobie skonfigurować odpowiedni tryb pod swoje dyski. Zapisujemy ustawienia i po restarcie komputera można stwierdzić, że instalacja ruszyła dalej.

Wniosek – przed instalacją ESXi wymuś właściwy tryb pracy dla Twojego kontrolera HDD. Jeżeli problem z instalacją dalej występuje – czytaj niżej.

Po chwili instalator ESXi zaczyna ładować różne potrzebne mu do pracy moduły – w moim przypadku zatrzymał się w momencie ładowania modułu nfs41client. Po chwili na ekranie pojawił się komunikat o braku adapterów sieciowych wobec czego instalacja nie może być kontynuowana. "Houston, we've had a problem."

Przyczyn przez które VM ESXi nie wyszukuje karty sieciowej może być kilka. Po pierwsze (podobno - nie stwierdziłem tego osobiście) vSphere w najnowszej wersji 6.0 wyświetla komunikat o braku karty sieciowej w przypadku kiedy port karty sieciowej zestawił się w trybie 100Mb/s lub niższym. Jeżeli dotyczy to naszego przypadku to musimy wymusić tryb pracy 1GE w BIOS lub zmienić kabel sieciowy. W najgorszym wypadku musimy zmienić urządzenie do którego podpięty jest nasz serwerek (np. na router z portami 1GE – w sumie dziś to już standard).

Drugą przyczyną problemów z kartą sieciową może być brak sterowników. I tu drodzy czytelnicy pozwolę sobie na dygresję. DUŻĄ dygresję

Instalacja ESXi, podejście drugie i długie

Dlatego odsyłałem Państwa do listy zgodności z systemem ESXi, aby tego problemu uniknąć. Zadbaliśmy o wszystko, ale mały szkopuł umknął naszej uwadze i teraz przez głupi sterownik karty sieciowej nie uda Nam się zainstalować hypervisora?
Jest dobra wiadomość: można dodać własne sterowniki do instalatora ESXI…

Na problemy z instalacją vSphere – www.v-front.de

Googlując trochę o problemach związanych z instalacją produktów VMware na pewno natraficie na stronę www.v-front.de. Znajdziecie na niej całą masę poradników i narzędzi, w tym również ESXi-Customizer – narzędzie za pomocą którego możemy dorzucić do płyty instalacyjnej dodatkowe pliki sterowników.

Opiszę teraz jak sobie poradzić w przypadku kiedy brakuje nam sterownika karty sieciowej, ale poniższe kroki można zastosować w każdym innym przypadku np. jeżeli podstawowy instalator ESXi nie wykrył naszego kontrolera SATA itp.
Zaznaczam, że nie jest to moja autorska metoda, znalazłem ją na v-front.de, tutaj daję linka. Autorem tego artykułu jest Andreas Peetz. Jeżeli ktoś nie ma problemów z językiem angielskim to zachęcam do odwiedzenia oryginalnego wpisu kolegi Andreasa.

A więc zaczynamy od momentu gdzie ostatnio się zatrzymaliśmy. Podczas instalacji ESXi pojawił się problem z załadowaniem modułu nfs41client. Po chwili powinien pojawić się ekran z komunikatem mówiącym o tym, że nie znaleziono karty sieciowej i instalacja nie będzie kontynuowana. Jeżeli mamy pewność, że nasza karta sieciowa nie została omyłkowo wyłączona w BIOSie i że jest 100% to możemy mieć pewność, że mamy problem z sterownikami. W takim przypadku po pierwsze powinniśmy stwierdzić jakiego sterownika potrzebujemy – musimy więc zidentyfikować naszą kartę sieciową. Możemy to zrobić bezpośrednio z poziomu instalatora ESXi.

Zaraz po pojawieniu się błędu należy nacisnąć klawisze Alt + F1. Przywita nas widok linii poleceń. Dane do zalogowania to root i puste hasło. Teraz powinniśmy wylistować sprzęt którego szukamy – tak więc aby wyświetlić identyfikator karty sieciowej powinniśmy wpisać komendę

lspci -v | grep "Class 0200" -B 1

Dla znających podstawy linuxa wszystko jest jasne – lspci to komenda do listowania urządzeń wykorzystujących szynę systemową PCI. Grepem filtrujemy wynik komendy lspci pod kątem urządzeń sieciowych (podajemy tzw. PCI ID). Dla tych którzy borykają się z problemem związanym z kontrolerem dysków polecenie będzie wyglądać tak

lspci -v | grep "Class 0106" -B 1

Dla innego rodzaju sprzętu musimy użyć jeszcze innego zapytania. Dokładną rozpiskę dotyczącą polecenia lspci i wyszukiwania odpowiedniego rodzaju sprzętu znajdziecie tutaj lista Lista może być nieaktualna.

Tyle o poleceniu, a co otrzymamy jako wynik?
W moim przypadku otrzymałem informacje o swojej karcie sieciowej:

\0000:02:00.0 Ethernet controller Network controller: Realtek Semiconductor Co., Ltd. Motherboard
Class 0200: 10ec:8168

Jak widać wiemy już kto wyprodukował naszą kartę sieciowej oraz znamy jej identyfikator 10ec:8168. Teraz powinniśmy poszukać sterownika do naszej karty sieciowej i dodać go do płytki instalacyjnej. Bardzo pomocny w odnalezieniu właściwego sterownika może okazać się portal VIBsdepot

Pliki VIB to paczki instalacyjne specjalnie spreparowane na potrzeby instalatora VM ESXi. Jeżeli ktoś jest ciekawski to może otworzyć plik VIB np. za pomocą 7zipa – można wtedy stwierdzić, że w środku znajdują się plik z sterownikiem, plik deskryptora w postaci XML(opisuje zawartość paczki) oraz tzw. Signature file który definiuje czy paczka pochodzi bezpośrednio od VM (VMwareCertified) czy może paczka została stworzona przez społeczność (CommunitySupported). Oprócz tego jest jeszcze kilka innych możliwości ale o tym może w innym artykule.

Na stronie VIBSdepot możemy za pomocą PCI ID odnaleźć odpowiednią paczkę – wystarczy w okno przeglądarki wpisać ID (wpisujemy tylko to co jest po dwukropku - w moim przypadku 8168) i pobrać plik.

Następnie należy pobrać narzędzie ESXI-Customizer (już niewspierane ale dalej świetnie działa) lub skrypt PowerShell. Nieważne które narzędzie wybierzemy – idea jest taka sama – podajemy ścieżkę do naszego dodatkowego pliku vib (tego którego ściągnęliśmy z VIBsdepot) i ścieżkę lokalizacyjną do obrazu iso ESXi. Program (skrypt) wykonuje całą magię za nas i po chwili otrzymujemy wynikowy plik iso. Możemy mieć pewność, że teraz do instalatora został dołączony nasz sterownik. Teraz tylko wystarczy wypalić iso na CD/USB i przejść cały proces instalacji ESXi. Następnie należy skonfigurować adres IP karty sieciowej (oczywiście jeżeli nie dostajemy go z serwera DHCP) i postępować zgodnie z opisem oficjalnej dokumentacji CISCO Virl http://virl-dev-innovate.cisco.com/client.php

Niestety to nie jest szczęśliwe zakończenie tego wpisu – w moim przypadku pomimo tego, że znalazłem odpowiednią paczkę VIB, to adapter sieciowy dalej nie był wykrywany. Prawdopodobnie stało się tak dlatego, że w znalezionej przeze mnie paczce brakowało sterownika konkretnie do mojego modelu karty sieciowej (PCI ID może być wspólne dla kilku modeli kart sieciowych). Podobne problemy zdarzają się głównie z kartami Realtek i Qualcomm. Co zrobić w takiej sytuacji? Ja zawsze staram się „grzebać” dalej co w doprowadziło mnie do instrukcji tworzenia własnych VIBów i kompilacji źródeł własnych sterowników. Niestety im głębiej wchodziłem w temat tym byłem dalej od rozwiązania problemu – przede wszystkim chciałem szybko uruchomić VIRL-a! Wobec czego zdecydowałem się na inną formę instalacji, ale o tym będzie traktować mój kolejny wpis.

P.S.
Przepraszam za tempo tworzenia kolejnych wpisów ALE w ostatnim czasie jestem bardzo zapracowany/zastudiowany :)
 

porady serwery hobby

Komentarze

0 nowych
bachus   20 #1 01.12.2015 14:03

Ciekawe wpisy, czekam na więcej ;-) Jako ciekawostka (co do wersji 60-dniowej) - liczona jest w czasie działania systemu, tj. 1440h darmowych godzin na wszystkie ficzery. Sprawdza się jedynie wtedy, gdy domowy lab odpalamy na kilka godzin dziennie - łatwo policzyć, że można "przeciągnąć" do kilku miesięcy...

sagraelski   7 #2 02.12.2015 06:45

ciekawe czy aktualnie na zajęciach Cisco CCNA używają jeszcze Packet Tracer'a czy już Virl'a?

Ppetro   5 #3 02.12.2015 18:21

@bachus: Dzięki za info - nie wiedziałem, że tak to działa

Ppetro   5 #4 02.12.2015 18:24

@sagraelski: Dalej Packet Tracer i jeszcze długi czas tak będzie :)
Po pierwsze: VIRL to nowy projekt i nie ma do niego jeszcze takiego zbioru literatury.
Po drugie: VIRL wymaga dużo mocniejszego sprzętu.
Po trzecie: Na poziom CCNA nie widzę potrzeby, aby instalować VIRL-a. Nawet nie jest to wskazane, bo jest jednak dużo trudniejszy w obsłudze.

Autor edytował komentarz.
bachus   20 #5 02.12.2015 18:50

@Ppetro: pamiętam, jak kilka lat temu robiłem VCP i szedłem na szkolenie jako pewniak ("ale się wynudzę przez tydzień") i trafiłem na bardzo dobrego trenera, co rzucał właśnie takimi ciekawostkami (chociaż to jest w dokumentacji), oraz jak z rękawa wyciągał nieudokumentowane opcje do ręcznego grzebania w konfigach...

Ppetro   5 #6 02.12.2015 19:06

@bachus: Pytanie z innej beczki - niedługo koniec studiów (daj Boże) - warto odkładać na szkolenia VMware czy lepiej jak najwięcej grzebać i uczyć się w domu?

bachus   20 #7 03.12.2015 08:59

@Ppetro: za szkolenie to niech Ci (daj Boże) nowa firma zapłaci (bez szkolenia nie ma VCP). Jak prywatnie płacić - za te pieniądze to już lepiej uzyskać jakiś "większy" certyfikat w innej dziedzinie (np. CCNP).

psejta3   4 #8 05.12.2015 16:16

@sagraelski: U nas nadal Pocket Tracer.