Sérti-e a VmWare ESX Server a Linux kernel fejlesztőinek szerzői jogait?

Kernel

A Bloomberg (egyike az öt legnagyobb online üzleti oldalnak) azt hiszi, hogy a VmWare tegnapi első nyilvános (tőzsdei) kibocsátása a legnagyobb technológiai kibocsátás lehet a Google óta. Ha bebizonyosodik, hogy a VmWare ESX Server terméke sérti a Linux kernel fejlesztőinek szerzői jogait, az árnyékot vethet erre a pillanatra. Christopher Helwig, a Linux kernel egyik fejlesztője régóta üldözi a VmWare-t azért, mert hiszi, hogy a cég sérti a szerzői jogait.

"VMware uses a badly hacked 2.4 kernel with a big binary blob hooked into it, giving a derived work of the Linux kernel that’s not legally redistributable. I unfortunately don’t have enough copyrights on that particular version to sue them. I do object to use of any open-iscsi code of my origin to be used with it, though."

Ez a cikk annak próbál meg utánajárni, hogy a VmWare valóban érintett-e a vádakban.

( XMI | 2007. 08. 14., k – 23:46 )

Az ESX serverrel amúgy is hócsukám tele van már. 2007-ben nem képes egyetlen SATA vezérlővel sem együttműködni az valahol gáz. Ráadásul a 2.5->3.0 váltásnál nem hogy bűvült volna, hanem kifejezetten csökkent a támogatott hardverek listája. Aztán itt vannak az olyan apró kis viccek, hogy az smbmountja nem képes kapcsolódni olyan szerverhez, ami támogatja (tehát nem kell, hogy kötelezőre legyen állítva, elég, ha csak támogatja) a signed connection-öket (utoljára Win98 volt olyan oprendszer, ami unsigned smb-t igényelt). Ja, természetesen 2GB-nál nagyobb fileokat nem képes átvinni, ami különösen vicces, tekintve, hogy a virtuális gépek disk image-ei ennél kivétel nélkül nagyobbak szoktak lenni. Persze lehet exportálni az image-et 2GB sparse formátumba, de a suspendelt gép memóriatartalmára már nincs ilyen trükk és manapság már az is szokott 2GB-nál nagyobb lenni... Ja és persze jó dolog snapshot készítés meg ilyenek, csak éppen a snapshot delta image-ekre sincs értelmes exportálási megoldás. Arról nem is szólva, hogy újabban management kliensprogramot már csak windows alá csinálnak, amit ráadásul teljesen lehetetlen futtatni wine vagy mono alatt.
Szóval fel kéne ébredni a vmware-nél, hogy esetleg nem teljesen véletlenül csökken a piaci részesedésük. Meg nem teljesen véletlenül van annyi anyázás a vmtn fórumokban. A Vmware egyetlen igazán ütős előnye a piac többi szereplőjével szemben, hogy olyan szervereken is elfut (és windows guest-et is tud futtatni), amikben a processzornak nincs virtualizációs utasításkészlete. Viszont, ha az egyéb hülyeségeik miatt az egész infrastruktúrát az esx köré kell tervezni, ahelyett, hogy az esx illeszkedne bele a meglévő infrastruktúrába, akkor pont a fő előnyüket negálják ki.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Az ESX serverrel amúgy is hócsukám tele van már. 2007-ben nem képes egyetlen SATA vezérlővel sem együttműködni az valahol gáz.

Te aztán eléggé el vagy tájolva... Az ESX az Datacenter szintű megoldás és mint ilyen szigorúan szabályozott és ellenőrzött hardverekre van tervezve és garantálva, nem pedig holmi alacsony kategóriás, SATA-val szerelt szerverekre készült... Ha viszont számodra ez eddig nem volt világos és az ESX Compatibility Guides sem tartozik neked az elolvasott dokumentációk közé, akkor kötve hiszem, hogy komolyabb szinten üzemeltetnél ESX alapú infrastruktúrát. Az meg hogy letöltöttél egy próba verziót (vagy esetleg lewarezoltál egy teljes verziót valamelyik p2p klienssel) és értetlenkedsz a SATA-s GagyiPC előtt, hogy nem támogatottak a hardvereid, még nem jelenti azt, hogy különösebben ki kellene oktatnod a VMWare-t, hogy mit és hogyan is kellene csinálni.

Csak úgy szólok, hogy nagyobb szerverekbe is szoktak ám SATA vinyókat tenni, nem csak GagyiPC-kbe. Van olyan hely, ahol a SAS/SCSI diszkek ára egyszerűen nem éri meg, a strapa miatt úgyis elég sűrűn kell őket cserélni.

A SATA egyre inkább enterprise megoldás lesz.

Szerintem amúgy tényleg átállhatnának 2.6-os kernelre, Compatibility Guide ide vagy oda. Nagyon kevés az olyan cég, akik még mindig 2.4-es kernelt használnak, nem beszélve arról, hogy a 2.4-es kernelben nem csak SATA support nincs, az újabb chipsetes alaplapokkal is meggyűlhet a baja. Mellesleg ha yól emléxem, a SAS sincs támogatva a vanilla 2.4-es kernelben, pedig arra nem mondja senki, hogy dzsunkamegoldás, ugye?

Csak úgy szólok, hogy nagyobb szerverekbe is szoktak ám SATA vinyókat tenni, nem csak GagyiPC-kbe.

Gondolom a hihetetlen Datacenter tapasztalataidról beszélsz... Eleve ott bukik a dolog, hogy ilyen helyeken nem is a szerverben van a "vinyó", hanem külön diszkalrendszerekben. Lehet, hogy amit láttál szervert az neked nagynak számított, attól még nem egy kategória az igazi számítóközpontokba tervezetett és használt megoldásokkal. :)

Van olyan hely, ahol a SAS/SCSI diszkek ára egyszerűen nem éri meg, a strapa miatt úgyis elég sűrűn kell őket cserélni.

Ilyen helyeken nem a diszkek ára szokott számítani. :)

A SATA egyre inkább enterprise megoldás lesz.

vö.: Datacenter

Egyébként nem. Komoly enterprise környezetben sem dívik a SATA. Small & Medium Business only.

Szerintem amúgy tényleg átállhatnának 2.6-os kernelre, Compatibility Guide ide vagy oda.

Hál'sten nem a te véleményedre alapoznak arrafele. :)

Nagyon kevés az olyan cég, akik még mindig 2.4-es kernelt használnak

:)

nem beszélve arról, hogy a 2.4-es kernelben nem csak SATA support nincs, az újabb chipsetes alaplapokkal is meggyűlhet a baja.

Senki nem mondta, hogy 2.4 vanilla kernelt használnak... Pont erről szól egyébként a cikk. :)
Egyébként van egy alap SATA support 2.4-ben is, de ez most igazán mellékes.

Mellesleg ha yól emléxem, a SAS sincs támogatva a vanilla 2.4-es kernelben, pedig arra nem mondja senki, hogy dzsunkamegoldás, ugye?

:)

Mondjuk konkrétan a compatibility guide-ból pl egy rakás 3com hálókártyatípus veszett el a 2.5->3.0 váltás során. Persze lehet trükközni, hogy a 2.5-ös modulokat a 3.0-sba betölteni, ahogy ezt sokan javasolják (és állítólag stabilan működik is), csakhát ugye miről is beszélünk... Meg azt is megjegyezném, hogy a SATA-s gagyipc Intel 5000X chipsetre épül és valóban, tényleg gagyi, mert csak 20GB ram van benne.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Engem érdekelne, esetleg küldd el kérlek privátban. Köszi.

Nekem az a véleményem, hogy

1) nem értem miért éppen *most* kavar, ez neki így miért jobb (valaki buzdította, vagy szimplán rossz indulatú, vagy reménykedik, hogy a VMware megtámogatja egzisztenciáját, vagy....),

2) a VMware valószínűleg nem fog önmagának ellentmondani, az ESX forrását emiatt kiadni még kevésbé,

3) nem értek a mély technikai részletekhez, de ha kellően alátámasztotta volna állításait, valószínűleg vagy jogi lépéseket tett volna, vagy a VMware is jobban foglalkozott volna már korábban az esettel.

Érdekelne, hogy milyen környezetből szedted tapasztalataidat, hogy ilyen szóáradat hagyta el billentyűzetedet (aláírásod alapján mondjuk nem is túl meglepő... kinek a munkáját oltod és hogyan? - erre sajnos nem tér ki).

- hardver és egyéb kompatibilitási listák: általában nem dísznek vannak, ezen rendszereknek (ESX és környezete) nem célja a barkács igények kielégítése. Támogatott eszközök köre csökkent: valószínűleg nem egy olyan döntés volt, aminek meghozatalára céges bulit szerveztek, hogy most milyen jól kitoltak az ügyfelekkel. (képzeld magad a cég helyébe, bár ez adott esetben nyilván sovány vigasz)

- 2GB: alig merem megkérdezni: SCP-t próbáltad már? (mint preferált/ajánlott/támogatott protokoll fájlok másolására...)
Még egy tipp: http://www.veeam.com/veeam_fast_scp.asp
De ha az ESX-ről FTP-zel kifelé, akkor is megoldható.

- Windows: tekintve, hogy a VMware erőteljesen épít a Linuxra, érdemes lenne belegondolni, hogy mi lehet az oka annak, hogy a management eszközök mégis Windows-on futnak (azt kihagytad, hogy a VirtualCenter miért nem támogatott MySQL háttérrel) - azonkívül, hogy Veled kitoljanak.
Szerintem ez viszonylag kevés embernek okoz gondot, tekintve, hogy legalább egy Windows XP kb mindenhol van, ha meg nincs, akkor sem kerül olyan sokba, hogy ezen akadjon el bármi is.

- SATA: nem kizárt, hogy a közeljövőben megjelenő 3.1-es támogatni fogja. Azt nem szabad figyelmen kívül hagyni, hogy nagyobb adatközponti szerverekben nem elterjedt a SATA (ESX elsődleges környezete). ESX-et leginkább SAN-hoz szokták kapcsolni, ha mégsem akkor SCSI preferált, innentől kezdve ennek viszonylag kicsi a jelentősége, bár tény, hogy néha jól jöhetne a támogatottsága.
(magát az alaprendszert VMFS nélkül ATA-ra is telepítheted)

- Piaci részesedés csökken: valamennyire biztos, de ez elkerülhetetlen több résztvevő piacra lépésével (nagyon forrósodik a téma - mondhatni kezd erőteljes pénz szagot eregetni magából-, egyre többen nézegetnek ebbe az irányba, lásd Citrix és XenSource).

- Anyázások:
1) mondj egy olyan gyártót, akinek a termékeivel nincsen baj,
2) sok anyázás hátterében nem a gyártó hibája áll, hanem a felhasználók tudatlansága, lustasága, lehetne sorolni (igen, Te is felhasználó vagy, egy gyártó szemében akár pont olyan, mint egy rendszergazda szemében egy titkárnő. A különbség az, hogy a gyártó a felhasználóiból él, emiatt kevesebb a beszólási lehetősége)

- VMware előny: ajánlom, hogy kicsit jobban tanulmányozd át, hogy mit is nyújt a VMware és a konkurencia (ne a SATA támogatás legyen a kiinduló pont). Főbb szempontok: technológia, funkcionalitás, megbízhatóság/kiforrottság, kompatibilitás, ISV és egyéb gyártói támogatottság, innováció.

- ESX köré építeni: attól, hogy Neked nem olyan eszközeid vannak, amit az ESX támogat, a világ gondolkodhat másképpen, nem?
Szerinted úgy indultak el a pályán és növekedtek, hogy kiálltak egy dombra, szembe álltak a széllel és nosza rajta: "Vizeljünk!"?

Bevallom/nem titkolom, hogy elfogult vagyok a VMware irányába (persze mind a cégnek, mind a termékeknek vannak hibái/hiányosságai), de ha összesített objektív mérleget veszünk, a VMware serpenyője erősen pozitív irányba billen több szempont alapján is - valószínűleg ezért tudott megerősödni és ennyire elterjedni.

Gyakorlatilag egy menedzsment eszköz van, a VMware Virtual Infrastructure Client. Nem tudom, hogy mekkora a valós igény egy linuxos változatra - idővel úgyis kiderül.

Ezenkívül van webes felület, aminek igaz, hogy jelentősen kisebb a funkcionalitása, de azért ezt-azt meg lehet azon keresztül is csinálni - akár linuxon, akár windows-on futó böngészőről (talán a MacOS is támogatott).

Ha olvasgatsz a VMTN fórumbejegyzéseket, akkor kiderül, hogy ez bizony nem csak nekem probléma. És a vmware már egy jó ideje szarik válaszolni a problémára.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Érdekelne, hogy milyen környezetből szedted tapasztalataidat, hogy ilyen szóáradat hagyta el billentyűzetedet
Ha nagyon érdekel elmesélem külön. Tényleg nem datacenter. ~10 szerver, ebből 4 ESX, nagyrészt IBM hardver. Limitált költségvetés...

alig merem megkérdezni: SCP-t próbáltad már? (mint preferált/ajánlott/támogatott protokoll fájlok másolására...)
Úgy tapasztaltuk, hogy az NFS mountra másolás az egyetlen, ami nem cseszi el az image-eket, úgyhogy most így van megoldva. Egyébként VMTN fórumokban arra utalnak a megjegyzések, hogy ez a hiba korábban már javítva volt egyszer, és most valahogy sikerült "reintroduce"-olni.

adatközponti szerverekben nem elterjedt a SATA (ESX elsődleges környezete).
Ez igaz, de attól lefele egyre inkább terjed és azért nem csak adatközpontok vannak a vmware ügyfelei között. (igényesebb környezetben is kezdik drágállani a SCSI-t manapság, különösen, hogy feature setben a SATA elég sokat behozott az IDE lemaradásából)

(magát az alaprendszert VMFS nélkül ATA-ra is telepítheted)
Igen sajnos egy helyen kénytelen voltam így megoldani... Nem szép...

Piaci részesedés csökken: valamennyire biztos, de ez elkerülhetetlen több résztvevő piacra lépésével
Mivel a kialakított image-ek konvertálása mondjuk esx->xen vagy akármi más között egy elég macerás feladat (bár ha itt tartunk vmware workstation és esx között se egyszerű), ezért azt kijelenthetjük, hogy van egy elég erős vendor lock-in tényezője. Tehát akik ráálltak esx-re azok, nehezen váltanak másra, vegyes szerverpark pedig különösen nem jellemző. Lévén, hogy igen sokáig az esx volt az egyetlen szervereknél jól használható virtualizációs megoldás (LPAR-t és ilyen speciális nyalánkságokat most hagyjuk), ezért kb a teljes piac az övéké volt és akár sokáig az is maradhatott volna. Csak a gondot én ott látom, hogy ahelyett, hogy a piac igényeit figyelembe véve nyitnának lefelé a kis és középvállalkozások irányába, ahonnan már így is volt jelentős ügyfélbázisuk, ehelyett egyre inkább specializálják magukat az extra high-end datacenterek felé, a kissebb igényű/költségvetésű ügyfelek rovására. Pedig a piac főleg az alsó felén bővül. Érdekes, hogy ezt pl a Vmware Server, illetve Player ingyenessé tételénél észrevették, az ESX-nél valahogy mégsem akarják felfogni.

VMware előny: ajánlom, hogy kicsit jobban tanulmányozd át...
Pontosan tudom, hogy mik az esx erősségei, amiknek egyelőre nincs konkurenciájuk. VMotion pl tényleg egy hasznos feature... egy bizonyos piaci szegmens számára. Numa ütemezés is csak náluk van ezidáig jól megoldva. (Ez konkrétan opteron szervereken kell is, tehát nem egy szűk rétegnek szól). Ezek tényleg komoly technológiai vívmányok. Mint ahogy az az "alap" dolog is, hogy a windows guesteket tudják paravirtualizálni, így nem kell hardveres támogatás hozzá. Gyakorlatilag ettől lettek piacvezetők.
Akkor kérdem én, miért kell apró hülyeségekkel elcseszni a teljes termékről alkotott képet? Ha a nagy problémákat meg lehet oldani, akkor az apróbb dolgokra miért nem tudnak odafigyelni? Nem igaz, hogy akkora többletmunka lenne egy normális smbmount-ot belerakni, vagy a patch/update kezelést megoldani úgy, hogy ne embernek kelljen számontartania, hogy mi lett már applikálva és milyen sorrendben, stb. Apróságok ezek, mint ahogy az is, hogy időnként el kéne olvasni, hogy mit írkálnak az ügyfelek a vmware saját fórumába és esetleg megpróbálni ebből kitalálni, hogy merre tovább.

Tényleg remélem, hogy a 2.5->3.0 során tapasztalt visszalépések tényleg csak átmeneti botlások voltak és a 3.1-ben újra előre fognak lépni. Csak kicsit sokat szoptam az utóbbi időkben vele ezért írtam olyan hangnemben, amilyenben.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Öhm, nálatok is az van az SCP-vel amúgy, hogy 1M fölé nem megy a sebesség? Mert én több gépen is azzal küzdök, Win-Lin és Lin-Lin irányokban is, hogy 1 M a max töltési sáv, akár gigabites a vonal akár nem. Én nem gyenge gépek között megy a dolog. Minden más egész yól viszi.

Amúgy az adatsérülés érdekes, valami ismert hálózati hiba az oka, vagy rejtély?

Húú, hát asszem nem pont 1MB/s, hanem inkább olyan 3-4, de tény, hogy vmfs-ről másolás valami kritikán aluli lassú a management vm host partíciójához képest és ezen a maintenance módba kapcsolás sem segít (illetve csak alig valamit). Az a fura, hogy vmkfstools-al exportálás/importálás sokkal gyorsabb, még ahhoz képest is, hogyha figyelembe vesszük, hogy az allokálatlan területet nem kell mozgatni a sparse vmdk formátum esetén. Egy tippem egyébként van rá, mégpedig az, hogy a vmfs műveleteket mindig szikronizálja, ugyanis a vmfs támogat több konkurens hozzáférést is. Tehát pl egyszerre több gép is fel tudja mountolni ugyanazt a vmfs volume-ot, mondjuk iscsi vagy san-on keresztül és az egyidejű hozzáféréseket így folyamatosan a lemezre írt szemaforos kölcsönös kizárással kell szinkronizálni. Na ennek elég komoly overheadje lehet. Egyébként tényleg az nfs-t javaslom, mert a többi megoldáshoz képest viszonylag gyorsnak tűnt.

Az adatsérüléses problémakör még nem teljesen világos előttem. Sokáig úgy gondoltam, hogy az okozza, hogy a vmfs valójában nem igazi filerendszer, hanem sokkal inkább egy lvm féleség és más módon tárolja a vmdk-k tartalmát, mint a többi file-t és a read/write műveletek nincsenek rendesen implementálva rájuk. De igazából ez úgy néz ki, hogy mégsem igaz, mert akkor miért működik jól nfs-el?! Ráadásul md5sum is korrekt. Szóval szerintem a probléma inkább valahol a 2gb-os mértekorlát környékén keresendő. Az smb, ftp esetén ismert bug van. Hogy az scp miért nem jó, arra nem tudom a magyaráztatot. Bár most így belegondolva az a szörnyű rémkép merült fel bennem, hogy lehet, hogy a gyári glibc van rosszul legforgatva rá.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

Huhh... egy dologban félreértettél. Nálunk ugyan nem volt VMFS, de a scp minden szerver között nagyon alacsony sebességet produkált, akár Deb, akár Red6 volt a szerver.
Nekem pl. egyszer sikerült ilyen 2-3 M körüli sebességet produkálni nemtomhogy, és a csapatba én voltam a király. Bármilyen más metódus hozott 5-6 M körül, SCP soha.

Amit a GlibC-ről mondasz, lehetséges hogy igazad van, bár ugyanaz vonatkozik rá, mint a VMFS-es tippre, azaz, hogy akkor az NFS mitől megy? Bár az is igaz ugyanakkor, hogy az NFS kalapnyi része kerneloldalon van implementálva, ami ugye nem hazsnál GlibC-t.

Köszi a választ.

- SATA: mint írtam, nem kizárt, hogy a 3.1-ben lesz támogatás (bejelentés talán a VMworld-ön várható), ez is mutatja, hogy képes nyitni, ha valamire igény van, akkor válaszol rá. Az ESX/VMFS eddig kvázi 100%-ban SCSI-re épített, nem biztos, hogy kis munka volt bevenni a SATA támogatást (az jó kérdés, hogy mi lesz támogatott SATA-n, azon belül is milyen megkötések, de első lépésnek mindenképpen ígéretes lehet).

- a VMware-nek ketyeg az idő, hogy a Microsoft előtt minél jobban megerősödjön. Az MS-nek 1 év múlva lesz egy olyan terméke (Viridian - ha elkészül, még béta sincs tudtommal), ami minden bizonnyal nem fog annyit tudni, mint az VI4 (nem kizárt, hogy jövő nyáron megjelenik). Ehhez képest az MS marketing úthenger már most is iszonyatos erővel nyomul, elég megnézni a "Quick Migration"-t.
A VMware rövidtávú növekedési potenciálja elsősorban a nagy cégekben van: innen tud viszonylag rövidebb idő alatt nagy bevételt generálni, illetve itt fontos erősen megvetnie a lábát, különben később nehezebb lesz

- a VMware Server ingyenes megjelentetése szerintem egyrészt kötelező lépés volt (Microsoft Virtual Server ingyenessége), másrészt ahogy írod egy kezdeti lépés az SMB felé.
A VI3-mal is történt azért lépés az SMB felé a Starter változat megjelentetésével, de a 3.1-es változat esetleges SATA támogatásával ez tovább nyílhat. Azaz én nem minősíteném visszalépésnek a 3.x-et a 2.x-hez képest.
Ha minden igaz a VMworld környékén bejelentik a VMware Server 2.0-át, több jel is erre utal, például az, hogy a VC2.1 kezelni fogja előzetes híresztelések alapján.

- apró hiányok: feltehetően nem végtelenek a fejlesztési kapacitások (sőt, egy adott létszám fölé adott méretű projekt esetén nem is érdemes menni), így - mint általában minden termékben - itt is vannak és biztosan lesznek is.
Ide tartozik a VI3 Client linuxos változata is: viszonylag összetettebb alkalmazás, ezért nem tartom kizártnak, hogyha lenne linuxos változat, akkor több smbmnt-hez hasonló zavaró apróság lenne. (+ támogatást is kellene nyújtani hozzá, ... - összeségében nem biztos, hogy kifizetődő termék lenne)

- Patch-ek: ők is rájöttek, figyelmet is fordítottak rá, 3.1-esben VC-vel integrált központi patch-elési lehetőség is lesz (egyébként nem nehéz egy szkriptet írni, ami megfelelően feltolja az összeset, de tény, hogy kényelmesebb is elképzelhető akár kevés fantáziával is)

- Vendor lock-in: lássuk be, hogy valamilyen szintű lock-in minden gyártónak érdeke. Ahhoz képest, hogy még gyakorlatilag most is uralják a piacot, meglehetősen nyitott egy cég, pl a vmdk formátumot már nagyon régen publikálták, külső eszközök is születtek hozzá, úgyhogy valószínűleg ez a publikáció használható minőségben történt.

- VMTN: áprilisban Nizzában volt az európai VMware konferencia, a bevezető előadásban elég nagy hangsúlyt fektettek a VMTN helyzetjelentésre és a jövőbeli elképzelésekre, nekem teljesen az jött le, hogy nagyon is figyelemmel kísérik (nem kevés VMware-es VMTN hozzászólással is találkoztam már, ami ezt alá támasztja). Megint előjön az, hogy végesek a kapacitásaik, prioritások nyilván fel kell állítani. (talán valami grafikonokat is mutattak ezzel kapcsolatban, ha érdekel előbányászom)

Csak megjegyzésként: már itt a HUP-on is megjelent, hogy a Citrix felvásárolja a XenSource-t. Ez elég sok kérdést felvet, például mi lesz az OSS változattal és a többi Xen-re épülő céggel? Mi lesz a Linux-ba olvasztott Xen patch-csel? Lesz önkéntes kapacitás karbantartani, ha a Citrix nem publikál a fejlesztéseiből?

Én meg örülök neki, hogy az itt szokásos hülye flame helyett értelmes választ kaptam.

A visszalépés témakört én arra értettem, hogy egyrészt "reintroduce"-oltak régebben már kijavított bugokat, illetve, hogy kivettek néhány drivert a vmkernelből (látszólag technikai indok nélkül, lévén, hogy elég sokan állítják, hogy stabilan működik a 2.5-ösből szedett driver a 3.0-ás vmkernellel. Persze én ilyesmivel még nem pancsoltam, nem biztos, hogy ez igaz is, de elég sok fórumbejegyzés szól ilyesmiről) Ez az egész vmfs kezelési szenvedés tkp fel sem merülne, ha a VI clientnek lenne "export virtual machine" funkciója, mint pl a Xen clientnek. Minimális kis oversight, és akkor egyáltalán nem is kéne a konzolra belépkedni, hanem a data store kezelés tényleg teljesen transzparensen menne. Igazából az integrált management tud egy ilyen terméket igazán enterprise megoldássá tenni, nagy kár, hogy néhány apróság miatt nem lehet teljes körüen használni.

A VI3 client linuxosításához igazából csak a DCOM-ot kéne valahogy kiváltani belőle. Ugyanis ha jól látom dotnetben írták az egészet, a Mono mindössze a DCOM support hiánya miatt nem tudja futtatni.

SATA
Itt igazából két dologról van szó. Az egyik (egyszerű), hogy a host vm-et fel lehessen telepíteni SATA diskre, ne csak PATA-ra. Ennek én nem látom nagy technikai akadályát, csak upgrade-elni kéne management vm linux kernelét vagy könnyen upgradelhetővé tenni. Esetleg, hogy kicsit ontopic legyek itt lehetne megmutatni, hogy a vmkernelt be lehet tölteni linux nélkül is, és akkor nem sírhat a szája senkinek a gpl miatt. A másik komolyabb probléma, hogy a vmfs is mehessen SATA-ról. Ennek a fő akadálya nyilván az, hogy a jelenleg valami SCSI-SCSI parancsfordító van implementálva a vmkernelben, ami a egyrészt kezeli a vmfs-t, másrészt a parancsokban az azonosítókat/címeket átírja és úgy továbbítja a tényleges eszköz fele. Nyilván egy SCSI-ATA parancsfordítót még ebbe beleépíteni egy nagyon nagy feladat. Ugyanakkor pl van szoftveres iSCSI driverük, ami mutatja, hogy megoldható, hogy még egy réteget berakjanak a fordított SCSI parancsok és a tényleges eszköz közé. És itt driverben meg lehetne oldani egy SCSI-ATA parancsfordítást (á la a régi ide-scsi linuxban), ami lényegesen egyszerűbb, mert nem kell címeket átírkálni, meg konkurens hozzáféréshez köcsönös kizárást csinálni meg ilyenek. Nyilván valamelyest lassabb lenne, de legalább egy tisztább rétegszerkezet, karbantarthatóbb lenne. Egyébként is, ha valaki SCSI helyet SATA-t használ, akkor már úgyis elve nem az abszolút maximális teljesítmény a lényeg, tehát a nagyobb overhead-et a célközönség tolerálja. Ráadásul sima SCSI-ATA parancsfordítót nem kell maguknak kifejleszteniük, ilyet biztosan tudnak licenszelni, de GPL-es változatot is csináltak már belőle, tehát a jövőbeli licenszpolitikájuktól függően még választhatnak is.

Vendor lock-in: lássuk be, hogy valamilyen szintű lock-in minden gyártónak érdeke.
Igen és én éppen azt mondtam, hogy szerintem ezzel jobban is élhettek volna. Nem vissza :), csak talán a világ változásaira kissé gyorsabb reagálással kihasználhatták volna, hogy nagyon nagy a barrier ha egy bejártatott virtualizációs technológiáról teljesen át kell állni egy másikra. Tehát ahhoz, hogy az ügyfél váltson, nagyon nagy kényszerítés kell -> nem szabad olyan bugokat/hardver support hiányokat nyitva hagyni, ami kényszeríti az ügyfelet a váltásra. Tudom, erőforráshiány...

Xen
Nos erre is azt tudom mondani amit már fentebb írtam. Szerintem az integrált management megoldás egy alapvető szempont a virtualizációs megoldást piaci elfogadtatásánál. A Xen opensource változatából pont ez a rész van kihagyva, ebben tud többet a Xen Enterprise. Ha az alapvető taskokhoz kézzel kell varázsolgatni, akkor az az "enthusiast"-ekenek meg fog felelni, de a piacon nem lesz sikeres. Most, hogy a kernelbe berakták a Xent és még 2 másik megoldást, arra vagyok nagyon kíváncsi, hogy a disztribúciókészítők mit tudnak ezekből kihozni. Tudnak-e olyan management felületet építeni rá, ami mondjuk versenyképes a mostani ESX-el? Ha igen, akkor ezzel a Citrix vitorlájából kifogták a szelet. Egyébként ettől féltek a Xen készítői is, szerintem ezért adtak túl ilyen hirtelen a cégen. Attól nem félek, hogy a kernelfejlesztők a core virtualizációs technológiákat ne kezdenék el fejleszteni kifejezetten enterprise igények irányába. Nyilván kell egy idő, amíg rákapnak, de szerintem utána megint az lesz a panasz, mint a kernelfejlesztésben mostanában, hogy túlságosan is rákoncentrálnak az enterprise igényekre.
---
Sok gyerekkel ellentétben én sose akartam tűzoltó lenni. Lettem helyette informatikus. Nem találjátok ki, hogy mit csinálok nap mint nap...

VI3 Client: ehhez részletesebben nem tudok hozzászólni, ugyanis nem tudom, hogy a DCOM mennyi szolgáltatást biztosít a szoftverfejlesztők számára, ezt kiváltani mennyi munka - hiába csak 1 valamin múlik.
Ugyanakkor az, hogy nincs nem jelenti azt, hogy nem is lesz (de nyilván azt sem, hogy lesz :-) ).

Gondoljunk bele, hogy az ACE 1.0 csak Windows-on volt támogatott. Megjelent a 2.0, ami már Linuxon is az, de ennél fontosabb, hogy az ACE Management Server Linuxon is futtatható (+PostgreSQL!!!). Emiatt azt sem zárnám ki, hogy talán valamikor a VC is fog Linuxon futni (a FlexLM ez ügyben nem akadály).
Ha a VC fog futni Linuxon, az az elképzelésem fog erősödni, amit korábban is írtam: a VMware-nek a nagyvállalatok nagyon sürgősek gyors erősödéshez, de folyamatosan támogatja az "alsóbb" piaci szegmenset.

Export/Import VM/file funkció: valóban nem lenne rossz, de szerintem ami késik az nem múlik - ha csak részlegesen is -, mert a 3.1-es VC-be integrálják a Convertert. (ami elvileg most is használható, a Starter változat ingyenes - próbáltad már?)

SATA: nem vagyok alacsony szintű storage guru, de ha jól tudom az iSCSI nagy előnye az, hogy gyakorlatilag SCSI parancsok kerülnek továbbításra a hálózaton, emiatt passzol bele viszonylag jól a VMware architektúrájába, passzítható össze valószínűleg viszonylag könnyen a VMFS-be.
A VMFS témakör másik fele, hogy az NFS nem VMFS, tehát az ESX többféle tárolórendszert képest kezelni, valószínűleg a VMFS fölött van egy másik absztrakciós réteg, mégpedig maga a fájlkezelés (az NFS nem blokk szintű hozzáférést biztosít). Emiatt akár olyat is el lehet képzelni, hogyha lesz SATA-ra VMFS, akkor az egy harmadik féle tároló típus lesz - kérdés, hogy mit egyszerűbb nekik megvalósítani: SATA->SCSI vagy új tároló típus.

Az tény, hogy látszólag kicsit lassan kapcsolnak a SATA-ra (remélhetőleg kapcsolnak...), sajnos a 3.0.2 is elég sokat csúszott.

Ami a bootolást és az alacsony szintű dolgokat illeti, minden bizonnyal itt is lesz változás a 3.1-gyel (a Xen ennyi változásért 3-ról legalább 6-os verzióra ugrott volna...), ugyanis lesz egy "ESX Lite" nevű cucc. Hogy ez pontosan mit takar, még nem tudom, de nem kizárt, hogy érdekes lesz (olyasmit rebesgetnek, hogy az ESX-t a Biosba teszik vagy nagyon alapszintre, de konkrétum hiányában elég nehéz minősíteni).

Vendor lock-in: valóban, de arra azért kiváncsi lennék, hogy hányan dobták ki az ESX-et és választottak helyette mást. Azt könnyebben el tudom képzelni, hogy a VMware Servert kiváltja valaki Xennel.

Xen: valóban leginkább egy jó menedzsment cucc kellene köré, de én valahogy nem látom, hogy a közösség ki tudná szenvedni magából. Talán a Novell vagy a RedHat magának, és ez fogja őket megkülönböztetni egymástól - kiderül.
Szerintem pedig azért adtak túl a cégen, mert túl kicsik és elkéstek. A VMware eléggé megerősödött, ráadásul jön a Microsoft is - mondom, érdemes megnézni a Quick Migration dolgát, egy jó iromány: http://virtualscoop.org/?q=node/4.

Miért adtak túl a XenSource-on? Szerintem mert nincs eszköze erős marketinghez, a cégeknél nincs jelen, hogy szélesítse eladott termékkörét, technikailag pedig nem tudják a legtöbbet nyújtani (az, hogy néhány mérésben jobb egy hajszálnyival az ESX-nél konkrétan senkinek a szívét nem dobbantja meg). Nem vagyok egy piaci szakértő, de ez nem tűnik nyerő pozíciónak.