VMware ESXi kontra Microsoft Hyper-V Server

Lehet, hogy még egy hónap múlva sem írtam volna meg ezt a cikket, ha nincs az ESXi-ről egy hosszú-hosszú fórumszál a hup.hu-n, és nem látok benne annyi félreértést és félremagyarázást. Itt az ideje, hogy a régi ígéretemet beváltsam és összehasonlítsam ezt a két “ingyenes” hypervisort.

VMware ESXi
A VMware ESXi 2007. decemberében jelent meg és kezdetben nem volt ingyenes, 459$ volt a listaára. 2008. júliusában azonban a gyártó úgy döntött, nem kér már pénzt a termékért. Ezt megelőzően megjelent egy spekuláció a virtualization.info-n arról, hogy az ESXi ingyenessége a VMware belépését jelenti a kis- és középvállalati piacra. Ezt nagyjából az egész iparág így könyvelte el, és lényegében ezt ismételtem én is az egyik összehasonlító cikkben, amire persze többen is felkapták a fejüket és javítottak. Ma már világosabb, hogy bár lehet szerepe az ESXi-nek az SMB szegmensben, sokkal inkább az ESX, egy architektúrális változásról beszélhetünk. Nézzük meg, miben különbözik a két szoftver.

VMware-ESX architecture VMware-ESXi architecture
           A VMware ESX kiszolgáló architektúrája                                         A VMware ESXi architektúrája

A bal oldali ábrán egy hagyományos ESX-et láthatunk, míg jobb oldalon egy ESXi mutatkozik be. Első ránézésre nem sok különbség látszik, “csupán” annyi, hogy a Service Console eltűnt, és helyett egy “User World” nevű komponens jelent meg. Ebből a szemszögből a változás minimális, mi itt a nagy felhajtás? Nos, a fenti ábrák csalnak, ugyanis nem jelezik, hogy mekkora szoftver-kód van egy-egy kocka mögött. Ezért aztán egy internetről beszerzett, eredeti VMware-es ábrát is mutatok a változás érzékeltetéséhez.

ESXvsESXi

Hoppá! Az Service Console valójában a szállított kód 92%-a! Ráadásul egy Red Hat Enterprise Linux alapú rendszer. Tudjuk, hogy az ESX egy monolitikus hypervisor – vagyis szinte egy teljes operációs rendszer fut hypervisorként – ezért már korábban is megvolt az elvi lehetőség, hogy Console operációs rendszer nélküli változat készüljön(*). Persze az “elvi” lehetőség azért erőd fejlesztést igényelt, ami végül is sikerült – sok, sok előnyt hordozva mind a VMware, mind pedig a felhasználók számára. Ezek többek között:

  • A kevesebb kód kevesebb hibát feltételez – ahogy az ábrán is láthatjuk a javítások számának drasztikus csökkenésére lehet számítani.
  • A 32 MB-os kód terjesztése/indítása SD kártyáról, USB kulcsról és egyéb, nem merevlemez médiáról is megoldható. A hypervisor “firmware” jelleget ölt.
  • Ha nincs harmadik gyártótól származó Service Console, akkor esetleg fizetni sem kell annak a gyártónak.  – Itt a egyik titka, miért lehet ingyenes az ESXi?

Fontos tudni, hogy funkcionális értelemben az ESXi és az ESX lényegében azonos: azonos teljesítmény, skálázhatóság, menedzselhetőség. Az olyan funkciók, képességek, mint a VMware Virtual Machine File System, Virtual SMP, VirtualCenter, VMotion, VMware Distributed Resource Scheduler, VMware High Availability, VMware Update Manager és VMware Consolidated Backup – mind-mind előcsalogathatók az ESxi-ből.

Eddig minden szép és jó. Csakhogy nem véletlen használtam az “előcsalogatható” kifejezést az előbb. Nézzük meg még egyszer, hogyan lehet a VI Enterprise különböző verzióihoz hozzájutni.

Látható, hogy minden változat alapja lehet ESXi, még a teljes értékű csomagnak is. Ingyenesen azonban csak a bal szélső csomag érhető el. A probléma az, hogy a különböző VMware-es ismertetőkben a VMotion, a VMware Distributed Resource Scheduler, a VMware High Availability, a VMware Update Manager és VMware Consolidated Backup mind-mind ESXi képességként van feltüntetve, de az már csak “kisbetűs” rész, hogy a menedzsment funkciókért továbbra is fizetni kell.

Sőt! Sokaknak furcsa lehet, de az ESXi-nek továbbra is van fizetős változata. Ami még ennél is furcsább, a fizetős és ingyenes ESXi között van némi technológiai különbség is – a fizetős javára.

  • Az ingyenes ESXi Remote Command Line Interface (RCLI) –e csak olvasható, míg a fizetősé írható/olvasható
  • Az ingyenes ESXi SNMP támogatása letiltott, a fizetősé nem.
  • Az ingyenes verzió nem AD integrált, mivel az integráció a Virtual Center (vCenter Server)-en keresztül történik, azért pedig már fizetni kell.

Mindezt azért jó látni, mert egy összehasonlítás előtt  mindig tisztázni kell, hogy most a valóban ingyenes ESXi-ről beszélünk, vagy a VI infrastruktúráról – amelynek alapja lehet az ESXi is.

A Microsoft Hyper-V Server
2007. novemberében a barcelonai TechEd konferencián jelentette be a Microsoft a Hyper-V nevet, a termék különböző verzióit, illetve azt, hogy megjelenik egy önálló “Microsoft Hyper-V Server” nevű termék is. Az eredeti tervek szerint – ne feledjük, ekkor még nincs a piacon az ESXi sem – a termék 28$ lett volna. 11 hónappal később, a tényleges megjelenéskor viszont már egészen más volt a piaci helyzet, az ingyenes ESXi után kijöhetett pereskedés nélkül egy ingyenes Hyper-V szerver is. Akárcsak az ESXi-nél, itt is akadt némi félreértés a termék körül. Mivel a Microsoft folyamatosan egy “vékony” hypervisorról beszélt, mindenki egy olyan terméket várt, amelynek mérete az ESXi-vel összemérhető. Ez azonban – a mikrokernel architektúra miatt és a tudomány jelen állása szerint – nem megvalósítható, ezért a piaci csalódás általános volt. Növelték mindezt a Hyper-V – sokak számára érthetetlen – hardver-korlátai, mint például a 32 GB maximális memóra, vagy a fürtbe köthetőség hiánya. No, járjunk utána, mi is valójában a “Microsoft Hyper-V Server”!

Archittektúrális értelemben a Hyper-V Server nem más, mint egy “Windows Server 2008 Standard Edition with Hyper-V” derivátum. A derivátum itt egyszerre jelent öröklést és származást. A Hyper-V server nagyjából az alábbi “műveletekkel” jött létre:

  • Végy egy Windows Server 2008 Standard with Hyper-V (x64) szerver kiadást
  • Vedd ennek a Server Core telepítését
  • Vedd el ebből az összes szerepkört a Hyper-V-t leszámítva
  • A telepítéskor tedd fel a Hyper-V-t automatikusan
  • Tégy hozzá egy karakteres konfiguráló programot
  • Vedd el az összes licence jogot virtuális Windows példány futtatására
  • Add ingyen, tedd letölthetővé.

A fenti “műveletek” minden lépése fontos, innen származnak ugyanis a képességek, a korlátok, az ár, sőt még a név is. Lássuk sorban:

image image

Név: A Microsoft Hyper-V Server nem tartalmazza “Windows” nevet, amivel a gyártó azt jelzi, ezzel a termékkel nem jár teljes értékű Windows operációs rendszer futtatási joga. Technológiai értelemben persze a Hyper-V – ahogy azt pár sorral feljebb írtam – egy Windows-származék, de licencelési értelemben nem. (Sokan úgy humorizáltak, hogy nem Windowsless, hanem Windows liceceless)

Ár: Mivel jogi értelemben nem Windows-ról van szó, ezért az árat is másképp határozza meg a gyártó. Ez konkrétan azt jelenti, hogy a termék ingyenes.

Képességek és korlátok: A Microsoft Hyper-V Server – jelen kiadásában – technológiai értelemben mindazt tudja, amit egy Windows Server 2008 Standard with Hyper-V rendszer tud, és éppen ugyanazokkal a korlátokkal rendelkezik. Konkrétan: éppúgy lehet tartománytag, ugyanazok a integrált komponensek használhatók, ugyanúgy működik a Windows Update, telepíthetők rá management agent-et, felügyelhető SCVMM-mel stb. stb. Ugyanakkor nem lehet fürttag – hiszen ahhoz Enterprise Edition-ből kellene származnia, nem kezel 32 GB RAM-nál többet, nem kezel négy processzornál többet stb. stb.

Szemben az ESXi-vel, a Microsoft nem feltétlenül “első lépésnek” tekinti a Hyper-V szervert, hanem meghatározott célterületeken látja hasznosnak. Ezek:

  • Teszt és fejlesztés – Világos, nem kerül pénzbe, nem kritikus, hadd menjen!
  • Alapszintű szerver konszolidáció – két-három régi gépet, különösebb magas rendelkezésre állási követelmény nélkül is rátehetünk egyetlen hypervisorra.
  • Távoli telephelyek (branch office) – ott, ahol soha nem is lesz két szervernél több, milyen jó, ha van egy hypervisor, amellyel pl. a beszerzett vasak számát le lehet felezni.
  • Alapszintű VDI – Ez is lehetséges. Képzeljünk el egy hat-nyolcfős irodát, amely a második munkaállomást VM formájában biztosítja a munkatársainak. Jó erre egy Hyper-V Server? Miért ne lenne?

A “továbblépés” nem teljesen triviális, de szintén megoldható. A Hyper-V szerver nem változtatható át Windows szerverré, de a System Center Virtual Machine Manager-nek lehet ügyfele, így aztán a gépeket, igény esetén, át lehet migrálni a nagyobb testvérekre.

Hasonlítgassunk
Az Interneten található összehasonlítások legnagyobb problémája, hogy nem definiálja pontosan, mit mivel hasonlít össze, illetve össze nem hasonlítható dolgok kerülnek egymás mellé. Véleményem szerint kétféle korrekt összevetés tehető: egy, amelyben kizárólag a két ingyenes megoldást tesszük egymás mellé, illetve egy másik, amikor teljes díszbe öltöztetjük őket és a menedzsment környezetet is számításba vesszük. Az első esetben azt nézzük, mit kapunk tényleg ingyen, a másik esetben pedig azt, hogy mit hozhatunk ki – akár pénzt sem sajnálva – a termékekből.

Szemtől szemben, pucéran
Az Interneten kering néhány összehasonlítás, amitől a hajam égnek áll, ezért egy-két megjegyzést fűzök ezekhez is. Az első  méretbeli különbségek emlegetése: 32 MB vs 2,2 GB, következtetés: az ESXi kisebb támadási felülettel rendelkezik és kevesebbet kell patchelni. Nos, először is fenti két szám csak a igényelt lemezterületet fedi, a szükséges memória tekintetében már más a helyzet:, az ESXi 700 MB-ot is elvisz alapjáraton, a Hyper-V üresen kb. 400 MB-nál áll meg. Ha a támadási felületet a memóriában is számításba vesszük, akkor a kép egy kicsit másképp fest(ene).  Másrészt szeretném felhívni a figyelmet egy érdekes adatra az egyik ábrán, néhány bekezdéssel feljebb. Láthattuk, hogy a az ESXi az ESX-hez képest 92%-kal kevesebb kódot tartalmaz. Szép. Az ábrán az is látszik, hogy ez a 92% kód a hibák és sérülékenységek valamivel több, mint 50%-áért felel. Vagyis fordítva: az ESXi-ben maradó kódkészletben – statisztikailag – a hibák és sérülékenyégek valamivel kevesebb, mint 50% ott maradt. Micsoda?? A kód 8%-a felelős a patchek majdnem 50%-áért? Ennyivel rosszabb kódot írna a VMware, mint tette azt a RedHat?

imageEgyáltalán nem erről van szó, de ahhoz, hogy korrekt válaszokat adjunk, el kell szakadnunk a FUD-ok világától. Az igényelt lemezméret csupán egy a sok paraméter közül, amely meghatározza, hogy egy szoftver biztonságos-e vagy sem. Számít például az architektúra, a kódolás folyamata, és az abba épített biztonsági ellenőrzési ciklusok (a Microsoftnál ez az SDL, a VMware-nél nincs ilyen, vagy nem publikálják), de nem mellékes például egy támadási felület dokumentáció, vagy éppenséggel egy Security Guide. És még egy fontos, dologról megfeledkezik mindenki: bármelyik terméknél, ha betartják azt a szabályt, hogy a management hálózatot (Hyper-V esetén a szülő partíció dedikált hálózati kártyáját) elválasztják a többi hálózattól, akkor kizárólag a vendég gépeken keresztül lehet végrehajtani támadásokat – ezt az utat pedig mindkét szoftver nagyon védi. (Az ábrán egy kompromittált virtuális gépből indítható támadási útvonalak láthatók.)

Summa summarum, a hypervisor méretét, OS függőséget emlegetni  a fenti tényezők elhagyása mellett – meglátásom szerint – puszta félelemkeltés, vagyis FUD. A témába vágóan egyetlen fontos kritikát viszont meg kell fogalmazni a Hyper-V-vel szemben, ez pedig a rendszerindítás helye. Az ESXi-vel ellentétben ugyanis a Hyper-V nem kapható SD kártyán vagy hasonló gyors és kényelmes médián. Úgy gondolom, hogy a firmware jelleg, legalábbis a merevlemeztől való elszakadás, elvárható lenne.

Sokszor írtam már a VMware azon állításáról is, miszerint – szemben a Hyper-V-vel – “megerősített” eszközkezelők dolgoznak az ESXi-ben. Hát nem! Az igazság az, hogy “hypervisorba fordított” eszközkezelők futnak az ESXi-ben. Ez azonban nem jelent nagyobb biztonságot, sőt, összetettebb és heterogén forrású hypervisort jelent (lásd a fenti gondolatmenetet a patchek számáról) – ez a szememben inkább probléma. Ami a Hyper-V-t illet, a Windows Server katalógusban megtalálható eszközökkel kompatibilis, a felhasználható eszközkezelők pedig azonosak a Windows szervereknél megszokottakkal.

Izgalmas dolog a VMFS kérdése. Az ingyenes ESXi nem képes semmiféle fürtben részt venni, így aztán a fürtözött fájlrendszernek sem tudja hasznát venni. A szokásos összehasonlításoknál persze a VMFS-t előnyként említik, pedig inkább hátrány: az NTFS sokkal több operációs rendszerből olvasható és önmagában jobban kezelhető, mint a VMFS.

Általában kihagyják az értékelésből a távoli menedzsment kérdéskörét. És nem csoda: az ESXi ingyenes változatánál ez nem fényes történet. Adott ugye a konzol az alapadatok beállításához, ez rendben is van. Távolról GUI felület az ESXi számára a Virtual Infrastructure Client, rövidítve a VI client. Ez is rendben. De az már nincs rendjén, hogy a VI Client nem képes több ESXi menedzselésére – csak akkor ha veszünk egy Virtual Centert. Upsz! Vagyis ha van 4 telephelyünk, és mindegyiken 1-1 ESXi hypervisor, akkor azt ingyenesen csak 4 VI kliens lesz képes távolról birizgálni, nem pedig egy közös, nyoma sincs az MMC egyszerűségének. (Egy többtucat helyszínből álló branch office virtualizációba már bele sem gondolok.) Hasonlóan hiányozhat a többszörös konfiguráció elkerülése – a Hyper-V viszont lazán magára veszi a csoportházirendeket. És a Hyper-V servernél megoldott az automatikus, sőt a központilag vezérelt hotfix frissítés is, az ESXi a témában megint csak sántikál. (Jegyezzük meg, hogy a frissítések telepítése után az ESXi MINDEN ESETBEN újraindítást igényel, a Hyper-V-nél ez nem így van.) A menedzsment körben a végső döfés az Active Directory integráció: az ESXi-nél ez sem megy, míg a Hyper-V server természetesen aktív tagja lehet egy tartománynak – élvezve annak minden előnyét.

És akkor a táblázat. Elvileg a korábban összegyűjtött mind a 160 paramétert ide lehetne citálni, de ezt nem teszem, viszont felhívom a figyelmet, hogy a teljes összehasonlítás esetén az alábbi táblázat csak kiegészítője és pontosítója az eredeti nagynak. Kiemelem azt, ahol a Hyper-V Server kevesebbet tud, mint a nagyobb testvérei, illetve, ahol az ESXi korlátokba ütközik a menedzsment hiánya miatt. nagyjából láthatóak lesznek a különbségek. Ahol külön nem jelzem, ott a funkcionalitás (pl. SMP támogatás, Guest OS támogatás, belső architektúra, hardware támogatás stb.) megegyezik a teljes képességű verzióval. Még egyszer: most a pucér szoftvereket vetjük össze.

No. Tulajdonság Microsoft Hyper-V Server VMware ESXi
1. A hypervisor típusa type1 mikrokernel type1 monolitikus
2. Max processzorok száma 4 32
3. Maximális memória 32 GB 256 GB
4. Virtuális gépek paraméterei Mint a Window with Hyper-V esetén, kivéve a maximális VM memóra: 31 GB Mint a VMware ESX esetén
5. VM magas rendelkezésre állás (HA) Nincs Nincs
6. VM Quick migration/Live Migration Nincs Nincs
7. DRS / PRO Nincs Nincs
8. Active directory integráció Van Nincs
9. Honos management eszközbe kliensként való felvétel Igen Igen
10. Idegen management eszközbe kliensként való felvétel Igen Nem
11. Távoli parancssor Igen Csak olvasási műveletek
12. Szerver távoli felügyelete GUI eszközzel Igen, MMC Igen, VI Client
13. Több szerver távoli felügyelete GUI eszközzel Igen, MMC Nem
14. Több szerver csoportos beállítása GUI-val Igen, GPO Nem
15. SNMP felügyelet Lehetséges Nem
16. Teljesítményadatok lekérdezése Igen, Reliability and Performance MMC Igen, VI client
17. Script alapú felügyelet Igen Igen
18. Automatikus host patching Igen (Microsoft Update) Nem (Manuális VI Client)
19. Központosított patch managementbe való bekapcsolódás Igen (WSUS) Nem
20. Hotfix után újraindulás Nem mindig Minden esetben
21. SAN-ró bootolás Igen Nem
22. USB, SD-kártyáról indítás Nem Igen
23. Átállás a teljes termékre Nem lehetséges (migráció) Lehetséges (licence vásárlás)

 

Szemtől szemben teljes harci díszben:
Ahogy korábban írtam, az összehasonlításnak kétféle korrekt módszertana lehet, az első a valóban ingyenes képességek összevetése, a másik pedig a termékek vizsgálata teljes környezetben. Most nézzük a fenti táblázatot, hogyan festi át a VI infrastruktúra. A korábbi sántikáló ESXi szárnyakat kapott és számos képessége kibontakozott (AD integráció, patch management), sőt az oly annyira sztárolt  VMotion, Storage VMotion, DRS is elérhető. Nincs is olyan tulajdonság, amelyben a Hyper-V Server – legalábbis így madártávlatból – felülmúlhatná a nehézsúlyú VI Enterprise-t. Talán csak néhány érdekes sort említek – ahol nem veszít, vagy nem annyira.

Itt van mindjárt a DRS / PRO kérdésköre. Világos, hogy teljes funkcionalitáshoz az kellene, hogy a Hyper-V Server is fürtbe köthető legyen – de az nem lehetséges. Viszont ettől még a PRO működhet. Tegyük fel, hogy van három Hyper-V Serverünk, amelyeken van 2-2-2 virtuális gép, webszerverek, NLB-be kötve. Ha megnő a fürt terhelése és egy újabb virtuális gépet kell üzembe állítani, akkor ezt az SCVMM egy Hyper-V Serveren is végre tudja hajtani, tehát a PRO képességek azon része, amely nem gépmozgatással jár, működhetnek. (Mellesleg ilyen parancsot a DRS nem is tud adni). A 7. sorban ezért írtam a “korlátozott” értéket.

Az sem teljesen igaz, hogy a Hyper-V-ről nem lehet elmozgatni virtuális gépeket. Az SCVMM ismeri a NPIV szabványt, és ha a tároló alrendszer is támogatja, meg a SAN switchek, akkor a LUN-ok áthelyezésével egyik hypervisorról a másikra “tehető át” egy virtuális gép. Végül – és ez  nagyon fontos – a Hyper-V Server is lehet mind SCOM, mind pedig SCVMM ügyfél, vagyis éppúgy menedzselhető, mint a teljes értékű változatok.

No. Tulajdonság Microsoft Hyper-V Server + System Center VMware ESXi + VI Enterprise
1. A hypervisor típusa type1 mikrokernel type1 monolitikus
2. Max processzorok száma 4 32
3. Maximális memória 32 GB 256 GB
4. Virtuális gépek paraméterei Mint a Window with Hyper-V esetén, kivéve a maximális VM memóra: 31 GB Mint a VMware ESX esetén
5. VM magas rendelkezésre állás (HA) Nincs Van
6. VM Quick migration/Live Migration Nincs Van
7. DRS / PRO Korlátozott Van
8. Active directory integráció Van Van
9. Honos management eszközbe kliensként való felvétel Igen Igen
10. Idegen management eszközbe kliensként való felvétel Igen Igen
11. Távoli parancssor Igen Igen
12. Szerver távoli felügyelete GUI eszközzel Igen, SCVMM Igen, Virtual Center
13. Több szerver távoli felügyelete GUI eszközzel Igen, SCVMM Igen, Virtual Center
14. Több szerver csoportos beállítása GUI-val Igen Igen
15. SNMP felügyelet Lehetséges Lehetséges
16. Teljesítményadatok lekérdezése Igen, SCOM Igen, Virtual Center
17. Script alapú felügyelet Igen Igen
18. Automatikus host patching Igen Igen
19. Központosított patch managementbe való bekapcsolódás Igen Igen
20. Hotfix után újraindulás Nem mindig Maintenance mode
21. SAN-ró bootolás Igen Nincs értelme
22. USB, SD-kártyáról indítás Nem Igen
23 Átállás a teljes termékre Nem lehetséges (migráció) Lehetséges (licence vásárlás)
24. Gépmozgatás NPIV alapokon Van Van

 

Összegzés
Amikor elkezdtem a cikket, fogalmam sem volt, hogy mire fogok kilyukadni, mostanra azonban néhány dolog világosan körvonalazódott a számomra.

  • Az ESXi egy architektúrális változás a VMware zászlóshajójánál, ingyenessége másodlagos jelentőségű.
  • Az ingyenes ESXi egyáltalán nem jelenti, hogy a kisvállalatok körében valóban jó megoldással rendelkezik a VMware. Számomra úgy tűnik, hogy az ingyenes VMware-es megoldásra az SMB szegmensben továbbra is a VMware Server – csakhogy az meg nem type1-es hypervisor.
  • Az ESXi elsősorban továbbra is a  nagyvállalatokat célozza, és a kezdeti ismerkedés után a menedzsment termékek megvásárlására ösztönzi a felhasználókat.
  • A Hyper-V képességei lefedik a kis- és középvállalatok igényeinek egy részét, de még itt is hiányozhat a magas rendelkezésre állást biztosító technológia.
  • A Hyper-V server nem tud mindent, viszont amit tud, azt jó minőségben – a Windows korábbi fejlesztéseire alapozva tudja.
  • A weben található összehasonlítások azért sántítanak, mert nem vizsgálják előzetesen, mi a termék célcsoportja és felhasználási területe.

…a parkőr meg mindenkit haza zavart
image  Pár hete már jeleztem, hogy a Hyper-V Server 2008 R2 nem egy Windows Standard derivátum lesz, hanem egy Enterprise Edition, ezért minden, ma még felróható fogyatékossága (fürtözött fájlrendszer, cluster, live migration stb.) egycsapásra megszűnik. Ez a fenti csetepatét kispajtások számháborújává fokozza le: számos, ma még a legdrágábbnak számító képesség (pl. VMotion) ingyenesen lesz elérhető.

A kórházi kirándulásom közben újabb bejelentés érkezett, miszerint a Citrix XenServer – az, amivel az Amazon felépítette a maga cloud-computing szolgáltatását – teljesen ingyen letölthetővé vált. Ami fizetős (Citrix Essentials), az a rendszerfelügyelet.

Mindez lépésre kell, hogy késztesse, sőt üzleti modelljének átalakítására kell, hogy sarkallja a VMware-t. A vSphere legfontosabb újítása az ártáblázata lesz. Meglátjuk.

————————-

* – Kevesen tudják, de még az ESXi-nek is van egy konzol-szerű komponense, ezt Tech Support Mode-nak hívják. Alapértelmezetten kikapcsolt, kizárólag hibakereséskor használható.

7 Responses to VMware ESXi kontra Microsoft Hyper-V Server

  1. Engedi Balázs says:

    Lenne két kérdésem :)Lehetséges lesz Hyper-V Server-ről Hyper-V Server R2-re az in-place upgrade?SCVMM SP1 mikorra várható?

  2. Gábor says:

    Én szerény vagyok, csak egy kérdésem van: kirakod ezt a cikket valamilyen formában a HUP-ra? Nagyon érdekes téma…

  3. Tamas says:

    Köszönöm, megtisztelő a felkérés, de tolakodásnak érezném. Aki keres, rámtalál, ha gondolod belinkelsz. A HUP tagságom célja (azon túl, hogy így hozzászólhattam az összehasonlító cikksorozatról folyó vitához), hogy ha vannak félreértések, ahol a tudásommal helyre tudom billenteni a dolgokat, akkor azt megtegyem.

  4. Tamas says:

    Az in-place upgrade még nem eldöntött dolog. Van nálatok Hyper-V Server amit frissíteni kellene? Mire használjátok? Hány szerverről illetve hány kliensről van szó?Az SCVMM SP1 a 2008 R2 megjelenésétől számított 90 napon belül várható.

  5. Engedi Balázs says:

    Epp most telepitunk egy helyre HP EVA SAN-t plusz 3 blade szervert, es virtualizalt kornyezetben EBS 2008 premiumot. Az az otletem, hogy Hyper-V szervere telepitunk minden EBS cuccot, majd kesobb frissitjuk alatta R2-re. EBS miatt 4 szerver + Blackberry miatt migralni kell meg egy 2k3-at is. 30-40 kliens hasznalja a rendszert.

  6. Tamas says:

    Ez már üzleti igény! Továbbítom az esetet, lehet, hogy levélben folytatjuk. A címem a keresztnevem és a vezetéknevem első betűje, tehát tamasl, majd a munkáltatóm neve pont com.

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: