Het grote Proxmox VE topic

[Flappie]

Navi schreef op dinsdag 16 september 2025 @ 20:40:
[...]


Moet je niet gewoon even --clear-needs-check-flag toevoegen aan de options?

Ja, dat had ik geprobeerd maar dan deed mijn storage het niet meer en konden de vm's dus niet starten.

Uiteindelijk maar gewoon de update gedaan. Tijdens het update proces werd ik gevraagd of ik lvm.conf wilde overschrijving met een nieuwe default versie. Dat maar gedaan en na de upgrade werkte alles naar behoren ook zonder de no-mappings parameter.

Ik vraag me eigenlijk nu vooral af waarom die check word gedaan als de upgrade toch een nieuwe default lvm.conf installeert.

[sloth]

Hoe maken jullie offsite backups van VMs of containers?

Wat ik wil doen is automatisch een VM backuppen naar s3 storage. Wat ik nu al heb:

Automatische backup job van de VM in PVE
LXC met rclone en een bind mount naar de PVE host backup locatie (RO)
rclone copy naar AWS s3 bucket met beperkte permissions

Wat nog moet gebeuren is een cron job oid in de container of op de host om bijvoorbeeld 1x per maand de rclone copy uit te voeren.

Dit lijkt wel zo een houtje touwtje oplossing...
PBS heb ik ook overwogen. Vanaf versie 4 heb je ook s3 support in preview. Iemand daar ervaring mee? Of andere opties?

[nassau]

sloth schreef op zaterdag 20 september 2025 @ 10:38:
Hoe maken jullie offsite backups van VMs of containers?

Wat ik wil doen is automatisch een VM backuppen naar s3 storage. Wat ik nu al heb:

Automatische backup job van de VM in PVE
LXC met rclone en een bind mount naar de PVE host backup locatie (RO)
rclone copy naar AWS s3 bucket met beperkte permissions

Wat nog moet gebeuren is een cron job oid in de container of op de host om bijvoorbeeld 1x per maand de rclone copy uit te voeren.

Dit lijkt wel zo een houtje touwtje oplossing...
PBS heb ik ook overwogen. Vanaf versie 4 heb je ook s3 support in preview. Iemand daar ervaring mee? Of andere opties?

PBS is zoveel makkelijker om dit te regelen …

ik heb het als een VM draaien op mijn NAS. Alle backups naar een NFS share. Vanuit NAS een rsync job naar een externe storagebox (Hetzner). Draai ook nog een zelfde replicatie naar een externe SSD voor de zekerheid.

S3 in 4.0 zou goed moeten werken, zelf nog geen ervaring mee.

[The-Source]

Vandaag mijn PVE 8 >9 upgrade ( duurde een uur) gedaan en ook gelijk PBS 3>4
Maar LXC upgrade moet ik nog even uitvogelen. Ze werken allemaal maar zitten nog wel op bookworm.

Mijn LXC update stappen (zou wellicht beter kunnen maar werkt )

code:

apt full-upgrade

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

apt update

apt upgrade --without-new-pkgs -y

apt full-upgrade -y

apt autoremove --purge -y
reboot
## check_version: 
cat /etc/*-release

^^ PS bestaand doet ook ergens nog een python update en als je LXC software daar kritish over is dan goed om het monitoren (of in ieder geval backup vooraf)

[ Voor 59% gewijzigd door The-Source op 20-09-2025 17:43 ]

[HellStorm666]

Voor debian 13 kan je tegenwoordig ook

code:

apt dist-upgrade -y --update

doen.
Die

code:

--update

kan er sowieso altijd achter, waardoor ie zelf een apt update doet als t nodig is.

[ Voor 8% gewijzigd door HellStorm666 op 23-09-2025 19:47 ]

[BJozi]

Ik heb hulp nodig met iets dat makkelijker in mijn hoofd had geweest.

Ik heb een 1tb nvme waarop proxmox is geïnstalleerd. Proxmox heeft de nodige partitions gemaakt met als gevolg dat ik 800+gb ruimte heb (voor denk ik containers).

Voorheen had ik een kleine os drive, nu deze groter is wilde ik de download map voor sabnzbd (lxc) in dat 800gb volume maken. Ik kan alleen niet vinden hoe ik dit kan doen? Chatgpt maakt het alleen maar meer verwarrend, heeft iemand een tutorial die dit goed uitgelegd?

[H143]

sinds kort sluiten mijn containers automatisch af en starten vervolgens ook weer vanzelf
ik heb nog niet kunnen vinden wat het is helaas heb ik niet veel verstand van Linux
kan iemand mij opweg helpen waar dit probleem vandaan kan komen?

[lolgast]

Lijkt me in ieder geval vanuit de Proxmox host zelf want als je een LXC een shutdown geeft vanuit de LXC zefl zie je geen 'Stop'.

Staat er een rare cronjob actief ofzo? crontab -l even draaien en kijken of daar iets van pct restart .. in voorkomt

[H143]

lolgast schreef op vrijdag 3 oktober 2025 @ 22:30:
Lijkt me in ieder geval vanuit de Proxmox host zelf want als je een LXC een shutdown geeft vanuit de LXC zefl zie je geen 'Stop'.

Staat er een rare cronjob actief ofzo? crontab -l even draaien en kijken of daar iets van pct restart .. in voorkomt

ik had de volgende regels erin staan

code:

@reboot (sleep 60 && echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor)
0 0 * * 0 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/misc/update-lxcs-cron.sh)" >>/var/log/update-lxcs-cron.log 2>/dev/null

deze heb ik verwijderd maar helas geen soelaas

[RobertMe]

H143 schreef op vrijdag 3 oktober 2025 @ 22:54:
[...]

ik had de volgende regels erin staan

code:

@reboot (sleep 60 && echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor)
0 0 * * 0 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/misc/update-lxcs-cron.sh)" >>/var/log/update-lxcs-cron.log 2>/dev/null

offtopic:
"Doe elke zondag om middernacht een script downloaden van internet en uitvoeren als root", * ouch *. Als die helper scripts geïnfecteerd worden met malware heb je het niet eens in de gaten.

[hansat]

Ik weet niet of deze al eerder in dit topic is vermeld maar bij deze ProxMenux
https://github.com/MacRimi/ProxMenux

een hele goede tool tenminste voor mij

[Cardinal]

@hansat heb je screenshots oid? is het vergelijkbaar met pulse?

[H143]

H143 schreef op vrijdag 3 oktober 2025 @ 22:01:
sinds kort sluiten mijn containers automatisch af en starten vervolgens ook weer vanzelf
ik heb nog niet kunnen vinden wat het is helaas heb ik niet veel verstand van Linux
kan iemand mij opweg helpen waar dit probleem vandaan kan komen?
[Afbeelding]

Het lijkt nu opgelost beide lxc draaide docker in met elk hun eigen containers en heb ze gecreëerd uit een backup (backup was een lxc met alleen docker zonder conteiners)
Gister de lxc weer opnieuw opgebouwd en docker en de containers erin en het probleem is opgelost..

[Barryvdh]

Cardinal schreef op zaterdag 4 oktober 2025 @ 19:58:
@hansat heb je screenshots oid? is het vergelijkbaar met pulse?

De docs heeft voorbeelden; https://macrimi.github.io/ProxMenux/docs/introduction

Ziet er wel interessant uit, wellicht handig voor iGPU en NFS dingen ipv handmatig al die commando's.

[Harmen]

Iemand ervaringen met https://cloud-pbs.com/ ? M'n 'gratis' variant van Tuxis is vol, betaalde variant is helaas 19 euro per 1TB. Helaas is er geen kleinere variant, heb genoeg aan 300GB oid.

[Quad]

Voldoet Hetzner storagebox voor je eventueel?

[The-Source]

Harmen schreef op dinsdag 7 oktober 2025 @ 14:05:
Iemand ervaringen met https://cloud-pbs.com/ ? M'n 'gratis' variant van Tuxis is vol, betaalde variant is helaas 19 euro per 1TB. Helaas is er geen kleinere variant, heb genoeg aan 300GB oid.

Als je dedicated kiest klopt dat. Maar shared is per 250GB €6, te schalen tot 1TB €12,- beide ex BTW per maand.

[Quad]

Wat heeft jullie voorkeur om als virtueel NAS OS te draaien icm enkele fysieke harddrives in passtrough?
Ik heb OMV en TrueNAS met elkaar nu getest. TrueNAS leunt ernstig zwaar op je CPU/RAM door ZFS. OMV heeft ZFS niet native ingebakken (wel via extensies).
Performance met ZFS lijkt ook snel in te kakken met interne transfers tussen VM <> NAS OS. Het liefst zie ik iets als btrfs wat Synology toepast.

Ik wil graag mijn Synology uitfaseren en dus overstappen op storage binnen de server. Dit zal hogere prestaties leveren doordat de onderlinge verbinding gewoon hoger ligt dan de 1Gb via PVE - switch - NAS en weer terug.

[_JGC_]

@Quad Is maar net wat je precies wilt. Je kunt de raw disks doorzetten naar de VM en alles vanuit je VM managen, moet je wel CPUs en geheugen hebben om ZFS of btrfs te kunnen doen.
Je kunt ook Proxmox het hele ZFS gebeuren laten afhandelen en dan een virtuele disk sharen naar de NAS VM. Persoonlijk denk ik dat dit de betere oplossing is.

[orvintax]

Quad schreef op woensdag 8 oktober 2025 @ 11:59:
Wat heeft jullie voorkeur om als virtueel NAS OS te draaien icm enkele fysieke harddrives in passtrough?
Ik heb OMV en TrueNAS met elkaar nu getest. TrueNAS leunt ernstig zwaar op je CPU/RAM door ZFS. OMV heeft ZFS niet native ingebakken (wel via extensies).
Performance met ZFS lijkt ook snel in te kakken met interne transfers tussen VM <> NAS OS. Het liefst zie ik iets als btrfs wat Synology toepast.

Ik wil graag mijn Synology uitfaseren en dus overstappen op storage binnen de server. Dit zal hogere prestaties leveren doordat de onderlinge verbinding gewoon hoger ligt dan de 1Gb via PVE - switch - NAS en weer terug.

Ik gebruik zelf TrueNAS. CPU gebruik kan ik me niet in vinden, dat is altijd erg laag bij mij. Maar qua RAM pakt ZFS wat die pakken kan. Belangrijke nuance is dus dat het niet wil zeggen dat ZFS zoveel RAM ook nodig heeft.

Hoe maak je de transfer tussen VM en NAS OS?

[Quad]

_JGC_ schreef op woensdag 8 oktober 2025 @ 12:23:
@Quad Is maar net wat je precies wilt. Je kunt de raw disks doorzetten naar de VM en alles vanuit je VM managen, moet je wel CPUs en geheugen hebben om ZFS of btrfs te kunnen doen.
Je kunt ook Proxmox het hele ZFS gebeuren laten afhandelen en dan een virtuele disk sharen naar de NAS VM. Persoonlijk denk ik dat dit de betere oplossing is.

En @orvintax
Ik ga dat met PVE op ZFS ook nog wel even bekijken. Dat kan pas als ik de harde schijven zelf binnen heb.
Huidige NAS heeft 2x 18TB, dat wordt dan vervangen door 3x 6/8 TB (even afhankelijk wat nu nodig is).

*arr stack, SABNzb, Plex(en Jellyfin), PBS, Immich maken er dan gebruik van. Verbinding via SMB/CIFS of NFS.
Geheugenupgrade gaat vandaag binnenkomen, dan krijgt de server 64GB om te verbruiken. Ik zou dan evt de TrueNAS instantie 16GB toe kunnen kennen.

Bij gebruik van 3 HDDs kan ik een SATA SSD nog gebruiken om in te zetten als cache binnen OMV.

Performance met OMV op een RAID5 array met btrfs lijkt sneller te zijn vooralsnog. Het kakt vooral niet in.
Dit is op een test VM met 4 virtuele disks gekoppeld.

[_JGC_]

Ik zou zelf gewoon voor ZFS mirror gaan ipv RAIDZ1 of RAID5 met 3 disks. Minder stroomverbruik, snellere writes en net als bij RAIDZ1 of RAID5 1 disk redundancy.

Ja je recovery tijden zijn langer omdat je disk groter is, maar 8TB duurt sowieso ook al een hele tijd, je moet gewoon backups hebben voor het geval er 2 disks sterven.

[RobertMe]

Het ligt natuurlijk ook aan de gevraagde netto capaciteit. Als de vraag nu ~20TB is is een mirror van 2 disks van de gewenste capaciteit voldoende. Als je meer nodig hebt wordt het lastig (in combi met prijs)

Ik loop er nu ook tegenaan dat ik met een 3-way RAIDZ1 steeds de maximale capaciteit moet kopen . Begonnen met 3x 8TB 5 jaar terug. Eerst een door 14 vervangen vroegtijdig, toen een door 18 vroegtijdig. Vervolgens was ik door de capaciteit heen (effectief toen nog steeds op basis van de resterende 8TB dus 16TB netto) en een 20TB "moeten" kopen wat maar een vrij kleine sprong is vanaf de 18TB (gaat tzt maar 4 TB netto opleveren. Nu was het dan wel kleinste van 8 naar 14 is 6TB erbij en dus 12TB in netto totaal). Vervolgens is eerder dit jaar de 14TB gesneuveld (start uberhaupt niet meer met draaien en wordt ook niet herkent) en toen wel maar voor 24TB gegaan. Maar nu is de rek er ook aardig uit. Grotere modellen zijn IIRC nog veel onbetaalbaarder. Maar dit is wel de enige / goedkoooste optie als je niet voldoende hebt aan zeg ~24TB netto.

Of je moet al over stappen naar een stripe van mirrors. Dan kun je elke keer 2 disks (in mirror) aan de stripe toevoegen. En zo semi oneindig uitbreiden. Maar kost wel elke keer 2 disks extra.

Ja, ik weet dat je RAIDZ tegenwoordig ook kunt expanden met extra schijven. Maar dat voelt nogal hackish. Alhoewel die feature volgens mij ook al een jaar of 2 aanwezig is en dus wel al weer redelijk battle tested zal zijn.

[Quad]

Ik heb nu dus een mirror van 18TB, dat is naar verwachting ruim voldoende (heb nu 9TB vrij).
Heb op de server de mogelijkheid tot maximaal 4 SATA HDD/SSDs, de PCIe zal worden gebruikt door een GPU en de 2 NVMe sloten door de SSDs voor de VMs.

De mogelijkheid voor een RAID5 (of ZRAID1) is om later nog uit te breiden met een disk door nu 3 te kiezen. Het hoeft geen state-of-the-art setup te zijn uiteindelijk, als het maar sneller is dan de huidige setup (en dat is het waarschijnlijk al wel snel).

Al die NAS OS's zijn erop gericht dat er meer services zijn om te draaien, dat is voor mij niet van belang natuurlijk. Ik wil voornamelijk dataopslag bieden aan de services die los in LXCs draaien op de Proxmox host.

In dat geval kan ik denk ik beter inderdaad Proxmox de ZFS afhandeling laten doen, dan zit er ook geen extra laag tussen.

[DjoeC]

Even over RAID1/5/6: ALS er een probleem of onverwachte shutdown is zijn de recovery tijden lang. Mijn 8TB WD-reds (RAID1) moeten ongeveer een dag draaien om te resyncen. Raid-5 raad ik niemand meer aan omdat het risico op uitval van een 2e schijf erg groot is. Dan kom je dus op RAID6 uit (2x parity) waarmee het risico een stuk minder wordt. O ja, en een 2TB RAID-6 schijf herstellen liep ooit bij mij 3-4 dagen.....

Voor prive draai ik nu nog RAID1 (2 sets van 2x 8TB) maar ik ga binnenkort terug naar enkelvoudige opslag met automatisch folder sync - ofwel onmiddellijk via folder monitoring, ofwel dagelijks. Eerstvolgende nieuwe disks zullen 24TB of groter worden, resyncen onder RAID zou dan nog veeel langer gaan duren. Denk na over use-cases en risico's. RAID(achtig) klinkt leuk maar zorg dat je er niet van afhankelijk wordt -> Backups.....

Bovenstaande geldt (in mijn geval) voor Windows maar de concepten achter RAID zijn natuurlijk OS onafhankelijk.

[RobertMe]

DjoeC schreef op woensdag 8 oktober 2025 @ 17:31:
Even over RAID1/5/6: ALS er een probleem of onverwachte shutdown is zijn de recovery tijden lang. Mijn 8TB WD-reds (RAID1) moeten ongeveer een dag draaien om te resyncen. Raid-5 raad ik niemand meer aan omdat het risico op uitval van een 2e schijf erg groot is.

Ik heb dus al meerdere keren een disk vervangen, maar dan wel op 1x na altijd met de originele er nog in. En zelfs toen ik dan paar maanden terug daadwerkelijk een kapotte disk had en er max 14TB opnieuw gedaan moest worden (als in: 14TB disk was de kleinste) duurde die hele resilver volgens mij maar om en nabij een dag, zeg 1,5 dag max. Dus mijn N=4 ervaring tot nu toe toont aan dat de kans op uitval tijdens een resilver minder dan 25% is. Uiteraard nog steeds een hoog percentage, maar misschien kan ik nog wel 10x een disk vervangen zonder uitval, en blijft het percentage dus zakken. En max 1,5e dag voor ergens tussen de 8 en 14 TB te rebuilden/resilveren vind ik ook nog wel meevallen.

Bovenstaande geldt (in mijn geval) voor Windows maar de concepten achter RAID zijn natuurlijk OS onafhankelijk.

Ja en nee. ZFS is toch wel iets anders dan "RAID". Aangezien ZFS zowel een volume manager als filesystem is. Geen idee hoe dat overigens bij Windows Storage Spaces(?) zit, of je daarop nog steeds NTFS (/fs naar keuze) draait of dat dat ook zowel een filesystem als volume manager is.

Dingen die ZFS AFAIK ook afwijkend kan doen (sinds een jaar of 2, 3 pas) is sequentieel met de data om gaan. Dus in ieder geval bij een replace waar de originele disk er nog in zit sequentieel de oude disk lezen en naar de nieuwe over zetten. Incl. alle "filesystem" checks dan (checksumming etc) die netjes worden toegepast, dus het is niet letterlijk "lees X MB van de oude schijf in en schrijf die 1 op 1 naar de nieuwe schijf", er zit nog steeds "logica" achter in wat die het doet incl. controle of de oude data "correct" is. En ook het scrubben kan al verschillende jaren sequentieel. Bij mijn weten zijn dat toch zaken die traditionele RAID (/alleen de volume manager) niet kunnen omdat die geen weet hebben van de data/....

[Quad]

Backups is voor mij het punt niet. Dat is nu en dat wordt wel geregeld.
Voor mij is RAID een redundantie waarbij de boel blijft draaien en bruikbaar blijft terwijl ondertussen een drive vervangen wordt waarna de rebuild bezig kan. En of dat 8 uur of 48 uur duurt is niet zo spannend voor thuis.

Ik ben puur op zoek naar een mogelijkheid voor de laagste resourceverbruik in combinatie met voldoende opslag en prestaties.

En dat gevoel heb ik bij TrueNAS bij lange na niet op dit moment.

[orvintax]

Quad schreef op woensdag 8 oktober 2025 @ 13:16:
[...]

En @orvintax
Ik ga dat met PVE op ZFS ook nog wel even bekijken. Dat kan pas als ik de harde schijven zelf binnen heb.
Huidige NAS heeft 2x 18TB, dat wordt dan vervangen door 3x 6/8 TB (even afhankelijk wat nu nodig is).

*arr stack, SABNzb, Plex(en Jellyfin), PBS, Immich maken er dan gebruik van. Verbinding via SMB/CIFS of NFS.
Geheugenupgrade gaat vandaag binnenkomen, dan krijgt de server 64GB om te verbruiken. Ik zou dan evt de TrueNAS instantie 16GB toe kunnen kennen.

Bij gebruik van 3 HDDs kan ik een SATA SSD nog gebruiken om in te zetten als cache binnen OMV.

Performance met OMV op een RAID5 array met btrfs lijkt sneller te zijn vooralsnog. Het kakt vooral niet in.
Dit is op een test VM met 4 virtuele disks gekoppeld.

Wat ik wel een vervelend nadeel vind aan de Proxmox ZFS route is dat je gaat moeten werken met virtuele disks. Ik ben bewust voor een Truenas VM gegaan zodat mijn hele HDD pool dynamisch beschikbaar is. Het is gewoon een filesystem waar je tegen praat. Ik hoef dus mijn pool niet te gaan segmenteren.

Als je trouwens op 1 node draait is de overhead minimaal. Vanwege VirtIO gaat dat allemaal lokaal waardoor in mijn geval de disks gewoon de bottleneck blijven.

[orvintax]

Quad schreef op woensdag 8 oktober 2025 @ 17:19:
Ik heb nu dus een mirror van 18TB, dat is naar verwachting ruim voldoende (heb nu 9TB vrij).
Heb op de server de mogelijkheid tot maximaal 4 SATA HDD/SSDs, de PCIe zal worden gebruikt door een GPU en de 2 NVMe sloten door de SSDs voor de VMs.

De mogelijkheid voor een RAID5 (of ZRAID1) is om later nog uit te breiden met een disk door nu 3 te kiezen. Het hoeft geen state-of-the-art setup te zijn uiteindelijk, als het maar sneller is dan de huidige setup (en dat is het waarschijnlijk al wel snel).

Al die NAS OS's zijn erop gericht dat er meer services zijn om te draaien, dat is voor mij niet van belang natuurlijk. Ik wil voornamelijk dataopslag bieden aan de services die los in LXCs draaien op de Proxmox host.

In dat geval kan ik denk ik beter inderdaad Proxmox de ZFS afhandeling laten doen, dan zit er ook geen extra laag tussen.

Heb je die drie disks al? Mij lijkt het persoonlijk logischer om eerst die twee (die je zeker al hebt) in te zitten als mirror. Daar heb je voorlopig in je eigen woorden genoeg aan. Je kunt dan later altijd nog twee nieuwe toevoegen als extra vdev.

Het voordeel hiervan is dat je nu dan nog niet hoeft te gaan anticiperen op later. Als je nu er een extra van 18TB gaat kopen, dan moet je er later als je wilt uitbreiden ook zo een bijzetten. Door het voor nu te houden bij een mirror, kun je straks bijvoorbeeld ook 2x 24TB toevoegen.

Het andere voordeel is ook dat je met een stripe + mirror meer IOPS krijgt, terwijl met enkel de stripe je meer throughput krijgt. En dat eerste lijkt me wenselijker voor een HDD setup.

[orvintax]

Quad schreef op woensdag 8 oktober 2025 @ 18:45:
En dat gevoel heb ik bij TrueNAS bij lange na niet op dit moment.

Ben wel benieuwd waar dat vandaan komt. TrueNAS is Debian + OpenZFS met een sausje erover. Je kunt ook services uitzetten die je niet gebruikt om het efficienter te maken.

[RobertMe]

orvintax schreef op woensdag 8 oktober 2025 @ 20:18:
[...]

Ben wel benieuwd waar dat vandaan komt. TrueNAS is Debian + OpenZFS met een sausje erover. Je kunt ook services uitzetten die je niet gebruikt om het efficienter te maken.

TrueNAS is toch BSD (FreeBSD, waar ook OpenZFS in zit)? Debian based is TrueNAS Scale bij mijn weten? (En "scale" is niet benoemd geworden tot nu toe)

[orvintax]

RobertMe schreef op woensdag 8 oktober 2025 @ 20:23:
[...]

TrueNAS is toch BSD (FreeBSD, waar ook OpenZFS in zit)? Debian based is TrueNAS Scale bij mijn weten? (En "scale" is niet benoemd geworden tot nu toe)

Je hebt in princiepe gelijk. Alleen is de BSD versie tegenwoordig TrueNAS Legacy/ TrueNAS CORE. TrueNAS Scale noemen ze nu ook TrueNAS CE. Ze gaan CORE versie uitfaseren dus tegenwoordig is Scale de normale.

[Quad]

orvintax schreef op woensdag 8 oktober 2025 @ 20:12:
[...]

Wat ik wel een vervelend nadeel vind aan de Proxmox ZFS route is dat je gaat moeten werken met virtuele disks. Ik ben bewust voor een Truenas VM gegaan zodat mijn hele HDD pool dynamisch beschikbaar is. Het is gewoon een filesystem waar je tegen praat. Ik hoef dus mijn pool niet te gaan segmenteren.

Als je trouwens op 1 node draait is de overhead minimaal. Vanwege VirtIO gaat dat allemaal lokaal waardoor in mijn geval de disks gewoon de bottleneck blijven.

Ja dat bedacht ik mij net ook, je hebt alsnog iets nodig waar je SMB/cifs en NFS service op regelt met de authenticatie. Dus dat lijkt alsnog af te vallen.

orvintax schreef op woensdag 8 oktober 2025 @ 20:17:
[...]

Heb je die drie disks al? Mij lijkt het persoonlijk logischer om eerst die twee (die je zeker al hebt) in te zitten als mirror. Daar heb je voorlopig in je eigen woorden genoeg aan. Je kunt dan later altijd nog twee nieuwe toevoegen als extra vdev.

Het voordeel hiervan is dat je nu dan nog niet hoeft te gaan anticiperen op later. Als je nu er een extra van 18TB gaat kopen, dan moet je er later als je wilt uitbreiden ook zo een bijzetten. Door het voor nu te houden bij een mirror, kun je straks bijvoorbeeld ook 2x 24TB toevoegen.

Het andere voordeel is ook dat je met een stripe + mirror meer IOPS krijgt, terwijl met enkel de stripe je meer throughput krijgt. En dat eerste lijkt me wenselijker voor een HDD setup.

Ik heb nu in de Synology 2x MG09 18TB zitten. Die wil ik samen met de Synology weg doen..

• Het geluid van de schijven is echt heftig, alsof er constant een koffieapparaat staat te pruttelen. Tevens lijkt mijn vrouw dit 's nachts te horen.
• 1Gb netwerksnelheid updown is dan max 500Mbps met acties als SabNZB.

Ik zit dus te azen op een nieuwe setup van 3x 6TB of 3x 8TB met 1 disk in parity voor redundancy. Ik begrijp dat zoiets langzamer kan zijn maar ik verwacht dat de snelheid hoger ligt dan 1Gb als de data vanuit het VirtIO netwerk wordt aangesproken of wordt geschreven.

orvintax schreef op woensdag 8 oktober 2025 @ 20:18:
[...]

Ben wel benieuwd waar dat vandaan komt. TrueNAS is Debian + OpenZFS met een sausje erover. Je kunt ook services uitzetten die je niet gebruikt om het efficienter te maken.

Het is weliswaar wel gebaseerd op een test van ca 30 minuten klikken, kijken en een testsetup opbouwen met 3x een virtuele disk vanaf een SATA SSD. Ik zie net echter dat TrueNAS Connect heeft aangekondigd, dit maakt het ook wel weer interessant.
Ik ga het eerst maar eens uitwerken en uitzoeken en dan een beslissing maken, geen haast.

Mijn PVE is voor nu voorzien van een nieuwe behuizing en een memory upgrade naar 64GB.

[dcm360]

In het geval van LXC kan je eenzelfde dataset ook delen doormiddel van bind mounts, en voor KVM heb je tegenwoordig VirtioFS (maar dat heb ik zelf nog nooit gebruikt). Op die manier kan je voorkomen dat je intern op de server de storage alsnog met netwerkprotocollen aan elkaar moet knopen.

[stormfly]

Quad schreef op woensdag 8 oktober 2025 @ 22:53:
[...]

Ik heb nu in de Synology 2x MG09 18TB zitten. Die wil ik samen met de Synology weg doen..

• Het geluid van de schijven is echt heftig, alsof er constant een koffieapparaat staat te pruttelen. Tevens lijkt mijn vrouw dit 's nachts te horen.
• 1Gb netwerksnelheid updown is dan max 500Mbps met acties als SabNZB.

Misschien niet helemaal relevant maar deel het toch, ik ben zelf begonnen met het afbouwen van Synology vanwege hun achterblijven de hardware specs en de opmerkelijke stap tot het boycotten van bepaalde disken.

De TerraMaster F4 SSD is als aanvulling gekomen, 4x NVMe NAS en een 5Gbps port, ideaal voor VM's over NFS. Qua software is DSM het ultieme product, daar komt TerraMaster niet in de buurt. Bijkomend voordeel meer ruimte over in meterkast, minder stroom verbruik (11watt 4x NVMe) en geen gepruttel meer. En een enorme performance vanuit de N95 CPU. 2TB NVMe is nu betaalbaar aan het worden dus je moet misschien wel iets anders nadenken over je storage verdeling. Mijn DS1019+ draait nog als backup server voor wat taken en gaat zeker niet weg, staat alleen op zondag aan als de backups lopen.

[orvintax]

dcm360 schreef op woensdag 8 oktober 2025 @ 23:09:
In het geval van LXC kan je eenzelfde dataset ook delen doormiddel van bind mounts, en voor KVM heb je tegenwoordig VirtioFS (maar dat heb ik zelf nog nooit gebruikt). Op die manier kan je voorkomen dat je intern op de server de storage alsnog met netwerkprotocollen aan elkaar moet knopen.

Bindmounts zijn ook nog een goeie ja Ik ben wel benieuwd of iemand hier al ervaring heeft met VirtioFS? Het is wel een FUSE filesystem dus dat is wel nadelig voor de snelheid. Ik vraag me dan af wat sneller zou zijn NFS over een VirtIO netwerk of FUSE.

[Quad]

dcm360 schreef op woensdag 8 oktober 2025 @ 23:09:
In het geval van LXC kan je eenzelfde dataset ook delen doormiddel van bind mounts, en voor KVM heb je tegenwoordig VirtioFS (maar dat heb ik zelf nog nooit gebruikt). Op die manier kan je voorkomen dat je intern op de server de storage alsnog met netwerkprotocollen aan elkaar moet knopen.

Bindmounts werk ik nu ook al mee voor de LXC's. De PVE servers verzorgen de koppeling naar de NAS toe.
Ik had zelf bedacht dat dit zo ongeveer wel blijft bestaan, anders moet ik elke container die hier gebruik van maakt langs gaan en de mounts aanpassen.

stormfly schreef op donderdag 9 oktober 2025 @ 08:09:
[...]


Misschien niet helemaal relevant maar deel het toch, ik ben zelf begonnen met het afbouwen van Synology vanwege hun achterblijven de hardware specs en de opmerkelijke stap tot het boycotten van bepaalde disken.

De TerraMaster F4 SSD is als aanvulling gekomen, 4x NVMe NAS en een 5Gbps port, ideaal voor VM's over NFS. Qua software is DSM het ultieme product, daar komt TerraMaster niet in de buurt. Bijkomend voordeel meer ruimte over in meterkast, minder stroom verbruik (11watt 4x NVMe) en geen gepruttel meer. En een enorme performance vanuit de N95 CPU. 2TB NVMe is nu betaalbaar aan het worden dus je moet misschien wel iets anders nadenken over je storage verdeling. Mijn DS1019+ draait nog als backup server voor wat taken en gaat zeker niet weg, staat alleen op zondag aan als de backups lopen.

Hm ja mooi apparaatje. Maar voor mijn huidige setup geen optie verwacht ik. Ik heb nu (en straks) 2x NVMe SSDs voor de boot en voor de VMs/LXCs draaien. Backups van PVE/ M365 en overige data (Plex/fotos enz) gaan naar de NAS opslag. De belangrijkste data (foto's/M365) wordt weer weggezet bij Hetzner. Gevoelsmatig heb ik het wel goed voor elkaar en is het doel om van 3 naar 1 machine te gaan goed te realiseren.
Alleen de juiste keuze voor het OS van de NAS binnen een VM op PVE is iets waar ik goed naar moet kijken.

Ik ga dat weer oppakken zodra de keuze voor schijven zijn gemaakt en deze binnen zijn. Het blijft uiteindelijk maar een thuismachine.

[ComTech]

Is er ook een manier om te zorgen dat één LXC of VM je hele systeem niet kan platleggen?
Ik was daar straks wat aan het testen met een LXC en ik had die wat weinig ram gegeven en daardoor was mijn hele proxmox host niet meer te bereiken.
Uiteindelijk de host kunnen rebooten maar handig is dat niet natuurlijk.

[FrankHe]

ComTech schreef op donderdag 9 oktober 2025 @ 23:23:
Is er ook een manier om te zorgen dat één LXC of VM je hele systeem niet kan platleggen?
Ik was daar straks wat aan het testen met een LXC en ik had die wat weinig ram gegeven en daardoor was mijn hele proxmox host niet meer te bereiken.
Uiteindelijk de host kunnen rebooten maar handig is dat niet natuurlijk.

Wat er vermoedelijk aan de hand was is dat die LXC vanwege geheugengebrek als een gek is gaan swappen naar HDD/SSD waardoor je storage onvoldoende I/O beschikbaar had om aan andere dingen toe te komen? Dat is althans mijn eerste indruk wanneer ik je verhaal lees.

Bij een Virtual Machine kun je onder 'Hardware' bij een HDD aangeven of er sprake moet zijn van een bandbreedtebeperking. Megabyte per seconde dan wel operations per seconde.


Voor zover ik kan nagaan is dit bij een LXC niet als zodanig mogelijk?

Wanneer het probleem niet de disk I/O's is dan is het ook goed mogelijk dat het host OS / PVE ergens op vastloopt. Een LXC is immers geen VM maar een container, die is meer geïntegreerd met het host OS en kent daardoor minder isolatie dan een daadwerkelijke VM. Ik vind het lastig te zeggen hoe ver dit uit de hand kan lopen.

[FrankHe]

FrankHe schreef op woensdag 15 oktober 2025 @ 14:48:
[...]

Wat er vermoedelijk aan de hand was is dat die LXC vanwege geheugengebrek als een gek is gaan swappen naar HDD/SSD waardoor je storage onvoldoende I/O beschikbaar had om aan andere dingen toe te komen? Dat is althans mijn eerste indruk wanneer ik je verhaal lees.

Bij een Virtual Machine kun je onder 'Hardware' bij een HDD aangeven of er sprake moet zijn van een bandbreedtebeperking. Megabyte per seconde dan wel operations per seconde.
[Afbeelding]

Voor zover ik kan nagaan is dit bij een LXC niet als zodanig mogelijk?

Wanneer het probleem niet de disk I/O's is dan is het ook goed mogelijk dat het host OS / PVE ergens op vastloopt. Een LXC is immers geen VM maar een container, die is meer geïntegreerd met het host OS en kent daardoor minder isolatie dan een daadwerkelijke VM. Ik vind het lastig te zeggen hoe ver dit uit de hand kan lopen.

Een aanvulling op het voorgaande. Lukte het uiteindelijk om Proxmox VE via de webinterface te benaderen? Heb je toevallig (ook) via SSH geprobeerd PVE te benaderen? Als er ook via SSH geen doorkomen aan is dan is het inderdaad flink mis.

[Quad]

Quad schreef op woensdag 8 oktober 2025 @ 11:59:
Wat heeft jullie voorkeur om als virtueel NAS OS te draaien icm enkele fysieke harddrives in passtrough?
Ik heb OMV en TrueNAS met elkaar nu getest. TrueNAS leunt ernstig zwaar op je CPU/RAM door ZFS. OMV heeft ZFS niet native ingebakken (wel via extensies).
Performance met ZFS lijkt ook snel in te kakken met interne transfers tussen VM <> NAS OS. Het liefst zie ik iets als btrfs wat Synology toepast.

Ik wil graag mijn Synology uitfaseren en dus overstappen op storage binnen de server. Dit zal hogere prestaties leveren doordat de onderlinge verbinding gewoon hoger ligt dan de 1Gb via PVE - switch - NAS en weer terug.

Even terugkomend op bovenstaand;
Ik heb inmiddels TrueNAS gekozen. 4 cores 16GB RAM, 64GB bootdisk (wordt gebackupt) en 128GB als cache disk vanaf mn NVMe SSD voor ZFS. De SATA controller is doorgelusd met passtrough waardoor ik 3x 8TB WD Red Plus WD80EFPX in de TrueNAS VM heb.
Gekozen voor ZFS RAID met 1 disk als parity en 128GB vDISK als cache SSD. De schijven kon ik via via nieuw voor 160 euro krijgen waardoor het een nobrainer was.

Om onderling snellere en directe verbindingen te hebben heeft de TrueNAS VM een 2e netwerkadapter gekregen die, via een interne bridge, aan de host gekoppeld wordt en met mountpoints de LXCs bedient.
Het gevolg is dat bijvoorbeeld SabNZB download via zn netwerkpoort en de data kan uitpakken via de mountpoint op de PVE host met maximale snelheid door die interne bridge.

Nu kan direct unpack ook aan, eerst zorgde dat voor een halvering van de downloadsnelheid.


Maar goed, alles gaat sneller, het laden van video binnen Plex gaat rapper en Proxmox Backup heeft hogere schrijfsnelheden. Tot nu toe niet ontevreden over mijn keuze.

Voor de rest is mijn energieverbruik met ca 15W toegenomen, wat geheel volgens de verwachting is. De NAS consumeert ongeveer hetzelfde met 2 drives a 18TB. Deze is nu afgeschakeld en en gaat de deur uit.

Een goed alternatief om mijn M365 te backuppen ipv via Synology NAS heb ik nog niet gevonden. Het alternatief wat ik daarvoor bedacht heb en werkt is een iSCSI disk van TrueNAS naar de PVE host, deze is dan gekoppeld aan een xpenology VM die elke dag een kwartiertje draait, de backup van de omgeving maakt en de boel weer afsluit. Notificaties gaan naar Home Assistant via webhooks waarop ik ook monitor op leeftijd van de notificaties.
Houwtjetouwtje oplossing, maar het werkt tot ik een goed alternatief heb.

De komende week komt een CPU upgrade binnen en dan gaan we BF in de gaten houden voor een GPU. Verder verdient mijn PVE host nog finetuning ivm start- afsluitvolgordes enz.

Al met al niet ontevreden en dank voor de tips.

[_eLMo_]

Ik heb een nieuwe NAS gekocht en was van plan deze in te richten met Unraid, maar daar kom ik een beetje van terug. Alle "mooie" dingen die daar inzitten zijn vooral halve abstracties, die me meer in de weg gingen zitten (VLAN's bv) dan hielpen.

Mijn huidige use cases:
- Home Assistant - VM
- Minecraft game server - LXC
- ARR Stack + Jellyfin - LXC / Docker?
- PiHole - LXC
- SeaFile - LXC / Docker?
- Immich - LXC / Docker?

Mijn huidige NUC draait Proxmox VE, en daar ben ik erg tevreden over, dus ik wil mijn nieuwe NAS hier ook op gaan baseren.
Dan moet ik alleen beslissen wat ik ga doen met de disk array (3x 20TB). Ik vond het aan Unraid wel cool dat ze XFS gebruikten met parity disk. Ik vind ZFS zelf overkill en teveel overhead, daarnaast is het slecht uitbreidbaar (ik heb 8 bays, waarvan dus nog 5 beschikbaar). Stroomverbruik vind ik minder belangrijk dan lange levensduur van de HDD's.

Iemand hier ervaring met zoiets inrichting op Proxmox? Kan je zoiets als XFS gebruiken maar wel 1 volume krijgen? Cronjob opzetten om spul te moven van de M.2 SSD naar de array kan ik zelf wel bakken, maar als er al iets is....

Of gewoon Unraid in een LXC proppen, SATA controllers VT-d'en en alleen de Disk Array kant gebruiken en mounten/beschikbaar maken naar Proxmox?
Toch inbinden en ZFS? En dan de SSD alleen in een losse ZFS pool?

[ Voor 14% gewijzigd door _eLMo_ op 21-10-2025 14:19 ]

[RobertMe]

_eLMo_ schreef op dinsdag 21 oktober 2025 @ 14:00:
k vind ZFS zelf overkill en teveel overhead, daarnaast is het slecht uitbreidbaar (ik heb 8 bays, waarvan dus nog 5 beschikbaar).

ZFS ondersteund al een aantal versies RAIDZ expansion. Dus van die 3 disks in RAIDZ1 (neem ik aan) kun je ook naar 4 disks of 5 disks, bij mijn weten.

Daarnaast is hoe ik het lees RAIDZ / RAID5/6 sowieso een beetje passé? En kun je beter een stripped mirror (/RAID10) gebruiken. Dus steeds 2 disks in een mirror plaatsen en die mirrors met een stripe samenvoegen. Bij grotere sets geeft dat een veel betere bescherming (als je bv 5 mirrors van 2 disks hebt, dus 10 disks in totaal, mag bij de uitval van 1 disk er van de 9 overblijvende disks er 8 verschillende uitvallen zonder dat er data loss optreed, de enige die niet mag uitvallen is dus de disk in dezelfde mirror (en na uitval van een ander uiteraard ook niet de ander in die mirror). Van de 10 mogen er dus "de juiste 5" allemaal tegelijkertijd stuk zijn. Zou je RAIDZ1 hebben met 10 disks dan mogen na de uitval van 1 disk er nog maar 0 uitvallen of je bent de data kwijt). En de performance van een striped mirror is ook beter. En je kunt meer mixen en matchen (bij RAIDZ telt de capaciteit van de kleinste disk voor de totale capaciteit (kleinste disk * (aantal - aantal parity)). Bij striped mirror maakt de grote van de vdevs in de stripe niet uit, alleen de kleinste disk in de mirror bepaald de grote van de mirror vdev. Maar 2x 10 in een mirror + 2x 20 in een mirror levert netto 30TB op, bij RAIDZ1 is dat ook 30, maar wel lastiger uitbreiden).

Note: ik draai zelf al ~5 jaar RAIDZ1, en heb nog altijd disks vervangen om de capaciteit te vergroten, en geen expansion met een extra disk gedaan. Zou ik de pool opnieuw opzetten zou ik eerder een striped mirror nemen waarschijnlijk (en de 8TBs die nu ongebruikt zijn want te klein gewoon gebruiken).

[_eLMo_]

RobertMe schreef op dinsdag 21 oktober 2025 @ 14:20:
[...]

ZFS ondersteund al een aantal versies RAIDZ expansion. Dus van die 3 disks in RAIDZ1 (neem ik aan) kun je ook naar 4 disks of 5 disks, bij mijn weten.

Daarnaast is hoe ik het lees RAIDZ / RAID5/6 sowieso een beetje passé? En kun je beter een stripped mirror (/RAID10) gebruiken. Dus steeds 2 disks in een mirror plaatsen en die mirrors met een stripe samenvoegen. Bij grotere sets geeft dat een veel betere bescherming (als je bv 5 mirrors van 2 disks hebt, dus 10 disks in totaal, mag bij de uitval van 1 disk er van de 9 overblijvende disks er 8 verschillende uitvallen zonder dat er data loss optreed, de enige die niet mag uitvallen is dus de disk in dezelfde mirror (en na uitval van een ander uiteraard ook niet de ander in die mirror). Van de 10 mogen er dus "de juiste 5" allemaal tegelijkertijd stuk zijn. Zou je RAIDZ1 hebben met 10 disks dan mogen na de uitval van 1 disk er nog maar 0 uitvallen of je bent de data kwijt). En de performance van een striped mirror is ook beter. En je kunt meer mixen en matchen (bij RAIDZ telt de capaciteit van de kleinste disk voor de totale capaciteit (kleinste disk * (aantal - aantal parity)). Bij striped mirror maakt de grote van de vdevs in de stripe niet uit, alleen de kleinste disk in de mirror bepaald de grote van de mirror vdev. Maar 2x 10 in een mirror + 2x 20 in een mirror levert netto 30TB op, bij RAIDZ1 is dat ook 30, maar wel lastiger uitbreiden).

Note: ik draai zelf al ~5 jaar RAIDZ1, en heb nog altijd disks vervangen om de capaciteit te vergroten, en geen expansion met een extra disk gedaan. Zou ik de pool opnieuw opzetten zou ik eerder een striped mirror nemen waarschijnlijk (en de 8TBs die nu ongebruikt zijn want te klein gewoon gebruiken).

Dankjewel voor je antwoord. De reden dat ik zei dat uitbreidbaarheid slecht is, is tweeledig. Enerzijds kan je niet van RAIDZ1 naar RAIDZ2, dat is een destructieve operatie. Anderzijds kan je nu een schijf toevoegen aan je UDEV (van dezelfde grootte idd), maar wordt de data niet opnieuw gebalanceerd, dus is het qua protectie niet optimaal zonder al je data opnieuw weg te schrijven?
Gezien ik 20TB disks gebruik, is er een veel grotere kans op een tweede failure (bij het herstellen van de array), dus is dat minder aantrekkelijk dan wat Unraid doet.

Als ik naar Striped mirror wil, dan heb ik een extra disk nodig (€330), kost het meer energie, en to be fair: ik sla vooral licentie vrije films op, die ik opnieuw kan downloaden, dus ik heb geen rock solid betrouwbare NAS nodig, daarvoor heb ik ook backups op andere plekken.

De performance is wellicht wel interessant, en ook minder gedoe bij resilvering versus RAIDZ1, en je kan disks verwijderen (niet bij RAIDZ1). Ik zal er eens over nadenken.

- Edit: ik heb een 4e disk besteld, Striped Mirror it is

[XiMMiX]

_eLMo_ schreef op dinsdag 21 oktober 2025 @ 14:00:
Dan moet ik alleen beslissen wat ik ga doen met de disk array (3x 20TB). Ik vond het aan Unraid wel cool dat ze XFS gebruikten met parity disk. Ik vind ZFS zelf overkill en teveel overhead, daarnaast is het slecht uitbreidbaar (ik heb 8 bays, waarvan dus nog 5 beschikbaar). Stroomverbruik vind ik minder belangrijk dan lange levensduur van de HDD's.

Iemand hier ervaring met zoiets inrichting op Proxmox? Kan je zoiets als XFS gebruiken maar wel 1 volume krijgen? Cronjob opzetten om spul te moven van de M.2 SSD naar de array kan ik zelf wel bakken, maar als er al iets is....

XFS is puur een filesystem, en heeft dus geen weet van parity disk. De laatste keer dat ik naar unraid keek gebruikten ze linux' mdraid met een custom driver. Dus ze gebruiken mdraid om meerdere fysieke disks te combineren tot 1 array en op die array zet je dan een (XFS) filesystem. De unieke features van Unraid wat betreft het uitbreiden van een bestaande array zijn het gevolg van die custom driver.

Op zich is proxmox een extra schil bovenop linux, dus op zich kan je in proxmox ook mdraid gebruiken. Maar er zit in de proxmox GUI geen ondersteuning hiervoor. En de custom driver van Unraid is uiteraard niet beschikbaar. Op zich biedt standaard mdraid ook wel opties om een extra drive aan een bestaande array toe te voegen, maar wel beperkter dan Unraid. Binnen proxmox gui gebruik je vervolgens lvm boven op de mdraid array, je kan dan binnen de gui volumes aanmaken en die toewijzen aan VMs. Binnen de VM kies je dan het filesystem.
Er is dus een optie, maar vraagt wel veel hand werk buiten de Proxmox GUI om. En aangezien weinig andere mensen het zo doen zal je bij problemen het helemaal zelf moeten oplossen.

_eLMo_ schreef op dinsdag 21 oktober 2025 @ 14:00:
Of gewoon Unraid in een LXC proppen, SATA controllers VT-d'en en alleen de Disk Array kant gebruiken en mounten/beschikbaar maken naar Proxmox?
Toch inbinden en ZFS? En dan de SSD alleen in een losse ZFS pool?

Unraid in een LXC gaat niet, wel in een VM. Maar anders dan dat lijkt me het een werkende optie.

Ik heb zelf voor ZFS gekozen. Storage uitbreiden heb ik gedaan door mijn 6x6TB array disk voor disk te vervangen door een 6x18TB array. Maar nog een keer zo'n stap is moeilijker omdat het maximale formaat van HDDs minder hard groeit en de prijzen wel hard door blijven groeien.

[Airw0lf]

XiMMiX schreef op dinsdag 21 oktober 2025 @ 16:23:
[...]

Op zich is proxmox een extra schil bovenop linux, dus op zich kan je in proxmox ook mdraid gebruiken. Maar er zit in de proxmox GUI geen ondersteuning hiervoor. En de custom driver van Unraid is uiteraard niet beschikbaar. Op zich biedt standaard mdraid ook wel opties om een extra drive aan een bestaande array toe te voegen, maar wel beperkter dan Unraid. Binnen proxmox gui gebruik je vervolgens lvm boven op de mdraid array, je kan dan binnen de gui volumes aanmaken en die toewijzen aan VMs. Binnen de VM kies je dan het filesystem.
Er is dus een optie, maar vraagt wel veel hand werk buiten de Proxmox GUI om. En aangezien weinig andere mensen het zo doen zal je bij problemen het helemaal zelf moeten oplossen.

[...]

Ik heb voor deze variant gekozen en via mdadm een raid volume aangemaakt.
Vervolgens opgenomen in de Proxmox storage config.

De mdadm om het volume aan te maken:
mdadm --create /dev/md0 --level=0 --raid-devices=2 --chunk=128 /dev/sdb /dev/sdc
mdadm --detail /dev/md0
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
sudo update-initramfs -u

In mijn geval een raid-0 device met 2 SATA disken van elk 8-Tbytes: /dev/md0

Vervolgens met pvcreate en vgcreate een lvm volume aangemaakt:
pvcreate /dev/md0
vgcreate raid0-nas /dev/md0

Als laatste in /etc/pve/storage.cfg het volgende toegevoegd:
lvm: nas-volume
vgname raid0-nas
content images,rootdir

Verschijnt dan spontaan als nas-volume in de web-ui - een reboot is niet nodig.
Nu kan ie opgenomen worden in een VM of LXC container - ik heb het laatste gedaan via een mount point.
Binnen die container draaien o.a. Samba en Nextcloud - de laatste via een Docker container.

Ik gebruik geen passthrough modus en heb binnen de container een eigen Samba config aangemaakt:

[global]

# AD settings for member server
# realm tech.lan

# Remaining settings
server role = standalone server
workgroup = zion
logging = file
disable netbios = yes
smb ports = 445
map to guest = bad user
pam password change = yes
obey pam restrictions = yes
map system = yes
server string = %h server
log file = /var/log/samba/log.%m
max log size = 1000
security = user
unix password sync = yes
unix extensions = yes
wide links = no
passwd program = /usr/bin/passwd %u
usershare allow guests = no
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
panic action = /usr/share/samba/panic-action %d
server min protocol = SMB2
create mask = 775
directory mask = 2775
force create mode = 2775
force directory mode = 2775
force group = sambashare
valid users = @sambashare
writable = yes
server multi channel support = yes
aio read size = 1
aio write size = 1
bind interfaces only = yes
interfaces = eth*

#======================= Share Definitions =======================

# Un-comment the following (and tweak the other settings below to suit)
# to enable the default home directory shares. This will share each
# user's home directory as \\server\username

[homes]
path = /mnt/nas-volume/shares/homes/%U
browseable = yes
guest ok = no

[install]
path = /mnt/nas-volume/shares/install
browseable = yes
guest ok = no

[cz-images]
path = /mnt/nas-volume/shares/cz-images
browseable = yes
guest ok = no

[staging]
path = /mnt/nas-volume/shares/staging
browseable = yes
guest ok = no

[scans]
path = /mnt/nas-volume/shares/scans
browseable = yes
guest ok = no

[lyrion]
path = /mnt/nas-volume/lyrion
browseable = yes
guest ok = yes

[temp]
path = /mnt/nas-volume/shares/temp
browseable = yes
guest ok = yes

[backup]
path = /mnt/nas-volume/shares/backup
browseable = yes
guest ok = no

[ftp]
path = /mnt/nas-volume/shares/ftp
browseable = yes
guest ok = no

[ Voor 56% gewijzigd door Airw0lf op 21-10-2025 17:08 ]

[DarkAllMan]

Misschien heeft iemand deze situatie ook. Ik draai nog niet heel lang op Proxmox, maar tot op heden ben ik er super blij mee. Ik heb Kuma Uptime draaien als LXC via een helper script.
Nu is er een flinke release (2.0). Als ik een upgrade doe binnen de LXC dan werkt het niet meer. (langleve snapshots)
Kuma-Uptime server geeft alleen maar deze melding in error log:

code:

Error [ERR_SERVER_NOT_RUNNING]: Server is not running. at Server.close (node:net:2359:12) at Object.onceWrapper (node:events:633:28) at Server.emit (node:events:531:35) at emitCloseNT (node:net:2419:8) at process.processTicksAndRejections (node:internal/process/task_queues:89:21) { code: 'ERR_SERVER_NOT_RUNNING' }

Hoe kan ik upgraden zonder dat ik alles sloop

[GoBieN-Be]

Heb je de community helper scripts gebruikt?
https://community-scripts...xVE/scripts?id=uptimekuma
En doe je de update zoals beschreven?

To Update Uptime Kuma, run the command below (or type update) in the LXC Console

[GoBieN-Be]

Ik heb de update zelf zonet gedaan via het update commando in de LXC console.

✔️ Setup Node.js 22
✔️ Update available: uptime-kuma not installed → 2.0.2
✔️ Stopped Service
✔️ Deployed: uptime-kuma (2.0.2)
✔️ Updated Uptime Kuma
✔️ Started Service
✔️ Updated Successfully
root@uptimekuma:~#

Als ik nu surf naar de URL van mijn uptime-kuma, dan krijg ik de melding dat een migratie bezig is.

Migration is in progress, it may take some time. You can check the progress in the console, or click here to check.

Migration is in progress, listening message...
[DON'T STOP] Migrating monitor data 6 - 2025-09-19 [31.53%][6/22]
...

[GoBieN-Be]

De migratie van data heeft toch een uurtje geduurd.
Pas daarna was het dashboard weer bereikbaar.

[ Voor 31% gewijzigd door GoBieN-Be op 23-10-2025 20:06 ]

[MakhouT]

Iemand dat weet wat er aan de hand is?
Omdat ik het beu was om een telkens mijn LXC te bootstrappen heb ik een nieuwe LXC aangemaakt en vanalles geinstalleerd dat ik er standaard op wil hebben. Daarvan heb ik een template gemaakt.
Vervolgens maak ik een nieuwe LXC aan gebaseerd op die template, het enige dat ik nog manueel moet aanpassen is de statische ip address (anders heb ik een duplicate)
So far so good. Maar nu komt het, telkens ik naar mijn nieuwe LXC willen ssh'en, krijg ik het volgende:

code:

ssh -vvv root@192.168.1.8
OpenSSH_9.9p2, LibreSSL 3.3.6
debug1: Reading configuration data /Users/johnny/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.1.8 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/Users/johnny/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/Users/johnny/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug3: channel_clear_timeouts: clearing
debug3: ssh_connect_direct: entering
debug1: Connecting to 192.168.1.8 [192.168.1.8] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Connection established.
debug1: identity file /Users/johnny/.ssh/id_rsa type 0
debug1: identity file /Users/johnny/.ssh/id_rsa-cert type -1
debug1: identity file /Users/johnny/.ssh/id_ecdsa type -1
debug1: identity file /Users/johnny/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/johnny/.ssh/id_ecdsa_sk type -1
debug1: identity file /Users/johnny/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /Users/johnny/.ssh/id_ed25519 type 3
debug1: identity file /Users/johnny/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/johnny/.ssh/id_ed25519_sk type -1
debug1: identity file /Users/johnny/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /Users/johnny/.ssh/id_xmss type -1
debug1: identity file /Users/johnny/.ssh/id_xmss-cert type -1
debug1: identity file /Users/johnny/.ssh/id_dsa type -1
debug1: identity file /Users/johnny/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.9
kex_exchange_identification: read: Connection reset by peer
Connection reset by 192.168.1.8 port 22

Enig idee wat hier verkeerd gaat? Er naartoe pingen lukt wel

[lolgast]

Heeft elke LXC SSH nodig? Het verhoogt ook het eventuele risico voor misbruik.

Ik gebruik pct enter ### vanuit de PVE host om bij mijn LXC te komen

[Liegebeest]

MakhouT schreef op donderdag 23 oktober 2025 @ 23:13:

Enig idee wat hier verkeerd gaat? Er naartoe pingen lukt wel

Heb je misschien de SSH daemon zo ingesteld dat alleen key authenticatie is toegestaan, zonder jouw public key te installeren?

[Liegebeest]

Liegebeest schreef op vrijdag 24 oktober 2025 @ 07:09:
[...]

Heb je misschien de SSH daemon zo ingesteld dat alleen key authenticatie is toegestaan, zonder jouw public key te installeren?

Omdat ik het beu was om een telkens mijn LXC te bootstrappen heb ik een nieuwe LXC aangemaakt en vanalles geinstalleerd dat ik er standaard op wil hebben. Daarvan heb ik een template gemaakt.

Ik ben nog niet zo thuis in LXC, daarom kan het zijn dat ik t verkeerd begrijp. Voor mij leest dit alsof je hebt gezegd: begin met deze parent image, zet er dit allemaal in en maak dat de template om te klonen. Dat klinkt in de buurt van, maar eigenlijk niet, een Dockerfile. Containers zou je niet moeten hard coden, je zou het herbouwen elke dag opnieuw moeten kunnen doen dankzij automatisering en een Dockerfile, om te zorgen dat je altijd courant bent. Een container moet je niet zien als een VM.

EDIT:
Ik loop inderdaad achter. Voor LXC werkt allemaal wat anders.

https://discuss.linuxcont...on-of-a-dockerfile/6487/7

Packer kan uitkomst bieden voor de automatische build, dat wel. En anders Cloud-Init of Ansible.

Maar ik moet duidelijk eens gaan kijken waarom sommige mensen “OS Containers” zouden willen. Dat is voor mij namelijk de antithese van wat je met containers zou willen.

[ Voor 18% gewijzigd door Liegebeest op 24-10-2025 07:26 ]

[MakhouT]

lolgast schreef op vrijdag 24 oktober 2025 @ 06:43:
Heeft elke LXC SSH nodig? Het verhoogt ook het eventuele risico voor misbruik.

Ik gebruik pct enter ### vanuit de PVE host om bij mijn LXC te komen

In principe niet, maar qua security maak ik me geen zorgen omdat het enkel lokaal op mijn netwerk blijft. De uitzonderlijke LXCs die exposed zijn schakel ik wel manueel uit. Maar standaard wil ik dat ik in elke nieuwe LXC kan ssh’en

[MakhouT]

Liegebeest schreef op vrijdag 24 oktober 2025 @ 07:09:
[...]

Heb je misschien de SSH daemon zo ingesteld dat alleen key authenticatie is toegestaan, zonder jouw public key te installeren?

Ik heb het gezet op

code:

# /etc/ssh/sshd_config

PermitRootLogin yes
PasswordAuthentication yes

[Liegebeest]

Het voelt vies maar zou moeten werken. Werkt het wel vanuit de container naar zichzelf?

[Airw0lf]

Liegebeest schreef op vrijdag 24 oktober 2025 @ 07:14:
[...]
Maar ik moet duidelijk eens gaan kijken waarom sommige mensen “OS Containers” zouden willen. Dat is voor mij namelijk de antithese van wat je met containers zou willen.

Niet alle applicaties zijn beschikbaar in een Docker uitvoering. En dan is een LXC container the next-best-thing.

Er zijn ook applicaties die niet (of met veel kunst-en-vlieg-werk) in een LXC container kunnen draaien. In dat geval zit er niks anders op dan een VM in te zetten - voorbeelden hiervan zijn OpnSense en HASS.

Voor de volledigheid - weet dat ook een Docker container een OS aan boord heeft - weliswaar gestript - maar toch. Kan eigenlijk ook niet anders omdat applicaties nou eenmaal een OS nodig hebben. In mijn geval lijkt dat bij alle containers Alpine te zijn.

[DarkAllMan]

GoBieN-Be schreef op donderdag 23 oktober 2025 @ 19:06:
Ik heb de update zelf zonet gedaan via het update commando in de LXC console.

[...]


Als ik nu surf naar de URL van mijn uptime-kuma, dan krijg ik de melding dat een migratie bezig is.

[...]


[...]

Ah, ik tikte "upgrade" ipv "update" en dan gaat het fout.

[Liegebeest]

Airw0lf schreef op vrijdag 24 oktober 2025 @ 07:59:
[...]
Voor de volledigheid - weet dat ook een Docker container een OS aan boord heeft - weliswaar gestript - maar toch. Kan eigenlijk ook niet anders omdat applicaties nou eenmaal een OS nodig hebben. In mijn geval lijkt dat bij alle containers Alpine te zijn.

Ik ben't oneens met deze paragraaf.

Je hebt geen Linux OS-omgeving nodig voor de meeste dingen die in een container zouden draaien. Net als in een chroot omgeving kan je in veel gevallen uit met een aantal ondersteunende libraries, maar alle sores onder /etc, /var, /usr, /bin etc. heb je niet nodig. En hoewel Alpine een fantastische gooi hebben gedaan naar het zo-klein-mogelijk, bevat ook die vaak nog veel meer dan nodig is.

Maar iets als "system containers" of "os containers", waar je meerdere daemons in zou draaien met systemd als pid=1? Of zelfs, zoals in sommige gevallen, een hele grafische omgeving? Daar kan ik met m'n hoofd echt niet bij.

[MakhouT]

Liegebeest schreef op vrijdag 24 oktober 2025 @ 07:27:
Het voelt vies maar zou moeten werken. Werkt het wel vanuit de container naar zichzelf?

Neen dat werkt ook niet:

code:

ssh: connect to host 192.168.1.8 port 22: Connection refused

Gisteren uren bezig geweest met een oplossing te vinden, vandaag een nieuwe dag om enkele uren hieraan te verslinden

[RobertMe]

Airw0lf schreef op vrijdag 24 oktober 2025 @ 07:59:
Voor de volledigheid - weet dat ook een Docker container een OS aan boord heeft - weliswaar gestript - maar toch. Kan eigenlijk ook niet anders omdat applicaties nou eenmaal een OS nodig hebben. In mijn geval lijkt dat bij alle containers Alpine te zijn.

Ter aanvulling op de post van @Liegebeest, er zijn ook programma's, al dan niet gecompileerd voor Docker, die statisch gecompileerd zijn of 0 dependencies hebben. Het image bevat dan letterlijk één bestand, de executable. Dit geldt in ieder geval vaak voor software geschreven in Go (Traefik bv). Dat is een self contained executable die je zo kunt downloaden en op elke Linux versie/distro kunt draaien, incl een Docker container gebaseerd op het "scratch" image (dat letterlijk helemaal leeg is).

En daarnaast zit er nogal een verschil tussen een OS en een Docker container. Een Docker container draait idealiter geen init systeem (systemd, initd, of wat je bij containers ziet supervised), een Docker container draait geen logging daemon (journald bv), een Docker container draait geen SSH in, .... Alleen daardoor is de exposure naar bv security issues een stuk kleiner. Iets dat er niet is kun je ook niet aanvallen. En al deze zaken zijn (standaard) wel aanwezig in de LXC OS templates.

[Liegebeest]

MakhouT schreef op vrijdag 24 oktober 2025 @ 09:37:
[...]

Neen dat werkt ook niet:

code:

ssh: connect to host 192.168.1.8 port 22: Connection refused

Gisteren uren bezig geweest met een oplossing te vinden, vandaag een nieuwe dag om enkele uren hieraan te verslinden

Voor de SSH van container, naar dezelfde container moet je naar localhost gaan... Tenzij je expliciet zeker weet dat het IP adres dat je noemt actief is voor die container.

[wishmaster1986]

MakhouT schreef op vrijdag 24 oktober 2025 @ 09:37:
[...]

Neen dat werkt ook niet:

code:

ssh: connect to host 192.168.1.8 port 22: Connection refused

Gisteren uren bezig geweest met een oplossing te vinden, vandaag een nieuwe dag om enkele uren hieraan te verslinden

Werkt een

code:

nc -zv localhost 22

in de Alpine LXC wel? Dan weet je iig dat de ssh daemon draait en connecties accepteerd. Netcat installeren kan met

code:

pkg install netcat-openbsd

[MakhouT]

Tja domme zaken dat ik dus zat te doen!
Bij het clonen bestonden mijn oude ssh keys nog, nu heb ik ze verwijderd en terug aangemaakt en dan werkt het wel.
Nu nog een scriptje schrijven dat nieuwe ssh keys aanmaakt bij het spinnen van een nieuwe LXC en ssh restart.
Ik denk dat ik er nu wel ga geraken

Voor de volledigheid:
@wishmaster1986
➜ ~ nc -zv localhost 22
localhost [127.0.0.1] 22 (ssh) open

EDIT: Hmmm toch niet precies. Eerste keer lukte het, maar de 2de keer is het gewoon terug hetzelfde. Ik begrijp niet waarom.

[ Voor 13% gewijzigd door MakhouT op 24-10-2025 10:28 ]

[Quad]

Liegebeest schreef op vrijdag 24 oktober 2025 @ 07:14:
[...]


[...]

Ik ben nog niet zo thuis in LXC, daarom kan het zijn dat ik t verkeerd begrijp. Voor mij leest dit alsof je hebt gezegd: begin met deze parent image, zet er dit allemaal in en maak dat de template om te klonen. Dat klinkt in de buurt van, maar eigenlijk niet, een Dockerfile. Containers zou je niet moeten hard coden, je zou het herbouwen elke dag opnieuw moeten kunnen doen dankzij automatisering en een Dockerfile, om te zorgen dat je altijd courant bent. Een container moet je niet zien als een VM.

EDIT:
Ik loop inderdaad achter. Voor LXC werkt allemaal wat anders.

https://discuss.linuxcont...on-of-a-dockerfile/6487/7

Packer kan uitkomst bieden voor de automatische build, dat wel. En anders Cloud-Init of Ansible.

Maar ik moet duidelijk eens gaan kijken waarom sommige mensen “OS Containers” zouden willen. Dat is voor mij namelijk de antithese van wat je met containers zou willen.

Ik ben van 3 docker VMs naar enkel LXCs gegaan met voornamelijk docker erin.
Het biedt mij persoonlijk enkele voordelen (alsook nadelen).
Ipv MACVlan is het beheer van het IP adres op de LXC zelf.
Geen 'zware' OS laag tussen host en de dockercontainer.
Mountpoints direct op de host <> TrueNAS met hoogst mogelijke snelheiden door eigen bridge.
Als er onderhoud op de docker VM plaats vindt, heeft het impact op alle dockercontainers.
Na een aantal jaar zijn die VMs ook wel wat vervuild qua configs dus werd het wel tijd voor wat nieuws.
PBS backupt per LXC, een restore van een enkele LXC heeft veel minder impact dan de volledige VM te moeten herstellen.

Nadeel; ik heb een sloot aan LXCs (23 actief + 8 offline) die ik moet bijhouden, even updaten zie ik nog geen goede optie voor. Mogelijk dat ik n8n dit ga laten doen.
De LXC template heeft wel een docker, portainer en Watchtower zodat de containers zover mogelijk up-to-date blijven.

[DRAFTER86]

Quad schreef op vrijdag 24 oktober 2025 @ 10:33:
[...]

Ik ben van 3 docker VMs naar enkel LXCs gegaan met voornamelijk docker erin.
Het biedt mij persoonlijk enkele voordelen (alsook nadelen).
Ipv MACVlan is het beheer van het IP adres op de LXC zelf.
Geen 'zware' OS laag tussen host en de dockercontainer.
Mountpoints direct op de host <> TrueNAS met hoogst mogelijke snelheiden door eigen bridge.
Als er onderhoud op de docker VM plaats vindt, heeft het impact op alle dockercontainers.
Na een aantal jaar zijn die VMs ook wel wat vervuild qua configs dus werd het wel tijd voor wat nieuws.
PBS backupt per LXC, een restore van een enkele LXC heeft veel minder impact dan de volledige VM te moeten herstellen.

Nadeel; ik heb een sloot aan LXCs (23 actief + 8 offline) die ik moet bijhouden, even updaten zie ik nog geen goede optie voor. Mogelijk dat ik n8n dit ga laten doen.
De LXC template heeft wel een docker, portainer en Watchtower zodat de containers zover mogelijk up-to-date blijven.

Ehm, is meerdere LXC containers met ieder een eigen docker daemon niet een beetje omslachtig? Wat is het voordeel daarvan?

[Liegebeest]

MakhouT schreef op vrijdag 24 oktober 2025 @ 09:55:
Bij het clonen bestonden mijn oude ssh keys nog, nu heb ik ze verwijderd en terug aangemaakt en dan werkt het wel.
Nu nog een scriptje schrijven dat nieuwe ssh keys aanmaakt bij het spinnen van een nieuwe LXC en ssh restart.

Je hoeft helemaal niet steeds nieuwe SSH keys te maken.

Wanneer je een nieuwe container spint moet je jouw bestaande public key er op installeren, dat is alles.

[Liegebeest]

Quad schreef op vrijdag 24 oktober 2025 @ 10:33:
[...]
Als er onderhoud op de docker VM plaats vindt, heeft het impact op alle dockercontainers.

Dat is waar we Kubernetes en dat soort platforms voor hebben. Heck, dat is waar we Proxmox voor hebben, waarbij je containers tussen cluster nodes heen en weer kan ketsen.

Na een aantal jaar zijn die VMs ook wel wat vervuild qua configs dus werd het wel tijd voor wat nieuws.

En dat is waar we Ansible en Terraform voor hebben; herbouw je VMs regelmatig schoon en voorkom configuration drift met de juiste tooling.

Hoe de meeste omgevingen waar ik kom werken: VM platform cluster -> Meerdere VMs voor een container platform -> Vele containers op het cont.platform -> Met meerdere instances per container.

Bijvoorbeeld een cluster van Proxmox systemen, met daarop meerdere Kubernetes VMs, met daarop tientallen of honderden containers, waarvan de meesten meerdere instances hebben. Wordt een K8S node herbouwd, draait alles door op de rest van het cluster. Gaat een container instance down, nemen de andere instances het waar. En moet de software in de container worden gewijzigd, dan maken we on-the-fly een nieuwe versie van de container die daarna één-voor-één de runnende containers vervangt.

Maar Docker-in-LXC is er niet eentje die we zouden gebruiken. Weet namelijk één van die LCX containers de kernel te crashen, dan is werkelijk alles down.

...

Om het weer naar de kleinere situatie te betrekken:

Ik run Mailcow met Docker Compose op een Ubuntu VM in Proxmox. De Mailcow containers worden dagelijks gestopt en vervangen met nieuwe software. De Ubuntu VM wordt dagelijks geüpdated en indien nodig gereboot. Ik heb tot nog toe nog geen enkele email gemist.

[ Voor 70% gewijzigd door Liegebeest op 24-10-2025 11:05 ]

[Quad]

DRAFTER86 schreef op vrijdag 24 oktober 2025 @ 10:50:
[...]


Ehm, is meerdere LXC containers met ieder een eigen docker daemon niet een beetje omslachtig? Wat is het voordeel daarvan?

Geen MACVlan per docker container maar direct op LXC.
De LXC wordt per service gebackupped ipv de hele docker VM.
*arr stack heb ik wel grotendeels in 1 LXC draaien.
Maar AdGuard draait dan weer verdeeld over 2 LXCs op 2 hosts voor redundancy.
En ik vind het wel prettig om in 1 interface te zien en te weten wat ik draai.

Liegebeest schreef op vrijdag 24 oktober 2025 @ 10:58:
[...]

Dat is waar we Kubernetes en dat soort platforms voor hebben. Heck, dat is waar we Proxmox voor hebben, waarbij je containers tussen cluster nodes heen en weer kan ketsen.

Precies, ik hoef nu niet 1 VM bij te houden wat impact heeft op alles. als ik bij een LXC moet en die geef ik een schop, dan heeft het alleen impact daarop en niet op overige applicaties.

Ps ik zit in een thuissituatie hè, geen zakelijke omgeving.
Ik snap dat een docker in LXC niet de meest nuttige optie is, maar voor mij persoonlijk werkt het goed.

[ Voor 6% gewijzigd door Quad op 24-10-2025 11:08 ]

[Airw0lf]

@Liegebeest @RobertMe - klopt - je kan zeker niet meer spreken over een OS (en zo had ik het ook niet direct bedoeld). Tis meer dat elke applicatie iets aan I/O nodig heeft - toch? Met minimaal iets van netwerk, opslag en een presentatielaag? En daarmee minimaal die delen van een OS die relevant zijn voor dat I/O-gedeelte?

Hoe die dan bij die applicatie terecht komen is dan weer een ander vraagstuk - de ene keer wordt iets mee-gecompileerd in de applicatie. De andere keer wordt het als losse bouwblokken bij elkaar geassembleerd in een (op Alpine?) gebaseerd Docker image. Zolang die I/O functies er maar in zitten en het "ding" ook gebruikt kan worden.

[Liegebeest]

Airw0lf schreef op vrijdag 24 oktober 2025 @ 11:26:
@Liegebeest @RobertMe - klopt - je kan zeker niet meer spreken over een OS (en zo had ik het ook niet direct bedoeld). Tis meer dat elke applicatie iets aan I/O nodig heeft - toch? Met minimaal iets van netwerk, opslag en een presentatielaag? En daarmee minimaal die delen van een OS die relevant zijn voor dat I/O-gedeelte?

Hoe die dan bij die applicatie terecht komen is dan weer een ander vraagstuk -

Nee hoor, dat is juist wat de kernel allemaal voor je doet. En laat dat nou in een container-situatie verzorgd worden door het host OS.

[ Voor 14% gewijzigd door Liegebeest op 24-10-2025 12:28 ]

[MakhouT]

Liegebeest schreef op vrijdag 24 oktober 2025 @ 10:57:
[...]

Je hoeft helemaal niet steeds nieuwe SSH keys te maken.

Wanneer je een nieuwe container spint moet je jouw bestaande public key er op installeren, dat is alles.

Ik ben niet helemaal mee met wat je bedoelt. Want ik login in met password en niet dmv ssh key.

Hele dag verspild en nog steeds geen progress. Ik weet het niet meer wat ik nog verkeerd doe...
Ik heb zelfs de template terug opnieuw gebouwd om zeker te zijn dat ik niets verkeerd doe.

Zien jullie misschien of ik wat verkeerd heb staan in mijn scriptje? Dit is een scriptje dat ik draai voor ik mijn LXC naar een template omzet:

code:

#!/usr/bin/env bash
# ==========================================================
# setup-base-root.sh
# Debian Trixie LXC base template setup for Proxmox
# Root-only version (no extra users)
# Installs dev tools, Node.js, Zsh + Oh My Zsh, etc.
# ==========================================================

set -e

echo "???? Updating and upgrading packages..."
apt update && apt upgrade -y

echo "???? Installing essential system tools..."
apt install -y \
  sudo curl wget vim git htop btop net-tools iproute2 bind9-dnsutils \
  unzip zip tar ca-certificates build-essential lsb-release gnupg2 dirmngr

echo "???? Installing Node.js & npm..."
curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
apt install -y nodejs
echo "Node version: $(node -v), npm version: $(npm -v)"

echo "?????? Installing Zsh and productivity tools..."
apt install -y zsh fzf ripgrep bat eza autojump

echo "???? Oh My Zsh already installed, skipping..."

echo "??? Adding Zsh plugins (autosuggestions + syntax highlighting)..."
ZSH_CUSTOM=${ZSH_CUSTOM:-/root/.oh-my-zsh/custom}
git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM}/plugins/zsh-autosuggestions
git clone https://github.com/zsh-users/zsh-syntax-highlighting ${ZSH_CUSTOM}/plugins/zsh-syntax-highlighting

sed -i 's/^plugins=(git)/plugins=(git zsh-autosuggestions zsh-syntax-highlighting)/' /root/.zshrc

echo "???? Adding alias for 'ls' using eza..."
echo "alias ls='eza -al --color=auto'" >> /root/.zshrc

echo "???? Setting Zsh as default shell for root..."
chsh -s $(which zsh)

echo "???? Setting up SSH key regeneration service..."
cat > /etc/systemd/system/regenerate-ssh-keys.service << 'SERVICEEOF'
[Unit]
Description=Regenerate SSH host keys on first boot
After=multi-user.target
ConditionPathExists=!/etc/ssh/ssh_host_rsa_key

[Service]
Type=oneshot
ExecStart=/usr/bin/ssh-keygen -A
ExecStartPost=/bin/systemctl restart ssh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
SERVICEEOF

systemctl enable regenerate-ssh-keys.service

echo "???? Removing SSH host keys for template..."
rm -f /etc/ssh/ssh_host_*

echo "???? Cleaning up temporary files..."
apt autoremove -y
apt clean
rm -rf /var/lib/apt/lists/*
rm -rf /tmp/* /var/tmp/*
truncate -s 0 /etc/machine-id

echo "??? Setup complete!"
echo "You can now stop and convert this container to a Proxmox template:"
echo "   pct stop <CTID> && pct template <CTID>"

[dcm360]

Liegebeest schreef op vrijdag 24 oktober 2025 @ 07:14:
[...]
Maar ik moet duidelijk eens gaan kijken waarom sommige mensen “OS Containers” zouden willen. Dat is voor mij namelijk de antithese van wat je met containers zou willen.

Containers als soort van lichtgewicht VM of beter geïsoleerde chroot-omgeving is een ouder concept dan wat Docker er mee is gaan doen. De andere kant op is meer de vraag waarom je graag containers wil die niets kunnen...

[Liegebeest]

dcm360 schreef op zaterdag 25 oktober 2025 @ 01:07:
[...]

Containers als soort van lichtgewicht VM of beter geïsoleerde chroot-omgeving is een ouder concept dan wat Docker er mee is gaan doen. De andere kant op is meer de vraag waarom je graag containers wil die niets kunnen...

Dat is een fair punt. En ik zal toegeven dat, toen Sun de introductie deed van Solaris Zones, ik het punt ook niet echt zag. Ik mis daar vast een stukje visie.

[ Voor 3% gewijzigd door Liegebeest op 25-10-2025 07:48 ]

[Dutchess_Nicole]

Bash:

echo "???? Setting up SSH key regeneration service..."
cat > /etc/systemd/system/regenerate-ssh-keys.service << 'SERVICEEOF'
[Unit]
Description=Regenerate SSH host keys on first boot
After=multi-user.target
ConditionPathExists=!/etc/ssh/ssh_host_rsa_key

[Service]
Type=oneshot
ExecStart=/usr/bin/ssh-keygen -A
ExecStartPost=/bin/systemctl restart ssh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
SERVICEEOF

systemctl enable regenerate-ssh-keys.service

Doe hiertussen ook nog even een systemctl daemon-reload. Je probeert nu een service te enablen waar systemd nog niet van weet.

[dcm360]

Op zich is het ook helemaal niet nodig om zelf iets te doen met de SSH host key. Zodra je een container aanmaakt op basis van een template, zal Proxmox een nieuwe host key genereren voor de container.

[MakhouT]

dcm360 schreef op zaterdag 25 oktober 2025 @ 12:56:
Op zich is het ook helemaal niet nodig om zelf iets te doen met de SSH host key. Zodra je een container aanmaakt op basis van een template, zal Proxmox een nieuwe host key genereren voor de container.

Dat dacht ik ook, maar ik weet niet waarom ik deze error dan krijg als ik clone van mijn template. Ik heb geen idee meer

[MakhouT]

Dutchess_Nicole schreef op zaterdag 25 oktober 2025 @ 11:35:

Bash:

echo "???? Setting up SSH key regeneration service..."
cat > /etc/systemd/system/regenerate-ssh-keys.service << 'SERVICEEOF'
[Unit]
Description=Regenerate SSH host keys on first boot
After=multi-user.target
ConditionPathExists=!/etc/ssh/ssh_host_rsa_key

[Service]
Type=oneshot
ExecStart=/usr/bin/ssh-keygen -A
ExecStartPost=/bin/systemctl restart ssh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
SERVICEEOF

systemctl enable regenerate-ssh-keys.service

Doe hiertussen ook nog even een systemctl daemon-reload. Je probeert nu een service te enablen waar systemd nog niet van weet.

Zal dat eens proberen just in case

[dcm360]

Wacht eens, wat ben je nu precies aan het doen? Je hebt het over een template en over een clone-actie, maar clone is niet een actie die ik associeer met templates. Wat jij een template noemt is dan een bestaande container? In dat geval zou ik aanraden om de container om te zetten naar een template, en via de standaard create wizard het template te gebruiken.

[MakhouT]

dcm360 schreef op zaterdag 25 oktober 2025 @ 14:59:
Wacht eens, wat ben je nu precies aan het doen? Je hebt het over een template en over een clone-actie, maar clone is niet een actie die ik associeer met templates. Wat jij een template noemt is dan een bestaande container? In dat geval zou ik aanraden om de container om te zetten naar een template, en via de standaard create wizard het template te gebruiken.

Ok misschien even een stapje teruggaan, want ik ben nog wel een leek in de proxmox wereld. Dus kan zijn dat ik nog wat verkeerd heb gedaan?
Stappenplan:
1. Ik heb een nieuwe LXC gemaakt met ipv4 static 192.168.1.7/24 en met id 500
2. In die nieuwe LXC heb ik mijn script gerund om mijn default tools te installeren. Deze tools (npm, node, zsh, etc) wil ik telkens ik een nieuwe LXC aanmaak dat die er standaard al opstaan.
3. Shutdown de LXC
4. Eenmaal uitgeschakeld, convert ik de LXC naar een template (rechtermuis op de LXC en convert to template)
5. Dan maak ik een nieuwe LXC aan gebaseerd op deze template. Dat doe ik dan ook vervolgens met rechtermuis op de template dat ik heb aangemaakt en daar staat letterlijk clone. Als ik die aanklik komt er een popup om een naam en mode te selecteren (ik heb tot nu toe altijd de 'full clone' mode gekozen)
6. Voor ik de nieuwe LXC opstart verander ik nog snel even het ipv4 adres.
7. Start de nieuwe LXC op en dan probeer ik te ssh'en naar deze nieuwe LXC maar dan krijg ik die fout

code:

ssh root@192.168.1.8
kex_exchange_identification: read: Connection reset by peer
Connection reset by 192.168.1.8 port 22

Dat is ongeveer het process dat ik nu toe. Doe ik wat verkeerd dan?
Ik heb nog even een screenshotje erbij gezet wat ik exact te zien krijg in een LXC template menu

[lolgast]

Misschien moet je het preppen dan op zijn minst via ‘pct enter 500’ doen, ipv SSH te gebruiken en daardoor eigenlijk je profiel te vervuilen. Een template moet zo min mogelijk statische data bevatten. Feit dat je een fixed IP toekent aan een te preppen vind ik ook ‘onverstandig’

[MakhouT]

lolgast schreef op zondag 26 oktober 2025 @ 07:55:
Misschien moet je het preppen dan op zijn minst via ‘pct enter 500’ doen, ipv SSH te gebruiken en daardoor eigenlijk je profiel te vervuilen. Een template moet zo min mogelijk statische data bevatten. Feit dat je een fixed IP toekent aan een te preppen vind ik ook ‘onverstandig’

Ik ben akkoord met wat je zegt dat een template zo min mogelijk statische data moet bevatten. Dat is inderdaad een goed punt van die static ip, die pas ik nog aan en ik ga inderdaad eens proberen via pct enter 500 proberen te doen (ik ga een nieuwe template aanmaken en het opnieuw proberen)
Ter verduidelijking: Ik heb SSH niet gebruikt om de template te preppen, ik ben direct via proxmox webui naar de LXCs console gegaan en van daaruit zitten werken. Echter wil ik gewoon dat elke nieuwe LXC standaard in gessht kan worden. Ik probeer je suggestie uit en rapporteer terug met een update
Dank je wel voor de tips

[stormfly]

MakhouT schreef op zondag 26 oktober 2025 @ 22:01:
[...]

Ik ben akkoord met wat je zegt dat een template zo min mogelijk statische data moet bevatten. Dat is inderdaad een goed punt van die static ip, die pas ik nog aan en ik ga inderdaad eens proberen via pct enter 500 proberen te doen (ik ga een nieuwe template aanmaken en het opnieuw proberen)
Ter verduidelijking: Ik heb SSH niet gebruikt om de template te preppen, ik ben direct via proxmox webui naar de LXCs console gegaan en van daaruit zitten werken. Echter wil ik gewoon dat elke nieuwe LXC standaard in gessht kan worden. Ik probeer je suggestie uit en rapporteer terug met een update
Dank je wel voor de tips

Krijgen ze wel een uniek MAC adres?

[Liegebeest]

@MakhouT om te zien wat er fout gaat zal je toch echt op de container moeten inloggen.

Draait de SSH daemon überhaupt? Wederom: kan je naar localhost SSHen? Zo nee dan draait je SSH daemon gewoon niet goed en moet je kijken wat je fout hebt gedaan. Op welke wijze heb je er bijvoorbeeld voor gezorgd dat ie zou opstarten?

[dotcom87]

Even een vraagje ivm storage in proxmox. Ik heb recent 4 HP EliteDesk 800 G4 mini pc's op de kop kunnen tikken. Hier wil ik graag een HA cluster + 1 PBS mee draaien. Er is plaats voor 2 nvme SSD's in elke pc.

Ik had nog 2 WD RED nvme's liggen van 500 gb elk. Deze heb ik in 1 van de pc's gestoken en dan tijdens de proxmox installatie gekozen voor ZFS mirrored.

Maar ik vraag me af of dat een slimme keuze is? Of was het beter geweest om 1 nvme met ext4 te gebruiken voor proxmox en dan de andere als zfs, met replication over alle nodes?

Ik ga niet veel draaien, voornamelijk Home Assistant, pi-hole, nginx.

Hoe zouden jullie dit doen?