Edomi in Proxmox LXC container.

[saegefisch]

Dank‘ Dir, jeder Hinweis ist wertvoll! Gerade bei sporadischen Themen kann es immer auch HW sein - und ohne Deinen Hinweis kam mir das dennoch gar nicht in den Sinn. Ist halt auch selten, dass HW Problem macht.

@all: gibt es Indikatoren für HW-Probleme mit der SSD im System, nach denen ich suchen könnte? Gibt es vielleicht bestimmte Marker/schwache Signale/Symptome in syslog oder Journal bei so etwas bzw. im Vorfeld?

[saegefisch]

Gestern war Proxmox wieder down...

Ich gehe davon aus, dass ich grundlegend etwas in der Netzwerk-Konfiguration im VLAN-Kontext falsch konfiguriert habe. Faktisch habe in beide Richtungen sporadische/regelmäßige Störungen; das deutet nach meinem Verständnis darauf hin. Die Container (z.B. edomi) hingegen laufen alle sauber mit DNS/Ping/SSH/gesamte Funktionen - bis Proxmox halt einfach stehen bleibt.

• OUTBOUND: Ich habe ausschließlich vom Proxmox-Host aus weiterhin ein regelmäßiges, aber nicht dauerndes Problem mit DNS - mal geht's etwas, meist geht's nicht. Kein einziges anderes Gerät im mittlerweile umfassenden Netzwerk hat sonst ein DNS-Thema.
• INBOUND: Zum Host komme ich per Ping nur von manchen anderen Geräten. Selbst der MikroTik hat einen reproduzierbaren gestörten (aber nicht toten) Zugang per Ping btw. traceroute.. das sieht nicht gut aus...

traceroute.JPG
Vielleicht fange ich noch mal ganz vorne an und frage nach Euren Netzwerkkonfigurationen:

• Vereinfachtes Beispiel: VLAN 210 = internes SubNetz | 220 = Subnetz A | 230 = Subnetz B | 1 = Management (derzeit nutze ich es nicht)
• Host hängt am MikroTik-Router TRUNKED (VLAN mode: "check" | VLAN Header "leave as is" | Default VLAN ID "210")

Ziele für Proxmox-Netzwerk:

• 1 Rechenzentrum | 1 Knoten | X Container
• Host bekommt IP per DHCP (statische beim Router), z.B: 192.168.210.10
• Container bekommen alle IP per DHCP (ebenfalls statisch beim Router), z.B. 192.168.210.11, 192.168.210.12, 192.168.220.20, 192.168.230.30
• Die meisten Container liegen fest in einem VLAN.
• Einzelne Container (z.B. AVAHI/bonjour) liegen in alle VLAN

Meine Einstellungen im Proxmox-Knoten:

• eno1 = Netzwerkkarte
• eno1.210 = Linux VLAN
• eno1.220 = Linux VLAN
• eno1.230 = Linux VLAN
• vbmr0 = Linux-Bridge -> Bridge-Port: eno1 | VLAN-aware: "Nein" | Autostart: X
• vbmr210 = Linux-Bridge -> Bridge-Port: eno1.210 | VLAN-aware: "Nein" | Autostart: X
• vbmr220 = Linux-Bridge -> Bridge-Port: eno1.220 | VLAN-aware: "Nein" | Autostart: X
• vbmr230 = Linux-Bridge -> Bridge-Port: eno1.230 | VLAN-aware: "Nein" | Autostart: X
• in /etc/network/interfaces stehen alle inet auf "manual", aber ohne IP/NMask/GW (wofür auch). Nur vmbr0 steht auf "dhcp" (damit der Host eine IP bekommt - ich dachte, das wäre so klug...ist es aber wohl möglich nicht)

[SIZE=11px]auto lo
iface lo inet loopback
iface eno1 inet manual
iface eno1.210 inet manual
iface eno1.220 inet manual
iface eno1.230 inet manual
auto vmbr0
iface vmbr0 inet dhcp
bridge-ports eno1
bridge-stp off
bridge-fd 0
auto vmbr210
iface vmbr210 inet manual
bridge-ports eno1.210
bridge-stp off
bridge-fd 0
auto vmbr220
iface vmbr220 inet manual
bridge-ports eno1.220
bridge-stp off
bridge-fd 0
auto vmbr230
iface vmbr230 inet manual
bridge-ports eno1.230
bridge-stp off
bridge-fd 0[/SIZE]

Meine Einstellungen in den Proxmox-Containern:

• Container1: net0 | Name: "eth0" | Bridge: "vmbr210" | VLAN-Tag: - | MAC: <unique_festgelegt> | DHCP | Firewall: nein
• Container2: net0 | Name: "eth0" | Bridge: "vmbr220" | VLAN-Tag: - | MAC: <unique_festgelegt> | DHCP | Firewall: nein
• Container3: net0 | Name: "eth0" | Bridge: "vmbr230" | VLAN-Tag: - | MAC: <unique_festgelegt> | DHCP | Firewall: nein
• AVAHI-Container: net0 | Name: "eth0" | Bridge: "vmbr0" | VLAN-Tag: - | MAC: <unique_festgelegt> | DHCP | Firewall: nein
• AVAHI-Container: net0 | Name: "eth0.210" | Bridge: "vmbr210" | VLAN-Tag: - | MAC: <unique_festgelegt> | DHCP | Firewall: nein
• AVAHI-Container: net0 | Name: "eth0.220" | Bridge: "vmbr210" | VLAN-Tag: - | MAC: <unique_festgelegt> | DHCP | Firewall: nein
• AVAHI-Container: net0 | Name: "eth0.230" | Bridge: "vmbr210" | VLAN-Tag: - | MAC: <unique_festgelegt> | DHCP | Firewall: nein

Fragen:

• Ist die es falsch, im MT-Router default = VLAN 210 zu setzen und damit eno1/vmbr0 und eno1.210/vbmr210 im selben Subnetz zu haben? Sollte der Host-Zugriff besser über das Management-VLAN 1 erfolgen? Oder sollte man auf vmbr0 ganz verzichten oder auf vmbr210? Kommt es da zu Kollisionen?
• Andere Fehlkonfigurationen/Gedanken?
• Wie sieht die Konfig bei Euch aus? Vielleicht mit /etc/network/interfaces und/oder screenshots des Proxmox-Knoten-Netzwerks?

Der Austausch der SSD aus dem letzten Rat hier im Forum befolge ich, wenn das Netzwerk sauber läuft und es wieder zu einem freeze kommt. Mit den Symptomen glaube ich nicht so recht, dass es die SSD sein könnte...

[jonofe]

Ich kenne mich zwar mit Proxmox gar nicht aus, hatte aber auch lange Zeit ein Problem mit Aussetzern im Zusammenhang mit VLANs und insbesondere bei deren Zuordnung zu WLANs. Die Ursache war am Ende, dass ich mehrere Interfaces mit derselbe MAC Adresse hatte. Ist vielleicht mal einen Check wert, insbesondere weil das gerade bei Virtualisierung/Containerization schnell mal passieren kann.
Übrigens hat es sich auch in total wechselhaften PING Werten geäußert. Manchmal performant, manchmal total träge (bis zu 30 Sekunden bis die Antwort kam) und manchmal Totalausfall.

[saegefisch]

Daran dachte ich auch schon: Selbe IP oder selbe MAC wäre ja der Klassiker für so ein Verhalten.... Habe den Proxmox runter gefahren und geprüft, ob die IP von einem anderen Gerät per ping antwortet oder in der ARP ist. War nicht. Die vergebenen MAC-Adressen des Hosts habe ich auf Dublette geprüft, alle anderen MAC der Container vergebe ich mittlerweile selber systematisch und habe ich gestern schon x mal geprüft...

[starwarsfan]

Hi

Bei mir bekommen nur die Geräte ausserhalb des Rack ihre IPs via DHCP. Alles im Rack hat eine feste IP. Damit fahre ich seit Jahren gut und ohne jegliche DHCP Probleme.

[saegefisch]

Hi Yves,
der eine so, der andere so - es gibt für beides gute Gründe... Und in Bezug auf doppelte IP ist's eher gefährlicher, dafür in Problemsituationen stabilier.

Aber DHCP ist ziemlich sicher nicht mein Problem. Ich vermute, es ist nicht richtig, dass Netzwerkkarte und VLAN210 (also eno1 und eno1.210 und damit auch die Bridges vmbr0 und vmbr210) im selben Subnetz liegen. Aber anders habe ich es nicht hin bekommen, dass der Host und manche Container im selben VLAN liegen. Habe ich da einen Denkfehler oder nicht? Daher die Frage: Wie sieht bei Dir die /etc/network/interfaces aus? Und: Machst Du das Management im internen Netz oder über ein Management-VLAN (meist ja ID 1)? Oder müsste ich mit "VLAN aware" arbeiten (mit nur 1 Bridge vmbr0?) und den Containern ein VLAN zuweisen statt x bridges?

[saegefisch]

Ein Update - dank Yves Hilfe: Ich habe bislang offenbar viel zu kompliziert bei Proxmox im VLAN-Kontext gedacht. Hier mein neuer Versuch - vielleicht hilft es dem ein oder anderen. Anregungen, wo ich (weiterhin?) auf dem Holzweg bin oder zu einfach oder zu kompliziert denke: Immer her damit!

Zunächst der Erfolg und Ziele:

• Proxmox hängt an per trunk am Router
• Einer der Problem war, dass ich im Mikrotik dem Port ein Default-VLAN mit gab. Seit ich das entfernt habe, sind bereits viele Problem mit DHCP verschwunden (im Default-VLAN wurde mir das DHCP-Lease mit nach "waiting" mit "offered" angezeigt, aber es wurde die "bound" erreicht. Ohne Default-VLAN am Port geht das nun sauber
• Per ssh in auf Proxmox nun ping auf beliebge URL (inkl. ftp.de.debian.org) ohne loss in durchgängiger icmp_seq. Ebenso geht apt-get update nun immer und in sekunden -> Damit sind meine sporadischen Proxmox-Ausfälle hoffentlich Geschichte. Wir werden sehen...
• IP von Proxmox nun statisch festgelegt - ist beim zentralen Server sicher keine falsche Idee. Habe ich letztlich bei edomi und dem KNX-GW auch schon so gemacht und wenigen sehr zentralen Geräten. Alles andere (tendenziell volatiler) soll unbedingt weiter per DHCP belegt werden.
• Alle Container sollen genau einem VLAN angehören. IP per DHCP
• Ein Container (AVAHI/bonjour) soll IP aus jedem VLAN bekommen. IP per DHCP

Bis jetzt (seit 3 Tagen) gehen die edomi-VMs wunderbar..
AVAHI muss ich erst wieder installieren, um das beurteilen zu können...

Proxmox: Die /etc/network/interfaces sieht jetzt schön einfach aus: Die Beispiel-VLANs 200, 201, 202,... und XXX und YYY muss man natürlich ersetzen:. Der Ansatz mit der Bridge, um damit auf Proxmox zugreifen zu können, habe ich aus einer Proxmox-Anleitung zum Thema VLAN (vom Hersteller). Ich nutze hier den Schalter "VLAN aware"

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet manual
bridge-ports eno1
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094

auto vmbr0.200
iface vmbr0.200 inet static
address 192.168.xxx.yyy
netmask 24
gateway 192.168.xxx.1

Container (1 VLAN - z.B. edomi):

net0 | Name = eth0 | Bridge = vmbr0 | FW = Nein | VLAN-Tag = 202 | MAC-Adresse = <auto> oder fest vergeben | IP = <dhcp> oder fest vergeben + Gateway

Container (mehrere VLAN):

net0 | Name = eth0 | Bridge = vmbr0 | FW = Nein | VLAN-Tag = 200 | MAC-Adresse = <auto> oder fest vergeben | IP = <dhcp> oder fest vergeben + Gateway
net1 | Name = eth0.201 | Bridge = vmbr0 | FW = Nein | VLAN-Tag = 201 | MAC-Adresse = <auto> oder fest vergeben | IP = <dhcp> oder fest vergeben + Gateway
net2 | Name = eth0.202 | Bridge = vmbr0 | FW = Nein | VLAN-Tag = 202 | MAC-Adresse = <auto> oder fest vergeben | IP = <dhcp> oder fest vergeben + Gateway
...

ACHTUNG: Bei mehreren VLAN in einem Container SICHERHEITS-RISIKO: UNBEDINGT prüfen, dass der LXC kein Forwarding zwischen den VLANs (am Router vorbei!) betreibt z.B: in /etc/sysctl.conf
Üblicherweise muss man sicher stellen, dass die Zeilen für IP4 UND IP6 mit dem ip_forward auskommentiert sind!

[saegefisch]

Aargh! Beim Versuch, AVAHI zu installieren gleich ein Problem:

• In Proxmox und alle anderen Containern mit 1 VLAN funktioniert DNS und upgrade/unnattended-upgrade wunderbar.
• Aber im AVAHI-Container mit mehreren VLAN geht gar nichts. Nutze das Proxmox-Ubuntu-Template 18.04. Upgrade geht nicht, weil DNS zwar offenbar noch auflöst, aber der ping nicht geht, weil der auf dem letzten der eth0.xxx abgesetzt wird und eben das eth0.210 ist über das VLAN 210 in der FW begrenzt ist. Das Beispiel-VLAN 200 hingegen nicht und soll eigentlich verwendet werden; ich häte gedacht, das System würde bevorzugtr eth0 benutzen, bevor es ein VLAN nutzt...

HAL-AVAHI:~$ ping archive.ubuntu.com
PING archive.ubuntu.com (91.189.88.152) 56(84) bytes of data.
From 192.168.210.1 (192.168.210.1) icmp_seq=2 Packet filtered
From 192.168.210.1 (192.168.210.1) icmp_seq=4 Packet filtered
From 192.168.210.1 (192.168.210.1) icmp_seq=6 Packet filtered

Muss man da die virtuellen NICs irgendwie nacharbeiten, dass primär eth0 (in VLAN 200) verwendet wird, statt ein eth0.210? Die ip a sieht unauffällig auf...
Kann man das irgendwie (und wo) priorisieren (route-metric)? Die /etc/network/interfaces ist leer und veweisst auf netplan, aber unter /etc/netplan ist gähnende Leere... in einem normalen Ubuntu würde ich mir wohl zu helfen wissen, aber wo stecken in Proxmox-Containern die Netzwerkeinstellungen?

Nachtrag: Wenn man eth0 statt dhcp statisch eine IP/GW gibt, geht ping und apt-get upgrade! Warum? Ist das erklärbar/logisch?

[saegefisch]

Proxmox läuft nun schon lange problemlos, eine stabile Lösung für vieles inkl. mehrerer edomi-Instanzen. Nun kam für mich der Bedarf auf, per NFS auf einen Share meines NAS zugreifen zu wollen - und scheitere seit ein paar Stunden. Die ersten Stunden dauerte es die Ursache für die erste Hürde zu finden: Unter Proxmox können unpriviligierte LXC offenbar kein NFS. Argh!. Zumindest sah die Fehlermeldung nach Neuaufbau des LXC mit ubuntu server priviligiert (und Aktivierung der Option -> Feature -> NFS) besser aus - aber noch nicht erfolgreich. Nun kommt:

[FONT=Courier New]mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting ...[/FONT]

Allerdings kann ich den selben Share mit exakt dem selben Befehl und user von einem dedizierten Ubuntu-Server problemlos aufrufen. Proxmox scheint hier verursachend zu stören:

sudo mount -v -t nfs4 <IP_NAS>:/Public /mnt/test

Ich bin dann noch auf Hinweise gestoßen, dass man in

[B][FONT=Courier New]/etc/apparmor.d/lxc/lxc-default-cgns[/FONT][/B]

noch was manuell (?!?) ergänzen muss:

mount fstype=nfs,
mount fstype=nfs4,
mount fstype=nfsd,
mount fstype=rpc_pipefs

Aber selbst nach reload von apparmor, dem LXC und am Ende auch dem gesamten Proxmox-Knoten bleibt der mount mit obigem Fehler nicht erfolgreich.

Hat jemand einen Hinweis, wie man aus einem Proxmox-LXC als Client einen NFS-Share mounten kann?
Letztlich werde ich das auch für meine edomi-LXC nutzen wollen, um die Backups per NFS regelmäßig auf dem NAS zu sichern.

Danke!

[vento66]

Keine Ahnung, was in dem Container schon alles installiert ist, aber bei mkir musste ich erst

yum install nfs-utils nfs-utils-lib

installieren. (Zumindest unter CentOS 6.5)

[saegefisch]

Der Container war ganz frisch aufgesetzt, nur update/dist-upgrade und - da ubuntu - sudo apt-get install nfs-common. Da sollte (hoffentlich) das ubuntu-Pendant von nfs-utils/nfs-utils-lib enthalten sein. Ich werde es aber auch noch mal mit einem frischen Centos versuchen, damit es vergleichbar ist.

[saegefisch]

Hallo Micha, hallo allerseits,
jetzt in Proxmox neben dem frischen ubuntu-Container auch ein frischen centos8-container aufgesetzt. Nichts außer nfs-utils und nfs4-acl-tools installiert -> gleicher Fehler:

[FONT=Courier New]mount.nfs4: mount(2): Permission denied
mount.nfs4: access denied by server while mounting ...[/FONT]

Beide Container priviligiert und Option -> feature -> NFS aktiviert. Gibt es für als NFS-Client in einem Proxmox-Container noch anderes zu tun/beachten?

Auf NAS die NFS-Freigabe mit * | NO_ROOT_SQUASH und auch mit ROOT_SQUASH versucht. Wie gesagt: Von einem dedizierten Ubuntu funktioniert der exakt selbe mount-Befehl erfolgreich. Aus Proxmox-CT nicht.

@Micha: Geht das bei Dir wie beschrieben in centOS (dediziert oder non-Proxmox) oder CentOS tatsächlich in Proxmox-Container?

[starwarsfan]

Hallo saegefisch,

hast Du in den Optionen auch Nesting aktiviert? Das braucht's soviel ich weiss auch...

Ansonsten könntest Du den NFS-Mount auch auf dem Host machen und mit einem Bind-Mount in den Container bringen. Wäre aber eher eine Notlösung...

[saegefisch]

Hallo Yves,

ARGH!!! Danach Stunden suchen... wie kommt man denn darauf... aber egal...

SOLVED...Das war's...danke!

Folgende Voraussetzungen hat demnach ein Proxmox-Container für NFS:
* priviligiert
* Optionen -> Features -> "NFS" + "Nesting"

Funktioniert für Ubuntu- und CentOS-LXC gleichermaßen.

[starwarsfan]

Cool, danke für die Rückmeldung.