Windows auf dem Mac – Parallels vs. Bootcamp (und warum beides gleichzeitig nicht geht)

Früher oder später findet man als macOS Nutzer etwas, für das man ganz dringend Windows braucht. Die Alternativen für Mac sind entweder nicht gut genug, teuer oder gar nicht existent.

Ich muss gestehen, dass es bei mir in erster Linie ein Spiel war, das nicht für meinen Mac verfügbar war. Ich weiß, Schande über mich, dass ich versuche mit einem Mac zu zocken, aber ich habe nun einmal keinen anderen Rechner. Aus Kostengründen versuchte ich es zunächst mit Wine, was allerdings eher einem Glücksspiel glich. Mal funktioniert es, mal nicht. Schon alleine um Steam zu installieren, brauchte es drei verschiedene Programme von Wine, die abwechselnd funktionierten oder gar nicht erst starteten. Irgendwann vergeht einem dann die Lust. Also schaffte ich mir Parallels an. 

Parallels hat den Vorteil, dass macOS ganz bequem im Hintergrund laufen kann und nicht alle Aktionen in Windows ausgeführt werden müssen. Die Installation ist einfach, die Nutzung simpel und man kann sogar von Windows auf macOS-Dateien zugreifen und umgekehrt. Einziger Nachteil: man sollte einen Mac mit mindestens 8GB RAM haben, wenn man vernünftig damit arbeiten möchte. Es laufen eben zwei Betriebssysteme gleichzeitig, die sich den RAM teilen. Ein weiterer Nachteil, der für die meisten vielleicht unerheblich ist: Parallels unterstützt kein DirectX11. Da Apple die 3D-Grafikschnittstelle mit der Zeit komplett auf Metal umgestellt hat, funktioniert DirectX11 einfach nicht, wenn macOS im Hintergrund läuft. Was also tun?

Bootcamp heißt die zweite Möglichkeit, um Windows auf dem Mac zu nutzen. Das Einrichten ist etwas komplizierter, der Bootcamp-Installer aber schon auf dem Mac vorinstalliert. Je nach Modell des Macs braucht man einen leeren USB Stick und die ISO der gewünschten Windows Version. Bei neueren Macs läuft die Installation über eine kleine FAT32-Partition, auf die sowohl macOS als auch Windows zugreifen können und ein Stick ist nicht nötig.

Der Nachteil: man muss den Mac jedes Mal neu starten, wenn man Windows nutzen möchte und auf Dateien kann man nur von macOS zugreifen. Benötigt man unter Windows etwas von macOS heißt es neu starten und einen USB Stick suchen, oder einen Cloud-Dienst bemühen.

Zu Beginn der Installation von Bootcamp muss man sich entscheiden, wie groß die Windows-Partition werden soll.

Aber Vorsicht, wenn man auf Parallels nicht verzichten möchte bekommt man hier Probleme. Parallels scheint, was Speicherplatz angeht, ein wenig gierig zu sein. Auf meiner Festplatte waren über 200GB frei, Parallels nahm vom belegten Platz etwa 30GB ein. Trotzdem konnte ich im Bootcamp Installer nur 43GB zur Windows -Partition zuweisen. Zwei Stunden Googeln und einige Wutanfälle später war klar: Parallels reserviert sich den freien Festplattenspeicher vorsorglich. Wird dieser durch Programme oder Dateien unter macOS belegt ist das okay, doch beim Partitionieren der Festplatte legt Parallels Einspruch ein. Immerhin könnte es den Speicher ja irgendwann mal brauchen. Hier hilft dann nur der Verzicht auf Parallels oder das De- und Neuinstallieren, nachdem Bootcamp fertig ist. Backup nicht vergessen!

Lange Rede kurzer Sinn: Je nach Ansprüchen an den Arbeitsprozess können entweder Parallels oder Bootcamp die bessere Wahl sein. Auf beides gleichzeitig sollte man verzichten, es sei denn man stellt sich und seine Nerven auf einige zeitfressende Probleme ein.

Computerinventarisierung mit dem Microsoft MAP-Tool

Das Microsoft Assesment and Planning Toolkit (MAP) ist eine kostenlose Werkzeugsammlung, die bei der Migration auf eine neue Servergeneration hilfreich sein kann. Das MAP-Tool kann unter anderem für Inventarisierung und Berichterstellung eingesetzt werden.

Auf
http://www.microsoft.com/en-us/download/details.aspx?id=7826
findet man folgende Dateien:

1

Hilfreich ist dabei das Training_Kit. Damit können einzelne Funktionen geübt werden.

Anhand von einem Beispiel wird eine Funktion von MAP dargestellt, die Sie bei der Migration unterstützen kann:

MAP Inventarisierung AD-basierend

Listet alle Computer des Active Directory auf. Gesucht wird dabei nach Computerkonten: Client und Server.

Voraussetzung: zugriffsberechtigtes Domänenkonto, vorzugsweise  Domänenadministrator

Die Suchergebnisse werden in einer Datenbank gespeichert, die man nach der Installation des Toolkits erstellt. Es empfiehlt sich, eine Datenbank für jede Suche zu erstellen. Im Rahmen der Migration auf ein neueres Betriebssystem muss man alle Systeme mit dem Betriebssystem Windows Server 2003 identifizieren.

Folgende Schritte zeigen das Erstellen einer Datenbank:

2

Ein aussagekräftiger Datenbanknahme hillft bei der Identifikation der Suchergebnisse.

3

Hat man eine Datenbank erzeugt, ist die Inventarisierung der nächste logische Schritt. Dazu führt man eine Abfrage durch. In dem Bereich Environment wählt man den Schritt „Collect inventory data“ aus.

4

Gesucht wird nach Windows Computern

5

AD DS soll als Suchmethode ausgewählt werden

6

Notwendig sind die Angabe des Domänennamens, z.B. ad.uni-koeln.de, eines zugriffsberechtigten Accounts in Form Domäne\Benutzer bzw. Benutzer@Domäne, und eines Passworts.

7

8

Die restlichen Assistentenschritte werden mit Standardwerten durchgeführt.

Nach der Inventarisierung kann man feststellen, wieviele Computerkonten gefunden wurden. Dabei ist die Anzahl der erfolgreich inventarisierten Computerkonten zunächst unwichtig. Das Betriebssystem jedes Objekts wird angezeigt, sofern es definiert ist.

9

Bedient man sich der Reportgenerierung, wird ein Excel-Dokument mit allen gesammelten Daten erzeugt.

10

Im Dokument kann man einen Filter setzen und eine Übersicht für Server generieren, die nur das relevante Betriebssystem Windows Server 2003 haben.

C95K iscsi mode parameter und VMware iscsi software initiator

Wir hatten wiederholbar Probleme mit dem iSCSI-Verkehr zwischen einem ESX-Host vmnode8 und einer LUN, die vom Cisco 9509 SAN-director per iSCSI durch das IPS-8 board bereitgestellt wurde. Zwischen vmnode8 und c95k-rzkj-1 war wenigstens 1 router, wenn die Probleme auftraten. In einer Konfiguration ohne router, d.h. mit VMware host und c95k an einem switch waren die Probleme nicht zu beobachten.

Das Problem äusserte sich dadurch, dass bei dem Versuch der Installation eines Windows-Servers oder der Einrichtung einer disk unter knoppix mit fdisk I/O-Fehler auftraten.

Debugging mit tcpdump auf einem entsprechend auf den vSwitch (der auf promiscuous mode accept einzustellen war) des iSCSI-kernel-interfaces eingerichteten Gast zeigte, daß für eine Serie von mit TCP-Push gesendeten Paketen weniger Ack-Pakete zurückkamen, allerdings die sequencenumber korrekt inkremementiert war auf die Zahl des letzten gesendeten Bytes.

Cisco bietet zur Konfiguration eines iSCSI-(target) interfaces u.a. den mode parameter an:

interface iscsi
To configure an iSCSI interface, use the interface iscsi command. To revert to default values, use the no form of the command.
interface iscsi slot/port
mode {pass-thru | store-and-forward}
tcp qos value
interface iscsi slot/port
no mode {pass-thru | store-and-forward | cut-thru}
no tcp qos value
no interface iscsi slot/port
Syntax Description
Defaults
Disabled.
The TCP QoS default is 0.
The forwarding mode default is store-and-forward.

Bei uns standen aber alle Interfaces auf „mode pass-thru“. Umsetzen auf den „neuen“ Standardwert „mode store-and-forward“ ergab das offenbar vom VMware software iSCSI-initiator gewünschte Verhalten: nun wird offenbar für jedes TCP-Push ein ACK gesendet. Damit geht der fdisk-Vorgang dann rasch erfolgreich zuende.

Keiner versteht mich…

Seit einem Upgrade des Hostsystems auf Ubuntu 8.10 waren die Keyboardschemata in allen meinen VM-Guests verhunzt. Das hat zwar bisweilen amüsante Effekte („Pfeil-nach-unten“ war z.B. auf einmal das Signal für „mach einfach alles zu, frag erst gar nicht“), nach kurzer Zeit wird es aber sehr nervig. Nach einigem Herumprobieren mit Tastaturtreibern und Co. stöberte ich dann doch mal in der VMWare Knowledge Base und fand diesen Hinweis. In aller Kürze: Durch die Umstellung auf die neuen „evdev„-Treiber sendet das Hostsystem nun andere Tastencodes an VMWare und das knallt dementsprechend. In dem KB-Artikel werden einige Hinweise zur Behebung gegeben, bei mir genügten folgende zwei Zeilen in der Datei „/etc/vmware/config“:

xkeymap.nokeycodeMap = true
xkeymap.keysym.ISO_Level3_Shift = 0x138

Die erste Zeile behob bereits fast alle Probleme, die zweite war für die besonders bockige „AltGr“-Taste (was im übrigen für „Alt Graph“ steht, wie ich nun auch weiß) nötig. Der Wert „ISO_Level3_Shift“ kann dabei auf jedem System anders aussehen, Näheres dazu im KB-Artikel.

Wem auch der o.g. Artikel nicht weiterhilft, der findet im folgenden Blogeintrag weitere Lösungsvorschläge:

http://tinyurl.com/5kd7uz