Category Archives: VMware Workstation

Beiträge zum Einsatz von VMware Workstation am Linux-Arbeitsplatz

Installation Windows und CS4….ein Albtraum

Posted on by

Weil Krise ist und der Bürger mehr kaufen soll, um den Binnenmarkt anzukurbeln, wollte ich in Web-Entwickung investieren und habe mir das Upgrade auf Adobe CS4 Web Premium (Windows-SW!) geleistet.

Das ist eine sehr kostspielige Investition – der Preis für das Upgrade liegt etwa beim Doppelten dessen, was ein Harz4-Empfänger im Monat bekommt. Also erwartet man wenigstens eine halbwegs funktionierende Installation. Leider wird man hier bitter entäuscht. Schlimmer noch:

Ich habe noch nie eine so albtraumartige Installation irgendeines Systems vornehmen müssen !
18 sinnlos vergeudete Stunden!

Warum schreibe ich nun in einem Linux-Blog über ein Update in der Windows-Welt ?

1. Weil bei mir Windows (XP, SP3) unter VMware auf einem Linux-Host läuft und ich bislang mit den Adobe-Tools auch Web-Applikationen entwickelt habe.

2. Weil man sich ab und zu eine Windows-SW-Installation antun muss, um wieder genau zu wissen, was die IT-Entwicklung mit Linux und Opensource erreicht und gewonnen hat. Man durchforste mal das Internet bzgl. Installationsfehlern und -Problemen mit CS4 ! Ich finde das Beispiel symptomatisch für den Verfall jeglicher Qualitätssicherung im kommerziellen SW-Bereich. Man fragt sich angesichts der riesigen Anzahl an Treffern wirklich: Warum muss man eigentlich so viel Geld für Produkte bezahlen, für die der Kunde schon bei der Installation Beta-Tester spielen muss?

Ich habe die CS4 – Installation unter folgenden Voraussetzungen begonnen:

Voraussetzungen :

Vorhandene Adobe SW: Adobe Web-Premium CS3 habe ich vor 1,5 Jahren unter Windows XP als Update zu Macromedia Studio 8 installiert. Bis vorgestern habe ich die CS3 Suite produktiv eingesetzt. Alle CS3-Komponenten und Programme sind gepflegt und auf dem neuesten Stand.

Windows XP: Mein Windows XP ist unter einer virtuellen Maschine (VMware Workstation) auf einem Linux-Host (z.Z. Opensuse 11.1) installiert. Die virtuelle Maschine wurde vor ca. 3 Wochen problemfrei auf eine neue HW-Plattform (mit Intel-Quad-Core Prozessor) umgezogen. (Vorher lief diese Maschine über 3 Jahre stabil auf einem Athlon X2-System.) Der HW-Wechsel führte zur Installation neuer Treiber unter Windows. Windows selbst musste danach neu aktiviert werden. (Die vorhanden Adobe-Produkte [CS3] interessanterweise nicht, obwohl ich auch das schon bei Kunden erlebt habe.) Die virtuelle Maschine lief seitdem auf der neuen Hardware ohne Störungen. Die VMware-Version selbst ist die aktuellste (WS 6.5.2).

Host und HardwareMein virtuelle Maschine läuft auf zwei 2,83 GHz Prozessoren (von insgesamt 4 der Quad-Core-CPU des Linux-Hosts). Windows habe ich 2 GB RAM (von insgesamt 8 GB des Hosts) zur Verfügung gestellt. Im Laufe der Installation habe ich VMware ferner 2 DVD-Laufwerke zugänglich gemacht. Beides SATA-Laufwerke, die im Linux-Host als /dev/sr0 und /dev/sr1 erschienen. Im Windows Host bilden sich die als SCSI-Laufwerke ab. Dies ist deshalb erwähnenswert, weil der BusLogic SCSI-Controller der virtuellen Maschine in dieser Situation mit dem Treiber von VMware und nicht von Microsoft betrieben werden muss, auch wenn die virtuellen Festplatten als IDE-Platten eingerichtet wurden.

Also: Windows XP ist bei mir zwar virtuell vorhanden, dafür aber sehr großzügig ausgestattet – auch für Adobe CS3-Verhältnisse, das ja mindestens ein GB RAM sehen will. Ich ging daher davon aus, dass auch CS4 nichts zu meckern haben würde.

Ziel der Installation

Ich wollte CS4 zusätzlich zum vorhandenen CS3 installieren, um bei evtl. Problemen noch auf CS3 zurückgreifen zu können. Das ist eigentlich das vorgesehene Standardverfahren – zumindest habe ich nichts
Gegenteiliges gelesen.

Problem: Die Installation von Web Premium CS4 bei vorhandenem aktuellem Web Premium CS3 funktioniert nicht oder zumindest nicht immer !

Die Installation (des Updates) funktioniert unter den oben genannten Voraussetzungen nicht! Ich möchte den Leidensweg meiner vielen Anläufe über mehr als 18 Stunden hinweg nicht im Detail beschreiben – das würde Seiten füllen. An dieser Stelle mögen Stichworte genügen:

Mehrere Installationsanläufe mit sich ändernden Fehlern / Update-Versuche der Komponenten, die installiert wurden, über das Internet mit völig unterschiedlichem Ergebnis / Crashes und Blue Screens der virtuellen Maschine (sowas habe ich zuvor über mehrere Jahre hinweg überhaupt noch nie erlebt) / Probleme mit der Adobe Acrobat Seriennummer nach Deinstallation von Acrobat.com (es lief schon fast alles ausser Acrobat) / Installation nur einzelner Komponenten von CS4 / Installation unter verschiedenen Usern / Installation von der Festplatte statt von DVD / Installation nach Deinstallation von CS3, ……… immer gab es irgendwo und irgendwann Probleme – z.T. massiver Art bis zum Absturz von Windows. Und alles auf einem bisher absolut stabilen System.

Ich behaupte mal, dass das nichts mit der VMware-Umgebung zu tun hat, sondern mit früheren regulären Updates der vorhandenen CS3-Programme und entsprechenden Registry-Einträgen, die dem CS4 nicht gefallen.

Und mit diesem Befund stehe ich weiss Gott nicht alleine da – im Internet gibt es -zig Seiten zu der völlig misratenen Installationsroutine von Adobe und zu den vielfältigsten Varianten der resultierenden Katastrophen. Typischerweise bricht die Installation bei einer oder mehreren wichtigen Programmen (Photoshop, Flash) ab. Man kann danach noch einige Reste an SW installieren. Insgesamt kommt es aber zu einem Fehler “1603”, der sich hartnäckig als irreperabel erweist. Zudem folgen u.U. eine Reihe weiterer Fehler 1714, 1907 etc., oft im Font-Bereich oder im Zusammenhang mit Acrobat, Photoshop oder Flash. Man suche mal im Internet unter CS4 und Fehler 1603 !

Die Versuche, es durch erneute Anläufe und Zugriff auf Updates aus dem Internet doch irgendwie hinzukriegen, münden nur in einen gigantischen und sinnlosen Aufwand (bei mir ca. 20 Arbeitsstunden). Das Verhalten des Installers ist dabei völlig unberechenbar und inkonsistent. Ich habe in stundenlangen Versuchen so ziemlich alles ausprobiert, was ich im Internet an Hinweisen von Leidensgenossen gefunden habe. Übrigens auch viele Ratschläge der Fa. Adobe, die bis auf einen nichts geholfen haben.

Dabei konnte ich nur deshalb halbwegs ruhig bleiben, weil ich vor dem ganzen Theater einen Clone meiner virtuellen Maschine angelegt hatte, auf den ich im Ernstfall zurückgreifen hätte können (es lebe VMware !). Ich möchte mir eine entsprechende Situation und die Gefühle von Leuten mit realen, produktiven Windows-Systemen gar nicht ausmalen! Im Internet gibt es dazu einiges zu finden.

Letztlich funktionierte bei mir nur eines – nähmlich ein Vorgehen nach dem Prinzip “tabula rasa”: Man bereinige das System von allen Adobe-Einträgen und früheren Installationen und installiere erst danach CS 4 (erneut).

Meine Lösung:

Läuft die Installation nicht von Anfang an fehlerfrei durch, so erhält man durch neue Versuche (auch durch erfolgreiche Updates) offfenbar ein immer problematischer werdendes System. Man entferne deshalb schon nach dem ersten Fehlschlag systematisch alles, was sich aus früheren Installationen auf dem System befindet. In meinem Fall bedeutete das Folgendes:

  1. Systematische Entfernung von Adobe CS3
    Es reicht nicht, das über eine Windows-SW-Deinstallation zu tun. Man beschaffe sich vielmehr gleich die Tools von Adobe (http://www.adobe.com/support/contact/cs3clean.html) und benutze die mindestens auf Level 2 (ggf. 3 oder 4 – man kann dies
    einfach eingeben, wenn nach dem Level gefragt wird)
    .
  2. Reboot des Windows-Systems
  3. Beseitigung aller vorhergehenden (missglückten) Ruinen der CS4-Installation.
    Dazu setze man nach einer Deinstallation über das Windows SW-Management auch die Reinigungstools von Adobe ein (http://www.adobe.com/support/contact/cs4clean.html). Gut, dass es wenigstens diese Tools gibt.
  4. Reboot des Windows-Systems
  5. Reinigen der Oberfläche der CS4-DVDs (es gibt sehr viele Mini-Dateien zu übertragen – das DVD-Laufwerk wird in puncto häufige Positionierung sehr belastet)
  6. Installation als “administrator” – es wird wirklich der Windows “system”-Account benötigt.
  7. Abschalten des Virenscanners (rein aus Zeitgründen) – eine sinnvoll konfigurierte Personal-Firewall bereitete keine Probleme (F-Secure in meinem Fall).
  8. Zur Sicherheit: Zuordnung von nur einem Prozessor-Kern zur virtuellen Maschine. Bei SATA-DVD-Laufwerken am Host : Check, dass dem BusLogic-SCSI-Controller der virtuellen Maschine der VMware-Treiber und kein Microsofttreiber zugeordnet ist. Mit dem Microsoft-Treiber laufen die Sata-Devices, die als SCSI-Laufwerke abgebildet werden, nicht stabil genug. Den VMware-Buslogic-Treiber findet man im Downloadbereich der VMware-Website.
  9. Zuordnung zweier DVD-Laufwerke zur virtuellen Maschine und Einlegen der ersten CS3 DVD in ein Laufwerk. Dies gilt vermutlich nur,wenn CS4 als Upgrade eingespielt wird. Bei mir wurde die Seriennummer des CS4-Paketes nach der Deinstallation von CS3 und CS4 nicht mehr akzeptiert, solange der Installer nicht irgendwas von CS3 auf dem System finden konnte. Ich habe daher im zweiten Laufwerk während der ganzen Installation die CS3-DVD mitlaufen lassen.
  10. Neuinstallation von der CS4-DVD. Das lief bei mir dann anstandslos durch.
  11. Bei manchen Leuten hat es geholfen, die DVDs auf C:/ zu kopieren und dann von der Festplatte aus zu installieren. Man muss dabei aber den Namen des Verzeichnisses “Adobe CS4” jeder DVD rechtzeitig während der Installation umbenennen – der Adobe Installer sucht beim verlangten DVD-Wechsel immer nach dem gleichen Verzeichnis “Adobe CS4”. (s. auch “http://www.keptlight.com/?p=383” und die dortigen Hinweise).

Diskussionswürdige Ratschläge von Adobe im Internet

Noch etwas – einige Hinweise von Adobe selbst im Internet (http://kb.adobe.com/selfservice/viewContent.do?externalId=kb404083_ger_DE&sliceId=1)
sind für mein Gefühl letztlich eine Zumutung (obwohl sie bei dem einen oder anderen Betroffenen geholfen haben mögen):

So stimmt mich der lapidare Hinweis, es unter Abschalten aller Firewalls und Virenscanner zu versuchen, von Haus aus nicht nur missmutig sondern auch mißtrauisch. Warum sollte das erforderlich sein ? Was betreibt Adobe da auf der Maschine ? Ich habe das trotzdem probiert – genutzt hat es gar nichts. Das gleich gilt für die empfohlene Deinstallation des Google-Desktop – sowas gab und gibt es bei mir sowieso nicht.

Hinzu kommen die Aufforderungen, die Installation doch bitte mal für einen neu angelegten User zu versuchen oder gar auf einem anderen Computer. Wenn es so auch nicht ginge, solle man sich an Adobe wenden ! Ansonsten an den Hersteller des Computers.

Was denken die sich eigentlich ? Dass jeder Kunde gerade mal einen zweiten Computer für stundenlange Tests parat hat und dass kleinere Firmen es sich leisten können, im produktiven Umfeld nebenbei neue User einzurichten und dann alle erforderlichen Konfigurationseinstellungen nachzuziehen. Sinngemäß heisst das: Lieber Kunde wende dich erst an mich, wenn du meine fehlerhafte SW, deren Installation ca. 2,5 Stunden kostet, mehrfach auf verschiedenen Systemen und unter anderen Accounts ausprobiert hast. Und wenn du dabei zufällig eine Konstellation finden solltest, mit der auch wir bei der Entwicklung des
Installers gerechnet haben, dann darfst du dich wegen der vorhergehenden anderen Probleme nicht mehr an uns sondern deinen Computerhersteller wenden. Was für eine Zumutung und Arroganz – und was für ein Armutszeugnis für eine so renommierte Firma !

Dann lese man sich auch mal folgende interessanten Blog-Artikel zum persönlichen Service von Adobe im Zusammenhang mit der CS4-Installation durch:

http://www.keptlight.com/?p=382 und http://www.keptlight.com/?p=383

Dem gibt es nichts hinzuzufügen !

(Zugegebenermaßen gibt es auch bessere und sachlichere Beispiele an Adobe Ratschlägen :
http://kb.adobe.com/selfservice/viewContent.do?externalId=kb408716 – Lösung 7.

Schlechte Erfahrungen auch schon mit CS3

Auch bei der Installation von CS3 (Upgrade von Studio8) vor eineinhalb Jahren gab es bereits erhebliche Probleme, die ich damals aber umschiffen konnte. Ich hätte also gewarnt sein können. So schlimm wie bei CS4 war es aber bei weitem nicht gewesen!

Fazit und Appell:

Liebe Leute von Adobe:

Wenn ihr einfach zugeben würdet, dass die Installation bei einem vorhandenen CS3 nicht läuft und im Internet schreiben würdet, dass man von vornherein alles, was mit Adobe zu tun hat, vom System entfernen muss und zugleich die Registry mit euren Cleaner-Tools bearbeiten muss, so würdet ihr vielen Menschen weniger unproduktive und sinnlos vergeudete Zeit von ihrem Leben stehlen. Würden allein alle diejenigen Betroffenen, die zu den Installationsprobleen im Zshg. mit CS4 inzwischen etwas ins Internet gesetzt haben, für die vergeudete Zeit eine Rechnung zum Stundensatz eurer Entwickler stellen, würde das für euch sehr teuer werden. Diese Summe solltet ihr künftig in die Qualitätssicherung eurer Installationsroutinen stecken!

Bei mir hat die CS4-Installation nur dazu geführt, mich wieder intensiver im Opensource-Bereich nach Alternativen umzusehen. Was bei Flash zugegebenermaßen ein schwieriges Unterfangen ist ….

VMware WS 6.5.1(2), Opensuse 11.1, Kernel-Update

Posted on by

Bei mir laufen die VMware-Workstation Versionen 6.5.1 und 6.5.2 inzwischen unter Opensuse 11.1 mit KDE 4.2 auf einem x86_64 System mit Intel-Quad-Core-Prozessor ohne Probleme (Kernel-Versionen: 2.6.27.19-3.2-default und 2.6.27.21-0.1-default).

Nachdem ich dabei allerdings zum zweiten Mal auf die neuen Install- und Kompilationsmechanismen von VMware reingefallen bin, dokumentiere ich kurz, wie man mit den neuen VMware-Workstation-Versionen (> 6.5.1) nach einem Kernel-Update verfahren kann und wie man eine Rekompilation der benötigten Module erzwingt.

Problemsituation 1 nach Kernel-Update:
Ich hatte VMware unter Opensuse 11.1 (mit KDE 4.2) neu installiert. Die Installation und die spätere Einrichtung einer virtuellen Maschine verliefen zunächst problemfrei. Dann habe ich den Kernel upgedated. Folgt man dem von früher gewohnten Verfahren, so müsste man nun “vmware-config.pl” laufen lassen. Dieses Script sucht man ab Version 6.5.1 allerdings vergeblich. Es hilft hier aber überraschenderweise (manchmal ?), einfach einen Neustart der virtuellen Maschine zu versuchen. Wird erkannt, dass ein neuer Kernel vorliegt, so erfolgt automatisch eine Neukompilation der benötigten Module. Hilft dies nicht, so siehe das Vorgehen unter Problem 2.

Problemsituation 2:
Nach einer Neukompilation des Kernels hatte ich in einem anderen Fall zudsätzlich noch eine neue Version der Workstation über das entsprechende “bundle”-Paket installiert. D.h., es handelte sich um eine Neuinstallation über eine bereits vorhandene ältere VMware-Installation. Leider gab der graphische Installer das Installationsverhalten falsch wieder. Er teilte mir nämlich mit, dass das alte System deinstalliert und dass die nachfolgende neue Installation erfolgreich abgeschlossen wurde. Dies war in meinem Fall aber falsch: Die Installation schlug wegen nicht ladbarer Kernelmodule fehl. Dies sieht man aber erst nach einem Blick in die Datei “/var/log/vmware-installer”.

Lösung: Erzwinge Neukompilation
Die Lösung besteht darin, eine Neukompilierung zu erzwingen. Am einfachsten erreicht man dies dadurch, dass man die vorhandenen von VMware im “bundle” mitgelieferten Kernelmodule, die der Installer verwenden will, entfernt:

mv /usr/lib/vmware/modules/binary /usr/lib/vmware/modules/binary_orig

Danach startet man VMware erneut – entweder über den KDE-Menü-Punkt unter “Programme->System->Weitere Programme->VMware Workstation” oder durch den Aufruf von “vmware” in ein er Shell. Es wird dann eine Neukompilation der VMware-Kernel-Module durchgeführt. (Bei mir zumindest liefen die Neu-Kompilation und das anschließende Laden der Module erfolgreich ab.)

Ob in anderen Problemsituationen ein direktes Löschen der vmware-Kernelmodule unter “/lib/modules/KERNEL_VERSION/misc” hilft, habe ich nicht ausprobiert.

Zusätzlicher Hinweis 07.06.2009:

Vor einer kompletten Neuinstallation (z.B. des Bundles VMware-Workstation-6.5.2-156735.x86_64.bundle ) ist es übrigens ratsam, zunächst die Verzeichnisse “/usr/lib/vmware” bzw. “/etc/vmware” zu löschen. Ich hatte Schwierigkeiten, eine komplette VMware-Neuinstallation auch mit dem Kernel 2.6.27.19 durchzuführen. Der Installer lief dabei zunächst eine ganze Weile ordnungsgemäß (Deinstallation vorhandene Version, Kopieren von Files, Konfiguration Player,..), stoppte dann aber und deinstallierte die eben erst eingerichteten Dateien wieder.
Evtl. lag dies an dem Vorhandensein des früher (s.o.) erzeugten Verzeichnisses “/usr/lib/vmware/modules/binary_orig” oder an Einträgen in “/etc/vmware”, die der Installer nicht selbständig beseitigt.

Nach dem Löschen war eine VMware-Neuinstallation mit dem Kernel 2.6.27.19 jedenfalls möglich. Danach kann man dann den Kernel-Update auf spätere Versionen (z.B. auch 2.6.27.23) wir oben beschrieben durchführen.

Link:
http://communities.vmware.com/thread/185900

VMware – Windows – kein Sound ?

Posted on by

Gestern hatte ich einen dummen Fehler zu beheben, an dem ich möglicherweise selbst schuld war. Die zugehörigen Meldungen des Systems aus Redmond waren aber auch nicht dazu angetan, der Sache schnellstmöglich auf die Spur zu kommen. Da diese Meldungen z.T. widersprüchlich bis kurios sind, hilft der folgende Beitrag vielleicht auch anderen:

MS Win XP läuft bei anracon auf Opensuse Hosts als VMware-Gastsystem. Da ich fast nie den Bedarf verspüre, auch noch Töne aus dem Windows-System zu hören, ist die virtuelle Soundkarte bei mir normalerweise deaktiviert. Nun ergab sich gestern doch einmal der Bedarf, dem Windows-Gast ein paar Töne zu entlocken (Grund war eine Flash-Programmierung). Da ich wusste, dass mir das früher schon gelungen war (allerdings unter Opensuse 10.2 statt meinem aktuellen 10.3 und mit der VMware Workstation 5 statt der WS 6), fügte ich meiner virtuellen Maschine frohgemut eine virtuelle Soundkarte hinzu.

Windows erkennt diese Karte – eine Soundblaster PCI 128 – im Normalfall auch anstandslos und lädt den passenden, im Windows Treiber-Resevoir befindlichen Treiber. Der Windows Gerätemanager zeigte mir dann auch brav, dass die Soundkarte funktionstüchtig sei.

Leider war aber schon beim obligatorischen Windows-Neustart die übliche Redmonder Startmelodie nicht zu vernehmen. Da dachte ich noch optimistisch, dass der Ton vielleicht zu leise eingestellt sei. Also: Linux-Soundsystem und Mixereinstellungen überprüfen – alles OK.

Im nächsten Schritt rief ich dann die Lautstärekregelung bzw. den Mixer im Windows-System auf. Antwort des Systems: ” Es ist kein Mixer installiert. Gehen Sie zu “Drucker und sonstige Hardware”, um einen geeigneten Mixer zu installieren.” So einen Punkt gibt es zwar gar nicht und was der Drucker damit zu tun haben soll, bleibt auch rätselhaft. Aber wer weiß schon, wie Windows-Entwickler denken …..

Früheren Erfahrungen folgend werfe ich erst mal einen kleinen Blick in die Registry. Sieht alles OK aus. Auch hier ist die Soundblasterkarte verzeichnet. Anderen schlechten Erfahrungen mit Windows folgend, entferne ich die Soundkarte dennoch aus der Hardwareliste und lasse sie danach neu erkennen und installieren. Keine Veränderung. Die Karte läuft angeblich, aber “No Sound” – kein Ton vom Windows VMware Gast. Also doch ein Problem mit VMware WS 6 unter Opensuse 10.3 ?

In banger Erwartung werfe ich nun einen Blick ins Internet und in diverse VMware Foren – wenig überrascht stelle ich fest, dass bemerkenswert viele Leute Probleme mit dem Sound eines Windows-VMware-Gastes auf einem Linux-Host haben – wenn auch eher im Ubuntu/Debian-Bereich als unter SUSE.

Ich befolge dann zur Sicherheit den ersten Ratschlag, aus alten Archiven den letzten Creative-Treiber für diesen Typ Soundkarte im Gastsystem zu installieren. Die Installation verlief zwar erfolgreich, zeitigte aber keinen Effekt in puncto “hörbare” Töne. Ich folge weiteren intelligent klingenden Diskussionen darüber, dass VMware evtl. Probleme mit Alsa habe und dass das liebe, alte “OSS” statt “Alsa” aktiviert werden müsse. Ich probiere diverse Varianten und Einstellungen des Linux-Soundsystems unter KDE aus. Keine Wirkung. Kein Ton. Auch andere Ratschläge in diversen Foren helfen nicht weiter.

In dem sicheren Bewusstsein, dass das alles doch schon mal lief, gebe ich die Schuld nun endgültig irgendeiner verpfuschten Einstellung unter Windows. Ein wenig dumpfes Suchen führt mich zu “Sounds und Audiogeräte” unter der “Systemsteuerung”. Hier kommt die interessante Meldung “Kein Audio-Device”, die in krassem Widerspruch zu den Informationen des Gerätemanagers steht, der eine funktionstüchtige Soundkarte meldet.

Etwas genervt kommt mir der Gedanke, dass die Soundkarte vielleicht zwar läuft, aber nicht ins System eingebunden ist – was vielleicht auch den fehlenden Mixer erklären könnte. Für letzteren sollte ich ja meinen Drucker checken, ha, ha, ha … . Das tue ich nicht, sondern wende mich
nun der Zwischenschicht der “Dienste” unter Windows zu und studiere die entsprechende Rubrik in der “Verwaltung”. Und da werde ich endlich fündig: Der Dienst “Windows Audio” befindet sich im Status deaktiviert.

Wie kam er denn in den Zustand? Liebe Leut’, glaubt es mir, ich weiß es nicht. Da ich für Windows nur eine sehr schlampige Buchführung zu administrativen Änderungen führe, kann ich nicht ausschließen, dass ich diese Einstellung irgendwann mal selbst vorgenommen habe. Vielleicht war es aber doch eines der vielen Updates ?

Na ja, die Umstellung des Dienstes auf einen öminös klingenden “Autostarttyp: Automatisch” bringt die Erlösung – endlich vernehmbare Töne aus dem Windows-Gast-System. …

Hmm …. “Autostarttyp Automatisch” – da braucht man auch erst mal Zeit, um über diese Alliteration hinweg zu kommen … Toll ist auch “Autostarttyp: Manuell “….. Wer sich sowas wohl ausgedacht hat ? Aber ich schweife ab ….

Was lernen wir nach 1 Stunde Nervenverlust zum Thema “Kein Ton vom Windows Gast auf einem Linux-Host”:

  1. Prüfe zunächst, ob die virtuelle Soundkarte erkannt wurde und ob der zugehörige MS Treiber geladen wurde (der reicht nämlich).
  2. Überprüfe dann die Anzeige des Soundblaster-Devices unter “Sounds und Audiogeräte” in der Systemsteuerung.
  3. Prüfe dann, ob der Audio-Service überhaupt aktiv ist.
  4. Fange erst dann, wenn die oberen Punkte alle OK sind, an, über Probleme von VMware und/oder Linux nachzudenken.

……und – fast hätte ich es vergessen – führe ein Logbuch auch über administrative Veränderungen am Windows-Gast-System ……selbst wenn es nervt …..

VMware – config-Datei nach Kernel-Update

Posted on by

In einem Beitrag zur VMware Workstation habe ich beschrieben, was man tun muss, wenn man ein Update des Kernels durchführt. In noch früheren Beiträgen standen Rezepte zur manuellen Vorgabe der CPU-Taktung für VMware in der Datei /etc/vmware/config. (Dies ist für den ordentlichen Betrieb auf manchen Prozessoren wichtig).

Ich vergaß, in beiden Beiträgen Folgendes zu erwähnen: Ein Durchführen der Prozedur “vmware-config.pl”

  • nach einem Kernel-Update
  • oder wenn man Veränderungen an den VMware-Basiseinstellungen wie dem virtuellen Netzwerk vornehmen will

führt zu einer Neuerzeugung der Datei “/etc/vmware/config”. Dabei verliert man i.d.R. alle schönen und mühsam erarbeiteten Einträge der Art

host.cpukHz = 2412359
host.noTSC = TRUE
ptsc.noTSC = TRUE.

Daher nun nachträglich der Hinweis:

Immer eine eigene Sicherung der “/etc/vmware/config” mit allen erarbeiteten eigenen Parametern anlegen. Nach der Durchführung von “vmware-config.pl” den Stand der “config”-Datei prüfen und die Parameter ggf. wieder nachtragen.

Das ist zugegebenermaßen unangenehm. Ich kenne aber keinen Weg, das zu vermeiden. Es liegt nahe, ein kleines Script zu schreiben, das wenigstens die Editierarbeit für einen erledigt.

VMware Workstation und Kernel-Updates

Posted on by

Kernel-Updates werden immer wieder von den jeweiligen Distributoren angeboten. Gründe sind die laufende Fehlerbehebung und natürlich das Schließen erkannter Sicherheitslücken.

In einem Linux-System bedeutet ein Kernel-Update einen Eingriff, der im Nachhinein Anpassungsarbeiten am System erforderlich machen kann. Betroffen sind u.a. (Treiber-) Module, die nicht mit den Kernelbibliotheken der Distribution mitgeliefert wurden und werden, sondern von externer Quelle stammen und für den vorherigen Kernel kompiliert wurden. In den meisten Fällen ist eine Neukompilation dieser Programme unumgänglich. Das gilt im Besonderen für Grafikartentreiber (z.B. von Nvidia) und eben auch für VMware und seine Module.

Im Falle von VMware ist das Vorgehen zur Neukompilation heute allerdings sehr einfach und unproblematisch:

1) Nach dem (obligatorischen) Reboot des Systems stoppt man zur Sicherheit zunächst die laufenden VMmware-Prozesse, die im Zuge der Systeminitialisierung über das Skript “vmware” in /etc/init.d automatisch gestartet wurden. Als root gibt man hierzu einfach “vmware stop” am Prompt seiner Konsole ein.

2) Dann startet man das Skript “vmware-config.pl” (i.d.R. zu finden in “/usr/bin” ) . Das Skript fragt einen der Reihe nach die Einstellungen ab, die bereits während der Erstinstallation festgelegt werden mussten, und führt auch eine Neukompilation der benötigten Module durch. Die meisten Einstellungen – u.a zum Netzwerk – kann man dabei bequemerweise auf dem bereits definierten Stand belassen, indem man die zugehörigen Nachfragen entsprechend beantwortet.

3) Im Normalfall startet das Skript abschließend die erforderlichen VMware-Prozesse neu. Geschieht dies nicht automatisch, so bedient man sich wieder des “/etc/init.d/vmware”-Skripts.

Es ist extrem selten, dass die Neukompilation zu anderen Problemen führt, als die die man bereits während der Erstinstallation durchlaufen hat. Mir ist es allerdings schon passiert, dass SuSE einmal nicht den passenden Source Code zum vorkompilierten Kernel ausgeliefert hatte. Für die Problemanalyse gibt es in der Regel kein Patentrezept. Man muss sich eben auf die Meldungen des Compilers seinen Reim machen.