Virtualizációs technológiák összehasonlítása

A héten két különböző helyen is előkerült a téma, úgyhogy gondoltam kicsit körüljárom azt a kérdést, hogy melyik virtualizációs megoldás milyen virtualizációs technológiát használ, és ezek közül melyik a “jobb”.

Jöjjön először egy pár alap fogalom (kicsit pongyola módon megfogalmazva, részletekért lásd a virttech tárgyunk anyagait)!

Platform virtualizáció: arról az esetről beszélünk, amikor egy fizikai számítógépen több “virtuális” számítógépet szeretnénk futtatni, potenciálisan akár teljesen különböző operációs rendszerrel. Viszont virtualizációt és nem emulációt szeretnénk, azaz megelégszünk azzal, hogy ugyanolyan processzor architektúrát lát a virtuális gép, mint a fizikai (tehát nem lehet ARM-os virtuális gép egy  x86 fizikai processzoron), viszont cserébe elvárjuk, hogy gyors legyen a megoldás. Ehhez kell majd nekünk egy komponens, aki a fizikai meg a virtuális gépeket kezeli, nevezzük ezt most VMM-nek (Virtual Machine Monitor). [Itt most egy nagyon hosszú fejtegetésbe lehetne belemenni, hogy pontosan mi a VMM feladata, ki hogyan hívja – de ezt most szántszándékkal kihagyom, ez szerencsére itt most nem tananyag, hanem csak egy blog bejegyzés:]

Egy ilyen virtualizációs környezet megvalósítása során egy csomó probléma fakad majd abból, hogy egy fizikai erőforrást szeretnénk majd több virtuális erőforrásként látni, és erre a fizikai erőforrásunk nem igen van felkészítve. Tipikusan három féle módon állhatunk neki megoldani az ilyen problémát:

  • Szoftveres: tisztán szoftveres úton próbálunk valamit varázsolni a VMM-ben.
  • Paravirtualizáció: a virtuális számítógépben futó operációs rendszer megfelelő részeit készítjük fel arra, hogy működjön együtt a VMM-mel.
  • Hardveres: a hardvert készítjük fel arra, hogy megosztható legyen, és több virtuális példány állapotát tudja tárolni.

[Megjegyzés: szokott olyan felosztás lenni, hogy full virtualization meg paravirtualization, én azt nem szeretem, mert szerintem félreértésre ad okot.]

Három féle alapvető erőforrást kell majd kezelni: CPU, memória, I/O eszközök. Ezek mindegyikéhez lehet használni bármelyik fenti három technológiát. Mindhárom technológia segítségével írtak már VMM-et, nézzük meg ki mit támogat.

1. Ki milyen virtualizációs technológiát használ?

[Itt most csak a VMware ESXi, Microsoft Hyper-V és a Xen kerül sorra. Kimaradnak a hosted architektúrájú megoldások (VirtualBox, KVM…), bár azokra is hasonlóan végig lehet játszani ezt. Meg nem kerülnek szóba a nem x86-os megoldások, pl. különböző mainframe-ek képességei. Azokat hajlamosak vagyunk elfelejteni mikor a virtualizáció szóba kerül, pedig már évtizedekkel korábban kitaláltak bennük sok mindent.]

1.1 CPU kezelése

Itt a feladat az, hogy a vendég virtuális gép szeretne mindenféle privilegizált utasítást végrehajtani, amit nem engedünk direktben neki (pl. HALT esetén leállna a teljes fizikai gép). Ezt lehet kezelni szoftveres úton bináris átírással (a vendég által kiadott bináris utasításokat vizsgáljuk, és cseréljük le benne menet közben a problémásakat), lehet paravirtualizációval (módosítjuk a vendég OS kódját, hogy ha problémás utasítás lenne, akkor a végrehajtása helyett hívja inkább a VMM megfelelő függvényét), és végül lehet hardveresen (a CPU adjon módot arra, hogy elkülönítsük a VMM-et és a virtuális gépekben futó OS-t, és tudjuk valahol tárolni a virtuális gépek állapotait).

VMware ESX/ESXi Microsoft Hyper-V Xen
Szoftveres (BT) +
Paravirtualizáció (+/-)* -** +
Hardveres (Intel VT-x, AMD-V) + + +

* Volt paravirtualizációs támogatás az ESXi-ben (VMI – Virtual Machine Interface néven futott), de megszüntették a vSphere 5-ben. Lásd itt: “Update: Support for guest OS paravirtualization using VMware VMI to be retired from new products in 2010-2011

** Itt utána olvasva kicsit elbizonytalanodtam:) A Hyper-V használatának előfeltétele a hardveres virtualizációs támogatás, azt mindig használja. Azonban van egy kellemesen homályos fogalom Hyper-V esetén, ez pedig az enlightenment (=felvilágosodás). Ez paravirtualizációs technológiákat takar, a Windows kernelt módosították, hogyha virtuális gépként fut, akkor máshogy viselkedjen. Az eszközöket biztos paravirtualizáltan kezeli, de itt van olyan utalás is, hogy más funkciónál is használ ilyesmit (lásd: Hyper-V: Integration Components and Enlightenments, alul az Operating System Enlightenments rész). Hogy ezek mik pontosan, arról nem találtam utalást. [A Hyper-V alacsony szintű működésének dokumentáltságát némiképp nehéz megtalálni a Techneten, elég csak annyit megjegyezni, hogy a legpöpecebb Hyper-V ábra és fogalommagyarázat a BizTalk 2009 függelékében van:)]

Összefoglalva akkor:

ESXi:

  • Megvan még a tisztán szoftveres megoldás, a bináris átírás (binary translation – BT) benne. Ehhez nem kell se hardveres támogatás, se a vendég kerneljének módosítása.
  • Klasszikus értelemben vett paravirtualizáció már az 5-ös verziótól kezdve nincs.
  • Hardveres virtualizációt tud használni, ha a hardver képes erre.

Hyper-V:

  • Kell neki a hardveres virtualizáció, különben nem lehet használni.
  • Azonban ha a vendég “felvilágosult”, akkor szerintem hypercall-okon keresztül biztos hívja néha a hypervisort, hogy jobb teljesítménye legyen.
  • Az újabb Windows kernelekben már benne van az enlightenment, de Linuxhoz is van valamennyi támogatás. Linux esetén Integration Componentsnek (IC) hívják azt a csomagot, ami paravirtualizált eszközkezelőket ad, ez most a 3.1-es verziónál jár. Ez Red Hat és CentOS 6.0-hoz támogatott, de az aktuális Linux kernel (3.0.8) forrásában a drivers/staging/hv alatt megtalálható a kód egy része. Volt az IC-nek egy érdekes része, a “hypercall adapter”, de a 3.1 readme-je szerint ez már nincs benne az új verzióban. Egyébként ez volt (forrás: RTM of Linux Integration Components for Hyper-V Now Available):

The hypercall adapter is basically a layer that translates between the Xen hypercall API and the Hyper-V hypercall API.  This allows you to install a Xen paravirtualized Linux kernel inside the virtual machine in order to get the best performance possible.

Xen:

  • Kezdetben paravirtualizációt használt, ezért csak módosított kernellel rendelkező virtuális OS-t tudott futtatni. Ezt a módszert továbbra is használják, manapság annyi könnyebbség van, hogy az ehhez szükséges OS módosításokat Linux esetén már nem kell külön patch-ként hozzáfordítani minden egyes új verzióhoz, hanem már része a kernelnek. Lásd: Linux mainline contains all the Xen code bits for Dom0 and DomU support.
  •  Ahol nem lehet kernelt módosítani, pl. virtuális Windows, ott hardveres virtualizációt használ a Xen (HVM a Xen szójárásában).

1.2 Memória kezelése

Itt a feladat az, hogy a szokásos 2 szintű fizikai – virtuális címtereket és címleképzést kiterjesszük 3 szintre: gazda fizikai – vendég “fizikai” – vendég virtuális. Szoftveres esetben árnyék laptáblákat (shadow page table) tartunk fent, és megpróbáljuk elkapni a vendég OS laptábla módosító utasításait mindenféle trükkel. Paravirtualizált esetben módosítjuk a vendég kernelt, hogy a VMM-et hívja, ha módosítani akar valamit a laptábláin. Hardveres esetben pedig a hardver biztosít még egy plusz szintet (nested page table, second level adrres translation bűvszavak).

VMware ESX/ESXi Microsoft Hyper-V Xen
Szoftveres + + +
Paravirtualizáció (+) +? +
Hardveres (Intel EPT, AMD RVI) + + (R2-től) +

Itt a melyiket használjam kérdés egyszerűbb. Alapból mindenki szoftveres technikákat használ. Ha tudják módosítani a vendég kernelt (Hyper-V esetén újabb Windowsok, Xen esetén Linux, ESXi esetén VMI-t használó Linux), akkor gondolom, hogy használnak valamiféle paravirtualizációs rásegítést.

De itt igazából a hardveres megoldások dobnak nagyon sokat a teljesítményen, úgyhogy kevés vita van, hogy mi a jó opció, lásd: (MMU) Paravirtualization is dead, VMware mérések (AMD RVI és Intel EPT hatása), vagy a “Virtualization performance: perspectives and challenges ahead” cikkből származó ábra.

Memória: szoftveres és hardveres megoldás összehasonlítása

Memória: szoftveres és hardveres megoldás összehasonlítása (forrás: VMware)

Ha van hardveres támogatás, akkor a legtöbbször azt használják.

1.3 I/O eszközök

Itt azt kell megoldani, hogy a virtuális gép tudja kezelni az I/O eszközöket, de mégis védjük azt tőle. Szoftveres esetben valami létező hardvert emulálunk. Paravirtualizált esetben egy speciális, direkt a virtualizált megoldáshoz létrehozott eszközt lát a virtuális gép (amit egyszerűbb megvalósítani, jobb a teljesítménye). Hardveres megoldások esetén vagy arra van támogatás, hogy közvetlenül odaadjunk egy eszközt egy virtuális gépnek (AMD-Vi vagy a régi nevén IOMMU, Intel VT-d), vagy a hardver képes több “virtuális példányt” kezelni magából (mindenféle PCI-SIG IOV szabványok) .

VMware ESX/ESXi Microsoft Hyper-V Xen
Szoftveres (emulált) + + +
Paravirtualizáció + + +
Hardveres (AMD-Vi, Intel VT-d, IOV stb. ) + – (v3-ban lesz) +

Itt is egyszerű a helyzet: amíg nincs jobb (pl. virtuális OS telepítése közben), addig emulált eszközöket kell használni. Utána érdemes felrakni a megfelelő csomagot (VMware Tools, Integration Components…), hogy paravirtualizált eszközeink legyenek. Hardveres támogatás meg bizonyos esetekben jó (videokártyát dedikáltan használjon a gép, sok hálókártyával rendelkező gép, 10 GB-es hálózati kártya), ez például egy érdekes kapcsolódó cikk: To VT-d or Not to VT-d?.

VMware esetén van VT-d/AMD-Vi támogatás (VMware VMDirectPath Tech Note), és az ESXi 5.0-ba bekerült valamiféle SR-IOV támogatás (vSphere 5.0 Features), de több részletet nem találtam erről.

Hyper-V esetén nem találtam hivatalos infot arról, hogy jelenleg nem támogatja, csak ennyit: Does 2008 R2 Hyper-V support PCI-SIG SR-IOV (2010-es, MSFT alkalmazott válaszolt, hogy nem); Does Windows Server 2008 R2 Hyper-V use Intel VT-d hardware features? (2011-es, a válasz, hogy nem). Viszont a következő verzióban (v3, Windows 8 Server-ben) lesz SR-IOV támogatás a BUILD fóliák szerint.

Xen esetén van VT-d támogatás (Xen Wiki VTdHowTo), és valamiféle SR-IOV támogatás is: SR – IOV and repeated enhancement for pass through device support és Xen 4.0 Relase Notes.

2. Melyik virtualizációs technológia a “jobb”?

(A memória és I/O eset szerintem viszonylag egyértelmű, marad a CPU).

A válasz könnyű, természetesen attól függ:-). Mitől is?

  • Milyen terhelést futtatunk a virtuális gépekben? Sok lesz-e a kontextusváltás, sok lesz-e a rendszerhívás? Mennyire kell majd beleavatkoznia a VMM-nek?
  • Milyen hardverünk van? Ha nincs benne hardveres virtualizációs támogatás, akkor az eléggé behatárolja a lehetőségeket:)
  • Milyen OS-t akarunk futtatni a virtuális gépen?

Arra vállalkozni, hogy általános esetben a különböző megoldások különböző módjait hasonlítjuk össze (gyorsabb-e a bináris átírás az ESXi-ben mint a paravirtualizált Xen), szerintem felesleges. Egy-egy konkrét alkalmazás esetén mindenki saját magának mérhet ilyet. Olyan mérések vannak, ahol Xen meg ESX vagy ESX meg Hyper-V kerül összehasonlításra mindenféle mikrobenchmarkkal vagy valósnak vélt terheléssel, de ennek az eredményét is sokkal inkább meghatározza az, hogy ki volt az, aki a mérést végezte, mint az, hogy mit tudnak a platformok:) (nem feltétlen rosszindulatból, csak nyilván a VMware Performance csapat az ESX-et ismeri jobban).

Azt érdekes inkább megnézni, hogy egy-egy megoldás mikor mit és miért használ.

ESXi: Igazából itt érdekes a kérdés, hisz a VMware tudja/tudta mindhárom módszert.

  • 2006: Amikor az első generációs hardveres megoldások megjelentek, csináltak jó pár mérést, és az eredmény az lett, hogy a bináris átírás – hardveres megoldás még akkor nem volt eldöntött. Lásd: “A Comparison of Software and Hardware Techniques for x86 Virtualization“. A fő ok, hogy a szoftveres megoldást már régóta tunningolták (fordítás gyorsítótárazása, több hívás összevonása stb.), míg a hardveres még csak az első verzió volt. Azóta azonban minden újabb processzorgenerációval javul a hardveres megoldás gyorsasága.
Bináris átírás és hardveres virtualizáció összehasonlítása

Bináris átírás és hardveres virtualizáció összehasonlítása (forrás: VMware)

  • 2007: Understanding Full Virtualization, Paravirtualization, and Hardware Assist. Itt már az szerepel, hogy bár még mindig a BT a legjobb, de már “Hardware Assist is the Future of Virtualization”. Itt még van paravirtualizáció.
  • 2009: Van egy ilyen leírás: Software and Hardware Techniques for x86 Virtualization. Ez egy nagyon jó technikai leírás azokról a fogalmakról, amik eddig szerepeltek, és utána egy lista, hogy milyen szempontok szerint dönt az ESX, hogy milyen módszert használ. [Ebben már nincs paravirtualizációról szó.]
  • 2009: Itt pedig a pontos lista, hogy mikor melyiket választja: Virtual Machine Monitor Execution Modes in VMware vSphere 4.0 Az itt lévő táblázatból az látszik, hogy próbálja használni a hardveres támogatást, ha van, kivéve, ha régi a vendég OS vagy egyéb körülmény miatt nem lehet (pl. a VMware Fault Tolerance nem támogatja az EPT/RVI-t).
  • De mit történt a paravirtualizációval?
    • 2008: Performance of VMware VMI. Itt még ez van: “concluding that VMI-style paravirtualization offers performance improvements for a wide variety of workloads, but that the actual performance gains depend on the nature of those workloads.
    • 2009: “Update: Support for guest OS paravirtualization using VMware VMI to be retired from new products in 2010-2011” Itt pedig már ez: “decided to retire support for VMI in 2010-2011 as a result of innovations in CPU hardware acceleration technologies from Intel and AMD which have surpassed the performance improvements provided by VMI
    • Gondolom már nem érte el az esetleges teljesítménynövekedés azt a szintet, amiért megérte volna vele nekik foglalkozni. Mivel a VMware nem OS gyártó, ezért neki különösen macerás ilyesmit karbantartani.
  • Összességében szerintem szépen lassan a hardveres megoldások felé terelődik az irány, a szoftveresek addig maradnak, amíg nem lesznek teljesen elterjedtek a hardveres támogatások minden gépben.

Hyper-V: itt igazából nincs választás, hardveres támogatást használ. A Windows kernelbe viszont gondolom, hogy mindig kerülnek majd olyan funkciók, amik segítenek a virtualizáció gyorsításán. A Linux támogatás azonban kérdéses, valamit gondolom adnak, de sosem fogja a linuxos IC kihasználni az összes lehetőséget.

Xen: Itt maradt meg ténylegesen a választási lehetőség, hogyan futassunk egy linuxos vendéget? Lehetőségek:

Xen futtatási módok

Xen futtatási módok (forrás: Stefano Stabellini)

A fő távlati kérdés, hogy gyorsabb tud-e lenni a paravirtualizáció, mint a második generációs hardveres támogatás? Egy kapcsolódó prezentációt találtam: Linux PV on HVM. Az itt lévő mérésekben sok helyen megelőzi a hardveres megoldás a paravirtualizáltat (már persze csak akkor, ha paravirtualizált eszközmeghajtókat használunk). Kíváncsi leszek, hogy hosszú távon mi lesz a Xen stratégiája.

Összességében akkor hova jutottunk?

1. Elment vele vagy két estém, de egy csomó érdekes dolgot összegyűjtöttem és olvastam, szóval nekem hasznos volt idáig eljutni;)

2. Előbb-utóbb már csak olyan processzorok lesznek, amikben van hardveres támogatás, az el fogja dönteni a kérdést. 64 bites vendégek futtatásához is szükséges a hardveres támogatás (Intel esetén). Hyper-V és KVM esetén pedig alapkövetelmény.

3. Addig is az átmeneti időszakban, aki Windowst akar futtatni és nincs hardveres támogatása, annak marad az ESXi. Ha Linuxot akarunk és nincs hardveres támogatás, akkor lehet ESXi vagy Xen. Ha AMD-V/Intel VT-x van a CPU-ban, de EPT/RVI nincs, akkor lehet érdekes kérdés, hogy VMware esetén BT vagy hardveres, Xen esetén PV vagy HVM, de ez meg nagyon alkalmazásfüggő.

Zárszó: remélem hasznos lesz másnak is:) Próbáltam mindennek utánajárni, de biztos van benne hiba, mert eléggé összetett (azt is mondhatnám, hogy néha zavaros) a téma. Ha valaki hibát talál, kérem jelezze megjegyzésben. Kösz:)

Advertisements
Kategória: Tech
Címke: , , ,
Közvetlen link a könyvjelzőhöz.

2 hozzászólás a(z) Virtualizációs technológiák összehasonlítása bejegyzéshez

  1. micskeiz szerint:

    Pont miután befejeztem a bejegyzést, találtam egy prezentációban egy kicsivel több részletet, hogy mit is csinál pontosan az enlightenment a Windowsokban.

    Hyper-V R2 mélylélektan (http://www.microsoft.com/hun/technet/article/?id=533272ce-82a8-48fe-acdc-ec40b8ebe96a), 35. dia jegyzet része:

    “The inclusion of virtual environment optimizations into an operating system is referred to as enlightenment. Enlightenments are implemented by modifying the operating system code so that it is aware of the hypervisor and can change its operation to be more efficient in the presence of a hypervisor. An operating system instance may be unenlightened, partially enlightened, or fully enlightened. Fully enlightened operating systems do not need hardware emulation for virtual devices. Windows Vista SP1 and Windows Server 2008 include enlightenments and are able to detect the presence of a hypervisor at run time. These changes are built into the Kernel and the HAL components for both performance optimization and functional enhancements. XEN is also including these enlightenments into the Linux Kernel for Microsoft.

    Performance Optimization Enhancements
    – Address space switching through hypercalls. The guest operating system can call the hypervisor to switch between virtual address spaces without performing a costly flush of the transaction lookaside buffer (TLB).
    – TLB flushing. The Windows kernel uses hypercalls to flush groups of TLB entries from both local and remote tagged TLBs.
    – CPUID removal in certain paths. In certain critical paths, the use of the CPUID processor instruction is eliminated and replaced with an execution-serializing MOV instruction, to avoid the mandatory intercept associated with execution of CPUID.
    – APIC register accesses. A number of frequently-accessed memory-mapped APIC registers are accessible by using lower-overhead synthetic memory service routines (MSRs).

    Functional Enhancements 
    – Processor utilization and idle determination. When a hypervisor is present, the operating system calls the hypervisor to determine the actual utilization of the logical processors. This information is used by the power manager to determine the idle state of individual processors or processor groups.
    – Event Tracing for Windows (ETW). Windows Virtualization uses ETW to record diagnostic information in order to allow customers to correlate kernel events with hypervisor events. ETW has added infrastructure support for high-performance recording and event correlation.
    – Machine-check handling. The hypervisor relies on the operating system in the root partition to process hardware machine checks and take the appropriate action. The kernel’s machine check processing recognizes when a machine check has occurred when another guest or the hypervisor is running, and records the appropriate information.
    – Interrupt usage agreements. Interrupt vector 0xFF is available solely for the hypervisor, and vectors 0xF0 – 0xFF are always edge-triggered”

  2. micskeiz szerint:

    Most került ki egy nagyon jó összefoglaló a Xen által jelenleg és a jövőben tervezett módokról:

    The Paravirtualization Spectrum, Part 2: From poles to a spectrum (http://blog.xen.org/index.php/2012/10/31/the-paravirtualization-spectrum-part-2-from-poles-to-a-spectrum/)

    A végén van egy jó táblázat, ami segít megérteni, hogy miket lehet paravirtualizációval támogatni, és hogyan fonódnak össze az egyes technikák.

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s