NFS Share verhält sich seltsam

[Varustartes]

Hallo zusammen,

ich habe mir neuerdings eine Docker-VM aufgebaut, dort möchte ich einen NFS-Share einbinden.
Dabei hängen USB-Platten am Host, und die NFS-Shares werden über einen LXC bereitgestellt.

Aktuell ist es folgendermaßen gelöst:

Im PVE: /etc/pve/lxc/400.conf

arch: amd64
cores: 4
features: mount=nfs,nesting=1
hostname: NFS-Server
memory: 512
mp0: /mnt/pve/SSD3/Varustartes/Complete ISO/,mp=/mnt/nfs_share
mp1: /mnt/pve/SSD3/,mp=/mnt/storage
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.0.1,hwaddr=7A:F3:96:6E:B6:43,ip=192.>
onboot: 1
ostype: debian
rootfs: local-lvm:vm-400-disk-0,size=8G
swap: 512

In der 400-LXC: /etc/exports

# M9201
/mnt/nfs_share 192.168.0.29/24(rw,sync,no_subtree_check)

# Docker
/mnt/storage 192.168.0.65/24(rw,sync,no_subtree_check)

Bei Änderungen immer "exportfs -a" durchgeführt.
Der Inhalt der MPs ist hier auch noch richtig.


Dann in der Docker-VM mit IP 192.168.0.65:
sudo mount -t nfs -o nolock 192.168.0.56:/mnt/storage /home/varustartes/Storage
oder auch per fstab:
192.168.0.56:/mnt/storage /home/varustartes/Storage nfs nofail,nolock,noatime 0 0

Führt dann dazu dass in der Docker-VM der Inhalt vom /mnt/nfs_share auftaucht, der nicht für die IP-Adresse der Docker-VM freigegeben ist, außerdem sind die Einträge in der exports-Datei doch völlig unterschiedlich benannt...

Sonst haben die NFS-Shares immer so funktioniert. Was bitte übersehe ich?
Das Verhalten trat erst auf nachdem ich einige NFS-shares konsolidiert habe, die vorher in der VM eingebunden waren.
Habe aber ganz normal einfach Einträge entfernt/unmounted, und jeweils neu gestartet, vom Ziel zur Quelle, so wie man es eigentlich auch machen sollte.

Wenn ich den ersten EIntrag in der Exports-Datei auskommentiere, dann wird der richtige NFS-Share gefunden. Aber das ist ja nur ein Workaround.

Entweder habe ich hier einen Bug, oder ich verstehe etwas fundamental falsch...

PS: Wenn ich die USB-Platten an der VM durchreichen würde, dann stünden sie am Host vermutlich nicht mehr zur Verfügung, richtig?
Will vermeiden zu viele Services auf die VM ziehen zu müssen.

 

[Der Harry]

PS: Wenn ich die USB-Platten an der VM durchreichen würde, dann stünden sie am Host vermutlich nicht mehr zur Verfügung, richtig?
Will vermeiden zu viele Services auf die VM ziehen zu müssen.

Meine Frage bei sowas - und die habe ich fast immer.

Warum kein Fileserver, wenn du einen Fileserver brauchst? Du hast doch eine Virtualisierungsumgebung - virtualisier den auch.

Das könnte man z.B. machen mit

- Einer VM mit virtueller Platte.
- Einer VM mit einer physikalischen Platte.
- Einer VM mit ggf. einer USB Platte (ist halt immer schlecht, weil USB und USB hat halt immer USB Probleme im Dauerbetrieb).

Auf die VM instierst du entweder ein Linux oder gleich sowas wie Truenas.

Dann hast du Samba, NFS, SFTP...

In die LXCs / anderen VMs mountest du einfach ein Netzwerk Storage.

Der Vorteil ist :

- du kannst entweder direkt daraus ein NAS machen (wenn es mal wachsen muss)
- oder wenn du Truenas nimmst und dem 1-2 physikalische Platten gibst, dann kannst du daraus auch einen eigenen Rechner machen (Falls nötig).

Stabiler ist es in jedem Fall, weil du niemals mount point harakiri machen musst (wie bei dem LXC mounts). Du hast immer einen Server (der zur Not Locks) machen kann - und nicht 10 VMs die "irgendwie" auf einem Storagepoint schreiben.

 

[Varustartes]

Danke für deine Antwort.

Das sind tatsächlich alles Überlegungen, die ich derzeit anstelle. Ist bisher halt alles aus Erfahrungsmangel erwachsen.
Überlege derzeit auch ein neues NAS zusammenzustellen, allerdings soll der aktuelle PVE-Server bestehen bleiben, und für die derzeit angeschlossenen Platten würde vermutlich deine vorgeschlagene Lösung am meisten Sinn machen (Virtualisierung eines Fileservers mit USB-Platten, gibt leider keinen anderen Anschluss).

Vorteil wäre auch dass ich die entsprechenden Lösungen kennenlernen kann, bin mit TrueNAS Scale am liebäugeln.

Deinen letzten Satz verstehe ich aber nicht. Wenn ich einen Fileserver bereitstelle, und ich eine separate VM (z.B. für einen Docker-Stack) habe, dann muss ich doch in der Ziel-VM irgendwie (NFS/SMB/whatever) einen Mount durchführen, damit mit der Storagepoint dort zur Verfügung steht...?


Für mich ist aber immernoch die Frage offen ob ich hier auf einen PVE/NFS-Bug gestoßen bin.
Das Verhalten ist für mich absolut widersprüchlich.

 

[Der Harry]

Für mich ist aber immernoch die Frage offen ob ich hier auf einen PVE/NFS-Bug gestoßen bin.
Das Verhalten ist für mich absolut widersprüchlich.

Nein das ist kein Bug. Deadlocks / "Probleme" kann man mit jedem Shared Storage in sekunden erzeugen. Es gilt eine Architektur aufzubauen / Services so zu gestalten, dass es nicht passiert.

Für dein Kennenlernen: Schau mal unter Storage Types die an, die Proxmox out of the box kann: https://pve.proxmox.com/wiki/Storage

Ich verspreche dir - wenn du zu jedem Filesystem da - 3 eigene Sätze schreiben kannst, sind alle deine Probleme weg.

 

[cheiss]

Hi,

zuerst mal:

ich habe mir neuerdings eine Docker-VM aufgebaut, dort möchte ich einen NFS-Share einbinden.

Im PVE: /etc/pve/lxc/400.conf

VM != LXC, das sind zwei komplett verschiedene Technologien und haben nichts miteinander zu tun.
Und Docker in LXC wird von uns explizit nicht empfohlen - da es früher oder später zu Problemen führen wird.

# M9201
/mnt/nfs_share 192.168.0.29/24(rw,sync,no_subtree_check)

# Docker
/mnt/storage 192.168.0.65/24(rw,sync,no_subtree_check)

Da beides das selbe Subnetz ist, sind beide Shares für alle Clients im 192.168.0.x zugreifbar.

PS: Wenn ich die USB-Platten an der VM durchreichen würde, dann stünden sie am Host vermutlich nicht mehr zur Verfügung, richtig?

Wenn du direkt durchreichst - ja. Aber macht natürlich auch einen Unterschied ob tatsächlich VM oder LXC.

Allgemein - wenn du LXC verwendest und die Disken sowieso am Host angeschlossen sind, würde ich empfehlen das mit NFS gleich zu lassen und die entsprechenden directories einfach per bindmounts in den Container durchzureichen.
Wenn du tatsächlich VMs verwenden möchtest, dann ist NFS natürlich eine der einfachsten Lösungen. Nur über LXC wird das immer etwas problematisch sein, einfach aufgrund dessen, wie LXC funktionieren.

Führt dann dazu dass in der Docker-VM der Inhalt vom /mnt/nfs_share auftaucht

mp0: /mnt/pve/SSD3/Varustartes/Complete ISO/,mp=/mnt/nfs_share
mp1: /mnt/pve/SSD3/,mp=/mnt/storage

Aufgrund dessen, dass die Directories am Host tatsächlich in der selben Hierachie liegen und du auch noch explizit no_subtree_check setzt, ist das alles eigentlich genau zu erwarten.

 

[Varustartes]

VM != LXC, das sind zwei komplett verschiedene Technologien und haben nichts miteinander zu tun.
Und Docker in LXC wird von uns explizit nicht empfohlen - da es früher oder später zu Problemen führen wird.

Danke für deine Antworten. Diese Passage war von mir wohl etwas missverständlich ausgedrückt.
Ich habe eine VM für Docker im Einsatz, und dort möchte ich einen NFS-Share einbinden, der widerrum in einer LXC als NFS-Server bereitgestellt wird.

Da beides das selbe Subnetz ist, sind beide Shares für alle Clients im 192.168.0.x zugreifbar.

Okay, das war mir nicht bewusst. Hätte ich eigentlich selber drauf kommen müssen, dass ich mit /24 dann das ganze Subnetz öffne.

Allgemein - wenn du LXC verwendest und die Disken sowieso am Host angeschlossen sind, würde ich empfehlen das mit NFS gleich zu lassen und die entsprechenden directories einfach per bindmounts in den Container durchzureichen.
Wenn du tatsächlich VMs verwenden möchtest, dann ist NFS natürlich eine der einfachsten Lösungen. Nur über LXC wird das immer etwas problematisch sein, einfach aufgrund dessen, wie LXC funktionieren.

So ist es ja aktuell gelöst. Für die LXCs habe ich direkt bindmounts verwendet, das klappt auch gut.
Für die VM - weil ich dort afaik keine bindmounts verwenden kann - habe ich dann per NFS (PVE-MP->LXC-NFS->VM) den Share in der VM eingebunden.

Aufgrund dessen, dass die Directories am Host tatsächlich in der selben Hierachie liegen und du auch noch explizit no_subtree_check setzt, ist das alles eigentlich genau zu erwarten.

Auch hier muss ich zugeben dass ich mich mit no_subtree_check nicht auseinander gesetzt hatte.
Ich war nur verwundert dass es mit mehreren Shares immer so wie gewünscht funktioniert hatte, und erst als ich die Shares konsolidiert hatte das Verhalten auf einmal abweicht.

Ich prüfe jetzt noch mal no_subtree_check, sowie die Angabe das Subnetzes, passe es an und probiere es erneut.

Danke für eure Geduld & Aufklärung!