-
Fototrend
"A Proxmox Virtual Environment (röviden: Proxmox VE, PVE vagy proxmox) egy szerver virtualizációra optimalizált nyilt forráskódú Debian alapú Linux disztribúció. Lehetővé teszi a virtuális gépek és konténerek egyszerű telepítését és kezelését web konzol és command line felülettel. A programcsomag két LXC és OpenVZ konténerek, valamint a KVM alapú virtualizáció kezelését támogatja" (Wikipédia)
Hivatalos oldal: https://proxmox.com/en/
Hivatalos fórum: https://forum.proxmox.com/
Backup center, mail gateway, proxmox hypervisor és datacenter letöltés: https://enterprise.proxmox.com/iso/Véreshurka hozzászólásából
Új hozzászólás Aktív témák
-
válasz
Vektor77
#2428
üzenetére
Nem viccel, ezt nem így szokás megoldani azon a célpiacon amire a PVE lő. Ott nem úgy néz ki a setup, hogy a szerverekre egyesével kötögetnek ups-eket. Ilyet még a vSphere/ESXi sem támogat, csak közvetetten (az UPS gyártójának kell támogatnia az API-t, amin keresztül tud egy shutdwont csinálni a saját szoftvere egy teljesen clusteren vagy akár egy komplett DC-n, és ez pontosan így van a Proxmoxnál is).
Ha a Proxmox lemenne erre a szintre, akkor elismerné, hogy DIY home usereket meg egy node-os mini cégeket szeretne ügyfélnek, és ez nem csak UPS támogatást kéne hogy magával hozzon, hanem egyéb olyan apróságokat is, amik az enterprise piacon teljesen máshol/máshogy működnek (nem a hypervisoron). Szóval van ennek egy üzenet értéke is ("hova pozicionáljuk magunkat"), érthető, ha nem akarnak ilyesmibe belemenni.
-
Nyugodtan tegyétek fel a NUT-ot a hostra, mezei Debian, eleve tele van egy csomó egyéb PVE-től független dologgal is gyárilag, nem a NUT service fogja tönkretenni a KVM-et meg az LXC-t
Ilyen jellegű toolok (ups manager, monitoring agentek, backup agent, apróbb toolok, stb..) nyugodtan telepíthetőek. -
válasz
Balinov
#2328
üzenetére
Sokan túlmisztifikálják szerintem ezt a dolgot. A konténer (pl. lxc, docker, vagy kubernetes) egy a chroothoz vagy jailhez nagyon hasonló megoldás, gyakorlatilag a host kernele futtat processeket ("alkalmazásokat") egy zárt, kontrollált környezetben. Kb. ugyanaz, mintha a hoston futtatnál valamit, csak maga a konténerizációs megoldás limitálja illetve szabályozza a futtatott process által elérhető dolgokat (más processek, memóriaterület, compute erőforrás, host filrendszere, network, stb...), ennyi az egész. Lxc esetén ez a zárt környezet egy komplett userspacet tartalmaz, azaz szinte egy komplett OS-t (a kernelt kivéve persze). Docker esetén jellemzően csak a minimálisan szükséges processek kerülnek a konténerbe, így az csak annyira funkcionális amennyire az adott process (alkalmazás, service, akármi) futtatásához szükséges. A Proxmoxnál szerintem nem volt túl jó döntés az LXC választása, mivel kicsit retro/idejétmúlt szemléletre épül. Én a helyükben már régen átálltam volna dokcerre, de a support miatt gondolom ez nem egyszerű történet. Azt mondjuk nem értem, hogy miért nem hozzák be a dockert párhuzamosan.
VM esetén a host hypervisorként funkciónál, mint ahogy a neve is mutatja egy virtuális gépet futtat, annak minden velejárójával. Saját biosa van, saját virtuális hardware, saját bootloader és kernel fut benne, semmi köze a host os-hez vagy annak kerneléhez (hacsak nem annyi, hogy a virtualizációs réteget nyilván az adja hozzá). Ennek mindig van valamekkora overheadje, ebből adódik az, hogy a konténer némileg gyorsabb, kevésbé terheli a hostot mint egy vm.
Ha semmi nem indokolja, akkor mindig a konténer használatát ajánlom. Pl. az említett Pihole esetén nem igazán van indok a vm-re. Jellemzően vm-ben olyan dolgokat érdemes futtatni, amik adott kernel verzióra dependelnek (pl. host kernelétől újabb vagy régebbi), netán custom kernelt szeretnél használni, valamilyen modul vagy funkció miatt, ami a host kernelében nincs meg. Illetve természetesen Linux kerneltől eltérő platformok esetén (Windows, BSD-k, stb...) is csak vm jöhet szóba.
A minden egyéb "azt írta az XY, hogy neki instabil volt a Home Assistant konténerben" dolgot el kell felejteni a fenébe, sajnos egyre inkább tapasztalható az a jelenség, hogy téves következtetéseket vonnak le emberek az általuk tapasztalt hibákból vagy dolgokból.
-
válasz
v.attis
#2325
üzenetére
Semmilyen hátránya nincs, hacsak nem a managelhetőség. Ha külön konténerbe (Promoxnál ez az LXC) vagy vm-be teszed, akkor a HA-tól függetlenül tudod frissíteni. Ha ez neked nem fontos, és kényelmesen frissíted a HA-t futtató vm-en belül is, akkor semmi jelentősége a dolognak, nyugodtan tedd oda.
-
válasz
nemurea
#2137
üzenetére
Telekomnál ez normális, az IP TV miatt tulképpen nincs soha bridge/modem mód, csak kapsz lehetőséget +1 pppoe kapcsolatra a saját routereddel. Szóval Telekom esetén az a helyzet, hogy 2db logikai internetkapcsolatot kapsz 1db fizikai eszközzel. Összeakadás nem lesz, nem kell a ZTE-n IP-t állítani, mert a saját routerén belül fog csak létezni a 192.168.1.x subnet, a pppoe kapcsolaton pedig publikus forgalom fog majd menni (ugyanakkor egy dolog miatt, lehet, hogy mégis érdemes, lásd lent). Egyszerűen köss le róla mindent, és csak a Mikrotiket hagyd rajta ami majd pppoe-zik. A Mikrotiken használd nyugodtan a 192.168.1.x subnetet.
Pár bónusz probléma amire nem biztos, hogy gondoltál:
- Ha van IP TV boxod, akkor az a Mikrotik mögött ebben a formában nem fog menni, látnia kell direktben a ZTE-t. Multicast forgalom, tehát az sem játszik, hogy a Mikrotik NAT-olja majd. Ezt meg lehet úgy oldani, hogy az IPTV eszközöket rajta hagyod a ZTE-n. Én nem TV-zek, de hallottam, hogy van ezekhez mindenféle mobilapp, ami ilyenkor nem fog menni, mert ugye teljesen más routeren és hálózatban lesz a telefonod (vagy a ZTE wifijére csatlakozol vele, de akkor meg a saját, Mikrotik mögötti cuccaid nem éred el róla).
- A ZTE admin felületét nem fogod elérni a Mikrotik mügöl, ha marad azon is a 192.168.1.x subnet, ez kényelmetlen lehet. Ezt meg lehet úgy oldani, hogy a ZTE-n átállítód a subnetet valami másra, a Mikrotiknek pedig adsz egy IP-t ebből a subnetből, mégpedig arra az interfacére amin amúgy majd pppoe-zni fog. Ez minden további nélkül lehetséges. A publikus forgalom a pppoe kapcsolaton fog kimenni, a 192.168.1.x belül marad a Mikrotiken, az új ZTE subnet felé menő forgalom (ami tulképpen kimerül a ZTE webes felelületének az elérésben) pedig szintén ki fog találni a ZTE-hez. Persze amilyen ritkán kell, az is megoldható, hogy olyankor odasétálsz egy laptoppal, és bedugod a ZTE-be, ebben az esetben nem kell átállítani semmit.
Egyébként roppantul off az egész, javaslom inkább a Mikrotik topicot, vagy bármelyik hálózatost.
-
#2081
Chal
addikt
inspiroyhome
#2080
válasz
inspiroyhome
#2080
üzenetére
Az nem üti a rackcszekrényt (lehet abba tenni mást is), meg a tanulást, hogy tartasz e otthon zsiráfot, vagy sem
-
#2079
Chal
addikt
inspiroyhome
#2076
válasz
inspiroyhome
#2076
üzenetére
Én ilyenekkel kelek/fekszek, és továbbra is tartom, hogy otthonra semmi értelme. Tanulni bőven elég bármilyen virtualizáció egy modernebb PC-n, és ha az áram árát egy ehhez való vasra, releváns tanfolyamra, cloud előfizetésre stb.. költöd, biztosan messzebbre jutsz. Hw support mérnök tudáshoz még csak-csak jók lennének, de az meg ott bukik meg, hogy nagyon régiek, egy gen8-al nem lehet piacképes kurrens tudást összeszedni bárhogy gyakorlatozol rajta, meg ez eleve nem is otthoni műfaj (arra ott a HPE tanfolyam + vizsga, és ott kapsz kurrens vasat is).
A hobbi részét bár nehezen, de el tudom fogadni (vannak ennél furcsább hobbik is a világban
), ha ilyesmire kell valakinek, akkor majd megírom ide ha lesz ingyen elvihető. -
Az energiaárak növekedésével ezeknek a cuccoknak a sokadlagos piaca (értsd: az életciklusuk zúzda előtti utolsó állapotát, az otthoni barkács felhasználást) gyakorlatilag kimúlt. Az áruk is azért ennyi, szórják ki őket mindenhonnét, pár éve még jó buli volt, ma már kevésbé.
Ha nincs nagyon kitömve, és szanaszét optimalizálod, akkor is bekap 150-200W-ot idleben. Ez önmagában 100-120eFt-s költség évente. Számold ki, hogy mennyivel jobb vasat tudsz venni csak az áramdíjból mondjuk 2 év után.
-
Amióta létezik Linux, hw független, mivel nincs registry, meg az adott vashoz az install során telepített szelektált driverek. Minden install minden drivert (kernel modult), és az összes cpu mikrokódot, firmwaret tartalmazza. Sajnos ezért van manapság az is, hogy egyre híznak a minimal install méretek is. Ez egyébként nem egy csoda feature, hanem szimplán csak nagyon bonyolult lenne egy olyan install metódust kialakítani mint Windows esetén, ilyesmibe egyik disztribúció se tesz energiát, kapsz mindent, ha akarod, ha nem. Ilyen esetekben persze lehet ennek örülni, máskor meg szomorkodni, mikor azt látod, hogy egy Ubuntu minimal server install 800 csomagot tesz fel, meg 2 GiB a /lib/modules mérete.
-
Csak most ugrott be, hogy a static route mellett ráadásul tudni kellene nat-olnia a belső subnetet is, ez meg a szappanatartóknál szinte kizárt, kb. default jön rajtuk létre a nat szabály, amikor a lan subnetet megadod, és nem vagy rá befolyással, valamint nem tudsz egy másikat felvenni mellé.
Szóval összegezve: ez esetben nem fogod tudni kikapcsolni a NAT-ot az Opensensen, mert nem fognak visszajutni a csomagok a belső hostokhoz.
-
Feltételezem, hogy 2db routered van (szolgáltatói, és mögötte az Opensense), és mindegyik nat-ol. Ez esetben a második nat totál felesleges, elég ha más subnetben vannak a mögötte levő gépek, ő pedig csak route-ol. Persze ehhez az kell, hogy a szolgáltatói routeren fel tudd venni a visszafelé irányt a belső subnetre egy static route-al, de ezt manapság már szokta tudni mindegyik.
-
#1956
Chal
addikt
inspiroyhome
#1951
válasz
inspiroyhome
#1951
üzenetére
Pedig ez a helyzet, jelentős költség (nem tudom nézted e valaha, hogy mennyibe kerül egy brandelt SSD, mert ugye mást ezekbe nem teszel/tehetsz, mert bukod a supportot). Ráadásul ebben a méretben már érzékelhető fogyasztást is jelent. A "volt pénz szerverre" dolog meg szorosan kapcsolatban áll ezzel a szemléletmóddal, ez is hozzátesz ahhoz a jelenséghez, hogy "lett pénz szerverre"
-
válasz
tasiadam
#1950
üzenetére
Én a kártyáról beszéltem. Az olvasó más kérdés, az i2c-n is tudja monitorozni magának a management rendszer (ilo, stb..). A másik gond az, hogy sem a HPE, sem a Dell, sem a Lenovo nem gyárt SD kártyát... Egyszer egy vita miatt ennek eléggé utánanéztem, és az van amire bárki gondolna józan paraszti ésszel: ahol éppen aktuálisan tudnak rendelni 1 tonna szart, azt megveszik, és felcímkéztetik maguknak. Szóval ne gondolja senki, hogy valamiféle high-end HPE/Dell/stb... kártyákat adnak a szerverkhez. Szoktak is hullani amúgy, csak legalább nem egyszerre.
-
#1949
Chal
addikt
inspiroyhome
#1944
válasz
inspiroyhome
#1944
üzenetére
?? Az összes enterprise gyártó termékében van SD slot. Most éppen két csákányvágás között néztem fel a ph-ra egy HPE Synergy farm elől felállva, ebben sincs local disk, csak SD kártya, rajta az ESXi. De belépő rackes gépekben is alap 15+ éve, nem kell ehhez blade.
Az más kérdés, hogy Proxmoxot én sem tennék rá, és az ESXi kapcsán is szoktak lenni ezzel kapcsolatos vitáim, de alapvetően standard eljárás régóta a piacon, nagyon ritkán merül fel, hogy ne SD-ről bootoljon (persze a RAID1 is alap hozzá) egy normális szerver (értsd: mondjuk nem Windows van rajta
) . Én azért nem szeretem, mert nincs smart, és egy normális enterprise hypervisornál soha nem fogod észrevenni ha mindkét kártya befosik, csak reboot után (mivel a boot után nem ír rá). Viszont ilyet az elmúlt ~15 évben egyszer láttam, és azt is meg tudom érteni, hogy ahol van 1000db host, ott már szabad szemmel is jól látható összeg 2000db nvme/sas/sata eszköz. Mindent a profitért! -
#1867
Chal
addikt
markussandor
#1865
válasz
markussandor
#1865
üzenetére
A host kapott DHCP-n IP címet nemde? A hoston van hálózatod, mert azt a MAC címet használja a benne levő virtuális nic, amit a vbox adott neki, ezért működik a DHCP is.
De miért nem nézed meg amúgy? Akkor egyből kiderülne, hogy így van e, én csak tippelgetek, nincs vbox-om. Google képkeresővel találtam: link
-
#1864
Chal
addikt
markussandor
#1863
válasz
markussandor
#1863
üzenetére
Akkor a Virtualbox lesz a gond, a PVE-ket hiába hasonlítgatod. A Virtualboxban nincs a vm networkjének a beállításainál promiscuous mode, vagy ahhoz hasonló opció? Ha van, azt kapcsold be. Default biztosan nem fog kiengedni bármilyen mac addresst, amit a vm-en belül generálsz. A host networkje (mac címe) azért működik, mert arról tud, ő rendelte a vm-hez.
-
válasz
Bornie127
#1832
üzenetére
Milyen cpu? Több szálon mennyit mérsz? "-P" -vel indítsd az iperf3-at, és nézd meg annyi szálon ahány magod van, közben mondjuk htop -al nézd a magok terhelését a hoston. Esetleg fordítsd meg az irányt (-R), és nézd meg úgy is.
Valamint tegyél iperf-et a hostra is, első körben ne lxc-ben és vm-ben futó iperf-el méregesd, ha van eltérés akkor legalább látszik, ha pl. a host bírná, csak a konténer/vm configja/driverei fogják meg.
-
válasz
inf3rno
#1762
üzenetére
Olvastad amit írtam fentebb? Milyen módban van a kártya? dmesg mit mond? Nem kell hozzá semmilyen gyártói driver külön, a nvidia sok éve biztosítja az un. "inbox" drivert a linux maninstream kernelekbe, az összes disztribúció használja, ezzel tökéletesen megy a CX3(pro). Egyébként az most ugrott be, hogy az 56G eleve egy zárt szabvány, az ethernet nem ismer ilyet, ezért csak Mellanox switch-el menne (CX3-al amúgy ez csak annyit jelentene hogy ezt a connection speedet látnád, de ~32G fölé nem igen tudnál menni, azt is csak sok szálas iperf-el, erős cpu-val, real world scenarioknál ennél jóval kevesebb hozható ki belőle).
Nem lehet, hogy IB módban van a kártyád? Van nálad /sys/bus/pci/devices/PCI_ID/mlx4_port* file?
PCI_ID: lspci | grep Mellanox megmondja.
-
válasz
inf3rno
#1746
üzenetére
Van HPE firmware frissítés is, én a helyedben bedugnám egy Windows PC-be, arra telepíteném a latest hpe drivert, az meg fogja upgradelni a firmwaret is, illetve ha IB módban lenne, akkor itt át is fogod tudni kapcsolni könnyen ethernet módba. Utána mehet a linuxba, amit így nem kell már összekoszolni.
Amúgy milyen vas az, amiből 2x56G-t ki tudsz préselni? A CX3 eleve csak logikailag tudja ezt kezelni, mert nincs rajta annyi pci-e lane. Ha a csillagos eget is lehozod neki, RDMA/ROCE képes switchre dugod, RDMA-t tudó alkalmazásokkal, akkor úgy 32-36G-ig lehet vele elmenni. Persze azt is csak több szálon, megfelelő CPU-val és alkalmazással. A két port itt inkább a switchport és kábel redundancia biztosítása miatt van.
-
-
Megnéztem,
Ethernet controller: Mellanox Technologies MT27520 Family [ConnectX-3 Pro]
# ethtool ens1
Supported ports: [ FIBRE ]
Link partner advertised link modes: 40000baseCR4/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 40000Mb/s
Duplex: Full
Auto-negotiation: onAz "mlx4_en" gyári Proxmox (debian) kernel modullal megy PVE 7.3-4 alatt (5.15.83-1-pve #1 SMP PVE 5.15.83-1 (2022-12-15T00:00Z) x86_64 GNU/Linux), 1 node-os kis backup proxy, szinte default install.
Az fontos, hogy a kártya ne IB (infiniband) módban legyen, hanem ethernetben, lehet, hogy ez a gond nálad.
Az említett Netflixes előadás anyaga, érdemes megnézni mindenkinek akit érdekel kicsit is a téma, nagyon komoly tudás van ott: link És ez lassan egy 2 éves prezi, simán 1Tb/s felett járhatnak már.
-
válasz
inf3rno
#1740
üzenetére
Pedig sima úgy, sok Mellanox kártyát használok, most nincs meg fejből, de talán Proxmox alatt is van valahol egy régi Connect-X 3. Ha jól rémlik, alapból benne van a kernelben, a dedikált Mellanox kernel modul csak akkor kell, ha firmwaret akarsz upgradelni, esetleg RDMA-t használni (de ebben sem vagyok biztos). Ránézek majd ha lesz időm.
Fun fact: FreeBSD-nél azért simább ügy, mert a Netflix FreeBSD-t használ Mellanox NIC-ekkel, és szépen visszacsorgatják a közösségnek a saját fejlesztéseiket. Ha jól emlékszem akkor jelenleg 1db streamer node-juk 800Gbit-et tud kiszolgálni 8db 100G-s Mellanoxal, és nagyon rámentek arra, hogy ez ne csak negotiated link speed legyen, hanem ténylegesen ki is jöjjön belőle ennyi.
-
válasz
tasiadam
#1715
üzenetére
Ez már 1x éve nem probléma, mert az összes ethernet interface (kártya, switch, akármi) auto MDI-X -es. Kb. a gigabittel jött be a dolog, azóta nem kell crosslink kábel két NIC összekötéséhez, megy sima "egyenes" kábellel is.
inf3rno: Persze ez nem fog segíteni, mert ahogy most nem éred el a hálózaton, úgy direktbe kötve se tudod, az az 1db switch ami most pluszban van a két gép között, nem számít semmit. Persze próbálkozni lehet, de ahhoz az kell, hogy működjön a mostani rendszer, és csak hálózati problémája legyen, abból is olyan jellegű ami miatt a másik gépről még el tudod érni.
Szóval vagy vegyél egy usb nvme adaptert és azon telepítsd újra a másik gépen a rendszert, vagy vegyél egy videokártyát. Az utóbbi talán jobb választás, hiszen lehet, hogy meg tudod javítani a rendszert ha lesz konzolod hozzá, és nem is kell újratelepíteni.
-
válasz
5leteseN
#1525
üzenetére
Mielőtt tovább folytatódik ez: szerintem a félreértés oka az, hogy ez egy szerver megoldás. Nem arra való, hogy a desktop gépeden vagy lapotpodon bebootold, és az arra kötött monitoron használd a kiválasztott virtuális gépeket egyfajta virtuális desktopként. A Proxmoxot alapvetően egy másik gépről éred el, böngészőből. A webes felületén látod a virtuális gépeket, itt tudod konfigurálni őket, és itt kapsz hozzájuk konzolt is (azaz "képernyőt"). B verzió, hogy a vm-en belül futtatsz valamilyen szolgáltatást (RDP, VNC, stb..), de erre ugyanúgy egy másik gépről csatlakozol egy megfelelő klienssel.
Nem biztos, hogy teljesen értem a célokat, de amit eddig leírtál, az alapján neked egy egyszerű bootmanager kell, nem virtualizációs platform. Ha pedig mégis virtualizáltan szeretnél futtatni valamit néha ugyanazon a gépen amin amúgy dolgozol (pl. teszt, labor, stb.. jelleggel), akkor telepíts valamilyen erre alkalmas szoftvert a fő OS-edre (pl. VMware Workstation, Virtualbox, Windows 10/11 beépített hyper-v szolgáltatása, stb..).
-
-
-
-
Mivel egy mezei Debian, ezért az telepítesz rá amit akarsz, akár k8s is lehet rajta, egy apt install kérdése az egész. Persze tényleg nem egy szép megoldás, egy hypervisor valóban nem erre való. Nálam számtalan egyéb apró plusz tool és service fut a hoston, nem csak a PVE és a "gyári" csomagok, de ezek csak apróságok, a monitroingot és egyebeket segítik elő, ha már van egy fizikai vasam egy totál sima Debiannal, akkor nyilván használom apróbb dolgokra.
A lényeg, hogy ha így telepítesz rá egy Dockert, akkro ettől még nem lesz a PVE-ben Docker támogatás. A PVE pont a gui és a cluster funkciók miatt jó, ők ezekbe viszont csak az lxc-t tették be.
-
válasz
szpeti40
#1457
üzenetére
Dehogy, sőt, két külön technológia. A docker egy másik megoldás, a Proxmox nem használja, ők az lxc mellett tették le a voksukat (sajnos..). Mindkettő konténerizációs technológia, de az lxc kicsit más megközelítést használ, inkább komplett OS konténert ad, a docker pedig alkalmazás szintre próbál lőni. A PBS telepíthető egy lxc-be simán.
-
válasz
tasiadam
#1438
üzenetére
Pont ezt mondom, csak én Proxmox vonalon, lxc-t értettem alatta, tetszőleges kedvenc OS, és arra egy pip install home-assistant, és készen vagy, ez a HA Core. De ugyanez menne dockerrel is. Mellé lehet tenni influxot, tetszőleges sql-t, z2m-et, akármit, 90%-át az OS gyártó repojából, ami mindig egy sokkal jobban összerakott, stabilabb, átgondoltabb termék mint a szedett-vedett HA OS.
-
Aki kicsit is ért a linuxhoz, annak nagyon ajánlom, hogy az egész HA OS-t, meg a mindenféle vackait felejtse el a fenébe, sokkal jobban jár. Kedvenc linux-ra egy HA Core, és soha semmi gond nem lesz.
Sajnos teljesen más fejlesztők foglalkoznak a körítéssel, és mások magával a Home Assistant kódbázissal, és ez nagyon látszik az egészen. Kiegészítők szempontjából persze nagyon jó, hogy minden ott van azonnal, store jelleggel, csak hát látható, hogy milyen a minősége és stabilitása. Az egész egy szeméttelep a csillió dockerrel, meg a körülötte levő script halmokkal. És amikor már azt hiszed, hogy érted meg átlátod, akkor 1 héttel később tekernek rajta valamit, és megint futhatsz magad után.
Én egy kezemen meg tudom számolni, hogy mennyi 3rdp kiegészítőt használok, azokat letöltöm kézzel a Core-ba, és megvagyok. Több mint 5 éve megy így nálam, és atomstabil az egész Proxmoxon (benne 150+ eszköz, a zigbee izzótól a robotfűnyírón át az elektromos autóig tényleg minden, még saját építésű eszközök is). Frissíteni is sokkal könnyebb, fájdalommentesebb. Egyébként a gyári HA modulokat és egyebeket a Core is magára tudja húzni az "add integration" menüben, szóval tényleg csak a 3rdp pluginekkel kell kézimunkázni kicsit.
-
válasz
tasiadam
#1410
üzenetére
Elég rugalmas, mivel csak egy alkalmazás, ezért a standalone telepítője mellett elérhetőek deb csomagok is, így egy mezei Debianra is lehet telepíteni (tulképpen ugyanúgy, ahogy a PVE-t is). Nekem a NAS-ként is funkcionáló, debian alapú vm-emen van, simán hozzáadtam csak a PBS repot, apt install... és ennyi. Ha ez megvan, akkor PVE oldalon fel tudod venni. Úgy oldották meg, hogy a PBS egy speciális storage type, szóval a storage-oknál tudod felvenni, de persze storage-ot olyan formában nem ad a PVE-nek mint a többi opció.
Maga a vm futhat azon a PVE-n, amit ment, ez szerintem nem akkora dealbreaker, pláne nem otthon, főleg akkor nem, ha oda van adva a vm-jének egy külső USB drive, és azon van a backup repo. Nálam kicsit speciálisan van megoldva, mert van egy remote PVE-m is, amin szintén fut ugyanígy egy PBS. A két PBS össze van kapcsolva (van ilyen feature benne), és egymásra replikálják a backup repoikat. Így mindkét helyen van egy local és egy remote mentésem mindkét környezetről (napi, heti, havi, stb.. jobokkal).
Az alatta levő blob storage amúgy parádés, inkrementál, dedup-ol, encryptel, tömörít, tape-t is kezel, tényleg mindent is tud, és valami veszett gyors. Valamint annyira kompakt, hogy file szinten hordozható a repo. Proxmox fórumon csevegtem régebben egy dev-el, mondta, hogy nyugodtan mentsem le kézzel is akár sima file szintű copyval, csak arra figyeljek, hogy közben ne fusson job (magát a blob storage-ot be akartam tolni AWS Glacierbe, de aztán letettem róla, de amúgy simán járható).
Talán már írtam, de ha tennének még bele egy kis munkát, és kapna mondjuk egy vSphere támogatást, meg pár enterprise funkciót, akkor a Veeamnél pisolghatnának, hogy most mi lesz...
-
Ha nem baj, hogy vm/konténer szintű mentésed lesz csak, akkor PBS.
Egyébként meg lehet erőszakolni úgy, hogy van hozzá linux kliens, azt egy vm-en vagy lxc-n, vagy akár fizikai gépen belül használva file szintű mentést is lehet vele készíteni, amit betol ugyanabba a repo-ba ahova a PVE-ről az image szintű mentések mennek.
-
-
válasz
Rhino666
#1304
üzenetére
Első körben nézd meg, hogy az Emby mDNS-el operál e a kliens és a szerver egymásra találásához. Szerintem igen, de nem használtam soha, doksi és egyebek erre utalnak, valamint ezt is:
Ebben ráadásul azt írják, hogy elég egy SRV record is a DNS-ben, szóval lehet, hogy mDNS reflector sem kell, ha tudsz biztosítani a vlan3-ban egy olyan DNS szervert, amiben szerepel a fenti postban leírt emby srv record.
NAT-olonod nem kell, csak route-olnod, felesleges terhelni ezzel a routert, mindkét subnet local, nincs szükség NAT-ra. Mivel a szeparáció gondolom nem véletlen, arra azért én figyelnék, hogy a TV-k csak az Emby IP-jét érjék el, a másik vlanban, hiszen ellenkező esetben akár lehetne az egész egy vlan/subnet is.
A Proxmox alatt egy mezei Debian van, nem kell félni attól, hogy a management interfacern van egy vlan tag. Egyszer bállítod, és kész, nálam is így van (annyival megfejelve, hogy 2db fizikai NIC van összefogva LACP-vel, és ezen megy 3-4 vlan). De egyébként azt is megcsinálhatod, hogy felveszed native vlan-nak a vlan2-őt, untaggedként a switchen, így maradhat a mostani config, csak a vlan3 lesz tagged. Switche válogatja, hogy ezt hogy tudod beállítani.
-
válasz
Rhino666
#1302
üzenetére
Az Emby nem mDNS-t használ a broadcasthoz? Ha igen, akkor elég egy kis konténerben egy mDSN reflector/repeater, aminek mindkét vlanban (2,3) van interfésze és IP-je. Persze kell hozzá, hogy a routing a két subnet között rendben legyen, mert az mDNS rész után az emby és a TV-k közötti forgalmat route-olni kell (az eltérő subnet miatt). De ha ugyanaz az eszköz adja a gw-t mindkét subnetben, akkor ezzel nem lesz gond, esetleg csak arra kell figyelni, hogy firewall rule ne korlátozza a forgalmat.
Az mDNS reflector mehet egy kis konténerbe akár a Proxmoxon, ehhez persze be kell kötni a vlan3-ba, ha jól értem ez most nincs meg. Azon a fizikai interfacen amin a vlan2 van most, ott mehetne taggedként mindkét vlan. Ez azért nem így van most, mert nem tudja a switch?
-
válasz
BullZeye
#1283
üzenetére
A nem használt ramot az os-ek filerendszer és egyéb cache-nek használják, amennyire csak lehet. Manapság még default beállítások esetén is elég "agresszív" ebben egy Linux. Egy NAS esetén ez meg pláne fontos funkció, így gondolom a DSM alatt levő kernel méginkább ki van erre hegyezve.
Mivel maga az OS tud erről, ezért ha a saját eszközeivel nézed, akkor látod a tényleges használatot. Viszont a külső hypervisor erről nyilván nem tud, ő azt a mennyiséget fogja mutatni, amit az OS befoglalt. Szóval egyfelől valós a dolog, mert tényleg lefoglalt annyit, a hypervisor nem hazudik, más azt nem tudja használni a hoston. Másfelől a vm-en belül ha szükség van memóriára a processeknek akkor röhögve szabadít fel ebből. Ezért is fontos a jó méretezés, és a "kevesebb néha több" elv követése.
-
A Proxmox devek kifejezett kérése, hogy ne legyen eltávolítva az az üzenet. Láthatóan nem tesznek érte szinte semmit technikailag, hogy ezt nehezítsék, tehát ha téged mint személyt nagyon zavar, akkor megoldod, és ennyi, nem fognak haragudni érte. De tutorialokban, összefoglalókban hirdetni szerintem nem lenne fair, ha kérhetem, ne legyen itt ilyen.
-
-
válasz
szpeti40
#1172
üzenetére
Én is használom a PBS-t a beta óta, remek cucc. Elképesztő, hogy az egész csomagot ingyen (is) adja a Proxmox.
vSphere témakörhöz: a PVE-hez kellene egy normális clusterezhető fs, a CEPH-et kivéve mindegyik félmegoldás, de az meg olyan mint a zsiráf. Persze erről nem ők tehetnek, ha nincs, akkor nincs. Viszont a VMwarenek ott van a vmfs. Az egyéb enterprise featureket most nem is sorolom, nem lenne fair az áruk miatt.
A KKV szektorban ahol van pénz (tehát megéri dolgozni nekik), csak nem végtelen mennyiségben, és már nem elég egy vSphere robo licence, ott is vagy kinyögik egy standard árát, vagy a WSFC a B terv (sajnos), valamilyen entry-level/midrange FC vagy iscsi tárolóval. Ha lenne ugyanerre a hw setupra egy jól működő, nagy megbízhatóságú, kicsi erőforrásigényű cluster fs linuxra, a Proxmox jelentősebb piacot tudna szerezni szerintem a területen.
Ilyen jellegű toolok (ups manager, monitoring agentek, backup agent, apróbb toolok, stb..) nyugodtan telepíthetőek.
), ha ilyesmire kell valakinek, akkor majd megírom ide ha lesz ingyen elvihető.
Új hozzászólás Aktív témák
- Építő/felújító topik
- Eredeti játékok OFF topik
- Anglia - élmények, tapasztalatok
- Okos otthon - Home Assistant, openHAB és más nyílt rendszerek
- Vezetékes FEJhallgatók
- Xbox Series X|S
- Tovább tarthat a memóriakrízis, mint gondolnánk
- Apple MacBook
- Xbox tulajok OFF topicja
- BestBuy topik
- További aktív témák...
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- MEGA AKCIÓ! - Jogtiszta Windows - Office & Autodesk & CorelDRAW - Azonnal - Számlával - Garanciával
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Microsoft és egyéb dobozos retro szoftverek
- Game Pass Ultimate előfizetések 1 - 36 hónapig azonnali kézbesítéssel a LEGOLCSÓBBAN! AKCIÓ!
- Lenovo Legion 5 RYZEN 5 6600H RTX 3050Ti 4GB 16 GB DDR5 512 GB SSD FHD 165 Hz Magyar bill Gari
- Dell Precision 5520 15,6" FHD, Xeon E3-1505M v5, 16GB RAM, Quadro 4GB VGA, SSD, jó akku, számla, gar
- AKCIÓ! Dell Precision 3571 4G LTE i7-12700H 32GB 1000GB FHD RTX A1000 4GB 1 év teljeskörű garancia
- AKCIÓ! Microsoft XBOX Series X 1TB SSD fekete játékkonzol garanciával hibátlan működéssel
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest