ESXi 4.x-re szeretnék telepíteni egy Windows 2012 R2 vm-et. Tudom, ne akarjam, unsupported. Találtam viszont régebben egy nem hivatalos utat, mely az 5.x-ből "backportolt" virtual hw biosát felhasználva kínál megoldást. Itt egy példa:
http://jgiffard.wordpress.com/2013/06/25/windows-server-2012-on-esxi-4-…
Egyébként a communities.vmware.com-tól kezdve tonnányi blogon át meg van énekelve ugyanez, 100%-ban pozitív feedbackekkel, és tapasztalatokkal.
Jómagam is csak pozitívan tudtam volna nyilatkozni eddig (van ahol fél éve használom a fenti megoldást, problémamentesen), azonban van egy vSphere clusterem amin nem akar működni a dolog. Felviszem a vm configjába a custom paramétereket, bemásolom a jól ismert bios filet, viszont a guest Win.2012 random fagyásokat produkál, van hogy 5 perc után, van hogy 3 óra után. Az Event logban nincs semmi, csak a következő boot után egy critical error (kernel-power), mely arra panaszkodik hogy az OS nem megfelelően lett leállítva előzőleg.
Ha valakinek van egyéb ötlete, tippje, akkor kérem ne tartsa magában.
(A felesleges körök lefutása végett: igen, tudom, hogy 5.x-öt kéne vásárolni, és upgradelni a gányolás helyett. Aki ellenállhatatlan vágyat érez az ügyben, hogy ezt az orrom alá dörgölje, azt megkérem hogy ne tegye, TUDOM, hogy egy ideális világban ezt kéne tenni, de ez nem egy ideális világ).
MEGOLDÁS:
CPUID maskingra is szükség volt. Pontosan ugyanezt csináltam, bár látszólag nincs köze egymáshoz a két a problémának:
http://hup.hu/treyblog/20140626/vsphere_ha_a_server_2012_csak_tekeri_te…
Hozzászólások
Hyper-V nem megoldás annak a néhány VM-nek?
(Egyébként ha prodban használod no comment.)
+1 a prod "no comment"-re.
a 4.1 mar osregi, ki kell dobni, es 5.5u1-et felrakni.
Adnék még néhány infót, bár direkt ezért írtam az eredeti kérdésben arról, hogy hagyjuk ezt a szálat, mert nem látom értelmét, de úgy tűnik sajnos muszáj:
Ha a bios backport miatt probléma lenne, az kizárólag abban az 1db vm-ben keletkezne. Ez viszont NEM gond. Persze jó lenne, ha úgy működne ahogy más helyeken, meg ahogy annak a több száz commenternek szerte a neten, de valamiért nem működik úgy, hanem 1-2 óránként dob egy hátast. Ennek a megoldására vonatkozott volna a kérdés. Ha a megoldás az, hogy ugyanúgy (azaz jól) működik, de elméletben veszélyeztetve van 1db (!NEM!) produciton Win 2012 vm, mert LEHET hogy ez a megoldás nem annyira jó, (meg amúgy is, milyen már...), és majd 1 év múlva rebootol egyet a vm, akkor oké, ez teljes mértékben vállalható szituáció.
Én is erősnek érzem, hogy az Update 3 (2012. augusztus 30.) ősrégi lenne.
Windows 8.1-s hack-ek sem segítettek?
Tök ugyanez szerepel abban a cikkben amit az eredeti kérdésben írtam…
Sajnos szegény magyar IT-s vízzel főz, és esxi 4.1-et patkol, még ha ősrégi is. Elég nehéz a menedzsment torkán lenyomni, hogy a host-onként közel 5000USD-ért, 3-4 éve megvett Enterprise Plus licenszeket vegyék meg újra. A mánágerek ebből csak annyit látnak, hogy újra fizessenek ki egy szekérnyi pénzt csak mert a korábbin nem megy a Windows Server 2012. Esélytelen... Pláne, ha van több tucat host. :(
Látom van aki meg bírja érteni, hogy miért nem akartam belemenni ebbe a mellékágba :)
Egyébként még mindig olcsóbb megoldás lett volna venni egy 2008 R2 licencet mint upgradelni, de azért az se 2Ft, és egy magyar KKV megérzi még ezt is (főleg ha már van a polcon egy 2012 licence).
Én is ezt javasolnám, felrakni egy Hyper-V Server 2012 R2-t ingyen és bérmentve és mehet bele a win server. Amin esxi fut, azon a hyper-v server is fog és ezer dolgot tud amit az esxi nem, tökingyen, pl. replikáció, live migration, clustering, storage QoS stb.
Licencelt vSphere-ről van szó, szóval van vmotion, FT, és egyebek, mindez aktívan használva, sok pénzért megvásárolva anno. Ezért is írtam le, hogy TUDOM hogy upgradelni kéne, de nem ingyenes ESXi-ről van szó, amit hipp-hopp kicserélek.
A hostokon rengeteg linux fut, elvétve 1-2db Win 2k8 R2, és most kéne 1db Win 2012 Server. Nyilván emiatt nem szeretnénk szétbombázni az egészet, pláne hogy nem egy zsákutcáról van szó vélhetően, hiszen más helyeken működik a megoldás, egyrészt.. Másrészt vélhetően a jövőben ki lesz köhögve a 5.x upgrade, de sajnos nem holnap. Ha nem 1db vm-ről beszélnénk, akkor persze más lenne a helyzet.
Amit megoldásnak vélsz, mint a mellékelt ábra számodra is mutatja nem mindenhol működőképes, ezért nem is támogatott. Innentől két út van.
1. Kell a Win2012, ekkor még lehet több alternatíva. vSphere upgrade, vagy másik hypervizor, Workstation, ingyenes ESXi, Hyper-V, stb...
2. Nem kell Win2012, akkor nem sürgős az upgrade viszont Win2008 rendszert kell használnotok.
Persze azt megteheted - és lehet, hogy teljesen feleslegesen -, hogy elkezded magad keresi a hibát, összehasonlítva egy működő rendszert ezzel. Patchek, Update csomag szint, hw környezet, stb...
Nem mindenhol = csak nálam, és nálam is csak az egyik clusternél. Egyébként ha minden jól megy, írom a 3. utat, de nem akarom elkiabálni, várnék vele 1 napot legalább :) Amúgy szerencsére a patchlevel/config/etc, eltérés nyomozását gyorsan megúsztam, mert ahol működik, az tükörképe ennek a rendszernek, egyedül a HW tér el. Ezért is kezdtem el kutakodni a CPUID masking környékén, ami beválni látszik, de majd az idő eldönti.
Mivel nekünk a cégnél is egy 4.2-es vmware klaszter van, 1-2 hónapja teszteltem a Hyper-V-t mint lehetséges alternatíva.
Feltettem az alap hypervisort egy gépre (talán HP szerver volt, tehát nem sima gép) és telepítettem pár vm-et. Windowsok esetében minden rendben volt, de egy ubuntu 12.04-es linuxot, kb 3-5x annyi idő alatt tett fel, mint vmware vagy XenServer-re.
Ez egy nagyon jelentős különbség.
Minden SSD-n futott, és minden tesztet ugyanazon a szerveren végeztem el, igaz nem ismételtem megy, egy újratelepítés után, de milyen szerver az, amit újra kell telepíteni, hogy elkapjam a normális futtatási sebességét.
Nincs ötletem, mint ronthattam, el, tehát számomra a HyperV evvel ki van zárva további pár évre, az alternatívákból.
Ezek előtt a 2008-as szerverben debütálót teszteltük a cégnél, akkor még a windows futtatásában is gondok voltak (iscsi is volt a tesztkörnyezetben, lehet egy sima helyi windows-al elboldogult volna).
Azért egy Integration Components nélküli telepítés sebességéből messzemenő következtetéseket nehéz levonni.
http://baudlabs.com/how-to-install-hyper-v-integration-services-in-ubun…
Üdv,
Marci
A Microsoftnál dolgozom.
Viszont itt 1 db win2012 telepítésről volt szó egy nem supportált, ingatag módszerrel, nem linuxokról.
(a 4.2 typo sajnos már így marad)
Úgy tűnik a CPUID masking megoldotta:
http://hup.hu/treyblog/20140626/vsphere_ha_a_server_2012_csak_tekeri_te…
A kollégák pont ugyanezzel küzdenek, Ennek kapcsán eszembe jutott, lehet hogy a problémát a esxi 4.1 patch level okozza. Szerintem nézd össze a problémamentes és a problémás cluster-ben az esxi-k verziószámát. Az talán jó lehet kiindulási alapnak. Lehet, hogy a patch-elt bios egy bizonyos verziójú esxi-nél készült, és azóta nem követte a készítő a vmware pacth-el kapcsán a változásokat. De ez csak egy tipp.
Nincs patchelve a bios, szűz 5.x telepítőből kell kimásolni. Ellenkező esetben egy kicsit én is soknak érezném már a dolgot, devel windows vm ide vagy oda. Vélhetően a vas okozta a problémát amúgy (lásd megoldás). Ahol csont nélkül működött ott Fujitsu RX*** hostok vannak, a problémás helyen DELL. Persze a CPU-k is eltérnek, de hogy konkrétan csak ez okozta e a problémát, vagy az egyéb komponensek eltérése, az sajnos valószínűleg soha nem fog kiderülni, mindenesetre az biztos, hogy a Fujitsukon nem volt szükség CPUID maskingra.
Korábban más probléma miatt néztük már a CPU mask-okat, és kiderült, hogy esetenként még verzión belül, de más patchlevel-en is eltérhet.
"devel windows"
Tényleg nem értem, hogy emiatt megérte ennyit szórakozni.
Mennyit? 2 órát bruttóban? Egyébként meg nyilván nem magamnak csinálom, hanem ügyfélnek, ő dönti el hogy mi éri meg neki és mi nem. Nekem ugyanúgy munka produktív vm-eket telepíteni neki, mint fejlesztői környezetet. A "devel" mivoltát csak azért volt muszáj megjegyeznem, mert nehezen értették meg egyesek hogy miért nem rohanok (illetve rohan az ügyfél) a disztribútorhoz pár millióért vSphere 5-öt vásárolni. Nyilván ehhez képest vállalta be az unsupported megoldást, mérlegelve a kockázatot és a biztos, supported megoldás árát.
Egyébként irigykedve olvasom a hozzászólásokat néha, úgy látszik csak én futok bele itthon olyan feladatokba, ahol abból kell főzni ami van. Illetve ezek alapján máshol mindig minden tök sima ügy, csettintésre migrálják Hyper-V-re az évek óta működő clustert 1db vm miatt, vásárolják a több milliós licenceket, és úgy egyáltalán minden megy mindig elsőre mint a karikacsapás. Tök jó nektek :)
Ki beszélt itt egész clusterek migrálásáról? Egy db fizikai gépre feltelepíted a devel windowst vagy a'la natur vagy alá teszel egy hyper-v-t és kicsit rugalmasabb lesz a dolog.
Nálunk is van olyan, hogy szarból kell várat építeni, de ha lehet kerüljük az ilyen tákolásokat, ez az ügyfél érdeke is.
Persze, 2db Xeon CPU-val, meg 48Gb rammal rendelkező fizikai gépet toljunk el erre, miközben aktív részese a HA-nak, FT-nek, és van még rajta egy halom vm.
Igen, nem írtam ezt a információt, de írtam helyette kb. hatszor, hogy nagyon szépen kérnék mindenkit, hagyjuk ezeket a mellékszálakat, teljesen felesleges körök, nem erre voltam kíváncsi.