Pełna wirtualizacja

to jest HTMLowa wersja prezentacji przeprowadzonej przez Stanisława Witkowskiego 7 stycznia 2005 roku. Oryginalne slajdy do te prezentacji znajdują się tutaj: PDF. 36 screenshotów Virtual PC znajduje się tutaj.

Wady przedstawionych do tej pory rozwiązań

Emulacja całego sprzętu (Bochs) jest strasznie wolna

Czemu?

każda instrukcja w SO guesta była symulowana przez kilka (lub więcej!) instrukcji SO hosta
(duży narzut!)
Każde odwołanie do sprzętu w SO guesta wymagała skomplikowanej emulacji tego sprzętu
(jeszcze większy narzut!)

A co z WINE?

wymagało żmudnego tworzenia bibliotek umożliwiających uruchomienie jakiejś windowsowej aplikacji
nowa wersja tejże mogła w najgorszym przypadku oznaczać konieczność wykonania pracy od nowa
uruchomienie mniej popularnych aplikacji było niemożliwe do czasu aż znalazł się ktoś, kto umiał (i chciał!) tą pracę wykonać

Co najważniejsze z punktu widzenia "popularności" projektu (nie wśród informatyków, ale ogólnie):

Żadna z dwóch opisanych już metod
nie jest odpowiednia dla "normalnego użytkownika"

(tzn. może w założeniach jest lub ma być,
ale na dzień dzisiejszy mało który zwykły użytkownik komputera
sobie z sobie z którąkolwiek z nich poradzi)

Gdzie leży rozwiązanie?

Rezygnując z uniwersalności Bochsa (emulowanie wielu architektur urządzeń) możemy zmniejszyć koszt wykonywanych na SO guesta operacji:
Ograniczamy się do "udawania" takiej architektury, na jakiej pracujemy, i staramy się wykonywać jak najwięcej operacji SO guesta bezpośrednio na sprzęcie.
Dopiero gdy niektóre operacje nie dadzą się w ten sposób wykonać poprawnie, emulujemy je programowo.

Co możemy uzyskać?

Przy takich założeniach możemy "normalnie" uruchomić obcy system operacyjny, a w nim dowolne jego aplikacje. Aplikacje te uruchamia się identycznie jak gdyby pracowało się na prawdziwym komputerze - czyli nawet "zwykły użytkownik sobie z tym poradzi."
Wydajność takiego systemu będzie bardzo przyzwoita.
Jesteśmy ograniczeni do tej samej architektury sprzętowej co host, ale... w zasadzie i tak korzystamy z jednej!

Co wykonywać bez emulacji?

w teorii:

wszystkie operacje wykonywane w trybie nieuprzywilejowanym

w praktyce:

dana architektura musiałaby być stworzona specjalnie pod kątem wirtualizacji, żeby wszystkie takie operacje dały się w ten sposób wykonywać
architektura X86 nie była stworzona pod tym kątem, więc...

Jak to działa?

pozwalamy procesom w SO guesta wykonywać swoje instrukcje normalnie - gdy dostajemy błąd ochrony, przechwytujemy go i emulujemy instrukcję, która go wywołała - zajmuje się tym VMM - Virtual Machine Monitor
Niektóre instrukcje wykonają się źle, choć ich nie przechwyciliśmy - niby nic nie zmieniają w systemie, ale np. sprawdzają jakieś flagi procesora i niejako orientują się, że coś jest nie tak (czyli po prostu się wywalają)
Są to m. in. na pewno świetnie znane z AKiPN: LAR, VERR, SMSW, STR, POPF, PUSHF itd. ;)
Musimy więc monitorować również wywołania tych instrukcji, o których wiemy że spowodują (lub istnieje szansa, że spowodują) problemy.

Słówko o przerwaniach

Bezpośrednio SO guesta nie ma dostępu do żadnego sprzętu
Myśli jednak, że ma - w szczególności zgłasza normalnie przerwania do niego
Przerwania te są przechwytywane przez VMM, który:
- przekazuje je "od siebie" do prawdziwego sprzętu, otrzymuje odpowiedź i przekazuje ją do SO guesta
- lub
- emuluje działanie danego sprzętu po otrzymaniu przerwania

Gdzie "przechowywać" VMM?

Może ona być zainstalowana bezpośrednio na maszynie, a dopiero na niej byłyby wtedy "równoprawnie" zainstalowane różne systemy - o tym za chwilkę
lub
Może się ona znajdować w SO hosta jako zwykły proces - o tym szerzej za dwie chwilki

Wirtualizacja na poziomie sprzętu

Na najwyższym poziomie uprzywilejowania (nr 0) uruchomiona jest VMM
Kod wszystkie systemów operacyjnych, które chcemy zainstalować musi być zmodyfikowany tak, aby pracowały one na drugim poziomie (nr 1)
Kod aplikacji uruchamianych na tych SO nie musi być zmieniany - wciąż mają one działać na poziomie najniższym

Poziom sprzętu cd. - przykład

XEN
Xen jest modelowym przykładem wirtualizacji na poziomie sprzętu. Instaluje się na "goły" komputer X86.
Każdy z przyszłych SO działa w tzw. "domenie".
Jeden z zainstalowanych SO jest wyróżniony - startuje od razu po starcie komputera, zawiera w sobie panel administracyjny XENa, umożliwiający tworzenie nowych domen oraz rozdzielanie zasobów komputera pomiędzy istniejące domeny(porcjujące dostęp do urządzeń oraz czas procesora).
Na każdej domenie instalujemy SO tak, jakby działo się to na normalnym sprzęcie. Oczywiście tak jak napisałem wyżej kod instalowanego SO musi być odpowiednio zmieniony.
Obecnie dostępne są zmodyfikowane systemy: Linux 2.4 i 2.6 oraz NetBSD, FreeBSD jest "nearing completion"), windowsów nie przewiduje się (problemy licencjonowania).
SO na każdej z domen widzi tylko te zasoby, które zostały mu udostępnione, zarządza więc nimi tak jakby była to cała maszyna.
XEN ma jedną podstawową zaletę - jest szybki. Jest bardzo szybki. W zasadzie nie ma żadnego innego sposobu wirtualizacji (czy emulacji) który byłby szybszy. Straty wydajnościowe w stosunku do normalnie zainstalowanego SO są rzędu kilku procent, praktycznie niezależnie od rodzaju wykonywanych operacji.

Przykład 2 - Wirtualizacja na poziomie SO

Chociaż aplikacje na XENie działają normalnie, to jednak trzeba się trochę napracować przy dostosowywaniu systemu. Przy emulacji na poziomie SO nie ma tego problemu.

Microsoft Virtual PC 2004

motto: Istnieje życie poza Linuxem!

jak to w ogóle wygląda?

Microsoft Virtual PC 2004: (porównując do innych aplikacji pod Windows)

zajmuje wyjątkowo mało miejsca
działa wyjątkowo przyzwoicie
po odinstalowaniu nie zostawia śmieci w systemie
posiada wersję pod inną niż windowsowa platformę!

Jak to możliwe?

Krótki rys historyczny

to całkowicie normalne biorąc pod uwagę, że to nie Microsoft napisał ten program.
Virtual PC 5.2 zostało zakupione przez Microsoft 19 lutego 2003 roku od firmy Connectix Corp. (która to z resztą zniknęła z rynku - Virtual PC było jej jedynym udanym dzieckiem)
Virtual PC przemianowane na "Microsoft Virtual PC 2004" 2 grudnia 2003 roku zostało wypuszczone na rynek, jako "next generation of virtualization"
Wersja mac'owa została nazwana Microsoft Virtual PC for Mac 7
Zmiany były - jak można się domyślić - niewielkie. (głównie polepszenie działania DOSa)

"Wizja" ;)

"po naszemu" Virtual PC ma po prostu wirtualizować architekturę komputera X86.
po "ichniemu" ma umożliwiać uruchamianie wielu systemów operacyjnych jednocześnie, w celu:
- testowania aplikacji na różnych SO (screenshot z MS)
- uruchamiania w firmie przechodzącej na nowy SO (oczywiście MS) programów, które w nim nie działają
używany ponadto do:
- symulacji sieci - a dokładniej symulacji pracy aplikacji sieciowych
- testowania łat na SO i tworzenia nowych SO
- uruchamiania potencjalnie niebezpiecznego softu

Małe diagramiki prosto z Redmond

Normalny komputer	Komputer z Virtual PC

Obsługiwane SO

w roli hosta może wystąpić:
- Windows XP Professional
- Windows XP Tablet Edition.
- Windows 2000 Professional
w roli guesta może wystąpić:
- Windows XP (home i prof.)
- Windows 2000 Professional
- Windows NT 4.0 Workstation (wymagany SP6a)
- Windows ME, 98, 95
- MS-Dos 6.22
- OS/2
A co z linuxem?
- Linux nie jest supportowany przez Microsoft (dziwne, prawda?)

Słówko o innych systemach

Linux nie jest supportowany, ale:
- Microsoft nie supportuje przecież żadnej aplikacji nie wyprodukowanej przez siebie (niezależnie czy uruchomionej w VM czy normalnie),
- Virtual PC to przecież wirtualizacja X86,
więc...
- Linux działa normalnie (w większości przypadków)
- Podobnie większość innych SO na X86
- z niektórymi trzeba się jednak napracować przy instalacji

To co w końcu działa?

Lista SO dla X86 utworzona pod kątem działania z Virtual PC znajduje się tu:

http://vpc.visualwin.com/

Są tam też opisy (bardzo dokładne), jak zainstalować te z SO, które stwarzają problemy

Powtórka z zasad działania

Virtual PC to przykład wirtualizacji na poziomie systemu operacyjnego - emuluje programowo większość sprzętu komputera X86 (oprócz procesora*)
Virtual PC stanowi dodatkową warstwę pomiędzy SO hosta a SO guesta - przez warstwę tą przechodzą wszystkie "zewnętrzne" operacje aplikacji SO guesta
wirtualizowanemu systemowi operacyjnemu wydaje się, że pracuje na całkowicie niezależnej maszynie
urządzenia wejścia/wyjścia są "przekierowywane" z hosta

* Virtual PC for Mac emuluje również procesor

Sprzęt w Virtual PC

Wszystkie maszyny wirtualne "widzą" w komputerze taką samą konfigurację podstawowych urządzeń
Jest to stała konfiguracja dla całego Virtual PC 2004
W jej skład wchodzi płyta główna na chipsecie Intel 440BX, karta graficzna S3 Trio, karta sieciowa DEC/Intel 21140A oraz karta muzyczna Sound Blaster 16 ISA
Nie można podmieniać wymienionych wyżej składników - jeśli nasz guest nie umie ich obsłużyć, to go nie uruchomimy :(

Sprzęt w Virtual PC - pamięć

Virtual PC korzysta bezpośrednio z pamięci operacyjnej hosta
Przy instalacji nowej maszyny wirtualnej ustalamy, jaką część pamięci chcemy przeznaczyć na działanie guesta (ilość tą możemy zmienić w każdym momencie, o ile VM jest wyłączona)
Ustalona w ten sposób ilość pamięci jest stale zaalokowana dla guesta, aż do zamknięcia maszyny wirtualnej

Sprzęt w Virtual PC - dyski

Dyski twarde możemy podłączyć do VM na cztery sposoby:
- wirtualny dysk twardy
- wirtualny dysk twardy o stałym rozmiarze
- dysk "różnicowy" (differencing) w stosunku do innego dysku wirtualnego (czyli dysk, który będzie udawał inny dysk wirtualny, ale wszelkie zmiany będzie zapisywał u siebie, a tamten dysk pozostanie nietknięty - bardzo przydatne!
- podczepiony dysk fizyczny (podobno tylko do "advanced users")

Sprzęt w Virtual PC - dyski wirtualne

Co to są wirtualne dyski?
- system operacyjny guesta widzi dysk o dużej pojemności (w Virtual PC domyślnie 17GB)
- dane SO guesta przechowywane są w jednym pliku na dysku hosta
- wraz z nowymi danymi zapisywanymi na dysku guesta rośnie objętość pliku na dysku hosta
- w teorii więc taki plik zajmuje tyle miejsca, ile cała jego zawartość
- w praktyce zajmuje tyle, ile jego pofragmentowana zawartość

Sprzęt w Virtual PC - inne

Napędy optyczne i magnetyczne guesta są symulowane z plików .iso z obrazami zawartości poszczególnych nośników, lub mogą być podpięte pod prawdziwe stacje dyskietek i napędy płyt
Nie działa USB, FireWire :(
Nie działają wszelkiej maści dongle podczepiane do LPT (padło pytanie co to jest dongiel - to jest takie małe coś, co niby jest przejściówką jakiegoś portu (najczęściej LPT) i stanowi sprzętowe zabezpieczenie przeciwko piractwu. Masowo korzystały i korzystają z tego programy księgowe pod DOSa - bez podczepionego dongla w ogóle się nie uruchamiały. To, że w Virtual PC dongle nie działają psuje piękną wizję Microsoftu o firmach przechodzących na nowe Windowsy a dzięki Virtual PC wciąż korzystających ze starych dosowych programów, które pod XP nie zadziałają)

Sprzęt w Virtual PC - procesor

procesor nie jest emulowany - jest dzielony z hostem
jak można się domyślić - niezbyt sprawiedliwie
jeśli SO hosta wykonuje aktualnie zasobożerną operację, SO guesta jest niejako "zwalniany" (praktycznie nie otrzymuje dostępu do procesora)
w przypadku wolnej mocy obliczeniowej na hoście jest ona przekazywana do guesta
wniosek - jeśli oczekujemy dużej wydajności na SO guesta, musimy zadbać o niezbyt duże obciążenie hosta
podobnie ma się sprawa z innymi zasobami komputera, np. współdzielonym łączem internetowym itp.

Opis do powyższego rysunku: po pierwsze widać, że sieć działa ;) Po drugie widać, że pingi są zróżnicowane - prawdopodobnie w pingu nr 1 i 3 łącze internetowe było prawdopodobnie wykorzystywane przez hosta, dostęp do niego zajął chwilkę dłużej niż w przypadku 2-go pinga.

Dygresja o sieci w Virtual PC

Mamy normalny dostęp do sieci lokalnej i internetu, ale... Tylko poprzez DHCP! (IP 192.168.131.xxx), czyli... Programy wymagające stałego IP nie będą działać :(

Przełączanie kontekstu

Skoro procesor jest dzielony między VM a hosta, to co jakiś czas potrzebne jest przełączenie kontekstu
O ile operacje wykonywane na SO guesta na to pozwalają (a sytuacja tego wymaga), są one grupowane* do następnego przełączenia kontekstu - jeśli natomiast na to nie pozwalają, są wstrzymywane aż przełączenie nastąpi
Im bardziej obciążony host, tym rzadziej** następuje przełączenie kontekstu

* Grupowane = nie wykonywane po jednej, ale po 2-3
** rzadziej = stosunkowo rzadziej, bo i tak jest to bardzo częste

Ficzery Virtual PC

Można wyłączyć VM z zapisaniem stanu sesji
Na koniec sesji można zdecydować, czy zmiany dokonane w VM od startu mają być zachowane, czy nie
Możliwe jest tworzenie współdzielonych folderów pomiędzy hostem a SO guesta
Można stosować technikę "drag & drop" pomiędzy hostem a guestem - o ile jest to Windows ;)
Klawiatura i myszka przekazują sygnał do hosta lub guesta w zależności od tego, czy okno VM jest aktywne czy nie

VMware

obecny w sumie dla króciutkiego porównania

Produkt bardzo podobny do Virtual PC
Umożliwia użycie jako hosta również Linuxa
Zaawansowane ustawienia sieciowe (w tym oczywiście stałe IP)
Również płatny (60$ więcej nic Virtual PC)

Czemu więc ludzie używają Virtual PC?

Jedynym rozsądnym podawanym przez użytkowników Virtual PC argumentem jest to, że jego praca nie wpływa znacząco na pracę SO hosta, podczas gdy VMware, choć też bardzo wydajny, czasami (rzadko!) powoduje "przywieszenie się" macierzystego systemu.

Instalacja

Instalacja Virtual PC jest banalnie prosta, jak to pod Windowsem bywa. Next, next, next, finish.

Screenshoty

Screenshoty z działania Virtual PC z Windowsem 98, PLD i Fedorą znajdują się tutaj tutaj.

Linki

Strona Virtual PC
Strona Virtual PC for MAC
Downloads m. in. obrazy dysków z Windows 98 (do dodania jedynie ISO i CD-KEY, oszczędza się czas instalacji!)
FAQ:
Oficjalny
Nieoficjalny i lepszy
Grupa dyskusyjna:
Na serwerach MS
Inne:
Lista systemów pod X86 pod względem działania z Virtual PC (szczegółowe opisy instalacji problemowych systemów, m. in. Fedory)
Niektórzy używają Virtual PC do robienia screenshotów innym SO: Longhorn

(bardzo) krótkie podsumowanie

	Czysta emulacja (Bochs)	Emulacja API (WINE)	Wirtualizacja na poziomie sprzętu (XEN)	Wirtualizacja na poziomie SO (Virtual PC)
Inna architektura Czy użycie na innej architekturze jest możliwe?	Tak łatwe do realizacji	Możliwe kosztowne w realizacji (trzeba sporo kodu napisać od nowa)	Nie (praktycznie wszystko trzeba by napisać od nowa)	Możliwe strata wydajności (no i w zasadzie stało by się to czystą emulacją)
Zależność od SO hosta W jakim stopniu SO guesta zależy od SO hosta?	brak	całkowita	brak	średnia (część rzeczy można robić niezależnie od niego, do niektórych rzeczy musimy się odwoływać za jego pośrednictwem)
Inny SO guesta Czy można zainstalować inny SO niż przewidywany?	Tak	Możliwe trzeba emulować inne API (czyli pisać sporo rzeczy od nowa)	Tak o ile nowy SO będzie przystosowany	Tak
Wydajność Na ile metoda jest wydajna?	BARDZO mała	Dobra	ŚWIETNA	dobra

Ciekawostka - Wirtualna Maszyna Javy

To, że przy nazwie "Java" często pojawia się sformułowanie "wirtualna maszyna" nie jest przypadkiem. Zalety tworzenia wirtualnych maszyn zostały wykorzystane do stworzenia samej Javy jako języka programowania. Na każdym SO instaluje się emulator nieistniejącej, abstrakcyjnej maszyny, po czym pisze się programy pracujące bezpośrednio na niej. Ponieważ specyfikacja tej abstrakcyjnej maszyny jest dokładnie określona mamy pewność, że program napisany na jednym SO będzie działał na drugim (w końcu nie zostanie bezpośrednio uruchomiony na tym innym SO, a jedynie na emulacji tej samej abstrakcyjnej maszyny).
Więcej szczegółów a propos Javy można znaleźć na stronie SUNa oraz w prezentacji przygotowanej przez Jarka z okazji ZPP (PDF).

Uwagi i linki:

strona główna Virtual PC. Virtual PC nie pozwala na uruchomienie na PC systemu MACowego - do tego można użyć Pear PC.
strona VMware
Zarówno Virtual PC, jak i VMware są oprogramowaniem komercyjnym (kosztują odpowiednio 129$ i 189$). Obydwa produkty są udostępniane w pełnych wersjach trial na stronach producentów (odpowiednio 45 i 30 dni). Virtual PC studenci MIMUWu mogą mieć za darmo, w ramach uniwersyteckiej licencji Microsoftu (szczegóły)
Strona Bochsa
Strona WINE
strona XENa
Strony innych przykładów wspomnianych na wstępie rodzajów wirtualizacji:
- "czysta emulacja" - wspomniane wcześniej Pear PC oraz QEMU i DOSEMU.
- "pełna wirtualizacja": UML, Transitive