Virtuális eszközök és a Hyper-V

Egy-két hete, a Hyper-V RC megjelenésekor kaptam egy elkeseredett levelet:

Hat ez az RC0 nem tul mukodokepesnek tunik. Neked van mar tapasztalatod? pl nincs halozat a belulre telepitett w2008 guest gepen. Meg nincs egerkezeles. Pedig oda is fel lett teve az rc0 patch. nem ertem.

Szombat este van. Uri Geller baráti köréhez való csatlakozás helyett inkább járjuk utána ennek a misztikus hálózati kártya és egér eltűnésnek. Szerintem ez izgalmasabb lesz🙂

A Hyper-V első felhasználói azok közül kerülnek ki, akik már a Virtual Server 2005-öt is használták. Nekik van némi gyakorlatuk a virtualizáció témakörében, tudják, hogy emulált hardver környezetben dolgoznak, tudják, hogy szükség van (Virtual Server 2005 alatt)  a VM Additions-re, és nem újdonság, hogy Hyper-V esetén egy "Integrated Services" szoftvert kell telepíteni a gyermekpartíciókba. De hogy pontosan mire való az egyik illetve a másik, no és hogy mi a különbség közöttük, az már többnyire homályba vész. Lássuk:

A Virtual Server 2005 egy olyan virtualizációs megoldás, amely a virtuális gépek virtuális hardvere szempontjából kizárólag hardver emulációval operál. Ez azt jelenti, hogy minden eszköz, amelyet a virtuális gép operációs rendszere lát, ugyan most virtuális, hiszen az adott gépben valójában nincs benne, de amúgy fizikailag is létező eszközökről "mintázták" őket, effektíve azokat valósítják meg szoftveres úton. Az Intel 440BX chipkészlet a maga fizikai valójában is létezett, mint ahogy az S3 Trio64 grafikus kártya és a DEC 21140-es hálózati csatoló is. A virtuális gép hardvere egy nagyon szűk, meghatározott és nem változó eszközlistából áll össze, a pontos listát tudásbázis cikkben el lehet olvasni. Az emulációhoz a virtuális gépben nem kell semmit külön telepíteni. Ha felrakunk egy olyan operációs rendszert, amely tartalmazza a szükséges eszközmeghajtókat, a virtuális gép máris használható. Az emulált eszközöket pedig éppen úgy válogatták össze, hogy az operációs rendszerek lehető legszélesebb köre azonnal használatban vehesse őket.

Akkor mire való a vendéggépbe külön telepíthető "Virtual Machine Additions"? Négy alapvető feladata van:

  1. Az egérműveletek javítása. Például a VMRC konzol és a gazdagép között vándorolhat ez egér, nem esik a virtuális gépe "csapdájába"
  2. Szívhang generátor. A VM Additions egy komponense rendszeresen jelzi a gazdagép felé, hogy a virtuális gép működik. Nagy terhelés esetén kevesebb szívhang érkezhet a virtual serverhez, ha pedig a vendéggép összeomlik, a szívhang megszűnik – ez ugyancsak fontos információ.
  3. Időszinkronizáció. A gazdagép és vendéggép között biztosít időszinkronizációt. Ez nagyon hasznos például akkor, ha a virtuális gépet állapotmentéssel (save state) állítottuk le, majd később újra elindítjuk.
  4. Általános teljesítmény-javítás. A homályos kifejezés mögött a "Ring Compression" nevű technológia áll. Ennek lényege, hogy a vendéggép kernele A CPU-n ring0 helyett ring1 privilégium szinten fut, azok a CPU utasítások pedig, amelyeket nem lehet ezen a szinten kiadni, a Vm Additions segítségével a Virtual Machine Managerhez kerülnek, amely aztán kezeli a helyzetet.
    Frissítés: Windows operációs rendszerek esetén a VMAdditions a memóriában megfoltozza a Windows kernelt, hogy további teljesítménynövekedést lehessen elérni. (Lásd: egy későbbi bejegyzésben részletesen.)

Amint látható, a Virtual Machine Additions a virtuális hardverek listájába, azok elérhetőségébe semmilyen szinte nem játszik szerepet. Nem így a Hyper-V-beli megfelelője az "Integrated Services". Ahhoz azonban, hogy az Integrated Services szerepét precízen leírjuk, szükség van némi Hyper-V architektúra ismeretre. Íme egy vázlatos rajz a felépítéséről. (A piros és sárga vonalról később)

Hyper-V-Architecture02

A hypervisor, tehát a processzort (és memóriát) kontroll alatt tartó kód a legalacsonyabb, Ring -1 privilégiumszinten fut. Erre mondják azt, hogy "közvetlenül a vason". Ehhez képes valamennyi virtuális gép, még a szülő partíció is kisebb privilégium-szinttel kénytelen beérni. Egészen pontosan a szokásos ring0 szinten futnak a kernelek, pont úgy, mintha azt virtualizáció nélkül tennék.

Szemben a Virtual Serverrel, a Hyper-V esetében beszélhetünk emulált és szintetikus, továbbá alap (Core) vagy beépülő (plug-in) eszközökről. Így néz ki a pontos csoportosítás

 

Emulált

Szintetikus

Alap (Core VDevs)

BIOS, DMA, APIC, ISA Bus, PCI Bus, PIC Device, PIT Device, Power Mgmt device, RTC device, Serial Controller, Speaker device, 8042 PS/2 keyboard/mouse controller, Emulated Ethernet, Floppy controller, IDE Controller, VGA/VESA video.

synthetic video controller
synthetic mouse controller

Beépülő (Plug-in Vdevs) (COM komponensek)

 

Synthetic Network Interface
Synthetic storage

Az emulált eszközök épp úgy működnek, mint a Virtual Server esetében: valóságos eszközök virtuális reprezentációi. Ha az operációs rendszer rendelkezik a szükséges eszközkezelőkkel, azonnal használatba vehetők. A szintetikus eszközök ezzel szemben valóságban sosemvolt eszközök – ahogy a szintetikus molekulák sem fordulnak elő a természetben. Néhány további különbség:

  • Bizonyos virtuális hardver elemekhez csak Core VDevs eszközök férnek hozzá. Ezek: Guest Memory, IRQ generation, Memory Mapped és Port Mapped IO.
  • A szintetikus eszközök a gyermekpartíciókban csak akkor válnak láthatóva, ha az "Integrated Services"-t (IS) először telepítjük.

Az Integrated Services másra is való, de a mi történetünk szempontjából most a fenti állítás a leglényegesebb!! Bizonyos eszközeink nem lesznek láthatók addik, amíg nem telepítjük a Hyper-V gyermekpartíciókba szánt kiegészítőjét. Ennek a kitételnek viszont kemény következményei vannak:

  1. Ha nincs IS, de csak szintetikus hálózati meghajtót konfiguráltunk a virtuális gépbe, akkor a telepítés befejezésekor még nem lesz hálózati kártyánk.
  2. A szintetikus kártya nem összegyeztethető a PXE indítási folyamattal, hiszen a PXE indításnál az operációs rendszer nem aktív, vagyis a szintetikus kártyához szükséges eszközkezelő sem az.
  3. Minden Hyper-V alatti operációs rendszernek IDE virtuális kontrollerről kell indulnia, mivel SCSI csatolóból csak szintetikus létezik.

A fenti lista nem teljes. Adódhat a kérdés: miért van szükség egyáltalán szintetikus eszközökre? A sebesség miatt. Ha csak emulációt használnák, akkor a fenti ábra piros vonalán keresztül haladnának az adafolyamok. A virtuális gép mit sem tudva arról, hol is fut valójában, megpróbálja elérni az általa valósnak gondolt hardvert. Ezeket a hívásokat a hypervisor elfogja, majd a szülő partíció munkafolyamatához (worker process) továbbítja. A worker process fordítja le az emulált eszköz kérését a valóságos eszköz eszközkezelője számára, illetve a válasz is hasonló útvonalon történik, csak visszafelé. Ezt ábrázolja a piros vonal. A legnagyobb baj az, hogy a worker processz a szülőpartíció ring3 szintén fut, az egész folyamat így a CPU tekintetében nagyon drága. A nagyon nagy adatmennyiséget mozgató eszközök esetén (hálózat, storage, video) szűk keresztmetszetet jelent. Mindemellett  hypervisort is terheli.

A szintetikus eszközök számára más út is adódik. A szintetikus eszközök három komponens együtteseként működnek. A szülőpartícióban, többnyire kernel módó komponensként definiálva futnak a Virtual Service Providerek (VSP), amelyek feladata adott eszközök megosztása a gyermekpartíciók felé a Virtual Machine Bus-on keresztül. A VMBus egy pont-pont direkt csatorna a szülőpartíció és a gyermekpartíció között. (Igen, a hypervisor sem kell hozzá.) Végül a gyermekpartíciókban a Virtual Service Comsumer, vagy client (VSC), többnyire egy miniport driver a kommunikáció kliens oldala, amely végső soron a VSP mögötti fizikai erőforrást használja. A fenti ábrán a sárga vonal jelzi a VSP-VMBus-VSC adatáramlást. Az emulációhoz képest ez nagyságrenddel gyorsabb megoldás és még a hypervisort is tehermentesíti. Hátránya, hogy csak az integrált szolgáltatás telepítése után működőképes. Ezért volt fontos a Xen-Citrix együttműködés. A XenSource vállalta, hogy megírja a Linux rendszerek alá a szükséges VSC-VMBus komponenseket, azok tehát éppolyan gyorsak lehetnek, mint a Windowsos társaik.

Dióhéjban ennyit az Hyper-V architektúrájáról, annak is inkább csak az I/O részéről. A levélre visszatérve most már látható a probléma. Az eredeti Hyper-V Béta gép VSC kompnense és a szülőpartíció Hyper-V RC0 verziójú VSP-je nem talált egymásra. És amíg a Hyper-V fejlesztése zajlik, addig bizony ez próbaváltozatról próbaváltozatra így lehet. No persze a teljes történetet ismerve volt itt más is, például a 949222 cikk is segíthet a helyzeten. Zárszóként három jótanács:

  1. A Hyper-V nem Virtual Server. Sok minden másképp történik, mégha nem is szembeötlő a változás.
  2. A Hyper-V – jelenleg – még nem végleges verzió. Próbálgatni lehet, de persze csak óvatosan.
  3. A Hyper-V-t érdemes alaposan megismerni. Jól jön majd az a tudás, gyakran lesz rá szükségünk.

3 Responses to Virtuális eszközök és a Hyper-V

  1. Tamás says:

    Szia Tamás!
    Virtualizáció? Emulált hardver környezet? Virtuális gépek virtuális hardvere? Valóságos eszközök virtuális reprezentációi?
    Azt hiszem, én inkább maradok Uri Geller baráti körében. :)))

  2. Tamas says:

    Pár nap türelmet kérek, amíg újra hozzáférek a bloghoz. Külön bejegyzésben fogok reagálni.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: