[GELÖST] ESXI yavdr-headless keine intakte Aufnahme mit SatIP/Unicast

  • Hi Gemeinde,


    ich bin mit meinem Server-Geraffel kürzlich ja umgezogen und nutze seitdem yavdr-ansible als headless in ESXI 7.0u3 als virtuelle Maschine.

    Funktioniert soweit, aaaaber:


    In der VM läuft wie vorher auch SatIP. Seit der Umstellung ist KEINE Aufnahme mit der Einstellung Unicast in Ordnung! Jede Aufnahme hat im 2-Sekunden-Takt Artefakte/Klötzchen/Audiohänger. Nur die Plugin-Einstellung RTP-over-TCP liefert intakte Aufnahmen...


    Gibt es unter Euch jemanden der mich aufklären kann woran das liegt und wie (ob) man das beheben kann?

    Kann/muß ich in ESXI ggflls. Netzwerktechnisch etwas nachjustieren?


    [GRUND UND LÖSUNG]: Beitrag #14

    Einmal editiert, zuletzt von Taipan ()

  • Oje, wenn's tatsächlich Netzwerk-Probleme sind, kann es dauern bis man was findet ...


    Fangen wir mal bei der Netzwerk Emulation der VM an? E1000 oder vmnetX? Ich nutze wann immer es geht "vmnetX" ... ist ja heute Standard in den Linux-Kernels drin.


    Hast Du innerhalb der VM in Ubuntu das Paket "open-vm-tools" installiert?


    Wie hast Du das virtuelle Netzwerk in ESXi aufgesetzt? Hast ja 2 Anschlüße? Beide genutzt? Welchen Modus eingestellt?

    HowTo: APT pinning

  • Hi Frank,


    ich habe "vm network" aktiv und "VMXNET3" als Adaptertyp (default). VM-Tools ist in Ubuntu installiert und beide Netzwerkkarten laufen (connected). Geschwindigkeits-Modus steht mit MTU 1500 bei beiden auf "autom. aushandeln" und im vswitch0 sind beide NICs als uplinks vorhanden...

  • BTW: was mich etwas wundert, ist die "Regelmäßigkeit" der Störungen im 2 Sekundentakt...

  • Ok, Sven,


    "open-vm-tools" ist am Ende wichtig für die Kommunikation ESXi zu VM und das Memory-Ballooning.


    Ich frag jetzt einfach mal weiter, Memory hat die VM genug? 2GB bis 4GB sollten immer reichen für Headless ...


    Anzahl virtuelle CPUs? wobei 2 immer gut genug sind für Multithread, Rest macht der Hypervisor ...


    Storage Emulation? IDE, SATA, SCSI oder NVMe? VMDK thin provisioned?

    HowTo: APT pinning

  • Die VM läuft mit 8GB Speicher und 2CPUs. Die Systemplatte hat 128GB mit Thin Provisioning bereitgestellt über SCSI (default bei der Installation von Ubuntu 64bit)

  • Und die Datenplatte wo die Aufnahmen rein laufen?

    HowTo: APT pinning

  • Ebenfalls als *.vmdk auf dem 2ten Raid1 mit 3,7TB und mit Thin Provisioning bereitgestellt, träge nullgesetzt...

  • träge nullgesetzt...

    Ok, das ist IIRC Standard-Einstellung, also keine Effekte aus einer dynamischen Vergrösserung der VMDK. Wie auch sonst alles im Prinzip Default Settings sind ...


    Mal einen einfach Test? Zieh mal das Ethernet-Kabel am Anschluß 2 ab oder konfiguriere den Doppelanschluß als Failover (active/standby) ... und schau mal ob sich was verbessert.

    HowTo: APT pinning

  • Habe ich eben gemacht und bei deaktiviertem LAN2 ist die Aufnahme fehlerhaft - anders herum (LAN1 aus) dito...

  • Ok, oje, wenn dieser Fehler aus dem Netzwerk kommt ... wird das ein langer Lösungsgang ... 🙈


    Ein Punkt habe ich vergessen zu fragen, welche SCSI Emulation in der VM? Und welches Dateisystem auf der Datenplatte?


    Ich bin irgendwie gefühlt immer noch eher so biss'le an der IO Konfiguration. Selbst habe ich immer versucht möglichst "pvscsi" zu nutzen, extra ISO Images generiert, damit ich bei Windows VMs ab Installation "injecten" kann.


    Seit ESXi "NVMe" bietet nutze ich das, muss man sich nicht mehr mit irgendwelchen Treibern rumschlagen, können alle einigermaßen aktuellen OSes.

    HowTo: APT pinning

  • Eigentlich ist das ja ein Witz an Datenströmchen der für einen DVB Aufnahme reinläuft und anfällt ... das sollte selbst mit der "lausigsten" Konfiguration kein Problem sein.


    Die Frage ist wo wird der Fehler erzeugt, beim Anlegen und Erzeugen der Aufnahme (vdr, Dateisystem) oder kommt der Datenstrom schon fehlerhaft rein (Netzwerk, Quelle) ... Sender ist egal?

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Ich habe mal zumindest für die Datenplatten auf NVME-Controller geändert und teste damit. Die Platten sind mit ext4 formatiert...

  • Hi,

    nach den ganzen Versuchen hatte ich alles wieder rückgängig gemacht, am Server RTP-over-TCP eingestellt und es laufen lassen. Heute habe ich meine USV von der yavdr-Server-VM weggenommen und in die VM eingebunden auf der minisatip läuft...


    Ergebnis - ich habe den Pixelfehler "mitgenommen" und prompt auch im Livebild im Wohnzimmer gehabt!

    Noch ist die USV aktiv aber die USB-Verbindung zu den VM's ist getrennt und damit läuft jetzt überall "Sat>IP/Unicast".

    Es scheint also nicht die USV an sich zu sein, sondern die Überwachung per NUT und/oder dem damit verbundenen USB-Treiber "blazer_usb"...


    Ich werde die USV-Überwachung später in der Windows-VM nutzen um sie von allem was mit TV zutun hat abzutrennen und trotzdem die Überwachung zu haben...


    BTW: Es handelt sich übrigens um dieses Prachtstück und eingebunden hatte ich es "lauffähig" nach dieser Anleitung...

    Einmal editiert, zuletzt von Taipan ()

  • Nachtrag:


    Ich habe nun eine Windows-VM genutzt in der ich das offizielle Überwachungstool zur GreenCell 600VA installiert habe. Innerhalb der Software kann man eigene Programme bei unterschiedlichen Stadien der USV ausführen lassen. Bei niedrigem Batteriestand wird über das Programm "plink.exe" (Bestandteil des Putty-Pakets) eine ssh-Verbindung zu ESXI hergestellt und der shutdown eingeleitet (erst VM's und dann der Host)...


    Code
    C:\Program Files\PuTTY\plink.exe -ssh -2 -pw PASSWORT root@192.168.x.x "/sbin/shutdown.sh && /sbin/poweroff"

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!