Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.
(Das "alte Design" kommt wieder, wird ne Weile brauchen!)

[gelöst] WS 8.04 auf CentOS 6.3 Host: kein 3D in W7-Gast

Ältere Postings, aber zu Schade zum Vergessen...

Moderatoren: irix, continuum, Dayworker, Tschoergez

Member
Beiträge: 386
Registriert: 16.05.2007, 00:58
Wohnort: DE/UA

[gelöst] WS 8.04 auf CentOS 6.3 Host: kein 3D in W7-Gast

Beitragvon saxa » 24.07.2012, 12:16

Hallo,

auf einem CentOS 6.3 x64 Host ist die Workstation 8.04 installiert.

In einer VM mit Windows 7 kriege ich keine 3D-Beschleunigung (Themes etc.) hin.

Ist das ein Bug oder ist das überhaupt nicht möglich?

Die selbe VM auf demselben Host, aber unter Windows 7, funktioniert einwandfrei.

Host benutzt die in die Core i7 CPU eingebaute Grafikkarte (HD4000). Diese wurde von CentOS erkannt - compiz funktioniert einwandfrei.

Benutzeravatar
Jenseits von Gut & Böse
Beiträge: 11835
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 24.07.2012, 12:29

GPU-RAM groß und v.HW-Version hoch genug?
Verlinke mal bitte ein "vmware.log" dieser VM.

Member
Beiträge: 386
Registriert: 16.05.2007, 00:58
Wohnort: DE/UA

Beitragvon saxa » 24.07.2012, 13:17

Dayworker hat geschrieben:GPU-RAM groß und v.HW-Version hoch genug?
Verlinke mal bitte ein "vmware.log" dieser VM.


vHW: letze Version - 8. Wie viel RAM die GPU benutzt, kann ich dir nicht sagen - weiß nicht, wo man es nachschaut... :oops:

Die Log-Datei.

Benutzeravatar
Jenseits von Gut & Böse
Beiträge: 11835
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 25.07.2012, 12:37

Je nach Gast sollte die WS entsprechende Vorgaben hinsichtlich GPU-Speicher haben, andernfalls reicht dieser nicht aus, um 3D zu aktivieren oder den WDDM-Treiber zur erfolgreichen Mitarbeit zu bewegen.
Wenn ich mich recht entsinne, mußten das mindestens 32MB sein und die könntest du auch manuell in die VMX-Datei eintragen.
In deinem Fall hilft dir das aber dennoch nicht weiter. Der folgende Ausschnitt deines Logs beschreibt die Situation:
2012-07-24T12:56:42.080+01:00| mks| W110: GLManager: Required extension GL_EXT_texture_compression_s3tc is missing.
2012-07-24T12:56:42.080+01:00| mks| W110: GL-Backend: GLRendererStart GLManager is not started successfully, will disable GLBackend 3D support.
2012-07-24T12:56:42.082+01:00| mks| W110: MKS-RenderMux: Backend GLBackend<25E1200> failed to start. Disabling.
2012-07-24T12:56:42.082+01:00| mks| I120: MKS-SLC: failed to start svga3d vmiop to render 3d.


Einen Versuch wert, wären neuere GPU-Treiber direkt von Intel und nicht die in der Distro enthaltenen, falls Intel eigene Closed-Source-Treiber bereitstellt.

Member
Beiträge: 386
Registriert: 16.05.2007, 00:58
Wohnort: DE/UA

Beitragvon saxa » 25.07.2012, 14:54

Hallo,

Dayworker hat geschrieben:Einen Versuch wert, wären neuere GPU-Treiber direkt von Intel und nicht die in der Distro enthaltenen, falls Intel eigene Closed-Source-Treiber bereitstellt.


Das werde ich versuchen. Intel hat vor kurzem neue Treiber publiziert; diese sind Open-Source und finden irgendwann auch den EInzug in den Kernel.

Danke für das Finden der entsprechnden Stelle in der Logdatei :grin: Habe die Datei dreimal durchgeschaut und nichts außer SCSI-Aussetzer gefunden.

Gruß,
Alexander

Benutzeravatar
Jenseits von Gut & Böse
Beiträge: 11835
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 25.07.2012, 22:05

Welche SCSI-Aussetzer meinst du?
2012-07-24T12:56:59.581+01:00| vcpu-0| I120: SCSI0: RESET BUS
2012-07-24T12:56:59.683+01:00| vcpu-0| I120: LSI: Invalid PageType [21] pageNo 0 Action 0
2012-07-24T12:56:59.683+01:00| vcpu-0| I120: SCSI scsi0:0: Unsupported command REPORT LUNS issued. --ok
2012-07-24T12:56:59.703+01:00| vcpu-0| I120: SCSI DEVICE (scsi0:0): MODE SENSE(6) for unsupported page 0x1c
2012-07-24T12:56:59.703+01:00| vcpu-0| I120: SCSI DEVICE (scsi0:0): MODE SENSE(6) for unsupported page 0x8
2012-07-24T12:56:59.703+01:00| vcpu-0| I120: SCSI DEVICE (scsi0:0): MODE SENSE(6) for unsupported page 0x8
Die sind als normal zu bezeichnen und haben ihren Ursprung in der Tatsache, daß VMware die vollständige VT nutzt und daher sämtliche Gast-HW mit Ausnahme der CPU (Serial-, Parallel- und USB-Ports eigentlich auch, aber das sind separate Geschichten) in SW abbildet. VMware halt nur sämtliche Anfragen des OS an das Gerät und dessen Antwort mit.

2012-07-24T12:57:04.774+01:00| vmx| I120: scsi0:0: Command READ(10) took 1.009 seconds (ok)
2012-07-24T12:57:04.784+01:00| vmx| I120: scsi0:0: Command READ(10) took 1.015 seconds (ok)
2012-07-24T12:57:04.787+01:00| vmx| I120: scsi0:0: Command READ(10) took 1.017 seconds (ok)
Falls du diese Einträge meinst, besteht auch kein Grund zur Sorge. Bei den niedrigen Latenzen könnte ich glatt neidisch werden. Du hast also entweder einen extem schnellen Datenträger sprich SSD bzw separate Platten für Host und Gast oder der Host hat momentan auch so nicht viel zu tun.

Member
Beiträge: 386
Registriert: 16.05.2007, 00:58
Wohnort: DE/UA

Beitragvon saxa » 29.07.2012, 12:04

Ich meinte die Einträge wie

Code: Alles auswählen

2012-07-24T12:57:04.774+01:00| vmx| I120: scsi0:0: Command READ(10) took 1.009 seconds (ok)


Habe immer gedacht, das wären die Virt-SCSI-Aussetzer; in diesem Fall beim Lesen.

Der Host hat keine SSD (bzw. er hat eine, aber sie wird unter CentOS nicht eingesetzt), sondern eine recht schnelle SATA2-Platte. Und ja, der Host hatte während des Ausführens der VM nichts anderes zu tun.[/i]

Benutzeravatar
Jenseits von Gut & Böse
Beiträge: 11835
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 29.07.2012, 14:25

Code: Alles auswählen

2012-07-24T12:57:04.774 +01:00 | vmx| I120: scsi0:0: Command READ(10) took 1.009 seconds (ok)
Wenn ich so darüber nachdenke, sind das wirklich, wenn auch harmlose, Aussetzer.

Das solche Logeinträge nur beim Einsatz virtueller SCSI- oder SAS-Controller gemacht werden, hängt auch mit deren Ausrichtung auf die professionelle Ebene zusammen, denn SCSI und das darauf aufbauende SAS bieten weit mehr Möglichkeiten zum Loggen und vor allem Korrigieren von Übertragungsfehlern schon während einer laufenden Übertragung.
Dazu werden unter anderem Prüfsummen genutzt, die der Controller unabhängig vom Betriebssystem berechnet und das ist weder bei IDE noch für SATA1/2/3 spezifiert worden. Wenn also eine Datenkorruption bei der Übertragung zwischen Controller und Platte auftritt, muß das OS dies registrieren, wenn es dazu überhaupt in der Lage ist, und eine erneute Übertagung anschieben.
Erst mit ZFS wurde dieser Mangel erkannt und unabhängig von Medium oder Übertragungsstandard spezifiert. Da man aber nicht bei jedem Controller diese Fähigkeiten voraussetzen kann, muß dann die Rechner-CPU wieder herhalten. Aber das kennt man ja schon von den Fake-Raids...

Member
Beiträge: 386
Registriert: 16.05.2007, 00:58
Wohnort: DE/UA

Beitragvon saxa » 01.08.2012, 12:53

Es ist alles richtig, was du sagst :)

Um zurück zum Thema zu kommen: ich werde es nicht schaffen, den neuen Intel-Treiber selbst zu kompillieren und zu installieren.

Diverse Bibliotheken sind notwendig, die auf CentOS 6.3 nicht in den richtigen Versionen vorliegen. Sollte ich das Kompillieren dennoch schaffen, werde ich bei jedem Upgrade des Kernels das Ganze wiederholen müssen.

Also, lasse ich das lieber :)

Eine Alternative wäre, die Einstellungen des bestehenden Treibers zu untersuchen und gegebenenfalls zu verändern - da bin ich noch auf der Suche.

Member
Beiträge: 386
Registriert: 16.05.2007, 00:58
Wohnort: DE/UA

Beitragvon saxa » 01.08.2012, 13:14

Habe hier etwas gefunden. Ich brauche das Programm DRIConf.

Im verlinkten Thread ist ein Workaround für ubuntu beschrieben; wenn ich mit meinem CentOS Erfolg haben sollte, werde ich ihn hier beschreiben.

Nachtrag: es ist... verboten, dieses Paket in RHEL einzubauen!

Member
Beiträge: 386
Registriert: 16.05.2007, 00:58
Wohnort: DE/UA

Beitragvon saxa » 01.08.2012, 13:40

Unglaublich... Gelöst! Mit dem eingebauten Treiber!

1. Auf dem Host das Paket driconf-0.9.1-13.fc12.noarch.rpm installieren.
2. System -> Preferences -> Driconf (die Einstellungen sind benutzerbezogen).
3. Reiter "Image Quality".
4. "Enable S3TC texture..." = "Yes".
5. Driconf schließen.
6. Den Gast starten. Warnung der Workstation warnehmen: "The GPU driver currently installed on this host may cause issues..."
7. Keine Issues.
8. ???
9. Profit!

Vielleicht kann der Ulli daraus einen Sticky machen, damit auch andere davon profitieren...

Member
Beiträge: 386
Registriert: 16.05.2007, 00:58
Wohnort: DE/UA

Beitragvon saxa » 31.08.2012, 09:52

Leider muss ich das Thema wieder aufgreifen. Das beschriebene Workaround funktioniert nicht mehr mit Workstation 9.

Benutzeravatar
Jenseits von Gut & Böse
Beiträge: 11835
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 31.08.2012, 13:01

Gabs einen Grund, weshalb du unbedingt die WS9 nehmen mußtest?
Die WS8 war laut Ulli aka continuum schon mit heißer Nadel gestrickt...

Member
Beiträge: 386
Registriert: 16.05.2007, 00:58
Wohnort: DE/UA

Beitragvon saxa » 31.08.2012, 13:03

Wegen WSX...

Benutzeravatar
Jenseits von Gut & Böse
Beiträge: 11835
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 31.08.2012, 13:08

saxa hat geschrieben:Wegen WSX...
Wie Ulli auch schon im VMTN erfahren hatte, ist WSX nicht im Lieferumfang der WS9 enthalten.
WSX ist bisher immer ein separater Download unterhalb des WS9-Downloadlinks.

Member
Beiträge: 386
Registriert: 16.05.2007, 00:58
Wohnort: DE/UA

Beitragvon saxa » 31.08.2012, 13:09

Ja, klar :) Aber WSX funktioniert nur mit WS9 - soweit ich weiss.

Member
Beiträge: 386
Registriert: 16.05.2007, 00:58
Wohnort: DE/UA

Beitragvon saxa » 05.09.2012, 13:32

Ich habe aus lauter Verzweiflung bereits ubuntu 12.04 als Host ausprobiert - das Gleiche :?

Benutzeravatar
Jenseits von Gut & Böse
Beiträge: 11835
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 05.09.2012, 19:30

saxa hat geschrieben:Ich habe aus lauter Verzweiflung bereits ubuntu 12.04 als Host ausprobiert - das Gleiche :?:
Linux als Host-OS ist in meinen Augen so mit das Unglücklichste, was man als Besitzer der Workstation einsetzen kann.
Die ewigen Kernelupdates ändern jedes mal die Umgebung. Wenn du es daher irgenwie einrichten kannst, laß den Virtualisierungshost solange wie möglich auf einer Kernelversion.
Falls du das nicht willst oder auch schlichtweg nicht kannst, weil der Kernel die HW nicht komplett unterstützt wird, bleibt dir fast nur noch ein Virtualisierer wie KVM. Dieser wird mit durch die Lernel-Hacker weiterentwickelt und funktioniert daher immer mit jeder neuen Kernelversion. Alles anderen Virtualisierungsabieter müssen früher oder später immer Anpassung ihrer Produkte vornehmen, um mit den sich stetig ändernden Kernelbedingungen mitzukommen.

Auch wenn dir das jetzt nicht weiterhilft, aber vor diesem Hintergrund verstehe ich auch absolut VMwares Entscheidung, den VMserver wieder eingestellt zu haben. Player und Workstation sind oder waren ja noch nie eigenständig entwickelte Produkte und VMware hat alle Hände damit zu tun, diese an die Kernelentwicklung anzupassen.
Mein vorläufiger Workaround wäre daher, wieder auf die WS8 zurückzugehen und wie bisher den Vi/vSphere-Client für ESX(i) zu nehmen. Vielleicht findet sich ja doch noch eine andere Möglichkeit bei der WS9 oder VMware steuert schnellstmöglich ein Update bei, das dann auch gleich noch das Policy-Problem löst...

Member
Beiträge: 386
Registriert: 16.05.2007, 00:58
Wohnort: DE/UA

Beitragvon saxa » 10.09.2012, 10:39

Habe auch für die WS9 einen Workaround gefunden.

In die vmx (oder in /etc/vmware/config) muss folgendes eingetragen werden:

mks.gl.allowBlacklistedDrivers = TRUE

Alles, was ich zu den DRI-Einstellungen entdeckt habe, muss ebenso eingerichtet werden.

Gruß,
Alexander


Zurück zu „Ältere angepinnte Workstation- & Player-Threads“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast