WIRTUALIZACJA SYSTEMÓW OPERACYJNYCH Sławomir Wojciech Wojtczak

UNIWERSYTET ŁÓDZKI WYDZIAŁ MATEMATYKI I INFORMATYKI

WIRTUALIZACJA SYSTEMÓW OPERACYJNYCH Sławomir Wojciech Wojtczak ... znany takze˙ jako vermaden :) 118435/s

Praca wykonana pod kierunkiem dr Mariusza Jarockiego Łód´z2008 KATEDRA INFORMATYKI STOSOWANEJ Spis tre´sci

Wst˛ep 3

1 Wprowadzenie do wirtualizacji5 1.1 Podstawowe poj˛ecia...... 5 1.2 Standardowe działanie systemu operacyjnego...... 6 1.3 Emulacja...... 8 1.4 Wirtualizacja procesora...... 9 1.4.1 Hypervisor typu 1...... 10 1.4.2 Hypervisor typu 2...... 12 1.4.3 Parawirtualizacja...... 13 1.4.4 Pełna wirtualizacja...... 15 1.4.5 Wirtualizacja na poziomie systemu operacyjnego...... 16 1.4.6 Hybrydowa wirtualizacja...... 17 1.4.7 Partycje sprz˛etowe...... 17 1.5 Wirtualizacja pami˛eci...... 18 1.5.1 Shadow Page Table...... 20 1.5.2 Nested Page Table...... 21 1.5.3 Memory Overcommitment...... 22 1.6 Wirtualizacja operacji I/O...... 23 1.7 Rozszerzenia sprz˛etowewspieraj ˛acewirtualizacj˛e...... 28 1.7.1 AMD...... 29 1.7.2 Intel...... 33 1.7.3 VIA...... 37 1.7.4 Podsumowanie...... 37 1.8 Innowacje i nowe technologie...... 38 1.8.1 Sterowniki parawirtualne...... 39 1.8.2 SMP w systemach guest...... 39 1.8.3 NUMA...... 40 1.8.4 Cache Coherent NUMA...... 41 1.8.5 Topology Aware Scheduler...... 42 1.8.6 Zarz ˛adzanieenergi ˛ai skalowanie...... 44 1.8.7 Sprz˛etowaakceleracja graﬁki...... 45 1.8.8 Seamless Mode...... 48 1.9 Zalety...... 50 1.10 Wady...... 52 1.11 Zastosowania...... 53

1 2 Dost˛epnemaszyny wirtualne 55 2.1 Hypervisor typu 1...... 55 2.1.1 Xen...... 55 2.1.2 xVM...... 56 2.1.3 VMware ESX...... 57 2.2 Hypervisor typu 2...... 58 2.2.1 QEMU...... 58 2.2.2 VirtualBox...... 59 2.2.3 KVM...... 61 2.2.4 VMware Server...... 61 2.2.5 VMware Workstation...... 62 2.2.6 VMware Fusion...... 63 2.2.7 Parallels Desktop...... 63 2.2.8 Parallels Workstation...... 64 2.2.9 Parallels Server...... 64 2.2.10 Win4Lin / Win4BSD / Win4Solaris...... 65 2.3 Na poziomie systemu operacyjnego...... 66 2.3.1 FreeBSD Jails...... 66 2.3.2 Solaris Containers...... 67 2.3.3 Linux VServer...... 68 2.3.4 Linux OpenVZ...... 69 2.3.5 Parallels Virtuozzo Containers...... 70 2.3.6 User Mode Linux...... 71 2.3.7 Cooperative Linux...... 71 2.4 Emulatory...... 73 2.4.1 QEMU...... 73 2.4.2 Bochs...... 73

3 Wydajno´s´cmaszyn wirtualnych 74

4 Przyszło´s´cwirtualizacji 77

5 Podsumowanie 78

Technikalia 79

Bibliograﬁa 79

Spis rysunków 84

Indeks 84

2 Wst˛ep

Wirtualizacja systemów operacyjnych to temat szeroki i skomplikowany. Praca ta ma na celu zebranie i dogł˛ebneomówienie wszystkich aktualnie licz ˛acychsi˛erozwi ˛aza´ni nowych technologii w dziedzinie wirtualizacji. Omawia rózne˙ podej´scia,nowe rozwi ˛azaniajak i te sprawdzone, uzywane˙ od lat, daj ˛acpełny przekrój aktualnych mozliwo´sciw˙ tej dziedzinie informatyki. Wirtualizacja pozwala na wydajne działanie ”obcych” systemów operacyjnych na innym systemie, z wi˛eksz˛ab ˛ad´zmniejsz ˛aintegracj ˛a,a takze˙ na rozwi ˛azania stricte przeznaczone pod współdziałanie setek czy tysi˛ecysystemów operacyjnych. Omówione zostały wszystkie licz ˛acesi˛erozwi ˛azaniazwi ˛azanez wirtualizacj ˛a,zarówno darmowe jak i płatne z uwzgl˛ednieniemich zalet, wad oraz ogólnego zastosowania.

Wzrost zainteresowania wirtualizacj ˛a, ´zródłodanych Google Trends.

Juz˙ teraz wirtualizacja jest wykorzystywana na wielk ˛askal˛ei to praktycznie wsz˛edzie. Mnóstwo stron internetowych jest serwowanych na serwerach wirtualnych, wła´sniedzi˛eki wirtualizacji i rozwi ˛azaniomopisanym w niniejszej pracy. Z czasem wirtualizacja stanie si˛e jeszcze bardziej powszechna i niezauwazalna˙ zarazem, gdyz˙ ko´ncowyuzytkownik˙ w isto- cie wcale nie musi by´c´swiadom, ze˙ korzysta z jej dobrodziejstw. Stanie si˛etakze˙ bardziej ”przezroczysta”, gdyz˙ kolejne generacje procesorów wraz z rozszerzeniami nast˛epnejgeneracji jeszcze bardziej ułatwi ˛ajej stosowanie. Odpowiednio stosowania wirtualizacja pozwala na znaczne zmniejszenie kosztów stałych oraz tych zwi ˛azanychz infrastruktur ˛a.Pozwala na znaczne oszcz˛edno´scipr ˛adu,wi˛ecsprzyja ochronie ´srodowiska.

3 Wirtualizacja to tak naprawd˛eprzyszło´sćinformatyki, s ˛aoczywi´sciepewne dziedziny, w których (jeszcze) nie ma ona tak wielkiego znaczenia czy tez˙ praktycznego zastosowania, jednak z czasem b˛edziesi˛eto zmieniało na korzy´sćwirtualizacji. Postanowiłem wybraćwła´snie wirtualizacj˛ena temat mojej pracy magisterskiej, gdyz˙ dziedzina ta dostarcza zupełnie nowych mozliwo´scioraz˙ innowacyjnych rozwi ˛azań.Wirtualizacja zapewnia wiele ułatwieńi udogod- nień,zwłaszcza gdy korzystamy z wi˛ecejniz˙ jednego systemu operacyjnego, co w sumie nie jest w dzisiejszych czasach az˙ tak ˛arzadko´sci˛a.Poza tym jest to aktualnie najpr˛ezniej˙ rozwija- j ˛acasi˛egał ˛a´zinformatyki i najwi˛ecejsi˛etu dzieje.

Ponizej˙ zamieszczam krótkie omówienie kazdego˙ z rozdziałów pracy.

Rozdział 1: Wprowadzenie do wirtualizacji Podstawowe poj˛ecianiezb˛ednedo zrozumienia działania wirtualizacji, metody jej realizowania, rozszerzenia sprz˛etowewspieraj ˛acewirtualizacj˛e.Rozdział ten zawiera takze˙ omówienie nowych technologii, a na koniec przedstawia wady, zalety i zastosowania wirtualizacji.

Rozdział 2: Dost˛epnemaszyny wirtualne Dogł˛ebnieomawia dost˛epnena rynku rozwi ˛azania.Zostały one podzielone na kategorie w celu ułatwienia porównywania oferowanych przez nie funkcjonalno´sci. Dokładny opis uzy-˙ wanych technik i rozwi ˛aza´noraz sugerowane zastosowania.

Rozdział 3: Wydajno´sćmaszyn wirtualnych Mierzenie wydajno´scimaszyn wirtualnych jest trudne, czasochłonne i skomplikowane, rozdział ten omawia najcz˛e´sciejpopełniane bł˛edyprzy próbie porównywania róznych˙ rozwi ˛azańwirtu- alizacji. Zawiera takze˙ sugestie i wskazówki jak nalezy˙ porównywaćmaszyny wirtualne.

Rozdział 4: Przyszło´sćwirtualizacji Aktualnie istnieje mnóstwo nowych rozwi ˛azańw dziedzinie wirtualizacji, a w najblizszym˙ czasie powstanie ich jeszcze wi˛ecej,rozdział ten po krótce omawia w jakich kierunkach b˛edzie rozwijaćsi˛ewirtualizacja, zarówno w krótszej jak i długiej perspektywie.

Rozdział 5: Podsumowanie Podsumowanie zebranych informacji.

Dodatek Technikalia omawia szczegóły techniczne dotycz ˛acesamej pracy magisterskiej, ewentualnych problemów oraz narz˛edziuzytych˙ przy jej powstawaniu. Mam nadziej˛e, ze˙ niniejsza praca przyczyni si˛edo lepszego poznania i zrozumienia mechanizmów funkcjonowania wirtualizacji.

4 Rozdział 1

Wprowadzenie do wirtualizacji

1.1 Podstawowe poj˛ecia

Wirtualizacja to bardzo ogólne poj˛eciei aby dokładnie je wyja´snići zrozumiećnalezy˙ najpierw poznaćkilka podstawowych poj˛eć,dzi˛ekiktórym b˛edzieto mozliwe.˙ Jednocze´snie zakładam, ze˙ czytaj ˛acyt ˛aprac˛ezna podstawowe poj˛eciai zagadnienia zwi ˛azanez tematyk ˛a komputerow ˛ajak procesor czy pami˛eć które mozna˙ łatwo nadrobićw ´zródłachtakich jak choćby [Wales, 2001]. Mimo wszystko postaram sie wyja´snićwszystkie zagadnienia w mozliwie˙ na- jłatwiejszy do zrozumienia sposób, zgodnie z ide ˛aKISS 1.

Przez host b˛edziemyrozumie´ckomputer z systemem operacyjnym, b ˛ad´ztez˙ sam system operacyjny, na którym b˛edziemyuruchamia´cinne systemy operacyjne, przez guest za´skazdy˙ z systemów operacyjnych uruchomionych na systemie host. W przypadku systemu host termi- nologia ta odnosi si˛etez˙ do sytuacji, w której system host ma rol˛ezarz ˛adzaj˛ac˛a.

Z kolej system operacyjny to oprogramowanie, które zarz ˛adzasprz˛etemnaszego komputera, czyli procesorami, pami˛eci˛a,dyskami twardymi, kartami graficznymi i wszystkim innym co znajduje si˛ew tym pudle pod biurkiem w taki sposób, ze˙ mozemy˙ uruchamiaćna tymze˙ systemie najrózniejsze˙ aplikacje, takie jak Firefox i Winamp, czy tez˙ graćw gry i pra- cowaćw najrózniejszych˙ programach co przedstawia rysunek 1.1. Poj˛eciekomputer lub sprz˛et b˛edziemyzast˛epowaćrówniez˙ poj˛eciem hardware. Mówi ˛acbardziej technicznie system operacyjny zarz ˛adzapami˛eci˛a,procesami (czyli naszymi aplikacjami), plikami, poł ˛aczeniami sieciowymi oraz wieloma innymi aspektami zwi ˛azanymiz codzienn ˛aprac ˛akomputera.

Na rynku dost˛epnychjest bardzo wiele systemów operacyjnych, zarówno komercyjnych jak i systemów otwartych rozwijanych na wolnych licencjach pokroju GPL [Stallman, 1989], BSD [Computer Systems Research Group of the University of California, 1989] czy CDDL [Sun, 2004]. Nie b˛ed˛esi˛etutaj rozwodzićnad ich klasyfikacja i szufladkowaniem do odpowiednich kategorii, poza małymi wyj ˛atkamisa one ze sob ˛aniekompatybilne, co oznacza, ze jezeli˙ posi-

1Keep It Small and Simple 5 Rysunek 1.1: Schemat działania systemu operacyjnego. adamy program działaj ˛acyna jednym, to na drugim juz˙ go nie uruchomimy, chyba ze˙ skorzys- tamy z dobrodziejstwa jakie niesie wirtualizacja.

Mówimy tutaj oczywi´scieo kompatybilno´scibinarnej owych aplikacji, istnieje oczywi´scie mnóstwo aplikacji specjalistycznych takich jak serwery www, bazy danych i mnóstwa innych aplikacji które zostały przeportowane na cał ˛arodzin˛esystemów [Thompson, 1969], a cz˛esto nawet na systemy Windows, ale trzeba je najpierw zbudowa´cze ´zródeł.Bior ˛acpierwszy lepszy program działaj ˛acyw systemie X, nie b˛edzieon działał w systemie Y tak po prostu.

Wirtualizacja jest szczególnie przydatna, jezeli˙ korzystamy z systemu innego niz˙ system z rodziny Windows. Producenci wielu programów komercyjnych takich jak Adobe Photoshop czy 3D Studio MAX nie wydaj ˛awersji na inne systemy, a mimo iz˙ wolne oprogramowanie jak GIMP czy Blender dobrze sobie radz ˛ajako zamienniki, to jednak czasami po prostu jeste´smy zmuszeni do produktów komercyjnych. Czy to przez naszego szefa lub ﬁrm˛e,czy po prostu przez własne przyzwyczajenia i wyuczon ˛ajuz˙ obsług˛ejednego produktu, nie b˛edziemyprze- ciez˙ uczy´csie od nowa całej aplikacji gdy mamy projekt do zrobienia na wczoraj.

1.2 Standardowe działanie systemu operacyjnego

Zobaczmy jak zachowuje si˛esystem operacyjny na sprz˛ecienatywnie. Kazdy˙ system ma do wykorzystania cztery protection rings (uprzywilejowane pier´scienie).Numerowane s ˛aod 0 do 3. Kod, który działa w trybie ring 0 ma wszystkie uprawnienia, moze˙ bezpo´srednio ”roz- mawiać”ze sprz˛etem,w skrócie moze˙ robićze sprz˛etemwszystko. Tryb ring 3 przeznaczany jest zazwyczaj na tak zwany userspace (aplikacje), posiada najmniejsze uprawnienia i to tutaj wła´sniedziałaj ˛aaplikacje. System uprzywilejowanych pier´scienicharakteryzuje hierarchiczna budowa, która jest mechanizmem ochronnym zapewniaj ˛acymbezpieczeństwo, jest przedstaw- iona na rysunku 1.2.

Pozostałe dwa tryby, odpowiednio ring 1 oraz ring 2 s ˛astosunkowo rzadko wykorzysty-

6 Rysunek 1.2: Typowe wykorzystanie protection rings przez system operacyjny. wane, chociaz˙ nic nie stoi na drodze programistów aby je wykorzysta´c. Głównym powodem takiego wyboru jest to, iz˙ przeł ˛aczaniepomi˛edzytrybami nie jest zbyt wydajne. Innym powodem takiego post˛epowanias ˛arówniez˙ zalezno´scihistoryczne˙ zwi ˛azanez portowaniem kodu na inne architektury poniewaz˙ wiele procesorów obsługuje tylko dwa tryby, uprzywilejowany i nieuprzywilejowany, czyli odpowiednio ring 0 oraz ring 3. Mozna˙ równiez˙ spotka´csi˛ez nazewnictwem kernel mode dla trybu uprzywilejowanego oraz user mode dla trybu nieuprzywilejowanego. Inna sprawa, ze˙ według wielu ludzi tryby po´srednie nie s ˛awcale az˙ tak uzyteczne.˙

Ogromna wi˛ekszo´sćsystemów wykorzystuje mechanizm pier´scieniw nast˛epuj˛acysposób, j ˛adro systemu operacyjnego wraz ze sterownikami urz ˛adzeńdziała w najwazniejszym˙ i najbardziej uprzywilejowanym trybie ring 0, aplikacje uruchomione na tym systemie działaj ˛aw trybie ring 3, a pozostałe tryby ”lez˙ ˛aodłogiem”. W ten sposób napisana jest wi˛ekszo´sćsys- temów z rodziny UNIX, oraz systemy z rodziny Windows.

Dobrym przykładem na wyj ˛atekpotwierdzaj ˛acy reguł˛ejest tutaj system OS/2, który poza standardowymi trybami ring 0 oraz ring 3 uzywał˙ równiez˙ trybu ring 2 dla aplikacji z prawami dost˛epudo operacji I/O (wej´scia/wyj´scia).

Systemy operacyjne, które wykorzystuj ˛a microkernel (mikroj ˛adro), równiez˙ uzywaj˙ ˛atylko dwóch trybów, gdzie małe j ˛adro działa w trybie ring 0 (czasami mie´scisi˛enawet w pami˛eci L1 procesora), a serwery j ˛adraoraz sterowniki działaj ˛aw trybie ring 3 razem z aplikacjami. Przykładem takich systemów s ˛ana przykład QNX czy MINIX 3.

Mechanizm przechodzenia pomi˛edzypier´scieniami,zwany po prostu gates to specjalne bramki, które daj ˛azewn˛etrznemupier´scieniowidost˛epdo zasobów wewn˛etrznegopier´scienia w pewien zdefiniowany sposób. Implementacja mechanizmu czy tez po prostu systemu op- 7 eracyjnego, który w odpowiedni sposób wykorzysta bramki pomi˛edzypier´scieniamizapewni mu duze˙ bezpieczeństwo,sprawiaj ˛ac, ze˙ zarówno ´zlenapisane programy czy tez˙ sterowniki nie b˛ed˛apowodowały problemów na wysoko´scij ˛adra.W razie problemów czy to program czy tez˙ sterownik byłby po prostu restartowany, a w razie problemów po prostu wył ˛aczany. Dla przykładu przegl ˛adarka internetowa nie mogłaby uzyskaćdost˛epudo sieci bez odpowiedniego pozwolenia z zewn˛etrznegopier´scienia. Niestety wad ˛atakiego rozwi ˛azaniajest to, iz˙ mechanizm przeł ˛aczaniapomi˛edzypier´scieniaminie jest zbyt wydajny i powoduje dodatkowe opó´znienia.

1.3 Emulacja

Na koniec wyja´snijmyjeszcze czym jest emulacja systemu operacyjnego. Polega ona na stworzeniu wirtualnego ´srodowiska, które w praktyce dla systemu guest jest postrzegane jako kompletny komputer. Wszystkie elementy wirtualnego komputera s ˛aprogramowo emulowane, mi˛edzyinnymi takie jak CPU, RAM, HDD, GPU, BIOS i CD. Emulator, to wi˛ecnic innego jak kolejna aplikacja działaj ˛acaw trybie ring 3, co przedstawia rysunek 1.3. Potrzebuje on jednak o wiele wi˛ecejzasobów niz˙ typowa aplikacja aby realizowa´cswoje zadania z sensown ˛aszy- bko´sci˛a.

Rysunek 1.3: Emulator jest po prostu kolejn ˛aaplikacj ˛adziałaj ˛ac˛aw systemie.

Wielk ˛azalet ˛aemulacji jest mozliwo´s´cemulowania˙ systemów, które wymagaj ˛ainnej architektury sprz˛etowej niz˙ architektura systemu host, na przykład emulacja architektury Pow- erPC na najpopularniejszej aktualnie architekturze i386, było to swego czasu popularne dzi˛eki emulatorowi PearPC, który był wykorzystywany do uruchamiania systemu Mac OS X na systemach Windows. Aktualnie najpopularniejszymi aplikacjami, zapewniaj ˛acymiemulacj˛es ˛ana QEMU 2 oraz Bochs.

Niestety wielk ˛awad ˛aemulacji jest jej wydajno´s´c,a konkretnie jej brak. Guest jest cz˛esto wielokrotnie wolniejszy od systemu host. Z biegiem czasu zacz˛etoszuka´ccoraz to wyda- jniejszych sposobów na realizacje emulacji d ˛az˙ ˛acdo emulowania jak najmniejszej ilo´sciza-

2QEMU wraz z modułem kqemu moze˙ równiez˙ słuzyćjako˙ maszyna wirtualna 8 sobów wirtualnego ´srodowiska, a instrukcje guesta wykonywaćbezpo´srednio na systemie host. Z czasem pojawiło si˛ejeszcze wi˛ecejrozwi ˛azańmaj ˛acychna celu przyspieszenie dzi- ałania systemu guest i tu wła´snietutaj kończysi˛eemulacja a zaczyna wirtualizacja.

1.4 Wirtualizacja procesora

Wirtualizacja, podobnie jak emulacja, polega na stworzeniu na systemie host kompletnego wirtualnego ´srodowiska dla systemu guest, jednak uzywaj˙ ˛acdo tego specjalnych technologii lub tez˙ rozszerzeńsprz˛etowychi emulowaniu tylko tego czego nie da si˛ezrealizowaćsprz˛e- towo w celu zapewnienia jak najwi˛ekszejwydajno´scisystemu guest. W praktyce wydajno´sć wirtualizacji jest porównywalna z wydajno´sci˛asystemu host. Wad ˛atakiego rozwi ˛azaniajest, ze˙ systemy host i guest musz ˛amiećt ˛asam ˛aarchitektur˛esprz˛etow˛a.

Zgodnie z tez ˛apostawion ˛aw ”Formal Requirements for Virtualizable Third Generation Architec- tures” [Goldberg, 1974] czyli Formalnych Wymagańwobec Wirtualizowalnych Architektur Trzeciej Generacji wirtualizacja musi spełniaćpewne warunki. Maszyna wirtualna musi byćzdolna do wirtualizacji całego sprz˛etukomputera, jego zasobów, ł ˛aczniez procesorami, pami˛eci˛a,przechowywaniem danych oraz peryferiów. Za´s monitor maszyny wirtualnej jest oprogramowaniem, które zapewnia abstrakcj˛emaszynie wirtualnej. Za- miennym poj˛eciemdla monitora jest tez virtual machine monitor a w skrócie VMM. S ˛atrzy własno´sciktóre według Popeka/Goldberga musi spełniaćmaszyna wirtualna:

• Equivalence (równowazno´s´c)˙ - Program działaj ˛acypod kontrol ˛awirtualizacji powinien zasta´c´srodowisko identyczne jak w przypadku bezpo´sredniego działania na tym sprz˛e- cie.

• Resource Control (kontrola zasobów) - Monitor musi posiada´cpełn ˛akontrol˛enad wirtualizowanymi zasobami.

• Efficiency (wydajno´sć) - Instrukcje w wi˛ekszo´scimusz ˛abyćwykonywane bez inter- wencji monitora.

Popek/Goldberg okre´slaj˛arówniez˙ charakterystyk˛e ISA - Instruction Set Architecture (zestaw instrukcji) jakie fizyczna maszyna musi spełniaćaby byćmóc realizowaćwymienione wyzej˙ własno´sci. Charakterystyka zawiera procesor działaj ˛acyw trybach user mode i kernel mode oraz ma dost˛epdo jednolitej liniowo adresowanej pami˛eci,operacje I/O oraz przerwania nie

9 s ˛aemulowane.

Twórca systemu operacyjnego OpenBSD czyli Theo de Raadt podzielił si˛eswoimi prze- my´sleniamina temat bezpieczeństwawirtualizacji na architekturze x86. Dotyczy to takze˙ sep- aracji maszyn wirtualnych. Zgodnie z jego słowami, nie nalezy˙ traktowaćwirtualizacji jako lepszy mechanizm bezpieczeństwapoprzez dokładanie kolejnych warstw, gdyz˙ sama architektura x86 ze wzgl˛eduna swoj ˛abudow˛ei słaby mechanizm ochrony stron jest dosyćtrudna w obsłudze, wi˛ecłatwo popełnićbł˛edyprzy projektowaniu zwykłego systemu operacyjnego, a co dopiero przy mechanizmie, który pozwoli uruchamiaćkilka systemów operacyjnych na jednej maszynie. Ponizej˙ zamieszczam owy cytat z listy dyskusyjnej.

"x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can’t write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes. You’ve seen something on the shelf, and it has all sorts of pretty colours, and you’ve bought it."

Theo de Raadt

Hypervisor, zwany tez˙ cz˛esto virtual machine monitor (monitor maszyny wirtualnej) to programowe narz˛edzie,które pozwala na jednoczesne działanie wielu systemów operacyjnych na jednym ﬁzycznym komputerze. Kazdemu˙ z wirtualizowanych systemów ”wydaje si˛e” ze˙ maja bezpo´sredni dost˛epdo wszystkich zasobów komputera, chociaz˙ tak naprawd˛eto monitor kontroluje i zarz ˛adzawszystkimi zasobami. Udost˛epniaon te zasoby, dziel ˛acje pomi˛edzy uruchomione systemy guest.

Mozliwo´sciwirtualizacji˙ równiez˙ s ˛aograniczone do wykorzystania mechanizmu protection rings, wi˛ecw zalezno´sciod˙ tego jak jest ona realizowana, wykorzystuje ona rozne˙ pier´scienie owego mechanizmu. Jest to równiez˙ zalezne˙ od wykorzystania do tego celu rozszerze´nsprz˛e- towych komputera czy tez˙ nie.

1.4.1 Hypervisor typu 1

Hypervisor typu 1 zajmuje miejsce pomi˛edzysprz˛etemkomputera a systemami operacyjnymi guest, którym udost˛epnia zasoby sprz˛etowekomputera. Przedstawia go rysunek 1.4. Za- zwyczaj jeden z systemów jest uprzywilejowany i słuzy˙ jako domena zarz ˛adzaj˛acapozostałymi 10 systemami guest. Sam monitor działa w trybie ring 0, podczas gdy systemy guest działaj ˛a w przestrzeni ring 1, a aplikacje standardowo w trybie ring 3. Bez rozszerze´nsprz˛etowych rozwi ˛azanietakie pozwala jedynie na parawirtualizacj˛e, o której wi˛ecejw dalszej cz˛e´scitego rozdziału.

Rysunek 1.4: Schemat hypervisora typu 1 na procesorze bez obsługi monitor mode.

Jezeli˙ procesor posiada rozszerzenia sprz˛etowewspieraj ˛acewirtualizacje, to schemat wykorzystania pier´scieninieco si˛ezmienia. Rozszerzenia sprz˛etowedostarczaj ˛arówniez˙ dodatkowe tryby, root mode oraz non root mode. Kazdy˙ z tych trybów zawiera niezalezne˙ tryby ring 0-3, hypervisor typu 1 działa w trybie root mode, maj ˛acpełny dost˛epdo prawdziwego sprz˛etu, podczas gdy niezmodyﬁkowany guest działa w standardowych dla siebie trybach ring 0-3 w trybie non root mode, a jego dost˛epdo sprz˛etujest w pełni kontrolowany przez hypervisora.

Wirtualizacja wspierana sprz˛etowooferuje instrukcje, które wspieraj ˛abezpo´srednie odwoła- nia parawirtualizowanego guesta do hypervisora. W praktyce mozemy˙ to logicznie opisa´cw nast˛epuj˛acysposób, niezmodyﬁkowane systemy guest działaj ˛aw standardowych dla siebie przestrzeniach, czyli ring 0 dla j ˛adraoraz ring 3 dla userspace, a host działa w trybie ring -1 (minus jeden) b˛ed˛acwyzej˙ w hierarchii pier´scieni. Tryb ten zwany jest tez˙ zamiennie VMX root. Schemat takiego działania przedstawia rysunek 1.5.

Tryb który zapewniaj ˛arozszerzenia sprz˛etowezwany jest równiez˙ monitor mode. Guest tak naprawd˛enie wie, ze˙ ma do dyspozycji jedynie ograniczone kontrolowane przez hypervisora zasoby. Dzi˛eki temu hypervisor nie musi wykonywaćwielu skoków pomi˛edzytrybami ring 1 i ring 0 co znacznie zwi˛ekszawydajno´sćwirtualizacji. Inn ˛azalet ˛ajest to, ze˙ dzi˛ekiowym rozsz- erzeniom mozliwe˙ jest uruchamianie guestów bez ich modyfikacji, wi˛ecmozliwa˙ jest pełna wirtualizacja systemu guest.

11 Rysunek 1.5: Schemat hypervisora typu 1 na procesorze z obsług ˛a monitor mode.

1.4.2 Hypervisor typu 2

Hypervisor typu 2 zwany równiez˙ hosted hypervisor działa pod kontrol ˛asystemu operacyjnego jak kazda˙ inna aplikacja. W tym wypadku to system operacyjny pełni role hosta, maj ˛ac pod kontrol ˛acały sprz˛eti udost˛epniago jedynie hypervisorowi. Hypervisor cz˛e´sćinstrukcji wykonuje bezpo´srednio na procesorze hosta, jak kod kazdej˙ innej aplikacji, musi jednak mieć dost˛epdo przestrzeni j ˛adrasystemu hosta, co przewaznie˙ realizowane jest po prostu modułem j ˛adradla hypervisora. Emulowane s ˛atylko te elementy maszyn wirtualnych, których nie da si˛ezrealizowaćsprz˛etowo,ani tez bezpo´srednio na systemie hosta. Schemat tego typu hypervisora przedstawia rysunek 1.6.

Rysunek 1.6: Schemat hypervisora typu 2 na mechanizmie protection rings.

Jedn ˛az głównych metod realizowania wirtualizacji przez hypervisor typu 2 jest binary translation, czyli tłumaczenie instrukcji guesta w locie na instrukcje, które b˛ed˛awykonane bezpo´sred- 12 nio na procesorze za pomoc ˛asystemu host, z kolej bezpo´srednie wykonywanie instrukcji guesta na systemie host jak kod kazdej˙ innej aplikacji zwane jest direct execution (bezpo´srednie wykonywanie). Translacja odbywa sie pomi˛edzyinstrukcjami j ˛adraguesta, które rezyduje w trybie ring 1, a jadrem systemu host pracuj ˛acymw trybie ring 0. Aplikacje standardowo urz˛eduj˛a w trybie ring 3, zarówno hosta jak i guesta. Wiele hypervisorów w implementuje równiez˙ mechanizm pami˛ecipodr˛ecznejdla zapyta´nguesta, czyli tak zwane cache, co jeszcze bardziej usprawnia działanie guesta. Inn ˛arówniez˙ cz˛estostosowan ˛atechnik ˛ajest kompilacja just in time3, instrukcja jest kompilowana podczas jej pierwszego wywołania, a kazde˙ nast˛epnejej wywołanie powoduje jedynie ponowne uruchomienie juz˙ skompilowanej wersji.

Przyj˛ełosi˛euznawać, ze˙ hypervisor typu 2 realizuje wirtualizacj˛ejedynie przez mechanizmy jak binary translation czy direct execution. Istniej ˛ajuz˙ jednak rozwi ˛azaniajak KVM, które cał ˛a swoj ˛afunkcjonalno´sćopieraj ˛ana wykorzystaniu sprz˛etowychrozszerzeńwirtualizacji czyli AMD-V oraz VT-x, co wi˛ecejbez owych rozszerzeńnie b˛ed˛aw ogóle działać.

1.4.3 Parawirtualizacja

Słowo para pochodzi z j˛ezykagreckiego i znaczy dosłownie obok, a parawirtualizacja to nic innego jak jedna lub wiele maszyn wirtualnych działaj ˛acychobok systemu host. Parawirtual- izacja wykorzystuje hypervisor typu 1, monitor działa bezpo´srednio na sprz˛ecieudost˛epniaj˛ac go (lub nie) systemom guest. Jeden z wirtualizowanych systemów jest uprzywilejowany i pełni rol˛ezarz ˛adzaj˛ac˛a,moze˙ rozdziela´czasoby pomi˛edzypozostałe systemy guest i ma pełn ˛akontrol˛enad maszyna wirtualn ˛ai jej zasobami. Schemat działania parawirtualizacji przedstawia rysunek 1.7.

Rysunek 1.7: Parawirtualizacja oraz pełna wirtualizacja przy uzyciu˙ hypervisora typu 1.

Parawirtualizacja nie rózni˙ si˛eaz˙ tak bardzo od techniki binary translation. Mechanizm binary translation tłumaczy odpowiednie instrukcje systemu guest w locie na odwołania hyper-

3Zwana tez˙ czasami jako dynamic recompilation. 13 visora (inaczej hypercall) podczas gdy parawirtualizacja robi to samo, tylko na poziomie kodu ´zródłowego. Oczywi´sciemodyfikacja kodu daje o wiele wi˛ecejmozliwo´sci,miedzy˙ innymi eliminacje niepotrzebnych odwołańsystemu guest. Poza tym translacja w locie musi odbywać si˛eszybko, wi˛ec nie moze˙ posiadaćzbyt kompleksowej implementacji gdyz˙ nie b˛edziezapew- niała odpowiedniej wydajno´sci.

Aby system mógł byćuruchomiony jako guest za pomoc ˛aparawirtualizacji, trzeba zmody- fikowaćjego j ˛adro tak, aby zamiast odwołańdo sprz˛etuczy tez˙ standardowych odwołań tego systemu, które nie s ˛adozwolone podczas parawirtualizacji, uzywał˙ odwołań hypercall bezpo´srednio do hypervisora. Dotyczy to odwołańdo pami˛eci,obsługi przerwań,operacji I/O i wielu innych rzeczy. Odwołanie hypercall to nic innego jak wywołanie systemowe systemu guest, z z˙ ˛adaniempewnych zasobów lub tez zmian od hypervisora. Idea jest taka sama jak przy zwykłym odwołaniu systemowym syscall do j ˛adrasystemu operacyjnego. Odwoła- nia hypercall to po prostu interfejs pomi˛edzymonitorem a systemami guest. Mechanizm ten zapewnia bardzo dobra wydajno´sć,zblizon˙ ˛ado natywnego działania systemu.

Zalet ˛aparawirtualizacji jest bardzo dobra wydajno´sćsystemów guest oraz to, iz˙ stosunkowo łatwo jest zmodyfikowaćj ˛adro systemu guest aby przystosowaćgo parawirtualizacji, nie trzeba tez uzywaćmechanizmu˙ binary translation który jest dosyćtrudny w implementacji, a jego prostsze implementacje nie zapewniaj ˛atak duzej˙ wydajno´sci.Jej wad ˛ajest wła´snieowa konieczno´sć modyfikacji systemu guest, poniewaz˙ nie zawsze jet to mozliwe.˙ Systemy, których ´zródłanie s ˛a dost˛epnenie mog ˛abyćzmodyfikowane. Dodatkowo modyfikacja j ˛adraniesie za sob ˛apewne koszty zwi ˛azanez dostosowaniem systemu guest do danego hypervisora i musimy t ˛aprocedur˛eponowićdla kazdego˙ innego hypervisora.

VMI (Virtual Machine Interface)

Implementacja parawirtualizacji w postaci VMI (czyli Virtual Machine Interface) to interfejs komunikacji pomi˛edzysystemem guest a hypervisorem zaproponowany przez VMware, z czasem specyfikacja została otwarta. Mozna˙ powiedzieć, ze˙ VMI to po prostu próba ujed- nolicenia interfejsu dla wirtualizacji. Celem tego posuni˛eciabyło takze˙ stworzenie jednego interfejsu komunikacji, który mógłby byćzaimplementowany na wielu hypervisorach i byłby w miar˛ełatwy do implementacji na systemach guest. Specyfikacja VMI mówi o nast˛epuj˛acych celach:

• przeno´sno´s´c - interfejs powinien by´cłatwy do zaadoptowania w systemach guest.

• wydajno´sć - implementacja musi zapewniaćdobr ˛awydajno´sć.

• konserwacja - upgrade i zarz ˛adzaniesystemem guest powinno by´cproste i łatwe.

• rozszerzalno´sć - API powinno byćskonstruowane w taki sposób aby mozna˙ było je w przyszło´scirozszerzyćw prosty sposób. 14 Aktualnie interfejs VMI działa z j ˛adrem Linux 2.6, w przyszło´sciVMware ma nadzieje na oficjaln ˛aadopcje/implementacje ich interfejsu przez wszystkie licz ˛acesi˛esystemy z rodziny UNIX, takie jak BSD, Solaris, Darwin. Zalet ˛aVMI jest fakt, ze˙ implementacja ta nie jest przyp- isana do tylko jednego hypervisora oraz to, ze˙ jest otwarta. Implementacja systemu guest raz dałaby mozliwo´sćuruchomienia˙ go we wszystkich licz ˛acychsi˛ehypervisorach.

1.4.4 Pełna wirtualizacja

Pełna wirtualizacja pozwala na wirtualizowanie dowolnego niezmodyfikowanego systemu operacyjnego. Jest to z pewno´sci˛anajwi˛ekszazaleta pełnej wirtualizacji poniewaz˙ nie narzuca nam zadnych˙ ograniczeńani wymagańco do systemu guest. Wydajno´sćtakiego rozwi ˛azania niestety jest nieco mniejsza niz˙ w przypadku parawirtualizacji. Pełna wirtualizacja moze˙ być realizowana zarówno za pomoc ˛ahypervisora typu 1 jak i typu 2.

Głównym wyzwaniem dla pełnej wirtualizacji jest przechwytywanie i realizowanie uprzywilejowanych instrukcji j ˛adraguesta, jak na przykład operacji I/O, przerwańczy operacji na pami˛eci.Wi˛ekszo´sćinstrukcji systemu guest moze˙ byćwykonana bezpo´srednio na procesorze przez hypervisora, ale te instrukcje, które wychodz ˛apoza uprawnienia systemu guest, czy tez˙ odwołuj ˛asi˛edo sprz˛etu,musz ˛abyćprzechwycone i emulowane.

W przypadku uzycia˙ hypervisora typu 1 wymagane s ˛aodpowiednie rozszerzenia sprz˛e- towe umozliwiaj˙ ˛acewirtualizacj˛e,takie jak AMD-V czy Intel VT-x, zostan ˛aone opisane dokład- niej w jednym z kolejnych podrozdziałów. Schemat działania jest tutaj taki sam jak w przypadku parawirtualizacji, co przedstawia rysunek 1.7. Pełna wirtualizacja okre´slanajest tez˙ zamiennie poj˛eciami natywna wirtualizacja oraz wirtualizacja wspierana sprz˛etowo.

Jezeli˙ za´sdo pełnej wirtualizacji uzyjemy˙ hypervisora typu 2, to b˛edzieona realizowana przez mechanizmy takie jak binary translation oraz direct execution, cz˛estoze wsparciem pami˛eci podr˛ecznejowych translacji w postaci cache, mozna˙ tez uzy´cmechanizmu˙ kompilacji instrukcji just in time. Drugi przypadek prezentuje rysunek 1.8.

15 Rysunek 1.8: Pełna wirtualizacja realizowana za pomoc ˛ahypervisora typu 2.

1.4.5 Wirtualizacja na poziomie systemu operacyjnego

Wirtualizacja na poziomie systemu operacyjnego czyli OS level virtualization w przeciwieńst- wie do poprzednich metod nie uzywa˙ hypervisora. System guest jest zawsze dokładnie taki sam jak system host, co wi˛ecejzarówno host jak i wszystkie wirtualizowane systemy guest korzystaj ˛abezpo´srednio z j ˛adrasystemu host. Mozemy˙ nawet powiedzieć, ze˙ uzywaj˙ ˛atego samego j ˛adra,jednak nie wszystkie z takim samym dost˛epemjak system host. Systemy guest, tak jak w kazdym˙ innym modelu wirtualizacji s ˛aoczywi´scieodseparowane zarówno od siebie jak i od systemu host. Kazdy˙ z wirtualizowanych systemów guest jest jedynie replikacj ˛astruk- tury systemu host, mniej lub bardziej zmodyfikowan ˛a.Schemat tej metody przedstawia rysunek 1.9.

Rysunek 1.9: Schemat wirtualizacji na poziomie systemu.

Podej´scieto posiada wiele unikalnych zalet w porównaniu do poprzednich rozwi ˛aza´n. W przypadku klasycznej wirtualizacji kazdy˙ z systemów guest przy uzyciu˙ hypervisora komunikuje si˛eze sprz˛etemprzez specjaln ˛awarstw˛eabstrakcji powoduj ˛acdodatkowy narzut i opó´znienie.Sprawia to, ze˙ im wi˛ecejmaszyn wirtualnych mamy uruchomionych, tym wi˛ecej zasobów jest zuzywanych˙ jedynie na sam ˛awarstw˛eabstrakcji i komunikacj˛eze sprz˛etem.W przypadku wirtualizacji na poziomie systemu operacyjnego wszystkie te problemy nie istniej ˛a poniewaz˙ kazdy˙ z systemów guest korzysta bezpo´srednio z zasobów komputera w taki sam sposób jak system host. Oczywi´sciedzieje si˛eto za przyzwoleniem systemu host. Rozwi ˛azanie to powoduje, ze˙ systemy guest s ˛apraktycznie identycznie wydajne jak system host.

16 Mówi ˛acinaczej j ˛adro systemu host pozwala na uruchomienie wielu niezaleznych˙ instancji userspace. Istnieje wiele konwencji nazw dla tego typu wirtualizacji, niektóre z nich to containers czyli tak zwane kontenery, mozna˙ spotka´csi˛etez˙ z okre´sleniem virtual environment czyli wirtualne ´srodowisko. Mechanizm wirtualizacji na poziomie systemu jest logicznym i funkcjon- alnym rozwini˛eciemfunkcjonalno´sci chroot z systemów UNIX, z reszt ˛ato wła´sniegłównie na tych systemach tego typu wirtualizacja wyst˛epuje. Współczesne implementacje tego typu wirtualizacji zapewniaj ˛aoczywi´sciezarz ˛adzaniezasobami systemów guest, ustawianie prio- rytetu dla kazdego˙ z systemów oraz limity czasu procesora i pami˛eci.

1.4.6 Hybrydowa wirtualizacja

Zarówno pełna wirtualizacja jak i parawirtualizacja posiadaj ˛aswoje wady i zalety. Pełna wirtualizacja pozwala na uruchamianie praktycznie kazdego˙ systemu operacyjnego bez konieczno´sci jego modyfikacji jednak cierpi na tym wydajno´sć. Parawirtualizacja z kolej zapewnia bardzo dobr ˛awydajno´sćzblizon˙ ˛ado natywnej, jednak wymaga odpowiedniego przystosowania systemu operacyjnego do odwołańhypervisora. Technik ˛aktóra stara si˛ewykorzystaćzalety wyzej˙ wymienionych technik przy okazji omijaj ˛acich wady jest hybrydowa wirtualizacja.

Technika ta polega na tym, ze˙ system guest działa na zasadzie pełnej wirtualizacji, jednak posiada zainstalowane odpowiednie parawirtualizowane sterowniki do urz ˛adzeń.Sprawia to, ze˙ dost˛epdo sprz˛etunie cierpi z powodu dodatkowego narzutu. Podej´scietakie nie wymaga równiez˙ modyfikacji systemu guest oraz zapewnia bardzo dobr ˛awydajno´sć. Parawirtuali- zowane sterowniki uzywane˙ s ˛ado operacji I/O oraz obsługi przerwań.

1.4.7 Partycje sprz˛etowe

Całkiem inne podej´sciew stosunku do juz˙ poznanych oferuj ˛a partycje sprz˛etowe zwane tez˙ hardware partitions. Rozwi ˛azanieto polega na podzieleniu zasobów sprz˛etowychna partycje. Na kazdej˙ takiej partycji mozemy˙ uruchomićdowolny niezmodyfikowany system operacyjny. Kazda˙ z partycji zachowuje sie jak kompletny komputer z procesorem, pami˛eci˛a,operacjami I/O czy sieci ˛a.Niektórzy producenci sprz˛etudo tego typu wirtualizacji jak HP oferuj ˛anawet rozwi ˛azaniapozwalaj ˛acena dostarczenie osobnego ´zródłazasilania dla kazdej˙ partycji. Party- cje sprz˛etowes ˛atez˙ zamiennie nazywane poj˛eciami server entity czy tez˙ logical domain. Partycje 17 sprz˛etowerealizowane s ˛aprzez firmware sprz˛etu,czyli niskopoziomowy program działaj ˛acy bezpo´srednio na sprz˛ecie,jak BIOS płyty głównej na przykład. Podział zasobów pomi˛edzy okre´slonepartycje odbywa si˛eza pomoc ˛aspecjalnej konsoli, któr ˛amozemy˙ tez˙ uruchomić przez sieć.Schemat partycji sprz˛etowychprzedstawia rysunek 1.10.

Rysunek 1.10: Schemat działania rozwi ˛azania hardware partitions.

Ogólnie uwaza˙ si˛e, ze˙ partycje sprz˛etowe b˛ed˛auzywane˙ coraz rzadziej i powoli odejd ˛aw za- pomnienie. Najprawdopodobniej stan ˛asi˛epo prostu drogim wyspecjalizowanym rozwi ˛azaniem dla w ˛askiegogrona odbiorców, jak na przykład banki i wojsko. Rozwi ˛azanietakie posiada tez˙ pewne ograniczenia, na przykład ilo´sćuruchomionych systemów w tym samym czasie jest ograniczona do minimum jednego procesora na system. Jezeli˙ mamy wi˛ecserwer z 32 procesorami to b˛edziemymogli uruchomićw najlepszym przypadku 32 systemy operacyjne. Ist- niej ˛arozwi ˛azaniapozwalaj ˛acena dzielenie procesorów pomi˛edzypartycje, jednak stanowi ˛a one mniejszo´sć.

Rozwi ˛azanietakie jest bardzo nieefektywne. Serwery przez wi˛eksz˛acz˛e´sćczasu mimo wszystko pozostaj ˛abezczynne, w przypadku wirtualizacji ma to o tyle znaczenie, ze˙ podczas gdy niektóre systemy ”nudz ˛asi˛e”inne wykorzystuj ˛awszystkie przydzielone im zasoby. Party- cje sprz˛etowenie pozwalaj ˛aaby wiele systemów współdzieliło zasoby tego samego procesora a co za tym idzie, wiele zasobów i pr ˛aduzostanie zmarnowane, a przeciez˙ jedn ˛az celów wirtualizacji jest konsolidacja serwerów. Do zalet partycji sprz˛etowychmozna˙ i trzeba zaliczyćjed- nak w pewnym sensie pewno´sćtakiego rozwi ˛azania. Zadne˙ oprogramowanie nie jest wolne od bł˛edów, a bug w hypervisorze moze˙ zawiesićdziałanie wszystkich maszyn wirtualnych. Kazda˙ z partycji jest zupełnie niezalezna˙ od pozostałych partycji, jednak firmware to równiez˙ swego rodzaju oprogramowanie i tam tez˙ mog ˛awkra´sćsi˛ebł˛edy.

1.5 Wirtualizacja pami˛eci

Poza wirtualizacj ˛aprocesora kluczowa jest takze˙ odpowiednia wirtualizacja pami˛eci. We współczesnych systemach operacyjnych najcz˛estszymrozwi ˛azaniemw dziedzinie zarz ˛adza- 18 nia pami˛ecijest virtual memory czyli pami˛ećwirtualna. Jedynym wyj ˛atkiemod tej reguły s ˛aniek- tóre systemy czasu rzeczywistego RTOS czyli real time operating system dla których najwi˛eksze znaczenie maj ˛ajak najmniejsze opó´znienia. Pami˛ećwirtualna to technika, która daje aplikacjom złudzenie ze maj ˛adost˛epdo zunifikowanej przestrzeni adresowej, chociaz˙ ”pod mask ˛a”moze˙ byćto kilka oddzielnych modułów pami˛ecio róznych˙ rozmiarach oraz plik wymiany na dysku twardym. Schemat pami˛eciwirtualnej przedstawia rysunek 1.11.

Rysunek 1.11: Schemat działania pami˛eciwirtualnej.

W sytuacji gdy na komputerze działa jeden system operacyjny ﬁzyczne adresy pami˛ecisa tłumaczone na adresy wirtualne (oraz na odwrót) przez układ memory management unit (w skrócie MMU). Pami˛e´cjest dzielona na strony (inaczej pages) o pewnym ustalonym rozmiarze i w ten sposób przydzielana odpowiednim aplikacjom przez system operacyjny. Schemat dzi- ałania MMU przedstawia rysunek 1.12.

Rysunek 1.12: Schemat działania układu memory management unit.

Dawniej, w starszych generacjach procesorów stronicowanie (czyli paging) odbywało si˛e przewaznie˙ jedynie za po´srednictwem page table (inaczej tablica stron). System przechowuje informacje o wolnych i uzywanych˙ ramkach w tablicy stron, która słuzy˙ do translacji adresów logicznych na ﬁzyczne. Schemat działania tego rozwi ˛azaniaprzedstawia rysunek 1.13.

Aby przyspieszyćow ˛atranslacj˛estosuje si˛edodatkowe rozwi ˛azaniezwane translation lookaside buffer (w skrócie TLB). Bufor ten słuzy˙ jako pami˛ećpodr˛eczna cache w postaci tablicy asocjacyjnej dla ostatnio uzywanych˙ stron pami˛eci. Układ TLB przyspiesza cały proces 19 Rysunek 1.13: Schemat translacji przy uzyciu˙ page table. translacji poniewaz˙ od razu otrzymujemy adres potrzebnej strony w pami˛ecifizycznej, dodatkowo tłumaczenie adresów odbywa si˛eniezaleznie˙ od standardowej procedury translacji. Jezeli˙ z˙ ˛adanegoadresu nie ma w buforze TLB, wtedy adres fizyczny jest uzywany˙ do odnalezienia poszukiwanych danych w pami˛eci.Mówi ˛acogólnie aktualny adres strony jest przechowywany w rejestrze CR3 procesora czyli tak zwanym hardware page table pointer a najcz˛e´sciejuzywane˙ strony przechowywane w buforze TLB. Schemat działania bufora TLB przedstawia rysunek 1.14. W dzisiejszych czasach kazdy˙ nowy procesor posiada układ TLB.

Rysunek 1.14: Schemat translacji przy uzyciu˙ bufora TLB.

Wiemy juz˙ w jaki sposób pami˛ećjest uzywana˙ w przypadku gdy na komputerze system operacyjny działa samodzielnie. Czas poznaćna jakie sposoby jest ona wykorzystywana w przypadku wirtualizacji. System guest oczekuje standardowej pami˛eciadresowanej od zera, jak w przypadku natywnego działania. Zarz ˛adzaniewirtualn ˛apami˛eci˛adla systemów guest nie rózni˙ si˛egeneralnie od zarz ˛adzaniapami˛eci˛awirtualn ˛aw dzisiejszych systemach operacyjnych. Jest to po prostu ci ˛agłaprzestrzeńadresowa, która jest logicznie powi ˛azanaz mod- ułami pami˛ecizamontowanymi w komputerze. System operacyjny przechowuje mapowanie wirtualnych numerów stron do stron fizycznych w specjalnych tablicach. Maszyna wirtualna za´sjest odpowiedzialna za mapowanie pami˛ecisystemów guest na fizyczn ˛apami˛ećkomput- era.

1.5.1 Shadow Page Table

W przypadku wirtualizacji fizyczna pami˛ećdzielona jest pomi˛edzyposzczególne systemy guest oraz system host. Sam hypervisor równiez˙ alokuje pami˛ećna własny uzytek˙ oraz rozdziela j ˛apomi˛edzysystemy guest i host. Wyst˛epujetu jednak pewien problem natury technicznej, 20 problem dwustopniowej translacji adresów w przypadku wirtualizacji. System guest otrzymuje od hypervisora pewien obszar pami˛ecii zarz ˛adzanim wedle własnego uznania. Z drugiej strony nie jest to obszar przydzielony bezpo´srednio w pami˛eci,lecz jedynie w pami˛ecihypervi- sora, który to z kolej przydziela t ˛apami˛ećz pami˛ecifizycznej komputera. Zachodzi wiec problem podwójnego kopiowania obszarów pami˛ecico jest niestety nie po drodze z wydajno´sci˛a. Rozwi ˛azanieto nosi nazw˛e shadow page table. Jest to nic wi˛ecejjak emulowanie jednostki MMU przez hypervisor. W takim rozwi ˛azaniusystemy guest otrzymuj ˛awirtualny emulowany rejestr CR3 przez który maja dost˛epdo pami˛eci.Technik˛e shadow page table przedstawia rysunek 1.15.

Rysunek 1.15: Schemat mechanizmu shadow page table.

1.5.2 Nested Page Table

Rozwi ˛azaniemtego problemu jest sprz˛etowawirtualizacja jednostki MMU w buforze TLB, rozwi ˛azanieto nosi nazw˛e nested page table. System host posiada swój rejestr CR3 czyli host CR3 a systemom guest udost˛epnianyjest rejestr guest CR3. Przez mapowanie pami˛ecisystemy guest mog ˛aprzydzielaćpami˛ećbezpo´srednio w pami˛ecikomputera i nie cierpi na tym wydajno´sć.Taki bufor TLB posiada specyficzn ˛aflag˛ezwan ˛a Address Space Identifier, która wskazuje, do którego systemu guest nalezy˙ dany obszar pami˛eci.Rozwi ˛azanieto nazywane jest tez˙ zamiennie jako Tagged TLB. Inna zalet ˛atego rozwi ˛azaniajest to, ze˙ im wi˛ecejsystemów guest działa na raz, tym wi˛ecejzyskujemy na wydajno´sci.Procesor musi po prostu zsynchronizowaćbufor TLB tak samo jakby działo si˛eto natywnie bez wirtualizacji. Analogiczne, wirtualizacja przy braku owej wirtualizacji w buforze TLB działa wolniej z kazdym˙ kolejnym wirtualizowanym systemem guest. Technik˛e nested page table przedstawia rysunek 1.16.

Sprz˛etowawirtualizacja jednostki MMU w buforze TLB mimo wszystkich dobrodziejstw jakie ze sob ˛aniesie posiada równiez˙ jedn ˛awad˛e. Rozwi ˛azanie nested page table komplikuje

21 Rysunek 1.16: Schemat mechanizmu nested page table. cał ˛aprocedur˛estandardowej translacji adresu jezeli˙ nie ma go w tablicy. Musimy wykona´c czterokrotnie wi˛ecejkroków podczas takiej translacji niz˙ w przypadku braku sprz˛etowejwirtu- alizacji jednostki MMU. Istnieje jednak bardzo proste rozwi ˛azanietego problemu, współczesne bufory TLB s ˛abardzo duze,˙ wi˛ecsytuacja ze standardow ˛atranslacj ˛ama miejsce bardzo rzadko.

1.5.3 Memory Overcommitment

Przy wirtualizacji pami˛ecinie mozna˙ nie wspomniećo mechanizmach memory overcommitment, czyli przydzielania wi˛ekszejilo´scipami˛ecisystemom guest niz˙ jest jej dost˛epnejfizy- cznie w systemie. Definicja ta moze˙ pocz ˛atkowobrzmiećniedorzecznie, wyja´snijmywi˛ecna czym owe rozwi ˛azaniepolega. Przydzielamy systemom guest wi˛ecejpami˛eciniz˙ jest fizycznie dost˛epnej,jednak wi˛ekszo´sćz nich (jezeli˙ nie wszystkie nawet) nie wykorzystuj ˛acałej przydzielonej im pami˛eci,a jedynie jej cz˛e´sć,pami˛ećz której systemy guest aktualnie nie korzystaj ˛a moze˙ byćwykorzystana na inne systemy guest, a gdy b˛edziepotrzebna danemu systemowi, b˛edziewtedy ”zabrana” pozostałym. Mozna˙ to w skrócie uj ˛aćjako dynamiczne przydzielanie pami˛eci,w zalezno´sciod˙ potrzeb, ale dla kazdego˙ system mimo to definiujemy maksymalna ilo´sćmozliwej˙ przydzielonej pami˛eci.

Nie jest to rozwi ˛azanieuniwersalne, nie zawsze mozna,˙ czy tez˙ opłaca si˛ez niego skorzys- tać. Na przykład w ´srodowiskach gdzie mamy do czynienia z systemami guest, o których wiemy, ze˙ b˛ed˛awykorzystywaćwi˛ekszo´sćprzydzielonej im pami˛eci. Innym przykładem ´srodowiska nie nadaj ˛acegosi˛ena stosowanie tego mechanizmu, b˛ed˛asystemy guest, które cz˛estoprzydzielaj ˛ai zwalniaj ˛aduze˙ ilo´scipami˛eci,w tym przypadku mechanizm b˛edziedzi- ałał, jednak ze wzgl˛edówwydajno´scistosowanie go tutaj nie b˛edzienajlepszym wyj´sciem. Narzut zwi ˛azanyz memory overcommitment nie jest jaki´sstrasznie duzy,˙ ale jest to rozwi ˛azanie stworzone dla ´srodowisk, w których pracuje wiele systemów guest, które przez wi˛ekszo´sć czasu nie zajmuj ˛aprawie całej swojej przydzielonej pami˛eci.

22 Mechanizm memory overcommitment moze˙ by´crealizowany na kilka sposobów, kazdy˙ z nich nadaje si˛edo innego rodzaju ´srodowiska.

Memory Ballooning

Rozwi ˛azanie memory ballooning pozwala systemom guest dynamicznie zmieniaćrozmiar przydzielonej pami˛eci,po prostu systemy guest maj ˛azwracaćnieuzywan˙ ˛apami˛ećprzez specjalny mechanizm (przewaznie˙ moduł lub usługa j ˛adradla systemu guest). Wad ˛atego rozwi ˛azania jest poleganie na ”dobrej woli” systemu guest przy zwalnianiu pami˛eci,co niestety nieco zmniejsza tak zwane reliability tego rozwi ˛azania.

Transparent Page Sharing

W sytuacji, gdy nasze ´srodowisko składa si˛ewielu podobnych czy tez˙ identycznych sys- temów guest (czy chociazby˙ z identycznymi aplikacjami) o wiele lepszym rozwi ˛azaniemjest mechanizm transparent page sharing (zwany tez˙ czasami content based page sharing). Identyczne strony pami˛ecis ˛ał ˛aczonew jedn ˛a,im wi˛ecejidentycznych stron pami˛eci,tym wi˛ecejpami˛eci oszcz˛edzamy. W razie zapisu jednego z systemów guest stosowany jest mechanizm copy on write aby stworzy´cnow ˛astron˛eo innej zawarto´sci. Wad ˛atego rozwi ˛azaniajest z pewno´sci˛a skomplikowana implementacja oraz spory spadek wydajno´sciw ´srodowiskach które nie s ˛a przez wi˛eksz˛acz˛e´s´cczasu w stanie idle. Nie wymaga jednak modułu j ˛adraczy tez˙ usługi po stronie systemu guest, jest wi˛ecto mechanizm przezroczysty.

Swapping

Ostatnim z mechanizmów memory overcommitment jest swapping, podobnie jak poprzednie rozwi ˛azanienie wymaga ”u´swiadamiania”systemu guest o jego istnieniu. Polega na implementacji jednej przestrzeni swap dzielonej w razie potrzeby przez wszystkie systemy guest. Niestety posiada ono wiele wad. Przez przezroczysto´s´chypervisor wie mniej o aktualnym wykorzystaniu pami˛eciprzez poszczególne systemy guest. Dodatkowo istnieje dosy´cspora szansa, ze˙ hypervisor b˛edziedublował mechanizm swapowania systemów guest, inn ˛akwesti ˛a jest skomplikowana implementacja takiego rozwi ˛azania.

1.6 Wirtualizacja operacji I/O

Trzecia i ostatnia z kluczowych warstw wirtualizacji to wirtualizacja operacji I/O. Bez wirtualizacji system operacyjny odwołuje si˛epo prostu bezpo´srednio do urz ˛adze´nkomputera przez 23 odpowiedni sterownik, udost˛epniaj˛ac(lub nie) dane urz ˛adzenieaplikacjom przez interfejs sterownika. Przedstawia to rysunek 1.17.

Rysunek 1.17: Schemat dost˛epudo urz ˛adzenia natywnie.

Dawniej kiedy kopiowanie danych z urz ˛adzeniamiodbywało si˛eprogramowo przez tryb PIO, procesor był przez cały czas zaj˛etytransferowaniem danych i nie mógł w tym czasie robić zadnych˙ innych rzeczy. Nie musz˛echyba pisaćjak bardzo było to nieefektywne. Z czasem wprowadzono mechanizm DMA, który pozwala na przesyłanie danych znaczenie mniejszym kosztem i mniejszym obciazeniem procesora niz˙ tryb PIO. Umozliwia˙ on urz ˛adzeniombezpo´sredni zapis i odczyt z fizycznej pami˛eciniezaleznie˙ od procesora. W praktyce wygl ˛adato tak, ze˙ CPU rozpoczyna transfer i wraca do innych czynno´scipodczas gdy transfer odbywa si˛ew tle, potem odbiera jedynie przerwanie od kontrolera DMA, ze˙ operacja si˛ezakończyła.

Tak samo jak układ MMU tłumaczy adresy stron logicznych na fizyczne, tak samo układ I/O MMU (w skrócie IOMMU) tłumaczy fizyczne adresy urz ˛adzeńna ich logiczne odpowiedniki w pami˛eci.W przypadku układu IOMMU czynno´sćta nazywa si˛e DMA remapping czyli mapowanie DMA. Cz˛estoodpowiada takze˙ za mapowanie przerwańw podobny sposób jak dzieje si˛eto dla adresów stron oraz za kontrol˛edost˛epudo danego urz ˛adzenia.Zestawienie układów MMU oraz IOMMU przedstawia rysunek 1.18.

Rysunek 1.18: Porównanie działania układów MMU oraz I/O MMU.

24 Innym od dawna stosowanym układem pokroju IOMMU jest układ GART stosowany przy mapowaniu pami˛ecikart graficznych. Układ IOMMU robi dokładnie to samo, tylko dla wszystkich urz ˛adzeńw komputerze, nie tylko dla karty graficznej. Urz ˛adzeniakorzystaj ˛acez kanału DMA swoje działania opieraj ˛ana adresach fizycznych a nie logicznych, st ˛adtez˙ hypervisor nie ma mozliwo´scizaw˛e˙ zenia˙ zakresu pami˛eciw przypadku transferu danych przy uzyciu˙ mechanizmu DMA do zakresu pami˛ecikonkretnego systemu guest. W rezultacie hypervisor musi emulowaćstare, proste w budowie, dobrze znane urz ˛adzenia,gdyz˙ s ˛aone łatwe do za- implementowania, poniewaz˙ nie posiadaj ˛askomplikowanych funkcjonalno´sciwspółczesnych urz ˛adzeń. Oczywi´scierozwi ˛azanietakie, mimo bardzo duzej˙ elastyczno´sciprzy zarz ˛adzani, bardzo cierpi na wydajno´sci. Rozwi ˛azanietakie nosi takze˙ nazw˛eprogramowego układu IOMMU. Opisany powyzej˙ sposób emulowania urz ˛adzeńprzez hypervisor przedstawia rysunek 1.19.

Rysunek 1.19: Programowe emulowanie układu IOMMU przez hypervisor.

Rozwi ˛azaniemtego problemu jest wła´sniewspomniany sprz˛etowyukład IOMMU. Pozwala on tłumaczyćfizyczne strony pami˛ecisystemu guest, na adresy fizyczne w pami˛ecikomputera, a dzi˛ekitemu hypervisor moze˙ pozwolićsystemowi guest na bezpo´sredni ˛akontrol˛enad fizycznym urz ˛adzeniem.Rozwi ˛azaniejest to o tyle uniwersalne, ze˙ system guest moze˙ uzy-˙ wać”zwykłych” niewirtualizowanych sterowników do komunikacji z tymze˙ urz ˛adzeniem. Rozwi ˛azanieto pozwala zmniejszyćniepoz˙ ˛adaneopó´znieniawynikaj ˛acez wirtualizacji do minimum.

Rozwi ˛azanieto posiada niestety pewn ˛awad˛e,jezeli˙ transfer danych nie powiedzie si˛ekon- troler DMA nie zwróci bł˛edu, nie pozostaje zatem nic innego jak obsłuzenie˙ tego wyj ˛atku programowo przez hypervisor. Mimo tego mankamentu rozwi ˛azanieto jest zdecydowanie lepszym podej´sciemniz˙ rozwi ˛azanieczysto programowe i jest dobrym krokiem w stron˛ekole- jnych bardziej rozwini˛etychukładów wspieraj ˛acychwirtualizacj˛e.Sprz˛etowyukład I/O MMU

25 przedstawia rysunek 1.20.

Rysunek 1.20: Schemat sprz˛etowegoukładu IOMMU.

Pozostaj ˛ajeszcze inne problemy do rozwi ˛azaniazwi ˛azanez wirtualizacj ˛aoperacji I/O. Mianowicie współdzielenie jednego, b ˛ad´zkilku fizycznych urz ˛adzeńprzez kilka systemów guest oraz/lub system host. Nie mozna˙ w końcupozwolićna dowolne korzystanie ze sprz˛etu poniewaz˙ wtedy tak naprawd˛e zaden˙ z systemów niczego nie osi ˛agnie,bo jeden b˛edzieka- sował to co poprzedni dopiero ustawił i vice versa. W końcuto nie pami˛eć, ze˙ jeden system b˛edziekorzystał ze swojej cz˛e´scia drugi ze swojej. Nalezy˙ takze˙ pami˛etać,ze owe dzielenie si˛e odnosi sie nie tylko do tak podstawowych zagadnieńjak karty sieciowe czy karty d´zwi˛ekowe, ale takze˙ karty graficzne i generowanie na nich akcelerowanego obrazu 2D/3D, czy tez˙ skomplikowanych obliczeńwykonywanych bezpo´srednio na GPU (zwane takze˙ GPGPU).

Podobnie jak w przypadku bezpo´sredniego dost˛epudo urz ˛adzeńrówniez˙ tutaj mozemy˙ uzyćpodej´sciaprogramowego˙ jak i sprz˛etowego. W tym pierwszym wypadku hypervisor b˛edzieodpowiedzialny za rozdzielanie, kolejkowanie i zarz ˛adzanie z˙ ˛adaniamiI/O systemów guest. B˛edzietez˙ musiał emulowaćurz ˛adzeniadla systemów guest i dopiero ”osobi´scie” zajmowaćsi˛ewymian ˛adanych z fizycznym sprz˛etem, a potem z powrotem rozdzielaćna wirtualne urz ˛adzenia.Oczywi´sciedalej pozostaje problem podwójnego kopiowania pomi˛edzy urz ˛adzeniamiwirtualnymi a fizycznymi. Daje to wi˛ekszemozliwo´scizarz˙ ˛adzaniai kontroli, jednak cierpi na tym wydajno´sć, czasami do´sćznacznie. Programowe dzielenie urz ˛adzeń obrazuje rysunek 1.21.

Lepszym rozwi ˛azaniem,na pewno w kwestii wydajno´sci,jest z pewno´sci˛asprz˛etowekole- jkowanie i zarz ˛adzanie,znacznie odci ˛aza˙ procesor, a ponadto omija problem podwójnego kopiowania jak w przypadku programowego podej´scia. Sprz˛etowepodej´sciedo dzielenia urz ˛adze´nobrazuje rysunek 1.22.

Kolejn ˛aistotn ˛akwesti ˛ajest całkowite ”przekazywanie” fizycznych urz ˛adzeńkonkretnym systemom guest w trybie wył ˛acznym(dedicated). Rozwi ˛azanieto jest o tyle wazne˙ i uzyteczne,˙ gdyz˙ system host moze˙ nie posiadaćodpowiednich sterowników do danego urz ˛adzenia,a sys-

26 Rysunek 1.21: Schemat dzielenia urz ˛adze´nza pomoc ˛a programowych urz ˛adze´nwirtualnych.

Rysunek 1.22: Schemat dzielenia urz ˛adzeńza pomoc ˛a rozwi ˛azaniasprz˛etowego. tem guest jak najbardziej. Powyzsza˙ funkcjonalno´sćjest uzyteczna˙ zarówno w ´srodowisku serwerowym jak i desktopowym. W przypadku serwerów b˛edzieto na pewno obsługa wszelkiej ma´scikontrolerów czy tez oprogramowania zarz ˛adzaj˛acegodo nich. Podobnie w przypadku całej masy urz ˛adzeńsieciowych (switch/router). W przypadku desktop przychodz ˛ana my´sl wszelkiej ma´sciurz ˛adzeniaUSB jak kamerki internetowe, odtwarzacze, aparaty cyfrowe. Przekazy- wanie urz ˛adzeńpodobnie jak w przypadku ich dzielenia równiez˙ moze˙ byćzrealizowane programowo i sprz˛etowo.Programowe rozwi ˛azanieprzedstawia rysunek 1.23.

Porównuj ˛acpodej´sciaprogramowe i sprz˛etowew przypadku ”przekazywania” dochodz- imy do tych samych wniosków jak w przypadku dzielenia urz ˛adzeń.Wi˛eksza(cz˛estoznacznie) wydajno´sćrozwi ˛azaniasprz˛etowegooraz duzo˙ mniejsze obci ˛azenie˙ procesora(ów). W przypadku dzielenia urz ˛adzeńpewnym argumentem dla rozwi ˛azaniaprogramowego była wi˛eksza elastyczno´sćoraz mozliwo´sci,w˙ tym wypadku rozwi ˛azanieprogramowe nie ma tej zalety, bo w sumie nie ma i czym zarz ˛adzać,system guest dostaje pod swoj ˛akontrol˛eurz ˛adzeniei robi z nim co chce. Podej´sciesprz˛etoweprzedstawia rysunek 1.24. 27 Rysunek 1.23: Schemat programowego ”przekazywania” urz ˛adzeńdo systemu guest.

Rysunek 1.24: Schemat dzielenia urz ˛adze´nza pomoc ˛a rozwi ˛azaniasprz˛etowego.

Mimo pewnych zalet podej´sciaprogramowego jak wi˛ekszemozliwo´scizarz˙ ˛adzaniato pode- j´sciesprz˛etowejest tym wła´sciwszymi nie nalezy˙ go rozpatrywa´cjako alternatyw˛ea jako em- ulacj˛ew stosunku do podej´sciaprogramowego.

1.7 Rozszerzenia sprz˛etowewspieraj ˛acewirtualizacj˛e

Opisane wcze´sniejtechniki wirtualizacji korzystaj ˛aze specjalnych sprz˛etowychrozszerze´n, zostan ˛aone opisane w tym rozdziale.

28 1.7.1 AMD

Rysunek 1.25: Logo procesorów ﬁrmy Advanced Micro Devices.

Nazwa kodowa sprz˛etowychrozszerze´nwirtualizacji w procesorach AMD to Paciﬁca.

AMD-V / SVM

Rozszerzenie procesorów AMD AMD-V zwane tez˙ cz˛esto SVM pozwala na sprz˛etow˛a wirtualizacj˛edostarczaj ˛acspecjalne tryby root mode (dla hypervisora) oraz non root mode (dla systemów guest) co pozwala na natywn ˛awirtualizacj˛esystemów guest w trybie ring 0, a nie jak dotychczas w ring 1. Eliminuje takze˙ potrzeb˛eprogramowego przechwytywania czułych instrukcji systemów guest.

Odpowiednik w procesorach Intel: VT-x

AMD Device Exclusion Vector

Device Exclusion Vector w skrócie DEV pozwala na kontrol˛edost˛epudo pami˛ecisystemów guest, co zwi˛ekszabezpiecze´nstwowirtualizacji i zapewnia izolacje kazdego˙ z systemów guest. Rozwi ˛azanietakie jest mozliwe˙ jedynie na procesorach ze zintegrowanym kontrolerem pami˛eci, patrz rozszerzenie AMD Integrated Memory Controller.

Odpowiednik w procesorach Intel: (brak)

AMD Integrated Memory Controller

Wirtualizacja to zadanie bardzo pami˛eciochłonne. Zintegrowany kontroler pami˛eciczyli Integrated Memory Controller (w skrócie IMC w procesorze zapewnia o wiele wi˛eksz˛awydajno´sćpami˛eciw porównaniu do historycznego rozwi ˛azaniabazuj ˛acegona szynie FSB. Pami˛eć jest podł ˛aczonabezpo´srednio do procesora co pozwala na cz˛estoznaczne zmniejszenie opó´znień w dost˛epiedo pami˛eci.Rozwi ˛azanietakie ´swietniesprawdza si˛etez˙ w konfiguracjach wieloprocesorowych (czyli SMP gdyz˙ kazdy˙ procesor korzysta z podobnej szyby w dost˛epiedo pami˛ecia nie jak w przypadku FSB dzieli ja z wszystkimi innymi procesorami. Architektura

29 taka okre´slanajest tez mianem NUMA.

Odpowiednik w procesorach Intel: Integrated Memory Controller

AMD Direct Connect Architecture

Rozwi ˛azanie Direct Connect Architecture pozwala wyeliminowaćw ˛askiegardła tradycyjnego podej´sciaw komunikacji pomi˛edzyprocesorem a urz ˛adzeniamiopartego na szynie FSB. Rozwi ˛azanie DCA pozwala poł ˛aczyćprocesor, kontroler pami˛ecii urz ˛adzeniamagistral ˛a HyperTransport. Pozwala to znacz ˛acozwi˛ekszyćskalowalno´sći wydajno´sćw komunikacji z urz ˛adzeniami.

Odpowiednik w procesorach Intel: VT-c

AMD Extended Migration

Mechanizm Extended Migration umozliwia˙ migracje maszyny wirtualnej z jednego procesora (lub kilku) AMD na inny (inne) bez przerywania pracy systemu guest. Pozwala takze˙ na odpowiednie ”ukrycie” róznic˙ pomi˛edzyróznymi˙ generacjami procesorów AMD pozwalaj ˛ac na migracje nawet pomi˛edzyróznymi˙ generacjami procesorów.

Odpowiednik w procesorach Intel: FlexMigration

AMD IOMMU

Sprz˛etowawirtualizacja operacji I/O czyli IOMMU (co rozwija si˛ena I/O Memory Manage- ment Unit). Hypervisor b˛edziemógł dzielićurz ˛adzeniapomi˛edzysystemy guest bezpo´srednio bez emulacji i podwójnego kopiowania, tłumaczenie adresów DMA, adresów urz ˛adzeńoraz sprawdzanie odpowiednich uprawnieńdost˛epudo owego sprz˛etu.

Odpowiednik w procesorach Intel: VT-d / VT-c

AMD Rapid Virtualization Indexing

Implementacja mechanizmu nested page table w procesorach AMD nosi nazw˛e Rapid Virtu- alization Indexing.

Odpowiednik w procesorach Intel: Extended Page Table

30 AMD Address Space Identiﬁer

Rozwi ˛azanie Address Space Identifier w skrócie ASID to implementacja rozwi ˛azania Tagged TLB w procesorach AMD pozwala na przypisanie obszarów pami˛ecikonkretnym systemom guest, dzi˛ekiczemu nie trzeba za kazdym˙ razem oprózniaćbufora˙ TLB gdy procesor zmienia kontekst pomi˛edzyhypervisorem a systemem guest, znacznie zmniejsza to ilo´sćoperacji na pami˛ecipotrzebnych do wykonania.

Odpowiednik w procesorach Intel: Virtual Processor Identiﬁer

AMD HyperTransport

Technologia HyperTransport to szyna systemowa wymy´slonaw miejsce starszego brata o nazwie FSB. Zapewnia wysoki transfer danych, niskie opó´znieniaoraz jest rozwi ˛azaniemtypu point-to-point maj ˛acymna celu przy´spieszeniekomunikacji pomi˛edzyurz ˛adzeniami.Jest kom- patybilna z istniej ˛acymirozwi ˛azaniamia jednocze´sniemoze˙ by´crozszerzona do Systems Net- work Architecture. Jest przezroczysta dla systemu operacyjnego. Logo konsorcjum |textitHy- perTransport przedstawia rysunek 1.26.

Rysunek 1.26: Logo HyperTransport Consortium.

Odpowiednik w procesorach Intel: QuickPath Interconnect

AMD Cool’n’Quiet

Rozwi ˛azanie Cool’n’Quiet to nic wi˛ecejjak mechanizm zarz ˛adzaj˛acynapi˛eciemi cz˛estotliwo´sci˛aprocesora w zalezno´sciod˙ zapotrzebowania na moc obliczeniow ˛a. Jezeli˙ procesor nic nie robi (lub robi bardzo mało), napi˛eciejest obnizane˙ razem z cz˛estotliwo´sci˛aprocesora. Pozwala to oszcz˛edza´cenergi˛eoraz wydziela´cznacznie mniej ciepła, pozwala to takze˙ na ci- chsze chłodzenie. St ˛adtez˙ wywodzi si˛enazwa rozwi ˛azania, Cool’n’Quiet znaczy ni mniej ni wi˛ecejjak chłodno i cicho. Rozwi ˛azanieto jest desktopow ˛ai serwerow ˛awersj ˛arozwi ˛azania PowerNow!, które jest uzywane˙ w Laptopach i innych urz ˛adzeniachmobilnych.

Rozwi ˛azanieto wyst˛epujew serwerowych procesorach Opteron serii ’E’ ale tam nosi nazw˛e Optimized Power Management, gdzie wyst˛epujew nieco zmodyfikowanej formie aby móc ob- słuzyćrejestrowan˙ ˛apami˛ećRAM.

31 Odpowiednik w procesorach Intel: (Enhanced) SpeedStep

AMD (Enhaced) AMD PowerNow!

Technologia PowerNow! to podobnie jak w przypadku Cool’n’Quiet skalowanie pr˛edko´sci procesora i jego napi˛ecia,tyle ze˙ przeznaczona do urz ˛adze´nmobilnych.

Odpowiednik w procesorach Intel: (Enhanced) SpeedStep

AMD Enhanced Power Management

W skład technologii pod nazwa Enhanced Power Management wchodzi kilka mniejszych rozwi ˛aza´n,zwi ˛azanychz oszcz˛edzaniemenergii i skalowaniem procesorów, s ˛ato:

Independent Dynamic Core Pozwala regulowa´cszybko´s´ckazdego˙ z rdzeni procesora.

Dual Dynamic Power Management Pozwala zarz ˛adza´cpr˛edko´sci˛ai napi˛eciemkazdego˙ procesora z osobna w systemach SMP.

CoolCore Sprawdza czy procesor, pami˛e´c,czy tez˙ obydwa s ˛aaktualnie potrzebne. W razie potrzeby zmniejsza napi˛eciedla nieuzywanych˙ tranzystorów.

Odpowiednik w procesorach Intel: (Enhanced) SpeedStep

AMD Presidio

Rozszerzenie Presidio dostarcza mechanizmów bezpieczeństwadla aplikacji. Kazda˙ aplikacja uruchamiana jest w swoim odizolowanym od pozostałych aplikacji ´srodowisku. Ni- estety uzycie˙ tych rozszerzeńwymaga modyfikacji systemu operacyjnego.

Rozszerzenie współdziała z modułem Trusted Platform Module który zaprojektowała grupa Trusted Computing Group4.

Ma to na celu zabezpieczenie pami˛ecikarty graficznej (podmiana obrazu przez inna aplikacj˛e),urz ˛adzeńtypu input (program moze˙ sprawdzaćco pisze uzytkownik),˙ pami˛eciRAM (czytanie pami˛eciinnego programu) oraz kontrolera DMA (równiez˙ kontrola pami˛eci).Za te

4Wi˛ecejinformacji o grupie Trusted Computing Group na stronie http://trustedcomputinggroup.org/

32 Rysunek 1.27: Logo grupy Trusted Computing Group. zabezpieczenia odpowiadaj ˛anast˛epuj˛acetechnologie:

Isolated Execution Space (CPU) Enhanced Virus Protection (CPU) Storage Sealing (Trusted Platform Modules) Secure Initialization (Chipset/CPU/Trusted Platform Modules) Secure Input (Chipset/CPU) Secure Output (Chipset/CPU/GPU) Remote Attestation (Chipset/CPU/Trusted Platform Modules)

Odpowiednik w procesorach Intel: Trusted Execution Technology

Dost˛epno´s´cwyzej˙ wymienionych rozszerze ´nw procesorach AMD http://en.wikipedia.org/wiki/List_of_AMD_Turion_microprocessors http://en.wikipedia.org/wiki/List_of_AMD_Sempron_microprocessors http://en.wikipedia.org/wiki/List_of_AMD_Athlon_64_microprocessors http://en.wikipedia.org/wiki/List_of_AMD_Athlon_X2_microprocessors http://en.wikipedia.org/wiki/List_of_AMD_Phenom_microprocessors http://en.wikipedia.org/wiki/List_of_AMD_Opteron_microprocessors http://en.wikipedia.org/wiki/Athlon_64 http://en.wikipedia.org/wiki/AMD_K10 http://en.wikipedia.org/wiki/Opteron

1.7.2 Intel

Nazwa kodowa sprz˛etowychrozszerze´nwirtualizacji w procesorach Intel nosi nazw˛e Van- derpool.

33 Rysunek 1.28: Logo procesorów ﬁrmy Intel.

Intel VT-x / VT-i

Rozszerzenia procesorów Intel VT-x (dla procesorów architektury i386/amd64) oraz VT-i (dla procesorów Itanium) pozwalaj ˛ana sprz˛etow˛awirtualizacj˛edostarczaj ˛acspecjalne tryby root mode (dla hypervisora) oraz non root mode (dla systemów guest) co pozwala na natywn ˛a wirtualizacj˛esystemów guest w trybie ring 0, a nie jak dotychczas w ring 1. Eliminuje takze˙ potrzeb˛eprogramowego przechwytywania czułych instrukcji systemów guest.

Odpowiednik w procesorach AMD: AMD-V / SVM

Intel VT-d

Technologia VT-d zwana tez˙ marketingowo Virtualization Technology for Directed I/O to sprz˛etowawirtualizacja operacji I/O spod znaku Intela. Dzi˛ekiniej hypervisor b˛edziemógł dzielićurz ˛adzeniapomi˛edzysystemy guest bez emulacji i podwójnego kopiowania, pozwala takze˙ na tłumaczenie adresów DMA, adresów urz ˛adzeńoraz sprawdzanie odpowiednich up- rawnieńdost˛epudo sprz˛etu.

Odpowiednik w procesorach AMD: IOMMU

Intel VT-c

Rozwi ˛azanie VT-c nazywane zamiennie Virtualization Technology for Connectivity ma na celu wyeliminowanie w ˛askichgardeł w komunikacji pomi˛edzyprocesorem a urz ˛adzeniami. Pozwala to na zwi˛ekszenieskalowalno´scii wydajno´scikomunikacji z urz ˛adzeniami.Zawiera kilka mniejszych technologii:

Virtual Machine Device Queues Zwane takze˙ VMDq, zwi˛ekszaprzepustowo´s´cI/O dla rozwi ˛aza´nsieciowych.

I/O Acceleration Technology

34 Zamiennie I/OAT minimalizuje zjawisko w ˛askiegogardła dla kart sieciowych.

Single-Root Input/Output Virtualization Czyli SR-IOV, pozwala hypervisorowi na bezpo´sredni dost˛epdo sprz˛etusieciowego. Pozwala partycjonowa´cszyn˛ePCI/PCI Express na wirtualne interfejsy.

Odpowiednik w procesorach AMD: Direct Connect Architecture / IOMMU

Intel Extended Page Tables

Implementacja mechanizmu nested page table w procesorach Intel, nazwana Extended Page Tables.

Odpowiednik w procesorach AMD: Rapid Virtualization Indexing

Intel (Enhanced) Speedstep

W skrócie nazywane EIST, jest rozwi ˛azaniempozwalaj ˛acymna skalowanie szybko´scipro- cesora i obnizania˙ jego napi˛eciaw zalezno´sciod˙ zapotrzebowania na moc obliczeniow ˛a.Ma to na celu oszcz˛edzanieenergii oraz mniejsze wydzielanie ciepła podczas pracy w trybie idle.

Odpowiednik w procesorach AMD: Cool’n’Quiet / (Enhaced) AMD PowerNow! / Enhanced Power Management

Intel QuickPath Interconnect

Technologia QuickPath Interconnect to szyna systemowa maj ˛acana celu zast ˛api´cstrasznie wysłuzonej˙ w rozwi ˛azaniachIntela szyn˛e FSB. Podobnie jak w przypadku rozwi ˛azaniaAMD jest rozwi ˛azaniemtypu point-to-point, zapewnia wysoki transfer danych, niskie opó´znienia,

Odpowiednik w procesorach AMD: HyperTransport

Intel FlexPriority

Rozwi ˛azanie FlexPriority udost˛epniasystemom guest dost˛epdo wirtualnego rejestru procesora steruj ˛acegopriorytetami task priority register co odci ˛aza˙ hypervisor od emulowania i przechwytywania instrukcji systemów guest zwi ˛azanychz tymze˙ rejestrem.

35 Odpowiednik w procesorach AMD: AMD-V / SVM

Intel FlexMigration

Technologia FlexMigration pozwala na migracj˛emaszyny wirtualnej bez przerywania jej pracy, czyli tak zwan ˛a live migration pomi˛edzyróznymi˙ generacjami procesorów ﬁrmy Intel.

Odpowiednik w procesorach AMD: Extended Migration

Intel Virtual Processor Identiﬁer

Rozwi ˛azanie Virtual Processor Identifier w skrócie VPID to implementacja rozwi ˛azania Tagged TLB w procesorach Intel. Pozwala na przypisanie obszarów pami˛ecikonkretnym systemom guest, dzi˛ekiczemu nie trzeba za kazdym˙ razem oprózniaćbufora˙ TLB gdy procesor zmienia kontekst pomi˛edzyhypervisorem a systemem guest, znacznie zmniejsza ilo´sćoperacji na pami˛ecipotrzebnych do wykonania.

Odpowiednik w procesorach AMD: Address Space Identiﬁer

Intel Trusted Execution Technology

Rozszerzenia o nazwie Trusted Execution Technology zwane w skrócie TXT zapewniaj ˛abez- piecze´nstwodziałania aplikacji. Kazda˙ aplikacja uruchamiana jest w swoim odizolowanym od pozostałych aplikacji ´srodowisku. Nazwa kodowa tego rozwi ˛azaniato LaGrande. Rozszerze- nie współdziała z modułem Trusted Platform Module grupy Trusted Computing Group.

Technologia ta ma na celu zabezpieczenie pami˛ecikarty graficznej (podmiana obrazu przez inna aplikacj˛e),urz ˛adzeńtypu input (program moze˙ sprawdzaćco pisze uzytkownik),˙ pami˛eci RAM (czytanie pami˛eciinnego programu) oraz kontrolera DMA (równiez˙ kontrola pami˛eci).

Odpowiednik w procesorach AMD: Presidio

Dost˛epno´s´cwyzej˙ wymienionych rozszerze ´nw procesorach Intel http://processorfinder.intel.com http://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors http://en.wikipedia.org/wiki/List_of_Intel_Pentium_4_microprocessors http://en.wikipedia.org/wiki/List_of_Intel_Pentium_D_microprocessors http://en.wikipedia.org/wiki/List_of_Intel_Core_microprocessors

36 http://en.wikipedia.org/wiki/List_of_Intel_Core_2_microprocessors http://en.wikipedia.org/wiki/List_of_Intel_Xeon_microprocessors http://en.wikipedia.org/wiki/List_of_Intel_Itanium_microprocessors http://en.wikipedia.org/wiki/Intel_Core_(microarchitecture) http://en.wikipedia.org/wiki/Intel_Nehalem_(microarchitecture) http://en.wikipedia.org/wiki/Intel_Core_i7

1.7.3 VIA

Procesory spod znaku VIA równiez˙ obsługuj ˛asprz˛etow˛awirtualizacj˛e,obsługuj ˛aj ˛ana- jnowsze procesory VIA NANO o kodowej nazwie Isaiah.

Rysunek 1.29: Logo procesorów ﬁrmy VIA.

Posiadaj ˛aimplementacj˛ezgodn ˛az rozszerzeniami procesorów Intel, czyli VT-i.

Dost˛epno´s´cwyzej˙ wymienionych rozszerze ´nw procesorach VIA http://en.wikipedia.org/wiki/List_of_VIA_Nano_microprocessors http://en.wikipedia.org/wiki/VIA_Nano

1.7.4 Podsumowanie

Po lekturze tegoz˙ podrozdziału mozna˙ odnie´sćwrazenie,˙ ze˙ zarówno AMD jak i Intel oferuj ˛abardzo podobne, praktycznie takie same rozwi ˛azania,jedynie pod innymi nazwami. Prawda jest taka, ze˙ wielu z opisanych tutaj rozszerzeńfirmy Intel nie ma w aktualnie dost˛ep- nych procesorach z serii Core 2 czy tez˙ Xeon, zostały jednak opisane ze wzgl˛eduna bardzo blisk ˛apremier˛eprocesora Core i7 o kodowej nazwie Nehalem, który wnosi naprawd˛eduzo˙ w kwestii wirtualizacji. Z drugiej strony wszystkie zastosowane w nim rozszerzenia i ulepszenia s ˛ajedynie kopi ˛atego co firma AMD ma w swoich procesorach juz˙ od dawna. Jedynie nieliczne z nich zostały dodane ponad półtora roku temu w nowej natywnej (a nie sklejanej jak u Intela) architekturze czterordzeniowej K10, a w procesorach Intela nie ma ich po dzi´sdzień. Inn ˛a kwesti ˛ajest, ze˙ Intel celowo wycina owe rozszerzenia z wielu swoich tańszychprocesorów,

37 równiez˙ z procesorów mobilnych, a nawet z niektórych procesorów 4 rdzeniowych5. AMD dla odmiany nie ”kaleczy” swoich procesorów, nawet najta´nszych.

Bior ˛acpod uwag˛eprocesory aktualnie dost˛epnena rynku zdecydowanie lepszym wyborem na wydajn ˛ai oszcz˛edn˛aplatform˛es ˛aprocesory firmy AMD6, Intel moze˙ jedynie ”konkurować” na konfiguracjach jedno procesorowych, poniewaz˙ w bardziej skomplikowanych ´srodowiskach rozwi ˛azaniaIntela po prostu si˛enie skaluj ˛a. Najwi˛ekszymproblemem procesorów Intela jest ogólnie mówi ˛acpami˛eć. Primo brak rozszerzeńwspieraj ˛acychwirtualizacj˛epami˛eciw procesorze (jak chociazby˙ nested page table czy tez brak zintegrowanego kontrolera pami˛eci czego skutkiem jest o wiele mniejsza przepustowo´sćpami˛eciw porównaniu do procesorów AMD. Secundo komunikacja pomi˛edzyprocesorami/rdzeniami i reszt ˛asystemu przez jedynie przyspieszon ˛aszyn˛e FSB.

Nalezy˙ tez˙ jeszcze pami˛etaćo nast˛epuj˛acejrzeczy, aktualnie w procesorach architektury i386 znajduj ˛asi˛egłównie sprz˛etowerozszerzenia pierwszej generacji, oznacza to niestety, ze˙ w niektórych przypadkach podej´scieprogramowe moze˙ jednak okazaćsi˛ewydajniejsze (!) anizeli˙ rozwi ˛azaniesprz˛etowe. Dotyczy to głownie rozszerzeń,które dodaj ˛atryb VMX root dla hypervisora, wydajno´sćnie jest powalaj ˛acaponiewaz˙ context switch procesora (czyli zmi- ana kontekstu pracy) trwa zbyt długo. Nast˛epnegeneracje owych rozwi ˛azańoraz takze˙ nowe lepsze rozwi ˛azaniabo nic w końcunie stoi w miejscu, b˛ed˛aoferowały o wiele bardziej zad- owalaj ˛ac˛awydajno´sć,mimo tych niedogodno´sciwarto z nich korzystać,gdyz˙ róznice˙ w wydajno´scinie s ˛ana tyle duze˙ aby w jakikolwiek sposób dyskwalifikowały owe rozszerzenia.

Pami˛etajmytakze,˙ ze˙ nawet jezeli˙ nie posiadamy sprz˛etbez owych rozszerze´nnic nie stoi na przeszkodzie aby´smyuzywali˙ wirtualizacji, czy to na poziomie systemu operacyjnego, czy pełnej wirtualizacji z technik ˛a binary translation. Równiez˙ parawirtualizacja z hypervisorem typu 1 b˛edzie´swietniedziała´cna takim sprz˛ecie.

1.8 Innowacje i nowe technologie

Wirtualizacja to aktualnie jedna z najszybciej rozwijaj ˛acychsie dziedzin informatyki, nowe rozwi ˛azania,lepsze pomysły, szybsze rozszerzenia sprz˛etowe,wielordzeniowe procesory ...

5Mozna˙ to sprawdzi´crówniez˙ na http://processorfinder.intel.com 6Moze˙ wła´sniest ˛adpomysł na hasło AMD pod nazw ˛a Smarter Choice.

38 1.8.1 Sterowniki parawirtualne

W przypadku parawirtualizacji i dost˛epudo kodu ´zródłowegosystemu guest który chcemy wirtualizowaćwszystkie odwołania do sprz˛etuoraz czułe instrukcje zast ˛apiones ˛aw kodzie na ich odpowiedniki hypervisora, czyli odwołania hypercall. Sprawia to, ze˙ system guest ”roz- mawia” z hypervisorem bez zb˛ednychemulacji na czym bardzo zyskuje wydajno´sć,która w tym wypadku jest bliska natywnej. Jezeli˙ uzywamy˙ pełnej wirtualizacji systemu operacyjnego, którego ´zródełnie posiadamy, musimy korzystaćz emulowania wirtualnych urz ˛adzeń,a hypervisor musi w locie przechwytywaći zamieniaćodpowiednie instrukcje. Niepotrzebnie za- biera to czas procesora oraz znacznie obniza˙ wydajno´sćtakiego rozwi ˛azania.Z pomoc ˛aprzy- chodz ˛atutaj sterowniki parawirtualne, które uzywaj˙ ˛acwirtualnego urz ˛adzenia,komunikuj ˛asie z hypervisorem za pomoc ˛ajego odwołań hypercall, nie ma wi˛ecpotrzeby emulacji a wydajno´sć jest w najgorszym wypadku kilkana´scieprocent gorsza od natywnej.

Oczywi´scierozwini˛eciemtej idei jest wirtualizacja na sprz˛eciewyposazonym˙ w rozszerzenia do wirtualizacji operacji I/O. System guest uzywa˙ wtedy zwykłych sterowników danego urz ˛adzenia,tak jakby działał samodzielnie na danej maszynie bez wirtualizacji, uzywaj˙ ˛acdanego urz ˛adzenianatywnie z natywn ˛awydajno´sci˛a.

1.8.2 SMP w systemach guest

Z pocz ˛atkuwirtualizowany system guest miał do dyspozycji jedynie jeden wirtualny procesor na którym mógł wykonywa´cswoje instrukcje, nawet jezeli˙ system host posiadał ich o wiele wi˛ecej.Zdarzało si˛enawet, ze˙ było to wymogiem nawet dla systemu host w niektórych przypadkach, na przykład VMware 3 na systemie FreeBSD jako host. W dzisiejszych czasach ograniczenia takie s ˛aniedopuszczalne i wywołuj ˛aco najwyzej˙ szyderczy u´smieszek.

Aktualnie uzywaj˙ ˛acczy to procesorów wirtualnych, czy tez˙ ﬁzycznych, systemy guest z udost˛epnionymirdzeniami s ˛acodzienno´sci˛a.Zarówno w rozwi ˛azaniachserwerowych jak i przeznaczonych na stacje robocze, a na desktopie ko´ncz˛ac.Stawia to oczywi´scienowe zadania i obowi ˛azkiprzed hypervisorem, zwłaszcza jezeli˙ dzielimy kilka lub kilkana´scieprocesorów pomi˛edzykilka maszyn wirtualnych.

SMP dla systemów guest jest wbrew pozorom bardzo waznym,˙ gdyz˙ wirtualizowane przez nas ´srodowiska tez˙ b˛ed˛aposiadały wiele wymagaj ˛acychaplikacji czy tez˙ serwerów, a jeden rdze´nto dla nich zdecydowanie za mało (na przykład serwer aplikacji JAVA), inn ˛azaleta dowolnego przydzielania procesorów systemom guest s ˛alicencje na oprogramowanie, przykład- owo Oracle sprzedaje licencje na swoje bazy danych w zalezno´sciod˙ ilo´sciprocesorów w systemie, wtedy posiadaj ˛acna przykład serwer z 16 procesorami, b˛edziemymogli uzywa´cnaszej˙ bazy danych zgodnie z licencj ˛aw wirtualizowanym ´srodowisku 4 procesorowym.

39 1.8.3 NUMA

Wraz ze wzrostem liczby procesorów i rdzeni klasyczne podej´scieuzycia˙ szyny FSB, czyli podpi˛eciewszystkich procesorów i ko´scipami˛eciRAM, coraz bardziej pokazuj˛eswoje wady. Niewystarczaj ˛acaprzepustowo´sć, coraz wi˛ekszeopó´znieniawraz ze wzrostem obci ˛azenia,˙ czynniki znacznie wpływaj ˛acena wydajno´sćnaszej platformy wirtualizacyjnej. Schemat wykorzystania szyny FSB przedstawia rysunek 1.30. Zarówno Intel jak i AMD wprowadziły juz˙ (bað´zzamierzaj ˛awprowadzić”na dniach”) rozwi ˛azaniao wiele lepiej przystosowane do takiego obci ˛azenia.˙ S ˛ato mianowicie HyperTransport oraz QuickPath Interconnect. Mimo swoich m ˛adrych nazw nie s ˛aniczym innym jak rozwi ˛azaniem NUMA czyli Non-Uniform Memory Access.

Rysunek 1.30: Wykorzystanie szyny FSB w konﬁguracji SMP.

Dawniej wszystkie procesory dzieliły cał ˛adost˛epn˛apami˛ećpomi˛edzysiebie, oczywi´scie uzywaj˙ ˛acszyny FSB. W architekturze NUMA kazdy˙ procesor posiada dedykowan ˛apami˛eć podł ˛aczon˛abezpo´srednio do niego, oczywi´scienic nie stoi na przeszkodzie aby korzystał z pami˛eciinnych procesorów, odbywaćsi˛eto jednak wolniej niz˙ w przypadku jego dedykowanej pami˛eci.Wymaganiem takiej architektury jest zintegrowany kontroler pami˛ecibezpo´srednio w procesorze, wła´sniedlatego Intel dopiero teraz wprowadza rozwi ˛azaniabazuj ˛acena NUMA, gdyz˙ wcze´sniejnie posiadał takowego procesora w swoim portfolio, w przeciwieństwiedo AMD, które od dawna korzysta z dobrodziejstw NUMA. Technologie NUMA przestawia rysunek 1.31.

Wad ˛atego rozwi ˛azaniajest to, ze˙ system operacyjny musi wiedziećjak wykorzystaćar- chitektur˛eNUMA, w przeciwnym wypadku b˛edzietraktował dedykowane pami˛eciposzczegól- nych procesorów jako jedn ˛aspójn ˛acało´sći przydzielał pami˛ećnie od tego procesora co trzeba, a cz˛estonawet od kilku, mimo iz˙ pami˛ećdedykowana danego procesora moze˙ w skrajnym

40 Rysunek 1.31: Technologia NUMA w konﬁguracji SMP. przypadku nawet pozostawa´cpusta.

1.8.4 Cache Coherent NUMA

Pomimo swoich niezaprzeczalnych zalet architektura NUMA posiada równiez˙ pewn ˛aniedo- godno´sć. Poniewaz˙ mamy do czynienia z kilkoma blokami pami˛eci,kazdy˙ procesor przechowuje w pami˛ecipodr˛ecznej cache która cz˛e´sćpami˛eci(dedykowanej czy nie) jest aktualnie uzywana.˙ Tutaj pojawi ˛asi˛eproblem synchronizacji zawarto´scitych pami˛eci,tak aby wszystkie procesory ”wiedziały” która cz˛e´sćpami˛ecijest aktualnie dost˛epna,a która nie. Rozwi ˛azanie takie nosi nazw˛e Cache Coherent NUMA (w skrócie ccNUMA). Dawniej zadanie optymalizacji aplikacji pod k ˛atem ccNUMA oraz synchronizacje pami˛ecipodr˛ecznychpozostawiano pro- gramistom za pomoc ˛a IPC, czyli Inter Process Communication, co zdecydowanie nie było dobrym rozwi ˛azaniem,nie pozwalało w pełni wykorzystaćmozliwo´sciarchitektury˙ NUMA.

Rozwi ˛azaniemtego problemu jest sprz˛etowesynchronizowanie tej cz˛e´sci cache procesorów, która odpowiada za obraz pami˛eci,oczywi´scieza pomoc ˛aspecjalnego układu. Rozwi ˛azania takie stosuje si˛ena przykład w procesorach opteron firmy AMD. Aby wi˛echypervisor mógł efektywnie wykorzystaćdany sprz˛etmusi być´swiadomczy działa na architekturze NUMA.

41 1.8.5 Topology Aware Scheduler

Skoro ”nauczyli´smy”juz˙ hypervisor efektywnego działania na architekturze NUMA, czas i´s´co krok dalej i zaj ˛a´csi˛etopologi ˛asprz˛etuna którym hypervisor b˛edziepracował. Jak kto´s kiedy´sm ˛adrzestwierdził porównuj ˛acprocesory AMD i Intela, z pułapu 10 000 stóp wygl ˛adaj˛a bardzo podobnie, jednak jak to zwykle bywa diabeł tkwi w szczegółach. Mimo iz˙ obydwie korporacje maj ˛aw swojej ofercie procesory 4 rdzeniowe znacz ˛acorózni˙ ˛asi˛eone budow ˛a.

Intel jako pierwszy wprowadził na rynek taki procesor pod nazw ˛a Core 2 Quad (Xeon7 na rynku serwerowym) i tak naprawd˛es ˛ato tylko 2 sklejone procesory architektury Core 2 Duo, nic wi˛ecej.Rozwi ˛azanietakie ma oczywi´scieswoje plusy i minusy. Z pocz ˛atkuna pewno b˛edzie tańszew produkcji, gdyz˙ nie musimy projektowaćnowego procesora prawie ”od zera”, a cała infrastruktura juz˙ produkuje potrzebne komponenty. Z drugiej strony wydajno´sćkomunikacji mi˛edzyrdzeniami zalezy˙ od tego które dwa rdzenie ze sob ˛a”rozmawiaj ˛a”.Ma to bardzo duze˙ znaczenie przy rozdzielaniu w ˛atkówprzez scheduler czyli algorytm szeregowania. Przewaznie˙ nie zna on budowy procesorów i wszystkie rdzenie traktuje z jednakowym priorytetem, co znacznie ułatwia jego implementacje, cierpi jednak na tym wydajno´sć. Nie jest to tak istotne gdy musimy obsłuzyćjeden˙ taki procesor, wtedy prosta implementacja schedulera zdaje egza- min. Schody zaczynaj ˛asi˛edopiero w konfiguracjach wieloprocesorowych.

Rozwi ˛azaniemjest tutaj topology aware scheduler, czyli algorytm szereguj ˛acy, który ma zaimplementowane róznice˙ w budowie procesorów. Wie, ze˙ w przypadku Core 2 Quad kazde˙ 2 rdzenie posiadaj ˛awspóln ˛apami˛eć cache L2, wie tez,˙ ze kolejne 2 rdzenie (nieparzysty oraz parzysty) b˛ed˛arozmawiać,ze sob ˛abezpo´srednio, a kazde˙ 2 rdzenie (parzysty oraz nieparzysty) b˛ed˛aroz- mawiały przez szyn˛e FSB. B˛edzietez˙ musiał wiedzieć, ze˙ rdzenie które nie rozmawiaj ˛aze sob ˛a bezpo´srednio, maj ˛atakie same opó´znieniado innych rdzeni nie rozmawiaj ˛acychbezpo´srednio, niezaleznie˙ od procesora. Kolejnym aspektem jest wspólna pami˛eć cache, o wiele bardziej opłaca si˛erozdzielaćw ˛atkina 2 rdzenie, które rozmawiaj ˛aze sob ˛abezpo´srednio i posiadaj ˛a wspóln ˛apami˛ećpodr˛eczn˛a,pomijaj ˛ackorzy´sciz wi˛ekszejwydajno´scidochodzi tutaj jeszcze kwestia lepszego wykorzystania pami˛eci cache, gdyz˙ gdyby w ˛atkizostały przydzielone na rdzeniach nie rozmawiaj ˛acychze sob ˛abezpo´srednio, to informacje w pami˛ecipodr˛ecznejbyłyby zdublowane w dwóch miejscach. Jest to bardzo nieefektywne, zwłaszcza ze˙ pami˛ećta jest małych rozmiarów i do tego dosyćdroga w produkcji. Przykładem implementacji takiego schedulera jest ULE z systemu FreeBSD. Schemat sposobu komunikacji rdzeni w procesorach Core 2 Quad przestawia rysunek 1.32.

Zupełnie inaczej jest w przypadku procesorów AMD. Natywna konstrukcja pozwala na szybka komunikacje wszystkich 4 rdzeni w obr˛ebieprocesora, nie ma tez potrzeby przydzielania w ˛atkówparami, gdyz˙ kazdy˙ rdze´nposiada swoj ˛awłasn ˛apami˛e´c cache L2, a do dyspozy-

7Jedyna róznica˙ pomi˛edzyprocesorami Core 2 oraz Xeon polega na tym, ze˙ te pierwsze maj ˛aprogramowo zablokowan ˛amozliwo´sćpracy˙ w konfiguracjach SMP w firmware procesora.

42 Rysunek 1.32: Sposób komunikacji rdzeni w procesorach Core 2 Quad. cji wszystkich 4 rdzeni jest jeszcze dodatkowa współdzielona pami˛e´cL3. Jedyne opó´znienia wi˛ecjakie wyst˛epuj˛a,to opó´znieniaw komunikacji pomi˛edzyrdzeniami róznych˙ procesorów. Schemat komunikacji rdzeni w procesorze AMD o architekturze K10 przedstawia rysunek 1.33.

Rysunek 1.33: Sposób komunikacji rdzeni w procesorach architektury K10.

Scheduler hypervisora powinien tez˙ wiedzie´co logicznych procesorach, stosowanych w

43 procesorach Intela z technologi ˛a HTT czyli Hyper Threading Technology. Pozwala ona uzywać˙ jednego fizycznego rdzenia jako dwóch logicznych w celu doci ˛azenia˙ układów procesora, gdyz˙ cz˛estojest tak, iz˙ wiele jednostek CPU nie jest wykorzystywanych w tym samym czasie. Gdy jeden w ˛atekkorzysta z jednostki FPU inny moze˙ korzystaćz układu ALU i odwrotnie, podobnie z rejestrami procesora. Algorytm szeregowania procesów, który nie jest ´swiadomtakiego rozwi ˛azania,b˛edzieobci ˛azał˙ logiczne rdzenie tak samo mocno jak fizyczne, co prowadzi do spadków wydajno´sci.Rozwi ˛azanie HTT w praktyce przedstawia rysunek 1.34.

Rysunek 1.34: Jednostki wykonawcze procesora z wł ˛aczon˛a/wył˛aczon˛aobsług ˛a HTT.

1.8.6 Zarz ˛adzanieenergi ˛ai skalowanie

Poza wydajno´sci˛abardzo wazne˙ znaczenie ma równiez˙ pobór mocy danej platformy, bo co z tego, ze˙ osi ˛agaona bardzo dobr ˛awydajno´sć,jezeli˙ na jej utrzymanie wydajemy krocie. Nie tylko w wirtualizacji coraz bardziej zaczyna si˛eliczyćwspółczynnik performance per watt, czyli wydajno´sćjak ˛aosi ˛agniemyprzy danym zuzyciu˙ energii, im taki wska´znikwyzszy˙ tym lepiej oczywi´scie.

Jedn ˛az metod jest skalowanie pr˛edko´sci˛ai napi˛eciemprocesorów czy tez˙ ich rdzeni. Rozwi ˛azanie takie skutecznie obniza˙ zarówno zuzycie˙ pr ˛adujak i temperatur˛ewewn ˛atrzkomputera. Py- tanie tylko ”komu” tak naprawd˛epozostawićzarz ˛adzanie,czy hypervisor ma decydowaćna ile system guest obci ˛aza˙ procesory i je skalować,czy tez˙ dostarczyćsystemowi guest standardowe mechanizmy skalowania procesora i to wła´sniejemu pozostawićzarz ˛adzanie.Zalezy˙ to od tego jak przydzielamy procesory maszynom wirtualnym. Jezeli˙ dany system guest b˛edzie posiadał na wył ˛aczno´sćjeden lub kilka rdzeni tego samego procesora, czy tez˙ kilka proce-

44 sorów, wtedy teoretycznie sterowanie owym mechanizmem mozemy˙ pozostawi´csystemowi guest. Jezeli˙ natomiast dzielimy procesor czy tez rdze´nna kilka maszyn wirtualnych, wtedy lepszym rozwi ˛azaniemb˛edziepozostawienie decyzji i sterowania hypervisorowi.

Mimo wszystko lepszym podej´sciemb˛edziechyba jednak pozostawienie nad tym mechanizmem pełnej kontroli hypervisorowi, jest tutaj kilka mocnych argumentów za. Nie wszystkie systemy operacyjne obsługuj ˛askalowanie procesora, jezeli˙ b˛edzieza to odpowiadaćhypervi- sor, wówczas mamy pewno´sć, ze˙ tak czy tak procesory b˛ed˛asie odpowiednio skalować,nawet w przypadku gdy jeden procesor, czy tez rdzeńjest przydzielony wi˛ecejniz˙ jednemu systemowi guest. Do tego dochodzi równiez˙ mozliwo´sć”gaszenia”˙ zarówno rdzeni jak i całych procesorów, na przykład na systemach, które ”nudz ˛asi˛e”przez kilka godzin na dob˛e,b˛edzieto prowadzićdo kolejnych oszcz˛edno´sci.Na systemach o małym obci ˛azeniu˙ hypervisor mógłby na przykład przenie´sćwszystkie procesy na 1 rdzeń,a pozostałe wył ˛aczyć,do tego zwolnići obnizyćnapi˛eciedla˙ tego ostatniego, jezeli˙ obci ˛azenie˙ b˛edziewystarczaj ˛acomałe.

Pozostaje jeszcze kwestia sprz˛etowa,procesowy musz ˛aobsługiwa´cte rozwi ˛azania,zarówno skalowanie jak i usypianie czy tez˙ wył ˛aczanie.Obecnie procesory zarówno serwerowe jak i te przeznaczone na desktop obsługuj ˛azarówno skalowanie, obnizanie˙ napi˛eciajak i wył ˛aczanie poszczególnych rdzeni, pozostaje wi˛ecodpowiednia implementacja tych rozwi ˛aza´n,tak aby hypervisor mozliwie˙ najefektywniej wykorzystywał sprz˛et.

1.8.7 Sprz˛etowaakceleracja graﬁki

Wiele aplikacji do poprawnego działania wymaga sprz˛etowejakceleracji graﬁki 3D, do niedawna maszyny wirtualne oferowały jedynie programowe wy´swietlanieobrazu, niestety tylko w 2D ale nawet wtedy zbyt wolno by pozwoli´cna komfortow ˛aprac˛e.Uzywanie˙ czegokol- wiek w trzech wymiarach po prostu mijało si˛ez celem.

Wirtualizacja układu GPU jest co najmniej problematyczna, z kilku powodów. W wi˛ekszo´sciprzypadków mamy dost˛epjedynie do binarnych sterowników kart graficznych, nie mamy wi˛ecnajwazniejszego,˙ czyli kodu ´zródłowegosterownika. Kolejn ˛aprzeszkod ˛ajest to, iz˙ karty graficzne z roznych˙ generacji posiadaj ˛arózne˙ niekompatybilne interfejsy [de Lara / H. A. Lagar-Cavilla, 2006]. Nie posiadamy tez˙ specyfikacji samych układów. Co prawda ostatnio wiele si˛ezmieniło w tym temacie in plus dzi˛ekitemu, ze˙ firma AMD wydała dokumentacj˛e 2D swoich nowszych układów z serii R600 bez potrzeby podpisywania NDA8 przez dewelop- erów, dokumentacja 3D ma zostaćopublikowana w najblizszym˙ czasie. Na płaszczy´znieot- warto´scinajlepszym wyborem nadal pozostaje Intel ze swoimi otwartymi sterownikami. Dostar- czył takze˙ pełn ˛adokumentacj˛eukładów 965G oraz G35, opisuje ona kompletn ˛aspecyfikacje 2D oraz 3D, a nawet dokładny opis akceleracji wideo. Powoli swoje sterowniki otwiera tez˙ VIA,

8 Non Disclosure Agreement to umowa poufno´scicz˛estowymagana przy otwieraniu specyﬁkacji sprz˛etu.

45 jednak nie mozna˙ tutaj na razie mówi´co tak duzych˙ porcjach danych jak w przypadku AMD. Na szarym ko´ncunadal pozostaje nVidia, która nie dostarcza zadnego˙ wsparcia programis- tom, ani w postaci dokumentacji, ani w postaci otwartego sterownika9.

Małym ´swiatełkiemw tunelu jest tutaj projekt Nouveau, który podj ˛ałsi˛ejakze˙ trudnego zadania napisania otwartych sterowników dla kart nVidii od zera, na bazie metody podobnej do reverse enginering, podobnej gdyz˙ EULA kart nVidia dodatkowo zabrania takiego poznawa- nia działania sterowników.

VMGL

Jednym z rozwi ˛azańtego problemu jest przechwytywanie i wykonywanie instrukcji OpenGL z systemu guest bezpo´srednio na karcie graficznej systemu host, a nast˛epniezwrócenie wyników do systemu guest. Wielkim plusem takiego rozwi ˛azaniajest jego prostota, oraz efektywno´sć, gdyz˙ nie ma tutaj miejsca zadna˙ emulacja, podwójne kopiowanie, czy tez˙ binarna translacja w locie. Jedyne opó´znieniepolega jedynie przekazaniu odpowiednich instrukcji OpenGL z systemu guest do karty graficznej systemu host i z powrotem. Rozwi ˛azujeto problem zarówno binarnych sterowników jak i jednego spójnego interfejsu, gdyz˙ wszystkie karty z ostatnich lat w pełni obsługuj ˛astandard OpenGL. Niestety wad ˛ategoz˙ rozwi ˛azaniajest to, iz˙ działa tylko dla aplikacji 3D, które korzystaj ˛az ... OpenGL. W przypadku aplikacji uzywaj˙ ˛acychzamkni˛e- tych interfejsów (czyli properitary) pokroju Direct3D, nic nie mozemy˙ zrobić.

Takie wła´sniepodej´scieoferuje technologia VMGL, pozwala na wieloplatformow ˛awirtualizacj˛eobrazu 3D za pomoc ˛ainstrukcji OpenGL. Jest niezalezna˙ zarówno od hypervisora, sys- temów guest jak i konkretnych modeli kart graficznych. VMGL do przekazywania instrukcji systemu guest uzywa˙ WireGL, które posiada kilka waznych˙ rozwi ˛azańznacznie poprawiaj ˛a- cych wydajno´sć.Instrukcje OpenGL s ˛aagregowane i przesyłane ”paczkami” a nie pojedynczo, a obliczenia dotycz ˛atylko miejsc na ekranie, które uległy zmianie. Dodatkowo przekształcenia nie s ˛anakładane jedno po drugim, ale ł ˛aczones ˛aw jedno przekształcenie i dopiero nakładane. Rozwi ˛azanieto dost˛epnejest dla praktycznie kazdej˙ licz ˛acejsi˛ena rynku technologii wirtualizacji: Xen (HVM / parawirtualizacja), Virtualbox, QEMU, KVM czy nawet VMware.

GPGPU

Renderowanie grafiki to nic innego jak wysyłanie danych do obliczeńi zwrócenie wyniku na ekran, róznica˙ polega tylko na tym, którym interfejsem owy wynik otrzymamy. Moze˙ to być OpenGL, Direct 3D czy nawet technologia GPGPU (General Purpose Computing on Graphics Processing Units. Nic nie stoi na przeszkodzie, aby wła´snieten ostatni mechanizm wykorzystać w przypadku wirtualizacji systemu guest i za jego pomoc ˛agenerowaćobraz 3D. Rozwi ˛azanie

9Dost˛epnyjest jedynie sterownik dla serwera X11 oferuj ˛acypodstawow ˛aobsług˛e2D. 46 takie moze˙ byćrealizowane przez wirtualne urz ˛adzenie,które hypervisor wystawi systemowi guest, system guest za´sb˛edziewymagał odpowiedniego sterownika. Hypervisor za´sb˛edzie odbierał z˙ ˛adaniawirtualnej karty graficznej, wysyłał je do prawdziwej karty graficznej, a rezul- tat wysyłał do systemu guest.

Rozwi ˛azanietakie jest bardzo elastyczne, gdyz˙ karty graficzne posiadaj ˛apewn ˛ailo´sćzu- nifikowanych jednostek obliczeniowych unified shaders, te z najwyzszej˙ półki posiadaj ˛aich setki. Przydzielaj ˛acsystemowi guest tak ˛awirtualn ˛akart˛egraficzna, mozemy˙ zdecydowaćile takich jednostek uzyć,co˙ wi˛ecej,mozliwe˙ byłoby tez˙ bardzo wygodne zarz ˛adzanietakimi jed- nostkami, tak samo jak w przypadku rdzeni procesorów przydzielanych maszynie wirtualnej. Wymagaj ˛acemu´srodowiskowi b˛edziemozna˙ przydzielićsporo jednostek na sztywno, podczas, gdy innym mniej wymagaj ˛acymgraficznie systemów, przydzielićpewn ˛apul˛ejednos- tek do podziału. Rozwi ˛azanietakie nie jest aktualnie zaimplementowane, ale nic nie stoi na przeszkodzie aby takowe wdrozyć.˙

Jest wiele dost˛epnychrozwi ˛azańdo realizowania obliczeń GPGPU, CUDA jest rozwi ˛azaniem stosowanym przez koncern nVidia w swoich kartach graficznych. Firma nVidia starała si˛etakze˙ zach˛ecićswego najwi˛ekszegokonkurenta na polu kart graficznych czyli ATI do implementacji tejze˙ technologii. Ten ostatni na razie jednak nie zdecydował si˛ena ten krok, prawdopodobnie ze wzgl˛edówfinansowych, gdyz˙ nVidia na pewno b˛edziewymagaćodpowiednich opłat licen- cyjnych za korzystanie z owego rozwi ˛azania.

Firma ATI równiez˙ chciała uzywaćwłasnego˙ rozwi ˛azaniapod nazw ˛a Stream jednak zrezyg- nowano z niego na rzecz otwartego j˛ezyka OpenCL, czyli Open Computing Language. Mecha- nizm ten wykorzystuje rozwi ˛azaniatakie jak OpenGL (do grafiki) oraz OpenAL (do d´zwi˛eku). Obecnie OpenCL został zgłoszony do procesu standaryzacji, co po pozytywnym zatwierdze- niu przez organizacj˛e ISO z pewno´sci˛azwi˛ekszyjego konkurencyjno´sćpo´sródinnych rozwi ˛azań.

Wad ˛atego rozwi ˛azaniajest z pewno´sci˛aprzywi ˛azanie si˛edo układów tylko jednego producenta, niezaleznie˙ czy wybierzemy CUDA czy OpenCL. Wazne˙ jest, aby w końcufirmy doszły do porozumienia i wspierały jeden wspólny standard, najlepiej OpenCL gdyz˙ jest otwarty, i korzysta z otwartych rozwi ˛azań.Firma nVidia na pewno nie zrezygnuje ze swego rozwi ˛azania CUDA, wi˛ecjest tez˙ szansa, ze˙ i ATI z czasem jednak skusi si˛ena jej implementacj˛e,chociaz˙ nie jest to nic pewnego.

Warto takze˙ wspomniećo niedawnym prototypie karty graficznej Intela o nazwie kodowej Larrabee. To w pełni programowalny10 układ wyposazony˙ w rdzenie architektury i386 (do- celowo od 8 do 48 rdzeni), swego rodzaju hybryda CPU i GPU. Obsługuje standardowe API jak OpenGL czy DirectX, ale pozwala takze˙ na ray tracing czy obliczenia fizyczne (inaczej physics processing). Oczywi´sciegłównym przeznaczeniem tego układu s ˛aobliczenia GPGPU

10Aktualne generacje kart graﬁcznych s ˛atylko w pewnym stopniu programowalne. 47 i bezpo´srednia konkurencja dla kart graﬁcznych nVidii i ATI.

Gallium3D

Rozwi ˛azanie Gallium3D to nowa biblioteka graficzna tworzon ˛aprzez form˛e Tungsten Graphics. Dostarcza ona wielu ciekawych mechanizmów, upraszcza pisanie sterowników oraz implementacje nowych API. Posiada tez˙ bardzo ciekawe rozwi ˛azaniepozwalaj ˛ace”podgl ˛a- dać”odwołania pomi˛edzysterownikiem a sprz˛etem.Pozornie nie brzmi to zbyt powalaj ˛aco, jest to jednak bardzo uzyteczna˙ funkcjonalno´sć,uzyteczna˙ nie tylko przy projektowaniu i pisa- niu sterowników. Mozna˙ j ˛awykorzystaćw wirtualizacji do przechwytywania zapytańsys- temu guest do karty graficznej, a potem wykonywaćje bezpo´srednio na karcie graficznej systemu host, zwrócenie wyników b˛edziejuz˙ wtedy jedynie formalno´sci˛a.Biblioteka Gallium3D b˛edziewykorzystywana do wirtualizacji GPU w nast˛epnejwersji hypervisora Xen 3.4.

Sprz˛etowawirtualizacja

Na koniec istniej ˛acei działaj ˛acerozwi ˛azanie,polegaj ˛acena wykorzystaniu sprz˛etowych rozszerzeńdo wirtualizacji operacji I/O, czyli VT-d lub IOMMU. Mozemy˙ zarówno ”oddać” cał ˛akart˛egraficzn ˛apod kontrol˛esystemu guest, jak i po prostu dzielićj ˛apomi˛edzywieloma systemami. Hypervisor musi jednak miećzaimplementowan ˛aobsług˛eowego rozszerzenia sprz˛etowego.

1.8.8 Seamless Mode

Rozwi ˛azaniestosowane na stacjach roboczych i desktopach. Dotychczas system guest uruchamiany był w swoim okienku, w czym´sna miano wirtualnego monitora, okno to jak kazde˙ inne podlegało menadzerowi˙ okien danego ´srodowiska, w którym uruchamiali´smy system guest. Bardzo utrudniona była wymiana plików pomi˛edzysystemem guest i host, korzys- tano na przykład z samby i montowania po sieci katalogu w systemie guest. I mechanizmie drag and drop mozna˙ było co najwyzej˙ pomarzy´c,podobnie jak o wygodnej pracy w takim ´srodowisku. To tradycyjne podej´scieprzedstawia rysunek 1.35.

Tryb seamless mode (zamiennie zwany równiez˙ coherence) to tryb wirtualizacji, w którym aplikacje uruchomione w systemie guest, zachowuj ˛asi˛etak jakby były aplikacjami uruchomionymi w systemie host. Podlegaj ˛amenadzerowi˙ okien systemu host, działa mechanizm drag and drop, a dzielenie plików jak i zwykła praca jest o wiele wygodniejsza. Rozwi ˛azanieto przedstawia rysunek 1.36.

48 Rysunek 1.35: Wirtualizacja systemu guest w oknie.

Rysunek 1.36: Wirtualizacja w trybie seamless mode.

Rozwi ˛azanieto przewaznie˙ działa tylko w ”jedn ˛astron˛e”,mianowicie implementuje si˛e ten tryb dla wirtualizacji systemu Windows, tak aby mozna˙ byłoby go wygodnie wirtualizowa´c na innych systemach operacyjnych. Spowodowane jest to tym, iz˙ sporo specjalistycznego oprogramowania dost˛epnegojest na ”jedyny słuszny system operacyjny” a producenci cz˛esto nie widz ˛apotrzeby portowania swoich aplikacji na inne systemy, lub tez˙ dostarczone przez nich programy nie posiadaj ˛apełnej funkcjonalno´scioryginalnego programu. Swego rodzaju wyj ˛atkiemjest tutaj wirtualizacja systemu Windows XP na systemie Windows Vista jest to jednak spowodowane spor ˛awadliwo´sci˛ai nieprzewidywalno´sci˛atego ostatniego, ale spora cz˛e´s´c producentów nie widzi juz˙ potrzeby wydawania sterowników na starsz ˛aodmian˛esystemu z Redmond, a na nowszy nie ma dost˛epnejnaszej aplikacji, b ˛ad´ztez˙ praca z ni ˛ajest w nim niemozliwa.˙

49 Mozliwa˙ jest tez˙ ograniczona realizacja tego mechanizmu przez protokół RDP (czyli Re- mote Desktop Protocol), po prostu ł ˛aczymysi˛ez wybranym komputerem, czy tez˙ maszyn ˛awirtualn ˛ai uruchamiamy na niej wybran ˛aaplikacj˛e,wynik otrzymujemy w postaci okna samej aplikacji na naszym pulpicie. Mozemy˙ jednak zapomnie´co drag and drop.

1.9 Zalety

Srednie´ obci ˛azenie˙ serwera si˛egaokoło 5-10%, oznacza to, ze˙ przez wi˛ekszo´sćczasu serwer po prostu nic nie robi, lub robi bardzo niewiele. Uzywanie˙ wi˛ekszejilo´sciserwerów z takim obci ˛azeniem˙ jest po prostu nieopłacalne, wyzsze˙ rachunki za energi˛eelektryczn ˛aczy dodatkowe obci ˛azenie˙ klimatyzacji, a takze˙ wi˛ekszekoszty samego sprz˛etu.Zamiast kupowaćkilka fizycznych serwerów które ”b˛ed˛asi˛enudzić”mozemy˙ kupićjeden mocniejszy i na nim za pomoc ˛awirtualizacji postawićpotrzebne systemy. Bardzo zwi˛ekszato utylizacj˛e i konsolidacj˛e naszego sprz˛etu,a koszty funkcjonowania s ˛ao wiele mniejsze. Oznacza to takze˙ oszcz˛edno´sci w innych aspektach centów danych, mniej komputerów oznacza mniej potrzebnego miejsca, znacznie mniejsze zapotrzebowanie na klimatyzacj˛e. Nalezy˙ jednak pami˛etać, ze˙ na jednym fizycznym serwerze mog ˛akomfortowo współdziałaćusługi, które nie wymagaj ˛atych samych zasobów w tym samym czasie. Musimy wi˛ecodpowiednio rozłozyćnasze˙ usługi pomi˛edzy dost˛epnysprz˛etaby maksymalnie go wykorzystać.

Maj ˛acuruchomionych wiele usług na jednym serwerze, mozemy˙ stan ˛a´cw sytuacji, gdy jedna z usług przez swoje tymczasowe wadliwe działanie odbiera czy to zasoby, czy tez˙ w ogóle uniemozliwia˙ działanie pozostałym usługom w naszym systemie. Za pomoc ˛awirtualizacji mozemy˙ od siebie odseparowa´c wszystkie nasze usługi, przez co jakakolwiek awaria jednej z usług nie poci ˛agnieza sob ˛aawarii pozostałych usług.

Wirtualizacja, pozwala na o wiele wygodniejsze zarz ˛adzanie cał ˛anasz ˛ainfrastruktur ˛a,im wi˛ekszainfrastruktura, tym bardziej docenimy ow ˛awygod˛e.Cały nasz serwer, czy tez˙ usługa moze˙ znajdowaćsi˛ew jednym pliku na dysku. Mozemy˙ go przenie´sćna inny serwer i tam uruchomić,mimo iz˙ b˛edzietam zupełnie inny sprz˛et(a czasami nawet zupełnie inna architektura). Bardzo ułatwia to takze˙ robienie kopii zapasowych.

Jezeli˙ korzystamy z odpowiednich rozwi ˛azańto mozemy˙ przenie´sćdziałaj ˛ac˛amaszyn˛e wirtualn ˛a na inny serwer, bez przerywania jej pracy. Mozemy˙ takze˙ korzystaćze snapshotów naszych maszyn, czyli uruchomićusług˛ez pewnego okre´slonegomiejsca w czasie, na przykład z poprzedniego tygodnia. Innym bardzo uzytecznym˙ rozwi ˛azaniemjest zatwierdzanie zmian

50 w momencie, gdy jeste´smyzadowoleni ze zmian wprowadzonych do naszego serwera czy tez˙ usługi, czyli tak zwany commit. Jezeli˙ nie jeste´smyzadowoleni, lub po prostu co´sposzło nie tak, uruchamiamy maszyn˛ewirtualn ˛anaszego serwera i mamy stan sprzed kłopotliwych zmian.

Wirtualizacja jest równiez˙ ´swietnymrozwi ˛azaniemdo debugowania nowych rozwi ˛azań, j ˛adrasystemu operacyjnego czy nawet całych klastrów. Dotyczy to takze˙ testowania nowych usług czy serwerów, mozemy˙ bardzo łatwo i szybko stworzyćodpowiednie testowe wirtualne ´srodowisko, bez wpływu na prac˛epozostałych naszych usług czy serwerów. Mozemy˙ wi˛ec dowolnie testowaćnowe rozwi ˛azaniabez obawy, niezaleznie˙ od tego czy s ˛abezpieczne czy nie.

Nic nie stoi na przeszkodzie aby uzywa´cwielu˙ róznych˙ systemów operacyjnych na jednym serwerze, Windows, FreeBSD, Solaris, czy jakikolwiek inny system który przyjdzie nam do głowy. Podobnie z poszczególnymi rozwi ˛azaniami,które s ˛adost˛epnena wybrane platformy, nie jeste´smyjuz˙ wi˛ecej”przywi ˛azani”do jednego rozwi ˛azania.

Dotychczas aby przetestowaćjakie´srozwi ˛azanie,potrzeba było całego serwera aby nie było zagrozenia˙ ”uszkodzenia” pozostałych usług. Trzeba było si˛eupewnić, ze˙ dostawiaj ˛ac kolejny serwer b˛edziewystarczaj ˛acochłodzenia i pr ˛adu,potem oczywi´sciezainstalowaćtam odpowiedni system operacyjny i dopiero rozpocz ˛aćtestowanie naszego nowego rozwi ˛azania czy tez˙ usługi. Jezeli˙ nie posiadamy odpowiedniego sprz˛etuna nowy serwer nalezy˙ oczywi´scie jeszcze doliczyćczas na dostaw˛e.Uzywaj˙ ˛acwirtualizacji zadanie to sprowadza si˛edo minut, jest tylko kwesti ˛apodania przez nas ilu zasobów przydzielimy nowej ”maszynie” testowej i jaki b˛edziemiała adres IP, po chwili mozemy˙ juz˙ testowaćnasze nowe rozwi ˛azania.

Awarie maj ˛ato do siebie, ze˙ przytrafiaj ˛asi˛ew najmniej odpowiednim momencie, dzi˛eki wirtualizacji dana usługa moze˙ zostaćprzywrócona automatycznie do pracy, bez potrzeby ´sci˛aganiaadministratorów w ´srodku nocy w celu naprawienia i przywrócenia usług, dzi˛eki wirtualizacji mog ˛asi˛etym spokojnie zaj ˛aćnast˛epnegodnia.

Dzi˛ekiwirtualizacji nasze usługi b˛ed˛aposiadały wi˛ekszestopień high availability, gdyz˙ w przypadku gdy jeden z naszych serwerów padnie, czy tez˙ b˛edziemywidzieć, ze˙ dzieje si˛ez nim co´snie tak, mozemy˙ przenie´sćnasze usługi na inny fizyczny serwer. Mozemy˙ takze˙ uru- chomićkilka takich samych instancji naszych usług na kilku fizycznych serwerach zapewniaj ˛ac sobie pełn ˛aochron˛eprzed takimi awariami, na przykład za pomoc ˛aprotokołu Virtual Router Redundancy Protocol.

Jezeli˙ kto´swłamie nam si˛edo jednej z naszych maszyn wirtualnych, to tylko do niej, stracimy jedna usług˛ea nie kilka czy kilkana´scie,do tego w kazdej˙ chwili mozemy˙ przywrócićnasz ˛a usług˛ew praktycznie kilka minut, kwestia podmiany obrazu z maszyn ˛awirtualn ˛ai jej uruchomienie. 51 W przypadku zamkni˛etychaplikacji, których potrzebujemy do pracy, a nie s ˛aone dost˛epne na naszej platformie, nie musimy juz˙ m˛eczyćsie w dual boot czyli restartowaćkomputer w celu uruchomienia innego systemu operacyjnego, teraz z trybem seamless mozemy˙ po prostu wygodnie pracowaćna dwóch systemach jednocze´snie.

1.10 Wady

Zaleznie˙ od wykorzystanego przez nas rozwi ˛azania,mozemy˙ spodziewaćsi˛epewnego spadku wydajno´sci, w stosunku do pojedynczej maszyny, jednak w przypadku serwerów których ´srednie obci ˛azenie˙ si˛ega5-10% nie powinno miećto wi˛ekszegoznaczenia. W dodatku wirtualizacja na poziomie systemu operacyjnego zapewnia t ˛asam ˛awydajno´sćco natywnie, gdyz˙ korzysta bezpo´srednio z j ˛adrasystemu host. Równiez˙ parawirtualizacja zapewnia pr˛edko´sćblisk ˛anatywnej, tak wi˛ecspadki wydajno´scis ˛azalezne˙ od stosowanego przez nas rozwi ˛azania.

Architektura i386 nie była projektowana z my´sl˛ao wirtualizacji, a aktualne rozszerzenia sprz˛etowenie zawsze zapewniaj ˛aodpowiedni ˛awydajno´sć.Inn ˛awad ˛ajest, ze˙ aby skorzystać z wielu metod wirtualizacji musimy zakupićsprz˛etwyposazony˙ w odpowiednie rozszerzenia sprz˛etowedo wirtualizacji.

Wirtualizacja jest bardzo dobrym rozwi ˛azaniemi w pewnych sytuacjach po prostu nie opłaca si˛ejej nie stosować, wazne˙ jednak jest, aby cała infrastruktura wirtualizacji została odpowiednio zaprojektowana, przez kogo´skto posiada odpowiednie do´swiadczenie w tym temacie. Moze˙ si˛eprzeciez˙ zdarzyć, ze˙ zajmie si˛etym zadaniem osoba niewykwalifikowana, dopiero zaczynaj ˛acaprac˛ez wirtualizowanymi ´srodowiskami i popełni wiele bł˛edówprojek- tuj ˛acwirtualn ˛ainfrastruktur˛e,co niestety zrobi wi˛ecejzłego niz˙ dobrego, nalezy˙ wi˛ecdopisać do kosztów zdobycie do´swiadczaniai odpowiedniej wiedzy na temat wirtualizacji aby j ˛aefek- tywnie i bezpiecznie stosować.

52 1.11 Zastosowania

Wirtualizacja ma tak wiele zastosowań, ze˙ ogranicza nas praktycznie tylko wyobra´znia i pomysłowo´sć. Na rynku istnieje bardzo wiele wyspecjalizowanych maszyn wirtualnych, zarówno przeznaczonych na serwery, stacje robocze jak i zwykły desktop. Rozwi ˛azania open source oraz properitary przeznaczone do uzytku˙ domowego i korporacyjnego. Daje to cały wachlarz róznych˙ mozliwych˙ zastosowań,w zalezno´sciod˙ potrzeb.

Przede wszystkim konsolidacja. Maj ˛acdo dyspozycji kilkana´scie,a czasem nawet kilkadziesi ˛atrdzeni, wirtualizacja umozliwia˙ nam najefektywniejsze wykorzystanie takiej mocy. B˛edziemymogli podzielićzasoby takiego systemu pomi˛edzywielu klientów, zupełnie tak jakby pracowali na kilku niezaleznych˙ maszynach, kazdy˙ moze˙ miećzupełnie inny system operacyjny, z innym zestawem oprogramowania, cz˛estodo zupełnie innych zastosowańniz˙ po- zostali klienci. Na przykład jeden z klientów b˛edziemiał przydzielone 4 rdzenie i 2 dedykowane karty sieciowe, gdyz˙ serwuje strony www z baz ˛adanych, inny klient b˛edziekorzystał z karty sieciowej i procesorów dzielonych pomi˛edzypozostałymi klientami, a jeszcze kolejny klient b˛edziemiał dedykowane 8 rdzeni, gdyz˙ jest developerem Java i potrzebuje duzej˙ mocy obliczeniowej.

Innym zastosowaniem wirtualizacji jest testowanie i pisanie nowych rozwi ˛azań,zwłaszcza tych niskopoziomowych zwi ˛azanychz systemami operacyjnymi, klastrami i sieciami. Nic nie stoi na przeszkodzie aby´smyuruchomili 16 identycznych maszyn wirtualnych w celu testowania wydajno´scioprogramowania klastra uruchomionego na tychze˙ 16 systemach. Wirtualiza- cja zapewnia tutaj duze˙ oszcz˛edno´scina wielu szczeblach. Bez wirtualizacji musieliby´smy posiadać16 fizycznych maszyn, których koszt byłby z pewno´sci˛aniemały, co prawda maszyna na której b˛edziemytestowaćnasz klaster równiez˙ powinna posiadaćodpowiednio wi˛eksz˛a moc, ilo´sćrdzeni i pami˛eci,jednakze˙ ceny tych podzespołów zeszły juz˙ do takiego poziomu, ze˙ i tak b˛edzieto bardziej opłacalne niz˙ wiele słabszych komputerów.

Drastycznie obniza˙ to pobór mocy naszego zestawu testowego, inna sprawa gdzie trzy- maćtak ˛ailo´sćkomputerów, a jedyn ˛asensown ˛aodpowiedzi ˛awydaje si˛ebyćprofesjonalna serwerownia. Dochodzi tez˙ kwestia wygody testowania tych rozwi ˛azań,jezeli˙ jeden z serw- erów składaj ˛acychsi˛ena ten klaster si˛ezawiesi, musimy si˛edo niego przej´sći go zrestartować, a dzi˛ekiwirtualizacji wystarczyłoby zapewne jedna komenda. Nie wspominaj ˛acjuz˙ o tym, ze system uruchomiony w maszynie wirtualnej uruchomi si˛eo wiele szybciej niz˙ na fizycznym komputerze, gdzie wiele czasu tracimy na sam BIOS POST. Mozemy˙ tez˙ si˛eograniczyćdo wyjmowania odpowiednich skr˛etekze switcha, ale dalej b˛edzienas to odci ˛agałood samego procesu testowania, a wirtualizacja i tak załatwi to lepiej i efektywniej.

Inn ˛azalet ˛awykorzystania wirtualizacji jest z pewno´sci ˛afakt, ze˙ mozemy˙ przetestować kazde˙ z dost˛epnychrozwi ˛azańbez obawy o bezpieczeństwonaszej infrastruktury, gdyz˙ jedyne szkody (jezeli˙ w ogóle si˛eprzydadz ˛a)zostan ˛awyrz ˛adzonewewn ˛atrzmaszyny wirtual-

53 nej, czyli nie maj ˛atak naprawd˛e zadnego˙ znaczenia.

Załózmy,˙ ze˙ blizej˙ nieokre´slonyczas temu zmienili´smysystem na Linux, znale´zli´smyjuz˙ zamienniki dla naszych ulubionych programów, z którymi byli´smyprzyzwyczajeni pracować na co dzieńna platformie Windows. Jest nam tu dobrze, mamy co chcemy i mozemy˙ pra- cować.Brakuje nam jednak jednego programu, akurat tego ulubionego, lub po prostu dla nas kluczowego. Wiele osób decyduje si˛ena dual boot z systemem Windows pozostawionym na jednej z pozostałych partycji dysku w celu posiadania dost˛eputej jednej aplikacji.

Zawsze to jakie´srozwi ˛azanie,jednak jest ono problematyczne i nieefektywne, pomijaj ˛ac juz˙ nasze delikatnie mówi ˛acniezadowolenie z oczekiwania na przeładowanie systemu, czy to w jedn ˛aczy w drug ˛astron˛e.Innym wyj´sciemmoze˙ by´cuzywanie˙ implementacji API systemu Windows na systemach UNIX, któr ˛aoferuje projekt WINE, jednak mimo iz˙ projekt ten dynamicznie rozwija si˛eod ponad 15 lat to niestety nie zapewnia on jeszcze pełnej zgodno´sci. Tutaj wła´snieprzydaje si˛ewirtualizacja, przez uruchomienie całego systemu Windows zapewni nam natywne ´srodowisko pracy dla naszej aplikacji, a dzi˛ekiwspółdzieleniu plików z naszym systemem host zapewni nam łatw ˛awymian˛eplików na których pracujemy Do tego zaoszcz˛edzimy sporo czasu, gdyz˙ nie b˛edziejuz˙ konieczno´sciprzeładowywania systemów.

Jedn ˛az zalet hypervisora typu 1 (jak na przykład Xen) jest ukrywanie skomplikowanej architektury sprz˛etuprzed systemami guest. Istniej ˛asystemy operacyjne, które maj ˛aproblemy z efektywnym rozdzielaniem zadańna wi˛ecej niz˙ 4 procesory lub rdzenie. Monitor Xen moze˙ udost˛epnićsystemom guest po jednym wirtualnym procesorze a sam b˛edziesobie rozkładał obci ˛azenie˙ na fizyczne procesory. Mozemy˙ tutaj oczywi´sciewymieniaćjeszcze długo, gdyz˙ zastosowańwirtualizacji jest mnóstwo, ale niestety nie mamy miejsca na zaprezentowanie kazdego˙ z nich.

54 Rozdział 2

Dost˛epnemaszyny wirtualne

2.1 Hypervisor typu 1

2.1.1 Xen

http://xen.org

Monitor Xen to hypervisor typu bare metal dost˛epnyna architektury i386, amd64, ia64 oraz powerpc. Pocz ˛atkowozaprojektowany i rozwijany na University of Cambridge Computer Labora- tory, aktualnie jest własno´sci˛aformy Citrix ale nadal jest rozwijany przez ludzi z całego ´swiata na otwartej licencji GPL. Pozwala na współdziałanie wielu systemów guest jednocze´snie,zapewniaj ˛acprzy tym bardzo duz˙ ˛awydajno´s´ci swobod˛ew zarz ˛adzaniuzasobami. Xen to narz˛edziaklasy enterprise, bez dyskusji jeden ze standardów dzisiejszych rozwi ˛aza´nwirtualizacji.

W przypadku monitora Xen zarz ˛adzanieodbywa si˛eprzez uprzywilejowan ˛adomen˛ezarz ˛adza- j ˛ac˛a dom0, która przez odpowiednie podsystemy monitora kontroluje zasobami pozostałych systemów guest, zwanych tutaj domU, warto tez˙ wspomnie´c, ze˙ dom0 posiada pełny dost˛epdo sprz˛etu,podczas, gdy domeny domU maja przewaznie˙ przydzielane wirtualne zasoby, chociaz˙ z odpowiednimi rozszerzeniami sprz˛etowymi,mozliwe˙ jest równiez˙ im przekazani bezpo´sred- niej kontroli nad poszczególnymi cz˛e´sciamikomputera.

Aktualnie monitor Xen jest przeportowany na trzy systemy operacyjne, które mog ˛apełnić rol˛ezarz ˛adzaj˛ac˛a dom0, mianowicie Linux, NetBSD oraz OpenSolaris. O wiele wi˛ecejsys- temów jest przystosowanych do pracy w parawirtualizacji jako domU (zamiast syscall uzywa˙ si˛especjalnych odwołańhypervisora czyli hypercall), s ˛ato mi˛edzyinnymi Minix, Plan 9, OpenBSD, FreeBSD, NetWare czy mikroj ˛adraHurd oraz Mach. Oczywi´sciesystemy, które zostały przepor- 55 towane na dom0 zostały takze˙ przeportowane na domU. Mozliwe˙ jest tez˙ uruchamianie niez- modyfikowanych systemów operacyjnych jako domen˛e HVM, nalezy˙ jednak posiadaćproce- sor z odpowiednimi rozszerzeniami sprz˛etowymijak AMD-V czy VT-x.

Wydajno´sćjest na najwyzszym˙ poziomie, w przypadku parawirtualizacji jest ona bardzo bliska natywnej, do tego zaimplementowano specjalny mechanizm z wirtualnymi urz ˛adzeniami i parawirtualnymi sterownikami dla systemów guest, tak aby jak najwydajniej obsługiwać siećczy operacje I/O. W przypadku trybu HVM wiele zalezy˙ od procesora oraz chipsetu, oraz odpowiednich rozszerzeńsprz˛etowych jak VT-d, poza tym nowsze implementacje zarówno VT-x jak i AMD-V zapewniaj ˛aszybsze działanie i mniejsze opó´znieniaw stosunku do poprzednich wersji.

Nalezy˙ takze˙ wspomnie´c, ze˙ sporo kodu, zwłaszcza zwi ˛azanegoz wirtualizacj ˛aI/O pochodzi z projektu emulatora/monitora QEMU. Sam Xen składa si˛ez mniej niz˙ 150 000 linii kodu, co sprawia, ze˙ nie posiada zadnego˙ zb˛ednegobalastu opó´zniaj˛acegojego działanie, a jedyne to co niezb˛edne.Uzywa˙ istniej ˛acychjuz˙ otwartych sterowników z systemu Linux, dzi˛ekiczemu nie ma potrzeby pisania ich na nowo, a poza tym dostajemy ”gratis” cał ˛amas˛etesterów, którzy juz˙ dawno przetestowali owe sterowniki na systemie Linux.

Xen pozwala na migracj˛esystemów guest bez zatrzymywania ich pracy, po sieci LAN pomi˛edzyróznymi˙ komputerami. Pami˛e´csystemu guest jest na biez˙ ˛acokopiowana na drugi serwer co pozwala na przeniesienie bez przerywania pracy. Potrzebna jest jedynie ”przerwa” długo´sci60-300ms na ostateczn ˛asynchronizacj˛ei zako´nczenieprocesu migracji

Hypervisor xVM Server obsługuje aktualnie nast˛epuj˛acetechnologie: pełna wirtualizacja, parawirtualne sterowniki, smp guest, skalowanie procesora, obsługa nested page table.

2.1.2 xVM

http://xvmserver.org

Korporacja Sun wzi˛ełaogólno dost˛epnykod ´zródłowyprojektu Xen i stworzyła swój produkt pod nazw ˛a xVM, działa on pod kontrol ˛aﬂagowego systemu operacyjnego tejze˙ ﬁrmy, czyli OpenSolaris. Aktualna implementacja monitora xVM odpowiada wersji 3.1 monitora Xen.

56 Generalnie jego funkcjonalno´s´codpowiada funkcjonalno´scimonitora Xen. Przykładowy wynik polecenia xm list pokazuj ˛acegoaktualnie działaj ˛acedomeny przedstawia rysunek 2.1.

# xm list Name ID Mem VCPUs State Time(s) Domain-0 0 4947 4 r----- 151429.5 bsd70 45 1023 1 -b---- 121.3 linux26 33 1032 1 -b---- 1393.9

Rysunek 2.1: Wynik polecenia xm list.

Hypervisor xVM Server obsługuje aktualnie nast˛epuj˛acetechnologie: pełna wirtualizacja, parawirtualne sterowniki, smp guest, skalowanie procesora, obsługa nested page table.

2.1.3 VMware ESX

http://vmware.com/products/esx

Komercyjne produkty korporacji VMware stanowi ˛anajwi˛eksz˛akonkurencje dla wolnych rozwi ˛aza´nna rynku wirtualizacji, a monitor ESX jest w szczególno´scikonkurencj ˛adla Xen. Uzywa˙ zmodyﬁkowanego systemu Linux w starszej wersji 2.4 oraz swojego j ˛adrawłasno´s- ciowego1 j ˛adra vmkernel. Jadro VMware bezpo´srednio zarz ˛adzapami˛eci˛ai procesorami uzy-˙ waj ˛actechniki scan before execution (czyli w skrócie SBE, co umozliwia˙ mu przechwytywanie i obsług˛ewrazliwych˙ lub niebezpiecznych instrukcji systemów guest. Oferuje równiez˙ specjaln ˛akonsol˛edo zdalnego zarz ˛adzaniazwana vmnix, przedstawia j ˛a rysunek 2.2.

Wiele z modułów do obsługi sprz˛etumonitora ESX pochodzi ze sterowników systemu Linux, a sam monitor ma zaimplementowany specjalny moduł z API systemu Linux, aby uzywaćjego˙ modułów bez modyfikacji. Moduły te s ˛auzywane˙ głownie do niektórych kart sieciowych, oraz interfejsu i kontrolerów SCSI. Podobnie jak w przypadku Xen, równiez˙ tutaj dostarczane s ˛aspecjalne parawirtualne sterowniki aby korzystaćz wirtualnych urz ˛adzeńoraz specjalnych odwołańhypervisora aby maksymalnie zwi˛ekszyćprzepustowo´sćzarówno sieci jak i operacji I/O.

Pozwala na migracj˛ew czasie rzeczywistym na inny system host, czyli live migration praktycznie bez zatrzymywania pracy systemu guest, podobnie jak w przypadku swojego najwi˛ek-

1properitary

57 Rysunek 2.2: Konsola zarz ˛adzaj˛acamonitora VMware ESX. szego konkurenta zapewnia wydajno´sćna przyzwoitym poziomie. Nie ma systemów przystosowanych do parawirtualizacji na monitorze ESX, przez co wszystkie systemy działaj ˛aw trybie pełnej emulacji dzi˛ekimechanizmowi binary translation, nalezy˙ wi˛ecspodziewaćsi˛e wydajno´scinieco mniejszej niz˙ natywna na tym samym sprz˛ecie.Wyj ˛atkiemjest interfejs VMI, który jest zaimplementowany w systemach Linux, wi˛ecchociaz˙ ten system moze˙ pracowaćz pr˛edko´sci˛ablisk ˛anatywnej za pomoc ˛aparawirtualizacji.

Hypervisor VMware ESX obsługuje aktualnie nast˛epuj˛acetechnologie: pełna wirtualizacja, parawirtualne sterowniki, smp guest, obsługa nested page table, binary translation, dynamic recompilation, direct execution.

2.2 Hypervisor typu 2

2.2.1 QEMU

http://qemu.org

Projekt QEMU to projekt bardzo niedoceniany. Jest zarówno emulatorem jak i maszyn ˛a wirtualn ˛a,zaleznie˙ od tego, czy korzystamy z dodatkowego modułu j ˛adra kqemu (istnieje tez˙ moduł qvm86 ale jego rozwój został porzucony na pocz ˛atku2007 roku). Autorem kodu zarówno emulatora jak i modułu jest Fabrice Bellard. Kod QEMU jest uzywany˙ w praktycznie kazdym˙ projekcie zwi ˛azanymz wirtualizacj ˛a,zarówno otwartym jak i zamkni˛etym,z Xen, Win4Lin, Win4BSD, Win4Solaris, KVM i VirtualBox na czele. Cały kod ´zródłowyzarówno emulatora, jak owego modułu jest wolny i dost˛epnyna wolnych licencjach GPL, LGPL oraz BSD

58 w przypadku emulacji urz ˛adze´n.

Aby zapewnićw miar˛edobr ˛awydajno´sćuzywa˙ mechanizmów binary translation oraz dynamic recompilation, a takze˙ direct execution (w przypadku uzycia˙ modułu kqemu2). Rozwi ˛azania te nie s ˛ajednak tak ”dopieszczone” jak na przykład w projekcie VirtualBox. W projekcie uzywa˙ si˛ewła´snietych technik, aby jego kod był jak najbardziej przeno´sny, to tak naprawd˛e jego najwi˛ekszazaleta, moze˙ zostaćbardzo łatwo przeportowany na inny system operacyjny. W trybie emulacji nie potrzebuje praw administratora do sprawnego działania. Aby wykony- waćkod aplikacji (czyli userspace) projekt QEMU wykorzystuje kod projektów WINE oraz DOSEMU.

Uzywa˙ mechanizmu copy on write przy zapisach danych na wirtualnych dyskach, do tego wirtualne dyski zajmuj ˛atylko tyle miejsca, ile danych si˛ena nim znajduje, a nie na sztywno tyle ile ma rozmiar dysku. Domy´slnieQEMU uruchamia si˛ez linii polece´n,jednak powstały takze˙ graﬁczne nakładki pokroju QEMU Lanucher czy Qemulator.

Emulator QEMU obsługuje aktualnie nast˛epuj˛acetechnologie: binary translation, dynamic recompilation, direct execution, obsługa snapshot/commit, obsługa protokołu RDP, smp guest, przekazywanie urz ˛adze´nUSB.

2.2.2 VirtualBox

http://virtualbox.org

Firma Sun wykupiła na pocz ˛atku2008 roku firm˛e Innotek, czyli twórc˛eoryginalnego hypervisora VirtualBox, od tego czasu kaze˙ nazywaćswój produkt xVM VirtualBox. Nazwa ta jest jednak myl ˛acaponiewaz˙ sugeruje, ze˙ VirtualBox moze˙ byćcz˛e´sci˛ahypervisora xVM Server, nic bardziej mylnego, co wi˛ecej,xVM i VirtualBox nie mog ˛adziałaćna raz na jednym kom- puterze3, ale od czego jest marketing. Firma Sun rozumie to w ten sposób, ze˙ deweloperzy mog ˛aprzetestowaćaplikacje w wirtualnych ´srodowiskach na swoim systemie operacyjnym zanim zaczn ˛auzywaćxVM˙ Server. Podobnie jak wi˛ekszo´sćprojektów open source zwi ˛azanych

2Moduł kqemu obsługuje aktualnie architektury i386 oraz amd64. 3Hypervisor typu 1 nie moze˙ współdziałaćna jednym komputerze z hypervisorem typu 2. 59 z wirtualizacj ˛arówniez˙ korzysta z kodu ´zródłowegoemulatora/hypervisora QEMU i jego rozwi ˛azań,jak dynamic recompilation gdy nie mozna˙ uzyćinnych˙ mechanizmów.

VirtualBox to klasyczny hosted hypervisor, aktualnie jeden z najwydajniejszych. Rozwijany jest na otwartej licencji GPL2. Systemem host mog ˛abyćsystemy Linux, Windows, OpenSolaris oraz Mac OS X. Mozliwy˙ jest dosyć”łatwy” port na system FreeBSD, jednak brakuje dewel- opera, który przeportowałby moduł j ˛adrana tenze˙ system. Wirtualizacja odbywa si˛etutaj za pomoc ˛atechnologii binary translation oraz direct execution ale mozliwe˙ jest takze˙ korzystanie ze sprz˛etowychrozszerzeńwirtualizacji. System guest moze˙ byćdowolny. VirtualBox oferuje wirtualizacj˛ena architekturach i386 oraz amd64.

Po tym jak Sun przej ˛ałtwórc˛eVirtualBox, zintegrował ten hypervisor tak dobrze jak tylko mógł ze swoim wiod ˛acymsystemem operacyjnym, czyli OpenSolaris, jednocze´sniewspiera- j ˛acporty na pozostałe systemy operacyjne. Dzi˛ekitej bliskiej wi˛eziVirtualBox współpracuje z Solaris Containers oraz aktualnie w fazie testowej rozwi ˛azaniem Crossbow, czyli wirtualizacj ˛a stosu sieciowego.

VirtualBox to rozwi ˛azanienajlepiej nadaj ˛acesi˛ena stacje robocze oraz desktop, zwłaszcza ze swoimi funkcjami integracji z pulpitem systemu host, czyli obsług˛etrybu seamless mode. Obsługuje takze˙ protokół RDP4. Posiada takze˙ wiele innych rozwi ˛azań,obsług˛estandardu iSCSI, kolejkowania rozkazów NCQ w przypadku uzywania˙ partycji czy całego dysku SATA bezpo´srednio. Pozwala na przekazywanie urz ˛adzeń USB bezpo´srednio do systemu guest, a takze˙ wiele innych usprawnieńw komunikacji z systemie host. Domy´slnie VirtualBox uzywa˙ emulowanej karty graficznej z 8MB pami˛eciale ze specjalnymi rozszerzeniami Guest Addi- tions pozwala na o wiele lepsz ˛awydajno´sćgenerowania grafiki ł ˛aczniez dynamiczn ˛azmian ˛a rozdzielczo´sciw systemie guest, gdy po prostu zmieniamy rozmiar okna.

Jest jednak pewna ”niedogodno´sć”,niektóre z wymienionych funkcjonalno´scijak przekazywanie urz ˛adzeń USB oraz obsługa interfejsu iSCSI s ˛adost˛epnew pełnej wersji VirtualBox, która jest dost˛epnajedynie w binarnej formie na innej licencji, które pozwala na darmowe uzy-˙ cie owego oprogramowania tylko na własny uzytek.˙ Równiez˙ kod ´zródłowytych rozwi ˛azań nie został opublikowany.

Hypervisor VirtualBox obsługuje aktualnie nast˛epuj˛acetechnologie: seamless mode, pełna wirtualizacja, parawirtualne sterowniki, smp guest, skalowanie procesora, obsługa nested page table, przekazywanie urz ˛adze´nUSB i SCSI, obsługa NCQ, obsługa protokołu RDP, binary translation, dynamic recompilation, direct execution.

4Remote Desktop Protocol

60 2.2.3 KVM

http://linux-kvm.com

Firma Qmuranet stworzyła maszyn˛epod nazw ˛a Kernel based Virtual Machine, co daje nam w skrócie KVM, jest ona silnie zwi ˛azanaz j ˛adrem systemu Linux, a od jego wersji 2.6.20 jest nawet jego cz˛e´sci˛a.Został równiez˙ przeportowany na system FreeBSD w 2007 roku, jednak od tamtego czasu port ten nie był rozwijany, co oznacza, ze˙ przez zmiany w projekcie po prostu juz˙ nie działa. Aktualnie mozliwa˙ jest wirtualizacja tylko z asyst ˛asprz˛etowychrozsz- erzeńjak AMD-V oraz VT-x. Podobnie jak kilka poprzednich projektów, równiez˙ tutaj zaimplementowano odpowiedni ˛ainfrastruktur˛edla parawirtualnych sterowników urz ˛adzeńw systemach guest. Aktualnie działa w formie modułu j ˛adra,wykorzystuj ˛acduz˙ ˛acze´sćkodu projektu QEMU dla emulacji urz ˛adzeń,wy´swietlaniaobrazu i prawie wszystkich innych as- pektów, oprócz samej wirtualizacji procesora.

Cały kod dost˛epnyjest na otwartej licencji GPL co z reszt ˛ajest raczej oczywiste, gdyz˙ licencja ta nie pozwala na linkowanie kodu z kodem na jakiejkolwiek innej licencji5, a na GPL jest przeciez˙ j ˛adro Linux. Aktualnie obsługuje architektury i386 oraz amd64 (aktualnie trwaj ˛a prace nad portami na architektury powerpc oraz ia64. Dzi˛ekitemu, ze˙ jest tylko modułem j ˛adra Linux, korzysta z wszystkich jego funkcji, jak na przykład skalowanie procesora, czy uzywanie˙ pami˛eci swap systemu host.

Sama wydajno´sćrozwi ˛azaniaKVM jest bardzo dobra, ale jej wydajno´sćzalezy˙ takze˙ od tego jak szybko działaj ˛asprz˛etowerozszerzenia w procesorze. Aplikacja Virtual Machine Man- ager pozwala na graficzne tworzenie i zarz ˛adzaniewirtualnymi maszynami korzystaj ˛acymiz KVM

Monitor KVM obsługuje aktualnie nast˛epuj˛acetechnologie: pełna wirtualizacja, parawirtualne sterowniki, migracja bez przerywania pracy, smp guest, skalowanie procesora, obsługa snapshot/commit, obsługa nested page table, obsługa protokołu RDP, przekazywanie urz ˛adze´nUSB i SCSI.

2.2.4 VMware Server

http://vmware.com/products/server

5Jest to uznawane zarówno za jej najwi˛eksz˛azalet˛ejak i wad˛ejednocze´snie. 61 Hypervisor VMware Server (kontynuator starej linii produktów pod nazw ˛a GSX Server) to najprostszy produkt ﬁrmy VMware przeznaczony do wirtualizacji serwerów. Systemem host moze˙ by´cLinux lub Windows, system guest jest dowolny, gdyz˙ wirtualizacja odbywa si˛eprzez rozwi ˛azaniatakie jak binary translation, czy direct execution. Działa na architekturach i386 oraz amd64.

Wydajno´sćstoi na dobrym poziomie, choćnalezy˙ pami˛etać, ze˙ produkt ten jest przeznaczony jedynie na rynek serwerów i został pozbawiony jakichkolwiek rozwi ˛azańzwi ˛azanychz prac ˛ana stacjach roboczych czy desktopach. VMware Server obsługuje interfejs parawirtualizacji VMI, oraz pozwala zarz ˛adzaćmaszynami wirtualnymi przez interfejs przegl ˛adarki stron www, czy tez˙ specjaln ˛akonsol˛ezdaln ˛a.

Pomimo swoich zalet bywa czasem problematyczny, gdyz˙ ”pochłania” przerwania procesora, co utrudnia poprawne utrzymywanie aktualnego czasu, sprawia to oczywi´scieproblemy z usługami i serwerami, które polegaj ˛ana ´scisłychzmianach w czasie. Aby zminimalizować t˛eniedogodno´sćco jaki´sczasy systemów guest s ˛asynchronizowane z czasem systemu host. Mozna˙ oczywi´sciezawsze skorzystaćz serwera czasu na systemie host, do którego b˛ed˛asi˛e odwoływaćsystemy guest.

Hypervisor VMware Server obsługuje aktualnie nast˛epuj˛acetechnologie: pełna wirtualizacja, parawirtualny interfejs VMI, smp guest, binary translation, direct execution.

2.2.5 VMware Workstation

http://vmware.com/products/ws

Hypervisor VMware Workstation firm VMware jest z kolej produktem przeznaczonym do pracy na stacjach roboczych oraz desktopach. Systemem host moze˙ byćLinux lub Windows, system guest moze˙ byćdowolny. Pozwala na wirtualizacj˛ena architekturach i386 oraz amd64. Uzywa˙ tradycyjnych dla VMware technik jak binary translation czy direct execution. W prze- ciwieństwiedo VMware Server posiada wiele usprawnieńjak choćbygrafika 3D w systemach guest dzi˛ekipełnej obsłudze API Direct3D 8 oraz cz˛e´sciowejobsłudze API Direct3D 9.

Produkt VMware Workstation gn˛ebi˛ate same problemy co wersj˛eserwerow ˛aczyli problemy z synchronizacj ˛aczasu w systemach guest. Posiada za to ciekaw ˛afunkcj˛e Shared Folders, dzi˛eki której mamy dost˛epz systemu guest do plików na systemie host. Zastosowania tego produktu s ˛adodatkowo wymuszane przez jego restrykcyjn ˛alicencj˛e,która nie pozwala na uruchamianie na owym hypervisorze serwerów. 62 Hypervisor VMware Workstation obsługuje aktualnie nast˛epuj˛acetechnologie: pełna wirtualizacja, binary translation, direct execution, graﬁka 3D, współdzielenie plików.

2.2.6 VMware Fusion

http://vmware.com/products/fusion

Ostatnim z rodziny produktów ﬁrmy VMware jest VMware Fusion. Hypervisor ten przeznaczony jest jedynie na system operacyjny Mac OS X (oraz tylko na procesorach Intel). Uzywa˙ takich rozwi ˛aza´njak binary translation czy direct execution. Dzi˛ekiimplementacji trybu seamless mode6 zapewnia duz˙ ˛awygod˛ew działaniu z systemem guest. Pozwala tez˙ na SMP w systemach guest.

Obsługuje takze˙ grafik˛e3D w systemach guest, API DirectX 9.0 oraz OpenGL przez mechanizm direct recompilation. Posiada rozwi ˛azaniatakie jak snapshot/commit czy współdzie- lenie plików pomi˛edzysystemem guest i host. Potrafi takze˙ przekazywaćurz ˛adzeniaUSB bezpo´srednio do systemu host. Innym ciekawym rozwi ˛azaniemjest mapowanie skrótów klaw- iaturowych pomi˛edzysystemem guest i host co pozwala na bardziej produktywn ˛aprac˛e.

Hypervisor VMware Fusion obsługuje aktualnie nast˛epuj˛acetechnologie: seamless mode, pełna wirtualizacja, smp guest, przekazywanie urz ˛adze´nUSB, binary translation, dynamic recompilation, direct execution, graﬁka 3D, współdzielenie plików.

2.2.7 Parallels Desktop

http://parallels.com/products/desktop

Hypervisor Parallels Desktop przeznaczony jest na system Mac OS X. Uzywa˙ standardowych technologii dla hypervisorów typu 2, czyli binary translation, dynamic recompilation oraz direct execution. Pozwala na przekazywanie urz ˛adze´n USB do systemów guest, a takze˙ tryb seamless mode, zwany tutaj coherence. Posiada takze˙ implementacje dzielonego schowka (czyli clipboard) a takze˙ mechanizmu drag and drop pomi˛edzysystemami guest oraz host. Jak wida´cjest to hy-

6Tryb ten zwany jest tutaj Unity.

63 pervisor przeznaczony stricte na stacj˛erobocz ˛alub po prostu desktop.

Obsługuje takze˙ grafik˛e3D w systemach guest, najprawdopodobniej przez implementacj˛e API systemu Windows przez kod biblioteki projektu WINE7, który juz˙ od ponad 15 lat rozwija owe API na otwartej licencji LGPL. Jak wiadomo produkt firmy Parallels jest aplikacj ˛azamkni˛et˛a, ale zgodnie z licencj ˛a WINE firma musi ”oddać”w postaci kodu ´zródłowegowszystkie zmiany jakie tam wprowadziła, odbyło si˛eto z pewnym opó´znieniem,jednak firma wywi ˛azałasi˛eze swych obowi ˛azków.

Aktualnie Parallels Desktop zapewnia obsług˛eAPI DirectX 8.1 oraz OpenGL. Posiada równiez˙ technologi˛e SmartSelect, która pozwala wybra´cczy dany plik otworzymy aplikacj ˛asystemu host, czy tez˙ aplikacj ˛asystemu guest, zapewnia takze˙ współdzielenie plików pomi˛edzysystemami.

Hypervisor Parallels Desktop obsługuje aktualnie nast˛epuj˛acetechnologie: seamless mode, pełna wirtualizacja, smp guest, przekazywanie urz ˛adze´nUSB, binary translation, dynamic recompilation, direct execution, graﬁka 3D, współdzielenie plików.

2.2.8 Parallels Workstation

http://parallels.com/products/workstation

Produkt Parallels Workstation przeznaczony jest zarówno na system Mac OS X (pod nazw ˛a Parallels Workstation for Mac, jak i na systemy Linux oraz Windows. Podobnie jak inne produkty z rodziny firmy Parallels uzywa˙ rozwi ˛azańtakich jak binary translation, dynamic recompilation oraz direct execution. Obsługuje takze˙ sprz˛etowerozszerzenia wirtualizacji AMD-V oraz TV- x. Zapewnia przekazywanie urz ˛adzeń USB do systemów guest, nie pozwala jednak na SMP. Mimo iz˙ jest to produkt przeznaczony na stacje robocze oraz desktop, to brakuje mu sporej cz˛e´scifunkcjonalno´sciz Parallels Desktop.

Hypervisor Parallels Workstation obsługuje aktualnie nast˛epuj˛acetechnologie: pełna wirtualizacja, przekazywanie urz ˛adze´nUSB, binary translation, dynamic recompilation, direct execution.

2.2.9 Parallels Server

Hypervisor Parallels Server przeznaczony jest głownie na system operacyjny Mac OS X (gdzie nosi nazw˛e Parallels Server for Mac. Na systemy Linux oraz Windows dost˛epnajest

7WINE znaczy dokładnie Wine Is Not an Emulator. 64 http://parallels.com/products/server aktualnie wersja beta.Uzywa˙ rozwi ˛aza´ntakich jak binary translation, dynamic recompilation oraz direct execution. Obsługuje takze˙ sprz˛etowerozszerzenia wirtualizacji AMD-V oraz TV-x. Pozwala na na SMP w systemach guest.

Tak naprawd˛eprodukt ten rózni˙ si˛eod poprzednich głównie nazw ˛aoraz licencj ˛apod któr ˛a jest sprzedawany, gdyz˙ rozwi ˛azanias ˛abardzo podobne, a cz˛estonawet po prostu takie same. Oferuje jednak specjaln ˛akonsol˛edo zarz ˛adzaniamaszynami wirtualnymi oraz narz˛edziado migracji systemów guest.

Hypervisor Parallels Server obsługuje aktualnie nast˛epuj˛acetechnologie: pełna wirtualizacja, binary translation, dynamic recompilation, direct execution, smp guest.

2.2.10 Win4Lin / Win4BSD / Win4Solaris

http://win4lin.net http://win4bsd.com http://win4solaris.com

Win4Lin to zamkni˛etyhypervisor ﬁrmy która aktualnie przyj˛ełanazw˛e Virtual Bridges8, przeznaczony jest do wirtualizacji systemów Windows na systemie Linux. Wiele kodu pochodzi z projektu QEMU (ł ˛aczniez kodem modułu kqemu).

Zastosowane technologie nie odbiegaj ˛aznacznie od tych zastosowanych w QEMU, czyli binary translation, direct execution czy dynamic recompilation, cho´cpewnie sporo zmodyﬁkowane pod k ˛atemwydajno´sci,ale za to znacznie mniej przenaszalne niz˙ oryginalny kod projektu QEMU. Posiada tez˙ ciekaw ˛afunkcje współdzielenia plików pomi˛edzysystemami host i guest, mianowicie, na pulpicie systemu guest jest specjalny katalog, który zapewnia bezpo´sredni dost˛epdo plików katalogu domowego uzytkownika˙ z prawem zapisu i odczytu.

Produkt ten miał duze˙ znaczenie w czasach systemów Windows z rodziny 9x, gdy ot- warte rozwi ˛azaniapraktycznie nie istniały, do tego Win4Lin zapewniał praktycznie natywn ˛a wydajno´sćdla starych systemów Windows. Aktualnie brakuje mu dzisiejszych rozwi ˛azańaby skutecznie konkurowaćz innymi popularnymi, a przede wszystkim domowymi rozwi ˛azaniami, bo przeciez˙ za kazd˙ ˛alicencj˛eWin4Lin nalezy˙ zapłacić.

8W przeszło´sciistniała takze˙ pod nazwami Win4Lin oraz Netraverse

65 Istniej ˛atakze˙ odmiany dla systemów FreeBSD (pod nazw ˛a Win4BSD) oraz Solaris (pod nazw ˛a Win4Solaris). Obsługuj ˛ate same technologie oraz zapewniaj ˛atak ˛asam ˛afunkcjonalno´sć,róznica˙ tkwi w innej architekturze modułu j ˛adrahypervisora, który musiał po prostu zostaćprzeportowany na j ˛adro innego systemu operacyjnego. Warto jednak zaznaczyć, ze˙ wersja Win4BSD jest darmowa dla uzytkownika˙ domowego.

Hypervisor Win4Lin obsługuje aktualnie nast˛epuj˛acetechnologie: pełna wirtualizacja, współdzie- lenie plików, binary translation, dynamic recompilation, direct execution.

2.3 Na poziomie systemu operacyjnego

2.3.1 FreeBSD Jails

http://freebsd.org

Mechanizm FreeBSD Jails jest cz˛e´sci˛asamego systemu operacyjnego i mozemy˙ go uakty- wnićw dowolnej chwili. Pozwala bezpiecznie odseparowaćkazd˙ ˛awirtualn ˛amaszyn˛ezarówno od pozostałych maszyn, jak i od systemu host. Kazdy˙ Jail moze˙ posiadaćswój adres IP i odpowiednio zmodyfikowany system FreeBSD w swoim katalogu. Narzut zwi ˛azanyz wirtualizacj ˛ajest praktycznie zerowy (mozna˙ takze˙ powiedziećze po prostu go nie ma), gdyz˙ kazda˙ maszyna korzysta i komunikuje si˛ebezpo´srednio z j ˛adrem systemu host, bez typowych ”spowal- niaczy” pokroju podwójnego kopiowania, czy tez˙ specjalnych odwołań.Do tego nie musimy na sztywno ustawiaćrozmiaru pami˛ecidla kazdej˙ maszyny, gdyz˙ jest dynamicznie przydzielana w miar˛epotrzeby. Rozwi ˛azanieto, podobnie jak cały system FreeBSD rozwijane jest na licencji BSD.

Ułatwia takze˙ administracj˛e,gdyz˙ w kazdej˙ chwili mozemy˙ podmienićjedn ˛az naszych usług na inny jej wariant, czy to inaczej skonfigurowany, czy tez˙ na nowsz ˛awersj˛e,a w razie jakichkolwiek problemów po prostu przywrócićstarsz ˛awersj˛e. Kazda˙ z instancji posiada swoich uzytkowników,˙ swoje procesy, równiez˙ odseparowane od procesów systemu host (tak zwany sandbox) co jest bardzo wazne˙ przy problemach type buffer overflow (czyli po prostu przepełnienie bufora). Zapewnia to bardzo dobre bezpieczeństwo. Dodatkowo system FreeBSD oferuje specjalny mechanizm automatycznego wykrywania zarówno buffer over- 66 flow jak i buffer underflow (niedopełnienie bufora), co zapewnia dodatkowe bezpieczeństwo. Dodatkowo mozemy˙ skorzystaćz mechanizmu FreeBSD o nazwie securelevel (zarówno dla systemu host jak i kazdego˙ z systemów guest). Rozwi ˛azanieto na najwyzszym˙ stopniu bez- pieczeństwaodbiera uprawnienia nawet najwazniejszemu˙ uzytkownikowi˙ na systemach UNIX czyli uzytkownikowi˙ root, nawet wi˛ecjak kto´ssi˛ewłamie to nic nie zrobi bo system mu na to nie pozwoli.

Sam mechanizm Jail jest po prostu bardzo rozszerzon ˛awersj ˛apolecenia chroot z systemów UNIX, samo polecenie chroot nie izoluje jednak przestrzeni adresowej procesów, ani nie zapewnia zadnej˙ z funkcjonalno´scijakie oferuje mechanizm systemu FreeBSD. Dodatkowo mozemy˙ bezpiecznie udost˛epni´czasoby systemu host w systemie guest za pomoc ˛asystemu plików nullfs z systemu FreeBSD, co w wielu przypadkach na pewno zaoszcz˛edzinam sporo miejsca.

Dzi˛ekimechanizmowi jail tak naprawd˛emozemy˙ uruchomićtyle wirtualnych systemów ile tylko nam si˛epodoba, nie ma zadnego˙ limitu, który nas ogranicza, co najwyzej˙ przestrzeń dyskowa oraz wolna pami˛eć.Nowy system Jail zajmuje troch˛eponad 100MB, jednak stosuj ˛ac metod˛e ezjail, która zamiast kopiowaćte same aplikacje do kazdego˙ z wirtualnych systemów po prostu odwołuje si˛edo poleceńsystemu host w trybie read only, podobnie z innymi zasobami, które wyst˛epuj˛aw kazdym˙ z takich systemów. Ogranicza to rozmiar kazdej˙ nowej maszyny do około 2MB, co sprawia, ze˙ miejsce na dysku przestaje miećtutaj jakiekolwiek znaczenie i musimy tylko zadbaćo odpowiedni ˛ailo´sćpami˛eci.

FreeBSD posiada takze˙ technologi˛e,która pozwala na uruchamianie niezmodyﬁkowanych aplikacji binarnych z systemu Linux, nosi ona nazw˛e Linux binary compatibility. Nic nie stoi wi˛ecna przeszkodzie, aby w ´srodowisku Jail uzywa´ctak˙ ze˙ aplikacji z systemu Linux dost˛ep- nych tylko w formie binarnej.

2.3.2 Solaris Containers

http://sun.com/software/solaris/containers

Technologia Solaris Containers (ł ˛aczniez Solaris Zones) jest cz˛e´sci˛asystemu operacyjnego Solaris (takze˙ OpenSolaris). Pozwala tworzyćmaszyny wirtualne odseparowane od systemu host, posiadaj ˛acewłasnych uzytkowników,˙ własne usługi i procesy, ale z izolacj ˛aod procesów systemu host. Kazda˙ taka instancja moze˙ byćdowolnie zmodyfikowan ˛awersj ˛asystemu So- laris (równiez˙ starszych wersji tego systemu). Wydajno´sćtakiego rozwi ˛azaniajest tozsama˙ 67 z wydajno´sci˛anatywn ˛a,gdyz˙ kazda˙ z takich maszyn korzysta bezpo´srednio z j ˛adrasystemu host, za pomoc ˛astandardowych odwołańtegoz˙ systemu, czyli syscall.

Mamy mozliwo´sćprzydzielania˙ na sztywno okre´slonejilo´sciprocesorów oraz pami˛ecidla kazdej˙ maszyny. Mozemy˙ tez˙ pozostawićprzydzielanie zasobów systemowi Solaris. Mozemy˙ tez przydzielićcałe pule zasobów odpowiednim grupom naszych maszyn, system Solaris dostarcza tutaj bardzo duz˙ ˛aelastyczno´sćw zarz ˛adzaniuzasobami. System host nazywany jest tutaj jako global zone, podczas gdy systemy guest nazywane s ˛apo prostu zones. Dla kazdej˙ takiej maszyny mozemy˙ takze˙ przydzielićadres IP, tak jak dla zwykłego komputera. Na jednym systemie Solaris mozemy˙ uruchomićmaksymalnie 8191 instancji systemów guest, 8192 licz ˛ac z systemem host.

Tak zwane sparse zones pozwalaj ˛ana współdzielenie wspólnych zasobów z systemem host, przez co instancja taka zajmuje tylko 50MB, podczas gdy instancja, która posiada pełny system Solaris b˛edziezajmowała kilkaset megabajtów, w skrajnych sytuacjach nawet do kilku giga- bajtów. Ograniczeniem Containers jest na przykład brak mozliwo´scikorzystania˙ z dzielenia zasobów protokołem NFS, moze˙ to robi´cjedynie system host.

Istnieje tez˙ mozliwo´s´cu˙ zywania˙ tak zwanych branded zones (w skrócie BrandZ), czyli instancji, które nie korzystaj ˛az j ˛adrasystemu host. Aktualnie mozliwe˙ jest uzywanie˙ j ˛adersys- temów Solaris 8, Solaris 9 oraz j ˛adrasystemu Linux. Dodatkowo rozszerza to mozliwo´scitego˙ rozwi ˛azania,zwłaszcza mozliwo´s´cu˙ zywania˙ j ˛adraLinux. Do tego technologie takie jak system plików ZFS czy DTrace do wyj ˛atkowodokładnego tuningowania wydajno´sciaplikacji jak i samego systemu zapewniaj ˛anaprawd˛ebogate ´srodowisko do pracy.

2.3.3 Linux VServer

http://linux-vserver.org

Technologia Linux VServer pozwala stworzyćwiele współdziałaj ˛acychmaszyn wirtualnych korzystaj ˛acychbezpo´srednio z j ˛adrasystemu Linux. Wymaga jednak nałozenia˙ odpowiednich nakładek (czyli po prostu patch) na j ˛adro systemu host. Zapewnia natywn ˛awydajno´sćdz- i˛ekiuzywaniu˙ odwołań syscall. Maszyny wirtualne s ˛aod siebie odizolowane, kazdy˙ z nich posiada osobn ˛abaz ˛auzytkowników,˙ procesów, struktur˛ekatalogów ale własnego odr˛ebnego adresu IP juz˙ sobie nie przydzielimy, gdyz˙ VServer nie zapewnia wirtualizacji stosu sieciowego.

Istnieje takze˙ projekt Linux Virtual Server, który zapewnia balansowanie ruchu sieciowego, ale nie nalezy˙ w zaden˙ sposób ł ˛aczyćtych dwóch projektów gdyz˙ nie maj ˛aze sob ˛anic wspól- 68 nego poza podobn ˛anazw ˛a. Przestrzeńadresowa procesów kazdego˙ z systemów guest jest odseparowana od pozostałych instancji (tak zwany sandbox), co zapewnia duze˙ bezpieczeństwo takiego rozwi ˛azania.Rozwi ˛azanie Linux VServer dost˛epnejest na licencji GPL.

Systemy guest dziel ˛apomi˛edzysiebie dost˛epnezasoby komputera ale nic nie stoi na przeszkodzie, aby konkretnej maszynie przydzielićkilka dedykowanych procesorów oraz wi˛eksz˛ailo´sćpami˛eci. Osobne drzewo plików i katalogów takiej wirtualnej instancji zajmuje mało miejsca przez współdzielenie tak wielu rzeczy z systemem host jak to tylko mozliwe˙ na zasadzie copy on write. Z wad tego rozwi ˛azaniamozna˙ wspomniećnie tyle wad˛esamego rozwi ˛azania,co wybór j ˛adraLinux, które nie jest tak bezpieczne jak j ˛adrasystemów FreeBSD czy Solaris.

2.3.4 Linux OpenVZ

http://openvz.org

Rozwi ˛azanie Linux OpenVZ jest konkurencj ˛adla rozwi ˛azania Linux VServer, równiez˙ wykorzystuje j ˛adro systemu Linux aby serwowaćwirtualne instancje na nim oparte. Mozna˙ powiedzieć, ze˙ wydajno´sćrówniez˙ jest taka sama, poniewaz˙ podobnie jak konkurent korzysta z odwołań syscall. Wymaga oczywi´scienałozenia˙ odpowiednich nakładek patch. Rozwi ˛azanieto jest dost˛epnena otwartej licencji GPL. Projekt ten jest takze˙ baz ˛adla innego rozwi ˛azania, konkretnie dla Parallels Virtuozzo Containers, zamkni˛etegorozwi ˛azaniafirmy Parallels. Warto o tym wspomnieć,gdyz˙ OpenVZ otrzymuje wsparcie finansowe od tej wła´sniefirmy.

Kazda˙ z wirtualnych instancji posiada swoje drzewo katalogów, uzytkowników,˙ adres IP, wirtualizowane systemy plików /proc oraz /sys. Jest to wbrew pozorom bardzo duza˙ zaleta gdyz˙ Linux VServer nie oferuje takiego rozwi ˛azania,a j ˛adro systemu Linux wymaga tych sys- temów plików do poprawnego działania. Oczywi´scienie zapomniano o takich podstawach jak izolacja przestrzeni adresowej procesów oraz wirtualizacji stosu sieciowego. Dodatkowym atutem jest mozliwo´s´cprzypisania˙ danej instancji karty sieciowej czy tez˙ portu serial.

Zasoby s ˛awspółdzielone pomi˛edzydziałaj ˛aceinstancje, w podobny sposób jak ma to miejsce przy zwykłych procesach systemu, mozliwe˙ jest jednak dowolne priorytetowanie poszczegól- nych instancji, a takze˙ przydzielanie na sztywno czasu procesora. Podobnie ma si˛esprawa z przypadku operacji I/O. Inn ˛abardzo wazn˙ ˛azalet ˛arozwi ˛azania OpenVZ jest migracja pomi˛edzy ﬁzycznymi serwerami, wymaga jednak zamrozenia˙ danej instancji na czas jej przeniesienia, co trwa jednak zwykle nie wi˛ecejniz˙ kilka do kilkunastu sekund. Nie ma zadnego˙ odgórnego limitu uruchomionych instancji, ograniczaj ˛anas tylko wolne zasoby komputera.

69 Na koniec moze˙ małe zestawienie OpenVZ ze konkurentem, czyli z VServer. OpenVZ jest mówi ˛acbardzo ogólnie rozwi ˛azaniemdojrzalszym i bardziej elastycznym, zapewniaj ˛acwyda- jno´s´cna tym samym poziomie co konkurent. Posiada o wiele wi˛ecejmozliwo´scizarz˙ ˛adzania,a przez wirtualizacj˛estosu sieciowego oraz wirtualnych systemów plików zapewnia, ze˙ wszystkie aplikacje b˛ed˛adziała´cw wirtualizowanych instancjach prawidłowo.

2.3.5 Parallels Virtuozzo Containers

http://parallels.com/virtuozzo

Rozwi ˛azanie Parallels Virtuozzo Containers firmy Parallels bazuje na technologii OpenVZ. Wyst˛epujew dwóch wersjach, na system Linux oraz na system Windows. W pierwszym przypadku jest to po prostu funkcjonalno´sćrozwi ˛azania OpenVZ które z reszt ˛afirma Parallels nie omieszka finansowaći wspierać.Wydajno´sćjest na poziomie natywnym, oczywi´sciez wi˛eksz˛a ilo´sci˛awspółdziałaj ˛acychmaszyn wirtualnych oraz w zalezno´sciod˙ ich obci ˛azenia˙ wydajno´sć b˛edzieodpowiednio mniejsza. Logiczny przekrój wirtualizacji jaki zapewnia rozwi ˛azanie Par- allels Virtuozzo Containers przedstawia rysunek 2.3.

Rysunek 2.3: Schemat rozwi ˛azania Parallels Virtuozzo Containers.

Wersja dla systemu Windows rózni˙ si˛egłownie tym, ze˙ narz˛edziado tworzenia i zarz ˛adzania s ˛agraﬁczne, wszystko mozemy˙ wyklika´cw okienkach co jest z reszt ˛atradycyjnym podej´s- ciem na systemach rodziny z Redmond. W przypadku systemu Linux powita nas instalacja w tekstowym interfejsie ncurses dost˛epnejest takze˙ czysto tekstowe narz˛edzie,dzi˛ekiktóremu

70 mozemy˙ wykonywa´cspersonalizowane nieinteraktywne instalacje.

2.3.6 User Mode Linux

http://user-mode-linux.sourceforge.net

Rozwi ˛azanie User Mode Linux (czyli w skrócie UML) to specjalna wersja j ˛adrasystemu Linux, która moze˙ byćwykonywana w taki sam sposób jak kazdy˙ inny proces. Oznacza to, ze˙ nie musimy posiadaćpraw administratora aby uzywaćtakiego˙ wirtualnego systemu. Mimo iz˙ zaden˙ patch na j ˛adro systemu host nie jest wymagany, to jednak zaleca si˛ezastosowanie odpowiednich łatek w celu zwi˛ekszaniawydajno´scirozwi ˛azania User Mode Linux. Zalet ˛ajest na pewno fakt, iz˙ od 2004 roku UML jest cz˛e´sci˛agłównej gał˛ezij ˛adraLinux, a co za tym idzie jest na otwartej licencji GPL.

Aby system guest posiadał dost˛epdo sieci Internet musimy r˛eczniestworzyćodpowiedni mostek bridge, innym wyj´sciemjest routing przez system host. Mozemy˙ takze˙ skorzystaćz narz˛edzido zarz ˛adzaniainstancjami UML jak na przykład UMLazi, znacznie ułatwi to administracj˛e. Niestety wydajno´sćnie stoi na tak wysokim poziomie jak w innych tego typu rozwi ˛azaniachjak OpenVZ czy VServer.

2.3.7 Cooperative Linux

http://colinux.org

Rozwi ˛azanie Cooperative Linux (nazywane takze˙ w skrócie coLinux) pozwala na uruchomienie j ˛adrasystemu Linux, na komputerze z uruchomionym juz˙ systemem Windows, czyli pozwala na współegzystowanie dwóch zupełnie innych j ˛aderna jednej maszynie w tym samym czasie. Technologia ta bazuje na koncepcji zwanej Cooperative Virtual Machine, która w przeciwie´nst- wie do standardowego podej´sciaz systemem host i guest nie uzywa˙ wirtualizowanych (lub 71 tez˙ emulowanych) peryferiów, tylko zapewnia obu j ˛adrom bezpo´sredni dost˛epdo ﬁzycznego sprz˛etukomputera jednocze´snie.

W teorii kazde˙ z j ˛aderposiada wył ˛acznydla siebie kompletny kontekst procesora oraz odr˛ebn˛aprzestrzeńadresow ˛a,a w przypadku dost˛epudo sprz˛etu,kazde˙ z j ˛aderdecyduje kiedy oddaćkontrol˛e”przeciwnikowi” nad danym sprz˛etem. Architektura i386 nie jest jednak zaprojektowana do pracy z dwoma systemami jednocze´snie,co prowadzi do wielu konfliktów a nawet niestabilno´scigdyby obydwu j ˛adrom daćpełne uprawnienia w zarz ˛adzaniukomput- erem. Wprowadzono tutaj poj˛eciaj ˛adrahost oraz j ˛adraguest, gdzie j ˛adro host kontroluje cały sprz˛et,a j ˛adro guest komunikuje si˛ez j ˛adrem host za pomoc ˛aspecjalnego API.

Aktualnie działa na systemach Windows XP/2000 oraz Linux, ale nic nie stoi na przeszkodzie aby przeportowaćgo na inne systemy, wszakze˙ cały projekt jest dost˛epnyna otwartej licencji GPL. Niestety nie ma nic za darmo, podej´scieto posiada wiele wad, jak na przykład niestabilno´sć(po prostu zobaczymy kernel panic, chociaz˙ na systemach Windows to zadna˙ nowo´sćtak naprawd˛e)oraz mniejsze bezpieczeństwo,na przykład jezeli˙ atakuj ˛acyodpowiednie spreparuje moduł j ˛adra coLinux. Rozwi ˛azanie coLinux działaj ˛acepod systemem Windows przedstawia rysunek 2.4.

Rysunek 2.4: Rozwi ˛azanie CoLinux działaj ˛acepod kontrol ˛asystemu Windows.

Przez do´sćnietypow ˛astruktur˛eurz ˛adzeńinstalowanie dystrybucji systemu Linux jest dosyć trudne dlatego przewaznie˙ przenosi si˛edziałaj ˛ac˛ainstalacj˛esystemu, lub tez˙ specjalnie przy- gotowany obraz do działania pod coLinux. Inna wad ˛ajest brak mozliwo´sciuruchamiania˙ systemu X window system, a co za tym idzie aplikacji graficznych ale aplikacje tekstowe jak serwery działaj ˛abez zarzutu.

72 2.4 Emulatory

2.4.1 QEMU

http://qemu.org

Projekt QEMU jest osobno wspomniany jako emulator, gdyz˙ taka była jego podstawowa idea, mimo iz˙ jest szeroko wykorzystywany jako rozwi ˛azaniedo wirtualizacji. Pozwala emulowa´carchitektury takie jak i386, amd64, alpha, arm, powerpc, powerpc64, mips, sparc oraz sparc64. Co wi˛ecejpozwala to robi´ctakze˙ na nich, na przykład architektur˛e arm na architekturze sparc64. Dla systemu guest dostarczany jest w pełni emulowany kompletny komputer z wszystkimi peryferiami i podzespołami.

2.4.2 Bochs

http://bochs.sourceforge.net

Podobnie jak QEMU emulator Bochs jest bardzo przeno´sny, do tego pozwala emulowa´c nie tylko cały wirtualny komputer, ale takze˙ BIOS oraz konkretne modele procesorów wraz z ich sprz˛etowymirozszerzeniami jak MMX czy SSE. Dodatkowo pozwala uruchamia´caplikacje i386 oraz amd64 na innych architekturach, ´swietnienadaje si˛ezatem do rozwijania oraz debugowania oprogramowania to wirtualizacji. Jest dost˛epnyna otwartej licencji LGPL.

Jako emulator zapewnia bardzo mał ˛awydajno´sć,ale nie ma to znaczenia, gdyz˙ przeznaczony jest do innych zadańniz˙ wirtualizacja. Autorem jest Kevin Lawton lecz po uwolnieniu kodu projekt rozwijaj ˛aludzie z całego ´swiata.Pocz ˛atkowobył dost˛epnyjako w cenie $25 jednak w 2000 roku firma MandrakeSoft9 wykupiła kod i wypu´sciłago na otwartej licencji LGPL.

9Aktualnie Mandriva. 73 Rozdział 3

Wydajno´s´cmaszyn wirtualnych

Testuj ˛acrózne˙ systemy operacyjne na danym komputerze musimy zadbaćo wiele czyn- ników, o powtarzalne ´srodowisko testowe, czy testy były wykonywane na maszynie cold boot (komputerze który dopiero co został wł ˛aczony)czy moze˙ hot boot (po restarcie komputera). Czynniki pozornie nieistotne s ˛ajednak bardzo wazne˙ w przypadku przeprowadzania dokładnych testów wydajno´scisamych systemów operacyjnych, a w przypadku testowania rozwi ˛azańwirtualizacji s ˛ajeszcze wazniejsze.˙ Musimy tez˙ wiedziećco i jak chcemy testować, gdyz˙ wyniki niektórych testów, mimo iz˙ poprawnie przeprowadzone, nie powiedz ˛anam tak naprawd˛enic o wydajno´scidanego rozwi ˛azania.

We´zmyna przykład do´sćpopularny test, uzywany˙ zarówno przy porównaniach samych systemów operacyjnych jak i maszyn wirtualnych, mianowicie SPECjbb [SPEC, 2005]. Jego zadaniem jest mierzenie wydajno´sciserwera aplikacji Java. Benchmark ten praktycznie nie uzywa˙ czasu kernelspace, podczas gdy typowe obci ˛azenie˙ tego typu mie´scisi˛ew przedziale 20-30%. Hypervisor po prostu w ogóle nie ma szansy si˛ewykazać,gdyz˙ praktycznie przez cały czas testu pozostaje bezczynny wykonuj ˛ackod aplikacji w userspace. To tak jak postawić samochód Porsche w korku ulicznym i wychwalaćmoc jego silnika [de Gelas, 2008b]. Inn ˛a ”wad ˛a”tego testu jest brak obci ˛azenia˙ operacjami I/O, gdyz˙ optymalizacje (lub ich brak) w tej kwestii s ˛abardzo wyra´zne,co pozwala łatwo oddzielićwydajny hypervisor od przereklam- owanego produktu.

Istniej ˛atakze˙ specjalne testy wydajno´scimaszyn wirtualnych jak na przykład VMmark firmy VMware. Juz˙ na pierwszy rzut oka podejrzane powinno być, ze˙ firma która sama jest jedn ˛aze stron w wy´sciguwydajno´scimaszyn wirtualnych oferuje swój program do testowania ich wydajno´sci. Co prawda jest on w cz˛e´sciprogramem open source, jednak nie w pełni wiec nie mozna˙ do końcasprawdzićco i w jaki sposób sprawdza. Inn ˛akwesti ˛ajest adno- tacja w FAQ owej aplikacji, która brzmi ”VMmark is neither a capacity planning tool nor a sizing tool.” (oprogramowanie VMmark nie moze˙ byćuzywane˙ w celu planowania ”pojemno´sci”ani ”rozmiarowo´sci”). Jaki jest wi˛eccel uzywania˙ go skoro nawet jego twórcy ostrzegaj ˛anas, ze˙ nic on nam nie powie?

74 Jednym z zadańwirtualizacji jest wirtualizacja systemów z rodziny Windows, dlaczego by wi˛ecnie wsi ˛a´sćjednego z najbardziej znanych testów, skoro wszyscy go uzywaj˙ ˛ado mierzenia wydajno´scikomputerów pod działaniem systemu Windows, mowa oczywi´scieo aplikacji PC- Mark. Wi˛ekszo´sćprocesorów architektur i386 oraz amd64 ma na sztywno ustawiony CPUID, czyli unikalny identyfikator modelu procesora, co oznacza ze˙ nie mozna˙ go w zaden˙ sposób zmodyfikować(bo tak naprawd˛epo co). Niedawno pojawił si˛ejednak na rynku procesor, który daje tak ˛amozliwo´sćczyli˙ VIA Nano.

Przy domy´slnychustawieniach procesor VIA Nano był o około 25% wolniejszy od swojego konkurenta Intel Atom. Po ustawieniu CPUID na AuthenticAMD (identyfikator procesorów AMD) nagle zyskał 10% wi˛ecejwydajno´sci.Najciekawszy jednak jest kolejny wynik, w którym zmieniono identyfikator na GenuineIntel (identyfikator procesorów firmy Intel). Po tej zmianie procesor ”Intel” Nano uzyskał wynik o prawie 50% lepszy niz˙ pod swoj ˛adomy´sln˛anazw ˛a VIA Nano, dodatkowo wyprzedzaj ˛acswojego konkurenta Atom ze stajni firmy Intel [Hruska, 2008].

Testy były przeprowadzone wiele razy, wi˛ecnie ma tu mowy o jakiejkolwiek pomyłce. Wy- ja´snieniatego stanu rzeczy mog ˛abyćrózne,˙ ale jak to zwykle bywa najprostsze wyja´snienias ˛a najbardziej trafne, a jak nie wiadomo o co chodzi to chodzi o pieni ˛adze.Jednym z nich jest wyja´snienie,iz˙ test PCMark korzysta ze specjalnych dla konkretnego procesora optymalizacji, st ˛adpo ich zamianie ustawienia były ”´zle”dobrane, a wyniki nieoptymalne. Test ten jednak pochodzi z 2005 roku, podczas gdy procesory Nano firmy VIA pojawiły si˛ew połowie 2008 roku, nie mógł on wi˛ecposiadaćjakichkolwiek optymalizacji dla tego procesora nawet jakby bardzo si˛estarał. id ˛acdalej załózmy,˙ ze˙ owy test posiada te ”udogodnienia” dla kazdego˙ z procesorów. Dlaczego wi˛ecustawiaj ˛ac”zły” identyfikator zamiast pogorszyćwyniki polep- szyli´smyje i nie o kilka lecz o kilkadziesi ˛atprocent?

Oczywi´scietwórcy PCMark zarzekaj ˛asi˛ejeden przez drugiego, ze˙ nie ma tu miejsca zadna˙ manipulacja, ze˙ to najpewniej bł ˛adw ich oprogramowaniu, którego zaraz usun ˛ai tak dalej, ale chyba jasno widaćna czyj ˛akorzy´sćbł ˛addziała. Poza tym jezeli˙ owa aplikacja posiada jakiekolwiek ułatwienia dla któregokolwiek z procesorów, to dyskwalifikuje to j ˛ajako miaro- dajne narz˛edziedo mierzenia wydajno´sciczegokolwiek, gdyz˙ test powinien byćtaki sam dla wszystkich, bez ułatwieńani utrudnień.

Mozna˙ tak wymieniaćdługo, przez kolejne wersje sterowników graficznych coraz to lepiej radz ˛acychsobie z testami 3DMark (z reszt ˛atego samego producenta co PCMark) oraz rózne˙ inne mniejsze i wi˛ekszeoszustwa w drodze do chwalenia si˛ewi˛eksz˛awydajno´sci˛a.Jak widać łatwo jest wybraćnieodpowiednie narz˛edzia,których wyniki nie tylko nic nam nie powiedz ˛a, ale na dodatek zniekształc ˛awyniki i to do´sćznacznie. Przede wszystkim musimy po prostu pami˛etaćco chcemy zmierzyći co mierzy nasz test. Dobrze jezeli˙ dany benchmark jest dost˛epny razem z całym kodem ´zródłowym,jednak specyfika rynku aplikacji na systemach Windows 75 ”preferuje” aplikacje binarne i mało kto pyta tutaj o kod ´zródłowy. Nalezy˙ jednak sprawdzić, czy aplikacja której chcemy uzyćnie˙ zawiera niechcianych niespodzianek jak PCMark.

Na koniec zastanówmy si˛eco jest tak naprawd˛ewazne˙ jezeli˙ chodzi o wydajno´sćwirtual- izacji. Tak naprawd˛emozna˙ owe zagadnienie podzielićna dwie cz˛e´sci. Wydajno´sćwirtual- izacji systemów z rodziny Windows, gdyz˙ to na nich jest aktualnie dost˛epnenajwi˛ecejopro- gramowania, ł ˛aczniez oprogramowaniem kooperacyjnym i specjalistycznym, a cz˛estodost˛ep- nym tylko na ten system. Do tego worka nalezy˙ takze˙ dorzucićogólne poj˛eciewydajno´sci pełnej wirtualizacji systemów operacyjnych w najlepszym wypadku z asyst ˛aparawirtualnych sterowników.

Drug ˛arz ˛adz˛ac˛asie zupełnie innymi prawami jest wydajno´sćwirtualizacji rozwi ˛azańser- werowych. Tutaj najcz˛e´sciejjest stosowana parawirtualizacja oraz wirtualizacja na poziomie systemu operacyjnego, gdyz˙ zapewniaj ˛aone najwi˛eksz˛awydajno´sćoraz pozwalaj ˛ana współdzi- ałanie wielu systemów guest na jednej maszynie przez mały ”narzut” wirtualizacji.

76 Rozdział 4

Przyszło´s´cwirtualizacji

Mówi ˛ackolokwialnie przyszło´sćwirtualizacji jest jasna. Rynek nigdy wcze´sniejnie ofer- ował tak wielu róznorodnych˙ rozwi ˛azań(w dodatku za darmo), nawet do celów korpora- cyjnych. Projekty open source na biez˙ ˛acowymieniaj ˛asi˛enowymi usprawnieniami i rozwi ˛azaniami zapewniaj ˛acstały rozwój. Producenci procesorów w praktycznie kazdym˙ procesorze implementuj ˛aswoje rozszerzenia sprz˛etowejuz˙ teraz zapowiadaj ˛acnast˛epnegeneracje rozsz- erzeń,zapewniaj ˛acejeszcze wi˛eksz˛awydajno´sćoraz funkcjonalno´sć.

Jednym z przyszłych zastosowańwirtualizacji b˛edziez pewno´sci˛a cluster virtualization (czyli klastry wirtualizacji). Wiele komputerów czy tez˙ wydajnych serwerów poł ˛aczonych w jedn ˛alogiczn ˛ajednostk˛e,z logicznymi procesorami (lub nawet jednym) wykorzystuj ˛acymi moc wszystkich składowych procesorów do konkretnego zadania. Z czasem powstan ˛amech- anizmy wykorzystuj ˛acetechnologi˛e GPGPU do obliczeńmaszyny wirtualnej, a z pojawie- niem si˛eproduktu Larrabee stanie si˛eto jeszcze prostsze ze wzgl˛eduna kompatybilno´sćtego procesora graficznego z instrukcjami i386 i brak konieczno´sciprzepisywania wszystkiego na przykład na rozwi ˛azanie CUDA.

Innym rozwi ˛azaniem,które prawdopodobnie zyska popularno´sćw przyszło´scib˛edzieuruchami- anie maszyny wirtualnej dla kazdego˙ z programów (w podobny sposób jak rozwi ˛azanieprzegl ˛a- darki Google Chrome, gdzie kazda˙ zakładka jest osobnym procesem). Zapewni to niespotykane dot ˛adbezpieczeństwo.Gdy upewnimy si˛e, ze˙ aplikacja nie stanowi zadnego˙ zagrozenia˙ dla naszego systemu, b˛edziemymogli zdecydowaćczy chcemy uruchamiaćj ˛a”natywnie”. Gdyby juz˙ teraz wyposazyćsystemy˙ operacyjne w tego rodzaju sandbox wirusy przestałyby byćza- grozeniem,˙ gdyz˙ nie byłyby w stanie w jakikolwiek sposób wpłyn ˛aćna prac˛esystemu, wszystkie skutki ich negatywnego działania pozostałyby w maszynie wirtualnej. Rozwi ˛azanieto mozna˙ by poł ˛aczyćz implementacj ˛aantywirusa przez co przy pierwszym uruchomieniu aplikacji b˛edziemywiedzieli czy nie zawiera ona jakich´sprzykrych niespodzianek.

Zastosowa´nwirtualizacji w przyszło´scijest bardzo wiele, z pewno´sci˛ab˛edzieona bardziej powszechna i dost˛epna,oraz stosowana na jeszcze wi˛eksz˛askal˛eniz˙ ma to miejsce dzi´s.

77 Rozdział 5

Podsumowanie

Celem mojej pracy było opisanie, zestawienie i porównanie wszystkich licz ˛acychsi˛erozwi ˛azań w dziedzinie wirtualizacji systemów operacyjnych. Przedstawienie w przejrzysty sposób wszystkich stosowanych mechanizmów i technologii uzywanych˙ w dzisiejszych produktach oraz podzielenie ich na odpowiednie kategorie. Praca ta, to swoisty przekrój wachlarza dost˛ep- nych dzisiaj rozwi ˛azańw dziedzinie wirtualizacji. Zawiera takze˙ opis rozwi ˛azańbardziej unikatowych i mniej popularnych, które b˛ed˛amiały znacznie wi˛ekszeznaczenie w blizszej˙ przyszło´scitej dziedziny informatyki.

Nie sposób pomin ˛a´ctutaj podrozdziału po´swi˛econegorozszerzeniom sprz˛etowymstwor- zonym w celu wspierania wirtualizacji. Jest ich coraz wi˛ecejoraz s ˛aone coraz bardziej wyspec- jalizowane, stworzone z my´sl˛adostarczenia jednej konkretnej funkcjonalno´sciw najlepszy mozliwy˙ sposób. Oczywi´scierozszerzenia te, podobnie jak rozwój samych hypervisorów równiez˙ ewoluuj ˛ai w nowszych procesorach implementowane s ˛arozszerzenia nast˛epnejgeneracji, jeszcze lepiej realizuj ˛aceswoje zadania.

Materiał tutaj przedstawiony moze˙ z powodzeniem byćbaz ˛ado dalszego zgł˛ebianiawiedzy w temacie wirtualizacji, porównywania implementacji konkretnych technologii i zastosowań. Moze˙ takze˙ słuzyćjako˙ swego rodzaju paleta dost˛epnychrozwi ˛azańw dziedzinie wirtualizacji systemów operacyjnych. Nalezy˙ pami˛etać, ze˙ wirtualizacja to wyj ˛atkowodynamicznie rozwijaj ˛acasi˛egał ˛a´zinformatyki, wi˛ecz czasem cz˛e´sćzawartego tutaj materiału z ulegnie przedawnieniu. Praca uchwyca najistotniejsze aspekty tematyki w aktualnym stadium rozwoju dzi˛ekiczemu za par˛elat b˛edziemozna˙ zweryfikowaćktóre drogi rzeczywi´scieokazały si˛ekrokiem na przód, a które porzucono.

Jest to charakterystyczne dla rozwoju techniki i nauki. Dla post˛epudanej dziedziny wiedzy maj ˛aznaczenie kazde˙ badania i wszystkie próby jej udoskonalenia. Nie jest najistotniejsze, które z wariantów okaz˙ ˛asi˛ew przyszło´scinajlepsze, ale wła´sniesam proces ich odkrywania i doskonalenia oraz wynik prac wszystkich zwi ˛azanychz nim projektantów i programistów.

78 Technikalia

Problemy z wy´swietlaniemobrazków

W razie problemów z wy´swietlaniemrysunków na systemach Windows nalezy˙ pobraći zaintalowaćwtyczk˛e svgview.exe firmy Adobe st ˛ad http://www.adobe.com/svg/viewer/install/ main.html, inaczej obrazki które s ˛aw formacie SVG b˛ed˛abardzo poszarpane i cz˛estonieczytelne.

Uzyte˙ ikony projektu Tango

W powyzszej˙ pracy zmodyfikowałem i uzyłem˙ ikon projektu Tango, którego strona znajduje si˛ena http://tango.freedesktop.org. Zgodnie z licencj ˛aprojektu, czyli Creative Commons [Creative Commons, 2002] jestem zobligowany do zwrócenia zmian, co tez˙ uczyniłem wysyła- j ˛aćowe modyfikacje na list˛emailingow ˛aprojektu [email protected]. Owe modyfikacje uzyte˙ s ˛aw rysunkach 1.30, 1.31, 1.33 oraz 1.32.

Oryginały uzytych˙ ikon z projektu Tango.

Uzyte˙ oprogramowanie

Napewno wiele osób chciałoby wiedziećw ”czym” powstała owa praca, oto wi˛eclista uzytego˙ oprogramowania. Sama praca jest zbudowana za pomoc ˛asystemu LATEX (konkretnie tetex pakiet na systemach UNIX) a bibliografia za pomoc ˛abiblioteki BIBTEX. Do wygenerowa- nia indeksu za´sposłuzył˙ program makeindex. Wektorowe obrazki w formacie SVG zostały stworzone w programie Inkspace, wszystkie pozostałe obrazki powstały w programie GIMP, obydwa te narz˛edziadost˛epnes ˛ana otwartej licencji GPL i mozna˙ je pobraćodpowiednio z http://inkscape.org oraz http://gimp.org.

79 Bibliograﬁa

K. Adams / O. Agesen. Comparison of Software and Hardware Techniques for x86 Virtualization. Oct 2006.

AVAXIO. Virtualizációs technikák. 2007. URL http://avaxio.hu/virttech_intro.

J. Stoess / C. Lang / F. Bellosa. Energy Management for Hypervisor-Based Virtual Machines. Jun 2007. URL http://i30www.ira.uka.de/research/publications/pm.

Berkeley Computer Systems Research Group of the University of California. Licencja BSD. 1989. URL http://opensource.org/licenses/bsd-license.php.

Creative Commons. Licencja Creative Commons 2.5. Dec 2002. URL http://creativecommons. org/licenses/by-sa/2.5.

V. Uhlig / J. LeVasseur / E. Skoglund / U. Dannowski. Towards Scalable Multiprocessor Virtual Machines. May 2004. URL http://l4ka.org/publications.

J. de Gelas. Hardware Virtualization: the Nuts and Bolts. Mar 2008a. URL http://it.anandtech. com/printarticle.aspx?i=3263.

J. de Gelas. Secrets of Virtual Benchmarketing. Aug 2008b. URL http://it.anandtech.com/ weblog/showpost.aspx?i=479.

N. Tolia / M. Satyanarayanan / E. de Lara / H. A. Lagar-Cavilla. VMM Independent Graphics Acceleration. 2006. URL http://cs.toronto.edu/~andreslc/vmgl.

Ubuntu Documentation. Seamless Virtualization. 2008. URL https://help.ubuntu.com/ community/SeamlessVirtualization.

J. M. Holzer / D. Dutile / B. Donahue. RHEL Para-virtualized Drivers Guide. 2008.

S. Hand / A. Warﬁeld / K. Fraser. Hardware Virtualization with Xen. Login Press, Feb 2007.

G. Gerzon. Intel R Processor Virtualization Extensions. 2007. URL http://intel.com.

G. J. Popek / R. P. Goldberg. Formal requirements for virtualizable third generation architec- tures. Communications of the ACM, 17(7):412–421, Jul 1974.

O. Goldshmidt. Virtualization Advanced Operating Systems. 2007. 80 B. Leslie / G. Heiser. Towards Untrusted Device Drivers. Mar 2003.

V. Uhlig / J. LeVasseur / G. Heiser. Are virtual-machine monitors microkernels done right? ACM SIGOPS Operating Systems Review, 40(1):95–99, Jan 2006.

J. G. Hansen / A. K. Henriksen. Nomadic operating systems. Master’s thesis, Dept. of Com- puter Science, University of Copenhagen, Denmark, 2002. URL http://nomadbios.dk.

J. Hruska. Low-end Grudge Match: Nano vs. Atom. Jul 2008. URL http://arstechnica.com/ reviews/hardware/atom-nano-review.ars/6.

IBM. IBM Systems Virtualization. Dec 2005.

J. S. Robin / C. E. Irvine. Analysis of the Intel Pentium’s Ability to Support a Secure Virtual Machine Monitor. Aug 2000. URL http://cisr.nps.navy.mil.

I. Kelly. Porting MINIX to Xen. May 2006.

H. A. Lagar-Cavilla. VMGL: VMM-Independent Graphics Acceleration. May 2007. URL http: //cs.toronto.edu/~andreslc.

D. Magenheimer. Memory Overcommit... Without the Commitment. Jun 2008.

J.Nakajima / A. K. Mallick. Hybrid Virtualization Enhanced Virtualization for Linux. Jun 2007.

Sun Microsystems. VirtualBox Architecture. 2008. URL http://virtualbox.org/wiki/ VirtualBox_architecture.

T. Ormandy. An Empirical Study into the Security Exposure to Hosts of Hostile Virtualized Environ- ments. 2007.

AMD White Paper. Live Migration with AMD-V Extended Migration Technology. 2007. URL http://amd.com.

J. Stoess / C. Lang / M. Reinhardt. Energy-aware Processor Management for Virtual Machines. Apr 2006. URL http://i30www.ira.uka.de/research/publications/pm/.

A. Przywara / J. Rödel. Linux Mainframe - KVM and the Road of Virtualization. May 2007.

M.A. Salsburg. What’s All the Fuss About I/O Virtualization? Jun 2007. URL http://cmg.org/ measureit/issues/mit42/m_42_2.html.

SPEC. SPECjbb. Standard Performance Evaluation Corporation, 2005. URL http://spec.org/ jbb2005.

R. M. Stallman. Licencja GPL. 1989. URL http://gnu.org/licenses/gpl.html.

Sun. Licencja CDDL. 2004. URL http://sun.com/cddl/cddl.html.

81 D. McIlroy / J. Ossanna / D. Ritchie / K. Thompson. UNIX time-sharing operating system. 1969. URL http://wikipedia.org/wiki/UNIX.

V. Uhlig. Scalability of Microkernel-Based Systems. PhD thesis, University of Karlsruhe, Germany, May 2005.

Jeff Victor. How to Move a Solaris Container. 2008. URL http://sun.com/software/solaris/ howtoguides/moving_containers.jsp.

VMware. Virtualization: Architectural Considerations and Other Evaluation Criteria. 2005.

VMware. Performance Benchmarking Guidelines for VMware Workstation 5.5. 2006.

VMware. Understanding Full Virtualization, Paravirtualization and Hardware Assist. 2007.

E. Wahlig. Hardware Based Virtualization Technologies. May 2008.

M. Ben-Yehuda / J. Mason / O. Krieger / J. Xenidis / L. Van Doorn / A. Mallick / J. Nakajima / E. Wahlig. Using IOMMUs for Virtualization in Linux and Xen. Jul 2006.

L. Sanger / J. Wales. Wikipedia. 2001. URL http://wikipedia.org.

82 Spis rysunków

1.1 Schemat działania systemu operacyjnego...... 6 1.2 Typowe wykorzystanie protection rings przez system operacyjny...... 7 1.3 Emulator jest po prostu kolejn ˛aaplikacj ˛adziałaj ˛ac˛aw systemie...... 8 1.4 Schemat hypervisora typu 1 na procesorze bez obsługi monitor mode...... 11 1.5 Schemat hypervisora typu 1 na procesorze z obsług ˛a monitor mode...... 12 1.6 Schemat hypervisora typu 2 na mechanizmie protection rings...... 12 1.7 Parawirtualizacja oraz pełna wirtualizacja przy uzyciu˙ hypervisora typu 1...... 13 1.8 Pełna wirtualizacja realizowana za pomoc ˛ahypervisora typu 2...... 16 1.9 Schemat wirtualizacji na poziomie systemu...... 16 1.10 Schemat działania rozwi ˛azania hardware partitions...... 18 1.11 Schemat działania pami˛eciwirtualnej...... 19 1.12 Schemat działania układu memory management unit...... 19 1.13 Schemat translacji przy uzyciu˙ page table...... 20 1.14 Schemat translacji przy uzyciu˙ bufora TLB...... 20 1.15 Schemat mechanizmu shadow page table...... 21 1.16 Schemat mechanizmu nested page table...... 22 1.17 Schemat dost˛epudo urz ˛adzenia natywnie...... 24 1.18 Porównanie działania układów MMU oraz I/O MMU...... 24 1.19 Programowe emulowanie układu IOMMU przez hypervisor...... 25 1.20 Schemat sprz˛etowegoukładu IOMMU...... 26 1.21 Schemat dzielenia urz ˛adzeńza pomoc ˛a programowych urz ˛adzeńwirtualnych.... 27 1.22 Schemat dzielenia urz ˛adzeńza pomoc ˛a rozwi ˛azaniasprz˛etowego...... 27 1.23 Schemat programowego ”przekazywania” urz ˛adzeńdo systemu guest...... 28 1.24 Schemat dzielenia urz ˛adzeńza pomoc ˛a rozwi ˛azaniasprz˛etowego...... 28 1.25 Logo procesorów firmy Advanced Micro Devices...... 29 1.26 Logo HyperTransport Consortium...... 31 1.27 Logo grupy Trusted Computing Group...... 33 1.28 Logo procesorów firmy Intel...... 34 1.29 Logo procesorów firmy VIA...... 37 1.30 Wykorzystanie szyny FSB w konfiguracji SMP...... 40 1.31 Technologia NUMA w konfiguracji SMP...... 41 1.32 Sposób komunikacji rdzeni w procesorach Core 2 Quad...... 43

83 1.33 Sposób komunikacji rdzeni w procesorach architektury K10...... 43 1.34 Jednostki wykonawcze procesora z wł ˛aczon˛a/wył˛aczon˛aobsług ˛a HTT...... 44 1.35 Wirtualizacja systemu guest w oknie...... 49 1.36 Wirtualizacja w trybie seamless mode...... 49

2.1 Wynik polecenia xm list...... 57 2.2 Konsola zarz ˛adzaj˛acamonitora VMware ESX...... 58 2.3 Schemat rozwi ˛azania Parallels Virtuozzo Containers...... 70 2.4 Rozwi ˛azanie CoLinux działaj ˛acepod kontrol ˛asystemu Windows...... 72

84 Indeks

Address Space Identifier, 20, 30 CR3, 19 algorytm szeregowania, 41 Crossbow, 59 ALU, 43 CUDA, 46 AMD-V, 12, 14, 28, 55, 60, 63, 64 DCA, 29 amd64, 60 DEV, 28 ASID, 30 Device Exclusion Vector, 28 bare metal, 54 Direct Connect Architecture, 29 binary translation, 11–14, 57–59, 61, 62, 64 direct execution, 12, 14, 58, 59, 61, 62, 64 BIOS, 17 direct recompilation, 62 Bochs,7, 72 DMA, 23 branded zones, 67 DMA remapping, 23 BrandZ, 67 dom0, 54 BSD,4 domU, 54 buffer overflow, 65 drag and drop, 47, 62 buffer underflow, 66 DTrace, 67 bug, 17 Dual Dynamic Power Management, 31 dynamic recompilation, 12, 58, 59, 64 cache, 12, 14, 18, 40 Cache Coherent NUMA, 40 EIST, 34 ccNUMA, 40 emulacja,7 CDDL,4 Enhanced Power Management, 31 chroot, 16 ESX, 56 clipboard, 62 Extended Migration, 29 cluster virtualization, 76 Extended Page Tables, 34 coherence, 47, 62 ezjail, 66 cold boot, 73 firmware, 17 coLinux, 70 FlexMigration, 35 containers, 16 FlexPriority, 34 content based page sharing, 22 FPU, 43 Cool’n’Quiet, 30, 31 FreeBSD, 41 CoolCore, 31 FSB, 28–30, 34, 39 Cooperative Linux, 70 Cooperative Virtual Machine, 70 Gallium3D, 47 copy on write, 22, 58, 68 GART, 24 85 gates,6 iSCSI, 59 global zone, 67 ISO, 46 GPGPU, 25 JAVA, 38 GPL,4, 60 just in time, 12, 14 GSX Server, 61 guest,4 K10, 36, 42 guest CR3, 20 Kernel based Virtual Machine, 60 kernel mode,6,8 hardware,4 konsolidacja, 17 hardware page table pointer, 19 kontenery, 16 hardware partitions, 16 kqemu, 57, 58 host,4 KVM, 12, 60 host CR3, 20 hosted hypervisor, 11, 59 LaGrande, 35 hot boot, 73 Larrabee, 46 HTT, 42 Linux binary compatibility, 66 HVM, 55 Linux OpenVZ, 68 hybrydowa wirtualizacja, 16 Linux VServer, 67 Hyper Threading Technology, 42 live migration, 35 hypercall, 13 logical domain, 16 HyperTransport, 29, 30 Hypervisor,9 Mac OS X,7 Hypervisor typu 1,9 mapowanie DMA, 23 Hypervisor typu 2, 11 Maszyna wirtualna,8 memory ballooning, 22 I/O,6,8 memory management unit, 18 I/O Acceleration Technology, 33 memory overcommitment, 21 I/O Memory Management Unit, 29 microkernel,6 I/O MMU, 23 MINIX 3,6 I/OAT, 34 MMU, 18 idle, 34 monitor maszyny wirtualnej,8 IMC, 28 monitor mode, 10 Independent Dynamic Core, 31 input, 31, 35 natywna wirtualizacja, 14 Instruction Set Architecture,8 NCQ, 59 Integrated Memory Controller, 28 ncurses, 69 Intel VT-x, 14 NDA, 44 Inter Process Communication, 40 nested page table, 20, 29, 34 IOMMU, 23, 29, 47 Non Disclosure Agreement, 44 IPC, 40 non root mode, 10, 28, 33 ISA,8 Non-Uniform Memory Access, 39 Isaiah, 36 Nouveau, 45 86 NUMA, 29, 39, 40 RDP, 48, 59 real time operating system, 18 Open Computing Language, 46 Remote Desktop Protocol, 48 open source, 58 reverse enginering, 45 OpenAL, 46 ring -1, 10 OpenCL, 46 ring 0,5 OpenGL, 45, 46 ring 1,5 Optimized Power Management, 30 ring 2,5 OS level virtualization, 15 ring 3,5 OS/2,6 root mode, 10, 28, 33 Pacifica, 28 RTOS, 18 page table, 18 sandbox, 65, 68 pages, 18 SBE, 56 paging, 18 scan before execution, 56 pami˛eć,4 scheduler, 41 pami˛ećwirtualna, 18 seamless mode, 47, 59, 62 para, 12 server entity, 16 Parallels Virtuozzo Containers, 68, 69 shadow page table, 20 parawirtualizacja, 12, 16 Single-Root Input/Output Virtualization, 34 partycje sprz˛etowe, 16 SmartSelect, 63 patch, 67 SMP, 28 pełna wirtualizacja, 10, 14, 16 snapshot/commit, 62 PearPC,7 Solaris Containers, 59, 66 physics processing, 46 Solaris Zones, 66 PIO, 23 sparse zones, 67 point-to-point, 34 SPECjbb, 73 PowerNow, 30, 31 SR-IOV, 34 Presidio, 31 sterowniki parawirtualne, 38 procesor,4 Stream, 46 properitary, 45 stronicowanie, 18 protection rings,5,9 SVM, 28 QEMU,7, 55, 57, 59, 60, 72 swap, 22, 60 QEMU Lanucher, 58 swapping, 22 Qemulator, 58 syscall, 13, 67, 68 Qmuranet, 60 system operacyjny,4 QNX,6 Systems Network Architecture, 30 QuickPath Interconnect, 34 tablica stron, 18 qvm86, 57 Tagged TLB, 20, 30, 35 Rapid Virtualization Indexing, 29 task priority register, 34 ray tracing, 46 TLB, 18 87 topology aware scheduler, 41 VT-d, 33, 47 translation lookaside buffer, 18 VT-i, 33 transparent page sharing, 22 VT-x, 12, 33, 55, 60 Trusted Computing Group, 31, 35 Win4BSD, 65 Trusted Execution Technology, 35 Win4Solaris, 65 Trusted Platform Module, 31, 35 WINE, 63 Tungsten Graphics, 47 WireGL, 45 TV-x, 63, 64 wirtualizacja,4,8 TXT, 35 wirtualizacja na poziomie systemu, 15 ULE, 41 wirtualizacja operacji I/O, 22 UML, 70 wirtualizacja pami˛eci, 17 unified shaders, 46 wirtualizacja wspierana sprz˛etowo, 14 USB, 59, 62 wirtualne ´srodowisko, 16 user mode,6,8 Xen, 54, 55 User Mode Linux, 70 xVM, 55 userspace,5, 10, 16 ZFS, 67 Vanderpool, 32 zones, 67 VIA, 36 VIA NANO, 36 virtual environment, 16 Virtual Machine Device Queues, 33 Virtual Machine Interface, 13 Virtual Machine Manager, 60 virtual machine monitor,8,9 virtual memory, 18 Virtual Processor Identifier, 35 Virtual Router Redundancy Protocol, 50 VirtualBox, 58 Virtualization Technology for Connectivity, 33 Virtualization Technology for Directed I/O, 33 VMDq, 33 VMGL, 45 VMI, 13, 57, 61 VMM,8 VMware, 56 VMware Server, 61 VMware Workstation, 61 VMX root, 10 VPID, 35 VT-c, 33 88