Edomi in Proxmox LXC container.

[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]

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!

[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]

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]

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?

[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]

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...

[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]

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...

[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?

[ruppsn]

Heute Nacht nun das 3x in diesen Betriebswochen: Proxmox ist nicht mehr sauber erreichbar - ohne einen ersichtliches Ereignis oder Last, weil in den frühen Morgenstunden):

Hi,
hatte ich bei mir auch schon mal, ebenfalls NUC8i3BEK mit einer Kingston SSD, die sogar in der Kompatibilitätsliste von Intel steht. Nachdem ich die gegen eine Samsung ausgetauscht hatte, waren die Probleme weg. Ich muss allerdings dazu sagen, dass das System nie länger als 1 Woche am Stück stabil lief, ist also ein bissl anders gelagert als bei Dir. Ob es Dich weiterbringt, weiß ich aber leider nicht.

VG
Stephan

[saegefisch]

Dem MT sollte es doch ziemlich egal sein, ob die DNS-Anfrage an ihn gestellt wird und er sie an PI-Hole weiter leitet oder der Client direkt bei PI-Hole anfragt. Hm...aber vielleicht hast Du auch schlicht recht... ich weiß es nicht...aber genau deswegen versuche ich ja gerade die damals mal manuell eingestellte DNS-Einstellung auf den PI-Hole umzubiegen - und es fällt immer wieder zurück auf meine initiale Einstellung. Ich vermute, dass dort die Ursache von allem liegt.

Die DNS-Umstellungen habe ich die ganze Zeit schon unter "System -> DNS" gemacht. Habe es auch mal direkt mit /etc/resolv.conf versucht, aber gleiches Ergebnis...

In einem anderem Forum habe ich gelesen, dass es das Verhalten gibt, wenn ein anderer Netzwerk-Manager installiert wird. Ich hätte eigentlich voller Überzeugung gesagt: habe ich nicht, ist alles pur Proxmox! Nach einem Blick in mein Wiki sehe ich aber:

apt install ifupdown2

habe ich damals als einzige zusätzliche Installation gemacht Habe mir damals dazu notiert "für direktes "Apply Configuration"". Möglicherweise kollidieren die beiden? Hat ifupdown2 anderer DNS-Einstellungen als /etc/resolv.conf und wenn ja: wo?

NACHTRAG: Sehe gerade: In der /etc/network/interfaces - habe dort mal DHCP aktiviert und jetzt wird der 1. DNS korrekt auf PI-Hole gesetzt. Yippie. Ändert aber nix daran: ping/dig ist mal erfolgreich, mal dauert es minutenlang, bis dig was "received" hat... Irgendwie scheint Proxmox über PI-Hole unglücklich zu laufen...

Status: ich sehe die Anfragen von Proxmox in PI-Hole als erfolgreich ("OK"). Apt-get update funktioniert im SSH-Terminal. Ping auch - aber manchmal dauert es unfassbar lange - für den ping bis zum timeout. Vielleicht macht DHCP jetzt irgend etwas besser.

Bleibt die ursprüngliche Frage: Das DNS-/Upgrade-Thema war ja Stunden vor dem Einfrieren. Wie kann ich über das SysLog hinaus erforschen, was um 7:21 Proxmox einfrieren ließ?

[starwarsfan]

Hi

Der MT liefert PI-Hole aus - so wie bei Dir und üblich. Damit muss man sich nie darum kümmern und alle Geräte laufen darüber. Läuft wunderbar seit geraumer Zeit.

Das ist schon klar und auch völlig korrekt. Aber bekommt denn Dein ProxMox-Host seine IP auch via DHCP? Wohl eher nicht!? Daher muss i.d.R. auch der DNS explizit konfiguriert werden.

Bei Proxmox hatte ich den MT (192.168.xx.1) selber eingetragen (Siehe oben). Aber auch mit PI-Hole als 1. DNS ändert sich nichts oder auch mal direkt 9.9.9.9. Die Symptome bleiben immer gleich.

Aber das ist m.M.n. falsch. Dort gehört die IP vom DNS hin aber nicht vom Router! Ich weiss nicht, wie sich der MikroTik verhält, wenn da jetzt DNS-Anfragen an ihn kommen...

Und nach ein paar Minuten setzt Proxmox die DNS-Einstellungen automatisch zurück auf meine Einstellungen der Erstinstallation... inkl. dieser beiden Zeilen, die Proxmox selber einträgt.

Das ist klar. Du musst das in der Admin-Oberfläche ändern, zu finden unter "System > DNS".

[saegefisch]

Der MT liefert PI-Hole aus - so wie bei Dir und üblich. Damit muss man sich nie darum kümmern und alle Geräte laufen darüber. Läuft wunderbar seit geraumer Zeit.

Bei Proxmox hatte ich den MT (192.168.xx.1) selber eingetragen (Siehe oben). Aber auch mit PI-Hole als 1. DNS ändert sich nichts oder auch mal direkt 9.9.9.9. Die Symptome bleiben immer gleich.

Und nach ein paar Minuten setzt Proxmox die DNS-Einstellungen automatisch zurück auf meine Einstellungen der Erstinstallation... inkl. dieser beiden Zeilen, die Proxmox selber einträgt.

[starwarsfan]

Hi

In /etc/resolv.conf habe ich meine MikroTik stehen. Der hat als primären DNS mein PI-Hole, als sekundären Quad9. Auf dem Weg fragen auch alle anderen Geräte DNS bei mir an. Daher für mich auch so unerklärlich...

domain int
search int
nameserver 192.168.xx.1

Irgendwie ist das jetzt nicht so recht eindeutig, zumindest für mich. Ich verstehe es aber mal so, als ob der Eintrag in der resolv.conf der MikroTik-Router ist, korrekt? Und da frage ich mich, warum? Ich habe dort direkt meine PiHole-Instanz drin stehen. Was haben denn Deine anderen Geräte vom Router als IP für den DNS bekommen? Die IP vom Router oder die IP vom PiHole? Sprich, geht der DNS-Traffic wirklich erst über den Router?