Es können nicht alle Ordner automatisch bereitgestellt werden

[maxblank]

Und der kommt mit der Installation von VMM…

Edit: Könnte auch Docker betreffen.

 

[Benares]

Mmh, ich hab keinen VMM (aber Docker) und finde bei mir nichts in der Richtung. Aber es gibt einige ovs-Befehle im DSM:

root@DS1522:~# ovs <TAB><TAB>
ovs-appctl    ovs-dpctl     ovs-vsctl     ovsdb-client  ovsdb-tool
ovs-docker    ovs-ofctl     ovs-vswitchd  ovsdb-server

 

[Ulfhednir]

Nach meinem Wissenstand werden die Adapter mit der Installation von VMM in ovs_ umbenannt. Also für mich Normalfall.
Open vSwitch lässt sich in den Netzwerkeinstellungen aktivieren.

Ich habe jetzt übrigens noch einen Laptop mit Stand vor Windows-Update angestöpselt (bzw. Wiederherstellung durchgeführt).
Das Ergebnis ist identisch: Stöpsle ich das Gerät per LAN an, funktioniert die Übertragung nicht. Per WLAN kann ich Dateien übertragen.

@Ebbi hast du VMM und / oder Docker bei dir im Einsatz?

 

[Benares]

Danke für die Info. Gibt es im VMM irgendwelche Einstellungen zur MTU?

 

[ctrlaltdelete]

Wäre mir nicht bekannt.

 

[Ulfhednir]

Nein, du kannst nicht wirklich viel einstellen. Du kannst konkret virtuelle Netzwerke erstellen und diese zu physischen Netzwerkadaptern zuweisen.
Nicht mehr, nicht weniger. Die MTU werden vom physischen Adapter übernommen.

Die MTU (VMM/Docker-Netzwerke) auf sind allesamt bei 1500. Ausnahme Loopback (denke normal) und sit0 (Tunneldevice IPv6? = Nutze kein IPv6 im Heimnetz).

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1
link/sit 0.0.0.0 brd 0.0.0.0
3: eth3: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 1000
link/ether 00:11:32:f5:ae:22 brd ff:ff:ff:ff:ff:ff
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master ovs-system state DOWN group default qlen 1000
link/ether 00:11:32:f5:ae:21 brd ff:ff:ff:ff:ff:ff
5: eth1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc pfifo_fast master ovs-system state DOWN group default qlen 1000
link/ether 00:11:32:f5:ae:20 brd ff:ff:ff:ff:ff:ff
6: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master ovs-system state UP group default qlen 1000
link/ether 00:11:32:f5:ae:1f brd ff:ff:ff:ff:ff:ff
7: eth4: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP group default qlen 1000
link/ether 00:11:32:d8:1a:6b brd ff:ff:ff:ff:ff:ff
8: ovs-system: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1

Möglicherweise ist man hier ja auch auf dem Holzweg. Aber verdächtig sind die vielen MTU-Fehlermeldungen trotzdem.

 

[Ulfhednir]

Ich glaube oder hoffe, dass ich einen Schritt weiter bin... Ich habe jetzt mal bei meinem Unifi-Switch die Auto-negotiation für einen Port der DS manuell abgeändert. Beim 10G-Port kriege ich bei Unifi eine Fehlermeldung. Das heißt: Ich kann für den Moment zumindest mit ~100MB/s wieder kopieren - ohne, dass der Explorer wegschmiert.

 

[Ebbi]

@Ebbi hast du VMM und / oder Docker bei dir im Einsatz?

Ja, beides. VMM und "Container Manager" (formerly known as Docker).

Möglicherweise ist man hier ja auch auf dem Holzweg. Aber verdächtig sind die vielen MTU-Fehlermeldungen trotzdem.

Das wäre möglich. Diese Meldungen ovs_eth0: dropped over-mtu packet bekomme ich auch, egal mit welcher MTU. Allerdings nur am 10 GbE Interface, nicht am Gigabit Interface.
Aber leider weiß ich nicht, ob ich die auch hatte, bevor die Probleme aufgetreten sind, weil die letzten 1,5 Jahre alles problemlos funktioniert hat und ich nicht nachgeschaut habe.

Laut Google gibt es diese dropped over-mtu packet Meldungen auch bei Proxmox, natürlich openvswitch.org und sogar kernel.org.
Dabei ist auch von einem Fehler im Broadcom Treiber die Rede.
Allerdings weiß ich nicht, ob das 10 GbE Interface der DS1621xs+ von Broadcom ist.

https://forum.proxmox.com/threads/dropped-over-mtu-packet-1501-1500.83087/ (2021)
https://lore.kernel.org/all/25c70926-1f20-395e-952c-b802aca2cbdc@ucloud.cn/T/ (2020)
https://mail.openvswitch.org/pipermail/ovs-discuss/2013-December/032066.html (2013)

 

[Ulfhednir]

Die Beiträge habe ich auch schon grob überflogen. Ich habe jetzt auch Auto-negotiation bei allen Ports deaktiviert und manuell hinterlegt. Auf dem Rechner ist das auch schon so hinterlegt. Ich komme allerdings jetzt nicht mehr über den 1G hinaus.

Kannst du das bei deinem QNAP-Switch ebenfalls umstellen?

 

[Benares]

Und welchen Link zeigt nun DS/Switch? Scheint ja wirklich nur GBit zu sein.

 

[Ebbi]

Kannst du das bei deinem QNAP-Switch ebenfalls umstellen?

Nein, der ist unmanaged.
Aber ich gehe stark davon aus, dass das nicht mein Problem ist, da mein Setup seit 1,5 Jahren unverändert funktioniert hat.

Hier würde ich auf die Info des Support warten. Es sei denn es macht nicht viel Mühe. Aber wenigstens konntest du somit die Fehlerquelle etwas eingrenzen.

Der Support hat mir geantwortet, dass ich alles das testen soll, was ich hier schon gemacht habe.
Dann kann ich ihm ja die Ergebnisse direkt mitteilen.
Außerdem soll ich mitteilen, ob meine 10 GbE Karte supported ist. Offenbar hat er übersehen, dass die bei meiner DS onboard ist...

 

[Ulfhednir]

Nein, der ist unmanaged.
Aber ich gehe stark davon aus, dass das nicht mein Problem ist, da mein Setup seit 1,5 Jahren unverändert funktioniert hat.

Was soll ich dir sagen....? Das war bei mir ebenfalls der Fall.
Noch eine Frage: Hast du das letzte DSM-Update drauf? (DSM 7.2.1-69057)

 

[Ebbi]

Ja, das habe ich.
Seit 26.9. morgens und es hat danach noch bis 27.9. mittags funktioniert.
Laut Changelog gab für das Netzwerk keine Änderungen.
Wenn jetzt plötzlich alles AutoNego-Switche für die Tonne wären, wäre das inakzeptabel.

Ich probiere nochmal mehr rum, aber das schaffe ich zeitlich erst am Wochenende.

 

[Ulfhednir]

Ich glaub ich muss zurückrudern. Geht schon wieder nicht.

 

[Ulfhednir]

Möglicherweise ein bekannter Bug:
https://community.synology.com/enu/forum/1/post/163057

 

[Benares]

Also doch etwas mit Open vSwitch und MTU. Ich habe Open vSwitch nicht aktiv und keine Probleme mit 10GBit.

 

[Ulfhednir]

Könnte mir vorstellen, dass der VMM die Wurzel des Bösen ist. Der aktiviert ja den Open vSwitch. Zeitlich würde es auch reinpassen.

(2023-09-26)
Bug fixed

1. Fixed an issue where a powered-off virtual machine might impact the hibernation of the host.
2. Fixed an issue where running Virtual DSM with high specifications might cause the host to run out of memory.

 

[Benares]

Wenn VMM Speicher frisst müsstest du das ja im Ressourcen-Monitor sehen. Hast du VMM 2.6.5-12202 schon installiert? Da der zusammen mit DSM 7.2.1-69057 am 26.09.2023 released wurde, dürfte DSM 7.2.1 wohl Pflicht sein.

Edit: Hier ist übrigens auch noch was dazu - sogar mit einer Aussage von Synology.

 

[Ulfhednir]

Ich hatte keine Probleme mit dem Speicherverbrauch. Aber darum geht es mir auch gar nicht. Ich möchte eigentlich wissen an welcher Stelle Synology den Kollateralschaden verursacht hat und da kommt mir nur der VMM in den Sinn.

Wie auch immer: Ich habe jetzt auch ein Ticket erstellt und habe auf die vorhandenen Forenbeiträge verwiesen.
Der Bug ist vorhanden, ich will jetzt nur noch von Lösungen hören. Ich hab jetzt genug Zeit vertüddelt.

 

[Ulfhednir]

Ich habe am Sonntag (!) die Info bekommen, dass die eine Fernwartung benötigen. Es wurden auch keine unnötigen Fragen gestellt.
Synology benötigte einen Admin-Zugang. Fix wurde heute manuell eingespielt und tatsächlich läuft wieder alles. Endlich kann ich meinen Portable Thunderbird wieder per Netzwerkfreigabe verwenden!