BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM VIRTUALIZÁCIÓ 2006/2007. tavaszi félév Tanulmány Esettanulmány: a XEN VMM KÉSZÍTETTE: CSAPÓ ÁDÁM (OJCKX4) KASZA BÁLINT (GXUV56)
Tanulmány: a virtualizáció Bevezetés A virtualizáció definíciója Virtualizáció alatt általában a számítógépes erőforrások valamely absztrakcióját értjük. A fogalmat azonban számos környezetben, kontextusban használjuk, ezért igen nehéz pontos definíciót találni. Az Enterprise Management Associates nevű IT menedzsmenttel foglalkozó cég által javasolt definíció az alábbi: A virtualizáció olyan technika, amit arra használunk, hogy elválasszuk a számítógép erőforrásainak fizikai jellemzőit attól, ahogyan azokat más rendszerek, alkalmazások vagy felhasználók igénybe veszik. Ebbe beleértendő az is, hogy egyetlen erőforrás (pl. egy szerver, operációs rendszer, alkalmazás, adattároló) logikailag több erőforrásnak látszik, illetve az is, hogy több fizikai erőforrás (mint pl. tároló helyek, szerverek) egyetlen logikai egységnek látszik. Történelem A virtualizáció megjelenése az IBM nevéhez fűződik. Két vonalon is történt ennek a technikának a korai kutatása. Egyik esetben az 1960-as évek közepén az IBM Cambridge-i kutatóközpontjában fejlesztették a CP-40 nevű időosztásos operációs rendszert. Ez az operációs rendszer a S/360 nevű architektúrán futott, s gyakorlatilag teljes virtualizációt valósított meg azzal, hogy több külön virtuális gépet alkotott az egyetlen fizikai erőforráson. Ezek a virtuális gépek egymástól teljesen függetlenek voltak, s futott rajtuk minden szoftver, ami az eredeti gépen is, s nem csak azok, amelyek kifejezetten időosztásos rendszerre lettek fejlesztve. Ezeken a különböző virtuális gépeken futtatták a CMS (Conversational Monitor System) nevű egy felhasználós operációs rendszert. Ezt az együttest nevezzük CP/CMS rendszernek. A Control Program (CP) által létrehozott virtuális gépet akkor pszeudo gépnek nevezték. A másik vonalon egy New York-i központban az IBM M44/44X nevű rendszer fejlesztése folyt. Itt az IBM 7044 (M44) nevű számítógépét virtualizálták. A kapott virtuális gépek, képek nem feltétlen egyeztek meg a fizikai erőforrásokkal, így ezt részleges virtualizációnak nevezzük. Maga a virtuális gép elnevezés ebből a projektből származik. Az 1970-es évekre az IBM tovább fejlesztette a fizikai számítógépet, s olyan újabb technikákkal segítette a virtualizáció fejlődését, mint pl. a virtuális memóriák megjelenése. Az új számítógép az S/370-es nevet kapta, s a rá épülő virtuális gépes architektúrát nevezték VM/370-nek. Ez a virtualizációs technológiákat kínáló VM-sorozat ma is létezik az IBM-nél. A 80-as években alábbhagyott a lelkesedés a virtualizáció iránt, ezekben az években nem voltak különösebb átütő erejű fejlesztések e téren. A 90-es években újra felerősödött az érdeklődés és az igény a virtualizáció iránt. Ezúttal azonban már nem csak nagyvállalati, szerver oldali környezetben, hanem asztali alkalmazásra is. Az x86-os architektúra nem volt alkalmas virtualizációra, ezért egészen 1999-ig kellett várni, amikor is a VMWare-től megjelent az első x86-os gépen használható virtualizációs termék, a VMWare Virtual Platform. Két fő alkalmazási terület Eleinte ez a technika nem jelentett mást, mint virtuális gépek szimulálását adott fizikai erőforrásokon. Ez a felhasználási terület jelentkezett először, s a mai napig is inkább ezt értjük
virtualizáció alatt. A módszert platform virtualizációnak nevezzük. Az évek során kibővítették a virtualizáció értelmezését, s tágabb értelemben már erőforrások virtualizációjáról is beszéltek. Ez esetben nem akarunk semmilyen pszeudo gépet szimulálni, csupán a fizikai erőforrásokról van szó, amelyek másképp látszanak, másképp láttatunk, mint amilyenek valójában. Platform virtualizáció Ebben a fejezetben bemutatom a platform virtualizáció nyújtotta lehetőségeket sorba véve a fontosabb alkalmazási módokat. Amennyiben a virtualizációnak ezt a módját használjuk, szükségünk van bizonyos fizikai erőforrásokra, azaz egy virtualizációra alkalmas hardverre, amin ezt a szimulációt elvégezzük. Ezt a platformot nevezzük fogadónak, azaz host-nak. Ezen a platformon hozunk létre egy újabb környezetet, egy virtuális gépet. Ezt nevezzük vendégnek, guest-nek. Ez a vendég szoftver gyakran nem más, mint egy másik operációs rendszer, ami úgy viselkedik, mintha a meglévő fizikai erőforrásainkat használná, azaz, mintha a fogadó platformon futna. Attól függően, hogy ezeket az erőforrásokat mennyire, hogyan és milyen rétegeken keresztül virtualizáljuk több módot is megkülönböztethetünk platform virtualizáción belül. Az itt használt elnevezések nem biztos, hogy pontosan megegyeznek az irodalomban találtakkal, azonban a mögötte lévő működés alapján be tudjuk őket azonosítani. Emuláció Szimulációról vagy emulációról akkor beszélünk, amikor a virtuális gép egy teljes hardver környezetet használ, s a vendég szoftver valamilyen más, a fizikai erőforrástól eltérő erőforráson fut. Ezt az új (virtuális) környezetet tudjuk megteremteni emuláció segítségével. Ezt tipikusan akkor használják, amikor pl. egy új processzort fejlesztenek, de az még fizikailag nem áll rendelkezésre, így emulációval hozzák létre ezt az új környezetet. A Bochs nevű emulátort kipróbálhatjuk asztali gépünkön is, ezt általában régebbi operációs rendszerek, szoftverek futtatására használják. Az emulátor segítségével létrehozhatjuk a futáshoz szükséges hardver környezetet is. Komolyabb hardver környezetre (pl. az IBM nagyszámítógépekhez a Hercules emulator-t használják. Natív, teljes virtualizáció Teljes virtualizáció alatt azt értjük, hogy a virtuális gép, amin egy módosítatlan vendég operációs rendszer fut, rendelkezik az összes, futásához szükséges erőforrással. Ezeket az erőforrásokat teljesen irányítása alatt tartja megfelelve ezzel a követelményeknek. Ebben az esetben a szimulált környezet, azaz a virtuális erőforrások teljes mértékben megegyeznek a fizikai megfelelőjükkel. A natív virtualizáció abban jelent többet ennél, hogy a hálózati és az I/O műveletekhez valamilyen gyorsítást használnak teljesítménynövelés céljából. Ezt a teljes virtualizációt tipikusan akkor használjuk, amikor a rendszerünket több felhasználóval szeretnénk megosztani, illetve amikor a különböző felhasználói környezeteket biztonsági és megbízhatósági okokból szeretnénk elkülöníteni (izoláció). Gyakorlati példának a Microsoft Virtual PC-jét ill. a VMWare Workstation-jét kell itt megemlíteni. Részleges virtualizáció A virtualizációnak ez a módja abban különbözik az előzőtől, hogy ezúttal nem szimuláljuk a teljes fizikai környezetet, annak csupán egy részét. Más néven címtér
virtualizációnak is szokták nevezni, ami arra utal, hogy habár nem vagyunk kötelesek a teljes hardver környezetet szimulálni, a futó virtuális gépek külön címtérrel kell, hogy rendelkezzenek. Mivel nem biztosítjuk a teljes fogadó környezet virtualizációját, ezért itt nem érvényes az a feltétel, hogy minden, a fogadó platformon futó szoftvernek futnia kell a vendégen is. Tehát pl. részleges virtualizációkor nem is futnak teljes operációs rendszerek a vendég környezetben. Az ilyen típusú virtualiáció történelme egészen a 60-as évekig nyúlik vissza, az IBM M44/44X-es időkig, ahol ezt először alkalmazták. Paravirtualizáció Ennek a technológiának lényege, hogy a virtuális gépek alatt és a fizikai erőforrások fölött nem helyezkedik el host operációs rendszer, hanem a hardver fölött közvetlenül egy ún. hipervisor (virtuális gép monitor) működik, s a vendég operációs rendszereknek ezzel a hipervisorral kell kommunikálnia, dolgoznia. Ehhez szükséges a vendég operációs rendszerek módosítása, ami jelentős hátrányt jelenthet, hiszen nem minden operációs rendszer rendelkezik nyílt forráskóddal. A technológia óriási előnye, hogy mindössze 2-5%-os a teljesítménycsökkenés a tiszta hardveres megoldáshoz képest. Mintapéldának az újabb, 3-as verziójú Xen-t tudjuk ide sorolni, ő használ tisztán paravirtualizációt. Operációs rendszer szintű virtualizáció Amennyiben a virtualizációt operációs rendszer szintjén oldjuk meg, teljesítményt nyerünk, cserébe viszont lekötjük az operációs rendszerünket. Ez esetben ugyanis mindössze egyetlen operációs rendszerünk (egyetlen kernelünk) van, s azon belül kapunk több partíciót. Ezeket a partíciókat nevezhetjük virtuális környezeteknek (Virtual Environment, VE), vagy akár virtuális magánszervereknek (Virtual Private Server, VPS) is. Ezeknek a partícióknak az izolációja természetesen megoldott, így azok kívülről különálló egyedüli rendszereknek látszanak. Gyakorlati alkalmazásként megemlíthetjük a Linux-VServer projektet, ill. a SWsoft Virtuozzo megoldását és annak nyílt forrású változatát, az OpenVZ-t is. Alkalmazás virtualizáció Ebben az esetben az operációs rendszer és a futtatott alkalmazás közé egy új réteget helyezünk, ezt nevezzük virtuális környezetnek. Az alkalmazásunk teljes mértékben ezzel a virtuális környezethez (virtuális gép ) kapcsolódik, míg az operációs rendszerrel való kapcsolat az új réteg feladata. Így tehát az alkalmazás elhatárolódik a hardvertől és az azon futó operációs rendszer API-jától is. Erre a fajta virtualizációra tipikus példa a Java Virtual Machine (JVM). A Java-ban megírt alkalmazásunk minden esetben egy java virtuális gépen fut, s nekünk nem kell foglalkozni az alatta lévő hardverrel és operációs rendszerrel. Erőforrás virtualizáció A virtualizáció szót újabban műs kontextusban is alkalmazni kezdték. Ez esetben nem virtuális gépekről van szó, hanem valamely fizikai erőforrás absztrakciójáról. Ez esetben továbbra is fizikai erőforrásként látjuk, azonban valós tulajdonságait elrejtjük, s kívülről másképp láttatjuk. Itt három jelentősebb csoportot különböztetek meg:
Egy erőforrás többnek látszik Ebben az esetben egyetlen fizikai erőforrás létezik, ami logikailag kívülről azonban többnek látszik. Ezek a kifelé mutatott virtuális erőforrások különállóknak mutatkoznak, így azok felhasználói nem tudnak arról, hogy valójában közös erőforrást használnak. Gyakorlatban használt megoldásként ide sorolhatjuk a diszkek partícionálását, és az azonos adatbázishoz tartozó különböző nézeteket. Több erőforrás egynek látszik A virtualizáció ezen formája gyakorlatilag az előző ellentettjét jelenti: több fizikai erőforrás létezik, ezeket egybe fogjuk, s kifelé egy nagyobb, erősebb logikai egység látszik egyetlen interfésszel. Itt példaként megemlíthetjük a SAN-t (Storage Area Network), ahol több kisebb tároló egységet fogunk egybe. A felhasználó egyetlen tárolóként látja, s nem tud arról, hogy az adatai esetleg több lemezre is szétszóródhattak. Másik jellegzetes alkalmazás a fürtözés. Kívülről mindössze a fej látszik a szerverfürtből, s arról nem tudunk, hogy az valójában több szerverből, csomópontból áll. Több erőforrásból egyet látunk Ez a típus abban különbözik az előzőtől, hogy most a fizikai erőforrások replikának tekinthetők, s mind ugyanazt a virtuális erőforrást valósítják meg. Kívülről a virtuális erőforrást látjuk, s amennyiben valamilyen igényt intézünk felé, az választani fog bizonyos kritériumok alapján egyet a valós erőforrások közül, s azzal kiszolgáltatja az igényt. Ez a kritérium lehet erőforrás-kihasználtság, esetleg fizikai közelség stb. Példának ide sorolhatjuk azt az esetet, amikor bizonyos adatokat több helyen is tárolunk, s mindig a leggyorsabban elérhetőt használjuk (pl. RAID 1). Ezen kívül ide tartoznak még az alkalmazás konténerek is: a klienst nem érdekli, hogy melyik alkalmazás dolgozza fel a kérését, neki csak az az érdeke, hogy azt a lehető leggyorsabban megtegye. Legújabb alkalmazási területek Szerverkonszolidáció Ez a technika nagyvállalatoknak nyújt megoldást a több szerver használata esetén előjövő problémákra. A költséghatékony megoldás lényege, hogy a több fizikai szerverünk helyett használjunk egy nagyobb teljesítményűt, s azon futtassuk az egyes szervereinket virtuális környezetben. Tesztelés Új szoftverek esetén a teszthardver szűk keresztmetszet lehet. Ezt meg tudjuk kerülni úgy, hogy a tesztelő virtuális gépen tesztel, s ez a virtuális gép van a teszthardvernek megfelelően konfigurálva. Másik fontos alkalmazás tesztelés esetén lehet a már korábban említett emuláció, amikor egy még nem létező fizikai erőforrást (pl. processzort) tesztelünk, használunk virtuális környezetben.
Hordozható alkalmazások Legtöbb esetben amennyiben használni szeretnénk egy alkalmazást, telepítenünk kell azt. Ez a folyamat bizonyos beállításokat tárol el olyan helyeken, amelyek nem tartoznak közvetlenül az alkalmazáshoz (pl. Windows Registry). Az itt tárolt beállítások szükségesek az alkalmazások futtatásához, ezért azt nem használhatjuk másik gépen. Erre a problémára is megoldást ad a virtualizáció, amennyiben az alkalmazásunkat egy virtuális környezetbe helyezzük, s ezzel a környezettel együtt használjuk azt. A beállítások és egyéb személyes beállítások ebben a virtuális környezetben tárolódnak, így azok hordozhatóvá válnak az alkalmazással együtt. Deszktop virtualizáció A technika lényege, hogy a felhasználó és a számítógép, amelyet használni kíván, fizikailag távol van egymástól. Ilyen esetben a hálózaton keresztül kell használnia a gépet. Minden információt (kép a monitoron, egérmozgás, billentyűzet) továbbítani kell egy sessionel a hálózaton. A deszktop virtualizációt további osztályokra bonthatjuk: i) Egyszerű távoli asztal: a felhasználó az asztali számítógépéhez kapcsolódik a hálózaton keresztül egy másik számítógép segítségével valamely alkalmas szotfver használatával. Ez a szoftver lehet pl. a Windows Távoli Asztal alkalmazása. ii) Megosztott asztal: ez esetben a felhasználó egy távoli, sok felhasználós környezetet megvalósító szerverhez kapcsolódik, amikor a saját fiókját használja. iii) Virtuális gépek: itt minden felhasználó saját virtuális géppel rendelkezik, amelyen egy felhasználói fiókos operációs rendszert futtat. iv) Penge számítógépek (blade pc): ennél a típusnál a felhasználók asztali számítógép helyett csak egy vékony klienst használnak, amivel kapcsolódnak egy távoli központban tárolt ún. blade PC-hez, s annak minden erőforrását igénybe vehetik, nem kell másokkal osztozkodniuk azon.
Egy konkrét VMM bemutatása: Xen A Xen céljai A Xen egy x86-os processzor architektúrára készitett VMM (Virtual Machine Monitor), amelynek kiemelt célja 100-as nagyságrendben lehetővé tenni különböző operációs rendszerek egyszerre történő futtatását. Mindezt egy olyan környezetben kivánja elérni, amely garantálja az egyszerre futtatott operációs rendszerek egymástól való függetlenségét, biztonságos és igazságos erőforrás-menedzsmentet nyújt és minimális plusz futtatási költséget igényel a nem-virtualizált esethez képest. A Xen tulajdonságainak bővebb kifejtése az alábbiakban olvasható. A Xen főbb tulajdonságai Ahhoz, hogy a Xen olyan szolgáltatást tudjon nyújtani, ami minimális plusz futtatási költséget igényel a nem-virtualizált esethez képest, ún. paravirtualizációt kell megvalósitania. Ez azt jelenti, hogy a VMM által nyújtott hardver interfész nem teljesen azonos a fizikai számitógéparchitektúra által nyújtott interfésszel. A paravirtualizáció több szempontból is előnyös, azonban a fenti követelményeknek eleget tevő VMM-ben azért feltétlenül szükséges, mert az x86-os processzor-architektúra nem támogatja a teljes virtualizációt. Például, léteznek olyan felügyeleti parancsok, amelyeket csak speciális jogokkal lehet futtatni, és amelyeket ha módosítás nélkül továbbítana az x86-os processzor felé a virtuális réteg, akkor a fail-silent modell szerinti lekezeletlen hiba keletkezne. Az általános megoldás erre a problémára, hogy a VMM réteg dinamikusan átírja, lefordítja a kiszolgált operációs rendszer kerneljének kódját, hogy megfelelően jelezze a keletkezett hibákat az operációs rendszer felé. Ez a megoldás azonban jelentős plusz-költséggel jár, amit paravirtualizáció útján el lehet kerülni (a virtuális hardver már nem fail-silent modell szerinti hibát generál). A paravirtualizáció következménye, hogy a Xen VMM-en futtatott vendég operációs rendszerek alsóbb rétegeit módosítani kell. Kitüntetett célja viszont a Xen-nek, hogy mindez ne legyen kihatással az alkalmazói programokra. Az alkalmazói programok bináris kódja változtatás nélkül fut a Xen-architektúrán futó operációs rendszeren. A valós fizikai operációs rendszerekkel összemérhető teljesítmény nyújtása mellett fontos cél volt a Xen fejlesztése során, hogy megbízható módon elkülönítse a látszólag külön hardveren, azonban valójában egy fizikai hardveren futó vendég operációs rendszerek folyamatait. Ezt az alábbiakban taglalt védelmi mechanizmusok segítségével éri el. A Xen által nyújtott interfész Memóriakezelés Mivel az x86-os architektúrán nincsen szoftver-menedzselt TLB (translation lookaside buffer), hanem hardveres lapozótáblákban keresgél a processzor, ezért a Xen tervezői úgy döntöttek, hogy egyrészt a vendég operációs rendszerre bízzák saját címterük menedzselését a hardveres lapozótáblában (a hypervisor csak minimálisan avatkozik ilyenkor be, hogy biztosítsa a vendég operációs rendszerek szeparáltságát), másrészt pedig a, lapozótábla kiürítését elkerülendő, minden címtér felső 64 Mb-ja a Xen számára van fenntartva, így
kontextusváltáskor is elérhető (ez azért fontos, mert a hardveres lapozótábla nem címkézett, ezért csak egy címtér van, amit minden kontextusváltáskor üríteni kell). Ha egy vendég operációs rendszer új lapozóterületet kíván inicializálni (pl. mert új processzt hozott létre), akkor a saját számára lefoglalt memóriaterületből allokál egy darabot, és azt regisztrálja a Xen-nél. Ezt követően az operációs rendszer írási jogokat kap arra a területre. Lévén hogy az írási jog átadása komoly biztonsági kérdéseket vethet fel, ezért ezek az írási jogok korlátozottak. Erre példa, hogy csak saját maga által birtokolt lapokat írhat ki az operációs rendszer. Ezen kívül ezek a lapleképezések nem írhatóak (magyarán nem változtathatóak később). CPU interfész A hypervisor (vendég OS és hardver közötti felügyeleti réteg, amely pl. trap-eket generál az egyébként fail-silent hibákra) bevezetése megdönti azt az általános feltételezést, hogy az operációs rendszer kernel módban maximális jogokkal rendelkezik. Az x86-os CPU architektúra támogatja a futtatási jogok virtualizációját, mivel hardver szinten 4 különböző jogkört definiál. Ezeket általában 0-tól 3-ig számozva jellemzik (0 a legerősebb, a hardveren felügyeleti privilégiummal rendelkező szint, a 3 pedig a leggyengébb szint, amely szinten az alkalmazói programok futnak). Az OS/2-es operációs rendszer óta nem volt olyan jelentős operációs rendszer az x86-os architektúrán, ami az 1-es illetve 2-es szintű privilégiumokat használta volna. A Xen-ben ezért a vendég operációs rendszer 1-es szinten, míg a hypervisor 0-ás szinten fut. A privilegizált parancsok virtualizációját a fentiek alapján úgy oldják meg, hogy az operációs rendszer közvetlenül nem, csak a hypervisoron keresztül hajthat végre ilyen utasításokat (ez vonatkozhat pl. olyan esetekre, mint új lapozófájl létrehozására, vagy a processzor leállítására abban az esetben, amikor a vendég operációs rendszer tétlen). A kivételkezelés terén szinte semmilyen módosítást nem kellett végrehajtani az eredeti x86-os architektúrához képest, mivel a paravirtualizált CPU-ban megőrizték azokat az adatstruktúrákat (verem-típusú tárakat), amelyek a kivételkezelést lehetővé teszik. Az egyes kivétel-típusok lekezelésére külön táblázatot kell létrehozni a VMM-ben (mivel a vendég OS már nem végezhet kivételkezelést). A két leggyakoribb kivétel (rendszerhívások és lapozóhibák) közül a rendszerhívásokat általában szoftver-hibával kezelik, és elkerülendő a jelentős pluszköltségeket, úgy oldották meg a Xen-ben hogy ne kelljen a processzornak 0-ás privilégiumú üzemmódba kontextust váltania, hogy előre regisztrálják a VMM-ben a lehetséges rendszerhívásokat, amelyek ezek után 1-es üzemmódból is hívhatóak lesznek. Ugyanez nem tehető meg lapozóhibák esetén, mivel ilyenkor a CR2-es regiszter tartalmának kiolvasása lenne szükséges, amit nem biztonságos 1-es privilégiumú üzemmódból engedélyezni. I/O eszközök kezelése Ahelyett, hogy minden lehetséges periféria eszköz virtualizációját megvalósították volna, a Xen készítői leegyszerűsített periféria-absztrakciót hoztak létre, ami egyszerre teszi lehetővé a fizikai perifériák elérését illetve a különböző vendég-operációs rendszerekhez tartozó perifériák izolációját.
Alrendszerek megvalósítása Vezérlő mechanizmusok Kétféle vezérlő mechanizmus létezik, amelyek segítségével irányítható a Xen és a felette elhelyezkedő vendég operációs rendszer interakciója. A vendég operációs rendszerből szinkron hívások küldhetőek a Xen felé, amelyeket hyperhívásoknak neveznek. A Xen ezzel szemben aszinkron eseményeket generálva tájékoztatja a vendég operációs rendszereket a főbb eseményekről. A hyperhívasok interfésze hasonlóan működik a hagyományos operációs rendszerekben megszokott rendszerhívásokhoz. Az interfész segítségével a vendég operációs rendszer olyan műveletek elvégzését kérheti a Xen-től, mint pl. lapozófájlok allokálása. A UNIX-rendszerekhez hasonlóan viszonylag kevés jelzés létezik a Xen-ben, amelyek bizonyos események hatására jöhetnek létre. Ezeknek az eseményeknek a bekövetkeztét vendég operációs rendszerenként külön-külön, bittérképes struktúrában tárolják, és a Xen ennek felhasználásával periodikusan értesíti a vendég operációs rendszer által beállított eseménykezelőt. Adatátvitel mechanizmusai A vendég operációs rendszer és a perifériaeszközök közé behelyezett hypervisor miatt meg kell oldani az adatok transzparens, vendég operációs rendszer és a perifériaeszközök közötti átvitelét. Az adatátvitel tervezésekor a két legfőbb szempont az volt, hogy az erőforrás-menedzsment és az eseményriasztás követelményei ne sérüljenek. Ennek jegyében, a perifériáról érkező adatok esetében minimális költségűre igyekeztek szorítani a vendég operációs rendszer felé történő demultiplexelést, és a pluszköltséget jelentő puffermenedzsment-feladatokat olyan időpontra késleltetik, amikor a végrehajtás ideje az adott vendég operációs rendszer számlájára írható. Hasonló módon, az I/O műveletekre specializált memóriaterületeket inkább a vendég operációs rendszeren belül igyekeztek elhelyezni, hogy ezzel elkerüljék az osztott memóriák használata esetén fellépő interferenciahatásokat. A tényleges adatátvitelhez ún. aszinkron I/O gyűrűt használ a Xen. Ez tulajdonképpen egy gyűrűbe szervezett puffer, amely az I/O műveletekhez tartozó pufferek leíróit tartalmazza. A tényleges puffereket maguk a vendég operációs rendszerek foglalják le a saját idő- és térkvótájukban. A gyűrűhöz két pár termelő- és fogyasztómutató tartozik. A vendég operációs rendszer, amikor új adatot szeretne küldeni, elhelyezi a pufferleirót a gyűrűben és növeli saját termelőmutatóját. A Xen, miután feldolgozta a kérést, növeli saját fogyasztómutatóját. A perifériáról érkező adatok esetében ugyanez játszódik le, csak forditott szerepkörök szerint (egy másik pár mutatóval). A fentiekben leírt módszer kellően generikus ahhoz, hogy általánosan alkalmazható legyen. Fontos tulajdonsága még az adatmozgatásoknak, hogy a termelő- és fogyasztómechanizmusok elkülönülnek az értesítési mechanizmusoktól, és így a vendég operációs rendszer specifikálhatja, hogy hány kérésének teljesítése után kíván először értesítést kapni. Így elkerülhető a feleslegesen gyakori megszakítások szerencsétlen hatása.
Alrendszerek virtualizációja Az imént tárgyalt vezérlő és adatmozgató mechanizmusok minden alrendszer kialakításában fontos szerepet játszottak. Az alábbiakban ezen alrendszerek virtualizációjáról olvasható rövid összefoglaló. CPU-ütemezés A Xen az ún. BVT (Borrowed Virtual Time) ütemező algoritmust használja. Fontos előnyös tulajdonságai ennek az algoritmusnak, hogy munka-konzerváló (tehát az egyszer elvégzett számításokat nem kell újra és újra elvégezni), illetve, hogy gyors riasztási mechanizmust kínál a vendég operációs rendszer felé. Ez utóbbi nagyon fontos követelmény az olyan alrendszereknél, ahol a szigorú ütemezettségű futás alapelvárás (ilyen pl. a TCP, amely pontosan ütemezett nyugtákat igényel ahhoz, hogy a RTT round-trip time, azaz odavissza idő mérhető legyen). Időkezelés A Xen három fajta időt szolgáltat a vendég operációs rendszer felé: valós időt, virtuális időt és ún. falióra-időt. A valós időt nanoszekundum pontosságban méri, a processzor órajelével szinkronban (azonban lehetőség van külső forráshoz való szinkronizálásra is, pl. az NTP Network Time Protocol segítségével). A virtuális idő kizárólag akkor ketyeg, amikor éppen az adott vendég OS birtokolja a CPU-t. A virtuális idő segítségével végezhet a vendég operációs rendszer belső ütemezést az alkalmazói programok között. A falióra-időt offszetként tárolják, amit hozzá kell adni a valós időhöz (a kauzalitás megőrzésére csak pozitív lehet). A vendég operációs rendszerek számára két programozható riasztó óra áll rendelkezésre. Ezek közül az egyik valós időt, a másik virtuális időt használ. Virtuális címfordítás A korábbiakban már volt róla szó, hogy az x86-os architektúra hardveres lapozófájlkezelése nehézkessé teszi a memória virtualizációját. A VMWare ún. árnyék lapozófájlt készít, ami egy olyan virtuális lapozófájl, amit az MMU közvetlenül nem lát. A hypervisor felelős ekkor a memóriaelérések validálásáért, kezeléséért. Ez jelentős pluszköltséget jelenthet. A Xen-ben ezért úgy került megvalósításra a memóriakezelés, hogy a lapozófájlok közvetlenül az MMU-nál kerülnek regisztrálásra, azonban csak olvasható üzemmódban használhatóak. Amennyiben írni is szeretné a vendég operációs rendszer a lapozófájlt, olyankor a hypervisor elvégzi a megfelelő ellenőrzéseket. A Xen-ben minden egyes lapozófájl-egységhez típust és referenciaszámot rendelnek. A típusok egymást kölcsönösen kizárják, és a következők lehetnek: PD (page directory), PT (page table), LDT (local descriptor table), GDT (global descriptor table), vagy RW (writeable). Ezzel a mechanizmussal különválaszthatóak a jogosultságok. Fizikai memória A fizikai memóriát a Xen statikusan allokálja minden egyes vendég operációs rendszerhez. Létezik egy felső korlát is arra nézve, hogy mennyi memóriát birtokolhat maximális esetben egy vendég operációs rendszer.
A fizikai memóriakezelés ezen túl hagy némi szabadságot a vendég operációs rendszernek, amennyiben indokolt esetben allokálhatóak újabb memórialapok is. Ezek a műveletek a fentiekkel összhangban kizárólag a hypervisoron keresztül történhetnek meg. A lefoglalt memóriaterületek fizikailag általában nem folytonosak. Ezért lehetőség van arra, hogy a fizikai címekhez is hozzájusson a vendég operációs rendszer, hogy a kritikusan időérzékeny feladatokhoz tartozó kódot egymáshoz közel álló lapokra olvassa be. Általános esetben azonban csak virtuális címekkel dolgoznak a vendég operációs rendszerek. Hálózatkezelés A hálózati forgalom kezeléséhez ún. VFR (virtual firewall-router) absztrakciót definiáltak. Egy virtuális tűzfal-routerhez számos VIF (virtuális interfész) tartozik, amelyek logikai felépítése hasonlít a modern hálózati kártyákéhoz. Két I/O gyűrűt tartalmaznak a szükséges pufferleirókhoz, mindkét irányhoz külön-külön egyet-egyet. Ezen kívül mindegyik virtuális interfészhez (mintázat, akció) típusú szabályok tartoznak, amelyek tipikus esetben azt írják le, hogy adott IP-címhez és porthoz milyen irányba kell küldeni a csomagokat. Ezeket a bejegyzéseket a domain0 (az operációs rendszer privilegizált rétege) helyezi el a virtuális interfészben. A jelentős pluszköltségek elkerülése érdekében a beérkező csomagokat nem adja oda közvetlenül a vendég operációs rendszernek a Xen. Ehelyett azt a megoldást alkalmazzák, hogy egy használatlan memórialapért cserében kapja meg az operációs rendszer a csomagot. Ha nincs rendelkezésre álló használatlan memórialap, akkor a Xen a csomagot eldobja. Háttértárak kezelése Egyedül az operációs rendszeren belüli domain0-ának van közvetlen hozzáférési joga az IDE-s és SCSI-s háttértárakhoz. A vendég operációs rendszerek felsőbb rétegei kizárólag ún. VBD-ket (Virtual Block Device, virtuális blokkos eszköz) látnak. A VBD tulajdonképpen csak extenteknek egy listája, amely hozzáférési jogokat és tulajdonossági információkat is tartalmaz. A vendég operációs rendszer a fentiekben ismertetett I/O gyűrű mechanizmust használja az eszköz hozzáféréséhez. A kérések kiszolgálásának sorrendjét mind a vendég operációs rendszer privilegizált rétegei, mind a hypervisor befolyásolhatják. A vendég operációs rendszer szükség esetén le is tilthatja, hogy átsorrendezze kéréseit a hypervisor (pl. write-ahead log használata esetén). Új domain létrehozása Egy új vendég operációs rendszer elindítása esetén nem a Xen-ben, hanem az operációs rendszer domain0-jában kerül megvalósításra a legtöbb funkció, amely funkciók meghatározott vezérlő-interfészen keresztül érhetik el a Xen-t. Ezen az interfészen keresztül lehet elérni a vendég operációs rendszerhez tartozó memóriaterületet, illetve specifikálni a kezdeti regisztertartalmat. Ez a fajta megoldás jelentős költségcsökkentést eredményez, ugyanis a különböző operációs rendszerek változó mennyiségű memóriát igényelnek induláskor, és egy supremum érték beállítása sem célszerű, mert ez gyakran kiegészítő módosításokat igényel magán az operációs rendszeren belül is.
A Xen értékelése Az [1] hivatkozás leírja különböző benchmark tesztek futtatási eredményeit. Ezek a benchmarkok általában összetett alkalmazás-szintű feladatok, amik a rendszer különböző alrendszereit eltérő módokon terhelik le. Így lehetőség nyílik a Xen felett futó virtuális gépek teljesítményének összehasonlítására valódi, közvetlenül fizikai gépeken futó operációs rendszerekkel. A hosszan elnyúló, nagy számításigényű feladatok esetében minimális pluszköltség tapasztalható a virtuális gép használatakor, mivel ilyenkor kevés I/O műveletre van szükség, és ezért minimális a Xen-nel való interakció. Volt olyan benchmark is, amely során egy linux kernel fordítási idejét figyelték. Egy fizikai gépen átlagosan a CPU idő 7%-át tölti ilyenkor az operációs rendszer kernelében, ehhez kb. 3%-ot tett hozzá a Xen. Ez más virtuális gépekhez hasonlítva figyelemreméltó. A leggyengébben teljesítő benchmark az OLTP tranzakcióknál jött elő. Ennek az az oka, hogy az OLTP tranzakciók sok szinkron diszkműveletet igényelnek, ami megnöveli a biztonsági domainek közötti váltások számát. A Xen összehasonlitása más VMM-ekkel Általában elmondható, hogy a Xen túlteljesíti VMM-es vetélytársait (bár egyes termékekkel való összevetése szerzői jogok miatt nem közölhető). Ennek leglényegesebb oka a paravirtualizációban rejlik. A paravirtualizációnak azonban megvan az ára: módosítani kell a vendég operációs rendszerek legalsóbb (leginkább gépközeli) szintjeit. Ez a módosítás azonban az alkalmazói programok felületére nem hat ki. Hivatkozások: [1] Barham, Dragovic, Fraser, Hand, Harris, Ho, Neugebauer, Pratt, Warfield: Xen and the Art of Virtualization