Het grote Proxmox VE topic

[Airw0lf]

Quad schreef op zondag 28 december 2025 @ 16:02:
@witchdoc Als je Proxmox Backup server gebruikt, zet de backups dan op een SSD. PBS gaat niet lekker met opslag op HDD.

Die volg ik niet - wat gaat er dan niet lekker?

[zeroday]

Quad schreef op zondag 28 december 2025 @ 16:02:
@witchdoc Als je Proxmox Backup server gebruikt, zet de backups dan op een SSD. PBS gaat niet lekker met opslag op HDD.

Nou .. hier althans wel .. lekker op een NUC
werkt als een tierelier.
Wat niet lekker werkte bij mij was NFS .. met SMB geen enkel issue
Probleem met NFS was het feit dat er bij het instellen tig folders aangemaakt word door PBS en dat vond indertijd bij de hele vroege eerste versie van PBS mijn hardware niet leuk.

ik heb PBS op een NUC draaien en daar zit een HDD in die de data binnen krijgt.
Daarnaast heb ik nog en sync remote erop gezet die de data naar de NAS dupliceert. dus mocht PBS eruit vliegen dan heb ik de data nog op de NAS ..

[Quad]

Mm dat zou misschien kunnen, ik gebruik standaard NFS en met PBS ging dat naar een HDD over z'n nek. Bij het aanmaken en back-uppen.

Met NFS naar een SATA SSD geen enkel issue. Ik heb wel een HDD extern aangesloten met USB, deze gebruik ik als sync, gaat wel prima.

[orvintax]

Quad schreef op maandag 29 december 2025 @ 14:18:
Mm dat zou misschien kunnen, ik gebruik standaard NFS en met PBS ging dat naar een HDD over z'n nek. Bij het aanmaken en back-uppen.

Met NFS naar een SATA SSD geen enkel issue. Ik heb wel een HDD extern aangesloten met USB, deze gebruik ik als sync, gaat wel prima.

Ik gebruik zelf PBS met een HDD NFS share, werkt prima. Wat bedoel je over z'n nek? Dat het echt mis ging of dat de performance belabberd was?

[ninjazx9r98]

Ik gebruik een PBS LXC container en die werkt prima samen met een NFS share op een NAS die OMV draait.
De share staat op een MDADM RAID 5 die bestaat uit zes HDD's.

[zeroday]

orvintax schreef op maandag 29 december 2025 @ 18:57:
[...]

Ik gebruik zelf PBS met een HDD NFS share, werkt prima. Wat bedoel je over z'n nek? Dat het echt mis ging of dat de performance belabberd was?

Ik spreek even voor mezelf en de ervaring bij versie 1.0 van PBS, want daarna had ik wel een goede werkende omgeving:
vooral het failen van de backups maken. Dat gebeurde om de haverklap. Onduidelijke redenen.
wellicht te maken de de UID's en GROUPID's etc.. daar bleek PBS picky ..

Uiteindelijk alles opnieuw opgebouwd, beter gelezen, beter de ervaringen opgezocht en 'juiste' instellingen ingevoerd. Nu draait het voor 99% goed. Heel af en toe failed er om welke reden dan ook een backup ..

[Rolfie]

zeroday schreef op dinsdag 30 december 2025 @ 09:01:
[...]

Ik spreek even voor mezelf en de ervaring bij versie 1.0 van PBS, want daarna had ik wel een goede werkende omgeving:
vooral het failen van de backups maken. Dat gebeurde om de haverklap. Onduidelijke redenen.
wellicht te maken de de UID's en GROUPID's etc.. daar bleek PBS picky ..

Uiteindelijk alles opnieuw opgebouwd, beter gelezen, beter de ervaringen opgezocht en 'juiste' instellingen ingevoerd. Nu draait het voor 99% goed. Heel af en toe failed er om welke reden dan ook een backup ..

Ik ben juist hierom eerst van NFS, daarna naar SMB overgestapt. En uiteindelijk gewoon ISCSI gebruikt op mjn Synology NASsen. ISCSI werkte eigenlijk direct en perfect zonder enige problemen.

[InjecTioN]

Rolfie schreef op zondag 28 december 2025 @ 17:11:
Ik heb juist PBS als VM draaien op mijn Synology NAS, waar ik een 16T harddisk in heb zitten voor mijn normale opslag. In die VM heb ik 1T ISCSI lun, van mijn Synology gemaakt, waarop ik de backups bewaar.

Niet het snelste, maar werkt wel goed.

Dit dus. Ik heb een OpenMediaVault zelfbouw NAS met 2x Seagate Exos 8TB in RAID1. Die wordt met NFS gemount aan de proxmox-backup-server LXC die op mijn proxmox cluster van 3 nodes draait.

De backup wordt dus weggeschreven naar mijn NAS met spinning rust. En performance is echt meer dan prima. Er wordt gewoon een snapshot gemaakt, wat ook echt niet de grootste hoeveelheid data hoeft te zijn. Daarbij hoeft het m.i. ook echt niet snel te gaan.

[Gunner]

Ik draai sinds kort Pulse monitoring, grappige tool. Maar nu ik na de update wil inloggen via pct enter krijg ik de melding

root@pve:~# pct enter 104
user config - ignore invalid privilege 'VM.Monitor'

Blijkbaar zit dit niet meer in PVE 9. Via het proxmox forum kom ik bij iets soortgelijks, waar een van de ontwikkelaars zegt;

well the parser drops it (see the warning), but it is still there in the config unless you modify it..

Dit zegt me allemaal niet zoveel. Kan ik dit gewoon negeren?

[ Voor 3% gewijzigd door Gunner op 30-12-2025 16:11 ]

[Vorkie]

Gunner schreef op dinsdag 30 december 2025 @ 16:11:
Ik draai sinds kort Pulse monitoring, grappige tool. Maar nu ik na de update wil inloggen via pct enter krijg ik de melding


[...]


Blijkbaar zit dit niet meer in PVE 9. Via het proxmox forum kom ik bij iets soortgelijks, waar een van de ontwikkelaars zegt;


[...]


Dit zegt me allemaal niet zoveel. Kan ik dit gewoon negeren?

Ben zelf net gemigreerd naar Proxmox vanuit VMWare, uit mijn open chat van Gemini - maak altijd cp van je config.

Hoe los je het op (zodat de melding stopt)?
Als je van die irritante melding af wilt, kun je de config even "verversen":
Handmatig via de CLI:
Open de config van de container: nano /etc/pve/lxc/104.conf.
Zoek naar de regel waar VM.Monitor in staat en verwijder dat woord (of de hele regel als het een overbodige permissie is).
Via de GUI:
Ga naar de container 104 -> Permissions. Als je daar iets ziet wat rood is of niet klopt, verwijder het en voeg het opnieuw toe met de huidige standaarden.
Kortom: Je Pulse monitoring loopt geen gevaar, het is puur een cosmetische waarschuwing van de Proxmox parser.

[Gunner]

@Vorkie Dank voor je uitzoekwerk. Zowel in de conf via de CLI als in de Permissions in de GUI staat geen verwijzing naar VM.Monitor maar als jouw AI resultaat aangeeft dat het puur cosmetisch is is dat verder prima. Het is maar een simpele pulse monitoring LXC die verder gewoon goed lijkt te draaien.

Vanuit een andere tool lijkt het alsof de ontwikkelaar dit moet doen, zie ik dat goed?

[zeroday]

Gunner schreef op dinsdag 30 december 2025 @ 16:11:
Ik draai sinds kort Pulse monitoring, grappige tool. Maar nu ik na de update wil inloggen via pct enter krijg ik de melding


[...]


Blijkbaar zit dit niet meer in PVE 9. Via het proxmox forum kom ik bij iets soortgelijks, waar een van de ontwikkelaars zegt;

Heb je al in github gekeken?
https://github.com/rcourtman/Pulse/issues/348

Daar wordt oa. over dit issue gesproken. Wellicht draai je met een ouder(e) versie?
[...]


Dit zegt me allemaal niet zoveel. Kan ik dit gewoon negeren?

[ Voor 1% gewijzigd door zeroday op 30-12-2025 17:08 . Reden: quote quote verkeerd gezet ]

[Gunner]

zeroday schreef op dinsdag 30 december 2025 @ 17:08:
[...]

Daar wordt oa. over dit issue gesproken. Wellicht draai je met een ouder(e) versie?

Nope, eerder deze week update gedaan naar 5.x en vanmiddag weer een nieuwe update naar 5.0.6
Wel had ik hem pas recent voor het eerst gestart na mijn PVE-update maar een reboot blijft dezelfde melding geven.

Verder zien mijn monitoring-stats er prima uit.

edit: ik zie dat het eigenlijk niets met Pulse te maken heeft. Als ik een QM list doe op PVE krijg ik hem ook

[ Voor 17% gewijzigd door Gunner op 30-12-2025 17:14 ]

[Gunner]

edit: dit is iets anders

[ Voor 89% gewijzigd door Gunner op 30-12-2025 17:17 ]

[Koepert]

Ok, toch ff delen hier.

Ik gebruik Proxmox voor mijn homelab. 1 Host met een Home Assistant VM en 1 Host met wat LXC containers (Adguard, NPM, Uptime Kuma, dat soort spul) maar die had ik in een cluster met een 3e host. Die is echter afgestorven (oude laptop) dus had ik een cluster zonder quorum. Ergens niet zo spannend, het zijn 2 minipc's die geen HA oid hoeven, ging me om 1 interface voor t geheel. Dat ik dan n CT naar die HOST 1 kan moven, ok. Maar daardoor had ik dus geen quorum en dat had de migratie naar een nieuwe PVE_versie enorm groot gemaakt. Ik ben al slecht in rebooten van de hosts, updaten schoot er ook bij in, maar vooral upgraden vanaf 7.4.x bleef er bij. Tot ik vandaag las over het inzetten van een extra device als "qdevice" voor quorum. Ik heb NOG een oude laptop liggen dus daar op gezet en aan de praat.

Daarmee eindelijk succesvol 2 hosts naar 9.1.4 geupgrade Wat kun je iets dan moeilijk maken..

Overigens kwam ik er daarna achter dat ik per ongeluk een niet meer actief zijnde Back-up locatie als plek had gebruikt voor een CT disk.. Dus mijn Uptime Kuma CT wilde niet meer booten. Omdat dit de 2e was die ik startte begon ik ff te zweten.. de scripts gaven elke keer groen op de update-checks, had ik toch wat gemist?

Maar dat bleek dus skill-issue.. Alleen nu ik Pulse zag.. Misschien toch die maar eens bekijken, hoewel Uptime Kuma voldoende doet.

[GoBieN-Be]

Om via 1 management interface te beheren en te kunnen moven kan je nu ook proxmox datacenter manager gebruiken. Heb je geen cluster voor nodig, kan ook perfect met 2 hosts. Ik draai het in een LXC op één van mijn hosts en start het eigenlijk pas op als ik het nodig heb.

[ Voor 11% gewijzigd door GoBieN-Be op 06-01-2026 20:50 ]

[Anoniemand]

GoBieN-Be schreef op dinsdag 6 januari 2026 @ 20:50:
Om via 1 management interface te beheren en te kunnen moven kan je nu ook proxmox datacenter manager gebruiken. Heb je geen cluster voor nodig, kan ook perfect met 2 hosts. Ik draai het in een LXC op één van mijn hosts en start het eigenlijk pas op als ik het nodig heb.

Bedankt voor het delen, klinkt interessant genoeg om binnenkort te installeren en te bekijken.

[Emootje]

Goedemiddag, omdat ik even niet scherp heb op welke zoektermen ik moet zoeken wil ik hierbij mijn vraag voorleggen. Hoop dat dit zo oké is:
Ik heb sinds een paar dagen de nieuwste versie van Proxmox VE draaien en daarop heb ik HA geïnstalleerd. Dat ging allemaal prima en werkt ook fijn. Echter: ik moet elke dag mijn nuc opnieuw opstarten omdat ik de server niet kan bereiken op het interne ip-adres. Zowel Proxmox als HA niet. Is er iets wat ik niet goed doe?

[Harmen]

Emootje schreef op woensdag 7 januari 2026 @ 12:56:
Goedemiddag, omdat ik even niet scherp heb op welke zoektermen ik moet zoeken wil ik hierbij mijn vraag voorleggen. Hoop dat dit zo oké is:
Ik heb sinds een paar dagen de nieuwste versie van Proxmox VE draaien en daarop heb ik HA geïnstalleerd. Dat ging allemaal prima en werkt ook fijn. Echter: ik moet elke dag mijn nuc opnieuw opstarten omdat ik de server niet kan bereiken op het interne ip-adres. Zowel Proxmox als HA niet. Is er iets wat ik niet goed doe?

Vermoedelijk een driver issue, heb hetzelfde meegemaakt. Zie volgende link:
scorpion303 in "Het grote Proxmox VE topic"

[Niekniek89]

Ik vermoed dat ik ook dat issue heb, aangezien ik een I219 netwerk NIC heb.

Nooit last van gehad, pas sinds de laatste Proxmox release (V9), daarvoor nooit gehad.
Volgens Google maakt deze ook gebruik van de e1000e drivers.
Afgelopen week was heel de host + VM"s opeens niet meer bereikbaar.
Na het loskoppelen van de LAN kabel, en weer aansluiten kwam het verkeer weer op gang.
Er is een script gemaakt, welke ik nog moet checken:

https://community-scripts...pts?id=nic-offloading-fix

Die zou ook het issue moeten fixen.

[ Voor 8% gewijzigd door Niekniek89 op 07-01-2026 13:48 ]

[Quad]

@Niekniek89 Je hebt geen script nodig; zie ThinkPad in "Het grote Proxmox VE topic" van @ThinkPad .
Werkt prima.

[Niekniek89]

Quad schreef op woensdag 7 januari 2026 @ 14:27:
@Niekniek89 Je hebt geen script nodig; zie ThinkPad in "Het grote Proxmox VE topic" van @ThinkPad .
Werkt prima.

Dan is er bij mij wellicht iets anders aan de hand, blijkbaar staat alles al op "off".....

root@Proxmox01:~# ethtool -k eno1 | grep -E 'tso|gso|gro'
tx-gso-robust: off [fixed]
tx-gso-partial: off [fixed]
tx-gso-list: off [fixed]
rx-gro-hw: off [fixed]
rx-gro-list: off
rx-udp-gro-forwarding: off
root@Proxmox01:~#

maar in de logging vindt ik toch:

Dec 31 19:54:26 Proxmox01 kernel: e1000e 0000:00:1f.6 eno1: Detected Hardware Unit Hang:

daarnaast hangt hij bij mij wel in een mgmt vlan:

iface vmbr0 inet manual
bridge-ports eno1
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094

iface wlp0s20f3 inet manual

auto vmbr0.3
iface vmbr0.3 inet static
address 192.168.176.10/24
gateway 192.168.176.1

[ Voor 28% gewijzigd door Niekniek89 op 07-01-2026 14:49 ]

[Emootje]

Harmen schreef op woensdag 7 januari 2026 @ 13:10:
[...]


Vermoedelijk een driver issue, heb hetzelfde meegemaakt. Zie volgende link:
scorpion303 in "Het grote Proxmox VE topic"

Ik zal er vanavond eens naar kijken. Hij heeft het elke dag, ik zie wel dat hij updates binnenhaalt en daarna is het klaar denk ik.
Dank voor je snelle reactie.

[mbouwmee]

Hoi ik had hier ook last van het schijnt iets te zijn met intel interfaces:
Nadat ik het onderstaande heb toegepast heb ik er geen last meer van.

########################################################
nano /etc/systemd/system/fix-e1000e.service

[Unit]
Description=Disable offloading on Intel e1000e NIC
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool -K enp0s25 tso off gso off gro off

[Install]
WantedBy=multi-user.target

######################################################
Daarrna
systemctl daemon-reload
systemctl enable fix-e1000e
systemctl start fix-e1000e

Ik hoop dat het bij jullie ook lukt ;-)

[RobbyTown]

Ergens sept/okt schoon Proxmox VE 9.0 geinstalleerd. Regelmatig updates gedaan.
Inmiddels draai ik op 9.1.4.

Via browser interface update / upgrade ik proxmox. Bij een kernel update/upgrade. Sluit ik de vm's af en reboot de machine. Echt nu blijft die hangen op Loading initial ramdisk


Na heel lang wachten. KERNEL PANIC

Advanced en dan (Recovery mode) kiezen werkt niet.

Nogmaals Advanced vorige versie gepakt (Linux 6.17.2-2-pve) dan start proxmox weer op.

Via BIOS systeem uitgebreid getest. Geen fouten


Via de "E" toets kun je opstart file aanpassen. Ik kom veel dingen tegen over ventoy dingen mogelijk de boosdoener zijn *klik*. Echter is mijn proxmox zonder ventoy geïnstalleerd dus kan het niet zijn. Maar wat dan wel is niet te vinden. Iemand ervaring met dit probleem?

Hierbij de parameters. Staat er wat vreemds in dat de boel ineens niet meer goed boot? Kies je Linux 6.17.2-2-pve dan start het allemaal goed op.

[ Voor 3% gewijzigd door RobbyTown op 07-01-2026 16:59 ]

[dcm360]

Is de laatste update wel goed gegaan, als in, is het wegschrijven van de initrd gelukt? Ik heb zelf (helaas) last van een te kleine /boot partitie, waardoor ik bij kernel-updates altijd goed moet opletten of de kernel en initrd goed weggeschreven zijn (en zo nee, moet ik wat ruimte maken door oude kernels weg te gooien en het opnieuw proberen). Dat hoeft natuurlijk niet exact ook jouw probleem te zijn, maar controleren of alles correct is weggeschreven is denk ik wel handig.

[Quad]

@RobbyTown Geen shares fstab staan die Proxmox probeert te mounten bij het booten?

[RobbyTown]

Ben geen expert in linux (met google werk kom ik aan de juiste commando's)

@dcm360 boot zou meer dan ruimte genoeg zijn. Slechts 6% gebruikt, toch?


@Quad fstab niets mee gedaan naar mijn weten. nano /etc/fstab gedaan en geeft deze output

code:

# <file system> <mount point> <type> <options> <dump> <pass>
/dev/pve/root / ext4 errors=remount-ro 0 1
UUID=4D14-B93D /boot/efi vfat defaults 0 1
/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0

[ Voor 8% gewijzigd door RobbyTown op 07-01-2026 17:31 ]

[Mich]

RobbyTown schreef op woensdag 7 januari 2026 @ 17:26:
Ben geen expert in linux (met google werk kom ik aan de juiste commando's)

@dcm360 boot zou meer dan ruimte genoeg zijn. Slechts 6% gebruikt, toch?
[Afbeelding]

@Quad fstab niets mee gedaan naar mijn weten. nano /etc/fstab gedaan en geeft deze output

code:

# <file system> <mount point> <type> <options> <dump> <pass>
/dev/pve/root / ext4 errors=remount-ro 0 1
UUID=4D14-B93D /boot/efi vfat defaults 0 1
/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0

Ik ben ook totaal geen expert maar als je op de command line kan uitkomen zou je met journalctl toch je laatste log files kunnen uitlezen en zien waar het op vast loopt?

[chielmi]

RobbyTown schreef op woensdag 7 januari 2026 @ 16:49:
Ergens sept/okt schoon Proxmox VE 9.0 geinstalleerd. Regelmatig updates gedaan.
Inmiddels draai ik op 9.1.4.

Via browser interface update / upgrade ik proxmox. Bij een kernel update/upgrade. Sluit ik de vm's af en reboot de machine. Echt nu blijft die hangen op Loading initial ramdisk
[Afbeelding]

Na heel lang wachten. KERNEL PANIC

Advanced en dan (Recovery mode) kiezen werkt niet.

Nogmaals Advanced vorige versie gepakt (Linux 6.17.2-2-pve) dan start proxmox weer op.

Via BIOS systeem uitgebreid getest. Geen fouten
[Afbeelding]

Via de "E" toets kun je opstart file aanpassen. Ik kom veel dingen tegen over ventoy dingen mogelijk de boosdoener zijn *klik*. Echter is mijn proxmox zonder ventoy geïnstalleerd dus kan het niet zijn. Maar wat dan wel is niet te vinden. Iemand ervaring met dit probleem?

Hierbij de parameters. Staat er wat vreemds in dat de boel ineens niet meer goed boot? Kies je Linux 6.17.2-2-pve dan start het allemaal goed op.
[Afbeelding]

Je bent niet de enige https://forum.proxmox.com...9-1-4.178729/#post-829150
In mijn geval was het pinnen van de vorige kernel ook de oplossing.

[Niekniek89]

chielmi schreef op woensdag 7 januari 2026 @ 19:21:
[...]

Je bent niet de enige https://forum.proxmox.com...9-1-4.178729/#post-829150
In mijn geval was het pinnen van de vorige kernel ook de oplossing.

Hoe doe je dat? Het pi. En van de vorige kernel?
Of komt proxmox nog met een oplossing?
9.1.4 staat bij mij al enkele weken klaar, maar een hogere versie lijkt nog niet te komen?

[Gunner]

Niekniek89 schreef op woensdag 7 januari 2026 @ 19:36:
[...]


Hoe doe je dat? Het pi. En van de vorige kernel?
Of komt proxmox nog met een oplossing?
9.1.4 staat bij mij al enkele weken klaar, maar een hogere versie lijkt nog niet te komen?

De commando’s staan in die laatste post.

[Emootje]

mbouwmee schreef op woensdag 7 januari 2026 @ 16:45:
Hoi ik had hier ook last van het schijnt iets te zijn met intel interfaces:
Nadat ik het onderstaande heb toegepast heb ik er geen last meer van.

########################################################
nano /etc/systemd/system/fix-e1000e.service

[Unit]
Description=Disable offloading on Intel e1000e NIC
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool -K enp0s25 tso off gso off gro off

[Install]
WantedBy=multi-user.target

######################################################
Daarrna
systemctl daemon-reload
systemctl enable fix-e1000e
systemctl start fix-e1000e

Ik hoop dat het bij jullie ook lukt ;-)

Dit zal mijn oplossing zijn, het is opgelost wanneer ik mijn netwerkkabel eruit haal en er weer in doe. Maar dat kan dus ook geautomatiseerd worden.
Als ik bovenstaande doe dan krijg ik een error: etc/systemd/system does not exist. Ik werk in root@pve.

[GoBieN-Be]

Het script doet het mooi voor jou:
https://community-scripts...pts?id=nic-offloading-fix
Hier kan je de inhoud bekijken:
https://raw.githubusercon...pve/nic-offloading-fix.sh

[Emootje]

GoBieN-Be schreef op woensdag 7 januari 2026 @ 21:02:
Het script doet het mooi voor jou:
https://community-scripts...pts?id=nic-offloading-fix
Hier kan je de inhoud bekijken:
https://raw.githubusercon...pve/nic-offloading-fix.sh

Dit werkt! Morgen even testen of ik er in kan blijven. Dank!!!

[Liegebeest]

Quad schreef op woensdag 7 januari 2026 @ 17:08:
@RobbyTown Geen shares fstab staan die Proxmox probeert te mounten bij het booten?

Dat zou geen kernel panic moeten geven, op zijn hoogst hangen tijdens het booten omdat de share onbereikbaar is.

[Liegebeest]

Mich schreef op woensdag 7 januari 2026 @ 18:04:
[...]


Ik ben ook totaal geen expert maar als je op de command line kan uitkomen zou je met journalctl toch je laatste log files kunnen uitlezen en zien waar het op vast loopt?

Of als het specifiek om de boot / kernel logs gaat: `dmesg`

[Liegebeest]

mbouwmee schreef op woensdag 7 januari 2026 @ 16:45:
Hoi ik had hier ook last van het schijnt iets te zijn met intel interfaces:
Nadat ik het onderstaande heb toegepast heb ik er geen last meer van.

Oplossen met een systemd service vind ik een grappige Maar het is eigenlijk wat netter om het via de netwerkkaart configuratie te doen, zoals hier -> https://www.reddit.com/r/...1000e_hardware_unit_hang/

Ik heb daar idd ook wat offloading uit moeten zetten, omdat een zware belasting van m'n e1000 (tijdens backups en transfers) de NIC liet hangen.

[Airw0lf]

Liegebeest schreef op woensdag 7 januari 2026 @ 22:14:
[...]

Dat zou geen kernel panic moeten geven, op zijn hoogst hangen tijdens het booten omdat de share onbereikbaar is.

Of het een kernel panic is weet ik niet - maar het systeem blijft er niet op hangen.
Het bootproces wordt gestopt met een login-prompt op de console.
Na ingelogd te zijn kan je fstab aanpassen.

[ Voor 7% gewijzigd door Airw0lf op 07-01-2026 22:22 ]

[Liegebeest]

Het hangt er vanaf hoe't in fstab staat.

"Hangen" was misschien niet het beste woord. Wat ik bedoel is dat wanneer je een "hard" mount doet (via het options veld), dan zal het systeem volledig weigeren door te gaan met het boot proces totdat de share beschikbaar is en ook werkelijk is gemount. Staat daar echter "soft", dan zal na een timeout het systeem doorgaan met het boot proces.

Heel lang geleden heb ik nog te maken gehad met servers die inderdaad bleven "hangen" omdat een file server niet beschikbaar was en de share "hard" mounted was. Die moesten we dus inderdaad naar een rescue boot gooien, de share op "soft" zetten en opnieuw booten.

[ Voor 25% gewijzigd door Liegebeest op 07-01-2026 22:26 ]

[RobbyTown]

chielmi schreef op woensdag 7 januari 2026 @ 19:21:
[...]

Je bent niet de enige https://forum.proxmox.com...9-1-4.178729/#post-829150
In mijn geval was het pinnen van de vorige kernel ook de oplossing.

Die commandos in dat topic geen idee hoe je dat doet. Ik wacht wel op een fix tot die tijd selecteer ik handmatig dat werkt nu ook. Bang dat ik de bedoel echt sloop en daar heb ik weinig zin in. Kan toeval zijn hier ook een Dell machine: uitvoering: Dell OptiPlex 7010 SFF (07CM1)

[ Voor 12% gewijzigd door RobbyTown op 08-01-2026 09:30 ]

[chielmi]

@RobbyTown Die commando's zijn echt niet lastig. Aangezien je eerst handmatig een vorig kernel selecteert in het boot menu zodat je ziet of Proxmox succesvol start. Nu weet je welk kernel goed werkt voor jouw systeem, en pas nu voer je de twee commando's uit die post uit om bij elke volgende boot deze specifieke kernel te gebruiken.

De commando's kun je gewoon in de Proxmox web interface uitvoeren. Selecteer eerst de server in het menu en start vervolgens een shell (4e menu item).

Ik ben er niet van overtuigd dat hier een fix voor gaat komen vanuit Proxmox omdat het nog maar door een handvol mensen is gerapporteerd.

[webgangster]

@RobbyTown Ik heb enige tijd geleden ook hetzelfde probleem gehad, en kunnen oplossen door Secure Boot uit te schakelen.

[ElCondor]

Na eigenlijk het afgelopen jaar geen tijd gehad te hebben om me er goed in te verdiepen de feestdagen er eens voor genomen om mijn ProxMox cluster eens verder 'productie gereed' te maken.
Ik had twee NUC6 apparaatjes hiervoor gebruikt en hier PVE8 op gezet, vorig jaar alweer.
Beetje gespeeld met een containertje aanmaken en heen en weer schieten, maar ik miste toch nog wel fundamentele kennis om de boel echt te beheren.
Het bleef een beetje een black box waar ik vooral gebruik van maakte om een container met een ID provider self-hosted te draaien. Op zich deed het zijn ding, maar het zat me dwars dat ik niet goed begreep hoe de onderliggende infra nu precies functioneerde.
Wat te doen bij een faillure (geen HA ingericht, geen backup, geen derde node beschikbaar enz.). Van de installatie procedure destijds te weinig gedocumenteerd en na een gefaalde upgrade die ik wel succesvol heb kunnen terugrollen toch maar eens door de zure appel heen gebeten en me verdiept in de onderliggende infra theorie.
Na een goede herinrichting mbt de storage, PBS op een nieuwe node uitgerold en PVE zelf geupgrade naar versie 9. Zelfs de aanwezige thunderbolt op de NUC ingezet als migratie netwerk tussen de twee PVE nodes. Dat scheelt de helft van de tijd bij een migratie.
Mijn laatste stap gaat zijn om op de PBS nog QDevice toe te voegen om daarmee HA tussen 2 nodes beschikbaar te hebben.

De bedoeling is om uiteindelijk op dit platform en Kubernetes cluster uit de grond te stampen. We gaan op het werk meer doen met Kubernetes en pods, dus het loont om daar nu ook mee te kunnen knoeien.
Leuk platform. Wellicht op een later moment nog mijn huidige Hyper-V omzetten naar PVE. 64GB ram en 2TB ssd ruimte. Daar moet je leuke dingen mee kunnen doen.

[Niekniek89]

Uiteindelijk toch maar geüpgraded naar v9.1.4, gelukkig zonder issues!

[RobbyTown]

webgangster schreef op donderdag 8 januari 2026 @ 11:36:
@RobbyTown Ik heb enige tijd geleden ook hetzelfde probleem gehad, en kunnen oplossen door Secure Boot uit te schakelen.

Getest maar dat maakt helaas geen verschil.

chielmi schreef op donderdag 8 januari 2026 @ 10:59:
@RobbyTown Die commando's zijn echt niet lastig. Aangezien je eerst handmatig een vorig kernel selecteert in het boot menu zodat je ziet of Proxmox succesvol start. Nu weet je welk kernel goed werkt voor jouw systeem, en pas nu voer je de twee commando's uit die post uit om bij elke volgende boot deze specifieke kernel te gebruiken.

De commando's kun je gewoon in de Proxmox web interface uitvoeren. Selecteer eerst de server in het menu en start vervolgens een shell (4e menu item).

Ik ben er niet van overtuigd dat hier een fix voor gaat komen vanuit Proxmox omdat het nog maar door een handvol mensen is gerapporteerd.

Dank voor de info. Dit lijkt voor mij ook de fix.
In de shell

code:

proxmox-boot-tool kernel pin 6.17.2-2-pve
proxmox-boot-tool refresh

Daarna. Reboot (rechtsboven in interface). Nu start de boel wel netjes op.

Voor wie het boeiend vind. Hierbij de output van de shell.


Allen dank voor de hulp

[ Voor 77% gewijzigd door RobbyTown op 08-01-2026 15:41 ]

[HowsMyApple]

Vanmorgen vroeg wilde ik iets checken in PVE en zag dat enkele LXC's uit stonden. Dat is raar dacht ik.. al snel bedacht ik me dat het allemaal LXC's waren die niet automatisch starten na een reboot.
Oke en waarom is er dan gereboot vannacht? Even in de logs zoeken en ik zag dat er vanwege m'n unattended upgrades config een reboot was gescheduled. Eigenlijk ging alles dus netjes zoals ik het zou willen.
In de toekomst zou ik ipv een "ojee wat is er kapot gegaan"-momentje liever een notificatie oid krijgen dat er iets is geupdatet en gereboot. Dit heb ik net ingeregeld dmv een apt post-invoke hook welke naar een prive Discord channel post.

Het wiel opnieuw uitvinden is soms erg leuk en leerzaam, maar wellicht hebben jullie weet van services/apps die dit beter en overzichtelijker kunnen?

[Airw0lf]

@HowsMyApple - een e-mail vanuit Proxmox/PVE? Zodat je niet afhankelijk bent van de grappen-en-grollen van Discord?

[d-vine]

@HowsMyApple
Pas paar weken geleden gemaakt
Ik heb een n8n CT in proxmox en die stuurt elke week de status door van alle CT's en VM's naar mijn telegram
Je kan ook maken dat bij uitval of reboot je gelijk een melding krijgt en meerdere opties.

[ Voor 112% gewijzigd door d-vine op 10-01-2026 13:39 ]

[Quad]

@HowsMyApple Als je Home Assistant gebruikt kan je Proxmox daar ook in integreren.
Als de hele PVE bak uit staat merk je dat wel snel genoeg, als het actief en herstart is krijg je via Home Assistant eventueel informatie binnen.

[TheMystery]

Ik loop tegen een probleem aan met een docker lxc waar ik de arr suite in draai waar ik een permission denied melding (PermissionError. Exception info: "'[Errno 1] Operation not permitted') krijg als er iets naar de cache folder van bazarr verplaatst wordt, na lang zoeken gevonden dat hiervoor shutil.move voor gebruikt wordt welke te weinig rechten heeft om zijn acties uit te voeren.

ik maak gebruik van een proxmox server waar ik een TrueNAS vm in heb met een aantal shares die ik gekoppeld heb middles de fstab file binnen proxmox en deze gebind mount heb aan de lxc en voor docker heb ik een share voor de config files dit werkt prima voor sonarr en radarr maar dus niet voor bazarr.

ik heb de shares op de volgende manier in fstab gekoppeld:

code:

//nas/Docker/ /mnt/lxc_shares/Docker cifs _netdev,x-systemd.automount,noatime,nobrl,uid=100000,gid=110000,dir_mode=0770,file_mode=0770,user=user,pass=pass 0 0

de bind mount binnen de lxc heb ik als volgt:

code:

lxc.mount.entry: /mnt/lxc_shares/Docker mnt/Docker none rbind,create=dir 0 0

binnen de lxc container en docker (PUID=1000 en PGID=10000 toegevegd) heb ik dan nog de juiste rechten gezet zodat alles werkt:

code:

lxc container
groupadd -g 10000 lxc_shares
useradd user
usermod -aG lxc_shares user

Nu mis ik dus nog waarschijnlijk binnen fstab een optie waardoor shutil.move niet werkt maar kan nergens vinden wat dit nu moet zijn. Iemand een idee?
Als workaround kan ik natuurlijk de config binnen de lxc zetten ipv de share maar had het liever op de share.

[The-Source]

Even een dubbel-check voordat ik mijn eigen systeem zou kunnen slopen. (ook al denk ik dat het veilig is )
Mijn install bestaat uit nvme drive (LVM) hier op draait PVE en van alle VMs/LXC de OS disk.

Daarnaast een Zpool Raid-Z2 van spinning-disks en deze is dan optioneel als VM disk gemount als 2e drive in een VM. Dus nooit als boot en voor VM gezien ook niet als ZFS zichtbaar.
Nu zag ik de "bekende" zpool upgrade bericht en mij lijkt dat dit veilig is om te doen maar toch even een dubbelcheck.

Some supported features are not enabled on the following pools. Once a
feature is enabled the pool may become incompatible with software
that does not support the feature. See zpool-features(7) for details.

Note that the pool 'compatibility' feature can be used to inhibit
feature upgrades.

code:

POOL  FEATURE
---------------
hdds
      redaction_list_spill
      raidz_expansion
      fast_dedup
      longname
      large_microzap

Lang verhaal kort, is het veilig te upgraden?

Backups worden ook in de Zpool opgeslagen maar naast deze backups heb ik ook een PBS draaien op extern systeem die ook backups heeft.

[ComTech]

Ik heb een hp elitedesk i5 8500t erbij gekocht om een extra proxmox node te hebben.
Vaak zit ik te klooien op de "main" node en als er wat mis gaat ligt mijn halve netwerk / domotica eruit.

Nu is deze nieuwe niet stabiel, hij reboot spontaan op random momenten.
De log zegt eigenlijk niks bijzonders alleen reboot
Heb al meerdere geheugen modules gewisseld.
Iemand een idee waar ik verder kan zoeken waarom dit gedrag?

Hij doet op dit moment bijna niks maar het gekke is na een reboot heb ik ineens een veel hogere load dan eerst, exact 1.01 1.01 1.00 dit was eerst 0.01 0.00 0.02 dus precies 1.00 hoger, dit klopt helemaal niet .

code:

Jan 14 01:54:23 pve systemd[1]: Finished beszel-agent-update.service - Update beszel-agent if needed.
Jan 14 01:55:01 pve kernel: audit: type=1400 audit(1768352101.939:1645): apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-209_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log" pid=20590 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=100000 ouid=100000
Jan 14 01:55:01 pve kernel: audit: type=1400 audit(1768352101.939:1646): apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-209_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log" pid=20590 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=100000 ouid=100000
Jan 14 01:55:01 pve kernel: audit: type=1400 audit(1768352101.941:1647): apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-209_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log" pid=20590 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=100000 ouid=100000
-- Reboot --
Jan 14 01:57:05 pve kernel: Linux version 6.17.4-2-pve (build@proxmox) (gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC PMX 6.17.4-2 (2025-12-19T07:49Z) ()
Jan 14 01:57:05 pve kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.17.4-2-pve root=/dev/mapper/pve-root ro quiet
Jan 14 01:57:05 pve kernel: KERNEL supported cpus:
Jan 14 01:57:05 pve kernel:   Intel GenuineIntel

[dotcom87]

ComTech schreef op woensdag 14 januari 2026 @ 19:25:
Ik heb een hp elitedesk i5 8500t erbij gekocht om een extra proxmox node te hebben.
Vaak zit ik te klooien op de "main" node en als er wat mis gaat ligt mijn halve netwerk / domotica eruit.

Nu is deze nieuwe niet stabiel, hij reboot spontaan op random momenten.
De log zegt eigenlijk niks bijzonders alleen reboot
Heb al meerdere geheugen modules gewisseld.
Iemand een idee waar ik verder kan zoeken waarom dit gedrag?

Hij doet op dit moment bijna niks maar het gekke is na een reboot heb ik ineens een veel hogere load dan eerst, exact 1.01 1.01 1.00 dit was eerst 0.01 0.00 0.02 dus precies 1.00 hoger, dit klopt helemaal niet .

code:

Jan 14 01:54:23 pve systemd[1]: Finished beszel-agent-update.service - Update beszel-agent if needed.
Jan 14 01:55:01 pve kernel: audit: type=1400 audit(1768352101.939:1645): apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-209_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log" pid=20590 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=100000 ouid=100000
Jan 14 01:55:01 pve kernel: audit: type=1400 audit(1768352101.939:1646): apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-209_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log" pid=20590 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=100000 ouid=100000
Jan 14 01:55:01 pve kernel: audit: type=1400 audit(1768352101.941:1647): apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-209_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log" pid=20590 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=100000 ouid=100000
-- Reboot --
Jan 14 01:57:05 pve kernel: Linux version 6.17.4-2-pve (build@proxmox) (gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC PMX 6.17.4-2 (2025-12-19T07:49Z) ()
Jan 14 01:57:05 pve kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.17.4-2-pve root=/dev/mapper/pve-root ro quiet
Jan 14 01:57:05 pve kernel: KERNEL supported cpus:
Jan 14 01:57:05 pve kernel:   Intel GenuineIntel

Been there. De fix voor mij was dit: Post in thread 'Proxmox random reboots on HP Elitedesk 800g4 - fixed with proxmox install on top of Debian 12 - now issues with hardware transcoding in plex' https://forum.proxmox.com...n-plex.132187/post-587779

[GHB363]

Ik vrees dat het los van Proxmox staat, maar als je memory al geswapt hebt, en eventueel ook een memtest gedraaid, (maar daar komt die dan misschien ook niet door?),
dan kan je misschien naar de voeding kijken. Ik gok dat deze een externe voeding heeft?
Misschien kan je die even wisselen met een van een ander exemplaar, of een universele?

Zelf met Synology NAS gehad, spontane reboots, in eerste instantie dacht ik ook aan memory, maar uiteindelijk bleek het de voeding te zijn. Dacht na het geheugen gewisseld, en ‚uitgesloten‘ te hebben dat het dan waarschijnlijk het moederbord was, dus nieuwe NAS besteld. Toch een memtest met de voeding van de nieuwe gedaan, en zo waar geen probleem meer. Universele voeding besteld, en toen had ik een goede NAS over…

Zie nu ook in de tussentijd geplaatste reactie hierboven, dat kan natuurlijk ook.

[ Voor 5% gewijzigd door GHB363 op 14-01-2026 20:00 ]

[InjecTioN]

GHB363 schreef op woensdag 14 januari 2026 @ 19:59:
…

Zie nu ook in de tussentijd geplaatste reactie hierboven, dat kan natuurlijk ook.

Hoewel deze hypothese simpeler te implementeren valt.

Er zijn echt een heleboel mensen die deze HP mini’s gebruiken als een proxmox node. De support is er ondertussen ook echt al lang. Deze node hoort deze problemen gewoon niet te hebben. Memtest is eigenlijk het eerste waar ik naar zou kijken. Als die gewoon succesvol blijft draaien, dan heb je een baseline waarin het mogelijk wel lijkt te werken en kan je de oorzaak mogelijk vinden bij het OS. Als echter ook memtest de reboot veroorzaakt, dan is het vervangen van de voeding ook het eerste waar ik naar zou kijken. Memtest hoort gewoon netjes te draaien op het apparaat. Evenals proxmox.

[Gunner]

Gewoon even een praktische vraag. Als ik PVE update zet ik altijd netjes alle VM's uit als ik de reboot doe. Is dat eigenlijk nodig?

[Airw0lf]

Gunner schreef op donderdag 15 januari 2026 @ 08:30:
Gewoon even een praktische vraag. Als ik PVE update zet ik altijd netjes alle VM's uit als ik de reboot doe. Is dat eigenlijk nodig?

Nee - niet nodig.

Kan wel zijn dat er op enig moment een reboot nodig is om alle updates geactiveerd te krijgen - zowel voor pve als voor de vm's en containers.

[ Voor 6% gewijzigd door Airw0lf op 15-01-2026 08:33 ]

[Zwelgje]

Gunner schreef op donderdag 15 januari 2026 @ 08:30:
Gewoon even een praktische vraag. Als ik PVE update zet ik altijd netjes alle VM's uit als ik de reboot doe. Is dat eigenlijk nodig?

Nee dat doet proxmox ook voor je als je herstart (kan je terugzien in de logging)

[The-Source]

Gunner schreef op donderdag 15 januari 2026 @ 08:30:
Gewoon even een praktische vraag. Als ik PVE update zet ik altijd netjes alle VM's uit als ik de reboot doe. Is dat eigenlijk nodig?

In de VM/ LCX opties kan je bootorder aangegeven welke ook (achterwaarts) wordt aangehouden bij een shutdown (reboot).
Daarbij kan je ook nog delays opgeven als je bijvoorbeeld een VM hebt die echt eerder opgestart moet zijn voor een ander (en zo ook netjes afsluiten )

The-Source schreef op zaterdag 10 januari 2026 @ 10:09:
Even een dubbel-check voordat ik mijn eigen systeem zou kunnen slopen. (ook al denk ik dat het veilig is )
Mijn install bestaat uit nvme drive (LVM) hier op draait PVE en van alle VMs/LXC de OS disk.

Daarnaast een Zpool Raid-Z2 van spinning-disks en deze is dan optioneel als VM disk gemount als 2e drive in een VM. Dus nooit als boot en voor VM gezien ook niet als ZFS zichtbaar.
Nu zag ik de "bekende" zpool upgrade bericht en mij lijkt dat dit veilig is om te doen maar toch even een dubbelcheck.

[...]

Lang verhaal kort, is het veilig te upgraden?

Backups worden ook in de Zpool opgeslagen maar naast deze backups heb ik ook een PBS draaien op extern systeem die ook backups heeft.

Had wellicht iemand hier een antwoord op?

[InjecTioN]

The-Source schreef op donderdag 15 januari 2026 @ 08:45:
[...]

In de VM/ LCX opties kan je bootorder aangegeven welke ook (achterwaarts) wordt aangehouden bij een shutdown (reboot).
Daarbij kan je ook nog delays opgeven als je bijvoorbeeld een VM hebt die echt eerder opgestart moet zijn voor een ander (en zo ook netjes afsluiten )


[...]

Had wellicht iemand hier een antwoord op?

Ik kan je niet vertellen of het volledig veilig is. Upgraden heeft in alle situaties zo z’n risico’s. Wanneer je ZFS wilt upgraden, dan gebruik je als het goed is sowieso een supported repository. Updaten zou daarin geen probleem mogen zijn.

Ik heb echter het gevoel dat je het niet alleen over ZFS hebt. Misschien wil je de situatie eens wat breder schetsen voor ons? Meer relevante context is hierin wat beter.

Bij het upgraden van packages krijg je overigens meestal wel warnings wanneer er iets stuk gaat. Wanneer je echter altijd netjes de updates en upgrades hebt gedaan en weinig speciaals in de configuraties hebt gespecificeerd, dan zou het allemaal gewoon as-is moeten kunnen blijven draaien na een update. (Specifieke situaties met bugs daargelaten).

[The-Source]

@InjecTioN mijn PVE host is enige die echt ZFS doet, de andere systemen krijgen een extra disk toegewezen van een vast formaat. Zie laatste afbeelding hoe ik dit o.a. naar diverse VMs doorzet.

PVE Node disk overview:

PVE ZFS


Voorbeeld disk in VM:

[zeroday]

ComTech schreef op woensdag 14 januari 2026 @ 19:25:
Ik heb een hp elitedesk i5 8500t erbij gekocht om een extra proxmox node te hebben.
Vaak zit ik te klooien op de "main" node en als er wat mis gaat ligt mijn halve netwerk / domotica eruit.

Nu is deze nieuwe niet stabiel, hij reboot spontaan op random momenten.
De log zegt eigenlijk niks bijzonders alleen reboot
Heb al meerdere geheugen modules gewisseld.
Iemand een idee waar ik verder kan zoeken waarom dit gedrag?

Hij doet op dit moment bijna niks maar het gekke is na een reboot heb ik ineens een veel hogere load dan eerst, exact 1.01 1.01 1.00 dit was eerst 0.01 0.00 0.02 dus precies 1.00 hoger, dit klopt helemaal niet .

code:

Jan 14 01:54:23 pve systemd[1]: Finished beszel-agent-update.service - Update beszel-agent if needed.
Jan 14 01:55:01 pve kernel: audit: type=1400 audit(1768352101.939:1645): apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-209_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log" pid=20590 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=100000 ouid=100000
Jan 14 01:55:01 pve kernel: audit: type=1400 audit(1768352101.939:1646): apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-209_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log" pid=20590 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=100000 ouid=100000
Jan 14 01:55:01 pve kernel: audit: type=1400 audit(1768352101.941:1647): apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-209_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log" pid=20590 comm="systemd-journal" requested_mask="r" denied_mask="r" fsuid=100000 ouid=100000
-- Reboot --
Jan 14 01:57:05 pve kernel: Linux version 6.17.4-2-pve (build@proxmox) (gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC PMX 6.17.4-2 (2025-12-19T07:49Z) ()
Jan 14 01:57:05 pve kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.17.4-2-pve root=/dev/mapper/pve-root ro quiet
Jan 14 01:57:05 pve kernel: KERNEL supported cpus:
Jan 14 01:57:05 pve kernel:   Intel GenuineIntel

Ik heb het gehad met een intel NUC, daar lag het probleem aan de termal settings. Die kwamen over een bepaalde threshold en daardoor een reboot. Bleek uiteindelijk te liggen aan de pasta onder de CPU ..
maar goed dat kan wellicht voor jou totaal niet van toepassing zijn.

[d3vlin]

The-Source schreef op donderdag 15 januari 2026 @ 08:45:
[...]

In de VM/ LCX opties kan je bootorder aangegeven welke ook (achterwaarts) wordt aangehouden bij een shutdown (reboot).
Daarbij kan je ook nog delays opgeven als je bijvoorbeeld een VM hebt die echt eerder opgestart moet zijn voor een ander (en zo ook netjes afsluiten )


[...]

Had wellicht iemand hier een antwoord op?

Je pool featureset loopt achter t.o.v. de draaiende zfs versie. Door je pool te upgraden kan die ook de nieuwere features van de draaiende zfs versie gaan gebruiken. Of upgraden verstandig is hangt vooral af van welke zfs versie je draait. Als dat de stabiele versie is (van proxmox) zou de pool upgraden geen enkel probleem mogen zijn. (En backups maken doe je natuurlijk al. )

Mocht je je pool na upgraden nog willen importeren op een systeem met een oudere zfs versie dan zou dat in theorie problemen op kunnen leveren, maar mijn ervaring is dat dat in de praktijk in elk geval met minor versieverschillen (dus een 2.3.0 pool importeren met zfs 2.2.x ofzo) ook gewoon prima gaat.

[ Voor 15% gewijzigd door d3vlin op 15-01-2026 11:37 ]

[InjecTioN]

The-Source schreef op donderdag 15 januari 2026 @ 09:49:
@InjecTioN mijn PVE host is enige die echt ZFS doet, de andere systemen krijgen een extra disk toegewezen van een vast formaat. Zie laatste afbeelding hoe ik dit o.a. naar diverse VMs doorzet.

PVE Node disk overview:
[Afbeelding]
PVE ZFS
[Afbeelding]

Voorbeeld disk in VM:
[Afbeelding]

Je gebruikt de ZFS pool als een datastore voor de 201/vm-201-disk0.qcow2 virtual harddisk. Het is dus een 20TB virtual disk.

Je kan hierin eigenlijk weinig mis laten gaan. Wel zou ik er even op letten dat alle VM's en LXC's die iets op die ZFS pool hebben staan, tijdelijk geen toegang hebben tot de datastore tijdens het updaten. Dus wel even de VM's en LXC's netjes afsluiten.

[InjecTioN]

d3vlin schreef op donderdag 15 januari 2026 @ 11:31:
[...]


Je pool featureset loopt achter t.o.v. de draaiende zfs versie. Door je pool te upgraden kan die ook de nieuwere features van de draaiende zfs versie gaan gebruiken. Of upgraden verstandig is hangt vooral af van welke zfs versie je draait. Als dat de stabiele versie is (van proxmox) zou de pool upgraden geen enkel probleem mogen zijn. (En backups maken doe je natuurlijk al. )

Mocht je je pool na upgraden nog willen importeren op een systeem met een oudere zfs versie dan zou dat in theorie problemen op kunnen leveren, maar mijn ervaring is dat dat in de praktijk in elk geval met minor versieverschillen (dus een 2.3.0 pool importeren met zfs 2.2.x ofzo) ook gewoon prima gaat.

Dit is inderdaad ook relevant.

[dotcom87]

Sinds gisteren heb ik Proxmox Backup Server draaien in mijn homelab. Ik draai op dit moment een 10-tal LXC containers en 1 VM (Home Assistant OS).

Ik heb op dit moment een local datastore opgezet op PBS zelf. Deze dacht ik te gebruiken om een beperkt aantal backups bij te houden (hij staat nu op "Keep Last": 3, de rest staat af). Ik heb dan ook nog een NFS share (Synology NAS) toegevoegd in PBS, die ik wil gebruiken om meer backups bij te houden. Ik heb hiervoor een Sync Job opgezet, om de local datastore naar de NAS te pullen. Op die NFS heb ik de volgende pruning ingesteld:

- Keep Last: 3
- Keep Daily: 7
- Keep Weekly: 4
- Keep Monthly: 3

Houden deze waardes wat steek? Ik ben heel erg benieuwd hoe andere home labbers hun backups regelen, zeker qua pruning.

[TheBrones]

dotcom87 schreef op vrijdag 16 januari 2026 @ 09:18:
Sinds gisteren heb ik Proxmox Backup Server draaien in mijn homelab. Ik draai op dit moment een 10-tal LXC containers en 1 VM (Home Assistant OS).

Ik heb op dit moment een local datastore opgezet op PBS zelf. Deze dacht ik te gebruiken om een beperkt aantal backups bij te houden (hij staat nu op "Keep Last": 3, de rest staat af). Ik heb dan ook nog een NFS share (Synology NAS) toegevoegd in PBS, die ik wil gebruiken om meer backups bij te houden. Ik heb hiervoor een Sync Job opgezet, om de local datastore naar de NAS te pullen. Op die NFS heb ik de volgende pruning ingesteld:

- Keep Last: 3
- Keep Daily: 7
- Keep Weekly: 4
- Keep Monthly: 3

Houden deze waardes wat steek? Ik ben heel erg benieuwd hoe andere home labbers hun backups regelen, zeker qua pruning.

Deze link is hier ooit lang geleden als eens gepost: https://pbs.proxmox.com/docs/prune-simulator/ Hiermee kun je berekenen/bekijken hoe lang de retentie is. Zelf heb ik de volgende settings:

Keep last 4
Keep daily: 2
Keep weekly: 1
Keep Monthly: 2

Mogelijk is dit wat weinig, maar ik heb in ieder geval verschillende herstelpunten beschikbaar, de job draait eens per dag. De backups kopieer ik ook nog wel via een cronjob naar een externe locatie eens per week als disaster recovery optie.

[ Voor 5% gewijzigd door TheBrones op 16-01-2026 09:37 ]

[ElCondor]

Na een weekje in de avonduren buffelen heb ik het dan eindelijk voor elkaar. Afscheid genomen van Hyper-V voor ProxMox. Na een start te hebben gemaakt op drie NUC-jes met ieder 32G aan ram en 450GB aan local storage, de sprong genomen en twee leuke productie nodes ingericht:
8-core i3 met 64GB ram en 2TB local ssd storage voor de main productie server. Dit was eerst de Hyper-V machine.
12-core i7 met 32GB ram en 500GB local ssd storage voor failover en pre-prod
Op de i3 draaien nu nog een aantal Windows VMs waarvan ik aan het bedenken ben of ik die ook wil uitfaseren. Deze heb ik van de Hyper-V host geconverteerd naar ProxMox VM en in eerste instantie op de NUCs en de preprod machine in de benen geholpen. Toen ik de Hyper-V leeg had, deze uitgefaseerd uit het Windows domein en opnieuw opgetuigd als ProxMox node. Opgenomen in het cluster en de Windows VM's teruggemigreerd naar deze machine (man, de technniek werkt voor je, stel je eens voor! )

Het hele cluster is nu backed door een ssd-cached NFS share om containers en Linux VMs op te draaien. De Windows guests blijven voor nu nog even op de local storage draaien van de main node. Ik heb een groepje van deze guests als essentieel gedefinieerd en deze kunnen dan over failen naar de pre-prod machine.
De NFS share en migraties gaan over een fysiek los netwerk met dedicated switch. Nu nog op 1GBps, want de NAS ondersteund niet beter. De NAS heeft wel een dedicated nic om de NFS share aan de nodes aan te bieden. Dus het zit normaal productie verkeer niet in de weg. Leuk was nog wel dat de NUCs ook een thunderbolt port hadden, maar ieder maar eentje. Kon dus wel een direct link opzetten voor migratie tussen die twee, maar niet een ring netwerk voor de andere nodes.
Kun je in ProxMox twee netwerken als migratie definieren? Zodat migraties tussen de NUCs wel over thunderbolt gaan?

Last, but not least, de derde NUC ingericht als PBS met een iSCSI verbinding naar een tweede NAS. Deze voorziet de backup jobs voor het hele cluster. Nice Dit wordt nog wel over het normale netwerk gedaan, maar dit gebeurt 's nachts, dus niet heel veel overhead voor me.

Ongelovelijk veel geleerd afgelopen week. Was ook een machitg mooi traject waar ik toch wel tegen op zag.

[nassau]

ElCondor schreef op donderdag 22 januari 2026 @ 10:16:
Kun je in ProxMox twee netwerken als migratie definieren? Zodat migraties tussen de NUCs wel over thunderbolt gaan?

Lekker gewerkt!

Je kunt inderdaad een migratienetwerk configureren: Datacenter->Options->Migration Setting. Kies hier de netwerkinterface

[Liegebeest]

Tot voor kort draaide mijn productie email en file servers op één enkele Proxmox node, tot overmaat van ramp ook nog eens met maar één opslagdevice. Ik heb natuurlijk solide backups en meerdere kopieën van alle data, maar toch... heel tof is het niet!

Ik heb de boel dus geüpgraded naar een cluster met twee nodes, beiden met de interne storage in RAID1. De migratie was even rommelig door mijn eigen onwennigheid, maar het is gelukt!

Maar dan: twee nodes is ook niet tof! Dat kan leiden tot split brain situaties waardoor het cluster geen kant meer op wil en je handmatig moet ingrijpen. Tijd dus voor een externe vote, om alsnog quorum te behalen. Proxmox hebben daar zelf een oplossing voor, de QDevice / Corosync-qnetd oplossing, die je gewoon op Linux kan draaien.

Mijn enige andere 24/7-on apparaat is de Synology en die kan containers draaien, dus dat is een win. Ik kan dus QDevice draaien in een Linux-container, op m'n Synology. Ik ben eens rond gaan neuzen en de meesten wijzen naar bcleonard/proxmox-qdevice. Dat ding heeft een aantal nadelen:

• Al meer dan een jaar niet bijgewerkt.
• Geen regelmatige releases voor patches en updates.
• Gebouwd op Debian Bookworm.[/i]
• Volgens bcleonard zelf draait het niet goed op Synology.[/i]
• Alles draait als root.
• Root logt in met een wachtwoord dat je elders ook nog eens opslaat

Niet tof, dus ik heb het project geforkt om één voor één die dingen aan te pakken.

• Het project op Github, met build pipelines en alles dat nodig is om te bouwen + runnen.
• De werkelijke container image op Docker Hub en op GHCR.[/i]

Al een aantal van de dingen die ik niet leuk vond verholpen: Wekelijkse update, build en release, wekelijkse scan op vulnerabilities. Releases met Trixie en Bookworm. Releases voor ARM64 en x86_64. Draait als een zonnetje op m'n Synology RS.

Volgende wat ik ga aanpakken: over naar een hele andere parent image, voor nog minder kwetsbaarheden. En daarna afstappen van het feit dat alles als root draait.

[Airw0lf]

@Liegebeest - en waarom dan QDevice/Corosync-qnetd niet gaan gebruiken?

[ Voor 21% gewijzigd door Airw0lf op 24-01-2026 12:30 ]

[Liegebeest]

Airw0lf schreef op zaterdag 24 januari 2026 @ 12:30:
@Liegebeest - en waarom dan QDevice/Corosync-qnetd niet gaan gebruiken?

Dat doe ik juist wel: ik run QDevice / Corosync-qnetd binnen die container op m'n Synology.

Misschien moet ik m'n post iets verduidelijken.

[ Voor 3% gewijzigd door Liegebeest op 24-01-2026 13:32 ]

[nassau]

Liegebeest schreef op zaterdag 24 januari 2026 @ 13:31:
[...]

Dat doe ik juist wel: ik run QDevice / Corosync-qnetd binnen die container op m'n Synology.

Misschien moet ik m'n post iets verduidelijken.

Ik heb een minimale VM met dietpi (debian) op mijn synology en dan corosync geïnstalleerd. Automatische updates, set and forget.

[Liegebeest]

nassau schreef op zaterdag 24 januari 2026 @ 14:17:
[...]
Ik heb een minimale VM met dietpi (debian) op mijn synology en dan corosync geïnstalleerd. Automatische updates, set and forget.

Dan doen we in principe het zelfde: een aparte, kleine omgeving op een Synology om de Qdevice te draaien. Of het nou een kleine VM of een container is, is lood om oud ijzer voor mij. Maar voor hen die het met een container willen oplossen, Synology of elders, wilde ik iets betrouwbaarders neerzetten dat wel wordt onderhouden.

[MJV]

Waarschijnlijk probeer ik iets te doen wat niet kan, maar ik probeer het toch.

Ik heb een Synology NAS met een NFS-share die ik in Proxmox heb toegevoegd.
Die NFS-share wil ik in een WIndows VM als disk zien, zodat ik met Proton Drive foto's kan importeren.

Ik kom er echter niet helemaal uit hoe ik dat doe. Ik kan de NSF-share als storage gebruiken, maar heb dan logischerwijs nog geen 1-op-1 toegang vanuit Synology.

Achterliggende use case: Google Takeout gedaan, 400GB aan foto's op Synology, die nu syncen. Proton Drive client wil niet syncen vanaf netwerkschijf, nu alles op USB-hdd gezet, dat werkt, maar is traag. Die USB-hdd wil ik er tussen hebben, zodat ik met een Windows VM direct vanaf de Synology kan syncen. Maar dan moet die share dus wel als 'echte disk' zichbaar zijn in die Windows VM...

WIe kan mij in de juiste richting wijzen?

[ Voor 29% gewijzigd door MJV op 24-01-2026 22:02 ]

[Rozz]

MJV schreef op zaterdag 24 januari 2026 @ 21:55:
Waarschijnlijk probeer ik iets te doen wat niet kan, maar ik probeer het toch.
Ik heb een Synology NAS met een NFS-share die ik in Proxmox heb toegevoegd.
Die NFS-share wil ik in een WIndows VM als disk zien, zodat ik met Proton Drive foto's kan importeren.
Ik kom er echter niet helemaal uit hoe ik dat doe. Ik kan de NSF-share als storage gebruiken, maar heb dan logischerwijs nog geen 1-op-1 toegang vanuit Synology.
Achterliggende use case: Google Takeout gedaan, 400GB aan foto's op Synology, die nu syncen. Proton Drive client wil niet syncen vanaf netwerkschijf, nu alles op USB-hdd gezet, dat werkt, maar is traag. Die USB-hdd wil ik er tussen hebben, zodat ik met een Windows VM direct vanaf de Synology kan syncen. Maar dan moet die share dus wel als 'echte disk' zichbaar zijn in die Windows VM...

WIe kan mij in de juiste richting wijzen?

Ik heb in al mn windows-vm`s een NFS share via windows verkenner gemaakt/gelinkt, direct toegang tot de Syno dus, ik snap niet helemaal wat er bij jou dan niet lukt? (Ik heb niets met die share in Proxmox gedaan trouwens)

[MJV]

Rozz schreef op zondag 25 januari 2026 @ 09:47:
[...]


Ik heb in al mn windows-vm`s een NFS share via windows verkenner gemaakt/gelinkt, direct toegang tot de Syno dus, ik snap niet helemaal wat er bij jou dan niet lukt? (Ik heb niets met die share in Proxmox gedaan trouwens)

Probleem is dat de Proton Drive app niet wil syncen vanaf een netwerklocatie. Heb nu maar via USB passthrough de hdd aan mijn proxmox host gehangen...

[Rozz]

MJV schreef op zondag 25 januari 2026 @ 09:50:
[...]
Probleem is dat de Proton Drive app niet wil syncen vanaf een netwerklocatie. Heb nu maar via USB passthrough de hdd aan mijn proxmox host gehangen...

Aha, ja snappum, misschien kan je kijken of de Syno als iscsi / lun op je VM aan kan sluiten, schijnt dan wel als een lokale HD te komen?!? zelf geen ervaring mee.

[Quad]

Rozz schreef op zondag 25 januari 2026 @ 16:28:
[...]


Aha, ja snappum, misschien kan je kijken of de Syno als iscsi / lun op je VM aan kan sluiten, schijnt dan wel als een lokale HD te komen?!? zelf geen ervaring mee.

Dat kan dan wel, maar die data is dan ook op een scsi volume, en daar kan je dan weer niets mee binnen je Synology.

[ElCondor]

nassau schreef op vrijdag 23 januari 2026 @ 18:46:
[...]

Lekker gewerkt!

Je kunt inderdaad een migratienetwerk configureren: Datacenter->Options->Migration Setting. Kies hier de netwerkinterface

Ja, die had ik gevonden en daar kun je één netwerk definiëren. Maar kun je er ook twee opgeven? Een van de nodes is nog niet op zijn plek beland en kan daardoor niet fysiek op het migratienetwerk worden aangesloten. Althans, niet zonder bekabeling over de gehele zolder te gooien
Hij kan wel migreren via het normale productie netwerk, maar dan moet ik iedere keer switchen. Geen groot issue, maar wel meer klikken te maken. Ik zou graag het productie netwerk als een soort fall-back instellen voor migraties. Nu ja, het werkt verder goed, dus alles ok voor nu,

[MJV]

Quad schreef op zondag 25 januari 2026 @ 16:29:
[...]

Dat kan dan wel, maar die data is dan ook op een scsi volume, en daar kan je dan weer niets mee binnen je Synology.

Precies. Het volgende-minst-slechte wat ik nu heb bedacht is een reguliere Windows share maken op mijn VM, die kan ik vanaf mijn Synology benaderen als het goed is. Dan zou ik daar vanaf de Synology de data heen kunnen pompen en vanaf de VM kunnen syncen. Dat wordt alleen qua performance denk ik dramatisch, want de storage van de VM staat ook op de Synology, dus gaat die data in een soort cirkeltje.

[ElCondor]

Zo dan, ook alweer mijn eerste hartaanval achter de rug. Met Windows en Hyper-V op mijn main server werd de SMART status van de verschillende disks eigenlijk niet echt in de gaten gehouden. Dus nu ik ProxMox er op heb staan gebeuren daar wel checks voor. En nu blijkt de main nvme waar PM zelf op staat SMART errors qua temperatuur te geven Ik heb toen nog gevoeld aan de disk en het leek me niet dat de disk nu echt heet werd, maar dat kunnen natuurlijk ook piek momenten zijn. Afgelopen vrijdag ineenkeer mail dat de main server succesvol fenced off was en dat de guests allemaal failovered zouden worden naar de andere nodes (had wel HA aan staan, maar verder niets aan fine-tuning gedaan).
Lekker dan, niets kwam echt terug meer op, dus het hele HA verhaal had gefaald. Thuisgekomen blijkt de server in de installatie boot te staan vanaf de PM iso die via de JetKVM geprovisioned werd. Oh-ohw, geen bootdevice? Inderdaad, na een reboot bleek de eerste disk foetsie:
Server uitgebouwd, disk eruit, was niet te heet, opnieuw geseat, server geboot en jawel, de disk was er weer en de server kwam op, echter, een flink aantal guests stonden her en der in error state op de verschillende nodes waarnaar ze een poging hadden gedaan om over te failen.
Opruimen geblazen en daarna bleek het opzetten van PBS een gouden greep te zijn geweest. Guests vanaf de PBS terugblazen naar de originele locatie en booten met die hap. Geen enkel probleem.
Nu dan toch wel even goed gaan zitten om HA voor de meest essentiele guests in te richten (DC en RDP server).
Daarnaast komt vanmiddag een heatsink voor de nvme drive binnen en die toch maar even installeren. Kan ik gelijk kijken of die failover zijn werk doet.

[InjecTioN]

ElCondor schreef op maandag 26 januari 2026 @ 09:44:
Zo dan, ook alweer mijn eerste hartaanval achter de rug. Met Windows en Hyper-V op mijn main server werd de SMART status van de verschillende disks eigenlijk niet echt in de gaten gehouden. Dus nu ik ProxMox er op heb staan gebeuren daar wel checks voor. En nu blijkt de main nvme waar PM zelf op staat SMART errors qua temperatuur te geven Ik heb toen nog gevoeld aan de disk en het leek me niet dat de disk nu echt heet werd, maar dat kunnen natuurlijk ook piek momenten zijn. Afgelopen vrijdag ineenkeer mail dat de main server succesvol fenced off was en dat de guests allemaal failovered zouden worden naar de andere nodes (had wel HA aan staan, maar verder niets aan fine-tuning gedaan).
Lekker dan, niets kwam echt terug meer op, dus het hele HA verhaal had gefaald. Thuisgekomen blijkt de server in de installatie boot te staan vanaf de PM iso die via de JetKVM geprovisioned werd. Oh-ohw, geen bootdevice? Inderdaad, na een reboot bleek de eerste disk foetsie:
Server uitgebouwd, disk eruit, was niet te heet, opnieuw geseat, server geboot en jawel, de disk was er weer en de server kwam op, echter, een flink aantal guests stonden her en der in error state op de verschillende nodes waarnaar ze een poging hadden gedaan om over te failen.
Opruimen geblazen en daarna bleek het opzetten van PBS een gouden greep te zijn geweest. Guests vanaf de PBS terugblazen naar de originele locatie en booten met die hap. Geen enkel probleem.
Nu dan toch wel even goed gaan zitten om HA voor de meest essentiele guests in te richten (DC en RDP server).
Daarnaast komt vanmiddag een heatsink voor de nvme drive binnen en die toch maar even installeren. Kan ik gelijk kijken of die failover zijn werk doet.

PBS (Proxmox Backup Server) heeft mij inderdaad ook al meerdere malen uit de brand geholpen. Wat een fijn product is dat!

Dus de conclusie kan zijn dat de SSD simpelweg niet lekker in z'n slot gestoken zat, of dat de hitte (en afkoelen) misschien juist voor rek en krimp heeft gezorgd, waardòòr de SSD niet lekker in z'n slot meer zat.

Een heatsink is in zo'n geval nooit een slecht idee.

In mijn proxmox cluster heb ik 3 identieke mini pc nodes in clusterized HA opstelling draaien. Iedere node heeft een nvme boot disk (OEM SSD van 256GB) met het OS en een enterprise SATA SSD van Intel (480GB). De SATA disk zit in een CEPH volume over iedere node, wat eigenlijk een mirror is over 3 nodes. Hierdoor is er overal shared storage aanwezig in het geval van een fail-over. Ook heb ik daarnaast nog een OpenMediaVault-NAS met bulk storage waar de VM's afzonderlijk verbinding mee maken. De PBS LXC maakt daar ook verbinding mee.

Wekelijkse backup wordt voorzien vanaf een andere machine op mijn netwerk - aan de andere kant van mijn huis.

[ElCondor]

InjecTioN schreef op maandag 26 januari 2026 @ 10:14:
[...]

PBS (Proxmox Backup Server) heeft mij inderdaad ook al meerdere malen uit de brand geholpen. Wat een fijn product is dat!

Dus de conclusie kan zijn dat de SSD simpelweg niet lekker in z'n slot gestoken zat, of dat de hitte (en afkoelen) misschien juist voor rek en krimp heeft gezorgd, waardòòr de SSD niet lekker in z'n slot meer zat.

Een heatsink is in zo'n geval nooit een slecht idee.

In mijn proxmox cluster heb ik 3 identieke mini pc nodes in clusterized HA opstelling draaien. Iedere node heeft een nvme boot disk (OEM SSD van 256GB) met het OS en een enterprise SATA SSD van Intel (480GB). De SATA disk zit in een CEPH volume over iedere node, wat eigenlijk een mirror is over 3 nodes. Hierdoor is er overal shared storage aanwezig in het geval van een fail-over. Ook heb ik daarnaast nog een OpenMediaVault-NAS met bulk storage waar de VM's afzonderlijk verbinding mee maken. De PBS LXC maakt daar ook verbinding mee.

Wekelijkse backup wordt voorzien vanaf een andere machine op mijn netwerk - aan de andere kant van mijn huis.

Nice, ik heb replication voor wat guests aan staan, maar op een ZFS volume. Ceph vereist in de meeste gevallen een 10Gb netwerk, heb ik me laten vertellen, en dat heb ik net niet liggen. Heb jij het wel op 10Gb draaien? Jouw Ceph cluster, bedoel ik dan?

[InjecTioN]

ElCondor schreef op maandag 26 januari 2026 @ 10:21:
[...]

Nice, ik heb replication voor wat guests aan staan, maar op een ZFS volume. Ceph vereist in de meeste gevallen een 10Gb netwerk, heb ik me laten vertellen, en dat heb ik net niet liggen. Heb jij het wel op 10Gb draaien? Jouw Ceph cluster, bedoel ik dan?

Ik heb een active-passive dual NIC opstelling via on-board 1Gbe en m.2 2.5Gbe kaartje. Dus ik heb wel een hogere doorvoer met 2.5Gbe ja. Een unify flex2.5 er tussen gezet en de 1Gbe poortjes aan een Zyxel 1920 series 8-poort switch.

Draait echt meer dan prima zo.

[ElCondor]

Nou, nvme voorzien van een heatsink, lijkt te werken, de temps registeren nu als -1~-5
Toen ook maar eens de andere nvme gecheckt en die blijkt ook een negatieve temp te registreren, vreemd allemaal, maar het schijnt voor te komen, zegt het internet. Niet iets om je zorgen over te maken, blijkbaar.
We gaan het allemaal meemaken. In de tussentijd ook direct maar even de 3e node voorzien van een extra nic die nu met de nas praat en dat werkt allemaal als een zonnetje.
Nog eens goed in de HA strategie duiken, want bij het downgaan van node 4, de main server, bleek één van de guests nog gekoppeld te zijn aan een lokale iso. Deze dus altijd direct verwijderen als je er klaar mee bent, want als de lokale iso niet beschikbaar is op de target node voor failover, dan => mislukte failover. Of is dat ook in te stellen? Een iso zou geen issue mogen zijn voor failover op een andere node, mijns inziens.

[InjecTioN]

ElCondor schreef op maandag 26 januari 2026 @ 23:12:
Nou, nvme voorzien van een heatsink, lijkt te werken, de temps registeren nu als -1~-5
Toen ook maar eens de andere nvme gecheckt en die blijkt ook een negatieve temp te registreren, vreemd allemaal, maar het schijnt voor te komen, zegt het internet. Niet iets om je zorgen over te maken, blijkbaar.
We gaan het allemaal meemaken. In de tussentijd ook direct maar even de 3e node voorzien van een extra nic die nu met de nas praat en dat werkt allemaal als een zonnetje.
Nog eens goed in de HA strategie duiken, want bij het downgaan van node 4, de main server, bleek één van de guests nog gekoppeld te zijn aan een lokale iso. Deze dus altijd direct verwijderen als je er klaar mee bent, want als de lokale iso niet beschikbaar is op de target node voor failover, dan => mislukte failover. Of is dat ook in te stellen? Een iso zou geen issue mogen zijn voor failover op een andere node, mijns inziens.

Sensors zijn voor OEM SSD’s soms inderdaad nog niet bekend in lmsensors, en/of het meten wijkt af van de standaard. Je kan eens kijken of er nog een firmware update voor beschikbaar is.

Wat betreft die ISO: ik heb nog nooit een iso hoeven gebruiken onder Proxmox. Ik gebruik namelijk deze LXC helper scripts: https://community-scripts.github.io/ProxmoxVE/

Ik gebruik overigens überhaupt geen Windows, wat voor mij de enige reden zou zijn om een ISO te moeten gebruiken.

Het hele ISO verhaal is overigens wel een bekend issue dat ook speelt bij ESXi en andere hypervisors. Je hebt simpelweg een working state gedefinieerd die je graag wilt aanhouden in de VM settings. Dat is ooit gevalideerd geweest, maar er ontbreekt simpelweg virtual hardware (ISO). Reden genoeg om te falen. Vooral als een dienst die je wilt draaien ervan afhankelijk is. ¯\_(ツ)_/¯

[ElCondor]

InjecTioN schreef op dinsdag 27 januari 2026 @ 07:16:
[...]
...
Wat betreft die ISO: ik heb nog nooit een iso hoeven gebruiken onder Proxmox. Ik gebruik namelijk deze LXC helper scripts: https://community-scripts.github.io/ProxmoxVE/

Ik gebruik overigens überhaupt geen Windows, wat voor mij de enige reden zou zijn om een ISO te moeten gebruiken.

Het hele ISO verhaal is overigens wel een bekend issue dat ook speelt bij ESXi en andere hypervisors. Je hebt simpelweg een working state gedefinieerd die je graag wilt aanhouden in de VM settings. Dat is ooit gevalideerd geweest, maar er ontbreekt simpelweg virtual hardware (ISO). Reden genoeg om te falen. Vooral als een dienst die je wilt draaien ervan afhankelijk is. ¯\_(ツ)_/¯

De helperscripts ken ik inderdaad. Het probleem was dat ik de VirtIO iso nodig had om de helper agent te installeren op de windows guests. Daarom stak deze er nog in. Ik ben me nog aan het beraden of ik de windows machines moet uitfaseren. Ik heb ze ook wel om gewoon de kennis een beetje op peil te houden en om mijn betere helft te voorzien van windows spulleboel, aangezien ze dat voor haar werk nodig heeft.

[commentator]

ElCondor schreef op dinsdag 27 januari 2026 @ 08:10:
[...]

De helperscripts ken ik inderdaad. Het probleem was dat ik de VirtIO iso nodig had om de helper agent te installeren op de windows guests. Daarom stak deze er nog in. Ik ben me nog aan het beraden of ik de windows machines moet uitfaseren. Ik heb ze ook wel om gewoon de kennis een beetje op peil te houden en om mijn betere helft te voorzien van windows spulleboel, aangezien ze dat voor haar werk nodig heeft.

na de installatie van de helper agent mag die iso er gewoon af

[ElCondor]

commentator schreef op dinsdag 27 januari 2026 @ 08:24:
[...]

na de installatie van de helper agent mag die iso er gewoon af

DAT begrijp ik, maar dat was ik vergeten te doen nadat ik de agent geinstalleerd had. Nog nooit een ceedeetje in de lade laten zitten?

[zeroday]

ElCondor schreef op dinsdag 27 januari 2026 @ 08:42:
[...]

DAT begrijp ik, maar dat was ik vergeten te doen nadat ik de agent geinstalleerd had. Nog nooit een ceedeetje in de lade laten zitten?

Toevallig vorige week gehad. ik verwijder een Linux iso bij een van mijn VM's en reboot en het kreng wilde niet meer starten en riep om de ISO .. uh ???
even alles terug gezet, boot order aangepast en daarna kon het wel ..

mja .. heul apart maar goed ..

[orvintax]

ElCondor schreef op maandag 26 januari 2026 @ 23:12:
Nou, nvme voorzien van een heatsink, lijkt te werken, de temps registeren nu als -1~-5
Toen ook maar eens de andere nvme gecheckt en die blijkt ook een negatieve temp te registreren, vreemd allemaal, maar het schijnt voor te komen, zegt het internet. Niet iets om je zorgen over te maken, blijkbaar.
We gaan het allemaal meemaken. In de tussentijd ook direct maar even de 3e node voorzien van een extra nic die nu met de nas praat en dat werkt allemaal als een zonnetje.
Nog eens goed in de HA strategie duiken, want bij het downgaan van node 4, de main server, bleek één van de guests nog gekoppeld te zijn aan een lokale iso. Deze dus altijd direct verwijderen als je er klaar mee bent, want als de lokale iso niet beschikbaar is op de target node voor failover, dan => mislukte failover. Of is dat ook in te stellen? Een iso zou geen issue mogen zijn voor failover op een andere node, mijns inziens.

Opzich logisch naar mijn mening als de ISO enkel lokaal op een bepaalde node is opgeslagen. Als je de ISO niet meer nodig hebt is verwijderen natuurlijk het handigst. Maar je kunt hem ook verplaatsen naar een stukje opslag wat voor meerdere nodes bereikbaar is i.e. het netwerk. Denk aan iets als NFS of CEPH.

[dotcom87]

Hoe monitoren jullie de services die jullie hebben lopen op proxmox?
En ik vroeg me ook af of Proxmox zelf al iets ingebouwd heeft ivm falende disks (slechte sectoren etc)?

[InjecTioN]

dotcom87 schreef op dinsdag 27 januari 2026 @ 20:22:
Hoe monitoren jullie de services die jullie hebben lopen op proxmox?
En ik vroeg me ook af of Proxmox zelf al iets ingebouwd heeft ivm falende disks (slechte sectoren etc)?

Proxmox heeft een onderdeel in het menu zitten waarin je van iedere disk de health status af kan lezen. Verder dan dat is er bij mijn weten niet echt iets.

Ik houd de health status overigens ook handmatig bij in grafieken binnen home assistant.

[Liegebeest]

dotcom87 schreef op dinsdag 27 januari 2026 @ 20:22:
Hoe monitoren jullie de services die jullie hebben lopen op proxmox?

Daaaaaaarrrr....moet ik nog werk in steken.

[Theetjuh]

Met Pulse, Patchmon en dan nog het nodige in Home Assistant

[dotcom87]

Theetjuh schreef op dinsdag 27 januari 2026 @ 20:35:
Met Pulse, Patchmon en dan nog het nodige in Home Assistant

Wat heb je dan zoal in Home Assistant zitten wat betreft Proxmox?

[Theetjuh]

dotcom87 schreef op dinsdag 27 januari 2026 @ 20:46:
[...]


Wat heb je dan zoal in Home Assistant zitten wat betreft Proxmox?

cpu, memory, diskspace van zowel de nodes als vm/lxc.
En heb sinds kort ook de temperatuur van cpu/gpu en nvme erin dmv een scriptje.

[InjecTioN]

Theetjuh schreef op dinsdag 27 januari 2026 @ 20:51:
[...]

cpu, memory, diskspace van zowel de nodes als vm/lxc.
En heb sinds kort ook de temperatuur van cpu/gpu en nvme erin dmv een scriptje.

Nice! Gevalletje GMTA I guess. Dat doe ik hier ook, maar dan dus ook met disk health erbij.

Ik ga vanavond mijn configuratie met de 3 nodes nog even omgooien. Ik heb 2 SSD’s in mijn units zitten, maar ik gebruik er nu slechts een. De enterprise SSD moet als CEPH storage dienen, maar dus ook echt alleen CEPH storage en niet ook OS boot disk zoals nu…

Dus: proxmox opnieuw installeren op de m.2 SSD, koppelen aan het cluster, nieuwe CEPH OSD aanmaken en koppelen aan de CEPH storage. als alle drie de nodes afgerond zijn, zou ik ook gelijk wat meer schijfruimte over moeten hebben.

We gaan het zien of het ook zo vlekkeloos gaat. Ik heb alles gedocumenteerd van de vorige keer, dus het zou een breeze moeten zijn. Famous last words…