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

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.

Flackern beim Seitenwechsel im MS IE

Viele Websites beinhalten Seiten, die vom Grundaufbau/Layout her völlig identisch aussehen. D.h., sie beinhalten viele begrenzende oder Hintergrunds-Elemente, die auf allen Seiten völlig gleich aussehen.

Bei einem Wechsel zwischen zwei Seiten erwartet man dann, dass die identisch aussehenden Seitenelemente während des Wechsel ohne jedes Flackern dargestellt werden. Der Wechsel soll für das Auge des Betrachters also so ablaufen, als ob nur die unterschiedlichen Seitenanteile im Wechsel neu aufgebaut werden. Die identisch aussehenden Elemente sollen beim Seitenwechsel dagegen als völlig statisch erscheinen. Es soll vor allem zu keinem Flackern beim Seitenaufbau kommen. Flackereffekte (kurzzeitige Hell-Dunkel-Wechsel in bestimmten Seitenbereichen) wirken auf die meisten Betrachter irritierend.

Leider stellt man aber immer wieder fest, dass es gerade bei komplexeren Seiten im MS IE zu diesem unangenehmen Flackern kommt – oft genau in den Bereichen, die beim Seitenwechsel eigentlich unverändert bleiben. Dagegen kann man bei Browsern wie Firefox, Opera, Konquerer oft  einen stabilen, flackerfreien Bildwechsel während des Renderns der neuen Seiten konstatieren. (Ausnahmen stellen Seiten dar, die Flash-Elemente beinhalten.) Wir haben das Problem schon des öfteren mit gewöhnlichen HTML-Seiten, aber auch im Zusammenhang mit PHP-Seiten festgestellt.

Wie kann man als Entwickler das nervige Flackern im MS IE in den Griff bekommen ?

Hierfür gibt es nach unserer Erfahrung mindestens zwei Tricks:

Trick 1: MS IE spezifisches Metatag

Im MS IE kann man den Seitenwechsel mit (teils spektakulären) Effekten unterlegen, die eine bestimmte Zeitdauer haben. Die Render-Engine arbeitet in diesem Modus anders als gewöhnlich. Wir nutzen das an dieser Stelle zur Vermeidung des Flackerns aus. Zur Parametrierung der Effekte dient ein Metatag der folgenden Form

<meta http-equiv=”Page-Enter” content=”revealtrans(duration=0.1,transition=5)” >

Der Parameter “duration” gibt die Zeitdauer des Effektes in Sekunden an, der Parameter “transition” den ausgewählten Effekt. In unserem Fall wird die Seite von oben nach unten aufgebaut (abgerollt) – die Zeitdauer ist allerdings so kurz gewählt, dass man das praktisch nicht merkt. Der von uns gewünschte Seiteneffekt ist allerdings der, dass ein Seitenwechsel nun in vielen Fällen völlig stabil und ohne jedes Flackern vor sich geht.

Weitere Information zu “revealtrans” findet man im Internet.

Trick 2: Einbau von Dummy-DIVs mit einer Opacity-Anweisung

Auch wenn man auf einem Layer der Webseite mit hohem z-Index ein Dummy-DIV mit einer Opacity-Vorgabe integriert, reagiert die Render-Engine des MS IE positiv im Sinne der Flackerfreiheit. Ein Element der Form :

<div style=”position:absolute; width:0.5em; height:0.5em; top:0.1em; left:0.1em; filter: alpha(opacity=66); -moz-opacity: .66; opacity: .66; z-index:10;”></div>

ist an sich zwar völlig sinnlos (da ohne Hintergrundsfarbe), zieht aber dennoch die Flackerfreiheit des Seitenaufbaus nach sich. (Ausschlaggebend für den MS IE ist dabei übrigens die “filter”-Anweisung.)

Viel Spass in Zukunft beim “Beruhigen” des MS IE.

Nachtrag am 18.11.2009: 

Im Falle von Hintergrundsbildern, die per CSS in Tags eingebunden werden, helfen die obigen Tricks in der Regel nichts. Siehe aber die Hinweise von Anne zu weiteren Möglichkeiten im Kommentar ! Danke, Anne !

Nachtrag am 28.11.2009

Anne hat mich darauf aufmerksam gemacht, dass beim MS IE in vielen Fällen auch der unauffällige Einbau eines kleinen Dummy-Flash-Films, der eigentlich nichts tut, zur Stabilisierung des Bildaufbaus und zur Vermeidung von Flackereffekten hilft. Wegen evtl. Schwierigkeiten mit Flash-Filmen in Gecko/Mozilla-Browsern ist das aber kein Trick, den man generalisieren könnte.

Interessant ist auch, dass im Moment das
gleichzeitige Öffnen mehrer Tabs mit Webseiten, die per SWFObjects 2.x eingebaute Flashfilme beinhalten, im Firefox zu Flackereffekten beim Seitenwechsel führt – zumindest unter Linux.  Es ist ein Leiden !

Ferner hat mich Anne mit einigen Beispielen, bei denen im BODY-Tag Hintergrundsbilder per CSS verankert wurden, davon überzeugt, dass es im MS IE (alle Versionen) manchmal sogar von Nachteil sein kann, den “revealtrans”-Effekt einzusetzen. Besser ist es da anscheinend, das Bild, das man im Body-Tag untergebracht hat, nochmal in Form eines gewöhnlichen IMG-Tags in einem DIV zu hinterlegen, das man per z-index unter allen anderen Seitenelementen einfügt.

OK, OK, ich gebe auf – es gibt keine Standardrezepte – man muss halt herumexperimentieren.

Wenn man Zeit hätte, könnte man ja die Sache mal systematisch untersuchen – Seitenwechsel bei vorhandenen Hintergrundsbildern, beim Vorhandensein  von Flash und das in allen gängigen Browsern unter Linux und  MS Windows.  Ach ja, man müßte dann auch noch die unterschiedlichen Arten der Einbindung von Flashfilmen berücksichtigen …..