Fórum Root.cz
Hlavní témata => Software => Téma založeno: googler2 19. 03. 2025, 21:24:23
-
Caute, potrebujem radu ohladom NVR software (idealne open source resp. free), ktory by vedel kontinualne nahravat a prehravat online stream z kamier Hikvision v slucke ale bez nutnosti transcodingu. Transcodingu sa chcem vyhnut z dovodu obmedzeneho vykonu HW. Kamery maju nativnu podporu codecov AVC/+ a HEVC/+. Testoval som viacero alternativ, ale vsetky doteraz testovane povodny stream transcodovali na svoj vlastny vystup:
- Frigate
- MotionEye
- Shinobi
Dakujem za odporucania.
-
Este doplnim, ze detekciu objektov vobec riesit nepotrebujem, maximalne mozno jednoduchu detekciu pohybu a ani to nie na zaklade analyzy obrazu cez NVR, ale na zaklade detekcie priamo podporovanej kamerou
-
Kolik kamer?
Proč neukládat video rovnou na disk třeba přes ffmpeg? Kamery často podporují přímo ukládání přes FTP. je třeba si uvědomit, že ty kamery často podporují pouze jeden výstupní stream, takže když to nahráváš, už z toho teba nedosaneš živý náhled.
Je to normální kamerový systém, nebo nějaká hračka ve stylu raspberry pi? Protože to je pak ztráta času tady řešit nesmyslné zadání - hraj si sám.
Pár kamer s Frigate ti utáhne i nějaký Nkový celeron, typu moderního N100 i jeho roky starý předchůdce.
-
Jo RTSP streamy by měly jít obecně ukládat třeba FFMPEGem, akorát byste si musel nějak ošetřit segmentování a odmazávání těch nejstarších.
Teď letmým pohledem třeba na ten MotionEye, což je web nadstavba nad Motion.
https://motion-project.github.io/motion_config.html#movie_passthrough
https://motion-project.github.io/motion_config.html#movie_codec (výběr korespondujícího kontejneru)
https://motion-project.github.io/motion_config.html#emulate_motion (aby to nahrávalo kontinuálně)
V MotionEye
https://github.com/motioneye-project/motioneye/issues/1157
Nikdy jsem s tím nedělal, ale vypadá to, že by to mohlo být to, co hledáte.
-
Frigate nahrává stream bez transcodingu, "problém" je v tom, že paralelně k němu jede i transcoding streamu pro detekci a to i tehdy, pokud se nepoužívá.
Tady https://github.com/blakeblackshear/frigate/discussions/4870 (https://github.com/blakeblackshear/frigate/discussions/4870) se na to někdo ptal a na konci je zmínka o issue #1911, které by to mělo řešit. To bude součástí v0.16, což je následující release (poslední v0.15 je z února t. r.), takže se snad dočkáš -- zkus to prostudovat a dej vědět...
-
S trancodingem několika streamů si bez problémů poradí i ta iGPU v celeronu. Provozuji několik DVR systémů s Nkovými celerony, vždy pár kamer okolo domu, a funguje to s Frigate v pohodě. Využití CPU všude do 30%.
Doma doplněno o Hailo-8L na detekci objektů.
-
Frigate se čtyřmi 4K kamerami, h.264, bez detekce čehokoliv, pouze nahrává, má aktuálně vytížení Celeronu N3050, na 45%. A to je to 10+ let starý, low power CPU.
-
Bezplatny iVMS-4200 priamo od HIKVISION ti nevyhovuje ? :
https://www.hikvision.com/en/support/download/software/ivms4200-series/
Pozri dole DataSheet, minimum i3 a 4GB RAM.
-
Tak podla toho co pise vecsina z Vas musim robit nejaku chybu pri konfiguraciach pretoze na Proxmox masine mam 8GB RAM a CPU:
lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
Model name: Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz
CPU family: 6
Model: 60
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Stepping: 3
CPU(s) scaling MHz: 98%
CPU max MHz: 3700.0000
CPU min MHz: 800.0000
BogoMIPS: 6584.83
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxs
r sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good
nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2
ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsa
ve avx f16c rdrand lahf_lm abm cpuid_fault epb pti ssbd ibrs ibpb stibp tpr_shadow flexpriority
ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt dtherm ida arat pl
n pts vnmi md_clear flush_l1d
Virtualization features:
Virtualization: VT-x
Caches (sum of all):
L1d: 128 KiB (4 instances)
L1i: 128 KiB (4 instances)
L2: 1 MiB (4 instances)
L3: 6 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-3
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: KVM: Mitigation: VMX disabled
L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT disabled
Mds: Mitigation; Clear CPU buffers; SMT disabled
Meltdown: Mitigation; PTI
Mmio stale data: Unknown: No mitigations
Reg file data sampling: Not affected
Retbleed: Not affected
Spec rstack overflow: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines; IBPB conditional; IBRS_FW; STIBP disabled; RSB filling; PBRSB-eIBRS Not
affected; BHI Not affected
Srbds: Mitigation; Microcode
Tsx async abort: Not affected
Vsetky jadra a celu RAM som vzdy naplno vyhradil pre dany NVR VM / LXC.
Doteraz som to vzdy testoval len s jednou kamerou Hikvision DS-2CD2685FWD-IZS (celkovo mam 4), pri plnej kvalite vstupneho streamu s rozlisenim 3840 x 2160, FPS: 25, bitrate 16 mbit/s mi frigate a motioneye reportovali tatazenie CPU 60-80% a to som nastavil len jednu kameru. Shinobi reportoval zatazenie stabilne cca 30% ale tam sa mi asi nepodarilo spustit nahravanie.
Takze dakujem za tipy, vyskusam ich a dam vediet. Ocenil by som zdielanie konfiguracie frigate, niekto tu spominal, ze vyuziva frigate cisto na dvr recordin a zataz ma velmi nizku.
PS: Viem, ze ten bitrate je mozno zbytocne vysoky, asi ho v ostrej prevadzke znizim, ale zaroven planujem kamery pouzivat na vacsi vzdialenost, preto budem potrebovat vyssi bitrate, ale asi nie az tak.
-
Ještě někde na Redditu si vcelku pochvalovali https://github.com/scottlamb/moonfire-nvr (https://github.com/scottlamb/moonfire-nvr) -- vypadá to udržovaně a mohlo by to vyhovovat... Zkus.
-
Je důležité, aby byla využita HW accelerace na GPU, jinak to bude nesmyslně zatěžovat CPU. Pokud to chceš virtualizovat, může být problém s passtrough GPU do VM, případně ti ta GPU bude chybět jinde.
Já aktuálně vše jedu na železe - Debian/Ubuntu a Frigate v Dockeru. Ale to především kvůli tomu Hailo-8L, které se mi rovněž pod Proxmoxem do VM dostat nepodařilo.
Zde jsem v rychlosti našel konfiguraci toho stroje s N3050, který uznávám běží na sekundárních streamech s nižším rozlišením. Ten CPU je pro tohle použití už asi za hranou, ale bylo to po ruce a funguje to. Zrovna v tomhle případě se jedná o použití v interiéru, takže nároky na kvalitu nejsou tak vysoké.
Doma mám škatuli s N100DC-ITX a to samé jede ve 4K a kvalitou na maximum. Rozpoznání objektů pak řeší zmíněné Hailo.
mqtt:
enabled: false
cameras:
cam1: # <--- this will be changed to your actual camera later
enabled: true
detect:
enabled: false
ffmpeg:
inputs:
- path: rtsp://user:PASSWORD@10.0.0.1:554/Streaming/Channels/102
roles:
- record
snapshots:
enabled: true
timestamp: true
bounding_box: true
record:
enabled: true
retain:
days: 7
events:
retain:
default: 7
mode: motion
pre_capture: 3
post_capture: 3
motion:
mask: 0,0.049,0,0.091,0.288,0.094,0.287,0.057
cam2: # <--- this will be changed to your actual camera later
enabled: true
detect:
enabled: false
ffmpeg:
inputs:
- path: rtsp://user:PASSWORD@10.0.0.2:554/Streaming/Channels/102
roles:
- record
snapshots:
enabled: true
timestamp: true
bounding_box: true
record:
enabled: true
retain:
days: 7
events:
retain:
default: 7
mode: motion
pre_capture: 3
post_capture: 3
motion:
mask: 0,0.049,0,0.091,0.288,0.094,0.287,0.057
cam3: # <--- this will be changed to your actual camera later
enabled: true
detect:
enabled: false
ffmpeg:
inputs:
- path: rtsp://user:PASSWORD@10.0.0.3:554/Streaming/Channels/102
roles:
- record
snapshots:
enabled: true
timestamp: true
bounding_box: true
record:
enabled: true
retain:
days: 7
events:
retain:
default: 7
mode: motion
pre_capture: 3
post_capture: 3
motion:
mask: 0,0.049,0,0.091,0.288,0.094,0.287,0.057
cam4: # <--- this will be changed to your actual camera later
enabled: true
detect:
enabled: false
ffmpeg:
inputs:
- path: rtsp://user:PASSWORD@10.0.0.4:554/Streaming/Channels/102
roles:
- record
snapshots:
enabled: true
timestamp: true
bounding_box: true
record:
enabled: true
retain:
days: 7
events:
retain:
default: 7
mode: motion
pre_capture: 3
post_capture: 3
motion:
mask: 0,0.049,0,0.091,0.288,0.094,0.287,0.057
version: 0.14
-
Je důležité, aby byla využita HW accelerace na GPU, jinak to bude nesmyslně zatěžovat CPU.
No moj problem je prave to, ze v tom stroji nemam dedikovanu GPU asi som to mal explicitne napisat uz skor, ale predpokladal som, ze je to jasne z kontextu. Tak uz rozumiem, ze mas nizky CPU usage :D
-
Je důležité, aby byla využita HW accelerace na GPU, jinak to bude nesmyslně zatěžovat CPU.
No moj problem je prave to, ze v tom stroji nemam dedikovanu GPU asi som to mal explicitne napisat uz skor, ale predpokladal som, ze je to jasne z kontextu. Tak uz rozumiem, ze mas nizky CPU usage :D
Mě nepříjde, že by ta GPU musela být dedikovaná. Ať je klidně integrovaná, ale musí se používat. Ne že to bude počítat surově CPU. Pokud ti samozřejmě do toho nehází vidle Proxmox, kvůli kterému tam tu integrovanou GPU nemůžeš předat.
-
Přesně tak, stačí i iGPU, a v podstatě jakákoliv plečka z posledních 10ti let, včetně té i5-4590, umí HW akceleraci videa.
Zabývat se dnes zpracováním videa pouze na CPU, to je přece nemysl, protože to bude žrát, topit a výkon bude nic moc. A jestli na tom proxmoxu má běžet ještě něco jiného, tak na to moc výkonu už nezbude. Zrovna NVR to jedinné, co mi na proxmoxu neběží a má to vlastní škatuli. No a v krabici s proxmoxem zase nemám GPU žádnou, protože netřeba.
-
@GPU
Jako ok, beru, že vám to chodí. Taky souhlas, že ten primární důvod, proč mu to tak žere výkon CPU, je absence akcelerace. Úplně nemyslím, že by stará HD 4600 z Haswellu dala přes QSV s H.264 ty jeho finální 4 kamery v UHD rozlišení, ale to by se asi muselo ozkoušet.
Nicméně vlastně pořád nemůžu přijít na to, proč by se pro to zmíněné jednoduché použití měly trvale překódovávat 4 streamy? Rozumím, že některé NVR programy tuhle možnost třeba nemají.
Ale přijde mi to zbytečné, pakliže by se to dalo nastavit tak, že se to prostě přijme RTSP a remuxuje do formátu, který jde pak streamovat přímo z webu (aplikace).
-
Ok tak to teda skusim tak, ze vyhodim odtial proxmox, dam tam klasicky debian a uvidim co z toho bude teda. Pozeral som ci sa neda v Proxmoxe nastavit, aby vedel vyuzivat integrovanu GPU, ale podla roznych for na to nie je univerzalny postup, zalezi to od konkretnej GPU a casto treba vela improvizovat a debugovat. Hlavny dovod preco som to povodne chcel mat pod proxmox bola jednoducha zaloha / obnova + som uvazoval, ze ak by tam ostal nejaky vykon, tak by som tam rozchodil este HA.
Inak k tym kameram: Skusal som este prenastavit motioneye podla rady z tejto temy, ale aj ked som zapol funkciu movie movie passthroug, na tej jednej kamere, tak cpu usage skocil na 50%+ a to som vypol stream ako taky a nechal iba nahravanie. Povodne som totiz predpokladal, ze stream nebudem pouzivat vobec a namiesto toho bude v realnom case pristupovat k tomu videu, ktore sa prave nahrava a v pripade potreby si ho budem moct zaroven aj prehravat. Zistil som, ze v pripade motioneye to nie je mozne pretoze v rezime passthrough vystupne video uklada do containeru mp4 a ten nie je mozne prehravat, ak video este nie je donahravane, ale v pripade mkv alebo flv by malo byt mozne prehravat video uz pocas jeho nahravania.
-
Možná bych si to pak pro porovnání ozkoušel jaké bude vytížení čistě jen s FFMPEGem.
Můžete vyjít z návodů a popisů např. odtud.
https://support.safr.com/support/solutions/articles/69000145615-record-rtsp-streams
resp.
https://medium.com/@tom.humph/saving-rtsp-camera-streams-with-ffmpeg-baab7e80d767
Tohle pak jen víceméně rozebere a muxuje streamy do MP4, dá se ozkoušet i jiný kontejner jako třeba FLV, i když to by nemělo mít žádný znatelný vliv na vytížení CPU.
Finálně ještě můžete stejným způsobem zkusit i překódovávání videa, např. -codec:v libx264 -preset:v veryfast nebo -codec:v h264_qsv pro porovnání zátěže se jen se softwarovým vs akcelerovaným kodekem (na Intel iGPU) a jestli ho případně vůbec rozchodíte.
-
Bude to chtít trochu si s tím pohrát, podívat se, co přesně ten iGPU zvládne - kolik streamů, v jaké v jaké kvalitě... I kdyby to zvládlo jen 2 streamy, tak to je pořád snížení zátěže CPU o polovinu.
A Frigate běží v dockeru, takže by neměl být problém vedle toho rozchodit i HA.
Nebo taky existuje Frigate jako addon pro HA.
-
Vyzera to tak, ze sa mi pod proxmoxom podarilo rozchodit integrovanu gpu. Nainstaloval som frigate lxc, nastavil zakladnu konfiguraciu, ale vychadzal som z tej, ktora tu bola postovana. Akurat som doplnil tu HWaccel, zmenil som record mode z motion na all a vypol som snapshoty. Frigate stream vyzera, ze bezi, zatazenie GPU reportuje 6% a CPU 8%, takze podla tej zataze je asi zjavne, ze nahravanie neprebieha ani v UI Frigate nevidim ziadne videa. Pravdepodobne mam chybu v konfiguracii, mozete sa na nu pozriet?
mqtt:
enabled: false
cameras:
cam1: # <--- this will be changed to your actual camera later
enabled: true
detect:
enabled: false
ffmpeg:
hwaccel_args: preset-vaapi
inputs:
- path: rtsp://user:pass1@ip:554/Streaming/Channels/101
roles:
- record
snapshots:
enabled: false
timestamp: false
bounding_box: false
record:
enabled: true
retain:
days: 7
events:
retain:
default: 7
mode: all
motion:
version: 0.14
-
Bude to chtít trochu si s tím pohrát, podívat se, co přesně ten iGPU zvládne - kolik streamů, v jaké v jaké kvalitě... I kdyby to zvládlo jen 2 streamy, tak to je pořád snížení zátěže CPU o polovinu.
To ho opravdu stejně neřeší se čtyřmi kamerami, pokud bude chtít transkódovat (zas předchozí otázka proč?). Na jednom počítači mám shodou okolností taky Haswell Refresh, ale i7-4790, který je trochu silnější než ta jeho i5.
Pokud transkóduju H.264 v UHD s libx264 a veryfast, tak se dostávám tak na 1,2-1,4x realtime. Záleží samozřejmě i na vstupu, náročnosti dekódování. Tzn. čistě přes CPU je to jeden stream z kamery s úplně odřenýma ušima (pokud server občas dělá i jiné věci a nechce vytéct z bufferu).
Takže za mě je pro transkódování více UHD streamu jediná možnost, že by se podařilo rozjet celou pipeline přes QSV (resp. vaapi). Podobně jako to nejspíš funguje u vás na tom N Celeronu. Ale jsem spíš skeptický a ani tak si nemyslím, že to tohle GPU dá 4x.
Jinak ještě jsem se díval konkrétně (a zapnul i iGPU, které mám na tom Haswellu normálně vypnuté)
Je to generace QSV 7.5
https://trac.ffmpeg.org/wiki/Hardware/QuickSync
A tedy opravuji, kodek pro tuhle generaci na Linuxu není h264_qsv (to je přes MFX), ale h264_vaapi
Např.
ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i $stream -c:v h264_vaapi neco.mp4
Nebo s explicitním výběrem zařízení a přiřazením aliasu foo, pak pro filtry.
fmpeg -init_hw_device vaapi=foo:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device foo -i $stream -filter_hw_device foo -vf 'format=nv12|vaapi,hwupload' -c:v h264_vaapi neco.mp4
Aby mi to chodilo, musel jsem přidat balíček intel-vaapi-driver (aspoň tak se jmenuje na OpenSUSE), kde je pak knihovna: /usr/lib64/dri/i965_drv_video.so
Na Debianu (Proxmoxu?) vypadá, že je to v balíčku i965-va-driver.
https://packages.debian.org/sid/video/i965-va-driver
případně ještě
https://packages.debian.org/sid/i965-va-driver-shaders z non-free (což je podle popisku právě potřeba i na H.264 od Haswellu - Gen 7.5 výš)
-
Tiez si myslim, ze cez FFmpeg to pojde jednoduchsie, menej narocne na HW, "skopirovat" a ukladat, ale problem je v tom, ze potrebujem, aby k tomu bol lahky pristup a aspon zakladne spravovanie pre bezneho cloveka. Z toho dovodu sa to stale snazim rozchodit v nejakom uz existujucom a ako tak prehladnom UI.
-
Tiez si myslim, ze cez FFmpeg to pojde jednoduchsie, menej narocne na HW, "skopirovat" a ukladat, ale problem je v tom, ze potrebujem, aby k tomu bol lahky pristup a aspon zakladne spravovanie pre bezneho cloveka. Z toho dovodu sa to stale snazim rozchodit v nejakom uz existujucom a ako tak prehladnom UI.
Já to chápu, je jasné, že je optimální už využít něco hotového. Ten ffmpeg zmiňoval primárně kvůli tomu, aby se daly nějak odhadnout výkonové možnosti té vaší konfigurace a případně ozkoušet, jestli tam ty HW kodeky vůbec pojedou, případně dořešit systémové věci, ne že byste u toho musel nutně skončit.
Stejně většina těch hotových NVR řešení používá vespod právě ffmpeg resp. libav.. knihovny, typicky nemají "své" kodeky, muxery atp.
Určitě jestli je tam nad tím poběží ještě další dekódování streamů, hledání patternů, detekce pohybu atp. tak to bude žrát další prostředky, ale pokud jde o samotné přijímání streamu, remux a ukládání, pak by to nemělo mít zásadně větší režii než třeba ten ffmpeg. Což když jsem si pro zajímavost zkoušel (UHD stream servírovaný z jiného počítače). Při přijmu a ukládání do segmentovaných mp4 mi ffmpeg na zmíněné konfiguraci bral tak 3-4 % CPU (ukázáno v topu, kde je max 800 % na všechna jádra).
Finálně taky, jestli to budete mít nějak základně ozkoušené s ffmpegem a objeví se případné problémy s nějakou nadstavbou, bude to podle mě trochu lepší situace pro jeho případné řešení nebo report na stránkách projektu.
-
Předpokládám, že většina hotových NVR řešení typu Frigate, se soustředí na jiné vlastnosti, než na to, aby to běželo na starém šrotu. A těmi vlastnostmi bývá právě to, aby to bylo použitelné pro běžného člověka.
Ukládat videa z kamer zvládne zmíněný ffmpeg, ale že bych tomu pak říkal NVR...
Ten N100 sežere v zátěži stejně, jako ten letitý i5 v idle, takže o ekonomickou stránku věci zjevně nejde, protože NVR zpravidla běží 24/7 a v idle nikdy není.
Proč je cílem projektu provozovat to na takové plečce? Jestli máte čas si hrát,což zjevně ano, nainstalujte si tam to Frigate, připojte si tam ty kamery, a podívejte se, co to CPU reálně zvládne. Je to práce na hodinu. Zbytečné tu teoretizovat.
-
Předpokládám, že většina hotových NVR řešení typu Frigate, se soustředí na jiné vlastnosti, než na to, aby to běželo na starém šrotu. A těmi vlastnostmi bývá právě to, aby to bylo použitelné pro běžného člověka.
Ukládat videa z kamer zvládne zmíněný ffmpeg, ale že bych tomu pak říkal NVR...
Tak ještě jednou, ffmpeg běží skoro pod vším, včetně toho Frigate. Hlavní point nebyl, aby používal finálně pouze ffmpeg, ale aby si ozkoušel různé konfigurace s plnou kontrolou nad jeho parametry, zjistil správné nastavení a vyloučil případné chyby, pokud by se na něco použila akcelerace.. nevím - špatně nastavené pass-through a iommu do virtuálu, jestli ho na proxmoxu používá, chybějící knihovny a ovladače, zpřístupnění správných zařízení a práv v kontejneru atp.
To by musel vyřešit úplně stejně, ať už by tam bylo jakékoliv CPU resp. iGPU.
Proč je cílem projektu provozovat to na takové plečce? Jestli máte čas si hrát,což zjevně ano, nainstalujte si tam to Frigate, připojte si tam ty kamery, a podívejte se, co to CPU reálně zvládne. Je to práce na hodinu. Zbytečné tu teoretizovat.
?
Podle postů ve vlákně bych tak tipoval, že se o to celou dobu snaží.
Já Frigate nikdy nepoužíval, ani nemám teď jak ozkoušet s nějakou podobnou kamerou a zjistit, proč mu to s tím nastavením zjevně neukládá videa. Podle všeho by i Frigate měl umět i "jen" nahrávat. Případně dekódovat (na náhledy, detekci atp.) na iGPU třeba pouze 720p streamy, které by z té kamery měly paralelně lézt taky a pak selektivně nahrát plný hi-res jen po tom, co se to triggeruje.
-
Pokouší se přesně o to, od čeho se ho vývojáři snaží odradit:
Frigate runs best with Docker installed on bare metal Debian-based distributions. For ideal performance, Frigate needs low overhead access to underlying hardware for the Coral and GPU devices. Running Frigate in a VM on top of Proxmox, ESXi, Virtualbox, etc. is not recommended though some users have had success with Proxmox.
https://docs.frigate.video/frigate/installation/
Napřed si snad vyzkouším doporučovaný a nejjednodušší způsob instalace, a až zjistím, že to funguje a vyhovuje, mohu to začít ohýbal a lámat přes koleno do virtuálu. Navíc si tím dané řešení alespoň trochu osahám, takže řešení pozdějších problémů pro mne bude jednodušší.
Další podporovaný způsob instalace je addon do HA, tím získá i ten HA, které chtěl vedle toho provozovat na tom Proxmoxu, takže opět odpadá potřeba to virtualizovat.