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 !