Bester Weg für Fileserver (samba)

Aber besser geeignet als die hier ebenfalls diskutierte Variante den Fileserver (NFS/Samba) direkt auf dem Host zu betreiben. Und unpriviligiert ist auf jeden Fall schon mal besser isoliert als priviligiert, da das System dort ja by Design keine root-Rechte haben kann.
Das ist richtig. In meinen Augen aber zu kurz gesprungen.
Dass man dann einen eigenen Controller braucht, siehe https://www.truenas.com/community/r...guide-to-not-completely-losing-your-data.212/ Je nach Hardware (mini-pc) oder Budget ist das halt nicht vorhanden oder finanzierbar.
Und envtl. will man ja nicht einen ganzen Controller samt Platten durchreichen, sondern flexibler sein. Das war für mich z.B. ein Grund, warum ich von der TrueNAS VM zu lxc gewechslelt bin. Einer der Vorteile von Virtualisierung ist ja gerade, dass man damit dann Storage in kleine Portionen schneiden kann, das finde ich persönlich schon praktisch. Die bessere Performance plus geringere RAM-/CPU-Bedarf des Containers ist dann noch die Kirsche auf der Torte.
Keiner zwingt dich irgendwelche HW durchzureichen, außer du legst tatsächlich Wert auf die letzen 10 Performance% wert.
OMV soll man ja laut den Entwicklern auch nicht im Container betreiben. Und ein stinknormales Debian im Container updaten ist ja nun ziemlich schmerzarm. In beiden Fällen sollte mit eingerichten automatischen Snapshots und/oder Backups (stündlich oder kürzer je nach bedarf) sich ein schiefgegangenes Update ja auch leicht wieder einfangen lassen.
Kluge Entscheidung von OMV, davon abzuraten. Warum soll ich mich manuell mit snapshots manuell rumschlage, wenn ich innerhalb von PVE per Click die letzte Sicherung zurückspielen kann.
Oder habe ich einen Menüpunkt "Restore last snapshot" in der GUI übersehen?
Wenn der Hauptgrund für OMV oder TrueNAS das Webinterface ist, kann man auch genausogut in der VM oder dem Container sich Webmin oder Cockpit installieren, auf den Host würde ich das natürlich nicht empfehlen.
Warum sollte man die existierenden, angepassten GUIs irgendwelcher spezialisierten Projekte links liegen lassen um dann zwangsläufig unzulänglichere Standardtools wie Cockpit oder Webmin zu verwenden.
Ketzerisch gefragt: Warum benutzt du PVE und kein Debian mit QEMU und Konsorten mit den genannten Tools?
 
Ich wollte mehr Kontrolle. Zb. über die Namen bzw. Pfade der Einhängepunkte. Ist schon etwas her und das ist alles was mir gerade einfällt aber es war nicht nur das.
 
Last edited:
  • Like
Reactions: Johannes S
Ich wollte mehr Kontrolle. Zb. über die Namen bzw. Pfade der Einhängepunkte. Ist schon etwas her und das ist alles was mir gerade einfällt aber es war nicht nur das.
So unterschiedlich kann es laufen. Ich wechselte irgendwann von Debian/samba/webmin zu OMV, weil ich die inkonsistente Administrierung leid war.
Heute denke ich wiederum manchmal nach, da OMV auch Nickligkeiten im Gepäck hat, zurück zu gehen.
 
Keiner zwingt dich irgendwelche HW durchzureichen, außer du legst tatsächlich Wert auf die letzen 10 Performance% wert.
OMV sollte auf einer virtuellen Festplatte keine Probleme machen sofern man ext4 benutzt. Ich hatte es damals auch so verwendet bevor ich auf mein debian CT mit manueller Verwaltung umgestiegen bin.

Naja, ich finde die Argumentation aus den TrueNAS Forum schon nachvollziehbar, also dass ein NAS-System ohne direkten Zugriff auf die Storage-Hardeware schlicht nicht die Konsistenz und Sicherheit (in Sinne von Zuverlässigkeit) der Daten garantieren kann (das Software-RAID der NAS übernimmt ja die Funktion des HW-RAID) , die Virtualisierung abstrahiert das ja weg. Dazu wird auch auf https://www.truenas.com/community/t...nas-in-production-as-a-virtual-machine.12484/ verwiesen.
Nun bezieht sich das in erster Linie auf TrueNAS und zfs, aber am Ende des Tages macht OMV ja auch nicht viel anderes, nur halt mit mdadm als HW-RAID Ersatz. Daher lässt sich diese Argumentation schon so übertragen in meinen Augen. Wenn man das weiß, bedenkt und nach Abwägung trotzdem macht: Meinetwegen ( siehe auch https://www.truenas.com/community/t...ative-for-those-seeking-virtualization.26095/ ), aber das ist dann nicht das, was ich Anfängern oder in einen Firmenkontext empfehlen würde.

Kluge Entscheidung von OMV, davon abzuraten. Warum soll ich mich manuell mit snapshots manuell rumschlage, wenn ich innerhalb von PVE per Click die letzte Sicherung zurückspielen kann.

Man kann in PVE auch immer auf den letzten Snapshot eines lxcs oder einer vm zurückgehen, auch in der GUI. Wenn man (per CLI) sich aber https://github.com/Corsinvest/cv4pve-autosnap einrichtet, werden diese VMSnapshots automatisch nach Zeitplan erzeugt.
Die OMV-Empfehlung hat damit aber nichts zu tun, sie raten davon ab, weil auch aus einer lxc eben kein exklusiver direkter Zugriff auf die Hardware ohne Klemmzüge möglich ist (bei einer VM auch nicht, aber da kann man den Storage-Controller durchreichen und hat sonst halt die virtualisierter Hardware):
ryeaaron said:
Is OMV supported via Linux LXC/LXD Containers?
I spent a few hours trying it in proxmox lxc. It will install but too many issues because there is no root device. I started looking at the changes to fix that and there are just too many core changes. So, no.
https://forum.openmediavault.org/in...-lxc-lxd-containers/&postID=232071#post232071
ryeaaron said:
I think OMV in docker is going to be tougher than lxc/lxd since lxc/lxd has more of stack like systemd running. For docker, I envisioned a stripped down OMV that had the physical devices. filesystems, power management, monitoring, updates, etc removed and shared folders were using the equivalent of sharerootfs to be created. The folders that sharerootfs would consume would be folders passed to the container. OMV would mainly be configuring services. But then I thought it is no longer a NAS but more like webmin. So, what's the point?
https://forum.openmediavault.org/in...-lxc-lxd-containers/&postID=232081#post232081

Den letzten Satz finde ich bezeichnend, weil wir damit wieder beim Ausgangspunkt wären, wenn es einen nur um ein Webinterface für samba-Freigaben geht, wozu dann omv?
Das die Höllenskripte ("community helper scripts") das trotzdem machen, macht es nicht besser, siehe hier: https://forum.openmediavault.org/in...ccess-additional-drives-via-proxmox-with-lxc/

Sprich: Mit Snapshots hat das nichts zu tun (die gehen ja mit Containern und vms), sondern dass die OMV-Entwickler und Community diesen Edgecase (OMV in lxc) und damit verbunden Hacks nicht supporten wollen.


Oder habe ich einen Menüpunkt "Restore last snapshot" in der GUI übersehen?

In der ProxmoxVE-GUI kann man ohne Probleme auf ältere Snapshots der Container und VMs zurückspringen, alle nach dessen Erstellungszeitpunkt gemachten Änderungen sind dann halt weg.
 
Naja, ich finde die Argumentation aus den TrueNAS Forum schon nachvollziehbar, also dass ein NAS-System ohne direkten Zugriff auf die Storage-Hardeware schlicht nicht die Konsistenz und Sicherheit (in Sinne von Zuverlässigkeit) der Daten garantieren kann (das Software-RAID der NAS übernimmt ja die Funktion des HW-RAID) , die Virtualisierung abstrahiert das ja weg. Dazu wird auch auf https://www.truenas.com/community/t...nas-in-production-as-a-virtual-machine.12484/ verwiesen.
Nun bezieht sich das in erster Linie auf TrueNAS und zfs, aber am Ende des Tages macht OMV ja auch nicht viel anderes, nur halt mit mdadm als HW-RAID Ersatz. Daher lässt sich diese Argumentation schon so übertragen in meinen Augen. Wenn man das weiß, bedenkt und nach Abwägung trotzdem macht: Meinetwegen ( siehe auch https://www.truenas.com/community/t...ative-for-those-seeking-virtualization.26095/ ), aber das ist dann nicht das, was ich Anfängern oder in einen Firmenkontext empfehlen würde.
Hmm, Das kann ich nicht so richtig nachvollziehen.
Für Datensicherheit muss in meinen Augen der Virtualisierungshost sorgen.
VMs müssen sich überhaupt keinen Gedanken machen, denn ich muss virtuellen Disks soweit vertrauen, wie ich dem Host vertraue. Müssen Container selbstverständlich auch, aber mir gefällt die Verquickung mit dem darunterliegenden Host nicht. Könnte man virt. Disks (in Containern genauso) nicht trauen, könnte man Virtualisierung generell in die Tonne treten.
Man kann in PVE auch immer auf den letzten Snapshot eines lxcs oder einer vm zurückgehen, auch in der GUI. Wenn man (per CLI) sich aber https://github.com/Corsinvest/cv4pve-autosnap einrichtet, werden diese VMSnapshots automatisch nach Zeitplan erzeugt.
Ich bitte um einen Tipp, wo ich das in der PVE-GUI finde um die Snapshots ohne nennenswerte Downtime zu aktivieren.
Die OMV-Empfehlung hat damit aber nichts zu tun, sie raten davon ab, weil auch aus einer lxc eben kein exklusiver direkter Zugriff auf die Hardware ohne Klemmzüge möglich ist (bei einer VM auch nicht, aber da kann man den Storage-Controller durchreichen und hat sonst halt die virtualisierter Hardware):
Das stimmt einfach nicht. OMV merkt gar nicht, bzw. will es gar nicht wissen, ob es eine virtuelle Disk oder echte HW vorgesetzt bekommt. Nie im Leben reiche ich HW an VMs durch. Gilt sowohl für GPU als auch Storagecontroller. Bei entsprechendem Performancebedarf ist Baremetal gefragt. Ausgenommen sind dusselige USB-Dongles. Da bin ich sehr froh, dass sie reibungslos durchgereicht werden können. Das sogar von Server A auf Server B, sofern man den Dongle umsteckt.

P.S.:
Selbstverständlich kannst du falls nötig in einer VM ZFS mit zwei Disks simulieren. Aber wozu außer Testzwecken?
 
Last edited: