Windows 8 unter Wheezy mit eigener Grafikkarte

Sound, Digitalkameras, TV+Video und Spiele.
Antworten
NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Windows 8 unter Wheezy mit eigener Grafikkarte

Beitrag von NAB » 13.02.2013 12:55:43

Das Thema Virtualisierung macht ja schon länger die Runde, und ist seit Virtualbox auch Desktoptauglich, und PCI(e)-Passthrough zum direkten Durchreichen von Geräten an das Gast-Betriebsssystem funktioniert inzwischen auch ganz gut ... nur nicht bei Grafikkarten ... da finden sich viele kleine Informationsbrocken im Netz, meist auf Englisch, oft veraltet, ein wenig für Ubuntu auf Deutsch ... und so richtig Allumfassend war das alles nicht.

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
ausführen. Ich hab das inzwischen als Shellscript unter "~/.kde/Autostart" untergebracht. Unter Gnome gibt's das Problem nicht.

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
ein.

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
Damit die Änderungen wirksam werden, muss man sich aus- und wieder einloggen ... und danach natürlich die xhost-Befehle von oben wieder eingeben. Beim Experimentieren kann man sich aber erst mal mit einem pauschalen

Code: Alles auswählen

xhost + local:
behelfen. Als Dauerlösung ist das allerdings sicherheitsbedenklich.

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
zeigt einem den vollständigen kvm-Befehlsaufruf mit sämtlichen Parametern ... virt-manager macht nämlich auch nix andere als kvm aufzurufen. Die Zeile kann man sich kopieren und für eigene Experimente nutzen, wenn man an die Grenzen von virt-manager stößt.

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>
Der CPU-Tag muss ersetzt werden durch diesen hier:

Code: Alles auswählen

<cpu mode='host-passthrough'>
</cpu>
Blöder Weise ist der virt-manager ziemlich pingelig mit seinen xml-Dateien, man sollte die Dateil also mit dem eingebauten Editor ändern:

Code: Alles auswählen

virsh edit <Name der virtuellen Maschine>
Noch blöderer Weise basiert der Editor auf dem Vi, den ich für so ziemlich das Gegenteil einer intuitiven Benutzeroberfläche halte. Darum mal das Wichtigste in Kürze: Der Vi kennt den Kommando-Modus und den Schreib-Modus. In den Kommandomodus kommt man mit ESC, von dort wechselt man mit "i" in den Schreib-Modus. Im Schreib-Modus kann man schreiben (surprise!), wobei es bei mir schon bei den Pfeiltasten hapert. Im Kommandomodus gehen dafür die Pfeiltasten, mit "d" kann man Zeilen löschen, mit ":w" speichern und mit ":q" beendet man. Danach guckt man mal, ob virsh ne Fehlermeldung ausgespuckt hat ... wenn er meckert, hat man was falsch gemacht. Dazu sollte Windows natürlich beendet, die VM gestoppt und der Virtual Machine Manager geschlossen sein.

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
Hierbei hat man mit der amerikanischen Tastaturbelegung zu kämpfen ... der Unterstrich findet sich mit Shift+ß und das "=" liegt rechts daneben.

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
(Wer mit Nvidia experimentiert, nimmt "nouveau" statt "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
Wenn das erst mal läuft, kopiert man sich am besten die aktuelle Konfiguration aus /boot/grub/grub.cfg heraus und fügt sie in /etc/grub.d/40_custom am Ende ein und ändert dann dort die Kernel-Parameter. Danach ein "update-grub", und man spart sich das Tippen beim Booten.

Ein

Code: Alles auswählen

lsmod | grep radeon
sollte jetzt übrigens keine Ergebnisse mehr liefern.

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
spuckt unter anderem Zeilen wie diese hier aus:

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]
Die Nummern 02:00:0 und 02:00:01 sind es, die uns interessieren. Als nächstes wollen wir noch die Gerätenummern wissen. Ein

Code: Alles auswählen

lspci -n
sagt zu diesen Nummern:

Code: Alles auswählen

02:00.0 0300: 1002:86e1
02:00.1 0403: 1002:aa86
Hier sind es die Zahlenblöcke 1002:86e1 und 1002:aa86, die wir brauchen.

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
Die oben gefundenen Zahlen sehen hier ein klein wenig anders aus, trotzdem solltet ihr die Zuordnung rauskriegen können.

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
Danach ein

Code: Alles auswählen

chmod u+x ~/grafikkarte-zuweisen.sh
und das Script lässt sich mit

Code: Alles auswählen

~/grafikkarte-zuweisen.sh
ausführen. Für erste Tests würde ich aber empfehlen, die Befehle zeilenweise zu kopieren, die Zahlen anzupassen und sie schrittweise auszuführen.

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
Man kann es auch automatisch starten lassen, sobald der virt-manager startet:

Code: Alles auswählen

virsh net-autostart default
Und so

Code: Alles auswählen

virsh net-autostart default --disable
macht man Letzteres wieder rückgängig.

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
sehen kann.

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.

8) 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.
Zuletzt geändert von NAB am 13.02.2013 14:01:39, insgesamt 1-mal geändert.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

syssi
Beiträge: 2951
Registriert: 24.12.2010 16:50:59
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Rheinland

Re: Windows 8 unter Wheezy mit eigener Grafikkarte

Beitrag von syssi » 13.02.2013 13:23:13

Wow. Hochkonzentrierte, detaillierte und gut destillierte Informationen. :-)

Benutzeravatar
Natureshadow
Beiträge: 2157
Registriert: 11.08.2007 22:45:28
Lizenz eigener Beiträge: MIT Lizenz
Wohnort: Radevormwald
Kontaktdaten:

Re: AW: Windows 8 unter Wheezy mit eigener Grafikkarte

Beitrag von Natureshadow » 13.02.2013 16:46:12


nowondeb
Beiträge: 81
Registriert: 17.11.2012 14:16:12

Re: Windows 8 unter Wheezy mit eigener Grafikkarte

Beitrag von nowondeb » 14.02.2013 02:14:40

Ja, bin dafür das der Artikel in die Wiki einfließt..... ich hatte mir Wochenlang die Karten gelegt wie ich vdr virtualisieren kann.... Mittlerweile geht das auch mit Passthrough für USB DVB Boxen ;)

Was mir auch sehr gefällt, ist, das Windows immer mehr dazu degradiert wird in einem Sandkasten zu laufen, nativ wollen das glaube ich immer weniger :lol:

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Windows 8 unter Wheezy mit eigener Grafikkarte

Beitrag von NAB » 14.02.2013 04:50:15

hmmm ... also falls das hier ne Abstimmung wird ...

Ja, ich hab auch nix dagegen, dass der Text ins Wiki kommt!

Ansonsten ... ich hab ein paar Wochen daran rumgepfickelt, bis es lief, mir dann den Sonntag um die Ohren gschlagen um meine nicht ganz konsistenten Notizen in einen konsistenten (deutschen) Text umzuwandeln, wissend dass es ein recht spezielles Unterfangen ist, unsicher, ob jetzt alles technisch korrekt und fehlerfrei formuliert ist und ob ich nicht hier und da einen hirnverbrannten Weg eingeschlagen habe, froh dass es online und über google auffindbar ist (auf Deutsch gibt's da nämlich echt wenig) und hoffungsvoll, dass es vielleicht den einen oder anderen gibt, der genau so komische Sachen versucht wie ich und ein wenig feedback bringt, und sei es nur ein "geht" oder "geht nicht". Insofern klingt ein "mach ma Wiki" in meinen Ohren gerade verdächtig nach "mach dir noch mehr Arbeit damit" ... ja ... vielleicht ... später ...sonst jemand?
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

nowondeb
Beiträge: 81
Registriert: 17.11.2012 14:16:12

Re: Windows 8 unter Wheezy mit eigener Grafikkarte

Beitrag von nowondeb » 14.02.2013 11:14:23

Hi NAB
du und ich sind kein Einzelfall, das Interesse besteht bei einigen und deine Abhandlung kann meiner Meinung nach so direkt als Wiki Artikel eingepflegt werden und dann reproduziert werden, ein wenig Fachwissen gehört zwar dazu, aber wir alle haben einen Mund um nötigenfalls Fragen zu stellen. Also mach dir keine grauen Haare wegen noch mehr Arbeit ;)
Es geht tatsächlich mit dem Passthrough...... ein wenig ge-confe noch und schwupp.....
In meinem Fall mit VDR und DVB Devices..... das Wirtssystem sollte NICHT über die Treiber für die dann genutzten DVB Geräte in VBox verfügen, ein VDR mit anderer Hardware und Treibern als in der VBox ist unproblematisch....

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Windows 8 unter Wheezy mit eigener Grafikkarte

Beitrag von NAB » 07.04.2013 22:51:32

So, mal ein kurzes Update von mir: Die ganze Sache läuft recht gut, ich kämpfe aber immer noch mit dem Sound.

Erst mal gibt es an meinem Text oben es natürlich einen kleinen Haken ... die HDMI-Soundkarte der Grafikkarte ist natürlich auch eine Soundkarte und wird natürlich nicht vom radeon-Treiber belegt, sondern von snd_hda_intel. Somit dürfte es eigentlich gar nicht klappen, die HDMI-Soundkarte an den Stub-Treiber zu übergeben, es klappt aber trotzdem. Drolliger Weise bekomme ich die durchgereichte Soundkarte trotzdem unter pulse-audio im Wirtssystem angezeigt - mir macht das keine Probleme, aber wer damit Probleme hat, weiß nun, wo er rumschrauben muss.

Ansonsten habe ich jetzt drei Monitore auf dem Tisch stehen, je zwei sind mit der Linux-Grafikkarte verbunden, und je zwei mit der Windows-Grafikkarte. Für einen vierten Monitor fehlt mir eindeutig der Platz.

Die Ausgabe des Windows-Sounds über den HDMI-Anschluss klappt ganz gut, aber irgendwie nervt das, die kleinen Boxen des Monitors sind ne Krankheit und es wäre schöner, den Sound über die Lautsprecher des Gastsystems ausgeben zu können.

Das oben erwähnte Problem mit dem Zufügen einer Soundkarte hatte gar nichts mit Pulse-Audio zu tun, sondern schlicht damit, dass der Benutzer "libvirt-qemu" in der Gruppe "audio" sein muss. Danach konnte ich beliebige Soundkarten zur Virtuellen Maschine hinzufügen und der Ärger ging weiter:

Keine der Soundkarten läuft unter Windows 8, mit der Ausnahme von "ich6", auch "hda" oder "High Definition Audio" genannt. Für alle anderen Karten findet Windows 8 keine Treiber. Nun gut, so probierte ich es mit "ich6".

Der Sound war gestört, leicht zerhackt, und irgendwie zu tief ... da stimmte was nicht.

Ich hatte natürlich gleich wieder Pulse-Audio in Verdacht und stellte fest, dass der Virt-Manager Pulse-Audio gar nicht nutzt, sondern die virtuelle Alsa-Schnittstelle, die Pulse-Audio zur Verfügung stellt. Die Lösung dazu fand ich auch schnell, nämlich

Code: Alles auswählen

export QEMU_AUDIO_DRV=pa
, ich fand nur keinen Weg, diese Lösung unter dem Virt-Manager zum Laufen zu bringen. Es gibt wohl keine Möglichkeit, kvm per Kommandozeilenoption zu sagen, welches Soundsystem es nehmen soll, sondern lediglich per Umgebungsvariable. Und da der Virt-Manager als "libvirt-qemu" läuft, und dieser Benutzer keine konfigurierbare Shellumgebung besitzt und auch nie einen Login-Prozess durchläuft, ist es schwer, ihm Umgebungsvariablen unterzuschieben.

Aber gut, ich hab's erst mal auf der Kommandozeile getestet und kvm direkt gestartet ... dann wurde mir auch kvm als "Tonquelle" unter Pulse-Audio angezeigt, ich hab ein wenig an den Reglern rumgespielt ... und nichts wurde besser. Sämtliche anderen "Tonquellen" funktionierten einwandfrei, somit vermutete ich, dass der Fehler doch eher bei kvm lag und suchte weiter nach einer Ursache.

Dabei stieß ich auf diesen frustrierenden Mailinglisten-Beitrag:
http://osdir.com/ml/qemu-devel/2012-09/msg00974.html

Das Problem scheint alle 64-Bit Windowse zu betreffen ... der 64-Bit-Treiber für HDA/ich6 hat zu kleine Buffer und darum lässt sich der Sound nicht störungsfrei durch kvm weiterleiten.

Hat hier irgendjemand Erfahrung und Erfolg mit Win7/8 64-Bit unter kvm mit virtueller Soundkarte? Gibt's andere Wege/Tricks?

Die einzige Lösung scheint mir zu sein, mir eine billige USB-Soundkarte zu besorgen und ein Kabel vom Ausgang der USB-Soundkarte zum Line-In der Linux-Soundkarte. Schön ist das nicht ...

P.S.: herrlich, hier hat jemand genau dasselbe unter Ubuntu gemacht, und einen tollen Text hingelegt. Die Ähnlichkeiten sind groß:
http://thinkpad-forum.de/threads/153930 ... hleunigung
Aber der hat seine Onboard-Soundkarte gleich komplett an Windows weitergereicht, das will ich ja auch nicht ...
P.P.S.: So, inzwischen hab ich mir eine tolle 4,95 Eur USB Soundkarte besorgt und ein Klinken-Kabel in einer Kiste gefunden, und das Kabel in den Line-In-Eingang meiner Onboard-Soundkarte gesteckt, und die USB-Soundkarte per Virt-Manager an das Windows 8 weitergereicht ... und nach ca. 4 Stunden planlosem Umherklicken läuft es jetzt fein.

Eigentlich lief alles auf Anhieb, ich hab es nur nicht geschafft, der Soundkarte zu erklären, dass ich das Signal von Line-In gleich wieder über Line-Out ausgegeben haben möchte. Ich dachte ja mal wieder, man kann die Sache über Pulse-Audio konfigurieren, und lag damit völlig falsch. Man braucht den guten alten "alsamixer", muss die Soundkarte wechseln (weg von PulseAudio hin zur richtigen Soundkarte) und nachdem ich dann spitzgekriegt hatte, dass ich das hintere Mikrofon freischalten musste, um über Line-In was zu hören (wtf?), läuft die Sache jetzt auch.

Ich hatte ja eine gewisse Zeitverzögerung des Tons erwartet, aber davon merke ich nichts (Bio-Test mit Augen und Ohren).

Der Ton scheint irgendwie an PulseAudio vorbeizulaufen ... zumindest kann ich ihn mit dem Pulse-Audio-Mixer nicht steuern.
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

NAB
Beiträge: 5501
Registriert: 06.03.2011 16:02:23
Lizenz eigener Beiträge: MIT Lizenz

Re: Windows 8 unter Wheezy mit eigener Grafikkarte

Beitrag von NAB » 23.04.2013 18:10:53

So, Zeit für ein paar Ergänzungen, bevor ich die Details vergesse ... vielleicht wird hieraus doch noch mal ein Wiki-Eintrag ^^
1) Die Virtio-Treiber
Ich hab mich da endlich mal rangetraut, vorallem um meiner virtuellen Netzwerkkarte Beine zu machen.
Die Treiber haben seit Version 0.1-52 vom Januar keine Aktualisierung mehr erhalten, ich habe aber auch keine Klagen darüber gefunden, sie schienen also einigermaßen stabil zu sein.
Treiber für Windows 8 müssen signiert sein, das macht Red Hat, und bekommen tut man sie als ISO von fedora:
http://alt.fedoraproject.org/pub/alt/vi ... mages/bin/
Das ISO lädt man sich am besten gleich unter Windows 8 runter, das geht am einfachsten.
Danach kann man im Virt-Manager seine virtuelle Netzwerkkarte auf das "Device Model: virtio" umstellen, die MAC bleibt dabei erhalten. Dann muss man Windows neu starten, und kann unter Win8 das ISO mit einem Rechtsklick per "Bereitstellen" mounten. Dann lässt man Windows auf der neuen virtuellen CD nach Treibern für die unbekannten Geräte suchen und kriegt dann einen neuen "Rad Hat VirtIO Ethernet Adapter". Bei der Gelegenheit findet man auch heraus, dass das oben erwähnte unbekannte PCI-Gerät zum "VirtIO Balloon Driver" gehört ... der soll eigentlich für dynamisch zugewiesenen Hauptspeicher sorgen. Ich hab davon bisher nichts gemerkt. Aber die Netzwerkkarte ist danach erfreulich fix.

Nicht ganz so einfach läuft das Umstellen vorhandener virtueller Festplatten auf "virtio". Dazu muss man im Virt-Manager erst eine neue (kleine) Festplatte zurechtklicken, mit dem "Device Type: virtio". Wenn man dann Windows neu startet, sieht es ein unbekanntes Gerät, dann lässt man es wieder nach Treibern suchen, und schwupp taucht die neue Festplatte auf. Danach kann man Windows auch gleich wieder herunterfahren, im Virt-Manager die neue Festplatte wieder entfernen, und sein altes vorhandenes Festplatten-Image auf "virtio" umstellen.

Ob das viel bringt, kann ich nicht sagen ... mein Festplatten-Leistungsindex unter Windows ist von vorher 7,8 ohne Virtio auf jetzt 8,0 mit Virtio gestiegen. Aber dieser Test sagt wenig aus, und die CPU-Belastung des Host-Systems beim Festplattenzugriff hab ich nicht verglichen.

Fazit: Es funktioniert!

2) USB-Geräte durchreichen
Das schien auf den ersten Blick wunderbar zu klappen mit der USB-Soundkarte. Danach habe ich es mit einer WebCam versucht ... und nix ging. Also ... es ging, ich konnte sie im Virt-Manager auswählen, der virtuellen Maschine hinzufügen, keine Fehlermeldungen, nur Windows sah von dem Gerät absolut nichts. Nach etwas Rumgesuche fand ich dann Fehlermeldungen unter /var/log/libvirt/qemu und dann auch schnell die einfache Lösung:
Der virtuelle USB-Controller im Virt-Manager "Controller USB" läuft in der Einstellung "default" nur als USB1.1-Controller. Erst in der Einstellung "USB2" wird daraus ein USB2-Controller. Das Umschalten läuft völlig problemlos.
Die WebCam ist ein USB2-Gerät, die Soundkarte anscheinend ein USB1.1 Gerät.
Nun funktioniert alles wunderbar, sogar die WebCam ohne FrameDrops.
Mir scheint allerdings inzwischen ein eigener PCIe-USB-Controller für Windows eine sinnvolle Investition zu sein.

3) Der UVC-Bug
Direkt danach stolperte ich dann in diesen Bug:
https://bugs.launchpad.net/ubuntu/+sour ... bug/811604
Merkwürdigste Fehlermeldungen, nix ging mehr ... die Festplatte war voll.
Die Datei /var/log/uvcdynctrl-udev.log hatte satte 80GB erreicht.
Das löschen der Datei reichte nicht, es musste auch "uvcdynctrl" gekillt werden.
Um zu verhindern, dass das wiederauftritt, muss in der Datei /lib/udev/uvcdynctrl das "debug=1" von "1" auf "0" gesetzt werden.
Das Problem tritt wohl nur auf, wenn man "uvcdynctrl" installiert hat, was auf der Recommends-Liste von "guvcview" steht _und_ eine WebCam per kvm durchreicht. Dumm gelaufen ...
Edit: Auch mit "debug=0" gibt es Probleme - "uvcdynctrl" sorgt für volle Auslastung einer oder mehrerer CPUs in mehreren Instanzen. Ein "killall uvcdynctrl" hilft vorübergehend, irgendwann startet es sich aber neu. Da ich eh nicht so genau weiß, wofür ich das brauche, werde ich es mal deinstallieren.


4) Echte Festplatten durchreichen
Tja, das funktioniert! Bisher problemlos.
Im Virt-Manager lassen die sich mit "Add Hardware"->"Storage" leicht hinzufügen. Als Pfad gibt man "/dev/sdX" an, beim "Device Type" nehme ich inzwischen "virtio" und das "Storage Format" kann man sicherheitshalber auf "raw" stellen.

Hierzu dürfen die Festplatten natürlich nicht unter Linux gemounted sein.

Im Netz las ich eine Warnung über zerschosssene Partitionstabellen, wenn man nur einzelne Partitionen durchreicht, daraufhin habe ich das gar nicht erst getestet, sondern gleich meine gesamte Windows-Festplatte durchgereicht. Die Warnung nehme ich zwar nicht sonderlich ernst, aber ich hatte keine Lust auf Experimente.

"Dynamische Datenträger" werden unter Win8 erst mal als "fremd" markiert und nicht angezeigt. Das lässt sich mit der Datenträgerverwaltung ändern.

Aber Achtung!
Die Reihenfolge, in der Virt-Manager die Festplatten hinzufügt, ist etwas willkürlich. Wer eine bootbare Festplatte hinzufügt, muss damit rechnen, dass die virtuelle Maschine davon bootet. Ein reales Windows auf der realen Festplatte entdeckt daraufhin völlig fremde Hardware und das kann einen ja bekanntlich in Teufels Küche bringen und üblen Verdächtigungen aussetzen. Eine einfache Lösung für das Problem habe ich nicht gefunden.

5) Samba
Das funktioniert recht anstandslos, und seit dem Virtio-Netzwerk-Treiber auch schön schnell, zumindest was den Aspekt der Virtualisierung angeht. Einziger Schönheitsfehler ist, dass der Virt-Manager die virtuellen Maschinen in ein eigenes Subnetz packt und man die Freigaben außerhalb dieses Subnetzes über ihre IP-Adresse ansprechen muss. Um das komfortabler zu gestalten, muss ich noch mal im Windows LAN Manager rumgraben und an der Konfiguration von Samba schrauben.

Ansonsten klappen Zugriffe _von_ Windows aus problemlos. Bei Zugriffen _auf_ Windows hat man die üblichen Windows-Probleme. Erstens sollte Windows unbedingt der Meinung sein, dass man sich in einem privaten Netzwerk befindet und zweitens sollte man das Heimnetzwerk ausschalten, wenn man Zugriffsrechte einigermaßen kontrollieren oder auch prüfen will.

Zum Debugging von Netzwerkproblemen hilft es natürlich ungemein, wenn Windows wieder auf Ping antwortet:
http://www.howtogeek.com/77132/how-to-e ... windows-8/

Welches Subnetz der Virt-Manager benutzt, steht übrigens in der Datei /var/lib/libvirt/network/default.xml und lässt sich mit dem Befehl

Code: Alles auswählen

virsh net-edit default
ändern.

6) Was noch fehlt:
Ich bin bisher ausgesprochen zufrieden mit dieser Lösung. Ich kann mir kaum noch Gründe vorstellen, mein Dual-Boot-System zu nutzen und Windows auf der echten Hardware zu booten. Wichtigste Gründe sind hier wohl irgendwelche Firmware-Updates, die nur unter Windows laufen, oder andere hardware-nahe Programme.

Das i-Tüpfelchen wäre jetzt noch eine Methode, das Clipboard zwischen Windows und Linux zu teilen. Die üblichen Lösungen für VNC und RDP scheinen da nicht zu taugen, die setzen auch gleich einen virtuellen Bildschirm voraus. Spice läuft unter Win8 immer noch nicht und scheint dasselbe Problem zu haben. Mit Synergy müsste sich das hinpfrickeln lassen:
http://synergy-foss.org/de/
Ich befürchte nur Probleme mit der virtuellen Maus/Tastatur.
Falls da jemand eine bessere Lösung weiß, nur her damit!

Und was mir immer noch fehlt, ist eine elegante Methode für das Suspend. Das hapert schon daran, dass sich das virtuelle Windows nicht in ein Suspend-to-Disk schicken lässt ... die virtuelle Maschine fährt nicht ganz runter, und wenn man sie dann gewaltsam ausschaltet und neu bootet, meckert Windows, dass es abgestürzt sei.

Nun gut ... das ist die nächste Baustelle ...
Never change a broken system. It could be worse afterwards.

"No computer system can be absolutely secure." Intel Document Number: 336983-001

Antworten