VMWare: Część II — atak klonów

Dostałem w ostatnich dniach kilka prywatnych wiadomości z pytaniem o obiecany wpis dotyczący wirtualizacji. Kolejność miała wyglądać troszkę inaczej, ale jak zacząłem wszystko zbierać w całość okazało się, że to temat rzeka - postanowiłem więc zrobić "krótki wpis" o tworzeniu "template", czyli maszyn referencyjnych. Będzie znowu technicznie - nudno z dygresjami i innymi wtrąceniami, zrzutami ekranu, dobrymi (dobrymi według mnie...) praktykami... taki potok myśli. Mam nadzieję, że nikt się nie obrazi za ten bałaganiarski wpis. Pracuję na środowisku:| Windows 7 64bit | 16GB RAM | i5-4690k | VMWare Workstation 12 |

Powód używania VMWare Workstation wyjaśniłem we wcześniejszym wpisie. Świetne narzędzie dla użytkowników desktopowych, jedynie cena może odstraszać...

Jedziemy z tym koksem

Tworząc nowy projekt (LAB), albo nawet przypadkową testową maszynę wirtualną (VM) staram się zachować pewien porządek - jestem już w wieku, że czasem nie pamięta się co jadło na śniadanie a co dopiero rzeczy, które np. robiło dwa dni wcześniej. Pisząc to zdanie musiałem nawet spojrzeć na temat o czym ma być ten wpis, bo już zapomniałem... Po pierwsze, zakładam osobne foldery na dysku wg. zasady: LABx --> MaszynaWirtualnaX

Druga sprawa, to notatki... Tak naprawdę to w rzeczywistości pamięć mam bardzo dobrą, ale wyjątkowo krótką i wybiórczą - staram się założyć chociaż prosty dokument tekstowy i uzupełniać w nim najważniejsze informacje o danej maszynie:

Nową wirtualną maszynę tworzę w standardowy sposób: wybieram opcję: "Typical (recommended)":

System operacyjny najwygodniej instalować z obrazu w formacie ISO. Ja jednak najczęściej wybieram opcję "I will install the operating system later" z dość prostej przyczyny - VMWare na tym etapie stara się rozpoznać instalowany system operacyjny i narzucić za dużo własnych opcji: [item]automatycznie zainstalować VMTools [/item][item]postara się wstrzyknąć kilka podanych wcześniej informacji (konto administratora, hasło, czy nawet kod aktywacji):[/item][img=LAB4_6]

Podobnie dzieje się też np. przy instalacji Ubuntu - po podaniu nazwy użytkownika i hasła skrypt VMWare utworzy cały system bez nadzoru użytownika, łącznie z rozmiarami partycji i pozostałymi ustawieniami Wybieram więc "I will install the operating system later":

Wybór oficjalnie wspieranych systemów operacyjnych jest bogaty - można znaleźć zarówno systemy ze stacji Microsoftu, jak i te opierające się o architekturę *nix (Linux, FreeBSD):

Za przykład do budowy "template" niech posłuży system kliencki Windows 7:

Tutaj też staram się zachować pewne zasady - nazwa odpowiadająca wersji OS i celowi utworzenia danego środowiska, oraz wspomniany katalog docelowy:

Kolejny krok to wybór wielkości wirtualnego dysku twardego (vHDD), oraz w jakiej formie ma być przechowywany: zmieniam, że jako jeden plik, czyli "Store virtual disk as a single file". VMWare podpowiada też, aby użyć dla W7 64bit partycji 60GB. Zwiększam tu rozmiar do 150GB. Domyślnie tworzony jest plik o dynamicznie zmieniającym się rozmiarze, czyli vHDD będzie "puchnąć" w miarę składowania na nim danych a nie zostanie zaalokowane od samego początku 150GB.

Zanim zakońę konfigurację nowej VM, zawsze dokonuję zmian ("Customize Hardware"):

Po pierwsze, zwiększam ilość dostępnej pamięci w celu przyspieszenia samego procesu instalacji:

Kolejna rzecz, to wskazuję, aby VMWare "wsadził" do wirtualnego napędu DVD plik ISO z obrazem OS:

Kolejna rzecz to odznaczam wyjątkowo irytujące dwie opcje: automatyczne wykrywanie podłączonych fizycznych urządzeń USB, oraz bluetooth. Objawia się to tym, że przy uruchomionej maszynie wirtualnej jak do komputera-hosta podłączamy np. pendrive VMWare na siłę chce go podpinać do maszyny wirtualnej:

Dalsza opcja którą odznaczam to wsparcie dla 3D i przekazywanie dzielonej pamięci RAM do vGPU - z reguły nie korzystam w swoich labach z konieczności użycia tej opcji a jakby co, zawsze przecież można to ponownie włączyć:

Po uruchomieniu wirtualnej maszyny dochodzą jeszcze pliki związane ze "stanem" pamięci maszyny wirtualnej, pliki logów i katalogi tymaczowe. Kwestia zrzutów pamięci będzie poruszona przy "migracji na żywo" dla Hyper-V. [item]VMDK: Wirtualny dysk twardy (Virtual Machine Disk)[/item] [item]VMX: plik konfiguracji[/item] [item]VMSD: plik konfiguracji opisujący relacje między dyskami wirtualnym (VMDK) a kolejnymi "migawkami" (snapshot)[/item][img=LAB4_23]

Inslaluję system operacyjny bez jakiś szczególnych ustawień: Next, Next, Next...

VMTools - sterowniki VMWare

Po standardowym zainstalowaniu Windowsa (lub innego systemu oficjalnie wspieranego przez VMWare...) dobrą praktyką jest instalacja "VMWare Tools" - zestawu sterowników. Gdybyś kiedyś się zastanawiał po co są pliki ISO w głównym katalogu wirtualizatora, to właśnie oprogramowanie, które po podpięciu do wirtualnego napędu optycznego umożliwia dodanie dodatkowego oprogramowania:

Tu magii też większej się nie znajdzie, spokojnie można instalować z domyślnymi opcjami:

Zaglądając w opcje zaawansowane wspomnę sterowniku, który czyni różnicę:

Moim zdaniem najważniejszy to Memory Control Driver- sterownik zarządzający przydzielaniem pamięci przez wirtualizator. W "bogatszych" wersjach oprogramowania (tj. np. serwer VMWare ESX, czy Hyper-V z wersji serwerowej Windowsa) można to kontrolować w bardziej rozbudowany sposób. W uproszeczeniu: w przypadku, gdy maszyna mająca skonfigurowane 4GB vRAM (a jej w danej chwili nie używa), zostanie to "przerzucone" na inne, będące w większej potrzebie maszyny. W dużych środowiskach jest to wyjątkowo ciekawa opcja: wiedząc np. że dany system potrzebuje raz w tygodniu do swoich potrzeb 12GB vRAM można skonfigurować priorytety, ale to znowu temat na inny wpis...

Drivery umożliwiają też wygodne restartowanie/usypianie wirtualnej maszyny (Guest) z poziomu menu VMWare - co sprowadza się pewnie do przekazywanie do VM np. komendy:

[code= shutdown -r -t 1] shutdown -r -t 1[/code]

Aktualizacja, optymalizacja - taka sytuacja

Wracając do naszej maszyny - vHDD po czystej instalacji urósł do około 8.5GB:

Odbiegając na chwilę od tematu budowania template - ciekawy ficzer, który może ułatwić życie. Często jest potrzeba wgrania na VM jakiejś aplikacji - pojawia się problem jak to zrobić: skonfigurować sieć i wgrać via LAN; a może podłączyć wirtualny napęd USB? VMWare z zainstalowanymi sterownikami umożliwia zwykłe "przeciągnięcie", lub wklejenie ze schowka hosta aplikacji:

Jak już odbiegam od tematu: VMWare Workstation całkiem sprawnie obsługuje vHDD - tutaj zrzut z testu napędu w komputerze-hoście:

Tu natomiast test uruchomiony bezpośrednio na VM:

Wracając do budowanej maszyny... na tym etapie uruchamiam aktualizacje systemu operacyjnego, co w zależności od szybkości internetu i podsystemu dyskowego, może potrwać "dłuższą chwilę" i kosztować kilka restartów VM:

Jak już to mamy za sobą zaczyna robić się nieprzyjemnie: system zajmuje 26GB, natomiast sam vHDD... 35GB:

Dzieje się to z prostego powodu - pojawiają się pliki tymczasowe (np. rozpakowywany Service Pack), które nawet po usunięciu nie powodują, że vHDD automagicznie zmaleje. Po wgraniu na VM dużego pliku 90GB i natychmiastowym go usunięciu plik vHDD i tak pozostanie powiększony o dodatkowe 90GB.

Zacznijmy od standardowego sprzątania, tj. usunięcia kopii związanych z instalacją SP1, logów, czy punktów przywracania systemu - kosmetyka zmniejszająca ilość danych na dysku systemowym, na Dobrych Programach o tym procesie napisano już wystarczająco dużo, nie będę się za bardzo rozwodził:

Ugraliśmy już ponad 8GB:

To nadal sporo a głównie z dość prozaicznej przyczyny - plik wymiany, który przy domyślnych ustawieniach może zajmować tyle, ile przydzielony vRAM, lub więcej:

Pozdbycie się balastu nie jest proste, można to zrobić na dwa sposoby. Pierwszy to "podmapowanie" vHDD do systemu (robimy to na zatrzymanej maszynie wirtualnej). Interesuje nas główna partycja a nie dodatkowa 100MB tworzona przez OS.

Na etapie podpinania vHDD w celu możliwości dokonywania zapisu należy odznaczyć domyślną opcję "read-only mode". W podanym przykładzie będzie widoczny jako napęd "Y:\" na komputerze-hoście:

Plik wymiany jest plikiem systemowym i domyślnie nie jest wyświetlany w systemie. Dostęp do niego jest możliwy na kilka sposób. W TotalCommander należy włączyć opcję wyświetlania plików sytemowych:

W eksploratorze Windows też można włączyć podobną opcję:

W linii poleceń to "dir /Ah". Samo usunięcie pliku może jednak przysporzyć sporo problemów (Windows będzie dzielnie twierdzić, że to jego niezbędny składnik, mimo że należy do niezależnego dysku, nawet jak przejmiemy uprawnienia itd.), operacja dla zaawansowanych użytkowników:

Należy pamiętać o odłączeniu vHDD ("odmapowaniu"):

Jest jeszcze kilka innych możliwości: zmniejszyć vRAM, uruchomić VM, ponownie wyłączyć i plik zmniejszy swoją objętość:

Można też całkowicie wyłączyć plik wymiany, ale potem pamiętać o włączaniu na "klonach"? Zła praktyka.

Wracamy do naszego wirtualnego dyski, który nadal ma 35GB. Pierwsza operacja to typowa defragmentacja systemu plików, którą można wykonać bezpośrednio na vHDD - będzie to dużo szybsza czynność, niż defragmencaja z poziomu systemu operacyjnego.

W przypadku posiadania dysku SSD będzie to trwało bardzo krótko:

Kolejna czynność to "Compact Disk" - to właśnie ta opcja "obetnie" używane GB na dysku hosta:

Linked Clone

Mamy swój "template" - OS zainstalowany, zaktualizowany. Można przystąpić do wykonania pierwszego "klonu":

W przypadku, gdy template posiada snapshoty, można odwołać się do którejś migawki. Tu  nie było wyżej wymienionych, więc za dużo wyboru nie ma:

Najistotniejsza sekcja: większość wirtualizatorów umożliwia utworzenie dwóch rodzajów "klonów":

Pełny - czyli można to porównać ze skopiowaniem wszystkich plików ze wzorca (template) do nowej, niezależnej maszyny - np. utworzenie kopii vHDD, pliku konfiguracyjnego itd.

Przyrostowy - zależny od template. Najważniejszą właściwością jest ilość miejsca zajmowanego przez nowy vHDD - w nowej maszynie będą zapisywane tylko zmiany wykonywane na "klonie", co oznacza że np. 10 wirtualnych maszyn w labie może zajmować tylko 20GB, zamiast kolejnych 200GB. Nie trzeba chyba wspomniać, że nie powinno się usuwać z dysku vHDD template, albo zbytnio edytować w nim plików...

Nadal staram się trzymać nazewnictwa i zapisać klon w odpowiednim katalogu na dysku:

Z racji tego, że jest to wspomniany wcześniej "linked clone" i  nie ma potrzeby "przerzucenia" ~15GB vHDD:, ała operacja potrwa kilka sekund:

" Za pamięci": VM przenoszę sobie do umieszczonego wcześniej zakładki maszyn wirtualnych:

Analogicznie tworzę drugą maszynę wirtualną:

Pierwsze uruchomienie klonów

Uruchamiamy nasze klony - maszyny nasze identyczne, nadane wcześniej nazwy, te same aktualizacje. Różni je jedynie adres MAC karty sieciowej - VMWare zadbał o to, aby się nie pokrywały:

Na pierwszy rzut oka mamy już gotowe referencyje VM -będzie to działało do czasu. Schody pojawią się dopiero, jak zaczniemy działać trochę głębiej w "uniwersum" Microsoftu. LAB to najczęściej trochę więcej, niż zmiana adresów IP: z czasem pojawi się np. konieczność podłączenia maszyn do domeny (AD). Windows rozpoznaje maszyny po identyfikatorze SID (Security Identifier) - jest to gałąź rejestru:

[code=SECURITY\SAM\Domains\Account]SECURITY\SAM\Domains\Account[/code]

Ten (jak widać w teorii...) unikalny identyfikator można wyświetlić np. za pomocą narzędzia "PsGetSid", wchodzącego w skład "PsTools ". Niestety na obu nowych maszynach nie będą one się różnić, co później przysporzy nam sporo kłopotów:

Tu znowu dygresja - zapomniałem wspomnieć, że na etapie tworzenia template umieszam na vHDD katalog "UTILS", gdzie wrzucam kilka przydatnych narzędzi - np. wspomniany pakiet PsTools:

Sysprep

Do zmiany SID jest kilka narzędzi, ale umówmy się - najpewniejszy jest jednak wbudowany w Windows "Sysprep" - były/są różne wynalazki typu "NewSID", ale nie do końca współpracują one poprawnie z systemami od Visty w górę, dodatkowo nie są to oficjalne narzędzia Microsoft - a na tym etapie lepiej nie "rozjechać" systemu. Co robi dokładnie Sysprep i jakie ma możliwości - jak ktoś jest bardzo zainteresowany, to zachęcam do poczytania na stronach Microsoftu:

https://technet.microsoft.com/en-us/library/cc783215%28v=ws.10%29.aspx

https://technet.microsoft.com/en-us/library/cc721940%28v=ws.10%29.aspx

Program znajduje się w katalogu Windowsa (C:\Windows\System32\sysprep):

Nie wdając się w zbędne szczegóły (opisane w podanych linkach do strony MS)- najczęściej wybieram takie opcje, gdzie najważniejsza jest "Generalize":

Operacja może potrwać nawet kilka minut a przy pomyślnych wiatrach plik vHDD po defragmentacji i kompaktowaniu może jeszcze bardziej zmniejszyć objętość:

Tu jeszcze jedno odstępstwo od tematu, mogące być istotne do labów z WSUSem. Spotykałem się z tym w dużych (kilkaset stacji roboczych i serwerów) środowiskach, gdzie właśnie osoba szykująca komputery "jechała" z koksem za pomocą obrazów 1:1, bo jakieś "sysprepy i inne bzdety to strata czasu" a potem płacz, czemu WSUS, czy inny SCCM nie chce widzieć hostów i zarządzać jego aktualizacjami. SysPrep nie usuwa SusClientId - czyli kolejnego (jak widać znowu w teorii...) niepowtarzalnego identyfikatora. Siedzi on sobie w gałęzi:

[code=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate]HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate[/code]

Można to oczywiście naprawić już na "klonach", ale chyba lepiej zrobić to na template, nieprawdzaż? Sprowadza się to do zatrzymania usługi aktualizacji, oraz usunięcia wpisu w rejestrze, gdzie jak wspomniałem najważniejszy jest SusClientId.

Ja, jako osoba z natury leniwa do katalogu "C:\UTILS" wgrywam prosty batch, który po uruchomieniu robi to za mnie:

Uruchomienie klonów - podejście drugie

Spróbujmy jeszcze raz utworzyć dla klony. Tym razem Windows będzie się zachowywał, jakby to było pierwsze uruchomienie zaraz po instalacji - zapyta o podstawowe informacje, w tym nazwa hosta:

Zobaczmy jak sytuacja z SIDem na VM "DESKOP1", oraz "DESKTOP2" - tym razem wygląda to lepiej:

Podsumowanie

W tym wpisie chciałem przedstawić tylko kwestie związane z tworzeniem template systemu opearcyjnego na przyładzie Windows 7. Operacja będzie wyglądała bardzo podobnie na wyższym wersjach systemów "desktopowych", oraz na serwerowym Windows 2012/2012R2, na którym ostatnio głównie pracuję. Poruszyłem przy okazji kilka dodatkowych tematów związanych z samym Windowsem. W przypadku pracy z wieloma maszynami wirtualnymi i "linked clone" VM największą wydajność można osiągnąć korzystając z dwóch SSD - na jednym umieszcza się maszynę referencyjną a klony dzieli między oba SSD. Same "template" warto sobie "zbackupować" - utworzony w powyższym wpiscie template spakował się do 3.8GB. Dzięki sysprepowi można go w prosty sposób przenieść nawet na inną platformę sprzętową. Jeżeli dotrwałeś do końca tego wpisu to gratuluję - dla rozweselenia kotek: