Edomi in Proxmox LXC container.

[trollmar]

Ergänzung:
Proxmox + NUT (USV):

• Eine Lösung im LXC per USB-passthrough wäre wohl möglich nach Lösung des Busmaster-USB-Problems gegangen, aber bei genauerer Überlegung ergibt es erheblich mehr Sinn, NUT als Master direkt auf dem Proxmox-Host zu installieren, weil Proxmox natürlich zentral ist bei der Orchestrierung eines "geregelten Untergangs" bei Stromausfall. Im Proxmox-Forum gibt es genug klare Aussagen von von Mitarbeitern und Intensiv-Nutzern, dass dies durchaus gängige Praxis und best-practise ist. Mein ursprünglicher Gedanke, den Host so unberührt wie möglich zu lassen ist bei NUT einfach nicht sinnvoll; mindestens ein nut-client wäre es ohnehin geworden.
• Installation nach "Lehrbuch" rasch und völlig problemlos. Alle 3 QNAP-NAS konnten sich erfolgreich direkt als Slave anbinden.

Ich habe dafür nen eigenen Raspberry genommen.
der schaut halt ob alle Geräte Runtergefahren sind bevor er die USV selbst aus macht. Muss nur noch die sdcard des Pi read only setzen

[saegefisch]

skyacer : was genau? Wen "es" der 1-wire-Busmaster ist, dann lautet die Antwort: VM. Nach dem ich tatsächlich abgekämpft den Grund für das mehrtägige nicht-klappen gefunden hatte, hatte ich mich bereits für VM entschieden und das ging auch wunderbar wie oben beschrieben; die VM liefert mir seit dem verlässlich alle 1-wire-Werte per MQTT. Passt für mich. Ist die einzige VM, der Rest ist bei mir alles LXC. Ich bin da kein Dogmatiker und finde die VM jetzt gar nicht falsch. Ich hatte anfangs nur gedacht, es würde alles per LXC gehen, weil nach meinem Verständnis ressourcenschonender. Ist halt nicht so <achselzuck>. Sicherheitstechnisch sehe ich das unkritisch, weil ich kritische Teile (z.B. ReverseProxy, Firewall) seit jeher auf dedizierter HW habe, die würde ich nie als LXC oder VM umsetzen wollen (weil ich Sorge hätte, dass ich was beim Einrichten übersehe; mache das ganze ja nur als "interessierter Laie"...)

Ob mit dem obigen Hinweis der pass-through des (im Vergleich zu anderen USB-Geräten) offenbar etwas komplexeren USB-Geräts in einen LXC-Container nun doch auch funktionieren würde bis zur sauberen Verarbeitung per owfs, habe ich nicht mehr versucht - mein Forscherdrang war nach der Zeit verflogen und wollte nur noch Ergebnis. Aber wenn Du magst, kannst Du gerne hier berichten...am besten von einem erfolgreichen Versuch mit Anleitung...

[skyacer]

saegefisch
Wow. das sind ja gute Nachrichten. Hast du es nur in einer VM probiert oder auch in einem LXC?

Grüße

[saegefisch]

nicht wirklich OT aus meiner Sicht, weil in der VM (VM auf Proxmox) ich per Script die ganzen 1-wire-Sensordaten per MQTT an Mosquitto (Docker in LXC auf Proxmox) sende, an denen sich meine edomi (prod; bare-metal) und edomi-DEV + edomi-Projekt (beide LXC auf Proxmox) bedienen. Geht auch nach influxDB + grafana (beide Docker in LXC auf Proxmox)... OT...kann ich nicht direkt erkennen... damit alles wie vor her geht auch mit Vollzug meines Server-.Umzugs auf Proxmox... und ich endlich mit funktionierenden Infrastruktur den edomi-Umzug auch abschließen kann... dann mach' ich auch wieder mehr LBS- und Visu-Gedöns...

uzi10 : VM mit Ubuntu-Server-ISO aufbauen (ich nehme immer LTS; derzeit 20.04)

sudo apt-get update
sudo apt-get dist-upgrade
sudo apt-get install qemu-guest-agent
sudo mkdir /mnt/1wire
sudo apt-get -y install owfs owserver
sudo nano /etc/owfs.conf

Zusammenfassung der nicht auskommentierten Zeilen der conf:

! server: server = localhost:4304
server: usb = all
mountpoint = /mnt/1wire
allow_other
http: port = 2121
server: port = localhost:4304

reboot der VM, dann sollte http://<deine VM-IP>:2121 bereits die 1-Wire-Daten liefern.

[vento66]

Ich will ja nicht meckern, aber sind wir hier nicht arg OT?

[uzi10]

wie hast du das jetzt gemacht? Schritte nacheinander?
In einer Unbuntu VM??
Wäre toll, wenn du das zusammenschreiben könntest

[saegefisch]

wintermutejonofe war ja nicht wirklich OT, sondern rundet das Bild ab mit Alternativlösungen zum Thema... alles gut...

Aber ich kann nach 2 Tagen frustriertem forschen immerhin Erfolg melden - es ist am Ende wie immer ganz einfach:

Proxmox + 1-wire Busmaster DS2490:

• Wenngleich die Übergabe diverser USB-Geräte in einen LXC-Container offenbar gut und vielfältig funktioniert (Es gibt dazu genug Anleitungen, siehe auch oben bei bas29), so scheint der passtrough des 1-wire-Busmasters es einfach nicht zu wollen. Daher schient mir der Weg über eine VM statt LXC an dieser Stelle eine valide und sinnvolle Lösung
• WICHTIG: Warum auch Übergabe an die VM nicht funktionierte, inkl. unflushable VM, reboot des proxmox-Nodes, manchmal sogar per hartem Reset ist so einfach wie banal und im Nachhinein recht logisch: Wenn der Proxmox-Host den Busmaster erkennt, wird sein Kernel Modul geladen inkl. Aufbau einer lesbaren Verzeichnisstruktur der vom Busmaster erkannten Sensoren via ls -l /sys/bus/w1/devices/. Das muss verhinder werden, wenn der Busmaster in einer VM/Container funktionieren soll:

  sudo nano /etc/modprobe.d/blacklist.conf

# Disable auto loading of Dallas USB-1-wire adapter
blacklist ds2490

Nach einem anschließenden Reboot des Nodes funktioniert das alles dann ganz geschmeidig, die VMs fühlen sich so an, wie man das erwartet und der Host zickt nicht mehr rum. Und in der VM liefert dann ls -l /sys/bus/w1/devices/ auch Sensorinformationen.

--> In der VM war die Installation des owfs dann nach 10 Minuten erledigt.
Die Zeit bis hierhin war hartes und bitteres Lehrgeld... Am Ende bin ich aber froh über meine Hartnäckigkeit - weil ich einfach wusste, dass es gehen muss. Möge dieses Fazit anderen helfen, schneller zum Ziel zu kommen.

Ergänzung:
Proxmox + NUT (USV):

• Eine Lösung im LXC per USB-passthrough wäre wohl möglich nach Lösung des Busmaster-USB-Problems gegangen, aber bei genauerer Überlegung ergibt es erheblich mehr Sinn, NUT als Master direkt auf dem Proxmox-Host zu installieren, weil Proxmox natürlich zentral ist bei der Orchestrierung eines "geregelten Untergangs" bei Stromausfall. Im Proxmox-Forum gibt es genug klare Aussagen von von Mitarbeitern und Intensiv-Nutzern, dass dies durchaus gängige Praxis und best-practise ist. Mein ursprünglicher Gedanke, den Host so unberührt wie möglich zu lassen ist bei NUT einfach nicht sinnvoll; mindestens ein nut-client wäre es ohnehin geworden.
• Installation nach "Lehrbuch" rasch und völlig problemlos. Alle 3 QNAP-NAS konnten sich erfolgreich direkt als Slave anbinden.

[bas29]

Ich habe hier nur einen simplen JeeLink-LaCrosse-868MHz Stick den ich an einen ioBroker Container übergebe.

Inhalt der /etc/udev/rules.d/99-usb-serial.rules

SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="LaCrosse", MODE="0666", GROUP="dialout"

Und Zeilen in Container Conf.

lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/LaCrosse dev/LaCrosse none bind,optional,create=file

Übersteht Reboots vom Host bei wechselnden Ids. Beim Umstecken muss man allerdings einmal den Container neu starten.

[wintermute]

Wie bekommst du denn das USB-Gerät in die LXC übergeben?

Sorry, das war etwas OT von mir: ich hatte mich auf Andrés ESXi bezogen, ich nutze keine LXC Container kann da also nix zu sagen.

[jonofe]

Ich weiss nicht ob das eine Loesung fuer dich darstellen wuerde, aber ich habe einen DS2490 an einem ESXi seit Jahren problemlos in Betrieb (an einer USB2 Buchse des Mainboards), dahinter haengt (noch) ein CommunityGate das damit arbeitet.

Ich muss mich korrigieren, hatte es wohl falsch in Erinnerung. Das Problem hatte damals der Kartenleser für meine HD+ Karte erzeugt und nicht der 1-wire USB Hostadapter.

Habe gerade nochmal an meinem ESXI nachgeschaut, mein DS9490 ist auch an einem USB2 Anschluss an die VM durchgereicht und dies funktioniert auch sehr zuverlässig. Also genau wie von Dir, Michael, beschrieben.

André, wenn Michaels Weg bei Dir nicht klappen sollte, funktioniert der VM-Lösung vielleicht bei Dir.

Ja, bei mir läuft ja ohnehin alles auf VMs.

[saegefisch]

skyacer Dank Dir, Jascha. Das ist schon mal gut zu wissen, dass die Strategie an sich gut funktioniert und das durchaus ein Lösungsweg ist!
Aber eine Frage noch dazu: Bleibt bei Dir Port/Device stabil nach jedem Reboot? Ich habe 3 USB-Geräte eingesteckt und die wechseln schon mal nach einem Reboot untereinander. Ist das bei Dir nicht so?

André, wenn Michaels Weg bei Dir nicht klappen sollte, funktioniert der VM-Lösung vielleicht bei Dir.

Warum bei mir die VMs reproduzierbar nicht mehr starten, sobald ich eine USB-Gerät in der HW aufnehme (egal, ob per Vendor/Device oder per Port/Device), versteh' ich nicht. Ich neige zu glauben, dass es ein (Treiber?)Problem schon auf Host-Ebene ist. Weil immer mal wieder nach diesen Versuchen funktioniert selbst in der Host-Shell "lsusb" nicht mal mehr und nur ein Node-Reboot zieht das wieder gerade.. Vielleicht fehlt da irgend etwas für Proxmox auf dem recht neuen NUC...?

Um dem auf den Grund zu gehen - vielleicht hat jemand eine Idee, wie ich ein solches Problem auf den Grund gehen kann. Mir liefert strace lsusb einen Trace, der mittendrin einfach aufhört und nicht zum Ende kommt:

[...]
close(7) = 0
openat(AT_FDCWD, "/sys/bus/usb/devices/1-3/speed", O_RDONLY|O_CLOEXEC) = 7
fcntl(7, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat(7, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
read(7, "12\n", 4096) = 3
close(7) = 0
openat(AT_FDCWD, "/sys/bus/usb/devices/1-3/descriptors", O_RDONLY|O_CLOEXEC) = 7
read(7,

Wie findet man in Linux die Ursache für derlei Verhalten?

Nachtrag: Habe mal einen Blick ins BIOS geworfen. Dort hatte ich "USB Legacy" damals aktiviert. Nach dem deaktivieren kann ich der VM nun offenbar zumindest das APC-USB-Geräte hinzufügen und die VM startet damit auch... bei dem 1-wire-Busmaster hängt er wieder... also besser, aber nicht gelöst, gleiches Verhalten bei lsusb wie oben beschrieben... es bleibt die Frage, wie man derlei nach der Ursache erforscht...

[skyacer]

Hi,

also ich habe mir für meine 1-Wire Sensoren eine Vm mit Ubuntu 19.10 eingerichtet und die USB Adapter dann unter Hardware fest eingebunden. Klappt bisher Problemslos bei mir.

[saegefisch]

Das wären ja sehr gute Nachrichten, Michael. Wie bekommst du denn das USB-Gerät in die LXC übergeben? Oder hast Du den owfs auf dem host installiert?

[wintermute]

Beim ESXI lässt sich mein DS9490 auch nicht an eine VM durchreichen...
...wäre ich auch an einer Lösung interessiert, denn dann hätte ich wieder einen PCIe Slot in meinem Server frei.

Ich weiss nicht ob das eine Loesung fuer dich darstellen wuerde, aber ich habe einen DS2490 an einem ESXi seit Jahren problemlos in Betrieb (an einer USB2 Buchse des Mainboards), dahinter haengt (noch) ein CommunityGate das damit arbeitet.

[saegefisch]

die komplette USB PCIe Karte an die VM durchgereicht

Könnte man das nicht auch mit einem USB-onboard Host machen? Will ich gerne mal versuchen, wie hast Du das gemacht in der .conf?

Mein Tagesfazit ist leider recht niederschmetternd:

• Ich weiß wieder, warum ich NUT genommen habe, statt APCUPSD: Die qnaps-NASe gehen nur mit NUT...
  --> bleibt die Frage: Wie kann man NUT ein USB-Device /dev/APC andienen, damit NUT es auch nimmt - APCUPSD kann das doch auch?!?
  --> jemand eine Idee?
• Den 1-wire-Busmaster habe ich auf 100 verschieden Weisen versucht zu übergeben an LXC.

  SUBSYSTEMS=="usb", ATTRS{idVendor}=="04fa", ATTRS{idProduct}=="2490", SYMLINK+="DS2490", MODE="0666", GROUP="owfs"

  schien recht positv, weil

  ls -l /dev/DS2490
  	lrwxrwxrwx 1 root root 15 Dec 21 18:47 DS2490 -> bus/usb/001/005

  gut in den LXC zu bringen war und auf die jeweils richtige BUS/DEV-Kombi verwiesen hat. Nur leider auch hier vermochte ich owfs via owfs.conf nicht, das Device im LXC auch anzudienen.
  --> jemand eine Idee?
• Eigentlich habe ich vorhin auch noch verschwiegen.. mir ging es wie Otto damals.. "da waren sie wieder...meine 3 Probleme..." Denn neben NUT und 1-wire ist wireguard das einzige, was meinem finalen Server-Umzug noch im Wege steht und ich den alten abschalten kann. Wireguard kann wohl auch nicht in LXC...

Aber da kam mir dann doch noch eine wohl möglich gute Idee: Neben den ganzen LXE könnte ich ja ein "echte" VM legen und dort meine 3 "Problemzonen" gesammelt lösen: NUT, 1-Wire, wireguard. Da reicht ja was kleines mit wenig RAM und Platte. Das ist mir allemal lieber, als stattdessen extra HW. Und da soll nach Proxmox-Wiki USB super-easy durchzureichen sein:. Für APC und 1-Wire wäre das nur schön leicht mit Vendor:Product auf der host-shell:

qm set 10020 -usb0 host=051d:0002
qm set 10020 -usb1 host=04fa:2490

bzw. in der conf

nano /etc/pve/qemu-server/10020.conf
usb0: host=051d:0002
usb1: host=04fa:2490

und in der VM ist dann bestimmt alles einfach - wäre vielleicht auch eine Lösung für Dich, André...

Da mach ich doch "kurz mal rasch" meine erste VM in Proxmox - wird ja kein Thema sein, wo LXC so geschmeidig geht. Aber noch eine Pleite: Ich habe auch in 6 Versuchen es nicht geschafft, eine VM mit 20.04-Ubuntu-Server.ISO oder 20.04-minimal.ISO einzurichten, die auch problemlos mehrfach(!) startet, rebootet oder runter fährt, ohne den Node neu zu starten. Es gibt unendliche Probleme..."TASK ERROR: timeout waiting on systemd" oder "TASK ERROR: can't lock file '/var/lock/qemu-server/lock-10020.conf' - got timeout" oder "TASK ERROR: VM quit/powerdown failed" oder oder oder ARGH!, unflushable! Was'n Mist! In seitenlangen Foren lernt man, dass VM offenbar nicht einfach ist mit Proxmox: Besser UEFI-BIOS, besser mit QEMU-Agent, besser ohne Balloning und Daumen drücken - damit wurde es besser, aber nie gut...andere haben derlei Probleme auch. Andererseits schien es ja auch viele doch hinzu bekommen - vielleicht bin ich auch nur zu doof dafür...Und ich dachte 2020 wäre VM einfach...

Nachtrag: Ich war offenbar mit dem USB-Durchreichen nach dem Wiki zu früh/optimistisch: Die VM fahren mit den obigen Parametern recht verlässlich hoch (in Proxmox) und runter (allerdings nur sauber per SSH), das ist schon ok so und auch über mehrere Zyklen. Fügt man aber einen USB-Port mit Vendorevice hinzu, starte die VM nicht mehr.

Nun bin ich dankbar für Antworten auf meine LXC-Frage, aber auch, wie man brauchbar die USB-Geräte in die VM übergeben kann (Proxmox 6.3-3; alle Updates), um das eigentliche USB-Thema dann mal testen und als Lösungsalternative bewerten kann...