A VMware beperelte a Siemens USA-t, mert az állítólag több szoftverét használja, mint amit licencelt

Virtualizáció

A Broadcom tulajdonában álló VMware pert indított a Siemens amerikai leányvállalata ellen, azt állítva, hogy a vállalat több ezer példányban használt jogosulatlanul VMware szoftvereket. A két cég között 2012 óta fennálló licencmegállapodás alapján a Siemens 2024 szeptemberében karbantartási és támogatási szolgáltatásokat kért a VMware-től. A Siemens által benyújtott lista azonban számos olyan VMware terméket tartalmazott, amelyekre a VMware-nek nem volt vásárlási nyilvántartása.

A VMware szerint a Siemens később megpróbálta visszavonni ezt a listát, és egy új, a VMware nyilvántartásaival jobban egyező listát nyújtott be. A VMware állítása szerint a Siemens nem adott kielégítő magyarázatot a korábbi lista pontatlanságára.​

A VMware azt is kifogásolja, hogy a Siemens nem engedélyezte a szoftverhasználatának auditálását, amit más ügyfelek általában együttműködően elfogadnak.

Részletek itt és itt.

( trey | 2025. 03. 27., cs – 09:28 )

Ezek után nem is csodálom, hogy a Broadcom beszigorított licenc fronton.

trey @ gépház

Nagyon közelire. Hosszas alkudozások vége horribilis áremelés és teljes üzleti kapcsolat megszakítása lett. Így a broadcom ügyvédei némi százalékért cserébe találtak valami listát ami alapján most megpróbálnak mégis pénzhez jutni. A Siemens software licence management keretein belül, legalábbis Európában ilyen banális hibát lehetetlen elkövetni.

találtak valami listát ami alapján most megpróbálnak mégis pénzhez jutni.

Ezt a listát a Siemens adta át nekik, nem?
Az hogyan lehet hogy a megvásárolt licenszek mennyisége és a Siemens által átadott lista között jelentős különbség volt?

vmware Workstation PRO licenszben példáúl 3.000 darab a differencia, Siemens 19573-t tartott számon, a vmware 16532 - azért 3000 destktop-ról elfelejtkezni.. :)

Mármint azért, hogy ha igaz a hír, a Siemens USA évekig meglopta a VMware-t és az most ezért nem örül? Én inkább ezt valószínűsítem: a Broadcom megvette a VMware-t, mint jó gazda csinált egy felmérést, hogy kik, miért fizetnek, majd rájöttek, hogy a keményen lopják a szoftvereiket. Mivel viszont akarják látni a befektetésüket - for-profit cégek lennének, vagy mi - elkezdték érvényesíteni a jogos igényeiket.

trey @ gépház

Ha igaz a hír. 

Ha nem, akkor csak hab a tortán az eset, ugyanis a Broadcom már tqavaly bebizonyította, alkalmatlan megbízható üzleti félnek, nem is érit, mi az. Lásd az AT&T vs Broadcom pert,  ahol ugyebár a Broadcom nem akarta betartani a szerződés rá vonatkozó support kötelezettség részét laza 75 000 VM -re.  Ebbn az ügyben összebvissza hazudozott a Broadcom, szóval kellő óvatóssággal kezelem a mostani állításaikat is. 

kerdes, hogy tud-e kuldeni? vagy mindenki kirakja a netre az osszes vmware hostjat? mert amerre en mozgok ott tuti nem latnak ki a netre.

masreszt lehet futtatnak parat tesztelesi celbol, vagy hidegtartalek vasakon, vagy pl backup visszallitas tesztre stb is.

az a 3000 kliens licensz hiany is fura. lehet ugy voltak vele, hogy van 6000 db kliensunk, de ugyse fogja mindenki hasznalni, eleg a felere megvenni. virusirtoknal is szoktak ilyen nagyvonaluan szamolni, hogy annyit vesznek ahany foallasu dolgozo van, de attol meg pc lehet tobb is, meg lehetnek bedolgozo kulsosok, alvallalkozok akiknek az IT ugyanugy felrakja.

> jogászokkal előtte ne tárgyaltak volna.

Az AT&T-s per előtt is biztos bementek, a jogászok meg rámondták, hogy "á, hagyd simán megnyerjük" - aztán hoppá, mégse nekik áll a zászló.

Vállalati jogászban akkor se bízz, ha ló legel a sírján. Komolyan. Neki abból van prémiuma, hogy mentül több ügyet vigyen bíróság elé és nyerjen meg. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Neki abból van prémiuma, hogy mentül több ügyet vigyen bíróság elé és nyerjen meg.

Nem hinném, hogy ne lenne legalább egy százalékos KPI ilyenkor. Tök jó, hogy megnyertél öt ügyet az évben, megy a buksisimi, csak az nem mindegy, hogy mondjuk hat ügyet pénzelt a cég, és abból nyertél meg ötöt, vagy hatvanat.

Látatlanban biztosra veszem, hogy a broadcom licensz policy-ja legalább olyan áttekinthető és egyértelmű (gy.k. sem nem áttekinthető, sem nem egyértelmű), mint mondjuk a mikroszofté. Elég nagy bizonyossággal feltételezem, hogy ha a mikroszoft fogná az összes kuncsaftját, és csukott szemmel rábökne közülük 1000-re (legyen közte a legkisebb egyénivállalkozó józsitól kezdve a legnagyobb giga top10 cégig bármelyik), MINDEGYIKNÉL tudná a saját szaros törvényeit úgy értelmezni, hogy abból licensz-sértést hozzon ki. Aki valaha az életében foglalkozott mikroszoft licensszel, kivétel nélkül tud saját személyes példát hozni, hogy megkérdezett egy adott témáról 3 felkent mikroszoft licenszing specialistát, azok pedig 3 különböző választ adtak. Innentől kezdve a licenszing viták nem a fekete-fehér egyértelműségi koordináta-rendszerben mozognak, hanem nagyjából az ügyfél szerint nem sértették meg, a vendor szerint meg igenis megsértették jogi csatározásról szól. Aztán majd a bíró döntést hoz, annak megfelelően h. melyik oldal ügyvédei és jogászai fizették le jobban.

Már megint a terelés ... nem azért indítottak pert, mert nem volt tisztában a licenceléssel, hanem mert miután bevallotta, hogy mennyit használ, mondták neki, hogy nem ennyi van nálunk könyvelve, fizetni kéne, elkezdett maszatolni, majd tagadni a használatot. Ekkor felajánlották nekik, hogy felmérik a használt licencek számát, de ezt nem engedte (vajon miért :D :D :D).

trey @ gépház

Egy cég sem engedné be a vendort kutakodni a belső hálózatába. A Szintézis se engedné be. Hacsak nem a bíróság kötelezi rá őket.

Te is pontosan ismered a 90-es években a BSA ténykedését, aztán meg a mikroszoft ténykedését. Ha önként kitöltötted az emailben kéretlenül küldözgetett ekszeles makrós nyilvántartós fájlt és visszaküldted nekik, azonnal lecsaptak rád mint a farkasok. Azóta az ilyen szoftver auditort a bejáratnál veri agyon minden cég portása. Majd ha a per során azt hozza ki a bíró, hogy be kell ereszteni az auditort, akkor be lesz eresztve.

Ne terelj, nem erről van szó. Arról van szó, hogy önként, pancser módon felnyomták magukat. Utána a szép szónak se engedve nem működtek együtt, hazudoztak. Erre írták, hogy akkor engedjék felmérni. Nyilván, ez már a per előkészítése volt, hivatkozási alap a sunyulásra.

Ráadásul, erősen biztos, hogy a Siemens által leadott lista, amivel felnyomták magukat, már egy erősen kozmetikázott volt, vagyis még annál is többet használtak illegálisan :D

trey @ gépház

Legalább üzemeltetőként ne terelj. Egy szoftver auditor vagy elfogad nyilvántartásokat (de akkor miben jobb, mint amikor most odatették a javított excelt) vagy bele akar nézni minden szerverbe - ekkor viszont kellene neki valami jogi felhatalmazás arra, hogy ezt megtehesse. Márpedig valószínűleg a Siemens licencszerződése alapból nem hatalmazza fel a szoftvergyártót (mert miért is tenné?) hogy bármilyen az ő szoftverükkel üzemeltetett rendszerhez kiküldhessenek egy random Pistikét, aki ki tudja milyen infókat lop ki úgy, hogy valószínűleg nem fog átmenni semmiféle átvilágításon amit a cég esetleg előírna egy ilyen random vadidegen embernek. A Siemens erre rámutatott, a Broadcom meg megsértődött. Gondolom a többi cég, ahol beengedték őket, vagy összeszarta magát a nagy Broadcom-tól, vagy nem tudták, hogy van lehetőségük ezt megtagadni (mert a Broadcom miért is mondaná ezt el).

Még egy ISO audit során se néznek bele konkrétan az üzemeltetett rendszerekbe egyesével, neked kell bemutatnod azt a részét, amit te bemutathatónak gondolsz.

Én se engedtem volna be, meg úgy felelős üzemeltetőként senki. Ha a cég a nyakamba is sózza, akkor is megmondanám neki, hogy ott áll a sarokban, és én mutogatok neki dolgokat, vagy kitakarodik a szerverteremből a picsába, és hoz valami olyan papírt, ami alapján belenézhet dolgokba. Mert ha ebből gond lesz, az én seggemet veszik elő, és nem az övét. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

ekkor viszont kellene neki valami jogi felhatalmazás

Ez a "jogi felhatalmazás" általában egy sajtpapír, amiben a cég illetékes képviselője meghatalmazza a vendort, hogy az meghatalmazzon egy külsős auditort.

Én se engedtem volna be, meg úgy felelős üzemeltetőként senki.

Sőt, én sem, innen indult a per, ugye.

Sőt, én sem, innen indult a per, ugye.

Én igen. Meg valószínűleg minden üzemeltető, akinek nincs vaj a füle mögött. A licencekért nem az üzemeltetés, hanem a cég tulajdonosa felel. Ha hozza a papírt, azt néz meg, amit akar.

Azt meg hagyjuk, hogy nem engedjük be a hypervisor fejlesztőjét, mert "jaj, mit fog csinálni" security aggályok. Nem, hogy root-ja van a rendszeren, hanem az összes rendszer alatt futó hypervisor-ra, ha úgy szeretné :D

Egyetlen okot tudnék, hogy valaki nem engedni be a megfelelő feltételek teljesülése esetén: sundám-bundám mennek a dolgok

trey @ gépház

Én igen. Meg valószínűleg minden üzemeltető, akinek nincs vaj a füle mögött.

Pontosítok: nincs jogosultságom beengedni. Ha hoz igazolást (írásban) attól, akinek van, akkor felőlem a laptopom is áttúrhatja, nem érdekes.

Amúgy nem olyan egyedülálló egy ilyen audit, mint ahogy itt körbeírják sokan.

Pontosítok: nincs jogosultságom beengedni.

Olyan faszságra senki sem gondolt, hogy XY toppantómaci majd jól beengedi. Nem is hiszem, hogy ez a párbeszéd a VMware jogi osztály és a legutolsó Siemens üzemeltetőmaci közt zajlott .... nem is értem, hogy hogyan jutottunk ide.

trey @ gépház

Azóta az ilyen szoftver auditort a bejáratnál veri agyon minden cég portása.

FALSE

VMware is also upset that Siemens would not allow a software audit and alleges “other more cooperative and forthcoming customers do [this] without objection.”

Akinek rendben vannak a licencei, azok mitől félnének? Hogy rendben találják őket? :D

trey @ gépház

Más, szintén felvásárolt  Broadcom termékkel kapcsolatban láttam, hogy Mennyire geci módon licenszel, alapjaiban változtatva meg a licenszszámítás szabályait. 
 

ezek után meg aztán végképp fontos egy menekülőút a Vmwaretől. 

Neked is. Itt most gyanúkról beszélgetünk, az ártatlanság vélelme meg még az USA-ban is elfogadott kiindulási alap. Majd ha a Broadcom bebizonyította, hogy neki van igaza, vagy a bíróság utasítja a Siemenst a felmérésre, akkor lehet itt bármit nyiltan kijelenteni. Addig ennek az egésznek annyi alapja van, minthogy én mindennap lefekszem Angelina Jolie-val.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Kicsit többről beszélünk, ugyanis itt az az eset forog fent, hogy egy balfasz ügyfél be akarta perelni a VMware-t, mert az nem akart supportot adni olyan szoftverre, amit az agresszor nem vett meg. Ez onnan derült ki, hogy az agresszor felnyomta magát. :D :D :D

Ha nem megy az angol, elolvashatod a magyart:

Az egész ügyet megelőzte, hogy a két cég között 2012 óta fennálló licencmegállapodás, a Master License and Service Agreement (MOLSA) alapján a Siemens próbált egyezségre jutni bizonyos szoftverek kiterjesztett támogatásáról és karbantartásáról tavaly szeptemberben. A cég elkészítette az általa használt VMware-szoftverek listáját, ami problémásnak bizonyult, mert a VMware-termékek telepítései messze meghaladták a Siemens által ténylegesen megvásárolt licencek számát.

A Siemens eleinte ragaszkodott ahhoz, hogy a lista korrekt, és követelte a VMware-től annak elfogadását, továbbá azzal is fenyegetőzött, hogy bepereli a virtualizációs óriást, ha nem nyújt számára támogatási szolgáltatásokat a felsorolt ​​termékekhez. Később a cég megváltoztatta álláspontját, és egy, a VMware nyilvántartásával jobban egyező, felülvizsgált listát nyújtott be, miközben nem szolgáltatott magyarázatot a korábban benyújtott dokumentum állítólagos pontatlanságával kapcsolatban.

Hogyan lesz a "szegény Siemens"-ből egy buta fasz agresszor, amelyik a saját picsájába iktatta a lófaszt? Hát így ^

Kérlek hanyagolj a "jaj szegényt betámadta a VMware" faszságokkal!

trey @ gépház

Na, semmi? Mi történt? Visszaütött a VMware? 🍿

Ebben a sztoriban, ha minden úgy volt, ahogy azt a sajtó lehozta, egyetlen céggel nem üzletelnék a jövőben: Siemens USA

Amelyik azzal kezdte, hogy perrel fenyegette meg a beszállítóját a saját szar nyilvántartásán alapuló téveszmék alapján.

trey @ gépház

ártatlanság vélelme

Polgári peres eljárásban nem igazán releváns ez.

akkor lehet itt bármit nyiltan kijelenteni

Szerintem itt ~bármit ki lehet jelenteni néhány Btk-s kivételtől eltekintve. Azt például biztosan, hogy a Siemens állítólag sokkal több licencre kért terméktámogatást, mint amennyit a Broadcom nyilvántartása szerint korábban megvásárolt. A pontos eltérést majd a bíró megállapítja.

A pontos eltérést majd a bíró megállapítja.

Előttem van, hogy a Siemens azóta nem éjt nappallá téve uninstallálja a licencszámból kilógó példányokat. Ugye? Ugye neeem? :D

Szóval, az, hogy mi lesz már a per kiemenetele, majdnem irreleváns. A Siemensnek, ha lopott is, bőven lesz ideje eltüntetni a nyomokat.

Ilyenkor jöhet képbe, hogy van-e a VMware-nek olyan telemetriája, ami felköpi a licencadatokat a gyártójának ...

trey @ gépház

"ártatlanság vélelme" vs. "Polgári peres eljárásban nem igazán releváns ez." - részben igaz, de a polgári jogban ennek elég közeli megfelelője az "aki állít, az bizonyít" elv. Nagyon kevés, külön tételesen rögzített kivétel van ez alól. Egy perben alapból a felperesnél (jelen esetben Broadcom) van a bizonyítási kötelezettség.

Régóta vágyok én, az androidok mezonkincsére már!

( asch v | 2025. 03. 27., cs – 10:59 )

Én ebből csak azt szűröm le, hogy ez a VMWare még a mamutoknak is túl drága.

Nem igy fogalmaznám meg, egy nagy cégnél mint a Siemens (400k alkalmazottal) valószínűleg olyan 5 ezres nagyságrendben használnak szoftvereket, és hogy ez még izgalmasabb legyen, sorra vásárolnak fel cégeket, szóval azok licenszei is hozzájuk kerülnek. Jó kérdés hogy mennyire jó/valid a nyilvántartásuk, de egy nagy cégnél ez mindig nagyon komoly probléma.

Mi az, hogy nincs? Mi nincs? Nincs ilyen szakma? Nem tudlak követni. De, ok.

Akkor ez ellen milyen kifogása lehetett?

Siemens also “resisted” VMware's attempts to audit the firm and run a script on its systems to figure out how much VMware software Siemens was running, the lawsuit claims.

trey @ gépház

Bruahahahah. Én technikai dologról beszélek, te meg a pénzért remegsz. Hát mi vagy te? Egy CFO? Vegyenek az autógyárak is szar robotokat, mert a KUKA drága?

Milyen bizalmat játszottak el technikai szinten? Én úgy jövök be minden reggel, hogy "Hmm, biztos beszartak a VMware termékek, mer a geci Broadcom megemelte az árait ...."? Vagy mi? :D

trey @ gépház

Öröklicensz helyett előfizetéses lett. A korábbi öröklicensz + hozzá kötelezően megveendő 3 éves support árához képest lett volna 4x-es csak a support díja a következő 3 évre. A supportot csak ahhoz kellett igénybe vennünk, hogy megkérdezzük az új árakat, bár igazából az is viszonteladó volt.

Nem 5000 darab szoftvert, 5000 különböző FAJTA szoftvert :D Egy Siemens-nél egy nagyságrenddel kisebb cégnél simán használnak 500-1000 különböző alkalmazást (desktop alkalmazást, szolgáltatásokat, rendszereket).

Ha meg darabszámokat nézünk akkor a 320 ezres Siemens-nél simán van mondjuk 150-200 ezer office licensz, és ez egyetlen "alkalmazás".

Ez a 3000 kimondva sok, de valójában ez csak a licencek 15%-a. Az lófing, ha hozzávesszük, hogy mennyire mocskos sokat kérnek el _egy_ licencért. Igen, 3000 licenc el tud tűnni véletlenül is, a lopás tényleges szándéka nélkül.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Nem mond már hogy 15 - 20 százalékos hibaarány elfogadható egy szoftvernyilvántartásban - Siemens MR gépek esetén mit szólnál ha a létrejött kép 20 százaléka hibás lenne? Vagy a Combino féke a fékezések 20 százalékában nem működne? :)

Akármerre is marketingeled meg pr-olod a vmware technológia elérte a "cash cow" fázist. 
A broadcom és ügyfelei is felismerték ezt. 

A cash-cow fázis után nincs következő: vége van.

Felőlem egész nyugodtan maradhatsz tagadásban, de lehet jobban jársz ha elkezdesz újat tanulni.

Gábriel Ákos

... Siemens AG revealed that it had downloaded, copied, distributed, and deployed thousands of copies of VMware products for which it had never purchased a license."

:D :D :D

Hát, ha azt mondod, hogy a Siemens szoftverleltára olyan fos, hogy abban ezres nagyságrendű pontatlanságok vannak, akkor nem jósolok nagy jövőt a felelősnek :D

trey @ gépház

Dolgoztam olyan amerikai tulajdonú cégnek, ahol rendszeresen kiadták a feladatot a belsős telecom csapatnak (vagy rosszabb esetben az IT-nak) hogy: itt van egy 100-as vagy 200-as telefonszámmező. Hívogassátok fel mindet egyesével, és kérdezzétek meg ha valaki esetleg felveszi h. hol van helyileg ez a konkrét szám használatban, és kihez tartozik. Mert a cég akkora, hogy szimplán fogalmuk nem volt róla, h. aktuálisan hány (ezer)  telefonszámuk volt ténylegesen használatban, és melyik számmezők nem is tartoztak már hozzájuk, mert az adott telephelyet, gyárat, irodát rég eladták egy másik cégnek. A nyilvántartás meg sosem érte utól a jelenkori állapotot.

És ez még egy kézzel fogható nyilvántartás, a valóságban is létező telefonszámokról. Nem holmi megfoghatatlan vmware vCPU licenszekről, amiket értelmezés és jogászhadsereg kell h. lefordítsa műszaki ember által értelmezhető szabályokra.

Magyar KKV szintet ismerő IT-sek számára elképzelhetetlen egy ilyen helyzet, egyszerűen nem is tudják felfogni, hogy egy nagy cégnél simán megtörténik hogy akkor most megveszünk egy pár ezer! fős céget. Amire ennek a nyilvántartása összefésülésre kerül a központi nyilvántartással az is években mérhető, a folyamatok, vagy az IT rendszerek összeérése meg simán 4-5 év.  

Úgy érted, hogy nem létezik független igazságügyi IT szakértő? Szerinted, ha ezek perre mennek és a bíró elrendeli a szoftverleltárt, akkor a Siemens vagy a VMware embere fogja megcsinálni? Ha a VMware biztos volt a dolgában, akkor a jogászai tanácsára nyilván egy külsős szakértőt küldött volna.

Ne nézzetek már mindenkit ennyire hülyének ...

trey @ gépház

Ebben az esetben a Siemens-nek képesnek kellene lennie hogy igazolja a licenszek megvételét, csak nem mindenféle igazolás nélkül akartak szoftvereket használni? - de nem ez történt hanem küldtek a vmware-nek egy második riportot, amiben már kevesebb szoftver szerepel. 

Csakhogy most volt migráció a broadcomnál a felvásárlás után. Eleve töröltek rengeteg licenszet, amik nyomtalanul eltűntek. 
Olvasni olyat is, hogy fizetős öröklicenszeket is töröltek, mert nem volt hozzá éppen aktív support szerződés. 
Mások már a broadcomtól vett licenszüket nem tudják haszálni. Vagy a botjuk törölte a siteid-t, mert automatizáltan úgy gondolták, hogy nem egy cég.
https://www.reddit.com/r/vmware/comments/1f8pr61/vmware_licenses_gone_s…

Nem dőlt ki semmi, csak be kéne fizeti az árát.

Feltételezem, itt inkább ez van:

Ahogy állítod (biztos képben vagy, elhiszem) a Siemens úgy döntött, hogy vált. A Siemens-nek nem egy-két nap lesz több ezres nagyságrendű hostokon futó virtuális gépek migrálása ingyenes Proxmoxra (lol), hanem akár évekbe is telhet. A VMware meg ezen időre szeretné a pénzét látni, nem hagyni potyázni. :D

🤷‍♂️

trey @ gépház

( gyuri23 | 2025. 03. 27., cs – 13:37 )

Ha a VMware szerint túlhasználják a szoftvereit akkor zseniális megoldás rá a 10x éremelés. Az álmoskönyvek  szerint is ha valaki nem akar fizetni valamiért, emeld magasabbra az árat, akkor egyből fog. Vagy szívasd meg a még fizető ügyfeleid, az még jobb.
Ha lenne egy csöpp eszük, akkor ihletet vehetnének, az online aktiválós, cloud bejelentkezős, stb, megoldásokról. Röhejes, hogy egy ekkora cég nem tudja megoldani, hogy lássa, hol és mennyit használják a szoftvereit.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Rengeteg hazatelefonálás megy át az auditon, ha azt normálisan csinálják (pl. helyi licencszerver, ami összegyűjti belül a licenceket, és csak ő tart kapcsolatot a gyártóval.Ezzel az erővel a Windows se menne át, főleg, hogy mostanában egyes update-ek szeretnek közvetlenül kimenni, hiába van WSUS.

Hát ez az audit 22-es csapdája. Frissítések és cloud, hazatelefonálás nélkül.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Ha megtartják az ügyfélbázis jóval kisebb, de rendesen fizető magját (akik ezt is kifizetik) és közben ezt az ügyfélkört kisebb apparátussal - kevesebb disztribútor, viszonteladó, technikai támogató - el tudják látni, az bőven megérheti anyagilag.

Ugye érzed abból az ügyfélből fakadó problémát, aki vesz 10 licencet, de közben 100x annyit használ valójában és erre igénybe is veszi a technikai támogatást?

trey @ gépház

vesz 10 licencet, de közben 100x annyit használ valójában és erre igénybe is veszi a technikai támogatást?

A VMware-nek nem tűnt fel évekig, hogy a Siemens 10x több termékre kér valóban támogatást, mint amire fizet? Na nemár, ekkora bénák nem lehetnek. Fura, amikor az éves elszámoláskor a Siemensért felelő Key Account Managerek látják a számokat, és nem szólnak, hogy hékás, valami gebasz lehet, mert X licencre az elvárt Y support helyett 10Y support jön be. Vagy a Siemens felé szállított szoftver überbugos, vagy valami más gond van. És ez ment évekig? LOL

Szerintem szimplán annyi történt, hogy műszakibb szemléletű vezetést, befektetői ebitda szemüveges köcsögök vették át.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

( wyx v | 2025. 03. 27., cs – 16:03 )

Ki a sz*rt erdekli a vmware, lassan mar mult lesz...

Nézd, én minden egykori VMware admin frusztrációját megértem, hogy ezentúl kénytelenek lesznek valami fossal szenvedni, mert a munkáltatóik basznak erre költeni. Főleg az olyanokét, akik életükben okádtak a Windowsra, így a Hyper-V kiesett (nekem nem okoz gondot 🤷‍♂️ nem egy rendszert építettem rá), vagy lófaszt se értenek a Linuxhoz 🤷‍♂️.

trey @ gépház

> hogy ezentúl kénytelenek lesznek valami fossal szenvedni,

 

Ezt azert gondold at meg1x. Az a fos mar 20 eve letezik, mondjuk egy XCP/Xen (ami az Amazonnak meg mindig jo) vagy 10 eve a KVM alapu rendszerek, de mostansag mar Openhift/stack is alternativa vagy az opensource KVM operatoros cucc. Gyakorlatilag a Linuxot nem is latod mogottuk, GUI van.

Ugyhogy lehet valogatni, nem ragadunk le az ESXinel, holott egy jo product (volt).

Szerintem ezeket gondold át:

  • a VMware a No. 1. megoldás a virtualizáció terén
  • a VMware erőssége a köré felépült 3rd party támogatások, kiegészítők, az miatt erős
  • a VMware erőssége a dokumentáltsága, hogy kb. mindenhol találsz hozzá infót. Ja, még a HUP-on is! (visszajelzés alapján tudom, hogy HUP postom alapján rakta rendbe cég az elhanyagolt vSphere rendszerét)

+ nekem nem kell magyarázni, VMware mellett mi támogatunk, üzemeltetünk, szállítunk VMware konkurens megoldásokat is, pontosan tisztában vagyunk mindegyik állapotával.

++ vicces a HUP-on olvasni ezeket, ahol rendre azt olvasom, hogy a grafikai világban a Photoshop az első, minden minden más csak rossz utánzat :D

Hallod, szedd le a Photoshop-ot a one trick pony grafikus gépéről, majd bizonygasd neki, hogy a Gimp pont olyan jó lesz neki :D

Ugyhogy lehet valogatni, nem ragadunk le az ESXinel, holott egy jo product (volt).

Persze, hogy lehet. Ahol nincs VMware-re pénz, oda adunk Hyper-V-t, vagy Proxmox-ot stb. Egyiket se azért, mert jobb, vagy legalább olyan jó lenne, mint egy VMware :D

Gyakorlatilag a Linuxot nem is latod mogottuk, GUI van.

Jajaja, a VMware-hez is csak addig "nem kell parancssorban érteni" (kb. egy Linux), amíg kell. Példa: amikor egy cégnél elfogyott a log partíción a lemezterület és megtümmedt az egész, akkor LVM átméretezéssel ezt kb. seperc alatt megoldotta, aki ért hozzá, aki meg nem ... az felhívta azt, aki ért (jelen).

Ugyanez a Proxmox. OpenStack dettó. Dehogynem kell :D

trey @ gépház

> amikor egy cégnél elfogyott a log partíción a lemezterület és megtümmedt az egész

 

Eleg baj az, hogy ilyen elofordul. Elvileg a logrotate, ha jol van konfiguralva ezt kizarja, dehat latod, meg/mar a vmware sem az igazi.  (nagyon keves olyan szitu van, ami annyira tulszemeteli a log-ot, hogy meg a jol bealllitott logrotate sem tudja lekezelni)

Persze ha monitoring nincs, az meg a masik baj, hogy ugyan miert nem vettek eszre idoben.

 

A mai vilagban 70% a Linux alapu szerver rendszerek marketshare-je, igy muszaj ertened a Linuxhoz alapszinten. A Linux nem egy rocket-science, a legegyszerubb es legjobban atlathato (op)rendszer. Nem kell tulmisztifikalni.

Eleg baj az, hogy ilyen elofordul. Elvileg a logrotate, ha jol van konfiguralva ezt kizarja, dehat latod, meg/mar a vmware sem az igazi.

Nem, az a baj, hogy a balfasz, hozzá nem értő elfelejtette elvégezni alapszinten a rendszer konfigját. Ha már a telepítésnél alulbecsülve telepítette a vCenter-t, elfelejtette a historikus adatok megtartását konfiolni és még akkora balfasz is volt, hogy a vCenter levélküldést (bare minimum monitorozás) se állította be. De nem is ez volt a lényeg, hanem az, hogy mindegyikhez kell érteni a motorháztető alatt is.

Nekem szerencsére 25 év Windows (Hyper-V), 25 év Linux (összes többi) tapasztalattal nem okoz ez problémát. Ahogy mondjuk, el tudok vezetni egy Trabantot is, egy Audit, egy Lambót is, egy Tesla-t is, de azért mégis ... ha megkérdezik, hogy melyikkel akarnék huzamosabban járni, az nem a Trabant lenne.

trey @ gépház

> Nem, az a baj, hogy a balfasz, hozzá nem értő elfelejtette elvégezni alapszinten a rendszer konfigját.

 

Hogy egy kicsit megvedjem azt a balf*szt. Ha a deploy endedi, hogy sz*rul telepitsd, akkor az nem csak az admin hivaja. Ilyen nincs (elviekben), hogy betelik az egyik legfontosabb particio es a rendszer megall. Es itt nem a root-rol beszelek.

Itt product-design problema is van. Hozzateszem, eleg regota vagyok a temaban, hogy en is lattam mar karon varjut. De itt _NEM_ mindig az admin a hibas, hanem a f*sul megirt es konfiguralt default programok/beallitasok es design.

Hogyne:

[VMware vCenter - Alarm alarm.HealthStatusChangedAlarm] vmware-syslog status changed from green to yellow

Target: Datacenters 
Stateless event alarm 
 
Alarm Definition: 
([Event alarm expression: Status change]) 
 
Event details: 
vmware-syslog status changed from green to yellow

Közben pedig a rászerelt hangosbemondó 1000-es hangerőn napokig kiabál, hogy mi várható ^^^^^ csak süket fülekre talál.

Pls. ne.

trey @ gépház

Ez egy masszív üzemeltetési / tervezési probléma. De még mindig ott tartunk, hogy ez egy mellékszál/szalmabáb, mert az állításom az volt, hogy legyen az VMware, Proxmox, vagy bármilyen más virtualizációs ökoszisztéma, a parancssorhoz bizony érteni kell. Legyen az Linux, vagy Windows (PowerShell).

Aki meg ezekhez ért, annak nem okoz gondot egyiket, másikat, mindegyiket üzemeltetni, sőt, az se hogy - juj - Linuxra fel kell SSH-zni és ki kell adni 30 parancsot, hogy a "jujdejövőbemutatófasztudjaamit" ne tudja kezelni.

trey @ gépház

> De még mindig ott tartunk, hogy ez egy mellékszál/szalmabáb, mert az állításom az volt, hogy legyen az VMware, Proxmox, vagy bármilyen más virtualizációs ökoszisztéma, a parancssorhoz bizony érteni kell. Legyen az Linux, vagy Windows (PowerShell).

 

Ebben egyetertunk! A mellekszal azert alakult ki, mivel azt is allitottad, hogy a b*lfasz admin stb. stb. Csak megvedtem egy kicsit oket az allitasoddal szemben. de ignoralhatjuk eme mellekszalat, ki lett mar vesezve...

nem akarok (vagy ha elfeljtek) kozbelepni, en azt akarom, hogy a rendszer ne omoljon ossze utana...ez alap lenne a szoftvereknel...ha 10 VM helyett 100 logozik az adott mappaba (es altalaban itt szokott lenni a gond), akkor 10x gyorsabban rotalok es persze torlok is...ennyi...csakhat ugye erre mar plusz penz/design kellene, az meg nincs

Ez akkor működik, ha a logrotate nem bugos. Volt olyan, hogy az volt. De, ez nem csak ennek a világnak sajátja. Aki látott már CBS logot 3 GB fölé hízni, ami miatt elfogy az összes hely a C meghajtóról ... az nem csodálkozik semmin :D

https://answers.microsoft.com/en-us/windows/forum/all/solved-component-…

trey @ gépház

Ha jól emlékszem, a yellow alert 75%-nál triggerelődik, napok, hetekkel azelőtt, hogy abból gond lenne. Persze, ha "gond" van belőle, az is csak a 0.1-es adminnak gond, mert egy átlag Linux user csukott szemmel bootolja a vCenter Appliance-t single módba, üti ki a root jelszót, méretezi át az LVM kötetet és már kész is. 🤷‍♂️

trey @ gépház

>  egy átlag Linux user csukott szemmel bootolja a vCenter Appliance-t single módba, üti ki a root jelszót, méretezi át az LVM kötetet és már kész is.

Ami valószínűleg support szerződés sértésnek minősül. Ez a felvetés egy licenclopásos gyanúról szóló cikk alatti kommentháborúban elképesztően vicces. Hozok popcornt.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Volt szerencsém igen nagy cégeknek menedzselni a support szerződését egy szintén igen nagy vendornál ("microsof"-fal kezdődik, és "t" a vége), és nem igazán rémlik egy olyan eset sem abból a négy évből, hogy ilyen miatt bárki balhézott volna. Ráadásul ha az ügyfél nem tudja mit csinál, és nagyobb bajt okoz, mint eredetileg volt, az csak tovább pörgeti a supportos taxiórát, emiatt senki nem bontana szerződést.

jah, es egy zart (marpedig egypar az) appliance-hez hogy fersz hozza legalisan - modjuk torolni a particiojarol?...a pont valid az elottem szolotol ;)

(persze lehet hackelni, de az infra nem arrol szolna, hogy a sz*rt pofozgassuk, arra ott vannak a fejlesztok es a programjaik)

Amikor az egyetlen shell user az appliance-ben az 'emergency' aminek a default jeszava az 'unsupported' és login message: "itt csak akkor kotorássz, ha a tech supportunk mondta neked"... 

...na akkor bizony a logrotate hibás beállítása igenis egy bug a termékben, nem pedig üzemeltetői balfasszág.

Fejlesztettem ilyen appliance-formában terjesztett szoftvert, ha valamihez shell access kellett a felhasználónak, az hiányosság volt a konfig menedzsment/operations felületen, amit kezelni kellett. Persze mindig voltak ilyen "ő jobban tudja és rutinszerűen alányúl a rendszernek" ügyfelek. A tech supportosaink már kérték, hogy csináljunk valami audit trail feature-t nekik, amiből láthatóvá válik számukra a mókolás és ne nyomozzák feleslegesen napokig az elvileg lehetetlen hibákat, amiket az úgyfél maga idézett elő. A legjobbak azok voltak amikor a userek magukat buktatták le, a hivatalos konfig management "reconfigure" művelet lefutása után revertálódott a kézi belepiszkálásuk és ezt bejelentették hibának.

Régóta vágyok én, az androidok mezonkincsére már!

Amikor az egyetlen shell user az appliance-ben az 'emergency' aminek a default jeszava az 'unsupported' és login message: "itt csak akkor kotorássz, ha a tech supportunk mondta neked"... 

Mikori ez az infód? vSphere 4.x? 8.x-nél tartunk :D

https://hup.hu/comment/3175203#comment-3175203

trey @ gépház

Egyrészt kb 6 évvel ezelőttig foglalkoztam vmware cuccokkal. Másrészt nemcsak vSphere volt, hanem akadt ott NSX-V, NSX-T, vCloud Director, VIO, egy rahedli csomó ilyen-olyan management appliance is ezekhez. És bizony akadtak kisebb-nagyobb stiklik, ilyen szempontból nem mindig volt egységes a minősége az összes terméküknek. (Igen, mielőtt hozod a whataboutizmust, volt dolgom sokkal rosszabb minőségi standardok szerint készülő enterprise szoftverekkel is.)

Régóta vágyok én, az androidok mezonkincsére már!

A mondandóm lényege erre volt az állításodra volt reakció:

Amikor az egyetlen shell user az appliance-ben az 'emergency' aminek a default jeszava az 'unsupported' és login message: "itt csak akkor kotorássz, ha a tech supportunk mondta neked"... 

Régen nincs már ez a figyelmeztetés (talán az 5.x-nél volt, de az is lehet, hogy a 4.x-szel ment a süllyesztőbe), az LVM-es átméretezésről pedig hivatalos VMware (most már Broadcom) tudásbázis cikk van, semmilyen support nem ugrik. 1000 éves urban legend:

https://knowledge.broadcom.com/external/article/318953/vcenter-server-a…

Log into the vCenter Server Appliance as root via SSH or the vCenter virtual machine Console.

Note: If unable to log in to vCenter Appliance and suspect this is due to the /dev/sda3 "root partition" being full, refer to the following article steps 1 to 7 to gain Single user mode shell access:  Resetting root password in vCenter Server Appliance 6.5 / 6.7 / 7.x / 8.x (322247).

https://knowledge.broadcom.com/external/article/321369

Ezek hivatalos eljárások.

trey @ gépház

Csak vicceltem, nyugi. Pont azt mondom én is, hogy hülyeség.

Fizetős support sosem fog olyat mondani egy ilyen commodity termékre, hogy nem szolgáltat, mert belenyúltál. (Hacsak nem valami lepecsételt appliance-ról van szó) A kolléga keveri a supportot a kínai elektronikai hulladékhoz járó garanciával. Ott ha megbontod az eszközt, valóban ugrik a gari.

Nem, nem ugrik a gari általánosan az egész termékre. De a tech supportnak innentől megvan a joga arra a konkrét support case-re azt mondani, hogy bocs, ebben nem tudunk segíteni.

Hidd el, álltam én ennek a rossz végén, ne tudd meg hány esetben próbáltak ügyfelek a zárt appliance-ként kiadott termékbe belehákolni olyan feature-t, amit hivatalosan nem támogattunk, majd mikor akaratlanul/fogalmatlanul eltörtek vele valamit, akkor nyitották a support case-t (amiben persze jól kussoltak arról, hogy belepiszkáltak). A mi TS-eseink meg debuggolhatták 2-3 napon át, hogy ez az elvileg lehetetlen hibaeset hogy állhatott elő egyáltalán. Aztán mikor kiderült a dolog, akkor jött a "dehát ez nekik kritikus use-case, ezt MUSZÁJ megoldanunk valahogy ASAP". Ja, hát kérem, tessék a feature request pulthoz fáradni... "Dehát ők már feladták a feature request-et, csak mi ezt későbbi release-re vállaltuk, nekik sürgősebben kell, ezért meghákolták, most oldjuk meg, hogy ne okozzon hibát" stb. Voltak simán esetek, mikor így próbáltak kikényszeríteni olyan feature-t tőlünk, amit a mi product management-ünk kerek perec elutasított.

Régóta vágyok én, az androidok mezonkincsére már!

És honnan kellene a szoftvernek kitalálnia, hogy az adott cégnek, az adott iparágban, mi az értelmes default? Honnan fogja tudni az app, hogy nekem mondjuk 10 év megtartási kötelezettségem van a logokra, mert olyan területen működik a cég?

Legyen mondjuk A-cég, akinél 0 másodperc leállás a megengedett, cserébe már a tegnap logra sincs szükség, meg legyen B-cég, ahol akár két nap leállás is megengedett, de nem lehet semmilyen adatvesztés, logból sem.

Melyik legyen a default működés?

> Honnan fogja tudni az app, hogy nekem mondjuk 10 év megtartási kötelezettségem van a logokra

 

requirement management elotte, csak ez az, amit a vmware-nel elfelejtettek betenni a kerdesekbe

a log particio karbantartasa szinten nem rocket-science, ha 10 evig kell tartanom a log-ot (ami ugyan baromsag), de 2 ev utan betelik, akkor is torlok/rotalok, lesz*rom hogy mit ir elo a szabalyzat..ugyanis ha nem teszem, az egeszet elveszthetem...inkabb, mint hagyjam megdogleni a rendszert

> Nyilván azért vannak a piacon erre jó pénzért megoldások, mert "baromság"

rossz szalon vagy, nem a vmware log particionak kell ezt megoldania :D

a szabadidom akkor is keletkezik, ha osszeomlott a sz*r design-u rendszer a log beteltsege miatt es nem tudom kijavitani 5 perc alatt

Erre a válasz a konfig management API vagy valami UI ahol a user beállítja, és az appliance belső konfig kezelő service-e megoldja. Legjobb ha van valami konfig validátor, ami legalábbis figyelmezeteti a usert ha beállítások hülye kombinációját próbálja beadni.

Másrészt logot soha nem azon a szerveren tartunk meg évekig, ahol keletkezett, hanem valami kifejezetten erre való logkezelő rendszerben (mondjuk Graylog amíg kereshetőnek kell lennie, aztán megy offline archívumba).

Régóta vágyok én, az androidok mezonkincsére már!

Csak - ha jol tudom, bar reg foglalkoztam ezzel - mondjuk a vCSA-t ova-bol deployolva nem tudod ennyire customizalni. Talan lehet override-olni a vdisk meretet, hatha akkor nagyobb szelet jut a log particionak. De azt meg nem igen tudjuk, hogy a default log particio merete mire eleg, kell-e novelni egyaltalan, ha igen mennyire.

Amikor mi belefutottunk ilyen problemaba, akkor vmi LDAP connector logolt brutal sokat (nem hibat, hanem csak egyszeruen nagyon verbose volt alapbol), ami raadasul nem is infra meret fuggo. Emlekszem a vCSA ugy maga ala piszkitott, hogy init=/bin/bash hackelessel kellett takaritani, hogy egyaltalan elinduljanak a service-ek...

( kubi | 2025. 03. 27., cs – 18:11 )

Van ez igy.

Csak aztan ki ne deruljon, hogy nem minden licensz olyan licensz. A nagyok kozott van egy rakas megallapodas mindenfele hasznalatra. Nagyon nem ugyanaz, ha termeket az IT pakolja mukafolyamatok szoftverei ala, az R&D tesztkornyezeteiben fut, az R&D beepiti a termekeibe vagy az R&D par kulonbozo TCA-n (technical collaboration agreement) keresztul jatszik vele. 

Nyilvan ezt mind le kellene papirozni a kellementlensegek elkerulese erdekeben. De mindig ott van egy gentlemen's agreement, ha mar a sales es a procurement ugyanarra az egyetemre es kocsmakba jart, illetve ott van az evek alatt kialaklt szokasjog, amirol nem keszul papir. De mindezt majd jol nem tudjuk meg, mert kiegyeznek par honap alatt egy uj munkapontban. Lasd meg az AT&T esetet.

Es igen, nem engedunk be mindenfele jottmentet nezelodni a rendszereinkbe.

Pontosan, en is erre tippelek.

R&D es egyeb lab (nem production) kornyezetre ingyen kapjak a licenceket kulonfele agreementeken keresztul. Ez egyfajta win-win szituacio, mert ha egy ceg vmware komponensekbol epitkezik, akkor az end-usereknel tobb licenc eladas varhato. A VMware meg eddig segitette az ilyen cegeket, hogy lehetove tette, hogy lab keretek kozott elerheto volt minden termekuk.

Most hogy osszerugtak a port, elvarjak, hogy a teljes lab infra is list price-on legyen licencelve.

Jah, itt láthatólag nem értik az emberek, hogy nem csak darab-darab-stimmel-nemstimmel módon lehet licensz-sértést kiprovokálni. Hanem millió más nem egzakt módon, ld. a te példád is. Partnership feltétel nem teljesítésével. Vagy a feltételek eddig nem betű szerint értelmezése, megengedően kezelése helyett most már betűszerint betartatjuk, és akkor meg már nem felelsz meg.

( bazso | 2025. 03. 28., p – 09:38 )

A Siemens cégek gyűjteménye, gondolom igen sok beszerzési csatornával, ennek egy részét partnereken keresztül. Valószínűleg a két fél más mozit néz

( KoGa v | 2025. 03. 28., p – 11:30 )

Ilyen az amikor átláthatatlan a licencelés, és az ügyfél sem tudja mit használ, meg az eladó sem hogy mit adott el...