yaVDR64 0.5 goes Xen Hypervisor - VDR Server als Hypervisor oder in VM inkl. DVB Karten


  • Zu Intel Mainboards die VT-d unterstützen bin ich letztens über eine interessante Information gestossen, das Intel DB75EN unterstützt lt. Intels eigene Angaben hier ebenfalls VT-d. Das Mainboard ist preislich sehr interessant und ab ca. €71 zu bekommen


    Hallo fnu, wäre es sinnvoll, einen neuen Thread zu VT-D-fähiger attraktiver Hardware anzulegen, wo man Preis-Schnäppchen posten oder sein VT-D-Budget planen kann? Oder gibt's so einen Thread vielleicht schon?


    Viele Grüße
    hepi

  • wäre es sinnvoll, einen neuen Thread zu VT-D-fähiger attraktiver Hardware anzulegen, wo man Preis-Schnäppchen posten oder sein VT-D-Budget planen kann?


    Hmm, so richtig preiswert ist das halt gar nicht, selbst AMD Hardware nicht. Eine passende VT-d CPU zum "preiswerteren" DB75EN kostet halt immer noch €170 ... :S


    Aber ja, das könnte man wirklich mal angehen, weil man sucht sich echt den Wolf nach Infos welche HW das kann oder nicht. Intels o.a. Übersicht ist echt gut, bezieht sich nur auf Desktop Mainboards, spart aber passende CPUs völlig aus. Von AMD finde ich sowas irgendwie gar nicht ...


    Ein eigenen Thread finde ich gut, aber eher mit dem Ziel Information zentral zu sammeln. Schnäppchen gibt es in dem Bereich eh nicht wirklich ... ^^


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Die englische Wikipedia spuckt eine (kleine) Übersicht aus: http://en.wikipedia.org/wiki/IOMMU_hardware_list#Chipset


    Als Anfang evtl. brauchbar...?


    cu
    Markus

  • Bei mir läuft dieses Mainboard mit vollster Unterstützung.


    MSI Z68A-G43(G3) Mainboard Sockel 1155 (Intel Z68 (B3)


    dazu folgende CPU



    Intel(R) Xeon(R) CPU E31225 @ 3.10GHz


    Gruß
    ochja

    ------------------------------------------------------------------------------------------------------------------------------------------------------------
    VDR1: M4N78-VM:AMD XII 215e:Tevii S470PCIe: yaVDR 0.5a
    VDR Neu: Q1900M, Cine S2: yavdr 0.6
    VDR Server: Debian testing Dom0 XEN 4.6, Tevii S470 PCIe running in HVM Trusty DomU

  • Bei mir läuft dieses Mainboard mit vollster Unterstützung.


    MSI Z68A-G43(G3) Mainboard Sockel 1155 (Intel Z68 (B3)


    Mit welcher CPU?


    cu
    Markus

  • dank integrierter Grafik ist das System dazu noch sehr sparsam (läuft als Server ja immerhin 24/7)


    Gruß
    ochja

    ------------------------------------------------------------------------------------------------------------------------------------------------------------
    VDR1: M4N78-VM:AMD XII 215e:Tevii S470PCIe: yaVDR 0.5a
    VDR Neu: Q1900M, Cine S2: yavdr 0.6
    VDR Server: Debian testing Dom0 XEN 4.6, Tevii S470 PCIe running in HVM Trusty DomU

  • Mit welcher CPU?


    cu
    Markus


    model name : Intel(R) Xeon(R) CPU E31225 @ 3.10GHz

    ------------------------------------------------------------------------------------------------------------------------------------------------------------
    VDR1: M4N78-VM:AMD XII 215e:Tevii S470PCIe: yaVDR 0.5a
    VDR Neu: Q1900M, Cine S2: yavdr 0.6
    VDR Server: Debian testing Dom0 XEN 4.6, Tevii S470 PCIe running in HVM Trusty DomU

  • Ein eigenen Thread finde ich gut, aber eher mit dem Ziel Information zentral zu sammeln.


    mahlzeit & ochja


    Eure Punkte würden sich in einem eigenen Thread sehr gut machen, nur anfangen müßte halt mal jemand, danke ... :arme


    Regards
    fnu

    HowTo: APT pinning

  • Hier fand ich den Hinweis, das auf dem Client per grub folgendes übergeben werden sollte:


    Code
    ...GRUB_CMDLINE_LINUX="iommu=soft swiotlb=force console=hvc0"...


    Also iommu & swiotlb, das Verhalten war aber beim Ubuntu Client mit und ohne das gleiche, schaden tuts aber wohl auch nicht.


    => Diese CMDLINE Parameter müssen unbedingt übergeben werden, wenn die zu virtualisierende DVB Karte ihre Firmware aus einer Datei bezieht. DomU nach erstmaliger Änderung unbedingt "ausschalten", reboot endet vmtl. in Kernel-OOPS.
    => Evtl. kann es hilfreich sein "pci=nomsi" zusätzlich zu übergeben.

    @all


    Hatte mal wieder Lust zum Spielen und zitiere mich dazu mal selbst. Ich habe die L4M Twin S2 V6 ausgebaut und eine V5.5 in meine Xen Testmaschine eingebaut. Im Gegensatz zur V6.x laden alle V5.x ihre Firmware aus einer Datei. Bei der V6 war es unerheblich ob die o.a. Kernelparameter in der Ubuntu PV übergeben werden, bei der V5 ist es zwingend erforderlich.


    Weiter kann es sein hier einem Hinweis von "UFO" zu folgen und zusätzlich "pci=nomsi" zu übergeben, bei meinem Q67 Mainboard war es nicht nötig. Aber es war notwendig die PV einmal komplett zu deaktivieren, erst danach funktioniert das Laden der Firmware Datei ohne Kernel OOPS. Anschließend sollte man das so in der virtuellen Maschine vorfinden, zur Erinnerung alles ohne VT-d:


    Code
    vdr@vdrserv:~$ sudo lspci -v00:00.0 Multimedia video controller: Micronas Semiconductor Holding AG nGene PCI-Express Multimedia Controller (rev 01)        Subsystem: Micronas Semiconductor Holding AG Device dd00        Flags: bus master, fast devsel, latency 0, IRQ 28        Memory at fbb10000 (32-bit, non-prefetchable) [size=64K]        Memory at fbb00000 (64-bit, non-prefetchable) [size=64K]        Capabilities: [40] Power Management version 2        Capabilities: [48] MSI: Enable+ Count=1/1 Maskable- 64bit+        Capabilities: [58] Express Endpoint, MSI 00        Capabilities: [100] Device Serial Number 00-00-00-00-00-00-00-00        Capabilities: [400] Virtual Channel        Kernel driver in use: ngene        Kernel modules: ngene...vdr@vdrserv:~$ dmesg | grep ngene[    2.673678] ngene 0000:00:00.0: enabling device (0000 -> 0002)[    2.673800] ngene 0000:00:00.0: Xen PCI mapped GSI16 to IRQ27[    2.673816] ngene: Found Linux4Media cineS2 DVB-S2 Twin Tuner (v5)[    2.676119] ngene 0000:00:00.0: setting latency timer to 64[    2.676226] ngene: Device version 1[    3.312580] ngene: Loading firmware file ngene_18.fw....vdr@vdrserv:~$ ll /dev/dvb/*/dev/dvb/adapter0:total 0drwxr-xr-x 2 root root     120 Jan  4 16:43 ./drwxr-xr-x 4 root root      80 Jan  4 16:43 ../crw-rw---- 1 root video 212, 1 Jan  4 16:43 demux0crw-rw---- 1 root video 212, 2 Jan  4 16:43 dvr0crw-rw---- 1 root video 212, 0 Jan  4 16:43 frontend0crw-rw---- 1 root video 212, 3 Jan  4 16:43 net0/dev/dvb/adapter1:total 0drwxr-xr-x 2 root root     120 Jan  4 16:43 ./drwxr-xr-x 4 root root      80 Jan  4 16:43 ../crw-rw---- 1 root video 212, 5 Jan  4 16:43 demux0crw-rw---- 1 root video 212, 6 Jan  4 16:43 dvr0crw-rw---- 1 root video 212, 4 Jan  4 16:43 frontend0crw-rw---- 1 root video 212, 7 Jan  4 16:43 net0


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • fnu


    Mal eine Frage zu XEN Hypervisor. Kann man nach der Installation von XEN Hypervisor es über das WI erreichen und braucht man da auch da ein Client Tool so wie bei VMware ESXi 5.1 oder geht es auch ohne. Da ich keine Windows mehr am laufen habe nur in der VM suche ich ein Virtualisierung Programm wo ich ohne zusätzlichen Windows Tool mit Linux Mint zugreifen kann um VM's zu erstellen und auch zu verwalten. Oder gibt es ein Linux Client Tool für VMware ESXi 5.1


    MfG

    VDR1 | MLD 5.4 64Bit Stable | ASRock Q1900M | 4GB Ram | Intel VA-API | Digital Devices DuoFlex DVB-S2 | SSD 64GB

    MLD 5.1 Server | Banana Pi | Fhem |

    Test VDR: MLD 5.4 64Bit Unstable | ASRock Q1900M | 4GB RAM | Intel VA-API | OctopusNet S2-2

  • mafe68


    OpenSource Xen hat kein GUI, nur cmdline "xm" bzw. neu "xl". Von Citrix gibt es ein Windows GUI für deren Xen-Server, ähnlich VMWare VShere Client, ist aber IMHO nicht gut nutzbar in der o.a. Konstellation, obwohl oft empfohlen.


    Daher verwende ich "virt-manager", das ist kein Windows Tool, sondern ein Linux-Tool. Das nutze ich auf Linux- als auch Windows-Desktops, da per Xming, einer sehr guten Xserver Umsetzung für Win. Schau mal weiter oben gibt es ein paar Screenshots.


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • hi,


    da gibt es viele Wege ....
    zum erzeugen/installieren von DomU
    - xen-create-image
    - virsh / virt-install
    - virt-manager
    ....
    zum verwalten
    - xm oder xl / virt-manager
    ....


    Gruß
    ochja

    ------------------------------------------------------------------------------------------------------------------------------------------------------------
    VDR1: M4N78-VM:AMD XII 215e:Tevii S470PCIe: yaVDR 0.5a
    VDR Neu: Q1900M, Cine S2: yavdr 0.6
    VDR Server: Debian testing Dom0 XEN 4.6, Tevii S470 PCIe running in HVM Trusty DomU

  • fnu


    Danke schon mal für deine Info! Das werde ich mir gleich mal ansehen, bin schon länger am suchen zu einer alternative zu den Win Tool das vernünftig läuft.


    MfG

    VDR1 | MLD 5.4 64Bit Stable | ASRock Q1900M | 4GB Ram | Intel VA-API | Digital Devices DuoFlex DVB-S2 | SSD 64GB

    MLD 5.1 Server | Banana Pi | Fhem |

    Test VDR: MLD 5.4 64Bit Unstable | ASRock Q1900M | 4GB RAM | Intel VA-API | OctopusNet S2-2

  • mafe68


    "virt-manager" ist kein Remote-GUI wie das von VMWare oder Citrix, sondern wird auf der Dom0 aufgerufen und eben per X umgelenkt ...


    Regards
    fnu

    HowTo: APT pinning

  • Schaue mir gerade bei ubuntuusers die Anleitung an und was alles man machen kann damit.

    VDR1 | MLD 5.4 64Bit Stable | ASRock Q1900M | 4GB Ram | Intel VA-API | Digital Devices DuoFlex DVB-S2 | SSD 64GB

    MLD 5.1 Server | Banana Pi | Fhem |

    Test VDR: MLD 5.4 64Bit Unstable | ASRock Q1900M | 4GB RAM | Intel VA-API | OctopusNet S2-2

  • fnu


    natürlich geht virt-manager auch remote . :]


    Gruß
    ochja

    ------------------------------------------------------------------------------------------------------------------------------------------------------------
    VDR1: M4N78-VM:AMD XII 215e:Tevii S470PCIe: yaVDR 0.5a
    VDR Neu: Q1900M, Cine S2: yavdr 0.6
    VDR Server: Debian testing Dom0 XEN 4.6, Tevii S470 PCIe running in HVM Trusty DomU

  • natürlich geht virt-manager auch remote . :]


    Hast ja Recht, ich ruf's nur immer per X-Umlenkung auf, weil's dann da liegt wo es für mich hingehört ... 8)

    HowTo: APT pinning

  • So, habe mir mal wieder Zeit genommen, mich mit dem Server zu befassen. Aufgrund einiger HW Änderungen, u.a. neues Mainboard, habe ich die Maschine neu aufgesetzt. Die Installation des Hypervisors und 3 Ubuntu PVs war in knapp 45min erledigt, allerdings gab es ein paar offen Punkte die ich klären wollte:

    • Der Quantal Kernel 3.5.0 läuft ohne Problem als Xen Hypervisor 4.1.2. Ein kleine Abweichung zum Precise Kernel 3.2.0 gibt es, es ist nötig das Kernel-Modul für die L4M DVB Karten auf dem Hypervisor zu blacklist'en, wenn man diese an eine PV weitergeben möchte, je nachdem ob yaVDR den Hypervisor gibt oder nicht:


      Code
      #/> cat /etc/modprobe.d/blacklist-xen.confblacklist ddbridgeblacklist ngene


    • Xen 4.2 für Ubuntu ist zu sehen, "am Horizont", ab 13.04 (Raring Ringtail). Aber, den Kernel wird es wohl als Backport in Precise geben, vorr. nicht aber Xen 4.2, leider.
    • Ein weiter Punkt sind die vom mir weiter oben beschriebenen Netzwerkprobleme bei Verwendung der HVM-to-PV Treiber GPLPV von Univention in einer Windows HVM, der Durchsatz war mehr als lausig. Dazu fand ich bei der c't einen Hinweis, die Einstellungen wie beschrieben im Device-Manager umsetzen und das Netzwerk ist schnell, subjektiv tatsächlich etwas besser als die Intel Emulation. Man kann nun einem Windows Client dieses als NIC Definiton mitgeben:


      Code
      ...vif = [ 'bridge=xenbr0, type=paravirtualised' ]...


    • Der nächste Punkt war eine besonderes Ärgernis, wenn bei einem "dist-upgrade" in einer Ubuntu PV eine neuer Kernel kam, weigerte sich "pygrub" diese zu starten. Es gibt unterschiedliche Hinweise wie man das lösen kann, aber die Ursache liegt hier bei "grub2", dessen dynamische Scripts "pygrub" aus dem Tritt bringen. Raring Ringtail startet z.B. gleich gar überhaupt nicht nach Installation mittels "pygrub", die Scripte werden hier noch komplexer. Meine Lösung ist und die einiger anderer auch, man stellt eben wieder auf "grub-legacy" um. Hier fehlt natürlich das dynamische Anpassen des Bootloaders, wer braucht das aber schon in einer virtuellen Maschine, dafür ist ein Kernel-Update kein Problem mehr, da "grub-legacy" relativ statisch arbeitet und "pygrub" nicht aus dem Tritt bringt. Nach der Netzwerk-Installation wenn die PV sich abgeschaltet hat, vor dem ersten Boot:


      Code
      #/> fdisk -lu /dev/vg00/raring => den Offset der Root-Partition feststellen, bei mir immer 2048.Disk /dev/vg00/raring: 10.7 GB, 10737418240 bytes255 Köpfe, 63 Sektoren/Spur, 1305 Zylinder, zusammen 20971520 SektorenEinheiten = Sektoren von 1 × 512 = 512 BytesSector size (logical/physical): 512 bytes / 512 bytesI/O size (minimum/optimal): 512 bytes / 512 bytesFestplattenidentifikation: 0x0009c50d           Gerät  boot.     Anfang        Ende     Blöcke   Id  System/dev/vg00/raring1            2048    18860031     9428992   83  Linux/dev/vg00/raring2        18862078    20969471     1053697    5  Erweiterte/dev/vg00/raring5        18862080    20969471     1053696   82  Linux Swap / Solaris


      Offset berechnen, 2048*512=1048576 und die virtuelle Platte montieren:


      Code
      #/> mount /dev/vg00/raring /mnt -o loop,offset=1048576#/> chroot /mnt#/> for i in /proc /sys /dev /run; do mount $i; done#/> mkdir /run/resolvconf#/> touch /run/resolvconf/resolv.conf#/> mkdir /run/lock#/> echo "nameserver 192.168.xxx.yyy" > /run/resolvconf/resolv.conf#/> aptitude -y purge grub2 grub-pc grub2-common && aptitude install grub#/> mkdir /boot/grub#/> update-grub#/> for i in /proc /sys /dev /run; do umount $i; done#/> exit#/> umount /mnt


      Maschine Xen zu hinzufügen und mittels "pygrub" starten lassen.


      Achtung: Alle Änderungen erfolgen nun nicht mehr in "/etc/default/grub" sondern wie von früher bekannt in "/boot/grub/menu.lst", daher nach dem ersten Start folgende Zeile anpassen:

      Code
      #/> sudo vi /boot/grub/menu.lst...# defoptions=iommu=soft swiotlb=force console=hvc0...#/> sudo update-grub

    Regards
    fnu

    HowTo: APT pinning

    7 Mal editiert, zuletzt von fnu ()

  • Hallo,
    ich habe ein frage bezüglich der Hardware, da ich meinen alten CT-server (mit virtualisiertem CT-VDR) auflösen und einen neuen Server aufbauen möchte.
    Wie sieht es denn mit den Interrupts aus? Bei meiner alten Hardware (GA-M720US3 mit AMD Athlon 4450e) musste ich immer darauf achten dass die in die DomU hereingereichten PCI Karten nicht einen IRQ mit anderen Karten teilten. Mit den PCIe Karten gab es irgendwie immer Ärger da sie immer mit anderen Geräten auf einem IRQ lagen. Bei den neuen Boards mit H77 bzw. Z77 Chipsatz ist immer wieder die Rede von IRQ remapping, funktioniert dies zuverlässig unter XEN? Brauche ich nicht mehr darauf zu achten wie die IRQ verteilung auf dem Mainboard ist?


    fnu: Betreibst Du jetzt den VDR virtualisiert oder in der dom0? Weil in einem vorherigen Beitrag vom Durchreichen der TV-Karten sprichts.


    Bis jetzt läuft bei mir auf dem Testsystem (alter CT-Server) der yaVDR als PV mit zwei durchgereichten Technotrend DVB-C Karten. Zur Stabilität kann ich leider noch nichts sagen.
    Ziel ist es ein virtualisierter yaVDR (mit durchgereichter Cine S2 V6.5 oder Octopuss miniPCIe Bridge) ein virtualisiertes NAS (mit durchgereichter NIC ) und eine virtuelle DMZ als Webserver (mit durchgereichter NIC ) ans laufen zu bekommen. Dazu wollte ich mir ein neues Board +CPU zulegen um evtl. den IRQ Problemen aus dem Weg zu gehen. Bei der Boardauswahl bin ich noch etwas hin und hergerissen. Die Entscheidung fällt dann zwischen dem Intel DH77KC (wie es FNU betreibt), dem DZ77BH-66K oder einem ASUS P8Z77-V LX. In Kombination mit einem Core i5-3570T bzw. erst testweise mit einem vorhanden Core i3-2120.


    Hoffe ihr könnt mir noch ein paar Tips zu den Mainboards geben.


    Viele Grüße


    JoeBar

Jetzt mitmachen!

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