Außerdem ist jetzt Windows 8 neu und hat neue Macken, Wheezy ist fast fertig und bietet neue Möglichkeiten ... und genau darum soll es hier gehen und ich werde meine bisherigen Ergebnisse zusammentragen. Der Text ist verdammt lang und absichtlich anfängertauglich gehalten und hoffentlich auch als Tutorial geeignet. Trotzdem hoffe ich auf Ergänzungen und Tipps und Tricks zur Verbesserung und zum Umschiffen der restlichen Klippen.
Ob die Rubrik hier richtig gewählt ist, mögen die Moderatoren entscheiden ... für die meisten Leute wird der Reiz eines virtuellen Windows mit nativer Grafikkarte wohl im Spielen liegen ... mir geht's allerdings mehr um Videobearbeitung. "Multimedia und Spiele" schien mir da passend.
1) Die Hardware
a) Mainboard und CPU
Die Hardware muss "IOMMU" können ... mit Xen geht es zwar auch irgendwie ohne, aber mit IOMMU macht man sich das Leben ne ganze Ecke leichter.
Da mir bei meinem alten AMD-System der Chipsatz durchgeschmort war, hab ich mich für Ersatz von Intel entschieden. Bei Intel heißt die Sache "VT-d" (nicht zu verwechseln mit "VT-x") und ist unübersichtlich. Pauschal können wohl alle Core-i5 und Core-i7 Prozessoren VT-d, außer den "K"-Versionen ... also nix für Übertakter, sorry. Bei den Mainboards kommt es wohl vorallem auf den Chipsatz an ... mit den alten Q-Chipsätzen und den neuen Z77er Chipsätzen liegt man schon mal richtig, aber es kommt immer darauf an, ob der Hersteller des Mainboads "VT-d" auch implementiert hat und dabei nichts versaut hat. ASRock und Gigabyte scheinen da gute Kandidaten zu sein, aber am besten sucht man vor dem Kauf im Netz nach Erfolgsberichten.
Bei AMD sieht's da entspannter aus ... da nennt sich die Sache "AMD-Vi" und ist ein Teil der "AMD-V"-Virtualisierung und AMD ist recht größzügig und baut es in sämtliche größeren Desktopmodelle ein. Das bedeutet aber nicht, dass es immer funktioniert ... auch hier sollte man nach Erfolgsmeldungen mit dem Wunsch-Mainboard suchen.
b) Die Grafikkarte
Theoretisch sollte es wohl gehen, Linux "headless", also ohne eigene Grafikkarte zu betreiben. Praktisch macht es wohl Probleme, den Kernel bzw. das BIOS daran zu hindern, die Grafikkarte beim Booten so halb initialisiert liegenzulassen ... aber da es hier um Desktopsysteme geht, gehe ich mal davon aus, dass Linux seine eigene Grafikkarte hat. Die Intel-Onboard-Grafik reicht mir hier völlig aus.
Man macht sich die Konfiguration übrigens einfacher, wenn Linux-Grafikkarte und Gast-Grafikkarte von unterschiedlichen Herstellern stammen. Nimmt man für beides z.B. ATI, so muss man dem Kernel beibringen, dass der radeon-Treiber die eine Karte ansprechen soll, die andere aber nicht.
Eigentlich bin ich ja Nvidia-Fanboy, aber mit Nvidia und PCI-Passthrough scheint es arge Probleme zu geben ... die Karten von Nvidia modifizieren ihr BIOS wohl im laufenden Betrieb ... hier und da gibt es Erfolgsmeldungen mit modifiziertem VGA-BIOS für spezielle Grafikkarten, aber mit meiner alten Geforce 9500 hab ich absolut nix Brauchbares zustande bekommen.
Bei ATI sieht es wesentlich besser aus ... ich hatte noch eine alte Radeon HD 5450 rumliegen, und mit der lief es. Generell finden sich die meisten Erfolgsmeldungen im ATI-Lager.
2) Die Software
Die Sache mit der Virtualisierung findet vorallem Anwendung im Serverbereich ... so gibt es wunderbare Lösungen, mit denen sich ganze virtuelle Serverfarmen per Weboberfläche verwalten und per VNC über's Netz auf den eigenen Desktop holen lassen. Die waren für mich aber allesamt nutzlos.
Die meiste Erfahrung hatte ich mit Virtualbox. Nun befindet sich die PCI-Passthrough-Funktion aber im dauer-beta-Stadium und VGA-Passthrough scheint gar nicht zu funktionieren. Selbst in deren Forum wird auf Xen verwiesen. Außerdem scheint Virtualbox sämtliche USB3 Anschlüsse lahmzulegen ... also keine Option.
(Mit Microsofts HyperV scheint das übrigens auch nicht zu gehen)
Bei VMware heißt die Funktion "VMDirectPath", aber da VMware sämtliche Gratis-Produkte gestrichen hat, und google bei meiner Suche vorallem Berichte über "BSOD" ausgespruckt hat, schien mir das kein erfolgsversprechender Ansatz zu sein.
Xen ist der Altmeister unter Linux, wenn es um das Durchreichen von Geräten geht. Es finden sich zahlreiche Erfolgsmeldungen und teils sehr versierte Lösungen für Problemfälle. Und Xen bietet als einziges Produkt die Möglichkeit, auch ohne IOMMU zum Erfolg zu kommen. Allerdings braucht Xen einen eigenen Kernel und die Entwicklung scheint mir im Verhältnis zu Kvm etwas ins Stocken geraten zu sein. Für ältere Systeme sicherlich einen Versuch wert, aber als ich mal testweise den Xen-Kernel installiert habe, nachdem ich mit kvm nicht so recht weiterkam, rauschten mit soviele Fehlermeldungen beim booten über den Schirm, dass ich doch lieber weiter an kvm rumgepfrickelt habe.
Somit war die für mich beste Lösung dann die Kernel Virtual Machine, kurz kvm, und praktischer Weise fest in den Linux-Kernel eingebaut.
kvm alleine reichte mir aber nicht. Bei der Konfiguration komplexer virtueller Systeme werden die Befehlszeilen schnell abartig lang, so suchte ich eine nette grafische Klick-Lösung, ähnlich Virtualbox. Viel Auswahl gab's da nicht, nach kurzem Test von AQEmu fiel meine Wahl auf den "virt-manager". Der ist zwar auch nicht perfekt, zieht aber mit "virsh" und der "libvirt" ein komplettes Framework zum Verwalten von virtuellen Maschinen mit rein, das deutlich komfortabler ist als das nackte kvm.
Außerdem verwende ich KDE ... da gibt's noch ein paar kleine Stolpersteine. Und natürlich pures Wheezy AMD64 auf dem aktuellsten Stand.
3) Jetzt geht's los! ^^
Sämtliche Befehle sind als root auszuführen, solange nicht anders erwähnt. Ob ihr das nun per Rootshell macht oder sudo nehmt, ist eure Sache.
Ich benutze ja gerne synaptic, wenn ich nicht genau weiß, was ich installieren will, da kann man so schön rumklicken, scrollen und suchen. Das muss natürlich erst installiert werden, und dann gibt's beim Starten auch schon das erste Problem. root darf das nicht.
Also müssen wir es ihm erst erlauben, indem wir als der Benutzer, dem die X-Sitzung gehört
Code: Alles auswählen
xhost + SI:localuser:root
Ich weiß nicht mehr genau, was ich bei meinen Experimenten alles installiert habe, aber eigentlich müssten "qemu-kvm" und "virt-manager" nebst sämtlichen Abhängigkeiten reichen. (libvirt-bin sollte mit reingezogen werden, ich weiß blos gerade nicht mehr, von was. Sonst auch installieren)
Bevor man jetzt feststellt, dass auch der virt-manager kein Fenster auf dem X-Display öffnen darf, gibt man lieber als normaler Benutzer
Code: Alles auswählen
xhost + SI:localuser:libvirt-qemu
Das ist nach jedem login nötig, gehört also langfristig in ein Startupscript.
Bei der Installation wurde auch die Gruppe "libvirt" angelegt und jeder Benutzer, der den virt-manager nutzen will, muss in dieser Gruppe sein. Ich bin ja bequem, also hab ich mir das zurechtgeklickt:
Code: Alles auswählen
aptitude install kuser
dbus-launch kuser
Code: Alles auswählen
xhost + local:
4) Windows 8 installieren
a) Vorbereitungen
Ich gehe mal davon aus, dass man einen Lizenzschlüssel erworben hat. Ich zumindest habe das Upgrade auf Windows 8 Pro für 50 Eur beim Medimarkt mitgenommen ... nachdem ich das letzte mal vor über 10 Jahren Geld für Win XP Professional ausgegeben habe, schien mir das eine akzeptable Ausgabe zu sein.
Da Windows aber unter dem bekannten Bug leidet zu vergessen, dass es legal erworben wurde, wenn zuviel an der (virtuellen) Hardware geändert wird, sollte man sich gut überlegen, ob man seinen Lizenzschlüssel gleich bei der Installation eingibt und das Risiko eingeht, nach einigen Änderungen mit Microsoft telefonieren zu müssen.
Das kann man natürlich verhindern, indem man erst mal ohne Netzwerkkarte arbeitet, bis alles rund läuft, aber das macht den Download von aktuellen Treibern nicht leichter. Oder man greift für Experimente erst mal zur Enterprise-Demo-Version, die nicht gleich bei der Installation nach einem Schlüssel fragt:
http://www.chip.de/downloads/Windows-8- ... 63405.html
Übrigens ... es heißt ja Upgrade auf Windows 8 Pro. Ich geriet etwas ins Schwitzen, als ich meine alte Windows XP CD suchte und mir dann das "Upgrade" auf dem XP-Karton ins Auge fiel. Wo zur Hölle mochte meine Win95 CD sein? Ich hab's dann einfach mal versucht, Win8 ließ sich nach der Eingabe des Lizensschlüssels auf eine nackte (virtuelle) Festplatte installieren und befindet sich nachher in einem merkwürdigen Zustand, bei dem unter "Windows ist aktiviert" nur eine Fehlermeldung auftaucht. In diesem Zustand bricht aus einem unerfindlichen Grund die Berechnung des Windows-Leistungsindexes im Multimedia-Teil mit einer Fehlermeldung ab. Das hat mich Stunden gekostet ... ich dachte, mit der Grafikkarte und dem PCI-Passthrough stimmt was nicht. Anscheinend erkennt das Upgrade diese verkorkste Version aber als "Windows" ... wenn man es noch mal drüberinstalliert, läuft es danach einwandfrei und lässt sich aktivieren.
Wer ein OEM-Windows 8 von einem anderen Rechner recyclen möchte, oder gar auf diesem Rechner Linux betreiben möchte und sein Windows 8 darauf virtualisieren möchte: Bei Rechnern mit OEM-Windows 8 liegt kein Lizenzschlüssel mehr bei, der steckt irgendwo im BIOS. Pech gehabt. (Soll sich aber auslesen lassen, irgendwie)
ISO oder DVD? Gute Frage ... ich hatte ja eh die DVD, also hab ich die ins Laufwerk gelegt und das Laufwerk an den virt-manager weitergeleitet. Das läuft einwandfrei, allerdings ist kvm im Ansprechen realer DVD-Laufwerke schnarchlangsam ... die Installation dauert ne knappe Stunde. Über ein ISO sollte es schneller gehen, allerdings muss man darauf achten, dass der virt-manager auf die ISO-Datei und den Pfad Zugriff hat. Einen optimalen Platz dafür habe ich nicht gefunden, das eigene home-Verzeichnis taugt nur, wenn "jeder" darauf Leseberechtigung hat. Somit dümpeln meine ISOs jetzt in /var rum, mit r-r-r-Rechten.
b) Die Installation
Wenn man aus dem Menü den "Virtual Machine Manager" startet, öffnet sich ein Fenster (toll!). Es scheint keine andere Methode zu geben, eine VM zu erzeugen, als auf "New" zu klicken, dann ist man in einem Wizard, der einen durch den Erstellungsprozess führt ... ist ja auch nicht schlecht. Als Namen sollte man was Einfaches nehmen, eventuell mus man es öfter mal eintippen. Als DVD-Laufwerk sollte /dev/sr0 vorausgewählt sein, was für die Meisten richtig sein sollte, sonst muss man ihm zeigen, wo das Installations-ISO liegt. Was Neueres als Win7 lässt sich nicht auswählen, also hab ich das genommen. Die Speichermenge hängt wohl vom Verwendungszweck ab, und da ich nicht vorhabe, mit mehreren VMs auf unterschiedlichen CPU-Kernen zu jonglieren, hab ich ihm alle Kerne gegönnt, die ich hatte. Dann fragt sich noch, wie groß die virtuelle Festplatte sein soll. So als Hausnummer ... das nackte Windows 8 belegt nach dem Update-Marathon schon geschlagene 20 GB. Ich hab 128 GB eingetippt und den Haken bei "Allocate entire disk now" entfernt. Zum Schlusss sollte man noch einen Haken bei "Customize configuration before install" machen, wir sind nämlich noch nicht fertig:
Als erstes löschen (remove) wir die gerade erstellte Festplatte (Disks 1) wieder und erstellen eine neue (Storage). Die hat dieselbe Größe wie die Alte, nur wählen wir statt IDE SATA als Anschluss und als "Storage Format" "qcow2". Der Haken bei "Allocate entire disk now" sollte wieder verschwinden. Bei der Erstellung fragt er, ob er das alte Disk-Image wiederverwenden soll ... ja, soll er. Danach kann es meiner Meinung nach nicht schaden, der eben erstellten Festplatte noch eine beliebige "Serial number" zuzuweisen ... vielleicht steigert das ja den Wiedererkennungswert der Hardware für Windows.
Wer Wert auf maximale Performance legt, sollte sich schon mal überlegen, ob er Windows nicht eine eigene Partition oder gar eine eigene reale Festplatte spendieren möchte. Außerdem sollte man einen Blick auf die virtio-Treiber werfen. Aber solange man mit einer Datei als Diskimage arbeitet, gibt es zwischen "raw" und "qcow2" nach meiner Beobachtung keine großen Performance-Unterschiede und qcow2 bietet gewaltige Vorteile, wenn es um Backups oder Snapshots geht. Der Leistungsindex von Windows bescheinigt meiner virtuellen Festplattendatei eine Leistung von 7,8, ich denke, das geht in Ordnung.
Als nächstes entfernt man das VNC-Display und ersetzt es durch ein SDL-Window. VNC mag ja toll sein für den Remote-Zugriff, aber ein direktes X-Fenster fühlt sich eindeutig flüssiger an.
Außerdem sollte unter "Video" die "cirrus"-Grafikkarte ausgewählt werden. Standard ist "vga" und eigentlich ist vga auch besser, weil es höhere Auflösungen zulässst, nur bei Windowss 8 nicht, da ist die Auflösung auf 1024x768 begrenzt. Mit cirrus kommt man wenigsten auf 1280x1024. Dazu gibt's auch schon einen Bugreport und einen Fix, ich weiß nur nich so recht, wie ich den anwenden soll ... mit den Xen-Sourcen zu hantieren ist mir dann doch etwas zu heikel:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685097
Wer lieber offline arbeiten möchte, sollte noch die Netzwerkkarte entfernen, sonst ist Windows sofort online und telefoniert nach Hause.
Klickt man jetzt auf "Beginn Installation", sollte die Sache eigentlich glatt durchlaufen, inklusive einiger Reboots.
Ich hatte und habe zeitweise Ärger mit der Soundkarte ... wenn virt-manager den Start mit einer Fehlermeldung über Alsa verweigert, schmeißt man die virtuelle Soundkarte einfach erst mal raus. Ich vermute, dass liegt an irgendwelchen fehlenden Berechtigungen für Pulseaudio, aber da ich den Sound eh über HDMI und den Monitor laufen lassen wollte, hab ich mich da noch nicht reingekniet.
Wer auf die Idee kommt, die Installation von Windows 8 gleich mit durchgeschleifter nativer Grafikkarte zu versuchen, dem sei gesagt: es geht! Genau einmal! Danach nie wieder. Die Windows-Installation läuft duch, sogar auf dem eigenen Monitor, und danach zeigt Windows nie wieder ein Bild. Keine Ahnung warum.
Da unter Windows 8 ja viel über die "Hot Corners" funktioniert, und man dazu mit der Maus genau die Bildschirmecke treffen muss, fand ich die Funktion, dass die Maus fließend zwischen Windows-Fenster und Linux-Desktop wechselt, ausgesprochen nervig. Wem das auch so geht, der kann sich behelfen, indem er das virtuelle Grafiktablett aus der Konfiguration schmeißt. Danach "fängt" das Windows-Fenster die Maus und sie lässt sich mit "Strg"+"Alt" wieder befreien.
Wenn Windows schon läuft, kann man gleich mal in den Gerätemanager gucken, ob da alles nett aussieht. Ich habe ein mysteriöses "PCI-Gerät" in der Liste, und keine Ahnung, was das ist. Ich habe es "deaktiviert" und alles läuft prächtig. Besonders interessant ist, auf welchem Prozessor Windows zu laufen meint ... vermutlich steht da was von "KVM CPU".
Die CPU-Frage hat mir einiges an Kopfzerbrechen bereitet. Wenn man Wert auf Portabilität legt, also seine virtuelle Maschine auch mal auf einem anderen Rechner laufen lassen möchte, dann sind die KVM-CPUs wohl die sicherste Wahl. Andererseits sind sie auch der "kleinste gemeinsame Nenner" und man verschenkt damit eventuell zusätzliche Fähigkeiten seiner nativen CPU (zum Beispiel AES-NI).
Da ich einen nagelneuen Ivy-Bridge Prozessor hatte und nicht plane, die VM umzuziehen, war mir das nicht genug. Als übliche Lösung wird empfohlen, im virt-manager unter Processsor->Configuration auf "Copy host CPU configuration" zu klicken. Wenn ich das tue, hab ich nachher einen mageren Core2Duo in Windows. Wenn ich "SandyBridge" als "Model" auswähle, ebenfalls. Ich habe zig Experimente gemacht ... mit kvm auf der Kommandozeile geht es, mit dem virt-manager nicht.
Tipp:
Code: Alles auswählen
ps -e -F | grep kvm
Aber zurück zu meinem CPU-Problem ... die Konfigurationen der VMs lagern unter /etc/libvirt/qemu/<NAME>.xml. Wenn man da reinschaut, findet man eine CPU-Definiton ähnlich dieser hier:
Code: Alles auswählen
<cpu mode='custom' match='exact'>
<model fallback='allow'>SandyBridge</model>
<vendor>Intel</vendor>
<feature ....
...
</cpu>
Code: Alles auswählen
<cpu mode='host-passthrough'>
</cpu>
Code: Alles auswählen
virsh edit <Name der virtuellen Maschine>
Danach wurde zumindest bei mir unter Windows der richtige Prozessor angezeigt ... feine Sache.
Beim Neustart kann man gleich mal darauf achten, ob Windows sich darüber beschwert, dass es beim Start unerwartet beendet wurde. Diese verwirrende Fehlermeldung hat mich auch einige Zeit beschäftigt ... Ursache ist, dass Windows beim Herunterfahren abstürzt, das aber erst beim nächsten Neustart bemerkt und gerne reparieren möchte.
Eigentlich wollte ich ja die Ursache für das Problem finden und beheben, aber nachdem ich auf die Geschichte dieses Leidensgenossen gestoßen bin, verging mir die Lust:
http://superuser.com/questions/505946/w ... up-enabled
Für mich war die Lösung einfach, ich habe Fast Boot ausgeschaltet. Das geht über Systemsteuerung->Energieoptionen->Netzschalter->Einige Einstellungen sind im Moment nicht verfügbar.
Danach war die Fehlermeldung verschwunden, und das Ausschalten empfiehlt sich eh, falls man mal die Festplattendatei unter Linux direkt mounten möchte.
Windows 8 sollte jetzt fehlerfrei laufen, dann können wir endlich mit den spannenden Sachen anfangen!
5) IOMMU aktivieren
Das klingt leicht, hatte aber auch so seine Tücken.
Zuerst muss die Funktion im BIOS aktiviert werden ... bei mir hieß sie "Intel VT-x" - das war leicht.
Dann muss sie im Kernel aktiviert werden. Zumindest für Intel-Prozesssoren ist sie nämlich deaktiviert, weil sie zuviel Ärger macht. Wie es bei AMD steht, weiß ich nicht genau.
Das geht am leichtesten über Grub - drückt man im Bootmenü "e", kommt man in den Editor, und fügt dort hinter dem "quiet" ein:
Code: Alles auswählen
intel_iommu=on
Jetzt drückt man am besten mal F10 und schaut, was beim Booten passiert. Optimaler Weise passiert nix ungewöhnliches ... die Kiste bootet wie immer. Bei mir leider nicht ... mir flogen Unmengen an Zeilen vor den Augen entlang, irgendwas mit DMAR.
Eine kurze Google-Befragung ergab, dass die Schuld meist auf einem im BIOS falsch konfiguriertem USB-Controller beruht (Zitat "because BIOS is written by monkeys"). Das war auch richtig ... nachdem ich die 4 USB3-Ports des VIA VL800 Chips abgeschaltet hatte, konnte ich booten. Tja, bis jetzt hab ich keine bessere Lösung gefunden, die 4 Ports sind unbrauchbar, schade.
So ganz sauber war der Boot-Vorgang aber immer noch nicht ... weitere DMAR-Meldungen konnte ich aber wenigstens lesen und die PCI-Gerätenummer deutete auf den onboard Marvell-Sata-Controller hin.
Tja, wieder richtig ... das Problem ist wohl bekannt, und ein Patch ist mit wenig Engagement in Arbeit:
https://lkml.org/lkml/2012/12/19/104
Gut ... nun hab ich 4 USB- und 2 Sata-Ports weniger, aber ich kann wenigstens mit aktivierter IOMMU booten. Die Sata-Ports habe ich übrigens durch einen billigen Jmicron-Controller ersetzt, der läuft problemlos.
Als nächstes muss man den Kernel noch daran hindern, den Treiber für die Windows-Grafikkarte zu laden. Meine Versuche mit Eintragungen in /etc/modules und /etc/modprobe.d waren erfolglos, also muss wieder ein Kernelparameter helfen:
Code: Alles auswählen
modprobe.blacklist=radeon
Bei meinen Recherchen habe ich noch diesen Artikel:
http://lwn.net/Articles/329174/
entdeckt, und einen etwas anders lautenden undokumentierten Kernel-Parameter:
https://www.kernel.org/doc/Documentatio ... meters.txt
Soweit ich das verstehe, schaltet die iommu=pt Option lediglich das Passthrough für PCI-Geräte frei, nicht jedoch die volle IOMMU-Funktion, die ja eigentlich das umblenden von Speicherbereichen auf andere Speicherbereiche ermöglichen soll. Das soll dem Wirts-System gewisse Performance-Vorteile bringen, und zumindest bei mir habe ich keine negativen Einflüsse entdeckt, aber auch keine positiven (ich hatte ja die Hoffnung, es bringt mir meine USB- und SATA-Ports zurück).
Somit sehen meine vollständigen zusätzlichen Kernelparameter jetzt so aus:
Code: Alles auswählen
modprobe.blacklist=radeon intel_iommu=on iommu=pt
Ein
Code: Alles auswählen
lsmod | grep radeon
6) Grafikkarte freigeben
Damit der virt-manager die Grafikkarte nutzen kann, muss sie dem PCI-Stub-Treiber zugewiesen werden. Dazu müssen wir erst mal wissen, unter welcher PCI-Bus-Nummer sie zu finden ist.
Ein
Code: Alles auswählen
lspci
Code: Alles auswählen
02:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Manhattan [Mobility Radeon HD 5430 Series]
02:00:1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI Audio [Radeon HD 5400/6300 Series]
Code: Alles auswählen
lspci -n
Code: Alles auswählen
02:00.0 0300: 1002:86e1
02:00.1 0403: 1002:aa86
Die Befehle für das Zuweisen der Grafikkarte sind etwas unhandlich, daher habe ich sie gleich in ein Shellscript gebastelt:
Code: Alles auswählen
emacs ~/grafikkarte-zuweisen.sh
Code: Alles auswählen
#! /bin/sh
xhost + SI:localuser:libvirt-qemu
# sollte keine Ausgabe zeigen:
lsmod | grep radeon
# virsh start-net default
modprobe pci_stub
echo "1002 86e1" > /sys/bus/pci/drivers/pci-stub/new_id
echo 0000:02:00.0 > /sys/bus/pci/devices/0000\:02\:00.0/driver/unbind
echo 0000:02:00.0 > /sys/bus/pci/drivers/pci-stub/bind
echo "1002 aa86" > /sys/bus/pci/drivers/pci-stub/new_id
echo 0000:02:00.1 > /sys/bus/pci/devices/0000\:02\:00.1/driver/unbind
echo 0000:02:00.1 > /sys/bus/pci/drivers/pci-stub/bind
rmmod kvm-intel
rmmod kvm
# entweder:
modprobe kvm ignore_msrs=1
# oder:
# modprobe kvm
modprobe kvm-intel
Code: Alles auswählen
chmod u+x ~/grafikkarte-zuweisen.sh
Code: Alles auswählen
~/grafikkarte-zuweisen.sh
So, jetzt haben wir es auch schon fast ... wir können den Virtual Machine Manager jetzt wieder starten, unsere Windows-Maschine öffnen, und über "Details" und "Add Hardware" die Grafikkarte und die HDMI Soundkarte hinzufügen. Jetzt auf "Run" klicken uuuuuund?
Tja, meistens passierte jetzt bei mir was ... Windows startete und erkannte die reale Grafikkarte und der Monitor wurde hell. Manchmal aber auch nicht, und im Gerätemanager erschien ein Fragezeichen. Ich hab lange die Ursache für dieses anscheinend zufällige Verhalten gesucht, bis ich endlich den mitgelieferten Microsoft-Standard-Treiber durch den neusten original ATI Treiber ersetzt habe. Damit geht's zuverlässig.
Sobald die reale Grafikkarte ins Spiel kam, waren meine ersten Ergebnisse übrigens permanente Blue Screens in Windows. Gleichzeitg hatte ich Meldungen über "MSR" vom kvm-Treiber im dmesg. Offiziell soll das wohl ein Bug in qemu sein, aber es ließ sich leicht lösen, indem man das kvm-Modul mit der Option "ignore_msrs=1" lädt. Darum kümmert sich schon das kleine Script oben.
7) Weitere kleine Problemchen
Wenn man mal so weit ist, dass Windows über die eigene Grafikkarte ein Bild ausgibt, kann man schon mal sehr zufrieden sein.
Das nächste Problem, über das ich stolperte, war dass die Konfiguration keinen Neustart von Windows überlebt hat. Beim nächsten Start war die Grafikkarte wieder tot und im Gerätemanager prankte ein Fragezeichen. Das ist ein bekanntes Problem - die virtuelle Hardware erlebt zwar einen kompletten Rebootzyklus, nicht jedoch die reale Grafikkarte ... die befindet sich danach in einem undefinierten Zustand und lässt sich von Windows nicht neu initialisieren. Die übliche Lösung lautet "Linux neustarten", was gewaltig nervt, so oft, wie Windows rebooten will. Bei mir hat ein viel einfacherer Trick geholfen ... ich habe Linux einfach ins Suspend-To-Ram geschickt, danach war die Grafikkarte wieder ansprechbar.
Später habe ich mir noch eine Radeon HD 6450 geholt, weil mir die 5450 doch etwas lahm erschien (beide Karten sind übrigens ne feine Sache ... kein Lüfter, belegen nur einen Slot und sehr sparsam im Stromverbrauch). Die 6450 ließ sich seltsamer Weise problemlos rebooten, und ich habe keine Ahnung warum.
Spätestens jetzt, wenn die Konfiguration steht, sollte man Windows mit einer Netzwerkkarte ausstatten und aktivieren. Das macht keine Probleme (naja, abgesehen von dem Updatemarathon, den Windows dann vollführt ... es ist erstaunlich, wieviele Patches jetzt schon eingespielt werden müssen und wie lange das dauert). Das Problem kriegt man beim nächsten Linux-Reboot in Form einer komischen Fehlermeldung vom virt-manager, dass irgendwas mit dem default-Netzwerk nicht stimmt.
Logisch ... das muss erst gestartet werden:
Code: Alles auswählen
virsh net-start default
Code: Alles auswählen
virsh net-autostart default
Code: Alles auswählen
virsh net-autostart default --disable
Die Konfiguration des "default" Netzwerkes versteckt sich in /etc/libvirt/qemu/networks und ich habe mich noch nicht näher damit beschäftigt, aber ich würde Windows ja gerne das Netz abdrehen können, wenn ich mal nicht will, dass es nach Hause telefoniert. Das geht vermutlich entweder in dieser Konfigurationsdatei oder über die virtuelle Bridge und das virtuelle Netzwerk, das man per
Code: Alles auswählen
ifconfig
Das laufende Window überlebt übrigens keinen Suspend-to-Ram oder Suspend-to-Disk des Linux-Systems - man muss es vorher herunterfahren. Fährt man Linux herunter, so ist schon ein Automatismus eingebaut, der Versucht, alle VMs vorher zu stoppen ... vermutlich indem ACPI-Events an die VMs geschickt werden. Ähnliches werde ich dann mal als hook in die pm-utils einbauen, damit es auch beim STR passiert. Vielleicht kann man Windows ja sogar vorher automatisch ins Suspend-to-Disk schicken?
Wer auf die Idee kommt, die virtuelle Grafikkarte in Windows zu deaktivieren, der sollte wissen, dass es dann keine Möglichkeit mehr gibt, den Mauszeiger aus Windows zu befreien. Als Lösung könnte man es mit einer eigenen Maus für Windows versuchen, die als USB-Gerät durchgereicht wird. Wen das extra-Windows-Fenster auf dem Desktop nervt, der kann den virtuellen Monitor während der Arbeit unter Windows einfach in den Anzeige-Eigenschaften deaktivieren und nachher wieder reaktivieren.
Spätestens jetzt, wo die Konfiguration steht und alles läuft, sollte man sich eine Kopie seiner Konfiguration unter /etc/libvirt/qemu/ und seiner Festplattendatei unter /var/lib/libvirt/images/ anlegen.
Wie es weiter geht
Als erstes werd ich mir mal Netzwerkfreigaben unter Windows und Samba-Freigaben unter Linux einrichten, damit der Dateiaustausch im laufenden Betrieb klappt ... das war ja schließlich Sinn der ganzen Aktion. Und ein Script, das mir die Windows-Festplatten-Datei mounted, falls ich mal kurz an ne Datei ran muss.
Dann gibt es noch die virtio-Treiber, die spezielle Virtio-Geräte ansprechen können, die der virt-manager bereitstellen kann. Die Virtio-Geräte funktionieren schneller - das Betrifft vorallem den Festplattendurchsatz und die Netzwerkkarte. Mit der Festplattenperformance bin ich eigentlich ganz zufrieden,aber die virtuelle Netzwerkkarte schafft nur 100Mbit, das ist etwas wenig. Die Virtio-Gasttreiber für Windows 8 sollen schon recht ausgereift sein und lassen sich hier finden:
http://alt.fedoraproject.org/pub/alt/vi ... mages/bin/
Vermutlich ist es eine gute Idee, sich die MAC-Adresse der alten virtuellen Netzwerkkarte zu notieren und für die Virtio-Karte wiederzuverwenden ... sonst wird Windows noch schwindelig vor lauter Änderungen.
Außerdem gibt es noch "Spice". Spice ist, soweit ich das verstanden habe, eine Erweiterung für VNC, die die Übertragung bewegter Bilder beschleunigen soll. Zu Spice gehört ein QXL-xserver und QXL-Treiber für Windows. Die Windows Treiber sollen hervorragend funktionieren, nur nicht unter Windows 8, weil Microsoft hier ein neues Treibermodell (WDDM statt XDDM) einsetzt. Zum einen interessiert mich das nicht so, da ich ja gerade native 3D-Beschleunigung haben will, und VNC nicht zu nutzen plane, zum anderen scheint es eh noch etwas zu dauern, bis ein WDDM-Treiber für QXL fertig ist. Wer das Thema verfolgen will, findet hier weitere Informationen:
http://spice-space.org/page/Features/WinQXLRewrite
http://lists.freedesktop.org/archives/s ... 09253.html
(Und ehrlich gesagt - bei meinen Recherchen wurde mir klar, mit Windows 7 wäre ich besser dran gewesen, was die Virtualisierung angeht)
Ansonsten habe ich hier jetzt auf dem Schreibtisch zwei Monitore mit je zwei Eingängen stehen, von denen jeweils einer an der Linux- und einer an der Windows-Grafikkarte angeschlossen ist. Da xrandr auf der Intel-Grafik wunderbar funktioniert, und Windows ebenfalls im laufenden Betrieb einen Monitor aus- oder einblenden kann, sind die Möglichkeiten sehr flexibel und umfangreich. Ich muss das erst mal ausprobieren, was da alles möglich ist ... vielleicht hole ich mir noch einen dritten Monitor ... oder einen vierten ... hach ... ich brauche einen größeren Schreibtisch!
9) Was die Zukunft bringt
kvm wird es demnächst nicht mehr geben, es fließt endgültig in die Entwicklung von qemu zurück. Das ist ab qemu Version 1.3 der Fall, und die ist schon fertig und war kurzzeitig in Experimental, aber ich bin bei der Installation an unerfüllten Abhängigkeiten gescheitert. Version 1.3 soll zusammen mit dem Kernel 3.7 die Sache mit dem PCI-Passthrough noch leichter und flexibler machen ... ich bin gespannt. Aber erst mal muss Wheezy fertig werden, dann taucht die neue Version vielleicht mal in den Backports auf.
Den Kernel 3.7 aus Experimental hatte ich übrigens mal installiert, aber ich konnte bezüglich meiner Probleme mit IOMMU keine Verbesserung feststellen. Ich hoffe mal auf 3.8. Dafür hatte ich bisher unter Kernel 3.7 keinen dieser sporadischen Abstürze, für die ich die Ivy Bridge Grafik verdächtige ... inzwischen benutze ich ihn als Standard.