HP Proliant Microserver Gen8 - RaidController HP P410 - Passthrough Probleme

[morph027]

Jups, dann brauch ich auf dem Proxmox keinen Samba installieren/bauen. Könnte man auch machen, aber lieber nicht

Der Samba Container macht auch gleich noch AD und per ACL-Inherit passen dann auch die ACLs für die Domänennutzer auf dem ZFS Dataset.

Läuft bei mir privat sowie auf einigen Produktivsystemen bei "Kunden" stabil und ohne Probleme.

 

[dschense]

hier noch ein kleines Update zum Reboot der VM mit aktivem Passthrough.
Nach direktem Neustart des Proxmox Hosts funktioniert der Passthrough tadellos.
Sobald die VM aber gestoppt, oder neu gestartet wird erhalte ich das hier.. Ich werde daraus noch nicht so ganz schlau.

 

[dschense]

Ein weiteres Update:

Ich habe es tatsächlich hinbekommen. Ich habe die neuste Version von Proxmox 4.4 am laufen. Ich habe natürlich wie in meinen vorherigen Posts beschrieben den Kernel patchen müssen.

ansonsten habe ich bei der Installation und den Anpassungen nichts verändert. Das einzige was bislang mein Problem war - Ich konnte zwar beim ersten start des Hosts den Controller via passthrough an einen Gast durchreichen, aber sobald ich einen Neustart oder Shutdown des Gasts durchführen musste, konnte ich den Controller nicht mehr an den Gast durchreichen. (Nur ein Host reboot konnte das Problem lösen).
Ich bekam keine wirkliche Fehlermeldung, sondern bekam beim booten der VM nur den Status wie im Bild meines vorherigen Posts.

Lösen konnte ich das Problem indem ich von SeaBios zu OVMF gewechselt bin.
Ich habe die VM also gelöscht und neu aufgesetzt. Als Bios wie schon gesagt OVMF ausgewählt, unter Hardware noch ein EFI-Laufwerk hinzugefügt.
Vor dem ersten Start der VM (also vor der Installation) habe ich noch in der vm.conf (in meinem Fall die 101.conf unter //etc/pve/qemu-server)
folgendes hinzugefügt:

hostpci0: 07:00.0

meine Config sieht dann wie folgt aus:

bios: ovmf
boot: cdn
bootdisk: virtio0
cores: 4
efidisk0: local:101/vm-101-disk-2.qcow2,size=128K
hostpci0: 07:00.0
ide2: local:iso/debian-7.11.0-amd64-netinst.iso,media=cdrom,size=222M
memory: 4096
name: NAS
net0: virtio=BA:67:38:52:C2:3F,bridge=vmbr0
numa: 0
ostype: l26
scsihw: virtio-scsi-pci
smbios1: uuid=f92b4596-2cab-4e8a-844b-a284c8c4abd1
sockets: 1
virtio0: local:101/vm-101-disk-1.qcow2,size=15G

Danach habe ich die VM gestartet.
In meinem Fall habe ich ein nacktes Debian wheezy installiert. Schon bei der Installation wurde mein durchgereichter Controller samt Platten (mit RAID1) erkannt.

nach meiner Installation habe ich die VM mehrfach neu gestartet (sowohl via reboot, als auch shutdown und komplettem Start). bei jedem Start wurde mir der Controller und die zugehörigen Platten durchgereicht.

Nachdem das funktionierte habe ich das passende Openmediavault drüber installiert.
Für die, die nicht wissen wie das geht verlinke ich auf das Tutorial aus dem OMV-Forum:

http://forum.openmediavault.org/ind...-install-OpenMediaVault-on-Debian-7-x-Wheezy/

Nach diesen schritten wieder einen kompletten shutdown und einen Neustart. Und siehe da. Der Controller samt Platten wird wieder in den Gast durchgereicht.
Auch das Anlegen eines Volumes bzw. das Einbinden eines Volumes funktioniert tadellos.

Ich werde das jetzt ein wenig testen (auch was den Speed und natürlich die Stabilität angeht) aber bislang sieht mir die Geschichte sehr vielversprechend aus.

Ich hoffe ich kann damit dem Einen oder Anderen helfen.

 

[bk_81]

Hi,

das lese ich gerne. Ich werde am Wochenende mich gleich daran versuchen.
Sau stark!!!

Kannst du alle nötigen Schritte hier in eine Art Mini-HowTo zusammenfassen?
Ich habe mich das letzte Mal vor 10 Jahren mit dem kompilieren eines Kernels auseinandersetzen dürfen und befürchte daher viele Stunden Frust/Googlen/lesen.

Ich kann mich noch dunkel daran erinnern, dass es möglich war, dass man am Ende der Übersetzung auch .deb-Paket erhalten kann. Das würde mir ungemein helfen, da ich 2 HP Microserver betreibe und so mir nur einmal die Arbeit machen müsste. Sobald wieder ein neuer Kernel zur Verfügung gestellt würde, ginge doch der ganze Spaß wieder von vorne los, oder?

Gruß

 

[dschense]

Hi,

das lese ich gerne. Ich werde am Wochenende mich gleich daran versuchen.
Sau stark!!!

Kannst du alle nötigen Schritte hier in eine Art Mini-HowTo zusammenfassen?
Ich habe mich das letzte Mal vor 10 Jahren mit dem kompilieren eines Kernels auseinandersetzen dürfen und befürchte daher viele Stunden Frust/Googlen/lesen.

Ich kann mich noch dunkel daran erinnern, dass es möglich war, dass man am Ende der Übersetzung auch .deb-Paket erhalten kann. Das würde mir ungemein helfen, da ich 2 HP Microserver betreibe und so mir nur einmal die Arbeit machen müsste. Sobald wieder ein neuer Kernel zur Verfügung gestellt würde, ginge doch der ganze Spaß wieder von vorne los, oder?

Gruß

Schau mal in Post #9 des Themas. Da habe ich bereits alle meine Schritte zusammen gefasst. Die sollten dir dabei eigentlich gut helfen. Ansonsten einfach Fragen.
Ich habe mir zum Testen ein virtuelles proxmox eingerichtet. Da funktioniert das alles wunderbar. Kompilieren, testen und wenn alles geht die debs auf den host und installieren.

 

[lyter]

Grandios! Hatte exakt dasselbe Problem beim Durchreichen eines RAID-Controllers mit einem HP ML310e und hatte die Hoffnung aufgegeben und mir geschworen nie mehr einen HP-Server zu kaufen!

Werde mich am Wochenende auch daran versuchen.
Kannst du noch auf bk_81s Frage eingehen?

Sobald wieder ein neuer Kernel zur Verfügung gestellt würde, ginge doch der ganze Spaß wieder von vorne los, oder?

Wird das nötig sein? Wie siehts mit Proxmox-Updates aus?

Sehr cool, dass du hier deinen (Miss-)Erfolg so gut dokumentierst!

 

[dschense]

Grandios! Hatte exakt dasselbe Problem beim Durchreichen eines RAID-Controllers mit einem HP ML310e und hatte die Hoffnung aufgegeben und mir geschworen nie mehr einen HP-Server zu kaufen!

Werde mich am Wochenende auch daran versuchen.
Kannst du noch auf bk_81s Frage eingehen?


Wird das nötig sein? Wie siehts mit Proxmox-Updates aus?

Sehr cool, dass du hier deinen (Miss-)Erfolg so gut dokumentierst!

Ja, bei jedem Kernel Update musste dieser dementsprechend angepasst werden, solange von Proxmox Seiten nichts an der Source verändert wird.
Ich sehe da aber kein Großes Problem darin. Man hat ja immer ein Auge darauf, welche Paket Updates anstehen.. Somit habe ich noch ein virtuelles proxmox, unter welchem ich den Kernel kompiliere und dann bei Bedarf die Pakete via .deb Files Update.

Es gibt bestimmt eine elegantere Variante.. Bin da für Vorschläge oder Kritik immer offen..

Bekomme übrigens auf diese Weise einen speed von ca. 110 - 120 mb/s schreibend und lesend.. Kann man bestimmt noch was machen (verwende derzeit openmediavault als Gastsystem an das der Kontroller mit 2 X 1TB Platten im Raid1 durchgereicht wird.)

 

[lyter]

Habe Proxmox 4.4 gemäss Anleitungen installiert und läuft nun seit ein paar Tagen. Nochmals besten Dank für deine Mühe dschense!
Werde mich aber hüten jedes Update von Proxmox zu installieren, da der Aufwand einfach zu gross ist.

 

[dschense]

Habe Proxmox 4.4 gemäss Anleitungen installiert und läuft nun seit ein paar Tagen. Nochmals besten Dank für deine Mühe dschense!
Werde mich aber hüten jedes Update von Proxmox zu installieren, da der Aufwand einfach zu gross ist.

Das freut mich ;-)
So groß ist der Aufwand eigentlich gar nicht ;-) das Prozedere sollte eigentlich nur gemacht werden müssen, sobald es Kernel Updates gibt.. Und der Kernel muss ja nur einmal kurz kompiliert werden..
Aber das bleibt ja jedem selbst überlassen ;-)

 

[dschense]

Ich habe für die ganze Geschichte mal ein Repo auf Github aufgemacht. Da sind dann auch meine kompilierten Pakete drin, falls jemand sich die Mühe nicht machen möchte diese selbst zu bauen.

https://github.com/dschense/Proxmox-HP-Proliant-Microserver-Gen8-PCIE-Passthrough

 

[dschense]

Nur zur Information:

Die pve-kernel-4.4.35-2-pve-4.4.35-79 scheint nicht zu funktionieren.
Ich bekomme zwar keinerlei Fehlermeldung (bislang), der Kontroller wird wohl auch durchgereicht, vom System aber nicht wirklich erkannt.
Ich habe auf dem System die Updates und die betreffenden .deb Pakete installiert, musst aber nochmal auf den Kernel: pve-kernel-4.4.35-1-pve-4.4.35-77 zurück um das Passthrough weiterhin lauffähig zu lassen.
Vielleicht kann jemand anderes das selbst noch ausprobieren, und mir eine Rückmeldung geben, ob es vielleicht nur an meinem System, oder der durchzureichenden VM liegt.

EDIT 30.01.2017:
Ich habe mit dem Update ein wenig rumgespielt, bin aber leider nicht erfolgreich gewesen.. ganz im Gegenteil. Ich musste das OMV an das der Kontroller durchgereicht wird reparieren, da das Raid irgendwie kaputt gegangen ist.
Ich bin wieder auf meine alte, lauffähige Version zurück --> pve-kernel-4.4.35-1-pve-4.4.35-77, da durch das Update auf pve-kernel-4.4.35-2-pve-4.4.35-79 wohl noch etwas anderes geändert wurde, was meine Maschinen nicht mehr booten lässt. Nach dem Rollback und dem reparieren der VM funktioniert alles wieder wie davor.

 

[tschanness]

Hi,
https://forum.proxmox.com/threads/4...-for-mem-size-0x-pref-failed-to-assign.32557/
Vielleicht gibt es hier einen Zusammenhang? Habe es mir aber nicht genau angeschaut.

LG Jonas

 

[zeipet]

Hallo Leute! Wie schaut es aus? Kann ich mich drübertrauen?
Meine HW:
Proloant Microserver Gen8 12GB Ram
Xeon E3-1231 V2
Smartarray P410 512 Flash
3x Seagate IronWolf 4 TB, ST4000VN008
SSD PNY CS1311 Interner Flash-Speicher SSD 2,5 " 120GB SATA III
MicroSD 64GB
Ich habe KVM auf Ubuntu, ESXI 6 und 6.5 getestet, immer habe ich Probleme mit dem PCI Passthought des P410 Probleme.
Ich vermute, dass es der Umstand ist, dass die SSD am internen Raid Controller hängt und dieser Irgenwie etwas blockiert.
Auf jedenfall bekomme ich am ESXI purple Screen, beim Vm beenden. (komisch) Im Betrieb sehe ich den Controller, aber keine Laufwerke.
KVM fährt mir die VM einfach nicht hoch.

Hintergrund ist, ich will auf meinen Platten ein NTFS Filesystem lassen, da ich eine BAckup WIndows Maschine mit gleichem P410 habe.

Hat jemand auch den P410 im Einsatz?

LG Peter

 

[dschense]

Hallo Leute! Wie schaut es aus? Kann ich mich drübertrauen?
Meine HW:
Proloant Microserver Gen8 12GB Ram
Xeon E3-1231 V2
Smartarray P410 512 Flash
3x Seagate IronWolf 4 TB, ST4000VN008
SSD PNY CS1311 Interner Flash-Speicher SSD 2,5 " 120GB SATA III
MicroSD 64GB
Ich habe KVM auf Ubuntu, ESXI 6 und 6.5 getestet, immer habe ich Probleme mit dem PCI Passthought des P410 Probleme.
Ich vermute, dass es der Umstand ist, dass die SSD am internen Raid Controller hängt und dieser Irgenwie etwas blockiert.
Auf jedenfall bekomme ich am ESXI purple Screen, beim Vm beenden. (komisch) Im Betrieb sehe ich den Controller, aber keine Laufwerke.
KVM fährt mir die VM einfach nicht hoch.

Hintergrund ist, ich will auf meinen Platten ein NTFS Filesystem lassen, da ich eine BAckup WIndows Maschine mit gleichem P410 habe.

Hat jemand auch den P410 im Einsatz?

LG Peter

Laut deinen Angaben sollte es meines Erachtens nach problemlos mit Proxmox funktionieren.
Ich habe meine SSD am ODD Port des internen Adapters angeschlossen (wovon ich auch boote) Auf der SSD laufen das Proxmox System und die VMs.
Meinen Raid Controller habe ich am PCIe Port hängen und reiche diesen dann komplett via passthrough an eine meiner VMs durch.

Halte dich an die Anleitung die ich hier schon geschrieben habe, dann sollte das flutschen
https://forum.proxmox.com/threads/h...-p410-passthrough-probleme.30547/#post-155675

Vom neusten Kernel update würde ich allerdings bislang noch absehen. Bei meinem letzten Versuch das mit dem Update ans laufen zu bekommen funktionierte der Passthrough nur zum Teil. Der Controller wurde zwar an die VM durchgereicht (via qm monitor konnte ich das sehen), allerdings konnte die VM dann nicht ordnungsgemäß gestartet werden. Sie bekam beim Bootvorgang eine Kernelpanic und sprang in die emergency Konsole.

Grüße

 

[zeipet]

Hallo dschense mein Mentor.
Ich hab gerade den ESXI geschrottet und spiel gerade das Image drauf. Ich werde das ganze mit deinen Kompillierten Files installieren, da ich jetzt das ganze Wochenende schon dran rumgespielt hab.

Ich werde mich bei einem Fail oder Sucess wieder melden.

PS: Ich habe vorher von Proxmox noch nicht so viel gehört. Es basiert ja auf KVM und ist kommerziell.
Welche möglichkeiten habe ich in der Free-Version? Gits eine gute Backuplösung?

LG Peter

 

[dschense]

Hallo dschense mein Mentor.
Ich hab gerade den ESXI geschrottet und spiel gerade das Image drauf. Ich werde das ganze mit deinen Kompillierten Files installieren, da ich jetzt das ganze Wochenende schon dran rumgespielt hab.

Ich werde mich bei einem Fail oder Sucess wieder melden.

PS: Ich habe vorher von Proxmox noch nicht so viel gehört. Es basiert ja auf KVM und ist kommerziell.
Welche möglichkeiten habe ich in der Free-Version? Gits eine gute Backuplösung?

LG Peter

Als Mentor wurde ich mich jetzt nicht gerade bezeichnen XD aber denke ;-)

Dann hast du ja jetzt die besten Vorraussetzungen um mit proxmox anzufangen.
Du solltest dir evtl die Manpages bzw das Wiki von Proxmox durchlesen.. Proxmox ist sehr umfangreich, sodass man sich wirklich eingehend damit beschäftigen sollte.
Proxmox basiert zuerst einmal auf Debian, und ja, proxmox nutz kvm und qemu, bzw lxc für seine kontainer.
Wenn du meine Files benutzt, nimm die älteren Dateinen. Die neueren auf Github sind leider nicht funktionsfähig.
Was das Backup angeht.. Proxmox unterstützt snapshots, Backups als tar.gz und weitere tolle Möglichkeiten..
Die Free-Version schränkt sich auf keine Art ein. Du bekommst lediglich beim Login einen popup mit dem Hinweis, dass du nur die kostenlose Version verwendest. Und du bekommst Änderungen bei Updates etwas später.. Das ist aber auch schon alles.

Ich rate dir wirklich, dich über die Wiki etwas zu belesen, dass du die Grundzüge des ganzen verstehst und die nicht zu viel unnötige Arbeit machst.

 

[zeipet]

Hallo!
Alles was das Virtualisieren und den pve-Kernel patchen betrifft hat bestens funktioniert.
Es läuft nun pve-kernel-4.4.35-1-pve: 4.4.35-77
Der Controller wird durchgereicht und erscheint beim Gast. Server2008r2 mekkert aber noch, dass er das Gerät nicht starten kann Error10.
Ich kann auch den Gast ohne Probleme durchstarten. Nur sehe ich das Bios des P410 nicht im Post des Gastes beim starten.
Bei dir gab es aber einen Screenshot mit dem Bios Post (der bunte)
Liegt das am Sea Bios?
Hab auch eine Fehlermeldung beim starten des Gastes gefunden, sagt euch das etwas?:

DMAR: DRHD: handling fault status reg 3
DMAR: DMAR: [DMA Read] Request device [07:00.0] fault addr f1f93000
DMAR: [fault reason 06] PTE Read access is not set

hatte "intel_iommu=pt" probiert, dann wird aber nichts durchgereicht.

Naja muss vermutlich den Gast neu aufsetzen, hatte ein altes KVM Image genommen.

Für heute ist auf jedenfall Schluss und begnüge mich mit der erfolgreichen Installation und keinen "purple Screen of death" wie beim ESXI.
Hatte übrigens auch einen anderen P410 getestet um einen Hardwarefehler auszuschließen.

LG Peter

 

[zeipet]

*Push*
Ich komme nicht weiter mit dem durchreichen meiner P410 Raidkarte. Am Server und an der Karte kann es nicht liegen, da ich schon eine andere Karte verwendet habe. Kann es im ILO an den Einstellungen liegen?
Ich habe den P410 auf IRQ 10 laufen. Allerdings ändern sich die IRQ auch vom: ILO, Matrox und Netzwerkschnittstelle1 mit, haben also immer die gleiche Adresse.
Ist dies bei euch auch so? Könnt Ihr mir eure ILO Einstellungen zeigen?
Ich bekomme nach dem ersten mal einbinden des Reidcontrollers in eine VM diese Meldung:
DMAR: DMAR: [DMA Read] Request device [07:00.0] fault addr f1f93000
DMAR: [fault reason 06] PTE Read access is not set
Dann erst wieder nach einem Reboot des Hostes.

LG Grüße Peter

Infos:
root@ProliantKVM:~# 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
root@ProliantKVM:~# 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: fast devsel, IRQ 16
Memory at fbe00000 (64-bit, non-prefetchable) [disabled] [size=2M]
Memory at fbdf0000 (64-bit, non-prefetchable) [disabled] [size=4K]
I/O ports at 5000 [disabled]
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

root@ProliantKVM:~# pveversion -v
proxmox-ve: 4.4-77 (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-77
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+deb8u3
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
root@ProliantKVM:~#

VM.conf: (Ich habe auch nur hostpci0: 07:00.0 oder hostpci0: 07:00.0,pcie=1 getestet)
balloon: 512
bios: ovmf
boot: dc
bootdisk: ide0
cores: 2
cpu: IvyBridge
efidisk0: UsbDisk:102/vm-102-disk-1.qcow2,size=128K
ide0: UsbDisk:102/vm-102-disk-2.qcow2,size=40G
ide2: UsbDisk:iso/virtio-win-0.1.126.iso,media=cdrom,size=152204K
machine: q35
hostpci0: 07:00.0
memory: 3000
name: Server2008r2-NAS
net0: e1000=82:687:51:4C:0A,bridge=vmbr0
numa: 0
ostype: win7
smbios1: uuid=1086f775-e702-4ffb-a248-4200aeae00c6
sockets: 1

Kernel:
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"

ILO: iLO Firmware Version 2.30 Aug 19 2015

 

[dschense]

Sorry, für die verspätete Antwort.
So wie ich es bis jetzt rauslesen konnte benutzt du das SeaBios. Damit hatte ich auch durchgehend Probleme.
Bei mir wurde der Controller zwar durchgereicht und von der VM erkannt, allerdings konnte ich das System dann einfach nicht booten. Ich bekam ständig eine Kernel-Panic.

Bei mir funktioniert die Geschichte wirklich nur in Verbindung mit OVMF als Bios und natürlich einer EFI Bootpartition.
Ich boote damit Debian und Ubuntu Problemlos (Mit Windows habe ich es nicht ausprobiert und kann dir daher nicht sagen, ob es damit auch funktioniert)

Ich habe im Bios des Proxmox Hosts lediglich VT-d aktiviert. Sonst habe ich nichts verändert. anbei meine Ausgaben:

proxmox-ve: 4.4-77 (running kernel: 4.4.35-1-pve)
pve-manager: 4.4-5 (running version: 4.4-5/c43015a5)
pve-kernel-4.4.35-1-pve: 4.4.35-77
lvm2: 2.02.116-pve3
corosync-pve: 2.4.0-1
libqb0: 1.0-1
pve-cluster: 4.0-48
qemu-server: 4.0-102
pve-firmware: 1.1-10
libpve-common-perl: 4.0-85
libpve-access-control: 4.0-19
libpve-storage-perl: 4.0-71
pve-libspice-server1: 0.12.8-1
vncterm: 1.2-1
pve-docs: 4.4-1
pve-qemu-kvm: 2.7.1-1
pve-container: 1.0-90
pve-firewall: 2.0-33
pve-ha-manager: 1.0-38
ksm-control-daemon: 1.2-1
glusterfs-client: 3.5.2-2+deb8u3
lxc-pve: 2.0.6-5
lxcfs: 2.0.5-pve2
criu: 1.6.0-1
novnc-pve: 0.5-8
smartmontools: 6.5+svn4324-1~pve80

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/2/devices/0000:02:00.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

Mein Controller wäre hier: 0000:07:00.0
Der Teilt sich die Iommu Gruppe also mit 0000:00:01.0
funktioniert bei mir aber trotzdem Problemlos.

Meine /etc/default/grub hat nur folgende Zeile:

GRUB_CMDLINE_LINUX_DEFAULT="intel_iommu=on"

und meine VM.conf sieht folgendermaßen aus:

bios: ovmf
boot: cdn
bootdisk: virtio0
cores: 4
efidisk0: local:101/vm-101-disk-2.qcow2,size=128K
ide2: none,media=cdrom
memory: 4096
name: NAS
net0: virtio=BA:67:38:52:C2:3F,bridge=vmbr0
numa: 0
ostype: l26
parent: jessie
scsihw: virtio-scsi-pci
smbios1: uuid=f92b4596-2cab-4e8a-844b-a284c8c4abd1
sockets: 1
startup: order=3
virtio0: local:101/vm-101-disk-1.qcow2,size=15G
hostpci0: 07:00.0

Ich hoffe das hilft dir ein wenig weiter.
Vielleicht hilft es auch schon dei VM, an die du den Controller durchreichen möchtest einfach mit den von mir genannten Settings einfach komplett neu aufzusetzten.

 

[zeipet]

Hallo dschense,
Leider habe ich schon Server2008r2 mit ovmf Bios neu aufgesetzt, meine letzten Einstellen sind deinen recht ähnlich bis auf den ide0 den ich als Bootplatte verwende.

Als ich dann noch etwas getestet habe habe ich den Controller nochmal im Proxmox host eingebunden und festgestellt, dass ich nur einen Datendurchsatz von max 30MB/s mit Netperf messe... Das durfte mit dem ntfs Filesystem ja nicht zusammenhängen, da ich ja das /dev angegeben habe. Im Server2008r2 hatte ich 130mb/s am anfang, später wenn der cache aus war etwa 95mb/s.
=> Ich denke, dass der Kernel irgend ein Problem mit den Raidcontroller hat, ich komme einfach nicht drauf welches.
Als nächstes werde ich auch auf einem neuem Debian Guest mal den Datendurchsatz zu meinem Volume testen

Ich bin über jeglichen Hinweis dankbar!

Lg Peter


EDIT:

Ich habe es nun anders gelöst, ich habe cpqacuxe vom repo http://downloads.linux.hpe.com/SDR/downloads/MCP/debian besorgt.
Seidem habe ich komischerweise einen guten Durchsatz (etwa 170mb/sec!!! cached)
Deshalb binde ich die ganzen Volumes über Virtio ein:

virtio2: /dev/disk/by-id/wwn-0x600508b1001c56dc400a9ee763eacccb
virtio3: /dev/disk/by-id/wwn-0x600508b1001cffc83cdbddb9373747df

komme nun auf 120 - 170 mb/sec über Windows SMB mit NTFS.

Also alles was ich wollte.
Nun sollte ich auch wieder den original PVE-Kernel nehmen können.

Danke auf jedenfall für deine Hilfe dschense, hätte sonst Proxmox sicher nicht getestet.
VMWare EsxI kann auf jedenfall NICHT ein ganzes Volume an Windows überreichen.
Zumindest nicht mit meinem P410.

LG Peter