====== XEN: O dostępie do zasobów ======

Celem laboratorium jest zbadanie możliwości wpływania na wydajność gości przy użyciu mechanizmów udostępnianych przez hypervisor Xen.

===== Preliminaria =====

Proszę zalogować się na konto roota i wykonać następującą komendę:

<code bash>
cd /home/student/sitw && ./prepare_xen_lab3.sh && reboot
</code>

Po ponownym uruchomieniu komputera powinien włączyć się znajomy już Xen. Powinniśmy mieć dostępne dwie maszyny gości: ''lab2-pvm'' oraz ''lab2-pvhvm''.

**Zadanie 1:** Proszę stworzyć ([[https://ai.ia.agh.edu.pl/wiki/pl:dydaktyka:sitw:2016:xen:lab1#lekcja_7instalowanie_gosci|lab1]]), a potem zalogować się na obie maszyny (hasło ''xena'') i sprawdzić działanie połączenia internetowego (polecenie ''ping'').
**Podpowiedź:** Na maszynę wirtualizowaną sprzętowo trzeba logować się przez protokół ''vnc'', np.
<code bash>
vncviewer 127.0.0.1:<n-1> #dla n-tej maszyny
</code>
lub:
<code bash>
xl vnc <nazwa maszyny>
</code>
Może być konieczne zainstalowanie pakietu ''vncviewer'' ręcznie. 

W przypadku maszyny parawirtualizowanej, wystarczy zajrzeć do [[https://ai.ia.agh.edu.pl/wiki/pl:dydaktyka:sitw:2016:xen:lab1#lekcja_8sterowanie_goscmi|
lab 1]]. Jeżeli gość parawirtualizowany nie chce się uruchomić, narzekając na nieistniejący kernel, to znak, że kernel nie istnieje. Proszę sprawdzić jaką wersję kernela ma host (''uname'') i zmienić odpowiednią linię w pliku konfiguracyjnym maszyny (''/etc/xen/lab-pvm.cfg''). 

**Pytanie:** dlaczego trzeba było to zrobić?

**Przypomnienie:** hasło root'a to ''xena''.
==== Sekcja opcjonalna: SSH ====

Jeżeli dostęp po VNC jest zbyt niewygodny (niemożność kopiowania, etc.), to proszę skonfigurować na gościu ssh.

  * na gościu:
<code bash>
# instalujemy ssh
apt-get update
apt-get install ssh
# uruchamiamy ssh
systemctl start ssh
systemctl enable ssh
# podglądamy adres ip maszyny
ip addr show 
# sprawdzamy, czy istnieje w systemie użytkownik lab2
grep lab2 /etc/passwd
# jeśli nie, to go tworzymy
adduser lab2
# hasło też powinno brzmieć lab2
</code>
  * na gospodarzu:
<code bash>
# zapominamy o zaufanych adresach 
# na wypadek gdyby inna maszyna miała kiedyś ten sam adres
rm ~/.ssh/known_hosts 
# zastępujemy X odpowiednim numerkiem z adres
ssh lab2@10.0.0.X
# hasło: lab2
su
# hasło xena
# i już jesteśmy na koncie root
</code>

===== Lekcja 2: Sterowniki parawirtualne ======

Gość ''lab2-pvhvm'', jak dobrze pamiętamy, jest gościem sprzętowym, czyli tzw. pełną wirtualizacją. Mamy jednak do czynienia tutaj z pewnym oszustwem --- otóż gość ten zupełnie świadom tego, że jest uruchomiony w Xenie i używa specjalnych sterowników parawirtualnych. Skąd to wiemy? Standardowe (//vanilla// jądro linuksa od wersji ''2.6.36'' ma wbudowane sterowniki na takie okazje. 

**Zadanie 2:** Proszę sprawdzić numer jądra gościa (''man uname''). 

Ale nie musimy ufać zapewnieniom tego typu, możemy sami zobaczyć, jakie sterowniki zostały załadowane. Wystarczy zalogować się na gościa i sprawdzić, co powie polecenie ''dmesg''. Powinno mówić coś o urządzeniach PCI zarządzanych przez XEN.

**Zadanie 3:** Proszę sprawdzić, czy ''lab2-pvhvm'' używa sterowników parawirtualnych. Polecane: ''man grep'' i ignorowanie wielkości znaków.

Zainstalujmy zatem trzeciego gościa, który z takich sterowników nie korzysta. Aby przyśpieszyć pracę, proszę skopiować konfigurację maszyny ''lab2-pvhvm.cfg'' do pliku ''lab3-hvm.cfg'' i dokonać trzech zmian:

  * zmienić nazwę maszyny na ''lab3-hvm''
  * zmienić adres ip na ''10.0.0.4'':
    * żeby zmienić adres ip na zainstalowanym systemie należy dodatkowo:
      * zedytować na gościu plik: ''/etc/network/interfaces''
      * uruchomić komendę: ''/etc/init.d/networking restart''  
  * zmienić ścieżki dysków twardych
  * wyłączamy urządzenia PCI zarządzane przez Xen. Znowu zerkamy do [[https://xenbits.xen.org/docs/4.8-testing/man/xl.cfg.5.html|dokumentacji]].

Po skopiowaniu dysków twardych z poprzedniej maszyny do odpowiednich ścieżek, maszyna powinna się elegancko uruchomić. Teraz na uruchomionej maszynie zmieniamy jeszcze kilka szczegółów:
  * zmieniamy nazwę hosta:
    * zastępujemy starą nazwę na nową (''lab3-hvm'') w plikach:
      * ''/etc/hostname''
      * ''/etc/hosts''
    * ... i zrestartować usługi internetowe:
      * dla leniwych: restart maszyny
      * dla pracowitych:
<code bash>
invoke-rc.d hostname.sh start
invoke-rc.d networking force-reload
invoke-rc.d network-manager force-reload
</code>  

**Zadanie 4:** Proszę sprawdzić, czy nowy gość używa sterowników PV.

===== Lekcja 3: Benchmark DIY =====

Mając trzech gości, sprawdźmy, który z nich najlepiej sobie radzi w prostych benchmarkach. Przeprowadzimy kilka prostych testów (w razie potrzeby proszę instalować brakujące narzędzia używając ''apt-get'', wcześniejsze ''apt-get update'' może okazać się konieczne):

  * [cpu] jak szybko jesteśmy w stanie znaleźć liczby pierwsze:
<code bash>
sysbench --test=cpu --num-threads=<liczba procesorów> --cpu-max-prime=<duża liczba, np. 9999> run
</code>
  * [hdd] jak szybko potrafimy pisać do pliku:
<code bash>
dd bs=16k count=<tyle, żeby plik zajął około 1GB> oflag=direct if=/dev/zero of=test_data
</code>
  * [hdd] jak szybko potrafimy czytać z pliku:
<code bash>
dd bs=16K count=<tyle samo, co wcześniej> iflag=direct if=test_data of=/dev/null
</code>

**Zadanie 5:** Czy istnieje różnica w wydajności procesora między ''lab2-pvm'' i ''lab3-hvm''? Proszę spróbować uruchomić testy pojedynczo oraz naraz na obu maszynach.

**Zadanie 6:** Czy istnieje różnica w wydajności dysku twardego między ''lab2-pvhvm'' i ''lab3-hvm''? Proszę spróbować uruchomić testy pojedynczo oraz naraz na obu maszynach.




===== Lekcja 4: Scheduler CPU =====

Xen jako nadzorca musi dbać o zapotrzebowania swoich gości, w szczególności o przydzielany im czas procesora --- podobnie jak w systemie operacyjnym czas jest przydzielany procesom. Służy do tego narzędzie zwane schedulerem. W Xenie możliwe jest tworzenie pul procesorów (ang. //cpu pool//) i do każdej puli można przyporządkować inny scheduler. Krótkie opisy dostępnych schedulerów można znaleźć na [[https://wiki.xenproject.org/wiki/Xen_Project_Schedulers | wiki Xena]].

**Zadanie 7:** Używając komendy ''xl'' proszę sprawdzić jaki scheduler jest aktualnie używany w systemie.

Proszę teraz przeanalizować wyjście komendy:

<code bash>
xl help sched-credit
</code>

oraz [[https://wiki.xen.org/wiki/Credit_Scheduler|opis schedulera o nazwie credit z wiki Xen]].

Na potrzeby kolejnych pytań, zakładamy, że nasze maszyny mają za zadanie wykonać dużą liczbę ciężkich obliczeniowo zadań, np. służą do rozwiązywania problemów optymalizacyjnych.

**Zadanie 8**: Czy domyślny //timeslice// jest w porządku?

**Zadanie 9**: Proszę ustawić //rate limiting// tak, żeby odpowiadało środowisku małej liczby maszyn o dużej liczbie obliczeń do wykonania. 

**Zadanie 10**: Proszę teraz uruchomić testy CPU na wszystkich maszynach równocześnie i zapisać wyniki.

**Zadanie 11**: Proszę ustawić wagi schedulera tak, żeby maszyna ''lab2-pvhvm'' była "dwa razy" ważniejsza od innych.

**Zadanie 12**: Proszę ustawić ograniczenia tak, żeby żadna maszyna poza ''lab2-phvm'' nie mogła używać naraz więcej niż 1,5 rdzenia.

**Zadanie 13**: Proszę teraz ponownie uruchomić testy CPU na wszystkich maszynach równocześnie. Czy wyniki testów się zmieniły?

**Zadanie 14**: Proszę zmienić scheduler na ''credit2'' i ponownie przetestować działanie procesora.
**Podpowiedź**: konfiguracja ''gruba'' i [[https://xenbits.xen.org/docs/4.8-testing/misc/xen-command-line.html|docs/misc/xen-command-line.html]]

===== Lekcja 5: Stronicowanie pamięci =====

Gość, jak każdy system operacyjny, stronicuje pamięć ram. Niestety, nie możemy dać mu bezpośredniego dostępu do ramu, ponieważ mógłby wtedy ingerować w życie innych maszyn. Trzeba zatem w jakiś sposób tłumaczyć tablice pamięci gościa na prawdziwe tablice --- dla tego problemu istnieją dwa rozwiązana:

    * shadowing --- tablica LUT zarządzana programowo przez Xen, tłumacząca bezpośrednio wirtualne strony pamięci na rzeczywiste. Dzięki prostocie bardzo szybko obsługuje chybienia, natomiast dużo energii trzeba włożyć w utrzymaniu mapy pamięci na rozsądnym poziomie
    * hap --- hardware assisted paging, które korzysta z bardziej złożonych struktur, ale jest implementowane sprzętowo, dzięki czemu w bardzo szybki sposób obsługiwane są aktualizacje mapy pamięci. Problemem jest stosunkowo wolna obsługa chybień.

**Zadanie 15**: Proszę wyłączyć hap na jednej z maszyn ([[https://xenbits.xen.org/docs/4.8-testing/man/xl.cfg.5.html|dokumentacja xl.cfg]]).

Żeby przetestować prędkość ramu, trzeba uciec się do sztuczki, mianowicie można stworzyć partycję, która znajduje się w ramie, np.

<code bash>
mkdir RAM_test
sudo mount tmpfs -t tmpfs RAM_test/ 
cd RAM_test
</code>

Następnie w katalogu ''RAM_test'' używamy testów wcześniej używanych do testowania dysku twardego. 

**Zadanie 15**: Proszę przeprowadzić testy oparte o narzędzie ''dd''. Czy jest widoczna różnica między //shadowing// a //hap//?

===== Lekcja 7: Benchmark Professional =====

Poprzednie benchmarki badały w dość prosty sposób dostęp do niektórych zasobów. Istnieją bardziej profesjonalne narzędzia służące do bardziej ogólnego testowanie systemu jako takiego, np. [[https://github.com/kdlucas/byte-unixbench|UnixBench]]. Narzędzie to bada wiele elementów systemu i zwraca nam na koniec jedną liczbę: **System Benchmarks Index Score**. 

  * przed uruchomieniem ''UnixBench'' należy zainstalować kilka pakietów: ''libx11-dev libgl1-mesa-dev libxext-dev perl perl-modules make gcc''
  * uruchamiamy ''UnixBench'':

<code bash>
wget -O UnixBench.tar.gz http://ai.ia.agh.edu.pl/wiki/_media/pl:dydaktyka:sitw:2016:xen:unixbench.tar.gz
tar xf UnixBench.tar.gz
cd UnixBench
./Run
</code>
  
  
**Zadanie 16**: która maszyna ma najwyższy wynik SBIS?
===== Epilog: Sprzątanie =====

Proszę wyłączyć i usunąć wszystkich gości **wraz z ich dyskami i plikami konifuracyjnymi**. Następnie z konta roota: 

<code bash>
cd /home/student && rm -rf /home/student/sitw && tar xf ./sitw.tar.gz && cd /home/student/sitw && ./clean_xen_lab3.sh
</code>
I na koniec proszę **uruchomić komputer ponownie**, tym razem bez Xena i zaktualizować konfigurację gruba:
<code bash>
update-grub
</code>