Zarządzanie Microsoft Virtual Server

Wstęp

Zanim Hyper-v przyjmie się na co dzień, Virtual Server nadal pozostaje bardzo ważną usługą dla stworzenia środowiska wirtualnego – zapewne też długo jeszcze takim pozostanie nawet po premierze Hyper-v. Pracując z VS w pełnym środowisku produkcyjnym, aplikacją która na pewno pomoże jest System Center: Virtual Machine Manager. Aplikacja ta jednak jest płatna – co powoduje, że wiele osób, zwłaszcza tych, którzy traktują środowiska wirtualne w celach testowych, nie może skorzystać z oferowanych przez SC:VMM wspaniałości. Poza tym, czy opłaca się instalować tak potężną aplikację na stacji roboczej, aby raz na jakiś czas uruchomić maszynę wirtualną do wykonania testów?
Poniższy tekst jest przeznaczony głównie [acz nie tylko!] dla osób pracujących z maszynami wirtualnymi „na stacji roboczej” – co oznacza:

  • częste modyfikacje maszyn
  • potrzebę częstej wymiany danych pomiędzy stacją host a maszyną wirtualną
  • częste starty/wyłączenia maszyn
  • praca na dyskach dyferencyjnych

Artykuł przeznaczony jest dla osób już pracujących z VS/VPC od jakiegoś czasu. Dla początkujących lub dla uszeregowania wiedzy – polecam lekturę uzupełniającą w postaci WebCasta będącą wstępem do problemu wirtualizacji.

Virtual PC vs Virtual Server

W zasadzie można powiedzieć, że wyżej wymienione punkty charakteryzują VPC. To właśnie ten produkt zrobiony był z myślą o pracy do krótkich testów i pozwala na łatwą wymianę danych pomiędzy hostem a guestem , poprzez obsługę „przeciągnij-i-upuść” oraz możliwość podmapowania katalogu lokalnego hosta jako dysku sieciowego guesta. Szczegółowy spis różnic pomiędzy tymi dwoma platformami można znaleźć pod tym adresem . Oto krótki spis cech VS, których nie ma w VPC:

  • obsługa wielu procesorów
  • wielowątkowość
  • wsparcie do 3.6GB RAM per guest
  • wsparcie dla SCSI (łącznie ze współdzielonym SCSI)
  • zdalne zarządzanie
  • działanie jako usługa
  • obsługa via WMI (możliwość automatyzacji)
  • inne…

Są to cechy wysoko pożądane i wpływające na wydajność nawet niewielkiego środowiska wirtualnego. Architektura wieloprocesorowa oraz duża ilość pamięci jest codziennością i właśnie przy zastosowaniu maszyn wirtualnych ma to krytyczne znaczenie. Biorąc pod uwagę wszystkie zalety chciało by się móc korzystać z Virtual Server, zachowując funkcjonalność VPC.

VMRCplus

Podstawą czynnością jest „konfiguracja”. W przypadku VS mamy do dyspozycji interfejs web pozwalający na konfigurację środowiska wirtualnego oraz samych maszyn. Jest to niezbyt wygodne w codziennym użyciu – zwłaszcza w porównaniu do prostego i szybkiego Virtual PC. Dla tego polecam zacząć od instalacji Virtual Machine Remote Control client Plus (VMRCPlus). O ile narzędzie to nie jest doskonałe (nie można np. zarządzać zdalną maszyną jeśli nie jest się w tej samej domenie) to jest to nieporównywalnie przyjemniejszy sposób zarządzaniem VS. Ponad to, interfejs jest zbliżony logiką do SC:VMM co ułatwi „przesiadkę” w przyszłości.
W skrócie opisując VMRCPlus – jest to narzędzie, które pozwala na pełną konfigurację środowiska Virtual Server eliminując potrzebę korzystania z interfejsu Web. Jest przejrzyste, intuicyjne i znacząco ułatwia pracę z maszynami wirtualnymi.
Jednak nie stricte na funkcjach VMRCPlus chciałbym się skupić w tym tekście.

Wymiana plików i schowka

Najczęstszym scenariuszem, i najbardziej uciążliwym przy pracy z VS jest konieczność wymiany danych pomiędzy hostem i guestem – czy to pliki czy zawartość tekstu w schowku – ot głupi klucz seryjny podczas instalacji, czy plik programu instalacyjnego znajdującego się na dysku hosta.
Wymiana tekstu pomiędzy maszynami była możliwa już przy pomocy starszego narzędzia – VMRC, dostarczanego wraz z instalacją Virtual Server. I możliwość ta pozostała również w VMRCPlus szybko dostępna z konsoli lub z menu „Special -> Send Text to Virtual Machine”.
opcja “send text”

Większym problemem są pliki. Ponieważ VS nie wspiera ani opcji „przeciągnij-i-upuść” ani możliwości bezpośredniego podmapowania katalogu jako dysku sieciowego, jedynym sposobem jest upublicznienie [wyshare’owanie] katalogu i podmapowanie go z poziomu maszyny wirtualnej. Ponieważ obie maszyny są de facto oddzielnymi bytami, z zupełnie niezależna konfiguracją sieci, jest to często niemożliwe lub pracochłonne – nie można korzystać z wyizolowanej sieci dla maszyn wirtualnych, konfiguracja TCP/IP musi być zgodna, więc maszyna wirtualna musi być w tej samej podsieci. Podobny problem powstaje, gdyby chciało się zarządzać maszynami korzystając z Pulpitu Zdalnego . Podaję więc przepis na przygotowanie sobie środowiska, które pomoże ominąć ten problem i w efekcie pozwoli zarządzać wyłącznie przy pomocy VMRC/VMRCPlus.

Idea

Ideą jest takie przygotowanie środowiska dla maszyn wirtualnych, aby bez konieczności rekonfiguracji było można podmapować katalog hosta oraz w razie potrzeby połączyć się via RDP. Ponad to dyski maszyn muszą być przenaszalne.
Aby to osiągnąć trzeba utworzyć wirtualne połączenie sieciowe, które będzie pomostem pomiędzy hostem a guestem. Takim pomostem jest wirtualna karta sieciowa – Microsoft Loopback Adapter.

Przepis

  • krok 1 – wirtualna sieciówka
  • Aby utworzyć wirtualną kartę sieciową najlepiej skorzystać z managera urządzeń – najszybciej wpisać „devmgmt.msc” w pasku „run”. Teraz z menu „Action” należy wybrać opcję „Add legacy hardware” a następnie ze spisu wybrać urządzenie typu „Network Adapters”. Po odświeżeniu się listy dostępnych „sieciówek” należy wybrać „Microsoft Loopback Adapter” dostępny oczywiście w liście dla producenta „Microsoft”.
    add loopback 1
    add loopback 2
    Po ukończeniu dodawania urządzenia trzeba skonfigurować parametry TCP/IP. Najlepiej wybrać najrzadziej wykorzystywaną klasę – w moim przypadku wybór padł na 172.16.16.0/24. Konfiguracja DNS czy GW jest zupełnie zbędna. I tak nazwałem swoją wirtualną kartę „LocalLoop” i nadałem jest adres 172.16.16.16/24.

  • krok 2 – przygotowanie Virtual Servera
  • W następnym kroku należy utworzyć dodatkową sieć wirtualną, która będzie kanałem komunikacyjnym host-guest. Aby ułatwić sobie życie – warto dla tej sieci włączyć DHCP. Operacja nie jest skomplikowana:

  • uruchamia się widok „Virtual Networks”
    Tworzenie nowej sieci wirtualnej krok 1
  • pojawi się ekran pozwalający utworzyć nową sieć wirtualną (przycisk „Create”). Można skonfigurować nazwę, wybrać interfejs sieciowy, warto również dodać krótki opis, który ułatwi w przyszłości rozpoznanie sieci
    Tworzenie nowej sieci wirtualnej krok 2
  • na końcu warto włączyć i skonfigurować parametry DHCP [Rysunek 6 Ustawienie DHCP dla nowej sieci]
    Tworzenie nowej sieci wirtualnej krok 3

Po takiej konfiguracji pozostaje już tylko ostatni element – jak teraz skorzystać z tej konfiguracji na maszynie wirtualnej?

  • krok 3 – konfiguracja guesta
  • Poprzednie kroki mogą wydawać się nieco czasochłonne – w rzeczywistości jest to kilkanaście minut. Ostatni element to po prostu coś, co jeśli przyjmie się jako nawyk podczas tworzenia nowej maszyny – zajmie dodatkowe kilkanaście sekund, a konfigurację wcześniej opisywaną wykonuje się tylko raz. Niewiele więcej zajmie to dla istniejącej maszyny.
    Wystarczy teraz dodać dodatkowy interfejs sieciowy, zbindowany do interfejsu „LocalLoop” .
    Nowy interfejs dla maszyny wirtualnej
    W efekcie niezależnie od sieci podstawowej – czy będzie zamknięta, czy w zupełnie innej klasie – zawsze będzie można dostać się do hosta – zarówno po nazwie jak i wpisując (wedle przykładu) \172.16.16.16.
    Oczywiście wypadało by stworzyć jakiś katalog udostępniony [share] na dysku lokalnym hosta i sprawdzić czy firewall nie blokuje dostępu. Teraz różnica do VPC sprowadza się do skorzystania z polecenia „net use” z poziomu guesta zamiast mapowania z poziomu aplikacji.
    Ostatnią operacją o jakiej warto nie zapomnieć, jest wyłącznie autorejestracji adresu utworznego interfejsu sieciowego dla guesta, jeśli ten będzie dodawany do domeny – ma to znaczenie zwłaszcza, jeśli w przypadku, jeśli maszyna wirtualna będzie kontrolerem domeny.
    W tym celu należy:

    • wedytować właściwości interfejsu,
    • następnie przejść do konfiguracji protokołu TCP/IP [w wersji 4, 6 lub obu – zależnie z czego się korzysta],
    • przejść do właściwości zaawansowanych („Advanced”)
    • na zakładce „DNS” odznaczyć opcję „Register this connection’s addresses in DNS” jak pokazano na Rysunek 8 Opcja autorejestracji w DNS.

    Opcja autorejestracji w DNS

    Dyski dyferencyjne

    VMRCPlus ma jeszcze jedno bardzo poważne ograniczenie w stosunku do VPC – nie dysponuje narzędziem do zarządzania dyskami wirtualnymi. Jest co prawda narzędzie „Virtual Disks” dzięki któremu można założyć dowolny rodzaj nowego dysku, oraz sprawdzić właściwości istniejącego, nie ma jednak możliwości edycji. Podstawowym scenariuszem, kiedy jest to bolesne, jest zmiana położenia dysku macierzystego dla dysku dyferencyjnego. W przypadku VMRCPlus podczas próby uruchomienia maszyny z dyskiem dyferencyjnym, jeśli nie odnaleziony zostanie dysk macierzysty – zwrócony zostanie błąd, a informacja o konfiguracji zostanie usunięta. W takim przypadku Virtual PC automatycznie pyta o wskazanie nowej ścieżki – tutaj niestety nijak się tego zrobić nie da.
    Szczęśliwie istnieje możliwość modyfikacji właściwości plików vhd za pomocą skryptów (link1, link2). Zatem przedstawiam gotowy skrypt, który pozwoli zmodyfikować ścieżkę do dysku macierzystego:

    OPTION EXPLICIT
    'error handling is not necessary - script will fail with err description
    'ON ERROR RESUME NEXT

    CONST VHD_DIFFERENCING=2

    DIM oVS, oVHD, oParentVHD
    DIM strVHDfname, strParentVHDname, strLine
    DIM dVHDTypes

    if wscript.Arguments.count<>2 then
    wscript.echo "Wrong number of arguments."&vbCrLf&"Usage:"
    wscript.echo wscript.ScriptName&" mychildfile.vhd x:pathtoparent.vhd"
    wscript.quit
    end if

    set dVHDTypes=createObject("Scripting.Dictionary")
    dVHDTypes.add 0,"VHD_DYNAMIC"
    dVHDTypes.add 1,"VHD_FIXED"
    dVHDTypes.add 2,"VHD_DIFFERENCING"

    strVHDfname = WScript.Arguments.Item(0)
    strParentVHDname = WScript.Arguments.Item(1)

    Set oVS = CreateObject("VirtualServer.Application")
    set oVHD = oVS.GetHardDisk(strVHDfname)
    wscript.echo "VHD type: "&dVHDTypes.Item(oVHD.type)
    if oVHD.type <> VHD_DIFFERENCING then
    wscript.echo "this script changes parent of *differencing* disk. nothing to do."
    wscript.quit
    end if
    wscript.echo "VHD parent file: "&oVHD.parent.file

    wscript.echo "Are sure you want to change current parent to "&strParentVHDname&"? [type 'y' for yes]"
    if strComp(lcase(wscript.stdin.readline),"y")<>0 then
    wscript.echo "[parsed "&strLine&"] canceling..."
    wscript.quit
    end if
    set oParentVHD = oVS.GetHardDisk(strParentVHDname)

    if oVHD.type = VHD_DIFFERENCING then
    wscript.echo "Changing the parent VHD..."
    oVHD.Parent = oParentVHD
    end if
    wscript.echo "change succesfull."&vbcrlf&"checking... current parent file is:"
    set oVHD = oVS.GetHardDisk(strVHDfname)
    wscript.echo oVHD.parent.file

    Podsumowanie

    To prawda, że praca z Virtual Serverem może się na początku wydawać nieco toporna. Mam jednak nadzieję, iż zaprezentowane tricki pozwolą przygotować sobie środowisko i narzędzia tak, aby wykorzystać zalety VS, które są na tyle duże, że warto chwilę się pomęczyć ale zrezygnować z Virtual PC.

    -o((:: sprEad the l0ve ::))o-