PCI Passthrough zu Debian Jessie Guest

[m0nKeY]

Hallo,

ich hoffe das Thema ist hier richtig. Ich bin kein Linux-Experte, aber auch kein Neuling. Kann also mit einer Bash umgehen, aber ich stoße auch mal schnell bei einigen Problemen an meine Grenzen.

Vor ein paar Wochen habe ich mir einen Dell T20 zugelegt um mir einen kleinen Home-Server inklusive NAS zu bauen. Dafür wurde auf dem Dell T20 Citrix XenServer installiert und OpenMediaVault also NAS VM. OMV basiert bzw. ist Debian, weshalb ich dann letztendlich hier gelandet bin. Für die NAS VM war eigentlich der Plan den SATA/SAS Controller an die VM via PCI Passthrough durch zuleiten. Was auch, zumindest augenscheinlich, erstmal funktionierte. Recht schnell wurde klar, dass beim Streamen von Video-Dateien vom NAS ständig Bitfehler auftreten. Daraufhin habe ich die MD5 Summe einer Test-Datei erstellen lasse und dabei fiel auf, dass die MD5 Summe bei jeder Berechnung ein anderes Ergebnis liefert und auch jedes Mal anders ist, als die MD5 Summe der Original-Datei.

Da habe ich erstmal gebetet, dass die Daten hoffentlich korrekt auf dem Raid liegen und nur beim Lesen Fehler passieren. Es handelt sich um ein Software Raid6 mit 8 Festplatten. Also habe ich Ubuntu von einem Stick gestartet und dort das Raid6 gemountet. Siehe da, die MD5 Summe der Test-Datei war korrekt. Die Dateien wurde also richtig auf die Platten geschrieben, aber fehlerhaft gelesen. Damit muss sich also um ein Software Problem im XenServer oder OpenMediaVault handeln. Erst hatte ich XenServer in Verdacht, also Ausschluss-Test habe ich dann den SAS/SATA Controller an eine Ubuntu VM weitergegeben und gemounten, siehe da, auch hier funktioniert alles tadellos.

Nun war klar, dass es sich um die OMV VM handelt, die das Problem verursacht. Aber ist es OMV oder Debian? Also hab ich mir eine reine und minimale Debian Jessie VM aufgesetzt und da habe ich ebenfalls die Lesefehler. Es liegt also eindeutig an Debian und nun weiß ich leider nicht mehr weiter.

Ich bekomme keinerlei Fehlermeldungen. "dmesg" ist sauber und auch sonst habe ich in keinem Log einen Fehler gefunden.Der Kernel von Ubuntu ist aktueller als der von Debian Jessie (Soweit ich das korrekt interpretiere), also habe ich den aktuellsten Kernel via der Debian Jessie Backports Rep installiert, aber das Problem bleibt bestehen. Die mdadm und lvm2 Version von Ubuntu ist älter als die von Debian, ab hier weiß ich nicht überhaupt nicht mehr weiter. Mir fehlt leider dafür das Fachwissen.

Ich hoffe ich bin hier richtig und mir kann jemand weiterhelfen. Ich poste gerne jeden Log und führe jeden Test zu Analyse des Problems durch.

Grüße
m0nKeY

[TRex]

Die beiden Systeme (in der VM) haben auf jeden Fall ne Schnittmenge, aber als du Ubuntu gestartet hast, war das dann außerhalb von Xen, oder? Also ist die noch auszuschließende Komponente das Passthrough, nicht Debian.

Im Kernel-Log oder so taucht nichts auf? (Ja, beide - vom Host und vom Gast, überall)

[m0nKeY]

Ich hab das Raid sowohl einmal außerhalb vom Xenserver (per USB Stick) eingehangen und auch in ein Ubuntu, welches als VM auf dem Server läuft. Bei beiden gab es keine Probleme. Deshalb vermute ich, dass das Problem an Debian Jessie liegt.

Was die Kernel-Logs angeht, hab ich zumindest nichts bezüglich des Problems gesehen. Anbei "dmesg" vom XenServer und von OMV. Beide Logs wurden erstellt, nach dem ich den Controller wieder an die VM weitergeben habe und eine md5sum von der Testdatei habe erstellen lassen.

dmesg XenServer:
https://pastebin.com/rHMkQX5E

dmesg OMV:
https://pastebin.com/56iW9jFr

[TRex]

Hast du mal die Parameter aus mdstat verglichen zwischen funktionierenden und nichtfunktionierenden Systemen? Ich könnte mir vorstellen, dass das Raid mit anderen Parametern initialisiert wurde, als es anschließend in jessie verwendet wurde. Ich hab mir bisher nie Gedanken um sowas gemacht, weil ich kein Raid über zwei OS hinweg verwendet hab... Von Xen weiß ich auch nur wenig - die Kernelmodule (und Kernel selbst) kommen vollständig vom Gast, oder? mdadm userland in jessie ist per se in Ordnung, das verwende ich selbst auch (und das wäre im Gegensatz zu cross-OS-Verwendung auch schnell aufgefallen).

[m0nKeY]

Werde das heute Abend wenn ich Zuhause bin mal überprüfen. Die Parameter sollten aber identisch sein, denn als Workaround gebe ich jetzt die einzelnen Platten an die VM weiter und das Problem ist weg. Der Raid sollte also identisch sein, gegenüber der Weitergabe des gesamten Controllers. Nur kann ich jetzt den Festplatten Spin-Down nicht mehr kontrollieren und keine SMART-Daten aus OMV mehr auslesen.

Ich vermute, dass die Ursache des Problems im Treiber für den SATA-Controller oder im Treiber für das PCI Passthrough liegt.

[m0nKeY]

Hier der Inhalt von mdstat:

OMV VM mit SATA Passthrough:

Code: Alles auswählen

Personalities : [raid6] [raid5] [raid4]
md127 : active raid6 xvdi[0] xvde[7] xvdf[6] xvdb[5] xvdj[4] xvdg[3] xvdh[8] xvdc[1]
      17580810240 blocks super 1.2 level 6, 512k chunk, algorithm 2 [8/8] [UUUUUUUU]
      bitmap: 0/22 pages [0KB], 65536KB chunk

XenServer:

Code: Alles auswählen

Personalities : [raid6] [raid5] [raid4]
md127 : active (auto-read-only) raid6 sdg[0] sdf[8] sdh[4] sdb[1] sde[3] sdc[7] sdd[6] sda[5]
      17580810240 blocks super 1.2 level 6, 512k chunk, algorithm 2 [8/8] [UUUUUUUU]
      bitmap: 0/22 pages [0KB], 65536KB chunk

OMV VM mit PCI Passthrough:

Code: Alles auswählen

Personalities : [raid6] [raid5] [raid4]
md127 : active raid6 sdg[0] sdc[7] sdd[6] sda[5] sdh[4] sde[3] sdf[8] sdb[1]
      17580810240 blocks super 1.2 level 6, 512k chunk, algorithm 2 [8/8] [UUUUUUUU]
      bitmap: 0/22 pages [0KB], 65536KB chunk

Nachtag vom 05.04.2014:

Habe jetzt noch ein Firmware-Update des HP SAS Controllers HP220 gemahct, hat aber leider auch nicht geholfen. Hat noch jemand eine Idee, wie das Problem weiter analysieren kann?

[TRex]

Nein, leider nicht. Ich denke auch, dass das Problem beim Passthrough im Treiber entsteht. Hilfe suchen würde ich in der Xen Mailingliste, falls sich hier sonst niemand mehr findet. Du könntest noch mdadm als Fehlerquelle ausschließen und mal direkt Schreib-Lese-Tests auf den Blockdevices ausführen (falls du das kannst - sind ja Daten drauf). Aber allzuviel Unterschied wirds vermutlich nicht machen.

Edit: installier mal den Ubuntu-Kernel im Debian-System.

[m0nKeY]

Hi,

vielen vielen Dank schon mal für deine Hilfe.

Heute hatte ich etwas Zeit und habe weitere Analyse betrieben. Als erstes habe ich Debian per Live CD gestartet und den md5sum Test wieder durchgeführt. Der Fehler war dann natürlich weg, also wird das Problem also wirklich vom PCI Passthrough ausgelöst.

Kurz vorher hatte ich etwas über die PCI Gruppen gelesen und das es zu Fehler kommen kann, wenn manche Devices sich einen PCI Slot "teilen". Entweder reicht man alle Devices durch, die an diesem Slot hängen oder sucht sich einen anderen Slot.

https://wiki.archlinux.org/index.php/PC ... _PCIe_slot

Ich dachte, ein Versuch wäre es wert und habe einfach mal den PCI Slot gewechselt. Sieh da, das Problem ist weg. Schön wäre, wenn ich diese PCI Gruppierung noch nachvollziehen könnte, aber die Methode , die auf der Seite beschrieben wird, funktioniert wohl nicht in dem CentOS vom XenServer. Entweder das oder es funktioniert generell nicht mehr.

Gruß
m0nKeY