Category Archives: VMware Workstation

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

Dell M90, Suse 11.2, KDE 4.4, VMware – Teil I

Posted on by

Ich habe einen Dell Precision M90 als PC-Ersatz (80GB SATA HD, 2GB RAM, 2.16 GHz Intel Dualcore). Bestückt war dieser Laptop bislang mit einer Dual-Boot-Konfiguration aus Opensuse 10.3 und Windows XP SP 3 (von Dell). Unter Windows XP läuft zudem VMware – um unter einem Opensuse 10.3-Gastsystem einen Apache2- und einen Samba-Server bereit zu stellen. Zudem habe ich eine externe USB-Disk, auf der ein separates Opensuse 11.1 und eine Xen-Installation für Experimente bootfähig zur Verfügung steht.

Da ich den Laptop im letzten Jahr nur sporadisch benutzt habe, konnte ich mit der bisherigen Installation gut leben. Windows ist halt träge (s.u.), aber wegen ein paar Präsentationen von PHP-Programmen denkt man nicht wirklich über eine bessere und umfassendere Neu-Installation nach. Jetzt – nach einer längeren Abwesenheit von meinen normalen Linux-PCs – reichte mir das nicht mehr.

Wunschkonfiguration

Ich wollte und will den Laptop nun primär unter Opensuse 11.2 und mit KDE 4.4 betreiben. Das auf einer physikalischen Partition installierte Win XP soll künftig in einer virtuellen VMware-Maschine unter Linux zum Einsatz kommen – mit der Wahlmöglichkeit, es später bei Bedarf auch direkt booten zu können.

Das angestrebte System lässt sich auf der Dell Precision Plattform mit ein wenig Experimentierfreude auch tatsächlich implementieren. Wie man ein in einer Dual Boot-Konfiguration vorhandenes Win XP in einer virtuellen Maschine unter Linux zum Laufen bringt, werde ich in einem nachfolgenden Artikel (Teil II) beschreiben.

KDE44_DEll_M90

In diesem ersten Artikel möchte ich dagegen einen kurzen Überblick darüber geben, was für Erfahrungen ich mit dem Dell-Precision-System bislang und in den letzten Tagen speziell unter Opensuse 11.2 gemacht habe.

Performance des Dell M90 unter Win XP (32 Bit):

Die Performance unter Win XP ist vom Gefühl her wirklich unzureichend. Hauptgrund ist die sehr schlechte Performance der Harddisk und/oder des SATA-Controllers in Kombination mit Win XP. Installiert sind die empfohlenen Intel-Chipset-Treiber, die den Treiber für den SATA-Controller beinhalten. Die Platte ist eine Seagate ST980825AS.
Dennoch gilt:

Allzu oft wartet man – oder besser das Win XP-System – auf den Abschluss von Harddisk-Operationen. Und damit meine ich, dass man das Gefühl hat, dass das ganze System steht oder träge wird, wenn größere Schreib- oder Leseoperationen auf der Harddisk durchgeführt werden. Die Platte ist eigentlich im Internet gut bewertet. Und Tests unter Linux zeigen, dass beim Kopieren von Platte zu Platte mehr als 15 MB/s möglich sind. Dennoch hinkt das Win-XP System immer wieder den Plattenoperationen hinterher. Das fängt beim Systemstart an, zieht sich über die Phase des initialen Virenscans hinweg und setzt sich im Normal-Betrieb bei allen plattenintensiven Operationen fort.

Als Linux-Anwender weiß ich vermutlich einfach nicht mehr, welch ineffektiver Systemnutzung man sich unter MS Windows ausgesetzt sieht und was man als einfacher Benutzer als “normal” akzeptieren muss. Wenn man das Arbeiten an einem ordentlichen Linux-PC mit ähnlicher Ausstattung gewohnt ist, macht sich auf dem Dell-Precision-System unter Win XP jedenfalls dauerhafter Frust breit.

Echtes Multitasking mit plattenintensiven Programmen im Hintergrund kann man da nicht betreiben, selbst wenn man feststellt, dass die CPU überhaupt nicht ausgelastet ist.

Ich weiß leider nicht, wem man wirklich die Schuld geben soll oder muss – F-Secure als Virenscanner unter Win XP, der schlechten Performance und dem schlechten Harddisk-Handling unter Win XP, dem Intel SATA-Driver oder dem Dell-System als Ganzem – das Plattensystem ist
jedenfalls unter Win XP ein echter und aus meiner Sicht inakzeptabler Engpass. Ehrlich gesagt habe ich auch wenig Lust dem Phänomen im Detail nachzugehen, wenn ich auf dem Sony-Laptop einer Bekannten unter Vista ein ähnlich träges Verhalten erlebe. Dasselbe gilt für ein XP-System auf einem Fujitsu-Siemens Laptop. Zu Windows 7 oder 64-Bit Varianten der Windows-Systeme kann ich mich nicht äußern.

Trotz der schlechten Platten-Performance ist es mit viel Geduld beim Hochfahren aller Komponenten möglich, unter dem Win XP System eine VMware Workstation mit einem Opensuse 10.3 als Gastsystem zu betreiben. Unter dem virtuellen Gastsystem laufen dann bei mir – wie gesagt – ein Samba-Fileserver und ein Apache2-Webserver. Ich benutze diese Kombination für die Präsentation von PHP-Serverprogrammen bei Kunden. Zum Einsatz kommt dabei auch Adobes Web Premium Suite mit Dreamweaver CSx. Das sind alles Ressourcenfresser. Aber Gott sei Dank benötigt das Opensuse Gast-System nur relativ wenig Hauptspeicher – 512 MB sind genug, auch wenn KDE 3.5 gestartet wird. Wenn das dann alles (Win XP, VMware, Adobe SW) mal hochgefahren ist, kann man ganz gut arbeiten – zumindest im Rahmen einer Präsentation. Man muss halt die 5 – 10 Minuten des Systemstarts und der Windows Upgrade-Orgien für ein freundliches Kundengespräch nutzen.

Was unter Win XP dagegen sehr gut funktioniert, ist die Lüftersteuerung. Der Lüfter geht nämlich kaum an. Zu bedenken ist hier aber, dass das System unter meinem Win XP nur mit 32 Bit läuft und die Grafikkarte wohl vollständig in einem 2D-Modus operiert und praktisch nie in einen 3D-Modus schaltet. Die thermische Belastung ist hier also von Haus aus gering. Die zwei Lüfter, im Besonderen der auf der CPU-Seite des Laptops, laufen deshalb nur in einem Minimalmodus, der geräuschmäßig nicht auffällt. Der CPU-Lüfter schaltet dagegen öfter einen Gang höher, wenn man anfängt, die virtuelle Maschine auszureizen. Bei ein wenig Web-Entwicklung und PHP-Testen passiert das aber praktisch nie. Und wenn, so läuft der Lüfter nicht auf Maximalstufe und das Geräusch ist gut auszuhalten. Also das muss ich sagen: Unter Win XP wird man praktisch keiner Geräuschentwicklung durch Lüfter ausgesetzt. Sehr gut !

Sehr gut funktioniert unter Win XP auch das Einstellen der Energiesparmöglichkeiten. Der Schirm erweist sich allerdings als Energiefresser.

Der Akku reicht von Haus aus ma. 2.5 – 3 Stunden – aber nur, wenn man die Helligkeit des Schirms um mindestens zwei Stufen reduziert. Bei einem Desktop-Ersatz-System ist das tolerierbar. Dell verkauft das System ja explizit nicht als Energiesparer – dafür ist es einfach nicht gedacht. Es ist eher ein mobiler Desktop. Das Gewicht ist für ein echtes Mobile-Gerät auch viel zu hoch. Wenn man allerdings eine kleine Workstation bei einem längeren Aufenthalt an einem stationären Ort braucht, ist der Laptop ein gute Wahl. Wenn man denn ein vernünftiges Betriebssystem installiert ……

Installation von Opensuse 11.2 (64 Bit) mit KDE 4.4

Die Installation von Opensuse 11.2 64 Bit ist auf dem Dell M90-Laptop völlig problemlos möglich – egal ob über das Internet oder von einer DVD. Das gilt auch unabhängig vom Ziel-Datenträger: Eine Installation auf einer externen USB-Disk lässt sich genauso durchführen ist wie eine Installation auf der eingebauten Harddisk.

Ich verwende i.d.R. tatsächlich zwei solcher Installationen. Gründe:

So kann man das Opensuse- System auf der USB-Disk auch auf anderen Systemen benutzen, die USB-bootfähig sind. Ferner kann man eines der beiden Systeme für Experimente benutzen, ohne das produktive System auf der jeweils anderen Disk zu gefährden. Ist die USB-Disk schneller als die eingebaute Disk von Dell, so lassen sich für die angestrebte Kombination mit Win XP evtl. auch Performance-Gewinne verzeichnen, wenn man das produktive Linux-System dort installiert. Auch auf normalen PCs bewährt es sich ja, das virtuelle System auf
einer anderen Harddisk als derjenigen für das Hauptsystem zu betreiben.

Mit ein wenig Bios- und Grub-Kosmetik kann man die USB-Installation so einrichten, dass ein Grub-Startmenü auf der USB-Disk selbst hinterlegt wird und dann sowohl einen Eintrag zum Booten des Betriebssystems auf der USB-Disk als auch weitere Einträge für Systeme auf internen Harddisk anbietet. Dieses Grub-Menü der USB-Disk erscheint nur dann, wenn beim Starten des Laptops die USB-Disk bereits angeschlossen ist. Im Laptop-BIOS muss die entsprechende USB-Disk als primäre Disk eingetragen sein. Hierzu schreibe ich mal einen separaten Artikel.

Was lässt sich sonst noch zur Installation sagen? Als Filesystem habe ich Ext4 installiert. Als Desktop wähle ich primär KDE, nachdem ich mich dort seit KDE 4.2 immer wohler fühle. Gnome installiere ich mir im Nachhinein zusätzlich, um da ein wenig auf dem Laufenden zu bleiben. Die automatische Hardware-Konfiguration, die der SuSE-Installer vorschlägt, lasse ich nicht zu. Ich möchte die Vorschläge des Installers lieber sehen und bestätigen. Dabei lernt man meist immer auch noch was über die betroffene Hardware.

Nachdem der SUSE-Installer seinen Teil erledigt hat, führe ich in der Regel (und nicht nur auf dem Laptop) noch folgende Schritte durch :

a) Internet-Anbindung
Zuerst sorge ich für eine Internet-Anbindung. An meinem jetzigen Aufenthaltsort kopple ich mich per WLAN an einen WLAN-Access-Punkt an. Für die eingebaute WLAN-Karte von Intel (eine Pro/Wireless 3945ABG) gilt, dass Sie sich mit Hilfe des KDE “KNetworkManagers” anstandslos einrichten lässt. Ich hatte und habe damit normalerweise überhaupt keine Probleme, zumindest dann nicht, wenn der zugehörige WLAN-Access-Point sauber konfiguriert ist. Bei WEP-Verbindungen (ja, sowas gibt es noch!) muss man sich ein wenig in die jeweils geforderte Konfiguration vertiefen – man beachte, ob ein Access Key im Hex-Format oder ein “gemeinsames Passwort” gefordert ist. Das Menü des KNetworkManager bietet alle Möglichkeiten – z.T. über Drop-Down-Menüs. WPA/WPA2-Verbindungen stellen gar kein Problem dar.

Die Konfiguration von Ethernet-Schnittstellen ist genauso einfach möglich. Hier greife ich gewohnheitsmäßig nicht zum KNetworkManager sondern zu YAST und der dortigen Verwaltung von if-down, if-up etc.. KNetworkmanager wird dabei leider deaktiviert – hier hilft aber ein anschließender Blick in die SUSE sysconfig-Dateien – z.B. per Yast und dem “/sysconfig”-Editor. Dort setzt man dann den USERCONTROL-Parameters unter “Hardware-Network-wlan0” wieder auf “yes”. Natürlich kann man auch die entsprechende Datei unter /etc/sysconfig editieren. Oder eben gleich den KNetworkmanager auch für die Konfiguration der Ethernet-Karten benutzen.

b) Updates
Steht die Internet-Anbindung, so versorge ich die YAST-SW-Installationsprogramme erst einmal mit den von mir bevorzugten Repositories. Für KDE 4.4 nutze ich das Factory-Repository. Hinzu kommen das Openoffice-Repository, das Mozilla-Repository, das M17N-Repository. Des weiteren nutze ich das Packman-Repository über einen der zugehörigen Mirror-Server und noch ein paar weitere Repositories aus dem Entwicklungsbereich. Ich führe dann alle notwendigen Updates durch – im Besonderen Kernel-Updates. Macht man das gleich, spart man sich später überflüssige Neukompilationen der Nvidia-Treiber-Module und der VMware-Module.

Sind die Repositories in die YAST-RPM-Verwaltung eingebunden, installiere ich KDE 4.4 – zuerst das Base-System und nach einem erneuten KDE-Start dann den Rest. Aus dem Packman-Repository hole ich mir die libxine-Bibliotheken, kaffeine, k3b und alles, was das Herz sonst noch im Xine-Umfeld begehrt. Hinzu kommen die neueste Openoffice-Version, C/C++-Compiler, der Kernel Source-Code, etc, etc….. Für KDE 4.4 ist es übrigens noch hilfreich, “Virtuoso” und “Akonadi” möglichst vollständig zu installieren. Virtuoso wird als Backend für Nepomuk, Strigi und Co. benutzt. Akonadi liefert in der Zukunft das neue
Backend für Adressbuch-, Mail- und andere Groupware-Dienste.

c) Nvidia-Treiber
Ist das System so auf einen aktuellen, brauchbaren Stand gebracht und u.a. in der Lage, Kernel-Module zu kompilieren, installiere ich den Nvidia-Treiber für die Quadro FX-Karte des Laptops. Hierzu benutze ich i.d.R. nie das Nvidia-Repository, sondern lade mir den neuesten Treiber – hier den 190.53-Treiber – von nvidia.de herunter. Die Installation inkl. Modul-Kompilation im Runlevel 3 (init 3) über die Shell geht – wie erwartet – problemfrei über die Bühne. Adaptive Clocking für die Grafikkarte ist automatisch aktiviert. Das kann man später unter KDE über das Nvidia-Settings-Panel im Powermizer-Bereich prüfen. Will man übrigens später ein Down(!)-Clocking der Taktrate der Videokarte ausprobieren, so muss man die “Coolbit”-Option in “/etc/X11/xorg.conf” setzen

Section “Screen”
Identifier “Screen0”
Device “Device0”
Monitor “Monitor0”
DefaultDepth 24
Option “Coolbits” “1”
# Option “RegistryDwords” “PowerMizerEnable=0x1; PerfLevelSrc=0x2222; PowerMizerLevel=0x3; PowerMizerDefault=0x3; PowerMizerDefaultAC=0x3;”
SubSection “Display”
Depth 24
EndSubSection
EndSection

Von einem Overclocking läßt man auf einem Laptop die Finger – schon wegen der Garantiebestimmungen. Ein Herunterfahren der Taktraten ist aber wegen Energieeinsparungen durchaus ein Thema. Siehe auch :
http://linux.aldeby.org/nvidia-powermizer-powersaving.html
http://linux.aldeby.org/enable-nvidia-coolbits-frequency-tuner.html

d) Hinweise zum Anpassen des Desktops
Nach einem init 5 und einem Login in den KDE-Desktop prüfe ich mit Hilfe der KDE-“Systemeinstellungen” ein paar OpenGL-, 3D- und Transparenz-Effekte aus. Alles läuft einwandfrei. Auch “compiz” läuft nach einer entsprechenden Installation wie es soll. Nun steht der Einrichtung eines “eye-candy”-3D-Desktops also nichts mehr im Wege. [MS Windows Anwendern aus dem Bekanntenkreis fallen hier dann doch immer wieder die Augen aus dem Kopf, welche hübschen Effekte unter Linux heute zum Standard gehören. Das ist es mir wert. Hier geht es natürlich nicht um sinnvolle Dinge für ernsthafte Arbeit – nur um etwas Werbung :-). ].

Ach ja – die Schriften. Hier installiere ich mir mit Hilfe der KDE-“Systemeinstellungen” zunächst die TTF-Schriften aus dem vorhandenen MS Windows-System. Das ist einfach der schnellste Weg. Danach stelle ich die Systemschriften auf “Verdana” und “Efont fixed” um, aktiviere die Schriftenglättung (mit dem Parameter “leicht” für das Subpixel-Hinting), schließe den Font-Bereich bis 10 Pt von der Glättung aus und voila – der Desktop zeigt nun superscharfe und glatte Schriften an. Will man das auch für Firefox und andere GTK-Anwendungen erreichen, genügt es leider nicht, die GTK-Parametrierungs-Möglichkeiten der “Systemeinstellungen” zu benutzen. Es müssen ferner einige GTK- und QT-Bibliotheken nachinstalliert werden. S. hierzu einen früheren Blog-Beitrag.

Bzgl. der Desktop-Suchmaschine Nepomuk sollte man folgenden Eintrag in der Datei “~/.kde4/share/config/nepomukserverrc” prüfen:

[main Settings]
Maximum memory=50
Storage Dir[$e]=$HOME/.kde4/share/apps/nepomuk/repository/main/
Used Soprano Backend=virtuosobackend

Jedes andere Backend (wie redland, aber auch soprano) ist entweder zu langsam oder funktioniert nach eigener Erfahrung unter KDE 4.4 nicht richtig. Hier sollte man sich die Log-Dateien für den Start des Akonadi-Servers mal ansehen. Bei Problemen hilft es ggf. die Akonadi- und Nepomuk-Konfigurationsdateien zu löschen und beide Komponenten neu zu starten.

e) Hinweise zum Audio-System
In den Laptop ist eine Standard-82801G-Soundkarte des Intel ICH7-Chipsatzes eingebaut. Die läuft mit OSS und Alsa. Der Suse-Installer wählt automatisch Alsa. Als Phonon-Backend unter KDE stelle ich “Xine”
statt Gstreamer ein. Damit habe ich wesentlich bessere Erfahrungen. Ansonsten muss man in den KDE-Systemeinstellungen für das Sound-Subsystem nichts verändern. KMix zeigt koreekt getrennte Regler für die Hauptlautsprecher und den LFE-Lautsprecher des Laptops an. Hinzu kommt ein Regler für den PCM-Kanal. Amarok 2.2.2 läuft hiermit bestens – und der vor kurzem hinzugekommene Equalizer hilft wirklich, dem Laptop einen brauchbaren Klang zu entlocken. In keinem Fall schlechter als unter dem Windows Media-Player. Für einen besseren Musikgenuss sind natürlich Kopfhörer zu empfehlen. (Ich verwende hier auf Reisen übrigens zusammenklappbare geschlossene AKG-Kopfhörer und bin damit sehr zufrieden).

f) K3b
K3B installiere ich mir übrigens aus dem Packman Repository – zusammen mit den dort vorhandenen Codecs. Brennen mit dem im Laptop vorhandenen DVD-Brenner ist für alle DVD- und CD-Typen problemlos möglich. Ich erinnere mich aber, einmal ein Firmware-Update durchgeführt zu haben, um für eine der DVD-Typen eien höhere Brenngeschwindigkeit zu erreichen.

g) KMail, Akonadi und das Adressbuch
Eine Anmerkung noch zu der (aus meiner Sicht verfehlten) Vorgehensweise bzgl. Kontact und Akonadi: Es ist wichtig zu begreifen, dass das “Default Adressbook”, das unter dem aktuellen “KDE 4.4 Kontact” eingerichtet wird, keine (!) Verbindung zu Kmail aufweist. Kmail nutzt wie alle anderen PIM-Programme außer der “Adressbuch”-Applikation bislang noch keine (!) Akonadi-Ressourcen.
In einer einfachen Erstinstallation muss man sich eine zusätzliche Kontact-Ressoure – nämlich ein Standard-KDE-Adressbuch einrichten (rechter Mausklick im Kontact-Adressbuch-Bereich auf die Adressbuchübersicht). Für ein lokales Adressbuch sollte die zugehörige Datei auf

/home/user_xyz/.kde4/share/apps/kabc/std.vcf

verweisen, wenn das vcf-Format gewählt wurde. Als Name habe ich “Adressbuch” verwendet. Andere Konfigurationsmöglichkeiten (z.B. mit Open-Xchange) führen hier zu weit.
Dieses Adressbuch wird schließlich unter Kmail erkannt und kann wie gewohnt benutzt werden.

[Wie es sich einem normalen User erschließen soll, dass das eingerichtete Default-Adressbuch nicht unter Kmail nutzbar ist, bleibt ein Rätsel, das die KDE-Entwicklungsleitung schnellstens lösen sollte. Zumal auch das Kmail Adressbuch “Default Addressbook” heißt.]

h) HW-Sensoren
Für Leute, die ein paar Temperaturwerte sehen wollen, empfiehlt sich ein Durchgang durch sensors-detect (die Sensors-Pakte muss man sich halt vorher installieren). Danach stehen einem Sensoren für beide CPU-Cores zur Verfügung (sagt jedenfalls die KDE-Systemüberwachung ksysguard).

Performance unter Opensuse 11.2 (64 Bit) mit KDE 4.4

Das Gesamtsystem erlebt schon beim Start unter Opensuse Linux eine enorme Beschleunigung. Nach 23 Sekunden ist der graphische Login möglich. Nach weiteren 9 – 10 Sekunden kann man arbeiten. Von solchen Zeiten kann man unter einem halbwegs mit Software ausgestatteten Win XP System nur träumen.

Im normalen Tagesbetrieb (Openoffice, Firefox, etc.) fallen Plattenzugriffe als Behinderungen des Systemablaufs nicht auf. Hier ist der Gegensatz zu MS Win XP enorm. UDMA6 ist unter Linux aktiviert.

/dev/sda:

Model=ST980825AS, FwRev=8.04, SerialNo=3MH0QGR1
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=8
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7

*
signifies the current active mode

Das System reagiert unter KDE 4.4 insgesamt recht spritzig – die Performance-Unterschiede zu meinen wesentlich besser ausgestatteten, normalen Workstations-PCs kann ich gut verschmerzen. Die typische CPU-Belastung bei folgenden geöffneten und aktiven Programmen

* Writer, Impress (Openoffice 3.2)
* Firefox beim Blog-Editieren,
* spielender Amarok (ogg-vorbis-Datei von angeschlossener USB-Disk) mit aktivem Equalizer ,
* Kontact (Kmail offen, Korganizer im Hintergrund),
* laufender KDE-Systemmonitor mit mehreren aktiven Datenblättern,
* laufendem gkrellm
* laufendes Miniprogramm für die Systemauslastung
* einigen Plasma-Miniprogrammen (RSS, Wetterbericht)
* Plattenplatzüberwachung

schwankt zwischen 3%-26% auf beiden Prozessorcores – beide allerdings bei nur 1000 MHz-Taktung. Geschätzte Mittelwerte: 17% auf einem Core, 10% auf dem anderen. Bei grafikintensiven Desktop-Aktionen (3D-Animationen des Desktops, intensive Zeichenoperationen und Objektbewegungen unter Impress) treten mal zusätzliche Peaks bis 50 % auf.

Enger wird die Sache, wenn die virtuelle Maschine mit Win XP von einer physikalischen Partition gestartet wird. Während des Startvorgangs stehen CPU und Platte natürlich unter Druck. Man kann dabei aber trotzdem bequem unter Linux weiterarbeiten – und das ist ein fundamentaler Unterschied zu allem, was man unter MS Windows erlebt.

Natürlich muss man der virtuellen Maschine schon etwas Speicher geben, damit ein minimales Chaching unter Win XP überhaupt möglich wird. Für einen Einsatz der Adobe Web Premium Suite wird 1 GB RAM empfohlen. Da ich aber selten Photoshop, Flash und Dreamweaver gleichzeitig verwende, gönne ich der virtuellen Maschine nur 800 MByte. Das ist nach bisherigen Tests ein ganz guter Kompromiss.

Einen Performance-Unterschied zwischen einer Ausstattung der virtuellen Maschine mit 2 oder 1 CPU konnte ich subjektiv nicht fühlen. Ich halte mich aber besser an die Empfehlungen von VMware, auf einem Dual-Core-System dem Gast-System nur einen Prozessor(-Kern) zu gönnen.

Die Zugriffe auf die Harddisk kommen bei laufender virtueller Maschine natürlich häufiger vor als im alleinigen Linux-Betrieb – seltsamerweise hat man aber nicht das Gefühl, dass Win XP als VMware Gast dabei wesentlich schlechter läuft als im nativen Zustand. So liegt z.B. die Startzeit bis zum Login beim “virtuellen” Win XP nur geringfügig über der entsprechenden Startzeit für den nativen Modus.

Durch die virtuelle Maschine gibt es natürlich auch eine höhere Grundbelastung der CPU, aber das ist bei einem zugeordneten Prozessor aber nicht so problematisch, wie man vielleicht meinen möchte. Betreibt man nur Dreamweaver, MS Office und eine Internet-Security-Suite auf dem Windows-System, so kann man fast genauso gut arbeiten, wie unter nativen Bedingungen. Sind die initialen Update- und Virusscanner-Orgien unter XP mal gelaufen, so führt das im Hintergrund im Leerlauf betriebene System (bei aktivem Gerätemanager zur Anzeige der Systembelastung und aktivem Dreamweaver ) lediglich zu einer höheren Grundbelastung des Systems von ca. 6-10%. Dabei waren alle oben aufgelisteten Programme unter Linux nach wie vor geöffnet. Die gesamte CPU-Belastung geht im Mittel aber auch dann kaum über 24 % (bei 1000 MHz auf dem einem und im Mittel 1333 MHz auf dem belasteten Core ) hinaus.

Auch während der Durchführung eines Acrobat und Camera Raw Updates auf dem virtuellen Win XP ging die effektive CPU-Belastung kaum über 35 % bei schwankender CPU-Taktung an. Die Wait I/Os auf dem durch die virtuelle Maschine belasteten Core stiegen jedoch deutlich an – mit Peaks bis zu 60%. Da bleiben aber immer noch genug Reserven für Linux – zumal dort das Festplatten-Caching eindeutig besser läuft. Alle Linux-Programme ließen sich während des Updates praktisch verzögerungsfrei bedienen – bis auf wenige kurze Augenblicke, in denen ein Plattenzugriff erforderlich wurde und das virtuelle System den Platten I/O bereits auf 100%
hochgetrieben hatte. Auch ein Kopierprozess von 1 GB auf der D-Disk des virtuellen Systems brachte den Linux-Host zu keinem Zeitpunkt aus dem Takt. Man konnte bestens weiterarbeiten.

Powermanagement unter Opensuse

Das Power-Management unter KDE’s “Systemeinstellungen” – “Erweitert” – “Energieverwaltung” funktioniert und die verschiedenen Optionen greifen auch. In den Standardeinstellungen sind das Prozessor- und das Systemschema auf “Performance” gestellt. Nach meiner Erfahrung läuft dann der Lüfter auf der CPU nahen Seite laufend auf einer mittleren Stufe. Leider ! Man kann hier aber defensiver vorgehen : Eine Einstellung des “Performance”-Schemas für Prozessor und System auf

*   “Dynamisch (energiesparend)” für die Prozessortaktung,
*   “Powersaving” für das System-Energiesparschema

hilft, die Temperatur des Systems spürbar zu senken – deutlich unter 50° Celsius im Normalbetrieb. Typische CPU-Core-Temperaturen liegen bei 46/47 Grad und 40/41 Grad. Ein Core ist seltsamerweise immer heißer. Das hat möglicherweise mit der Lüfteranordnung zu tun. Verständlicher wäre die Anzeige, wenn es sich bei der einen Temperatur um eine Prozessor-Kerntemperatur und bei dem anderen Wert um eine Oberflächentemperatur handeln würde – aber so weisen die HW-Sensoren (Ksensors) das nicht aus.

Unter Druck gehen die CPU-Temperaturen schon mal auf deutlich über 60 Grad hinaus – der dann auf höherer Drehzahl arbeitende Lüfter fängt das aber ab. Das Lüftergeräusch ist dann vernehmbar – ist aber immer noch nicht wirklich unangenehm. Im Gegensatz zu einigen anderen Dell-Laptops, die ich mal mein eigen nennen durfte.

Der Lüfter läuft dennoch deutlich öfter mit höherer Drehzahl als unter MS Windows. Ich weiß nicht wirklich, woran das liegt. Ggf. an der Grafikkarte, die unter KDE 4.4 sehr oft in den 3D-Modus schaltet und damit die Taktung der Nvidia-Quadro-Karte hochschraubt. Ich persönlich möchte halt ungern auf die Transparenz- und 3D-OpenGL-Effekte verzichten. Aber wen das stört, der kann sicher auch mit den 2D-Standard-Treibern leben.

Es hat sich auch gezeigt, dass der Lüfter – wenn er erst einmal auf eine höhere Drehzahl geschaltet hat – unter Linux nicht unbedingt zurückschaltet, selbst wenn die Temperatur des Systems abgesunken ist. Hier hilft manchmal die Tastenkombination

FN + y.

Elementare Systemkompnenten werden dadurch anscheinend resettet und der Lüfter springt nur wieder an, wenn das BIOS auch mit der abgesunkenen Temperatur nicht zufrieden ist.

Ein Übergang in den “Standby”-Zustand funktionierte bei mir mehrfach ohne Schwierigkeiten. Einmal stürzte Plasma beim Hochfahren aus dem Standby ab. Das blieb allerdings ohne Folgen – die Plasma-Oberfläche startete neu und alles war wieder OK.

Fazit

Win XP (32 Bit) auf einem Dell M90 ist eine Verschwendung von Ressourcen und macht wegen der trägen Performance keinen Spaß.

Ein 64-Bit-Linux-System passt viel, viel besser zu diesem Dell Precision Laptop. Nach meinen bisherigen Erfahrungen arbeiten zumindest Opensuse 11.2 (64 Bit) und KDE 4.4 problemlos mit diesem Laptop zusammen. Es gibt ferner keine Schwierigkeiten damit, ein bereits installiertes und nativ bootbares Win XP auch in einer virtuellen VMware-Maschine unter dem Opensuse-System zum Laufen zu bringen. Ein flüssiges Arbeiten unter Linux ist selbst bei gestarteter virtueller Maschine gewährleistet. Man kann durchaus sagen, dass Opensuse 11.2, KDE 4.4, VMware 7 ein fast ideales SW-Gespann für diesen Laptop darstellen.

Man fragt sich eigentlich, warum Dell die Nachfolger seine Precision-Systeme und im besonderen die Nachfolger des M90 nicht von Haus aus mit 64-Bit Linux-Systemen anbietet. Die Systeme sind als (mobiler) Workstation-Ersatz gedacht – und wer will denn
auf so einem Gerät mit Windows arbeiten? Außer im VMware-Fenster natürlich. Die letzten Tage haben mal wieder gezeigt, was Sache ist:

MS Windows gehört definitiv in ein “Fenster”, das unter der Kontrolle von Linux, VMware oder VirtualBox steht. Da stört es nicht und behindert den normalen Arbeitsprozess eines produktiven Anwenders nicht.

Gegenüber einem KDE 4.4-Desktop wirken Windows XP und Vista zudem altertümlich und optisch unattraktiv. (Von der zunehmenden Behandlung der Anwender als hirnlose Wesen durch die diversen Microsoft-Systeme ganz zu schweigen.) Wäre unter dem aktuellen Kontact unter KDE 4.4 eine verständliche Adressbuch-Behandlung gegeben, würde sich der KDE-Desktop langsam sogar einem wünschenswert optimalen Zustand annähern. Wer sich damit und mit Akonadi nicht rumschlagen will, kann aber auf KDE 4.3 ausweichen.

Aus Anwendersicht bleibt im Zusammenhang mit dem Dell M90 allerdings die geräuschfreiere Lüfteraktivität unter MS Windows zu vermerken. Eine defensive Energiepolitik unter Linux verbessert zwar die Situation zwar deutlich ohne einen reibungslosen Betrieb zu gefährden. Man kommt aber an die den fast geräuschlosen, minimalen Lüfterbetrieb unter MS Windows nicht heran.

VMware WS: Wechsel zw. Multi/Single-CPU WIN XP Guest

Posted on by

Installiert man als Linuxer ein Windows-System in einer virtuellen VMware Workstation, so wählt man beim ersten Anlauf i.d.R. eine virtuelle Maschine mit einem Prozessor. Leute, die die VMware Workstation auf einem Linux Host mit Quadcore Prozessor einsetzen, werden aber früher oder später mal ausprobieren, wie sich ein Win XP Pro Gastsystem verhält, wenn man in der virtuellen Maschine 2 Prozessoren  aktiviert.

Stellt man dann fest, dass die Performance nicht so berauschend ist, möchte man ggf. wieder zu einem virtuellen Gast mit nur einem Prozessor zurückkehren. Leider ist es dabei nicht mit einer entsprechenden Einstellung der Prozessoranzahl unter VMware getan. Win XP Pro zeigt dann im Gerätemanager zwar brav an, dass nur ein Prozessor läuft.  Aktiv ist aber immer noch der Mehrprozessor HAL. Woran erkennt man das ?

 
Einstellungen unter “Computer” im Win XP Gerätemanager

Welcher HAL (+ Windows Kernel) läuft und welche Alternativen man grundsätzlich hat, erkennt man, indem man sich im Gerätemanager die Einstellungen unter “Computer” ansieht.

Hat man Win XP in der virtuellen Maschine zunächst normal für einen Prozessor installiert, so findet man dort zumeist einen Eintrag

“ACPI -PC” vor.

Geht man nun per rechtem Mausklick auf “Treiber aktualisieren” und läßt sich dort alle Möglichkeiten anzeigen, so bekommt man eine Auswahl von vier Varianten:

HAL32-Auswahl

WIN XP Pro schaltet nach einem Wechsel der virtuellen Maschine vom Single- zum Mehrprozessor-System automatisch zum “ACPI-Multiprocessor – HAL” um. Wechselt man also  in einen Zustand mit 2 Prozessoren, so ändert sich der Eintrag unter “Computer” auf “ACPI-Multiprocessor-PC”; die Auswahl unter “Treiber aktualisieren” bleibt aber (meist ?) erhalten.

Das eigentliche Problem kann nun entstehen, wenn man die virtuelle Maschine wieder auf einen Prozessor reduziert. Danach ist der HAL nicht korrekt eingestellt; die Auswahlmöglichkeiten bei “Treiber aktualisieren” sind aber leider auch verschwunden! Und dies ändert sich auch nicht mehr, wenn man die virtuelle Maschine wieder auf 2 Prozessoren umstellt.

Das war zumindest bei mir der Fall. (Im Internet liest man, dass zumindest der Win 2003 Server ein anderes Verhalten zeigt und die Auswahlmöglichkeiten in jedem Zustand anbietet – beschwören möchte ich daher das bei mir festgestellte Verhalten nicht.)

Mein virtuelles Windows-System jedenfalls lief nach dem Downgrade auf 1 Prozessor weiter mit dem Multiprozessor HAL und ließ sich nicht mehr umstellen. Beim Forschen im Internet kam ich bei MS zu der Information, dass ein solcher Downgrade-Vorgang nicht unterstützt würde und eine Neuinstallation von Windows notwendig sei. Auch über ältere (aber nicht zu alte) Wiederherstellungspunkte des Systems kam ich nicht zum Ziel. Im Gegenteil: Weil da ja noch 2 Prozessoren vorausgesetzt waren, die Maschine laut VMWare-Einstellung aber nur noch 1 Prozessor hat, streikt die Wiederherstellung.

Wie kann man dieser Situation durch kluges und vorausschauendes Management entkommen ?

 
Varianten für eine Rückkehr zum Single-Prozessor-Zustand  und deren Vorbereitung

1) Variante 1:

Eine Variante ist die, die gesamte virtuelle Maschine schon vor dem ersten Wechsel auf mehrere Prozessoren zu klonen. Hat man genügend Platz, so ist dies mit Sicherheit der beste Weg. Man probiert die Mehrprozessor-Variante aus, fährt in der Zeit keine Updates, speichert neue Files auf einem Netzlaufwerk und kann ggf. wieder zurück zur älteren Version. Nicht brauchbar ist diese Methode ggf., wenn man während der Experimentierzeit ernsthafte Veränderungen am System vorgenommen hat, die man später nicht verlieren will.

2) Variante 2

Eine zweite Variante besteht aus meiner Sicht darin, mit VMware Snapshots zu arbeiten. Allerdings habe ich eine Rückkehr zu Snapshots vor und nach einem Wechsel der Prozessoranzahl bislang nie ausprobiert. Sollte aber funktionieren. Wichtig ist es, den ersten Snapshot vor dem Wechsel zum Multiprozessor-Zustand anzulegen – und zur Sicherheit auch noch einen weiteren danach.

3) Variante 3

Variante 3 ist laut einer Diskussion im VMware-Forum unsicher und möglicherweise mit Nebenwirkungen versehen. Bei mir hat sie aber funktioniert. Dennoch – keine Garantie von mir, dass das immer gut geht.

Die Methode besteht darin, noch vor dem ersten Wechsel von einer Single-Prozessor-Installation auf ein Multiprozessor-System (!) das “system32”-Verzeichnis zu sichern. Darin befinden sich mindestens 3 Dateien, die man später benötigt, um zum alten Zustand mit einem Single-Prozessor HAL zurückzukommen :

hal.dll, ntkmlpa.exe, ntoskml.exe

Diese Dateien haben im Multiprozessor und im Single-Prozessor-Zustand übrigens unterschiedliche Größe, was für sich spricht. (Ggf. findet man im system32-Verzeichnis auch die Dateien halacpi.dll und halmacpi.dll vor, wie manche Zeitgenossen behaupten – dann mitsichern.)   

Genau das Gleiche – also die Sicherung des system32-Verzeichnisses – macht man dann nach der Aufrüstung der virtuellen Maschine – also im Multiprozessor-Zustand. Man hat dann also die oben genannten Dateien in den unterschiedlichen Zuständen (für eine 1 Prozessor-Umgebung und für eine Mehrprozessor-Umgebung) zur Verfügung. (Das Backup des gesamten Verzeichnisses führe ich nur zur Sicherheit durch.)

Will man dann in den Single-Prozessor-Zustand zurück, so stellt man zunächst VMware auf 1 Prozessor um. Danach bootet man den Win XP Gast (ggf. im abgesicherten Modus mit Netzwerk) und kopiert dann von einer externen Quelle die oben genannten 3 gesicherten Dateien für den Single Prozessor Zustand ins “system32”-Verzeichnis. Nach einem Reboot findet man dann Win XP hoffentlich im ordnungsgemäßen Zustand – in meinem Fall mit einem ausgewählten “ACPI PC”-HAL vor. Auch die vier Wahlmöglichkeiten sollten dann wieder angezeigt werden.

Übrigens: Auch ein anschließender erneutet Wechsel zurück in den Multiprozessor-Zustand funktionierte problemfrei.

4) Variante 4

Die letzte Variante entspricht im wesentlichen der dritten. Allerdings wird hier eine andere Quelle für die drei fraglichen D ateien verwendet. In Frage kommt z.B. die Win XP Pro Installations CD.

Dort muss man das I386 Verzeichnis öffnen. Im SP2.Cab muss man halacpi.dll, ntkrnlpa.exe und ntoskrnl.exe extrahieren und in einem Verzeichnis abspeichern. Danach halacpi.dll in hal.dll umbenennen und alle drei Files in den system32-Ordner kopieren.

Ggf. kann man aber auch die Dateien von einem laufenden anderen Windows System mit 1 Prozessor holen. Vorher aber prüfen, dass dort tatsächlich der ACPI-Hal läuft, wenn das Ziel – nämlich die virtuelle Maschine – selbst den ACPI HAL verwendet.

Variante 4 ist dann von Interesse, wenn man die Sicherungen/Snapshots etc. für den ursprünglichen Einprozessor-Zustand nicht oder nicht mehr hat.

In meinem Fall habe ich die 3 Dateien für den Single-Prozessor-Zustand übrigens von einer anderen Windows-Installation auf einem  Einzelprozessor-System geholt.

Ich hoffe, dass hilft den experimentierfreudigen Lesern und VMware-Enthusiasten weiter.

In jedem Fall gilt:  Trotz aller Features von VMware wie Klonen und Snapshots lohnt sich ein Backup der virtuellen Windows-Systeme, wenn man trotz Linux ernsthaft damit arbeiten muss.

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 ….