Free virtualizáció, oVirt egyenlőre nem jött be

Virtualizáció

Sziasztok!

Van két új szerverem (ProLiant ML380 G7 + egy SAN P2000 fele), amire rá kéne zsúfolni a jelenleg egyedi gépeken futó Linux szervereket. Főleg Web szerverek, de elég vegyes felvágott, legalább egy tucat virtuális gép.
A terv az volt, hogy az oVirt-et teszem fel, de ez nem igazán jön össze.
Az oVirt-engine-t feltettem egy régi szerverre, és az eddig működőképesnek tűnik (panaszkodik, hogy kevés a 4GByte memória, de nincs több).
Az ovirt-node-ok telepítése viszont nem megy. A doksi csak a triviális dolgokat taglalja igen részletesen, minden egyebet elintéz félmondatokban. Ha jól értem a telepítés menetét, akkor a ML380-okra kéne telepítenem az ovirt-node-ot egy CD-ről. Első körben a CD boot után a helyreállítási mód fogadott, ahol megadhatnám a root jelszót, ha tudnám, de akkor is minek, mert nincs mit helyreállítani.
Egy fél mondatban utal a doksi arra, hogy repo-bol is telepíthető, ehhez kellene egy FC16-ot telepíteni, de a telepítő aránylag az elején kifagy.
Egy CentOs 6.2-t sikerült feltelepíteni, egy nap kínlódás után felment a HP support pack-ja is. Telepítettem az ovirt-node 1.9-es változatát a yum-al. A menedzser gép viszont (az ovirt-engine) viszont nem ért szót a szerverrel (hibaüzenetek számomra nem voltak informatívak, és azóta legyilkoltam a CentOs-t a szerverről).
Újra próbálkoztam a CD-ről telepíteni az FC + ovirt-node párost. Gondolom a support pack-os kínlódásnál volt egy firmware frissítés, és emiatt elindult a telepítő. Miután megadtam, hova települjön, partícionál/formáz, majd közli, hogy a telepítés sikertelen. A logokban pedig hosszú oldalakon keresztül hibaüzenetek tömkelege. Egyrészt nem látja a hálózatot ( a telepítőben nincs hálózat konfigurálás, enélkül pedig ez nem meglepő), nem tud elindítani egy csomó szolgáltatást, és ha jól értem gondja van a diszkek elérésével is (valami nyoma van a telepítésnek, mert újbóli próbálkozásnál csak a reinstall indítható el, egyébként közli, hogy van egy sikertelen telepítésem).
Nagyjából itt tartok, és fogalmam nincs merre tovább.
Mivel ez egy főiskola, vagy is közintézmény, így velem ugyan meg lehet értetni, hogy kell valamilyen licenc, de pénz nem lesz rá (vicc, de jelenleg UTP kábelt snem tudok szerezni, Az, hogy vas van az is egy kisebb csoda).
Szóval valamilyen megoldás kéne. Vagy az ovirt-node installálására, vagy valamilyen más lehetőleg nem túl fapados virtualizációs környezetre, ami felmegy a szerverekre.
Eddig kisebb volumenben a KVM-el és az UML-el volt szerencsém virtualizálni, minden különösebb körítés nélkül. Ez most is menne, de sok gép és vlan esetén ez eléggé rémálomnak ígérkezik.
Nézegettem, az RHEV-t, ami elvileg ingyen letölthető, és ha jól értem 15 napig támogatott, de utána mi van? A CentOs-ból nem lessz RHEV-nek megfelelő változat, pedig nekem teljesen jó lenne az RHEV-nek egy ingyenes klónja, támogatás nélkül (már amennyiben működik).

  • 9656 megtekintés

( Zahy v | 2012. 02. 29., sze – 12:53 )

Miért nem jó az ingyenes VMware ESXi? 4.x vagy pláne 5.0-s verzió?

Nem említettem egy szóval sem, hogy nem jó. Az viszont érdekelne, hogy miért jó, mik a lehetőségek.
Régebben, amikor még csak elméleti szinten érdekelt a dolog, akkor ránéztem a VMware-nál ezekre, de nem könnyű eligazodni az oldalukon, mert nem igazán arra ösztönöznek, hogy az ingyenes dolgaikat használd, abszolút nem az "ingyenélők" tájékoztatásán van a hangsúly. Amúgy egy félreértés folytán :) 32G helyett 44G memória van a szerverekben az ESXi pedig csak 32G-t használ ingyen, ez mondjuk ellenérv.

Ez így van a vmware Free hypervisor csak 32GB fizikai memória használatot enged meg a szerverben. Ez a szoftver arra való, hogy egy darab fizikai vasat virtualizálj vele, tehát nincs központi menedzsmentje. Ügyes felhasználók azonban igyekeznek feltuningolni a szolgáltatásait (DR, backup és egyéb területen), minden ilyen infó elérhető a vmware community site-on (egyfajta felhasználói fórum).
A vmware-nek van Academic licencelése, pl. "Essentials Kit" csomag (6xCPU licence, max. 192GB vRAM, központi management) 1év basic support és követés, listaáron kb. 150k HUF.
http://www.vmware.com/products/datacenter-virtualization/vsphere/small-…

Javaslom az ESXI használatot. Ingyenes, stabil, az OS réteggel nem kell foglalkoznod, az update egyszerű, a virtuális gépek vmfs tárolója csatolható minden host gépre, minden szépen támogatja, a teljesítmény nagyon remek, minden os támogatott, jó snapshot képesség, kényelmes kezelhetőség, a teljes vm kompatibilis a playerel is akár. stb. Az 5-ös verziót a megjelenés óta használjuk, leállítás nélkül.

( Umath v | 2012. 02. 29., sze – 13:58 )

Tudom ajánlani a Proxmox-ot (KVM + OpenVZ). Mi eddig megelégedéssel használjuk.

Nekem ebbol csak annyi esik le, hogy mas, de semmikepp nem jobb. Ha megfelelo szempontokat valasztok, epphogy meg rosszabb.
Masreszt a proxmox KVM-et is tud kezelni, ahogy irtak is. Marpedig az szinten teljes erteku gepet emulal.

FC backend meg hol kellene egy ilyen soho kornyezetben?

tompos

Nem volt szempont a SOHO.
Másrészt tök jó, hogy simán le tudják DOSolni az admin felületet.
VLAN alapban nincs. Töketlen dummy interfészeket felvehetsz, de több szerveres módban xart sem ér.
Ha VLAN-t akarsz bele kell hegeszteni. OK, nem atomfizika, csak megy vele az idő. ESX ezt csuklóból tudja.
ESX-nek sokkal-sokkal jobb az erőforrás kezelése. A mgmt eszközök meg _nem_ léte (KVM/prox) meg egy külön történet.

Van ket kozepes szerver, aztan annyi. Az soho:)
De most latom, van valoban storage is hozza, az tenyleg emel a teten, szoval azt a reszet visszavonom.
Az admin feluletet hogy tudjak ledosolni, miert tudnak? Az esx admin feluletet miert nem tudjak?
Mit jelent az, h jobb az eroforraskezelese? Az openvz gyakorlatilag a host gep teljesitmenyet adja vissza veszteseg nelkul. Az ESX tudja ezt (mielott valaszolnal: nem, nem tudja, elvi keptelenseg, de ha a vmware marketingesein mulik, akkor meg annal jobb is:)
Minek milyen meg nem lete?

Az esx-et milyen mgmt felulete van?

tompos

OK, nem DOS-olják le, rak elé tűzfalat. (Egyezzünk meg döntetlenben :)
Sry, az én szótáramban openvz != virtualizáció. (Az nálam container.)
Minek a meg nem léte?
Osszál már ki felhasználói jogokat Prox-on (még a 2.x-es is xar.)
Vagy adjál meg proci korlátot egy VM-nek.
Vagy garantáld, hogy egy intenzív diszk I/O nem dönti le (megáll) a lábáról a többi VM-et.
...

Én itt megálltam, saját cuccokra egyébként nem ESXi-t használok.
Hanem Prox-ot (is). :D

"Minek a meg nem léte?
Osszál már ki felhasználói jogokat Prox-on (még a 2.x-es is xar.)
Vagy adjál meg proci korlátot egy VM-nek.
Vagy garantáld, hogy egy intenzív diszk I/O nem dönti le (megáll) a lábáról a többi VM-et."

Igen, vmit vmiert. Nem allitottam, h mindent tud. De nezd mar meg, a kerdezonek fogalma sincs, h eszik v. isszak.
Ilyenkor annal jobb, minel egyszerubb.
Az ESXi nem ecceru sok szempontbol.

tompos

Alapvetően 2 megoldást kezel egyben.
Léteznek KVM (VM) guestek, plusz támogatja az OVZ-t is (CT). A teljes funkcionalitás a KVM-re van már kihegyezve, azt gyönyörűen tudja kezelni.
Backup LVM snapshotokkal (vagy akár a raw diszkekről is tud, én LVM-el használom), a migrációt tekintve az online és offline is működik, teszteltük több féle guesttel is, megy.
Hiába 2.0, még mindig nem egy ESX, de amit tud azt korrekten tudja és jól működik.

Felraktam a 2.0 RC1-et. Nem világos, hogy a két gép hogyan fogja kezelni az FC SAN-t? A drbd nekem úgy tűnik másról szól. A dokumentáció is elég soványnak tűnik. Csináltam egy clustert, de nem tudok hozzáadni gépet, ha parancsból próbálom, azt mondja van már ilyen kulcs, web-en meg nincs is ilyen lehetőség.

Igen, a drbd arról szól h. szegény parasztnak nincsen SAN-ja :)
SAN-ra majd most akarom én is pakolni, 4 node clusterrel, de ez még a jövő zenéje.
Az FC SAN-t a két gép úgy fogja kezelni, hogy egy LVM-et pakol rá, majd minden virtuális gépnek saját LV-je lesz, amit a gépek közül mindig csak 1 node 'birtokol'. Ezért szeretik a 3 node-os megoldást, ahogy azt írja is a doksi.
Ezeket olvasd el:
Általánosságban a Proxmox Clusterről (nem keverendő a HA clusterrel, minden node ugyanaz a verzió legyen, upgrade fusson le előtte)
http://pve.proxmox.com/wiki/Proxmox_VE_2.0_Cluster
Általánosságban a HA clusterről (van benne link a 2 node-os megoldásra)
http://pve.proxmox.com/wiki/High_Availability_Cluster
2 node-os megoldás:
http://pve.proxmox.com/wiki/Two-Node_High_Availability_Cluster
Jelen esetben DRBD-vel demozza, de tökmind1, a 3 node-os leírás alapján csináld, a 2-node-os verzióból a fencing a lényeg 2 gép esetén.

Z

Köszi a linkeket, neki is esek az olvasgatásnak.

A SAN kezelésénél én is ezt találtam ki, csak azt nem tudom (nem ismerem az LVM belső működését), hogyha az egyik node-al létrehozok egy LV-t mert kell egy új virtuális gép, akkor a másik gép erről hogyan értesül, rájön, vagy szólni kell neki, esetleg újraindítani (az barátságtalan lenne).
Lehet meg is van a válasz (első körben rossz kulcsszavakra kerestem): CLVM. Az majd kiderül ez CentOs-al mennyire lejtmenet, mert a cluster támogatás kimaradt az új CenOs-ból, már-ha nem proxmox, hanem CentOs, és fapados virtualizáció. De a CLVM és Proxmox párosra is van találat.

Fogja tudni, nem lesz gond vele. Ha már clusterben vannak, onnantól a proxmox cluster intézi az LVM-es fejfájásodra a megoldást.
Alapvetően a lényeg h. a SAN-t lássa mindkét gép, az egyiken csinálsz egy virtuális gépet és a másik fogja látni.
A svédcsavar annyi h. előbb meg kell csinálni egy VM-et, majd utána tudsz belőle HA VM -et csinálni a webes felületen a doksi alapján. Van fent video is, amin elmagyarázza a srác h. hogy kell (pl. manuálisan kell először rgmanager-t elindítani), de nem vészes összerakni.

( ncc1701 | 2012. 02. 29., sze – 14:39 )

A Xen-nek azé én adnék egy esélyt.

( _ventura_ v | 2012. 02. 29., sze – 17:49 )

érdemes meglesni az XCP-t is, erre épül a xenserver.

Fedora 16, Thinkpad x61s

Van itt a főiskolán kettő (KMOP-ból), meg a SAN másik fele még két új Hyper-V szerveré, de a Windows az nem az én asztalom. Persze, ha feladom akkor az lesz belőle, de ha feladom, azt nehéz lesz sikerként elkönyvelni.
Nem mellékesen egy Windows licenc beszerzése bár egyszerűbb, mint bármi másé, de így is jelentős probléma.
Talán nem meglepő, de 3 nap szívás után, még inkább magamnak adnék esélyt és nem a Hyper-V -nek.

Ok. Ingyenes. Sikeresen beindítottunk egy népszerű mellék szálat, köszönhetően a tévedésemnek és annak, hogy lecsaptatok rá.
Halványan, de azért szerintem érthetően céloztam rá, hogy a nyílt forrású megoldásokat preferálom.
Köszönöm a helyreigazítást, és hálás lennék, ha ezt a mellékszálat a továbbiakban nem erőltetnénk.

Ezt írtad:
"Szóval valamilyen megoldás kéne. Vagy az ovirt-node installálására, vagy valamilyen más lehetőleg nem túl fapados virtualizációs környezetre, ami felmegy a szerverekre."

Ebben csak én nem látom a "nyílt forráskódú" kritériumot?
Nem a tévedésedre csaptunk le, csak javasoltunk egy olyan ingyenes alternatívát, ami jól működik, és nincs benne az ESXi-hez hasonlóan a max 32G memória korlát.

A Hyper-V server ingyenes, viszont nem minden linux disztró támogatott, de ha a linux szervereid benne vannak a support mátrix-ban akkor gyakorlatilag ingyen kapsz egy enterprise szintű virtualizációs technológiát. Ha nagyon linux irányba akarsz elmozdulni, akkor még adnék a helyedbe egy esélyt az Oracle VM server-nek, 2 fizikai CPU-ig ingyenes, az adatbázis amiben tárolja az adatokat ha Oracle XE akkor szintén ingyenes.

A Hyper-V Server licenc vásárlás nélkül, teljes értékű szoftverként használható.

Azt tapasztaljuk, hogy a 2.6.32-es kernel felett általában csont nélkül megy a dolog. Korábbi kernel verziók is szóba jöhetnek, de az azokhoz kiadott Linux Integrált komponensek (IC, vagyis paravirtualizált driverek) kicsit kevesebb fukciót tudnak. A 2.6.19-nél korábbi kernel verziókhoz úgy tudom, nincs IC.

Ha a RHEV elfuthat támogatás nélkül, akkor ez megállhat más gyártók esetén is. Márpedig a legfrissebb kernelek esetén már telepíteni sem kell semmit, egyszerűen a Linux felismeri, hogy milyen környezetben fut.

Összegyűjtöttem néhány linket, amely Linux on Hyper-V témáról ír.

http://wiki.centos.org/OzydeJong/HyperV
http://www.servercommand.org/content/hyper-v-centos-6-setup-networking-…
Hyper-V: Detailed Step-by-Step Installation of RedHat 6.1 VM in Expert Mode with the New Linux Integration Services 3.1
Installing Hyper-V Linux Integration Services v3.2 on CentOS 6.2
CentOS 2.6.37 kernel upgrade for Hyper-V Client drivers
Debian 2.6.36 kernel upgrade for Hyper-V Client drivers
Building your own Debian Kernel packages for Hyper-V Support

Egyéb iránt pedig itt egy jó, téma szerint csoportosított és frissen tartott linkgyűjtemény a Hyper-V-ről:

Hyper-V Survival Guide

Üdv:
Lepenye Tamás

( tompos v | 2012. 02. 29., sze – 20:57 )

Valoban szukseged van az GUI altal nyujtott extrakra?

tompos

Az, hogy a GUI vagy egy CLI hatékonyabb-e, az dönti el, hogy a felhasználó mennyire profi egy témában. Jelen pillanatban, ugyan igen jól elboldogulok a Linux-okkal és általában én is a parancssort részesítem előnyben, azért a virtualizáció terén nem számítok vérprofinak. Amíg nem tudom kisujjból kirázni az összes parancsot a kapcsolóival, addig jól jön egy GUI. Aztán idővel, ha megvan a kellő rutin, akkor jöhetnek a CLI parancsok, meg a scriptek is.

( STP | 2012. 02. 29., sze – 21:30 )

FC16 a "supportált" platform.
Vagy tökölsz, mert másoknak azért megy Centos|SL 6.2-vel.

Láttam én már olyat, hogy valaki howto-bol dolgozott, nem olyan nagy bűn az, bár nem tudom Te mit értesz ez esetben a személyre szabotton.
Persze neked sem ártana egy howto arról (akár személyre szabott), hogy mit is jelent a segítség, és mire való egy fórum.
És ha már szóba került, hogy mit szeretnék, akkor elmondom: Jó lenne, ha a hozzád hasonló nagy arcú megmondó emberek valahol máshol osztanák az észt.

Most őszintén.
Mond már el, hogy mit szeretnél.
Csináljam meg helyetted?
Ha feliratkoznál az ovirt levlistára, olvashatnád, hogy FC16-ra van az egész kitalálva, mivel ez az RHEV homokozója.
Van jó pár olyan függőség, ami miatt nem triviális az az alatti - RHEL|CentOS|SL 6.x-es - platform használata, igaz, nem megoldhatatlan. (Akinek van ideje, vagy...)
Ha számodra sértés, hogy az irányt írtam le, és nem a komplett megoldást, akkor nem leszünk cimbik. Így jártam.

Leírtam, hogy mit csináltam eddig. Ebből kiderül, hogy az FC16 belefagy a telepítésbe, itt le lehetett volna írni, hogy mit csesztem el, vagy lehetett volna adni egy tippet vagy linket, arra, hogyan kellett volna.
Ha jól sejtem az FC16 a ProLiant DL380 G7 valamelyik HW komponensén elhasal. A HP semmilyen infót nem add, mivel a Fedorát ők nem támogatják.
Leírtam, hogy az ovirt.org -ról letöltöttem a dokumentáció által javasolt CD képet, ami szerintem egy FC16/oVirt-node telepítő lemez, megpróbálkoztam a telepítéssel, itt ugyan nem fagyot le, csak közölte, hogy nem sikerült, és az arcomba nyomott több száz hibaüzenetet. Semmilyen utalás nem volt a hozzászólásodban arról, hol tévedtem, mit csináltam rosszul, vagy hogyan kéne továbblépni, és a dokumentációban sincs szó hibaelhárításról, vagy arról hogy lehet egyáltalán hiba.
Sehol egy kézzelfogható javaslat tipp, vagy link, mindössze annyi, hogy nőjek fel a feladathoz, ill. oldjam meg ahogy tudom.
Semmilyen (új) irányt nem írtál le, ha elolvasod azt amit írtam, akkor kiderül, hogy én is arra indultam.
Szóval rendkívül hálás lennék bármi nemű konkrét javaslatért. Viszont ha neked drágább az időd annál, hogy hülye gyerekeknek tarts virtualizációs fejtágítást, akkor ne pazarold a drága idődet arra, hogy válaszolsz. Ha pedig úgy érzed, hogy feltétlenül meg kell vitatni hozzáállásom, hozzáértésem és stílusom számodra botrányos színvonalát, akkor nyiss egy új témát, és fejtsd ki a véleményedet ott, ÉS NE ITT, ha kérhetem.

Hi,
Esetleg megnezheted, hatha talalsz valami infot itt:
http://fedoraproject.org/wiki/Common_F16_bugs

Illetve ezt is atolvashatod, hatha sikerul leszukiteni problemat:
http://fedoraproject.org/wiki/How_to_debug_installation_problems

Ha postolnad, hogy mik az error uzenetek az installalas folyaman, akkor talan tudna valaki segiteni. Melyik resznel fagy le etc. Install kozben nezd a logokat (Ctrl+Alt+F2)
Probalkozhatsz meg BIOS beallitasok modositasaval esetleg kernel opciokkal mint noacpi etc.

Neki futottam még egyszer, most megint a helyreállítási módban üdvözöl, ha boot-olok a telepítő CD-ről.
Találtam egy számomra érthetőbb leírást az oVirt-ről, ebből kiderült, amit csak sejtettem, hogy a tárolóhoz hozzáférés kell a menedzser gépnek is (és most már az is érthető minek kell alá egy erőmű), az pedig nem fog menni a jelenlegi hardverekkel, így az oVirt nekem nem lesz jó.

A helyreallito mod gondolom azt jelenti, hogy talal valamit a diskeken amirol azt hiszi, hogy neki azt helyre kell allitani.
Ha nem fersz hozza a rajta levo linux console-jahoz akkor bootolj egy live cd-t es dd if=/dev/zero of=/dev/disk-ed bs=512 count=1 (gondolom nem kell elmagyarazni, hogy ez a parancs veszelyes)
Ezutan nezd meg azt az install cd-t.

Amennyiben a tarolo alatt a shared storage-ot erted ( amin a virtualis gepek lesznek ) es a menedzser gepen az oVirt-m-et (RHEV-M) futtato gepet, akkor valamit elneztel abban a doksiban. A manager-nek nem kell (semmi ertelme) latnia a shared storage-ot. O csak a node-okkal beszelget normal halozaton es a node-okat hasznalja (jobban mondva te valaszthatod ki hogy melyik node "szemszogebol" keresse a shared storage-okat) amikor definialni kell a Storage domain-t.
(Bar nem volt idom kiprobalni az oVirt-et de jatszadoztam a RHEV3.0 betaval par napot)

A diszk kinullázása megtörtént, nem akartam, hogy az előtte telepített akármi bezavarjon (az elötte futó linuxnak ez volt az utolsó parancsa reboot elött). Bármilyen adatot csak a SAN-on láthatott (bár az egyik gépen elfelejtettem visszadugni az FC kábelt, de már nem emlékszem ezen-e).
A doksiban egy rajz volt, ahol az oVir-engine-t futtató gép is rá volt kötve a SAN-ra. Azt nem rajzolta oda senki, hogy muszáj, de volt egy ilyen sejtésem, és ebből úgy gondoltam, hogy annak is csatlakoznia kell.
Az oVirt szimpatikusabbnak tűnik mint a proxmox, clusterem ugyan már van, de az authentikáció nem kerek.
ui.: Újra megpróbáltam egy ovirt-node -t telepíteni, felment, egyetlen kernelparamétert változtattam meg: töröltem a quiet -et, nem hinném, hogy emiatt. Ja, és most nem töröltem az előző proxmox telepítést.

( _ventura_ v | 2012. 03. 02., p – 11:57 )

Ma talán odáig eljutok hogy feltelepítem a F16 ot meg rá az oVirt-et, a node-ok majd talán holnap.

Fedora 16, Thinkpad x61s

( csfeco | 2012. 03. 09., p – 10:00 )

A helyzet az, hogy feladtam, abban a tekintetben, hogy Linux alapú virtualizáció legyen.
Az oVirt nem futott a virtualizációs node-okon, több komponense elszállt (sig11-el).
Az RHVE 3 (majdnem ua. mint az oVirt) rendesen települt, látszólag összebeszélt a manager és a node, de a manager szerint a node "non-responsible" a doksi megemlíti, hogy ez van, ha kikapcsoljuk a node-ot.
A proxmox simán települ, de hegeszteni kell a tárolók miatt, lehet, hogy csak több elszántság kellett volna (de az elment az oVirt-re).
A Hyper-V negyed annyi idő alatt működőképes, mint amennyit a fenti rendszerekre elszúrtam.
Gondolom most néhány Windows huszár elégedetten hümmög...
Nem örülök az eredménynek, de muszáj volt eredményt produkálni. Azok az alapvető beállítások, amik egy linux-on rutinból mentek, itt. néha rémálomnak bizonyulnak. Azt ugye senki nem említette itt, hogy az ingyenes Hyper-V nevéből nem véletlenül hiányzik a windows. Addig ok, hogy távolról sok minden beállítható, de nem minden, a Hyper-V szerver (helyi) kezelő felülete szerintem felér egy kicseszéssel.
A hálózat konfigurációja pedig szerintem egy őskáosz. Addig OK, hogy a Hyper-V kezelő felületén tiszta és világos, de ott egy pár dolog nem érhető el, ellenőrzéskor pedig jól megreklamálja azokat az alapbeállításokat, amiken a GUI-ban nem is lehet változtatni, ha tudja mi a jó, akkor miért nem azt állítja be? Az nvspbind paranccsal kellene bohóckodni, ami persze nem alap parancs, le kell tölteni. Aki viszont itt be tudja azonosítani az összes interfészt az jóval nagyobb zseni mint én.
Tehát addig nagyon könnyű eljutni, hogy működjön, de ahogy mondani szokták az ördög a részletekben van, és itt szerintem tényleg ott van. És persze nem kis része volt a Hyper-V győzelméhez annak a körülménynek, hogy házon belül volt kitől kérdezni, és a Windows-os infrastruktúra rendelkezésre állt, nekem az adminisztrátor programokkal csak annyi dolgom volt, hogy megtaláljam a menüben.
Ha lenne időm ezzel foglalkozni (tanulni és hegeszteni), akkor biztos maradtam volna egy Linux-os megoldásnál.

Vagy cmd-ul. A halozati beallitasok - meglepo modon - a netsh parancs okszeru hasznalataval allithatoak be, eleg reszletes szinten, ahogy emlekszem. Raadasul a netsh kepes az interfeszek kiirasara is.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Sok minden kaphatott volna esélyt, és az néha nekem is jól jönne.
De kb. 3 témát jegeltem, amiknek már rég kész kéne lennie, vannak napi feladatok, mag feladatokat kiagyalók, és biztos meglepő, de nekem is 24 óra egy nap. Sőt, ha igaz, akkor a munkaidőm ennél rövidebb.

Azért nekem sikerült egyszer 45 percet lenyomnom úgy az egyik virtualizációs konferencián, hogy azt mutattam, amire nem képes a Hyper-V, a KVM/qemu/libvirt trió pedig igen :) És kb a 2 nodeos klasztert - meg a harmadik gépen a storage-ot - úgy raktam össze, hogy kb 3 órámba került. OK, nem először csinálok ilyet, meghajtottam már én is korábban a szopórollert, de azért el elhet viselni, jó doksi van hozzá. Van benne VLAN, rendes memória, és hálózatkezelés, USB support :) hot-add diskek és nic, meg stb. jah, pacemakerrel ezt is simán betolod klaszterba.

Az elmúlt 30 évben elég sok helyen dolgoztam, és mindenhol meg voltak elégedve a hozzáállásommal. Versenyszférában alkalmazottként, rövid ideig tulajdonosként is, dolgoztam egyetemen, kutatóintézetben, jelenleg egy főiskolán. Még azt sem lehet kizárni, hogy több tapasztalatom van mint neked.
Rész igazságokat mondasz, és egyáltalán nem vagy tisztában a konkrét körülményekkel.
A közszférában rengeteg fél hülye dolgozik, ezt még nálad is jobban tudom, aki meg megpróbálja jól végezni a munkáját, az küzdhet mint disznó a jégen.

Azért a windows license miatt olvass vissza, mert a Hyper-V Server még mindig ingyenes és nem kell hozzá windows license.Ha meg a guest-ekre gondolsz, az meg lehet, hogy régebb óta megvan, amikor még volt rá keret. Viszont a mondatod első felével teljesen egyetértek, nem kell beleugrani egy projektbe ha nincs meg mindenre a pénz.

Ezek szerint Te sem vagy tisztában azzal, hogy mi folyik a közszférában.
Általában néhány havonta csinálunk egy, három, öt vagy akárhány éves fejlesztési tervet. Ezek közül random módon elfogadnak néhányat, így ezek között lesznek átfedések és lyukak jócskán. Erre rájön a a megszorítások miatt a pénzek zárolása (tök mellékes, de most is érvényben van egy). Továbbá időnként izibe el kell költeni pár milliót, ami persze szintén random módon valósul meg, és nem lehet akármire költeni, be kell tartani néhány piszok ésszerű szabályt, és az, hogy éppen mire van szükség, az másodlagos.
Tehát, ha kiderül, hogy egy projekthez hiányzik valami, akkor azt utólag beszerezni, értelmes, vagy tervezhető határidővel egyszerűen lehetetlen. Jelenleg a 4 szerveres és egy 4T-as SAN-os projekthez hiányzik 2 transceiver (szerencsére csak a redundancia miatt), és kb. 100m UTP fali kábel. Talán fali kábel lesz, de nem tudni mikor, addig vezethetem a biteket kézen fogva a switch-ig vagy kitalálhatok amit akarok. (Kábelt többször is kértem, de az elveszett a bürokrácia útvesztőibe).
Tehát licenc lehetne, de rosszul és amatőr módon álltam hozzá, vagyis úgy gondoltam, hogy valamelyik nyílt forrású megoldást használom, ezzel is spórolva az adófizetők pénzén (belátom, totális baromság). Sőt, amikor többször rákérdeztek, hogy "Microsoft licenc nem kell ?" akkor elég lett volna annyit mondani, hogy "Ja, de.". Aztán használom ha kell, nincs abban semmi, a Linuxos munkaállomásomon is ott virít a COA címke.

akkor megint ott tartunk, hogy tajekozatlan modon nekialltal egy projektnek, es _utolag_ probaltad felmerni, hogy mit lehet kezdeni. nem baj ez, mindenkivel megesik, csak erdemes elismerni.

ha elore megkerdezed, elmondjuk, hogy gagyizni jok az ingyenes megoldasok, de ha komolyan akarod tolni, akkor nem annyira. (*)

a sporolas mar ott buzlik amugy, hogy FC SAN -nal szamoltal. persze, az a legjobb megoldas, csak ha valasztanom kell, hogy szuper hardverem van, de szoftverileg meg vagyok love, vagy kevesbe jo hwm van (iSCSI jut eszembe hirtelen, nem az ordogtol valo az sem...), de kiraly a szoftverem, akkor en a masodikat valasztom.

*: azt elismerem, hogy a pontos felhasznalasi kovetelmenyek mellett akar eleg lehet valamelyik ingyenes megoldas is. live migration nyilvan nem lenne rossz, ezt mar tudja szinte minden (a securityrol azert ne beszeljunk, irto gagyi ahogy meg van csinalva OpenStack alatt, pl), viszont annyira kiraly virtualis halozatkelezest, mint amit a VMWare nyujt, meg _sehol_ nem lattam.

Nem tudom, hogy az ingyenes ESXi is tudná e kezelni azt a "király virtuális hálózatkezelést", de ha csak a fizetős megoldással tudja(vCenter) akkor az összehanonlításod nem állja meg a helyét, mert az SCVMM-nek is van olyan jó hálózatkezelő része mint a VMWare-nek, csak ezért már fizetni kell (PS-ből szinte bármit nem tudsz csinálni csak nagyon kell érteni hozzá). Jó volna az almát az almával összehasonlítani és úgy nyilatkozni, ha viszont tudja az ESXi is akkor elnézést nem ismerem VMWare licenselését, elég volt az MS-t megérteni az se egyszerű.

Szerintem itt és most zárjuk le a vitát, mert meddő és inkább a flame témakörbe tartozik.
Soha nem állítottam, hogy nem követek el hibákat, vagy hogy olyan tökéletes vagyok mint Te, és semmi kedvem minden részletet elmesélni, csak azért, hogy az élvezetből kötözködőknek kellően beszűkítsem a lehetőségeit.
Egyezzünk meg abban, hogy te győztél. Ha válaszolnál, megígérem le fogom szarni, így az utolsó szó is a tiéd lehet.