ich empfehle als Hostsystem Lenny
http://www.howtoforge.com/virt…xen-on-debian-lenny-amd64
http://www.errorsystem.de/arti…lisierter-homeserver.html
etc .........
Xen 3.3(4) sollte einfach mit aptitude "out of the Box' funktionieren.
"managen" kannst du die DomU's super per commandline (ssh)
da braucht man eigentlich keine WebGUI....
xm create
xm list ....... usw ....
Falls Du allerdings VTd benutzen willst (was ja bei Xen nicht nötig wäre) würde ich eher zu Xen 4.0.1 raten, da hat sich einiges getan. PV Passthrough sollte auch mit 3.3/3.4 gehen...
Edit:
Zur Interrupt-Problematik:
- lspci ist kein geeignetes Mittel um zu sehen ob ein Gerät benutzt wird oder nicht. Es ist physikalisch vorhanden und solange Du es nicht im BIOS abstellen kannst, wird lspci es *immer* anzeigen.
- Wenn nousb nicht funktioniert, dann arbeitet Dein System ausschließlich mit Modulen für usb -> dann ab in die schon gefundene Blacklist damit
- Im konkreten Fall sollte es reichen dafür zu sorgen, dass das zweite Gerät auf dem IRQ nicht beutzt wird, dann ist es auch kein Problem wenn sie sich den Interrupr teilen (dir kann ja egal sein ob der USB Controller einen Interrupr abbekommt der nicht zu ihm gehört solange kein Treiber überhaupt mit dem Controller spricht)
Wenn Du sowieso neu installierst könnte ich Dir auch CentOS als Distri ans Herz legen (wohlgemerkt für das Hostsystem, was Du im Gast installierst ist weitgehend* egal), da gibt es auf gitco.de immer aktuelle Xen Versionen als RPM.
das mit dem PCIe-Slot durchreichen erscheint mir als sehr gute Idee.
Unter XEN mache ich das jedenfalls so .... anders geht es da gar nicht??
wie konnte ich das nur überlesen ....
Gruß
Das ist afair nur erforderlich wenn die Karte Ihre eigene PCI(e) Bridge mitbringt, dann mußt Du schon die Bridge durchreichen (das meint sicher auch ochja).
Den Port (in Deinem Fall mit pciid von Intel) solltest Du nicht durchreichen müssen. Probieren kannst Du es natürlich, aber mich würde es eher überraschen, wenn es dadurch funktionieren sollte...
Sehr interessant... habe quasi zeitlich parallel zu Dir ähnliches probiert. Hier ebenfalls mit einer CineS2, allerdings unter ESXi.
Passthrough der Karte zu Windows klappte einwandfrei, Installation der Treiber ebenfalls, aber - genau wie bei Dir -: Keine Channels!
Habe jetzt noch lange nicht in dem Detailgrad wie Du das Thema durchleuchtet, werde mich aber nochmal melden, sobald ich wieder mal Zeit finde, das Thema weiter zu bearbeiten (ESXi aktuell wieder zurückgenommen, da der Rechner quasi "produktiv" arbeitet (Fileserver für die Mediensammlung).
Ich frage mich, ob dies ein CineS2-spezifisches Problem ist oder ob dies ein generelles Problem von PCI/PCIe-SAT-Karten ist...
Zu Deiner "Access Denied"-Frage unter Ubuntu: Hast Du schonmal "lspci" mit root-Rechten ausgeführt (sudo)?
Gruß
Oliver
Habe am Wochende mal einen Versuch mit einer anderen SAT-Karte gewagt (TeVii S464 / PCI). Habe die Karte analog zur Cine-S2 per PCI Passthrough an ein virtualisiertes Win7 durchgereicht. Treiber Installation lief problemlos.
Dann der Test mit ProgDVB: Beim Senderscan zeigt das Tool entsprechende Werte für Signalstärke und -qualität. Ich habe schon innerlich gejubelt, aber der Scan brachte dann am Ende doch keine Sender.
Wenn ich mich recht erinnere, dann wurde bei der Cine-S2 keine Signalstärke und -qualität angezeigt. Bin mir aber nicht mehr so sicher.
Weisst Du noch, ob bei der Cine-S2 gar nix durchkommt?
Dann nochmal ein Test mit einer USB-Lösung (TeVii S660): Die USB-Box ebenfalls per Passthrough an das virtualisierte Win7 durchgereicht, Treiber installiert... und... Sender werden gefunden!
Ein erster schneller Test mit MediaPortal lief auch ganz o.k., insgesamt hatte das Bild aber oft Klötzchen und an HD war gar nicht zu denken. Vermutlich ist beim USB-Passthrough die Bandbreite einfach zu beschränkt 
Was machen Deine Versucht mit XEN?
Oliver
hi,
also zum thema esxi und cine s2 kann ich was beitragen. betrifft allerdings windows (als gast). bin mir aber sicher, dass es im linux gast ebenso läuft. hatte nämlich ähnlche probleme wie du, aber nach tagelangem rumtüffteln, hab ich endlich ne lösung gefunden:
Du musst die VMX Datei (der virtuellen Maschine) mit nem Editor bearbeiten. Folgenden Eintrag musste eintragen:
pciPassthru0.msiEnabled = False
Die "0" eben durch deinen Wert ersetzen.
Wichtig ist, den Wert musst du setzen, BEVOR du die virtuelle Maschine das erste mal startest. Ist ein OS bereits installiert, haste keine Chance es zum laufen zu kriegen. So war es zumindest bei mir. Hab es auch mehrere male getestet.
Also deswegen erst VM anlegen, Wert setzen, dann OS installieren.
Während Du noch Windows benutzt würde ich die GPLPV-Treiber (von James Harper) empfehlen, damit ist Netzwerk und Disk-Durchsatz deutlich besser als über die qemu-emulierten Devices.
Convirt sieht zwar ganz nett aus, aber das hättest Du Dir glaube ich auch sparen können wenn Du nicht gerade 20 sich ständig ändernde VMs auf dem Host laufen lassen willst.
Eine Xen-domU Config kann man mit ca. 10-20 Zeilen auch noch gut mit vi bearbeiten 
Gibt es einen bestimmten Grund für "pci_msitranslate = 0"? Ich dachte genau mit msitranslate wären die Interrupt-Probleme umgangen...
ZitatAlles anzeigenOriginally posted by ErAzOr2kx
Du musst die VMX Datei (der virtuellen Maschine) mit nem Editor bearbeiten. Folgenden Eintrag musste eintragen:
pciPassthru0.msiEnabled = False
Die "0" eben durch deinen Wert ersetzen.
Hallo ErAzOr2kx,
das sind gute Nachrichten. Habe mich jetzt schon einige Wochen nicht mehr mit dem Thema auseinandergesetzt und nicht mehr alles vor Augen.
Wenn ich die Kiste wieder anwerfe komme ich vermutlich selber drauf aber nur zur Sicherheit: Was meinst du denn mit "deinen Wert" bzw. wie bekomme ich heraus, welchen Wert ich setzten muss?
Besten Dank
Oliver
Hallo,
ich versuche mich gerade an dem HowTo, bin mir aber an der Stelle wo es um die Ermittlung der PCI-ID's geht nicht ganz sicher...
...
#PCI-ID herausfinden und grub-Eintrag anpassen. Außerdem vt-d aktivieren
...
Wenn ich das richtig deute, dann werden diverse ID's nicht über passthrough weitergereicht?!.
...
xen-pciback.hide=(01:00.0)(02:00.0)(00:1d.7)(00:1a.7)Die Frage ist nur, welche das sind, wenn ich die Einträge (01:00.0)(02:00.0)(00:1d.7)(00:1a.7) mit der weiter oben ausgegebenen Ausgabe von lspci -vv vergleiche ergibt das ganze für mich keinen Sinn.
Vielleicht kann mir jemand auf die Sprünge helfen.
Anbei noch meine Ausgabe von lspci -vv:
CU
Stefan
Um sich einen Überblick über die device-ids zu verschaffen, finde ich das Script von "neobiker" sehr hilfreich:
#!/bin/bash
for dev_id in $( lspci | cut -d\ -f1 ) ; do
irq=$( dmesg | grep GSI | grep $dev_id | awk '{print $12}' | head -n 1 )
device=$( lspci | grep $dev_id | cut -d\ -f2- )
[ -n "$irq" ] && echo "$irq: $dev_id - $device"
doneEinfach in der Dom0 ausführen und man sieht sofort welches Gerät welche ID hat und wie die IRQ-Verteilung ist.
Gruß
tec
ZitatAlles anzeigenOriginal von negotiator7
Hallo ErAzOr2kx,
das sind gute Nachrichten. Habe mich jetzt schon einige Wochen nicht mehr mit dem Thema auseinandergesetzt und nicht mehr alles vor Augen.
Wenn ich die Kiste wieder anwerfe komme ich vermutlich selber drauf aber nur zur Sicherheit: Was meinst du denn mit "deinen Wert" bzw. wie bekomme ich heraus, welchen Wert ich setzten muss?
Besten Dank
Oliver
Sorry, habe den Thread schon ewig nicht mehr weiterverfolgt 
Vielleicht hast du es schon selber herausgefunden...
Je nachdem wieviel Karten du durchreichst, wird das in der VMX Datei eben durchnummeriert. Reichst du nur eine Karte durch, hat die Karte eben den Wert 0. Bei zwei Karten eine eine den Wert 0, die andere den Wert 1. Da musst dann eben schauen, welche die richtige ist.
Leider hab ich mit PCI Passthrough sowohl mit dem TVServer (Mediaportal), als auch VDR schlechte erfahrungen gemacht. Habe damit ständig freezer im Live TV (vorallem bei HD Sendern). Ich denke das kommt von der Virtualisierung ansich.
Hat da schon jemand ähnliche Erfahrungen gemacht?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!