Het grote Proxmox VE topic

[MewBie]

Proxmox heeft ingebouwde Influx ondersteuning waar je een boel stats uit kan halen.

[Fresh T.]

In hoeverre heeft het zin om een nvme ssd zoals de wd black in te zetten ten opzichye van een "reguliere" sata ssd? Ik verneem op verschillende plekken meestal een aardige drop in performance van de ssd, dat de vm's niet het volle potentieel benutten van de ssd. Merken jullie een significant verschil in performance tussen deze twee typen aansluitingen van ssd's?

[unezra]

Fresh T. schreef op maandag 6 mei 2019 @ 19:37:
In hoeverre heeft het zin om een nvme ssd zoals de wd black in te zetten ten opzichye van een "reguliere" sata ssd? Ik verneem op verschillende plekken meestal een aardige drop in performance van de ssd, dat de vm's niet het volle potentieel benutten van de ssd. Merken jullie een significant verschil in performance tussen deze twee typen aansluitingen van ssd's?

Als je de performance niet *nodig* hebt, heeft een NVMe weinig voordelen.

Ik draai zelf PVE vanaf een reguliere SATA SSD, maar mijn vm's draaien allemaal via NFS via een etherchannel (2xGBit) op mijn NAS. Werkt goed. Maar ik vraag niet veel performance. NVMe heb ik hier geen behoefte aan.

Dit jaar wil ik het spul vervangen door één server, maar grote kans dat ik de vm's gewoon op spinnend roest zet, met 1 of 2 SATA SSD's of 1 of 2 NVMe SSD's voor het OS en wat basiszaken. (Ik heb nu 2 PVE dozen en een NAS, dat vind ik niet praktisch meer.)

NVMe is overigens geen aansluiting. Een veel gebruikte aansluiting voor NVMe is m.2, maar m.2 kan ook gewoon SATA SSD's hebben en een NVMe kan ook op een PCIe kaart zitten. Het enige dat je NIET zult vinden, is een NVMe op een SATA aansluiting.

[ Voor 10% gewijzigd door unezra op 06-05-2019 19:49 ]

[Fresh T.]

unezra schreef op maandag 6 mei 2019 @ 19:48:
[...]


Als je de performance niet *nodig* hebt, heeft een NVMe weinig voordelen.

Nodig is een groot woord voor een thuissituatie. Heb momenteel een Hyper-V box thuis staan met een aantal vm's er op met webservers, mailserver voor familie en sql server, maar de beheersbaarheid valt me toch wat tegen. Kwam daarom bij Proxmox uit. Alleen de performance van de schijven die aan de vm's zijn toegewezen, zijn toch vaak stuk lager dan als je de performance rechtstreeks vanuit een host os bekijkt (read/write speeds). Ik vroeg me dan ook af of een nvme schijf (via pci-e, in mijn geval m.2 aansluiting) wel een zinvolle upgrade is ten opzichte van de goedkopere ssd's. Kun je wel het volle potentieel halen van zo'n snelle schijf?

NVMe is overigens geen aansluiting. Een veel gebruikte aansluiting voor NVMe is m.2, maar m.2 kan ook gewoon SATA SSD's hebben en een NVMe kan ook op een PCIe kaart zitten. Het enige dat je NIET zult vinden, is een NVMe op een SATA aansluiting.

Excuus, aansluiting was het verkeerde woord, interface was beter geweest.

[unezra]

Fresh T. schreef op maandag 6 mei 2019 @ 20:34:
[...]
Nodig is een groot woord voor een thuissituatie. Heb momenteel een Hyper-V box thuis staan met een aantal vm's er op met webservers, mailserver voor familie en sql server, maar de beheersbaarheid valt me toch wat tegen. Kwam daarom bij Proxmox uit. Alleen de performance van de schijven die aan de vm's zijn toegewezen, zijn toch vaak stuk lager dan als je de performance rechtstreeks vanuit een host os bekijkt (read/write speeds). Ik vroeg me dan ook af of een nvme schijf (via pci-e, in mijn geval m.2 aansluiting) wel een zinvolle upgrade is ten opzichte van de goedkopere ssd's. Kun je wel het volle potentieel halen van zo'n snelle schijf?

Gebruik je ZFS als onderliggend filesystem?
Zo nee, kijk daar eens naar. Dát voegt serieus wat toe qua performance én data integriteit.

Performanceverlies op IO is, mits je bovenliggende OS gebruik maakt van paravirtualisatie (dus óók op IO), zeer beperkt. Je verliest wel performance, maar met meerdere vm's deel je de performance van de onderliggende storage hoe dan ook dus zou je in theorie tegen de max aan moeten kunnen komen.

Aan de andere kant... De kans dat je NVMe nodig hebt is heel erg klein.

Ter vergelijk, op kantoor hangen wij een ruwe 30, 40 vm's via ethernet aan een NetApp storagedoos met disks. Nu is dat 4xGBit per controller (we hebben 2 controllers) én heb ik 1 shelf van 12 disks en 1 shelf van 24 disks, allemaal 10KRPM SAS, maar toch. Dat spul is trager dan een lokale NVMe en zelfs trager dan een lokale enkele SATA SSD. Het gaat prima.

Daar zit dus de crux. Hoe veel snelheid heb je nodig. Dat word, zeker in thuissituaties, niet zelden flink overschat. (Ik heb als eens iemand gesproken die vond dat 'ie thuis 10G nodig had. 10G is leuk, maar *nodig*, in zijn situatie, met een hand vol hobby vm's, no way in f*cking hell. Die jongen overschatte zijn werkelijke noodzaak bij meer dan een factor 10, als het geen 20 of meer was.)

[ocf81]

Ik wil graag een ZFS pool op een van mijn servers als shared storage delen met de rest van mijn machines. Ik wil graag de pool beschikbaar stellen. Ik weet alleen niet hoe dat moet. Er gaan VMs op draaien.

Ik heb nu al tijden zitten zoeken hoe ik in proxmox een iSCSI target moet opzetten, maar alle guides/tutorials gaan er vanuit dat je een NAS (veelal wordt FreeNAS of Synology genoemd) gebruikt waar je dit met 3 muisklikken kan regelen. Zelfs het boek Mastering Proxmox (3^e editie / ISBN 978-1-78839-760-5) gaat er gladjes vanuit dat je dit zo even hebt gedaan. (De rest van het boek is overigens best oké, maar dit deel dus niet)

Als het zo teruglees is qua performance voor de VMs een oplossing op basis van iSCSI de beste optie?
Ik weet niet of het dan het beste is om LVM daar bovenop te draaien, of ZFS over iSCSI, of een andere laag die meerdere clienten (andere nodes) kan bedienen.

Ik ben er al achter dat ik, als ik eenmaal een target heb, ik vervolgens naar het datacenter moet en daar de storage aan de target moet koppelen, maar hoe ik nu een target opzet is mij een raadsel.

[mdbraber]

ocf81 schreef op donderdag 30 mei 2019 @ 02:00:
Ik wil graag een ZFS pool op een van mijn servers als shared storage delen met de rest van mijn machines. Ik wil graag de pool beschikbaar stellen. Ik weet alleen niet hoe dat moet. Er gaan VMs op draaien.

Ik heb nu al tijden zitten zoeken hoe ik in proxmox een iSCSI target moet opzetten, maar alle guides/tutorials gaan er vanuit dat je een NAS (veelal wordt FreeNAS of Synology genoemd) gebruikt waar je dit met 3 muisklikken kan regelen. Zelfs het boek Mastering Proxmox (3^e editie / ISBN 978-1-78839-760-5) gaat er gladjes vanuit dat je dit zo even hebt gedaan. (De rest van het boek is overigens best oké, maar dit deel dus niet)

Als het zo teruglees is qua performance voor de VMs een oplossing op basis van iSCSI de beste optie?
Ik weet niet of het dan het beste is om LVM daar bovenop te draaien, of ZFS over iSCSI, of een andere laag die meerdere clienten (andere nodes) kan bedienen.

Ik ben er al achter dat ik, als ik eenmaal een target heb, ik vervolgens naar het datacenter moet en daar de storage aan de target moet koppelen, maar hoe ik nu een target opzet is mij een raadsel.

Ik heb geen iSCSI draaien, maar is het niet zo dat je simpelweg `zfs set shareiscsi=on mypool/test` kan doen? Hier wat achtergrond van de implementatie die al sinds 2015 in ZFSonLinux zit https://github.com/behlen...libshare/README_iscsi.txt

[ Voor 28% gewijzigd door mdbraber op 30-05-2019 11:35 ]

[ocf81]

mdbraber schreef op donderdag 30 mei 2019 @ 11:35:
[...]


Ik heb geen iSCSI draaien, maar is het niet zo dat je simpelweg `zfs set shareiscsi=on mypool/test` kan doen? Hier wat achtergrond van de implementatie die al sinds 2015 in ZFSonLinux zit https://github.com/behlen...libshare/README_iscsi.txt

Ja dat is ook nog het overwegen waard. Als ik het zo kijk worden dan de LUNs ook door dit verhaal gemanaged, en als ik het goed begrijp heeft Proxmox eigenlijk alleen een target nodig en doet het dan zelf de rest binnen het cluster. (maar dat kan ik ook verkeerd hebben begrepen) In ieder geval bedankt voor de link!

[maomanna]

proxmox kan toch gewoon je pools maken welke je dan weer via NFS kan delen met je VM's.
Daarnaast kan je een pool maken en die toewijzen voor de VM machines zelf.

[ocf81]

@maomanna Als ik het goed heb begrepen heeft NFS heeft wel een mindere performance dan iSCSI. Dat is niet mijn eerste keus.

Maar wellicht kan je uitleggen wat je precies bedoelt met een pool voor de VMs? Bedoel je dan een ZFS pool? Kan ik daar block level access op krijgen? Hoe gaat dat precies?

[Freeaqingme]

ocf81 schreef op maandag 3 juni 2019 @ 23:06:
@maomanna Als ik het goed heb begrepen heeft NFS heeft wel een mindere performance dan iSCSI. Dat is niet mijn eerste keus.

Waar baseer je dat op? Bij een vorig werkgever hebben we dat wel eens getest, en voor onze toepassing kwamen we hoogstens op ~5% betere performance uit. Daar stond een significant complexere configuratie tegenover, en hebben we besloten bij NFS te blijven. Ook aan NFS valt natuurlijk van alles te tunen, het belangrijkste was in ieder geval een MTU van 9000 bytes gebruiken.

[unezra]

Freeaqingme schreef op dinsdag 4 juni 2019 @ 00:39:
[...]
Waar baseer je dat op? Bij een vorig werkgever hebben we dat wel eens getest, en voor onze toepassing kwamen we hoogstens op ~5% betere performance uit. Daar stond een significant complexere configuratie tegenover, en hebben we besloten bij NFS te blijven. Ook aan NFS valt natuurlijk van alles te tunen, het belangrijkste was in ieder geval een MTU van 9000 bytes gebruiken.

Plus dat dit alleen relevant is, als je de performance *nodig* hebt. (De vraag is dan of je niet moet investeren in andere hardware om een hogere performance te halen of etherchannels moet gaan toepassen.)

Er word soms te makkelijk geroepen dat iets geen optie is omdat het minder performant is, terwijl als puntje bij het paaltje komt, dan blijkt dat iemand nooit de maximale performance nodig gaat hebben en het dus helemaal niet relevant is dat iets trager is.

[maomanna]

ocf81 schreef op maandag 3 juni 2019 @ 23:06:
@maomanna Als ik het goed heb begrepen heeft NFS heeft wel een mindere performance dan iSCSI. Dat is niet mijn eerste keus.

Maar wellicht kan je uitleggen wat je precies bedoelt met een pool voor de VMs? Bedoel je dan een ZFS pool? Kan ik daar block level access op krijgen? Hoe gaat dat precies?

Proxmox heeft native ondersteuning voor ZFS. Daarmee kan je dus op het hoogste niveau de pools maken.
Je kan daarmee dus een pool maken waar alle VM's op komen te staan, maar ook een pool waar je je data opzet en die deelt met je VM's alszijne opslag. Hoe je dat dan deelt is natuurlijk aan jou zelf.

Hoe en wat met block level, geen idee. Daar heb ik geen weet van. schijnbaar heb ik het dus ook niet nodig, omdat het nu bij mij gewoon werkt (don't fix it if it ain't broke)
Je kan voor elke VM natuurlijk een eigen mountpoint maken op de grote pool.

[ Voor 4% gewijzigd door maomanna op 04-06-2019 09:23 ]

[ocf81]

Freeaqingme schreef op dinsdag 4 juni 2019 @ 00:39:
[...]


Waar baseer je dat op? Bij een vorig werkgever hebben we dat wel eens getest, en voor onze toepassing kwamen we hoogstens op ~5% betere performance uit. Daar stond een significant complexere configuratie tegenover, en hebben we besloten bij NFS te blijven. Ook aan NFS valt natuurlijk van alles te tunen, het belangrijkste was in ieder geval een MTU van 9000 bytes gebruiken.

Ik heb dat gelezen in enkele reddit posts en youtube video's. NFS zou ook kunnen. Het beeld wat ik kreeg is dat, hoewel throughput niet heel erg uit elkaar loopt tussen de twee, de IOPS performance wel een stuk hoger kan liggen met iSCSI. Dat is voor VMs niet onbelangrijk. Goed om te weten dat jumbo frames belangrijk zijn voor de performance.

unezra schreef op dinsdag 4 juni 2019 @ 06:49:
[...]


Plus dat dit alleen relevant is, als je de performance *nodig* hebt. (De vraag is dan of je niet moet investeren in andere hardware om een hogere performance te halen of etherchannels moet gaan toepassen.)

Er word soms te makkelijk geroepen dat iets geen optie is omdat het minder performant is, terwijl als puntje bij het paaltje komt, dan blijkt dat iemand nooit de maximale performance nodig gaat hebben en het dus helemaal niet relevant is dat iets trager is.

Natuurlijk is het een optie, maar het heeft niet mijn eerste voorkeur als er andere opties zijn die mogelijk sneller kunnen werken. Wat werk steken in configuratie om irritatie tegen te gaan lijkt mij een goede trade-off. Ik heb nu nog HDDs maar de volgende upgrade is een cluster SSDs. Het netwerk is inmiddels al wel snel genoeg gemaakt om dat aan te kunnen. (10GbE) Ik ben me ook bewust dat lang niet alles tegelijkertijd volle bak zal staan te draaien, maar ik wil geen bottlenecks door onderspecificatie.

[unezra]

ocf81 schreef op woensdag 5 juni 2019 @ 18:37:
[...]
Natuurlijk is het een optie, maar het heeft niet mijn eerste voorkeur als er andere opties zijn die mogelijk sneller kunnen werken. Wat werk steken in configuratie om irritatie tegen te gaan lijkt mij een goede trade-off. Ik heb nu nog HDDs maar de volgende upgrade is een cluster SSDs. Het netwerk is inmiddels al wel snel genoeg gemaakt om dat aan te kunnen. (10GbE) Ik ben me ook bewust dat lang niet alles tegelijkertijd volle bak zal staan te draaien, maar ik wil geen bottlenecks door onderspecificatie.

Tja, blijft, als je het niet nodig hebt, is het onzin er geld aan uit te geven.

Je moet geen bottlenecks gaan oplossen waar je helemaal geen last van hebt of waar je binnnen de afschrijvingstermijn van je hardware geen last van verwacht te krijgen.

Ik kan uiteraard met de informatie die je geeft niet inschatten of dat het geval is en of je het nodig gaat hebben, maar kijk er vooral kritisch naar.

Soms is het natuurlijk ook gewoon leuk om dingen te doen omdat het kán, in een bedrijfssituatie is dat alleen wat zinloos. Zeker als het geld kost.

[mdbraber]

Proxmox VE 6.0 beta is uit: https://forum.proxmox.com...-6-0-beta-released.55668/

[Freeaqingme]

Nice!

Bij versie 4 en bij versie 5 zat er iedere keer 3.5 maanden tussen de eerste beta en GA. Kunnen we alvast eind oktober in de agenda zetten

ik ben overigens wel benieuwd of Proxmox echt groeipotentie heeft, of dat het toch een beetje bij de hobbyisten blijft. Je zou denken dat als je een product heel interessant kan maken voor startups en hobbyisten, dat er dan vanzelf wel een paar van die gebruikers uitgroeien tot grote gebrijven die dat dan blijven gebruiken (en kunnen sponsoren). Het clustermodel van Proxmox schaalt echter niet voorbij de ~20 nodes ofzo, dus echt schalen zal niet lukken (tenzij je heel veel kleine clustertjes bouwt).

[ocf81]

Cool. Net de check voor de update gedraaid. Kennelijk moet je voordat je de proxmox upgrade uitvoert zelf je corosync upgraden.

Overigens heb ik toch maar gekozen voor de installatie van FreeNAS. Net mijn eerste live migration uitgevoerd. Dat is ergens toch een best indrukwekkend staaltje techniek, al zeg ik het zelf. Het maakt onderhoud wel makkelijker denk ik.

Ik vraag me wel af of het ook mogelijk is om daar een apart netwerk voor aan te wijzen. Zonder Ceph is een bonded 10GbE link niet zo heel nuttig. Ik denk dat het dan handiger is om die 2^e 10GbE link in te zetten voor een backhaul subnet waarmee Proxmox supersnel de VMs kan migreren.

Nu nog kijken hoe MPIO in elkaar zit en of ik daar wat redundancy uit kan halen. Dan kan ik wellicht de overgebleven poorten op de switch vullen met een soort backup NAS waar ik een paar 14TB schijven in druk.

[unezra]

Freeaqingme schreef op zaterdag 6 juli 2019 @ 21:12:
Nice!

Bij versie 4 en bij versie 5 zat er iedere keer 3.5 maanden tussen de eerste beta en GA. Kunnen we alvast eind oktober in de agenda zetten

ik ben overigens wel benieuwd of Proxmox echt groeipotentie heeft, of dat het toch een beetje bij de hobbyisten blijft. Je zou denken dat als je een product heel interessant kan maken voor startups en hobbyisten, dat er dan vanzelf wel een paar van die gebruikers uitgroeien tot grote gebrijven die dat dan blijven gebruiken (en kunnen sponsoren). Het clustermodel van Proxmox schaalt echter niet voorbij de ~20 nodes ofzo, dus echt schalen zal niet lukken (tenzij je heel veel kleine clustertjes bouwt).

In mijn beleving is het inderdaad vooral gericht op het MKB/MKB+.
Aan de andere kant, ook voor MKB/MKB+ zijn clusters van 20 nodes al heel behoorlijk.

Wij draaien, met 40 FTE en een capaciteit van 80-100 FTE, op 3 clusters van 3, 2 en 2 nodes.
Het cluster van 3 is voor de VDI omgeving, de 2 clusters van 2 nodes zijn voor KA, de website en alle andere noodzakelijke services.

Storage draait apart. (2 NetApp systemen.)

Alleen al aan hardware voor de hypervisors (7 stuks) is dat uit mijn hoofd dik €70.000 aan hardware en het is bewust verdeeld over 3 clusters. Met een beetje hardware kun je makkelijk met hetzelfde aantal een 2-3x zo krachtig cluster bouwen.

Ofwel, uitgaande van onze situatie en zwaardere hardware, zou met clusters van 20 nodes de capaciteit enkele honderden tot enkelde duizenden FTE zijn met alle dienstverlening die daar bij hoort.

Da's al behoorlijk MKB+.

Een van de grootste nadelen is dat hoewel het clustermanagement op iedere node gedaan kan worden, er volgens mij niet echt een mechaniek binnen PVE is om via 1 cluster IP en hostname, een willekeurige managing node van het cluster aan te spreken.

Ander nadeel voor kleinere omgevingen vind ik dat een HA cluster *moet* bestaan uit 3 nodes. Er zijn geen mechanismen waardoor het met 2 nodes kan, zoals wel het geval bij VMWare en Hyper-V.

Kortom, PVE heeft potentie maar er is duidelijk nog wat werk aan de winkel.

[Freeaqingme]

unezra schreef op zondag 7 juli 2019 @ 10:51:
[...]

Da's al behoorlijk MKB+.

Zeker waar. Voor VDI en KA heb je doorgaans geen corridors vol servers nodig. Maar je hebt toch ook menig bedrijf die eerder per bladechassis of rack rekenen dan per server. Naar die grootte bedrijven zal proxmox lastig kunnen schalen.

Toch heb je wel een goed punt; wellicht pakken ze gewoon als 'niche' het MKB. Een markt waar een vmware zich veel minder profileert. En hoeven ze helemaal niet die niche te ontgroeien, omdat die markt an sich gewoon groot genoeg is.

unezra schreef op zondag 7 juli 2019 @ 10:51:
[...]

Een van de grootste nadelen is dat hoewel het clustermanagement op iedere node gedaan kan worden, er volgens mij niet echt een mechagewoniek binnen PVE is om via 1 cluster IP en hostname, een willekeurige managing node van het cluster aan te spreken.

Klopt. Proxmox gebruikt 1 distributed file system waar alle configuratie op staat middels Corosync. Iedere wijziging in de configuratie wordt op dat file system weggeschreven, en iedere node monitort (met iets als inotify) alle changes op dat file system om die toe te passen.

Daaruit volgt ook meteen de beperking dat alle nodes maximaal 2ms uit elkaar mogen staan, en waarom het cluster-deel relatief beperkt schaalt.

unezra schreef op zondag 7 juli 2019 @ 10:51:
[...]
Ander nadeel voor kleinere omgevingen vind ik dat een HA cluster *moet* bestaan uit 3 nodes. Er zijn geen mechanismen waardoor het met 2 nodes kan, zoals wel het geval bij VMWare en Hyper-V.

Toch kán het wel. Normaliter staat de minimum cluster size op 2. Waarbij als je 3 nodes hebt er altijd 1 uit kan vallen zonder je quorum kwijt te raken. Je kan die minimum cluster size echter ook op 1 zetten, waarmee je een 2-node cluster kan realiseren. Op eigen risico, split-brain situaties gegarandeerd

[MewBie]

Freeaqingme schreef op zondag 7 juli 2019 @ 19:41:
[...]


Zeker waar. Voor VDI en KA heb je doorgaans geen corridors vol servers nodig. Maar je hebt toch ook menig bedrijf die eerder per bladechassis of rack rekenen dan per server. Naar die grootte bedrijven zal proxmox lastig kunnen schalen.

Toch heb je wel een goed punt; wellicht pakken ze gewoon als 'niche' het MKB. Een markt waar een vmware zich veel minder profileert. En hoeven ze helemaal niet die niche te ontgroeien, omdat die markt an sich gewoon groot genoeg is.


[...]


Klopt. Proxmox gebruikt 1 distributed file system waar alle configuratie op staat middels Corosync. Iedere wijziging in de configuratie wordt op dat file system weggeschreven, en iedere node monitort (met iets als inotify) alle changes op dat file system om die toe te passen.

Daaruit volgt ook meteen de beperking dat alle nodes maximaal 2ms uit elkaar mogen staan, en waarom het cluster-deel relatief beperkt schaalt.


[...]


Toch kán het wel. Normaliter staat de minimum cluster size op 2. Waarbij als je 3 nodes hebt er altijd 1 uit kan vallen zonder je quorum kwijt te raken. Je kan die minimum cluster size echter ook op 1 zetten, waarmee je een 2-node cluster kan realiseren. Op eigen risico, split-brain situaties gegarandeerd

toon volledige bericht

Je kan Corosync dusdanig configureren dat 1 node de "master" is, dan is de 2de node niet meer als een extensie van de eerste. Node 1 dood, cluster dood.

Maar echt een toevoeging is dat niet voor een bedrijfssituatie en met storage als Ceph is 2 nodes ook minder bruikbaar.

[mdbraber]

Da's snel: Proxmox VE 6.0 is officieel uit: https://www.proxmox.com/en/proxmox-ve

[mdbraber]

Zijn er hier mensen die Proxmox op een remote server gebruiken? Ik gebruik het tot nu toe alleen lokaal in mijn homelab.

Ik overweeg te gaan switchen van een VPS naar een dedicated server bij Hetzner met daarop Proxmox (een 2-3 VMs, waaronder pfSense). Grootste punt om uit te zoeken is hoe ik de hypervisor zo min mogelijk expose (wsl. door te binden aan een local IP en dan alleen met SSH + port-forwarding of VPN toegang te verkrijgen). Zijn er hier mensen die ervaring hebben met een publicly exposed Proxmox?

[FireDrunk]

Gewoon goede firewall inrichten? Alleen ssh open dmv key authenticatie, en daarna port forwarding gebruiken om bij de gui te komen.

[mdbraber]

Voor iedereen die Proxmox 6.0 en ZFS gebruikt: er is een kernel regressie tussen de 4.15 en de 5.0 kernels mbt to "FPU/SIMD symbol exports" waardoor je significant lagere schrijfsnelheden krijgt met ZFS in sommige gevallen. Het lijkt er op dat het gefixed is in ZFS 0.8.2, maar dat die op dit moment nog niet in de laatste Proxmox versie zit.

Reactie Proxmox:
https://forum.proxmox.com...edium=ios_app#post-258015

Fix Brian Behlendorf / ZFS:
https://www.reddit.com/r/...=share&utm_medium=ios_app

[LiquidSmoke]

mdbraber schreef op vrijdag 19 juli 2019 @ 09:42:
Voor iedereen die Proxmox 6.0 en ZFS gebruikt: er is een kernel regressie tussen de 4.15 en de 5.0 kernels mbt to "FPU/SIMD symbol exports" waardoor je significant lagere schrijfsnelheden krijgt met ZFS in sommige gevallen. Het lijkt er op dat het gefixed is in ZFS 0.8.2, maar dat die op dit moment nog niet in de laatste Proxmox versie zit.

Reactie Proxmox:
https://forum.proxmox.com...edium=ios_app#post-258015

Fix Brian Behlendorf / ZFS:
https://www.reddit.com/r/...=share&utm_medium=ios_app

De update naar PVE6 voer ik nu niet omdat ik niet weet of mijn omgeving hier last van krijgt (gewoon een stapeltje 4TB disken in RAIDZ, ashift=12, compression=lz4).

Zijn er specifieken bekend in welke gevallen dit issue optreed?

[mdbraber]

LiquidSmoke schreef op vrijdag 26 juli 2019 @ 10:07:
[...]
Zijn er specifieken bekend in welke gevallen dit issue optreed?

In deze comment wordt uitgelegd in welke kernels de FPU export was verwijderd: na 4.14.120 en na 4.19.38 (naast de 5.0 kernels). Er is een fix (https://github.com/zfsonl...859c7a942eb15b98d68ce5b4d) die geimplementeerd wordt in ZFS 0.8.2 en ook gebackport wordt naar 0.7 zo te lezen.

https://github.com/zfsonl...93#issuecomment-496709454

@tonyhutter Is it prudent to clarify that this patch has been backported to the LTS branches in a semi-public place? I knew that 5.x was impacted because of the changelog entry on 0.7.13, but didn't notice the patchset got backported. The issue that tracks this (#8259) also repeatedly lists relevant commits as affecting "Linux 5.0+".

For the record, it appears the FPU export was removed in 4.19.38 (released 2019-05-02) via d4ff57d0320bf441ad5a3084b3adbba4da1d79f8 and 4.14.120 (released 2019-05-16) via a725c5201f0807a9f843db525f5f98f6c7a4c25b.

Users of the LTS branches: be advised that (at least) as of these versions, you're subject to the same slowdown that applied to the 5.0 branch.

[A1AD]

LiquidSmoke schreef op vrijdag 26 juli 2019 @ 10:07:
[...]


De update naar PVE6 voer ik nu niet omdat ik niet weet of mijn omgeving hier last van krijgt (gewoon een stapeltje 4TB disken in RAIDZ, ashift=12, compression=lz4).

Zijn er specifieken bekend in welke gevallen dit issue optreed?

Ik heb net iets voorgehad > https://forum.proxmox.com/threads/grub-rescue-mode-after-rpool-upgrade.56381/

[OsiriS.nl]

Beste,

Ik heb een nieuwe server opgezet met proxmox 6.0. Sinds gisteren heb ik de volgende errors.
Iemand een idee hoe ik dit kan debuggen?



Ik heb dit probleem sinds ik een Ubuntu 19.04 VM heb aangemaakt maar tegelijkertijd heb ik ook een ZFS mirror op de host aangemaakt. Ik ben bang dat dit nu iets te maken heeft met deze ZFS mirror, maar ik lees op internet diverse berichten dat soortgelijke errors door een VM kunnen komen.
Hoe kan ik dit uitzoeken?

[ Voor 62% gewijzigd door OsiriS.nl op 30-07-2019 08:33 ]

[dcm360]

Op het eerste gezicht ziet het er uit als een schijf die niet wil/kan praten met de schijfcontroller. De eerste stap is dus de SMART van de schijf uitlezen om te kijken of die nog in orde is.

[OsiriS.nl]

Welke schijf? SDA, die geen rare stats.
Waar staat ATA1.00 voor?

[joker1977]

LiquidSmoke schreef op vrijdag 26 juli 2019 @ 10:07:
[...]


De update naar PVE6 voer ik nu niet omdat ik niet weet of mijn omgeving hier last van krijgt (gewoon een stapeltje 4TB disken in RAIDZ, ashift=12, compression=lz4).

Zijn er specifieken bekend in welke gevallen dit issue optreed?

Ik kan je niet helpen die vraag te beantwoorden, maar ik heb de update wel doorgevoerd voor mijn server.

Ik merk geen snelheidsprobleem op mijn 7x 4TB RAIDZ2 ZFS-pool. Ik zie een scrub lopen met:
scan: scrub in progress since Wed Jul 31 08:36:39 2019
7.94T scanned at 735M/s, 7.41T issued at 686M/s, 11.2T total
0B repaired, 66.30% done, 0 days 01:35:56 to go

Dat lijkt me behoorlijk wat sneller dan ik eerder had onder ZFS 0.7

Daarnaast kunnen mijn SSD's (die ik in een andere pool heb) nu geTRIM' ed worden, dat is altijd fijn

[LiquidSmoke]

joker1977 schreef op woensdag 31 juli 2019 @ 11:48:
[...]


Ik kan je niet helpen die vraag te beantwoorden, maar ik heb de update wel doorgevoerd voor mijn server.

Ik merk geen snelheidsprobleem op mijn 7x 4TB RAIDZ2 ZFS-pool. Ik zie een scrub lopen met:
scan: scrub in progress since Wed Jul 31 08:36:39 2019
7.94T scanned at 735M/s, 7.41T issued at 686M/s, 11.2T total
0B repaired, 66.30% done, 0 days 01:35:56 to go

Dat lijkt me behoorlijk wat sneller dan ik eerder had onder ZFS 0.7

Daarnaast kunnen mijn SSD's (die ik in een andere pool heb) nu geTRIM' ed worden, dat is altijd fijn

Netjes!

Binnenkort toch maar upgraden dus

[Gamerkoe]

Ik heb net een nieuwe server (onderdelen) gekocht en wilde Proxmox installeren. Het moederbord is een Fujitsu D3644-B met RAID ondersteuning. Wanneer ik deze inschakel via de BIOS dan wordt in de Proxmox installatie daarna alsnog twee keer een HDD herkend. Het RAID lijkt niet te werken?

Of is het beter om Proxmox ZFS raid te gebruiken?

[Freeaqingme]

Gamerkoe schreef op zaterdag 3 augustus 2019 @ 14:36:
Ik heb net een nieuwe server (onderdelen) gekocht en wilde Proxmox installeren. Het moederbord is een Fujitsu D3644-B met RAID ondersteuning. Wanneer ik deze inschakel via de BIOS dan wordt in de Proxmox installatie daarna alsnog twee keer een HDD herkend. Het RAID lijkt niet te werken?

Of is het beter om Proxmox ZFS raid te gebruiken?

Dat klinkt als softraid, en dat wil je in ieder geval niet

Zelf heb ik niet zo veel met raid controllers, in mijn beleving levert dat meer problemen op dan dat ze oplossen. Als ZFS geschikt is voor jouw use case (en meestal voldoet het prima), dan zou ik inderdaad gewoon voor ZFS gaan. Wel even de raid opties in je bios uitzetten, zit dat in ieder geval niet in de weg.

[Gamerkoe]

Het wordt een Home server voor enkele VM's zoals Home Assistant, TVHeadend en OpenVPN server. Ik moet ZFS raid gaan uitzoeken om te onderzoeken of dit prima is, maar als je aangeeft dat dit meestel prima voldoet dan zal dit voor mijn doel ook wel het geval zijn.

Mag ik verwachten dat in dit geval Proxmox mij ook notificaties kan sturen indien het volume beschadigd raakt indien je het software matig in het Host OS inricht? Of verwacht ik dan teveel ?

[dcm360]

Uit mijn hoofd weet ik niet of zed (ZFS Event Daemon) standaard geïnstalleerd wordt, maar die houdt mij netjes op de hoogte van wat er gebeurd met mijn pools (wat met een paar niet helemaal jofele schijven wel een paar mailtjes per maand oplevert).

[A1AD]

Gamerkoe schreef op zaterdag 3 augustus 2019 @ 14:45:
Het wordt een Home server voor enkele VM's zoals Home Assistant, TVHeadend en OpenVPN server. Ik moet ZFS raid gaan uitzoeken om te onderzoeken of dit prima is, maar als je aangeeft dat dit meestel prima voldoet dan zal dit voor mijn doel ook wel het geval zijn.

Mag ik verwachten dat in dit geval Proxmox mij ook notificaties kan sturen indien het volume beschadigd raakt indien je het software matig in het Host OS inricht? Of verwacht ik dan teveel ?

Hier vind je alle info.

[Munchie]

Heeft hier iemand ervaring met het gebruik van encryptie i.c.m Proxmox?
Ik ben niet op zoek naar full disk encyrption, maar zou graag een plek hebben om privé bestanden veilig te kunnen opslaan.

Ik zat zelf te denken om twee partities aan te maken, één gewoon, en één LUKS encrypted, die ik bijvoorbeeld op een Next Cloud VM aansluit. Weet niet of dit de handigste manier is, en of het gaat werken.

De illustratie hieronder is hoe ik de Proxmox server will opzetten.

[unezra]

Dit weekend ontdekt dat ook de Proxmox Mail Gateway (PMG) -- een spam & virusfilter op basis van Clamav en SpamAsassin -- 100% gratis te gebruiken is en hetzelfde licentiemodel kent als Proxmox Virtual Environment (PVE).

https://www.proxmox.com/en/proxmox-mail-gateway

Documentatie is niet zo mooi als die van PVE, maar staat wel online:
https://pmg.proxmox.com/pmg-docs/

Hebben mensen daar ervaring mee?
Pro's, con's?

(Ik wil 'm vooralsnog enkel thuis inzetten. Ben MailScanner zat. Te veel gedoe om te configureren, geen fatsoenlijke GUI. De GUI van PGM ziet er redelijk gelijk uit aan die van PVE en dat is een van de dingen die ze echt *prima* voor elkaar hebben daar bij Proxmox Server Solutions GmbH.)

[duiveltje666]

unezra schreef op maandag 5 augustus 2019 @ 08:37:
Dit weekend ontdekt dat ook de Proxmox Mail Gateway (PMG) -- een spam & virusfilter op basis van Clamav en SpamAsassin -- 100% gratis te gebruiken is en hetzelfde licentiemodel kent als Proxmox Virtual Environment (PVE).

https://www.proxmox.com/en/proxmox-mail-gateway

Documentatie is niet zo mooi als die van PVE, maar staat wel online:
https://pmg.proxmox.com/pmg-docs/

Hebben mensen daar ervaring mee?
Pro's, con's?

(Ik wil 'm vooralsnog enkel thuis inzetten. Ben MailScanner zat. Te veel gedoe om te configureren, geen fatsoenlijke GUI. De GUI van PGM ziet er redelijk gelijk uit aan die van PVE en dat is een van de dingen die ze echt *prima* voor elkaar hebben daar bij Proxmox Server Solutions GmbH.)

Ik heb em gebruikt , maar ben toch over gegaan op zelfbouw (want spamassassin is relatief traag en belastend voor cpu) . Het werd Clamav en Rspamd

[unezra]

duiveltje666 schreef op maandag 5 augustus 2019 @ 17:22:
[...]
Ik heb em gebruikt , maar ben toch over gegaan op zelfbouw (want spamassassin is relatief traag en belastend voor cpu) . Het werd Clamav en Rspamd

Beviel het verder wel?
Nog dingen waar ik rekening mee moet houden?

Gisteren even heel snel een LXC aangeslingerd puur om eens door de GUI heen te klikken. LXC hortelt wat en hij lijkt minimaal 2G geheugen nodig te hebben om zich helemaal senang te voelen. GUI ziet er verder goed uit alleen nog niet echt dingen ingesteld.

Twijfel nu vooral tussen LXC en een full-blown-vm, ik vraag me af of LXC wel veel minder resources in beslag neemt als een reguliere vm. Twijfel ook hoe groot de disk moet zijn, maar da's misschien gewoon een kwestie van kijken hoe groot mijn huidige maildir is.

[harmen@tachyon:~]$ du -hs Maildir/
22G Maildir/

Ok. Dat moet met een 25G Thin Provisioned dus goed te doen zijn.

Op dit moment doe ik het zelf, met MailScanner, maar dat vind ik beroerd werken en het concept van een aparte appliance voor mailfiltering spreekt me wel aan. Ik kreeg ook nog deze tip: https://efa-project.org/
Maar als ik de screenshots bekijk word ik daar niet heel warm van. Onoverzichtelijke griebusbende uit het jaar 1990. De UI van PMG ziet er super clean uit en persoonlijk vind ik dát wel belangrijk. Ik vind het niet erg mijn mailfilter een beetje te onderhouden maar met moet wel eenvoudig zijn.

Wat ik niet goed begrijp is waarom ze een "Internal SMTP Port" definiëren. Waarvoor word die gebruikt?
Die staat op 26, maar ik maak daar niet uit op of je die poort nu moet gebruiken als je vanaf interne hosts naar de PMG mail wil sturen, of dat die poort enkel intern op de PMG zelf word gebruikt.

[NaliXL]

Het was vakantietijd dus ben ik maar eens flink aan het upgraden geslagen, want rustig op het bedrijfsnetwerk. Proxmox een upgrade gegeven vanaf versie 4, via 5 naar 6. Daarmee werden de gluster binaries binnen proxmox automatisch bijgewerkt naar versie 5.5.

Het upgraden van de gluster cluster (2 machines met 3 replicated volumes, waaronder 1 met disk images voor proxmox) vanaf versie 3.8 via 3.12 naar 5.9 stond ook nog op mijn wenslijstje en verliep ook vlekkeloos. Uiteraard de OP-versie ook naar 50400 gezet. So far so good.

Omdat het met sommige VM images na een reboot of ander incident soms uren duurde voordat een heal compleet was, heb ik sharding aangezet op dat volume en heb vast enkele VM images gekopiëerd (zodat ze in shards verdeeld worden). Ook hier geen enkel probleem.

Last but not least heb ik besloten om aan het volume waar de VM images op staan een arbiter toe te voegen. Dat leek vlekkeloos te gaan, en er zijn tot nu toe geen problemen met het opslaan of de integriteit van de data opgetreden.
MAAR sinds het toevoegen van de arbiter heeft gluster voortdurend een heal backlog op één of beide van de opslag nodes. Nooit op de arbiter node. Er is bijna altijd een lijst met shards en/of bestanden die een heal nodig (lijken te) hebben. De lijst lijkt voortdurend te veranderen. Geef ik handmatig een opdracht voor een (full) heal dan verdwijnen de shards binnen een paar seconden als sneeuw voor de zon. Disk images duren wat langer uiteraard.

In de gluster logs staat vervolgens meestal (maar niet altijd lijkt het) een heal log:

code:

[2019-08-06 11:44:36.640247] I [MSGID: 108026] [afr-self-heal-common.c:1729:afr_log_selfheal] 0-systemdisks-replicate-0: Completed data selfheal on 887ee4e0-f51e-49bb-bd18-af55984a8236. sources=[0] 1  sinks=2

De volume configuratie:

code:

root@bunker1:/mnt/systemdisks/images/101# gluster volume info systemdisks

Volume Name: systemdisks
Type: Replicate
Volume ID: f04f3e26-a031-4295-b678-a07176bed89a
Status: Started
Snapshot Count: 1
Number of Bricks: 1 x (2 + 1) = 3
Transport-type: tcp
Bricks:
Brick1: bunker1.domein:/opt/glusterdata/systemdisks/gluster
Brick2: bunker2:/opt/glusterdata/systemdisks/gluster
Brick3: arbiter.domein:/opt/glusterdata/systemdisks (arbiter)
Options Reconfigured:
features.shard: on
features.shard-block-size: 64MB
performance.write-behind-window-size: 8MB
features.barrier: disable
features.scrub: Active
features.bitrot: on
nfs.disable: on
performance.readdir-ahead: on
transport.address-family: inet
cluster.self-heal-daemon: enable
server.allow-insecure: on

Ik hoop dat er iemand zijn licht op kan laten schijnen wat er hier aan de hand kan zijn, want alhoewel het allemaal wel goed lijkt te gaan vind ik het behoorlijk spannend zo...

[ Voor 24% gewijzigd door NaliXL op 06-08-2019 13:50 . Reden: Te vlug geblaat over logs en wat info aanvullen ]

[duiveltje666]

unezra schreef op dinsdag 6 augustus 2019 @ 06:42:
[...]

Beviel het verder wel?
Nog dingen waar ik rekening mee moet houden?

Gisteren even heel snel een LXC aangeslingerd puur om eens door de GUI heen te klikken. LXC hortelt wat en hij lijkt minimaal 2G geheugen nodig te hebben om zich helemaal senang te voelen. GUI ziet er verder goed uit alleen nog niet echt dingen ingesteld.

Twijfel nu vooral tussen LXC en een full-blown-vm, ik vraag me af of LXC wel veel minder resources in beslag neemt als een reguliere vm. Twijfel ook hoe groot de disk moet zijn, maar da's misschien gewoon een kwestie van kijken hoe groot mijn huidige maildir is.

[harmen@tachyon:~]$ du -hs Maildir/
22G Maildir/

Ok. Dat moet met een 25G Thin Provisioned dus goed te doen zijn.

Op dit moment doe ik het zelf, met MailScanner, maar dat vind ik beroerd werken en het concept van een aparte appliance voor mailfiltering spreekt me wel aan. Ik kreeg ook nog deze tip: https://efa-project.org/
Maar als ik de screenshots bekijk word ik daar niet heel warm van. Onoverzichtelijke griebusbende uit het jaar 1990. De UI van PMG ziet er super clean uit en persoonlijk vind ik dát wel belangrijk. Ik vind het niet erg mijn mailfilter een beetje te onderhouden maar met moet wel eenvoudig zijn.

Wat ik niet goed begrijp is waarom ze een "Internal SMTP Port" definiëren. Waarvoor word die gebruikt?
Die staat op 26, maar ik maak daar niet uit op of je die poort nu moet gebruiken als je vanaf interne hosts naar de PMG mail wil sturen, of dat die poort enkel intern op de PMG zelf word gebruikt.

toon volledige bericht

De Gui was leuk , maar dat zit op Rspamd ook ...
Eind van het verhaal , waar Rspamd al klaar was met scannen van 1000 berichten stond Spamassassin halverwege te kotsen bijna
en de keuze tussen LXC en VM is simpel : Krijg je veeeeeel mail ? VM . Weinig mail? -> LXC

[joker1977]

duiveltje666 schreef op dinsdag 6 augustus 2019 @ 16:12:
[...]

De Gui was leuk , maar dat zit op Rspamd ook ...
Eind van het verhaal , waar Rspamd al klaar was met scannen van 1000 berichten stond Spamassassin halverwege te kotsen bijna
en de keuze tussen LXC en VM is simpel : Krijg je veeeeeel mail ? VM . Weinig mail? -> LXC

Ik begrijp niet waarom de hoeveelheid mail invloed heeft op de keus of je LXC of een VM gebruikt.

Ik kan allerlei redenen bedenken waarom je LXC of juist een VM gebruikt, maar de hoeveelheid mail heeft daar in mijn beleving niets mee te maken.

Wat is de redenering daarachter?

[duiveltje666]

joker1977 schreef op vrijdag 9 augustus 2019 @ 11:55:
[...]


Ik begrijp niet waarom de hoeveelheid mail invloed heeft op de keus of je LXC of een VM gebruikt.

Ik kan allerlei redenen bedenken waarom je LXC of juist een VM gebruikt, maar de hoeveelheid mail heeft daar in mijn beleving niets mee te maken.

Wat is de redenering daarachter?

In mijn beleving loopt een container altijd minder hard , heb ook testen gedaan , similar setup en op hetzelfde moment op beide bakken meerdere malen dezelfde hoeveelheid mail erdoor gejaagd .. de container was nog bezig terwijl de VM al aan ronde 2 begon..

[unezra]

Ik heb toch gekozen voor een vm.
De setup van de container laat wat te wensen over en bij zoiets kritieks vind ik dat geen fijn gevoel geven.
Dus ik heb de ISO gepakt en PMG als vm geïnstalleerd.

Draait en is getest. Werkt vooralsnog goed maar er is nog geen serieuze mail doorheen gegaan.
Ik hoop de komende dagen de eerste slagen te maken met het overzetten van mijn mail. (Zal de komende tijd nog wel wat spam op binnen komen wat afgevangen moet worden. Een oud domein raak je niet snel vanaf en kan ook niet makkelijk uitgefaseerd worden.)

Vind het iig tot nu toe prettig werken. Moet er nu wel rekening mee houden dat als ik een nieuw domein in gebruik neem, ik dat op 2 plekken toe voeg. Én in PMG én op mijn shelldoos. Maar goed, dat komt vast goed.

[A1AD]

duiveltje666 schreef op vrijdag 9 augustus 2019 @ 15:50:
[...]

In mijn beleving loopt een container altijd minder hard , heb ook testen gedaan , similar setup en op hetzelfde moment op beide bakken meerdere malen dezelfde hoeveelheid mail erdoor gejaagd .. de container was nog bezig terwijl de VM al aan ronde 2 begon..

Wut? Dat is de eerste keer dat ik zoiets hoor. Een container zit toch veel dichter op het metaal dan een VM??

[Freeaqingme]

duiveltje666 schreef op vrijdag 9 augustus 2019 @ 15:50:
[...]

In mijn beleving loopt een container altijd minder hard , heb ook testen gedaan , similar setup en op hetzelfde moment op beide bakken meerdere malen dezelfde hoeveelheid mail erdoor gejaagd .. de container was nog bezig terwijl de VM al aan ronde 2 begon..

Dat kan. Mail benchmarks zijn doorgaans vooral IO tests, waaribj de throughput van het filesystem beproefd wordt. Dit omdat mailserversoftware vaak werkt met een lokale spool directory om te garanderen dat mail gegarandeerd (>=1 keer) verstuurd wordt nadat deze geacepteerd is.

De vraag is dan ook wat voor container het was. Als ik zomaar moet gokken was het een docker-achtige container, met een FS op basis van allemaal losse laagjes (bijv. overlayfs). Dat zorgt er - zeker met mail-benchmarks voor - dat een container veel trager is dan wanneer je een VM op een raw file/device draait.

heb je al die dingen als overlayfs niet, dan is het in theorie mogelijk om een container iets meer performant te krijgen dan die VM. Bij een VM moet je immers meer context switches doen tussen de guest en de vm. Daarnaast draai je 2 kernels etc.

Dat is wel als je het 'perfect' tunet. Het is makkelijker om de performane van een container te verkloten dan die van een VM.

offtopic:
En dan kan je ook nog een discussie voeren wat een container is, aangezien de linux kernel alleen het concept cgroups en namespaces kent...

[unezra]

@Freeaqingme Ik gok dat het hier om LXC gaat, gezien de context van PVE.

PMG word ook geleverd als LXC container door Proxmox Server Solutions GmbH. Heb heel kort (een uurtje) daarmee gespeeld, puur om de keuze te maken tussen LXC en een reguliere KVM vm. Ben gegaan voor het laatste, omdat de installer daarvan wél zijn werk goed deed.

Zit nog wel een klein foutje in mbt LVM, hij doet @boot een scan om zijn disks te zien. Blijkbaar zijn de volumes niet ergens opgeslagen in een config file. Los ik nog wel een keer op. Totaal minor gezien die scan prima zijn werk doet en het letterlijk niet meer oplevert dan een paar seconden vertraging en een foutmelding @boot waar 'ie zelf doorheen knart.

Als alles goed gaat, zal PMG een uptime halen van een paar maanden tot een jaar. (Ik wil toch wat vaker onderhoud plannen thuis. Nu update ik vm's onregelmatig. Kan geen kwaad het aantal vm's te reduceren en tegelijkertijd gewoon 4x per jaar een avondje apt update te doen.)

[Freeaqingme]

unezra schreef op zaterdag 10 augustus 2019 @ 08:56:
@Freeaqingme Ik gok dat het hier om LXC gaat, gezien de context van PVE.

Als we nog even doorgaan kunnen we wel een casino beginnen

Realiseerde me dat dit topic primair om PVE ging. Alleen @duiveltje666 had 't over "containers" en het kon natuurlijk dat deze het een keer buiten Proxmox getest had, en die ervaring ook binnen Proxmox toepaste.

[zx9r_mario]

Gamerkoe schreef op zaterdag 3 augustus 2019 @ 14:36:
Ik heb net een nieuwe server (onderdelen) gekocht en wilde Proxmox installeren. Het moederbord is een Fujitsu D3644-B met RAID ondersteuning. Wanneer ik deze inschakel via de BIOS dan wordt in de Proxmox installatie daarna alsnog twee keer een HDD herkend. Het RAID lijkt niet te werken?

Of is het beter om Proxmox ZFS raid te gebruiken?

Proxmox vereist een echte raidcontroller, je kunt dan het beste ZFS raid gebruiken.

[ocf81]

HBA kan ook hoor.

[unezra]

zx9r_mario schreef op woensdag 21 augustus 2019 @ 16:57:
[...]
Proxmox vereist een echte raidcontroller, je kunt dan het beste ZFS raid gebruiken.

Eh, nee.

Met ZFS wil je juist géén RAID controller, maar een HBA.

Ook met andere softraid vormen voegt een RAID controller niets toe.

In principe voldoen std. on-boad SATA poorten meer dan prima voor ZFS, heb je meer poorten nodig, kun je gaan voor een HBA, nooit een RAID controller.

EDIT:

Overigens is niet iedere ZFS implementatie, een RAID implementatie.

De RAID0, RAID1, RAID10 en RAID 0+1 implementaties heten bij ZFS geen RAID maar stripe, mirror, mirrored stripe en striped mirror.

RAIDZ1 is grofweg vergelijkbaar met RAID5, RAIDZ2 met RAID6 en RAIDZ3 bestaat niet in de klassieke RAID levels. In alle gevallen mag je dat nooit "RAID" noemen, maar altijd "RAIDZ", omdat het een heel specifieke ZFS implementatie is.

Ook zonder welke vorm van RAID, mirroring of striping dan ook is ZFS nuttig. Het kan ook prima op een enkele disk zijn nut bewijzen.

EDIT:
@zx9r_mario Ik realiseer me dat ik mogelijk je zin verkeerd las / interpreteerde.
Sorry. (Namelijk dat je ZFS met RAID controller moet gebruiken, maar ws bedoel je dat PVE met RAID controller gebruikt moet worden, óf je ZFS moet gebruiken maar dan met HBA of reguliere SATA poorten.)

Thnx @Wolfensteijn voor de opmerkzaamheid.

[ Voor 49% gewijzigd door unezra op 22-08-2019 12:12 ]

[_JGC_]

Proxmox is Debian met een Ubuntu kernel, zelfs met Fakeraid die je aanmaakt in de BIOS moet dat gewoon kunnen werken. Ja je ziet 2 losse disks, maar die zou je gewoon als raidset moeten kunnen benaderen via dmraid.

[zx9r_mario]

Dat gaat niet werken. MDraid driver is standaard niet geactiveerd in Proxmox.

Je kunt wel eerst Debian installeren met mdraid en daarna handmatig Proxmox installeren: https://pve.proxmox.com/w...oxmox_VE_on_Debian_Jessie

Of Proxmox op 1 disk installeren en daarna mdraid via deze procedure: https://www.prado.lt/prox...software-raid-using-mdadm.

[ Voor 8% gewijzigd door zx9r_mario op 22-08-2019 12:03 ]

[unezra]

zx9r_mario schreef op donderdag 22 augustus 2019 @ 12:02:
Dat gaat niet werken. MDraid driver is standaard niet geactiveerd in Proxmox.

Je kunt wel eerst Debian installeren met mdraid en daarna handmatig Proxmox installeren: https://pve.proxmox.com/w...oxmox_VE_on_Debian_Jessie

Of Proxmox op 1 disk installeren en daarna mdraid via deze procedure: https://www.prado.lt/prox...software-raid-using-mdadm.

Sterker nog, PVE raad het compleet af:
https://pve.proxmox.com/wiki/Software_RAID

All Proxmox VE versions does not support the Linux Software RAID (mdraid). That means, its not tested in our labs and its not recommended, but its still used by experience users. If you want to run a supported configuration, go for Hardware RAID.

Met andere woorden: Als je iets van RAID functionaliteit wil op je ZFS PVE installatie, ga voor ZFS.
(Dat is sowieso een heel goede keuze.) Hardware RAID raad ik hoe dan ook af. In eigenlijk iedere situatie anno 2019, niet alleen voor PVE.

[ Voor 4% gewijzigd door unezra op 22-08-2019 12:06 ]

[_JGC_]

@unezra ik verkoop MKB eigenlijk alleen nog maar proxmox met ZFS. Voor de prijs van een RAID controller en BBU kan je heel wat geheugen kopen om als ARC te gebruiken.

[unezra]

_JGC_ schreef op donderdag 22 augustus 2019 @ 12:19:
@unezra ik verkoop MKB eigenlijk alleen nog maar proxmox met ZFS. Voor de prijs van een RAID controller en BBU kan je heel wat geheugen kopen om als ARC te gebruiken.

Hardware RAID heeft anno 2019 ook eigenlijk geen voordelen meer.
Zeker niet met zoiets als ZFS.

Wel tof trouwens dat je ook werkelijk PVE verkoopt. Dat komt volgens mij niet vaak voor.

[ Voor 11% gewijzigd door unezra op 22-08-2019 12:49 ]

[Incolumis]

Ik meld me even, ben gister ook begonnen met Proxmox. Ik heb een klein beetje ervaring met Linux en wat ervaring met Openmediavault.
Ik heb sinds deze week een nieuwe computer gebouwd, namelijk:

#	Category	Product	Prijs	Subtotaal
1	Processors	AMD Ryzen 5 3400G Boxed	€ 150,95	€ 150,95
1	Barebones	ASRock DeskMini A300	€ 144,-	€ 144,-
1	Processorkoeling	Noctua NH-L9a-AM4	€ 39,95	€ 39,95
1	Geheugen intern	G.Skill Ripjaws F4-3200C18D-16GRS	€ 103,50	€ 103,50
1	Solid state drives	Intel 660p 512GB	€ 60,96	€ 60,96
1	Solid state drives	Samsung 850 EVO 500GB	€ 99,95	€ 99,95
Bekijk collectie Importeer producten			Totaal	€ 599,31

Ook heb ik er een 500GB hdd er bij gedaan, want waarom niet?
Proxmox is geinstalleerd op de nvme schijf, en de SATA SSD en HDD zijn nu nog leeg.

Wat wil ik er mee doen? Ik wil Windows 10 op de SSD en Openmediavault op de HDD draaien. via OMV draait dan docker met verschillende containers. (Plex, Sonarr, Radarr, SABNZBD, qBittorrent, Bazarr, Lidarr, Jackett, pi-hole, Home Assistant, etc.)
Is dit een goede manier? Of kan ik beter gewoon LXC containers hiervan direct in Proxmox runnen, en OMV helemaal overslaan?
Graag in Jip en Janneke-taal, want zoals ik al zei, ik heb er nog niet zo heel veel verstand van

[Kaspers]

Incolumis schreef op donderdag 22 augustus 2019 @ 12:57:
Wat wil ik er mee doen? Ik wil Windows 10 op de SSD en Openmediavault op de HDD draaien. via OMV draait dan docker met verschillende containers. (Plex, Sonarr, Radarr, SABNZBD, qBittorrent, Bazarr, Lidarr, Jackett, pi-hole, Home Assistant, etc.)
Is dit een goede manier? Of kan ik beter gewoon LXC containers hiervan direct in Proxmox runnen, en OMV helemaal overslaan?
Graag in Jip en Janneke-taal, want zoals ik al zei, ik heb er nog niet zo heel veel verstand van

Persoonlijk zou ik een privileged LXC container aanmaken (met nesting feature), waarin je de docker service draait met vervolgens de docker containers die je nodig hebt. Geeft je veel flexibiliteit. En je alloceert geen resources, want je draait een LXC en geen VM. Met proxmox maak je vervolgens backups van deze LXC container, en kunt je op ieder moment de hele LXC inclusief de docker containers restoren wanneer 't spul weer eens stuk is.

Deze LXC zou ik op de NVME draaien, de data (media e.d.), download-dirs, etc. zou ik op de SSD / HDD zetten, met bind-mounts naar de LXC container en vervolgens doorlinken naar de benodigde docker-containers.

Ik vermoed dat ik met deze opmerking een docker in LXC vs VM discussie ontketen, maar je vroeg naar een mening .

[ Voor 7% gewijzigd door Kaspers op 22-08-2019 21:36 ]

[3raser]

Ik ben compleet nieuw in Proxmox en ik zie dat de Jip en Janneke taal ook al bijna onleesbaar is. Toch ga ik het proberen met mijn vraag.

Als test (om te wennen met Proxmox) heb ik een Virtualbox VM gemaakt en Proxmox 6.0-1 geïnstalleerd. De installatie verliep uiteraard vlekkeloos en mijn Proxmox host is bereikbaar via het netwerk. In de webGUI zie ik momenteel zelfs 6.0-4 staan dus dat zal wel via updates gegaan zijn. Daarna heb ik een Ubuntu 18.04 template gedownload en een nieuwe container gemaakt op basis van dat template. Bij de netwerkinstellingen heb ik als ip4 adres 192.168.10.17/32 ingevuld omdat ik de container 1 vast IP adres wil geven en ik heb de gateway ook ingevuld. De container is gestart en via console (webGUI) kan ik inloggen. Ik heb echter geen netwerk. /etc/network/interfaces is leeg en zegt alleen maar:

code:

# ifupdown has been replaced by netplan(5) on this system.  See
# /etc/netplan for current configuration.
# To re-enable ifupdown on this system, you can run:
#    sudo apt install ifupdown

ifconfig werkt niet en kan ik niet installeren omdat ik geen internet heb. Met

code:

netplan generate

gebeurt er ook niets. De map /etc/netplan blijft leeg. Ik kan wel pingen naar mijn eigen IP adres (dus 192.168.10.17) maar niet naar de gateway of de host.

Vervolgens heb ik de netwerkconfiguratie van de container aangepast en op DHCP gezet. De container is herstart maar het resultaat is hetzelfde. Daarna de container maar weer terug gezet op static IP omdat dat is wat ik wil.

Wat doe ik verkeerd? Ik wil de container simpelweg een IP adres in mijn bestaande netwerk geven inclusief internet toegang.

[dcm360]

In VirtualBox moet je aangeven dat Promiscuous mode toegestaan is op de netwerkadapter, en het ip-adres dat je aan de container geeft zit niet in hetzelfde subnet als de gateway, waarschijnlijk wil je /24 instellen in plaats van /32.

[3raser]

dcm360 schreef op zaterdag 7 september 2019 @ 16:08:
In VirtualBox moet je aangeven dat Promiscuous mode toegestaan is op de netwerkadapter, en het ip-adres dat je aan de container geeft zit niet in hetzelfde subnet als de gateway, waarschijnlijk wil je /24 instellen in plaats van /32.

Ontzettend bedankt. Ik weet nu dus dat de CIDR het subnet moet bevatten waar ik het betreffende IP adres in wil hebben. Ik dacht namelijk dat je daar een subnet kon toewijzen aan de container om vervolgens in de guest zelf de IP adressen toe te wijzen.

Het werkt nu!

[wopie]

Even een korte vraag, ik wil via de gui van proxmox 6 bind mounts toevoegen, kan dit uberhaupt via de gui?

Google geeft mij nog niet het gewenste resultaat (en nee ik bedoel niet bind-mounts maken via de gui-shell feature). Ik probeer een lcx (Debian) fileserver op te zetten en wil graag gebruik maken van mijn eigen dataset-structuur die ik op de disk heb staan (gemaakt middels zfs-create).

Hoe runnen jullie een NAS middels proxmox? gewoon samba op de host? Of een kvm met disken in passtrough?
Mijn voorkeur is eigenlijk de SmartOS way, gewoon een container met daarin een stuk ZFS afgekaderd (in SmartOS kun je een ZFS-dataset delegaten naar je container en dat dan vanuit daar managen), maar het lijkt erop dat iets dergelijks onder Proxmox niet zo makkelijk gaat.

[dcm360]

Samba heb ik (samen met ldap) in een container zitten, en met bind mounts heeft deze container toegang tot enkele zfs datasets op de host. iSCSI doe ik wel direct van op de host.

[ocf81]

Ik ben uiteindelijk gecapituleerd en heb nu als NAS FreeNAS draaien vanwaar ik de images voor mijn VMs host via iSCSI. Dat werkt prima. De overige files host ik via een samba share.

[unezra]

ocf81 schreef op zaterdag 7 september 2019 @ 23:47:
Ik ben uiteindelijk gecapituleerd en heb nu als NAS FreeNAS draaien vanwaar ik de images voor mijn VMs host via iSCSI. Dat werkt prima. De overige files host ik via een samba share.

Ik heb het tot nu toe via NFS gedaan, met QCOW2 images op mijn FreeNAS machine.
Gaat ook meer dan prima.

Mijn nieuwe setup gaat FreeNAS er uit maar ik moet daar echt nog even heel goed nadenken wat de beste optie is voor filesharing.

Meest logische is een dedicated vm of container met een purpose-built filesharing distro, maar ik weet nog niet of ik een dataset passthrough (als dat kan), of dat ik domweg mijn SMB data in een aparte QCOW2 image zet.

Het heeft beiden zijn voor- en nadelen.

Samba op de hypervisor lijkt me iig géén goed idee. Ik wil zo min mogelijk klooien aan mijn hypervisor.
Backups in de vorm van sanoid/syncoid en een Zabbix agent, samen met misschien wat basistools als vim, zijn denk ik het verste dat ik wil gaan. https://github.com/jimsalterjrs/sanoid

[A1AD]

unezra schreef op zondag 8 september 2019 @ 10:37:
[...]


Ik heb het tot nu toe via NFS gedaan, met QCOW2 images op mijn FreeNAS machine.
Gaat ook meer dan prima.

Mijn nieuwe setup gaat FreeNAS er uit maar ik moet daar echt nog even heel goed nadenken wat de beste optie is voor filesharing.

Meest logische is een dedicated vm of container met een purpose-built filesharing distro, maar ik weet nog niet of ik een dataset passthrough (als dat kan), of dat ik domweg mijn SMB data in een aparte QCOW2 image zet.

Het heeft beiden zijn voor- en nadelen.

Samba op de hypervisor lijkt me iig géén goed idee. Ik wil zo min mogelijk klooien aan mijn hypervisor.
Backups in de vorm van sanoid/syncoid en een Zabbix agent, samen met misschien wat basistools als vim, zijn denk ik het verste dat ik wil gaan. https://github.com/jimsalterjrs/sanoid

toon volledige bericht

Debian LXC met Samba en bind mounts van je ZFS datasets van pve naar je samba lxc. Werkt hier als een trein.

Edit: sanoid gebruik ik inderdaad ook vanop de host.

[3raser]

Er lijken erg veel meningen te zijn over wat nu de beste manier is om data te delen. Ik wil een nieuwe server bouwen met de volgende drives:

1. SATA-6 SSD van 500GB als Proxmox boot drive
2. NVME SSD van 1TB om containers en VM's op te slaan (LVM Thin denk ik?)
3. SATA HDD van 4TB om data op te slaan (Directory?)
4. SATA HDD van 4TB om VM backups en data backups op te slaan (Directory?)

Drives 1 en 2 lijken me geen probleem. Drive 2 maak ik LVM Thin zodat ik ook snapshots kan maken. Het probleem is vooral hoe ik drive 3 moet gaan toepassen. Ik wil dezelfde data delen over meerdere containers/VM's en wil ook dat de data benaderbaar is als ik de drive in een ander systeem zou stoppen. Kan ik dan het beste een ext4 Directory aanmaken in Proxmox en daar Mount Points mee maken op mijn containers en VM's? Ik heb nog geen ervaring met Mount Points dus daar moet ik nog wat testjes mee uitvoeren.
Drive 4 weet ik ook nog niet. Kun je zowel VM backups als normale data opslaan zonder de schijf in meerdere delen te partitioneren?

Voor network file sharing zou ik dan een Freenas VM maken die weer toegang geeft tot de data op drive 3. Samba installeren op de host doe ik liever niet omdat ik liever alles via containers of VM's doe. De host moet als het even kan zo kaal mogelijk blijven.

[MewBie]

In het kort: Schijven 3 en 4 direct aan een FreeNAS/OMV/whatever VM/LXC koppelen. Proxmox regelt alleen maar opslag voor het hypervisor gebeuren.

[3raser]

Ik heb sinds gisteren mijn nieuwe proxmox server in gebruik genomen. Dit gaat helaas niet zonder slag of stoot. Het lijkt erop dat mijn (te nieuwe?) hardware problemen geeft. Zo heb ik een foutmelding op de console gezien en valt regelmatig de netwerkverbinding weg.

Het systeem heeft de volgende specs.

#	Category	Product
1	Processors	AMD Ryzen 5 3600 Boxed
1	Moederborden	ASRock B450M Pro4
1	Processorkoeling	Cooler Master Hyper 212 Black Edition
1	Geheugen intern	Corsair Vengeance LPX CMK32GX4M2D3000C16
1	Voedingen	Corsair VS450 (2018)
1	Solid state drive (M2 SATA)	Crucial MX500 m.2 500GB
1	Solid state drive (NVMe)	Samsung 970 EVO 1TB

Ik was gelukkig ingelogd op de host toen het probleem zich opnieuw voor deed. Bovenin beeld zie je nog dat ik een ping heb gedaan die succesvol was. Daarna komt er een foutmelding in beeld over de PCIe Bus. De volgende ping faalt direct. Ik moet vervolgens het netwerk herstarten met ifdown en ifup. Soms komt deze ook vanzelf weer in de lucht.



Foutmelding:

code:

[2397.331074] nvme 0000:01:00.0 PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Roquester ID)
[2397.331387] nvme 0000:01:00.0 device (144d: a808) error status/mask=00004000/00400000
[2397.331691] nvme 0000101:00.01 [14] Cmpit TO               (First)

Stukje syslog wat volgens mij de fout weergeeft: (sorry voor de lange tekst. Is er een tag die dit kan invouwen ofzo?)

code:

Sep 18 07:55:00 pve systemd[1]: Starting Proxmox VE replication runner...
Sep 18 07:55:00 pve systemd[1]: pvesr.service: Succeeded.
Sep 18 07:55:00 pve systemd[1]: Started Proxmox VE replication runner.
Sep 18 07:56:00 pve systemd[1]: Starting Proxmox VE replication runner...
Sep 18 07:56:00 pve systemd[1]: pvesr.service: Succeeded.
Sep 18 07:56:00 pve systemd[1]: Started Proxmox VE replication runner.
Sep 18 07:57:00 pve systemd[1]: Starting Proxmox VE replication runner...
Sep 18 07:57:00 pve systemd[1]: pvesr.service: Succeeded.
Sep 18 07:57:00 pve systemd[1]: Started Proxmox VE replication runner.
Sep 18 07:57:02 pve systemd-timesyncd[773]: Timed out waiting for reply from 213.154.236.182:123 (2.debian.pool.ntp.org).
Sep 18 07:57:12 pve systemd-timesyncd[773]: Timed out waiting for reply from 195.242.98.57:123 (2.debian.pool.ntp.org).
Sep 18 07:57:23 pve systemd-timesyncd[773]: Timed out waiting for reply from 51.15.44.1:123 (2.debian.pool.ntp.org).
Sep 18 07:57:33 pve systemd-timesyncd[773]: Timed out waiting for reply from 82.161.139.11:123 (2.debian.pool.ntp.org).
Sep 18 07:57:38 pve kernel: ------------[ cut here ]------------
Sep 18 07:57:38 pve kernel: NETDEV WATCHDOG: enp5s0 (r8169): transmit queue 0 timed out
Sep 18 07:57:38 pve kernel: WARNING: CPU: 5 PID: 0 at net/sched/sch_generic.c:461 dev_watchdog+0x221/0x230
Sep 18 07:57:38 pve kernel: Modules linked in: ebtable_filter ebtables ip_set ip6table_filter ip6_tables iptable_filter bpfilter softdog nfnetlink_log nfnetlink edac_mce_amd kvm_amd ccp kvm irqbypass snd_hda_codec_hdmi zfs(PO) zunicode(PO) zlua(PO) crct10dif_pclmul nouveau crc32_pclmul ghash_clmulni_intel mxm_wmi video ttm snd_hda_codec_realtek snd_hda_codec_generic drm_kms_helper ledtrig_audio aesni_intel snd_hda_intel aes_x86_64 wmi_bmof crypto_simd snd_hda_codec cryptd glue_helper snd_hda_core drm snd_hwdep i2c_algo_bit snd_pcm fb_sys_fops syscopyarea sysfillrect snd_timer sysimgblt pcspkr snd soundcore mac_hid zcommon(PO) znvpair(PO) zavl(PO) icp(PO) spl(O) vhost_net vhost tap ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi sunrpc ip_tables x_tables autofs4 btrfs xor zstd_compress raid6_pq dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio libcrc32c i2c_piix4 r8169 realtek ahci libahci wmi gpio_amdpt gpio_generic
Sep 18 07:57:38 pve kernel: CPU: 5 PID: 0 Comm: swapper/5 Tainted: P           O      5.0.15-1-pve #1
Sep 18 07:57:38 pve kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450M Pro4, BIOS P3.30 05/10/2019
Sep 18 07:57:38 pve kernel: RIP: 0010:dev_watchdog+0x221/0x230
Sep 18 07:57:38 pve kernel: Code: 00 49 63 4e e0 eb 92 4c 89 ef c6 05 5a a2 ef 00 01 e8 03 2b fc ff 89 d9 4c 89 ee 48 c7 c7 90 03 bb 8a 48 89 c2 e8 91 d5 78 ff <0f> 0b eb c0 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48
Sep 18 07:57:38 pve kernel: RSP: 0018:ffff9ff93e743e68 EFLAGS: 00010286
Sep 18 07:57:38 pve kernel: RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
Sep 18 07:57:38 pve kernel: RDX: 0000000000040400 RSI: 00000000000000f6 RDI: 0000000000000300
Sep 18 07:57:38 pve kernel: RBP: ffff9ff93e743e98 R08: 0000000000000001 R09: 00000000000003c3
Sep 18 07:57:38 pve kernel: R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000001
Sep 18 07:57:38 pve kernel: R13: ffff9ff92e048000 R14: ffff9ff92e0484c0 R15: ffff9ff92c142e80
Sep 18 07:57:38 pve kernel: FS:  0000000000000000(0000) GS:ffff9ff93e740000(0000) knlGS:0000000000000000
Sep 18 07:57:38 pve kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Sep 18 07:57:38 pve kernel: CR2: 0000565559c880c0 CR3: 00000007dc48a000 CR4: 0000000000340ee0
Sep 18 07:57:38 pve kernel: Call Trace:
Sep 18 07:57:38 pve kernel:  <IRQ>
Sep 18 07:57:38 pve kernel:  ? pfifo_fast_enqueue+0x120/0x120
Sep 18 07:57:38 pve kernel:  call_timer_fn+0x30/0x130
Sep 18 07:57:38 pve kernel:  run_timer_softirq+0x3e4/0x420
Sep 18 07:57:38 pve kernel:  ? ktime_get+0x3c/0xa0
Sep 18 07:57:38 pve kernel:  ? lapic_next_event+0x20/0x30
Sep 18 07:57:38 pve kernel:  ? clockevents_program_event+0x93/0xf0
Sep 18 07:57:38 pve kernel:  __do_softirq+0xdc/0x2f3
Sep 18 07:57:38 pve kernel:  irq_exit+0xc0/0xd0
Sep 18 07:57:38 pve kernel:  smp_apic_timer_interrupt+0x79/0x140
Sep 18 07:57:38 pve kernel:  apic_timer_interrupt+0xf/0x20
Sep 18 07:57:38 pve kernel:  </IRQ>
Sep 18 07:57:38 pve kernel: RIP: 0010:cpuidle_enter_state+0xbd/0x450
Sep 18 07:57:38 pve kernel: Code: ff e8 b7 30 86 ff 80 7d c7 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f 85 63 03 00 00 31 ff e8 5a 60 8c ff fb 66 0f 1f 44 00 00 <45> 85 ed 0f 88 8d 02 00 00 49 63 cd 48 8b 75 d0 48 2b 75 c8 48 8d
Sep 18 07:57:38 pve kernel: RSP: 0018:ffffbcfa4326be60 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
Sep 18 07:57:38 pve kernel: RAX: ffff9ff93e762d80 RBX: ffffffff8af628a0 RCX: 000000000000001f
Sep 18 07:57:38 pve kernel: RDX: 000001ff7b2703d8 RSI: 00000000239f5376 RDI: 0000000000000000
Sep 18 07:57:38 pve kernel: RBP: ffffbcfa4326bea0 R08: 0000000000000002 R09: 0000000000022640
Sep 18 07:57:38 pve kernel: R10: 000007477f6d86f8 R11: ffff9ff93e761c04 R12: ffff9ff92ee70000
Sep 18 07:57:38 pve kernel: R13: 0000000000000002 R14: ffffffff8af62978 R15: ffffffff8af62960
Sep 18 07:57:38 pve kernel:  cpuidle_enter+0x17/0x20
Sep 18 07:57:38 pve kernel:  call_cpuidle+0x23/0x40
Sep 18 07:57:38 pve kernel:  do_idle+0x23a/0x280
Sep 18 07:57:38 pve kernel:  cpu_startup_entry+0x1d/0x20
Sep 18 07:57:38 pve kernel:  start_secondary+0x1ab/0x200
Sep 18 07:57:38 pve kernel:  secondary_startup_64+0xa4/0xb0
Sep 18 07:57:38 pve kernel: ---[ end trace 3d4701b204e64b11 ]---
Sep 18 07:57:38 pve systemd-timesyncd[773]: Synchronized to time server for the first time 62.212.76.57:123 (3.debian.pool.ntp.org).
Sep 18 07:58:00 pve systemd[1]: Starting Proxmox VE replication runner...
Sep 18 07:58:00 pve systemd[1]: pvesr.service: Succeeded.
Sep 18 07:58:00 pve systemd[1]: Started Proxmox VE replication runner.
Sep 18 07:59:00 pve systemd[1]: Starting Proxmox VE replication runner...
Sep 18 07:59:00 pve systemd[1]: pvesr.service: Succeeded.
Sep 18 07:59:00 pve systemd[1]: Started Proxmox VE replication runner.

Kan ik iemand mij in de goede richting wijzen? De foutmelding heeft het over mijn NVMe drive maar de fout heeft overduidelijk effect op de onboard netwerk interface. Ik heb wat gelezen over ACPI instellingen van de kernel maar ik ben redelijk blauw op dat gebied. Ik wil ook niet zomaar van alles proberen omdat dit mogelijk weer andere zaken van het systeem negatief beïnvloed.

[3raser]

Ik heb de BIOS geflashed en mijn netwerk lijkt nu stabiel te werken.

[ocf81]

Altijd goed om ook de oplossing gepost te zien

[ Voor 13% gewijzigd door ocf81 op 20-09-2019 10:39 ]

[exepti0n]

wopie schreef op zaterdag 7 september 2019 @ 19:19:
Even een korte vraag, ik wil via de gui van proxmox 6 bind mounts toevoegen, kan dit uberhaupt via de gui?

Google geeft mij nog niet het gewenste resultaat (en nee ik bedoel niet bind-mounts maken via de gui-shell feature). Ik probeer een lcx (Debian) fileserver op te zetten en wil graag gebruik maken van mijn eigen dataset-structuur die ik op de disk heb staan (gemaakt middels zfs-create).

Ik verwacht dat het je ondertussen gelukt is maar volgens mij kun je de bind mounts via de GUI van een container regelen via de "Resources" van de LXC container.

Via "Add" verschijnt de optie "Mount Point"

[itcouldbeanyone]

Ik heb een fresh install van proxmox 6.04
Zodra ik van een windows cd wil booten , kom ik in een bootloop , zie het winows logo en dan reset me VM.
Heb dit niet met linux.
Zelfde server draaide eerst debian met onder virtual vox windows 10,
Is er iets verander in 6.04 waardoor windows niet wilt instaleren ?
Kan er niets over vinden

[dcm360]

Gebruik je de aanbevolen instellingen voor de VM? (Pagina loopt een beetje achter, maar zou een goede eerste zet moeten zijn)

[ Voor 24% gewijzigd door dcm360 op 21-09-2019 17:56 ]

[itcouldbeanyone]

dcm360 schreef op zaterdag 21 september 2019 @ 17:55:
Gebruik je de aanbevolen instellingen voor de VM? (Pagina loopt een beetje achter, maar zou een goede eerste zet moeten zijn)

Jep, en heb met verschillende iso’s VM instellingen en windows versie geprobeerd.


Heb wat gevonden blijkbaar is het probleem al bekend en is er een workaround,
Morgen maar ff testen

https://forum.proxmox.com...een-with-proxmox-6.56053/

[ Voor 19% gewijzigd door itcouldbeanyone op 21-09-2019 18:18 ]

[dcm360]

Ah, een bug die alleen in combinatie met bepaalde hardware voorkomt. Bij wijze van test had ik ook maar even een installatie gestart, en dat werkte zonder problemen (nu alleen nog ergens een key vandaan toveren).

[nYzEkE]

Hallo iedereen,

ik zou ook eens proxmox willen gebruiken.
De hardware die ik hiervoor liggen heb is

#	Category	Product
1	Processors	Intel Pentium G4560 Boxed
1	Moederborden	ASRock H270M-ITX/ac
1	Geheugen intern	Kingston ValueRAM KVR24N17D8/16
1	Voedingen	Mini-box picoPSU 90 + 80W Adapter Power Kit

nu moet er wel nog iets van opslag in natuurlijk. daarvoor zou ik mijn oude HDs enkel maar meer willen gebruiken voor backups een in deze server en een in men htpc. Dan hopelijk deze disks volledig laten uitvallen zodat het stroomverbruik beperkt blijft.

Als opslag voor de server zou ik een intel-660p 1Tb willen aanschaffen. Mijn huidige samsung evo 850 is niet zo geschikt omdat deze niet goed trim wil gebruiken in linux als ik het goed begrijp.

Nu is mijn vraag een beetje welk filesystem moet ik gebruiken op die ssd. Zfs zal misschien wat tegenvallen omdat er slechts 8Gb ram inzit en een upgrade kan er niet komen. Of stellen jullie misschien toch voor om zfs te proberen?

doel van deze server is

• pfsense
• nas, maar niet voor grote hoeveelheden (werkbestanden/administratie)
• Scada systeem voor mijn S7-300 plc in huis (nog onbekend wat ik zal nemen)
• debian servertje om mee te klooien of docker/containers

Hoe die 1ne ssd inrichten is dan nog een andere zaak

Alvast voor mogelijke suggesties of opmerkingen!

[FireDrunk]

Aantal punten:
- 850 EVO TRIM werkt volgens mij al jaren prima, niet druk over maken. Zelfs zonder TRIM werkt zo'n SSD jaren lang prima zolang je hem niet helemaal vol schrijft.
- ZFS op 8GB kan prima, ook niet druk over maken
- 1TB SSD voor een speel server is misschien zelfs wat veel, nou kan ik niet raden wat je er allemaal op gaat zetten, maar mijns inziens is het zonde om er een te grote ssd in te zetten.

Indeling is met ZFS vrij simpel. 1 disk in een single pool, en je kan super makkelijk extra filesystems aanmaken.

[nYzEkE]

FireDrunk schreef op woensdag 25 september 2019 @ 20:50:
Aantal punten:
- 850 EVO TRIM werkt volgens mij al jaren prima, niet druk over maken. Zelfs zonder TRIM werkt zo'n SSD jaren lang prima zolang je hem niet helemaal vol schrijft.

Ik haal dit van https://wiki.debian.org/SSDOptimization waar verwezen wordt naar een drivers/ata/libata-core.c.

/* devices that don't properly handle queued TRIM commands */
{ "Samsung SSD 840*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Samsung SSD 850*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },

Kheb die drive ook een tijdje in een linux bak gehad en de healt ging toch wel "vlug" achteruit 4% in 3 weken vond ik toch snel in mijn inziens

FireDrunk schreef op woensdag 25 september 2019 @ 20:50:
- ZFS op 8GB kan prima, ook niet druk over maken

Ok proberen waard dus

FireDrunk schreef op woensdag 25 september 2019 @ 20:50:
- 1TB SSD voor een speel server is misschien zelfs wat veel, nou kan ik niet raden wat je er allemaal op gaat zetten, maar mijns inziens is het zonde om er een te grote ssd in te zetten.

Misschien heb je wel gelijk en kan ik een 512Gb ssd erin stoppen en moest het nodig zijn een extra ramlat kopen (later dan)

FireDrunk schreef op woensdag 25 september 2019 @ 20:50:
Indeling is met ZFS vrij simpel. 1 disk in een single pool, en je kan super makkelijk extra filesystems aanmaken.

Als het zo simpel is zal ik zeker ZFS proberen thx

[unezra]

A1AD schreef op zondag 8 september 2019 @ 20:32:
[...]
Debian LXC met Samba en bind mounts van je ZFS datasets van pve naar je samba lxc. Werkt hier als een trein.

Edit: sanoid gebruik ik inderdaad ook vanop de host.

Ik heb even gespeeld met OpenMediaVault in een Debian LXC met bind mounts, maar dát werkt helaas niet.
OMV ziet ze niet als device/filesystem, dus kun je ze niet sharen. In OMV kun je geen data sharen die staat op je OS disk en gezien een bindmount als reguliere mount voor het OS word gezien...

Omdat ik toch graag specifiek die data (effectief de data die ik via SMB wil ontsluiten), direct op ZFS wil hebben heb ik een wat smerige workaround bedacht die, ondanks wat onhebbelijkheden, wel goed werkt:

• nfs-kernel-server installeren op de onderliggende host
• zfs datasets aanmaken naar behoefte (optioneel)
• datasets (of directories) exporteren via /etc/exports (en rechten goed zetten, nobody:nogroup 777 als ik het goed heb)
• openmediavault-remotemount plugin installeren vanuit de OMV Extra's
• Via "Remote Mount" de NFS shares opvoeren als filesystem
• Verder business as usual

Twee grote nadelen:

• Je draait een extra service (NFS) die behoorlijk onveilig is en technisch gezien via je netwerk stack loopt.
• Je krijgt foutmeldingen bij het zetten van rechten binnen OMV op de Shared Folders. (Maar het werkt verder prima.)

Kortom, het is een beetje een lelijke oplossing, maar in een hobby omgeving met in essentie maar 2 gebruikers, durf ik dit wel aan. NFS open voor mijn hele netwerk (zou ik nog kunnen limiten tot enkel mijn OMV host), data via OMV ontsluiten. (Of, nog beter, een extra bridge aanmaken met enkel de PVE host en OMV machine d'r aan, puur voor lokaal NFS verkeer.)

---

Sanoid heb ik helaas gisteren wél een onhebbelijkheid van ontdekt: Het maakt snapshots aan die niet werken met Windows Shadow Copy (Previous Versions). Daarover heb ik een update gezet in het ZFS topic: unezra in "Het grote ZFS topic"

Daar ga ik tzt nog op zoek naar een betere oplossing. Nu eerst maar mijn server verder inrichten en data overzetten. (Als ik dat durf. Blijft eng, het moment dat je definitief je data gaat verhuizen naar een nieuwe machine die nog maar een paar dagen oud is.)

[A1AD]

unezra schreef op maandag 30 september 2019 @ 07:12:
[...]


Ik heb even gespeeld met OpenMediaVault in een Debian LXC met bind mounts, maar dát werkt helaas niet.
OMV ziet ze niet als device/filesystem, dus kun je ze niet sharen. In OMV kun je geen data sharen die staat op je OS disk en gezien een bindmount als reguliere mount voor het OS word gezien...

Omdat ik toch graag specifiek die data (effectief de data die ik via SMB wil ontsluiten), direct op ZFS wil hebben heb ik een wat smerige workaround bedacht die, ondanks wat onhebbelijkheden, wel goed werkt:

• nfs-kernel-server installeren op de onderliggende host
• zfs datasets aanmaken naar behoefte (optioneel)
• datasets (of directories) exporteren via /etc/exports (en rechten goed zetten, nobody:nogroup 777 als ik het goed heb)
• openmediavault-remotemount plugin installeren vanuit de OMV Extra's
• Via "Remote Mount" de NFS shares opvoeren als filesystem
• Verder business as usual

Twee grote nadelen:

• Je draait een extra service (NFS) die behoorlijk onveilig is en technisch gezien via je netwerk stack loopt.
• Je krijgt foutmeldingen bij het zetten van rechten binnen OMV op de Shared Folders. (Maar het werkt verder prima.)

Kortom, het is een beetje een lelijke oplossing, maar in een hobby omgeving met in essentie maar 2 gebruikers, durf ik dit wel aan. NFS open voor mijn hele netwerk (zou ik nog kunnen limiten tot enkel mijn OMV host), data via OMV ontsluiten. (Of, nog beter, een extra bridge aanmaken met enkel de PVE host en OMV machine d'r aan, puur voor lokaal NFS verkeer.)

---

toon volledige bericht

Ik volg je even niet hoor. Je spreekt over OMV en ik over puur SAMBA. Je hebt helemaal geen work around nodig als je je ZFS datasets bind mount in je LXC. In je LXC heb je dan SAMBA draaien die de data deelt. SAMBA is zo poepie eenvoudig dat je daar toch geen OMV voor nodig hebt?

Mijn oplossing is toch veel meer KISS?

[unezra]

A1AD schreef op maandag 30 september 2019 @ 16:17:
[...]
Ik volg je even niet hoor. Je spreekt over OMV en ik over puur SAMBA. Je hebt helemaal geen work around nodig als je je ZFS datasets bind mount in je LXC. In je LXC heb je dan SAMBA draaien die de data deelt. SAMBA is zo poepie eenvoudig dat je daar toch geen OMV voor nodig hebt?

Mijn oplossing is toch veel meer KISS?

Klopt. Met puur SAMBA zou het inderdaad wél kunnen.
Dat heb ik nu ook draaien en zou prima overgezet kunnen worden.

Alleen, ik wil juist iets waarmee ik wat meer kan doen dan alleen dat en met fatsoenlijke GUI om de boel te beheren. OMV lijkt daarvoor een prima oplossing. Hét probleem is dat het niet overweg kan met bindmounts en op dit moment de meest zinvolle weg naar mijn data, via NFS lijkt te zijn.

Vandaar. Maar misschien dat als ik hier toch niet gelukkig van word, ik het alsnog een keer om gooi. Da's wel het voordeel van het allemaal direct op ZFS laten landen. Of ik het nu via NFS, via OMV, via een bindmount of desnoods via Samba op mijn hypervisor ontsluit, ik kan er simpel bij en ik heb niet die hele blubs data in een qcow2 image.

[A1AD]

unezra schreef op maandag 30 september 2019 @ 17:29:
[...]


Klopt. Met puur SAMBA zou het inderdaad wél kunnen.
Dat heb ik nu ook draaien en zou prima overgezet kunnen worden.

Alleen, ik wil juist iets waarmee ik wat meer kan doen dan alleen dat en met fatsoenlijke GUI om de boel te beheren. OMV lijkt daarvoor een prima oplossing. Hét probleem is dat het niet overweg kan met bindmounts en op dit moment de meest zinvolle weg naar mijn data, via NFS lijkt te zijn.

Vandaar. Maar misschien dat als ik hier toch niet gelukkig van word, ik het alsnog een keer om gooi. Da's wel het voordeel van het allemaal direct op ZFS laten landen. Of ik het nu via NFS, via OMV, via een bindmount of desnoods via Samba op mijn hypervisor ontsluit, ik kan er simpel bij en ik heb niet die hele blubs data in een qcow2 image.

Ja snap ik wel. OMV in een LXC zou echt ideaal zijn. Ik heb dat in het begin ook getest :-)

Moest je iets vinden laat het dan zeker weten.

[unezra]

A1AD schreef op maandag 30 september 2019 @ 18:03:
[...]
Ja snap ik wel. OMV in een LXC zou echt ideaal zijn. Ik heb dat in het begin ook getest :-)

Moest je iets vinden laat het dan zeker weten.

Ik hou het zeker in de gaten.
Kon ook geen andere fatsoenlijke filesharing distro vinden die het eventueel wél zou kunnen.

Heb nog wel geexperimenteerd met de ZFS plugin, maar die heeft vooral nadelen. Hij werkt niet (goed) en heeft het nodige geheugen nodig, terwijl er onderliggend al ZFS ligt.

Denk dat ik in korte tijd met een stuk of 8 varianten en subvarianten heb gespeeld, zowel met OMV4 als OMV5. Helaas is OMV5 echt nog beta, dus dat durf ik niet aan.

Uiteindelijk besloten te gaan voor de minst lelijke oplossing: NFS naar de onderliggende hypervisor.

Het enige waar ik serieus nog over twijfel, is of ik voor dit doel niet een apart intern netwerkje (Linux Bridge) maak, puur en alleen om NFS te doen tussen host en vm's. De vmbr heb ik zojuist aangemaakt, testen en eventuele migratie laat ik even voor wat het is. Eerst maar eens de server in productie nemen (gaat lang duren, backups maken, scp-en naar de nieuwe host, restoren), machine naar beneden verplaatsen en dan verder kijken.

Domme vraag, maar als ik vanuit een vm naar mijn storage grijp via een virtuele (paravirt) netwerkkaart, ben ik dan gelimiteerd tot de snelheid van die kaart (1GBit), of knalt 'ie gewoon volle bak naar de machine en is de enige beperkende factor mijn onderliggende storage? (Ik heb het nog niet getest. Als dat een beperkende factor is, kan het nog interessant zijn een virtuele 10Ge kaart er in te hangen of de snelheid omhoog te gooien. Als hij d'r verder niets mee doet, laat ik het lekker zo.)

[A1AD]

unezra schreef op maandag 30 september 2019 @ 18:12:
[...]


Ik hou het zeker in de gaten.
Kon ook geen andere fatsoenlijke filesharing distro vinden die het eventueel wél zou kunnen.

Heb nog wel geexperimenteerd met de ZFS plugin, maar die heeft vooral nadelen. Hij werkt niet (goed) en heeft het nodige geheugen nodig, terwijl er onderliggend al ZFS ligt.

Denk dat ik in korte tijd met een stuk of 8 varianten en subvarianten heb gespeeld, zowel met OMV4 als OMV5. Helaas is OMV5 echt nog beta, dus dat durf ik niet aan.

Uiteindelijk besloten te gaan voor de minst lelijke oplossing: NFS naar de onderliggende hypervisor.

Het enige waar ik serieus nog over twijfel, is of ik voor dit doel niet een apart intern netwerkje (Linux Bridge) maak, puur en alleen om NFS te doen tussen host en vm's. De vmbr heb ik zojuist aangemaakt, testen en eventuele migratie laat ik even voor wat het is. Eerst maar eens de server in productie nemen (gaat lang duren, backups maken, scp-en naar de nieuwe host, restoren), machine naar beneden verplaatsen en dan verder kijken.

Domme vraag, maar als ik vanuit een vm naar mijn storage grijp via een virtuele (paravirt) netwerkkaart, ben ik dan gelimiteerd tot de snelheid van die kaart (1GBit), of knalt 'ie gewoon volle bak naar de machine en is de enige beperkende factor mijn onderliggende storage? (Ik heb het nog niet getest. Als dat een beperkende factor is, kan het nog interessant zijn een virtuele 10Ge kaart er in te hangen of de snelheid omhoog te gooien. Als hij d'r verder niets mee doet, laat ik het lekker zo.)

toon volledige bericht

En, ik ben maar luidop aan het nadenken, kan je niet bind mounten naar je "omv fileserver" en daar NFS op draaien en de openmediavault-remotemount wijzen naar localhost (127.0.0.1)? Op deze manier heb je rechtstreeks toegang tot je data via de bind mounts en in theorie snellere IO.

[unezra]

A1AD schreef op maandag 30 september 2019 @ 21:07:
[...]
En, ik ben maar luidop aan het nadenken, kan je niet bind mounten naar je "omv fileserver" en daar NFS op draaien en de openmediavault-remotemount wijzen naar localhost (127.0.0.1)? Op deze manier heb je rechtstreeks toegang tot je data via de bind mounts en in theorie snellere IO.

Heh. Het is vies, maar het klinkt qua theorie best logisch.

Ik heb geen idee of het in de praktijk ook veel sneller gaat zijn dan mijn huidige setup, dat hangt er vooral heel erg vanaf of die PVE machine daadwerkelijk gelimiteerd word tot 1GBit wanneer ik de NFS share benader, of dat die snelheid onbeperkt is.

Nu weet ik dat het wel mogelijk is 'm te limiten.
https://pve.proxmox.com/p...qm.html#qm_network_device
(Zoek op "Rate limit in mbps (megabytes per second) as floating point number.")

Ik vermoed, dat hij géén beperking heeft in zijn snelheid. Ofwel, dat 'ie ook met mijn setup volle bak via de vmbr naar mijn NFS server kan en ik eigenlijk alleen beperkt ben door de snelheid van de netwerkstack aan beide kanten en mijn NFS server en client.

root@hetty:~# ethtool ens18
Settings for ens18:
Supported ports: [ ]
Supported link modes: Not reported
Supported pause frame use: No
Supports auto-negotiation: No
Advertised link modes: Not reported
Advertised pause frame use: No
Advertised auto-negotiation: No
Speed: Unknown!
Duplex: Unknown! (255)
Port: Other
PHYAD: 0
Transceiver: internal
Auto-negotiation: off
Link detected: yes
root@hetty:~#

toon volledige bericht

Oh, voordat mensen het zich afvragen, deze vm heet niet naar een vrouw, maar naar dit:

(Ik gebruik al vrij lang stofzuigerbrands en types als hostnames.)

[ Voor 6% gewijzigd door unezra op 30-09-2019 22:45 ]

[A1AD]

unezra schreef op maandag 30 september 2019 @ 22:44:
[...]


Heh. Het is vies, maar het klinkt qua theorie best logisch.

Ik zou het enkel al doen om geen NFS op de host te moeten installeren, host zo clean mogelijk houden is altijd mijn doel.

unezra schreef op maandag 30 september 2019 @ 22:44:
[...]
Ik vermoed, dat hij géén beperking heeft in zijn snelheid.

Ik ben benieuwd naar je testen.

[unezra]

A1AD schreef op dinsdag 1 oktober 2019 @ 09:53:
[...]
Ik zou het enkel al doen om geen NFS op de host te moeten installeren, host zo clean mogelijk houden is altijd mijn doel.

Eens, maar NFS is nog redelijk weinig ingrijpend en moet zeggen dat ik met mijn migratie van de oude naar de nieuwe setup, er érg blij mee ben. (Helaas bedacht ik me gisterenavond pas halverwege dat ik ook direct mijn backups/vzdumps via nfs naar de nieuwe machine kon schrijven. Heeft me 2, 3 uur vertraging opgeleverd. Gelukkig nog een paar grote, "kritieke", vm's die wel via nfs direct naar de nieuwe machine kunnen, zonder dump op de NAS en dan scp naar de nieuwe.)

[...]
Ik ben benieuwd naar je testen.

Kan niet beloven dat ik het uberhaupt ga testen. Vind ook dit een vrij vieze oplossing.
Ben ook nog niet zeker of ik OMV wel wil houden voor dit doel, of dat ik toch niet gewoon een LXC maak met stock Samba config en klaar. (Die alleen dat doet.)

Stel dat ik toch wat functionaliteit extra wil hebben (streaming, mediaserver, etc) zou ik dat altijd nog op een aparte vm of LXC kunnen doen.

Het werkt, maar ik vind foutmeldingen op een productiedoos toch nooit heel fijn ook al zijn ze verklaarbaar en heeft het geen gevolgen voor mijn data.

Vind het ook wel serieus storend van OMV dat het niet overweg kan met zoiets als een bindmount en eigenlijk niet echt bedoeld lijkt te zijn om in een container te draaien. Kortom, daar ga ik nog even over nadenken. Uitgangspunt blijft om de data zelf op de huidige nieuwe plek te houden, op een dataset. Hooguit verander ik de toegang daartoe.

[A1AD]

unezra schreef op dinsdag 1 oktober 2019 @ 10:15:
[...


...of dat ik toch niet gewoon een LXC maak met stock Samba config en klaar. (Die alleen dat doet.)

Stel dat ik toch wat functionaliteit extra wil hebben (streaming, mediaserver, etc) zou ik dat altijd nog op een aparte vm of LXC kunnen doen.

Dat lijkt me de beste optie ja. Ik heb ook verschillende LXCs per functionaliteit. (Samba, plex, backup, cloud, dns, ...)

Je moet enkel je users en groepen gelijk houden wanneer je dezelfde datasets mount in verschillende containers.

[unezra]

A1AD schreef op dinsdag 1 oktober 2019 @ 11:41:
[...]
Dat lijkt me de beste optie ja. Ik heb ook verschillende LXCs per functionaliteit. (Samba, plex, backup, cloud, dns, ...)

Je moet enkel je users en groepen gelijk houden wanneer je dezelfde datasets mount in verschillende containers.

Jup.

Mocht je nog een suggestie hebben als alternatief voor OMV hou ik me aanbevolen.
(Liefst iets dat een fatsoenlijke webGUI heeft, maar wel goed in een container kan draaien vanwege de bindmount.)

Grote migratie is groot helaas. Ik ben nu mijn oude machines as-is aan het overzetten, zodat mijn oude serverfarm zo snel mogelijk uit kan en ik 1 machine kan recyclen als backupmachine. De rest heb ik nog geen doel voor. (Mogelijk ga ik ze inzetten als vervanging van mijn grote zware DL-series LAB servers.)

Daarna volgen er nog een hele trits herinrichtingsklussen. Nieuw nummerplan, nieuwe functionaliteit, oude functionaliteit uitzetten, etc, etc, etc. Klus van maanden. Eerst die nieuwe server maar iig in de meterkast krijgen.

[zx9r_mario]

In een LXC container kun je via dmesg de kernel messages van de onderliggende hardware zien, dit is soms niet wenselijk.

Als je kernel.dmesg_restrict=1 in /etc/sysctl.conf zet kun je niet-root users (dus ook LXC containers) de toegang tot de kernel messages uitzetten.

https://lxadm.com/Lxc:_restricting_container_view_of_dmesg

[MsG]

Wat is eigenlijk de handigste manier om Docker containers te kunnen draaien? Ik heb een Intel NUC met 128GB SSD en 8GB Ram. Ik heb binnen Proxmox nu 1 virtual machine die HomeAssistant/HassOS draait. Het liefst heb ik niet aldoor voor elke scheet een VM, waarbij je per machine weer de updates en dergelijke bij mag gaan houden. Ik lees wel mensen die Docker rechtstreeks op de Proxmox-debian draaien, maar moet je dat wel willen? Ik wil het liefst zo weinig mogelijk organisatorische en schijfruimtetechnische overhead. En eigenlijk is 99% van de systeempjes die ik wil draaien Linux-gebaseerd. (Ik wil graag OctoPrint draaien bijvoorbeeld, en eventueel PiHole).

[ocf81]

De Proxmox doctrine zegt een VM met daarin je Docker containers. Op zich is er natuurlijk enige overhead als je een VM draait met je Docker comtainers. Anderzijds kan je bij een upgrade wel heel makkelijk de image verplaatsen en dan in één keer door. Met een cluster van 3 bakken kies ik voor de doctrineoplossing, maar met een NUC met beperkte geheugencapaciteit die niet in een cluster hangt zou ik denk ik voor een directe installatie gaan. Als je bak niet aan het internet hangt als server zie ik er weinig problemen mee om gewoon Docker op de Proxmox bak te zetten en daar direct je containers mee te draaien vanuit security oogpunt.

[ Voor 28% gewijzigd door ocf81 op 23-10-2019 21:25 ]

[RobertMe]

MsG schreef op woensdag 23 oktober 2019 @ 20:44:
Wat is eigenlijk de handigste manier om Docker containers te kunnen draaien? Ik heb een Intel NUC met 128GB SSD en 8GB Ram. Ik heb binnen Proxmox nu 1 virtual machine die HomeAssistant/HassOS draait. Het liefst heb ik niet aldoor voor elke scheet een VM, waarbij je per machine weer de updates en dergelijke bij mag gaan houden. Ik lees wel mensen die Docker rechtstreeks op de Proxmox-debian draaien, maar moet je dat wel willen? Ik wil het liefst zo weinig mogelijk organisatorische en schijfruimtetechnische overhead. En eigenlijk is 99% van de systeempjes die ik wil draaien Linux-gebaseerd. (Ik wil graag OctoPrint draaien bijvoorbeeld, en eventueel PiHole).

Misschien een beetje vloeken in de kerk, en ik heb er nog minder ervaring mee dan Proxmox en zelfs daarvan heb ik alleen een keer de installer doorlopen en verder niks meer mee gedaan. Maar als het alleen voor het draaien van Docker is, is het dan wellicht niet handiger om een daarvoor bestemd OS zoals CoreOS of RancherOS in te zetten? Die zijn echt gericht op "alles in Docker" en verder niks (dus geen VMs etc).

Of dan bv juist een CoreOS of RancherOS in een LXC container of VM op Proxmox gooien en daar alle containers in draaien i.p.v. meerdere geisoleerde containers / VMs voor verschillende toepassingen met vervolgens daarin weer Docker.

[unezra]

ocf81 schreef op woensdag 23 oktober 2019 @ 21:23:
De Proxmox doctrine zegt een VM met daarin je Docker containers. Op zich is er natuurlijk enige overhead als je een VM draait met je Docker comtainers. Anderzijds kan je bij een upgrade wel heel makkelijk de image verplaatsen en dan in één keer door. Met een cluster van 3 bakken kies ik voor de doctrineoplossing, maar met een NUC met beperkte geheugencapaciteit die niet in een cluster hangt zou ik denk ik voor een directe installatie gaan. Als je bak niet aan het internet hangt als server zie ik er weinig problemen mee om gewoon Docker op de Proxmox bak te zetten en daar direct je containers mee te draaien vanuit security oogpunt.

Security is 1 ding, maar ik denk dat het goed is je hypervisor zo schoon mogelijk te houden. Dus zo min mogelijk tools er op en zeker geen dingen als Docker.

Zelf ga ik nooit veel verder dan vim, een Zabbix agent en wat andere basiszaken.

Dus ook in dit geval zou ik denk ik kiezen voor een vm met daarin Docker.

[Kaspers]

Docker op een Ubuntu LXC geen optie voor je? Weinig overhead, flexibel, maar je moet m uiteraard wel privileged draaien.

[ocf81]

In de categorie gekke plannen die ik toch wil onderzoeken:
Ik heb een storage server die ik redundant wil maken. Helaas blijkt FreeNAS ziet altijd even jofel te draaien en ook niet zo geschikt te zijn voor multi-chassis MPIO. Ik wil daarom toch kijken of overgaan op Ceph voor mij een optie is. In één keer over is te duur, de hardware daarvoor kost een godsvermogen als je het goed op wil zetten. Vandaar het volgende plan: Met proxmox een aantal VMs maken waarbij je de VM een middels passthrough fysieke schijf toewijst voor de bootdrive i.p.v. een virtuele disk en een fysieke schijf als OSD drive voor de data. Op deze manier zou ik over een langere tijd langzaam mijn Ceph nodes willen devirtualiseren zonder verlies van data door de schijven uit de NAS te trekken en in fysieke nodes te stoppen. Monitors etc wil ik in eerste instantie ook gevirtualiseerd draaien en later devirtualiseren. (Een paar per jaar, in plaats van gelijk de hardware voor 7 nodes en 3 monitors aan te schaffen)

Ik snap natuurlijk dat, tot het storage netwerk op eigen pootjes staat door genoeg werkende nodes over te houden, het overlijden van de storage server de nekslag kan betekenen voor deze setup. Helaas is een enkele FreeNAS bak voor mij gewoon niet stabiel genoeg.

De specs van de storage server:
Dual E5 2630 v3 (8c/16t @2.4 GHz)
64GiB RAM
9x 4TB schijf
2x H310/9211-8i in IT mode
Intel X710-DA4 nic
500GiB SSD voor os storage host

voor de os disks van de nodes zou ik dan een paar goedkope SSDs op de kop tikken om bij te prikken.

Ik ben wel benieuwd wat men er over denkt hier.

[ Voor 11% gewijzigd door ocf81 op 24-10-2019 23:56 ]