Tutorial: Fedora 23, libvirt ,KVM, GPU passthrough, win8.1 and GTX780, copy and paste

Hubs sind problematisch.
Das mit dem Port durchreichen funktioniert mit libvirt nicht so recht (und irgendwann ist dann auch das Problem, wie man die wenigen USB2-Ports des virtuellen Chipsatzes nutzt, da), sollte aber in der Tat mit qemu gehen (theoretisch kann man auch einen der meist zwei USB-Controller des PCH reinreichen, nachdem man die gewünschten physischen Ports konfiguriert hat – recht aufwendig, aber falls es dich interessiert, gab es da vor kurzem auf der vfio-Liste einen Beitrag).
Ich kaufte, nachdem ich ein ähnliches XML-Snippet ausprobiert hatte (das aber m.M. nach nur einen neuen Port am virtuellen USB-Chipset anlegt und nichts zur Sache tut...), dann doch einfach eine USB3-Karte und steckte die in einen freien PCIe-Slot des PCH – 20€ und ich kann jedes USB-Gerät nutzen...
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
danke für deine Rückmeldung.

Hatte ich auch das Gefühl, dass der XML Snippet nicht das zu sein scheint, was ich möchte. Da mein Board nur 2 USB Controller hat habe ich mir jetzt für knapp 16 € einen USB 3.0 PCIe Controller gekauft und werde dieses komplett an die VM durchreichen. Damit sollte das dann alles klappen.

Grüße
KingGoggel
 
Wenn ich den Windows-Gast am laufen habe, kann ich irgendwie verhindern, dass der Wirt in den Standby gehen kann?
Nutze libvirt unter Arch.
 
Hab seit dem Wochenende auch Arch laufen und direkt Windows 10 in die VM geworfen.
Passthrough funktioniert super. Für den Fall der Fälle liegt eine angeschlossene DinovoEdge parat um den Host noch bedienen zu können.

Als grandioses Setting fürs Netzwerk hat sich der Umstand herausgestellt, dass ich eine Intel Pro Dual Port GBit Nic verbaut habe. Einen Port für den Host, und den zweiten Port, problemlos wie es sich für eine server nic gehört, an die vm durchgeführt. Erspart einem das lästige konfigurieren einer sonst nötigen bridge und kostet bei ebay unter 20€

In der nächsten Zeit folgt noch etwas Feintuning.
Endlich kein Dual Boot gefrickel mehr :-)
 
Könntest du die Einstellungen posten, mit denen das bei dir läuft? Welche GPUs hast du im System?
 
Welche Einstellungen interessieren Dich denn genau?

Ich habe die Intel GPU aus dem i7 fürs Arch Linux, und die GTX780ti komplett für die VM.
 
Die Startparameter für qemu/kvm wären gut zu wissen.
 
Ich kann Dir später das Startscript usw hier posten.

Gern auch die Vorgehensweise in Kurzform. Anleitung dazu gibts ja schon :-)
 
Ich kann Dir später das Startscript usw hier posten.

Gern auch die Vorgehensweise in Kurzform. Anleitung dazu gibts ja schon :-)
Posten ist immer gut ... zu viel Posten gibts nie :)

Gesendet von meinem Elephone P8000 mit Tapatalk
 
Mein Setup:

mrcs aus der Sig ( sowohl board als auch cpu unterstützen VT-d, was zwingend erforderlich ist )
Von der iGPU 1 x HDMI 1 x DVI zu Desplay 1 & Display 2
Von Der GTX 1 x Displayport zu Display 2

Lezteres habe ich aber erst angeschlossen als ich soweit war die VM das erste Mal zu starten.
Vorher kann das ggf zu Verwirrung führen ;-) Zumindest bei mir.
Eingabegeräte sind eine öde DELL USB Tastatur, eine Func MS3 R2 und als Backup fürs Arch eine Logitech Dinovo Edge

Also ich habe mich in den Grundzügen recht genau an diese Anleitung hier gehalten:

GPU Passthrough Guide

Dies habe ich in einem frischen, händisch Installierten Arch umgesetzt. Ich gehe hier die einzelnen Punkte aus
der Installation noch mal durch und schreibe, was bei mir "anders" war ;-)

Setup and Installation

Meine erste Arch-Installation auf diesem System habe ich ( aus mir gerade nicht verständlichen gründen ) mit isolinux als bootloader durchgeführt.
Da ich keine Ahnung habe wie ich dort "intel_iommu=on” als Parameter übergebe um VT-d zu aktivieren, und der Wechsel zu Grub nicht sofort geklappt hat, habe ich
noch mal neu angefangen.

Das war nicht schlimm, da das System jungfräulich, also eh gerade frisch installiert war. Außerdem verinnerliche ich durch Wiederholung wichtige Dinge einfach besser ;-)

Mit Grub2 als Bootloader ( damit kenne ich mich ja aus ) hat es dann wunderbar funktioniert.

pci-e bus meiner GTX 0000:01:00.0 & 0000:01:00.1

look in /sys/bus/pci/devices/YOUR_BUS/iommu_group/devices/. If you do not have an iommu_group folder then vt-d was not enabled properly!

iommu group vorhanden = vt-d aktiv .. also weiter im Guide

Fixing IOMMU Grouping
War für mich nicht relevant.

Skip if using Nouveau
Da ich ein frisches System händisch installiert habe, gab es bei mir noch keinerlei Treiber für die GTX außer den Kernelinternen Nouveau. Also SKIP

Setup Continued
Den Kernelinternen Nvidia Treiber "Nouveau" muss man leider blacklisten, sonst kommt man einfach nicht weiter. Amd User sind hier klar im Vorteil :-)

/etc/modprobe.d/blacklist.conf :

blacklist nouveau
blacklist lbm-nouveau
options nouveau modeset=0
alias nouveau off
alias lbm-nouveau off

Modul "pci-stub" als dummymodul wird dann hinzugefügtund es folgt ein rebuild

linux-vfio users run this
Der Punkt in der Anleitung hat dann für viel Verwirrung gesorgt, es war aber auch schon sehr spät ;-)
Natürlich nutze ja auch ich vfio aber eben NICHT den vfio gepatchten Kernel vom Anfang, da ich das ja einfach nicht machen muss.

Now we edit grub once again ....
Dort ging es dann weiter. Man muss dem Dummy Modul PCI-Stub schon durch den Bootloader Grub die device IDs der Grafikkarte zuweisen, dann haben nämlich die fiesen Nouveau Kernelmodule keine Chance mehr
die GTX für sich zu beanspruchen.

Nach einem Grub Update und Reboot ist folgendes erstrebenswert:

Console
“lspci -nnk”

Für die Grafikkarte sollte dann stehen
Kernel driver in use: pci-stub ( und nicht mehr nouveau)

Setup KVM/QEMU
Ohne Änderungen weiter bis:

sudo vfio-bind 0000:0#:00.0 0000:0#:00.1

Hiermit wird definiert, welche Geräte man mit in die VM nehmen möchte. In der Anleitung wird erst mal nur die Grafikkarte gewählt. Für einen ersten Test ist das OK, wird aber später eh angepasst.

Bei mir sieht es derzeit so aus: vfio-bind 0000:01:00.0(<- GTX780ti ohne HDMI Sound) 0000:03:00.0(<- Zweiter Port der Intel Pro DualPort NIC) 0000:00:1b.0(<- OnboardSound Usb geräte werden anders gehandhabt

Wenn man das vfio-bind ausgeführt hat und "lspci -nnk" folgendes ausgibt "Kernel driver in use: vfio-pci" ist alles bestens.


Die relevanten Pfade im Startscript aus der Anleitung sind natürlich anzupassen, das Script reicht aber für einen ersten Test ebenfalls aus.
Den späteren Punkt mit xrandr habe ich bisher noch nicht getestet, da ich es derzeit als unproblematisch ansehe nach dem Starten der VM zweimal auf die "Source" Taste am entsprechenden Monitor zu drücken.

Mein Startscript sieht derzeit so aus:

Code:
  GNU nano 2.5.3                                                     Datei: /usr/bin/kvmstart                                                                                                                  

#!/bin/bash

vfio-bind 0000:01:00.0 0000:03:00.0 0000:00:1b.0 <-- [COLOR="#FF0000"]den vfio-bind befehl habe ich erst mal in mein vm-start-script itegriert, da es mir dort sinnig erschien.[/COLOR]

cp /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd /tmp/my_vars.fd
qemu-system-x86_64 \
-enable-kvm \
-m 16384 \ <-- [COLOR="#FF0000"]16 von 32GiB Ram der VM zugewiesen. Arch mit XFCE Chromium und 10 offenen Tabs belegt gerade 1.2Gib Ram, da würde also noch was gehen ;-)[/COLOR]
-smp cores=4,threads=2 \ [COLOR="#FF0000"]<-- CPU Kerne und Threads angepasst[/COLOR]
-cpu host,kvm=off \ <-- [COLOR="#FF0000"]afaik ist es derzeit zwingend nötig bei nvidia Karten kvm=off zu setzen da der treiber unter windows sonst seinen dienst verweigert. [/COLOR]Blame Nvidia for the GTX / Quadro bullshit
-vga none \
-usb -usbdevice host:413c:2113 \ <-- [COLOR="#FF0000"]Maus oder Tastatur[/COLOR]
-usb -usbdevice host:040b:0a68 \ <-- [COLOR="#FF0000"]Maus oder Tastatur[/COLOR]
-device vfio-pci,host=01:00.0,multifunction=on \ <--[COLOR="#FF0000"]vga[/COLOR]
-device vfio-pci,host=00:1b.0 \ <-- [COLOR="#FF0000"]sound [/COLOR]
-device vfio-pci,host=03:00.0 \ <-- [COLOR="#FF0000"]netzwerk[/COLOR]
-drive if=pflash,format=raw,readonly,file=/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd \
-drive if=pflash,format=raw,file=/tmp/my_vars.fd \
-device virtio-scsi-pci,id=scsi \
-drive file=/home/mrcs/win.img,id=disk,format=qcow2,if=none,cache=writeback -device scsi-hd,drive=disk \ <-- [COLOR="#FF0000"]Win10 System HDD[/COLOR]
-drive file=/home/mrcs/win2.img,id=disk2,format=qcow2,if=none,cache=writeback -device scsi-hd,drive=disk2 \ <-- [COLOR="#FF0000"]Win10 Games HDD[/COLOR]

Die Pfade für das Windows 10.iso und die Treiber.iso habe ich hier schon wieder entfernt, sowie diverse Anpassungen für mich gemacht.
So läuft es bei mir schon nahezu perfekt spielbar!
 
Super, danke! Muss mich in den nächsten Wochen auch mal dran setzen.
 
Weiß zufällig jemand, wie man mit Windows programmatisch für ein Gerät (bei mir den QXL-Adapter) einen Disable/Enable-Zyklus, wie er im Gerätemanager möglich ist, durchführen kann? Mein Problem: das QXL-Display, das für Skype am Linux-Desktop (und als Zweitbildschirm bei Windows-Nutzung) nebenher noch offen ist, hängt sich manchmal auf (Bild friert ein), die Tastatur fkt. aber noch (war im Skype-Gespräch und konnte noch die Stummschaltung schalten), d.h. man könnte das ganze in ein AHK(leichtgewichtigere Alternativen)/PS/BAT-Skript packen und einfach den Screen neustarten :).
 
Wo genau liegen denn nun eigentlich die Vorteile von "libvirt" im Vergleich zum "normalen" kvm?
 
Sorry, da hab ich mich wohl maximal missverständlich ausgedrückt :-) Unterschiede sind mir bewusst, allerdings verstehe ich den Nutzen von libvirt in Verbindung mit Qemu+Kvm nicht.
Das läuft ja auch ohne, also wo sind da die Vorteile, wenn man noch libvirt mit benutzt.
 
Sehe ich das richtig, dass GPU passthrough ausschließlich mit einer eigenen GPU für Windows funktioniert? Wäre nämlich suboptimal, da mein i5-2550k nun keine iGPU hat.
 
Sorry, da hab ich mich wohl maximal missverständlich ausgedrückt :-) Unterschiede sind mir bewusst, allerdings verstehe ich den Nutzen von libvirt in Verbindung mit Qemu+Kvm nicht.
Das läuft ja auch ohne, also wo sind da die Vorteile, wenn man noch libvirt mit benutzt.

https://libvirt.org/ ... alles beschrieben ^^

- - - Updated - - -

Sehe ich das richtig, dass GPU passthrough ausschließlich mit einer eigenen GPU für Windows funktioniert? Wäre nämlich suboptimal, da mein i5-2550k nun keine iGPU hat.

ja, derzeit noch, es sei denn du kaufst dir ne NVidia Grid oder ähnliches - oder steckst 2 Grafikkarten (fürs Linux os reicht das günstigste dann) rein

VGpus sind zwar schon möglich, aber für den 0185 "User" nicht sinnvoll
 
Zuletzt bearbeitet:
Sorry, da hab ich mich wohl maximal missverständlich ausgedrückt :-) Unterschiede sind mir bewusst, allerdings verstehe ich den Nutzen von libvirt in Verbindung mit Qemu+Kvm nicht.
Das läuft ja auch ohne, also wo sind da die Vorteile, wenn man noch libvirt mit benutzt.

libvirt ist halt ein Managementstack für diverse Virtualisierungslösungen, im vorliegenden Fall ist dabei praktisch, dass man halt eine GUI hat, die Spice-Client und die Möglichkeit, halbwegs einfach Geräte on-the-fly einzubinden (ohne jedesmal lsusb/lspci und qemu-attach aufrufen zu müssen) vereint. Außerdem muss man nicht die ganze Zeit Optionen nachschauen ;) und wenn man abhängig vom Status der VM Sachen machen will, muss man sich nicht in seinem Qemu-Script explizit Gedanken machen, sondern nimmt einfach die fertigen Hooks.

@pumuckel/fallwrrk: auf absehbare Zeit wird das noch der Fall sein, die KVMGT-Patches haben es noch nicht wirklich weit geschafft (werden zwar im akt. Kernel erwähnt?) und sind dann erst mal auch nur für Intel. Inwiefern die VGPU für einen 0815-User, der einfach nur Word braucht, nicht sinnvoll ist, weiß ich auch nicht?
 
Zuletzt bearbeitet:
die Intelansätze hatte ich im 1. Post ja schon genannt

btw warte ich schon gespannt auf die AMD 480 .... bin dieses NVidia Geblödel leid bei virtualisierung :)

die trifft genau meinen Sweetspot in der P/L/Verbrauch und endlich HDMI 2.0 (verwende einen 4K TV als 2. Monitor) .... hoffentlich kastrieren die nicht :)
 
Zuletzt bearbeitet:
Hallo zusammen,

nachdem meine VM jetzt ziemlich gut lief, habe ich nun doch ein erhebliches Problem.

Vorgeschichte:
Hatte meine Antergos Distri aufgesetzt und habe mich nach dem Tutorial hier gehalten um die VM aufzubauen. Hat wie gesagt alles bestens geklappt... nun wollte ich aber gestern meine VM von WIndows 7 auf Windows 10 hochziehen und habe mein LVM gelöscht und neu aufgesetzt. Seit dem habe ich das Problem das die Farben innerhalb der VM falsch angezeigt (siehe hier) werden. Ich habe wirklich nichts geändert an der Config oder so... ziemlich komisch.

Daraufhin dachte ich (noch von Windows geschädigt), setze ich mal mein Antergos neu auf. Möglicherweise biegt sich das dann wieder zurecht. Leider nicht... Hatte sowohl den Kernel linux-vfio wie auch linux-vfio-lts ausprobiert.

Hat jmd. eine Idee? Wäre über jeden Hinweis froh...

Btw... Graka hat keinen knacks weg. Das habe ich schon getestet

Schicke mal im Folgenden meine Config mit ...

gamingvm
01bd2ed1-b465-4eba-b6e4-47c6ac8171c6
16
16
6












hvm
/usr/share/qemu/bios.bin













destroy
restart
destroy

/usr/bin/qemu-system-x86_64
 
Zuletzt bearbeitet:
Sehr spannendes Thema. Wollte eigentlich bis Zen warten mit neuer Hardware, aber das könnte mich glatt dazu animieren, nochmal Geld in die Hand zu nehmen und meine CPU zu tauschen (der i5-4670k kann kein VT-d -.-).
 
Hallo zusammen,

nachdem meine VM jetzt ziemlich gut lief, habe ich nun doch ein erhebliches Problem.

Vorgeschichte:
Hatte meine Antergos Distri aufgesetzt und habe mich nach dem Tutorial hier gehalten um die VM aufzubauen. Hat wie gesagt alles bestens geklappt... nun wollte ich aber gestern meine VM von WIndows 7 auf Windows 10 hochziehen und habe mein LVM gelöscht und neu aufgesetzt. Seit dem habe ich das Problem das die Farben innerhalb der VM falsch angezeigt (siehe hier) werden. Ich habe wirklich nichts geändert an der Config oder so... ziemlich komisch.

Daraufhin dachte ich (noch von Windows geschädigt), setze ich mal mein Antergos neu auf. Möglicherweise biegt sich das dann wieder zurecht. Leider nicht... Hatte sowohl den Kernel linux-vfio wie auch linux-vfio-lts ausprobiert.

Hat jmd. eine Idee? Wäre über jeden Hinweis froh...

Btw... Graka hat keinen knacks weg. Das habe ich schon getestet

Schicke mal im Folgenden meine Config mit ...

Habe den Fehler gefunden. Anscheinend hängt es mit der Qemu Version 2.6.0.1 zusammen. Nachdem ich mir 2.7.0 rc2 kompiliert habe und im Skript eingebunden habe, hat alles geklappt.

Grüße
:-)
 
Ja, ich kann das Phänomen bestätigen. Habe ein "nacktes" Arch am laufen und mit meiner Win10 VM ist alles Pink. :d Qemu 2.7 habe ich aber noch nicht getestet.
 
musste mittlerweile wieder zurück auf die Version 2.6.0.1, da mein Sound in der VM bei 2.7 nicht lief. Komischerweise läuft das installierte Windows 10 auch mit 2.6.0.1 wieder. Anscheinend funzt es mit 2.6.0.1 nicht, wenn du eine Neuinstallation machst. Dann bekommst du halt die hübschen Farben...

Kann mir das Verhalten zwar nicht erklären aber gut... :d
 
Hi,

hat jemand die Beta von Battlefield 1 gespielt?
Hänge bei mir mit einem i5-4460 scheinbar stark am CPU-Limit (meine R9-380 ist bei 100% und CPU zwischen 90-100%). Das Spiel läuft leider nicht komplett flüssig, zwar bekomme ich auch über 60 FPS, aber immer wieder Ruckler etc.
Habe bereits CPU-Pinning und Static Huge Pages (8 von 16GB RAM) eingerichtet. Glaube, dass hat etwas gebracht, aber zufrieden bin ich noch nicht.
Denke, das Spiel sollte mit meinem System auf einer normalen Windows-Installation wahrscheinlich einwandfrei laufen. Vielleicht weiß einer hier noch, was man für noch mehr (CPU-) Leistung versuchen kann?


Grüße
 
Ich habe nen alten Dualcore von AMD, mit OnBoard NVidia und eingestecker 5770 von Club3D, fände das hier damit sehr interessant zwecks nem ollen WIndows XP für Retrogaming :-)

Wär das mit sowas drin ? oder fehlt da was CPU-seitig für die VM mit Hardwaregrafikzugriff ?


Gruss Dennis
 
Die CPU muss AMD-Vi (früher nur IOMMU genannt) können.
 
Ich bastel mir gerade ein System zusammen und hätte da einigen Fragen passend zur Thematik:

  1. Sollte man gleich auf Server Hardware gehen oder reicht ein "einfaches" Consumer Board wie das ASRock z127 Pro4s?
  2. Ist eine CPU mit Hyperthreading sinnvoll? Bin noch am überlegen ob ich mir das Geld für den i7 sparen kann und dann einen i5 hole.
  3. Würdet ihr dafür eine Nvidia Karte kaufen? Ich weiß, dass man den Virtualisierungscheck umgehen kann, aber kann NVIDIA uns da nicht aus einer Laune heraus von jetzt auf gleich die Karte deaktivieren durch ein Treiberupdate?
  4. Wurde das durchreichen schonmal mit einer GTX 1070 gemacht? Überlege mir diese wegen der besseren Performance für 1440p zu holen. Für 1440p ist di rx480 doch etwas schwach.
 
3. Nein, würde ich nicht kaufen. NVidia unterbindet die Nutzung im Windows Gast. Warum würde man, wenn man das weiß, trotzdem viel Geld hinlegen und hoffen, dass man auch in Zukunft da irgendwie drum herum tricksen kann?

4. Demnächst soll die RX 490 rauskommen. Wird preis- und leistungsmäßig aber angeblich eher auf GTX 1080 Niveau liegen.
 
Hallo zusammen,

nachdem meine VM jetzt ziemlich gut lief, habe ich nun doch ein erhebliches Problem.

Vorgeschichte:
Hatte meine Antergos Distri aufgesetzt und habe mich nach dem Tutorial hier gehalten um die VM aufzubauen. Hat wie gesagt alles bestens geklappt... nun wollte ich aber gestern meine VM von WIndows 7 auf Windows 10 hochziehen und habe mein LVM gelöscht und neu aufgesetzt. Seit dem habe ich das Problem das die Farben innerhalb der VM falsch angezeigt (siehe hier) werden. Ich habe wirklich nichts geändert an der Config oder so... ziemlich komisch.

Daraufhin dachte ich (noch von Windows geschädigt), setze ich mal mein Antergos neu auf. Möglicherweise biegt sich das dann wieder zurecht. Leider nicht... Hatte sowohl den Kernel linux-vfio wie auch linux-vfio-lts ausprobiert.

Hat jmd. eine Idee? Wäre über jeden Hinweis froh...

Btw... Graka hat keinen knacks weg. Das habe ich schon getestet

Schicke mal im Folgenden meine Config mit ...

gamingvm
01bd2ed1-b465-4eba-b6e4-47c6ac8171c6
16
16
6












hvm
/usr/share/qemu/bios.bin













destroy
restart
destroy

/usr/bin/qemu-system-x86_64

seit heute ist libvirt 3.0.0.1 in der Paketverwaltung von Arch verfügbar. Bekomme hierfür beim Start meiner VM nur noch folgenden Fehler.

"Fehler: Domain gamingvm konnte nicht gestartet werden
Fehler: Ein Fehler ist aufgetreten, aber die Ursache ist unbekannt"

Laut meinen Logs unter /var/log/libvirt/gamingvm.log sehe ich dort folgendes.

"2017-01-24 09:29:37.871+0000: starting up libvirt version: 3.0.0, qemu version: 2.8.0, hostname: gerrit-linux
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/bin/qemu-system-x86_64 -name guest=gamingvm,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-gamingvm/master-key.aes -machine pc-q35-2.7,accel=kvm,usb=off,dump-guest-core=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff -bios /usr/share/qemu/bios.bin -m 15259 -realtime mlock=off -smp 6,sockets=1,cores=3,threads=2 -uuid 01bd2ed1-b465-4eba-b6e4-47c6ac8171c6 -display none -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-2-gamingvm/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot menu=on,strict=on -device i82801b11-bridge,id=pci.1,bus=pcie.0,addr=0x1e -device pci-bridge,chassis_nr=2,id=pci.2,bus=pci.1,addr=0x0 -device piix3-usb-uhci,id=usb,bus=pci.2,addr=0x2 -device piix3-usb-uhci,id=usb1,bus=pci.2,addr=0x3 -device piix3-usb-uhci,id=usb2,bus=pci.2,addr=0x4 -device piix3-usb-uhci,id=usb3,bus=pci.2,addr=0x5 -device ahci,id=sata1,bus=pci.2,addr=0x6 -drive file=/dev/vgroup/vm,format=raw,if=none,id=drive-sata1-0-0,cache=none,discard=unmap -device ide-hd,bus=sata1.0,drive=drive-sata1-0-0,id=sata1-0-0,bootindex=1 -drive file=/home/gerrit/Win10_1607_German_x64.iso,format=raw,if=none,media=cdrom,id=drive-sata0-0-0,readonly=on -device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0 -netdev tap,fd=24,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:a0:41:92,bus=pci.2,addr=0x1,rombar=0 -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=2,chassis=1,id=root.1 -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on -device vfio-pci,host=01:00.1,bus=root.1,addr=00.1 -device vfio-pci,host=02:00.0,bus=pcie.0 -cpu host -msg timestamp=on
Domain id=2 is tainted: high-privileges
Domain id=2 is tainted: custom-argv
Domain id=2 is tainted: host-cpu
libvirt: Fehler : libvirtd während Übergabe beendet: Eingabe-/Ausgabefehler
2017-01-24 09:29:37.916+0000: shutting down, reason=failed"

Hat jemand ein ähnliches Verhalten bzw. weiß ein Lösung?
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh