Xen - základy virtualizácie

19. 11. 2008 | Ivan Dirbák | Systém | 14038×

Xen je open-source virtualizačný software určený pre linuxové hostiteľské systémy. Článok obsahuje zakladný popis princípov virtualizácie a paravirtualizácie, rovnako ako možnosti realizácie virtualizácie pomocou Xenu.

Úvod

Vznikol na univerzite Cambridge (UK) odštiepením od projektu Xenoserver určenom k vývoju infraštruktúry pre distribuovaný výpočet. Prvá verzia XENu (1.0) bola uvoľnená v roku 2003. V súčasnosti existuje už verzia XEN 3.3. ktorá sa  využíva v rozličných komerčných prostrediach na beh štandardných ale aj bussiness critical aplikácií. V tomto článku popíšem základné princípy virtualizácie prostredníctvom virtualizačného software XEN.

Virtualizácia a požiadavky na ňu kladené

Virtualizácia umožňuje simultánny beh niekoľkých virtuálnych mašín (VM) na jednom fyzickom hardware, pričom je zaručená ich vzájomná izolácia. Keďže VM zdieľajú spoločný prístup k HW, musí byť virtualizácia navrhnutá tak, aby pri tomto zdieľaní došlo k minimálnemu poklesu výkonu. Z administrátorského hľadiska by bolo vhodné zabezpečiť centrálnu administráciu virtuálnych mašín a dynamickú relokáciu zdrojov prípadne samotných VM bez toho, aby došlo k prerušeniu služieb. Vzhľadom k operačnému systému bežiacom na samotných virtuálnych VM by mal byť virtualizačný software navrhnutý tak, aby nebola nutná jeho modifikácia.

Privilegovaný režim procesora

Súčasné procesory dokážu bežať v rôznych režimoch z dôvodu ochrany proti neautorizovanému prístupu k fyzickému procesoru a hardware (reálny, privilegovaný, nereálny mód, virtuálny reálny režim ai.). Z pohľadu virtualizácie nás najviac zaujíma privilegovaný režim procesora. Tento režim vytvára tzv. chránené úrovne, označované tiež ako kruh (ring). Procesory x86 rozoznávajú štyri kruhy, ktoré sú číslované od 0 do 3 (viz Obr. 1). Najnižší - kruh0 - je označovaný aj ako “supervisor mode“ a je to úroveň s najväčšími privilégiami vzhľadom k prístupu k hardwarovým prostriedkom. Na tejto úrovni beží jadro operačného systému, správa pamäti, kontrola prístupu k HW a privilegované inštrukcie, tzn. inštrukcie, ktoré môžu ohroziť beh systému. Kruh 1 a 2 sa používajú minimálne, kruh3 je označovaný ako „user mode“ a je určený pre beh neprivilegovaných inštrukcií, tj. užívateľských aplikácií.

Obr. 1: Úrovne privilegovaného režimu.

Xen

Pri virtualizácií prostredníctvom virtualizačného software XEN dochádza k niekoľkým zmenám oproti predchodziemu popisu. Jadro operačného systému nebeží v supervisor mode, ale na menej privilegovanej úrovni v závislosti na tom, či je použitá 32bit. architektúra (kruh1), alebo 64bit. (kruh3). Keďže je jadro OS presunuté, dochádza k závažnému problému s vykonávaním privilegovaných inštrukcií – tie samozrejme nie je možné spúšťať na úrovni kruhu 1 resp. 3. Pokus o ich spustenie by vyvolal chybový stav. Jedným z riešení by mohol byť prechod do kruhu0, kde by sa vykonala operácia s následným návratom. Toto riešenie však znamená značnú degradáciu výkonu. XEN na rozdiel od predchodzieho riešenia využíva paravirtualizáciu. Pre vykonávanie privilegovaných inštrukcií je v kruhu0 zavedená vrstva označovaná ako hypervisor (viz Obr. 2), ktorý je akýmsi sprostredkovateľom medzi hardware a virtuálnymi mašinami XENu.

Obr. 2: XEN a začlenenie jeho komponentov v úrovniach privilegovaného režimu.

Hypervisor spolu s modifikovaným kernelom operačného systému nielenže spravuje prístup k pamäti a ostatnému hardware, ale slúži aj k monitorovaniu a administrácií virtuálnych mašín. Tento modifikovaný kernel sa nazýva domain0 (v skratke dom0). Domain0 následne spúšťa ďalšie tzv. neprivilegované domény označované aj ako domainU (v skratke domU). Detailné informácie o každej domU sú uložené v konfiguračnom súbore domény (konfigurácia siete, grafická podpora, pamäť, plánovač ai.). Konfiguračný súbor taktiež poskytuje mechanizmus pre priradenie jedného alebo viacerých CPU k danej doméne, aby zabezpečil, že v prípade potreby vyšších výpočetných nárokov bude doméne priradene priradená adekvátna výpočetná sila.

Obr. 3: Základné komponenty virtualizácie pomocou Xenu.

Podobne ako aplikácia komunikuje s operačným systémom prostredníctvom systémových volaní, komunikujú domU s hypervisorom prostredníctvom volaní označovaných ako hypercally. Jedná sa o softwarové volania, ktoré sú reakciou napr. na potrebu vykonania privilegovaných operácií. V prípade, že procesor hardwarovo nepodporuje virtualizáciu, označuje sa domU ako „paravirtual guest“. V tomto prípade je nutné modifikovať operačný systém tak, aby zabraňoval spusteniu privilegovaných operácií a v prípade potreby vykonania týchto operácií volal hypervisor pomocou hypercallov. Tento proces je naznačený na obrázku 4.

Obr. 4: Porovnanie vykonávania privilegovaných operácií v paravirtualizovanom a natívnom móde.

Moderné procesory ako Intel VM (Virtualization technology, aka vanderpool), a AMD-V/SVM(Virtualization/Secure Virtual Nachine, aka pacifica), obsahujú hardwarovú podporu virtualizácie. Týmto pridávajú sadu nových inštrukcií pre podporu virtualizácie na úrovni Kruh1. Výsledokom je, že nie je nutná zmena OS a teda dochádza k plnej virtualizácií.

V prípade simultánneho behu viacerých domU plánovač hypervisoru zisťuje, ktorá VM má mať pridelený fyzický procesor a v akom poradí. XEN spočiatku podporoval plánovače round robin a bvt (borrowed virtual time). Tieto však boli postupom času odstranené a nahradené plánovačmi sedf a credit (pridelenie na základe výsledkov merania), ktoré využíva XEN verzie 3.x. Výber plánovača sa volí ako parameter v konfiguračnom súbore Grub loadera (pozn. Grub je jediný bootloader podporovaný XENom). Okrem samotného plánovača hypervisora každá VM implementuje svoju vlastnú politiku plánovania pre procesy bežiace vo vnútri domény k poskytovaniu I/O požiadaviek vo vnútri jadra (SCHED_FIFO, SCHED_NORMAL, SCHED_BATCH, SCHED_RR).

Záver

Zmeny OS vyžadované pre interakciu s hypervisorom nemenia vyšší level kernelu (nieje nutné modifikovať aplikácie) ale len kernel level kód, ako napríklad drivery zariadení. Dochádza teda k paravirtualizácii, čím je zaručený minimálny pokles výkonu virtuálnych mašín. Do doby, kým nebola pridaná HW podpora virtualizácie, bolo možné púšťať len 32bit. XEN domU na fyzickom hoste, ktorý bežal na 32bit. hypervisore a dom0. S nástupom HW podpory virtualizácie zavádzajúcej kruh1 umožňuje XEN aj podporu plnej virtualizácie. Výsledokom je, že XEN podporuje 32 a 64bit. virtuálne mašiny rôznych typov na jednom systéme bez nutnosti modifikácie OS.

Nie som špecialista na virtualizáciu, avšak táto téma je hodne zaujímavá, preto by som v prípade nejakých nepresností poprosil o pripomienky.

       

Komentáře

[Láďa]

Skvělé, jenom škoda že Xen už není virtualizační hvězda jako býval - seriál by byl hned mnohem zajímavější. V současné době má přece jenom mnohem zářivější budoucnost KVM, jednak protože je podporováno dvěmi nejvýraznějšími distribucemi (Redhat a Ubuntu) a druhák protože je oblíbené mezi Linuxovými hackery.

[Pavel F.]

KVM má možná budoucnost, ale v současnosti bych stále volil Xen, zejména pro mission-critical aplikace. Xen bych nazval vyzrálým systémem, kde dnes můžeme sklízet plody, u KVM uvidíme za jeden, dva roky, kam nám doroste.

[Nikola Ciprich]

na zaklade ceho byste oznacil XEN za vyzralejsi, zvlaste pro mission-critical aplikace? ze svych zkusenosti bych rekl ze mnohem bezproblemovejsi je KVM, at uz z hlediska funkcnosti, tak i z hlediska diagnostiky chyb, odezvy vyvojaru, celkove koncepce vyvoje atd...

[Black.Stone]

treba tim ze je nejakou dobu XEN v RHEL supportovany? Nebo snad nekdo nasazuje mission-critical aplikace na nesupportovany SW/HW?

[xm]

Představ si, že na mission-critical aplikace se používá i třeba takový Debian.

[xm]

Já bych naopak za mnohem vyzrálejší řešení nazval KVM (a to přesto, že je mnohem mladší - i to něco vypovídá o jeho kvalitách).

[SAL]

XEN stale vedie, ale je fakt, ze KVM sa v poslednom case vyvija velmi rychlo a naopak XEN dost pomaly.

KVM stale postrada:

  - live migraciu (migraciu za behu virtualneho systemu)
  - paravirtualizacia je stale v plienkach. Paravirtualne ovladace disku/sietovky znacne urychluju beh. Paravirtualne servery nepotrebuju podporu virtualizacie v HW.
  - nejaka vhodne nastroje na spravu virtualnych serverov (start, stop, restart, pripojenie na konzolu, ...) su v plienkach
  - sprava zariadeni v KVM je tiez dost obmedzena

Co sa tyka virtualizacie na desktope, tak KVM urcite vedie. Co sa tyka virtualizacie na servri, tak Xen stale vedie.

[Láďa]

- Live migraci KVM umí.

- Díky virtio je výkon KVM při komunikaci s hostem výborný. A HW bez podpory virtualizace jsou už muzejní kousky.

- libvirt vyvíjený Redhatem je dost dobře použitelný. Sériová konzole je trabl, na druhou stranu VNC do guesta funguje skvěle.

Virtualizace na desktopu je spíš doménou produktů jako VirtualBox nebo VMware, které se zaměřují na pohodlí a už tolik neřeší výkon. Xen samozřejmě je v tuhle chvíli napřed, protože je déle podporovaný Redhatem a Novellem a protože tu jednoduše byl dřív. Ale třeba u Redhatu to může být otázka jenom do vydání RHEL 6, protože je jasné, že po zaplacení 107 mil. USD za Quamranet sotva budou pokračovat ve výrazné podpoře Xenu (už dříve koupeného Citrixem za 500 mil. USD - skvělý obchod).

[miso]

Prosim no flame - ako Ubuntu podporuje XEN?

[miso]

... samozrejme som myslel KVM

[Láďa]

Víc info tady. Z vlastní zkušenosti můžu říct, že nástroj ubuntu-vm-builder není tak dotažený jako xen-tools, ale samotný běh KVM je bezproblémový.

[miso]

Ale nepytal som sa ci preferuje, ale ako ho podporuje ...(nieco taketo)
Inak suhlasim, ze KVM ma nabeh zatienit XEN, ale ten den este neprisiel

[Láďa]

Podporovat má dva významy - do oblíbené diskuze jestli Ubuntu dostatečně přispívá do upstreamu nechci zabíhat

[nettezzaumana]

hmm .. nestacil by priste misto takto pozoruhodneho clanku jen odkaz na wiki ??

nechci rejpat, ale informacni hodnota mi pripada miziva ..

regards

[nettezzaumana]

pouzivame ve firme Xen i kvm a mohu prohlasit, ze s KVM jsme nemeli diky bohu jediny problem a me osobne pripada transparentnejsi, efektivnejsi a ve virtualizaci linuxoveho kernelu temer spolehlivejsi nez Xen ..

[Kerala]

Předpokládám, že MS Hyper-V vychází z XENu, takže XEN nemusí být jenom pro linux.

[xxxs]

esteticke chybicky:

označovaných ako hypercalli -y

potrebu vykonanie -vykonania

nieje -nie je

kernel level kod -kód

Dochádza teda k paravirtualizácií -cii

virtualne mašiny -virtuálne

Niesom -nie som

clanok sa mi pacil.

[Stevko]

predchodziemu -> predchádzajúcemu/predošlému

A nejak sa strácam v článku (a asi aj v problematike). Viackrát je tam spomenutý operačný systém (a že ho treba nejak upravovať), ale neviem, či hostiteľský (ak tam vôbec niečo také je) alebo ten vo virtuálnom stroji.

[Luboš Doležel (Doli)]

Opraveno.

[artec]

Informacni hodnota clanku mi prijde uplne nulova ve srovnani s tim, co vyslo asi pred rokem a pul na rootu. Bude mit clanek nejake pokracovani s nejakou praktickou casti?

[dannak]

Nemate nekdo, prosim, tuseni, jestli ve VM v XENu, kdyz budu mit procak s HW virtualizaci (Core i7), pujde accelerace videa ? resp. pristup k HW ? jde mi o programovani v CUDE (grafika NV9500GT), ne tak o video acceleraci, ikdyz i to by bylo prijemny.

Nebo by melo spis smysl mit jako "podvozek" treba Gentoo64bit a v tom nekolik masin v KVM ? chci jednu VM na databazi, druhou na WWW server, treti na windowsy a mozna jeste jedna se bude hodit na hrani... Diky, s virtualizaci mam zatim zkusenosti jen s VMWare-serverem (ne ESX(i)) a VirtualBoxem, XEN ani KVM jsem zatim nestudoval a neznam :( takze, prosim o radu. diky