HP Proliant Microserver Gen8 - RaidController HP P410 - Passthrough Probleme

[dschense]

Ich suche mich nun schon seit Tagen wirklich dumm und dämlich... leide bin ich bis jetzt noch auf nichts Brauchbares gestoßen.
Ich habe mich daran versucht einen RaidController an eine VM durchzureichen...
Ich bekomme aber ständig folgende Ausgabe:

kvm: -device vfio-pci,host=07:00.0,id=hostpci0,bus=pci.0,addr=0x10: vfio: failed to set iommu for container: Operation not permitted
kvm: -device vfio-pci,host=07:00.0,id=hostpci0,bus=pci.0,addr=0x10: vfio: failed to setup container for group 1
kvm: -device vfio-pci,host=07:00.0,id=hostpci0,bus=pci.0,addr=0x10: vfio: failed to get group 1
kvm: -device vfio-pci,host=07:00.0,id=hostpci0,bus=pci.0,addr=0x10: Device initialization failed

TASK ERROR: start failed: command '/usr/bin/kvm -id 101 -chardev 'socket,id=qmp,path=/var/run/qemu-server/101.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -pidfile /var/run/qemu-server/101.pid -daemonize -smbios 'type=1,uuid=5da287d8-6d3c-4b25-9dfd-f7f1a0b5b2ed' -name NAS -smp '4,sockets=1,cores=4,maxcpus=4' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' -vga cirrus -vnc unix:/var/run/qemu-server/101.vnc,x509,password -cpu kvm64,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 8192 -k de -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' -device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' -device 'vfio-pci,host=07:00.0,id=hostpci0,bus=pci.0,addr=0x10' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:801b4b2e85f' -drive 'if=none,id=drive-ide2,media=cdrom,aio=threads' -device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200' -drive 'file=/var/lib/vz/images/101/vm-101-disk-1.qcow2,if=none,id=drive-virtio0,format=qcow2,cache=none,aio=native,detect-zeroes=on' -device 'virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100' -netdev 'type=tap,id=net0,ifname=tap101i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=12:1F:B8:71:8E:16,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300'' failed: exit code 1

Ich hoffe mir kann damit jemand helfen...

System:

Proliant Microserver Gen8
8 x Intel(R) Xeon(R) CPU E3-1230 V2 @ 3.30GHz (1 Socket)
16 GB Ram

proxmox-ve: 4.3-71 (running kernel: pve-kernel-4.4.21-1-pve)
pve-manager: 4.3-10 (running version: 4.3-10/7230e60f)
pve-kernel-4.4.21-1-pve: 4.4.21-71
pve-kernel-4.4.24-1-pve: 4.4.24-72
lvm2: 2.02.116-pve3
corosync-pve: 2.4.0-1
libqb0: 1.0-1
pve-cluster: 4.0-47
qemu-server: 4.0-94
pve-firmware: 1.1-10
libpve-common-perl: 4.0-80
libpve-access-control: 4.0-19
libpve-storage-perl: 4.0-68
pve-libspice-server1: 0.12.8-1
vncterm: 1.2-1
pve-docs: 4.3-14
pve-qemu-kvm: 2.7.0-8
pve-container: 1.0-81
pve-firewall: 2.0-31
pve-ha-manager: 1.0-35
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u2
lxc-pve: 2.0.5-1
lxcfs: 2.0.4-pve2
criu: 1.6.0-1
novnc-pve: 0.5-8
smartmontools: 6.5+svn4324-1~pve80

dmesg | grep -e DMAR -e IOMMU
[    0.000000] ACPI: DMAR 0x00000000F1DE4A80 0003B4 (v01 HP     ProLiant 00000001 \xffffffd2?   0000162E)
[    0.000000] Intel-IOMMU: enabled
[    0.014567] dmar: IOMMU 0: reg_base_addr fed90000 ver 1:0 cap c9008020660262 ecap f010da
[    0.014642] IOAPIC id 8 under DRHD base  0xfed90000 IOMMU 0
[    0.315512] DMAR: No ATSR found
[    0.315527] IOMMU 0 0xfed90000: using Queued invalidation
[    0.315528] IOMMU: Setting RMRR:
[    0.315535] IOMMU: Setting identity map for device 0000:01:00.0 [0xf1dee000 - 0xf1deefff]
[    0.315552] IOMMU: Setting identity map for device 0000:01:00.2 [0xf1dee000 - 0xf1deefff]
[    0.315564] IOMMU: Setting identity map for device 0000:01:00.4 [0xf1dee000 - 0xf1deefff]
[    0.315575] IOMMU: Setting identity map for device 0000:00:1f.2 [0xe8000 - 0xe8fff]
[    0.315590] IOMMU: Setting identity map for device 0000:07:00.0 [0xe8000 - 0xe8fff]
[    0.315604] IOMMU: Setting identity map for device 0000:03:00.0 [0xe8000 - 0xe8fff]
[    0.315618] IOMMU: Setting identity map for device 0000:03:00.1 [0xe8000 - 0xe8fff]
[    0.315630] IOMMU: Setting identity map for device 0000:04:00.0 [0xe8000 - 0xe8fff]
[    0.315640] IOMMU: Setting identity map for device 0000:01:00.0 [0xe8000 - 0xe8fff]
[    0.315647] IOMMU: Setting identity map for device 0000:01:00.2 [0xe8000 - 0xe8fff]
[    0.315654] IOMMU: Setting identity map for device 0000:00:1f.2 [0xf4000 - 0xf4fff]
[    0.315656] IOMMU: Setting identity map for device 0000:07:00.0 [0xf4000 - 0xf4fff]
[    0.315657] IOMMU: Setting identity map for device 0000:03:00.0 [0xf4000 - 0xf4fff]
[    0.315658] IOMMU: Setting identity map for device 0000:03:00.1 [0xf4000 - 0xf4fff]
[    0.315660] IOMMU: Setting identity map for device 0000:04:00.0 [0xf4000 - 0xf4fff]
[    0.315661] IOMMU: Setting identity map for device 0000:01:00.0 [0xf4000 - 0xf4fff]
[    0.315662] IOMMU: Setting identity map for device 0000:01:00.2 [0xf4000 - 0xf4fff]
[    0.315663] IOMMU: Setting identity map for device 0000:00:1f.2 [0xf1f7e000 - 0xf1f7efff]
[    0.315670] IOMMU: Setting identity map for device 0000:07:00.0 [0xf1f7e000 - 0xf1f7efff]
[    0.315678] IOMMU: Setting identity map for device 0000:03:00.0 [0xf1f7e000 - 0xf1f7efff]
[    0.315684] IOMMU: Setting identity map for device 0000:03:00.1 [0xf1f7e000 - 0xf1f7efff]
[    0.315691] IOMMU: Setting identity map for device 0000:04:00.0 [0xf1f7e000 - 0xf1f7efff]
[    0.315698] IOMMU: Setting identity map for device 0000:01:00.0 [0xf1f7e000 - 0xf1f7efff]
[    0.315702] IOMMU: Setting identity map for device 0000:01:00.2 [0xf1f7e000 - 0xf1f7efff]
[    0.315706] IOMMU: Setting identity map for device 0000:00:1f.2 [0xf1f7f000 - 0xf1f8efff]
[    0.315708] IOMMU: Setting identity map for device 0000:07:00.0 [0xf1f7f000 - 0xf1f8efff]
[    0.315710] IOMMU: Setting identity map for device 0000:03:00.0 [0xf1f7f000 - 0xf1f8efff]
[    0.315711] IOMMU: Setting identity map for device 0000:03:00.1 [0xf1f7f000 - 0xf1f8efff]
[    0.315712] IOMMU: Setting identity map for device 0000:04:00.0 [0xf1f7f000 - 0xf1f8efff]
[    0.315714] IOMMU: Setting identity map for device 0000:01:00.0 [0xf1f7f000 - 0xf1f8efff]
[    0.315715] IOMMU: Setting identity map for device 0000:01:00.2 [0xf1f7f000 - 0xf1f8efff]
[    0.315716] IOMMU: Setting identity map for device 0000:00:1f.2 [0xf1f8f000 - 0xf1f92fff]
[    0.315718] IOMMU: Setting identity map for device 0000:07:00.0 [0xf1f8f000 - 0xf1f92fff]
[    0.315719] IOMMU: Setting identity map for device 0000:03:00.0 [0xf1f8f000 - 0xf1f92fff]
[    0.315720] IOMMU: Setting identity map for device 0000:03:00.1 [0xf1f8f000 - 0xf1f92fff]
[    0.315722] IOMMU: Setting identity map for device 0000:04:00.0 [0xf1f8f000 - 0xf1f92fff]
[    0.315723] IOMMU: Setting identity map for device 0000:01:00.0 [0xf1f8f000 - 0xf1f92fff]
[    0.315725] IOMMU: Setting identity map for device 0000:01:00.2 [0xf1f8f000 - 0xf1f92fff]
[    0.315726] IOMMU: Setting identity map for device 0000:00:1f.2 [0xf1f93000 - 0xf1f94fff]
[    0.315728] IOMMU: Setting identity map for device 0000:07:00.0 [0xf1f93000 - 0xf1f94fff]
[    0.315729] IOMMU: Setting identity map for device 0000:03:00.0 [0xf1f93000 - 0xf1f94fff]
[    0.315730] IOMMU: Setting identity map for device 0000:03:00.1 [0xf1f93000 - 0xf1f94fff]
[    0.315731] IOMMU: Setting identity map for device 0000:04:00.0 [0xf1f93000 - 0xf1f94fff]
[    0.315732] IOMMU: Setting identity map for device 0000:01:00.0 [0xf1f93000 - 0xf1f94fff]
[    0.315734] IOMMU: Setting identity map for device 0000:01:00.2 [0xf1f93000 - 0xf1f94fff]
[    0.315735] IOMMU: Setting identity map for device 0000:01:00.0 [0xf1ff6000 - 0xf1ffcfff]
[    0.315736] IOMMU: Setting identity map for device 0000:01:00.2 [0xf1ff6000 - 0xf1ffcfff]
[    0.315737] IOMMU: Setting identity map for device 0000:01:00.4 [0xf1ff6000 - 0xf1ffcfff]
[    0.315746] IOMMU: Setting identity map for device 0000:00:1a.0 [0xf1ffd000 - 0xf1ffffff]
[    0.315757] IOMMU: Setting identity map for device 0000:00:1d.0 [0xf1ffd000 - 0xf1ffffff]
[    0.315764] IOMMU: Prepare 0-16MiB unity mapping for LPC
[    0.315769] IOMMU: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
[    0.323201] AMD IOMMUv2 driver by Joerg Roedel <joerg.roedel@amd.com>
[    0.323203] AMD IOMMUv2 functionality not available on this system
[  266.465090] vfio-pci 0000:07:00.0: Device is ineligible for IOMMU domain attach due to platform RMRR requirement.  Contact your platform vendor.

find /sys/kernel/iommu_groups/ -type l
/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/1/devices/0000:07:00.0
/sys/kernel/iommu_groups/2/devices/0000:00:06.0
/sys/kernel/iommu_groups/3/devices/0000:00:1a.0
/sys/kernel/iommu_groups/4/devices/0000:00:1c.0
/sys/kernel/iommu_groups/5/devices/0000:00:1c.4
/sys/kernel/iommu_groups/6/devices/0000:00:1c.6
/sys/kernel/iommu_groups/7/devices/0000:00:1c.7
/sys/kernel/iommu_groups/8/devices/0000:00:1d.0
/sys/kernel/iommu_groups/9/devices/0000:00:1e.0
/sys/kernel/iommu_groups/10/devices/0000:00:1f.0
/sys/kernel/iommu_groups/10/devices/0000:00:1f.2
/sys/kernel/iommu_groups/11/devices/0000:03:00.0
/sys/kernel/iommu_groups/11/devices/0000:03:00.1
/sys/kernel/iommu_groups/12/devices/0000:04:00.0
/sys/kernel/iommu_groups/13/devices/0000:01:00.0
/sys/kernel/iommu_groups/13/devices/0000:01:00.1
/sys/kernel/iommu_groups/13/devices/0000:01:00.2
/sys/kernel/iommu_groups/13/devices/0000:01:00.4

VM config:

bootdisk: virtio0
cores: 4
ide2: none,media=cdrom
memory: 8192
name: NAS
net0: virtio=12:1F:B8:71:8E:16,bridge=vmbr0
numa: 0
ostype: l26
scsihw: virtio-scsi-pci
smbios1: uuid=5da287d8-6d3c-4b25-9dfd-f7f1a0b5b2ed
sockets: 1
virtio0: local:101/vm-101-disk-1.qcow2,size=10G
hostpci0: 07:00.0

 

[morph027]

PCI-Express?

machine: q35
hostpci0: 07:00.0,pcie=1

 

[dschense]

Damit bekomme ich leider den selben Fehler (die VM wird wieder gestoppt)

EDIT:

with

machine: q35
hostpci0: 07:00.0,pcie=1,driver=vfio

die VM startet zwar, aber das scheint trotzdem nicht so wirklich zu funktionieren..

EDIT2:

mit dem hostpci0 von oben bekomme ich leider folgenden Fehler:

qm monitor 101
vm 101 - unable to parse value of 'hostpci0' - format error
driver: property is not defined in schema and the schema does not allow additional properties
Entering Qemu Monitor for VM 101 - type 'help' for help

 

[dschense]

Ich habe mich ein wenig weiter versucht und dabei diesen Link gefunden:
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04781229&sp4ts.oid=5249566

Ich habe dabei versucht den PCI Slot 1 der ja von dem Raid Controller (HP P410) verwendet wird freizuschalten..
aber irgendwie hatte ich damit auch kein Glück.

 

[dschense]

Noch ein kleines Update zu meinem Problem:

Ich habe festgestellt, dass mein RaidController sich eine iommu Gruppe teilt. bislang war er in der Gruppe1:

find /sys/kernel/iommu_groups/ -type l
/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/1/devices/0000:07:00.0
/sys/kernel/iommu_groups/2/devices/0000:00:06.0
/sys/kernel/iommu_groups/3/devices/0000:00:1a.0
/sys/kernel/iommu_groups/4/devices/0000:00:1c.0
/sys/kernel/iommu_groups/5/devices/0000:00:1c.4
/sys/kernel/iommu_groups/6/devices/0000:00:1c.6
/sys/kernel/iommu_groups/7/devices/0000:00:1c.7
/sys/kernel/iommu_groups/8/devices/0000:00:1d.0
/sys/kernel/iommu_groups/9/devices/0000:00:1e.0
/sys/kernel/iommu_groups/10/devices/0000:00:1f.0
/sys/kernel/iommu_groups/10/devices/0000:00:1f.2
/sys/kernel/iommu_groups/11/devices/0000:03:00.0
/sys/kernel/iommu_groups/11/devices/0000:03:00.1
/sys/kernel/iommu_groups/12/devices/0000:04:00.0
/sys/kernel/iommu_groups/13/devices/0000:01:00.0
/sys/kernel/iommu_groups/13/devices/0000:01:00.1
/sys/kernel/iommu_groups/13/devices/0000:01:00.2
/sys/kernel/iommu_groups/13/devices/0000:01:00.4

/sys/kernel/iommu_groups/1/devices/0000:07:00.0
wäre in diesem Fall mein RaidController.

jetzt habe ich den Kernel 4.4.24-1-pve mal aus den Sources selbst kompiliert.
das hat alles wunderbar funktioniert.

Ich habe dann folgende .deb´s erhalten:

linux-tools-4.4_4.4.24-72_amd64.deb
proxmox-ve_4.3-72_all.deb
pve-firmware_1.1-10_all.deb
pve-headers_4.3-72_all.deb
pve-headers-4.4.24-1-pve_4.4.24-72_amd64.deb
pve-kernel-4.4.24-1-pve_4.4.24-72_amd64.deb

nach der Installation "dpkg -i *deb"
und einem Restart hat auch alles wunderbar funktioniert.

und siehe da, der RaidController hat dank des override_for_missing_acs_capabilities.patch
der in den Sources integriert ist seine eigene iommu Gruppe erhalten:

find /sys/kernel/iommu_groups/ -type l
/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
/sys/kernel/iommu_groups/2/devices/0000:00:06.0
/sys/kernel/iommu_groups/3/devices/0000:00:1a.0
/sys/kernel/iommu_groups/4/devices/0000:00:1c.0
/sys/kernel/iommu_groups/5/devices/0000:00:1c.4
/sys/kernel/iommu_groups/6/devices/0000:00:1c.6
/sys/kernel/iommu_groups/7/devices/0000:00:1c.7
/sys/kernel/iommu_groups/8/devices/0000:00:1d.0
/sys/kernel/iommu_groups/9/devices/0000:00:1e.0
/sys/kernel/iommu_groups/10/devices/0000:00:1f.0
/sys/kernel/iommu_groups/10/devices/0000:00:1f.2
/sys/kernel/iommu_groups/11/devices/0000:07:00.0
/sys/kernel/iommu_groups/12/devices/0000:03:00.0
/sys/kernel/iommu_groups/12/devices/0000:03:00.1
/sys/kernel/iommu_groups/13/devices/0000:04:00.0
/sys/kernel/iommu_groups/14/devices/0000:01:00.0
/sys/kernel/iommu_groups/14/devices/0000:01:00.1
/sys/kernel/iommu_groups/14/devices/0000:01:00.2
/sys/kernel/iommu_groups/14/devices/0000:01:00.4

der Controller sitzt jetzt in der Gruppe "11"..
Allerdings bekomme ich noch immer den Fehler beim starten der VM:

kvm: -device vfio-pci,host=07:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0: vfio: failed to set iommu for container: Operation not permitted
kvm: -device vfio-pci,host=07:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0: vfio: failed to setup container for group 11
kvm: -device vfio-pci,host=07:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0: vfio: failed to get group 11
kvm: -device vfio-pci,host=07:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0: Device initialization failed

TASK ERROR: start failed: command '/usr/bin/kvm -id 101 -chardev 'socket,id=qmp,path=/var/run/qemu-server/101.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -pidfile /var/run/qemu-server/101.pid -daemonize -smbios 'type=1,uuid=5da287d8-6d3c-4b25-9dfd-f7f1a0b5b2ed' -name NAS -smp '4,sockets=1,cores=4,maxcpus=4' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' -vga cirrus -vnc unix:/var/run/qemu-server/101.vnc,x509,password -cpu kvm64,+lahf_lm,+sep,+kvm_pv_unhalt,+kvm_pv_eoi,enforce -m 8192 -k de -readconfig /usr/share/qemu-server/pve-q35.cfg -device 'usb-tablet,id=tablet,bus=ehci.0,port=1' -device 'vfio-pci,host=07:00.0,id=hostpci0,bus=ich9-pcie-port-1,addr=0x0' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:801b4b2e85f' -drive 'if=none,id=drive-ide2,media=cdrom,aio=threads' -device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=100' -drive 'file=/var/lib/vz/images/101/vm-101-disk-1.qcow2,if=none,id=drive-virtio0,format=qcow2,cache=none,aio=native,detect-zeroes=on' -device 'virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=200' -netdev 'type=tap,id=net0,ifname=tap101i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=12:1F:B8:71:8E:16,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300' -machine 'type=q35'' failed: exit code 1

meine /etc/default/grub sieht übrigens wie folg aus:

quiet intel_iommu=on pcie_acs_override=downstream intremap=no_x2apic_optout

 

[udo]

Hi,
wie sieht denn der die Ausgabe von

lspci -v -s 07:00.0

aus?

Wahrscheinlich eine dumme Frage, aber der Treiber für den Controller ist auf dem Host geblacklisted?

Udo

 

[dschense]

Hi und danke für deine Antwort,.. nein, natürlich keine dumme frage, das hatte ich mir auch zuerst gedacht..aber bei mir schaut die Ausgabe so aus:

lspci -v -s 07:00.0
07:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 controllers (rev 01)
    Subsystem: Hewlett-Packard Company Smart Array P410
    Physical Slot: 1
    Flags: bus master, fast devsel, latency 0, IRQ 10
    Memory at fbe00000 (64-bit, non-prefetchable) [size=2M]
    Memory at fbdf0000 (64-bit, non-prefetchable) [size=4K]
    I/O ports at 4000 [size=256]
    [virtual] Expansion ROM at fbd00000 [disabled] [size=512K]
    Capabilities: [40] Power Management version 3
    Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
    Capabilities: [70] Express Endpoint, MSI 00
    Capabilities: [ac] MSI-X: Enable- Count=16 Masked-
    Capabilities: [100] Advanced Error Reporting
    Kernel driver in use: vfio-pci

der Kerneltreiber vfio-pci ist aber erst drin, seit ich in der Grub Zeite das hier mit eingetragen habe:

vfio-pci.ids=103c:323a

ohne die Boot-Zeile habe ich den Treiber vfio drin stehen.

den sollte ich ja glaube ich nicht auf die Blackliste setzen, oder ?

 

[dschense]

Ein weiteres Update meines Problems. Ich bin jetzt wie folgt vorgegangen:

Installation von Proxmox: proxmox-ve_3.4-102d4547-6.iso
nach der installation ein komplettes Update und ein neustart

Anderen Kernel installieren:
Sammlung: http://download.proxmox.com/debian/dists/wheezy/pve-no-subscription/binary-amd64/
Installiert:
pve-kernel-3.10.0-3-pve_3.10.0-11_amd64.deb

Direktlink:
http://download.proxmox.com/debian/...4/pve-kernel-3.10.0-3-pve_3.10.0-11_amd64.deb

herunterladen mit wget in die laufende Proxmox Instanz.
Installieren mit "dpkg -i pve-kernel-3.10.0-3-pve_3.10.0-11_amd64.deb

danach ein Neustart und in Grub darauf achten, dass auch von dem Kernel gebootet wird.

Einstellungen in Proxmox:

/etc/default/grub anpassen
--->
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"

/etc/modules folgendes einfügen:
--->
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

danach alles neu starten !!!!!

nach dem Reboot folgendes in die vm.conf eintragen:
--->
hostpci0: 07:00.0,driver=vfio

oder

machine: q35
hostpci0: 07:00.0,driver=vfio,pcie=1

Sieh da... die Karte wird tatsächlich in das Gastsystem durchgereicht.. allerdings habe ich jetzt das Problem, dass die VM nicht richtig booten will. dazu ein kleines Bild um die Situation richtig zu beschreiben:

die Installation schaut derzeit so aus:

 pveversion -v
proxmox-ve-2.6.32: 3.4-156 (running kernel: 3.10.0-3-pve)
pve-manager: 3.4-6 (running version: 3.4-6/102d4547)
pve-kernel-2.6.32-39-pve: 2.6.32-156
pve-kernel-3.10.0-3-pve: 3.10.0-11
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.7-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.10-2
pve-cluster: 3.0-17
qemu-server: 3.4-6
pve-firmware: 1.1-4
libpve-common-perl: 3.0-24
libpve-access-control: 3.0-16
libpve-storage-perl: 3.0-33
pve-libspice-server1: 0.12.4-3
vncterm: 1.1-8
vzctl: 4.0-1pve6
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 2.2-10
ksm-control-daemon: 1.1-1
glusterfs-client: 3.5.2-1

Vielleicht bin ich jetzt auf dem richtigen Weg und brauche nur noch etwas Unterstützung..

 

[dschense]

Ich melde mich hier jetzt noch einmal zu Wort, denn ich habe es tatsächlich geschafft meinen HP Smart Array Controller P410 samt Platten im Raid0 Verbund an ein Gastsystem durchzureichen..

das sind jetzt meine Endgültigen Schritte, um das System zum laufen zu bekommen:

Installation von Proxmox 3.4:
proxmox-ve_3.4-102d4547-6.iso
http://www.proxmox.com/de/downloads/item/proxmox-ve-3-4-iso-installer

nach der installation ein komplettes Update und ein neustart
/etc/apt/sources.list anpassen und folgendes hinzufügen:

#Proxmox VE 3.x No-Subscription
deb http://download.proxmox.com/debian wheezy pve-no-subscription

#Proxmox VE 3.x Test
deb http://download.proxmox.com/debian wheezy pvetest

apt-get update && apt-get upgrade && apt-get dist-upgrade

Anderen Kernel installieren 3.10:
Sammlung: http://download.proxmox.com/debian/dists/wheezy/pve-no-subscription/binary-amd64/
http://download.proxmox.com/debian/dists/wheezy/pve-no-subscription/binary-amd64/
Installiert:
pve-kernel-3.10.0-3-pve_3.10.0-11_amd64.deb
Direktlink:
http://download.proxmox.com/debian/...4/pve-kernel-3.10.0-3-pve_3.10.0-11_amd64.deb

herunterladen mit wget in die laufende Proxmox Instanz.
Installieren mit :
dpkg -i pve-kernel-3.10.0-3-pve_3.10.0-11_amd64.deb

danach ein Neustart und in Grub darauf achten, dass auch von dem Kernel gebootet wird.

Einstellungen in Proxmox:

/etc/default/grub anpassen
--->

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on  iommu=pt"

iommu=pt war bei mir wichtig, da ich sonst diesen Fehler beim durchreichen erhalten habe:

[ 35.715620] dmar: DMAR:[DMA Write] Request device [07:00.0] fault addr ffee0000
[ 35.715620] DMAR:[fault reason 05] PTE Write access is not set



/etc/modules folgendes einfügen:
--->

vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

Treibermodul auf die Blacklist:
/etc/modprobe.d/blacklist.conf und darin:

blacklist hpsa

da über lspci -vvv: Kernel driver in use: hpsa angeigt wurde.

danach noch initramfs neu schreiben:
update-initramfs -u

und Grub updaten:
update-grub

danach alles neu starten !!!!!

nach dem Reboot folgendes in die vm.conf eintragen:
--->

hostpci0: 07:00.0,driver=vfio

und schon hatte ich den RaidController in meiner Openmediavault VM. Zugriff auf den Controller, auf die Platten und und und..
Wäre zwar sehr cool, wenn das mit den neueren Versionen von Proxmox auch so funktionieren würde. aber immerhin läuft es jetzt mal so wie ich es haben wollte..

 

[tschanness]

Danke für die Info

 

[dschense]

Danke für die Info

Gern,.. hat mich ein paar Tage gekostet, bis ich so weit gekommen bin..
Mich würde natürlich interessieren, ob es bei anderen auch so funktioniert.
(Ich wollte ungern auf Proxmox verzichten - ungeachtet davon, dass der Passthrough mit ESXi auch nur teilweise, bis gar nicht funktioniert hat. Auch mit älteren Versionen / 5.5, 5.1, 5.0, etc)

Es liegt in diesem Fall also wirklich am OS was auf den Server gespielt wird. (bzw. am Kernel und glaube auch an der qemu Version)

Vielleicht bekommen wir die Geschichte ja auch noch mit einer neueren Version als 3.X zum laufen.

zum Aufbau:
Ich habe meine Systemplatte (SSD) am ODD Port des Gen8 hängen und diese als Raid0 gesetzt (um das Booten von USB oder SD zu umgehen.
der P410 Controller hat derzeit 2x 1TB Platten, die ich zum testen derzeit auch jeweils als Raid0 betreibe.

In den nächsten Tests, wenn ich dazu komme, möchte ich natürlich testen, ob auch ein Hardwareraid problemlos durchgereicht wird..
Also ein Mirror bei 2 Platten, oder ein Raid5, wenn ich mal mehr haben sollte.

 

[zeha]

$Kollege hat sich das in den letzten Tagen auch angesehen und dann aufgegeben; hat aber auch festgestellt dass es vielleicht gar nicht so sinnvoll ist einen SCSI/RAID-Controller an einen Guest durchzugeben. Für Storage sollte man wohl besser direkt Volumes durchgeben, und wenns um andere SCSI Devices geht ist dann ein iSCSI Target möglicherweise stabiler bzw. sogar angenehmer zu verwenden...

 

[dschense]

$Kollege hat sich das in den letzten Tagen auch angesehen und dann aufgegeben; hat aber auch festgestellt dass es vielleicht gar nicht so sinnvoll ist einen SCSI/RAID-Controller an einen Guest durchzugeben. Für Storage sollte man wohl besser direkt Volumes durchgeben, und wenns um andere SCSI Devices geht ist dann ein iSCSI Target möglicherweise stabiler bzw. sogar angenehmer zu verwenden...

Magst du mir vielleicht erklären, aus welchem Grund ein Durchreichen eines SCSI/RAID-Controllers an eine VM nicht sinnvoll ist?

Mit dem von mir angegebenen Setup oben läuft die sache bei mir absolut problemlos.
Ich habe derzeit zum testen 2x 1TB Platten an dem Controller hängen, beide Platten als Raid0 gesetzt. Den Controller über Proxmox an eine Openmediavault VM durchgereicht. Controller und beide Platten werden problemlos erkannt. Habe dann in OMV ein SoftwareRaid erstellt (Mirror). und das funktioniert absolut problemlos.. Als Dateisystem dann ext4.
Die Freigabe über NFS ergibt bei mir einen Durchsatz von ca. 120 MB/s und via SMB/CIFS bekomme ich sogar zwischen 140-180 MB/s.

Als nächstes werde ich noch testen, wie sich das System verhält, wenn ich die Platten am Controller nicht als Raid0 setze, sondern dort bereits den Mirror erstelle und den Controller das Raid verwalten lasse. in OVM dann kein Software-Raid, sondern dort auf das bestehende Hardware-Raid nur ein Dateisystem drauf.

 

[dschense]

Weiteres Update:

Der Passthrough funktioniert nun auch mit dem proxmox 4.4 Paket:

proxmox-ve: 4.4-76 (running kernel: 4.4.35-1-pve)
pve-manager: 4.4-1 (running version: 4.4-1/eb2d6f1e)
pve-kernel-4.4.35-1-pve: 4.4.35-76
pve-kernel-4.4.19-1-pve: 4.4.19-66
lvm2: 2.02.116-pve3
corosync-pve: 2.4.0-1
libqb0: 1.0-1
pve-cluster: 4.0-48
qemu-server: 4.0-101
pve-firmware: 1.1-10
libpve-common-perl: 4.0-83
libpve-access-control: 4.0-19
libpve-storage-perl: 4.0-70
pve-libspice-server1: 0.12.8-1
vncterm: 1.2-1
pve-docs: 4.4-1
pve-qemu-kvm: 2.7.0-9
pve-container: 1.0-88
pve-firewall: 2.0-33
pve-ha-manager: 1.0-38
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u2
lxc-pve: 2.0.6-2
lxcfs: 2.0.5-pve1
criu: 1.6.0-1
novnc-pve: 0.5-8
smartmontools: 6.5+svn4324-1~pve80
zfsutils: 0.6.5.8-pve13~bpo80

Ich habe mich an diesem Thread entlang gehangelt:
https://forum.proxmox.com/threads/help-with-pci-passthrough.23980/

die entscheidende Lösung hat chrisaw in seinem Post geliefert.

um mit dem Proliant Microserver Gen8 den PCI(e) Passthrough ans laufen zu bekommen muss man den rmrr-check aus dem Kernel entfernen und den Kernel selbst kompilieren.
Das entfernen des rmrr-checks ist natürlich ein Sicherheitsrisiko,.. das ist mir durchaus bewusst..
Aber es funktioniert immerhin

Wie folgt bin ich vorgegangen:

Abhängigkeiten bzw. benötigte Pakete herunterladen:

$ apt-get install git screen fakeroot build-essential devscripts libncurses5 libncurses5-dev libssl-dev bc flex bison libelf-dev libaudit-dev libgtk2.0-dev libperl-dev libperl-dev asciidoc xmlto gnupg gnupg2

Download der Sources:

git clone git://git.proxmox.com/git/pve-kernel.git

(es sind ca. 4,5 GB)

danach muss der Patch angewendet werden:

Der Patch von Cainsaw sah wie folg aus:

--- ubuntu-xenial/drivers/iommu/intel-iommu.c.orig      2016-11-24 08:16:14.101871771 +0100
+++ ubuntu-xenial/drivers/iommu/intel-iommu.c   2016-11-24 08:17:36.581195062 +0100
@@ -4797,11 +4797,6 @@ static int intel_iommu_attach_device(str
        int addr_width;
        u8 bus, devfn;
-       if (device_is_rmrr_locked(dev)) {
-               dev_warn(dev, "Device is ineligible for IOMMU domain attach due to platform RMRR requirement.  Contact your platform vendor.\n");
-               return -EPERM;
-       }
-
        /* normally dev is not mapped */
        if (unlikely(domain_context_mapped(dev))) {
                struct dmar_domain *old_domain;

abgewandelt auf den ubuntu-xenial kernel sieht das ganze dann so aus:

--- ubuntu-xenial/drivers/iommu/intel-iommu.c   2016-12-05 10:04:59.000000000 +0100
+++ ubuntu-xenial/drivers/iommu/intel-iommu.c.BACKUP    2016-12-19 11:17:35.897891365 +0100
@@ -4807,11 +4807,6 @@
        int addr_width;
        u8 bus, devfn;
-       if (device_is_rmrr_locked(dev)) {
-               dev_warn(dev, "Device is ineligible for IOMMU domain attach due to platform RMRR requirement.  Contact your platform vendor.\n");
-               return -EPERM;
-       }
-
        /* normally dev is not mapped */
        if (unlikely(domain_context_mapped(dev))) {
                struct dmar_domain *old_domain;

Um dieses Patchfile zu erstellen muss man wie folgt vorgehen:

$ apt-get install patch

patchfile erstellen:

ubuntu-xenial.tgz entpacken:

tar -xvzf ubuntu-xenial.tgz

zu ubuntu-xenial/drivers/iommu/intel-iommu.c navigieren:

cd ubuntu-xenial/drivers/iommu/

$ cp ubuntu-xenial/drivers/iommu/intel-iommu.c ubuntu-xenial/drivers/iommu/intel-iommu.c.BACKUP
$ nano ubuntu-xenial/drivers/iommu/intel-iommu.c.BACKUP

diese Zeilen entfernen:

if (device_is_rmrr_locked(dev)) {
              dev_warn(dev, "Device is ineligible for IOMMU domain attach due to platform RMRR requirement.  Contact your platform vendor.\n");
               return -EPERM;
       }

danach wieder in den Hauptordner pve-kernel zurücknavigieren und den patch erstellen:

$ diff -u ubuntu-xenial/drivers/iommu/intel-iommu.c ubuntu-xenial/drivers/iommu/intel-iommu.c.BACKUP > remove_mbrr_check.patch

darauf sollte das file: remove_mbrr_check.patch
mit etwa folgendem Inhalt im pve-kernel Ordner erscheinen:

--- ubuntu-xenial/drivers/iommu/intel-iommu.c   2016-12-05 10:04:59.000000000 +0100
+++ ubuntu-xenial/drivers/iommu/intel-iommu.c.BACKUP    2016-12-19 11:17:35.897891365 +0100
@@ -4807,11 +4807,6 @@
        int addr_width;
        u8 bus, devfn;

-       if (device_is_rmrr_locked(dev)) {
-               dev_warn(dev, "Device is ineligible for IOMMU domain attach due to platform RMRR requirement.  Contact your platform vendor.\n");
-               return -EPERM;
-       }
-
        /* normally dev is not mapped */
        if (unlikely(domain_context_mapped(dev))) {
                struct dmar_domain *old_domain;

Jetzt muss der Patch noch in das Makefile des Kernels gepackt werden, dass die Änderungen beim kompilieren angewendet werden:

$ nano Makefile

nach der Zeile:

cd ${KERNEL_SRC}; patch -p1 <../bridge-patch.diff

einfach folgende Zeile einfügen:

cd ${KERNEL_SRC}; patch -p1 <../remove_mbrr_check.patch

dann speichern und den Kompilierprozess starten:

$ make

Der Vorgang kann einige Zeit bis zu mehreren Stunden, je nach Hardware, in Anspruch nehmen,..

wenn der Vorgang abgeschlossen ist solltet ihr in eurem Kernel Ordner mehrere .deb Dateien haben.
die werden jetzt installiert:

linux-tools-4.4_4.4.35-76_amd64.deb
proxmox-ve_4.4-76_all.deb
pve-firmware_1.1-10_all.deb
pve-headers-4.4.35-1-pve_4.4.35-76_amd64.deb
pve-headers_4.4-76_all.deb
pve-kernel-4.4.35-1-pve_4.4.35-76_amd64.deb

installiert werden die via:

$ dpkg -i *.deb

danach vorsichtshalber noch ein:

$ update-initramfs -u
$ update-grub

Einstellungen in Proxmox:

/etc/default/grub anpassen
--->

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"

ich brauche nicht mehr in meiner Zeile. Es wird soweit alles gut erkannt


/etc/modules folgendes einfügen um die vfio Module beim boot zu laden:
--->

vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd

Treibermodul auf die Blacklist:
/etc/modprobe.d/blacklist.conf und darin:

blacklist hpsa

da über lspci -vvv: Kernel driver in use: hpsa angeigt wurde.

danach noch initramfs neu schreiben:
update-initramfs -u

und Grub updaten:
update-grub

danach alles neu starten !!!!!

nach dem Reboot folgendes in die vm.conf eintragen:
--->

hostpci0: 07:00.0

Mehr braucht es bei mir nicht.

und schon hatte ich den RaidController in meiner Openmediavault VM. Zugriff auf den Controller, auf die Platten und und und..

 

[dschense]

Ich habe festgestellt, dass der Passthrough nur einmal funktioniert. Also nach einem reboot oder shutdown und erneutem start der VM wird der Controller zwar vom System "irgendwie" erkannt, kann aber in der VM keinem Slot zugewiesen werden.
Das heißt die VM startet nicht mehr.
Um das ganze dann wieder zum Laufen zu bekommen muss ich das gesamte System (also den Proxmox Host) neu starten. Danach funktioniert die Zuweisung und das Starten der VM dann wieder einmal, bis es einen erneuten Reboot gibt.

Vielleicht weiß ja zufällig jemand woran das liegen könnte.

 

[fireon]

Hallo Leute,

nicht böse sein, aber ich kann mir das hier nicht mehr ansehen. Könnte mir mal bitte irgendjemand wirklich plausibel und technisch erklären was es um Gottes Willen für einen Sinn hat einen Raidcontroller in eine VM durch zureichen. Das hat meines achtens nur viel mehr Arbeit, mehr Probleme und absolut keinen Vorteil. Und wenn ich ein NAS haben will dann installier ich mir auch eins und virtualisiere es nicht das macht es ja alles noch komplexer und Fehleranfälliger.

PVE kann selbst NAS/Storage spielen mit ZFS und Co.

 

[bk_81]

Hi,

ich habe genau das gleiche Problem und Vorhaben wie dschense und würde auch gerne unter Proxmox den Controller an eine VM durchreichen.

Warum?

Ich will eine klare Trennung zwischen dem Host der die VMs bereitstellt und den angebotenen Services.
Aktuell laufen bei mir 2 HP Microserver mit ESXi 6.5 und es sind jeweils die HBAs an je eine VM durchgereicht.

ESXi1 VMs:
1.) DomainController (Win2008R2)
2.) FreeNAS (Controller durchgereicht, PLEX)
3.) Sophos UTM (im HA-Verbund)
4.) Univention Corporate Server als MemberServer für Benutzerprofile

ESXi2 VMs:
1.) DomainController
2.) OMV ( Controller durchgereicht, für Backups)
3.) Sophos UTM (im HA-Verbund)
4.) UbuntuServet mit Nextcloud
5.) WindowsServer2012R2 Foundation HP ROK für EcoDMS und PasswordDepotServer, DocusnapX

Dies soll nur veranschaulichen was mit diesen kleinen Kisten von HP möglich ist und dient mir zu Hause als Spielwiese und wird aus Spaß an der Freude eingesetzt.

In jedem Server ist eine XEON CPU, 16GB RAM sowie 4x 3,5" HDD, 3x SSD und 2x 2,5" HDD verbaut.

Die Möglichkeiten sind also vielfältig.

@dschense
Vielen Danke für Deine Mühe und Hut ab dafür. Ich hoffe es gelingt dir noch. Ich würde nämlich auch gerne mal über den ESXi-Tellerrand schauen.

Gruß

 

[dschense]

@bk_81
Vielen Dank für deinen ausführlichen Post. Ich hätte es mit Sicherheit nicht besser sagen können ;-)
Meine kleine Kiste hat auch meist bis zu 6 Maschinen durchgängig am Laufen.. Deswegen ist mir eine strikte Trennung auch sehr wichtig.
Es ist kein wirkliches Produktivsystem. Eine Spielwiese trifft es bei mir auch sehr gut.. Ich lerne damit, sammle Erfahrungen und möchte das, was ich mir vornehme gerne umsetzen..

@fireon
Böse ist dir mit Sicherheit keiner..
Erfreut wäre der eine oder andere sicherlich gewesen, wenn du etwas produktives beigetragen hättest..
Wenn passthrough Quatsch wäre, würde es nicht eingesetzt werden.. Und so kompliziert ist das gar nicht.. Problematisch in meinem Fall ist lediglich der proliant gen8, da hp sein bios bzw die ROM verpfuscht hat.. Das macht es mit dem passthrough nicht ganz einfach.. Und natürlich, dass seit Kernel 3.16 dieser mbrr Check integriert wurde.

 

[morph027]

Das schöne an einer Trennung ist natürlich, dass man einfach nur VM Configs sichert, den Host neu aufsetzt, VM Config zurückholt und alles läuft wieder. Dummer Host halt. Aber mit gepatchtem Kernel ist das Konzept schon wieder leicht aufgeweicht. Aber da zeigt der Finger schon zu Recht in Richtung HP.

SMB mach ich so: ZFS Datasets per mount-bind in einen LXC reichen, dort dann die Samba-Freigaben.
NFS mach ich (read only) direkt auf dem Host, da die properties ja direkt im ZFS selbst gespeichert sind und man nur neu installiert und es geht einfach

 

[bogo22]

....
SMB mach ich so: ZFS Datasets per mount-bind in einen LXC reichen, dort dann die Samba-Freigaben.
NFS mach ich (read only) direkt auf dem Host, da die properties ja direkt im ZFS selbst gespeichert sind und man nur neu installiert und es geht einfach

Etwas Off-Topic zum Thread aber das interessiert mich
Du hast also einen ZFS Datenpool nativ unter Proxmox und unter einem LXC samba installiert/gebildet von source und dann via
$ echo "mp0: /tank/dataset,mp=/freigabe01" >> /etc/pve/lxc/<lxc-id>.conf
den Dataset dem LXC durchgereicht? Funktioniert das ohne Probleme? So gehen aber sämtliche Daten den 'Umweg' über die VM/LXC richtig? Also quasi über die NIC der LXC und dann über die NIC von Proxmox (wenn ich via passthrough ein Port durchgereicht habe) ?