Proxmox ingyenes verzió megbízhatósága

Virtualizáció

Mennyire jelent problémát, hogy az ingyenes Proxmox egy testing ág? A fizetős verzió árait otthoni gépre túlzásnak tartom, akkor inkább magam építek Debian-ra virtualizációs környezetet. 
De ha komolyabb probléma nincs az ingyenes Proxmox-szal akkor természetesen kényelmesebb választás. 

  • 1419 megtekintés

( hrgy84 | 2025. 10. 06., h – 18:45 )

Nincs komolyabb probléma vele, mi az ingyenest használjuk házon belül virtualizációra, mert nincs szükség a fizetős plusz funkcionalitására, és teljesen stabil. De mondjuk az igaz, hogy nekünk nincs olyan szolgáltatásunk élesben, amin emberéletek múlnának, oda nem ezt javasolnám. Minden másra: nyugodtan használd.

Blog | @hron84

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

via @snq-

Úgy tudom nincsenek plusz szolgáltatások a fizetős Proxmoxban, a hivatalos supporton kívül. Egyébként az a lényeges különbség, hogy az ingyenes az a testing ág még a fizetős stable. Mivel Debian alapú rendszerről van szó fontos megjegyezni, hogy ez csak a Proxmox saját csomagjaira áll, azok vannak teszt ágból az ingyenesben még az alap Debian az ingyenesben is stable. 

Ez milyen hibákat tud okozni és milyen gyakorisággal? 

A fizetősben egy extra dolog van tudtommal, az pedig a HA (automatikusan átterheli a VM-eket leállításnál pl, illetve van funkció "drainelni" a node-ot)

Eddigi tapasztalataink szerint semmilyet. A cluster maga atomstabil, a VM-ek jönnek-mennek rajta, nem tudnék semmilyen olyan hibát felhozni, amit kifejezeten a "testing" jelleghez tudnék kötni. 

Blog | @hron84

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

via @snq-

A teljes HA funkcionalitás és a klaszteren belüli dinamikus erőforrás menedzsment is része az ingyenes Proxmox-nak. Tényleg csak az alaposabban tesztelt csomagtároló és az elérhető support a különbség.

A 8.x valamelyikben vezették be, hogy van maintenance mód a node-on, és akkor automatikusan migrálja a VM-eket más node-okra és mindaddig nem teszi vissza rá, míg ez a mód aktív. Azt, hogy leállításkor és újraindításkor ezt megtegye, már a 7.x-ben is benne volt.

Az a Proxmox érdekessége, hogy akkor is tud élő migrálást (persze jó lassan, sok idő alatt), ha nincs közös, osztott tároló. Meg akkor is, ha csak ZFS replikáció van igazi osztott tároló nélkül. A Proxmox Datacenter Manager (igaz, ez még nem production ready) tud klaszterek közötti élő migrációt is, ugyan így akár közös osztott tároló nélkül is.

( x-daemon | 2025. 10. 06., h – 19:33 )

en stabil debianra epitem a virtualizacios kornyezetet, ha a libvirt tudasa megfelel neked, akkor az is jarhato ut lehet.

nem tudom milyen szempontjaid vannak, de nem a kenyelmet helyeznem elore.

neked aztan fura humorod van...

( Proci85 v | 2025. 10. 06., h – 20:57 )

Évek óta használom éles környezetben. Semmi gond nincs vele. Persze nem kell elsők között nagy verziót váltani. Jó ha van backup. Érdemes alacsony prio-s géppel kezdeni a frissítést, és a kritikust a végére hagyni. Ha valami gixer van, addigra kikeresed a neten. Én teljesen elégedett vagyok a Proxmox-szal.

Nagy verzióváltásoknál azonnal megszűnik ingyenes Proxmoxban a korábbi verzió támogatott státusza, vagy egy ideig van átfedés támogatásba? 

"Érdemes alacsony prio-s géppel kezdeni a frissítést, és a kritikust a végére hagyni."

Ezt hogy érted? Alacsony prios guest ? Egy félresiketült proxmox frissítés maradandó hibát okozhat a guestekben? 

Az nem tudom mennyire működőképes lehetőség, hogy tartok egy másodlagos proxmox rendszert csak azért, hogy rendszeresen leszedjem a frissítéseket, és apt cacheből lementsem a deb csomagokat. Utána azokat teszem fel az élesben használt Proxmox rendszerre amelyek bekerülnek a fizetős ágba frissítésként. 

"Nagy verzióváltásoknál azonnal megszűnik ingyenes Proxmoxban a korábbi verzió támogatott státusza, vagy egy ideig van átfedés támogatásba?"

Sosem néztem ezt így pontosan, de nem éles váltás van. Van, hogy 1 évig még régit használom, mint pl. most is.Nyáron kijött az új proxmox, de a korábbi kiadáshoz folyamatosan jönnek a frissítések. A debian alaprendszer miatt egyértelmű, de proxmox tárolóból is.

 

"Ezt hogy érted? Alacsony prios guest ?

Vállalati környezetben van dev, test, prod környezet. Jó esetben mindegyik proxmox alapokon. Előbb dev VM-eket futtató, majd test VM-eket futtató proxmoxot frissítem. Aztán prod-ok között is van lazább és igazán kiemelt. Na őket frissítem utoljára. Addig remélhetőleg bármilyen felmerülő problémára ott lesz a kézikönyv. Ezt nem proxmox miatt csinálom, de ott is alkalmazom. Nem is emlékszem, hogy proxmox-nál mikor volt utoljára galiba egy frissítés után. Nagyon régről, 10 éves távlatból dereng olyan, hogy a dist-upgrade leszedte a pve kernelt, ezért nem mentek a VM-ek. Nyílván kiiírta a konzolra, hogy mit fog csinálni, de nem tűnt fel. Régi kernelről vagy livecd-ről bebootoltam, chroot és felraktam. Más nagyon nem is rémlik.

Sok száz VM alatt használom éles környezetben hostingban, KKV-ban, kiemelt területeken is. Utóbbinál nem feltétlen a proxmox-szal csinálom meg a magas rendelkezésre állást, hanem az alkalmazott szoftvernek fut aktiv-passzív párja egymástól akár 100km-re egymástól. Az elv meg hasonló, mint egy openvpn client connect. Ha az első szerver cím nem megy, lép a második címre. A váltásból adódó kiesés meg belefér.

 

"Egy félresiketült proxmox frissítés maradandó hibát okozhat a guestekben?"

Nem. Elképzelni sem tudnék ilyen esetet. Egy raw image LVM-en. Rommá lehet konvertálni, tekergetni, az adat ott van. Baromi kezes az egész virtualizáció emiatt, mert standard linux toolok ott vannak a kezedben. Legutóbb xenserver image export -> convert raw image -> dd to LVM (proxmox) konvertálást csináltam. Simán ment linuxos VM-mel.

Nálunk két cluster van, PROD meg ETC (a többi... :D ), mert nálunk tényleges PROD környezet csak a saját belső rendszereinknek van (git, ticketing, wiki, stb) az összes többi csak fejlesztői "játszótér" úgymond. Az igazi éles, fontos cuccok az ügyfélnél futnak.

Szétontásnál arra érdemes figyelni, hogy régebben volt olyan bugja a Proxmoxnak, hogy nem szerette, ha nagyon sok node van egy clusterben, most ez redukálódott arra, hogy mindenképpen páratlan számú node-nak kell lennie (ez egy cluster a nap végén!), különben nincs meg a quorun és sír miatta. De van egy egyszerű trükk, ha csak páros számú (pl: kettő) géped van, felraksz VM-be egy proxmxoot (elég neki egy pici VM) és belépteted a clusterbe. Nagyon ritkán omlanak össze a node-ok annyira, hogy ez így gondot okozzon, akkor meg már úgyis több bajod is lesz, minthogy ez az arbitrator node nem elérhető.

Blog | @hron84

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

via @snq-

Még mindig elérhető a qdevice, mint quorum pótló lehetőség, ami egyetlen, apt-tal telepíthető szolgáltatás egy alap Debian Linux-on. Ezt akár egy RPi-re is fel lehet tenni, hogy ne valamelyik node-tól függjön a működése. De szerintem sokkal egyszerűbb és hasznosabb simán páratlan számú node-ot tartani. A gyári leírásban is azt javasolják, hogy ezt csak akkor használjuk, ha összesen két node van, mert kell valamilyen szintű HA, de nem kell több erőforrás, így több igazi node.

Nem, mert akkor két szavazat veszik el és marad az az egy "igazságnak". 

Ha a quorumos node szeparálódik el pl network miatt de nem "fagy le" akkor meg azoknak ketten "van igaza".

Lényeg az hogy nincs split-brain szituáció ahol szavazategyenlőség alakulhatna ki.

zászló, zászló, szív

A Proxmoxot nem ismerem, úgyhogy kérdezek.

  1. Honnan tudja az egyedül maradt node, hogy "neki van igaza"?
  2. Ha háromból egy node működőképes marad, akkor mi van akkor, ha mondjuk egy network issue miatt nem lát rá a másik kettőre, és különutas node tovább működik, miközben a másik kettő is, párban?

Nem a network a lényeges része a kérdésemnek, lehet, félreérthető voltam.

Ha jól értem, kb. az volt az állítás, hogy a 3 node-ból kettő elérhetetlen (a harmadik szerint), ilyenkor a harmadik tovább működik önállóan. Ilyenkor mi történik? Nem az lenne a quorum lényege, hogy ha 3 node-ból kettő eltűnik, akkor a minority node nem kezd partizánkodni?

A cluster tagok tudják hogy hányan "kéne lenniük" és hogy "megvan-e a többség". 
Ha nincs meg a többség akkor read-only lesz az adott node, nem kezd el partizánkodni.
Ha te mint admin tudod hogy "neki van igaza" akkor "pvecm expected 1"-el megadhatod neki az írásjogot.

zászló, zászló, szív

( gattila | 2025. 10. 07., k – 00:45 )

Én itthon a Node-okat standalone futtatom. Nincs licensz. A VM-ek legalább 2 node-on futnak párhuzamosan.

Egy reverseproxy balance-ol közöttük health check-el. Így frissítéskor nem okoz gondot az sem, ha lehalna a node. Mondjuk még nem volt ilyen szerencsére, de az is igaz, hogy nemrég valtottam hyperV-ről.

Azért az biztos  hogy a VMware-rel nem lehet egy lapon említeni. Az más szint. Mondjuk annak az árához képest az 1000 dolláros proxmox csomag is ingyen van.

A 100 usd/socket/év supportot azért már kkv szinten mindenképpen pofátlanság nem kifizetni.

annak az árához képest az 1000 dolláros proxmox csomag is ingyen van.

Nem világos, miért. Kb annyi, mint a vSphere Standard 16 magra, ami kiforrottabb és 24x7-es támogatást kapsz hozzá. (Proxmox nem 1000 USD, hanem 1060 EUR, ami egyre kevésbé elhanyagolható különbség, konkrétan több a VMware-nél)

Én személy szerint drágállom a Proxmox támogatást. 115 /EUR /év-ért mindössze "community support" jár. 355 EUR-ért is csak 3 hibajegyed van évente, az is NBD. Az 530 EUR-os csomag tartalma közelíti a vállalatilag elfogadhatót/értelmezhetőt, de drága. Szerintem ezen dolgozniuk kellene. Persze ha annyi munkát ad, hogy csak így rentábilis, az más kérdés.

Hát, izé...

vSphere Standard subscription pricing is based on a 72-core minimum, effective April 10, 2025, with the minimum annual subscription cost approximately $3,600 (or around $50/core) based on the new minimum, replacing the older 16-core minimum.

vSphere Standard is now sold with a minimum of 72 cores. Licensing is still 16-cores per CPU, there are just also solution minimums.

Remélem elnézed nekem, hogy 2 sorban nem végeztem teljes TCO elemzést különféle környezeteket feltételezve.

Ha egy szervered van, nyilván más a leányzó fekvése, ráadásul igen, a Standard valószínűleg meg fog szűnni.

A lényeg az, hogy általánosságban erőteljes csúsztatás, hogy a Proxmox prémium kvázi ingyen van a VMware-hez képest. Ezzel a kijelentéssel még a vSphere Foundation esetén is óvatosan bánnék, főleg ha nemcsak az összeget, hanem a tartalmat is nézzük (mind a termék, mind a szolgáltatás vonatkozásában).

Én viszont utána néztem most már, hogy így szóba került. És nem a Proxmox védelmében - mert én spúrként jól elvagyok az előfizetés nélküli community support verzióval is probléma manetesen sok éve - hanem azért, mert ha tényleg ilyen kicsi lenne a különbség, akkor nem "cikkeznének" sokan arról, hogy váltani kell valamire a VMware-ről a magas költségek miatt.

No, 5 perc kereséssel azt találtam, hogy vSphere Standard nincs, helyett a vSphere Foundation-t lehet venni előfizetni. Erre is vonatkozik a minimum 72 core licenc vásárlás függetlenül attól, hogy mondjuk csak 1 db 16 magos gépen akarom futtatni. A vSphere Foundation kiegészítve a Production Support (7/24) lehetőséggel listaáron 150 USD/core/év, tehát 10800 USD/év (~3.6 millió/év) a minimum induló költség (gondolom alku, több éves vállalás, stb. előtt).

Nyilván ennyi pénzért többet tudónak kell lennie a terméknek és még jobbnak a supportnak. Ez nem kérdés. De ez már nem az a szint, hogy ezt mindenki dalolva ki tudja fizetni. Ahogy olvasom, az is a Broadcom célja, hogy a kis ügyfeleket lepattintsa, és csak a nagyok maradjanak.

Képben vagyok nemcsak a cikkezésekkel, hanem a frontvonallal is.

Én megértem, hogy stabilan megy az ingyenes Proxmox is, én nem is ezt vitattam, nem erre reagáltam.

Számolás előtt kérlek olvass: "(a VMware) árához képest az 1000 dolláros proxmox csomag is ingyen van."

Ha almát nem is lehet almával összehasonlítani, 3 alma mellé legalább 3 körtét vegyél, ne egyet.

72 mag helyett vegyünk 96-at, az 6db CPU, 3db szerver 2db 16 magos CPU-val.

Proxmox esetén 6db CPU ára 6360 EUR /év

VMware esetén 14.400 USD, ami ~12.400 EUR /év

Bárhogy is nézem, az 6360-at nem érzem ingyenesnek a 12400-hoz képest, konkrétan az sem mondható el, hogy fele annyiba se kerül. A funkcionalitást, kezelhetőséget, kiforrottságot, támogatási szintet hozzálapátolva pláne nem.

Téged idézve: a 6360 EUR/év sem az a szint, amit mindenki dalolva kifizet. De akinek egy szervere van 1db CPU-val, gyanítom az sem fog dalolva kifizetni 1060 EUR-t minden évben. Most elvileg van ingyenes ESXi, egy szerverre fel lehet tenni, de akár kettőre is.

Ezzel nem azt állítom, hogy olcsó a VMware, hanem azt, hogy drága a Proxmox Premium támogatása.

Ami technikailag érdekelne, hogy Proxmox alatt miként csináltok redundáns hálózatot, ha nincs LACP (van két hálókártya, mindegyik másik switch-be kötve, nincs stack/MLAG), VM-eknek, Proxmoxnak is redundáns uplinkje legyen, több VLAN? Azt tapasztaljuk, hogy a Proxmox interfésze (amin a Linuxot éred el) szakadozik csak OVSBridge-et használva, OVSPatchPorttal mintha jó lenne. Van jobb/egyszerűbb megoldás? (VMware-ben ez kb két kattintás és STP-vel nem is kell foglalkozni)

Szia, meg tudnád adni, hogy hol lehet ilyen olcsón vmware-t venni, vagy melyik ez a termék, mert akkor vennék én is belőle. Köszi!

(A két termék különböző vállalati szegmensben használható, Ha a cégnek olyan üzletmenete van, amihez magas rendelkezésre állás kell vm-k esetében, akkor azt érdemes vmware alapon kiépíteni, mert ebben a vezető termék, de erre sok esetben nincs szükség, és szolgáltatási oldalról, más platformokon virtualizációs platformokon is el lehet érni olyan rendelkezésre állást, ami megfelelő az üzleti oldalnak. Azt is érdemes megjegyezni, hogy egy VMWARE környezetben nem biztos hogy a licenc ára lesz a probléma, hanem inkább az, hogy HCL szinten is megfelelj, ami extra költség.)

Ennyiért sehol. Csak bíztam a kollégában, hogy jól néz utána, de inkább 210 USD/mag/év körül van/volt az ár a saját anyagokat átnézve. Pontos árat nehéz adni, mert projekt alapon megy, egy darabig volt 3 éves ár, ami sokkal kedvezőbb volt, most nincs.

Azaz a helyes összehasonlítás: 96 mag: 20.160 USD, ami ~17.400.- EUR.

A 6.360 EUR-hoz képest elmondható, hogy a fele se, de a harmada már nem, én ehhez képest is fenntartom, hogy a Proxmox Premium túlárazott és közel sincs ingyen hozzá képest.

 

Szerk: akkor már legyen teljes a kép: a Standard esetén 65 USD/mag/év árral lehet számolni, ami 96 mag esetén 6240.- USD, azaz ~5400 EUR, ami olcsóbb, mint a Proxmox Premium, az eredeti állítás erre vonatkozott. Elvileg még pont rendelhető a Standard.

Szerintem ebben a szálban ott "beszélünk el egymás mellett", hogy aki a Proxmox felé fordul, az nem az 1000 EUR-os support előfizetéssel számol, hanem max. a 100 vagy 350 EUR-ossal (vagy leginkább az ingyenessel). Értem, hogy azt kell árban a VMware-hez hasonlítani, mert Proxmox esetében az az elérhető legmagasabb support szint (ami még így sem éri el a VMware support-ot), de ott, ahol a support ilyen súllyal szerepel a döntésnél, fel sem merül a Proxmox (véleményem szerint).

A VMware baja (igazából nem az övék, a kisebb felhasználóké) az lett, hogy a kisebb cégek nem igénylik a tudás és a support ilyen szintjét, de nekik is ki kell fizetni, ha ezt akarják használni, mert nincs egyszerűbb terkék a kínálatban.

Azért a 6k vs a 12k (most kerekítettem) az egy mocsok nagy ugrás, ha kikonvertálod forintra, de még USD-ben is mocsok sok. Ráadásul ez ugye előfizetés, az adózási szempontóbl a rosszabbik féle költség a cégnek, ha én valahol vágok 6k -t bármelyik cégnek, a lábam nyomát megcsókolják.

Szóval, valóban nincs ingyen, de egy cégnek ez a különbség azért bizony számít, többet is mint hinnéd.

Blog | @hron84

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

via @snq-

Igen, nagy különbség, de a kosárban levő tartalomban is nagy különbség van, így a 6k vágás sem egyértelmű.

Van, ahol az előfizetést preferálják.

"egy cégnek ez a különbség azért bizony számít, többet is mint hinnéd." - tényleg? mik vannak. nem is gondoltam volna. ezen gondolkodom. köszi.

Értem amit írsz. Én sohasem gondolkodok a Proxmox support-ban, mert amit nem tudunk megoldani, azt valaki más meg tudja (neten). Az a jó, hogy teljesen nyílt, szabványos elemekből áll a Proxmox, így nem olyan nehéz hibát keresni, mint a sokszor fekete doboz proprietary szoftvereknél, aminél nem mindig egyértelmű, mi mért történt. Ráadásul a Proxmox előnye, hogy maga a cég nagyon gyorsan reagál a felhasználók által fellelt hibákra, napokon max. belül javítottak eddig mindent, ami bárhol felmerült és többeket érintett.

Így az én nézőpontomból nagyon drága a VMware bármennyiért az ingyenes Proxmox-hoz képest 5-10 fizikai szerverig (nagybb rendszerekkel nem dolgozok jelenleg). Nyilván ha van compliance igény, ahol fel kell mutatni a support-ot, az más kérdés. Ahol meg ennél több gép van, ott már úgy is olyan az IT költségvetés, hogy lehet "drága" fizetős szoftvereken gondolkodni. Nyilván mi, KKV-s üzemeltetők nem a multik IT-saként gondolkodunk a termékekről.

Én nem használom az OpenVSwitch-et, csak sima Linux építőkockákat, és a bonyolultabb konfigot kézzel írom, nem a Proxmox GUI-n sakkozom össze.

Két helyen is úgy működik atomstablian amit kérdezel, hogy Linux bond failover (active-passive) módon a fizikai interfészeken két külön switch-re (nincs MLAG; ha nincs LACP-MLAG, akkor úgy se lesz teljes sávszél kihasználás), és vagy a bond-on vannak a vlan-ok és a vlan-ok különböző bridge-ekben, vagy a bond-ok a bridge-ekben amik vlan aware (hol hogyan használják szívesebben a vlan-okat).

Az egyik Ceph megoldásnál a 2x 10 GbE úgy van konfigolva, hogy a fizikai interfészeken vlan-ok, a vlan-on active-passive bond-ok úgy, hogy az egyik vlan esetében az egyik kártya a master, a másik vlan-nál a másik kártya a master, így amíg mindkét kapcsolat él, addig 2x 10 Gbps sebességgel mehet a kommunikáció (valamiért nem akart az ügyfél több 10 GbE kapcsolatot anno, nem emléxem miért). Az így kialaklult bond-ok meg a Ceph public és replication network-ök. A gyakorlatban ez a rendszer eddig 3-4 Gbps-nél feljebb nem replikált és VM oldalon sem volt 3 Gbps-nél nagyobb igény a Ceph felé, úgyhogy ennél a rendszernékl ez a megoldás féllábas működésnél sem okozna észrevehető lassulást. De persze ahol NVMe diszkek vannak OBS-nek, vagy magas IO-val futó VM-ek, ott ez a trükközés nem játszik, vagy lesz hátránya hálózati probléma esetén.

Amivel az OpenVSwitch többet tudna a "gyári" lehetőségeknél (pl. vxlan), arra eddig nem volt sehol szükség, így arról nem tudok éles könyezeti tapasztalatokat megosztani. De amit írsz, ahhoz lokális hálózat esetén, nem is kell OVS.

Két helyen is úgy működik atomstablian amit kérdezel, hogy Linux bond failover (active-passive) módon a fizikai interfészeken két külön switch-re (nincs MLAG; ha nincs LACP-MLAG, akkor úgy se lesz teljes sávszél kihasználás), és vagy a bond-on vannak a vlan-ok és a vlan-ok különböző bridge-ekben, vagy a bond-ok a bridge-ekben amik vlan aware (hol hogyan használják szívesebben a vlan-okat).

Köszi ezt megnézetem, ennek kapcsán látom, hogy ehhez (aktív-passzív bond) nem is kell switch támogatás. balance-tlb és balance-alb-t nem használtok? (ahhoz sem kell switch támogatás)

A "a bond-ok a bridge-ekben" felállást miként kell elképzelni? Úgy gondolnám, hogy csinálsz bond-ot akárhány interfészből, aztán arra pakolsz bridge-t, amit a VM-eknek be lehet állítani. És a akkor a bridge arra megy, amerre a bond küldi. Vagy rosszul értem? 

Nem használjuk a többi módot, csak az aktív-passzív vagy LACP (+MLAG) ahol elérhető.

A bond-ok a bridge-ekben úgy értem, hogy a bridge member interfészek a bond-ok. Ilyenkor a bridge-nek vlan-aware kell lenni és a VM-nél be kell állítani a vlan-t.

A másik lehetőség (volt, ahogy így kérték) az, hogy a bond-on vlan van, és a vlan kerül a bridge-be member inerfésznek, így nem kell vlan-aware bridge, és nem kell vlan-t állítani a VM-nél, hanem a kiválasztott bridge dönti el, hová csatlakozik a VM.

"Ami technikailag érdekelne, hogy Proxmox alatt miként csináltok redundáns hálózatot, ha nincs LACP (van két hálókártya, mindegyik másik switch-be kötve, nincs stack/MLAG), VM-eknek, Proxmoxnak is redundáns uplinkje legyen, több VLAN? Azt tapasztaljuk, hogy a Proxmox interfésze (amin a Linuxot éred el) szakadozik csak OVSBridge-et használva, OVSPatchPorttal mintha jó lenne. Van jobb/egyszerűbb megoldás? (VMware-ben ez kb két kattintás és STP-vel nem is kell foglalkozni)"

Egyrészt: ezt annyira részletkérdésnek érzem hogy na...
Másrészt: a hálózati redundanciát oldjuk már meg hálózati eszközökkel.
Harmadrészt: az esetek jó részében nem is a fizikai hálózati redundancia számít hanem a "service level redundancy" az meg megint csak nem a virtualizáció dolga. Persze oké ez protokollfüggő, mondjuk egy sambának tényleg kell a hálózati redundancia, de egy ceph-s3-nak már nem, vagy nem úgy.

zászló, zászló, szív

Nálunk nincs baj az OVSBridge-gel, bár őszintén: nem én konfiguráltam a hypervisorokat, úgyhogy nem tudom elmondani, mi a titok, de ha nagyon érdekel, rákérdezek. Supermicro blade szervereken üzemeltetünk, ott adott a LACP lehetősége, élünk is vele, és őszintén szólva úgy gondolom,  hogy ha a redundancia fontos, akkor nem is szabad elspórolni. Gyakorlatilag egy virtualizációs környezetben az uplinket nem LACP-vel csinálni hülyeség. 

A hypervisoron belül a VM-ek tagelt VLAN-okon kommunikálnak, így a hálózati izoláció meglehetősen alacsony szinten már megvalósul.

Blog | @hron84

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

via @snq-

Nálunk nincs baj az OVSBridge-gel, bár őszintén: nem én konfiguráltam a hypervisorokat, úgyhogy nem tudom elmondani, mi a titok, de ha nagyon érdekel, rákérdezek.

Megköszönöm.

Gyakorlatilag egy virtualizációs környezetben az uplinket nem LACP-vel csinálni hülyeség.

Ez így azért nem állja meg a helyét.

VMware esetén (ami szintén virtualizációs környezet) biztosan nem, mert LACP-hez DVS is kell, amire sok esetben biztosan nincs (nem volt) keret, így más szempontok alapján kell eldönteni, hogy a switch esetén megéri a stack/mlag a felárat vagy sem. Továbbá ott a beacon probing, ami jól teszi a dolgát, felár nélkül. Proxmox esetén jobban meggondolandó lehet, bár elvileg az arp_* paraméterekkel ez ott is elérhető, ezt még tesztelnünk kell.

Másfelől az LACP-nek is vannak korlátai, kevésbé rugalmasan lehet forgalomirányt dedikálni (ESXi esetén elég könnyen meg lehet mondani, melyik forgalom melyik hálókártyán menjen elsősorban), illetve iSCSI esetén teljesen felesleges (sőt, nem is javasolt), protokoll szinten megoldja. Proxmox esetén az iSCSI pont kevésbé releváns talán, nem tudom, mennyien nyomják zfs-over-iscsi-vel.

Azért az biztos  hogy a VMware-rel nem lehet egy lapon említeni. Az más szint. Mondjuk annak az árához képest az 1000 dolláros proxmox csomag is ingyen van.

Na igen, a VMware amatőr liga a KVM-hez képest. Nem véletlen, hogy egyik AAA kategóriás felhőszolgáltató sem VMware-re építi a felhős infrastruktúráját. 
Amazon, Google, Microsoft(ők persze a saját Hyper-Vjüket használják)

Mivel a hupon úgy szeretjük az autós hasonlatokat, saját mérnökcsapattal megvalósított felhős infra Linux világban elérhető opensource kódra alapozva a Formula1-es versenyautó. Tökéletesre optimalizált egyedi építésű, saját igényekre optimalizálva. 

A VMware egy Ferrari, amit a maffiától bérelsz és mindig a hó elején derül ki éppen mennyi lesz a beszedett díj. 

A Proxmox megy egy Porsche, ami az F1 motorját kapta meg. 

Ha valaki beleragadt a VMware világba és nincs kapacitás váltani érthető. De egy most kezdett projektnél a legmegbízhatatlanabb és ezért legrosszabb választás. Ha a kedves kollégák nem ismernek mást, akkor továbbképzésre kell küldeni őket! :-)  

“Az ellenség keze betette a lábát”

"

A VMware egy Ferrari, amit a maffiától bérelsz és mindig a hó elején derül ki éppen mennyi lesz a beszedett díj. 

A Proxmox megy egy Porsche, ami az F1 motorját kapta meg. 

by: jevgenyij

"

 

Ezt lopom, aláírásnak!

( •̀ᴗ•́)╭∩╮

A VMware egy Ferrari, amit a maffiától bérelsz és mindig a hó elején derül ki éppen mennyi lesz a beszedett díj. 
A Proxmox megy egy Porsche, ami az F1 motorját kapta meg. 
by: jevgenyij

Erre így nem is gondoltam még. Az AI amit összeszedett nekem:

Világszinten több mint 100 millió aktív VM fut KVM-alapú infrastruktúrán.

Ezzel szemben a Hyper-V és VMware együtt kevesebb mint 40%-ot tesznek ki a piaci részesedésből (főként vállalati környezetben).

Források (2023–2024 elemzések):

Linux Foundation – State of Cloud Infrastructure Report

Stack Overflow Developer Survey

Synergy Research Group – Cloud Market Share

 

A VMware tényleg kispálya :D 

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.

Ez amolyan vallásos megközelítésű hozzászólás.

A múltra vonatkozóan a nagy szolgáltatók valószínűleg azért használnak mást, mert akkora méretben nyomják, hogy meg tudják oldani gazdaságosan, hozzá fejlesztve azt, ami nincs meg "dobozosan". Amazon esetén azért hozzátenném, hogy Xen is van (és VMware is).

Egy most kezdett projekt esetén pedig így általánosságban és látatlanban kijelenteni, hogy a VMware a legrosszabb választás némi szűklátókörűségre utal.

( gyuri23 | 2025. 10. 07., k – 06:57 )

Szerkesztve: 2025. 10. 07., k – 07:01

A 2-es verzió óta használom 10+ éve 10+ cégnél 50+ node-on. Ennyi idő alatt 1 azaz egy darab problémám volt egy darab node-on, ahol bele kellett nyúlni a kódba amíg kijött a javítás, de az sem befolyásolta a guest gépek működését.
Egyszer sem kellett a support, bunkó módon az volt a terv, hogy ha gond van, majd előfizetünk. Nem kellett.
Ha jól van összerakva a rendszer és válogatva alatta a vas, betartod az ajánlásaikat (pl. ZFS kizárólag HBA módba) az egyik legstabilabb rendszer amivel dolgom volt, illetve van (a bajnok nálam a postfix).
Most azért van előfizetés a jobb módú cégeknél nálam, mert már "ég a pofám", hogy mennyit használom ingyen.

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.

( ggallo | 2025. 10. 07., k – 07:52 )

Tökéletesen használható éles környezetben a community Proxmox verzió. 5-ös óta használjuk, a legtöbb gép frissítve, nem újratelepítve van főverzió váltáskor, néhány már 9-en fut. Soha nem volt gont működés közben és frissítés során sem. Van szóló gép, cluster-ben több, ebből van Ceph-fel és külön storage-dzsel is, mind jól működik.

Én annyit teszek, hogy mikor főverzió váltás van, akkor 2-3 hónapot várok a főverzió frissítéssel. Főverzión belül frissítek saját ütemezés szerint mennek, soha nem volt gond. Új főverziónál bőven van átfedés az előző és az új főverzió között támogatás terén. Pl. a 9-es 2025.08.05-én jelent meg, a 8-as pedig 2026.08.31-ig támogatott, ez bőven elég minden ütemezésben a frissítésre. Egyébként volt olyan 6-os, amit nemrég örököltem mástól, 2022.07.31-én járt le a támogatása, de simán frissítettem 7-re majd 8-ra probléma mentesen (tehát jó sokáig elérhetőek a csomagtárolók a régi verziókhoz is).

A nem-előfizetős az nem a teszt verzió. Van külön testing (az a harmadik lehetőség) a legfrisebb csomagokkal, de alapból nem azt telepíted. Ami az ingyenessel települ pont ugyan az, mint az enterprise, csak kevesebb tesztelésen esik át (kb. 1-2 hónappal később kerül át minden új csomag az enterprise tárolóba, hogy kiderüljön, hogy van-e hiba...). Az enterprise előfizetés az gyakorlatilag alaposabban tesztelt azonos csomagokat és valamennyi nyitható hibajegyet jelent. A community support-os előfizetés arra van, hogy akinek nem kell support, az is tudja támogatni egy jelképes összeggel a fejlesztőket. Szerintem ez tök jó opció, mert egyébként support szerintem ultra ritkán kell, ha valaki betartja az ajánlásokat (minden működik, ami meg néha nem, arra megvan a megoldás netről 1 napon belül).

( gabrielakos v | 2025. 10. 07., k – 08:13 )

Tökéletesen használható. 3.5 óta használom (15 éve kb?), sose volt vele gondom.
Pár hónapja frissítettem 7.x-ről 8.x-re mert már zavaróan régen lejárt a supportja :)
Teljesen sima ügy, van pre-upgrade check script, lefuttatod ha minden zöld akkor mehet. 

8.4 egyelőre teljesen jó, nyilván el kell olvasni mi változott.
9.x-re majd egyszer frissítek, szerintem olyan 9.3-9.4 körül. 

zászló, zászló, szív

( ollnx | 2025. 10. 07., k – 22:27 )

10+ éve használunk több helyen proxmoxot: a cluster+ceph rendszereket előfizetéssel, az önálló gépek esetében az ingyenes megoldással. Eddig összesen az egyik cluster ceph főverzió upgradet leszámítva (ahol a rados gw s3 funkcionalitás upgradejével volt gond) nem futottunk problémába, de azt is el lehetett hárítani support nélkül.

Azaz stabilan használjuk az ingyenes verziót is.

A frissítés szépen végigment, a leírásban található proxmox és ceph verziófüggőségeket be kell tartani. Nálunk a frissítés a proxmox 6.4, ceph 14->15, proxmox 6.4->7.1, ceph 15->16 lépésekben történt, majd proxmox 7.3, ceph 16->17, proxmox 8.1, ceph 17->18. De célszerű az upgrade leírásban található kompatibilitást alapul venni.

Meglepetés nem volt, leszámítva radosgw upgrade-t a ceph 16->17 upgradekor: nem jöttek létre a szükséges admin userek és a default zone/zonegroup beállítások, ezeket kézzel kellett becsempészni, hogy elinduljon a radosgw. Bár egy másik clusternél ahol nem használunk s3-at, ott semmi probléma nem volt az upgradeval, így lehet hogy egyedi eset volt.

Nekem is ugyan ez a tapasztalatom, és én kimaradtam a radosgw hibából, mert nem használunk s3-at. Bármiféle probléma nélkül zaljott a frissítés, betartva a gyári leírás sorrendjét a Proxmox és Ceph verziók frissítével. Ráadásul úgy, hogy le sem állítottam egy VM-et sem, csak migráltam ide-oda, mikor melyik node-ra került a sor frissítésnél.

hogy le sem állítottam egy VM-et sem, csak migráltam ide-oda, mikor melyik node-ra került a sor frissítésnél.

Minimum elvárt működés már rég virtualizáció témakörben. 

Az se baj, ha mindez automatikusan megy. Pl. x node-os cluster nodejain futnak a virtuális gépek, a cluster-re megcsinálod az upgrade image-et, validálod, majd elengeded a frissítést. A rendszer automatikusan megfrissíti az összes node-ot, egyenként, automatikusan leköltöztetve a futó virt. gépeket, upgrade, majd vissza a gépek és a végén az egész cluster összes node-ja megfrissült. 

Lásd még: VMware Lifecycle Manager

VMware környezetben a VMFS upgrade kb. ennyi: jobb klikk -> upgrade vmfs. Viszlát évek múlva. 

trey @ gépház

Mivel a proxmox tulképpen csak egy fancy debian szerintem egy jól irányzott ansible kupaccal a dolog szépen megoldható. Nem az a szint mint a vmware lifecycle manager de egy csomó manuális munkát meg lehet spórolni ezzel. Ansible jó, szeretjük.

zászló, zászló, szív