QNAP QuTS Hero 5.2 "virtual switch" ohne IP-Adresse für Container

[KillerCow]

Mahlzeit

Bin gerade etwas am Verzweifeln. Für ein Projekt darf ich eine QNAP TS-464u einrichten. Auf dem Ding soll auch ein Debian Container laufen (mit statischer IP-Konfig). Soweit erstmal alles nicht weiter wild.

Die Kiste hat zwei Netzwerkschnittstellen. Die eine hat regulär ihre IP-Konfiguration bekommen, worüber ich an das Teil dran komme.
Die zweite Schnittstelle soll für den Container (und ggf. weitere) genutzt werden. Das NAS selbst braucht und soll auf dieser zweiten Schnittstelle keine IP-Konfiguration bekommen. Container landen an einer Bridge und an dieser Bridge hängt die Schnittstelle, fertig.

Habe ich in der Art auch eingerichtet (physical interace hat keine IP-Konfiguration, virtual switch steht auf "do not assign an ip address"), allerdings kann ich beim Anlegen eines LXD-Containers den "virtual switch" nicht auswählen (ist ausgegraut). Die Fehlermeldung suggeriert, es fehle die IP-Konfiguration.

Als Vergleich, in meinen Proxmox-Systemen fahre ich fast immer ein ähnliches Setup: Eine physische Schnittstelle für den Zugriff aufs WebUI, API, etc. und eine weitere physische Schnittstelle (ohne IP-Konfiguration) hängt an einer bridge (ohne IP-Konfiguration), an der die VMs/Container hängen.

Muss in diesem tollen QuTS Hero ein "virtual switch" eine IP-Konfiguration haben, damit man daran Container anstöpseln kann oder mache ich schlicht irgendwas falsch!?

Bin für jeden Tipp dankbar.

 

[VDC]

Probiere es doch anstatt darüber zu meckern, dass es bei Proxmox doch funktioniert hätte.

 

[KillerCow]

@VDC Verstehe ich nicht!? Ich habe es ausprobiert, wie oben beschrieben und es funktioniert nicht auf der QNAP.

Ergänzung (28. Juli 2025)

Ist allerdings meine erste qnap, daher die "Hoffnung", dass ich mich doof anstelle. Nur finde ich keine Hebel mehr und keine eindeutigen Hinweise im Netz, ob das so klappen kann oder nicht.

 

[CoMo]

Und hast du mal versucht, dem Switch eine Adresse zu geben, ihn einem Container zuzuweisen und ihm dann die Adresse wieder wegzunehmen?

Alternativ 0.0.0.0/0?

 

[und tschüss]

Ich verstehe dein Problem irgendwie nicht ganz.
Soll das wirklich ein Container sein und keine VM? Nicht alles, was man in einem Container beistellen und ausführen kann, ist auch wirklich praktisch!

Wenn du im Container eine bestimmte IP benutzen willst, musst du diese IP auch dem Container mitgeben. Soll der Container eine dem Netzwerk zugeordnete Adresse bekommen, ist die Einrichtung als Macvlan notwendig. Dann kann der Container über einen virtuellen Switch in der Qnap erreicht werden. Beachte aber die besonderen Einschränkungsengen vom Macvlan zum Host-System.

Die Customer-NAS-Systeme haben keine richtige Netzwerksteuerung. Wenn du da etwas steuern willst, passiert das meist über die Firewall. Dazu muss natürlich das 2. Interface auch eine IP bekommen. Mehr ist bei er Software oft nicht möglich.

Warum nutzt du keine VM?
Um welchen Container handelt es sich?
Welche Ports hast du gemappt?

 

[CoMo]

Um welchen Container handelt es sich?

Steht doch im ersten Post. Debian.

Warum nutzt du keine VM?

Warum sollte eine VM da jetzt besser sein?

 

[und tschüss]

Steht doch im ersten Post. Debian.

Es gibt mehrere, die sich alle ein wenig unterscheiden. z. B. offizielle und inoffiziellen Container mit oder ohne Modifikationen oder Änderungen z. B. bestimmte Apps. Ich kann leider nicht hellsehen, was der Hintergrund für dieses Vorhaben ist.

Warum sollte eine VM da jetzt besser sein?

Beim Abbilden eines OS ist die VM auf jeden Fall die besser Lösung. Grundsätzlich sollte man sich mit den Unterschieden zwischen Docker und einer VM auseinandersetzten. Die VM kann man mit einer nativen Installation vergleichen und ist leichter zu installieren, anzuwenden und auch aktualisieren.

Bei einer VM ist das Dockernetzwerk (Bridge, Host oder Macvlan) uninteressant, da diese VM wie beim Macvlan eine eigene IP aus dem Netzwerk bekommt.

Nur weil vieles in Docker möglich ist, ist es nicht immer die beste Lösung. Ein OS ist eindeutig in einer VM besser aufgehoben!

 

[CoMo]

Stimmt. Aber hast du dich vielleicht im Thread geirrt? Hier geht es um LXC. Von Docker hat hier niemand gesprochen. Ein LXC Container ist ein ganz normales OS, mit eigenem Paketmanagement und eigener Netzwerkkonfiguration. Genauso wie eine VM.

 

[und tschüss]

Aber hast du dich vielleicht im Thread geirrt?

Kann sein, hatte das mit seinem Proxmox durcheinander gebracht.

 

[thrawnx]

Stimmt. Aber hast du dich vielleicht im Thread geirrt? Hier geht es um LXC. Von Docker hat hier niemand gesprochen. Ein LXC Container ist ein ganz normales OS, mit eigenem Paketmanagement und eigener Netzwerkkonfiguration. Genauso wie eine VM.

Naja, meines Wissens nach ist es das eben nicht, da eine VM ihren eigenen Kernel fährt und LXC Container greifen alle auf den selben Kernel des Hosts zu.

 

[CoMo]

Richtig; das ist genau der Grund, warum man einen LXC-Container anstelle einer VM einsetzt.