Processzor kompatibilitás és a virtuális gépek mozgatás

Ez egy régi történet, még 2008 februárjában vetette fel Mike DiPetrillo. Az utóbbi napokban Bognár Attila megjegyzéseiben újra előbukkant a téma, és vele egyetértésben úgy gondoltam, megér egy bejegyzést.

A probléma
Az bizonyára tudjátok, hogy a modern virtualizációs megoldások nem emulálják a processzorokat, hanem csak virtualizálják. Ez azt jelenti, hogy a virtuális gépek bár virtuális CPU-t látnak, annak funkcionalitása lényegében mindenkor megegyezik a fizikai processzor funkcionalitásával. No, mármost a processzorgyártók a közöttük folyó verseny miatt újabb és újabb utasításkészlettel vértezték fel a termékeiket, amelyeket viszont nem engedtek megjelenni a konkurenciánál. Így azután egy Intel és egy AMD utasítás-készlete, regisztereinek száma és funkciója ma jelentősen eltér egymástól. Ha egy virtuális gépet átmozgatunk egyik fizikai kiszolgálóról a másikra, a mozgatásnak van egy olyan fázisa, amikor a forrás-gépen megállítjuk a virtuális processzort, az éppen futó utasításokat és regiszter-értékeket pedig a cél-gépre másoljuk, egy új virtuális processzorba. Ha azonban az új gépen nincsenek meg a forrás-gép regiszterei és utasításai, akkor a másolás nem történik meg, a gép futása pedig kárt szenvedhet. Hasonló a helyzet akkor is, azonos gyártótól származik a forrás- és a célprocesszor is, de a forrás-CPU olyan utasítás-készlettel rendelkezik, amely nem található meg a cél-CPU-n.

Megoldás a VMware-től
Hogy az esetleges virtuálisgép-összeomlásokat megakadályozza, a VMware ESX a VMotion művelet elvégzése előtt ellenőrzi a forrás- és a célprocesszort. Ha azt látja, hogy az utasítás-készletek eltérnek egymástól, akkor megakadályozza a művelet végrehajtását. Az ESX 3.5 U2 még ennél is tovább megy és bevezeti az “Enhanced VMotion Compatibility” funkciót. Ennek lényege, hogy egy fürtön belül minden processzorra maszk húzható, vagyis a virtuális gépek elől elrejthetők az új utasítás-készletek. A fürt szinten egységes utasítás-készlet lehetővé teszi, hogy a VMotion műveleteket sikeresen végre lehessen hajtani. Miután a fürt minden tagja j processzort kapott, a maszkot le lehet venni és az utasítás-készlet használatba vehető.

A Hyper-V működése
Mike DiPetrillo rosszul tudta: mind a Virtual Serverben, mind pedig a Hyper-V-ben VAN processzor kompatibilitás ellenőrzés. A mozgatás során először lementjük a virtuális gép állapotát, majd a célgépen, a mentett állapot betöltése előtt, ellenőrizzük, hogy betölthetők-e a lementett virtuális processzor utasításai. Ha nem, akkor nem történik meg az adott gépen a visszaállítás, az erőforrás csoportnak keresnie kell egy kompatibilis processzorral rendelkező node-ot. Ha nincs ilyen, akkor a mozgatás meghiúsul – de a virtuális gép stabilitása nem kerül veszélybe. Mellesleg van mód arra, hogy inkompatibilis processzorok között mozgatni lehessen gépeket. Nem kell nagy csodára gondolni: pusztán arról van szó, hogy a Quick Migration során be lehet állítani, mi legyen az erőforrás kikapcsolt állapotba tételekor a teendő a virtuális géppel (Offline action). Ha az állapotmentés (save state) helyett azt mondjuk, legyen lekapcsolás (Shut down), máris nincs állapot, amit át kellene vinni, tehát a virtuális gép átköltözhet egyik fizikai kiszolgálóról a másikra – egy újraindítással megfűszerezve.

A történet itt véget is érhetne, a a vmware-es kollégák nem nyugodtak és összehoztak egy videót arról, mennyire “nem működik” a processzor kompatibilitás ellenőrzés a Hyper-v esetén. Intel-AMD demót nem lehet bemutatni a fentiek miatt, maradt hát az azonos gyártó de eltérő utasítás-készlet szituáció. Ha valaki megnézi a videót, első az elszörnyülködés. Te jó ég! Hogy még ezt sem tudja! Hogy lehet egy ilyen termékben megbízni! Mielőtt azonban mindenki teljes letargiába esik, érdemes néhány dolgot “észrevenni”:

  1. A videón egy desktop alkalmazás az állatorvosi ló. Nem egy levelező kiszolgáló, nem egy adatbázis-kezelő, nem egy ERP rendszer, nem egy fájl- és nyomtatókiszolgáló, nem egy webszerver stb. stb. Miért? Nem lenne hatásosabb, és főleg, életszagúbb, ha ismert szerver-alkalmazást mutattak volna be? Nem lehetséges, hogy azért ezt az alkalmazást használták a videó készítői, mert nem ismernek olyan szerver szoftvert, amely a fenti utasítás-készlet különbség hatására összeomlik?
  2. OK, rendben. Lehet, hogy nincs ilyen szerver alkalmazás. Akkor miért nem olyan utasítás-készletet mutatnak, amely releváns? Nem lehet, hogy azért, mert az SSE 4.1-es utasításkészletet az egyetlen, amin be lehet mutatni ezt a hibát?
  3. Az SSE 4.1-et tipikusan multi-média alkalmazások használják. Gyakori használata ez a szerver-virtualizáció termékeknek? Aligha.

Persze adódik a kérdés: ez esetben tulajdonképpen lényegtelen az utasítás-készlet ellenőrzés? Nem, nem az. Látni kell, hogy a VMware ESX lassan nyolc éves termék. Ez idő alatt rengeteg processzor került ki a piacra és bizonyára sokkal könnyebb lenne demózni egy 2002-2003 táján kiadott proci és egy mai közötti inkompatibilitást. A VMware-nek, már csak a termék története miatt is, létre kellett hoznia ezt a funkciót.

A Hyper-V, az ESX-hez képest, az újabb processzorokon fut (megköveteli a hardveres virtualizáció támogatást). Bár a processzorok erőteljesen fejlődnek, a fejlődés jelenleg a magokra, és olyan képességekre koncentrál, amelyet a virtualizációs gazdagépek tudnak kiaknázni, az utasítás-készlet bővülés ritkább (de amint láttuk nem szűnt meg teljesen). Ahogy haladunk előre az időben, úgy válik egyre valószínűbbé, hogy újabb utasítás-készletek lesznek elérhetők. Ha ezeket a szerver alkalmazások is kihasználják, akkor majd a Hyper-V is szembesül azokkal a problémákkal, amelyekkel az ESX már korábban találkozott. Ma még ez nincs így.

Vagyis, összefoglalva: a vmware-es kollégák által készített demó egy ténylegesen meglévő, de jelenleg még marginális probléma felnagyítása. A célja pedig, hogy a bizonytalan ügyfeleket elriassza a hyper-v-től. Úgy szokás ezt nevezni, hogy FUD.

10 Responses to Processzor kompatibilitás és a virtuális gépek mozgatás

  1. Balázs says:

    Látványos prezentáció, az biztos.Lehet tudni valamit arról, hogy mikor lesz beépítve, egy komolyabb ellenőrzés? 2008 R2 végleges verziójába gondolom még nem, esetleg egy hotfix vagy SP formájában.

  2. Tamas says:

    Pár nap múlva kint lesz a 2008 R2 RC. Akkor többet fogunk tudni. Visszatérek majd a témára.

  3. Gábor says:

    Azt lehet tudni, hogy a Virtual PC mikor kap vegre 64 bites guest supportot? Mert azert nem lenne rossz a Windows 7 XP modjahoz….

  4. Gábor says:

    Annyit szeretnek a cikkhez fuzni, hogy valo igaz, hogy jelenleg a problema marginalis, viszont kozismert. Azert az eleg erdekes hozzaallas, hogy majd akkor vezetunk be tuzvedelmi berendezeseket, ha mar erezni a fustszagot. Nem hiszem, hogy olyan borzaszto nagy dolog lenne egy rendes processzorellenorzesi alrendszer alapjait leprogramozni most, amig meg nem hajt a torok, es amikor tenylegesen szukseg van ilyesmire, ket ujjmozdulat lenne ezen ugy valtoztatni, hogy eleve fel legyen keszulve a dologra. Ez jot tenne a fejlesztoknek, el lehetne adni marketingben is (mi gondolunk a jovore!), a felhasznalok szamara pedig azert lenne jo, mert nem service-packokra kellene varni, hogy legyen ilyen nagyobb mervu feature-juk, hanem egy hotfixben megkaphatnak az epp aktualis processzor-adatbazist (mint a Windows Defender eseteben mondjuk). Igazabol erre is igaz, hogy ez koncepcio kerdese is. Ha mar eleve gondolunk ilyen dolgokra is, meg mielott az elso ezer kodsor le lenne irva, akkor mar az alapok megvetesenel fel lehet keszulni ilyesmire; viszont az utolag belefejlesztes mindig, kivetel nelkul problemaforras tud lenni. A Windows fejlodese soran rengeteg helyen meg lehet figyelni ezt a tendenciat, es az eredmenyet.

  5. Tamas says:

    A Windows7 XP módja még nem kapott 64 bites támogatás, de USB eszközöket már tud.

  6. Tamas says:

    Nem tudom, hogy miért hagyták ki, vagyis inkább miért nem tették teljes-körűvé, de gondolom priorizálták a fukciókat és ez alapján hátrább sorolták.

  7. Gábor says:

    En ugy tudom, hogy a Virtual PC kompletten nem rendelkezik 64 bit supporttal.

  8. Tamas says:

    Igen, jól tudod. Nem fogtam pontosan, mit kérdeztél. Úgy tudom, hogy az XP-mode-hoz használt VPC egy többszálú (gépenként egy-egy szál) megoldás, vagyis sokkal inkább a Virtual Server utódja, mint a tényleges VPC-é. HW virtualizációs követelménye is van, hogy ne kelljen ring-compression-t használni, ami tovább gyorsítja. Viszont az eredeti connectix kódra épül, ezért nincs 64 bites vendég OS támogatás. Ha az XP-mode pozícionálását nézzük akkor ez elfogadható. Ha azt, hogy a VPC-nek – akárcsak a konkurenciának – tudnia kellene támogatni a 64-bites rendszereket is, akkor már kevésbé.

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: