Instalacja Maszyny Wirtualnej VMware / vSphere z użyciem nośnika (np. obrazu ISO)

Dzisiaj coś dla fanów wirtualizacji, a mianowicie Instalacja Maszyny Wirtualnej VMware / vSphere 5.x, ale bez użycia szablonów (templates). Choć w codziennej pracy administratora vSphere szablony to podstawowy sposób tworzenia wirtualnych maszyn (któż chciałby za każdym razem tworząc nową maszynę przechodzić nudny i czasochłonny proces instalowania systemu operacyjnego z nośnika, a potem sterowników i oprogramowania, gdy można cały ten proces pominąć? ), to aby stworzyć nowy szablon, albo postawić pojedynczą maszynę z niestandardowym systemem, trzeba przynajmniej raz wszystko wy-klikać ręcznie :). Tak więc, tematem tego artykułu będzie instalacja maszyny wirtualnej z użyciem instalatora na płycie lub pliku ISO – nie będę jednak opisywał instalacji samego systemu operacyjnego. Screenshoty przedstawią Windows Serwer 2012, ale z punktu widzenia vSphere nie ma to dużego znaczenia dla ogólnego procesu tworzenia nowej maszyny.

Przedstawiony w tym artykule proces tworzenia nowej maszyny odbędzie się w konsoli „Virtual Center Server” podpiętej do serwera VC – nie ma znaczenia, czy VC postawiliście na windowsie, czy używacie gotowego VC linuksowego (pre-konfigurowana maszyna wirtualna zainstalowanym Virtual Center).

Instalacja Maszyny Wirtualnej VMware/vSphere

Widok konsoli powinien być ustawiony na Home > Inventory > Hosts and Clusters,
vspher home inventory hosts_and_clusters
..lub Home > Inventory > VMs and Templates.

Zaznaczamy Datacenter, lub klaster, lub fizyczny host ESXi, klikamy PPM, wybieramy „New Virtual Machine”:
vSphere-new-vm
Następnie, musimy wybrać pomiędzy instalacją typową „Typical” i bardziej zaawansowaną (custom). Sekwencję kroków, którą teraz przejdziemy, zdradza lista po lewej stronie.
new_vm_vsphere1
Jak widać, gdy wybierzemy „custom”, będziemy mogli dodatkowo podać ilość procesorów i rdzeni (CPUs), pamięć RAM (Memory), ustawienia sieciowe (Network), i kontroler SCSI. Oczywiście, wszystkie te ustawienia można zmienić nawet, gdy instalacja jest zakończona. Ja wybieram „custom” i klikam „Next”:
new_vm_vsphere2
Podajemy nazwę maszyny – nie będzie to jednak nazwa w systemie zapisana operacyjnym, a nazwa obiektu, jakim jest maszyna wirtualna. Warto pamiętać, że zarówno folder wirtualnej maszyny jak i większość plików tworzących ja mają w sobie tę nazwę. Warto więc dla porządku i łatwiejszej administracji użyć tej samej nazwy jaką będziemy później rejestrować w DNS. Nazwy maszyn mogą mieć do 80 znaków i muszą być unikalne w obrębie Virtual Center.
new_vm_vsphere3
Wskazujemy odpowiedni klaster (jeśli mamy więcej niż 1 host ESXi to musimy mieć klaster 🙂 Klastrów oczywiście może być więcej niż jeden.) vSphere powinien sam zadecydować na jakim hoście ESXi znajdzie się maszyna):
new_vm_vsphere4
Teraz musimy wskazać, gdzie będą leżały pliki wirtualnej maszyny – maszyna wirtualna, to tak naprawdę zestaw plików. Wskazujemy konkretny „Datastore” (to taki „logicza jednostka dyskowa dyskowa” w vmware’owym systemie plików VMFS, który najczęściej znajduje się na współdzielonej macierzy (np iSCSI, FC czy NAS) i jest widziany przez wszystkie hosty ESXi) lub klaster DRS. Jak się domyślacie, Klaster DRS to coś, co zapewnia balans pomiędzy Datastore’ami na podstawie zużytego miejsca lub obciążenia. O klastrach DRS napisze coś innym razem, bo to bardzo rozbudowany temat.

Podzielę się screenami z 2 różnych konfiguracji. W tym przykładzie nie mamy klastra DRS tylko widoczne Datastore’y, z których muszę wybrać taki, co ma wystarczająco dużo wolnego miejsca. Zwróćmy uwagę, aby plików maszyny nie umieszczać na lokalnych dyskach hostów ESX – uniemożliwi nam to korzystanie z krytycznych opcji jak vMotion i zrujnuje redundancję (niedostępność hosta ESXi będzie oznaczała niedostępność Maszyny Virtualnej).
new_vm_vsphere5
Tutaj natomiast widzimy 2 klastry DRS (jak wynika z nadanych im nazwom, jeden oparty jest na macierzy z dyskami z interfejsem SAS drugi SATA). Gdy zaznaczymy któyś klaster, to domyślnie datastore’y są szare, bo pozwalamy klastrowi zadecydować gdzie trafi maszyna. Jak pewnie sami oceniliście, wariant z klastrem jest sensowniejszy, bo pozwala uniknąć błędów administratora. Można oczywiście sprecyzować na który datastore trafi maszyna wybierając „Disable Storage DRS for this Virtual Machine”:
new_vm_vsphere5-drs-cluster

Wybieramy System Operacyjny

Wybieramy Wersję systemu operacyjnego – to bardzo ważne, gdyż na tym etapie VSphere dobierze odpowiedni zestaw różnego rodzaju sterowników i vmtools. Możemy wybrać którąś z licznych wersji systemów Windows lub Linux, albo „other” dla czegoś, czego nie ma na liście:
new_vm_vsphere6b
Ile procesorów będzie miała wirtualna maszyna? (wartości te można w przyszłości swobodnie zmienić):
new_vm_vsphere7
Ile RAMu będzie miała wirtualna maszyna? (wartości te można w przyszłości swobodnie zmienić):
new_vm_vsphere8
Ustawienia karty sieciowej – vswitch, czy ma byc podpięta zaraz po włączeniu? (tutaj NIE ustawiamy adresu IP, maski itd..)
new_vm_vsphere9
Wybieramy kontroler iSCSI:
new_vm_vsphere10

Wirtualne dyski w vSphere: Tworzenie wirtualnego dysku

Możemy stworzyć nowy dysk (i taka jest domyślna opcja), podpiąć istniejący, lub stworzyć maszynę bez dysku (nigdy nie miałem potrzeby tworzyć takiej maszyny poza środowiskiem testowym, ale u Was taka maszyna może mieć zastosowanie):
new_vm_vsphere11

Wirtualne dyski w vSphere: Dyski „chude”, dyski „grube”, czyli thin- i thick provsioning

Zarówno przy instalacji maszyny z szablonów jak i bez szablonów, przy tworzeniu nowej maszyny jak i dodawaniu dysku do istniejącej, oprócz podania rozmiaru dysku musimy dokonać niezwykle ważnego wyboru: czy maszyna ma od razu za-alokować sobie tyle miejsca ile jej wskazaliśmy, czy też ma zużywać tylko tyle ile w danym momencie potrzebuje.

new_vm_vsphere12

Podam 2 przykłady:
Przy dyskach „grubych” (thick provisioning), system operacyjny widzi swój wirtualny dysk o wielkości np. 500GB, i nawet gdy pliki na tym dysku zajmują łącznie 20GB, to plik .VHD tej maszyny wirtualnej (plik dysku) będzie zajmował ok 500GB.

Przy dyskach „chudych” (Thin Provisioning) system operacyjny „myśli”, że ma dysk wielkości 500GB, ale jeśli jej pliki zajmują łącznie 20GB, to plik .VHD tej maszyny będzie zajmował tylko około 20GB (pomijam tu zaawansowane liczenie KB).

Thin Provisioning to mechanizm równie cudowny, co niebezpieczny. Możemy naszym systemom operacyjnym „wmówić”, że ich dyski mają razem więcej przestrzeni niż go naprawdę mamy na macierzy. Podczas gdy użytkownicy tych maszyn cieszą się z przestrzeni jaką dostali od admina, to admin niestety musi trzymać palec na pulsie. Mając maszyny wirtualne z „chudymi” dyskami musimy obserwować faktyczne zużycie miejsca na macierzy i zwiększać przestrzeń dyskową zanim maszyna wirtualna się o nie „upomni”. Pewnie od razu pomyśleliście o dwóch aspektach: można oszczędzić fundusze poprzez przekładanie w czasie rozbudowy infrastruktury i kupowanie dysków, dopiero gdy będą naprawdę potrzebne, ale z drugiej strony maszyna wirtualna może niespodziewanie zużyć całe fizyczne miejsce na datastore i .. doprowadzić do niedostępności swojego dysku lub niedostępności wszystkich maszyn na tym datastore.

Od siebie dodam jeszcze jeden ważny punkt: niektóre typy serwerów np te z MS SQL wedle wielu poradników powinny mieć od razu dyski „grube (thick provisioning)”. Warto przy podejmowaniu decyzji poczytać trochę czy dany produkt wymaga dysków „grubych” czy może mieć „chude”.

Teraz wyjaśnię kwestię dwóch typów dysków „grubych”:

Thick Provision Lazy Zeroed – Miejsce na ten dysk jest zarezerwowane w momencie tworzenia dysku. Wszytskie dane znajdujące się na fizycznym dysku nie są skasowane, tylko wyzerowane „na żądanie” kiedy maszyna zapisuje na tym dysku nowe dane.
Thick Provision Eager Zeroed – Miejsce na ten dysk jest zarezerwowane w momencie tworzenia dysku, ale jednocześnie dane na fizycznym nośniku są całkowicie wyzerowane. Proces może potrwać kilka -kilkanaście minut w zależności od wielkości i rodzaju fizycznych dysków.

Wracając do instalacji maszyny wirtualnej, w tym kroku podejmujemy jeszcze decyzję, czy dysk maszyny (plik VHD) ma leżeć na tym samym datastore co maszyna (Store with the virtual machine). Najczęściej odpowiecie, że tak, chyba, że tworzycie dodatkowy dysk, który niekoniecznie zmieści się na danym datastore – wtedy wybierzecie „Specify a Datastore” i wskażecie lokalizację.

Na tym etapie możemy zaznaczyć, że dysk maszyny będzie „independent„, czyli nigdy nie będą objęte snapshotami ( snapshot to zapisana kopia maszyny wirtualnej pozwalająca przywrócić maszynę do stanu w jakim była w momencie robienia snapshota).. Dyski typu „independent” dzielą się na 2 rodzaje:

Persistent – zmiany na dysku będą od razu zapisywane i zapamiętane po restarcie.

Non Persistent – zmiany nie będą zapamiętywanie i restart maszyny wirtualnej spowoduje jej powrót do poprzedniego stanu – fajna rzecz dla maszyn testowych lub maszyn typu „kiosk”.

new_vm_vsphere13

Podpinamy instalator systemu do maszyny wirtualnej – wirtualne napędy

Nareszcie możemy podpiąć instalator. Możemy to zrobić na wiele sposobów. Na przykład mając otworzoną konsolę maszyny wirtualnej (PPM na maszynie > Open Console). W pasku narzędziowym tej konsoli widzimy ikonę przedstawiającą płytę CD z kluczem (na moje oko to „płaska szesnastka ;)”). Rozwinie nam się menu:
vm ISO

Connect to F: (F reprezentuje literę jaką oznaczony jest napęd CD/DVD na komputerze z jakiego uruchomiliśmy konsolę VC – najczęściej to nasz lokalny komputer ). Możemy mieć fizyczny lub wirtualny nośnik w naszym napędzie i z niego właśnie skorzysta maszyna wirtualna do instalacji systemu. Oczywiście, jeśli serwer VC jest daleko, to ściąganie danych przez LAN/WAN może nie być dobrym pomysłem..

Connect to ISO Image on local disk: możemy wskazać plik ISO znajdujący się na dysku komputera, na którym uruchomiliśmy konsolę VC.

Connect to Host device…: oznacza napęd fizycznego hosta ESXi na którym właśnie znajduje się maszyna wirtualna.

Connect to ISO image on a Datastore… – ta opcja jest najlepsza pod względem wydajności (czasu instalacji), bo dane z pliku ISO przechodzą tylko pomiędzy macierzą a serwerem ESXi bez pośrednictwa sieci LAN/WAN:
vm ISO3

Te same opcje podpięcia instalatora ujrzymy z poziomu właściwości maszyny (PPM na maszynie > Edit Settings > Zakładka „Genral” > „CD/DVD Drive 1”)
vm ISO2

Skoro maszyna wirtualna widzi nasz instalator, należy ją uruchomić ponownie i rozpocząć proces instalacji systemu. Na pewno warto opóźnić bootowanie, aby mieć kilka sekund na wciśnięcie odpowiedniego klawisza. Opisałem jak to zrobić w artykule „Kolejność bootowania i opóźnione bootowanie w maszynie wirtualnej VMware/vSphere” – zachęcam do odświeżenia.

Mam nadzieję, że ten długi artykuł nie powstał na marne i komuś się przyda. Jeśli macie jakieś komentarze, pytania lub pomysły na dalsze wpisy w vSphere – zachęcam do dyskusji.

Łukasz Skalikow

Obecnie Manager IT. Przez lata byłem Inżynierem systemów. Jestem entuzjastą i specem od vSphere, Windows serwer, GPO. Od zawsze byłem zwolennikiem wiersza poleceń i automatyzacji. Obecnie, ze względu na pracę, rodzinę i wyjazdy służbowe, dużo mniej udzielam się na blogu, ale mam nadzieję, że pośród kilkuset porad opublikowanych na spece.it, wiele osób znajdzie dla siebie coś przydatnego :)

Przeczytaj także...

9 komentarzy

  1. on napisał(a):

    Bardzo fajny artykuł! Szkoda, że nie ma takich wpisów o XenServer 🙁

  2. slawa napisał(a):

    Powiedz mi proszę jak to wygląda w przypadku thin provisioning rozmiar dysku vmdk zmniejsza się też ? Bo to że zwiększa w raz z ilością danych to jest jasne ale czy przy usuwaniu rozmiar się też zmniejsza ?
    Mam taką sytuację że w teorii system pokazuje mi 60GB wolnego z 130GB a w configuration na hoście w storage widze że vmdk zajmuje prawie 130 GB

Dodaj komentarz