Het grote Proxmox VE topic

[nero355]

@RobbyTown

Ik zou dan eens kijken naar een oplossing zoals https://www.veeam.com/vir...backup-solution-free.html die wat uitgebreider is en je hopelijk wat meer opties geeft die nog binnen de Free/Community License passen

[RobbyTown]

nero355 schreef op zondag 30 oktober 2022 @ 19:01:
@RobbyTown

Ik zou dan eens kijken naar een oplossing zoals https://www.veeam.com/vir...backup-solution-free.html die wat uitgebreider is en je hopelijk wat meer opties geeft die nog binnen de Free/Community License passen

Uhm zoals het nu is na de tip van @Feni werkt het zoals ik wilde in Proxmox .

Liep alleen tegen het probleem aan dat die de disk mee backup te en kon bij backup module niet vinden om het te exclude. Die moest dus op de vm. Met Google werk kwam ik niet op gewenste resultaat maar door tip van @Feni bleek het mogelijk zijn dus stap voor stap alles nagekeken .

[ Voor 24% gewijzigd door RobbyTown op 30-10-2022 19:41 ]

[nero355]

RobbyTown schreef op zondag 30 oktober 2022 @ 19:31:
Liep alleen tegen het probleem aan dat die de disk mee backup te en kon bij backup module niet vinden om het te exclude. Die moest dus op de vm.

Ik vind dat dus niet logisch :

Backup Settings regel je op je Centrale Backup Server en op je Clients draai je alleen een Backup Agent net zoals je in elke VM de qemu-guest-agent installeert bijvoorbeeld

[dcm360]

@nero355 de Centrale Backup Server is in dit geval gewoon Proxmox zelf. Meer software toevoegen kan nuttig zijn, maar voegt ook complexiteit toe (je noemt meer agents al als voorbeeld).

[nero355]

dcm360 schreef op maandag 31 oktober 2022 @ 09:46:
@nero355 de Centrale Backup Server is in dit geval gewoon Proxmox zelf. Meer software toevoegen kan nuttig zijn, maar voegt ook complexiteit toe (je noemt meer agents al als voorbeeld).

Maar @RobbyTown heeft het over bepaalde instellingen aan de kant van de Client veranderen i.p.v. de Server dus klopt dat nou wel of niet

[RobbyTown]

nero355 schreef op maandag 31 oktober 2022 @ 17:42:
[...]

Maar @RobbyTown heeft het over bepaalde instellingen aan de kant van de Client veranderen i.p.v. de Server dus klopt dat nou wel of niet

Ik liep tegen het volgende aan

Server 1 heeft 1 C schijf en 2 Netwerk schijven U en V (van vele TB's groot).
Met Proxmox maak ik een complete backup van Server 1. Hierbij word compleet C gebackupt, de 2 netwerk schijven tellen niet mee in de backup. Dus iets van 15 GB groot die backup.

Server 2 heeft 1 C schijf en 1 schijf (de V) voor de beelden. Ik liep tegen het probleem aan dat die beelden ook werden de gebackupt, kortom ik had een backup van 3,5 TB. Dat was nou net niet nodig. Alleen de C schijf is voldoende.

Dus wilde de 3,5TB schijf ook als een soort netwerkshare maken want dan loopt die niet mee in de backup zoals Server 1. Maar dat is niet nodig, want blijkbaar (wat ik dus niet wist) kon je dus een extra schijf excluden van de backup.

[nero355]

RobbyTown schreef op maandag 31 oktober 2022 @ 20:19:
Blijkbaar (wat ik dus niet wist) kon je dus een extra schijf excluden van de backup.

Maar waar deed je dat

[RobbyTown]

nero355 schreef op dinsdag 1 november 2022 @ 00:06:
[...]

Maar waar deed je dat

In Proxmox
https://www.wundertech.ne...roxmox-to-a-synology-nas/

[nero355]

RobbyTown schreef op dinsdag 1 november 2022 @ 04:28:
In Proxmox
https://www.wundertech.ne...roxmox-to-a-synology-nas/

Daar zie ik dit niet staan :

RobbyTown schreef op zondag 30 oktober 2022 @ 19:31:
Liep alleen tegen het probleem aan dat die de disk mee backup te en kon bij backup module niet vinden om het te exclude. Die moest dus op de vm.

Maar ik heb alles nog een keer gelezen en ik denk dat je het gewoon een beetje raar hebt geformuleerd terwijl ik ondertussen blijkbaar erg kippig was en dit niet goed heb gelezen : RobbyTown in "Het grote Proxmox VE topic"

Dus... ehh... ik weet genoeg!

[ComTech]

Ik heb hier voor een goede kennis proxmox opgezet op een intel nuc voor zijn domotica gebeuren.
Nu wil ik dit makkelijk back-uppen maar hij heeft lokaal geen nas of andere opslag beschikbaar.
Ik wel en heb genoeg ruimte daarvoor, hoe zou ik het beste en veiligst zijn VM's via internet naar mij kunnen back-uppen?
Heb een synology VM draaien en TrueNas dus allerlei protocollen zijn beschikbaar.
Evenals een eigen domeinnaam (met een nginx reverse proxy).
SMB/CIFS of NFS over internet lijkt me niet echt veilig (is het überhaupt mogelijk) maar andere mogelijkheden via internet zie ik ook niet.

[powerboat]

ComTech schreef op zaterdag 26 november 2022 @ 17:12:
Ik heb hier voor een goede kennis proxmox opgezet op een intel nuc voor zijn domotica gebeuren.
Nu wil ik dit makkelijk back-uppen maar hij heeft lokaal geen nas of andere opslag beschikbaar.
Ik wel en heb genoeg ruimte daarvoor, hoe zou ik het beste en veiligst zijn VM's via internet naar mij kunnen back-uppen?
Heb een synology VM draaien en TrueNas dus allerlei protocollen zijn beschikbaar.
Evenals een eigen domeinnaam (met een nginx reverse proxy).
SMB/CIFS of NFS over internet lijkt me niet echt veilig (is het überhaupt mogelijk) maar andere mogelijkheden via internet zie ik ook niet.

Je kan met een site-2-site vpn best een beveiligde verbinding opzetten voor smb/nfs verkeer.
Ik zou bij voorkeur een Proxmox Backup Server gebruiken dat werkt nl. erg lekker (liefts ook over een tunnel).

[ComTech]

powerboat schreef op zaterdag 26 november 2022 @ 17:24:
[...]


Je kan met een site-2-site vpn best een beveiligde verbinding opzetten voor smb/nfs verkeer.
Ik zou bij voorkeur een Proxmox Backup Server gebruiken dat werkt nl. erg lekker (liefts ook over een tunnel).

Daar gaan we eens mee prutsen mijn netwerk/VPN kennis is niet zo groot maar er is online genoeg te vinden.
Die Proxmox Backup Server is die ook in een VM te draaien?

[powerboat]

ComTech schreef op zaterdag 26 november 2022 @ 17:31:
[...]


Daar gaan we eens mee prutsen mijn netwerk/VPN kennis is niet zo groot maar er is online genoeg te vinden.
Die Proxmox Backup Server is die ook in een VM te draaien?

Ik heb hem een tijdje in een vm gedraait met een NFS share naar mijn Truenas

[ComTech]

powerboat schreef op zaterdag 26 november 2022 @ 17:35:
[...]


Ik heb hem een tijdje in een vm gedraait met een NFS share naar mijn Truenas

Dan gaan we die eerst opzetten.
Maar hoe zou ik dan de VPN moeten opzetten?
Wil natuurlijk dat alleen het verkeer wat naar mijn PBS server gaat via smb/nfs via VPN gaat.

[orvintax]

ComTech schreef op zaterdag 26 november 2022 @ 17:44:
[...]


Dan gaan we die eerst opzetten.
Maar hoe zou ik dan de VPN moeten opzetten?
Wil natuurlijk dat alleen het verkeer wat naar mijn PBS server gaat via smb/nfs via VPN gaat.

Voor je VPN zou ik Wireguard gebruiken, dat zal denk ik het makkelijkste zijn. Daarin kun je ook aangeven op de client dat die alleen verkeer naar jouw server moet routeren over die VPN en de rest niet.

Tailscale is als het goed is een eenvoudig alternatief, maar daar heb ik zelf geen ervaring mee.

[ZatarraNL]

Hey allemaal,

Raar vraagje hier. Ik draai al een tijdje een Proxmox cluster met 3 nodes en een beperkte Ceph-cluster. Werkt prima.

Eén van de nodes is een Asrock A300 mini barebone met een Ryzen 3 2200G. Deze is ook voorzien van een 240 Gb ssd voor OS (nvme) en 500Gb voor Ceph (sata). Nu heeft deze A300 twee m.2 PCIe poorten, dus ik wilde er een Samsung 980 1Tb nvme aan toevoegen. Dat werkt. De schijf is zichtbaar in proxmox.

Het probleem is nu dat de netwerkinterface niet meer werkt nadat ik die 2e nvme heb toegevoegd. Bij opstart werkt deze, maar zodra Proxmox wordt gestart gaan de lampjes van de RJ45 poort uit en is de verbinding verdwenen. En het device (Enp2s0) is ook helemaal weg. De networking.service kan niet starten, want hij kan het device niet vinden.

Als ik nvme uit het 2e pcie slot haal, dan werkt de netwerkinterface weer. Overigens, als ik de bootdisk in de 2e pcie-slot steek (en de eerste leeg laat) werkt de netwerkinterface ook niet. Ik heb nog gekeken of ik de meest recente bios gebruikte. Deze maar eens geüpdate, maar zonder effect. Er lijkt dus een duidelijke relatie tussen de 2e PCIe slot en de netwerkinterface.

Iemand enig idee? Kan het zijn dat ik moet kiezen: of de 2e pci-slot of de netwerkinterface? Dat lijkt me niet waarschijnlijk. In de handleiding, bios, etc. kan ik hier niets over terugvinden. Ook google helpt me niet verder.

[ Voor 3% gewijzigd door ZatarraNL op 29-11-2022 20:50 ]

[Kek]

ZatarraNL schreef op dinsdag 29 november 2022 @ 20:48:
Hey allemaal,

Raar vraagje hier. Ik draai al een tijdje een Proxmox cluster met 3 nodes en een beperkte Ceph-cluster. Werkt prima.

Eén van de nodes is een Asrock A300 mini barebone met een Ryzen 3 2200G. Deze is ook voorzien van een 240 Gb ssd voor OS (nvme) en 500Gb voor Ceph (sata). Nu heeft deze A300 twee m.2 PCIe poorten, dus ik wilde er een Samsung 980 1Tb nvme aan toevoegen. Dat werkt. De schijf is zichtbaar in proxmox.

Het probleem is nu dat de netwerkinterface niet meer werkt nadat ik die 2e nvme heb toegevoegd. Bij opstart werkt deze, maar zodra Proxmox wordt gestart gaan de lampjes van de RJ45 poort uit en is de verbinding verdwenen. En het device (Enp2s0) is ook helemaal weg. De networking.service kan niet starten, want hij kan het device niet vinden.

Als ik nvme uit het 2e pcie slot haal, dan werkt de netwerkinterface weer. Overigens, als ik de bootdisk in de 2e pcie-slot steek (en de eerste leeg laat) werkt de netwerkinterface ook niet. Ik heb nog gekeken of ik de meest recente bios gebruikte. Deze maar eens geüpdate, maar zonder effect. Er lijkt dus een duidelijke relatie tussen de 2e PCIe slot en de netwerkinterface.

Iemand enig idee? Kan het zijn dat ik moet kiezen: of de 2e pci-slot of de netwerkinterface? Dat lijkt me niet waarschijnlijk. In de handleiding, bios, etc. kan ik hier niets over terugvinden. Ook google helpt me niet verder.

Klinkt als een hardware issue.. je zou nog es kunnen proberen met een usb stick met een live iso om proxmox uit te sluiten.. maar ik denk dat dit in de hardware zit.. (wel een raar probleem overigens)

[DaRoot]

ZatarraNL schreef op dinsdag 29 november 2022 @ 20:48:
Hey allemaal,

Raar vraagje hier. Ik draai al een tijdje een Proxmox cluster met 3 nodes en een beperkte Ceph-cluster. Werkt prima.

Eén van de nodes is een Asrock A300 mini barebone met een Ryzen 3 2200G. Deze is ook voorzien van een 240 Gb ssd voor OS (nvme) en 500Gb voor Ceph (sata). Nu heeft deze A300 twee m.2 PCIe poorten, dus ik wilde er een Samsung 980 1Tb nvme aan toevoegen. Dat werkt. De schijf is zichtbaar in proxmox.

Het probleem is nu dat de netwerkinterface niet meer werkt nadat ik die 2e nvme heb toegevoegd. Bij opstart werkt deze, maar zodra Proxmox wordt gestart gaan de lampjes van de RJ45 poort uit en is de verbinding verdwenen. En het device (Enp2s0) is ook helemaal weg. De networking.service kan niet starten, want hij kan het device niet vinden.

Als ik nvme uit het 2e pcie slot haal, dan werkt de netwerkinterface weer. Overigens, als ik de bootdisk in de 2e pcie-slot steek (en de eerste leeg laat) werkt de netwerkinterface ook niet. Ik heb nog gekeken of ik de meest recente bios gebruikte. Deze maar eens geüpdate, maar zonder effect. Er lijkt dus een duidelijke relatie tussen de 2e PCIe slot en de netwerkinterface.

Iemand enig idee? Kan het zijn dat ik moet kiezen: of de 2e pci-slot of de netwerkinterface? Dat lijkt me niet waarschijnlijk. In de handleiding, bios, etc. kan ik hier niets over terugvinden. Ook google helpt me niet verder.

Het zal vermoedelijk wel iets te maken hebben met dat 2e slot icm de specifieke CPU die je gebruikt, zie ook https://smallformfactor.n...rock-a300-deskmini.13650/
Daar maak ik uit op dat dat M2 slot met 2 lanes wordt aangestuurd icm jouw CPU, ipv 4 bij een 3xxx serie. Mogelijk blijft er daardoor niets over voor de netwerkkaart?

[ZatarraNL]

Kek schreef op woensdag 30 november 2022 @ 09:15:
[...]


Klinkt als een hardware issue.. je zou nog es kunnen proberen met een usb stick met een live iso om proxmox uit te sluiten.. maar ik denk dat dit in de hardware zit.. (wel een raar probleem overigens)

Dat is een idee. Maar ik denk idd hardwarematig.

DaRoot schreef op woensdag 30 november 2022 @ 09:59:
[...]

Het zal vermoedelijk wel iets te maken hebben met dat 2e slot icm de specifieke CPU die je gebruikt, zie ook https://smallformfactor.n...rock-a300-deskmini.13650/
Daar maak ik uit op dat dat M2 slot met 2 lanes wordt aangestuurd icm jouw CPU, ipv 4 bij een 3xxx serie. Mogelijk blijft er daardoor niets over voor de netwerkkaart?

Dat is een interessante theorie. Een van de andere nodes heeft een Ryzen 5 5600g. Ik kan ze eens omwisselen.

[lamaa1]

ZatarraNL schreef op dinsdag 29 november 2022 @ 20:48:
Hey allemaal,

Raar vraagje hier. Ik draai al een tijdje een Proxmox cluster met 3 nodes en een beperkte Ceph-cluster. Werkt prima.

Eén van de nodes is een Asrock A300 mini barebone met een Ryzen 3 2200G. Deze is ook voorzien van een 240 Gb ssd voor OS (nvme) en 500Gb voor Ceph (sata). Nu heeft deze A300 twee m.2 PCIe poorten, dus ik wilde er een Samsung 980 1Tb nvme aan toevoegen. Dat werkt. De schijf is zichtbaar in proxmox.

Het probleem is nu dat de netwerkinterface niet meer werkt nadat ik die 2e nvme heb toegevoegd. Bij opstart werkt deze, maar zodra Proxmox wordt gestart gaan de lampjes van de RJ45 poort uit en is de verbinding verdwenen. En het device (Enp2s0) is ook helemaal weg. De networking.service kan niet starten, want hij kan het device niet vinden.

Als ik nvme uit het 2e pcie slot haal, dan werkt de netwerkinterface weer. Overigens, als ik de bootdisk in de 2e pcie-slot steek (en de eerste leeg laat) werkt de netwerkinterface ook niet. Ik heb nog gekeken of ik de meest recente bios gebruikte. Deze maar eens geüpdate, maar zonder effect. Er lijkt dus een duidelijke relatie tussen de 2e PCIe slot en de netwerkinterface.

Iemand enig idee? Kan het zijn dat ik moet kiezen: of de 2e pci-slot of de netwerkinterface? Dat lijkt me niet waarschijnlijk. In de handleiding, bios, etc. kan ik hier niets over terugvinden. Ook google helpt me niet verder.

Ik heb vrijwel hetzelfde probleem afgelopen geconstateerd vorige week. Echter is het bij mij al de eerste PCIe 4.0 SSD (was een mooie aanbieding, ondanks dat het mobo slechts 3.0 ondersteund) waarna hij eruit knalt. Opgestart met een Windows 10 PE stickje, en daar geen enkel probleem mee.

Specs voor de goede orde:
R5 1600(x?)
16GB RAM
Gigabyte B450M DS3H
Kingston A400 500GB
Kingston N2 2tb

[orvintax]

lamaa1 schreef op woensdag 30 november 2022 @ 15:17:
[...]


Ik heb vrijwel hetzelfde probleem afgelopen geconstateerd vorige week. Echter is het bij mij al de eerste PCIe 4.0 SSD (was een mooie aanbieding, ondanks dat het mobo slechts 3.0 ondersteund) waarna hij eruit knalt. Opgestart met een Windows 10 PE stickje, en daar geen enkel probleem mee.

Specs voor de goede orde:
R5 1600(x?)
16GB RAM
Gigabyte B450M DS3H
Kingston A400 500GB
Kingston N2 2tb

In de Linux community is Kingston wel bekend vanwege zijn problemen. Als je ook zoekt op "Linux Kingston A400 SSD" zie je ook verschillende posts op Reddit en fora voorbij komen met mensen die problemen hebben. Je zou kunnen proberen de firmware te updaten, dat lijkt soms te werken. Voor de rest is er niks dat je kunt doen

[RobertMe]

orvintax schreef op woensdag 30 november 2022 @ 18:12:
[...]

In de Linux community is Kingston wel bekend vanwege zijn problemen. Als je ook zoekt op "Linux Kingston A400 SSD" zie je ook verschillende posts op Reddit en fora voorbij komen met mensen die problemen hebben. Je zou kunnen proberen de firmware te updaten, dat lijkt soms te werken. Voor de rest is er niks dat je kunt doen

* RobertMe heeft gisteren een Samsung 980 ontvangen. (In mijn Chinese mini PC met N5105 CPU) vindt Proxmox die ook niet leuk. Die spuugt ook alleen maar errors en installer start niet eens. Met een boot flag start die dan wel op (nvme_core.<iets met latency>) maar na installatie gaat het feest vrolijk verder.

Overigens heb ik ook een Kingston A2000 gehad. Daarna heb ik gezweerd nooit meer een Kingston te kopen. En heb ik die vervangen door een Evo 970 Plus (uit mijn hoofd). Maar ook Samsung is dus blijkbaar niet immuun voor vage issues in sleep modussen.

Overigens heeft dat denk ik niet met het originele probleem te maken dat PCI lanes weg lijken te vallen.

[orvintax]

RobertMe schreef op woensdag 30 november 2022 @ 18:22:
[...]
Overigens heeft dat denk ik niet met het originele probleem te maken dat PCI lanes weg lijken te vallen.

Bedoel je met het originele probleem het probleem van @ZatarraNL of van @lamaa1? Want @lamaa1 denkt dat het een gerelateerd probleem is, maar dat denk ik van niet. Als het aan die pcie lanes lag had hij namelijk ook niet tevoorschijn moeten komen in Windows. Dit ism met Kingstons reputatie op Linux doet mij aan firmware denken.

[Feni]

RobertMe schreef op woensdag 30 november 2022 @ 18:22:
[...]

[ME=296998]Die spuugt ook alleen maar errors en installer start niet eens. Met een boot flag start die dan wel op (nvme_core.<iets met latency>) maar na installatie gaat het feest vrolijk verder.

Dit is een bekend probleem, een deel van de NVME standaard wordt niet ondersteund door Proxmox waardoor bij elke boot je een foutmelding krijgt en de error counter met 1 toeneemt. Is enkel optisch, veroorzaakt geen instabiliteit.

[RobertMe]

Feni schreef op woensdag 30 november 2022 @ 20:54:
[...]

Dit is een bekend probleem, een deel van de NVME standaard wordt niet ondersteund door Proxmox waardoor bij elke boot je een foutmelding krijgt en de error counter met 1 toeneemt. Is enkel optisch, veroorzaakt geen instabiliteit.

Dat leest niet als wat ik had. Iets met een frozen drive, resetten om proberen de drive weer werkende te krijgen, etc. En verder ook gewoon niks doen behalve elke seconde het scherm vol spugen met allemaal PCIe debug info (elke keer gevolgd door dat de drive frozen is).

Heb overigens een 980 Pro in mijn huidige server / NAS zitten (ook Proxmox). En die spuugt dan weer periodiek een SMART temperature warning uit. Drive die 200+ graden is. Dat kwam ik ook al tegen toen ik vanmorgen snel aan het zoeken was naar de "frozen" drive. En ook dat zou opgelost kunnen zijn met dezelfde nvme_core.<iets met latency> kernel optie.

[RobertMe]

Even gesprekje / onderzoekje ontstaan uit / in Het grote zuinige server topic - deel 3 dat ik had met @stormfly & @TheByteBoy hierheen verplaatsen.

In het aangehaalde topic heb ik geschreven dat ik met een Chinese MiniPC met Proxmox een zeer onregelmatig verbruik had dat continu tussen de 2,x & 6,x Watt schommeld. @TheByteBoy gaf daarop aan hetzelfde probleem te hebben (sterk schommelend verbruik bij idle) maar dat zijn installatie afkomstig was van een plain Debian install, en Debian wel hartstikke stabiel was in verbruik.

Daarop heb ik eerder deze week een kale Debian installatie op gezet (met experimental 6.1 kernel omdat de 5.10 kernel een veel hoger verbruik had) op basis waarvan ik kan bevestigen dat het verbruik daarvan stabiel is, met 2,x Watt. Vervolgens de Proxmox kernel geïnstalleerd (zoals in de handleiding staat, dus apt repo toevoegen en apt install pve-kernel-5.19, wetende dat die wat nieuwer is en de stock 5.15 kernel issues geeft met de Intel N5105), en het was meteen raak. Gisteren in eerste instantie zelf de PVE kernel gecompileerd zodat ik daarmee verder kon testen (enerzijds baseert Proxmox de kernel dan sowieso op Ubuntu, anderzijds doen ze ook nog eens de compile flags aanpassen voor wat optimalisaties). Deze kernel gaf vervolgens uiteraard ook hetzelfde resultaat. Echter... toen ik weer op de Debian 6.1 kernel zat zag ik exact hetzelfde gedrag. Het verbruik is totaal niet stabiel en blijft op en neer gaan.

Daarom heb ik vervolgens gekeken wat ik precies gedaan / geïnstalleerd had. En dan blijkt dat ee installatie van pve-kernel- ook meteen pve-firmware installeert en de Debian firmware-* packages verwijderd (in mijn geval firmware-linux-free, firmware-iwlwifi & firmware-realtek). Dus pve-firmware verwijderd en de Debian firmware packages opnieuw geïnstalleerd. Et voila, het verbruik is nu wel weer super stabiel op de Debian kernel.

Heeft iemand hier dus ervaring mee? En waarom Proxmox überhaupt hun eigen firmware package heeft? Lijkt mij immers dat de firmware kernel onafhankelijk is (ook gezien de Debian packages niet gekoppeld zijn aan een kernel versie, de Debian 6.1 kernel net zo goed / slecht werkt met de pve-firmware, etc).

* RobertMe gaat als volgende stapje in deze puzzel maar eens kijken of die niet de pve kernel met Debian firmware packages kan draaien.

[RobertMe]

RobertMe schreef op zaterdag 10 december 2022 @ 12:42:
Even gesprekje / onderzoekje ontstaan uit / in Het grote zuinige server topic - deel 3 dat ik had met @stormfly & @TheByteBoy hierheen verplaatsen.

In het aangehaalde topic heb ik geschreven dat ik met een Chinese MiniPC met Proxmox een zeer onregelmatig verbruik had dat continu tussen de 2,x & 6,x Watt schommeld. @TheByteBoy gaf daarop aan hetzelfde probleem te hebben (sterk schommelend verbruik bij idle) maar dat zijn installatie afkomstig was van een plain Debian install, en Debian wel hartstikke stabiel was in verbruik.

Daarop heb ik eerder deze week een kale Debian installatie op gezet (met experimental 6.1 kernel omdat de 5.10 kernel een veel hoger verbruik had) op basis waarvan ik kan bevestigen dat het verbruik daarvan stabiel is, met 2,x Watt. Vervolgens de Proxmox kernel geïnstalleerd (zoals in de handleiding staat, dus apt repo toevoegen en apt install pve-kernel-5.19, wetende dat die wat nieuwer is en de stock 5.15 kernel issues geeft met de Intel N5105), en het was meteen raak. Gisteren in eerste instantie zelf de PVE kernel gecompileerd zodat ik daarmee verder kon testen (enerzijds baseert Proxmox de kernel dan sowieso op Ubuntu, anderzijds doen ze ook nog eens de compile flags aanpassen voor wat optimalisaties). Deze kernel gaf vervolgens uiteraard ook hetzelfde resultaat. Echter... toen ik weer op de Debian 6.1 kernel zat zag ik exact hetzelfde gedrag. Het verbruik is totaal niet stabiel en blijft op en neer gaan.

Daarom heb ik vervolgens gekeken wat ik precies gedaan / geïnstalleerd had. En dan blijkt dat ee installatie van pve-kernel- ook meteen pve-firmware installeert en de Debian firmware-* packages verwijderd (in mijn geval firmware-linux-free, firmware-iwlwifi & firmware-realtek). Dus pve-firmware verwijderd en de Debian firmware packages opnieuw geïnstalleerd. Et voila, het verbruik is nu wel weer super stabiel op de Debian kernel.

Heeft iemand hier dus ervaring mee? En waarom Proxmox überhaupt hun eigen firmware package heeft? Lijkt mij immers dat de firmware kernel onafhankelijk is (ook gezien de Debian packages niet gekoppeld zijn aan een kernel versie, de Debian 6.1 kernel net zo goed / slecht werkt met de pve-firmware, etc).

* RobertMe gaat als volgende stapje in deze puzzel maar eens kijken of die niet de pve kernel met Debian firmware packages kan draaien.

Here we go:

Clean Proxmox 7.3 installatie (vanaf ISO image), met de 5.19 kernel, vs exact dezelfde installatie na het installeren van een dummy pve-firmware (/leeg package met een Provides: pve-firmware) en het installeren van firmware-linux-free, firmware-iwlwifi & firmware-realtek (laatste twee komen overigens uit de non-free repo). Dus in ieder geval in mijn geval gaat het om een brakke firmware.
Nu nog eens gaan puzzelen met een voor een de (in gebruik zijnde) firmware files vervangen door die uit het pve-firmware package (dus package uitpakken, en dan de files uit de Debian packages overschrijven).

Die 2 korte "blokjes" in de rechte lijn waren toen ik was ingelogd, en in ieder geval een apt show gedaan heb, dus mogelijk dat dat wat activiteit gaf waardoor die voor wat performance ging. Die langere "verhoging" op het eind heb ik geen idee van, maar waarschijnlijk een "meetfout". Meet met een Fibaro WallPlug, en toen ik die, over Z-Wave, een refresh gaf was die meteen terug van 3,x naar 2,x

[nero355]

RobertMe schreef op zaterdag 10 december 2022 @ 12:42:
In het aangehaalde topic heb ik geschreven dat ik met een Chinese MiniPC met Proxmox een zeer onregelmatig verbruik had dat continu tussen de 2,x & 6,x Watt schommeld.

Hou je er ook rekening mee dat er kans is dat de metingen i.c.m. een laag verbruik niet altijd even goed gaan bij sommige adapters/meters die dat wel claimen te kunnen

* RobertMe gaat als volgende stapje in deze puzzel maar eens kijken of die niet de pve kernel met Debian firmware packages kan draaien.

Vroeger deden ze nog weleens Proxmox installeren nadat er eerst een verse kale Debian installatie was gedaan dus check effe of die optie nog steeds bestaat ?!

Verder is het misschien wel handig om te weten dat er vroeger gezeik ontstond op het moment dat je VMWare ESXi draaide op een Server die op "Balanced" dan wel "Eco" mode stond ingesteld i.p.v. "High Performance" waarbij dus ALLE CORES van de CPU constant op de hoogste clockspeeds draaiden!

Misschien heeft dat kastje een soortgelijke bug i.c.m. Proxmox/Linux toevallig ?!

[RobertMe]

@nero355 de TL;DR versie is dus:

1. Installeer Debian Bullseye (en de 6.1 kernel van experimental en de non free firmwares)
2. Laat het systeem een tijd draaien => mooie rechte lijn v.w.b. verbruik, dit kan uren lang
3. Voeg de Proxmox repo toe en installeer pve-firmware (dat verwijderd vervolgens firmware-linux-free, firmware-iwlwifi & firmware-realtek)
4. Reboot => verbruik gaat continu op en neer

En hetzelfde werkt dus ook andersom. Installeer Proxmox via de officiële ISO => installeer een dummy pve-firmware en vervolgens weer de firmware-* packages van Debian.

nero355 schreef op zaterdag 10 december 2022 @ 17:46:
[...]

Hou je er ook rekening mee dat er kans is dat de metingen i.c.m. een laag verbruik niet altijd even goed gaan bij sommige adapters/meters die dat wel claimen te kunnen

Ik claim niet eens dat deze meter betrouwbaar is. Maar er zit natuurlijk ook een verschil tussen accuraat en constant. Als ik met standaard Proxmox een uur lang schommelingen in het verbruik zie en na het erin hacken van de Debian firmware een vlakke lijn zie dan zou het wel heel sterk zijn dat het aan de meter ligt. En dat ook nog eens herhaaldelijk, alsof de meter weet of ik wel of niet met de pve-firmwares draai.

[...]

Vroeger deden ze nog weleens Proxmox installeren nadat er eerst een verse kale Debian installatie was gedaan dus check effe of die optie nog steeds bestaat ?!

Uhm, mijn eerste post omschrijft letterlijk dat ik na @TheByteBoy zijn opmerking (in het andere topic) dat hij dit ook zag met Debian vs Proxmox ook zelf ben begonnen te experimenteren vanaf een Debian installatie. Met daarop dus pve-kernel-5.19 te installeren, en vervolgens "meteen" dit gedrag te zien. Ergo: het komt niet door allemaal monitoring en beheer tools van Proxmox, maar alleen uit de installatie van de kernel, die dus ook de firmware vervangt.

Verder is het misschien wel handig om te weten dat er vroeger gezeik ontstond op het moment dat je VMWare ESXi draaide op een Server die op "Balanced" dan wel "Eco" mode stond ingesteld i.p.v. "High Performance" waarbij dus ALLE CORES van de CPU constant op de hoogste clockspeeds draaiden!

Proxmox draait standaard ook op CPU governor performance, om die reden. Maar dat maakt verder ook niet uit, aangezien ik dit gedrag dus zowel zie met "hoe Debian werkt, met pve-firmware er bovenop" als met "Proxmox met firmware-* van Debian". Dus hoe beiden distros de CPU governor of wat dan ook anders instellen maakt niet uit. Het verschil zit niet "in de distro", maar in de firmware die gebruikt wordt.
En het gaat ook niet om dat Proxmox (iets) meer energie verbruikt, maar omdat Debian (& nu dus ook Proxmox met firmwares van Debian) in idle "gewoon" uren lang een vlakke lijn aan verbruik geeft. Terwijl met Proxmox (& Debian met firmwares van Proxmox) totaal geen constant verbruik hebben en het continu omhoog schiet naar 6,x Watt.

Dat Proxmox vervolgens bv 0,5W extra verbruikt ten opzichte van Debian doordat er services draaien voor het clustering verhaal (ook al is dat niet in gebruik), of een statistieken / metrics service om dus mooie grafieken te maken met het CPU, RAM, ... gebruik, ... is tot daar aan toe.
Waarbij ik überhaupt vermoed dat dat verschil nog marginaler is. Op Debian heb ik 2,2W gemeten, nu Proxmox, met Debian firmwares, draait al sinds 4 uur op 2,5W. Dus dan zou het een verschil zijn van 0,3W is 2,6kWh op jaarbasis. Dat is geneuzel in de marge. Terwijl het instabiele verbruik van Proxmox "standaard" (met pve-firmware dus) voor @TheByteBoy in zijn situatie meen ik een gemiddeld verbruik van 4,xW had, en Debian ook maar 2,xW. Oftewel over langere tijd een gemiddelde dat 2W hoger ligt en dan gaat het al over een verschil van 17kWh op jaarbasis, of gewoon uit te drukken in "Proxmox gebruikt idle het dubbele van wat Debian doet".

---

Overigens kan pve-firmware niet zomaar omzeild worden. Het proxmox-ve package heeft een dependency op pve-kernel-5.15, en pve-kernel-5.15 is een meta package met een dependency op pve-firmware en pve-kernel-5.15.<specifieke versie / build>. Want toen ik zag dat pve-kernel-5.19 maar een meta package is naar pve-firmware en de specifieke build versie wilde ik direct de build versie installeren (dus apt install pve-kernel-5.19.17-1...), en daarna pve-kernel-5.15 & pve-firmware verwijderen. Maar toen wilde die dus ook proxmox-ve "meenemen". Niet echt de bedoeling. Nog losstaand van dat het installeren van een specifiek package / versie dus ertoe leidt dat er geen updates meer binnen druppelen. Immers wordt het specifieke package nooit geüpdate, maar wordt het meta package geupdate met een aanpassing in de dependency.

[nero355]

RobertMe schreef op zaterdag 10 december 2022 @ 18:24:
Ik claim niet eens dat deze meter betrouwbaar is. Maar er zit natuurlijk ook een verschil tussen accuraat en constant. Als ik met standaard Proxmox een uur lang schommelingen in het verbruik zie en na het erin hacken van de Debian firmware een vlakke lijn zie dan zou het wel heel sterk zijn dat het aan de meter ligt. En dat ook nog eens herhaaldelijk, alsof de meter weet of ik wel of niet met de pve-firmwares draai.

Duidelijk!

Uhm, mijn eerste post omschrijft letterlijk dat ik na @TheByteBoy zijn opmerking (in het andere topic) dat hij dit ook zag met Debian vs Proxmox ook zelf ben begonnen te experimenteren vanaf een Debian installatie. Met daarop dus pve-kernel-5.19 te installeren, en vervolgens "meteen" dit gedrag te zien. Ergo: het komt niet door allemaal monitoring en beheer tools van Proxmox, maar alleen uit de installatie van de kernel, die dus ook de firmware vervangt.

Ik heb dat andere topic verder niet doorgelezen dus ik geloof je meteen, maar mijn opmerking was meer bedoeld als TIP om eventueel het beste van beide werelden te kunnen combineren en daarmee gewoon in de toekomst het systeem te kunnen gebruiken zonder gezeik

Overigens kan pve-firmware niet zomaar omzeild worden. Het proxmox-ve package heeft een dependency op pve-kernel-5.15, en pve-kernel-5.15 is een meta package met een dependency op pve-firmware en pve-kernel-5.15.<specifieke versie / build>. Want toen ik zag dat pve-kernel-5.19 maar een meta package is naar pve-firmware en de specifieke build versie wilde ik direct de build versie installeren (dus apt install pve-kernel-5.19.17-1...), en daarna pve-kernel-5.15 & pve-firmware verwijderen. Maar toen wilde die dus ook proxmox-ve "meenemen". Niet echt de bedoeling. Nog losstaand van dat het installeren van een specifiek package / versie dus ertoe leidt dat er geen updates meer binnen druppelen. Immers wordt het specifieke package nooit geüpdate, maar wordt het meta package geupdate met een aanpassing in de dependency.

Dus als ik het goed begrijp :
- Installeer Proxmox via hun eigen ISO.
- Deïnstalleer de PVE firmware meuk.
- Installeer de Debian firmware meuk via een aparte Debian Repository die je tijdelijk toevoegt
Of kopiëer je gewoon wat bestanden naar de juiste plek ?!

[RobertMe]

nero355 schreef op zaterdag 10 december 2022 @ 18:34:
[...]

Ik heb dat andere topic verder niet doorgelezen dus ik geloof je meteen, maar mijn opmerking was meer bedoeld als TIP om eventueel het beste van beide werelden te kunnen combineren en daarmee gewoon in de toekomst het systeem te kunnen gebruiken zonder gezeik

Proxmox is gewoon Debian, dus het is al een combinatie Een Proxmox installatie bevat ook gewoon de Debian repos (Bullseye in geval van Proxmox 7), en de additionele Proxmox repo bevat vervolgens alleen de Proxmox specifieke stuff.
Alleen gaat combineren van Proxmox beheer tools dus niet met Debian kernel, omdat er een dependency naar de Proxmox kernel ligt, die weer pve-firmware vereist, die weer een replace & conflict heeft op een hele lijst aan firmware-* packages van Debian. Dus om de Proxmox (beheer) tools te gebruiken (/dus letterlijk "om Proxmox te gebruiken") ben je verplicht om de firmwares uit de Proxmox repo te gebruiken. Tenzij je dus een dummy package maakt met een Provides: pve-firmware. Daarna kun je de echte pve-firmware wel verwijderen, en dus ook weer de packages van Debian installeren.]

[...]

Dus als ik het goed begrijp :
- Installeer Proxmox via hun eigen ISO.
- Deïnstalleer de PVE firmware meuk.
- Installeer de Debian firmware meuk via een aparte Debian Repository die je tijdelijk toevoegt
Of kopiëer je gewoon wat bestanden naar de juiste plek ?!

Niet "aparte Debian repository die je tijdelijk toevoegt" dus. Want je hebt gewoon de volledige Debian repo(s) tot je beschikking (bullseye, bullseye-update & bullseye-security zijn gewoon ingeschakeld voor main & contrib. Ik heb alleen nog non-free toegevoegd, omdat dan firmware-iwlwifi & firmware-realtek daarin zitten). En "gewoon de bestanden kopieren" is natuurlijk tricky. Want bij de eerste de beste update van pve-firmware worden ze dan overschreven (of krijg je conflicten tijdens updaten). Maar doordat ik nu die dummy pve-firmware (package die die "provides") heb hoef ik niet meer pve-firmware geinstalleerd te hebben (want de dependency op pve-firmware van pve-kernel-* wordt aan voldaan door de "Provides" van mijn dummy). En doordat ik pve-firmware niet geinstalleerd hoef te hebben kan ik dus weer gewoon de firmware-* packages uit de Debian repo installeren. Immers is het "conflict" dat pve-firmware daarmee heeft "weg", want er is geen "pve-firmware" geinstalleerd.

[RobertMe]

Zeer waarschijnlijk gevonden. Dit is nu Proxmox met pve-firmware in gebruik, met...

Vergelijking gedaan tussen dmesg gerelateerd aan "firmware" met en zonder pve-firmware. En dan blijkt dat met firmware-linux-free firmware-iwlwifi firmware-realtek er geen "i915" firmware wordt ingeladen, voor de GPU (iGPU dan). Bij Debian zit die in firmware-misc-nonfree. Dat package geinstalleerd => reboot. En leek op "same shit" (grillig verbruik dus). Vervolgens pve-firmware geinstalleerd, de specifieke firmware file met het handje verwijderd, reboot. En bovenstaande screenshot is daarvan het resultaat.

Nu nog puzzelen of dit niet op een andere manier te bereiken valt (module uitschakelen? Inladen van firmware voorkomen?). Want even een file uit package verwijderen is niet echt onderhoudsvriendelijk (elke update van dit package opnieuw verwijderen? )

Die kleine verhoging die zo lang duurt was weg nadat ik de plug de waardes heb laten verversen. Dus zal eerder aan de plug gelegen hebben dan continu dat hogere verbruik. Die andere 2, 3 piekjes durf ik niet te verklaren. Maarja, er draait natuurlijk genoeg aan achtergrond.

[TheByteBoy]

Lekker bezig @RobertMe fijn dat je zo vasthoudend aan het puzzelen bent . Ik ben benieuwd of het lukt om dit zo te configureren dat het een upgrade van Proxmox overleefd. Heb je ook als eens een workload op Proxmox getest in je nieuwe configuratie, bv Debian VM, hoe het verbruik er dan uit ziet? Zeker interessant

[RobertMe]

TheByteBoy schreef op zondag 11 december 2022 @ 08:38:
Ik ben benieuwd of het lukt om dit zo te configureren dat het een upgrade van Proxmox overleefd.

De oplossing met de dummy doet dat pve-firmware is dan niet geïnstalleerd en zal dus ook niet geupdate worden. En packages die een dependency hebben op pve-firmware kunnen gewoon gebruikt worden doordat de dummy die "provides". En met het gebruik van de Debian packages in de plaats heb ik wel gewoon de overige firmwares, en krijg ik daar updates voor.
De enige vragen zijn: waarom werkt dit? Bevat de iGPU een firmware die dit gedrag niet heeft? Of is de iGPU nu helemaal uitgeschakeld? Maar hoe krijg ik dan wel een terminal?; Wat zijn de gevolgen hiervan? Kan ik nu nog een desktop draaien? (In een VM) Waarschijnlijk niet? (Gebruik ik overigens ook nu niet). En is bv hardware offloading van video nu mogelijk? (Gebruik ik nu ook niet);

Heb je ook als eens een workload op Proxmox getest in je nieuwe configuratie, bv Debian VM, hoe het verbruik er dan uit ziet? Zeker interessant

Nope. Hoe meer je toevoegt hoe lastiger het natuurlijk ook te vergelijken is etc.. En VMs wil ik sowieso niet, of maar minimaal, gebruiken. VMs zijn veel onzuiniger dan LXC, dus LXC is mijn goto.
Heb door dit verbruik ook nog even zitten zoeken of ik niet voldoende heb aan bv plain Debian met Docker. Reden dat ik dat nu op het andere systeem niet gedaan heb is, voornamelijk, omdat Docker niet (eenvoudig) te gebruiken is in combinatie met VLANs. Lees: Docker stuurt het verkeer dan de deur uit op de default interface en zo. Terwijl ik bv Home Assistant alleen in het IoT VLAN wil hebben. De UniFi Controller alleen in het "default" VLAN, etc. Daarvoor heb ik wel ook weer een oplossing gevonden, maar is ook wat meer handwerk (in Docker zelf het netwerk aanmaken in combinatie met een optie om niet de iptables regel(s) aan te maken, en dat dan met de hand te doen met source nat). Alhoewel Docker in LXC op ZFS ook niet echt eenvoudig is . (Momenteel maak ik in Proxmox zelf een ZFS Volume aan, die format ik met ext4, die mount ik dan weer in de LXC op /var/lib/docker en ik maak een /etc/docker/daemon.json aan om de overlay2 driver te gebruiken. Alhoewel ik nu twijfel of het met driver configuratie nog uit maakt of ik hem naar een ext4 volume laat schrijven of rechtstreeks naar ZFS)

[nero355]

RobertMe schreef op zaterdag 10 december 2022 @ 18:42:
Proxmox is gewoon Debian, dus het is al een combinatie

Uiteraard!

Een Proxmox installatie bevat ook gewoon de Debian repos (Bullseye in geval van Proxmox 7), en de additionele Proxmox repo bevat vervolgens alleen de Proxmox specifieke stuff.

&

Niet "aparte Debian repository die je tijdelijk toevoegt" dus. Want je hebt gewoon de volledige Debian repo(s) tot je beschikking (bullseye, bullseye-update & bullseye-security zijn gewoon ingeschakeld voor main & contrib.

Dat wist ik effe niet meer, want de laatste keer dat ik daaraan heb gezeten is alweer een flinke tijd geleden...

Ik heb alleen nog non-free toegevoegd, omdat dan firmware-iwlwifi & firmware-realtek daarin zitten).

RobertMe schreef op zaterdag 10 december 2022 @ 22:50:
Zeer waarschijnlijk gevonden. Dit is nu Proxmox met pve-firmware in gebruik, met...
[Afbeelding]
Vergelijking gedaan tussen dmesg gerelateerd aan "firmware" met en zonder pve-firmware. En dan blijkt dat met firmware-linux-free firmware-iwlwifi firmware-realtek er geen "i915" firmware wordt ingeladen, voor de GPU (iGPU dan). Bij Debian zit die in firmware-misc-nonfree. Dat package geinstalleerd => reboot. En leek op "same shit" (grillig verbruik dus). Vervolgens pve-firmware geinstalleerd, de specifieke firmware file met het handje verwijderd, reboot. En bovenstaande screenshot is daarvan het resultaat.

Nu nog puzzelen of dit niet op een andere manier te bereiken valt (module uitschakelen? Inladen van firmware voorkomen?). Want even een file uit package verwijderen is niet echt onderhoudsvriendelijk (elke update van dit package opnieuw verwijderen? )

Kan je dat RealTek WLAN NICje niet gewoon uitbouwen
Anders aan de Modules modprobe Blacklist toevoegen ?!

RobertMe schreef op zondag 11 december 2022 @ 09:29:
De enige vragen zijn: waarom werkt dit? Bevat de iGPU een firmware die dit gedrag niet heeft? Of is de iGPU nu helemaal uitgeschakeld? Maar hoe krijg ik dan wel een terminal?; Wat zijn de gevolgen hiervan? Kan ik nu nog een desktop draaien? (In een VM) Waarschijnlijk niet? (Gebruik ik overigens ook nu niet). En is bv hardware offloading van video nu mogelijk? (Gebruik ik nu ook niet)

Als je de iGPU wilt Passthrough-en dan zou dat ook zonder een driver moeten kunnen denk ik...

Wat je ook kan doen : Via SPICE de Desktop VM via een andere PC/Laptop benaderen
Werkt echt geweldig goed! Zelfs met drie schermen actief!

[RobertMe]

nero355 schreef op zondag 11 december 2022 @ 16:05:
[...]

Kan je dat RealTek WLAN NICje niet gewoon uitbouwen

Er zit geen RealTek WLAN NICje in. Wel een LAN NICje van RealTek, en die doet het prima (behalve dat het RealTek is ). En daarnaast een Intel WLAN NICje, die het niet prima hoeft te doen, maar er zit ook een Intel "Bluetoothje" ingebakken, die ik wellicht wil gebruiken voor Home Assistant. Waarbij funnily enough de firmware voor de Bluetooth adapter niet in Proxmox / pve-firmware zit ingebakken, maar wel in firmware-iwlwifi.

Anders aan de Modules modprobe Blacklist toevoegen ?!

Het gaat over firmwares, niet drivers En een driver blacklisten lijkt mij juist ook weer niet handig (voor iets dat in principe werkt). In het geval van WLAN: ik gok dat het zuiniger is om iwlwifi wel te enablen / te gebruiken, maar vervolgens niks ermee te doen, dan de hele module / driver blacklisten. In het eerste geval kan de module / driver de WLAN chip immers uit zetten omdat die niet gebruikt wordt. In het tweede geval zal de WLAN chip niet uit gaan, omdat niks hem uit ziet / die helemaal niet wordt aangestuurd.

[...]

Als je de iGPU wilt Passthrough-en dan zou dat ook zonder een driver moeten kunnen denk ik...

Zonder driver? Wellicht. Zonder firmware? Not quite sure. Letterlijk zonder firmware zal de iGPU verwacht ik sowieso niet veel doen. Maar tegelijkertijd zal er ook wel ergens een firmware zijn ingebakken (hoe krijg ik anders beeld zonder firmware? En hoe heb je anders uberhaupt beeld in een BIOS?).

Wat je ook kan doen : Via SPICE de Desktop VM via een andere PC/Laptop benaderen
Werkt echt geweldig goed! Zelfs met drie schermen actief!

Nooit gedaan, en zal ik ook niet snel gaan doen gok ik Mijn laptop is beter, mijn desktop is net zo goed volgens benchmarks (i5, 6500 van ~7 jaar oud, vs een low end / budget Celeron van vorig jaar ).

[orvintax]

RobertMe schreef op zondag 11 december 2022 @ 09:29:
[...]

De oplossing met de dummy doet dat pve-firmware is dan niet geïnstalleerd en zal dus ook niet geupdate worden. En packages die een dependency hebben op pve-firmware kunnen gewoon gebruikt worden doordat de dummy die "provides". En met het gebruik van de Debian packages in de plaats heb ik wel gewoon de overige firmwares, en krijg ik daar updates voor.
De enige vragen zijn: waarom werkt dit? Bevat de iGPU een firmware die dit gedrag niet heeft? Of is de iGPU nu helemaal uitgeschakeld? Maar hoe krijg ik dan wel een terminal?; Wat zijn de gevolgen hiervan? Kan ik nu nog een desktop draaien? (In een VM) Waarschijnlijk niet? (Gebruik ik overigens ook nu niet). En is bv hardware offloading van video nu mogelijk? (Gebruik ik nu ook niet);


[...]

Nope. Hoe meer je toevoegt hoe lastiger het natuurlijk ook te vergelijken is etc.. En VMs wil ik sowieso niet, of maar minimaal, gebruiken. VMs zijn veel onzuiniger dan LXC, dus LXC is mijn goto.
Heb door dit verbruik ook nog even zitten zoeken of ik niet voldoende heb aan bv plain Debian met Docker. Reden dat ik dat nu op het andere systeem niet gedaan heb is, voornamelijk, omdat Docker niet (eenvoudig) te gebruiken is in combinatie met VLANs. Lees: Docker stuurt het verkeer dan de deur uit op de default interface en zo. Terwijl ik bv Home Assistant alleen in het IoT VLAN wil hebben. De UniFi Controller alleen in het "default" VLAN, etc. Daarvoor heb ik wel ook weer een oplossing gevonden, maar is ook wat meer handwerk (in Docker zelf het netwerk aanmaken in combinatie met een optie om niet de iptables regel(s) aan te maken, en dat dan met de hand te doen met source nat). Alhoewel Docker in LXC op ZFS ook niet echt eenvoudig is . (Momenteel maak ik in Proxmox zelf een ZFS Volume aan, die format ik met ext4, die mount ik dan weer in de LXC op /var/lib/docker en ik maak een /etc/docker/daemon.json aan om de overlay2 driver te gebruiken. Alhoewel ik nu twijfel of het met driver configuratie nog uit maakt of ik hem naar een ext4 volume laat schrijven of rechtstreeks naar ZFS)

Als ik me niet vergis kun je een GPU emuleren met je processor. Dit is natuurlijk niet efficient en kost relatief wel wat processing power. Dus je doet dit liever niet, maar het kan wel.

[RobertMe]

orvintax schreef op zondag 11 december 2022 @ 17:53:
[...]

Als ik me niet vergis kun je een GPU emuleren met je processor. Dit is natuurlijk niet efficient en kost relatief wel wat processing power. Dus je doet dit liever niet, maar het kan wel.

Blijft dan wel een beetje gek dat ik "zonder firmware" een lager verbruik zie dan "met firmware" Maar er zal vast wel ergens iets zijn ingebakken (mogelijk in BIOS zelf?) dat dan blijkbaar efficienter is.

Of het is zonder firmware / zonder GPU alsnog beter omdat het maar om een domme terminal gaat. Maar het vervolgens "mis gaat" bij het gebruik van Xorg / Wayland / ... dat veel meer van een GPU vraagt.

[nero355]

RobertMe schreef op zondag 11 december 2022 @ 18:40:
Of het is zonder firmware / zonder GPU alsnog beter omdat het maar om een domme terminal gaat. Maar het vervolgens "mis gaat" bij het gebruik van Xorg / Wayland / ... dat veel meer van een GPU vraagt.

Dat denk/verwacht ik dus ook!

[commentator]

weet iemand of ik een externe usb hardeschijf met btrfs en subvolumes direct kan mounten in een lxc?

[orvintax]

commentator schreef op maandag 26 december 2022 @ 21:23:
weet iemand of ik een externe usb hardeschijf met btrfs en subvolumes direct kan mounten in een lxc?

Je kunt die schijf toch gewoon mounten op je node en dan die subvolumes doorgeven? Direct de schijf doorgeven en laten beheren door de lxc kan ook. Je hebt opties

[maxxie85]

Ik probeer PCI passthrough voor elkaar te krijgen op mijn proxmox machine, maar ik kom er nog niet echt uit.

De host is een HP ProLiant ML350 G8, intel E5-2660 met 96GB RAM, met de 5.15.83-1-pve kernel.
In de BIOS heb ik VT-E en VT-D ingeschakeld. Ik heb de officiele guide gevolgd op https://pve.proxmox.com/wiki/Pci_passthrough.

Ik probeer een NVIDIA Quadro K2200 naar een Windows 10 VM door te schuiven. De K2000 staat op de officiële lijst van ondersteunde kaarten.

Het probleem waar ik tegen aan blijf lopen is de volgende error melding tijdens starten van de VM

vfio 0000:0a:00.0: failed to setup container for group 31: Failed to set iommu for container: Operation not permitted

Als afwijking op de officiële guide heb ik x2apic interrupt remapping uitgeschakeld omdat dit niet ondersteund word door mijn systeem. xapic interrupt remapping wordt wel ondersteunds dus ik heb die modus aangezet als interupt remapping. Alsnog heb ik unsafe interrupts aangezet omdat de VM niet wou starten, met altijd dezelfde melding

Als ik kijk naar de verschillende IOMMU groups die aangemaakt worden, lijkt het er wel op dat alle PCI devices een eigen IOMMU group toegewijst krijgt.

code:

/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/2/devices/0000:00:01.1
/sys/kernel/iommu_groups/3/devices/0000:00:02.0
/sys/kernel/iommu_groups/4/devices/0000:00:02.1
/sys/kernel/iommu_groups/5/devices/0000:00:02.2
/sys/kernel/iommu_groups/6/devices/0000:00:02.3
/sys/kernel/iommu_groups/7/devices/0000:00:03.0
/sys/kernel/iommu_groups/8/devices/0000:00:03.1
/sys/kernel/iommu_groups/9/devices/0000:00:03.2
/sys/kernel/iommu_groups/10/devices/0000:00:03.3
/sys/kernel/iommu_groups/11/devices/0000:00:04.0
/sys/kernel/iommu_groups/12/devices/0000:00:04.1
/sys/kernel/iommu_groups/13/devices/0000:00:04.2
/sys/kernel/iommu_groups/14/devices/0000:00:04.3
/sys/kernel/iommu_groups/15/devices/0000:00:04.4
/sys/kernel/iommu_groups/16/devices/0000:00:04.5
/sys/kernel/iommu_groups/17/devices/0000:00:04.6
/sys/kernel/iommu_groups/18/devices/0000:00:04.7
/sys/kernel/iommu_groups/19/devices/0000:00:05.0
/sys/kernel/iommu_groups/20/devices/0000:00:05.2
/sys/kernel/iommu_groups/21/devices/0000:00:05.4
/sys/kernel/iommu_groups/22/devices/0000:00:11.0
/sys/kernel/iommu_groups/23/devices/0000:00:1a.0
/sys/kernel/iommu_groups/24/devices/0000:00:1c.0
/sys/kernel/iommu_groups/25/devices/0000:00:1c.4
/sys/kernel/iommu_groups/26/devices/0000:00:1c.7
/sys/kernel/iommu_groups/27/devices/0000:00:1d.0
/sys/kernel/iommu_groups/28/devices/0000:00:1e.0
/sys/kernel/iommu_groups/29/devices/0000:00:1f.0
/sys/kernel/iommu_groups/29/devices/0000:00:1f.2
/sys/kernel/iommu_groups/30/devices/0000:03:00.0
/sys/kernel/iommu_groups/31/devices/0000:0a:00.0
/sys/kernel/iommu_groups/31/devices/0000:0a:00.1
/sys/kernel/iommu_groups/32/devices/0000:02:00.0
/sys/kernel/iommu_groups/32/devices/0000:02:00.1
/sys/kernel/iommu_groups/32/devices/0000:02:00.2
/sys/kernel/iommu_groups/32/devices/0000:02:00.3
/sys/kernel/iommu_groups/33/devices/0000:01:00.0
/sys/kernel/iommu_groups/33/devices/0000:01:00.1
/sys/kernel/iommu_groups/33/devices/0000:01:00.2
/sys/kernel/iommu_groups/33/devices/0000:01:00.4
/sys/kernel/iommu_groups/34/devices/0000:1f:08.0
/sys/kernel/iommu_groups/35/devices/0000:1f:09.0
/sys/kernel/iommu_groups/36/devices/0000:1f:0a.0
/sys/kernel/iommu_groups/36/devices/0000:1f:0a.1
/sys/kernel/iommu_groups/36/devices/0000:1f:0a.2
/sys/kernel/iommu_groups/36/devices/0000:1f:0a.3
/sys/kernel/iommu_groups/37/devices/0000:1f:0b.0
/sys/kernel/iommu_groups/37/devices/0000:1f:0b.3
/sys/kernel/iommu_groups/38/devices/0000:1f:0c.0
/sys/kernel/iommu_groups/38/devices/0000:1f:0c.1
/sys/kernel/iommu_groups/38/devices/0000:1f:0c.2
/sys/kernel/iommu_groups/38/devices/0000:1f:0c.3
/sys/kernel/iommu_groups/38/devices/0000:1f:0c.4
/sys/kernel/iommu_groups/39/devices/0000:1f:0d.0
/sys/kernel/iommu_groups/39/devices/0000:1f:0d.1
/sys/kernel/iommu_groups/39/devices/0000:1f:0d.2
/sys/kernel/iommu_groups/39/devices/0000:1f:0d.3
/sys/kernel/iommu_groups/39/devices/0000:1f:0d.4
/sys/kernel/iommu_groups/40/devices/0000:1f:0e.0
/sys/kernel/iommu_groups/40/devices/0000:1f:0e.1
/sys/kernel/iommu_groups/41/devices/0000:1f:0f.0
/sys/kernel/iommu_groups/42/devices/0000:1f:0f.1
/sys/kernel/iommu_groups/43/devices/0000:1f:0f.2
/sys/kernel/iommu_groups/44/devices/0000:1f:0f.3
/sys/kernel/iommu_groups/45/devices/0000:1f:0f.4
/sys/kernel/iommu_groups/46/devices/0000:1f:0f.5
/sys/kernel/iommu_groups/47/devices/0000:1f:10.0
/sys/kernel/iommu_groups/48/devices/0000:1f:10.1
/sys/kernel/iommu_groups/49/devices/0000:1f:10.2
/sys/kernel/iommu_groups/50/devices/0000:1f:10.3
/sys/kernel/iommu_groups/51/devices/0000:1f:10.4
/sys/kernel/iommu_groups/52/devices/0000:1f:10.5
/sys/kernel/iommu_groups/53/devices/0000:1f:10.6
/sys/kernel/iommu_groups/54/devices/0000:1f:10.7
/sys/kernel/iommu_groups/55/devices/0000:1f:13.0
/sys/kernel/iommu_groups/55/devices/0000:1f:13.1
/sys/kernel/iommu_groups/55/devices/0000:1f:13.4
/sys/kernel/iommu_groups/55/devices/0000:1f:13.5
/sys/kernel/iommu_groups/56/devices/0000:1f:16.0
/sys/kernel/iommu_groups/56/devices/0000:1f:16.1
/sys/kernel/iommu_groups/56/devices/0000:1f:16.2

Huidige configuratie:

VM configuratie

code:

agent: 1
bios: ovmf
boot: order=scsi0;net0;ide0
cores: 8
efidisk0: ssdtank:vm-204-disk-0,efitype=4m,pre-enrolled-keys=1,size=4M
hostpci0: 0000:0a:00.0,pcie=1,x-vga=1
machine: pc-q35-7.1
memory: 24576
meta: creation-qemu=7.0.0,ctime=1666000817
name: Win10
net0: virtio=76:A9:92:97:4B:0F,bridge=vmbr0,firewall=1
numa: 0
ostype: win10
scsi0: ssdtank:vm-204-disk-1,cache=writeback,discard=on,size=100G
scsihw: virtio-scsi-pci
smbios1: uuid=63230fd0-1551-4c26-88ab-12ab97014e8d
sockets: 1
tpmstate0: ssdtank:vm-204-disk-2,size=4M,version=v2.0
vmgenid: f119b314-bc18-46e6-ba5c-f9d77bec92f2

GRUB CMDLINE

code:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt nox2apic ntremap=no_x2apic_optout"

/etc/modules

code:

wireguard
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

/etc/modprobe.d/blacklist.conf

code:

blacklist radeon
blacklist nouveau
blacklist nvidia

/etc/modprobe.d/iommu_unsafe_interrupts.conf

code:

options vfio_iommu_type1 allow_unsafe_interrupts=1

Systeem output

dmesg | grep 'remapping'

code:

[    0.561344] DMAR-IR: Enabled IRQ remapping in xapic mode

edit:
Het lukt mij trouwens ook niet om de ROM uit te lezen om te kijken of deze UEFI compatible is. Ik krijg een Input/output error

code:

root@pve-ml350:/sys/bus/pci/devices/0000:0a:00.0# echo 1 > rom
root@pve-ml350:/sys/bus/pci/devices/0000:0a:00.0# cat rom 
cat: rom: Input/output error
root@pve-ml350:/sys/bus/pci/devices/0000:0a:00.0# echo 0 > rom
root@pve-ml350:/sys/bus/pci/devices/0000:0a:00.0#

[ Voor 3% gewijzigd door maxxie85 op 02-01-2023 14:00 ]

[nero355]

maxxie85 schreef op maandag 2 januari 2023 @ 13:55:
De host is een HP ProLiant ML350 G8, intel E5-2660

edit:
Het lukt mij trouwens ook niet om de ROM uit te lezen om te kijken of deze UEFI compatible is.

Volgens mij was de G8 serie nog steeds een BIOS reeks en kwam de keuze tussen BIOS of UEFI pas vanaf de G9 serie erbij

[maxxie85]

nero355 schreef op maandag 2 januari 2023 @ 15:06:
[...]

Volgens mij was de G8 serie nog steeds een BIOS reeks en kwam de keuze tussen BIOS of UEFI pas vanaf de G9 serie erbij

Ja dat zou heel goed kunnen. Het ziet er ook echt uit als een BIOS en niet als een UEFI.

Maar daardoor is de ROM niet leesbaar? Kan ik begrijpen. Heeft dat ook invloed op passtrough?

[nero355]

maxxie85 schreef op maandag 2 januari 2023 @ 15:23:
Maar daardoor is de ROM niet leesbaar? Kan ik begrijpen.

Daar gok ik inderdaad op

Heeft dat ook invloed op passtrough?

Als het goed is alleen op het gebruik van NVMe SSD's want je hebt UEFI nodig om daarvan te booten!

Wat ik je wel als TIP mee kan geven :
- Pak een .rpm based Linux distro Live Boot vanaf een USB Stick.
Dus iets van CentOS of Fedora bijvoorbeeld.
- Struin de HPE website af voor alle mogelijke bruikbare updates die je kan vinden voor je DL350 G8 en de hardware die erin zit om eventuele firmware problemen omtrent VT-D voor te zijn!

[Oesie]

Van de week werkte één naar van mijn VM's niet meer. Met hulp van Google ben ik erachter gekomen dat de data folder vol was gelopen. Echter is me niet helemaal duidelijk waardoor. Ik heb één van mijn ongebruikte VM's verwijderd waardoor de andere weer kon booten. Echter is de gebruikte space bijna 100%. Dus ben bang dat ik straks weer tegen het probleem aan loop. Echter heb ik dan niet meer de mogelijkheid om een VM te verwijderen.

Hebben jullie een tip waar naar te kijken?.

code:

:~# pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        15117272         3267104        11060460   21.61%
local-lvm     lvmthin     active        29360128        28059474         1300653   95.57%

code:

~# lsblk
NAME                         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                            8:0    0 59.6G  0 disk 
├─sda1                         8:1    0 1007K  0 part 
├─sda2                         8:2    0  512M  0 part /boot/efi
└─sda3                         8:3    0 59.1G  0 part 
  ├─pve-swap                 253:0    0    7G  0 lvm  [SWAP]
  ├─pve-root                 253:1    0 14.8G  0 lvm  /
  ├─pve-data_tmeta           253:2    0    1G  0 lvm  
  │ └─pve-data-tpool         253:4    0   28G  0 lvm  
  │   ├─pve-data             253:5    0   28G  1 lvm  
  │   ├─pve-vm--100--disk--0 253:6    0    4M  0 lvm  
  │   ├─pve-vm--100--disk--1 253:7    0   36G  0 lvm  
  │   └─pve-vm--101--disk--0 253:8    0    1G  0 lvm  
  └─pve-data_tdata           253:3    0   28G  0 lvm  
    └─pve-data-tpool         253:4    0   28G  0 lvm  
      ├─pve-data             253:5    0   28G  1 lvm  
      ├─pve-vm--100--disk--0 253:6    0    4M  0 lvm  
      ├─pve-vm--100--disk--1 253:7    0   36G  0 lvm  
      └─pve-vm--101--disk--0 253:8    0    1G  0 lvm

[ Voor 7% gewijzigd door Oesie op 07-01-2023 13:25 ]

[TigerMooD]

Dit heb ik zelf een keer gehad omdat ik een pfsense machine met logging aan had staan en een iets te hoge maximum diskspace (overprovisioned), die liep langzaam de storage vol te gooien.
Heb je misschien een VM of container die data genereert en opslaat?

[Oesie]

TigerMooD schreef op zaterdag 7 januari 2023 @ 15:32:
Dit heb ik zelf een keer gehad omdat ik een pfsense machine met logging aan had staan en een iets te hoge maximum diskspace (overprovisioned), die liep langzaam te storage vol te gooien.
Heb je misschien een VM of container die data genereert en opslaat?

Jazeker, een VM met HAOS / Home Assistant.

Ik dacht ook dat daar de fout zat in eerste instantie. Heb toen de disk in PVE van 32 GB naar 36 GB vergroot (achteraf was dat niet het probleem, deze vergroting werd niet doorgevoerd voordat ik een andere VM had verwijderd). In PVE GUI geeft die nu echter niet het gebruik aan.

Via de CLI zie ik onderstaande. Lijkt me dus dat er nog genoeg ruimte is of zie ik iets over het hoofd?

code:

root@pve:~# lvs
  LV                           VG  Attr       LSize  Pool Origin        Data%  Meta%  Move Log Cpy%Sync Convert
  data                         pve twi-aotz-- 28.00g                    96.03  2.54                            
  root                         pve -wi-ao---- 14.75g                                                           
  snap_vm-100-disk-0_Snapshot1 pve Vri---tz-k  4.00m data vm-100-disk-0                                        
  snap_vm-100-disk-1_Snapshot1 pve Vri---tz-k 36.00g data vm-100-disk-1                                        
  swap                         pve -wi-ao----  7.00g                                                           
  vm-100-disk-0                pve Vwi-aotz--  4.00m data               0.00                                   
  vm-100-disk-1                pve Vwi-aotz-- 36.00g data               71.65                                  
  vm-101-disk-0                pve Vwi-aotz--  1.00g data               96.51

[orvintax]

Oesie schreef op zaterdag 7 januari 2023 @ 13:19:
Van de week werkte één naar van mijn VM's niet meer. Met hulp van Google ben ik erachter gekomen dat de data folder vol was gelopen. Echter is me niet helemaal duidelijk waardoor. Ik heb één van mijn ongebruikte VM's verwijderd waardoor de andere weer kon booten. Echter is de gebruikte space bijna 100%. Dus ben bang dat ik straks weer tegen het probleem aan loop. Echter heb ik dan niet meer de mogelijkheid om een VM te verwijderen.

Hebben jullie een tip waar naar te kijken?.

[Afbeelding]

code:

:~# pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        15117272         3267104        11060460   21.61%
local-lvm     lvmthin     active        29360128        28059474         1300653   95.57%

code:

~# lsblk
NAME                         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                            8:0    0 59.6G  0 disk 
├─sda1                         8:1    0 1007K  0 part 
├─sda2                         8:2    0  512M  0 part /boot/efi
└─sda3                         8:3    0 59.1G  0 part 
  ├─pve-swap                 253:0    0    7G  0 lvm  [SWAP]
  ├─pve-root                 253:1    0 14.8G  0 lvm  /
  ├─pve-data_tmeta           253:2    0    1G  0 lvm  
  │ └─pve-data-tpool         253:4    0   28G  0 lvm  
  │   ├─pve-data             253:5    0   28G  1 lvm  
  │   ├─pve-vm--100--disk--0 253:6    0    4M  0 lvm  
  │   ├─pve-vm--100--disk--1 253:7    0   36G  0 lvm  
  │   └─pve-vm--101--disk--0 253:8    0    1G  0 lvm  
  └─pve-data_tdata           253:3    0   28G  0 lvm  
    └─pve-data-tpool         253:4    0   28G  0 lvm  
      ├─pve-data             253:5    0   28G  1 lvm  
      ├─pve-vm--100--disk--0 253:6    0    4M  0 lvm  
      ├─pve-vm--100--disk--1 253:7    0   36G  0 lvm  
      └─pve-vm--101--disk--0 253:8    0    1G  0 lvm

Misschien dat ik je vraag verkeerd begrijp, maar wat heeft dit met Proxmox te maken? De software binnen in je VM is hem toch de disk aan het volgooien?

[dcm360]

Oesie schreef op zaterdag 7 januari 2023 @ 15:43:
[...]

Jazeker, een VM met HAOS / Home Assistant.

Ik dacht ook dat daar de fout zat in eerste instantie. Heb toen de disk in PVE van 32 GB naar 36 GB vergroot (achteraf was dat niet het probleem, deze vergroting werd niet doorgevoerd voordat ik een andere VM had verwijderd). In PVE GUI geeft die nu echter niet het gebruik aan.

Via de CLI zie ik onderstaande. Lijkt me dus dat er nog genoeg ruimte is of zie ik iets over het hoofd?

code:

root@pve:~# lvs
  LV                           VG  Attr       LSize  Pool Origin        Data%  Meta%  Move Log Cpy%Sync Convert
  data                         pve twi-aotz-- 28.00g                    96.03  2.54                            
  root                         pve -wi-ao---- 14.75g                                                           
  snap_vm-100-disk-0_Snapshot1 pve Vri---tz-k  4.00m data vm-100-disk-0                                        
  snap_vm-100-disk-1_Snapshot1 pve Vri---tz-k 36.00g data vm-100-disk-1                                        
  swap                         pve -wi-ao----  7.00g                                                           
  vm-100-disk-0                pve Vwi-aotz--  4.00m data               0.00                                   
  vm-100-disk-1                pve Vwi-aotz-- 36.00g data               71.65                                  
  vm-101-disk-0                pve Vwi-aotz--  1.00g data               96.51

Op vm-100-disk-1 is er inderdaad nog vrije ruimte, maar pve-data-tpool is vol, dus vm-100-disk-1 kan geen ruimte uit de pool meer pakken om daadwerkelijk naar te kunnen schrijven. Hoewel een constructie met een virtuele schijf groter dan de pool wel mag, zou ik dat ten zeerste afraden, want je weet vooraf al dat de beschikbare ruimte eerder op is dan de virtuele schijf vol is.

Dan nu de vraag hoe dit op te lossen valt. Als de VM minder ruimte in gebruik heeft dan dat LVM nu aangeeft, zou dat er op kunnen wijzen dat TRIM/DISCARD niet werkt. LVM-thin vertoont SSD-achtig gedrag, waardoor je op Proxmox bij de virtuele schijf moet aangeven dat het een SSD is met TRIM/DISCARD-ondersteuning, en de VM moet ook TRIM/DISCARD toepassen op de schijf om vrije ruimte weer terug te geven. Mijn eerste hit op Google was per ongeluk meteen raak met een artikeltje dat wat daarover uitlegt: https://gist.github.com/h...1e50cc0666f1745e1897c0a56

[tomdh76]

Mijn hele huisnetwerk heb ik ondertussen op een server met proxmox inclusief ook OPNsense router. Nu maak ik me een beetje zorgen als die server hardware matig kapot gaat en ik dan eigenlijk zo snel mogelijk weer alles up and running wil hebben. Ik maak backups van de VM's dus dat is geen probleem maar meer de algehele configuratie van proxmox.
Nu zag ik dit voorbij komen https://github.com/DerDanilo/proxmox-stuff
Heeft iemand ervaring hiermee of zelf een goede strategie om in geval van hardware issues snel weer online te zijn? Of moet ik aan een cluster toegeven..

[A1AD]

tomdh76 schreef op zaterdag 7 januari 2023 @ 17:58:
Mijn hele huisnetwerk heb ik ondertussen op een server met proxmox inclusief ook OPNsense router. Nu maak ik me een beetje zorgen als die server hardware matig kapot gaat en ik dan eigenlijk zo snel mogelijk weer alles up and running wil hebben. Ik maak backups van de VM's dus dat is geen probleem maar meer de algehele configuratie van proxmox.
Nu zag ik dit voorbij komen https://github.com/DerDanilo/proxmox-stuff
Heeft iemand ervaring hiermee of zelf een goede strategie om in geval van hardware issues snel weer online te zijn? Of moet ik aan een cluster toegeven..

Ik heb een OpenWRT router als cold backup apparaat met ongeveer dezelfde config als mijn opnsense router.

[ZatarraNL]

tomdh76 schreef op zaterdag 7 januari 2023 @ 17:58:
Mijn hele huisnetwerk heb ik ondertussen op een server met proxmox inclusief ook OPNsense router. Nu maak ik me een beetje zorgen als die server hardware matig kapot gaat en ik dan eigenlijk zo snel mogelijk weer alles up and running wil hebben. Ik maak backups van de VM's dus dat is geen probleem maar meer de algehele configuratie van proxmox.
Nu zag ik dit voorbij komen https://github.com/DerDanilo/proxmox-stuff
Heeft iemand ervaring hiermee of zelf een goede strategie om in geval van hardware issues snel weer online te zijn? Of moet ik aan een cluster toegeven..

Ik heb een 3 node cluster draaien met ceph en high availability. Werkt wel mooi. Niet meer afhankelijk van een fail van een node. De derde node is trouwens een hele eenvoudige ryzen 3 mini pc. Die is eigenlijk alleen bedoeld voor de benodigde votes. De andere beide nodes hebben wat meer vermogen voor diverse VMs.

[rachez]

Oesie schreef op zaterdag 7 januari 2023 @ 13:19:
Van de week werkte één naar van mijn VM's niet meer. Met hulp van Google ben ik erachter gekomen dat de data folder vol was gelopen. Echter is me niet helemaal duidelijk waardoor. Ik heb één van mijn ongebruikte VM's verwijderd waardoor de andere weer kon booten. Echter is de gebruikte space bijna 100%. Dus ben bang dat ik straks weer tegen het probleem aan loop. Echter heb ik dan niet meer de mogelijkheid om een VM te verwijderen.

Hebben jullie een tip waar naar te kijken?.

[Afbeelding]

code:

:~# pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        15117272         3267104        11060460   21.61%
local-lvm     lvmthin     active        29360128        28059474         1300653   95.57%

code:

~# lsblk
NAME                         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                            8:0    0 59.6G  0 disk 
├─sda1                         8:1    0 1007K  0 part 
├─sda2                         8:2    0  512M  0 part /boot/efi
└─sda3                         8:3    0 59.1G  0 part 
  ├─pve-swap                 253:0    0    7G  0 lvm  [SWAP]
  ├─pve-root                 253:1    0 14.8G  0 lvm  /
  ├─pve-data_tmeta           253:2    0    1G  0 lvm  
  │ └─pve-data-tpool         253:4    0   28G  0 lvm  
  │   ├─pve-data             253:5    0   28G  1 lvm  
  │   ├─pve-vm--100--disk--0 253:6    0    4M  0 lvm  
  │   ├─pve-vm--100--disk--1 253:7    0   36G  0 lvm  
  │   └─pve-vm--101--disk--0 253:8    0    1G  0 lvm  
  └─pve-data_tdata           253:3    0   28G  0 lvm  
    └─pve-data-tpool         253:4    0   28G  0 lvm  
      ├─pve-data             253:5    0   28G  1 lvm  
      ├─pve-vm--100--disk--0 253:6    0    4M  0 lvm  
      ├─pve-vm--100--disk--1 253:7    0   36G  0 lvm  
      └─pve-vm--101--disk--0 253:8    0    1G  0 lvm

volgens mij probeer je 37GB weg te schrijven op een echte disk van 30GB. Zolang je vm onder die 30GB blijft gaat het goed, maar als je eroverheen gaat (in je vm) dan is je pool vol.

Heb je nog snapshots open staan, dan zou die als eerste verwijderen. Als dat geen ruimte oplevert kan je eigenlijk alleen storage erbij zetten, en je vm daarheen moven.

[bladebla]

tomdh76 schreef op zaterdag 7 januari 2023 @ 17:58:
Mijn hele huisnetwerk heb ik ondertussen op een server met proxmox inclusief ook OPNsense router. Nu maak ik me een beetje zorgen als die server hardware matig kapot gaat en ik dan eigenlijk zo snel mogelijk weer alles up and running wil hebben. Ik maak backups van de VM's dus dat is geen probleem maar meer de algehele configuratie van proxmox.
Nu zag ik dit voorbij komen https://github.com/DerDanilo/proxmox-stuff
Heeft iemand ervaring hiermee of zelf een goede strategie om in geval van hardware issues snel weer online te zijn? Of moet ik aan een cluster toegeven..

Begrijp je zorg en denk er van tijd tot tijd ook over na maar in de (financiële) afweging accepteer ik dat als er iets mis gaat, dat het er dan maar even uit ligt en bestel wat er nodig is. Een cluster is absoluut leuk en interessant maar ik heb wat VM's met hardware passthrough en dan is het alweer wat lastiger. Daarnaast dubbele hardware afschrijving en stroomkosten.
In mijn persoonlijke ervaring heb ik vooral, of misschien wel alleen, hdd's en voedingen stuk zien gaan. Ik heb daarom vorig jaar een reserve voeding op de plank gelegd, ook vanwege de afwijkende form factor.

Bij een volledig nieuwe installatie kan ik mijn VM's en containers redelijk snel restoren. Natuurlijk wat ongemakken met het instellen van bridges en vlan's maar dat kun je ook documenteren. Oh, en geen DHCP server beschikbaar want OPNsense draait niet, dus die NAS met backups zonder fixed IP is niet bereikbaar, maar daar kom je ook wel weer uit. Wellicht wat nuttige info halen uit configs die zijn gebackupt uit een script zoals je die aanhaalt. Ik zou niet kunnen beoordelen of zo'n script volledig is en blijft bij toekomstige PM versies; zou het restore script niet gebruiken.

Én ik heb geen SLA met mijn vrouw vastgelegd.

[powerboat]

tomdh76 schreef op zaterdag 7 januari 2023 @ 17:58:
Mijn hele huisnetwerk heb ik ondertussen op een server met proxmox inclusief ook OPNsense router. Nu maak ik me een beetje zorgen als die server hardware matig kapot gaat en ik dan eigenlijk zo snel mogelijk weer alles up and running wil hebben. Ik maak backups van de VM's dus dat is geen probleem maar meer de algehele configuratie van proxmox.
Nu zag ik dit voorbij komen https://github.com/DerDanilo/proxmox-stuff
Heeft iemand ervaring hiermee of zelf een goede strategie om in geval van hardware issues snel weer online te zijn? Of moet ik aan een cluster toegeven..

Denk dat je het jezelf niet zo moeilijk moet maken. Zorg voor goede backup middels nas (met vast ip) of zelfs een usb disk, zodat je die snel kan mounten en herstel kan inzetten zodra de andere hardware beschikbaar is.

[lolgast]

Ik backup mijn VMs en LXCs ook elke nacht naar een USB disk en elke zoveel dagen naar Backblaze. Mocht mijn proxmox de geest geven heb ik nog wel een oude computer om het op te zetten en is het via de USB disk vrij snel weer up en running (genoeg). Als de server én de USB disk tegelijk stuk gaan heb ik denk ik grotere zorgen

[Oesie]

Vanmorgen is helaas weer mijn HAOS VM vast gelopen door hetzelfde probleem. Wat me eerlijk gezegd wel een beetje verbaasde aangezien ik gisteren (o.a. naar aanleiding van jullie tips) 3 maanden aan dagelijkse backups heb verwijderd binnen de HAOS VM. Dat is eigenlijk ook de enige substantiele data die wordt gegenereerd.

Hiermee heb ik het idee dat het probleem niet binnen de VM zit. Dat lijkt HAOS ook te bevestigen want die geeft aan dat er 27% gebruikt is van de beschikbare ruimte (nog 24 GB vrij).

Dus ik moet sowieso op zoek wat de groei binnen de PVE data folder veroorzaakt (en nu ook niet lijkt in te zakken met het verwijderen van één machine in PVE en de backups binnen de HAOS VM). En weet eerlijk gezegd niet zo goed waar ik moet beginnen. Heb nu namelijk nog maar twee VM's. Een met HAOS welke ik dus eigenlijk uit sluit en de andere een Adguard Home container met nog geen 1GB aan disk size.

Bovenstaande gaat dus puur over het de datagroei welke ik niet kan verklaren maar wellicht op dit moment wat minder relevant. Ik wil voorkomen dat ik morgen weer het probleem heb en dan echt niks meer kan verwijderen (kon vanmorgen nog één snapshot) weg doen.

Dan hebben jullie nog gewezen op de toewijzing van disk space. Daar lijkt inderdaad wat verkeerd te gaan. En dat zal vast door mijn onervarenheid zijn. Had uberhaupt niet gedacht dat je via de standaard stappen meer kon toewijzen dat er is. Maar als ik het goed begrijp moet hier wel de oplossing van het probleem liggen dat de VM vast loopt.

Hieronder wat meer gegevens van de node. Het betreft een SSD van 64 GB.
Uit de gegevens hieronder maak ik op dat ik de 'pve_data' folder moet vergroten. Klopt dat? Zo ja, waar en hoe zou ik dat moeten aanpakken?

code:

root@pve:~# pvs
  PV         VG  Fmt  Attr PSize  PFree
  /dev/sda3  pve lvm2 a--  59.12g 7.37g

root@pve:~# vgs
  VG  #PV #LV #SN Attr   VSize  VFree
  pve   1   6   0 wz--n- 59.12g 7.37g

root@pve:~# lvs
  LV            VG  Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data          pve twi-aotz-- 28.00g             96.00  2.50                            
  root          pve -wi-ao---- 14.75g                                                    
  swap          pve -wi-ao----  7.00g                                                    
  vm-100-disk-0 pve Vwi-aotz--  4.00m data        0.00                                   
  vm-100-disk-1 pve Vwi-aotz-- 36.00g data        71.99                                  
  vm-101-disk-0 pve Vwi-aotz--  1.00g data        96.51

root@pve:~# pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        15117272         3268132        11059432   21.62%
local-lvm     lvmthin     active        29360128        28185722         1174405   96.00%

root@pve:~# lsblk
NAME                         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda                            8:0    0 59.6G  0 disk 
├─sda1                         8:1    0 1007K  0 part 
├─sda2                         8:2    0  512M  0 part /boot/efi
└─sda3                         8:3    0 59.1G  0 part 
  ├─pve-swap                 253:0    0    7G  0 lvm  [SWAP]
  ├─pve-root                 253:1    0 14.8G  0 lvm  /
  ├─pve-data_tmeta           253:2    0    1G  0 lvm  
  │ └─pve-data-tpool         253:4    0   28G  0 lvm  
  │   ├─pve-data             253:5    0   28G  1 lvm  
  │   ├─pve-vm--100--disk--0 253:6    0    4M  0 lvm  
  │   ├─pve-vm--100--disk--1 253:7    0   36G  0 lvm  
  │   └─pve-vm--101--disk--0 253:8    0    1G  0 lvm  
  └─pve-data_tdata           253:3    0   28G  0 lvm  
    └─pve-data-tpool         253:4    0   28G  0 lvm  
      ├─pve-data             253:5    0   28G  1 lvm  
      ├─pve-vm--100--disk--0 253:6    0    4M  0 lvm  
      ├─pve-vm--100--disk--1 253:7    0   36G  0 lvm  
      └─pve-vm--101--disk--0 253:8    0    1G  0 lvm

orvintax schreef op zaterdag 7 januari 2023 @ 16:41:
[...]

Misschien dat ik je vraag verkeerd begrijp, maar wat heeft dit met Proxmox te maken? De software binnen in je VM is hem toch de disk aan het volgooien?

Dat dacht ik in eerste instantie ook. Al hoewel ik dat niet voor mezelf kon verklaren omdat daar geen grote files worden opgeslagen. Zie ook hierboven.

dcm360 schreef op zaterdag 7 januari 2023 @ 16:51:
[...]

Op vm-100-disk-1 is er inderdaad nog vrije ruimte, maar pve-data-tpool is vol, dus vm-100-disk-1 kan geen ruimte uit de pool meer pakken om daadwerkelijk naar te kunnen schrijven. Hoewel een constructie met een virtuele schijf groter dan de pool wel mag, zou ik dat ten zeerste afraden, want je weet vooraf al dat de beschikbare ruimte eerder op is dan de virtuele schijf vol is.

Dan nu de vraag hoe dit op te lossen valt. Als de VM minder ruimte in gebruik heeft dan dat LVM nu aangeeft, zou dat er op kunnen wijzen dat TRIM/DISCARD niet werkt. LVM-thin vertoont SSD-achtig gedrag, waardoor je op Proxmox bij de virtuele schijf moet aangeven dat het een SSD is met TRIM/DISCARD-ondersteuning, en de VM moet ook TRIM/DISCARD toepassen op de schijf om vrije ruimte weer terug te geven. Mijn eerste hit op Google was per ongeluk meteen raak met een artikeltje dat wat daarover uitlegt: https://gist.github.com/h...1e50cc0666f1745e1897c0a56

Dank, is met de extra info je tip nog de route denk je?

rachez schreef op zaterdag 7 januari 2023 @ 19:10:
[...]

volgens mij probeer je 37GB weg te schrijven op een echte disk van 30GB. Zolang je vm onder die 30GB blijft gaat het goed, maar als je eroverheen gaat (in je vm) dan is je pool vol.

Heb je nog snapshots open staan, dan zou die als eerste verwijderen. Als dat geen ruimte oplevert kan je eigenlijk alleen storage erbij zetten, en je vm daarheen moven.

Echte disk is dus 64GB.
HAOS geeft aan dat er nog 24 GB ruimte vrij is dus ook opmerkelijk.
Straks sowieso maar even kijken hoe ik een copy kan maken voordat alles vast loopt en ik verder van huis ben.

[bes-r]

Oesie schreef op zondag 8 januari 2023 @ 11:03:
vraag

Heb je ook al naar de database gekeken? Wellicht bewaar je de data erg lang en is je database volgelopen.

[dcm360]

Oesie schreef op zondag 8 januari 2023 @ 11:03:
[...]

Dank, is met de extra info je tip nog de route denk je?


[...]

Echte disk is dus 64GB.
HAOS geeft aan dat er nog 24 GB ruimte vrij is dus ook opmerkelijk.
Straks sowieso maar even kijken hoe ik een copy kan maken voordat alles vast loopt en ik verder van huis ben.

De echte disk is dan wel 64GB, maar je hebt een 'partitie' van 30GB waarin alle data moet passen.
Met de extra informatie die je nu geeft is voor mij wel duidelijk dat de oplossing die ik gaf gaat werken: je moet er voor zorgen dat de VM door middel van TRIM aan de host doorgeeft dat vrijgemaakte ruimte ook weer beschikbaar is.

[rachez]

dcm360 schreef op zondag 8 januari 2023 @ 12:57:
[...]

De echte disk is dan wel 64GB, maar je hebt een 'partitie' van 30GB waarin alle data moet passen.
Met de extra informatie die je nu geeft is voor mij wel duidelijk dat de oplossing die ik gaf gaat werken: je moet er voor zorgen dat de VM door middel van TRIM aan de host doorgeeft dat vrijgemaakte ruimte ook weer beschikbaar is.

Klopt, zijn data partitie is maar 30GB.
Maar als hij doet wat jij voorstelt dan moet je wel ook de VM disk verkleinen naar iets kleiner dan 30GB. Die lijkt nu 36GB te zijn, tenminste als dit de 'probleem vm' is:

code:

vm-100-disk-1                pve Vwi-aotz-- 36.00g data

Anders ben je over een paar maanden weer terug bij af.

[rachez]

Oesie schreef op zondag 8 januari 2023 @ 11:03:

Hiermee heb ik het idee dat het probleem niet binnen de VM zit. Dat lijkt HAOS ook te bevestigen want die geeft aan dat er 27% gebruikt is van de beschikbare ruimte (nog 24 GB vrij).

Dat zou TRIM dus moeten oplossen wat dcm360 aangaf.

Straks sowieso maar even kijken hoe ik een copy kan maken voordat alles vast loopt en ik verder van huis ben.

backup naar een nas is sowieso een goed plan. Je kan gewoon een share mounten in de de proxmox ui en daarnaartoe een backup maken.

Bestaande pve-data pool vergroten kan wel, ik heb het alleen nooit gedaan op debian.
Persoonlijk zou ik een 500GB disk erbij zetten, die mounten als nieuwe storage dedicated voor je vms en daar je bestaande vms naar toe moven: server view > vm selecteren > hardware > harddisk selecteren > disk action > move storage.

[Oesie]

bes-r schreef op zondag 8 januari 2023 @ 11:09:
[...]


Heb je ook al naar de database gekeken? Wellicht bewaar je de data erg lang en is je database volgelopen.

Heb de standaard waardes van HAOS in gebruik. Database is nu 500 MB.

rachez schreef op zondag 8 januari 2023 @ 16:25:
[...]

Dat zou TRIM dus moeten oplossen wat dcm360 aangaf.


[...]

backup naar een nas is sowieso een goed plan. Je kan gewoon een share mounten in de de proxmox ui en daarnaartoe een backup maken.

Bestaande pve-data pool vergroten kan wel, ik heb het alleen nooit gedaan op debian.
Persoonlijk zou ik een 500GB disk erbij zetten, die mounten als nieuwe storage dedicated voor je vms en daar je bestaande vms naar toe moven: server view > vm selecteren > hardware > harddisk selecteren > disk action > move storage.

Muchos gracias, heb zojuist backups gedraaid naar mijn NAS.
Morgen naar de rest kijken.

[ Voor 17% gewijzigd door Oesie op 08-01-2023 22:21 ]

[nero355]

Oesie schreef op zondag 8 januari 2023 @ 11:03:
Dus ik moet sowieso op zoek wat de groei binnen de PVE data folder veroorzaakt (en nu ook niet lijkt in te zakken met het verwijderen van één machine in PVE en de backups binnen de HAOS VM). En weet eerlijk gezegd niet zo goed waar ik moet beginnen.

Onlangs moeten verklaren waarom ik 16 GB van de 32 GB in gebruik heb op een systeem waar hooguit 8 GB in gebruik zou moeten zijn en du was mijn beste vriend om daar achter te komen :

code:

du -h --threshold=1G | more
du -h --threshold=100M | more
du -h --threshold=10M | more
du -h --threshold=1M | more
du -h --threshold=100kB | more
du -h --threshold=1kB | more

enz.

Handmatig T.R.I.M. activeren kan trouwens met

# fstrim -a

Succes alvast!

[Koepert]

Hoi, beetje een bijzondere vraag wellicht.. maar ik heb het volgende:

- Dell Optiplex 1x 500GB HDD met Proxmox 7.3.3 in een cluster (op deze is cluster gemaakt)
- HP PRoDesk 800 Mini 1x 128GB SSD met Proxmox 7.3.3 die vandaag hetzelfde cluster gejoind heeft.

Nu DENK ik, dat mijn 500GB HDD wat op leeftijd raakt.. (nog geen alarmbellen, maar die wil ik graag voor zijn aangezien momenteel mijn smarthome, DNS/Pi-hole en Traefik hierop draaien.

1 host met 1 disk kun je wat van vinden, daarom nu ook een cluster.. maar is het volgende scenario een optie?

ik koop 2x een XGB SSD (250 minimaal) en doe dan het volgende:
- Migreer de 2 containers en 1 VM naar mn Prodesk
- Optiplex uitzetten, schijf vervangen, proxmox opnieuw installeren, cluster joinen;
- Migreer alle spul weer terug naar de Prodesk;
- Zet de Prodesk uit, vervang de schijf, installeer proxmox opnieuw, join cluster weer

Kan zoiets of is dat een probleem omdat de Optiplex de 'eigenaar/maker' van het cluster is?

[RobertMe]

Koepert schreef op donderdag 12 januari 2023 @ 11:08:
Hoi, beetje een bijzondere vraag wellicht.. maar ik heb het volgende:

- Dell Optiplex 1x 500GB HDD met Proxmox 7.3.3 in een cluster (op deze is cluster gemaakt)
- HP PRoDesk 800 Mini 1x 128GB SSD met Proxmox 7.3.3 die vandaag hetzelfde cluster gejoind heeft.

Nu DENK ik, dat mijn 500GB HDD wat op leeftijd raakt.. (nog geen alarmbellen, maar die wil ik graag voor zijn aangezien momenteel mijn smarthome, DNS/Pi-hole en Traefik hierop draaien.

1 host met 1 disk kun je wat van vinden, daarom nu ook een cluster.. maar is het volgende scenario een optie?

ik koop 2x een XGB SSD (250 minimaal) en doe dan het volgende:
- Migreer de 2 containers en 1 VM naar mn Prodesk
- Optiplex uitzetten, schijf vervangen, proxmox opnieuw installeren, cluster joinen;
- Migreer alle spul weer terug naar de Prodesk;
- Zet de Prodesk uit, vervang de schijf, installeer proxmox opnieuw, join cluster weer

Kan zoiets of is dat een probleem omdat de Optiplex de 'eigenaar/maker' van het cluster is?

Geen antwoord op de vraag, maar is een 2 node cluster niet vragen om problemen v.w.b. "split brain"? Als de ene node "A" zegt en de andere node "B", wat moet dan gedaan worden? Je hebt dan een derde node nodig die dus ook A of B zegt zodat er ook een "winnaar" is.

Verder zou ik persoonlijk in het geval dat de nodes ZFS gebruiken via een ZFS mirror de disk erbij plaatsen. Dan hoef je überhaupt geen herinstallatie te doen. Alleen heb je dan het probleem dat je een "downgrade" doet van 500GB naar 250GB en dat gaat natuurlijk niet. En uiteraard moet je dan nu al ZFS gebruiken.

[Koepert]

Mja,. daar heb je een punt.. wist ik eigenlijk niet.. maar dit was ook meer omdat ik beide hosts toevallig had en de ene de vervanging van de andere zou zijn.. dit leek me een soort 'soft migration'..

Op dit moment geen ZFS.. en wil liever niet alles opnieuw opbouwen.. ivm 'leunen van mijn huis' op de aanwezige containers/vms.

[orvintax]

Koepert schreef op donderdag 12 januari 2023 @ 11:08:
Hoi, beetje een bijzondere vraag wellicht.. maar ik heb het volgende:

- Dell Optiplex 1x 500GB HDD met Proxmox 7.3.3 in een cluster (op deze is cluster gemaakt)
- HP PRoDesk 800 Mini 1x 128GB SSD met Proxmox 7.3.3 die vandaag hetzelfde cluster gejoind heeft.

Nu DENK ik, dat mijn 500GB HDD wat op leeftijd raakt.. (nog geen alarmbellen, maar die wil ik graag voor zijn aangezien momenteel mijn smarthome, DNS/Pi-hole en Traefik hierop draaien.

1 host met 1 disk kun je wat van vinden, daarom nu ook een cluster.. maar is het volgende scenario een optie?

ik koop 2x een XGB SSD (250 minimaal) en doe dan het volgende:
- Migreer de 2 containers en 1 VM naar mn Prodesk
- Optiplex uitzetten, schijf vervangen, proxmox opnieuw installeren, cluster joinen;
- Migreer alle spul weer terug naar de Prodesk;
- Zet de Prodesk uit, vervang de schijf, installeer proxmox opnieuw, join cluster weer

Kan zoiets of is dat een probleem omdat de Optiplex de 'eigenaar/maker' van het cluster is?

Dit is perfect mogelijk. Maak wel even een backup op een USB ofzo voor de zekerheid. Kijk verder inderdaad wel uit met een twee node cluster zoals aangeven door @RobertMe

[Koepert]

orvintax schreef op donderdag 12 januari 2023 @ 15:06:
[...]

Dit is perfect mogelijk. Maak wel even een backup op een USB ofzo voor de zekerheid. Kijk verder inderdaad wel uit met een twee node cluster zoals aangeven door @RobertMe

Good to know.. maar hoe moet ik dat zien dan? Dat split brain?

In de basis wil ik dit vrij 'plat' gaan gebruiken: 1 host is namelijk ook nieuwer en sneller dan de andere (die t cluster gemaakt heeft is oudere 2 x Intel(R) Pentium(R) CPU G3250T, de andere 4 x Intel(R) Core(TM) i5-4590T ). Dus wilde ik dit cluster gaan gebruiken voor een 'soft migration' van oud naar nieuw en dan de 2e (oude) host als spare gaan gebruiken en wellicht wat spielerij..

Wat voor soort situatie krijg je dan te maken met een split brain?

[nero355]

Koepert schreef op donderdag 12 januari 2023 @ 11:08:
- Dell Optiplex 1x 500GB HDD met Proxmox 7.3.3 in een cluster (op deze is cluster gemaakt)
- HP PRoDesk 800 Mini 1x 128GB SSD met Proxmox 7.3.3 die vandaag hetzelfde cluster gejoind heeft.

Nu DENK ik, dat mijn 500GB HDD wat op leeftijd raakt.. (nog geen alarmbellen, maar die wil ik graag voor zijn aangezien momenteel mijn smarthome, DNS/Pi-hole en Traefik hierop draaien.

Post eens de output van die disk :

smartctl -a /dev/sda

In een mooi

code:

CODE blok met QUOTE Tags eromheen, zodat we ons niet suf scrollen elke keer!

Verder zou je die HDD gewoon 1:1 kunnen DD-en naar een andere 500 GB HDD mocht je die toevallig hebben liggen als tussenstap en gelijk ook je backup!

[Koepert]

nero355 schreef op donderdag 12 januari 2023 @ 15:45:
[...]

Post eens de output van die disk :

smartctl -a /dev/sda

In een mooi

[...]


Verder zou je die HDD gewoon 1:1 kunnen DD-en naar een andere 500 GB HDD mocht je die toevallig hebben liggen als tussenstap en gelijk ook je backup!

Code-tags ken ik

code:

smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.74-1-pve] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     TOSHIBA MQ01ACF050
Serial Number:    X5SEWRGQT
LU WWN Device Id: 5 000039 694b069d9
Firmware Version: AV001D
User Capacity:    500,107,862,016 bytes [500 GB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      2.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Thu Jan 12 15:45:59 2023 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x00) Offline data collection activity
                                        was never started.
                                        Auto Offline Data Collection: Disabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever 
                                        been run.
Total time to complete Offline 
data collection:                (  120) seconds.
Offline data collection
capabilities:                    (0x5b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        No Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine 
recommended polling time:        (   2) minutes.
Extended self-test routine
recommended polling time:        ( 100) minutes.
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 128
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   050    Pre-fail  Always       -       0
  3 Spin_Up_Time            0x0027   100   100   001    Pre-fail  Always       -       1983
  5 Reallocated_Sector_Ct   0x0033   100   100   050    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   052   052   000    Old_age   Always       -       19466
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       627
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       20
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       38
193 Load_Cycle_Count        0x0032   092   092   000    Old_age   Always       -       89888
194 Temperature_Celsius     0x0022   100   100   000    Old_age   Always       -       55 (Min/Max 4/65)
199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always       -       773527027
200 Multi_Zone_Error_Rate   0x0032   100   100   000    Old_age   Always       -       1297043924
240 Head_Flying_Hours       0x0032   053   053   000    Old_age   Always       -       18822
241 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       39559358211
242 Total_LBAs_Read         0x0032   100   100   000    Old_age   Always       -       38915568883
254 Free_Fall_Sensor        0x0032   100   100   000    Old_age   Always       -       0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed without error       00%         0         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

[nero355]

Koepert schreef op donderdag 12 januari 2023 @ 15:47:

code:

199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always       -       773527027

Ziet eruit als :
- Brakke kabel.
- Brakke SATA Poort.
- Brakke Controller/PCB van de HDD zelf.

Voor de rest zie ik zo gauw niks raars eigenlijk

[Koepert]

nero355 schreef op donderdag 12 januari 2023 @ 15:52:
[...]

Ziet eruit als :
- Brakke kabel.
- Brakke SATA Poort.
- Brakke Controller/PCB van de HDD zelf.

Voor de rest zie ik zo gauw niks raars eigenlijk

ok, dus eerder brakke internals dan brakke disk.. misschien dus sowieso geen slecht idee deze uit te faseren..zodat ik m kan nakijken/delen vervangen.

[ Voor 12% gewijzigd door Koepert op 12-01-2023 15:56 ]

[orvintax]

Koepert schreef op donderdag 12 januari 2023 @ 15:29:
[...]


Good to know.. maar hoe moet ik dat zien dan? Dat split brain?

In de basis wil ik dit vrij 'plat' gaan gebruiken: 1 host is namelijk ook nieuwer en sneller dan de andere (die t cluster gemaakt heeft is oudere 2 x Intel(R) Pentium(R) CPU G3250T, de andere 4 x Intel(R) Core(TM) i5-4590T ). Dus wilde ik dit cluster gaan gebruiken voor een 'soft migration' van oud naar nieuw en dan de 2e (oude) host als spare gaan gebruiken en wellicht wat spielerij..

Wat voor soort situatie krijg je dan te maken met een split brain?

Voor een migratie maakt het weinig uit. Het gaat hem vooral als je iets met HA en Ceph wilt gaan doen. Voornamelijk met Ceph kan het nog al destructief zijn aangezien je data corruption kan krijgen.
Quote van een pagina van 45drives:

They must establish a consensus about the data and the cluster map.

A quorum, which is the is reached by the nodes in a cluster each having a "vote" on what information is correct and only ever recording it when there is a majority consensus reached. It operates on several computer science principles.

Those principles are meant to guarantee data consistency by ensuring multiple different copies of data are never recorded. For example, there is only ever one consistent copy learned and for this to work it needs an odd number of nodes within the cluster to be able to vote each other down.

[Koepert]

orvintax schreef op donderdag 12 januari 2023 @ 17:17:
[...]

Voor een migratie maakt het weinig uit. Het gaat hem vooral als je iets met HA en Ceph wilt gaan doen. Voornamelijk met Ceph kan het nog al destructief zijn aangezien je data corruption kan krijgen.
Quote van een pagina van 45drives:

[...]

Dankje.. Ceph zal ik niet gaan gebruiken. HA was nog een twijfel-geval... maar geen must. Maar ik zal t in t achterhoofd houden.. K wilde alleen ook wat energie-besparing gaan doen en dan is n derde host geen besparing

[jbhc]

Weet iemand of het mogelijk is om een NTP server te draaien op proxmox? Ik heb wat apparaten in mijn netwerk zitten die NTP nodig hebben en ik dacht even simpel een NTP servertje op te starten maar vooralsnog krijg ik dat niet aan de gang omdat de virtuele servers de tijd niet kunnen wijzigen.

[ Voor 10% gewijzigd door jbhc op 28-01-2023 22:09 ]

[powerboat]

jbhc schreef op zaterdag 28 januari 2023 @ 22:09:
Weet iemand of het mogelijk is om een NTP server te draaien op proxmox? Ik heb wat apparaten in mijn netwerk zitten die NTP nodig hebben en ik dacht even simpel een NTP servertje op te starten maar vooralsnog krijg ik dat niet aan de gang omdat de virtuele servers de tijd niet kunnen wijzigen.

Weet niet of je een opnsense / pfsense draait, maar die kun je als ntp server gebruiken.

Overigens draait pve op debian dus je kan gewoon de ntp server configureren.

[nero355]

jbhc schreef op zaterdag 28 januari 2023 @ 22:09:
Weet iemand of het mogelijk is om een NTP server te draaien op proxmox?

Ik heb wat apparaten in mijn netwerk zitten die NTP nodig hebben en ik dacht even simpel een NTP servertje op te starten maar vooralsnog krijg ik dat niet aan de gang omdat de virtuele servers de tijd niet kunnen wijzigen.

powerboat schreef op zondag 29 januari 2023 @ 01:59:
Weet niet of je een opnsense / pfsense draait, maar die kun je als ntp server gebruiken.

Overigens draait pve op debian dus je kan gewoon de ntp server configureren.

Volgens mij heeft hij een ander probleem, maar ik kan er maar niks duidelijks over vinden om de een of andere reden, want voor zover ik weet :
- Sync je de tijd binnen een VM met de Host via een Agent zoals de QEMU Agent of VMWare Tools bij VMWare ESXi
- Heb ik nog ergens gelezen dat LXC Containers hun tijd gewoon syncen met de Host zonder extra gedoe en ik kan me voorstellen dat die ook geen rechten heeft om de tijd te syncen omdat die dan de host daarmee zou kunnen beïnvloeden ?!
- Een VM heeft natuurlijk die problemen niet en zou wel via NTP de tijd kunnen syncen, maar dat zou ik dus alleen gebruiken als er geen Agent gebruikt kan worden om wat voor reden dan ook!

Dus mijn vraag is eigenlijk : Wat mis ik hier in dit verhaal ??

[dcm360]

nero355 schreef op zondag 29 januari 2023 @ 19:36:
[...]

Dus mijn vraag is eigenlijk : Wat mis ik hier in dit verhaal ??

Waarschijnlijk dat de 'apparaten in het netwerk' niet draaien op de Proxmox host, maar losse apparaten zijn.

[jbhc]

dcm360 schreef op zondag 29 januari 2023 @ 20:40:
[...]

Waarschijnlijk dat de 'apparaten in het netwerk' niet draaien op de Proxmox host, maar losse apparaten zijn.

Precies dat. Die apparaten zitten in een ander vlan. Ik dacht dus eenvoudig een servertje op te zetten als NTP server aangezien dat niet in het ubiquity unifi ecosysteem ingebakken zit maar dat blijkt makkelijker gezegt dan gedaan.

[daan256]

noob hier m.b.t. PROXMOX. Kan iemand mij misschien helpen?

Ik wil graag dat de volgende commands automatisch worden geexecute nadat een VM is gestopt.

echo 1 > /sys/bus/pci/devices/0000\:04\:00.0/remove
echo 1 > /sys/bus/pci/devices/0000\:04\:00.1/remove

Nu probeerde ik het met een hookscript maar daar kom ik niet echt uit.
Is er wellicht een alternatief?

[nero355]

dcm360 schreef op zondag 29 januari 2023 @ 20:40:
Waarschijnlijk dat de 'apparaten in het netwerk' niet draaien op de Proxmox host, maar losse apparaten zijn.

Ik las zijn post dus echt totaal verkeerd zo te zien...

jbhc schreef op zondag 29 januari 2023 @ 21:28:
Precies dat. Die apparaten zitten in een ander vlan.
Ik dacht dus eenvoudig een servertje op te zetten als NTP server aangezien dat niet in het ubiquity unifi ecosysteem ingebakken zit maar dat blijkt makkelijker gezegt dan gedaan.

Ubiquiti UniFi apparatuur synct hun tijd zelf door naar de globale of Debian NTP Servers te querien tijdens de boot dus daar hoef je het niet voor te doen!

Of wil je een NTP Server op je CloudKey/UDR/UDM draaien voor andere apparatuur ?!

[jbhc]

nero355 schreef op maandag 30 januari 2023 @ 00:23:
[...]

Ik las zijn post dus echt totaal verkeerd zo te zien...


[...]

Ubiquiti UniFi apparatuur synct hun tijd zelf door naar de globale of Debian NTP Servers te querien tijdens de boot dus daar hoef je het niet voor te doen!

Of wil je een NTP Server op je CloudKey/UDR/UDM draaien voor andere apparatuur ?!

Inderdaad. Ik heb een berg Shelly's in een apart VLAN die geen internet toegang hebben maar deze hebben een NTP server nodig om hun tijd te synchroniseren.

En natuurlijk, ik zou de Shelly's toegang kunnen geven tot de Proxmox NTP server (net zoals ze nu toegang hebben tot de google NTP server) maar dat is eigenlijk nou net niet mijn bedoeling

[stormfly]

jbhc schreef op maandag 30 januari 2023 @ 00:41:
[...]


Inderdaad. Ik heb een berg Shelly's in een apart VLAN die geen internet toegang hebben maar deze hebben een NTP server nodig om hun tijd te synchroniseren.

En natuurlijk, ik zou de Shelly's toegang kunnen geven tot de Proxmox NTP server (net zoals ze nu toegang hebben tot de google NTP server) maar dat is eigenlijk nou net niet mijn bedoeling

Kan je router geen NTP rol vervullen? xSense kan dat in hetzelfde vlan?

Als je filtert op portniveau is NTP openzetten naar je servers geen gekke gedachte. Grote bedrijven doen dat ook, zonder NTP heb je meer kans op crap binnen ICT. Dan een selectief geopende poort voor NTP met source en destination IP’s.

Maar als je dan toch besluit om het door te laten is NTP vanaf internet weer veiliger. Dan hoef je geen port te openen op je LAN (Proxmox).

[ Voor 8% gewijzigd door stormfly op 30-01-2023 07:53 ]

[nero355]

jbhc schreef op maandag 30 januari 2023 @ 00:41:
Inderdaad. Ik heb een berg Shelly's in een apart VLAN die geen internet toegang hebben maar deze hebben een NTP server nodig om hun tijd te synchroniseren.

En natuurlijk, ik zou de Shelly's toegang kunnen geven tot de Proxmox NTP server (net zoals ze nu toegang hebben tot de google NTP server) maar dat is eigenlijk nou net niet mijn bedoeling

Zet een Raspberry Pi neer in dat VLAN die voor NTP Server speelt en klaar!

[jbhc]

nero355 schreef op maandag 30 januari 2023 @ 14:44:
[...]

Zet een Raspberry Pi neer in dat VLAN die voor NTP Server speelt en klaar!

Daar heb ik toch geen pc met Proxmox voor? In principe kan ik alles wat daarop draait ook op losse pi's gaan installeren en dat wil ik nou juist niet.

@stormfly Helaas kan dat niet op unifi.

[stormfly]

jbhc schreef op maandag 30 januari 2023 @ 16:51:
[...]


Daar heb ik toch geen pc met Proxmox voor? In principe kan ik alles wat daarop draait ook op losse pi's gaan installeren en dat wil ik nou juist niet.

@stormfly Helaas kan dat niet op unifi.

Gewoon naar het internet openzetten desnoods een bepaalde pool van cloudflare. En dan nooit meer aan denken.

[synoniem]

jbhc schreef op maandag 30 januari 2023 @ 16:51:
[...]


Daar heb ik toch geen pc met Proxmox voor? In principe kan ik alles wat daarop draait ook op losse pi's gaan installeren en dat wil ik nou juist niet.

@stormfly Helaas kan dat niet op unifi.

Wat is het probleem precies? Je kan op de ntp server in Proxmox ook hetzelfde vlan toevoegen als waar de shellies in draaien en daar specifiek alleen ntp toe staan. Hoef je de rest van de ntp server verder niet voor open te zetten.

[stormfly]

synoniem schreef op maandag 30 januari 2023 @ 17:23:
[...]

Wat is het probleem precies? Je kan op de ntp server in Proxmox ook hetzelfde vlan toevoegen als waar de shellies in draaien en daar specifiek alleen ntp toe staan. Hoef je de rest van de ntp server verder niet voor open te zetten.

Een oud collega van mij zei: het meest ranzige qua security is een OS meerdere pootjes geven 🤭 (don’t shoot the messenger).

Het is zeker wel het snelst, echter als Proxmox compromised is; zitten “ze” met direct access op meerdere vlans en kunnen ze overal bij.

Internet blokkeren klinkt heel zwaar zeker voor een netwerk in 2023. Als je doordacht en selectief diensten van het internet je secure vlan binnenhaalt, is dat voor mij prima. Logs op de fw rules inschakelen. Je Shelly devices (handvol) in de source, cloudflare NTP als destination, port 123. Daar gaat echt geen attack over binnenkomen.

Bij pfsense zie je direct de laatste fw rule matches. Heb je wel eens overwogen dat een USG/UDM eigenlijk unmanageable secure is 😂 Een blackbox in je LAN. Met de matige logs en FW ruleset gui ben je in feite blind. Is dat mogelijk een deel van de oorzaak dat je zo huiverig bent voor internet access?

[synoniem]

stormfly schreef op maandag 30 januari 2023 @ 17:57:
[...]


Een oud collega van mij zei: het meest ranzige qua security is een OS meerdere pootjes geven 🤭 (don’t shoot the messenger).

Het is zeker wel het snelst, echter als Proxmox compromised is; zitten “ze” met direct access op meerdere vlans en kunnen ze overal bij.
{.............}

Tja als je het mij vraagt zet ik liever een ntp poort open naar cloudflare of andere ntp server voor een paar shellies. Maar ja als je dat niet wilt is het aantal mogelijkheden wel beperkt.

[stormfly]

synoniem schreef op maandag 30 januari 2023 @ 18:07:
[...]

Tja als je het mij vraagt zet ik liever een ntp poort open naar cloudflare of andere ntp server voor een paar shellies. Maar ja als je dat niet wilt is het aantal mogelijkheden wel beperkt.

Exact, ik ben ook wel door de ideeënbus heen

[schumi2004]

Een nieuwe proxmox gebruiker hier en na een paar dagen redelijk zonder issues gedraaid te hebben met een LXC tegen een issue aan gelopen met SABnzbd.

Kort gezegd, ik kon de download folder voor Sabnbzd niet aanpassen vanwege een rechten issue.

Van een andere tweaker (Thomas H in "[Ervaringen] CouchPotato, Sickbeard, Headphones e.a. deel 4") de volgende links en tips gekregen:

Kort gezegd zou het volgende in mijn LXC conf het min of meer verhelpen:
[code]
lxc.idmap: u 0 100000 1000
lxc.idmap: g 0 100000 1000
lxc.idmap: u 1000 1000 1
lxc.idmap: g 1000 1000 1
lxc.idmap: u 1001 101001 64535
lxc.idmap: g 1001 101001 64535[/code]

Na de links gevolgd te hebben en wat aanpassingen gemaakt te hebben ben ik alleen maar verder van huis met dead containers en andere apps die gewoon niet meer willen starten, want geen rechten meer op de config folder.

Het gaat voornamelijk om apps als Sonarr, Radarr, SABnzbd etc van linuxserver.

Ik kan zonder problemen mount points maken en die zag ik voorheen ook maar sinds ik met rechten aan het spelen ben is het 1 grote chaos geworden en ben ik eigenlijk in staat maar gewoon een privileged container te starten omdat dat minder gezeik geeft.

Eigenlijk is SABnzbd de enige die vervelend deed, Sonarr, Radarr etc hadden 0 issues met rechten.

Nu kan ik weer van scratch beginnen, nieuwe unprivileged LXC, Mijn docker-compose bestandjes er tegen aan gooien (config backup heb ik nog) en ik draai weer maar dan wel zonder een optie om uberhaupt iets met rechten te kunenn doen en Sabnzbd alsnog werkend te krijgen met andere folders.

Ik ben begonnen met deze link : https://gist.github.com/b...0d531148dfb4c2640e9ebfc56
Mount points had ik al dus het was voornamelik een groepje aanmaken ACL's maken (wat in eerste instantie goed leek te gaan), vervolgens nog wat zaken in de container zelf en sinds dien is het stuk.

Ik dacht doe de stappen opnieuw, vereenvoudig de mountpoints maar loop nu vast bij de ACL's, elke keer als ik dat doe krijg ik Operation not supported.

cmd: setfacl -Rm g:101000:rwx,d:g:101000:rwx /mnt/docker_data/

Kan dit niet eenvoudiger, is er niet ergens een complete guide hoe NFS shares te mounten en vooral het rechten stukje werkend te krijgen?

/edit:
De issues lijken zich vooralsnog op magische wijze verholpen te hebben
Ben wel helemaal opnieuw begonnen.

[nero355]

jbhc schreef op maandag 30 januari 2023 @ 16:51:
Daar heb ik toch geen pc met Proxmox voor? In principe kan ik alles wat daarop draait ook op losse pi's gaan installeren en dat wil ik nou juist niet.

VM dan die alleen in dat VLAN kan communiceren

Overigens draaien de UniFi CloudKey en UDR/UDM modellen Alpine Linux onderhuids waarmee je het een en ander kan rommelen, maar de boel persistent maken kan een uitdaging zijn...

[jbhc]

nero355 schreef op dinsdag 31 januari 2023 @ 00:19:
[...]

VM dan die alleen in dat VLAN kan communiceren

Waarom niet?

[nero355]

jbhc schreef op dinsdag 31 januari 2023 @ 03:43:
Waarom niet?

Tja, dat is eigenlijk een beetje mijn vraag aan jou

[powerboat]

nero355 schreef op dinsdag 31 januari 2023 @ 14:59:
[...]

Tja, dat is eigenlijk een beetje mijn vraag aan jou

Soms wil je dat enkel een machine naar binnen en/of buiten moet of kan communiceren.

Zo doe ik dat bijv. bij klanten net een Zabbix proxy voor monitoring.

[nero355]

powerboat schreef op dinsdag 31 januari 2023 @ 22:40:
Soms wil je dat enkel een machine naar binnen en/of buiten moet of kan communiceren.

Zo doe ik dat bijv. bij klanten net een Zabbix proxy voor monitoring.

Dat snap ik ook wel, maar zoals je ziet begrijpen we @jbhc niet echt op het moment, want in principe heeft die een situatie waarin er meerdere wegen naar Rome zijn, maar waarom hij die niet heeft geprobeerd is nog een raadsel...

Maar misschien denken wij te moeilijk... Kan ook!

[MakhouT]

Ik ben volledig nieuw met Proxmox. Ik heb gisteren voor de eerste keer een installatie gedaan van Proxmox op mijn NUC. En ik zit eigenlijk al direct met vragen eigenlijk.

- Is het de bedoeling dat eenmaal proxmox geinstalleerd is dat ik die altijd benader via de browser via een andere client? Of moet ik nog altijd een muis, toetsenbord en scherm gekoppeld hebben met mijn NUC?

- Ik heb de installatie gedaan zonder internet verbinding, dus ik heb een lokaal ip adres gekregen. Nu wil ik hem koppelen aan mijn wifi, maar hier loop ik tegen. Blijkbaar is het niet aangeraden om via wifi te gaan, maar om die te koppelen via ethernet? Klopt dit?

[Sypher]

MakhouT schreef op woensdag 1 februari 2023 @ 10:15:
Ik ben volledig nieuw met Proxmox. Ik heb gisteren voor de eerste keer een installatie gedaan van Proxmox op mijn NUC. En ik zit eigenlijk al direct met vragen eigenlijk.

- Is het de bedoeling dat eenmaal proxmox geinstalleerd is dat ik die altijd benader via de browser via een andere client? Of moet ik nog altijd een muis, toetsenbord en scherm gekoppeld hebben met mijn NUC?

Proxmox heeft een webinterface welke je kan benaderen via

code:

https://JE_IP:8006

.
Een toetsenbord/muis/scherm heb je na de installatie niet meer nodig.

- Ik heb de installatie gedaan zonder internet verbinding, dus ik heb een lokaal ip adres gekregen. Nu wil ik hem koppelen aan mijn wifi, maar hier loop ik tegen. Blijkbaar is het niet aangeraden om via wifi te gaan, maar om die te koppelen via ethernet? Klopt dit?

Met je wifi zou hij alsnog een intern IP krijgen ;-)

Maar ethernet zou ik wel aanraden aangezien dat stabieler is dan wifi en doorgaans hogere bandbreedte heeft.

Als je DHCP gebruikt kan je die het beste wel even in je router static maken, of je Proxmox node een statisch IP geven.

[orvintax]

MakhouT schreef op woensdag 1 februari 2023 @ 10:15:
Ik ben volledig nieuw met Proxmox. Ik heb gisteren voor de eerste keer een installatie gedaan van Proxmox op mijn NUC. En ik zit eigenlijk al direct met vragen eigenlijk.

- Is het de bedoeling dat eenmaal proxmox geinstalleerd is dat ik die altijd benader via de browser via een andere client? Of moet ik nog altijd een muis, toetsenbord en scherm gekoppeld hebben met mijn NUC?

- Ik heb de installatie gedaan zonder internet verbinding, dus ik heb een lokaal ip adres gekregen. Nu wil ik hem koppelen aan mijn wifi, maar hier loop ik tegen. Blijkbaar is het niet aangeraden om via wifi te gaan, maar om die te koppelen via ethernet? Klopt dit?

- Beide is mogelijk, maar via de browser is een stuk makkelijker en dus aangeraden.

- In princiepe is het altijd en met elk apparaat aangeraden om te verbinden via ethernet waar mogelijk Je zou wel via WiFi kunnen verbinden, moet je wel even kijken of dat lukt met de drivers. Maar in serverland draait het voornamelijk om stabiliteit en robuustheid. En WiFi is dat gewoon een stuk minder dan ethernet.