Wenn man mit einer oder mehreren VMware-Workstation unter Linux hantiert, ist man froh über einen guten I/O. Gestern hat mich jemand in diesem Zusammenhang auf meine Erfahrungen mit 3ware-Controllern angesprochen.

Pauschal konnte und kann ich darauf nicht antworten – man müsste für eine solide Einschätzung systematische Vergleiche mit anderen Controllern durchführen. Dazu fehlen mir im Moment schlicht die Ressourcen. Es gibt aber interessaante Diskussionen im Internet. Ich empfehle den folgenden Beitrag

http://makarevitch.org/rant/raid/

Siehe auch die dortigen Links mit wirklich interessanten Statements und Erfahrungen zu 3ware-Controllern unter Linux. Hochinteressant finde ich vor allem die Vergleiche mit SW-Raid-Konfigurationen unter Linux, die mich ab und zu doch an meinen Investitionen in HW-Raid für Desktops zweifeln lassen.

Dennoch und aus dem Bauch heraus: Meine Erfahrungen sind im Mittel nicht schlecht, aber gerade mit laufenden VMware-Workstations wird der Platten I/O auf meine Opensuse Kisten bisweilen für kurze Momente zu einem echten, spürbaren Engpass. Zumindest, wenn man sich nicht ein wenig um die (begrenzten) Einstellmöglichkeiten des Controllers und auch des Linux-Systems kümmert.

Aufgefallen ist mir in der Praxis auch, dass auf meinen Opensuse-Systemen mit Quadcore-Prozessoren unter Last irgendwie immer (oder vor allem) der erste Core hohe WAIT I/O-Werte aufweist. Ich gehe mal davon aus, dass die 3ware-Treiber in Kombination mit dem Kernel den Controllerzugriff und den Datentransfer über genau einen Core handhaben. Auch dazu gibt es Hinweise in einschlägigen Diskussionen im Internet.

Der von mir auf den Desktop-Systemen verwendete Controller “9650SE-4LPML” ist ferner nicht ein System, bei dem man die Performance über große Raid-Stapel mit 12 oder 24 Platten hochziehen könnte. Mit 4 Platten sind die Möglichkeiten halt begrenzt.

Also fängt man an, ein wenig herumzuprobieren und vor ein paar Monaten habe ich tatsächlich mal ein wenig Zeit investiert, um mir mit “Bonnie++” verschiedene Konfigurationen anzusehen. Allerdings nur mit EXT3/Ext4 als Filesystem. Wenn ich auf dieser Basis Empfehlungen geben sollte, dann wären es folgende:

1) 4 Platten – Raid 10

2) Wenn man es sich leisten kann : Eher kein LVM einsetzen.

3) Controller-Parameter: Read-Cache auf “Intelligent” setzen und Write-Cache aktivieren (Battery Unit zur Vermeidung von Datenverlusten/Inkonsistenzen einkalkulieren). StorSave auf “Balance” oder “Performance” setzen. Verwendung von “Queuing” (NTQ Feature der Platten, wenn vorhanden) anschalten.
(Zum Einstellen von Controller-Eigenschaften kann man übrigens gut das übersichtliche “3DM2” benutzen.)

4) Linux-Einstellungen – z.B. für ein Raid-Device, das unter “/dev/sda” anzusprechen ist:

echo “512” > /sys/block/sda/queue/nr_requests

und danach (!):

blockdev   −−setra 16384 /dev/sda

5) VMware-Workstation (konfiguriert für 2 CPU-Cores eines Quad-Core-Systems):
Zuweisung des “vmware-vmx”-Prozesses an zwei andere Prozessor-Cores als den ersten, auf dem zumeist der I/O kontrolliert wird. Also z.B.:

taskset -pc 2,3 <pid des vmware-vmx-Prozesses>

Testet man die Performance unter diesen Bedingungen etwa mit zwei Raid 1 Units, die bei mir unter Linux als “/dev/sda” und “/dev/sdb” erscheinen, so erhält man mit Bonnie++ recht gute Werte für sequentielles Lesen und Schreiben (ca. 10% unter den theroretischen Maximalwerten der Platten). Aber es lohnt sich, auch andere Parameter-Werte – vor allem für blockdev – unter Linux auszuprobieren. Hier konnte ich durchaus messbare Unterschiede feststellen. Hat man gute Werte gefunden, hinterlegt man sich die Einstellungen in einem kleine Startup-Script.
Der Wechsel auf Raid 10 führt dann nochmals zu einer signifikanten Steigerung der I/O-Werte.

Mit unterschiedlichen Schedulern habe ich auch rumgespielt. Irgendwie erschienen mir die Unterschiede aber nicht so signifikant zu sein.

Ich hoffe, ein paar von den Hinweisen helfen auch anderen weiter.

Wie im vorhergehenden Artikel beschrieben, habe ich auf einem Dell 90 eine vorhandene Win XP Installation (32Bit, mit mehreren aktiven physikalischen Partitionen) um eine Opensuse 11.2-Installation ergänzt. Zunächst lag also eine Dual-Boot-Konfiguration vor. Das Management der verschiedenen Möglichkeiten beim Booten übernimmt bei mir Grub, das ich im MBR des Systems installiert habe.

Das eigentliche Ziel war es aber, die vorhandene 32Bit-Windows-Installation auch in einer virtuellen VMware-Maschine unter dem 64 Bit Opensuse 11.2 Linux-System verfügbar zu machen. Danach liegt dann natürlich nach wie vor eine Dual-Boot-Konfiguration vor. Der Unterschied ist aber der, dass das bereits installierte Windows auch nach dem Booten des Linux-Systems vollständig über VMware zugänglich wird – nämlich als Gastsystem. Ein und dasselbe Win XP kann in dieser angestrebten Zielkonfiguration dann also

• sowohl als natives OS gebootet und betrieben werden
• als auch als Gast einer VMware-Maschine unter der Regie des 64-Bit Linux-Hosts gebootet und genutzt werden – also im sog. “Raw-Modus” von VMware.

Dass eine solche Konfiguration reizvoll ist und viele Vorteile bietet, liegt auf der Hand. Ich wollte das schon lange mal ausprobieren. Nun ist das in meinem Fall erfolgreiche Vorgehen, das ich nachfolgend beschreibe, nicht wirklich auf meinem Mist gewachsen, sondern basiert auf Informationen aus verschiedenen Quellen. Zitieren möchte ich stellvertretend vor allem folgende 5 Artikel, die mir sehr geholfen haben :

http://www.vmware.com/pdf/dualboot_tech_note.pdf

http://www.informatik-forum.at/showthread.php?t=56924

http://wiki.ubuntuusers.de/VMware/Parallelsystem

http://www.gentooforum.de/post/106994/vmware-und-windows-von-eigener-partition-starten-vorgehensweise.html

http://www.kvaes.be/unix-linux/running-your-dual-boot-windows-inside-vmware-server-within-ubuntu/

http://linux.derkeiler.com/Mailing-Lists/SuSE/2007-12/msg00401.html

Hinweis und Disclaimer

Es ist durchaus gefährlich, eine solche Konfiguration ohne hinreichendes Wissen einzurichten. Das nachfolgend beschriebene Vorgehen funktioniert möglicherweise nicht auf Ihrem System! Kleine Fehler haben u.U. zudem fatale Folgen. Ein Totalverlust der installierten Systeme und der dort vorhandenen Daten kann die sehr wahrscheinliche Folge sein. Dies gilt für das vorhandene Linux- wie das Windows-System. Es handelt sich beim beschriebenen Vorgehen also um ein Experiment (!) mit potentiell großer bis maximaler Schadenswirkung. Man sollte eine solche Installation keinesfalls auf Produktiv-Systemen vornehmen. (Zumindest nicht ohne vorherige hinreichende Tests in einer unproduktiven Umgebung) Eine vollständige System- und Datensicherung ist obligatorisch, bevor man beginnt. Ein Problem ist eher wahrscheinlich als unwahrscheinlich!

Damit das klar ist: Ich übernehme keinerlei Haftung für evtl. Schäden als Folge des nachfolgend beschriebenen Vorgehens – weder an der Hardware, noch an der Software oder Daten. Ich garantiere auch nicht die Richtigkeit und Anwendbarkeit der nachfolgenden Schritte. Jeder, der dem beschriebenen Vorgehen auf seinem eigenen System folgt, tut das vollständig und in jeder Hinsicht auf eigenes Risiko.

Hingewiesen sei auch darauf, dass selbst im Fall einer erfolgreichen Konfiguration eine Reaktivierung des Win XP-Systems anstehen kann. Hier muss man im Besitz einer passenden Lizenz sein. Beachten Sie auch entsprechende Hinweise in den zitierten Artikeln und Blog-Beiträgen. Übrigens: Nach einer Reaktivierung von Win XP steht das gleiche Spielchen mit hoher Wahrscheinlichkeit auch für proprietäre SW wie MS Office oder Adobes Creative Suite an. Es lohnt sich daher wirklich, sich vorab intensiv mit der Lizenzfrage und ein paar BIOS-bezogenen Einstellungen der VM zu befassen (s. u.a. die Hinweise im dritten oben zitierten Artikel).

Vorsichtsmaßnahmen:

1. Da im hier gewählten Vorgehen mindestens der erste Boot-Vorgang in der virtuellen Maschine zu einer Anzeige der Grub-Optionen führt, besteht die Gefahr, das bereits laufende Linux-System oder eine Variante davon auch in der virtuellen Maschine zu starten. Das darf man aber auf keinen Fall tun – es würde zu einer Zerstörung der gesamten Linux-Installation führen !
2. Evtl. Timeout-Parameter im Boot-Menü sind daher vorab vorsichtshalber zu entfernen ! Ferner sollte man vor dem ersten Start der einzurichtenden virtuellen Maschine unter Grub “Windows” als das standardmäßig zu bootende System einstellen !
3. Die Windows-Partitionen dürfen beim Starten der virtuellen Maschine nicht unter Linux gemountet sein! Zumindest als beschreibbare Devices – also nur “read only” ! Eventuelle andere Einträge in der “/etc/fstab” sind zu entfernen ! Vor dem ersten Start der virtuellen Maschine muss unbedingt der Mount-Zustand per mount-Befehl geprüft werden !

Nach diesen Warnungen nun eine Beschreibung des Vorgehens, das bei mir zum Erfolg geführt hat:

Schritt 1: Vorbereitung des Win-XP-Systems auf 2 verschiedene HW-Umgebungen

VMware gaukelt dem späteren Gastsystem Win XP natürlich eine etwas andere Hardware vor, als die, die es bei einem direkten nativen Booten vorfindet. Das Win XP muss sich der neuen “virtuellen” HW anpassen können, ohne die ursprünglichen Einstellungen für einen nativen Boot-Vorgang zu verlieren. Um das zu erreichen, benutzt man unter Win XP die Möglichkeit zum Einstellen sog. “Hardwareprofile”.

Die SATA-Disk des Dell M90 erschient unter dem Kernel des Opensuse 11.2 Linux als “/dev/sda”, wird also über die Gerätetreiberschicht wie eine SCSI-Disk behandelt. Nun kann man auf dem Win XP-System prophylaktisch den VMware-SCSI-Treiber installieren, um später die virtuelle Maschine betreiben zu können. Hierauf gehen einige der oben zitierten Artikel ein. Alternativ kann man aber die SATA-Disk im Gastsystem auch als IDE-Disk betreiben – so sieht es schließlich ja auch das native WinXP. Man muss sich nun für einen Weg entscheiden. Ich bin bislang nur den Weg über den IDE-Treiber gegangen, der evtl. nicht die optimale Performance liefert. Er erschien mir aber einfacher und hat auf Anhieb funktioniert. Hinzu kommt, dass man in VMware-Unterlagen den Hinweis findet, dass diese Variante besser getestet sei.

Zusätzlich ist zu beachten, dass in dem später geltenden Hardwareprofil statt eines speziellen Intel-Treibers der native MS IDE-ATA-Treiber geladen werden muss. Nur dieser passt beim ersten Booten des Gastsystems zur IDE-Harddisk der virtuellen VMware-Maschine. (s. aber den Hinweis am Ende des Artikels).

Duchzuführen sind demnach also folgende Unterschritte:

• Booten von Win XP (aus der Dual-Boot-Konfiguration). Systemsteuerung aufrufen. Systemsteuerung -> System -> Reiter Hardware -> Hardwareprofile.
• Im
  Dialog eine Kopie des aktuellen Profils anlegen.
• Umbenennen des originalern Profils in “Standalone” und des neuen in “VMware”. Dies nur zur besseren späteren Unterscheidbarkeit.
• Anklicken der Option “Warten, bis ein Hardwareproil gewählt wird” unter dem Punkt “Beim Starten von Windows”
• Wechsel zum “Geräte-Manager”. Dort “IDE-Controller” auswählen. -> “Treiber aktualisieren” -> “…. den zu installierenden Treiber selbst wählen” -> “Standard-Zweikanal-PCI-IDE-Controller” auswählen und aktivieren.
• Win XP herunterfahren – Linux booten.

Schritt 2: Einrichten der virtuellen Maschine unter VMware (im Linux System)

Man boote Linux. Danach VMware installieren. In meinem Fall die Workstation 7. Das Ganze geht aber auch mit VMware Server 1.x. Da man später beim Booten der virtuellen Maschine auf die gesamte Festplatte zugreifen wird, ist es nötig, den User, der über VMware ein existierendes System von einer physikalischen Partition booten will, mit hinreichenden Rechten auszustatten. Unter Opensuse bedeutet das, den betreffenden User zu einem Mitglied der Gruppe “disk” zu machen. Danach richtet man dann die virtuelle MAschine ein.

• Opensuse: Gib dem User, der VMware benutzt, die Mitgliedschaft in der Gruppe “disk”. Per Yast oder mit dem Befehl “sudo adduser myusernamedisk”.
• Nun geht es an das Einrichten einer geeigneten virtuellen Maschine. Hier folgt man dem entsprechenden Dialog mit der Option “Custom”. In meinem Fall habe ich folgende Einstellungen gewählt:

• Workstation 6.5-7.0 bei der HW Compatibility
• “I will install the operating system later” bei den Einstellungen zur Installation
• Win XP Pro bei den Einstellungen zum geplanten OS
• Number of Processors: 2
• Number of Cores per Processor
• Memory: 800 MB
• Network Adapater Bridged (für Verbindungen nach außen)
• Network Adapter 2 Host-Only (für Verbindungen zum Host bei ggf. fehlendem Netz)
• “Use a physical disk” (+ “use entire disk”; s. hierzu die Anmerkungen weiter unten) [“Hard Disk (IDE) Using device /dev/sda “]

Hinweise zur SATA-Platte
Bzgl. der SATA-Harddisk ist anzumerken, dass ich vergeblich versucht habe, über die VM-Einrichtung eine individuelle Partition anzusprechen. Danach schlug das Booten der virtuellen Maschine regelmäßig fehl. Ferner gibt es das Problem, dass VMware für das Einrichten der Harddisk nur die Möglichkeit einer SCSI-Disk anbietet. Der Grund dafür ist vermutlich, dass die SATA-HD unter Linux als SCSI-Device geführt wird (/dev/sda). Damit bootet das virtuelle System aber nicht – zumindest nicht, wenn man nicht vorher den entsprechenden SCSI-Treiber von VMware installiert hat. Dieses Vorgehen habe ich aber, wie gesagt, nicht ausprobiert.

Notwendige Schritte zur Einrichtung der SATA-Harddisk:

• Die gesamte Harddisk auswählen, d.h. im entsprechenden VMware-Dialog als device /dev/sda angeben und den Radiobutton “use entire disk” anklicken.

n

• Im Einrichtungsdialog trotz allem Buslogic als SCSI-Controller auswählen. Nach dem Aufsetzen der virtuellen Maschine muss dann ein manuelles Nacheditieren der Dateien .vmdk und .vmx erfolgen :
• vmx-File: hier die wichtigen Einträge bzgl. der Platte

• ide0:0.present = “TRUE”
• ide0:0.fileName = “WinXP0.vmdk”
• ide1:0.present = “TRUE”
• ide1:0.fileName = “/dev/sr0”
• ide1:0.deviceType = “cdrom-rawk”
• scsi0.present = “TRUE”
• scsi0:0.redo = “”
• scsi0.pciSlotNumber = “16”
• ide0:0.redo = “”

Beim “fileName” muss natürlich das richtige File angegeben sein. Der überflüssig wirkende “scsi0.present”-Eintrag sorgt dafür, dass der SCSI-Treiber geladen wird (sicherheitshalber, falls man den später doch mal braucht).

• vmdk-File: hier die wichtigen Einträge bzgl. der Platte

• ddb.adapterType = “ide”

An den Geometriedaten der Disk habe ich nichts geändert !

Weitere Hinweise zur Einrichtung der VM:
Zu den 2 ausgwählten Prozessoren ist zu sagen, dass das auf einem Dual Core-System von VMware eigentlich nicht empfohlen wird. Ich hatte aber auch dem Dell mit der VMware WS 7 den Eindruck, dass das probemfrei geht und der VM insgesamt zu mehr Performance verhilft. Der USB-Controller wurde automatisch erkannt, die Soundkarte und das (Vmware-) Display ebenfalls. Das CD/DVD Drive wurde automatisch als IDE erkannt: “CD/DVD (IDE) Using drive /dev/sr0”.

Schritt 3: Ändern der Grub-Einstellungen

Nun muss man zur Sicherheit die Grubeinstellungen verändern. Ein schnelles Starten des bislang in Grub vermutlich als “Standard” oder “Default” eingerichten Linux-Systems muss verhindert werden. Hierzu muss man entweder die Datei “/boot/grub/menu.lst” editieren oder unter Opensuse das Yast-Tool zum Einstellen der erforderlichen Punkte heranziehen.

• Setzen des “default” Eintrages in der “/boot/grub/menu.lst” auf den korrekten Wert für den Eintrag zum Booten des Windows-Systems (Achtung: Die Einträge in der Datei menu.lst werden ab 0 hochgezählt! Ist der dritte Eintrag derjenige, der sich auf das Windows-System bezieht, so ist also ein Eintrag “default 2” richtig.) Man prüfe die neue Einstellung für das als Standard zu bootende System über einen Neustart !
• Um das automatische Booten zu deaktivieren, löscht man entweder die Zeile “timeout”. Nach erfolgreicher default-Eintrags-Änderung gem. 3.1) – aber nur dann – kann man den Tinmeout-Eintrag ggf. auch auf einen hohen Wert (z.B. 1800) setzen, um den Boot-Vorgang lang genug hinauszuzögern. Auch diese Einstellung kann man in einem Reboot testen.

Schritt 4: Check /etc/fstab und aktuell gemountete Devices

Hier sollte man überprüfen, dass keine der möglichen Windows-Partitionen des Systems unter dem Linux-Host-System gemountet ist – zumindest nicht in einem Modus, in dem auf das Device geschrieben werden kann.

Schritt 5: Erstmaliges Starten der virtuellen Maschine

Nun kann man die virtuelle Maschine erstmalig starten. Das Starten erfolgt hier über den Boot-Sektor der Platte! Deshalb sollte nun auch das vollständige Grub-Menu erschienen – u.a. mit dem Windows Eintrag als ausgewähltem Standard-System zum Booten.

• Bitte nun wirklich mehrfach verifizieren, dass im Grub-Menu nun das Windows-System für den Boot-Vorgang ausgewählt ist. (Ein Booten des bereits aktiven Linux-Systems würde natürlicherweise – wie oben angemerkt – zu einer Katastrophe und zu einem völlig inkonsistenten Filesystem führen!)
• Danach Win XP in der virtuellen Maschine booten.
• Auswahl des richtigen (!) Hardwareprofils: Nun sollte als erstes eine Rückfrage bzgl. des auszuwählenden Hardwareprofils erscheinen. Auch hier bitte extrem vorsichtig sein und das für vmware erstellte Profil (in unserem Beispiel mit “VMware” bezeichnet) auswählen. Alles andere kann bei einem späteren nativen Boot des Windows-Systems zu erheblichen Problemen führen.
• Boot-Vorgang fortsetzen. Das sollte nun funktionieren und zwar ohne Blue Screen. Wenn man einen Blue Screen erhält und bzgl. des IDE-ATA-Contollers alles richtig gemacht hat, hilft nur, das Win XP nach einem nativen Booten über den Gerätemanager ggf. so zu entschlacken, dass es auch in der virtuellen Umgebung läuft. Auf meinem Dell 90 M gab es allerdings kein Problem.
• Am Login-Schirm einloggen und ggf. Win XP reaktivieren! Zu der Frage, ob eine zweite Lizenz erforderlich ist oder nicht, siehe etwa die Diskussion unter http://forum.ubuntuusers.de/topic/windows-xp-aktivierung. Siehe auch den dritten der oben zitierten Artikel für weitere Hinweise bzgl. der BIOS-Einstellungen für die virtuelle Maschine.
• Nun die VMware-Tools für den Windows-Gast wie gewohnt installieren.

Hinweis zu den VMware-Tools
Ich habe den VMware-Tools-Service später in den “Dienste”-Einstellungen von Win XP als manuell zu startenden Dienst konfiguriert, um bei einem nativen Windows-Boot nicht laufend mit Problemmeldungen konfrontiert zu werden. Ich habe nicht genau untersucht, woher die Meldungen kommen; vermutlich rühren sie ja daher, dass der dann der Host gesucht wird, aber nicht vorhanden ist. Ggf. resultieren die Probleme aber auch daher, dass mein Win XP selbst eine VMware-Server-Installation beherbergte. Dass ich nun in der virtuellen Maschine, VMware-Tools manuell starten muss, stört mich persönlich nicht; hier würde vermutlich aber auch ein wenig Skripting unter Windows weiterhelfen)

Schritt 6: Testen der normalen Windows-Installation nach einem Reboot

Nachdem die virtuelle Maschine funktioniert, sollte man auf jeden Fall nach einem Reboot des gesamten Systems auch noch die Funktionstüchtigkeit der Win XP-Installation im normalen nativen Modus checken. Auch ein Blick in den “Gerätemanager” könnte von Interesse sein.

Bzgl. der Harddisk stellte ich nach einigem Gebrauch des Win XP Systems sowohl in nativer Form als auch als VMware-Gastsystem fest, dass am Schluss folgender Treiber geladen wurde:

Intel(R) 82371AB/EB PCI-Bus-Master-IDE-Controller

Im Gegensatz zum Treiber, der im nativen XP geladen wird, operiert dieser Treiber nur im UDMA 2-Modus. Ich habe sicherheitshalber bislang nicht versuchen, das zu ändern.

Schritt 7: Einrichten einer virtuellen Floppy für das Booten oder
Entfernen von Grub

Um die Gefahr eines versehentlichen Bootens des Host-Linux-Systems im Grub-Menü nach dem Start der virtuellen Maschine zu vermeiden, empfiehlt es sich über eine virtuell eingebundene Floppy zu booten. Hier erspare ich mir eine Beschreibung, da diese vollständig und nachvollziehbar in einem der oben zitierten Artikel (aus dem gentooforum) enthalten ist.

Der oben zitierte Ubuntu-Artikel beschreibt, wie man alternativ die Kopie (!) des MBR, die in der virtuellen Maschine gezogen wird, und damit dann auch auch Grub in der virtuellen Maschine entfernt. Dadurch habe ich übrigens gelernt, dass der MBR in der VM ein kopierter ist. Darüber hatte ich vorher, ehrlich gesagt, noch nie nachgedacht. Erscheint im nachhinein aber als logisch. Man lernt halt nie aus!

Nun viel Spass mit Win XP in einer VM im Raw-Modus auf einem Linux-Host !

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.

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.