vSphere 5.5 - esxi ellehetetlenitése?

Virtualizáció

Lehet, hogy valamit elnézek, mert nem láttam a probléma súlyának megfelelő őrjöngést fórumokon, de...

vSphere 5.5-ben ugye vannak új fejlesztések, amivel sok tekintetben utoléri pl. a hyper-v tudását (vmdk méret, memória korlát eltörlése stb) amiknek a kihasználásához viszont v10-esre kell upgradelni a VM-eket. Csakhogy onnantól a windows-os vsphere client nem hajlandó kezelni a vm-et, még a beállitásait sem tudja módositani.

Az régóta ismert, hogy próbálnak átállni a flash-es web client-re és a .net-est hanyagolni, de ugye a mai napig nem sikerült kiváltani minden funkciót (update manager, site recovery stb) ehhez képest az 5.1-es windows-os vsphere client nem tudja kezelni az 5.5-ös esxi-t, frissiteni kellett. De akkor minek, ha nem kezeli a v10-es VM-eket?

De a legnagyobb probléma, hogy az ingyenes esxi-hez (tudtommal) nincs web client, tehát innentől értelmetlen az egész, használhatatlan az ingyenes verzió. Ha ezt viszont komolyan gondolják, akkor biztos kidobom még a maradék két helyen is és ott is átállok hyper-v-re. De remélem csak valamit elnéztem...

  • 16415 megtekintés

( mauzi v | 2013. 09. 26., cs – 19:52 )

Nem nézted el...

Bár még nem volt időnk játszani vele, de IMHO a 32 GB-os memória limit eltörlése független a VM formátumtól, magyarul szerintem 9-es verziójú virtuális gépekkel is kéne tudnod 32 GB RAM fölé menni.

A VMDK limit nyilván marad a 9-es verzióval.

VM9-re gondolsz, azt még lehetett kezelni a wines client-ből. Hiányzik az új SATA kontroller, az új vGPU támogatás, a linuxos hardveres gyorsitás és persze a megnövelt méretű vmdk. Ezt mind tudná az ingyenes, de nem tudja, mert nem lehet kezelni vcenter nélkül. Röhej.
Ezért teljesen felesleges volt a vsphere client-et frissiteni, hiába tud kapcsolódni az esxi-hez, ha nem tudja a VM-eket kezelni. Azt még nagy jóindulattal megértem, hogy az új funkciókat nem tudja kirakni gui-ra (bár azért ez is necces, mert látszik rajta, hogy dinamikuson rakja össze a beállitási lehetőségeket) de az, hogy ne tudja felhozni legalább az alapvető beállitásokat se, amiket eddig is tudott az nevetséges.

Azért is fura az egész, mert a hyper-v megjelenésével látszólag észbe kaptak, mivel az mindent ingyen adott és elkezdtek átállni rá a népek, ezért az esxi-be is egyre több dolog lett ingyen, emelték a limitjeit, most meg úgy tűnik mintha visszafordulnának.

Nem egyre gondolunk szerintem. A legújabb klienst használom mindig, de a kliens megnézi hogy milyen verziójú vCenterhez/hosthoz csatlakozol és a megfelelő verziójú régebbi klienst meghívja a háttérben. Ha nincs fent akkor kapsz egy ablakot login helyett hogy letöltheted.

Elolvastam, és jelentős összefüggést látok azon dolgok között, hogy ha valaki 62T-nyi vmdk-t szeretne, az vélhetően azért szeretne ekkorát, mert meg is akarja tölteni, és mindahhoz, hogy ezt megtegye, rendelkeznie kéne (!) - lehet, hogy Szerinted nem, de szerintem igen, és itt van az összefüggés, ha ez nem tűnt volna fel - olyan méretű háttértárral, ahol az elhelyezhető.
Ettől függetlenül én biztos vagyok benne, hogy erre az összefüggésre Magad is rájöttél, csak kötekedni akarsz - ám, ha tévednék, és valóban nem látod az összefüggést, nagyon szívesen állok a rendelkezésedre. :D
Ám, ha még mindig nem értenéd a lényeget, annak is elébe mennék...
Te valóban vmdk-ról beszélsz, nem storage-ről. Ám - a figyelmes szemlélőnek minden bizonnyal feltűnt - a vmdk-n általában ugyanúgy tárolunk valamit, mint egy storage-on, még akkor is, ha a storage nem virtualizációs környezet része. Így, ha valakinek kell >1PByte tárterület annak ellenére, hogy egy kis cég, miért ne lenne létjogosultsága egy vagy több 62T-s vmdk-nak? És igen, a storage-okon a fájlrendszer is teljesen egyben van, nem 1T-s szeletekben osztogatják ide-oda.
--
PtY - www.onlinedemo.hu

Inkább 32x2TB lesz az, mert 2TB-ot tudott csak az 5.1-es adni, ami lássuk be egy kisvállalatnál is harmatkevés. Guest-ben pedig felesleges a sok külön lemez összerakásával bohóckodni, ha megoldható egyben is. (legalábbis van ilyen helyzet is, meg olyan is, hogy értelme van szétszedni, de felesleges elvitatni az igényt a 2TB-nál nagyobb lemezek kezeléséről)

Vagy egy nagy, és sok kicsi, vagy kevés nagy, vagy kinek mi tetszik.
Abból ítélve, hogy az 'általában' szót használtad, biztosan láttál már 5-6 ilyesmi storage-ot, ilyesmi kis cégeknél, hogy ezt a következtetést levond.
Fel sem merül Benned az, hogy valakinek csak 1 fog kelleni, akár adatbázishoz, akár nagy fájlok tömeges tárolásához és semmi kedve a vm alatt még plusszban 3-4 vmdk-ra építkezve stripe-olni a diskeket, hogy egyben legyen a tárterület?
--
PtY - www.onlinedemo.hu

Hát pedig a kkv-s változat 3 hostra az 5.1-esből volt vagy 500USD (az 5.5-ös is kb. ugyanannyi pénz. És akkor támogatást is kaptak volna. a támogatás keretein belül meg elmondhatta volna a vmware dealer a következőket:
- a vsphere client és ez esxi verziója szorosan összefügg. 4.1 esxi-hez 4.1-es kliens kell, 5.0 esxi-hez 5.0 kliens és így tovább. tehát az 5.5-ös esxi-t 5.5 klienssel lehet kezelni.
- az esxi != ingyenes verzió. Esx ugyanis már 4.1 óta nincs, nem létezik. Esxi-hez van ingyenes és fizetős licensz, a hypervisor ugyanaz.

Ezt kifejtenéd? A hyper-v server teljesen ingyenes, bárki letöltheti, semmilyen korlátozást nem tartalmaz, akár 64 node-os fürtöt is csinálhatsz belőle, ingyen és bérmentve. Ha nem akarsz fürtöt, akkor replikálhatsz is, szintén ingyen a gépek vagy akár telephelyek között. Ha ilyesmit akarsz vsphere-el, az alaphangon többmillió ft. Nincs semmi a windows server árába épitve.

Csakhogy Te a Windows Serverről beszélsz, Imo pedig a Hyper-V Serverről.
Utóbbi minden célra ingyenes és teljes funkcionalitású a Hyper-V szerepköre.
Leginkábbis úgy képzelhető el, mintha egy Windows Servert csak a Hyper-V szerepkörrel telepítenél. Viszont fontos tudni, hogy más szerepkörök nem telepíthetők rá, és a rajta futtatandó guest-eket licencelni kell.
VDI-hoz, nem Windows guestek futtatására igen alkalmas, de természetesen Windows Serverek virtualizálására is (egyszerűbb termék, kevesebb hotfix)

Üdv,
Marci

Pont Windows Serverről beszélt, én pedig arra válaszoltam. Előtte tudom, hogy a Hyper-V Serverről volt szó.

Az világos, hogy a Hyper-V szerepkörön kívül más hasznos dolgot művelő cuccot nem lehet telepíteni. De ez csak a "Role"-okra (AD, File, Web, stb) vagy a "Feature"-ökre is érvényes?

Dedup ezekszerint kilőve mert az magával húzza a File Server-t...

Volume licensing, MAK-al a host és a guest is aktiválva lett. Akkor ezt most hány telepítésnek látja a Microsoft?

"megnövelt méretű vmdk"
Frankón kell neked 2 teránál nagyobb vmdk a gyakorlatban?
Ezeknek az újdonságok nagy része már régen nem technikai dolog, hanem szimpla számháború szerintem...
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( Mico v | 2013. 09. 27., p – 07:01 )

a webes klienstol nagyon kivagyok. javult 5.5-ben?

Gyorsult kicsit, de még mindig legalább 2x lassabb mint a windows-os client. Ugyanúgy rányomsz valamire, elgondolkodik, felugrik minden, aztán eszébe jut, hogy pár dolognak nincs értelme ott, akkor azokat kiszürkiti. Ha egész nap ezt kéne nyomkodnom, biztos belehülyülnék, szerintem sose lesz olyan jó mint a .net-es.

Azért a .NET-es kliens sem egy rakéta, ráadásul Windows 8 alatt (ami már egy ideje kint van a piacon) még mindig rá lehet szaladni érdekes hibákra. Nyilván a VMWare érdeke is, hogy ugyan ingyen használod a termékét, de rákényszerítsen arra, hogy megvedd a licencelt verziókat.

[OFF]
Amit én hiányolok még, az a normális VM management Androidra. Még a fizetősöket is kipróbáltam, de nem vagyok elájulva. Elkezdem a SOAP-os API-t piszkálni benne, de olyan rosszul dokumentált, hogy elküldtem melegebb éghajlatra. Így az ingyeneshez marad a Windows .NET kliens.

( PtY | 2013. 09. 27., p – 09:53 )

4 évvel ezelőtt (egy hónap híján) a vmWare llőtte a vmware server 2 termékvonalat ahelyett, hogy egy olyan szolgáltatássá alakította volna át, mint pl. a KVM. Ehelyett az ESXi-t tolta, ami önmagában nem baj, csak a vmware server elfutott a krumplis zsákon is, az ESXi nem igazán, mert a támogatott hardverek száma nem igazán a végtelenhez konvergál.
Azóta a felhasználók egy része - akik nem brand gépen tolják a colocationben - áttért KVM-re, a másik része beruházott olyan hardverre, amin elfut az ESX - a vmware mentségére szóljon, hogy azóta jelentősen nőtt a hw támogatottság, de azért még vannak hiányosságok.
Evvel a lépéssel újabb közönséget fog veszíteni a vmware, és lassan elérik azt, hogy a feltörekvő nemzedék nem is fogja ismerni majd a nevüket, mert nem ez lesz az első, amivel az életben összefut és megismer.
Nem baj ez végül is, ha belegondolok, hogy a szó igazi értelmében vett okostelefont anno a BlackBerry találta ki... :D
--
PtY - www.onlinedemo.hu

Micsoda?

Nagy lóf@xt, már bocsánat. Ha már virtualizációval foglalkozunk, nem árt különbséget tenni szerver virtualizáció és desktop virtualizáció között!

Anno az egyik cégvezető - most átvette a pozíciómat a volt munkahelyemen (LOL) - megkérdezte, hogy a colocationben miért KVM-en üzemeltetünk, miért nem VirtualBox-on (OMFG). Mikor erőforrás-allokációról kezdtem neki mesélni, azt sem tudta, mi az!
Kellett neki egy virtuális környezet valami demora, a kezébe nyomtam egy mini itx-et ESX 5-tel, legyalulták b@szki, tettek rá virtualboxot... Azt hittem, befosok...
--
PtY - www.onlinedemo.hu

Arról meg ne is vegyünk tudomást, hogy a workstation és a server mint termékek léteztek egyidőben, így egymásnak nem alternatívái. Két külön termékvonal, különböző képességekkel. Ne keverjük a szezont a fazonnal.
Főleg, hogy az egyik termék free, a másik meg nem. Ha már itt tartunk, inkább a player az, amire Te gondolhatnál, de az meg még annyit sem tud, mint a WS.
--
PtY - www.onlinedemo.hu

Az esxi egy bare-metal rendszer, a server 2 nem igazán, innentől kezdve olyan mintha az almát hasonlítod a körtéhez, igaz hogy mindkettő gyümölcs, meg fán terem, de mégis egészen mások...

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Nem hasonlítok semmit semmihez, tudom, mi az ESXi.
A VMware nyilatkozta azt, hogy megszünteti az ingyenes vmware servert, és ezentúl már csak az ESXi-t támogatja, mint ingyenes szerver virtualizációs megoldást.

"End of General Support for VMware Server 2.0 is 2011-06-30, users should plan to upgrade to the newest release of either ESXi or VMware Player. - See more at: http://www.vmware.com/security/advisories/VMSA-2010-0007.html#sthash.rR…"
--
PtY - www.onlinedemo.hu

"csak a vmware server elfutott a krumplis zsákon is, az ESXi nem igazán"

Erre gondoltam konkrétan, a vmware server alatt ott van még a host rendszer, miközben az esx alatt közvetlen a vas van, innentől kezdve nem csoda, ha nem fut minden pizzásdobozon el.
Van egy ajánlott lista ami tuti jó, ha valaki időmilliomos az meg kikisérletezheti, melyik pizzásdoboz alkalmas a futtatásra, annyit hozzátennék, hogy normális server vason még nem láttam hogy ne futna, aki meg asztali vasra esx-et rak, vállalja be a szívást vele :)

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Igen a KVM type 1 virtualizáció, ahogy az esx is.
A vmware server pedig type 2.
A futás meg egy olyan dolog, hogy az esx is elfut sok mindenen, de azt a vmware nem garantálhatja, mert nyilván nem tesztelik le minden china gyártó termékével.
Intel alaplapkon futni szokott gond nélkül..
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Rengeteg forrás található a neten (vmware fórum, blogok) ahol a nem kimondottan szerver hardveren való futtatást taglalják. Mivel külföldön sem mindenki engedheti meg magának a brand szervereket az otthoni infrastruktúra felépítéséhez. Komplett hardver listával egyetemben. A kulcsszó ESXi 5 Whitebox. Demo célra sokan használak notebookot ESXi futtatására.

Tudom hogy rengeteg mindenen elfut, volt szerencsém managelni ilyen rendszereket is, a tapasztalatom szerint fényévekkel több gond van velük, mint egy normális akár hasznát bevált vasakkal.
Lehet szarból várat építeni, csak akkor ne legyen már szidva a vmware, hogy nem mindenen megy.
Azon amire azt mondják viszont, hogy megy, azok tényleg mennek.
Hidd el nagyon könnyen bele lehet olyan bugokba futni, hogy a virtuális gép olyan anomáliákkal él, hogy csak vakarod a fejedet, ha támogatott a vas ezt relatíve egyszerűen megtudod oldani, ha nem akkor komoly szoppantás elé nézel(ez is tapasztalat).

---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Nem hangsúlyoztam eléggé, otthoni labor célra gondolom csak az olcsósítás ezen módját. Szeritem fogadjuk el, hogy ez is egy műküdő út, mivel rengetegen foglalkoznak vele, és közzéteszik az információt. Én egy szóval sem említettem a vmware szidását.
Mellesleg brand szerveren is belefuthat az ember "szép" jelenségekbe.

Általánosságban gondoltam a szidását, nem csak neked szántam, sorry :)
"Mellesleg brand szerveren is belefuthat az ember "szép" jelenségekbe." Persze, de jóval kevesebb az esélye azért a dolognak...
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( freeoli v | 2013. 09. 27., p – 11:15 )

Az VMware vSphere Client 5.5 nem tudja kezelni a vm-et?

( AiRLAC v | 2013. 09. 27., p – 11:37 )

"amivel sok tekintetben utoléri pl. a hyper-v tudását"

Ez meg a hét vicce :D

( HKaresz | 2013. 09. 27., p – 21:38 )

Többen pedzegették, hogy szükség van-e X TB-os VMDK-ra. Tudna mondani valaki egy reális helyzetet, amikor ekkora tárhelyre van szükség VMDK-ban? Mert arra tippelnék, hogy menedzselésben, teljesítményben jobb egy NFS/iSCSI.

Egy virtuális környezetben elég sok network interface-re lesz szükség, ha sok VM-ed van, mert egyetlen gigabites kapcsolaton több gépnek kell osztoznia.
Úgy érted, hogy ezt még fejeljük meg drága network traffic-kal? És főleg: hogy lenne már nagyobb teljesítményre képes?
A SAS vagy Optikai IO teljesen más területen okoz terhelést, mint a network IO.
Persze, lehet tenni egy hostba 10+ hálózati vezérlőt, és össze lehet fűzni jópárat, és ha talán sikerül is vele elérni a a sas vagy a 4Gbit-es optika átvitelét, ott van még a multipath hiánya, a magasabb CPU terhelés, és jópár virtualizációs környezetben hasznos feature elvesztése (pl. snapshot).
És igen, tudom, hogy van 10Gbe, csak az meg hatványozottan CPU igényes, ami virtuális környezetben nagy érvágás, amellett horribilis költségei vannak. Igen, az infiniband is ugyanez a kategória, bár az inkább anyagiakban költségesebb, mint CPU-ban.
Szóval igen, szükség lehet 2T-nál nagyobb diskekre, és ez nem a cég méretétől, hanem a megvalósítandó feladattól függ.
--
PtY - www.onlinedemo.hu

Hol látsz összefüggést? A 2TB és az iSCSI között, vagy a 2TB és a stotage között, vagy a storage és az iSCSI között?
Egyik között se tudom, hogy lenne, azért kérdezem.
De azért itt egy link, ahol picit nagyobb számokról beszélnek: https://communities.netapp.com/thread/19375
--
PtY - www.onlinedemo.hu

Komolyan, egy 8 éves gyerek is megérti, amit írok. Neked nem megy, és ezért engem okolsz. OK. Menjünk le ovi szintre.

Amit utoljára idéztél:
Azt írtad, minek egy kis cégnek 62T - írtam rá példát, amit idéztél. Az, hogy egy cégnek ennyi adatterület fizikailag kell, vagy virtuálisan, tulajdonképpen irreleváns, csak szerettem volna rámutatni, hogy a szükséges adatterület mérete és a cég mérete nincs összefüggésben - akkor sem értetted, most sem érted, ezután sem fogod - sajnálom.

Amit meg azelőtt mondtam:
Egy hazai kis cég nem fog halom 10Gbe-t és infiniband-et használni virtualizáció alatt iSCSI-re és/vagy NFS-re, mert a SAS és az optika anyagiakban és CPU erőforrásban is olcsóbb. Erre jössz az előző példámmal, amelyben a virtualizáció nem szerepelt, itt meg igen, így a két dolog nem releváns, arról nem is beszélve, hogy az említett storage-ok mehetnének akár optikán is - ugyanis senki sem mondta, hogy mi az inteface... Ebből is látszik, hogy vaktában lövöldözöl, hátha eltalálsz valamit.

Azt azonban még a mai napig nem vetted észre, hogy ha VM-be NFS-t vagy iSCSI-t mountolunk, avval pl. a snapshot lehetőségét elveszítjük.
--
PtY - www.onlinedemo.hu

Nagyon ott vagy!
Gondolod, ha egy szánalmas Essential licencre nem futja, hogy VM10-et kezelhessen, akkor majd fabricra lesz...
A storage meg eth-n az ördögtől való, mi? Drága network traffic? Made my day! A converged hálózatok és a hardwares offload meg szemfényvesztés.

Topic nyitónak:
Előfordul, hogy szándékosan nem tudod kezelni az új verzióban a vastag klienssel az új VM verziót, hogy ezzel tereljenek legalább egy Essential megvásárlása felé. A VMware egy profit orientált cég, ez gondolom megbocsátható nekik. Ha nem akarsz költeni akkor fogadd el, hogy ennyit kaptál ingyen.

Még mindig nehéz felfogni, hogy az említett cég, aki ekkora storage-eket használ, nem virtualizál, és nem említettem sehol, hogy milyen interface-en kommunikálnak? Hahó! Jó reggelt kívánok!
Olyan dolgok között vonsz párhuzamot, amelyek között nincs, és mókásnak tartod, hogy nincs összefüggés.
Ne nevettesd már ki Magadat huszadszorra is :)

Ha valaki elmeséli Neked, hogy két hónapja hogy leégett a Balcsin, majd egy másik kontextusban megemlíti, hogy bezzeg milyen szép volt a telehold, akkor azon fogsz mókázni, hogy teleholdnál égett le? Nem érzed szánalmasnak?
--
PtY - www.onlinedemo.hu

Halkan jelzem, hogy az a cég, akiről említést tettem nem virtualizál.
Nem általánosítottam, egy konkrét cégről beszéltem. :)

Általánosságokban persze ez nyilván kirívó eset, emiatt nem lehet általánosítani, mint ahogyan azt sem lehet kijelenteni, hogy egy kis cégnek nincs szüksége egyben 62T tárterületre.
--
PtY - www.onlinedemo.hu

Az említett cég általam lett említve, és ugyanarra utaltam vissza. Ezt hogy lehet általánosításként értelmezni?
Meg kellett volna neveznem? Azt semmiképp sem tenném :)
Hogyan kellett volna írnom, hogy ne lehessen általánosításként értelmezni?
--
PtY - www.onlinedemo.hu

Már többször leírtam, több helyen: amilyen pongyola a nyelvhasználat manapság, sokszor az ember találgatni kényszerül, hogy egy-egy hozzászólás írója mit is akart valójában mondani.

Jelen esetben az "aki" használata mondjuk az "amely" helyett... hát legalábbis kétesélyessé tette számomra, hogy most akkor tényleg egy konkrét cégről beszélsz vagy rajtuk keresztül általánosítasz. Én úgy tippeltem az utóbbi lehet.
Ha nem, hát nem. :)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Vannak cégek, akik virtualizációt kénytelenek használni, mert a meglévő erőforrásaikat gazdaságosabban tudják kihasználni, és nem fognak kiadni közel 1M HUF-t essential licence-re, mert - míly meglepő - nincs rá pénzük.

Személy szerint használok storage-et eth-n nem is egy helyen, de ha értetted volna, amit írok, akkor nem kevernéd a szezont a fazonnal.
Ugyanis arról volt szó éppen, hogy ha a VM-nek nem lehet adni 2T-nál nagyobb vdisket, akkor miért nem adunk NFS-t vagy iSCSI-t.

Áruld már el, ha ilyen roppant okos vagy, hány helyen adnál egy VM-nek iSCSI-t, virtuális eth-n? Mesélj róla, mert érdekel!
--
PtY - www.onlinedemo.hu

Én tudok konkrét esetet: VirtualBox-ban egy időben nem lehetett más módon megosztani két VM között a diszkeket, ha clusterrel akartál kísérletezni. Erre jó volt az iSCSI egy virtuális adapteren.

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Azért én évek óta használom "semmire" :)
(desktop gépen szervereket futtatni)
Pár verzióval ezelőtt egyébként már belekerült, hogy meg lehet osztani diszk image-eket két VM közt úgy, hogy egyszerre lássák, szóval már nincs szükség effajta workaroundra. :)

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Az ár így pontatlan és zavart keltő: az Essentials csomag lista ára ~200e, az Essentials Plus lista ára van 1M körül (nettó árak).

VM-nek iSCSI virtuális eth-n:
- virtuális gépek mentése (SAN-hoz hozzáférni)
- iSCSI-s TL
- MSCS
- vs5 előtt 2TB-nál nagyobb méret igény
- tesztelés
- egyéb, mert valami miatt egyszerűbb az adott helyzetben vagy máshogy nem lehet megoldani.

A "semmire" túlzás, inkább úgy fogalmaznék, hogy "nem sokra", de ez független attól, hogy mi kerül mennyibe.

Olvastam az előzményeket (bár nem mindig egyértelmű, hogy egyes állításra Neked mi a válaszod), az aktuális hozzászólásodban az volt a felvetés, hogy mi célból lehet szükség iSCSI-t virtuális gépből használni, erre írtam néhány esetet. Egyébként nem vs5-öt emlegettem, hanem vs < 5-öt :-)

Tesztelésnél pl. használsz snapshotot is, ami nem hat a hálózati tárolókra, így, ha konzisztensnek kell lennie bizonyos elemeknek az iSCSI-n, és a local disken, a snapshot ezt tönkreteszi.
Produktív környezetben nem sok olyan scenario jutna eszembe, ahol az Általad felsoroltak számításba jönnének - annak ellenére, hogy azt be kell látni, egyre több kis cég használ tesztelésre is virtuális környezetet - azomban ezek zömmel nem ESX-ek, pont a certified hardver miatt.
--
PtY - www.onlinedemo.hu

Tudom, mik a különbségek az egyes technológiák között, a kérdés az, hogy mit akarsz tesztelni, jelen esetben arra gondoltam, ha fizikai gépen használnál iSCSI-t, de előtte ki szeretnéd próbálni.
A tesztelésen kívül a többi eset mind produktív környezetre vonatkozott, például virtuális gépek mentése tipikusan produktív környezetek feladata.

Egyébként tesztelés és tesztelés között is rengeteg különbség van: ki, milyen céllal, mit tesztel - ezek nagyjából meghatározzák, hogy milyen hardver és virtualizációs rendszer jöhet egyáltalán szóba.

iSCSI teszt: igen, hogy működik, miként működik, milyen OS-t válasszak, számtalan kérdés lehet.

Mentés: igen, célszoftverrel (például Veeam), nem iSCSI LUN-ra (bár arra is lehetne, ha például egy fizikai géppel szeretnél néha szalagos mentést készíteni), hanem iSCSI-vel egy LUN-ról például azért, mert a mentést végző VM-et futtató ESXi nem fér hozzá ahhoz a VMFS-hez, amin a mentendő VM-ek vannak.

iSCSI targetet bármiből tudsz csinálni, amin van linux. Bár tesztelheted az tény, de értelmét nem látom, mert az iSCSI eléggé jól körülhatárolt szabvány. Kb. olyan ez, mintha csinálnál egy virtuális gépet azért, hogy tesztelj egy IMAP fiókot - lehetséges, csak fölösleges.

A mentésnek már inkább lehet jelentőssége, bár ezt "iSCSI-vel egy LUN-ról például azért, mert a mentést végző VM-et futtató ESXi nem fér hozzá ahhoz a VMFS-hez, amin a mentendő VM-ek vannak." ilyenkor hálózati share-rel illik megoldani, mert nem biztos, hogy iSCSI-n osztott FS van, amit konzisztensen olvasol - vagy másik opció, hogy nem jól értem, amit írsz :)
--
PtY - www.onlinedemo.hu

Te találkoztál X esettel életed során, de ezenkívül van még nagyon sok egyéb lehetséges eset, sőt.

Nagyjából tudom, hogy mi az iSCSI, használom egy ideje, de ha már az IMAP fióknál vagyunk: például tesztelni szeretnéd, hogy milyen IMAP szervert használjál. Gondolom egyetértünk abban, hogy ahány IMAP kiszolgáló, annyi féle, mindegyik az elég jól körülhatárolható IMAP protokollt használja. Szerintem had döntse el az, hogy felesleges-e tesztelni egy szoftveres iSCSI kezdeményező megoldást vagy sem, akinek éppen ilyen megoldásra van szüksége (avagy melyik tetsszen neki jobban: Windows, Linux, netán valami egyéb).

Mentés: biztosan nem érted jól, mert elképzeltél valamit gondolkodás nélkül, holott teljesen másról van szó. Kicsit összetett a mondat, tény, de mivel a szituáció is összetett, nem tudom leírni egy szóban. Ha a VM-ek VMFS-esen vannak, akkor ahhoz a LUN-hoz hozzá tudok férni iSCSI-vel, remélem, ebben egyetértünk. Innentől kezdve nem tudom, hogy miért akarnék bármit hálózaton megosztani (gondolom fájl, nem pedig blokk szintű megosztásra gondoltál; egyébként a kérdéses tároló csak blokk szinten tud megosztani, remélem ez nem túl meglepő, ilyen is van a piacon) és miért lehetnek konzisztencia problémáim. Az is lehet, hogy a Veeam-et nem ismered (és úgy általában a VM szintű mentési technológiákat), de emiatt ne engem nézz bohócnak, magadat pedig királynak... :-)

Az első kérdésben ízlések és pofonok, én ilyesmit nem ESX alatt kreált VM-ben tesztelnék, az zicher.
A második dologban az nem volt tiszta az előző HSz-edben, hogy ki az initiator, és ki a target. Így már értem, hogy mire gondolsz, azonban így konzisztens mentést futó VM-ről nem csinálsz iSCSI alól, főleg, ha adatbázis van rajta - igaz, ez nem volt kitétel. A Veeam-et valóban nem ismerem, a VM szintű mentési technológiákból jópárat igen, még ha nem is mindent ESX vonatkozással - de melyik is szerepel az ingyenes ESXi-ben? Ugye egyik sem, nyugtass meg...
És nem néztelek bohócnak, sem magamat királynak. Ha így érezted, akkor sajnálom.
--
PtY - www.onlinedemo.hu

iSCSI kezdeményező teszt: akkor hol tesztelnél első körben alap funkcionalitást, működik-e, mi kell hozzá, érdemes-e szívni?

Miért nem lehet konzisztens mentést csinálni iSCSI alól? A konzisztencia egy dolog, hogy min fut a VM egy másik dolog. Mentéshez készül egy pillanatkép, annak kell konzisztens állapotot tartalmaznia, de az mindegy, hogy ez az állapot min van tárolva.
Egyik normális mentési megoldás sem fut ingyenes ESXi alatt, ez tény (ellenben Essentials csomagon igen ;-) ), de itt a kiindulás az volt, hogy lehet/célszerű/szükséges iSCSI kezdeményezőt VM-ben használni (mellesleg jelen esetben akár ingyenes ESXi-n is lehetne futtatni a mentő VM-et, nincs jelentősége).
Értelmezésem szerint onnan indult ez a téma, hogy a VM-ben az "initiator" fut és erre mikor lehet egyáltalán szükség, mert feleslegesnek tűnik, tehát a "target" szerepkör nem merült fel.

Ha iSCSI-t akarnék tesztelni, csinálnék a desktopon 1-2 virtualboxos vm-et ahelyett, hogy ESXszel vacakolnél.
Igen, a terget vm esetén nem merült fel, csak azt nem volt világos, hogy mi a target (értsd: külső eszköz - pl. vmi storage).

Ha mentéskor készül pillanatkép, az a diskről készül, és azt mented le. Adatbázis esetén lehetnek a memóriában olyasmik, amiket ha nem mentesz, az egész adatbázis elhasalhat, de legalábbis komoly adatvesztést okozhat.
Ehhez minimum egy agent kell, ami olyan állapotba hozza a db-t, hogy konzisztensen menthető diskről, azonban, ha már van ilyened, vélhetően nem az iSCSI-vel vacakolsz, hanem az agenten keresztül csinálsz mentést - így értettem a konzisztenciát.

--
PtY - www.onlinedemo.hu

Nekem egyszerűbb ESX-en "vacakolni", mint a desktopomat terhelni...

Pillanatkép: nem tudom, miért gondolod, hogy ezekkel újat mondasz nekem. Nem adatbázis esetén is célszerű/kell elcsendesíteni, erre megvannak a szükséges keretrendszerek. Kulcsszavak: VMware Tools, quiescing, VSS, pre-freeze-script, post-thaw-script.
Nem is kell iSCSI-vel vacakolni (elég egyszer beállítani, de általában még erre sincs szükség) ahhoz, hogy ez az egész működjön, inkább javaslom, hogy nézz utána a VM szintű mentéseknek, utána térjünk vissza a témára, leírásod alapján sok mindenről nem tudsz :-) http://www.veeam.com/vm-backup-recovery-replication-software.html (más is így működik alapvetően - beleérve a VMware által csomagolt Avamar alapú cuccot -, de ez a legjobb az összes közül)

Leírásom alapján arról beszélek, amiről a topik szól: ingyenes ESXi vs. iSCSI és a backup - ez utóbbit már Te hoztad ide.
Lehetne felsorolni végtelen sok fizetős variációt mindezek ellenében, csak épp nem arról van szó.
Amúgy valóban kíváncsi lennék arra, hogy hogyan mentenél le konzisztensen egy vm-et, amihez a backup VM-ről nem férsz hozzá, csak iSCSI-n a vmfs kötethez, de nem használsz fizetős backup terméket/licencet.
Ha ezt véghez tudod vinni, akkor elismerem a létjogosultságát annak, amiről írsz.
--
PtY - www.onlinedemo.hu

Az alfelvetés az volt, totálisan értelmetlen dolog VM-ből iSCSI kötethez kapcsolódni (függetlenül attól, hogy fizetős vagy ingyenes ESXi-ről van szó), erre írtam példákat, hogy igen, lehet és van rá igény.
De ha tényleg az ingyenes kapcsán lett volna érdekes számodra, akkor korábban is jelezhetted volna akkor, mikor említettem a Veeamet (ingyenes ESXi nem menthető "normális" szoftverrel). És tényleg nem értem, hogy ez elviekben miért annyira lényeges, hogy fizetősből vagy sem, vannak egyéb esetek, amikor ingyenes alatt futó VM-ből szeretne az ember iSCSI kötetet elérni.

A https://communities.vmware.com/docs/DOC-8760 (https://github.com/lamw/ghettoVCB/wiki) elvileg ingyeneset is tud menteni (még nem volt szükségem rá, így nem tudom személyes tapasztalattal alátámasztani, hogy tényleg működik-e a pillanatkép), van VM_SNAPSHOT_QUIESCE=0 opció, viszont itt nem nyúl az iSCSI-hez (ellenben a http://code.google.com/p/vmfs/ segítségével meg lehetne oldani, hogy ingyenesen is iSCSI-ről legyen kiolvasva a VM, leszedve a terhelést az ESXi-ről). Tehát akár ingyenes alatt is izgalmas lehet a dolog (sőt, talán még izgalmasabb, ha az egyetlen ingyenes ESXi-n kívül nincs más, mint egy távoli NAS, amire menteni kellene...)

Teljesen igazad van, az ingyenességgel kapcsolatban, ám...
Ha félretesszük ezt a kitételt, akkor sem értem, hogyan éred el annál a VM-nél, amit nem érsz el másként, csak iSCSI-n, hogy konzisztens állapotba kerüljön a vdiskjein az adattartalom.
Mert - ha nem tévedek - pont ez volt az érved az iSCSI létjogosultságát tekintve: nem éred el másként.
De ha nem éred el másként, akkor hiába van rajta vmtools, avval sem tudsz kommunikálni, nem tudsz neki mondani snapshotot, suspendet, semmit. Mindegy, hogy ingyenes a módszered, vagy sem, ha csak iSCSI-n keresztül férsz hozzá, és a gép fut, a backupod sok esetben használhatatlan lesz.
--
PtY - www.onlinedemo.hu

Nem tudom, hogy miből következtetted azt, hogy sem a vCenter, sem az ESXi nem érhető el, ezt írtam: "a mentést végző VM-et futtató ESXi nem fér hozzá ahhoz a VMFS-hez, amin a mentendő VM-ek vannak".
Azért ahhoz nagyon elvetemültnek kell lenni, hogy blokk szinten mentsen valaki az operációs rendszert is megkerülve, mégiscsak király-bolond effektus van...

Ha már itt tartunk, akkor megkérdezem: milyen módon mentettél már virtuális gépet (VM szinten, azaz nem az operációs rendszeren futó alkalmazással)?

Köszönöm a hasznos tanácsot az internet praktikumára vonatkozóan, ezt már korábban javasoltam Neked, örülök, hogy ennyire megtetszett, bár úgy tűnik még nem volt időd megfogadni.

Itt nem arról van szó, hogy én mit ismerek és mit nem, "enterspájz szemüveg vagy sem", hanem arról van szó, hogy korlátozott tapasztalatoddal tettél egy magabiztos állítást (VM-ből haszontalan dolog iSCSI-t használni), amire én írtam ellenpéldákat, melyből kiragadtál egyet (mentés és iSCSI) nagy mellénnyel, amit egyáltalán nem értettél meg, félreértés és hasonló frázisokkal takaróztál. Ezzel alapvetően nincs bajom - magán ügyed -, de azt nehezen tolerálom, ha valaki tudatlanságból bolondnak néz (tudod, Te pedig a király...).

Ha tudtad volna, hogy a vStorage API-n (korábban VCB) keresztül miként mennek a mentések, akkor nem jöttél volna olyannal, hogy mit akarom én közvetlenül turkálni az iSCSI kötetet; itt nincs mit félreérteni. Pedig ez egy meglehetősen alap dolog, nem is enterspájz, már az olcsóbb "semmire se való" Essentials csomag is tudja.

Ami a proxmox-ot illeti: biztos jó valamire, látomásból ismertem már, de amíg lehet inkább a bevált eszköztárat használom. (egyébként a proxmox pláne nem illik ehhez a témához, ha már annyira szőrszál hasogatjuk, hogy ingyenes ESXi-ről volt szó...)

Az, hogy ki kit néz kinek, fenti írásodból is tökéletesen világos, nem kel ragozni - mivel semmi olyat nem írtam, amire célzol, ellentétben Veled - no comment.

Azt, hogy VM-ből haszontalan dolog iSCSI-t használni, még mindig tartom - igen, elvetemült példákat lehet rá találni nyilván, csak nem érdemes, mert nem olyan terület, ami általánosítható. Főleg azért nem, mert fentebb konkrétan a 2T korlát átlépésére írták, mint példa, és én erre reagáltam - de ne is kanyarodjunk vissza az eredeti felvetéshez, mert még a végén nem lesz igazad, és ezt nem szeretném :)

Ami a proxmoxot illeti, ne is használd, mert még a végén megtérsz :)
És tudom, hogy ESXi-ről volt szó, viszont azt kérted, hogy válaszoljak a kérdésedre, innentől meg releváns.

Egyébként ESX 3.5 alatt is lehet csinálni backupot pusztán snapshot és OS által szállított toolokkal, a legalapabb csomagban, amiben akkor még nem volt semmiféle vmbackup feature. De ezt már nem is mesélem el, mert még a végén megint nem Neked lesz igazad, és megint én leszek az, akinek hiányosak az ismeretei/tapasztalatai.

Meghagylak ebben a hitben, jó helyen vagy Te ott :)
--
PtY - www.onlinedemo.hu

Akkor kanyarodjunk az elejére, itt indult a dolog (igaz, nem nekem címezted): "Áruld már el, ha ilyen roppant okos vagy, hány helyen adnál egy VM-nek iSCSI-t, virtuális eth-n? Mesélj róla, mert érdekel!"

Ez eléggé általános megfogalmazása annak, hogy eretnek, aki VM-ből használ iSCSI-t. Nincs szó semmiféle 2TB átlépésről, ingyenes akármicsodáról, pusztán egy használati módot temetsz el általánosan, hatalmas mellénnyel.

Sehol nem írtam, hogy általánosítható területről van szó, ami mindig mindenkinek kell, de soroltam néhány esetet, ahol igenis használatos lehet. Erre Te elkezdesz nekem okoskodni adatkonzisztenciáról - ami nyilván jogos, de eléggé alapvető és magától értetődő.
Nem igazán értem, hogy egy ilyen megoldás mitől elvetemült: attól, hogy Neked nincs rá szükséged? Mi konkrétan produktív környezetekben használunk ilyet. Nem azért, mert így szeretjük, hanem azért, mert nincs más megoldás (illetve lenne, de nem érné meg az ügyfélnek).
Ekkora erővel bármi, amit Te nem használsz, az elvetemült?

"Ami a proxmoxot illeti, ne is használd, mert még a végén megtérsz :)" - érdekes hozzáállás. Mivel előhoztad a proxmoxot, ezek alapján mégsem vagy képben vSphere mentések terén.

Persze, hogy lehetett olyat 3.5-ben, sőt: most is lehet (lásd ghettovcb.sh). Egyébként 3.5-ben volt már VCB, ami szintén indukálhatott iSCSI-t VM-ben... De inkább meséld el kérlek, kiváncsi lennék VM mentési kalandjaidra, én nyitott vagyok technológiákra, megoldásokra. Eddig nem sok konkrétumot említettél.

De ha már a proxmoxnál tartunk, gyakorlati kérdésem is lenne: van más mód a konzisztenciára, mint memória tartalmat menteni (vagy leállítani a gépet)? Például lehet így replikálni egy VM-et? Ha egy VM-ben 8GB RAM van, akkor az effektív adatváltozáson kívül ezt a 8GB-ot is mindig le kell menteni vagy optimalizál valahogyan? Nem tart túl sokáig, amíg kiírja a 8GB RAM tartalmat? Ha több VM van, akkor ez nem fogja meg nagyon a tárolót?
(a http://pve.proxmox.com/wiki/Vzdump_manual eléggé felületes, nem tér ki arra, hogy mitől lesz konzisztens a pillanatkép, azaz mi történik a VM memória tartalmával, memória mentést sem említ)
Replikálni lehet? Inkrementális mentést?

Nem bonyolítanám túl, mert fölösleges.

1-2 bek. - Igen, ha megnézed, hogy honnan indult az egész, rájössz, hogy mire írtam ezt: a felvetés az volt, hogy VM-nek 2T korlát mellett adhatunk akár 8T-s iSCSI-t, és nem lesz 2T korlát - igen, működik, de csak emiatt elég horror workaround.

3 bek. - A mentéssel kapcsolatos megoldásodat elfogadtam, bár he mentő alkalmazással magát a VM-et elérem az API-n/vmtoolson keresztül megszólítva, miért kellene a vdisket iSCSI-ról menteni, mert akkor a fájlrendszerhez is hozzá lehet férni.

4 bek. - A két dolog nem függ össze. Ha képben vagyok, nem beszélhetek a proxmoxról? Érdekes következtetés.

5 bek. - címszavakban: suspend-snapshot-resume sima cp, majd snapsot törlés. Tesztelve mysql-lel, nyitott sql sessionben adatbevitel commit nélkül. Backupból csináltunk új VM-et, indításkor (ami egy resume volt) lefuttattuk a commitot, és az adat bekerült a db-be, amit a backup előtt adtunk ki. Igen, nem volt a mysql-en autocommit.

6. bek - Tudtommal külön célszoftver nélkül nincs. Replikálni lehet, a backupból új vm készíthető - sőt, ha jól tudom, csak ez a mód van - vagy a mentésben lévő image-ek visszamásolása kézzel. Inkrementális mentés nincs. Nyilván nem tud mindent ez a backup (pl. inkrementálás, priorizálás, stb.), ellenben legalább van működő backup annak ellenére, hogy más ingyenes termékben nincs. És ez a HyperV-re is vonatkozik.

--
PtY - www.onlinedemo.hu

1-2: Igen, viszonylag horror megoldás, de ez nem az egyedüli ilyen eset, a 62TB-os korláttal is marad létjogosultsága a VM-ben iSCSI-nek (például ha valakinek legalább 63TB-nyi adat kell egybefüggően... ;-) )

3: A mentési preferenciák vSphere alatt adatelérés szempontjából:
- a mentés VM-ben fut, a mentendő VM-ek VMDK-i becsatolásra kerülnek ebbe a VM-be, innentől kezdve a feladat kvázi egyszerű: újonnan felvett lemez tartalmát kell lementeni; ez egyszerű, mert csak ESX szinten kell zónázással és hasonlókkal foglalkozni, a mentés úgymond automatikusan működik
- a mentés akár fizikai, akár virtuális gépből fut, közvetlenül a SAN-ra csatlakozva, a VMFS-t olvasva (sajnos VM-ből nem oldható meg az FC ilyen esetben)
Ennek a két megoldásnak az a lényege/előnye még a VCB-beli időktől kezdődően, hogy a mentendő adattömegnek ne kelljen átmásznia a LAN-on is (terhelés és ne lassítson, ha gyorsabban is tudna közlekedni az adat) + a mentendő VM-et futtató ESX(i)-t se terhelje feleslegesen.
Ha ezek valami miatt nem működnek, akkor jön az utolsó:
- ESXi-n keresztül van leszívva az adat; erre szerencsére nem nagyon van szükség
Illetve ha ingyenes ESXi van, akkor maradnak a barkács megoldások.

4: A 2014-es választásokról is lehet beszélni, de annak még kevésbé van az egészhez köze.

6: esxi + ghettovcb.sh, többit nem tudom.

Backupnál pont ezért szoktam nagy méretű vm-eket csak egyszer menteni kompletten. Legközelebb csak akkor, ha valami szoftverkomponens jelentősen változik - pl. update-ek.
Ezt követően csak az adattömeg az, amit mentek, mert a komplett gép mentésének nem sok értelme lenne - időben.
--
PtY - www.onlinedemo.hu

De ha nincs ilyen korlát, akkor sokkal egyszerűbb mindig az egészet VM-et menteni, a visszaállításnál pedig kb 0 perc vakarózás van. Ráadásul nincs szükség 2 mentési infrastruktúrára, minden teljesen egységesen kezelhető (kivételek természetesen bármikor lehetnek, de az más történet és kevés van).

Igen, az a kulcsszó, és pont az a lényeg, hogy normális rendszerrel mennyivel kevesebb ősz hajszálat szed össze az ember abból adódóan, hogy kevesebbet kell faragni. Ettől függetlenül a vSphere mentés így működik (jól), emiatt lehet szükség olyanra, hogy a VM-ből fusson az iSCSI.

Eddig nem fordult elő, hogy ne tudd ingyenesen kezelni az ingyenes verzióban elérhető funkciókat. Erről szólt ez a topic, hogy ez egy értelmetlen helyzet. Legyenek akkor ezek a feature-ök fizetős verzióban elérhetők, de igy, hogy az ingyenesben is elérhető, de kezelni nem tudod az nevetséges.

Nem az a kérdés, hogy milyen üzleti döntés lehet emögött, jó nagy baromság, mert inkább átállok másik ingyenes rendszerre ezeken a helyeken, mivel egyre nagyobb a különbség amit a vmware nem tud az ingyenes verzióban, mig pl. a hyper-v tud.

De mindegy, kiderült, hogy ez a helyzet, nem nálam van a probléma.

Nem a vastag kliensen van a hangsúly. Ha nem akarják tovább fejleszteni, mert másik fajta management eszközt fejlesztenek, semmi probléma, akkor adják hozzá a webes klienst. De az, hogy a régi klienst kinyirják, az újat viszont csak pénzért adják az már nem OK. Ill. innentől lássuk be, hogy oda jutunk, hogy nincs használható ingyenes esxi. Abból pedig nagy bukta lesz nekik, mivel a konkurencia gőzerővel erősödik, van amiben le is hagyta őket, ingyen. Nyilván azért adták eddig az esxi-t ingyen, hogy szépen rászokjanak az emberek és ha kinövik, komolyabb igényeik lesznek, akkor a fizetősre váltással egyidőben, minimális energiabefektetéssel átállhatnak a fullos termékre. Ha viszont az ingyenes termék arra sem képes, hogy a memória- vagy hdd méretet beállitsa egy VM-en, akkor az a termék használhatatlanná válik és akik eddig az ingyenest használták átmennek másik termékre. Sértődni nem a userek fognak, hanem a vmware fog meglepődni, ha ezt nem látja be.

( zrubi v | 2013. 09. 30., h – 09:28 )

Hú vazze. mega LOL

Átolvasva a hozzászólásokat, szerintem:

Használj Hyper-v-t. Meg 62TB-os diszkeket.... Mert megérdemled. Ja meg mert onnantól egy másik forumon tudod megbeszélni a tutit az ottani hyper-v szekértőkkel....

szerintem.

--
zrubi.hu

De hogy konstruktív is legyek:

A VMware már régóta szembe pisál a széllel... vagy csak mi nem tudjuk merre fúj.

Íme az eredeti kérdésre a válasz - by VMware hivatalos dokumentáció:


Caution

If you update the vCenter Server appliance to hardware version 10, you cannot edit the virtual machine settings for the appliance using the vSphere Client. This might cause difficulties in managing the vCenter Server Appliance, because you cannot use the vSphere Web Client to connect directly to the host on which the vCenter Server Appliance resides to manage it. Do not upgrade the vCenter Server Appliance to hardware version 10.

forrás:
http://pubs.vmware.com/vsphere-55/topic/com.vmware.vsphere.install.doc/…

* a fenti közlésben a "vCenter Server Appliance" tetszőlegesen kicserélhető minden egyéb más, nem v10-es virtuális hardverrel rendelkező cuccra.

Saját szavakkal leírva a helyzetet:
A régi (windows-os) kliens már az 5.1 fícsöreit sem tudja (pl. SSO adminisztráció).
Hivatalosan csak az 5.0-val bezárólag használható teljes értékű admin kliensnek.
Helyette van ugye a web client, ami egy flash alapú foshalmaz - és csak vCenter serverrel együtt használható (ugyanis annak a része)

Ettől függetlenül a v10-ben megjelent csodaszép maximumok messze elrugaszkodnak a valós igényektől. Ezek kizárólag marketing célokat szolgálnak - csak úgy mint az MS szarai termékei esetében.

Aki mégis úgy érzi, hogy neki 64 vCPU, 1TB RAM, és 62 TB vmdk szükséges egy vm-be, az valahol nagyon elrontotta a virtuális környezete tervezését....

--
zrubi.hu

Persze-persze, az is hülye, aki vGPU-t szeretne valamelyik vm-jében, netán sima vga gyorsitást linuxon, netán az új SATA vezérlőre van szüksége.

Egy 30 fős kisvállalatnál mekkora egybefüggő tárterületet engedélyezel, csak a miheztartás végett?

Persze tudom, aki nem a VM-ben akarja összegányolni egybefüggő tárterületté a szanaszét szabdalt vmdk-kat, az is hülye.

Az meg, hogy az 5.1-esben nem tudott SSO-t állitani a windows-os kliens a kutyát sem érdekelte, mert legalább az alapfunkciók működtek, mostantól viszont az sem.

Az olyan demagóg baromságot meg hagyjuk is, hogy a 2 TB után nálad nyilván 62 TB jön, a kettő között nincs semmi, igény sem lehet rá, sem a 32 GB vs 1TB közötti memóriaméretre. Akinek mégis van ilyen elvetemült, perverz igénye, az csakis "nagyon elronthatta a virtuális környezete tervezését...."

Éljen a széles látókör, vagy csak a beindult gyomorideg, hogy MS termék is meg lett pozitivan emlitve.

Köszi, nincs gyomorideg :)

Az elrontott tervezést viszont továbbra is fenntartom... csak néhány példa ami elsőre nem feltétlenül jön elő:

- ha túl sok menóriát adsz egy VM-nek, akkor igan hamar elérsz ahhoz a ponthoz, hogy gyakorlatilag nem lehet vmotion-nal mozgatni.
- ugyan ez igaz a vmdk-k esetén a storage vmotion-ra.
- ha menteni szeretnéd a sok TB-os vmdk-kat akkor is igen sok problémába fogsz ütközni, (kezdve ott, hogy sok esetben is nem lesz mire kiírni azokat)

- ha majd később növelni kell diszkterületet egy VM alatt, akkor máris nem felesleges hülyeség az LVM (vagy a win-es megfelelője)

- snapshotok használata esetén egész egyszerűen tökönlövöd a storage-et egyetlen kattintással - ha sok TB-os diszkjeid vannak...

- erőforrás optimalizáció (DRS) tekintetében is nagyon nem mindegy, hogy mekkora egy 'egység' (VM) az adott ESX-en. (minél kisebb egy VM ugyani, annál dinamikusabban kezelhető)

- HA esetén szintén igen nagy szívás az extrém VM-ek kezelése...

Persze, olyan esetben ahol "mindent" ingyenes ESXi-vel próbálnak okosban megoldani, ott ezekre a nagyjából ismerem a válaszokat...

--
zrubi.hu

"ha túl sok menóriát adsz egy VM-nek, akkor igan hamar elérsz ahhoz a ponthoz, hogy gyakorlatilag nem lehet vmotion-nal mozgatni."

Ez tényleg nap mint nap előfordul egy az ingyenes esxi-n vcenter nélkül, amiről ugye a topic szól.

"ugyan ez igaz a vmdk-k esetén a storage vmotion-ra."

Ez meg a másik, ami állandóan probléma.

"ha menteni szeretnéd a sok TB-os vmdk-kat akkor is igen sok problémába fogsz ütközni, (kezdve ott, hogy sok esetben is nem lesz mire kiírni azokat)"

Nyilván erre se gondol senki előre, a backup rendszerek nem tudnak több médiára szabdalni. (komolyan van valaki, aki a vmdk-kat copy-zza le backupként és addig megállitja a gépet?)

" ha majd később növelni kell diszkterületet egy VM alatt, akkor máris nem felesleges hülyeség az LVM (vagy a win-es megfelelője)"

Sajnos ez sem igaz, semmi szükség win alatt pl dinamikus lemezre és JBOD-os bohóckodásra VM szintjén. Simán megnövelem a VM diskjét, majd kiterjesztem a particiót 2 kattintással, beépitett feature-ökkel, online.

"snapshotok használata esetén egész egyszerűen tökönlövöd a storage-et egyetlen kattintással - ha sok TB-os diszkjeid vannak..."

Eddig is sok TB-os volume-ok voltak a storage-on, csak a klienseknek adott vmdk-kat kellett 2 TB-os tördelni, semmilyen probléma nem volt.

"erőforrás optimalizáció (DRS) tekintetében is nagyon nem mindegy..."

jaj

"HA esetén szintén igen nagy szívás..."

jaj

"Persze, olyan esetben ahol "mindent" ingyenes ESXi-vel próbálnak okosban megoldani, ott ezekre a nagyjából ismerem a válaszokat..."

Ezt is elég nehéz értelmezni. Olyan helyen használok ingyenes esxi-t, ahova (eddig) tökéletesen megfelelt. Ahova nem felelt meg, oda megvettük a license-et hozzá, vagy hyper-v-n üzemelünk.

Majdnem ilyennel kerültem közeli kapcsolatba úgy öt éve.
Csak úgy voltam vele, hogy szívességből, "hálából" senki se akarjon munkát adni. A srác (potenciális munkaadó) azóta nem áll szóba velem. :(
Te használod? Vagy csak olvastál róla?

Aki tudja, csinálja, aki nem tudja, tanítja... Hm... igazgatónak talán még jó lennék. :)

Élesben még nem használtam HA módban, csak teszteltük. Igen, kicsit szivatós, amikor a webfelületen 'látszólag' rendben van, csak épp nem működik, és rúgni kell rajta egyet, de nem agyhalál.
Ár/érték viszonylatban zseniális termék, ha vannak is gyerekbetegségei, hát na puff...
--
PtY - www.onlinedemo.hu

Úgy, hogy a volume groupot látja mindkét host, és látja a volume-ok státuszát is (foglalt/nem). Ha az egyik host elengedi, akkor a másik átveszi. Tehát egy VG-n belül meglehet, hogy az egyik LV-t az A, a másik LV-t a B, a harmadikat meg akár a C host (és így tovább) használja.
És nincs +1 FS réteg sem, mint VMware/NFS esetén.
Nem értek ilyen szinten az LVM-hez, de ezt írták, és meggyőztek :)
Mindjárt belinkelem a threadet.
--
PtY - www.onlinedemo.hu