Reprise du message précédent :
Ah bah niquel, perso ça me va
P'tet plus large en parlant de VT-d ? J'sais pas
 
XaT

 
Je confirme sous Ubuntu 14.04 :

 
Sous Debian, avec le kernel experimental :

 
Pour rappel, cette option est indispensable pour faire du primary passthrough (option x-vga=on), nécessaire pour certaines cartes graphiques dans une VM Windows (ma Radeon 7850 par exemple, et les cartes Nvidia à priori). A noter que cette option pose quelques problèmes avec les chipset Intel, certains patchs supplémentaires peuvent être nécessaires pour le kernel (vga arbiter, acs override). Et elle n'est pas encore native sous libvirtd, il faut bidouiller le fichier de conf xml.

arg

Pour info, sur elementaryOS 0.2 luna (31/03/14)
http://sourceforge.net/projects/el [...] o/download
ATTENTION !
Ce n'est pas vraiment une version stable, mais plutôt une version intégrant un kernel plus récent que la 0.2 d'origine.
 

 
eOS luna, c'est basé sur une ubuntu 12.04

Voilà petit compte rendu sur Ubuntu 14.04 d'origine
voici ce que j'ai fais:

ajouter

    A LA FIN DU FICHIER

GRUB_CMDLINE_LINUX_DEFAULT="iommu=1 intel_iommu=on quiet splash"

Ajout dans virt-manager des périphériques 01:00.0 et 01:00.1 pour la VM Windows
Lancement de la VM Windows
installation des drivers Catalyst
La carte graphique est bien visible, les drivers sont installé, bref ça fonctionne
maintenant il faut que je trouve un peu de temps pour tester ça avec Steam/Origin

Si vous avez des retours de vos expériences, n'hésitez pas à nous en faire part

Voilà une excellente nouvelle !
Si tu es passé par virt-manager, c'est que tu fais du secondary passthrough (tu as sans doute une carte virtuelle cirrus en plus de la Radeon). Si ça fonctionne comme ça, c'est parfait, c'est beaucoup plus simple. Avec Windows, ça fonctionne chez moi également avec une Radeon 6850, mais pas avec la Radeon 7850   .
Juste une remarque sur ta configuration grub :
GRUB_CMDLINE_LINUX_DEFAULT="iommu=1 intel_iommu=on quiet splash"
Je ne pense pas que tu ais besoin du iommu=1.
 
Les tests que je te conseille de faire :
- lancer un jeu, tu devrais avoir des performances similaires à du natif.
- essayer de rebooter la VM. C'est l'un des avantages avec VFIO, avant ça ne fonctionnait pas bien et ça faisait planter l'hôte.

La mauvaise nouvelle c'est que le reboot dans la VM me fait planter entièrement mon système, ce que tu disais au dessus, mon hôte plante
Mais l'arrêt et le redémarrage de la VM, pas de soucis !
Je vais quand même tester la VM sur une installation "propre", c'est une VM que j'avais pas mal bidouiller
Effectivement j'ai bien une carte virtuelle cirrus en plus de la Radeon, rien de génant mais si je ne sais pas comment m'en débarrasser dans la GUI de virt-manager.

Peut-être que mon iommu=1 est redondant avec mon intel_iommu=on
mais bon ce n'est pas bien grave j'espère.
Je suis content, les performances sont là dans les jeux !

Je vais tester sur une VM Windows7, ma VM de test est un Windows 8.1 Pro
PS: ma carte AMD est une Sapphire HD7950 oc Vapor-X

C'est surement tout bête mais j'ai un soucis avec le son
Vous prenez quoi comme matériel pour le son dans Qemu ?

D'après ce que j'avais lu il y a qq temps quand j'avais fait mes VM (voir config), en passant par virt-manager on utilise pci-stub et donc la carte graphique cirrus ne peut pas être supprimé.
 
Tu peux vérifier si c'est pci-stub ou vfio qui est utilisé pour ta Radeon. Avec pci-stub je n'ai jamais vu quelqu'un proposer une méthode fiable pour le reboot (bien que l'extinction et le redémarrage puisse fonctionner).
 
Est-il possible de créer la VM à la main pour utiliser vfio puis de l'importer dans virt-manager? Comme je n'arrivais pas à utiliser vfio quand j'ai fait mes VM je ne me suis pas penché sur le problème, mais ça pourrait être une option à vérifier

 
Dans virt-manager aucune carte son, la radeon s'en occupe très bien sous Windows à partir du moment ou on passe bien à la VM les 2 périphériques concernés.

mon lspci -k

Effectivement le cirrus ne peut pas être supprimé mais depuis que je suis reparti sur une VM "propre", je ne vois plus la cirrus dans windows
Ma carte AMD est bien l'écran principal et je n'ai eu aucune modification à faire, juste installer les drivers
Merci Arcord, mais pour la carte son, avec la radeon, ça fonctionnerai si celle-ci etait relié a ma TV en HDMI, or j'ai un casque stereo en fiche jack donc le son ne fonctionne pas pour le moment
 
Donc je viens d'éteindre ma VM, et au relancement de celle-ci par virt-manager, plantage de l'hôte
ça vient surement du fait que je n'ai pas encore installé les pilotes VFIO sous Windows, d'ailleurs comment on les installes ?

Depuis quelques temps dans libvirtd, VFIO est utilisé par défaut (pci-assign est deprecated), donc si tu n'as rien modifié c'est ce que tu utilises.
C'est donc surprenant que tu ais le problème de reboot.
Pour la cirrus, aucun intérêt d'essayer de la supprimer (c'est possible avec -nographic il me semble), elle ne pose aucun problème et ça permet d'avoir un affichage VNC de secours.
Quand j'utilisais pci-assign, ce que je faisais pour rebooter (notamment pour les patchs Windows), c'est que je détachais la Radeon et je rebootais via VNC.
Pour le son (autre que l'HDMI), si tu ne l'utilises pas sur l'hôte, tu dois pouvoir passer la carte son en PCI Passthrough.

pour le son, c'est bon avec l'adressage de la carte son intégrée:
00:1B:0 8 Series/C220 Series Chipset High Definition Audio Controller
ça fonctionne nickel, je n'y avais pas pensé, merci pour l'idée

Il y a un souci, tu devrais avoir vfio normalement. Chez moi :

Ca expliquerait tes problèmes de reboot
Tu peux nous montrer ta config libvirtd avec un cat /etc/libvirt/qemu/ta_vm.xml ?

Voici mon cat /etc/libvirt/qemu/Windows7x64.xml

C'est étrange que tu ne sois pas en VFIO.
Si on prend la doc : http://libvirt.org/formatdomain.ht [...] tDevSubsys

Il semble que ce soit parce que tu n'as pas chargé le module VFIO. Fait un "lsmod | grep vfio" pour le confirmer.
S'il n'est pas chargé, fait un "sudo modprobe vfio-pci".

effectivement le vfio n'était pas chargé
Je viens de le faire sur ton conseil
maintenant sur mon lsmod | grep vfio

Comment je peux le faire charger au démarrage de mon ubuntu ?
 
EDIT:
Quand je veux lancer maintenant virt-manager:
Erreur lors du démarrage du domaine: internal error: Process exited prior to exec: libvirt:  error : cannot limit locked memory to 18253611008: Operation not permitted
 
 
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 117, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1162, in startup
    self._backend.create()
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 866, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: Process exited prior to exec: libvirt:  error : cannot limit locked memory to 18253611008: Operation not permitted
 

Il sera pris d'office normalement, sinon il faudra faire le binding, avec le script vfio-bind par exemple. Tu pourras le vérifier avec un lspci -k.
Par contre, je ne te garantis pas que ça fonctionne  

mon lspci -k

 
Je viens de rebooter, malheureusement il n'est pas pris d'office, enfin ça m'arrange presque vu que virt-manager plante

Comparons nos méthodes, tu as fait comment pour ta/tes VM ?
Tu peux donner un début de manip ?

Pour résumer, de mon côté :
- pendant plusieurs mois, j'ai utilisé la méthode pci-assign avec une VM Windows (7, puis 8 puis 8.1). Le seul problème, que tu as rencontré, est le reboot.
- depuis quelques temps, j'utilise une VM sous Ubuntu. Je joue très peu, elle me sert surtout pour Xbmc et quelques jeux (en ce moment Metro Last Light). J'utilise la méthode VFIO en secondary passthrough, qui fonctionne très bien avec une VM Linux, reboot compris. Par contre, j'avais testé avec ma VM Windows, impossible de la faire fonctionner avec ma Radeon 7850 (dans le gestionnaire de périphérique, code 12 : Ce périphérique ne peut pas trouver suffisamment de ressources libres utilisables. Si vous voulez utiliser ce périphérique, vous devrez désactiver l'un des autres périphériques sur ce système.).
- j'ai aussi testé la méthode VFIO en primary passthrough. Là ma VM Windows fonctionnait bien, mais ça veut dire compilation et patch du kernel et customisation de la conf libvirtd pour passer l'option x-vga=on.
 
Mon hôte est sous Debian Wheezy, avec actuellement un kernel 3.14 et qemu 2.0 provenant d'unstable/experimental.
Pour la seconde méthode que j'utilise actuellement, rien d'extraordinaire.
Je blacklist le driver radeon. Mon grub est configuré comme ça :

Et j'utilise le script vfio-bind récupéré sur le forum Archlinux pour initialiser ma carte avant de démarrer la VM :

Ok merci pour ton retour toma222
Je vais rester avec ma configuration pour le moment, a part le reboot de la VM, tout fonctionne maintenant
Sinon vous avez une astuce afin de rendre les disques durs plus rapides dans une VM ?
J'utilise directement le DD avec /dev/sdc et /dev/sdd
Bus du disque IDE
Format de stockage: raw
Mode de cache: default
Mode d'E/S: default
Vous les avez paramétré de quelle façon ?

Ok, tu as raison, c'est le plus simple pour l'instant.
Pour les disques, il faut que tu utilises virtio.
Voici comment j'ai configuré les miens (j'utilise LVM) :

Sous Windows, il faut installer les drivers, tu peux récupérer un iso ici : http://alt.fedoraproject.org/pub/a [...] st/images/

Merci !
avec le VirtIO, ça dépote !
nickel

Salut!
 
Super ce topic.
Je souhaite faire du vga passthrough sur une nouvelle machine que je viens de me constituer. J'étais parti sur Debian, et j'ai également repéré les 2 topics que vous citez (celui sur arch et l'autre sur mint).  
Ici on explique comment faire marcher sous ubuntu : http://forums.linuxmint.com/viewto [...] 00#p846397
Je vois que vous preferez KVM, perso, je n'ai pas de préférence tant que ça marche!
Alors je veux bien tester et donner mes résultats. Quel tuto me conseillez vous d'utiliser sachant que je n'ai aucune expérience sur xen ni KVM et que je suis d'un niveau assez moyen sur linux?
 
Question de noob : Pourquoi vous n'avez pas continué sur Debian si il "suffit" de recompiler le noyau avec la bonne option?
 
Pour info, voici ma config :  
carte mère ASUS H87M-PLUS à priori compatible VT-D
GPU : Radeon R7 260X
RAM : 8Go
CPU : i5 4570
 
Et à terme je souhaite faire tourner :
- un NAS sous l'os DSM de synologie
- un serveur web / owncloud / mail
- un environnement multimedia sous windows 7 : jeux
 
Longue vie à ce topic!

 
Pour ma part je suis sur OpenSuse, et ça fait 11 mois que je fais du passthrough avec 1 VM Windows 7 (tout d'abord sur OpenSuse 12.3 et maintenant 13.1) puis j'ai ajouté 1 VM Windows 8.1 (donc 2 VM et 2 CG en passthrough). La plupart des tutos trouvés à l'époque concernaient Arch ou Debian, mais comme j'utilise OpenSuse depuis des années j'ai estimé préférable d'adapter les tutos à ma distribution plutôt que de changer mes habitudes.
Je ne sais pas pour les autres, mais je peux imaginer la même chose.

oui, justement, je disais ça pour ceux qui testent sur ubuntu plutot que sur debian.

De mon côté, j'avais commencé sous Ubuntu Server, puis je suis passé sous Debian depuis un moment. J'utilise Ubuntu sur mon laptop (et aussi Arch en dual boot), donc c'est par habitude et effectivement je pense qu'il faut mieux partir sur ce qu'on connaît.
Mon hôte ne sert qu'à ça, il ne fait tourner aucun autre service.
Il héberge plusieurs VM sous Debian aussi :
- DNS/DHCP.
- Filer (Samba/NFS) + apt-cacher.
- MySQL.
- Web interne (Roundcube, MythWeb...).
- Mails (Postfix + Dovecot).
- Backend MythTV (contrôleur PCI hébergeant mon tuner USB en PCI Passthrough).
- Monitoring (collectd).
- Web Externe : Owncloud (une carte réseau dédiée en PCI Passthrough).
A cela s'ajoute une VM Windows 8.1 que je ne démarre plus et une VM Ubuntu 14.04 pour Xbmc + jeux avec VGA Passthrough.
 
Pour le choix entre KVM et Xen, c'est pareil, c'est parce que je connaissais KVM depuis un moment, et aussi parce que je préfère le principe (pas besoin d'un kernel spécifique).

En fait, vous allez me dire que je veux le beurre et l'argent du beurre, mais je souhaiterais un système assez stable et assez sécurisé.
 
Avec mon peu d'expérience, je me fait quand même une mauvaise image de ubuntu 14.04 et de jessie pour cela (problèmes de sécurités potentiels pour jessie, et du code propriétaire avec ubuntu).
Ai-je raison?
 
Dans ce tutoriel, on utilise wheezy et on recompile le noyau 3.4.9:
http://wiki.xen.org/wiki/Comprehen [...] h_Tutorial
 
Que pensez vous de cette solution?

au niveau des perfs 3D ca donne quoi ?

J'utilise Wheezy, mais je fais de l'apt-pinning pour récupérer le kernel et qemu depuis testing/unstable/experimental.
Pour moi Jessie est suivi au niveau mises à jour de sécurité, le problème c'est qu'il peut y avoir de grosses mises à jour qui arriveront (je pense à systemd), même si c'est bien testé chez Debian, au niveau stabilité ça peut être problématique. Pour Ubuntu, c'est une question de point de vue. L'intérêt pour NHiX, c'est que la 14.04 embarque tout ce qu'il faut (kernel 3.13 avec l'option CONFIG_VFIO_PCI_VGA s'il veut tester le primary passthrough et qemu 2.0).
Les problèmes en compilant soit même :
- ce n'est pas forcément simple pour quelqu'un qui débute.
- ça prend du temps (même si avec nos core i5/i7 c'est acceptable).
- il n'y a pas de mises à jour automatiques, donc au niveau sécurité c'est à toi de suivre et de recompiler à chaque fois.
 
@duflotte : au niveau performance 3D, c'est proche du natif (95% d'après des tests que j'avais lu).

Ok, alors je vais tenter la même chose.
Quel tuto est le plus adapté à ton avis pour faire ça entre les 3 que je connais ?
- celui pour mint avec xen : http://forums.linuxmint.com/viewto [...] &start=400
- celui pour Arch avec KVM : https://bbs.archlinux.org/viewtopic [...] 3#p1268413
- ou celui pour Wheezy avec Xen (et ça inclus la recompilation du noyau) : http://wiki.xen.org/wiki/Comprehen [...] h_Tutorial
 
Si c'est trop difficile pour mon niveau, alors tant pis j'installerai ubuntu.
Mais si je réussis, j’essaierai de noter toutes les étapes pour les noob comme moi qui veulent faire pareil..

Pour le tuto, je n'ai pas trop d'avis. Prends celui qui te semble le plus clair. Entre Xen et KVM, à toi de choisir. Xen est probablement plus documenté, mais ne l'utilisant pas je ne saurais pas t'aider.
Si tu ne veux pas d'embêter avec l'apt-pinning, tu peux utiliser les backports de Wheezy : http://backports.debian.org/Instructions/. J'ai vu qu'il y a le kernel 3.13 et qemu 1.7, ce sera peut-être suffisant.
Après, comme je l'indique, avec KVM, il y a 3 méthodes, dans l'ordre de difficulté :
- secondary passthrough avec pci-assign : c'est la méthode historique, même si elle est dépréciée, c'est la plus simple à mettre en œuvre. Le seul problème est que le reboot de la VM risque de faire planter l'hôte. C'est la méthode utilisée par NHiX pour l'instant.
- secondary passthrough avec vfio : plus propre et plus de problèmes de reboot, mais chez moi ça ne passe pas avec une VM Windows (mais Ok avec une VM Linux). C'est celle que j'utilise actuellement, n'utilisant plus ma VM Windows.
- primary passthrough avec vfio : méthode décrite sur le forum Archlinux, plus délicate à mettre en œuvre mais elle présente certains avantages (plus de carte vidéo virtuelle, donc l'affichage du boot se fait directement sur la carte physique, plus compatible, à priori même avec des cartes Nvidia et fonctionne chez moi avec ma Radeon sous Windows).

Ok, merci pour tes conseils, c'est super!
Je vais tenter tout cela (et en primary ou secondary passthrough )

Petites news : j'avance doucement.
 
J'ai réinstallé Wheezy, j'ai configuré les backports et alors ça a marché sans problème pour installer le kernel 3.13, ainsi que quemu-kvm!
 
D'après ce que je comprends, ce kernel 3.13 n'a pas l'option CONFIG_VFIO_PCI_VGA donc je devrai me contenter du secondary passthrough pour l'instant. (a-t-on moyen d'ailleurs de vérifier simplement à l'aide d'une commande si le noyau a été ou pas compilé avec l'option CONFIG_VFIO_PCI_VGA ?).
 
Ensuite, j'essaye de suivre le tuto d'Arch ( https://bbs.archlinux.org/viewtopic.php?pid=1268413 ) sachant que j'ai compris qu'il faudra que j'adapte les options de qemu-system-x86_64 comme c'est expliqué dans les posts précédents (en particulier, ne pas mettre x-vga=on)
 
J'ai une difficultée de noob à ce points en particulier que je vais creuser (surement un module à charger...?):
- en ce qui concerne la ligne de configuration qui ressemble à "pci-stub.ids=1002:6719,1002:aa80", je ne suis pas bien sûr de moi : est-ce bien dans /etc/grub.d/40_custum qu'il faut la mettre ?
apres avoir fait update-grub, la ligne est bien reportée dans /boot/grub/grub.cfg
Mais même après reboot, la commande dmesg | grep pci-stub ne m'affiche rien..

Pour vérifier si l'option est activée ou non :

(en mettant la version de ton kernel bien sûr).
C'est dans le fichier /etc/default/grub qu'il aurait fallut l'ajouter, et non dans /etc/grub.d/40_custom, mais je ne pense pas que tu ais besoin de pci-stub, c'est surtout utile à priori si tu utilises 2 Radeon, une pour l'hôte, une pour la VM. Dans ton cas, le blacklist du driver Radeon devrait être suffisant. En plus, sous Debian, le pci-stub est compilé en tant que module :

Donc ça ne servirait à rien de l'ajouter dans grub.  

Ok, merci..
Je n'ai pas non plus réussi à m'en sortir avec la partie service / Systemd.
J'ai installé systemd (apt-get install systemd) mais j'ai une erreur :  
Failed to get D-Bus connection: No connection to service manager.  
Dois-je installer systemd-sysv ? -> un message me dissuade de le faire..
J'ai bien l'impression de faire des choses que je ne comprends pas et que ça va me jouer des tours!
Heureusement, mon système est totalement vierge !

Tu n'as pas besoin de systemd. Il est décrit dans le tuto sur Arch, mais c'est parce qu'il est utilisé par défaut. Sous Debian, ce n'est pas encore le cas.
Si tu utilises la méthode VFIO, lance la commande vfio-bind 0000:01:00.0 0000:01:00.1 à la main pour l'instant, tu verras plus tard pour le mettre au démarrage du système.

 
ok, donc voici mon premier test !
 
root@:/usr/bin# ./vfio-bind 0000:01:00.0 0000:01:00.1
root@:/usr/bin# qemu-system-x86_64 -enable-kvm -M q35 -m 1024 -cpu host \
> -smp 6,sockets=1,cores=4,threads=1 \
> -bios /usr/share/qemu/bios.bin \
> -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
> -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on \
> -vnc 127.0.0.1:8 \
> -device vfio-pci,host=01:00.1,bus=root.1,addr=00.1
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on: vfio: error no iommu_group for device
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on: Device 'vfio-pci' could not be initialized

Aye...
Je n'utilise pas qemu directement, je passe par libvirtd.
VT-D est bien activé ? Tu peux faire un :