Hängt davon ab was du genau meinst. Das meiste wie Overhead und Passthrough etc bezog sich schon auf VMs. Datasets per Bind-Mounting in Gäste bringen geht aber in der Tat nur bei Containern.@Dunuin - wir reden aber hier nur von Containern, oder?
Hängt davon ab was du genau meinst. Das meiste wie Overhead und Passthrough etc bezog sich schon auf VMs. Datasets per Bind-Mounting in Gäste bringen geht aber in der Tat nur bei Containern.@Dunuin - wir reden aber hier nur von Containern, oder?
Klingt soweit ok.@Dunuin
Wow, vielen lieben Dank für die ausführliche und aufschlussreiche Beschreibung der Verhältnisse.
Ich hab ein bisschen Bachschmerzen an Privilegien oder User-mappings "rumzuspielen". Das trau ich mir nicht zu. ich möchte es schon so gut wie eben möglich isoliert lassen.
Ich habe nun alle Komponenten für den neuen Server da und hab heute schonmal proxmox installiert.
Zuvor hab ich folgendes gemacht:
Das Mainboard hat 2 Sata-Anschlüsse, die wohl auch 6Gb/s schnell sind. Da nur ein Stromstecker für Sata vorhanden war (eilt. für das DVD-Laufwerk), habe ich aus einem alten PC einen zusätzlichen Sata-Stromanschluss angelötet und das DVD-Laufwerk ausgesteckt.
An die beiden SATA-Anschlüsse hängen nun meine 2 Intel SSD. Die hab ich nun im Gehäuse befestigt wo Platz war.
Zudem habe ich einen geflashten Dell H310 (IT-Mode ohne BIOS), an dem nun meine HDD-Backplate hängt und ich dort meine Daten-Platten reinstecken kann.
Da ich nun zuvor noch nicht so wirklich mit ZFS zu tun hatte, habe ich mal "die Standardprozedur" durchgeführt. Also keine Advanced Einstellungen, sondern lediglich die zwei Intel SSD zu einem Mirror-ZFS gemacht.
Ich hab da jetzt quasi nur eine Partition erstellt, also hab ich im Proxmox jetzt einmal ein local(pve) und ein lokal-zfs(pve).
Dort installier ich also nun auch meine VMs/CTs.
War das ok so, oder gibts Einwände? Will jetzt von Beginn an alles "richtig" machen...
Mit dem HBA bin ich also jetzt quasi "frei". Ich kann entweder ein PCI-Passthrough machen oder eben die Platten von Proxmox managen lassen.
Ich tendiere zum PCI Passthrough nach deinen Ausführungen der Pro und Kontras.
Ich würde da eine TrueNAS VM mit PCI Passthrough HBA echt nur als reines NAS benutzen. Nicht vergessen das TrueNAS Core ein Unix und kein Linux ist. VMs innerhalb einer VM möchte man eigentlich nicht nutzen, also müsstest du im TrueNAS die Nextcloud in einem Jail (also Unix Container) laufen lassen. Sofern du da nicht mit Unix fit bist würde ich lieber bei Linux bleiben. Außerdem verwaltet es sich viel leichter (Monitoring, Backups, Rechte, Netzwerk und so) wenn alles über Proxmox selbst läuft und du nicht Gäste in Gästen betreibst. Da würde ich Nextcloud dann schon als eigener LXC oder VM auf PVE laufen lassen und dann das Nextcloud Datenverzeichnis per NFS oder SMB in den LXC/VM bringen.OMV beherrscht kein ZFS, weshalb ich dann vielleicht mal trueNAS ausprobiere. Dort würde ich dann ggf. auch direkt die Nextcloud installieren, dann muss ich dort nichts per SMB o.ä. einbinden.
Da halte ich nicht viel von. Deine Backups sollten schon so liegen, dass man da noch drankommt, selbst wenn man die kompletten Systemplatten (also deine beiden 400GB SSD) formatieren muss oder wenn sich keine VM mehr starten lässt. Sobald dir deine beiden SSDs wegsterben laufen auch keine VMs mehr und laufen keine VMs kommst du auch nicht mehr an die SMB Shares deiner TrueNAS VM.Da die Intel SSD's nur 400GB groß sind, würde ich dann für die "lokalen" Backups der VMs/CTs dann doch von der NAS_VM ein SMB-Share mounten, damit Proxmox darin die Backups ablegen kann. Das geschieht nur einmal wöchentlich und sollte kein Nachteil sein.
Ehm... Ach ja.... ^^ Das ergibt Sinn.Da halte ich nicht viel von. Deine Backups sollten schon so liegen, dass man da noch drankommt, selbst wenn man die kompletten Systemplatten (also deine beiden 400GB SSD) formatieren muss oder wenn sich keine VM mehr starten lässt. Sobald dir deine beiden SSDs wegsterben laufen auch keine VMs mehr und laufen keine VMs kommst du auch nicht mehr an die SMB Shares deiner TrueNAS VM.
Da würde ich dann mal PBS auf den NUC drauf installieren.Ich werde mal weiter "rumspielen" und schauen, was für mich denn nun das best practice ist. Danke nochmals
ZFS speichert asynchrone Writes standardmäßig nur alle 5 Sekunden. Die werden also im RAM gesammelt und dann alle 5 Sekunden auf die Laufwerke geschrieben. Deshalb verlierst du auch immer mindestens die letzten 5 Sekunden an Daten beim Stromausfall. Das die HDDs da also nur alle 5 Sekunden kurz Aktivität zeigen wäre nicht weiter verwunderlich.Beim Lesen oder Schreiben sind die Platten aber auch nicht immer aktiv (HDD-LED am Server). Die gehen immer so für eine Sekunde an und dann ist für 3-5 Sekunden nichts.... Ist das ein zu erwartendes Testergebnis? Kommt mir sehr langsam vor.
2. LXC, Debian 10, privilegiert. Hier kann ich zwar per Bind-Mount toll auf das Datasets zugreifen. Dafür gibt es auf dem Gastsystem selber an allen Ecken und Enden Probleme mit rechten. Weil dann z.B. "Besitzer" und "Gruppe" nicht root ist sondern 100000 Was ja der Root vom Host ist.
Hier habe ich am Wochenende nichts gefunden wie man das einfach und schnell regeln kann. Und wenn ich ein "chown" macht und wieder root setze ... ja das ist ja mal am Ziel vorbei würde ich sagen.
Oh man... ich Depp.... war natürlich doch noch ein 100 MBit Port dazwischen.....SMB Übertragungsgeschwindigkeiten von/zu meinem Mac:
Lesen: 22MB/s
Schreiben 11MB/s
Alles per Gbit LAN angeschlossen... wirkt wieder sehr langsam auf mich.
Da hast du das Problem. Wenn du den LXC als unprivilegierten LXC erstellt hast und dann nachträglich auf privilegiert umstellst, dann ändert PVE ja nicht die bereits bestehenden Rechte. Das was vorher als "UID 0" im unprivilegierten LXC angezeigt war gehört dann "UID 100000" weil es dann als privilegierter LXC eben kein Remapping mehr gibt. Da sieht der Gast dann also die echten Dateirechte, wie sie auch auf dem Host existieren und da gehören die Ordner ja immer noch dem alten gemappten root User. Nach einem Wechsel von unprivilegiert zu privilegiert müsstest du dann schon von wirklich allen Dateien und Ordnern die Besitzer wechseln. Also chown Befehl nutzen und alles was UID 100000 bis 165535 gehört auf UID 0 bis 65535 abändern, damit das wieder so ist wie es als unprivilegiter LXC war. Oder du erstellst den LXC gleich neu und direkt als privilegierter LXC, dann passt das auch mit den Dateirechten von Anfang an.Ich habe es mehrmals ausprobiert, weil ich mich gewundert habe warum es im Gast zu problemen kommt.
Wenn ich den Haken bei "privilegiert" rausnehme habe ich die komischen 100000 nummern bei Besitzer und Gruppe anstelle von z.B. "root:root".
;-) Ja sowas passiert immer wieder.Oh man... ich Depp.... war natürlich doch noch ein 100 MBit Port dazwischen.....
Also nochmal gemessen und siehe da.... 102 MByte/s schreiben und 101MByte/s lesen. ^^
Leider nicht. Weil ich den Storage nicht nur für OMV nutzen möchte. Daher suche ich nach einer Lösung wo der Host das ZFS erstellt und die Gäste nur die Daten darauf ablegen. Jeder Gast soll aber seinen eigenen "sicheren Bereich" haben und nicht auf die Daten des jeweils anderen Gast zugreifen.@Aquator
Was du aber noch nicht versucht hast ist, die einzelnen Festplatten an die VM zu reichen. Also per qm set. Wäre, wie @Dunuin ja bereits erklärt hat auch eine zumindest vertretbare Option.
Und in der VM kannst du dann dein ZFS erstellen. OMV kann das mit OMV-Extras aus. Wusste ich bis gestern nicht ^^
Oh dann hatte ich mich falsch ausgedrückt. Natürlich habe ich NICHT nachträglich von privilegiert auf unprivilegiert gestellt, oder anders herum. Immer ein "frischer" LXC.Da hast du das Problem. Wenn du den LXC als unprivilegierten LXC erstellt hast und dann nachträglich auf privilegiert umstellst, dann ändert PVE ja nicht die bereits bestehenden Rechte. Das was vorher als "UID 0" im unprivilegierten LXC angezeigt war gehört dann "UID 100000" weil es dann als privilegierter LXC eben kein Remapping mehr gibt. Da sieht der Gast dann also die echten Dateirechte, wie sie auch auf dem Host existieren und da gehören die Ordner ja immer noch dem alten gemappten root User. Nach einem Wechsel von unprivilegiert zu privilegiert müsstest du dann schon von wirklich allen Dateien und Ordnern die Besitzer wechseln. Also chown Befehl nutzen und alles was UID 100000 bis 165535 gehört auf UID 0 bis 65535 abändern, damit das wieder so ist wie es als unprivilegiter LXC war. Oder du erstellst den LXC gleich neu und direkt als privilegierter LXC, dann passt das auch mit den Dateirechten von Anfang an.
Dann hast du aber trotzdem nicht den Besitzer des Ordners geändert? Wenn du im privilegierten LXC siehst dass der Ordner UID 100000 gehört und nicht dann UID 0, dann solltest du mal den Ordner von UID 100000 auf UID 0 abändern. Oder am Besten garnicht erst mit root arbeiten und einen eigenen OMV User erstellen und den dann zum Eigentümer des Bind-Mounts-Ordners machen.Oh dann hatte ich mich falsch ausgedrückt. Natürlich habe ich NICHT nachträglich von privilegiert auf unprivilegiert gestellt, oder anders herum. Immer ein "frischer" LXC.
UID 100000 sollte man wie gesagt eigentlich nur sehen, wenn man in einem privilegierten LXC ist und dann versucht auf einen durchgereichten Ordner zuzugreifen der vorher von root in einem unprivilegierten LXC besessen wurde.In keiner der Fälle hatte ich diesmal was von 100000 bei UID und GID stehen. Ich frage mich was das war und wie das kam.
Hängt vom Gast ab. Bei PVE6 ging es noch gut ohne Nesting, aber bei PVE7 will ein Debian 11 im LXC z.B. immer ein Nesting haben, weil sonst das mit Systemd nicht mehr funktioniert. Daher ist nun seit PVE7 auch per default immer Nesting deaktiviert, was bei PVE6 noch nicht war.Wenn ich das richtig gelesen habe braucht man Nesting doch nur wenn ich in diesem LXC ebenfalls Virutalisierung betreiben möchte oder?
Wieso genau muss man das aktivieren? Weil wenn ich den Haken bei "Unpriviliged Container" raus nehme ist "Nesting" ausgegraut. Und wenn ich dann z.B. in die conf des Containers schaue steht da auch nichts von "feature: nesting 1" oder so.Für den OMV LXC nimmt man einfach den normalen Debian 10 LXC und lässt dort das OMV Install Script drüberlaufen. Schon hat man ein OMV LXC. Ist jetzt mit PVE7 nur etwas nervig, weil man mit Debian 11 ja nun immer das Nesting-Feature aktivieren sollte und man Nesting wegen der Sicherheit eigentlich nicht nutzen möchte, wenn der LXC privilegiert ist.
Also hab ich die Nextcloud (bzw. Ubuntu Server VM) nochmal neu aufgesetzt und vor der Installation von Nextcloud den Share von OMV gemountet und wollte dann bei der Installation von Nextcloud diesen gemounteten Ordner als Datenverzeichnis hinterlegen.
Dann hat Nextcloud gemeckert, dass es scheinbar keine Schreibrechte hat...
Also häng ich grade auch bei einem Rechteproblem. Muss mal schauen woran es liegt.
sudo apt-get install cifs-utils
sudo mkdir /mnt/nextcloud
sudo nano ~/.smbcredentials
username=msusername
password=mspassword
chmod 600 ~/.smbcredentials
sudo nano /etc/fstab
//<IP-von-OMV>/<Share-Name> /mnt/nextcloud cifs credentials=/home/<user>/.smbcredentials,gid=33,uid=33,forceuid,forcegid,dir_mode=0770,file_mode=0770 0 0
sudo mount -a