Posts by mahlzeit

    Lass es mich anders sagen: Warum sollte die Netzwerkkarte noch in Betrieb sein, wenn WOL deaktiviert ist? Das was im BIOS eingestellt ist, muss zwangsläufig nicht mehr aktiv sein, nachdem ein OS mal an der Karte war. Ich würde es mal versuchen. Ich wüsste sonst keinen Grund, warum die Karte noch aktiv sein sollte.


    Edith meint, der Befehl lautet

    Code
    1. ethtool -s eth0 wol d

    Damit gibt es kein lauschendes Ohr mehr auf dem Kabel und damit auch keine aktive Netzwerkkarte mehr.


    cu
    Markus

    Ich habe 2 Systeme:
    Intel Board BOXDH67BLB3 mit und eine Intel I5 1155


    Etwas genauer, Intel i5 auf Sockel 1155 gibt es massig, nicht alle können auch vt-d ;)


    Quote

    hier zeigt mir dmesg an, dass ich "gar nichts" habe.


    Vermutlich weil der Prozessor es nicht kann oder es im BIOS deaktiviert ist.



    Kunststück, der Chipsatz unterstützt noch kein IOMMU. Ab der AMD 900er Serie wäre wohl was dabei. (http://de.wikipedia.org/wiki/AMD-900-Serie). Der Prozessor sollte es wohl können (http://products.amd.com/en-us/DesktopCPUDetail.aspx?id=772&f1=AMD+FX+6-Core+Black+Edition&f2=FX+6100&f3=3300&f4=1024&f5=AM3%2b&f6=&f7=32nm&f8=95+W&f9=5200&f10=False&f11=False&f12=True). Auch wenn AMD da selbst etwas wenig dazu schreibt. Da finde ich die Übersicht bei Intel zu den Prozessoren aussagekräftiger.


    cu
    Markus

    Kann der Core i5 (und das Mainboard) denn vt-d? Ohne das geht es nicht! Nur Xen kann ohne vt-d in eine paravirtualisierte VM Hardware durchreichen! Proxmox basiert auf kvm.


    Nach der Änderung an /etc/default/grub hast Du auch die Konfigurationsdatei für grub neu generiert (vor dem Reboot)?


    Hier nochmal der Auszug aus der Proxmox-Seite:


    Der output des letzten Kommandos aus der Anleitung sieht bei mir dann so aus:

    Ich nutze eigentlich virtualbox unter Linux Debian und bin damit bisher sehr zufrieden - bis auf die Tatsache mit dem vdr.


    Virtualbox kann imho ja nur USB, daher der Kauf der USB Hardware. Aber vermutlich klappt das mehr schlecht als recht, evtl. wird nur USB 1.0 statt USB 2.0 "zur Verfügung gestellt" (was ja für die Klötzchen sprechen würde, die Bandbreite von USB 1.0 reicht da nicht aus)?

    Quote

    Die von dir beschrieben Vorgehensweise war mir mehr oder weniger bekannt (Module im Host dürfen nicht geladen sein, PCI Passtrough etc).
    Ich hatte mir sogar extra eine 2. AMD Maschine angeschafft - weil mein Intel Systme auf jeden Fall kein IOMMU beherrscht.
    Wobei das AMD Board kein VT-d / iommu kann - wenigstens sehe ich nichts davon in dmesg).
    Mit Xen und Centos hatte ich auch rumgespielt ...hat aber nicht geklappt - bin lieber auf Debian unterwegs.


    Evtl. muss der Kernel noch angepasst werden. Bei AMD ist auch der Parameter für grub anders: "iommu=pt iommu=1".
    Die Seite hier kennst Du schon? http://www.linux-kvm.org/page/…_devices_with_VT-d_in_KVM Da steht zumindest was zur Kernelkonfiguration mit drauf. Oder versuch doch einfach mal Proxmox, Installieren (Änderungen in Grub nach der Installation machen, Reboot), Weboberfläche aufrufen, VM konfigurieren (für die Durchreichgeschichte musst Du aber auf die Shell, im Verzeichnis /etc/pve/qemu-server liegen die Konfigurationsdateien) und los gehts. Hat bei mir keine 20 Minuten gedauert, bis die erste VM soweit war.


    Quote

    Seufz... kannst du mir passende HW empfehlen (Mainboard vor allem - die AMD CPU ist noch recht jung)


    Leider nein, ich habe nur Intel-Hardware. Da nutze ich das MSI Z68MA-G43 (G3) (MS-7676) zusammen mit einem Core i7-3770.


    cu
    Markus

    Ach ja, wie schnoefftel schon angemerkt hat, das Ganze ist dann aktuell nur als headless Server zu gebrauchen, Grafikkarten in eine VM durchreichen funktioniert noch nicht wirklich gut. Aber dafür hat man dann z.B. ein Raspberry Pi oder ein sparsames ION2 Board nebst schicken kleinem Gehäuse als Client.


    Vielleicht spezifizierst Du noch einmal etwas genauer, was Du eigentlich konkret vorhast. Daraufhin kann man auch gezielter Tips geben.


    cu
    Markus

    Servus,


    im Prinzip brauchst Du nur[tm] passende Hardware (d.h. Mainboard und Prozessor mit vt-d) und passende Software (z.B. Xen, kvm). Bei Xen ist es sogar möglich, ohne vt-d die Hardware in ein Linux zu bekommen. Spätestens bei was anderem brauchts aber zwingend vt-d. Hier im Portal gibt es den einen oder anderen Thread dazu, oben rechts ist ein Suchfeld. "virtualisierung" sollte zu den passenden Threads führen.


    Ich selbst nutze Proxmox (vorkonfiguriertes Debian mit kvm als Hypervisor) und reiche damit eine DD Cine S2 nebst Erweiterungsmodul an ein vollständig virtualisiertes yavdr durch. Funktioniert hier problemlos seit Februar. Mainboard und CPU können vt-d, damit ist es mit einer Bootoption der Dom0 und einer Zeile in der VM Konfiguration getan.
    In /etc/default/grub wird bei der Variablen "GRUB_CMDLINE_LINUX_DEFAULT" ein "intel_iommu=on" ergänzt und grub mit grub-mkconfig übernommen (Reboot notwendig). in der VM-Konfiguration ist die Zeile "hostpci0: 02:00.0" zu ergänzen. Das "02:00.0" bezeichnet dabei das PCI(e) Device, welches man mittels lspci herausbekommt. In diesem Fall ist das die "02:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter". Wichtig: Auf der Dom0 darf für diese Hardware (oder für andere, durchzureichende Hardware) kein Modul geladen sein. Das ist in der /etc/modprobe.d/blacklist zu deaktivieren.


    Ich hatte in der Zeit seit Februar zwei "Hänger" der durchgereichten Hardware, aber mit dem hier beschriebenen Vorgehen konnte ich das ohne Reboot bereinigen. Ist schon ewig nicht mehr aufgetreten, der Server und die VMs laufen aber 24/7 durch.


    cu
    Markus

    Servus,


    an der Problemlösung wäre ich auch interessiert, zwischen den Aufnahmen könnte ich auch mal testen. Kann zwar einigermaßen Programmieren, aber mit C/C++ und den VDR Gegebenheiten habe ich mich noch nicht auseinandergesetzt-


    cu
    Markus

    Ein Restart des vdr service behebt das Problem dann vorerst.
    Im Einsatz habe ich yaVDR 0.5 stable mit "L4M-Twin S2 ver 6.2 + Flex". Das Ganze läuft als headless auf Proxmox 3.1 (das ganze lief nun seit Anfang des Jahres stabil ohne Probleme).


    Bevor nun aber das große Rätselraten beginnt, würde ich gerne über das
    Logging des dynamite prüfen, ob die devices überhaupt aufgeweckt werden! Daher bin ich über jede Hilfestellung dankbar, wie ich das Logging des dynamite plugins erweitern kann


    Servus,


    da schließe ich mich an, ich habe ein ähnliches Setup (ebenfalls auf Proxmox) und ab und an kann ich einzelne Kanäle nicht mehr streamen. Aufnahmen laufen aktuell nicht so viele, da ist es mir aber auch schon mal aufgefallen.


    Die "Probleme" fingen auch damit an, als ich das dynamite Plugin verwendet habe, um die L4M in den Schlaf zu schicken. Es ist zwar "nur" sporadisch, aber der WAF sinkt schon etwas... ?(


    cu
    Markus

    ich glaube Mahlzeit hat dein Vorhaben ein bisschen falsch verstanden...


    Das glaube ich nicht: "Ein leiser (muss in einem kleinen Kämmerchen im Wohnbereich stehen) PC mit 6? DVB-C Karten". Als Alternative war das mit dem Netceiver mal angedacht. Also stimmte meine Antwort schon... ;)


    Aber ich sehe auch, dass der Windows 2013 Server eher überflüssig ist. XEN/KVM mit PCI Passthrough an die VDR-VM und einer NAS VM mit direkt durchgereichten Platten (und/oder COntroller, falls es RAID ist). wäre flexibler, günstiger (Server 2013 für Privat, wer zahlt das denn?) und trifft den Kern der Sache.


    Die Geschichte mit den Sundtek Sticks hat zwar auch seine Reiz, aber da ist dann, soweit ich das verstanden habe, wieder jeder Stick exklusiv einem Client zugeteilt. Ein VDR mit streamdev-server kann aus weniger Karten/Sticks da deutlich mehr rausholen, was das parallele Streamen/Aufnehmen angeht.


    cu
    Markus

    - Ein leiser (muss in einem kleinen Kämmerchen im Wohnbereich stehen) PC mit 6? DVB-C Karten. Es sollen 4 HTPCs mit live TV versorgt werden und zusätzlich 2 parallele Aufnahmen möglich sein.
    - Auf meinem Selbstbau-NAS (Win2013 Server) eine Virtuelle Maschine mit der VDR-Software zum aufnehmen.


    Servus,


    erst mal herzlich Willkommen hier!


    Zum Thema, bedenke, dass Du die Hardware (DVB-C Karten) zur VM durchreichen musst (PCI Passthrough). Dass ist nicht mit jeder Virtualisierungslösung und schon gar nicht mit jedem Mainboard/CPU möglich. Hier im Board gibt es einige Diskussionen dazu, die Suche findet die passenden Threads. Inwieweit dass allerdings mit einem Server 2013 so einfach geht...


    cu
    markus

    Ich stand damals auch vor der Wahl und habe mich aus Preisgründen gegen einen Xeon und für einen Core i7 2600 entschieden. Hab ich damals bei Ebay Kleinanzeigen(! nicht die Auktionsplattform) günstig erstanden, mit Nachverhandeln (weil das Angebot schon seit knapp 3 Wochen stand) und Porto um die 140€ inkl. Kühler.Muss man halt Glück haben und grad einer im Angebot sein. Die CPU im Server wurde mittlerweie von einem Core i7 3770 abgelöst (IIRC 160€, auch bei Ebay Kleinanzeigen), der 2600 steckt noch in meiner Arbeitskiste.

    Meines Wissens nach hat nur XEN die Möglichkeit, Hardware ohne vt-d in eine VM durchzureichen. Bei KVM muss Board und CPU vt_d unterstützen. Dann klappt es aber wunderbar, ich habe dieses Setup nun seit Februar "produktiv" (=Server steht mit DVB-S Karten im Keller, Frau schaut im Wohnzimmer und im Schlafzimmer mit Streaming Client) im Einsatz. Dom-0 ist Proxmox mit KVM.


    Vor Jahren hatte ich schon unter XEN 4 PCI DVB-S Karten in eine Linux-VM durchgereicht, damals war es aber noch etwas wackelig (So um 2006 rum).


    Virtualisierung an sich klappt auch ohne vt-d (dann ohne Hardwarezugriff) bzw. vt-x (dann ohne Beschleunigung, d.h. die CPU der VM wird komplett emuliert, was halt je nach Hypervisor mehr oder weniger auf die Leistung geht).


    cu
    Markus

    Hast du den VDR neu gestartet? Das Hook-System bei den etobi- bzw. yaVDR-Paketen baut die reccmds ja immer beim Start des VDR aus den einzelnen Dateien zusammen.


    Das sollte nicht nötig sein, da 1. das nicht in den reccmds steht und 2. das Skript /usr/lib/vdr/vdr-recordingaction, welches die Recording-Hooks startet, bei jedem Aufruf (aka Begin, Ende oder Edit der Aufnahme) im Verzeichnis /usr/share/vdr/recording-hooks nach ausführbaren(!) Skripten sucht. Bei meiner yavdr-Installation z.B. fehlt das Execution Bit, also mach mal ein

    Code
    1. chmod +x /etc/vdr/recording-hooks/R90.custom

    und teste noch einmal.


    cu
    Markus


    EDITH sagt: Nach einem kurzen Test bei mir funktioniert es im "Auslieferungszustand" (also ohne Execution Bit) nicht, nach Änderung mittels oben genannten Befehl wird der Recording-Hook dann gestartet. Ganz ohne VDR Neustart. Ein Bug in yaVDR ;)