Het grote Proxmox VE topic

[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

[WheeleE]

Met behulp van alle adviezen en feedback naar aanleiding van mijn IO Pressure Stall uitdaging heb ik nu de boel omgezet.

Een Docker VM met daarin een NFS mount direct naar m'n NAS. QBittorrent zoemt nu als een zonnetje op volle snelheid zonder een centje pijn.

Dank allemaal!

[iGadget]

Vandaag wil ik de upgrade van PVE 8 -> 9 gaan doen op mijn laatste servertje. De eerste 2 van mijn servertjes gingen probleemloos, maar mijn derde draait naast PVE ook nog PBS. Uiteraard ga ik alle officiële guides volgen, maar wellicht hebben jullie nog lat-minute tips / best practices waar ik rekening mee moet houden?

Update - PVE & PBS zijn met behulp van alle guides succesvol geupgrade

[ Voor 10% gewijzigd door iGadget op 19-08-2026 17:18 ]

[powerboat]

iGadget schreef op woensdag 19 augustus 2026 @ 13:13:
Vandaag wil ik de upgrade van PVE 8 -> 9 gaan doen op mijn laatste servertje. De eerste 2 van mijn servertjes gingen probleemloos, maar mijn derde draait naast PVE ook nog PBS. Uiteraard ga ik alle officiële guides volgen, maar wellicht hebben jullie nog lat-minute tips / best practices waar ik rekening mee moet houden?

Je servers migreren naar je andere hosts en dan gewoon lekker upgraden. (Ik neem aan dat je ze in een cluster hebt).

[InjecTioN]

powerboat schreef op woensdag 19 augustus 2026 @ 14:06:
[...]

Je servers migreren naar je andere hosts en dan gewoon lekker upgraden. (Ik neem aan dat je ze in een cluster hebt).

Ik heb PBS als LXC draaien, waarmee ik in theorie zelfs een PBS server kan restoren. (storage voor PBS staat natuurlijk elders.)

[dcm360]

Met Proxmox Datacenter Manager kan je tegenwoordig ook guests migreren naar andere clusters (al dan niet met een enkele host per cluster). Mijn 2 hosts thuis zijn bewust niet ingesteld als cluster (ik heb ze graag compleet onafhankelijk van elkaar), maar met PDM kan ik tijdens upgrades wel de guests migreren.

[iGadget]

powerboat schreef op woensdag 19 augustus 2026 @ 14:06:
[...]

Je servers migreren naar je andere hosts en dan gewoon lekker upgraden. (Ik neem aan dat je ze in een cluster hebt).

Ja de eerste 2 servers wel, maar die laatste niet (want geen 10gbit nic en geen losse nic voor corosync). Draai er wel die package op om het quorum op meer dan 1 te houden als 1 van de andere servers uit valt, maar PVE zelf zit op deze bak verder niet in het cluster.

De enige VM dier er op draait die ik echt niet kwijt wil raken is HAOS welke via passthrough USB aan de P1 meter hangt. Deze VM kan ik hierdoor niet makkelijk migreren (de andere 2 servers staan fysiek te ver van de P1 meter).

Op termijn wil ik dit oplossen met een P1 dongle die via het netwerk uit te lezen is, maar dat moet nog.
Kan deze VM wel via de gedeelde PBS datastore restoren naar het cluster, maar dat heb ik nooit getest. Zal dit iig nog doen zodat ik tenminste een (extra) kopie heb.

[iGadget]

dcm360 schreef op woensdag 19 augustus 2026 @ 14:22:
Met Proxmox Datacenter Manager kan je tegenwoordig ook guests migreren naar andere clusters (al dan niet met een enkele host per cluster). Mijn 2 hosts thuis zijn bewust niet ingesteld als cluster (ik heb ze graag compleet onafhankelijk van elkaar), maar met PDM kan ik tijdens upgrades wel de guests migreren.

Hee maar dat is interessant... Zou voor mij eigenlijk ook een veel betere oplossing zijn - scheelt gedoe met quorum en corosync is dan niet langer nodig. HA gebruik ik in de praktijk nauwelijks (en met LXC kan het toch al niet seamless). Dank voor de tip!

[Jerie]

iGadget schreef op woensdag 19 augustus 2026 @ 14:28:
[...]

Ja de eerste 2 servers wel, maar die laatste niet (want geen 10gbit nic en geen losse nic voor corosync). Draai er wel die package op om het quorum op meer dan 1 te houden als 1 van de andere servers uit valt, maar PVE zelf zit op deze bak verder niet in het cluster.

De enige VM dier er op draait die ik echt niet kwijt wil raken is HAOS welke via passthrough USB aan de P1 meter hangt. Deze VM kan ik hierdoor niet makkelijk migreren (de andere 2 servers staan fysiek te ver van de P1 meter).

Op termijn wil ik dit oplossen met een P1 dongle die via het netwerk uit te lezen is, maar dat moet nog.
Kan deze VM wel via de gedeelde PBS datastore restoren naar het cluster, maar dat heb ik nooit getest. Zal dit iig nog doen zodat ik tenminste een (extra) kopie heb.

Je kunt ook de USB aan een RPi Zero hangen en met USBIP de USB exporteren. Een single point of failure is het altijd.

[iGadget]

Jerie schreef op woensdag 19 augustus 2026 @ 16:27:
[...]


Je kunt ook de USB aan een RPi Zero hangen en met USBIP de USB exporteren. Een single point of failure is het altijd.

Die heeft alleen WiFi toch? Dit soort belangrijke zaken hou ik liever volledig bedraad, net wat stabieler.

[Jerie]

iGadget schreef op woensdag 19 augustus 2026 @ 16:37:
[...]

Die heeft alleen WiFi toch? Dit soort belangrijke zaken hou ik liever volledig bedraad, net wat stabieler.

Dat klopt. Ik overigens ook liefst zo min mogelijk wireless.

Ik gebruik PoE module met mijn RPi Zero. Er zijn ook modules die non-PoE ethernet leveren (kan ook met de PoE module).

Wat je ook nog kunt doen i.p.v USBIP is Prometheus op de RPi exporteren. Dat is waarschijnlijk zelfs stabieler, omdat die intern ook nog caching heeft (dat kan zelfs in RAM i.p.v. flash). Ook kun je er een batterij aanhangen. Daar gebruik ik UPS-Lite voor.

Ik heb persoonlijk diverse USB-A aan mijn all-in-one server hangen. Een P1, Bluetooth, SDR, fan, ... ook diverse USB-C / TB.

Ja, het is een SPOF, het zij zo. De downtime na een reboot (en die is er soms dankzij nieuwe Linux kernels) is er, maar is toch vrij laag. De grootste moeite is de FDE unlocken op de NAS VM.

[iGadget]

Jerie schreef op woensdag 19 augustus 2026 @ 17:06:
Ik gebruik PoE module met mijn RPi Zero. Er zijn ook modules die non-PoE ethernet leveren (kan ook met de PoE module).

Mja PoE heb ik niet in mijn meterkast, dus dan zou een non-PoE module mss beter zijn.

Wat je ook nog kunt doen i.p.v USBIP is Prometheus op de RPi exporteren. Dat is waarschijnlijk zelfs stabieler, omdat die intern ook nog caching heeft (dat kan zelfs in RAM i.p.v. flash). Ook kun je er een batterij aanhangen. Daar gebruik ik UPS-Lite voor.

Heb echt nul ervaring met Prometheus, maar dat kun je dan weer (makkelijk) aan HomeAssistant knopen ter vervanging van DSMR?

Ik heb persoonlijk diverse USB-A aan mijn all-in-one server hangen. Een P1, Bluetooth, SDR, fan, ... ook diverse USB-C / TB.

Ah ja, bijna vergeten - aan diezelfde machine hangt ook een USB-A Zigbee dongle (passthrough naar HomeAssistant). Dus zelfs als fix ik de P1 dan ben ik er nog steeds niet. Ik denk dat ik het voorlopig maar zo laat.

[powerboat]

InjecTioN schreef op woensdag 19 augustus 2026 @ 14:22:
[...]

Ik heb PBS als LXC draaien, waarmee ik in theorie zelfs een PBS server kan restoren. (storage voor PBS staat natuurlijk elders.)

Dat heb ik ook enige tijd gehad, uiteindelijk heb ik deze nu in een container zitten op TrueNAS wat een aparte dedicated backup-server is.

YouTube: How to Run Proxmox Backup Server on TrueNAS

[stormfly]

dcm360 schreef op woensdag 19 augustus 2026 @ 14:22:
Met Proxmox Datacenter Manager kan je tegenwoordig ook guests migreren naar andere clusters (al dan niet met een enkele host per cluster). Mijn 2 hosts thuis zijn bewust niet ingesteld als cluster (ik heb ze graag compleet onafhankelijk van elkaar), maar met PDM kan ik tijdens upgrades wel de guests migreren.

Dat is hele fijne informatie, dank voor het delen. Ik heb nu een 2 node cluster met witness op een Pi 5. Totaal overbodig want de 2e node gaat alleen aan als ik de 1e node voor onderhoud reboot en dan verplaats ik 1 VM. Ik zou er wel meer willen verplaatsen maar deze hebben USB mounts wat het complex maakt.

As we speak aan het installeren van PDM ;-)

[InjecTioN]

Even ter informatie:

Proxmox VE 9
First Release: 2025-08, Debian Version 13 (Trixie), Debian EOL: TBA, Proxmox VE EOL: TBA

Proxmox VE 8
First Release: 2023-06, Debian Version 12 (Bookworm), Debian EOL: 2026-07, Proxmox VE EOL: 2026-08

_{Bron: https://forum.proxmox.com...-support-lifecycle.35755/}

Dit betekent dat er vanaf morgen dus geen security updates meer komen voor Proxmox 8.x. (Debian 12 was vorige maand reeds EoL.)

Upgraden is aangeraden wanneer mogelijk. PVE 9.2 is inmiddels ook al netjes volwassen geworden met Debian 13 (Trixie).

[GHB363]

Ik zag laatst inderdaad een alert hierover op mijn pbs, de pve nodes had ik een tijdje terug al naar trixie gehaald, maar de backup server was ik een beetje vergeten.

[ElCondor]

GHB363 schreef op maandag 31 augustus 2026 @ 21:49:
Ik zag laatst inderdaad een alert hierover op mijn pbs, de pve nodes had ik een tijdje terug al naar trixie gehaald, maar de backup server was ik een beetje vergeten.

that reminds me...

[ThinkPad]

Ik heb unattended-upgrades aan staan op PBS (op PVE vind ik dat te tricky), maar die doet geen versie updates Thuis ook maar even kijken welke versie ik heb, volgens mij tijd terug al geupdate.

[ Voor 3% gewijzigd door ThinkPad op 01-09-2026 08:47 ]

[Jerie]

ThinkPad schreef op dinsdag 1 september 2026 @ 08:46:
Ik heb unattended-upgrades aan staan op PBS (op PVE vind ik dat te tricky), maar die doet geen versie updates Thuis ook maar even kijken welke versie ik heb, volgens mij tijd terug al geupdate.

unattended-upgrades kan wel degelijk ingesteld worden om versies te upgraden, maar dat is zeer onverstandig gezien unattended.

[mkleinman]

Ik heb afgelopen week mijn 3 node cluster bijgewerkt naar Proxmox 9, Ceph had ik al naar 19.2.3 in een eerdere fase bijgewerkt.. Eerste node was eng.. nadat de dist-upgrade en reboot netjes was gegaan was mijn hele cluster binnen het uur bijgewerkt van 8 naar 9.

[_JGC_]

mkleinman schreef op woensdag 2 september 2026 @ 12:15:
Ik heb afgelopen week mijn 3 node cluster bijgewerkt naar Proxmox 9, Ceph had ik al naar 19.2.3 in een eerdere fase bijgewerkt.. Eerste node was eng.. nadat de dist-upgrade en reboot netjes was gegaan was mijn hele cluster binnen het uur bijgewerkt van 8 naar 9.

Nou nog van Squid naar Tentacle
19.2.3 is EOL over enkele weken.

En ja, ik vond dat upgraden ook best eng, maar eigenlijk stelt het niks voor, ook de Ceph upgrades niet. Meeste horrorverhalen hoor je over Erasure Coded pools, maar dat is sowieso Russische roulette op dit moment.

Enige waar ik tegenaanliep bij 8->9 was de mesh setup met FRR waar je een regeltje weg moest halen uit de netwerkconfig. Dat resulteerde in de eerste node die bleef hangen bij het initialiseren van netwerk, maar was snel verholpen.