Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

Probleme mit VMDirectPath und SATA Controller

Moderatoren: irix, Dayworker

Member
Beiträge: 435
Registriert: 28.01.2005, 11:14

Probleme mit VMDirectPath und SATA Controller

Beitragvon Wirrkopf » 25.08.2011, 20:24

Nun habe ich esa auch mal mit der 5er Version probiert. Installiert auf eine SATA HDD die an einem gesteckten PCIe Controller von Marvel hängt. Installation lief durch, ESXi 5 bootet von der HDD und man kann den Rest der hDD auch als Space für VMs nutzen. Klasse.

Dann habe ich den onBoard SATA Controller (AMD SB850) auf VMDirectPath gestellt da ich ihn ja an mein virtuelles SAN durchreichen will. Wie immer bei VMDirectPath Änderungen den notwendigen reboot gemacht und....

Der ESXi startet noch von der SATA HDD aber die HDD wurde nicht mehr als Space für VMs erkannt und angezeigt. Das beste: Sie tauchte auch nicht mehr auf nachdem ich die SB850(erkannt als SB700) wieder aus der VMDirectPath Einstellung rausgenommen habe.

Was kann das denn sein? Wieso ist ein gesteckter SATA Controller vom onBoard SATA Controller abhängig?

Member
Beiträge: 435
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 27.08.2011, 22:34

Der ESXi5 bootet jetzt vom USB Stick.

Als Speicheradapter wird der onBoard Sata Controller als AMD "SB700" erkannt, der Marvel PCIe Sata Controller als "Unknown".

Trotz Unknown kann ich die SATA HDD am Marvel Sata Controller als lokalen Speicher konfigurieren und nutzen.

ABER es bleibt dabei. Sobald ich den onBoard Controller per VMDirectPath einstelle und neustarte sind BEIDE speicheradapter weg.

Wenn ich in den erweiterten Einstellungen nachsehe ist dort aber wie gewollt nur der interne SATA Controller SB700 für VMDirectPath aktiv der Marvel Sata Controller ist nicht ausgewählt.

Warum verschwindet also der PCIe Sata Controller wenn man den internen Sata Controller auf VMDirectPath einstellt? Wo ist da die Abhängigkeit? Unter den "erweiterten Einstellungen" ist keine Abhängikeit zu erkennen.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 28.08.2011, 10:47

Schau dir mal das Bild "usb_setup2.jpg" auf http://www.vm-help.com/esx40i/VMDirectPath/USB_Setup.php an.
Verlinke mal bitte dasselbe Bild von deinem Host.

Member
Beiträge: 435
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 28.08.2011, 20:44

Meinst Du das?
Bild

Bild

Im Bild ist der Zustand zu sehen wenn der onBoard SATA Controller (AMD SB 850 erkannt als SB700) für VMDirectPath aktiviert wird. Der Marvel SATA Controller ist der "unknown IDE-Controller".

Ich habe bereits alle 3 PCIe Steckplätze für den Marvel PCIe SATA ausprobiert ohne das das was geändert hätte.

Andersrum gehts überigens! Also bei, Marvel SATA Controller VMDirectPath aktivieren und nach dem neustart sind auch nur die HDDs an diesem Controller für den ESXi unsichtbar. Die am onBoard Controller sind weiterhin sichtbar.

Aber andersrum nützt mir nix da der onBoard Controller 6x Sata hat und der Marvel nur 2x.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 28.08.2011, 22:02

Wenn ich mir http://www.petri.co.il/vmware-esxi4-vmdirectpath.htm ansehe (vm-help.com scheint momentan offline zu sein oder ich hab wieder mal DNS-Probleme), geht der Marvel-Controller, weil er keine weiteren Abhängigkeiten hat und völlig autark agieren kann. Das dürfte bei der Southbridge SB700/SB850 so nicht der Fall sein oder liegt eventuell nur an der fehlerhaften Erkennung der Southbridge.

Beim Marvel-Controller wäre sicherlich noch zu beachten, daß das unter '02:00.0' mit 'Unknown Unknown' gelistete Device auch noch mit an die VM durchgereicht wird. Der Hintergrund dafür wird im PDF http://www.vmware.com/pdf/vsp_4_vmdirectpath_host.pdf auf Seite 4 unter "Problems with Device Assignment Dependencies" genannt:
Because of the limits of the PCI bus or individual devices, it is sometimes necessary for multiple devices to be 
assigned to passthrough mode on the host together. These dependencies exist because passthrough requires a 
way to reset devices and it is sometimes not possible to reset a device without also resetting other devices.



PS: Wenn du eine zweite Nic und Graka einbauen würdest, könntest du sicher auch die Realtek-Nic und höchstwahrscheinlich sogar die Mach64-GPU, wenn diese nicht als primäre Graka dient, in eine VM hieven.

Benutzeravatar
Member
Beiträge: 131
Registriert: 05.04.2011, 20:08

Beitragvon Santa » 28.08.2011, 22:46

Dayworker hat geschrieben:vm-help.com scheint momentan offline zu sein oder ich hab wieder mal DNS-Probleme
http://vm-help.com is up.

Member
Beiträge: 435
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 29.08.2011, 09:38

Dayworker hat geschrieben:Wenn ich mir http://www.petri.co.il/vmware-esxi4-vmdirectpath.htm ansehe (vm-help.com scheint momentan offline zu sein oder ich hab wieder mal DNS-Probleme), geht der Marvel-Controller, weil er keine weiteren Abhängigkeiten hat und völlig autark agieren kann. Das dürfte bei der Southbridge SB700/SB850 so nicht der Fall sein oder liegt eventuell nur an der fehlerhaften Erkennung der Southbridge.

Im ESXi4.1 läßt sich die SB700 ohne Probleme per VMDirectPath leiten. Wobei ich in der ESXi4.1 Installation nicht den Marvel Sata Controller nutze sondern den onBoard jmicron jmb361 PATA Controller mit gepatchtem Treiber. Daher kann es gut sein das auch unter ESXi 4.1 diese Kombination SB700 - Marvel Controller Probleme bereitet. Ich werde das mal bei Gelegenheit probieren.

Aber die Frage WARUM ist immer noch völlig unklar. Oder hab ich etwas in Deiner Antwort übersehent?

Ich hoffe das es nicht mehr lange dauert bis es diesen Treiber für den jmicron jmb361 auch für den ESXi5 gibt. Dann wird das sicher genauso gut laufen wie unter 4.1.
Beim Marvel-Controller wäre sicherlich noch zu beachten, daß das unter '02:00.0' mit 'Unknown Unknown' gelistete Device auch noch mit an die VM durchgereicht wird. Der Hintergrund dafür wird im PDF http://www.vmware.com/pdf/vsp_4_vmdirectpath_host.pdf auf Seite 4 unter "Problems with Device Assignment Dependencies" genannt:
Because of the limits of the PCI bus or individual devices, it is sometimes necessary for multiple devices to be 
assigned to passthrough mode on the host together. These dependencies exist because passthrough requires a 
way to reset devices and it is sometimes not possible to reset a device without also resetting other devices.

Warum der Marvel Controller nun mit zwei Einträgen auftaucht ist mir recht egal. Den will ich doch gar nicht durchreichen! Der soll ja den Datenspeicher für die primäre SAN VM bereitstellen.

PS: Wenn du eine zweite Nic und Graka einbauen würdest, könntest du sicher auch die Realtek-Nic und höchstwahrscheinlich sogar die Mach64-GPU, wenn diese nicht als primäre Graka dient, in eine VM hieven.

Die uralte PCI MACH64 GPU fliegt raus sobald das System produktiv läuft. Das Board startet ohne Probleme ohne Graka. Dann kommt da eine PCI ISDN Karte rein. Den PCI Bus kann man leider nur komplett mit seinen zwei Steckplätzen an eine VM durchreichen.

So sieht es nach dem Reboot aus wenn ich die SB700 auf VMDirectpath gestellt habe:
In den erweiterten Einstellungen kann man sehen das NUR bei der SB700 VMDirectPath aktiviert ist. Beim Marvel Controller (unknwon IDE Controller) nicht.

Bild

Wenn ich dann aber bei den Speicheradaptern nachsehe sind leider beide verschwunden. WARUM ZUR HÖLLE! Das ist kein gepatche, kein rumgefrickel und sollte einfach funktionieren. Aber da sicher der MARVEL Controller nicht auf der HCL steht ist es VMWare wohl herzlich egal.

Bild

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 29.08.2011, 21:09

Aber die Frage WARUM ist immer noch völlig unklar. Oder hab ich etwas in Deiner Antwort übersehent?
Wie ich schon schrieb, sind einige Abhängigkeiten zu beachten. Speziell der Satz: "These dependencies exist because passthrough requires a
way to reset devices and it is sometimes not possible to reset a device without also resetting other devices.
" scheint dort eine Schlüsselfunktion zu haben.
So ein Fall könnte auch vorliegen, wenn die CPU nicht ausreichend PCIe-Lanes mitbringt bzw ansteuern kann und stattdessen die Southbridge ihre dafür hergeben muß. Da kommt es also auf auf jeweilige MB-Design an.

Weshalb es bei vSphere4 und 'jmicron' klappt, kann ich dir auch nicht genau beantworten. Ich hoffe hier einfach mal, daß dein vSphere4-Test der Kombi SB700/Marvel genauso fehl schlägt, wie schon unter vSphere5. Wenn es dort trotzdem läuft, liegt entweder noch ein Bug in vSphere5 vor oder durch die Umstellung von MBR auf GPT läßt sich das nicht umgehen. Man muß ja schon dankbar sein, daß laut dem Wikipedia-Eintrag zu GPT nicht unbedingt UEFI vorausgesetzt wird. Ich weiß natürlich sehr wohl, daß Linux und ESX(i) nichts mehr gemein haben, aber: "
"Ein 64-Bit-Linux kann – ganz ohne UEFI oder gesonderte BIOS-Unterstützung – mit GRUB2 von einer GPT-Partition booten. Es ist also kein UEFI dazu notwendig – die Kopplung anderer Betriebssysteme von GPT an (U)EFI ist somit unnötig." (*4)

(*4) Zeitschrift c’t Nr. 04/2011, S. 170ff. – Linux kann ohne gesonderte BIOS-Unterstützung GPT verwenden und von GPT-Partition booten



PS: Ja ich weiß, daß der ESX(i) kein Linux ist. ;)

Member
Beiträge: 435
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 30.08.2011, 07:57

Dayworker hat geschrieben:
Weshalb es bei vSphere4 und 'jmicron' klappt, kann ich dir auch nicht genau beantworten. Ich hoffe hier einfach mal, daß dein vSphere4-Test der Kombi SB700/Marvel genauso fehl schlägt, wie schon unter vSphere5.


Leider läßt sich dieser Test nicht führen. Gestern habe ich es probiert und leider wird der marvel Sata PCIe Controller von der 4.1er gar nicht erkannt bzw. die daran angeschlossenen HDDs werden nicht als Datastore erkannt.

Ob ich nun den onBoard SATA Controler auf VMDirectPath einstelle oder nicht kann ich den ZusatzController eh nicht nutzen.

Unterm Strich kann man sagen das der ESXi5 also bei den akzeptierten Treibern/geräten ein deutlicher Fortschritt ist, zumindest für Frickler wie mich die zu geizig für HCL erprobte Teile sind.

Also warte ich weiterhin auf den ESXi 5 Treiber für meinen onBoard P-ATA Controller jmicron jmb361.

Oder auf einen Trick wie man VMs auf einem USB Stick ablegen kann.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 30.08.2011, 16:08

Also warte ich weiterhin auf den ESXi 5 Treiber für meinen onBoard P-ATA Controller jmicron jmb361.
Der wird sicher nicht kommen, P-ATA ist tot.
Der Host in meiner Sig hatte schon beim Kauf Ende 2006 keinerlei Legacy-Schnittstellen (Serial, Parallel, Floppy, IDE, PS/2) mehr an Bord...

Oder auf einen Trick wie man VMs auf einem USB Stick ablegen kann.
Wenn der Stick groß genug ist, kannst du dort auch einen zweiten DS einrichten.

Member
Beiträge: 435
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 30.08.2011, 16:34

Dayworker hat geschrieben:
Oder auf einen Trick wie man VMs auf einem USB Stick ablegen kann.
Wenn der Stick groß genug ist, kannst du dort auch einen zweiten DS einrichten.


Dann sage mir bitte WIE!

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 30.08.2011, 16:45

Wirrkopf hat geschrieben:
Dayworker hat geschrieben:
Oder auf einen Trick wie man VMs auf einem USB Stick ablegen kann.
Wenn der Stick groß genug ist, kannst du dort auch einen zweiten DS einrichten.


Dann sage mir bitte WIE!
Schau dir mal http://www.binarygods.com/index.php?title=VTT-Scratch_Disk an. Zwar noch unter vSphere4i aber zumindest legen sie dort eine weitere Partition an. Das könnte so auch noch unter vSphere5 gehen..

Member
Beiträge: 435
Registriert: 28.01.2005, 11:14

Beitragvon Wirrkopf » 30.08.2011, 19:56

Dayworker hat geschrieben:
Wirrkopf hat geschrieben:Dann sage mir bitte WIE!
Schau dir mal http://www.binarygods.com/index.php?title=VTT-Scratch_Disk an. Zwar noch unter vSphere4i aber zumindest legen sie dort eine weitere Partition an. Das könnte so auch noch unter vSphere5 gehen..

Ich glaub das Anlegen einer weiteren Partition ist nicht das Hauptproblem.

Schwierig wird es wenn man dem ESXi den Datastore zuweisen will.

Daher denke ich das diese Lösung mit dem internen NFS Server (die mal beim ESXi 3.5 funktioniert hat) vielleicht die erfolgversprechendere ist.

Benutzeravatar
UNSTERBLICH(R.I.P.)
Beiträge: 14759
Registriert: 09.08.2003, 05:41
Wohnort: sauerland
Kontaktdaten:

Beitragvon continuum » 30.08.2011, 20:40

bei esx5i scheint mir fdisk so verkrueppelt zu sein das man keine Partitionen damit anlegen kann :roll:


Zurück zu „vSphere 5 / ESXi 5 und 5.1“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 7 Gäste