Het grote Proxmox VE topic

[Harmen]

Sinds de upgrade naar v9 merk ik dat m'n home assistant vm (haos) iets meer cpu verbruikt dan normaal. (was 4% nu 19%). Heb al een aantal zaken gechecked, cq aangepast zoals:
-cpu type aanpassen x86-66-v2-AES en kvm64
-Display van Default naar SPICE
-Use tablet for pointer stond al uit, als test aan gezet + reboot en uitgezet + reboot.

Iemand nog tips of tricks? Dank!

[Vorkie]

Harmen schreef op donderdag 2 juli 2026 @ 13:37:
Sinds de upgrade naar v9 merk ik dat m'n home assistant vm (haos) iets meer cpu verbruikt dan normaal. (was 4% nu 19%). Heb al een aantal zaken gechecked, cq aangepast zoals:
-cpu type aanpassen x86-66-v2-AES en kvm64
-Display van Default naar SPICE
-Use tablet for pointer stond al uit, als test aan gezet + reboot en uitgezet + reboot.

Iemand nog tips of tricks? Dank!

Heb je ook even in Home Assistant gekeken? Misschien 1 of andere database check?

Bij mij geen van alles ingesteld zoals jij gedaan hebt, maar ik heb hem ook gewoon op i440fx.

[dixet]

Harmen schreef op donderdag 2 juli 2026 @ 13:37:
Sinds de upgrade naar v9 merk ik dat m'n home assistant vm (haos) iets meer cpu verbruikt dan normaal. (was 4% nu 19%). Heb al een aantal zaken gechecked, cq aangepast zoals:
-cpu type aanpassen x86-66-v2-AES en kvm64
-Display van Default naar SPICE
-Use tablet for pointer stond al uit, als test aan gezet + reboot en uitgezet + reboot.

Iemand nog tips of tricks? Dank!

Idd ook eens in HA zelf kijken. Het is bijvoorbeeld bekend dat de DSMR integratie sinds de laatste update veel CPU vreet

https://github.com/home-assistant/core/issues/173474

[Harmen]

dixet schreef op donderdag 2 juli 2026 @ 13:55:
[...]

Idd ook eens in HA zelf kijken. Het is bijvoorbeeld bekend dat de DSMR integratie sinds de laatste update veel CPU vreet

https://github.com/home-assistant/core/issues/173474

Ik denk weet te moeilijk, had begin jun ook de upgrade na pve9 gedaan.
DSMR integratie uitgezet, cpu valt terug naar 3%.
Dank, oorzaak gevonden, zal alles weer terug zetten.

Zal het Github linkje ff doorspitten.

[batumulia]

Ik heb sinds een tijdje als ik de node herstart een gekke melding waar ik niet zo heel veel over kan vinden. Weten jullie meer? Het verstoort verder niks, ik kan ook gewoon verder opstarten zonder problemen, maar blijf het gek vinden dat deze melding tevoorschijn komt.

[ElCondor]

batumulia schreef op vrijdag 10 juli 2026 @ 10:21:
Ik heb sinds een tijdje als ik de node herstart een gekke melding waar ik niet zo heel veel over kan vinden. Weten jullie meer? Het verstoort verder niks, ik kan ook gewoon verder opstarten zonder problemen, maar blijf het gek vinden dat deze melding tevoorschijn komt.[Afbeelding]

Ben je hier al iets verder mee? Als ik zo zoek op internet dan zie ik dat het te maken zou hebben met TPM en secure boot perikelen. ProxMox heeft onlangs bij een update de nieuwe secure boot certs gepusht, als ik me niet vergis. wellicht dat het hiermee samen hangt? Zie je dit vooral op secure boot enabled vm's? Of specifiek op de host zelf? Is daar secure boot goed voor geconfigureerd?

[_JGC_]

Vandaag even heerlijk midden op de dag een Ceph Squid naar Tentacle update gedaan... werkt verbazend goed allemaal, niemand die ook maar iets gemerkt heeft van het herstarten van services

Heb dit cluster nu een jaar in gebruik, eigenlijk nooit iets aan de hand. Zo nu en dan een kernel update, dan moeten de VMs er even af, update+reboot, VMs terug en dan de volgende.

Moet alleen nog eens 10Gb switch regelen, heb nu meshed 25Gb voor Ceph, ik heb nog een 25Gb poort over op elke server. 1Gbit duurt best wel lang als je 400GB (geheugen) aan actieve VMs moet migreren.

[orvintax]

_JGC_ schreef op dinsdag 14 juli 2026 @ 17:23:
Vandaag even heerlijk midden op de dag een Ceph Squid naar Tentacle update gedaan... werkt verbazend goed allemaal, niemand die ook maar iets gemerkt heeft van het herstarten van services

Heb dit cluster nu een jaar in gebruik, eigenlijk nooit iets aan de hand. Zo nu en dan een kernel update, dan moeten de VMs er even af, update+reboot, VMs terug en dan de volgende.

Moet alleen nog eens 10Gb switch regelen, heb nu meshed 25Gb voor Ceph, ik heb nog een 25Gb poort over op elke server. 1Gbit duurt best wel lang als je 400GB (geheugen) aan actieve VMs moet migreren.

Zou je willen delen in wat voor context of waar je het cluster voor gebruikt? De 400gb aan geheugen klinkt heel interessant. Uiteraard alle begrip als het te gevoelig is.

[_JGC_]

orvintax schreef op woensdag 15 juli 2026 @ 10:25:
[...]

Zou je willen delen in wat voor context of waar je het cluster voor gebruikt? De 400gb aan geheugen klinkt heel interessant. Uiteraard alle begrip als het te gevoelig is.

Ik heb dit vorig jaar voor een klant ingericht. Oude setup was een 6-tal HPE/Supermicro Xeon E5-2620V3/V4 of E5-2660V4 met 128-192GB per node en 2TB aan SSD opslag in RAID5, losstaande HyperV servers. Windows update was een hel, elke keer puzzelen waar nog plek was, wachten tot VM over was over gigabit.

Vorig jaar dus besloten om het anders te doen. En ipv HyperV met storage spaces waar je gecertificeerde hardware voor nodig hebt of met shared storage te werken, besloten het bij Proxmox te houden met Ceph. Eerst nog replicated ZFS overwogen, maar Ceph is gewoon zoveel simpeler in gebruik. Zolang je replicated pools gebruikt ipv russische-roulette EC-pools is het eigenlijk zorgeloos.

Dat zijn 3 leuke servertjes geworden:

Supermicro 2015CS-TNR
AMD EPYC 9455P 48core
384GB DDR5 geheugen
2x Samsung PM9A1 256GB NVME SSD
3x Samsung PM9A3 3.84TB NVME hotswap SSD
Intel I350 quad 1Gbit OCP
Intel E810 quad 25Gbit OCP

Kostprijs rond de 11K per server. Koop je nu misschien net 384GB DDR5 geheugen voor .

Onderling meshed met DAC kabels, heb op elke server nog 2 poorten over voor evt uitbreiding later, maar zoals iedereen wel verwacht gaat die uitbreiding er niet komen met deze prijzen . De Gbit poorten zitten vol met active/passive bond over 2 switches en 2 cluster netwerken over 2 switches waarbij de migrations over het backup cluster netwerk draaien.

Al snel kwamen we erachter dat 1 server genoeg sap had om de complete oude setup te hosten... aangezien we voor elke core alsnog maandelijks een Windows licentie moeten afnemen onder SPLA hebben we wat geheugen verschoven: de 3e server hebben we 4 geheugenreepjes uitgehaald en verdeeld over de andere 2 servers waardoor de verdeling 2x512GB en 1x128GB werd. De derde server draait alleen linux/FreeBSD VM's en is uitgesloten van het hosten van Windows VM's met HA rules.

Na een maandje draaien ging server 3 ineens vanalles incl Ceph OOM-killen... er was zo'n 50GB aan VMs actief maar alle geheugen was weg... snapte er helemaal niks van. Toen besloten om voor elke server 128GB bij te kopen, dus toen werd het 2x640GB en 1x256GB. Extra investering van 1200 euro excl BTW totaal, week na het betalen van de factuur ging Max ICT failliet, gelukkig met achteraf betalen besteld . Vervolgens viel me op dat na elke reboot een diagonale lijn omhoog ging lopen in Zabbix mbt geheugengebruik, op elke server. Dit bleek een geheugenlek te zijn in de Intel driver voor 25Gbit netwerkkaarten en gebeurde op alle servers. Geheugenlek inmiddels opgelost, maar met de prijzen van nu zijn we blij met die onnodige investering toen

Klant is een webontwikkelbedrijf met vnml Windows VPS'en, dit is voor het hosten van hun eigen klanten. Hadden ze misschien ook bij een cloudboer kunnen inkopen, ik heb een andere klant die dat doet, maar afhankelijk van de cloudboer betaal je de hoofdprijs en komt de performance niet in de buurt van een EPYC Turin.

Maargoed, Ceph updaten is gewoon s/squid/tentacle/g; apt update; apt full-upgrade; paar daemons herstarten in de juiste volgorde met hier en daar even wachten op de recovery. Kernel update is node in maintenance zetten, wachten tot het geheugen van de VMs is gemigreerd over gigabit, ceph set noout, node rebooten, ceph unset noout, uit maintenance halen en door met de volgende.
Ik merk daarin dat Gbit een beperking wordt, sommige VMs migreren lastig omdat ze soms sneller dirty memory aanmaken dan de migratie het over gigabit weggestuurd krijgt.

[batumulia]

ElCondor schreef op dinsdag 14 juli 2026 @ 08:56:
[...]

Ben je hier al iets verder mee? Als ik zo zoek op internet dan zie ik dat het te maken zou hebben met TPM en secure boot perikelen. ProxMox heeft onlangs bij een update de nieuwe secure boot certs gepusht, als ik me niet vergis. wellicht dat het hiermee samen hangt? Zie je dit vooral op secure boot enabled vm's? Of specifiek op de host zelf? Is daar secure boot goed voor geconfigureerd?

Ik ben nog niet verder hiermee, het is niet storend genoeg om rond te gaan neuzen in de sec settings voor het geval ik het verpest en daarna mn node helemaal niet meer online komt

[Beekforel]

Ik heb een cluster met HA ingericht, nu nog over 2 nodes. Ik heb daarop 1 VM, met Home Assistant, en op deze VM replication geconfigureerd op elke 30 minuten. Gaat prima, binnen 20 seconden is dat ding gerepliceerd.

Nou is mij sinds kort opgevallen dat de Unifi app die in Home Assistant draait daar niet tegen kan, de crashed bij elke sync.

Iemand die dit bekend voor komt?

Ik heb op zich wel een workaround bedacht, ik kan Unifi wel weer lostrekken van HA en in een losse LXC installeren. Maar als het als app in HA kan vind ik dat ook wel fijn.

[ElCondor]

De VM is dat een Windows VM? Heb je daar de ProxMox drivers en guest agent op geinstalleerd?
De guest agent heeft volgens mij een optie om het filesystem te freezen bij een replicatie of migratie. Wellicht dat dit helpt?

Vergeet niet de guest agent ook te enabled bij de VM opties.

[Gizz]

Beekforel schreef op woensdag 22 juli 2026 @ 09:04:
Nou is mij sinds kort opgevallen dat de Unifi app die in Home Assistant draait daar niet tegen kan, de crashed bij elke sync.

offtopic:
Bedoel je deze? De standalone UniFi Network Application is (of wordt spoedig) end-of-life, dus het is sowieso goed om te migreren naar Unifi OS Server

ElCondor schreef op woensdag 22 juli 2026 @ 09:23:
De VM is dat een Windows VM?

Ik neem aan gewoon Home Assistant Operating System.

[ Voor 26% gewijzigd door Gizz op 22-07-2026 20:47 ]

[Beekforel]

Gizz schreef op woensdag 22 juli 2026 @ 20:40:
[...]

offtopic:
Bedoel je deze? De standalone UniFi Network Application is (of wordt spoedig) end-of-life, dus het is sowieso goed om te migreren naar Unifi OS Server

[...]

Ik neem aan gewoon Home Assistant Operating System.

Dat had ik gemist. Ga ik doen, dan is het ook opgelost.

[WheeleE]

Ik heb sinds mijn schone v9 installatie een uitdaging met IO Pressure Stall waar ik niet uit kom.

Mijn setup:
- een intel NUC met PVE 9.2.4 schoon geïnstalleerd op een 1TB nvme
- Er draaien een dozijn lxc's en 1 VM op
- Eén van de lxc's is een proxmox helper script Docker installatie waarop ik qBittorrent heb draaien
- Deze lxc schrijft de data weg naar een mountpoint op een Synology NAS
- Deze en andere lxc's worden gebackupt naar een aparte SSD in de NUC

De symptomen:
- bij qbittorrent-download op hoge snelheid loopt de IO Pressure Stall van de lxc (en van de PVE install an sic) op naar 900-100%
- de boel blijft eerst draaien, maar utieindelijk loopt de qbittorent lxc vast
- de PVE zelf en overige lxc's blijven functioneren
- shutdown/reboot van de lxc faalt
- uiteindelijk staat de qb lxc als locked, de overige lxc's staan grayed out, maar functioneren nog wel
- unlocken van de lxc's is onmgelijk

De troubleshooting:
- reboot van de PVE verhelpt het probleem, maar voorkomt toekomstige gevallen niet
- backup leek het issue te zijn, maar splitsen over meerdere groepen/schedules helpt niet
- beperken van maximum downloadsnelheid naar bv 5mbit ipv 120mbit helpt ook niet

Mijn netwerk- en storagekennis is bescheiden, maar voor zover ik heb kunnen vinden zou het een issue kunnen zijn van zfs storage? Al maakt de Synology NAS geen gebruik van zfs storage.
Heeft iemand een hint waar ik de oorzaak en oplossing zou moeten zoeken?

Ik vind het vooral frustrerend dat er geen mogelijkheid lijkt te zijn om de lxc's te unlocken.

[Airw0lf]

@WheeleE - heb je ook al eens een installatie geprobeerd zonder dat helperscript? Welk helperscript gebruik je precies?

Misschien heb je (onbewust?) een pve-installatie gedaan met een zfs partitie op die ene nvme?

Wat geeft je het idee dat lxc's niet te unlocken zijn? Er is toch zoiets als pct unlock 107? Waarbij lxc 107 ge-unlocked wordt - waarschijnlijk is het bij jou een ander nummertje?

Met pct config 107 is te achterhalen of een lxc ge-locked is. En waardoor.

Stoppen kan ook - gebruik in dat geval pct stop 107.

Dit zijn allemaal commando's die je via de pve-console kunt aanroepen - geen idee of deze ook via de webui beschikbaar zijn.

[ Voor 4% gewijzigd door Airw0lf op 25-07-2026 17:24 ]

[WheeleE]

@Airw0lf: ik heb het docker-lxc helper script gebruikt. Dat functioneert met voor een andere docker-lxc wel prima, al zitten daar geen data-intensieve containers in.

De pct stop en pct unlock commando's heb ik inderdaad ook gevonden en geprobeerd (via de console), zonder positieve uitkomst.

Of ik op de nvme een zfs partitie heb gemaakt weet ik eigenlijk niet.
Of de bottleneck ook echt zfs storage is was een voorzichtige aanname danwel gok om eerlijk te zijn.

Ik zal eens kijken of ik een niet-docker installatie kan doen, of iets zonder een helper script. En misschien de boel nog eens laten vastlopen om meer logging/bewijs te verzamelen.
Dank voor de feedback so far

[ Voor 6% gewijzigd door WheeleE op 25-07-2026 17:35 ]

[dcm360]

Hm, in dat overzicht staat geen ZFS, waar komt er dan vandaan dat het aan ZFS kan liggen?

Wat betreft de netwerk-storage, mijn ervaring daarmee is dat als het ook maar lichtelijk gammel lijkt te zijn, dat Proxmox daar onevenredig ongelukkig van wordt. Mijn oplossing tot zover is geweest om systemen die per se een netwerkmount nodig hebben, op te zetten in een VM en zelf de mount te laten regelen. Ook dan loopt het nog wel eens in de soep, maar een VM herstarten heeft minder impact dan de host.

[WheeleE]

@dcm360 de zfs connectie kan ik niet meer vinden in mijn browser history. Wellicht, waarschijnlijk is het een false positive of wanhopig aanknopingspunt geweest in mijn geheugen. Ik schrap 'm bij deze van de lijst.

Dat de netwerkstorage misschien niet ideaal is kan, maar dat verklaart niet waarom het in de PVE v8 installatie bijna 2 jaar lang vlekkeloos heeft gedraaid. Ik heb de configuratie op exact dezelfde manier gedaan bij de installatie van v9.

[Airw0lf]

WheeleE schreef op zaterdag 25 juli 2026 @ 17:35:
@Airw0lf: ik heb het docker-lxc helper script gebruikt. Dat functioneert met voor een andere docker-lxc wel prima, al zitten daar geen data-intensieve containers in.

De pct stop en pct unlock commando's heb ik inderdaad ook gevonden en geprobeerd (via de console), zonder positieve uitkomst.

Of ik op de nvme een zfs partitie heb gemaakt weet ik eigenlijk niet.
[Afbeelding] Of de bottleneck ook echt zfs storage is was een voorzichtige aanname danwel gok om eerlijk te zijn.

Ik zal eens kijken of ik een niet-docker installatie kan doen, of iets zonder een helper script. En misschien de boel nog eens laten vastlopen om meer logging/bewijs te verzamelen.
Dank voor de feedback so far

Ik heb werkelijk geen idee wat je precies bedoeld met "*het* docker-lxc helper script" - als ik hier kijk zijn er vele helper scripts - laat staan dat ik de jouwe er tussen uit kan vissen (if-at-all de goede repository).

Wat laat pct config zien als het fout gaat?

In de afbeelding met het volume overzicht is geen zfs storage te zien - alleen een wat bijzondere boot setup waarbij de bios boot en efi boot op de nvme staat. Technisch niks mis mee - maar wat is de functie van die sda dan nog? De rest van de pve boot bestanden?

Mijn setup is vergelijkbaar - alleen gebruik ik een ext4-ssd (ook sda) om pve van te booten. En de nvme is helemaal toebeeld aan een lvm (thick provisioning) met de virtuele disken van de vm's en lxc's. Maar dat is meer een persoonlijke voorkeur - geen technische - het maakt het geheel voor mij voorspelbaar(der).

Welk netwerk-FS gebruik je richting je NAS - nfs, samba of nog iets anders (en wat)? En als het nfs of samba is, welke protocol versie?

Is er in de pve-syslog, lxc-syslog en/of synology log iets te zien van diskfouten bij het lezen en/of schrijven?

[ Voor 8% gewijzigd door Airw0lf op 25-07-2026 23:04 ]

[powerboat]

WheeleE schreef op zaterdag 25 juli 2026 @ 16:57:
Ik heb sinds mijn schone v9 installatie een uitdaging met IO Pressure Stall waar ik niet uit kom.

Mijn setup:
- een intel NUC met PVE 9.2.4 schoon geïnstalleerd op een 1TB nvme
- Er draaien een dozijn lxc's en 1 VM op
- Eén van de lxc's is een proxmox helper script Docker installatie waarop ik qBittorrent heb draaien
- Deze lxc schrijft de data weg naar een mountpoint op een Synology NAS
- Deze en andere lxc's worden gebackupt naar een aparte SSD in de NUC

De symptomen:
- bij qbittorrent-download op hoge snelheid loopt de IO Pressure Stall van de lxc (en van de PVE install an sic) op naar 900-100%
- de boel blijft eerst draaien, maar utieindelijk loopt de qbittorent lxc vast
- de PVE zelf en overige lxc's blijven functioneren
- shutdown/reboot van de lxc faalt
- uiteindelijk staat de qb lxc als locked, de overige lxc's staan grayed out, maar functioneren nog wel
- unlocken van de lxc's is onmgelijk

De troubleshooting:
- reboot van de PVE verhelpt het probleem, maar voorkomt toekomstige gevallen niet
- backup leek het issue te zijn, maar splitsen over meerdere groepen/schedules helpt niet
- beperken van maximum downloadsnelheid naar bv 5mbit ipv 120mbit helpt ook niet

Mijn netwerk- en storagekennis is bescheiden, maar voor zover ik heb kunnen vinden zou het een issue kunnen zijn van zfs storage? Al maakt de Synology NAS geen gebruik van zfs storage.
Heeft iemand een hint waar ik de oorzaak en oplossing zou moeten zoeken?

Ik vind het vooral frustrerend dat er geen mogelijkheid lijkt te zijn om de lxc's te unlocken.

Lijkt op een issue wat ik heb gehad met UrBackup in LXC en een bind via de hypervisor. Ik heb dit verholpen door er een VM van te maken i.p.v. LXC.

Ps. Kun je vertellen hoe je die synology hebt verbonden? Is dat via NFS, SMB of ISCSI?

[InjecTioN]

powerboat schreef op zaterdag 25 juli 2026 @ 21:31:
[...]

Lijkt op een issue wat ik heb gehad met UrBackup in LXC en een bind via de hypervisor. Ik heb dit verholpen door er een VM van te maken i.p.v. LXC.

Ps. Kun je vertellen hoe je die synology hebt verbonden? Is dat via NFS, SMB of ISCSI?

Dit inderdaad. En heb je het gekoppeld aan de LXC via de gebruikelijke proxmox route, of heb je ‘m vanuit de LXC zelf gekoppeld? Dat maakt nogal een verschil namelijk.

[powerboat]

InjecTioN schreef op zondag 26 juli 2026 @ 01:57:
[...]

Dit inderdaad. En heb je het gekoppeld aan de LXC via de gebruikelijke proxmox route, of heb je ‘m vanuit de LXC zelf gekoppeld? Dat maakt nogal een verschil namelijk.

Ik had hem via NFS aan de Proxmox gemount en daarna via een bindmount in de VM (Ik gebruikte toen PVE8). De reden waarom ik dit zo gedaan had was omdat ik mijn containers niet op privileged wil zetten.

Gezien ik een cluster heb en meer dan voldoende geheugen, maak ik eigenlijk alleen nog maar gebruik van VM's. Ja ze zijn iets minder efficiënt maar zijn security technisch beter en hebben minder last van rare quirks.

Behalve bij mijn Backup server daar heb ik als basis OS TrueNAS gebruikt en daar heb ik 2 containers gemaakt met een keer Proxmox Backup Server en UrBackup. Zo kan ik ook nog snapshots maken van de backup.

[ Voor 13% gewijzigd door powerboat op 26-07-2026 09:55 ]

[WheeleE]

@Airw0lf ik zat gisteren in de ergernis-modus, vandaar m'n ietwat warrige post, sorry.

Uitgebreider antwoord op je vragen:
Dit is het helper script wat ik heb gebruikt: https://community-scripts.org/scripts/docker

SDA is de losse SSD waarop alleen de backups worden weggeschreven.


@powerboat :
De share is via CIFS op de PVE-host gemapped:

code:

//xxx.xxx.xxx.xxx/download/ /mnt/lxc_shares/synology2download_rwx cifs _netdev,x-systemd.automount,noatime,uid=100000,gid=110000,dir_mode=0777,file_mode=0777,credentials=/root/.credentials_synology2 0 0

CIFS-versie: mount.cifs version: 7.4

code:

root@pve:~# pct config 105
arch: amd64
cores: 2
description: 
features: nesting=1,keyctl=1
hostname: qbittorrent
lock: snapshot
memory: 2048
mp0: /mnt/lxc_shares/synology2download_rwx/,mp=/mnt/synology2download_rwx
net0: name=eth0,bridge=vmbr0,gw=192.168.1.1,hwaddr=BC:24:11:40:DB:77,ip=192.168.1.74/23,type=veth
onboot: 0
ostype: debian
rootfs: local-lvm:vm-105-disk-1,size=10G
swap: 512
tags: yyy.yyy.yyy.yyy;community-script;docker
timezone: Europe/Amsterdam
unprivileged: 1
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file

Gisteravond is de boel overigens weer vastgelopen:

Het tijdstip van stoppen van de metrics valt samen met de start van de backup van lxc 105 (qbittorrent).

journalctl -r laat dit zien rond dat tijdstip:

code:

Jul 25 23:17:01 pve CRON[623238]: pam_unix(cron:session): session closed for user root
Jul 25 23:17:01 pve CRON[623240]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Jul 25 23:17:01 pve CRON[623238]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Jul 25 22:17:01 pve CRON[564197]: pam_unix(cron:session): session closed for user root
Jul 25 22:17:01 pve CRON[564199]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Jul 25 22:17:01 pve CRON[564197]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Jul 25 21:24:32 pve smartd[830]: Device: /dev/sda ~[SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 71 to 66
Jul 25 21:17:01 pve CRON[505201]: pam_unix(cron:session): session closed for user root
Jul 25 21:17:01 pve CRON[505203]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Jul 25 21:17:01 pve CRON[505201]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Jul 25 21:01:40 pve iptag[1070]: ℹ Starting periodic check
Jul 25 21:01:38 pve pvescheduler[487157]: INFO: Starting Backup of VM 105 (lxc)
Jul 25 21:01:38 pve pvescheduler[487157]: INFO: Finished Backup of VM 104 (00:01:37)
Jul 25 21:01:38 pve kernel: EXT4-fs (dm-19): unmounting filesystem 87d22226-4ef4-469c-bf29-6a114f9f74c0.
Jul 25 21:00:02 pve kernel: EXT4-fs (dm-19): mounted filesystem 87d22226-4ef4-469c-bf29-6a114f9f74c0 ro without journal. Quota mode: none.
Jul 25 21:00:02 pve kernel: EXT4-fs (dm-19): write access unavailable, skipping orphan cleanup
Jul 25 21:00:01 pve dmeventd[400]: Monitoring thin pool pve-data-tpool.
Jul 25 21:00:01 pve dmeventd[400]: No longer monitoring thin pool pve-data-tpool.
Jul 25 21:00:01 pve pvescheduler[487157]: INFO: Starting Backup of VM 104 (lxc)
Jul 25 21:00:01 pve pvescheduler[487157]: INFO: starting new backup job: vzdump --notification-mode notification-system --mode snapshot --fleecing 0 --compress zstd --storage lvm-backup --quiet 1 --notes>
Jul 25 21:00:01 pve pvescheduler[487155]: <root@pam> starting task UPID:pve:00076EF5:00193A7F:6A6507B1:vzdump::root@pam:

Anders dan dit zie ik geen fouten is de diverse logging, ook niet op de Synology.


Als ik al jullie ervaringen zo lees kan ik er beter een VM van maken. Het troubleshooten van deze uitdaging kost me te veel tijd en energie, en dat is het nou ook weer niet waard

[InjecTioN]

WheeleE schreef op zondag 26 juli 2026 @ 11:14:
@Airw0lf ik zat gisteren in de ergernis-modus, vandaar m'n ietwat warrige post, sorry.

Uitgebreider antwoord op je vragen:
Dit is het helper script wat ik heb gebruikt: https://community-scripts.org/scripts/docker

SDA is de losse SSD waarop alleen de backups worden weggeschreven.


@powerboat :
De share is via CIFS op de PVE-host gemapped:

code:

//xxx.xxx.xxx.xxx/download/ /mnt/lxc_shares/synology2download_rwx cifs _netdev,x-systemd.automount,noatime,uid=100000,gid=110000,dir_mode=0777,file_mode=0777,credentials=/root/.credentials_synology2 0 0

CIFS-versie: mount.cifs version: 7.4

code:

root@pve:~# pct config 105
arch: amd64
cores: 2
description: 
features: nesting=1,keyctl=1
hostname: qbittorrent
lock: snapshot
memory: 2048
mp0: /mnt/lxc_shares/synology2download_rwx/,mp=/mnt/synology2download_rwx
net0: name=eth0,bridge=vmbr0,gw=192.168.1.1,hwaddr=BC:24:11:40:DB:77,ip=192.168.1.74/23,type=veth
onboot: 0
ostype: debian
rootfs: local-lvm:vm-105-disk-1,size=10G
swap: 512
tags: yyy.yyy.yyy.yyy;community-script;docker
timezone: Europe/Amsterdam
unprivileged: 1
lxc.cgroup2.devices.allow: c 10:200 rwm
lxc.mount.entry: /dev/net/tun dev/net/tun none bind,create=file

Gisteravond is de boel overigens weer vastgelopen:
[Afbeelding]
Het tijdstip van stoppen van de metrics valt samen met de start van de backup van lxc 105 (qbittorrent).

journalctl -r laat dit zien rond dat tijdstip:

code:

Jul 25 23:17:01 pve CRON[623238]: pam_unix(cron:session): session closed for user root
Jul 25 23:17:01 pve CRON[623240]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Jul 25 23:17:01 pve CRON[623238]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Jul 25 22:17:01 pve CRON[564197]: pam_unix(cron:session): session closed for user root
Jul 25 22:17:01 pve CRON[564199]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Jul 25 22:17:01 pve CRON[564197]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Jul 25 21:24:32 pve smartd[830]: Device: /dev/sda ~[SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 71 to 66
Jul 25 21:17:01 pve CRON[505201]: pam_unix(cron:session): session closed for user root
Jul 25 21:17:01 pve CRON[505203]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Jul 25 21:17:01 pve CRON[505201]: pam_unix(cron:session): session opened for user root(uid=0) by root(uid=0)
Jul 25 21:01:40 pve iptag[1070]: ℹ Starting periodic check
Jul 25 21:01:38 pve pvescheduler[487157]: INFO: Starting Backup of VM 105 (lxc)
Jul 25 21:01:38 pve pvescheduler[487157]: INFO: Finished Backup of VM 104 (00:01:37)
Jul 25 21:01:38 pve kernel: EXT4-fs (dm-19): unmounting filesystem 87d22226-4ef4-469c-bf29-6a114f9f74c0.
Jul 25 21:00:02 pve kernel: EXT4-fs (dm-19): mounted filesystem 87d22226-4ef4-469c-bf29-6a114f9f74c0 ro without journal. Quota mode: none.
Jul 25 21:00:02 pve kernel: EXT4-fs (dm-19): write access unavailable, skipping orphan cleanup
Jul 25 21:00:01 pve dmeventd[400]: Monitoring thin pool pve-data-tpool.
Jul 25 21:00:01 pve dmeventd[400]: No longer monitoring thin pool pve-data-tpool.
Jul 25 21:00:01 pve pvescheduler[487157]: INFO: Starting Backup of VM 104 (lxc)
Jul 25 21:00:01 pve pvescheduler[487157]: INFO: starting new backup job: vzdump --notification-mode notification-system --mode snapshot --fleecing 0 --compress zstd --storage lvm-backup --quiet 1 --notes>
Jul 25 21:00:01 pve pvescheduler[487155]: <root@pam> starting task UPID:pve:00076EF5:00193A7F:6A6507B1:vzdump::root@pam:

Anders dan dit zie ik geen fouten is de diverse logging, ook niet op de Synology.


Als ik al jullie ervaringen zo lees kan ik er beter een VM van maken. Het troubleshooten van deze uitdaging kost me te veel tijd en energie, en dat is het nou ook weer niet waard

Nah. Geen VM ervan maken als het niet nodig is. Lekker een unprivileged LXC behouden.

Ik zou eerst de Proxmox 9 voorgeschreven cq best practices methode proberen.

Je gebruikt nu feitelijk nog een “oudere manier” om te mounten: handmatige mount via /etc/fstab op de PVE-host en vervolgens de lokale directory als mp0-bindmount doorgeven aan de LXC

Dat heeft voor proxmox 9 natuurlijk prima gewerkt, maar onder PVE 9 kun je CIFS rechtstreeks als storage in Proxmox configureren en door Proxmox laten beheren. Daarmee vervallen de losse fstab- en systemd-automountconstructie en wordt de configuratie overzichtelijker en mogelijk zelfs toekomstbestendiger omdat deze oudere methode niet meer als best practices wordt beschouwd.

Ik zou daarom eerst het volgende proberen:

1. de huidige CIFS-bindmount tijdelijk verwijderen uit CT 105;
2. de Synology-share via Datacenter -> Storage als CIFS-storage toevoegen;
3. CIFS als feature toevoegen aan de LXC instellingen;
4. vervolgens de share via de LXC instellingen aan de unprivileged LXC beschikbaar maken;
5. daarna dezelfde qBittorrent-belasting en back-up opnieuw testen.

Als het probleem dan wegblijft, zat het waarschijnlijk in de oude hostmount/bindmountconstructie of de lifecycle daarvan.

Een VM kan altijd nog, maar ik zou niet beginnen met extra virtualisatie als PVE 9 hiervoor inmiddels een native route biedt.

[powerboat]

InjecTioN schreef op zondag 26 juli 2026 @ 14:02:
[...]

Nah. Geen VM ervan maken als het niet nodig is. Lekker een unprivileged LXC behouden.

Ik zou eerst de Proxmox 9 voorgeschreven cq best practices methode proberen.

Je gebruikt nu feitelijk nog een “oudere manier” om te mounten: handmatige mount via /etc/fstab op de PVE-host en vervolgens de lokale directory als mp0-bindmount doorgeven aan de LXC

De mout opties die je via de GUI doet is hetzelfde als de oude wijze van de bindmount, ik verwacht niet dat je het issue hiermee oplost.

@WheeleE, wellicht kun je proberen over te stappen van CIFS naar NFS, NFS is een native protocol dat beter ondersteund wordt door Linux.

Controleer eens wat je geheugen en swap doet.

[dcm360]

@InjecTioN Ik was even benieuwd hoe dit zou moeten werken, maar de CIFS-feature mag bij mij niet aan op unprivileged containers, en ik kan verder via de GUI alleen een disk image aanmaken op de CIFS-storage, dat is net wat anders dan een netwerkshare doorkoppelen. Klik ik verkeerd, of werkt dit niet zo?

[powerboat]

dcm360 schreef op zondag 26 juli 2026 @ 14:46:
@InjecTioN Ik was even benieuwd hoe dit zou moeten werken, maar de CIFS-feature mag bij mij niet aan op unprivileged containers, en ik kan verder via de GUI alleen een disk image aanmaken op de CIFS-storage, dat is net wat anders dan een netwerkshare doorkoppelen. Klik ik verkeerd, of werkt dit niet zo?

Gaat ook niet werken, unpriviledged laat geen systemkernel drivers toe. Dit kan enkel via de omweg of via een priviledged container.

[Jerie]

CIFS tussen Unices (Proxmox en Synology bijv.) is inefficiënt. NFSv4 geeft betere performance, en heeft ook gewoon Kerberos ondersteuning, en ondersteunt ook locking. Je hebt ook maar 1 port nodig voor NFS: 2049 TCP (UDP kan ook).

Ik gebruik NFSv4 over IPv6 LL tussen twee VMs (hoef niet eens networking te configureren) binnen een bridge. De tweede VM gebruikt een LTO-6 drive (abstract SCSI) via een passthrough van HBA, over SAS, met de HBA over TB. De data wordt eerst versleuteld at rest in de eerste VM, welke o.a. Duplicati draait. Werkt prima. Is de LTO-6 drive niet nodig, dan gaat deze en de eGPU met SAS en de VM uit. Doorgaans draait deze dus niet. Scheelt me stroom.

In deze casus gebruik ik (nog) geen Kerberos maar dat is een kwestie van tijd.

Overigens heb je ook NFS en CIFS clients die userspace zijn i.p.v kernelspace.

[Airw0lf]

@WheeleE - ergens klopt er iets niet met je indeling van de volumes.

Wat is de output vanlsblk -l? En waar in dit overzicht staan de pve-bestanden?

Ik zag ook dat je snapshots gebruikt bij het maken van backups. Ooit eens geprobeerd om de stop-mode te gebruiken?

[ Voor 19% gewijzigd door Airw0lf op 26-07-2026 15:26 ]

[WheeleE]

De switch naar NFS ga ik een van de komende dagen uitvogelen. Dank weer voor de tips.
Ik merk wel dat die wat meer complexere troubleshooting en configuratie tegen de grenzen van mijn kennis schurkt.

@Airw0lf :

code:

root@pve:~# lsblk -l
NAME                 MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda                    8:0    0 465.8G  0 disk
sda1                   8:1    0 465.8G  0 part /mnt/lvm-backup
pve-swap             252:0    0     8G  0 lvm  ~[SWAP]
pve-root             252:1    0   150G  0 lvm  /
pve-data_tmeta       252:2    0   7.6G  0 lvm
pve-data_tdata       252:3    0 740.9G  0 lvm
pve-data-tpool       252:4    0 740.9G  0 lvm
pve-data             252:5    0 740.9G  1 lvm
pve-vm--108--disk--0 252:6    0    10G  0 lvm
pve-vm--107--disk--0 252:7    0    13G  0 lvm
pve-vm--106--disk--0 252:8    0    15G  0 lvm
pve-vm--100--disk--0 252:9    0     4G  0 lvm
pve-vm--101--disk--0 252:10   0     6G  0 lvm
pve-vm--102--disk--0 252:11   0     4G  0 lvm
pve-vm--104--disk--0 252:12   0    25G  0 lvm
pve-vm--103--disk--0 252:13   0    10G  0 lvm
pve-vm--109--disk--0 252:14   0    10G  0 lvm
pve-vm--110--disk--0 252:15   0     6G  0 lvm
pve-vm--111--disk--0 252:16   0    10G  0 lvm
pve-vm--113--disk--0 252:17   0     4G  0 lvm
pve-vm--105--disk--1 252:18   0    10G  0 lvm
nvme0n1              259:0    0 931.5G  0 disk
nvme0n1p1            259:1    0  1007K  0 part
nvme0n1p2            259:2    0     1G  0 part /boot/efi
nvme0n1p3            259:3    0   930G  0 part

Ik heb bij de setup niks bijzonders ingesteld. Alleen een maxroot van 150Gb, zo uit m'n hoofd.
In mijn config staan de container disks op de local-lvm van 795Gb.

code:

root@pve:~# lsblk
NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda                            8:0    0 465.8G  0 disk
└─sda1                         8:1    0 465.8G  0 part /mnt/lvm-backup
nvme0n1                      259:0    0 931.5G  0 disk
├─nvme0n1p1                  259:1    0  1007K  0 part
├─nvme0n1p2                  259:2    0     1G  0 part /boot/efi
└─nvme0n1p3                  259:3    0   930G  0 part
  ├─pve-swap                 252:0    0     8G  0 lvm  ~[SWAP]
  ├─pve-root                 252:1    0   150G  0 lvm  /
  ├─pve-data_tmeta           252:2    0   7.6G  0 lvm
  │ └─pve-data-tpool         252:4    0 740.9G  0 lvm
  │   ├─pve-data             252:5    0 740.9G  1 lvm
  │   ├─pve-vm--108--disk--0 252:6    0    10G  0 lvm
  │   ├─pve-vm--107--disk--0 252:7    0    13G  0 lvm
  │   ├─pve-vm--106--disk--0 252:8    0    15G  0 lvm
  │   ├─pve-vm--100--disk--0 252:9    0     4G  0 lvm
  │   ├─pve-vm--101--disk--0 252:10   0     6G  0 lvm
  │   ├─pve-vm--102--disk--0 252:11   0     4G  0 lvm
  │   ├─pve-vm--104--disk--0 252:12   0    25G  0 lvm
  │   ├─pve-vm--103--disk--0 252:13   0    10G  0 lvm
  │   ├─pve-vm--109--disk--0 252:14   0    10G  0 lvm
  │   ├─pve-vm--110--disk--0 252:15   0     6G  0 lvm
  │   ├─pve-vm--111--disk--0 252:16   0    10G  0 lvm
  │   ├─pve-vm--113--disk--0 252:17   0     4G  0 lvm
  │   └─pve-vm--105--disk--1 252:18   0    10G  0 lvm
  └─pve-data_tdata           252:3    0 740.9G  0 lvm
    └─pve-data-tpool         252:4    0 740.9G  0 lvm
      ├─pve-data             252:5    0 740.9G  1 lvm
      ├─pve-vm--108--disk--0 252:6    0    10G  0 lvm
      ├─pve-vm--107--disk--0 252:7    0    13G  0 lvm
      ├─pve-vm--106--disk--0 252:8    0    15G  0 lvm
      ├─pve-vm--100--disk--0 252:9    0     4G  0 lvm
      ├─pve-vm--101--disk--0 252:10   0     6G  0 lvm
      ├─pve-vm--102--disk--0 252:11   0     4G  0 lvm
      ├─pve-vm--104--disk--0 252:12   0    25G  0 lvm
      ├─pve-vm--103--disk--0 252:13   0    10G  0 lvm
      ├─pve-vm--109--disk--0 252:14   0    10G  0 lvm
      ├─pve-vm--110--disk--0 252:15   0     6G  0 lvm
      ├─pve-vm--111--disk--0 252:16   0    10G  0 lvm
      ├─pve-vm--113--disk--0 252:17   0     4G  0 lvm
      └─pve-vm--105--disk--1 252:18   0    10G  0 lvm

V.w.b. de stop-mode backup: die kende ik nog niet. Zal ik ook een verder in duiken.

[Airw0lf]

@WheeleE - ok bedankt voor de update.

Ik weet nu hoe de nvme precies gebruikt wordt - en dat is prima zo.

Mijn 0,500 Euro:

Je bittorrent Docker container heeft waarschijnlijk een actieve download lopen. Bij een backup met snapshots moet van iedere wijziging een nieuwe kopie gemaakt worden. Waardoor je nvme volloopt en de backup van vm-105 nooit tot een afronding komt.

De backup-stop-functie stopt (een-voor-een!) alle LXC-containers die zijn opgenomen in de backup-job, maakt een backup en start de LXC weer op. Hierdoor wordt de torrent-download ook gestopt en kan de backup afgerond worden.

Ik ben in het verleden meerdere keren tegen dit soort dingen aangelopen rondom iets dat heet LVM-thin provisioning. En heb inmiddels alles overgezet naar LVM-thick provisioning met "harde" maxima op alle LXC-volumes.

Dit haalt alle flexibiliteit eruit - maar maakt het geheel wel super voorspelbaar; o.a. doordat je altijd zicht hebt op het exacte diskgebruik. En een backup die altijd in stop-mode draait zodat de kans van slagen maximaal is.

Nadeel van LVM-thick provisioning is wel dat je meer diskruimte nodig hebt omdat de slimmigheden van LVM-thin niet meer werken. Dit komt doordat de opgegeven diskruimte per LXC-volume meteen wordt aangemerkt als bezet - ook als er feitelijk maar een kleine percentage in gebruik is.

Nadeel bij deze backup-modus is dat de LXC's ook echt gestopt en herstart worden. Maar als ik kijk naar de lsblk output is dat in jouw geval minder dan een uur (ik gok15-30 minuten) voor alle LXC's bij elkaar.

[ Voor 13% gewijzigd door Airw0lf op 26-07-2026 18:50 ]

[Theetjuh]

Hij zou toch alleen alle lxc.mounts niet mee moeten backuppen, hoe kan hij dan problemen hebben met een lopende download?

[Airw0lf]

Theetjuh schreef op zondag 26 juli 2026 @ 18:46:
Hij zou toch alleen alle lxc.mounts niet mee moeten backuppen, hoe kan hij dan problemen hebben met een lopende download?

Ik weet niet precies wat er bij die backups ingesteld is - maar afgaande op de probleemomschrijving en alle geposte informatie lijkt me dit het meest voor de handliggende - in ieder geval voor nu.

[InjecTioN]

dcm360 schreef op zondag 26 juli 2026 @ 14:46:
@InjecTioN Ik was even benieuwd hoe dit zou moeten werken, maar de CIFS-feature mag bij mij niet aan op unprivileged containers, en ik kan verder via de GUI alleen een disk image aanmaken op de CIFS-storage, dat is net wat anders dan een netwerkshare doorkoppelen. Klik ik verkeerd, of werkt dit niet zo?

Ah! Je hebt gelijk. Unprivileged kan inderdaad niet via die route. Dan is een host mount met mountpoint eigenlijk de enige juiste methode. Excuses voor mijn onbedoelde verwarring.

Mogelijk wil je dan inderdaad eens kijken welke processen precies blijven hangen zodra het probleem optreedt. Ik ben benieuwd of er processen in D (uninterruptible sleep) terechtkomen. Dat zou namelijk kunnen verklaren waarom alles blijft hangen tijdens een vzdump.

Op de PVE-host in de terminal, tijdens de vastloper eens uitvoeren:

code:

ps -eo state,pid,ppid,wchan:40,etimes,cmd | awk '$1=="D"'

En voor iedere gevonden PID:

code:

cat /proc/<PID>/stack

Daarmee zie je vaak vrij snel of een proces vastzit in bijvoorbeeld CIFS, de VFS-layer, de block layer of iets anders in de kernel. Dat geeft waarschijnlijk veel meer aanknopingspunten dan alleen de hoge IO Pressure Stall. Het zal je op z'n minst de juiste richting op kunnen duwen!

[WheeleE]

In het omzetten naar NFS gaat iets meer tijd zitten qua uitzoeken van permissies matchen tussen proxmox en de NAS heb ik gemerkt.
Daarom ga ik eerst, met @InjecTioN's tips, kijken wat er onder water precies gebeurt als de boel vastloopt.

@Airw0lf Van wat ik tot nu toe heb gezien stijgt de IO Pressure Stall als er een download actief is. Als de download klaar is of gepauzeert wordt zakt de stall echter niet.
Bij de eerstvolgende backupronde loopt de boel vast, maar pas als de qbittorrent lxc aan de beurt is.

Voor de backups maak ik gebruik van de standaard proxmox job. Ik zie daar in de GUI geen optie voor dus daar duik ik nog ff verder.

[Jerie]

qbittorrent en cifs is een bekende combinatie welke lage performance geeft: https://github.com/arvidn/libtorrent/issues/7480

[fissa]

Iemand een idee? Mijn proxmox is lokaal maar sporadisch te benaderen via het statische ip die ik op de router heb ingesteld. Ping geeft een time out en dan soms, random, is die online en kan ik er snel bij.
M’n home assistent vm in pxe is wel gewoon netjes te benaderen.

Proxmox draait op een mini pc (mllse g2 pro).

[Gizz]

@fissa staan er interessante dingen in je logs? Hoge load? Zie je foutmeldingen op het scherm van je mini pc langskomen?

[fissa]

Gizz schreef op vrijdag 31 juli 2026 @ 19:35:
@fissa staan er interessante dingen in je logs? Hoge load? Zie je foutmeldingen op het scherm van je mini pc langskomen?

Zover ik kan zien niet. In ieder geval, als ik erbij kom; dan zie ik niks bijzonders staan. Proxmox als OS geïnstalleerd op de mini pc trouwens. Draait verder niks behalve HA. Ben er nog niet zo lang geleden mee begonnen, dus er kan eigenlijk weinig load zijn. Of waar kan ik dit checken?

[commentator]

fissa schreef op vrijdag 31 juli 2026 @ 19:26:
Iemand een idee? Mijn proxmox is lokaal maar sporadisch te benaderen via het statische ip die ik op de router heb ingesteld. Ping geeft een time out en dan soms, random, is die online en kan ik er snel bij.
M’n home assistent vm in pxe is wel gewoon netjes te benaderen.

Proxmox draait op een mini pc (mllse g2 pro).

is het niet weer zo'n intel nic waar een patch voor is?

[stormfly]

fissa schreef op vrijdag 31 juli 2026 @ 19:26:
Iemand een idee? Mijn proxmox is lokaal maar sporadisch te benaderen via het statische ip die ik op de router heb ingesteld. Ping geeft een time out en dan soms, random, is die online en kan ik er snel bij.
M’n home assistent vm in pxe is wel gewoon netjes te benaderen.

Proxmox draait op een mini pc (mllse g2 pro).

Duplicate IP in je omgeving waarvan Proxmox er één is?

[MrDirect]

stormfly schreef op vrijdag 31 juli 2026 @ 21:53:
[...]

Duplicate IP in je omgeving waarvan Proxmox er één is?

Dacht ik ook gelijk aan. Klinkt alsof een andere machine ook dat IP gebruikt.

[Airw0lf]

fissa schreef op vrijdag 31 juli 2026 @ 19:43:
[...]

Zover ik kan zien niet. In ieder geval, als ik erbij kom; dan zie ik niks bijzonders staan. Proxmox als OS geïnstalleerd op de mini pc trouwens. Draait verder niks behalve HA. Ben er nog niet zo lang geleden mee begonnen, dus er kan eigenlijk weinig load zijn. Of waar kan ik dit checken?

Ik ga toch de advocaat van de duivel spelen... als je hier nog "niet zo lang geleden mee begonnen" bent hoe weet je dan dat er "niks bijzonders" in de logs staat?

Met in het verlengde: als je de HA-VM wel goed kunt benaderen maar PVE zelf niet dan lijkt me toch echt iets mis in PVE. En dat zou je in /var/log/syslog terug moeten zien... toch?

[Airw0lf]

fissa schreef op vrijdag 31 juli 2026 @ 19:26:
Iemand een idee? Mijn proxmox is lokaal maar sporadisch te benaderen via het statische ip die ik op de router heb ingesteld.

Een statische ip wat je op de router hebt ingesteld? Als in: een op het MAC-adres geabseerde DHCP? En wat als je daar een echt statisch IP van maakt? Dus op de Proxmox server zelf?

[fissa]

Airw0lf schreef op vrijdag 31 juli 2026 @ 22:21:
[...]

Ik ga toch de advocaat van de duivel spelen... als je hier nog "niet zo lang geleden mee begonnen" bent hoe weet je dan dat er "niks bijzonders" in de logs staat?

Met in het verlengde: als je de HA-VM wel goed kunt benaderen maar PVE zelf niet dan lijkt me toch echt iets mis in PVE. En dat zou je in /var/log/syslog terug moeten zien... toch?

Je hebt gelijk, ik refereerde alleen naar de logs onderin de gui, die niks geks lieten zien. Ik ga naar de syslogs kijken!

[Gizz]

fissa schreef op zaterdag 1 augustus 2026 @ 08:43:
[...]

Je hebt gelijk, ik refereerde alleen naar de logs onderin de gui, die niks geks lieten zien. Ik ga naar de syslogs kijken!

Daarom gaf ik ook aan dat je even een scherm aan je proxmox-machine kunt hangen. Dan zie je vanzelf de foutmeldingen langskomen terwijl je apparaat niet bereikbaar is In de GUI zul je niet veel meer zien dan berichten over het starten/stoppen van LXC's/VM's of zaken betreffende backups.

[WheeleE]

InjecTioN schreef op zondag 26 juli 2026 @ 22:04:
[...]

Ah! Je hebt gelijk. Unprivileged kan inderdaad niet via die route. Dan is een host mount met mountpoint eigenlijk de enige juiste methode. Excuses voor mijn onbedoelde verwarring.

Mogelijk wil je dan inderdaad eens kijken welke processen precies blijven hangen zodra het probleem optreedt. Ik ben benieuwd of er processen in D (uninterruptible sleep) terechtkomen. Dat zou namelijk kunnen verklaren waarom alles blijft hangen tijdens een vzdump.

Op de PVE-host in de terminal, tijdens de vastloper eens uitvoeren:

code:

ps -eo state,pid,ppid,wchan:40,etimes,cmd | awk '$1=="D"'

En voor iedere gevonden PID:

code:

cat /proc/<PID>/stack

Daarmee zie je vaak vrij snel of een proces vastzit in bijvoorbeeld CIFS, de VFS-layer, de block layer of iets anders in de kernel. Dat geeft waarschijnlijk veel meer aanknopingspunten dan alleen de hoge IO Pressure Stall. Het zal je op z'n minst de juiste richting op kunnen duwen!

Vandaag was het dan weer zo ver, na 2 relatief high speed downloads liep de IO pressure stall op tot +- 90%
Toen ik een handmatige backup van de qbittorrent container startte liep na een paar minuten de boel echt vast.

Echter...er lijkt niets vast de zitten:

code:

root@pve:~# ps -eo state,pid,ppid,wchan:40,etimes,cmd | awk '$1=="D"'
root@pve:~#

Zelfs toen de backup nog niet liep lukte het niet om de qb-container te stoppen of te herstarten. Ook de qb-docker container herstarten lukte niet.

De pve log / journalctl -r :

code:

Aug 02 14:38:35 pve kernel: PKRU: 55555554
Aug 02 14:38:35 pve kernel: CR2: 0000000000000008 CR3: 00000003b2bf2001 CR4: 0000000000f72ef0
Aug 02 14:38:35 pve kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 02 14:38:35 pve kernel: FS:  00007d3363d51b30(0000) GS:ffff88c1b858e000(0000) knlGS:0000000000000000
Aug 02 14:38:35 pve kernel: R13: ffff88bf21f23578 R14: fffffb2b458e5b00 R15: ffff88bf21f23408
Aug 02 14:38:35 pve kernel: R10: 0000000000000000 R11: ffff88bf21f23578 R12: ffff88bf21f23408
Aug 02 14:38:35 pve kernel: RBP: ffffd008ec01fbf8 R08: 0000000000000000 R09: 0000000000000000
Aug 02 14:38:35 pve kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
Aug 02 14:38:35 pve kernel: RAX: 0000000000000000 RBX: ffff88c0397bbf00 RCX: 0000000000000000
Aug 02 14:38:35 pve kernel: RSP: 0018:ffffd008ec01fba0 EFLAGS: 00010246
Aug 02 14:38:35 pve kernel: Code: 31 db c3 cc cc cc cc 49 8b 46 28 4d 8b 5e 18 48 c7 45 d0 00 00 00 00 48 89 45 c0 a8 01 0f 85 b3 02 00 00 48 8b 45 d0 4d 8b 3b <44> 8b 68 08 8b 40 0c 89 45 bc 49 8b 06 a8 40 0f 84 84 02 00 00 49
Aug 02 14:38:35 pve kernel: RIP: 0010:netfs_read_folio+0x1a5/0x640 [netfs]
Aug 02 14:38:35 pve kernel: ---[ end trace 0000000000000000 ]---
Aug 02 14:38:35 pve kernel: CR2: 0000000000000008
Aug 02 14:38:35 pve kernel:  soundcore mtd ee1004 mei i2c_algo_bit igen6_edac serial_multi_instantiate mc acpi_tad intel_vsec acpi_pad mac_hid zfs(PO) spl(O) msr vhost_net vhost vhost_iotlb tap efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 btrfs libblake2b xor raid6_pq >
Aug 02 14:38:35 pve kernel:  snd_sof_xtensa_dsp snd_sof snd_sof_utils snd_soc_acpi_intel_match snd_soc_acpi_intel_sdca_quirks drm_gpusvm_helper soundwire_generic_allocation gpu_sched snd_soc_sdw_utils intel_rapl_msr drm_gpuvm snd_soc_acpi intel_rapl_common drm_ttm_helper soundwire_>
Aug 02 14:38:35 pve kernel: Modules linked in: tcp_diag inet_diag uas input_leds usb_storage usbkbd joydev usbmouse dm_snapshot nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace xt_mark wireguard libcurve25519 ip6_udp_tunnel udp_tunnel xt_nat xt_tcpudp nf_conntrack_ne>
Aug 02 14:38:35 pve kernel:  </TASK>
Aug 02 14:38:35 pve kernel: R13: 00007d336454caa0 R14: 00007d3363d50c7f R15: 00007d32e3fe97c0
Aug 02 14:38:35 pve kernel: R10: 00000000239c27eb R11: 0000000000000246 R12: 0000000000004000
Aug 02 14:38:35 pve kernel: RBP: 00007d2978acaf7c R08: 000000007ffaf3bf R09: 00000000ffebffff
Aug 02 14:38:35 pve kernel: RDX: 0000000000000100 RSI: 00007d2978acaf7c RDI: 00007d3363d50d10
Aug 02 14:38:35 pve kernel: RAX: 0000000000004000 RBX: 00007d3363d50d10 RCX: 0000000000000000
Aug 02 14:38:35 pve kernel: RSP: 002b:00007d3363d50828 EFLAGS: 00010206
Aug 02 14:38:35 pve kernel: Code: 8d 26 f3 c3 90 66 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 6f 07 66 0f 6e 4f 10 66 0f 6f 1d 2f 7d 01 ff <f3> 0f 6f 26 66 0f 70 c0 1b f3 0f 6f 6e 10 66 0f 70 c9 1b f3 0f 6f
Aug 02 14:38:35 pve kernel: RIP: 0033:0x7d3367b559b1
Aug 02 14:38:35 pve kernel:  asm_exc_page_fault+0x27/0x30
Aug 02 14:38:35 pve kernel:  exc_page_fault+0x81/0x1c0
Aug 02 14:38:35 pve kernel:  do_user_addr_fault+0x2f8/0x820
Aug 02 14:38:35 pve kernel:  handle_mm_fault+0x136/0x3a0
Aug 02 14:38:35 pve kernel:  __handle_mm_fault+0x9d5/0x1030
Aug 02 14:38:35 pve kernel:  ? x64_sys_call+0x1be6/0x2390
Aug 02 14:38:35 pve kernel:  do_fault+0x33a/0x580
Aug 02 14:38:35 pve kernel:  __do_fault+0x3d/0x190
Aug 02 14:38:35 pve kernel:  filemap_fault+0xa27/0x1300
Aug 02 14:38:35 pve kernel:  filemap_read_folio+0x42/0xf0
Aug 02 14:38:35 pve kernel:  ? __pfx_netfs_read_folio+0x10/0x10 [netfs]
Aug 02 14:38:35 pve kernel:  <TASK>
Aug 02 14:38:35 pve kernel: Call Trace:
Aug 02 14:38:35 pve kernel: PKRU: 55555554
Aug 02 14:38:35 pve kernel: CR2: 0000000000000008 CR3: 00000003b2bf2001 CR4: 0000000000f72ef0
Aug 02 14:38:35 pve kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 02 14:38:35 pve kernel: FS:  00007d3363d51b30(0000) GS:ffff88c1b858e000(0000) knlGS:0000000000000000
Aug 02 14:38:35 pve kernel: R13: ffff88bf21f23578 R14: fffffb2b458e5b00 R15: ffff88bf21f23408
Aug 02 14:38:35 pve kernel: R10: 0000000000000000 R11: ffff88bf21f23578 R12: ffff88bf21f23408
Aug 02 14:38:35 pve kernel: RBP: ffffd008ec01fbf8 R08: 0000000000000000 R09: 0000000000000000
Aug 02 14:38:35 pve kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
Aug 02 14:38:35 pve kernel: RAX: 0000000000000000 RBX: ffff88c0397bbf00 RCX: 0000000000000000
Aug 02 14:38:35 pve kernel: RSP: 0018:ffffd008ec01fba0 EFLAGS: 00010246
Aug 02 14:38:35 pve kernel: Code: 31 db c3 cc cc cc cc 49 8b 46 28 4d 8b 5e 18 48 c7 45 d0 00 00 00 00 48 89 45 c0 a8 01 0f 85 b3 02 00 00 48 8b 45 d0 4d 8b 3b <44> 8b 68 08 8b 40 0c 89 45 bc 49 8b 06 a8 40 0f 84 84 02 00 00 49
Aug 02 14:38:35 pve kernel: RIP: 0010:netfs_read_folio+0x1a5/0x640 [netfs]
Aug 02 14:38:35 pve kernel: Hardware name: Intel(R) Client Systems NUC12WSHi3/NUC12WSBi3, BIOS WSADL357.0086.2022.1103.1433 11/03/2022
Aug 02 14:38:35 pve kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE
Aug 02 14:38:35 pve kernel: CPU: 9 UID: 100911 PID: 1222749 Comm: qbittorrent-nox Tainted: P           O        7.0.12-1-pve #1 PREEMPT(lazy)
Aug 02 14:38:35 pve kernel: Oops: Oops: 0000 [#1] SMP NOPTI
Aug 02 14:38:35 pve kernel: PGD 0 P4D 0
Aug 02 14:38:35 pve kernel: #PF: error_code(0x0000) - not-present page
Aug 02 14:38:35 pve kernel: #PF: supervisor read access in kernel mode
Aug 02 14:38:35 pve kernel: BUG: kernel NULL pointer dereference, address: 0000000000000008

Tijd voor weer een reboot dan maar.

[Airw0lf]

@WheeleE - je qb-container was op dat moment zijn tanden aan het stukbijten op een netwerkschijf - dit blijkt uit het deel van de trace wat je hebt gepost met in het bijzonder de passage: pfx_netfs_read_folio+0x10/0x10 [netfs] Aug 02 14:38:35 pve kernel: <TASK>

Wat heb je ook weer aan filesystems geladen in deze lxc-container? En op welke manier?

[WheeleE]

@Airw0lf het is een cifs share op de pve host die met een mount point naar de lxc wordt doorgegeven.
Ik ga de komende week eens puzzelen om de boel om te zetten naar een NFS share. Kijken of dat helpt.

[Airw0lf]

WheeleE schreef op zondag 2 augustus 2026 @ 21:25:
@Airw0lf het is een cifs share op de pve host die met een mount point naar de lxc wordt doorgegeven.
Ik ga de komende week eens puzzelen om de boel om te zetten naar een NFS share. Kijken of dat helpt.

En waarom de share niet rechtstreeks in de LXC mounten?

[WheeleE]

Omdat het een unprivileged lxc is, en daar kan dat niet in voor zover ik weet.

[Airw0lf]

Verkeerd voorbeeld - weggehaald.

Schijnt wel te kunnen via iets dat heet fuse.

Bij nfs schijnt hetzelfde probleem te spelen - ook die weg schijnt via de host of via fuse te lopen.

Proxmox geeft in beide gevallen aan dat een mount via de host de voorkeur heeft.

[ Voor 182% gewijzigd door Airw0lf op 02-08-2026 21:54 ]

[Theetjuh]

Hier een nfs mount via autofs, echt nog nooit issues mee gehad.
Moet ook zeggen dat ik eigenlijk geen Windows meer gebruik behalve voor het werk, anders alleen linux.

[Jerie]

WheeleE schreef op zondag 2 augustus 2026 @ 17:15:
[...]

Vandaag was het dan weer zo ver, na 2 relatief high speed downloads liep de IO pressure stall op tot +- 90%
Toen ik een handmatige backup van de qbittorrent container startte liep na een paar minuten de boel echt vast.

Echter...er lijkt niets vast de zitten:

code:

root@pve:~# ps -eo state,pid,ppid,wchan:40,etimes,cmd | awk '$1=="D"'
root@pve:~#

Zelfs toen de backup nog niet liep lukte het niet om de qb-container te stoppen of te herstarten. Ook de qb-docker container herstarten lukte niet.

De pve log / journalctl -r :

code:

Aug 02 14:38:35 pve kernel: PKRU: 55555554
Aug 02 14:38:35 pve kernel: CR2: 0000000000000008 CR3: 00000003b2bf2001 CR4: 0000000000f72ef0
Aug 02 14:38:35 pve kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 02 14:38:35 pve kernel: FS:  00007d3363d51b30(0000) GS:ffff88c1b858e000(0000) knlGS:0000000000000000
Aug 02 14:38:35 pve kernel: R13: ffff88bf21f23578 R14: fffffb2b458e5b00 R15: ffff88bf21f23408
Aug 02 14:38:35 pve kernel: R10: 0000000000000000 R11: ffff88bf21f23578 R12: ffff88bf21f23408
Aug 02 14:38:35 pve kernel: RBP: ffffd008ec01fbf8 R08: 0000000000000000 R09: 0000000000000000
Aug 02 14:38:35 pve kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
Aug 02 14:38:35 pve kernel: RAX: 0000000000000000 RBX: ffff88c0397bbf00 RCX: 0000000000000000
Aug 02 14:38:35 pve kernel: RSP: 0018:ffffd008ec01fba0 EFLAGS: 00010246
Aug 02 14:38:35 pve kernel: Code: 31 db c3 cc cc cc cc 49 8b 46 28 4d 8b 5e 18 48 c7 45 d0 00 00 00 00 48 89 45 c0 a8 01 0f 85 b3 02 00 00 48 8b 45 d0 4d 8b 3b <44> 8b 68 08 8b 40 0c 89 45 bc 49 8b 06 a8 40 0f 84 84 02 00 00 49
Aug 02 14:38:35 pve kernel: RIP: 0010:netfs_read_folio+0x1a5/0x640 [netfs]
Aug 02 14:38:35 pve kernel: ---[ end trace 0000000000000000 ]---
Aug 02 14:38:35 pve kernel: CR2: 0000000000000008
Aug 02 14:38:35 pve kernel:  soundcore mtd ee1004 mei i2c_algo_bit igen6_edac serial_multi_instantiate mc acpi_tad intel_vsec acpi_pad mac_hid zfs(PO) spl(O) msr vhost_net vhost vhost_iotlb tap efi_pstore nfnetlink dmi_sysfs ip_tables x_tables autofs4 btrfs libblake2b xor raid6_pq >
Aug 02 14:38:35 pve kernel:  snd_sof_xtensa_dsp snd_sof snd_sof_utils snd_soc_acpi_intel_match snd_soc_acpi_intel_sdca_quirks drm_gpusvm_helper soundwire_generic_allocation gpu_sched snd_soc_sdw_utils intel_rapl_msr drm_gpuvm snd_soc_acpi intel_rapl_common drm_ttm_helper soundwire_>
Aug 02 14:38:35 pve kernel: Modules linked in: tcp_diag inet_diag uas input_leds usb_storage usbkbd joydev usbmouse dm_snapshot nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace xt_mark wireguard libcurve25519 ip6_udp_tunnel udp_tunnel xt_nat xt_tcpudp nf_conntrack_ne>
Aug 02 14:38:35 pve kernel:  </TASK>
Aug 02 14:38:35 pve kernel: R13: 00007d336454caa0 R14: 00007d3363d50c7f R15: 00007d32e3fe97c0
Aug 02 14:38:35 pve kernel: R10: 00000000239c27eb R11: 0000000000000246 R12: 0000000000004000
Aug 02 14:38:35 pve kernel: RBP: 00007d2978acaf7c R08: 000000007ffaf3bf R09: 00000000ffebffff
Aug 02 14:38:35 pve kernel: RDX: 0000000000000100 RSI: 00007d2978acaf7c RDI: 00007d3363d50d10
Aug 02 14:38:35 pve kernel: RAX: 0000000000004000 RBX: 00007d3363d50d10 RCX: 0000000000000000
Aug 02 14:38:35 pve kernel: RSP: 002b:00007d3363d50828 EFLAGS: 00010206
Aug 02 14:38:35 pve kernel: Code: 8d 26 f3 c3 90 66 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 6f 07 66 0f 6e 4f 10 66 0f 6f 1d 2f 7d 01 ff <f3> 0f 6f 26 66 0f 70 c0 1b f3 0f 6f 6e 10 66 0f 70 c9 1b f3 0f 6f
Aug 02 14:38:35 pve kernel: RIP: 0033:0x7d3367b559b1
Aug 02 14:38:35 pve kernel:  asm_exc_page_fault+0x27/0x30
Aug 02 14:38:35 pve kernel:  exc_page_fault+0x81/0x1c0
Aug 02 14:38:35 pve kernel:  do_user_addr_fault+0x2f8/0x820
Aug 02 14:38:35 pve kernel:  handle_mm_fault+0x136/0x3a0
Aug 02 14:38:35 pve kernel:  __handle_mm_fault+0x9d5/0x1030
Aug 02 14:38:35 pve kernel:  ? x64_sys_call+0x1be6/0x2390
Aug 02 14:38:35 pve kernel:  do_fault+0x33a/0x580
Aug 02 14:38:35 pve kernel:  __do_fault+0x3d/0x190
Aug 02 14:38:35 pve kernel:  filemap_fault+0xa27/0x1300
Aug 02 14:38:35 pve kernel:  filemap_read_folio+0x42/0xf0
Aug 02 14:38:35 pve kernel:  ? __pfx_netfs_read_folio+0x10/0x10 [netfs]
Aug 02 14:38:35 pve kernel:  <TASK>
Aug 02 14:38:35 pve kernel: Call Trace:
Aug 02 14:38:35 pve kernel: PKRU: 55555554
Aug 02 14:38:35 pve kernel: CR2: 0000000000000008 CR3: 00000003b2bf2001 CR4: 0000000000f72ef0
Aug 02 14:38:35 pve kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 02 14:38:35 pve kernel: FS:  00007d3363d51b30(0000) GS:ffff88c1b858e000(0000) knlGS:0000000000000000
Aug 02 14:38:35 pve kernel: R13: ffff88bf21f23578 R14: fffffb2b458e5b00 R15: ffff88bf21f23408
Aug 02 14:38:35 pve kernel: R10: 0000000000000000 R11: ffff88bf21f23578 R12: ffff88bf21f23408
Aug 02 14:38:35 pve kernel: RBP: ffffd008ec01fbf8 R08: 0000000000000000 R09: 0000000000000000
Aug 02 14:38:35 pve kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
Aug 02 14:38:35 pve kernel: RAX: 0000000000000000 RBX: ffff88c0397bbf00 RCX: 0000000000000000
Aug 02 14:38:35 pve kernel: RSP: 0018:ffffd008ec01fba0 EFLAGS: 00010246
Aug 02 14:38:35 pve kernel: Code: 31 db c3 cc cc cc cc 49 8b 46 28 4d 8b 5e 18 48 c7 45 d0 00 00 00 00 48 89 45 c0 a8 01 0f 85 b3 02 00 00 48 8b 45 d0 4d 8b 3b <44> 8b 68 08 8b 40 0c 89 45 bc 49 8b 06 a8 40 0f 84 84 02 00 00 49
Aug 02 14:38:35 pve kernel: RIP: 0010:netfs_read_folio+0x1a5/0x640 [netfs]
Aug 02 14:38:35 pve kernel: Hardware name: Intel(R) Client Systems NUC12WSHi3/NUC12WSBi3, BIOS WSADL357.0086.2022.1103.1433 11/03/2022
Aug 02 14:38:35 pve kernel: Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE
Aug 02 14:38:35 pve kernel: CPU: 9 UID: 100911 PID: 1222749 Comm: qbittorrent-nox Tainted: P           O        7.0.12-1-pve #1 PREEMPT(lazy)
Aug 02 14:38:35 pve kernel: Oops: Oops: 0000 [#1] SMP NOPTI
Aug 02 14:38:35 pve kernel: PGD 0 P4D 0
Aug 02 14:38:35 pve kernel: #PF: error_code(0x0000) - not-present page
Aug 02 14:38:35 pve kernel: #PF: supervisor read access in kernel mode
Aug 02 14:38:35 pve kernel: BUG: kernel NULL pointer dereference, address: 0000000000000008

Tijd voor weer een reboot dan maar.

Dat heb je hoe dan ook een tijdje niet gedaan, aan de Linux kernel te zien. Ik zie ZFS. Welke versie? Zit namelijk een bug in. Nog steeds bezig met CIFS?

[Airw0lf]

Theetjuh schreef op zondag 2 augustus 2026 @ 22:44:
Hier een nfs mount via autofs, echt nog nooit issues mee gehad.

Maar dit gebruik je dan vanuit de Proxmox host of een VM - niet een LXC container - toch?

[Theetjuh]

Airw0lf schreef op maandag 3 augustus 2026 @ 07:27:
[...]

Maar dit gebruik je dan vanuit de Proxmox host of een VM - niet een LXC container - toch?

Gemount met autofs op de host inderdaad en dan een lxc.mount in de lxc

[WheeleE]

@Jerie ik heb medio juni de boel compleet vers geïnstalleerd en geupdated, met de pve iso.
En sindsdien ook minstens 10 keer alles gereboot, zo niet vaker.
De huidige ZFS versie: : Loaded module v2.4.2-pve1, ZFS pool version 5000, ZFS filesystem version 5.

Het hele qbittorrent gebeuren is een nice to have maar zeker niet noodzakelijk. Als ik NFS aan de praat krijg en het probleem blijft daar ook mee bestaan dan gooi ik het geheel gewoon weg.

[orvintax]

WheeleE schreef op maandag 3 augustus 2026 @ 10:03:
@Jerie ik heb medio juni de boel compleet vers geïnstalleerd en geupdated, met de pve iso.
En sindsdien ook minstens 10 keer alles gereboot, zo niet vaker.
De huidige ZFS versie: : Loaded module v2.4.2-pve1, ZFS pool version 5000, ZFS filesystem version 5.

Het hele qbittorrent gebeuren is een nice to have maar zeker niet noodzakelijk. Als ik NFS aan de praat krijg en het probleem blijft daar ook mee bestaan dan gooi ik het geheel gewoon weg.

Mogelijk is het nog een optie om de download iets anders op te zetten. Dat je hem eerst lokaal (lees niet over NFS) download. Wanneer de download dan klaar is kan je hem in een keer overzetten.

[Pendora]

WheeleE schreef op zondag 2 augustus 2026 @ 21:25:
@Airw0lf het is een cifs share op de pve host die met een mount point naar de lxc wordt doorgegeven.
Ik ga de komende week eens puzzelen om de boel om te zetten naar een NFS share. Kijken of dat helpt.

Zelfde issue gehad. In mijn situatie had ik een VM met OpenMediaVault voor de NFS shares. Deze geprobeerd zowel via PVE mounted doorgegeven aan de LXC's en direct via FSTAB op privileged LXC's.

Alleen bij nieuwsgroepen downloads had ik het issues dat Proxmox uiteindelijk zich zo vast beet in het netwerk gedeelte dat die vol crashte. Maar de VM HA bleef wel werken... De LXC's die geen shares hadden bleven ook werken. Proxmox zelf was niet meer benaderbaar.

Uiteindelijk had ik een Debian VM aangemaakt in plaats van OMV die de NFS shares beheerde en waarop ik de Usenet software had geïnstalleerd zodat die geen share meer nodig had. Dit was het enige wat bij mij heeft gewerkt als je geen NAS erbij koopt.

[powerboat]

Ik blijf toch een vm adviseren omdat je toch wel wat load legt op die container. Containers zijn hier niet geschikt voor.

Wil je toch bij de container blijven, dan maak een nfs share of iscsi op je storage en mount deze in proxmox en plaats je container daar op. Je hoeft dan nl. geen share in je vm te mounten.

[Jerie]

powerboat schreef op woensdag 5 augustus 2026 @ 15:56:
Ik blijf toch een vm adviseren omdat je toch wel wat load legt op die container. Containers zijn hier niet geschikt voor.

Wil je toch bij de container blijven, dan maak een nfs share of iscsi op je storage en mount deze in proxmox en plaats je container daar op. Je hoeft dan nl. geen share in je vm te mounten.

Waarom zijn containers ongeschikt voor load? Ik draai allerlei containers in een VM, werkt prima.

De suggestie is om het met NFS(v4) te proberen. Kernel-space is behoorlijk simpel in te stellen.

Werkt dat niet, kun je misschien tmp op een tmpfs (RAM) of NVMe wegschrijven. Ik zou met een snelle downloadverbinding (denk aan glasvezel) wel oppassen als je ergens een trager medium gebruikt (zoals SATA HDD met encryptie) want de queue kan behoorlijk groot worden bij grote/veel downloads. Dan kan je cache (of dat nou RAM of NVMe is) vol geraken.

[WheeleE]

Ik ben er nog niet aan toegekomen om te switchen naar NFS.
Het is ook geen halszaak verder. Als ik m'n extra downloadbak voor nonessentials weg doen is er geen man over boord.

Het enige wat ik apart blijf vinden is dat exact dezelfde constructie het met Proxmox 8 wel probleemloss deed, en sinds v9 niet meer. Weliswaar is de qbittorrent-Docker-lxc nu Debian 13 ipv 12, maar toch.

Anyhow, alle tips en meedenken van iedereen hier zijn desondanks erg gewaardeerd

[Theetjuh]

Je gebruikt op je proxmox een lxc met daarin docker voor qbittorrent?

Dus op je proxmox host doe je de mount met smb, deze geef je door aan je lxc, waarin je deze weer doorgeeft aan docker, waar je qbittorrent in draait.

Je ziet misschien aan m’n zin … waarom zoiets niet goed zou kunnen gaan.
Ik draai enkel lxc’s … geen docker, want je werkt al in een container, wat meer dan prima kan met qbittorrent.
Mocht je het nog niet kennen: Proxmox VE Scripts

[WheeleE]

Theetjuh schreef op woensdag 5 augustus 2026 @ 17:45:
Je gebruikt op je proxmox een lxc met daarin docker voor qbittorrent?

Dus op je proxmox host doe je de mount met smb, deze geef je door aan je lxc, waarin je deze weer doorgeeft aan docker, waar je qbittorrent in draait.

Je ziet misschien aan m’n zin … waarom zoiets niet goed zou kunnen gaan.
Ik draai enkel lxc’s … geen docker, want je werkt al in een container, wat meer dan prima kan met qbittorrent.
Mocht je het nog niet kennen: Proxmox VE Scripts

Correct, dat is mijn setup. Opgezet d.m.v. de Proxmox Helper Scripts
Ik heb indertijd voor deze variant gekozen omdat ik het QB-verkeer via een vpn wilde routeren. Dat had ik al aan de praat via Docker, maar lukte me niet via een losse vpn lxc.

Het is misschien niet de meest efficiënte manier, maar het werkte probleemloos. Dus ik had geen reden om het anders te willen.

[MrDirect]

Moet ook gewoon prima kunnen, docker in lxc. Waar je probleem wel zit weet ik ook niet, maar ik kan mij niet voorstellen dat het aan de combi lxc/docker ligt.

[Theetjuh]

Het zal ook prima kunnen werken, maar Proxmox raadt niet voor niets het niet aan om in een LXC te draaien, maar juist in een VM.

Maar ik zou zeggen, kijk eens naar gluetun, draait in een lxc, als je je qbit daar weer achter zet, ben je er ook

[Jerie]

VM kun je met OCI of LXC combineren.

LXC met daaronder OCI is onnodig.

Wat je ook gewoon kunt doen is op host OS een wg interface maken met een VPN provider. Vervolgens als je die interface of dat IP als default gateway gebruikt op een VM of OCI dan gaat al het verkeer via die interface. Wel opletten dat je geen andere default gateway hebt met minder prioriteit. En IPv6 voor de zekerheid uitschakelen op de client VM/OCI, en even opletten op DNS leaks. Dat is in dit geval waarschijnlijk niet wat je wilt.

Iets als Gluetun doet bovenstaande waarschijnlijk met een relatief makkelijke abstractie.

[WheeleE]

De Guetun lxc ken ik, alleen schiet/schoot mijn netwerkkennis nog te kort om daar verkeer door te routeren.

V.w.b. de VM-adviezen: bedoelen jullie een (privileged) docker-vm, en vervolgens in de vm een directe mount naar de NAS maken? Zodat het niet via de proxmox-host en een lxc-mount loopt?

[Jerie]

Proxmox voor ARM64 is uit:

https://forum.proxmox.com...-64-bit-arm-arm64.185527/

Voor je enthusiast wordt: het gaat niet officieel werken op SBCs met device trees zoals Raspberry Pi. Denk eerder aan een Ampere machine, of een Nvidia Grace Hopper. Jammer, want ik zou het graag willen draaien op een Jetson.

[zeroday]

WheeleE schreef op maandag 3 augustus 2026 @ 10:03:
@Jerie ik heb medio juni de boel compleet vers geïnstalleerd en geupdated, met de pve iso.
En sindsdien ook minstens 10 keer alles gereboot, zo niet vaker.
De huidige ZFS versie: : Loaded module v2.4.2-pve1, ZFS pool version 5000, ZFS filesystem version 5.

Het hele qbittorrent gebeuren is een nice to have maar zeker niet noodzakelijk. Als ik NFS aan de praat krijg en het probleem blijft daar ook mee bestaan dan gooi ik het geheel gewoon weg.

Ik werk al heel lang met qbittorrent via SMB share want NFS deed niet wat ik wilde

//10.1.1.141/Torrents /media/torrents cifs credentials=/home/smb,vers=3.0,noperm,x-systemd.automount 0 0
is in mijn /etc/fstab

Werkt hier als een tierelier, wel weer gezegd hebbende dat ik deze versie gebruik

Qt: 5.15.4
Libtorrent:2.0.7.0
Boost:1.74.0
OpenSSL:3.0.5
zlib: 1.2.11

Andere versie(s) gaven bij mij performance issues, waar dat aan ligt geen idee. Maar daar kakte de downloads in of bleef het gewoon niet stabiel. Dit hier werkt op lxc al erg lang ok

[RobertMe]

Jerie schreef op donderdag 6 augustus 2026 @ 02:54:
Proxmox voor ARM64 is uit:

https://forum.proxmox.com...-64-bit-arm-arm64.185527/

Voor je enthusiast wordt: het gaat niet officieel werken op SBCs met device trees zoals Raspberry Pi. Denk eerder aan een Ampere machine, of een Nvidia Grace Hopper. Jammer, want ik zou het graag willen draaien op een Jetson.

De limitatie zal dan zitten in dat UEFI en de hele riedel nodig is? Volgens mij zijn daar wel wat opties voor. Meen dat Uboot ook UEFI "kan doen", incl device tree achtig gebeuren aan de achterkant. Dus het apparaat boot dan nog steeds Uboot maar, in combinatie met een device tree, "emuleert" die UEFI en kun je elk OS dat met UEFI werkt gewoon gebruiken alsof "de hardware UEFI ondersteund".

[Cyphax]

Jerie schreef op donderdag 6 augustus 2026 @ 02:54:
Proxmox voor ARM64 is uit:

https://forum.proxmox.com...-64-bit-arm-arm64.185527/

Voor je enthusiast wordt: het gaat niet officieel werken op SBCs met device trees zoals Raspberry Pi. Denk eerder aan een Ampere machine, of een Nvidia Grace Hopper. Jammer, want ik zou het graag willen draaien op een Jetson.

In de commentaren onder de video van Jeff Geerling beweert iemand het op een Pi5 draaiende te hebben gekregen.

YouTube: FINALLY! Proxmox officially supports Arm (but not Raspberry Pi)

[Jerie]

Cyphax schreef op donderdag 6 augustus 2026 @ 11:18:
[...]

In de commentaren onder de video van Jeff Geerling beweert iemand het op een Pi5 draaiende te hebben gekregen.

YouTube: FINALLY! Proxmox officially supports Arm (but not Raspberry Pi)

Ja, gaaf. Pimox bestond al langer, sinds Proxmox 7 als ik het wel heb.

Zie o.a. https://github.com/pimox/pimox7

Probleem is dat je dan afhankelijk bent van een third party. Dat is nu nog steeds zo met RPi, maat minder. Heeft iets met device tree en bootloader.

[orvintax]

WheeleE schreef op woensdag 5 augustus 2026 @ 19:38:
V.w.b. de VM-adviezen: bedoelen jullie een (privileged) docker-vm, en vervolgens in de vm een directe mount naar de NAS maken? Zodat het niet via de proxmox-host en een lxc-mount loopt?

Er bestaat niet zo iets als een unprivileged/privileged VM, maar voor de rest is dat wel wat ze bedoelen.

[Shinji]

GoBieN-Be schreef op woensdag 19 november 2025 @ 20:52:
Er is blijkbaar zelfs een community script:
https://community-scripts...pts?id=nic-offloading-fix

Ik had nooit meer gemeld, maar dit heeft geholpen inderdaad.

[powerboat]

WheeleE schreef op woensdag 5 augustus 2026 @ 19:38:
V.w.b. de VM-adviezen: bedoelen jullie een (privileged) docker-vm, en vervolgens in de vm een directe mount naar de NAS maken? Zodat het niet via de proxmox-host en een lxc-mount loopt?

Een VM aanmaken i.p.v. een LXC-container, daarin Docker installeren.

Het voordeel is dat je een volledig geïsoleerd systeem krijgt waarbij je de hypervisor niet om zeep helpt bij een te hoge load o.i.d. (of je moet de boel flink over committen) tevens is het security technische veiliger.

[Thomas H]

WheeleE schreef op zondag 2 augustus 2026 @ 21:33:
Omdat het een unprivileged lxc is, en daar kan dat niet in voor zover ik weet.

Ik heb, al jaren, letterlijk tientallen unpriviliged LXC's draaien. Twee met docker, zonder issues, een stuk of 10 met bindmounts. Dat is echt geen issue met unpriviliged LXC's. Je moet een stukje storage op de host oormerken als gebruik in deze LXC's, toewijzen aan een specifieke user ID (zoals nummer 1000) op de host. Vervolgens kun je, in de configuratie van de betreffende LXC's, user ID (bv) 1000 op de host koppelen met user ID 1000 in de container. Die user moet dan de services draaien die willen schrijven op de bindmounts.

Hier staat e.e.a. uitgelegd:

https://www.itsembedded.com/sysadmin/proxmox_bind_unprivileged_lxc/

https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

Ik kan eventueel een voorbeeldconfiguratie delen met jullie. Vergeet vooral niet aan te merken dat je de bindmount niet moet backuppen

[WheeleE]

@Thomas H Dankjewel, volgens mij heb ik een vergelijkbare setup:https://forum.proxmox.com/threads/tutorial-unprivileged-lxcs-mount-cifs-shares.101795/

Alleen de bindmount uit de backup laten moet ik nog nalopen.

[Thomas H]

Ha interessante post. Bij mij speelt Samba geen rol, ik doe zoveel mogelijk op de server, mijn storage pool is ook onderdeel van dezelfde unit.

[The-Source]

Voor thuisserver ga ik als de verkoop doorgaat binnenkort leuke upgrade maken.
Van 2x 48GB DDR5 4800MT/s (dual channel) icm AMD Ryzen 7 8700G (8 core / 16 thread) naar,
16x 32GB DDR4 2600MT (octa channel) en 2x AMD EPYC 7663 (56core / 112 thread)^2x

Iets met hobby enzo

[orvintax]

The-Source schreef op dinsdag 11 augustus 2026 @ 11:15:
Voor thuisserver ga ik als de verkoop doorgaat binnenkort leuke upgrade maken.
Van 2x 48GB DDR5 4800MT/s (dual channel) icm AMD Ryzen 7 8700G (8 core / 16 thread) naar,
16x 32GB DDR4 2600MT (octa channel) en 2x AMD EPYC 7663 (56core / 112 thread)^2x

Iets met hobby enzo

Waar woon je ongeveer?

Nee, het klinkt wel als een hele leuke upgrade!

[Quad]

Ook een aardige upgrade voor je energierekening denk ik.

[The-Source]

Quad schreef op dinsdag 11 augustus 2026 @ 11:34:
Ook een aardige upgrade voor je energierekening denk ik.

Klopt maar huidig systeem draait ook wel lekker. Maar idle ga ik van 35w naar ongeveer 75w is de verwachting.
Full load is ander verhaal, huidige cpu heeft tdp 65w en deze hebben per stuk 225w TDP.
Maar heb zelf veel stroom over, thuis accu etc dus stroom is niet direct een zorg maar heb dat wel mee genomen.
Maar dit systeem heeft ook andere PSU nodig dus nu wel gelijk voor 80 Plus Titanium voeding gegaan (die ook 2x CPU kabel heeft)

orvintax schreef op dinsdag 11 augustus 2026 @ 11:23:
[...]

Waar woon je ongeveer?

Nee, het klinkt wel als een hele leuke upgrade!

Regio Amersfoort

[ Voor 15% gewijzigd door The-Source op 11-08-2026 11:50 ]

[Quad]

@The-Source en een hobby mag ook wel een beetje geld kosten.

[RobertMe]

orvintax schreef op dinsdag 11 augustus 2026 @ 11:23:
[...]

Waar woon je ongeveer?

Nee, het klinkt wel als een hele leuke upgrade!

Zodat je weet wat er gaande is bij stroomuitval?

[orvintax]

RobertMe schreef op dinsdag 11 augustus 2026 @ 12:51:
[...]

Zodat je weet wat er gaande is bij stroomuitval?

Was als grapje bedoeld omdat hij upgraded naar 16x 32GB RAM

[The-Source]

Quad schreef op dinsdag 11 augustus 2026 @ 12:48:
@The-Source en een hobby mag ook wel een beetje geld kosten.

Goedkoopste 'onderdeel' wat al 50 euro kost is de koelpasta (TPM7950 maar aangezien de die 'ietsjes' groter is kom je niet weg met kleine velletjes)

[Renegade666]

Allen,

ik heb sinds dit weekend een klein cluster draaien met 4x hp sff pctjes in combi met ceph en ha
Moet zeggen dat het allemaal prima werkt. Heb het nodige gemigreerd van mijn Truenas af, op de Arr dingen na, ivm 10Gbit

Ik zit alleen even met 1 ding te prutsen gisteren.
Ik heb 1 pctje voorzien van een Nvidia quadro T1000, zodat ik die kan door zetten naar een plex-lcx.
Echter ik krijg de nvidia drivers er maar niet op. hij faalt tekens bij kernel modules maken.
Nu is de pc met SecureBoot, maar ook de dingen die op proxmox en github had gevonden, werken niet.
Iemand een idee waarom dit niet gewoon werkt?
Hij wordt wel gezien op host als in lcx als ik de installatie doe. Maar omdat er geen driver is doet hij niet.
De intel chip word ook gezien, en die wordt dan ook standaard gebruikt, en die werkt dan wel gewoon en zichtbaar in plex.

En backups werken helaas niet met de LCX containers. heeft geen rechten Iemand een idee hoe ik dat kan fixen.
De VM's doet hij wel zonder problemen.

[ Voor 8% gewijzigd door Renegade666 op 12-08-2026 08:40 ]

[Cyphax]

Renegade666 schreef op woensdag 12 augustus 2026 @ 08:36:
Allen,

ik heb sinds dit weekend een klein cluster draaien met 4x hp sff pctjes in combi met ceph en ha
Moet zeggen dat het allemaal prima werkt. Heb het nodige gemigreerd van mijn Truenas af, op de Arr dingen na, ivm 10Gbit

Ik zit alleen even met 1 ding te prutsen gisteren.
Ik heb 1 pctje voorzien van een Nvidia quadro T1000, zodat ik die kan door zetten naar een plex-lcx.
Echter ik krijg de nvidia drivers er maar niet op. hij faalt tekens bij kernel modules maken.
Nu is de pc met SecureBoot, maar ook de dingen die op proxmox en github had gevonden, werken niet.
Iemand een idee waarom dit niet gewoon werkt?
Hij wordt wel gezien op host als in lcx als ik de installatie doe. Maar omdat er geen driver is doet hij niet.
De intel chip word ook gezien, en die wordt dan ook standaard gebruikt, en die werkt dan wel gewoon en zichtbaar in plex.

En backups werken helaas niet met de LCX containers. heeft geen rechten Iemand een idee hoe ik dat kan fixen.
De VM's doet hij wel zonder problemen.

Wat ik doe is dit (in mijn geval een T600):
Requirements installeren op de host:

apt install -y dkms pve-headers wget

Driver installeren op de host (met --dkms flag)

./NVIDIA-Linux-x86_64-550.78.run --dkms

Devices in de lxc-configuratie toevoegen:

code:

dev0: /dev/nvidia0
dev1: /dev/nvidiactl
dev2: /dev/nvidia-uvm
dev3: /dev/nvidia-uvm-tools
dev4: /dev/nvidia-caps/nvidia-cap1
dev5: /dev/nvidia-caps/nvidia-cap2

Tot slot: dezelfde driver in lxc installeren maar met optie --no-kernel-module

Het enige wat ik dan nog weleens tegenkom is dat de devices op de host (onder /dev/) nog niet aangemaakt zijn voordat de containers waar ik 'm aan doorgeef (2 stuks) up zijn. Het lijkt wel alsof die nodes onder /dev/ pas later gemaakt worden. Wanneer ik een keer nvidia-smi draai op de host, dan verschijnen ze wel en kunnen de containers er gewoon bij.

[Renegade666]

Driver installeren op de host (met --dkms flag)
./NVIDIA-Linux-x86_64-550.78.run --dkms

Dit gaat dus fout, daar krijg ik die melding weg.

Dat eerste heb ik idd ook gedaan, die pre-req.

[The-Source]

@Cyphax moet je de kaart dan ook niet aan de blacklist toevoegen op je host zodat daar de driver niet wordt geladen (en dan zou in theorie driver installatie ook niet nodig zijn op je host)?
Weet even niet zo uit mijn hoofd waar dat blacklist deel zit maar heb dat voor mijn Jellyfin zo wel gedaan met graphics kaart aan de LXC knopen.

[Cyphax]

Renegade666 schreef op woensdag 12 augustus 2026 @ 10:37:
Driver installeren op de host (met --dkms flag)
./NVIDIA-Linux-x86_64-550.78.run --dkms

Dit gaat dus fout, daar krijg ik die melding weg.

Dat eerste heb ik idd ook gedaan, die pre-req.

Wat is dat dan voor melding die je krijgt?

The-Source schreef op woensdag 12 augustus 2026 @ 10:54:
@Cyphax moet je de kaart dan ook niet aan de blacklist toevoegen op je host zodat daar de driver niet wordt geladen (en dan zou in theorie driver installatie ook niet nodig zijn op je host)?
Weet even niet zo uit mijn hoofd waar dat blacklist deel zit maar heb dat voor mijn Jellyfin zo wel gedaan met graphics kaart aan de LXC knopen.

Hmmm dat is wel een goede vraag. Volgens mij heb ik niks geblacklist. Er zijn wat modules geblacklist, met name nouveau. Maar er is ook een pve-blacklist.conf waar nvidiafb in wordt geblokkeerd. Ik kan me niet herinneren daar met de hand iets voor gedaan te hebben.
(ik kijk in /etc/modprobe.d voor de geblackliste modules)

[ Voor 3% gewijzigd door Cyphax op 12-08-2026 11:00 ]

[Renegade666]

Ik heb deze oa gevolgd, dit was het meest moderne/laatst aangemaakt.
https://gist.github.com/n...564ece8be3990d774386b5d0c

eerste stappen gaan allemaal prima, maar bij het installeren dus mis.
Hij gaat door Building Kernel Modules tot 100%, en daarna poef
An error has occurred while perfomrming the step building kernel moduls.
met verwijzing naar log. waar ik ook niet echt uitkom wat ze daarin nu zeggen wat stuk is

Hier linkje naar log bestand.
https://e.pcloud.link/pub...802TmCMjKsFCeDKSQBuh2F9ek

Dus als iemand een idee heeft
En anders maar gewoon met de intel igpu doen
Want alleen die kaart er in doen gaat het verbruik al met 25 watt omhoog XD terwijl 4 pc's rond de 50 zaten, zit ik nu rond de 75. (de containers/vms hebben het niet erg druk, dus dat scheelt)

[ Voor 14% gewijzigd door Renegade666 op 12-08-2026 16:12 ]

[Cyphax]

@Renegade666
Ik zou het met een jongere versie van de driver proberen. Niet alle versies werken altijd zomaar, ik heb daar ook weleens gezeur mee gehad waarbij de oplossing een jongere driver is. Je hebt geprobeerd 580.95.05 te installeren. Ik heb zelf 580.159.03 draaien. Je hebt best wel kans dat die het bij jou ook doet.
https://www.nvidia.com/en-us/drivers/details/267258/

[servies]

The-Source schreef op woensdag 12 augustus 2026 @ 10:54:
@Cyphax moet je de kaart dan ook niet aan de blacklist toevoegen op je host zodat daar de driver niet wordt geladen (en dan zou in theorie driver installatie ook niet nodig zijn op je host)?

Vziw geldt dat voor een VM, die heeft dan als enige de beschikking over dat device.
Bij een container juist niet, daar moet de kaart geenabled zijn in de host, waarna je het desbetreffende device in de lxc configuratie toevoegd.

[Renegade666]

@Cyphax
KOmen weer een stapje verder.
Kreeg nu de melding dat cc miste tijds de installtie, deze is nu aanwezig.

toen weer een melding..

Toen maar even opnieuw begonnen van de handleiding, en toen kon ik wel verder
Dus de driver is geinstalleerd.

Nu net de plex container opnieuw gedaan, en dat ging ook zonder problemen en zag hem.
Maar nu komt het belangrijkste, plex, die ziet hem niet XD

Ga later wel weer even verder, wil nu even nog wat anders doen

Edit:
reboot container, en tadaaaa, een T1000 in plex :D:D

Danks voor de push naar de juiste richting (de nieuwere driver waar ik verder niet echt naar gekeken had XD)

[ Voor 23% gewijzigd door Renegade666 op 12-08-2026 16:53 ]

[Cyphax]

Renegade666 schreef op woensdag 12 augustus 2026 @ 16:50:
@Cyphax
KOmen weer een stapje verder.
Kreeg nu de melding dat cc miste tijds de installtie, deze is nu aanwezig.

toen weer een melding..

Toen maar even opnieuw begonnen van de handleiding, en toen kon ik wel verder
Dus de driver is geinstalleerd.

Nu net de plex container opnieuw gedaan, en dat ging ook zonder problemen en zag hem.
Maar nu komt het belangrijkste, plex, die ziet hem niet XD

Ga later wel weer even verder, wil nu even nog wat anders doen

Edit:
reboot container, en tadaaaa, een T1000 in plex :D:D

Danks voor de push naar de juiste richting (de nieuwere driver waar ik verder niet echt naar gekeken had XD)

Top!
Laatste tip nog: maak een aantekening in Proxmox (note bij de container of op host-niveau) met de stappen die je nu hebt gevolgd. Je gaat die vaker uit moeten voeren (kernel-updates hoofdzakelijk). Het kan altijd zijn dat de driver die je dan probeert te installeert niet meer werkt maar de nieuwste driver wel.
Het kan ook zijn dat je de driver een keer moet uninstallen. Dat kan je ook met de installer doen. Gooi die .run-file dus niet weg. Ik laat 'm zelf altijd in /root staan ergens op de host.

[powerboat]

Volgens mij hoef je niet de blacklisten in een lxc maar doe je meer aan gpu sharing.

[The-Source]

Niet direct proxmox gerelateerd (ook al staat de test wel op de boot usb van PVE )
Maar memtest86+ icm met dual cpu en dan 16x dimms vol duurt best lang voordat deze door init fase heen is en werkelijk gaat testen.
Best lang is bijna 10 minuten en * The-Source is dan natuurlijk ongeduldig en al op zoek naar info waarom
maar Gemini kon mij wel goed uitleggen dat het door reserveren van parallel channels & threads is en tja dat is iets meer dan consumenten hardware situatie waar mij ervaringen vanuit het verleden op gebasseerd waren.
Maar alles is met PASS afgerond in ongeveer 10 uur.

Nu alleen wachten op mijn behuizing die wat vertraagd is