VDR-Server Virtualisierung Probleme mit PCI Passthrough

Hallo Zusammen,

ich bin momentan dabei mir einen VDR-Streaming Server hochzuziehen. Diesen würde ich gerne Virtualisieren und die TV-Tuner mittels vt-d zum Gast durchschleifen.

Meine ersten Versuche mit VM-Ware ESXI sind kläglich gescheitert.
So nun habe ich das ganze mal mit KVM (Proxmox-VE) probiert und habe momentan das Problem, dass der TV-Tuner zwar vom Gast erkannt wird, jedoch kein Signal bekommt.

Die Karte und die SAT-Leitung sind in Ordnung. Das habe ich schon ausgeschlossen.

Zunachächst zur Hardware:

MB: Intel DQ57TM
CPU: Intel Core I-5 650
TV-Tuner: Digital Devices Cine S2

CPU und Board unterstützen VT-d. VT-d ist im BIOS auch enabled.

Folgendes habe ich gemacht:

1. ProxmoxVE von CD installiert (neuste Version --> 1.6-5261-4)
2. Kernel 2.6.35 installiert

wget ftp://download.proxmox.com/deb…-1-pve_2.6.35-3_amd64.deb
dpkg -i pve-kernel-2.6.35-1-pve_2.6.35-3_amd64.deb

3. Intels VT-d für den Kernel in der menu.lst aktiviert.
Ohne diesen Eintrag, in der menu.lst funktionierte das Durchreichen überhaupt nicht. Ich hatte dann einen Fehler im kernel-Log.... ".... no iommu found....device hasn´t been assigned before so can not be reassigned."

nano /boot/grub/menu.lst

...
kernel /vmlinuz-2.6.35-1-pve root=/dev/mapper/pve-root ro intel_iommu=on

4. Karte mit lspci identifizieren

lspci

00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02)
00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06)
00:16.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset PT IDER Controller (rev 06)
00:16.3 Serial controller: Intel Corporation 5 Series/3400 Series Chipset KT Controller (rev 06)
00:19.0 Ethernet controller: Intel Corporation 82578DM Gigabit Network Connection (rev 06)
00:1a.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06)
00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 5 (rev 06)
00:1d.0 USB Controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface Controller (rev 06)
00:1f.2 IDE interface: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA IDE Controller (rev 06)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller (rev 06)
00:1f.5 IDE interface: Intel Corporation 5 Series/3400 Series Chipset 2 port SATA IDE Controller (rev 06)
02:00.0 Multimedia video controller: Micronas Semiconductor Holding AG Device 0720 (rev 01)

Lspci –n
00:00.0 0600: 8086:0040 (rev 02)
00:02.0 0300: 8086:0042 (rev 02)
00:16.0 0780: 8086:3b64 (rev 06)
00:16.2 0101: 8086:3b66 (rev 06)
00:16.3 0700: 8086:3b67 (rev 06)
00:19.0 0200: 8086:10ef (rev 06)
00:1a.0 0c03: 8086:3b3c (rev 06)
00:1b.0 0403: 8086:3b56 (rev 06)
00:1c.0 0604: 8086:3b42 (rev 06)
00:1c.4 0604: 8086:3b4a (rev 06)
00:1d.0 0c03: 8086:3b34 (rev 06)
00:1e.0 0604: 8086:244e (rev a6)
00:1f.0 0601: 8086:3b0a (rev 06)
00:1f.2 0101: 8086:3b20 (rev 06)
00:1f.3 0c05: 8086:3b30 (rev 06)
00:1f.5 0101: 8086:3b26 (rev 06)
02:00.0 0400: 18c3:0720 (rev 01)

5. Blacklisten der Kernel-Module

mit lspci -vv konnte ich sehen das die Karte das Kernel-Modul ngene nutzt. Dieses ist wiederum in Benutzung von dem Kernel-Modul dvb_core.

nano /etc/modprobe.d/blacklist
blacklist ngene
blacklist dvb_core

Nach einem Neustart konnte ich mit lsmod sehen, dass die Kernel-Module nun nicht mehr geladen wurden.

6. Unbind Cine-S2 (Ich weiß nicht ob das nötig ist)

Hier bin ich mehr oder weniger Strickt nach der Anleitung von KVM vorgegangen.

http://www.linux-kvm.org/page/…_devices_with_VT-d_in_KVM

modprobe -r kvm-intel
modprobe -r kvm

echo "18c3 0720" > /sys/bus/pci/drivers/pci-stub/new_id
echo 0000:02:00.0 > /sys/bus/pci/devices/0000:02:00.0/driver/unbind
echo 0000:02:00.0 > /sys/bus/pci/drivers/pci-stub/bind

modprobe –a kvm kvm_intel

7. Karte in der VM zuweisen und VM starten

nano /etc/qemu-server/101.conf

...
args: -pcidevice host=02:00.0
..

So nach starten der VM (ist momentan testhalber Windows 7 installiert), wurde die Karte sauber erkannt. Auch konnte ich ohne Probleme im Gerätemanager die Treiber installieren. Jedoch bekommt die Karte kein Signal (Probiert mit mehrern Applikationen)

Jedoch bekomme ich andauernd im Kernel-Log einen Fehler:

...
"irq 16: nobody cared (try booting with the "irqpoll" option)"
....

8. irqpoll option in der menu.lst eintragen

nano /boot/grub/menu.lst
....
kernel /vmlinuz-2.6.35-1-pve root=/dev/mapper/pve-root ro intel_iommu=on irqpoll
....

Der Fehler bleibt jedoch. Karte wird sauber erkannt jedoch kein Signal.
Hat jemand von euch so etwas schon mal erfolgreich zum laufen gebracht?

Hi,

am Kabel liegt ein Signal an. Wenn ich yavdr direkt auf die Kiste installiere habe ich ein signal. Ich bekomme nur leider kein Signal in der Virtuellen Maschine.

Nein scan habe ich jetzt nicht probiert, da auf der VM momentan Windows installiert ist. Ich bekomme aber sowohl mit DVBViewer/Mediaportal/Windows-Media-Center kein signal. Ist ja eigentlich egal ob jetzt linux oder windows. Die karte hat in der vm einfach kein signal.

Ich kann aber auch mal yavdr draufinstallieren und test.

Wie hast du das ganze mit XEN realisiert? Gibt es irgendwo ein kleines howto? An XEN habe ich mich noch nicht probiert. Soweit ich aber gelesen habe, muss ich hierfür einen sehr alten kernel verwenden. Deswegen hatte ich es erst gar nicht probiert. Es muss nicht unbedingt Proxmox sein. Läuft das ganze dann auch über vt-d?

So ich habe das ganze jetzt nochmal untersucht. Es ganze hängt wohl irgendwie mit IRQ-Sharing zusammen. Die Karte bekommt zunächst nach dem booten den IRQ11 zugewiesen. Dieser ist bereits schon mehrfach belegt.

proxmox:~# lspci -vv | grep IRQ
Interrupt: pin A routed to IRQ 11
Interrupt: pin A routed to IRQ 11
Interrupt: pin C routed to IRQ 18
Interrupt: pin B routed to IRQ 17
Interrupt: pin A routed to IRQ 44
Interrupt: pin B routed to IRQ 21
Interrupt: pin C routed to IRQ 18
Interrupt: pin D routed to IRQ 19
Interrupt: pin A routed to IRQ 16
Interrupt: pin A routed to IRQ 22
Interrupt: pin B routed to IRQ 19
Interrupt: pin C routed to IRQ 16
Interrupt: pin D routed to IRQ 18
Interrupt: pin A routed to IRQ 23
Interrupt: pin A routed to IRQ 23
Interrupt: pin B routed to IRQ 45
Interrupt: pin C routed to IRQ 18
Interrupt: pin A routed to IRQ 11

Starte ich die VM bekommt die Karte kurzzeitg den IRQ 46

proxmox:~# lspci -vv | grep IRQ
Interrupt: pin A routed to IRQ 11
Interrupt: pin A routed to IRQ 11
Interrupt: pin C routed to IRQ 18
Interrupt: pin B routed to IRQ 17
Interrupt: pin A routed to IRQ 44
Interrupt: pin B routed to IRQ 21
Interrupt: pin C routed to IRQ 18
Interrupt: pin D routed to IRQ 19
Interrupt: pin A routed to IRQ 16
Interrupt: pin A routed to IRQ 22
Interrupt: pin B routed to IRQ 19
Interrupt: pin C routed to IRQ 16
Interrupt: pin D routed to IRQ 18
Interrupt: pin A routed to IRQ 23
Interrupt: pin A routed to IRQ 23
Interrupt: pin B routed to IRQ 45
Interrupt: pin C routed to IRQ 18
Interrupt: pin A routed to IRQ 46

Ist die VM richtig hochgefahren bekommt die Karte den IRQ16. Dieser ist bereits durch die USB-Ports belegt. Dann bekomm ich den Fehler im Kernel-Log "...Disabling IRQ 16"

proxmox:~# lspci -vv | grep IRQ
Interrupt: pin A routed to IRQ 11
Interrupt: pin A routed to IRQ 11
Interrupt: pin C routed to IRQ 18
Interrupt: pin B routed to IRQ 17
Interrupt: pin A routed to IRQ 44
Interrupt: pin B routed to IRQ 21
Interrupt: pin C routed to IRQ 18
Interrupt: pin D routed to IRQ 19
Interrupt: pin A routed to IRQ 16
Interrupt: pin A routed to IRQ 22
Interrupt: pin B routed to IRQ 19
Interrupt: pin C routed to IRQ 16
Interrupt: pin D routed to IRQ 18
Interrupt: pin A routed to IRQ 23
Interrupt: pin A routed to IRQ 23
Interrupt: pin B routed to IRQ 45
Interrupt: pin C routed to IRQ 18
Interrupt: pin A routed to IRQ 16

Die Proxomox-Logs sehen dann so aus:

Nov 14 11:47:07 kernel hda-intel: Codec #3 probe error; disabling it...
Nov 14 11:47:07 kernel hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x300f0000
Nov 14 11:47:07 kernel i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
Nov 14 11:47:07 kernel Adding 4194300k swap on /dev/mapper/pve-swap. Priority:-1 extents:1 across:4194300k
Nov 14 11:47:07 kernel EXT3-fs (dm-1): using internal journal
Nov 14 11:47:07 kernel EXT3-fs: barriers not enabled
Nov 14 11:47:07 kernel kjournald starting. Commit interval 5 seconds
Nov 14 11:47:07 kernel EXT3-fs (dm-2): using internal journal
Nov 14 11:47:07 kernel EXT3-fs (dm-2): mounted filesystem with ordered data mode
Nov 14 11:47:07 kernel EXT3-fs: barriers not enabled
Nov 14 11:47:07 kernel kjournald starting. Commit interval 5 seconds
Nov 14 11:47:07 kernel EXT3-fs (sda1): using internal journal
Nov 14 11:47:07 kernel EXT3-fs (sda1): mounted filesystem with ordered data mode
Nov 14 11:47:07 kernel Bridge firewalling registered
Nov 14 11:47:07 kernel device eth0 entered promiscuous mode
Nov 14 11:47:07 kernel e1000e 0000:00:19.0: irq 44 for MSI/MSI-X
Nov 14 11:47:07 kernel e1000e 0000:00:19.0: irq 44 for MSI/MSI-X
Nov 14 11:47:07 kernel ADDRCONF(NETDEV_UP): eth0: link is not ready
Nov 14 11:47:07 kernel Registering the dns_resolver key type
Nov 14 11:47:07 kernel Slow work thread pool: Starting up
Nov 14 11:47:07 kernel Slow work thread pool: Ready
Nov 14 11:47:07 kernel e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
Nov 14 11:47:07 kernel ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Nov 14 11:47:07 kernel vmbr0: port 1(eth0) entering forwarding state
Nov 14 11:47:07 kernel vmbr0: port 1(eth0) entering forwarding state
Nov 14 11:47:07 kernel Loading iSCSI transport class v2.0-870.
Nov 14 11:47:07 kernel iscsi: registered transport (tcp)
Nov 14 11:47:07 kernel iscsi: registered transport (iser)
Nov 14 11:47:07 master 2293 daemon started -- version 2.5.5, configuration /etc/postfix
Nov 14 11:47:07 pvedaemon 2318 starting server
Nov 14 11:47:07 pvedaemon 2318 starting 2 worker(s)
Nov 14 11:47:07 pvedaemon 2318 worker 2320 started
Nov 14 11:47:07 pvedaemon 2318 worker 2322 started
Nov 14 11:47:07 pvetunnel 2328 not starting server - not part of cluster
Nov 14 11:47:07 pvemirror 2336 not starting server - not part of cluster
Nov 14 11:47:07 ntpd 2348 ntpd 4.2.4p4@1.1520-o Sun Nov 22 16:14:34 UTC 2009 (1)
Nov 14 11:47:07 ntpd 2349 precision = 1.000 usec
Nov 14 11:47:07 ntpd 2349 Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Nov 14 11:47:07 ntpd 2349 Listening on interface #1 wildcard, ::#123 Disabled
Nov 14 11:47:07 ntpd 2349 Listening on interface #2 eth0, fe80::227:eff:fe11:9a27#123 Enabled
Nov 14 11:47:07 ntpd 2349 Listening on interface #3 lo, ::1#123 Enabled
Nov 14 11:47:07 ntpd 2349 Listening on interface #4 lo, 127.0.0.1#123 Enabled
Nov 14 11:47:07 ntpd 2349 Listening on interface #5 vmbr0, 192.168.100.254#123 Enabled
Nov 14 11:47:07 ntpd 2349 kernel time sync status 0040
Nov 14 11:47:07 ntpd 2349 frequency initialized 0.000 PPM from /var/lib/ntp/ntp.drift
Nov 14 11:47:07 iscsid transport class version 2.0-870. iscsid version 2.0-870
Nov 14 11:47:07 iscsid iSCSI daemon with pid=2089 started!
Nov 14 11:47:08 cron 2391 (CRON) INFO (pidfile fd = 3)
Nov 14 11:47:08 cron 2392 (CRON) STARTUP (fork ok)
Nov 14 11:47:08 cron 2392 (CRON) INFO (Running @reboot jobs)
Nov 14 11:47:08 cron 2400 (root) CMD (test -x /usr/lib/atsar/atsadc && (LOGDIR=/var/log/atsar; CURDAY=`date +%d`; find $LOGDIR/atsa$CURDAY -mtime +2 -type f -exec rm {} \; 2> /dev/null; /usr/lib/atsar/atsadc $LOGDIR/atsa$CURDAY))
Nov 14 11:47:08 proxwww 2447 Starting new child 2447
Nov 14 11:47:08 proxwww 2448 Starting new child 2448
Nov 14 11:47:13 kernel vmbr0: no IPv6 routers present
Nov 14 11:47:16 kernel eth0: no IPv6 routers present
Nov 14 11:49:35 pvedaemon 2320 WARNING: Cannot encode 'meminfo' element as 'hash'. Will be encoded as 'map' instead
Nov 14 11:49:40 pvedaemon 2497 starting VM 101 on node 0 (localhost)
Nov 14 11:49:40 qm 2498 VM 101 start
Nov 14 11:49:40 kernel device vmtab101i0 entered promiscuous mode
Nov 14 11:49:40 kernel vmbr0: port 2(vmtab101i0) entering forwarding state
Nov 14 11:49:40 kernel vmbr0: port 2(vmtab101i0) entering forwarding state
Nov 14 11:49:40 kernel vmbr0: new device vmtab101i0 does not support netpoll (disabling)
Nov 14 11:49:40 kernel pci 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
Nov 14 11:49:40 kernel pci 0000:01:00.0: restoring config space at offset 0x1 (was 0x100400, writing 0x100007)
Nov 14 11:49:41 kernel assign device 0:1:0.0
Nov 14 11:49:41 pvedaemon 2497 VM 101 started
Nov 14 11:49:41 kernel pci 0000:01:00.0: irq 46 for MSI/MSI-X
Nov 14 11:49:41 kernel pci 0000:01:00.0: irq 46 for MSI/MSI-X
Nov 14 11:49:47 ntpd 2523 signal_no_reset: signal 17 had flags 4000000
Nov 14 11:49:47 kernel warning: `ntpd' uses 32-bit capabilities (legacy support in use)
Nov 14 11:49:48 ntpd 2349 Listening on interface #6 vmtab101i0, fe80::1843:49ff:fea1:2a3d#123 Enabled
Nov 14 11:49:50 kernel vmtab101i0: no IPv6 routers present
Nov 14 11:50:01 cron 2547 (root) CMD (test -x /usr/lib/atsar/atsa1 && /usr/lib/atsar/atsa1)
Nov 14 11:50:05 pvedaemon 2552 starting vnc proxy UPID:2552-19467:1289731805:vncproxy:0:101:root:5900:oxDAQwb7sPZowSO6ArBLm/mtNfE
Nov 14 11:50:05 pvedaemon 2552 CMD: /bin/nc -l -p 5900 -w 30 -c /usr/sbin/qm vncproxy 101 oxDAQwb7sPZowSO6ArBLm/mtNfE 2>/dev/null
Nov 14 11:50:15 kernel pci 0000:01:00.0: irq 46 for MSI/MSI-X
Nov 14 11:50:20 kernel pci 0000:01:00.0: irq 46 for MSI/MSI-X
Nov 14 11:50:22 kernel irq 16: nobody cared (try booting with the "irqpoll" option)
Nov 14 11:50:22 kernel Pid: 0, comm: swapper Not tainted 2.6.35-1-pve #1
Nov 14 11:50:22 kernel Call Trace:
Nov 14 11:50:22 kernel <IRQ> [<ffffffff810ccf5b>] __report_bad_irq+0x2b/0xb0
Nov 14 11:50:22 kernel [<ffffffff810cd178>] note_interrupt+0x198/0x1e0
Nov 14 11:50:22 kernel [<ffffffff810cd96d>] handle_fasteoi_irq+0xdd/0x110
Nov 14 11:50:22 kernel [<ffffffff8100dac4>] handle_irq+0x24/0x40
Nov 14 11:50:22 kernel [<ffffffff815bc10f>] do_IRQ+0x6f/0xf0
Nov 14 11:50:22 kernel [<ffffffff815b4f53>] ret_from_intr+0x0/0x11
Nov 14 11:50:22 kernel <EOI> [<ffffffff81342482>] ? acpi_idle_enter_simple+0xe7/0x120
Nov 14 11:50:22 kernel [<ffffffff8134247b>] ? acpi_idle_enter_simple+0xe0/0x120
Nov 14 11:50:22 kernel [<ffffffff81493da4>] cpuidle_idle_call+0xb4/0x140
Nov 14 11:50:22 kernel [<ffffffff8100a1a1>] cpu_idle+0xb1/0x110
Nov 14 11:50:22 kernel [<ffffffff8159285a>] rest_init+0x8a/0xa0
Nov 14 11:50:22 kernel [<ffffffff81b05e3d>] start_kernel+0x42f/0x4f0
Nov 14 11:50:22 kernel [<ffffffff81b052c0>] x86_64_start_reservations+0xa0/0xc1
Nov 14 11:50:22 kernel [<ffffffff81b053e7>] x86_64_start_kernel+0x106/0x121
Nov 14 11:50:22 kernel [<ffffffff81b05140>] ? early_idt_handler+0x0/0x71
Nov 14 11:50:22 kernel handlers:
Nov 14 11:50:22 kernel [<ffffffff814263a0>] (usb_hcd_irq+0x0/0x90)
Nov 14 11:50:22 kernel [<ffffffff814263a0>] (usb_hcd_irq+0x0/0x90)
Nov 14 11:50:22 kernel Disabling IRQ #16
Nov 14 11:50:59 proxwww 2594 Starting new child 2594
Nov 14 11:51:31 proxwww 2633 Starting new child 2633
Nov 14 11:51:56 proxwww 2655 Starting new child 2655
Nov 14 11:52:30 ntpd_initres 2523 signal_no_reset: signal 14 had flags 4000000
Nov 14 11:52:37 proxwww 2703 Starting new child 2703

Ich habe schon das Bios durchgeschaut. Jedoch gibt es hier keine Möglichkeit IRQs fest zuzuweisen. Kann ich irgendwie per command-line irqs fest zuweisen?

habe ich schon probiert. Bei beiden PCIe1x Ports das gleiche Problem und gleicher IRQ. Auf dem PCIe16x-Steckplatz funktioniert die Karte gar nicht.

keine Ahnung ob das geht. Helft mir mal auf die Sprünge. Was ist eigentlich MSI und wie aktiviere ich das? Ich sehe nur im Log was von MSI und MSI-X:

.....
Nov 14 11:47:07 kernel e1000e 0000:00:19.0: irq 44 for MSI/MSI-X
Nov 14 11:47:07 kernel e1000e 0000:00:19.0: irq 44 for MSI/MSI-X
.....
Nov 14 11:49:41 kernel pci 0000:01:00.0: irq 46 for MSI/MSI-X
Nov 14 11:49:41 kernel pci 0000:01:00.0: irq 46 for MSI/MSI-X

.....
Ich würde ja gerne USB komplett deaktivieren. Doch das gibt mein BIOS nicht her. Ich kann nur einzelne USB-Ports deaktiveren. Aber USB nicht komplett. Deaktivere ich alle USB ports ist unter lspci der USB-Controller immer noch vorhanden. Alle anderen unnötigen Komponenten (HD Audio, eSATA) habe ich schon deaktivert.

Hilft mir vielleicht einer dieser Zahlreichen kernel-Paremeter weiter?
acpi=off
pci=assign-busses
pci=irqbios
noapic
nolapic
pci=biosirq
irqpoll
acpi=force
pci=noacpi
noapic
pci=routeirq
pci=norouteirc
pci=biosirq
pnpbios=off
pci=usepirqmask
acpi_apic_instance=2
pci=ioapicreroute
pci=irqmask=0xMMMM
pci=routeirq

Danke schonmal für eure zahlreichen Antworten.

Razorblade hierzu hätte ich noch ein paar Fragen.

zu Punkt 1. Ok ich muss also irgendwie MSI nutzen. Aber laut meinen Logs ist das doch schon aktiv oder sehe ich das falsch? Wie kann ich MSI explizit aktivieren? Weil du sagst dass muss vom kernel und von den Treibern unterstüzt werden. Wie sehe ich ob das ein Treiber unterstützt und welche Treiber meinst du? Den Treiber für die dvb-karte habe ich ja extra geblacklistet, dass ich die Karte durchreichen kann. Somit wird dieser ja gar nicht geladen. Der Treiber für die dvb-karte wird ja dann auf der VM installiert. Meinst du somit die Treiber für PCI-Express (bei mir dann pcieport)?

Zu Punkt2. Ok wo kann ich das im kernel abschalten ohne dass ich meinen kernel neu kompilieren muss? kann ich dass auch über die /boot/grub/menu.lst machen?

Zu Punkt 3.
Da muss ich einfach rumprobieren. irqpoll hatte ich schon probiert. Fehler tauchte zwar nicht mehr auf. jedoch immer noch kein Signal der Karte.

Experimentiere zur zeit mit KVM rum. VmWare habe ich gleich wieder sein lassen. Es würde ja auch nix gegen XEN sprechen. Wie ich das rauslese, kann man da auch Geräte ohne VT-d durchschleifen.

Jedoch würde ich das ganze gerne mit Proxmox-KVM realisieren. Da habe ich eine Distri die ich installiere und fertig. Und kann schön meine VMs über eine WebGui verwalten.

Für XEN gibt es so eine Webgui nicht oder? Auch gibt es keine fertige Distri. Das heißt erste Debian/Ubuntu installieren dann XEN und soweit ich mitbekommen habe auch noch einen extra kernel. Deswegen würde ich gerne das Problem mit KVM in den Griff bekommen.

Bei mir heißt die Blacklist-Datei:
/etc/modprobe.d/blacklist

Also ich habe gestern nochmal etwas rumprobiert.

Zunächst habe ich versucht USB zu deaktivieren. Hierzu habe ich in der /boot/grub/menu.lst den kernel mit nousb gestartet. Jedoch scheint die Option nicht zu greifen. Nach einem Reboot kann ich die USB-Controller immer noch alle unter lspci finden. Auch haben sie einen IRQ und die kernel-Module laufen. Danach habe ich die Kernel-module der usb ports gestoppt (uhci-hcd und ehci-hcd). Jedoch belegen die Controller danach immer noch einen IRQ.

Mein Hauptproblem ist, dass MSI anscheinend nicht richtig funktioniert.
Boote ich die VM bekommt die karte über msi zunächst einen IRQ > 30 zugewiesen. Soweit sieht es ja ganz gut aus.

das sieht man ja auch im log:
..
Nov 14 11:49:41 kernel pci 0000:01:00.0: irq 46 for MSI/MSI-X
Nov 14 11:49:41 kernel pci 0000:01:00.0: irq 46 for MSI/MSI-X
...

proxmox:~# lspci -vv | grep IRQ
.....
Interrupt: pin B routed to IRQ 45
Interrupt: pin C routed to IRQ 18
Interrupt: pin A routed to IRQ 46

Wenn aber anscheinend die VM versucht auf die Karte zuzugreifen, verliert die Karte wieder den IRQ und bekommt dann wieder den IRQ 16. Dieses Problem tritt immer auf, egal ob ich im kernel den Fehler "....Disabling IRQ16...." bekomme. Mit irqpoll bekomme ich z.B. nicht den Fehler im kernel-log. Jedoch verliert die Karte trotzdem ihren IRQ>30 (hier z.B. 46) und hat dann wieder den IRQ16. Das Problem tritt erst auf, wenn die VM komplett hochgefahren ist.

proxmox:~# lspci -vv | grep IRQ
...
Interrupt: pin B routed to IRQ 45
Interrupt: pin C routed to IRQ 18
Interrupt: pin A routed to IRQ 16

Auch mit den Parametern irqpoll, irqfixup, noirqdebug tritt das Problem auf. Die karte verliert immer ihren IRQ, denn Sie von msi zugewiesen bekommt. Der Fehler im log kommt mal und mal nicht. Aber egal, ich sehe ja mit lspci, dass der IRQ wieder weg ist..

ok werd mich auch mal mit XEN befassen.
Hat vielleicht jemand von euch für mich ein kleine Howto?
Muss nur stichpunktartig sein

z. B.
1. Debian xx ins
2. apt-get install xyz
3. ....conf anpassen...

Gibt es jetzt eigentlich für XEN eine Art weboberfläche? oder wie managed ihr eure VMs von über Netz? Der Server soll nämlich in den Dachboden ohne Bildschirm.....und im Dachboden wollte ich nicht gerade werkeln...