Blog (66)
Komentarze (4.8k)
Recenzje (2)
@bachusVMWare: Część II — atak klonów

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

28.11.2015 23:31, aktualizacja: 30.11.2015 16:59

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 |

574843

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

574847

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:

574849

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

574851
574852

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":

574855

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):

574857
574858

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

574860

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

574862

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.

574864

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

574866

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

574868

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

574870

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:

574872

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ć:

574874
574875

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:

574880

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

574882
574883

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

574885

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...

574887

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]

574890

Aktualizacja, optymalizacja - taka sytuacja

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

574893

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:

574895

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

574897

Tu natomiast test uruchomiony bezpośrednio na VM:

574899

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:

574901
574902

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

574904
574905

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ł:

574908
574909

Ugraliśmy już ponad 8GB:

574911

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:

574913

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.

574915

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:

574917
574918

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:

574920
574921

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

574923

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:

574925

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

574927

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

574929

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.

574932

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

574934

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

574936
574937

Linked Clone

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

574940

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:

574942

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...

574946

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

574948

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

574950
574951

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

574953

Analogicznie tworzę drugą maszynę wirtualną:

574955

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:

574958

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:

574962

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:

574964

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

574969

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

574971

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":

574973

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ść:

574975
574976

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.

574980

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

574982
574983

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:

574986
574987

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

574989
574990

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:

574993
Wybrane dla Ciebie
Komentarze (7)