Hirdetés
- Mától Huawei okosórákkal is lehet érintésmentesen fizetni
- Távozik az Apple vezérigazgatója
- Szívós, szép és kitartó az új OnePlus óra
- Poco X8 Pro Max - nem kell ide sem bank, sem akkubank
- iPhone topik
- Xiaomi 15 - kicsi telefon nagy energiával
- Fotók, videók mobillal
- Külföldi prepaid SIM-ek itthon
- Redmi Note 14 5G - jól sikerült az alapmodell
- Így spórolhat az Apple az iPhone 18 kijelzőin
-
Mobilarena
"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
-
+1
VM hátránya a lassú indulás és leállás, ha sok kieged van. De ezen kívül csak előnye van.
Mivel PVE remekül osztja be a cpu-t, nálam 6 core és asszem 3 gb ram van. Masszív overkill, de esphome compile miatt jobb így.
HAOS mindent intéz, minden frissül, nagyon ritka, h vmi nem működik, de az is a változtatások miatt és nem hiba miatt. -
-
VANESSZA1
őstag
De ha már túrni lehet valamit téma:
Használ valaki Home Assistant LXC--t ?
Életképes alternativa a VM-es helyett? -
-
-
válasz
VANESSZA1
#4790
üzenetére
No várjáá-várjááá!
És ami furcsa, hogy ha lefagy a Proxmox, akkor az LXC-k VM-k tovább futnak, csak a PVE Webgui-n vagy SSH-n nem elérhető, és ezért nem értem a dolgot.Nyugi, én AI-t is használom... ez a "Management lockup".
Ilyenem volt és hullott a hajam
Anno valami python bug okozta, a Frigate LXC-ből indult (szerintem). A Python akármelyik verzió valamiért a Host ramot "látta" és nem az LXC-t, összefosott mindent. Másik kernellel jó volt, tehát az is ludas valahol. Kihagytam pár verziót és "elmúlt". Minden bigyód frissítve van? PVE kernel? Mert ez régen volt, javítva lett.
NAS-ra mentés az script? Mert AI szerint első ok a haldokló tároló, ami nem tud mit kezdeni a terheléssel. Én a ramot mondanám, de az drága, keressünk más gyanúsítottat...
Smart teszt, futtasd azért:
smartctl -t long /dev/sdX
SSD-ken nem vészes, HDD-n órák is lehet, ha sok a HDD és néha használod is (lehet közben használni), akkor ne egyszerre futtasd azért. Konzolban indítod, de a belső vezérlőjén fut, konzol bezárás nem öli meg, de egy gép restart igen.
Eredmény lekérdezése:
smartctl -a /dev/sdX | grep -i "self-test" -A 5
hátralévő idő:
smartctl -c /dev/sdX | grep -i "extended"
nvme tszt:
smartctl -t edit /dev/nvme0n1#smart #self-test #smartmontools
AI szerint az oom / out of memory a 2. leggyakoribb ok.
Ellenőrzés: A fagyás utáni újraindításkor nézzen bele a logokba:journalctl -b -1 -e(Az előző boot utolsó sorai)
vagydmesg | grep -i oom3. KSM (Kernel Samepage Merging)
A Proxmox próbál spórolni a RAM-mal (összefésüli az azonos memóriablokkokat). Mentés közben a memória tartalma sokat változik, a KSM pedig próbál utánafutni.
A gond: Ez néha extrém magas CPU terhelést okozhat egyetlen magon, ami pont a menedzsment folyamatokat akasztja meg.
Teszt: Érdemes lehet ideiglenesen kikapcsolni:systemctl stop ksmtunedextra:
Mentési sávszélesség korlátozása: Állítson be korlátot (Bandwidth limit) a mentéshez (Datacenter -> Options -> Bandwidth Limit). Ha visszaveszi a tempót, és megszűnik a fagyás, akkor az I/O volt a szűk keresztmetszet.
Mentési mód: Ha "Snapshot" módban ment, próbálja meg a "Suspend" módot (bár ez leállítja a VM-et egy időre, de stabilabb lehet a teszthez).
Logs, logs, logs: Keresse a/var/log/syslogvagyjournalctlfájlban a "blocked for more than 120 seconds" hibaüzeneteket. Ez egyértelműen lemezhibára vagy I/O túlcsordulásra utal.Remélem találsz benne hasznosat. Nekem múltkor egy HDD haldoklott szegény, mindenre is gondoltam (a HDD hibán kívül
): kábelcsere, formáztam, új particiós tábla, ram időzítések, stb... kemény napok voltak
-
VANESSZA1
őstag
Nem magára ment. Két mentés van az egyik ébreszti a PBS-t és arra, és van mégegy mentés és az pedig a NAS-ra. Mindkettőnél csinálja.
Bios nem lett turva.
Valahogy a RAM gyanús nekem, de ebbe a rohadt árkavalkádban beújítani 2db 32Gb-st az enyhén fájó projekt.
És ami furcsa, hogy ha lefagy a Proxmox, akkor az LXC-k VM-k tovább futnak, csak a PVE Webgui-n vagy SSH-n nem elérhető, és ezért nem értem a dolgot.
Nem akarok AI-al nekiállni, mert lehet úgy beküld a málnásba, hogy még felteteti a Proxmox 10.1-et is
-
válasz
VANESSZA1
#4788
üzenetére
hát, uhh... ha manual lefut és random helyen fagy, akkor elvileg a mentős script hátrébb kerül a gyanúsítottaknál.
kezdenék a meghajtókon long self test-el, illetve mielőtt elindítod, kellene egy mem test. Praktikus, ha van másik gép és modulonként teszteled, akkor a szerver dolgozhat "csökkentett" módban.
Ha biost nem piszkáltad és korábban jól működött, akkor azt is hátrébb sorolnám. De Ryzennél mindig a ram az...
Volt vmi állítgatás? Esetleg önmagára ment vagy ilyesmi? lehet köze zfs-hez, ahhoz nem értek... kell több adat. -
VANESSZA1
őstag
Küzdők egy hülye hibával, esetleg találkozott már hasonlóval:
Időzített (vagy manuális ) mentés esetén különböző pontoknál megfagy a Proxmox, és csak a hradreset segít. Sehol nincsERROR:vagyfailed, seTASK ERROR, ami a Proxmox tipikus hibajelölése lenne vzdump/PBS backupnál.
Már néztem a memória felhasználást, már figyeltem, hogy mikor, melyik LXC-nél vagy Vm-nél de mindig random, és nem jövők rá mi okozza. Elméletileg 32GB memória van és olyan mintha backup után a kernel memóriakezelése szétcsúszna, de már ebben sem vagyok 100% biztos.
Már a következők is lehetséges okoként felmerültek
I/O (PBS/NFS) deadlock,
LVM snapshot bug,
vagy konkrét kernel bug játszik‑e.
Esetleg valakinek volt valami ilyenje ?
-
-
válasz
tasiadam
#4783
üzenetére
Mindentől IS féltem, 22-es port kuka, bár most őjraraktam a tűzfal szabélyokat, ezt nem másoltam át.
Balinov: openwrt-n egy kieg telepítése, egy kattintás és két gomb nyomás.
opnsense-n shaper, pipe és rules. Mobilnetnél kevésbé hatékony, mint az openwrt megoldása. Kb. annyi, hogy a különböző eszközöknek más-más pipe van, amin belül osztoznak a sebességen (IOT, vendég wifi, minden egyéb és a játszós gép), ezen felül meg van egy pipe mindenre, ami a teljes sebességet "védi". Mobilnetnél ez azért nem jó, mert nem tudja dinamikusan változtatni a méretét, a mobilnet meg hullámzik erősen. -
válasz
tasiadam
#4779
üzenetére
...hahahaaa
nincs SSH. Biztonság van. PVE konzol van, de abbúl csak 1 van
Annyit nem ért, h küzdjek vele. Most túl vagyok az opnsense és openWRT sokkon, Bufferbloat és shaper beállításokon, átrendeztem a fix IP-k egy részét, pihenésképpen ollama-t nyúztam. -
Nálam a "NAS" az egy samba.conf meg pár samba user...

danih: nos, a ram volt a hiba oka. A CPU számolna, de a cache kevés, DDR4 lassú (főleg Intelen). Ezért szimplán több core kell neki, 'oszt amikor van adat, akkor számolgat.
Összességében 4-5 coret (PVE core, helyesen inkább szál) tud terhelni. fixált fizikai core csak rontott rajta. PVE szépen elosztja neki a terhelést, most 11 core-val, emelt súlyozással és fixált üres rammal a 4,1 t/s fel lett tornázva 5,83-ra, llama 8b.ollama run qwen2.5:3b --verbose "Say hello in 10 languages."
13.51 tokens/s ez má' hasítógép!
ollama run qwen3:4b --verbose "Say hello in 10 languages."
5.94 tokens/s-ről 8.95 tokens/s... és még most is vicces
-
történelmi okai vannak.
kezdetben vala egy nas és vala egy windows 10-es gép, ami torrentezik, tévészerverként működik, utóbb jellyfin szerver is, meg még pár apróság. a két gép nem is egy városban volt

később jött az igény, hogy a két gépből legyen egy. először a nast csináltam meg egy vm-ben az új gépen, aztán amikor egy megvolt, a másik gép feladatait kezdtem konténerekba pakolni.
mellékszál: transmissiont linuxra költöztetni sima ügy, a jellyfint viszont nem sikerült.a nas lehetne docker host, de egyelőre megnyugtatóbb szétválasztva, hátha szét találom gányolni a dockert
aztán lehet, hogy egy szép napon összeköltöztetem őket. -
e-core? Hmm, akkor ez nem rossz eredmény szerintem Nálad.
Arra jöttem rá, h LXC-ben mindegy, h mit hegesztek, akkor is 35-45% CPU core-t használ. Hát ha csak ez kel...
Kapott 10 core-t:
total duration: 13.568864706s
load duration: 2.226628799s
prompt eval count: 37 token(s)
prompt eval duration: 1.215423458s
prompt eval rate: 30.44 tokens/s
eval count: 129 token(s)
eval duration: 9.814112429s
eval rate: 13.14 tokens/s -
-
ollama run qwen2.5:3b --verbose "Say hello in 10 languages."
total duration: 19.431330627s
load duration: 2.489440457s
prompt eval count: 37 token(s)
prompt eval duration: 2.442934457s
prompt eval rate: 15.15 tokens/s
eval count: 131 token(s)
eval duration: 14.168623047s
eval rate: 9.25 tokens/s
ollama run qwen3:4b --verbose "Say hello in 10 languages."
Thinking modelleken mindig röhögök...
total duration: 3m26.990139562s
load duration: 2.452051744s
prompt eval count: 18 token(s)
prompt eval duration: 1.527201689s
prompt eval rate: 11.79 tokens/s
eval count: 1204 token(s)
eval duration: 3m22.542799786s
eval rate: 5.94 tokens/s -
qwen2.5:3b
qwen2.5:7b
qwen3:4b
llama3.2:3b
Hmmm... akkor lehet én sem látom/nem jól mutatja a PVE? Nem tudok két konzolt nyitni LXC-ben, kellete egy top is, nézni. De lassú...ollama run llama3.2:3b --verbose "Mi a kedvenc színed?"
ettől lehidalt vmelyik thinking model.
ollama run llama3.1 --verbose "Say hello in 10 languages."
ez is vicces, thinking modellek elvergődnek vele, qwen2.5 az meg csak dobálja... -
danih
veterán
Ok makd megnézem beteszem, max 2-3 ilyen env van...
Mekkora modellre nézzek sebességet? Van ami gyorsabb, van ami lassab, attól függ ugye hány "b"
A linkeltet használom igen, 4 core és 6 gb ramot adtam neki... De érdekesen működik mert nem látszik a ram használat pvestaton, ugyanis vram-ként veszi el a ramot... -
intel, 10500T CPU. IGP harmatos, nem köll...

Tiéd is az, ami a linken van? Hány core, mennyi ram? Nálam nem használja ki, azt hittem Ryzen miatt, de itt sem... az AI meg bevinne a F erdőbe ismét, mondtam neki, h sztem pont annyira ért ehhez, mint én...![;]](//cdn.rios.hu/dl/s/v1.gif)
...és igazat adott
ollama service-t bámásolod, h milyen ENV-el futtatod? Egyáltalán milyen a sebessége? Nálam a kicsiknek is 12-15, ami kb. fele-harmada az elméleti a normálisnak.
Docker nincs, csak HA-ban -oda is felrakható, de szegény HA-t nem hízlalnám tovább, meg ott a modellváltás=addon reinstall.
A linkelt portable is málnás, 11-14 gen
de CPU-ból is többet lehetne kihozni, ha használná...
-
Szia!
Az első rész nem tiszta, működik, de kell más módszer?
Vagy a PVE wipe és inicializálást skippelnéd? Arra ott az fstab.WD-nél egyáltalán nincs hdparm, ha purple, akkor ne is erőltesd, nincs értelme (fogyasztásilag).
apt install hd-idlenano /etc/default/hd-idleHD_IDLE_OPTS="-i 0 -a sda -i 600"
-i 0: Alapból minden lemezre kikapcsolja (biztonsági okból).
-a sda: Kiválasztod a konkrét lemezt.
-i 600: 600 másodpercre (10 perc) állítja az időt.systemctl daemon-reloadsystemctl enable hd-idlesystemctl start hd-idleA kevésbé elegáns módszer a crontab, vagy saját service-t készítesz.
-
Zaied
addikt
Sziasztok!
Egy kis segítséget szeretnék kérni. Adott egy Proxmox 9.1.5 amin fut többek között egy Debian13 VM.
Szerettem volna fölcsatlakoztatni a SATA HDD ket a Debian VM-nek. Az AI ezt a parancsot javasolta qm set 100 -scsi2 /dev/disk/by-id/ata-MASIK_HDD_AZONOSITO.
Ezzel még nincs is gondom, pont úgy működik ahogy én szeretném (különben van erre más módszer is, hogy ne keljen a rajta lévő adatokat módosítanom?)A következő a gondom, szeretnék hdparmban spindown_time = 240 állítani. VM be egyáltalán semmi hatása, proxmoxon hdparm.conf-ba beírva semmi, csak ezzel a manuális parancsal működik hdparm -S 240 /dev/sdx.
Meg lehet valahogy úgy oldani hogy minden újraindításnál életbe lépjen/automatán betöltsön a parancs? Vagy hogy illik/érdemes ezt megcsinálni? -
danih
veterán
Lejárt az edit, közben eszembe jutott egy dockeres megoldás is, ez is jól működött GPU-val, compose (volume-t átírni):
services:ollama-intel-gpu:build:context: .dockerfile_inline: |FROM intelanalytics/ipex-llm-inference-cpp-xpu:latestENV ZES_ENABLE_SYSMAN=1ENV OLLAMA_HOST=0.0.0.0:11434ENV OLLAMA_NUM_GPU=999ENV OLLAMA_KEEP_ALIVE=5ENV OLLAMA_DEBUG=1ENV SYCL_CACHE_PERSISTENT=1RUN mkdir -p /llm/ollama; \cd /llm/ollama; \init-ollama;WORKDIR /llm/ollamaENTRYPOINT ["./ollama", "serve"]container_name: ollamaports:- 11434:11434restart: unless-stoppedenvironment:OLLAMA_INTEL_GPU: trueDISPLAY: ${DISPLAY}devices:- /dev/dri:/dev/drivolumes:- /tmp/.X11-unix:/tmp/.X11-unix- /volumes/ollama:/root/.ollamaDisclaimer: buildel, tehát kell neki "kis" hely és idő amíg elkészül, de ez is szuper. Update a konténerben:
pip install --pre --upgrade ipex-llm[cpp] -
danih
veterán
Nekem van Ollama LXC-m ami használja az IGP-t. Akkor most min vagy? Már teljesen összezavarodtam

Ha intel akkor ez kell neked. Sima portable, nincs szívás csak kicsomi alap GPU-s Ubuntu LXC-be, meg esetleg pár env változó belövése. Kis modellek simán mennek, és jobban mint csak CPU-val. Helper script ide nem jó. -
Ollama LXC-vel szórakozom, de botrányosan fut... Mondjuk gyanús, h régi topikokban amit linkeltek doksikat, azok már 404-et dobnak.
Helper script, manuál install, mindegy neki, csak 2-3 core és 3-5 GB ramot használ. IGP-t elengedtem, AI szerint kb. semmit nem ér az enyém...
Valaki használja, próbálta? Esetleg full VM-be jobb lehet?
-
huhh... hát ez egy "docker" konténer csak. Minimális tárhely, ram, cpu. A host markában van, nincs elherdált ram. Indulásra meg kb. mintha egy programot indítanál, a VM meg egy komplett gép. Amit lehet/szabad aztérdemes lxc-be rakni. De a docker VM miért nem jó nas-nak is?
-
danih
veterán
Docker VM-ben fstab mountol a docker konténereknek? Abban opcióként megadhatod hogy mindenképpen a network után és a docker service előtt menjen a mount. Vagy teszel oda egy scriptet ami "feltartja" az utána lévő dolgokat ha nem tudható, mennyi idő kell... VM felett pedig ahogy már vizion írta, delay megadása vm opciókban...
-
Mivel a NAS-od VM, annak "sok" idő az indulás, lehet a samba még nincs kész, amikor a docker VM már keresi. boot order-t állíts be a VM-eknek + timeout-ot.
boot order 1-2 ami a hálózathoz kell, router, tűzfal, akármi. Ha router, akkor annak is adhatsz 3-5 sec-et, majd order 3: NAS, +5 sec, order 4: docker VM
Ha nem időzítés, akkor jogosultság lesz, gondolom Te root-ként indítod az újra csatolást, a docker meg nem. Akkor itt szinkronba kell tenni a dolgokat, NAS-on megnézni a samba jogosultságokat, mappák beállításait. -
amit még meg kell fejtenem, és ebben az éáj nem vitt előbbre (ebben sem
bár sok dologban meg igen), hogy a nas vm már fut, elindítom a docker vm-et, és a nas megosztásának felcsatolására hibát dob, és emiatt persze az arról dolgozó containerek is elhasalnak. ha kézzel csatolom fél perccel később, már hibátlan.
nem indítgatom félóránként, de azért jó lenne, ha úgy tudna indulni, hogy nem kell kézzel piszkálni. -
VANESSZA1
őstag
U.i:
A sok copásból lehet sokat tanulni
-
VANESSZA1
őstag
Igen az a másik. azt én is észre vettem, hogy a NAS rendesen fel kall álljon, és után a PVE különben nincsenek jóban. De az áramszünet (oké van UPS, de az is véges) az padlóra dobja a rendszert.
powertop régi inteles vonalon nálam (i5-7500t) még tette a dolgát. Most már nem használom. 7-10W és max 17W de akkor minden megy nekem bőven jó -
válasz
VANESSZA1
#4749
üzenetére
Bind mount akkor nem műxik, ha az LXC előbb indul, mint ahogy a HW készen van. Nekem ezt egy haldokló HDD mutatta meg...
AI -főleg a gyors gemini és a CGPT- bevihet a málnásba, nem kell mindent elhinni nekik. De fstab nofail és a timeout-ok jó ha be vannak állítva.
Az újabb költözés miatt elég intenzíven használtam AI-t, faragni a fogyasztásból, optimalizálni ezt-azt. Hát mondtak marhaságokat és nem vették észre a nyilvánvalót.
Sajnos az összefoglalóban ajánlott powertop kuka, még nézegetésre is. Belenyúl a rendszerbe durván, nálam fixálta a 800 MHz-t, AI már majdnem kernelt fordíttatott volna 10 éves leírások alapján...
--purge powertop, install tlp... és minden jó.
falból, UPS-en át 1 HDD + 4 SSD, 3 venti: 46-48 W idle. Amikor kell, akkor meg ott a kraft.
Összefoglalóba is megjegyzésként nem ártana, h a powertop (ehhez nem kell autotune vagy calibrate sem!) után ha lassú, nem reszponzív, akkor az biza lekapcsolt mindent is. Ez nálam olyan 4-5 W-ot jelentett. Cserébe fix 800 MHz.
Másik az MSI power master... na azt is ütném, aki ezt kitalálta
-
szegmentáció nincs. végül lxc lett, meg tartaléknak feltettem a routerre is.
ez utóbbi kicsit kalandos volt, mert az openwrt csomagok között csak nagyon régi tailscale volt, inkább lecseréltem kézzel újabbra. 2x 30 mb a csomag, ami nem tűnik soknak, kivéve ha összesen van 128 mb tárhey
köszi!
-
VANESSZA1
őstag
Sokszor van, hogy nem mükődik a bind mount, vagy a csatolások. Ezt párszor már olvastam a hozzászólásokban, és én nálam is előfordult, ha valamiért áramszünet volt, és szétcseszte a csatolásokat. Ilyenkor legegyszerűbb gondoljuk sokan AI és segítsen nekem a nagy testvér, de az is idő és tök felesleges, és néha össze-vissza javítgattattja velünk az fstab eléréseit még nagyobb káoszt okozva....
Én a PBS-ből nézem vissza a mentéseket már az utóbbi időben, és abban a root.pxar.didx mentésből kiválasztom a etc-fstab, majd letöltés, és így mindig van egy jó referenciám.
Általában 99%-ban segít, majd PVE-n amit ísmét megcsinálok a
NSF jogosultság (jelene esetben a jellyfin):chmod -R 755 /mnt/media
majd tesztelem:mount -a pvesm status
Nálam ez vált be.
-
-
-
helló,
van egy proxmox gép, azon belül egy debian nas vm meg egy docker host vm, szintén debian. meg van még egy windows is, de az most nem releváns

hova tegyem a tailscale-t? a proxmoxra, lxc-be, esetleg dockerbe? előbbit nem illik, azt tudom. vagy hagyjam a francba az egészet, és a routerre

a cél az lenne, hogy elérjem a vm-eket távolról, de ha magát a proxmoxot is, az se baj. -
tasiadam
Topikgazda
válasz
markussandor
#4740
üzenetére
REDHAT-hez tartozik, ami meg az IBM-hez
-
tasiadam
Topikgazda
válasz
VANESSZA1
#4737
üzenetére
Azt magadnak irod, nalad fut es a tied. Az ansible az IBM tulajdona, nem a tencenthez tartozik. Meg minden ilyen mar kesz kod a community altal keszult, nem altaluk. Ahol dolgozom is rengeteg ansible playbook van, napi szinten hasznalva. Raadasul nyakam rateszem, hogy mar van keszen ilyen
-
-
VANESSZA1
őstag
AMD APU‑n (4650G, HP 805 G6) én így csinálnám:
De a host teljesen elveszíti az iGPU‑t, tehát csak akkor érdemes, ha tényleg VM‑ben akarsz natív GPU‑t, nem csak VAAPI‑t konténerben.
Biosban:
SR‑IOV, Above 4G Decoding Bekapcsolni
IOMMU / SVM / AMD‑Vi: Be
Integrált graf szintén Be, amúgy nem lesz Passtrough
Majd kezdeném a Proxmoxban:dmesg | grep -e IOMMU -e AMD-Vi(ezzel megnézni az OIMMU-t, hogy aktív-e)
Bekapcsolnám az IOMMU-t:/etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt video=efifb:off"
(Mondjuk itt még lehetne mókolnivfio-pci.ids=ésnomodeset-et)update-grub update-initramfs -u reboot
iGPU PCI ID azonosítása és VFIO‑hoz kötés, de ezt már Host-onlspci -nn | grep -Ei "vga|display"
ekkor már meg kellene jöjjön az AMD Devices, amiből ai ID-t láthatnánk (VGA+ Audio)
Aztán /etc/modulesvfio vfio_pci vfio_iommu_type1 vfio_virqfd
/etc/modprobe.d/vfio.confoptions vfio-pci ids=1xxxx:1xx6,1xx2:1xxx disable_vga=1(mondjuk saját ID-vel)
Blacklisted driver :
/etc/modprobe.d/blacklist-amdgpu.conf:blacklist amdgpu
frissiteni:update-initramfs -ureboot
Aztán ha újraindult és még él :lspci -nnk | grep -A3 -Ei "vga|display"
És a többit már a VM-ben , amihez jobb a Debian, és Sea BIOS+vBIOS mindenképp..stb. -
-
VANESSZA1
őstag
Én meg pont kiköltöztettem a HA alól a Frigate-t, de behívva be van és látom ott is a kamerákat, mert ha már van MQTT akkor már ott csak egy lépés.
PCIe passthrough‑val teljesen VM‑nek adni az iGPU‑t AMD APU‑nál macerásabb, és a host akkor nem tudja használni konzolra, GUI‑ra, stb., ezért a legtöbb Jellyfin‑/Frigate‑s setup LXC‑s/dev/dripassthrough‑t használ, de nem lehetlen. -
válasz
VANESSZA1
#4728
üzenetére
Köszi, hasznos ez, mert Frigate is kuka a helper scriptből, nekem beköltözött Home Assistant alá. De ez még változhat. IGP itt LXC-nek van adva, VM-nek akkor továbbra sincs megoldás (amit ismernék), de kicsit el is engedtem.
Most az Opnsense frissült, rules-t teljesen átrajzolták, összes szabály kuka...
-
VANESSZA1
őstag
Én így csináltam, és adtam esélyt az AI-nak megfogalmazni a lépéseket

(bocs ha kicsit hosszú), de remélem segít.
🚀 Ultimate Frigate Útmutató:
Proxmox LXC + AMD Ryzen iGPU + Google Coral Dual Edge TPU
Ez az útmutató bemutatja, hogyan építs fel egy brutális teljesítményű NVR rendszert Proxmox alatt, LXC konténerben (nem VM-ben!), minimális erőforrás-veszteséggel.
A Vas ("A Főnök"):
• CPU: AMD Ryzen 5 Pro 4650G (Vega 7 iGPU - hardveres kódoláshoz)
• AI: Google Coral Dual Edge TPU (M.2 E-key - objektum detektáláshoz)
• OS: Proxmox VE 8.x (Kernel 6.8+)
________________________________________
🛠️ 1. Lépés: Proxmox Host Előkészítése (Driverek)
Mivel LXC-t használunk, a Host gép kernelét és drivereit használja a konténer. A Proxmox 8-as kerneléhez (6.5+) a hivatalos Google Coral driver nem jó, a közösségi javított verzió kell.
Lépj be a Proxmox Shellbe:
1. Csomagtárolók és Header-ek rendezése:
(Ha nincs előfizetésed, kapcsold be a no-subscription repót, és kapcsold ki az enterprise-t, majd frissíts).
> apt update
> apt install -y pve-headers-$(uname -r) git dkms build-essential
2. A Dual Coral Driver telepítése (Feranick Fork):
> cd /usr/src
> git clone https://github.com/feranick/gasket-driver.git
> cd gasket-driver
> debuild -us -uc -tc -b
> cd ..
> dpkg -i gasket-dkms_*.deb
> apt install -y libedgetpu1-std
3. Jogosultságok (UDEV szabály):
> sh -c "echo 'SUBSYSTEM==\"apex\", MODE=\"0666\"' > /etc/udev/rules.d/65-apex.rules"
> udevadm control --reload-rules && udevadm trigger
4. Ellenőrzés és Újraindítás:
Indítsd újra a szervert (reboot). Utána ellenőrizd:
> ls -l /dev/apex*
# látnod-kell-devapex_0-és-devapex_1
________________________________________
📦 2. Lépés: Az LXC Konténer Létrehozása
Hozz létre egy Debian 12 (Bookworm) konténert a Proxmox felületén ezekkel a beállításokkal:
• Privileged: IGEN (Unprivileged pipát vedd ki!) – Kritikus a hardver eléréshez.
• Nesting: IGEN (Options -> Features -> Nesting) – Kell a Dockernek.
• Resources: 4 CPU mag, 4GB+ RAM.
________________________________________
🔗 3. Lépés: Hardver Átadás (Passthrough)
Mielőtt elindítanád a konténert, szerkeszd a konfigurációját a Host Shellben.
(A példában a konténer ID: 300, a tárhelyed UUID-jét vagy mount pontját ellenőrizd!)
> nano /etc/pve/lxc/300.conf
Add a fájl végéhez:
# --- AMD Vega GPU Átadás ---
> lxc.cgroup2.devices.allow: c 226:* rwm
> lxc.mount.entry: /dev/dri/renderD128 dev/dri/renderD128 none bind,optional,create=file 0, 0
> lxc.mount.entry: /dev/dri/card0 dev/dri/card0 none bind,optional,create=file 0, 0
# --- Google Coral Dual TPU Átadás (Major ID: 120) ---
> lxc.cgroup2.devices.allow: c 120:* rwm
> lxc.mount.entry: /dev/apex_0 dev/apex_0 none bind,optional,create=file 0, 0
> lxc.mount.entry: /dev/apex_1 dev/apex_1 none bind,optional,create=file 0, 0
# --- Tárhely (Bind Mount) ---
> mp0: /mnt/frigate_media,mp=/media/frigate
# --- DOCKER JOGOSULTSÁG JAVÍTÁS (Kritikus!) ---
> lxc.apparmor.profile: unconfined
________________________________________
🐳 4. Lépés: Docker és Driverek a Konténerben
Indítsd el a konténert, lépj be a konzoljába, és telepítsd a környezetet:
# Rendszer frissítés
> apt update && apt upgrade -y
> apt install -y curl gnupg2 lsb-release
# Docker telepítése
> curl -fsSL https://get.docker.com -o get-docker.sh
> sh get-docker.sh
# AMD Driverek telepítése (hogy a Frigate lássa a GPU-t)
> apt install -y mesa-va-drivers mesa-vdpau-drivers vainfo
________________________________________
⚙️ 5. Lépés: Frigate Telepítése (Docker Compose)
Hozd létre a mappát: /opt/frigate.
docker-compose.yml (Kiemelt figyelem a Frigate Plus kulcsra!):
version: "3.9"
services:
frigate:
container_name: frigate
privileged: true
restart: unless-stopped
image: ghcr.io/blakeblackshear/frigate:stable
shm_size: "256mb"
environment:
# FONTOS: Frigate 0.14+ alatt a kulcsot itt kell megadni!
# A változó neve: PLUS_API_KEY (nem FRIGATE_PLUS_API_KEY)
- PLUS_API_KEY=IDE_ÍRD_A_HOSSZÚ_KULCSOT_MACSKAKÖRÖM_NÉLKÜL
devices:
- /dev/apex_0:/dev/apex_0
- /dev/apex_1:/dev/apex_1
- /dev/dri/renderD128:/dev/dri/renderD128
volumes:
- /etc/localtime:/etc/localtime:ro
- ./config.yml:/config/config.yml
- /media/frigate:/media/frigate
- type: tmpfs
target: /tmp/cache
tmpfs:
size: 1000000000 # 1GB RAM Cache
ports:
- "5000:5000"
- "8554:8554"
- "8555:8555/tcp" # WebRTC
- "8555:8555/udp" # WebRTC
config.yml (Optimális beállítások):
mqtt:
enabled: False # Vagy add meg a HA adatait
# Frigate Plus Modell (Kulcs a docker-compose-ban van!)
model:
path: plus://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# Dual TPU használata
> * detectors:
> * coral_pci1:
> * type: edgetpu
> * device: pci:0
> * coral_pci2:
> * type: edgetpu
> * device: pci:1
# AMD GPU Hardveres gyorsítás
> ffmpeg:
> hwaccel_args: preset-vaapi
# Helytakarékos rögzítés (Csak események tárolása)
> record:
> enabled: True
> retain:
> days: 0 # Üresjáratot nem tárolunk
> mode: all
> events:
> retain:
> default: 10 # Eseményeket 10 napig őrizzük
> mode: active_objects
>
> snapshots:
> enabled: True
________________________________________
✅ 6. Lépés: Indítás
docker compose up -d
Ha mindent jól csináltál, a http://IP_CIM:5000 címen:
1. A System fülön látod a két Coralt (Inference speed < 10ms).
2. Látod az AMD GPU (vaapi) használatot.
3. A Frigate Plus modell aktív.
Pro Tipp: Most azonnal csinálj egy Backupot a konténerről a Proxmoxban! 😉
⚠️ KRITIKUS PONT: A Frigate Plus Kulcs és a Modell ID megkülönböztetése
A leggyakoribb hiba, hogy összekeverik a "Belépőkártyát" (API Key) és a "Terméket" (Model ID). A Frigate 0.14+ verziótól kezdve ezeket KÉT KÜLÖNBÖZŐ HELYRE kell írni!
1. A Hosszú API Kulcs ("A Jelszó")
• Hol találod: Frigate Plus Dashboard -> Settings -> API Key.
• Hova kell írni: docker-compose.yml
• Változó neve: PLUS_API_KEY (Szigorúan ez a neve! Nem FRIGATE_PLUS...!)
• Formátum: Csak a hosszú karaktersorozat, macskaköröm nélkül.
Példa a docker-compose.yml-ben:
> environment:
> - PLUS_API_KEY=xxxxxxxxxxxxxxxxxxxxxxxx... (IDE JÖN A HOSSZÚ KULCS) ...707bxaxa
2. A Modell Azonosító ("A Termék")
• Hol találod: Frigate Plus Dashboard -> Models -> A modell ID-ja (pl. plus://...).
• Hova kell írni: config.yml
• Szekció: model: path:
• Fontos: Itt NEM szabad megadni a plus: key: blokkot, mert az már a docker-compose-ban van!
Példa a config.yml-ben:
> model:
> path: plus://xxxxxxxxxxxxxxxxxxxxxxxxx <-- IDE CSAK AZ ID KELL!
________________________________________
Összefoglalva a működés logikája:
1. A konténer induláskor beolvassa a titkos kulcsot a docker-compose.yml-ből (PLUS_API_KEY).
2. Ezzel "bejelentkezik" a Frigate szerverre.
3. Ezután megnézi a config.yml-t, látja a model: path:-ot.
4. Mivel már be van jelentkezve, engedélyt kap a modell letöltésére és futtatására.
________________________________________
Mükődő AMD Ryzen Proxmox IGP átadással ! 😉 -
Egy vadiúj hiba, ami talán itt is érint 1-2 rendszert: 7271 – pve-container 6.1.0: NFS bind mounts fail with "failed to propagate uid and gid to mountpoint: Operation not permitted"
A pve-container 6.1.0 óta a nem privileged LXC nem tudta használni az átadott mount-okat, konkrétan többnyire el sem indul.
Az elsö workaround a régi 6.0.18:apt install pve-container=6.0.18Forrás: Mountpoints for LXC containers broken after update | Proxmox Support Forum
Bár nem Proxmox, hanem Home Assistant:
Ezzel párhuzamosan az SMLight SLZB-MR3U update-je is dobott egy csodát: A core update után nem látta a thread-et. A "megoldás": Az aktuális fw-t az adott rádió core-ra újra kell update-elni. -
danih
veterán
Van rajta fogyimérő, ennyit mutat... MiniPC notebook alkatrészekkel.
Pve-t meg jól látod, mióta átment communitybe a minőség romlik, túl sok mindent akarnak gyorsan hozzáadni, sok a hiba... Most kijött az OpenCloud lxc, ki szeretném próbálni de nem néz ki valami "jól"... -
ezeket az idle fogyikat nem értem, ok, Neked N100 az lehet ennyi, de néha dúván vadakat is olvasok.
Átlag mobo is 5-8 watt, cpu idle is ennyi, meg a ram -ami nem is idle normális vason-, ssd, ventik... mATX 20-25 W már reális.pve helper scriptnél most is látom, h nem olyan, mint volt...
ollama lxc script kérdez, de hibás az egész. Manual újrarakom majd.
Múltkor is találtam vmi hibát, de nem ugrik be, h mit. Az viszont eszembe jutott, h volt aggodalom a váltáskor, h mi lesz az oldallal... több cucc van, de ha egy része hibás, akkor ehh... -
danih
veterán
válasz
VANESSZA1
#4719
üzenetére
Vedd meg - add el, idd el a különbséget, ennyi
Én sem szívnék vele még ha papíron jobb a jelenlegi konfigomnál. Mindent belaktam, minden jól működik és az igényeimet 100%-ban kielégíti úgy, hogy még mindig "van hely" új dolgokra (pedig nem nevezném erős konfignak, cserébe idle 10W alatt) -
-
válasz
VANESSZA1
#4718
üzenetére
mesélj még...
Milyen Ryzen, mi a setup? Nálam az IGP átadás nem ment, ezért is fontolgatom a cserét, mert a semmire nem kell a bika IGP.
Részleteket. Most!

...és a fogyasztás. Nálam minimálra vett IGP-vel, UPS-en keresztül 55-65 W, ami mondjuk az intelhez képest sok. De nem ideális, mert a GT1050-et kellett a win11-nek adnom, nincs full idle-ben.
-
VANESSZA1
őstag
Igen épp ez, hogy ha a Ryzen-t nézem (a jelenlegi konfigot) az is bőven elég mindenre. Kb soha vagy nagyon ritkán lenne kihasználva az új teljesítménye. Esetleg amiben pluszt tudna adni a Jellyfin transkodólás mert abban jobb a Vega-ál, de ez is bőven megcsinálja amit kell és bárhonnan a világból elérem, és meg se akad. Tehát bőven jó vagyok. Tudod van az mikor úgy érzed minden belőve összeállt, és nincs kedved újból nekifútni a köröknek, esetleg valami új hardver egyedi sajátosságai miatt kutatni küzdeni. Kb itt vagyok most.
-
VANESSZA1
őstag
válasz
PhoenixK
#4717
üzenetére
Nem vagyok teljesen elszállva a projekttől. Ennyi. olcsón jutnék hozzá, de túl új, és félek, hogy a Proxmox-ban csak a szívás lenne vele.
Most hogy a Ryzen gép jól összeállt, és a fogyasztás is lement szépen nem igazán kívánom a hátam közepére sem a cserét.
A sztori csak annyi, hogy a munkatárs megkérdezte, hogy mennyit adnék érte és hülyeségből egy nagyon alacsony összeget mondtam neki érte, ő meg rábólintott, mert rendelt a HP-tól egy AI-s AMD-s gépet.
De közbe egy másik kollega (az anyacégnél már ráígért, hogy átvenné), úgyhogy lehet kipróbálom és megy tovább.
Tényleg nincs kedvem hozzá, és boldog vagyok, hogy a Ryzennel ilyen jól a Frigate, Jellyfin, a kritikus Dual TPU passtrough is tök jól megy.
Sőt a múltkor még a AI is úgy körbedícsért a fogyasztás optimalizálással elért eredményekért, hogy csak irultam-pirultam örömömben.
Akkor most kezdjek bele az elejétől..?
-
VANESSZA1
őstag
Lehet költözik a Proxmox...

Marad a HP vonal, de lehet hogy egy HP EliteDesk 8 Mini G1i lesz a jövő.
Első körben csak tesztelésre, de majd meglátjuk, hogy érdemes-e..
-
danih
veterán
Projekt státusz ápdét - minden működik. Virtuális Proxmox-on Docker VM illetve LXC-k mind működnek, legutóbb sync-elt adatok CIFS-ről beolvasva.
Claude írt szupi kis .net progit ami a tálcán lakik, feladata a szerver monitorozása és a Proxmox VM indítása ha a szerver nem válaszol bizonyos ideig/bizonyos számú próba után (progiban állítható).
Ez nekem bőven elég őszintén szólva. -
...még itt sincs a cucc, csak tervezgetek.
De akkor ez megint ilyen AI-os volt, valami régi reddit posztból gondolom...Gondoltam, h fogyasztásilag visszamennék Intelre, de az AI dolog is érdekel, Home Assistantba bedrótozva, oda meg kell a kraft és a sok ram (ami mondjuk nincs, 32 GB-ből olyan 23 foglalt).
-
Te már tapasztalt vagy intel IGP átadásban... AI szerint pl. 10500T procival sem minden alaplapon lehet teljesen átadni VM-nek, úgy, hogy a fizikai alaplapi HDMI portot is átadja...
WTF?
Akkor nem lennék beljebb, mint a Ryzennel, ha nem tudom a Windows VM-nek átadni, pedig az lenne a cél, nem kell PVE konzol kimenet. -
danih
veterán
válasz
markussandor
#4708
üzenetére
Nah, elég robosztusan meg tudom oldani, nem szívás ez. Clusterhez meg 3 kell ami felesleges, nem akarom pörgetni a cluster szolgáltatást sem - és nem akarok annyi erőforrást ráfordítani VM szempontból sem. Ahogy írtam: ez inkább egyfajta plusz egy (részleges) backup dolog ami kizárólag arra szolgál, hogy pár, kulcsfontosságú LXC elérhető legyen a szerver hardveres jellegű leállása esetén időleges jelleggel. Utána pedig a teljes szervert simán vissza tudom állítani egyéb backupokból ha az kell.
Igazából nem is kell hozzá tákolás sem, ez inkább poén volt. Elég robosztus tud ez így lenni arra, amire nekem kell. Naponta sync-elek egy plusz mentést arra a néhány, kis méretű LXC-re, egyenesen a desktop-ra, majd proxmox backup indításkor behúzom és elindítom (automatikusan), csak ennyi az egész... -
markussandor
senior tag
-
danih
veterán
Tákolásért-gányolásért simán lehet hozzám jönni
Amit írtam arra lenne kihegyezve ha csak maga a szerógép hal le, vagy mondjuk a vinyója - és cseréig nem lennék minden nélkül. Mivel nálam a szeró a router után van, a netet nem befolyásolja (kis setup, na). Van NAS is, illetve persze az meg van már oldva hogy Storage-ként be van téve a dekstop-om mint potenciális backup célpont... Szóval ezek mind nem jelentenek gondot, már így is megvoltak.
Szerintem elég egyszerűen lehetne automatizálni, boot végére berakni service-ként hogy fusson le egy "behúzás" és indítás. AI tuti megbírkózik ezzel, komplexebb Proxmox szkript feladatokkal is megbírkózott már.
Csak a legfontosabb dolgok mennének át persze - DNS szerver, Vaultwarden, Tailscale, Proxy manager, ilyesmik. -
thx.
Ilyen fura megoldásokról danih-t kérdezném, Ő szokott ilyet
Nálam eléggé centralizált a helyzet, szal. magamból indulok ki: ha meghal a proxmox, akkor nincs net, nas, mentések meg kb. semmi. Nem ideális. Ha nálad ezek szeparáltak, pl. mentések külön nason vannak, akkor még járható út, h ha nincs PVE, akkor a friss mentést töltse be és indítson el ilyen "emergency" dolgokat, ha nem is mindent. De ehhez az kell, h a router, meg a mentések is PVE függetlenül rendelkezésre álljanak, a scriptnek hozzáférhetőleg.
Az ilyen fontosabb LXC, VM csinálhatna mentést hajnalban, amit a ryzen gép -ha meg van osztva a mentős hely- át tud húzni magának a mentés után. Hogy ezt miként lehet a másodlagos PVE-be automatizálva betölteni azt nem tudom...
-
danih
veterán
Dark módban úgy formáz a weboldal hogy kifolyik a szemem a kód blokkoknál
Amúgy szép munka!Más dolog hiányában homelab téren (mivel minden megy olajozottan - azaz unatkozom), azon gondolkodtam, hogy kéne még egy kis redundancia, de óccón. Cluster ezért kizárva, nem is akarok szenvedni vele. Ellenben az jutott eszembe hogy itt van a kis desktop mini pc-m barátságos fogyasztással amit gyakorlatilag sosem kapcsolok ki - mobil Ryzen 7, 32 GB RAM... Mi lenne, ha virtualizálnék rá egy másdolagos Proxmox-ot?
Esetleg meg lehetne csinálni azt, hogy indítás után a legfirssebb konténer mentésekből automatikusan állítsa vissza (azaz inkább "importálja") a szükséges LXC-ket és indítsa el azokat. Szerintem akár AI-val össze lehetne tákolni egy ilyen szkriptet simán.
A PC-mre pedig írhaték egy szimpla szkriptet ami monitorozza a szervert, és ha mondjuk pár percen keresztül nem elérhető, akkor indítja lokálisan a virtuálisat (és leveri ha esetleg a szeró magától visszajönne)...
Egyelőre ott tartok hogy feldobtam egy Virtuális Proxmox-ot és kézzel leteszteltem Vaultwarden-nel (szerveren LXC kikapcs, VM-en bekapcs). Működött rögtön, ahogy kell.
Szóval kotlok kicsit a láncolaton, hogy mehetne a mentés/visszaállítás (és ne gabalyodjak bele
)
Csinált már valaki ilyet? -
Ha ráértek, nézzetek bele: [link] Ha marhaságot írtam valahol, akkor szóljatok
Éjjelente született, most még frissek az "élmények"
Új hozzászólás Aktív témák
Hirdetés
- Egyre inkább szoftverrel segítene a Core CPU-k teljesítményén az Intel
- Autós topik
- Androidos tablet topic
- Óra topik
- LEGO klub
- PlayStation 5
- Mától Huawei okosórákkal is lehet érintésmentesen fizetni
- Bittorrent topik
- Távozik az Apple vezérigazgatója
- Graphics: Telefonvásárlási kálváriám....avagy clickbait cím: Horror a hardveraprón
- További aktív témák...
- PC Szervizeket, Gépépítőket keresek B2B szoftver partnerségre (E-számlával)
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Eladó jogtiszta, Windows 11/10, Office 2019/2021/2024, Fizikai és Digitális licencek, Számlával.
- Microsoft Office 2024 Home Business dobozos
- HIBÁTLAN iPhone 14 Pro 256GB Space Black -1 ÉV GARANCIA -Kártyafüggetlen, MS3235
- 27% - ÚJ - Captiva 16" Notebook! Ryzen 9955HX / RTX 5090 / 64GB DDR5 / 2TB NVMe! BeszámítOK
- Bomba ár! HP EliteBook 840 G9 - i7-1270P I 16GB I 512SSD I 14,1" WUXGA I Cam I W11 I Gar!
- Apple iPhone 15 Pro Max / 512GB / Kártyafüggetlen / 12HÓ Garancia / Akku: 84%
- Thermalright Aqua Elite 360 V3
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest

)
létezik az a kieg tomatora is,t64 cfw megy a flint 2 routeren itthon
Nálam kb 3-4 token körül "vereti".



