Setup des Gast OS stürzt wg Passthrough ab

[Gold-Cobra]

Hallo Community,
ich bin zwar IT-ler aber Neuling im ESX Bereich. Ich habe folgendes Problem:

Ich habe einen ESX Server und möchte auf meinen HW-Raid Controller via Passthrough an eine VM weiterreichen. Meine Hardware unterstützt auch VT-d und somit Passthrough und ich kann den Controller auch einer VM zuweisen.
Leider habe ich zB bei Debain, openSUSE oder Windows 7 das Problem, dass während der Hardwareerkennung das Setup einfach stehen bleibt und nichts mehr macht. Das einzige OS was keine Probleme macht, ist openIndiana. Es lässt sich installieren und erkennt auch ohne Probleme den Controller. Ich habe schon einiges an Zeit investiert und bin eigentlich mit meinem Latein am Ende. Eigentlich würde ich gerne das Debian durch Passthrough Vollzugriff auf den Controller bekommt.

Meine Hardware:
Mainboard: ASUS ASUS P8B-E/4L
CPU: Intel Xeon E3-1220LV2
Controller: ASUS Pike Card 2108 (auf LSI 2108 basierend und baugleich zu einem MegaRAID SAS 9260-8i)
RAM: 16GB Kingston ValueRAM DDR3-1333 ECC DIMM

Vielleicht kann mir jemand einen Tipp geben, wie ich die VM dazu bekommen kann, den Controller zu erkennen.
Wenn ihr noch irgendwelche Informationen braucht, dann bitte einfach fragen.

Gruß

[Dayworker]

Additional Slot 1 : PIKE Slot for Storage expansion

So stehts in der MB-Beschreibung. Ich hab leider keine Ahnung, was das für den Anschluß bedeutet bzw wie dieser ans MB realisiert ist. Vermutlich scheitert deswegen die Erkennung bei einigen OS.
Verlinke mal bitte ein Bild deiner Passthrough-Config, dann sehen wir weiter.

Wovon startest du eigentlich deinen ESXi? Du probierst hoffentlich nicht den Controller durchzureichen, an dem auch das ESXi-Bootmedium hängt.

[Gold-Cobra]

Hallo,
also meine VMs liegen separat auf einer anderen Platte, welche am internen SATA Controller des MB hängt.
Der ESX wird von einem USB Stick gestartet.
Das RAID Setup des HW-Controllers, sollte eigentlich nur als reiner Datenspeicher dienen, welcher von einer VM verwaltet wird.

Ja die PIKE (Proprietary I/O Kit Expansion) Schnittstelle wird wohl nur von ASUS verwendet. Die SATA Anschlüsse sind schon am MB vorhanden und durch die Karte erst nutzbar.
Also kommt das MB mit dem Intel C204 SATA Controller (6 Anschlüsse) und die 8 weiteren SATA Anschlüsse sind dann durch die PIKE Card ansprechbar (HW RAID).

Meinst du mit der Passthrough-Config die Einträge, welche man sieht, wenn ich bei "Erweiterte Einstellungen" den Controller auswähle und dann auf "Bearbeiten" klicke?

Gruß

[Dayworker]

Meinst du mit der Passthrough-Config die Einträge, welche man sieht, wenn ich bei "Erweiterte Einstellungen" den Controller auswähle und dann auf "Bearbeiten" klicke?

Jep.

[Gold-Cobra]

Alles klar. Hier ist meine Config.

[Dayworker]

Der Controller hängt allein an einen PCIe-Port. Ich hatte gehofft, daß dem nicht so wäre und es deshalb zu dem Problem kommt...
Verlinke mal bitte noch ein "vmware.log" von einer fehlgeschlagenen Gast-Inst. Vielleicht findet sich ja darin ein Hinweis, weshalb einige Gäste ausser OI ins Trudeln kommen.
Falls wir darin nichts finden, könnte auch eine unsaubere BIOS/FW-Implementierung von VT-d vorliegen und ein BIOS/FW-Update wäre die naheliegendste Lösung. Da Passthrough offiziell CPU und Chipsatz der Serie 5500 voraussetzt und auch sonst allgemein recht tricky sein kann, ist eine Lösung leider nicht garantiert.

[Gold-Cobra]

Hi,
also BIOS Update habe ich schon gemacht und FW Update vom Controller habe ich noch vor.
Ich dachte mir aber schon, dass es evtl auch gar nicht funktionieren wird. Mir kommt es hald nur komisch vor, das OI es schafft, während alle anderen einfach nur stehen bleiben.

Anbei ist der vmware.log bis zum Abbruch der Installation (von mir forciert).

Ich hänge das einfach mal per Freehoster ran, da man bei euch wohl keine Attachments anfügen darf. Wenn das problematisch sein sollte, oder ihr hier ein anderes Verfahren/Vorgehen habt, gib mir doch bitte Bescheid und ich ändere das dann sofort.

http://www.file-upload.net/download-718 ... e.log.html

Gruß

[Dayworker]

Nö, Freehoster oder eigner Webspace ist schick.

2013-02-10T15:49:47.911Z| vmx| I120: DICT memsize = 1024
...
2013-02-10T15:49:47.912Z| vmx| I120: DICT sched.mem.min = 1024

Gönn der VM mal zumindest ein weiteres Gigabyte vRAM und setz die Memory-Reservation (sched.mem.min) auf denselben Wert, fall das nicht automatisch bei vRAM-Erhöhung per Vi/vSphere-Client passieren sollte. VMs mit Passthrough-Geräten können ihren vRAM bei Nichtgebrauch nicht an bedürftigere zurückgeben, so wie es normalerweise der Fall ist.

2013-02-10T15:49:48.228Z| vmx| I120: PCIPassthru: Device 03:00.0 barIndex 0 type 1 realaddr 0xe000 size 256 flags 1
2013-02-10T15:49:48.228Z| vmx| I120: PCIPassthru: Device 03:00.0 barIndex 1 type 3 realaddr 0xdf560000 size 16384 flags 4
2013-02-10T15:49:48.228Z| vmx| I120: PCIPassthru: Device 03:00.0 barIndex 3 type 3 realaddr 0xdf500000 size 262144 flags 4
2013-02-10T15:49:48.228Z| vmx| I120: PCIPassthru: Device has PCI Express Cap Version 2(size 60)
2013-02-10T15:49:48.228Z| vmx| I120: PCIPassthru: Registered a PCI device for 03:00.0 vIRQ 0x12, physical MSI = Enabled (vmmInt = Enabled), IntrPin = 1
...
2013-02-10T15:49:48.430Z| vcpu-0| I120: PCIPassthru: pinning guest memory (0x40000 pages)
...
2013-02-10T15:49:48.805Z| vcpu-0| I120: PCIPassthru: guest memory successfully pinned
2013-02-10T15:49:48.899Z| vcpu-0| I120: PCIPassthru: Resetting Device at 03:00.0
...
2013-02-10T15:49:49.441Z| vcpu-0| I120: PCIPassthru: Attempted to program PCI cacheline size 32 not a power of 2 factor of original physical 64 for device 03:00.0
...
2013-02-10T15:49:49.638Z| vcpu-0| I120: PCIPassthru: Attempted to program PCI cacheline size 32 not a power of 2 factor of original physical 64 for device 03:00.0
...
2013-02-10T15:51:00.184Z| vcpu-0| I120: PCIPassthru: 03:00.0 : Guest requested starting IO port that was too large (4294967041). Ignoring TurnIOSpace request.
2013-02-10T15:51:00.184Z| vcpu-0| I120: PCIPassthru: 03:00.0 : Guest requested starting IO port that was too large (4294967041). Ignoring TurnIOSpace request.
2013-02-10T15:51:00.185Z| vcpu-0| I120: PCIPassthru: 03:00.0 : Guest requested PPN that was too large (4503599627183104). Ignoring TurnIOSpace request.
2013-02-10T15:51:00.185Z| vcpu-0| I120: PCIPassthru: 03:00.0 : Guest requested PPN that was too large (4503599627183104). Ignoring TurnIOSpace request.
2013-02-10T15:51:00.186Z| vcpu-0| I120: PCIPassthru: 03:00.0 : Guest requested PPN that was too large (4503599627183168). Ignoring TurnIOSpace request.
2013-02-10T15:51:00.186Z| vcpu-0| I120: PCIPassthru: 03:00.0 : Guest requested PPN that was too large (4503599627183168). Ignoring TurnIOSpace request.

Das sieht soweit alles okay aus, einzig das Fettgeschriebene stellt ein Problem dar. Sowas habe ich in dieser Form noch nie in nem früheren "vmware.log" gesehen.


Wenn ich jedoch "PCI cacheline size 32 not a power of 2 factor of original physical 64 for device 03:00.0" genauer betrachte, sollte im Host-Bios mal die "PCI cacheline size" erhöht werden.
Liefert die OI-VM eigentlich dieselben Meldungen in ihrem "vmware.log"

[Gold-Cobra]

Also die VM habe ich nur kurz zum testen erstellt. Normal hätte die VM (wenn sie mal laufen würde) 4GB zur Verfügung.

Das bei mir mal wieder was besonderes los ist, war mir eig fast schon wieder klar.
Habe zum testen mal kurz eine OI-VM aufgesetzt und den Controller durchgereicht.

vmware.log der OI Installation:
http://www.file-upload.net/download-718 ... I.log.html

Der Fehler "Ignoring TurnIOSpace request" kommt zwar nicht, aber "PCI cacheline size 32 not a power of 2 factor of original physical 64 for device 03:00.0" ist da.
Obwohl mir das nicht ganz klar ist, da 2^5 = 32. Vielleicht versteh ich aber auch die Meldung falsch.
Ich habe den Server mal durchgestartet und mich durch das BIOS vom MB gewühlt. Leider kann ich die Cacheline Size nicht erhöhen bzw. habe keine Funktion dafür gefunden.

Hätte langsam gute Lust die ganze Kiste einfach nur noch raus in den Regen zu stellen.

Gruß und auf jedenfall Danke, dass du dir da soviel Zeit nimmst.

[Dayworker]

Der Fehler "Ignoring TurnIOSpace request" kommt zwar nicht, aber "PCI cacheline size 32 not a power of 2 factor of original physical 64 for device 03:00.0" ist da.
Obwohl mir das nicht ganz klar ist, da 2^5 = 32. Vielleicht versteh ich aber auch die Meldung falsch.
Ich habe den Server mal durchgestartet und mich durch das BIOS vom MB gewühlt. Leider kann ich die Cacheline Size nicht erhöhen bzw. habe keine Funktion dafür gefunden.

Mit 2^5=32 hast du zwar Recht, allerdings erwartet der ESXi hier anscheinend eher ein Vielfaches von 2^6=64 aufwärts.

2013-02-10T17:45:11.922Z| vmx| I120: DICT guestOS = otherlinux-64
...
2013-02-10T15:49:47.912Z| vmx| I120: DICT guestOS = debian6-64

Deine OI-Inst läuft als otherlinux-64 und scheint damit problemlos zu laufen, während die korrekt bezeichnete Debian6-VM Spirenzchen macht. Änder doch bitte einfach mal das Gast-OS der Debian-VM auf otherlinux-64 um. Wenn es dann läuft, dürfte ein Bug in den grundlegenden Virtualisierungseinstellungen vorliegen oder dein MB harmoniert nicht mit den VMware-Einstellungen.

[Gold-Cobra]

Leider nein. Bleibt wieder bei der Hardwareerkennung hängen.
Macht es denn ein Unterschied, wenn ich ein anderes Template auswähle?

Nur am Rande:
Ich habe es ja am Anfang mit RAW-Device Mapping probiert, aber hatte katastrophale Durchsatzleistungen. Als ich einfach ein Win2008Srv aufgesetzt habe (ohne ESX dazwischen) habe ich erst bemerkt, was der Controller leistet. Obwohl ich da auch Probleme hatte, da im RAID-5 Betrieb mehr Schreibdurchsatz als Lesedurchsatz zu verzeichnen war. Sollte ja eigentlich nicht so sein, aber ist wohl anderes Thema.

Ich wollte die Maschine dann schon fast nur mit dem 2008er Server laufen lassen und dann darin weitere Systeme per VMWare Player (o.ä.) realisieren, bis ich irgendwo in den tiefen des Internets auf jemand gestoßen bin, der mit dem baugleichem Controller von LSI ähnliche Probleme hatte und es eben mit OpenIndiana zum laufen gebracht hat. Da ich zu diesem Zeitpunkt schon Wochen mit dem ESX Server rumgespielt habe und ihn eigentlich nicht mehr missen wollte, bin ich dann wieder umgestiegen.

Naja und als letztes habe ich mir gedacht, dass ich mich hier anmelde und nach Hilfe frage.

Gruß

[Gold-Cobra]

Noch ein kurzer Nachtrag:

Habe gerade CentOS getestet und das erkennt den Controller auch ohne Probleme.
Eigentlich komisch, da CentOS ja genau wie Debian von Linux abstammt. OpenIndiana stammt ja von UNIX ab. Also geht meine Theorie das es von der Abstammung der Distribution abhängt auch net so ganz auf.

Naja werde mir die Nacht mal mit Cent um die Ohren schlagen und wenn alles soweit funktioniert, mir gefällt und es passt, dann bin ich froh und trotzdem irgendwie ans Ziel gekommen.

Gruß

[Dayworker]

Eigentlich komisch, da CentOS ja genau wie Debian von Linux abstammt. OpenIndiana stammt ja von UNIX ab.

Um das mal auseinander zu klamüsern.
CentOS bedeutet Community ENTerprise Operating System und ist eine Linux-Distribution, die auf der Distribution Red Hat Enterprise Linux (RHEL) des Unternehmens Red Hat aufbaut. Neben CentOS bauen noch weitere Distributionen wie Scientific Linux oder Oracle Linux (früher als Oracle Enterprise Linux bekannt) auf derselben RHEL-Codebasis auf.

OpenIndiana ist ein Unix-ähnliches OS, das frei und als Open Source veröffentlicht wurde. OI entstand, nachdem Oracle Sun Microsystems aufgekauft hatte und deren Community-Linux namens OpenSolaris nicht mehr weiterentwickeln wollte, aus der OpenSolaris Codebasis und mit dem Ziel diese weiter zu entwickeln. OI wird unter dem Schirm der illumos Foundation vorangebracht.

[Gold-Cobra]

So um nochmal ein Feedback zu geben. Das Grundproblem besteht leider immer noch.
Ich habe mich aber jetzt die letzten Tage mit CentOS auseinandergesetzt und konnte dies erfolgreich für uns einsetzen. Das OS hat vollen Zugriff auf den Controller und kann u.a. somit auch die Steuerungssoftware ausführen.

Nach der langen Zeit, die ich durch diesen Fehler verschenkt habe, bin ich mit der Lösung jetzt mehr als zufrieden.

Nochmals Danke für deine Hilfe.

Gruß