Matrioszka, czyli Hyper-V pracujący pod kontrolą VMware Workstation

[img=Matrioszka]

Dzisiejszy wpis będzie dość hermetyczny, ale może kogoś zainteresuje - dotyczy on konfigurowania domowych "labów" i jednego z problemów z którym można się spotkać. Nie będę tu opowiadać, jak ważnym dla administratorów jest zagadnienie wirtualizacji - wszystko jest teraz do obrzydzenia "chmurą" i już nawet firmowa serwerownia to "private cloud" - sorry, taki mamy klimat... Z ostatnich tego typu smaczków językowych z jakim się spotkałem jest ten wymyślony przez CISCO w postaci "fog computing". Prawie tak dobre, jak ich akronimy technologii, które powstają od akronimów innych technologii... czapki z głów.

Zdaję sobie sprawę, że większość z czytelników doskonale zna wirtualizację i wpisy z tym związane to dla nich nuda i prościzna - po około 15 latach doświadczenia z ESX i Workstation (VMware), oraz po kilku latach pracy z Hyper-V (Microsoft) i liźnięcie AIX (IBM) jeszcze sporo mnie potrafi zaskoczyć. Wiedzę zdobywa się najlepiej praktykując - nie każdy ma takie możliwości, aby oddelegować dedykowany komputer na serwer wirtualizacji, szczególnie gdy czasem ich trzeba posiadać kilka sztuk - np. w celu przećwiczenia konfiguracji klastrów:

W domu głównie korzystam z VMware Workstation. Używam tego hypervizora z kilku powodów:

[item]uruchamia się na zwykłym OS (Windows/Linux) i nie trzeba dedykować dodatkowego komputera,[/item][item]przeogromne doświadczenie VMware w tym temacie,[/item][item]elastyczna konfiguracja hypervizora i maszyn wirtualnych,[/item][item]świetne opcje związane z migawkami, pracą z szablonami,[/item][item]opcje, których ciężko uświadczyć w desktopowym Hyper-V, albo np. VirtualBox,[/item][item]jest to po prostu dopracowany produkt i przy całym szacunku dla np. VirtualBox nie przejdzie tam np. "nested virtualization" (flaga VMX nie zostanie "przepuszczona do gościa), która jest tematem tego wpisu.[/item] W przypadku Microsoft i Hyper-V jest jeszcze ciekawiej - firma stara się wmówić, że jest inaczej, ale na dzień dzisiejszy raczej się nie da zmusić Redmontowego hypervizora do instalacji w nim np. drugiego Hyper-V:

Instalacja Hyper-V w VMware Workstaton

Podczas tworzenia nowej maszyny wirtualnej może już dać do myślenia wyraźne zaznaczenie w opcjach, że nie ma docelowo wsparcia dla Hyper-V, co jednak w teorii nie przeszkadza zainstalować zamiast tego Windows 2012 i dodać rolę hypervizora:

Ten wpis nie jest poświęcony zarówno optymalizacji i konfiguracji VMWare, jak i  Windows 2012, więc szczegóły samej instalacji ograniczę do minimum:

[item]Wybór miejsca składowania danych VM[/item][img=2_folderInstalacji]

[item]vHDD 120GB[/item](nie ma się co martwić o wielkość samego pliku, nie będzie zajmował więcej, niż 12‑15GB):

Co do samego "sprzętu" maszyny wirtualnej: [item]x2 vCPU (można dać więcej, ale w tym przypadku nie ma uzasadnionej potrzeby,[/item][item]pamięc ustawiona na 6GB (też nie zajmie fizycznie 6GB hosta),[/item][item]CD-ROM: podmapowany obraz system opearcyjnego (instalacja z ISO),[/item]Można też usunąć zbędne składniki: wsparcie dla karty dźwiękowej i drukarki.

[item]Instalacja Windows 2012R2 z GUI:[/item]

[item]Po 4‑5 minutach (tyle trwa instalacja Windows 2012 na dysku SSD) instalacja VMware tools:[/item][img=5_VMTools]

Po instalacji aktualizacji (Windows Update) przyszedł czas na dodanie roli Hyper-V:

No i tu właśnie zaczyna się cały problem: system operacyjny dostał sygnał od hypervisora, że działa w środowisku wirtualnym. Jest to to dla zwirtualizowanego OS dość przydatna wiedza, ponieważ pozwala na inne zachowanie i optymalizację działania / licencjonowania w środowisku wirtualnym:

Systeminfo (CMD -> systeminfo) w dwóch miejscach podaje tą informację:

Nas bardziej interesuje ta na samym końcu wyniku polecenia:

Trzeba więc spróbować "wmówić" wirtualnej maszynie, że jednak można zrobić "Matrioszkę ". Najpierw przekazanie do gościa (systemu zwirtualizowanego), że jest zainstalowany na "fizycznej" maszynie i że to "wcale nie są vCPU". Tego nie wyklika się z GUI, trzeba dodać komendę do pliku konfiguracji. Szukamy pliku o rozszerzeniu .VMX - informację o jego położeniu można uzyskać w kilku miejscach panelu VMWare, np. po najechaniu na samą maszynę:

Plik zawiera szczegółowe informacje dotyczące konfiguracji. Na końcu wystarczy dopisać dodatkową zmienną:

Dodatkowo należy dodać opcję: "Virtualize Intel VT‑x/EPT or AMD‑V/RVI" :

Odpowiada ona zaznaczeniu w GUI przy opcjach związanych z vCPU:

Po ponowym uruchomieniu wirtualnej maszyny z Windows 2012 i wydaniu polecenia systeminfo zaczyna to już wyglądać trochę lepiej:

Ponowna próba instalacji roli Hyper-V powinna nie sprawiać już problememów:

Po restarcie systemu pozostaje nam tylko testowa instalacja maszyny wirtualnej, której hypervizorem jest zwirtualizowany Hyper-V pracujący pod kontrolą WMware Workstation uruchomionego na Windows 7 :‑)

Podsumowanie

Niektórzy może uznają taką konfigurację za herezje i sztukę dla sztuki, jednak jak wspomniałem na początku może mieć to większy sens. Idąc tym schematem można zamiast Hyper-V zainstalować np. VMware vSphere 6.0, Xen, czy inne środowisko wymagające w teorii środowiska maszyny fizycznej.

W sytuacji, gdy temat wirtualizacji - np. optymalizacji VMware Workstation, organizacja labu, praca z szablonami i klonami może ułatwić życie ("linked-clone"), oraz jak np. zbudować działający klaster składający się z Hyper-V, kontrolera domeny i FreeNAS robiącego za CSVFS (iSCSI) jest dla Was ciekawy dajcie znać w komentarzach, chętnie o tym napiszę:

Wycinek z jednego z moich labów (mając przygotowany wcześniej szablok W2012 do zrobienia w godzinę: