HP Proliant Microserver Gen8 - RaidController HP P410 - Passthrough Probleme

dschense

Member
Jun 18, 2016
32
2
8
31
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:

Code:
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
Code:
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

Code:
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
Code:
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.
Code:
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:
Code:
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
 

dschense

Member
Jun 18, 2016
32
2
8
31
Damit bekomme ich leider den selben Fehler (die VM wird wieder gestoppt)

EDIT:

with
Code:
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:

Code:
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
 
Last edited:

dschense

Member
Jun 18, 2016
32
2
8
31
Noch ein kleines Update zu meinem Problem:

Ich habe festgestellt, dass mein RaidController sich eine iommu Gruppe teilt. bislang war er in der Gruppe1:
Code:
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:

Code:
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:

Code:
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:
Code:
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
Code:
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:
Code:
quiet intel_iommu=on pcie_acs_override=downstream intremap=no_x2apic_optout
 

dschense

Member
Jun 18, 2016
32
2
8
31
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:

Code:
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:

Code:
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

Member
Jun 18, 2016
32
2
8
31
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/dists/wheezy/pve-no-subscription/binary-amd64/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:

Code:
 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

Member
Jun 18, 2016
32
2
8
31
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:

Code:
#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
--->
Code:
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:
--->
Code:
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd
Treibermodul auf die Blacklist:
/etc/modprobe.d/blacklist.conf und darin:
Code:
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:
--->
Code:
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..
 

dschense

Member
Jun 18, 2016
32
2
8
31
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.
 
Oct 11, 2016
18
1
8
39
$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

Member
Jun 18, 2016
32
2
8
31
$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

Member
Jun 18, 2016
32
2
8
31
Weiteres Update:

Der Passthrough funktioniert nun auch mit dem proxmox 4.4 Paket:

Code:
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:

Code:
$ 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:

Code:
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:
Code:
--- 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:

Code:
--- 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:

Code:
$ apt-get install patch
patchfile erstellen:

ubuntu-xenial.tgz entpacken:
Code:
tar -xvzf ubuntu-xenial.tgz
zu ubuntu-xenial/drivers/iommu/intel-iommu.c navigieren:
Code:
cd ubuntu-xenial/drivers/iommu/
Code:
$ 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:

Code:
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:

Code:
$ 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:

Code:
--- 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:

Code:
$ nano Makefile
nach der Zeile:

Code:
cd ${KERNEL_SRC}; patch -p1 <../bridge-patch.diff
einfach folgende Zeile einfügen:

Code:
cd ${KERNEL_SRC}; patch -p1 <../remove_mbrr_check.patch
dann speichern und den Kompilierprozess starten:

Code:
$ 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:

Code:
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:

Code:
$ dpkg -i *.deb
danach vorsichtshalber noch ein:

Code:
$ update-initramfs -u
$ update-grub
Einstellungen in Proxmox:

/etc/default/grub anpassen
--->
Code:
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:
--->
Code:
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd
Treibermodul auf die Blacklist:
/etc/modprobe.d/blacklist.conf und darin:
Code:
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:
--->
Code:
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..
 
Last edited:
  • Like
Reactions: morph027

dschense

Member
Jun 18, 2016
32
2
8
31
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

Famous Member
Oct 25, 2010
3,143
203
83
37
Austria/Graz
iteas.at
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

New Member
Dec 11, 2016
5
0
1
38
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

Member
Jun 18, 2016
32
2
8
31
@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

Well-Known Member
Mar 22, 2013
433
54
48
Leipzig
morph027.gitlab.io
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

Member
Nov 4, 2016
46
1
11
....
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) ?
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE and Proxmox Mail Gateway. We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!