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

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


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:

r   e   k   l   a   m   a
  • uruchamia się na zwykłym OS (Windows/Linux) i nie trzeba dedykować dodatkowego komputera,
  • przeogromne doświadczenie VMware w tym temacie,
  • elastyczna konfiguracja hypervizora i maszyn wirtualnych,
  • świetne opcje związane z migawkami, pracą z szablonami,
  • opcje, których ciężko uświadczyć w desktopowym Hyper-V, albo np. VirtualBox,
  • 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.

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

  • Wybór miejsca składowania danych VM
  • vHDD 120GB
  • (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:

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

  • Instalacja Windows 2012R2 z GUI:
  • Po 4-5 minutach (tyle trwa instalacja Windows 2012 na dysku SSD) instalacja VMware tools:
  • 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:

    A hypervisor has been detected. Features for Hyper-V will not be displayed."

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

    code=hypervisor.cpuid.v0 = "FALSE"

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

    vhv.enable = "TRUE"

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

     

    windows porady serwery

    Komentarze