Reprise du message précédent :
Aucun problème avec les drivers virtio ni sur ma VM Windows 7 ni sur ma VM Windows 8.1.
Et comme j'utilise ma VM Windows 7 en tant que PC "Home-Cine" la lecture de video ou de musique à partir du réseau c'est ce que cette VM fait le plus.
 
Je suppose que ça n'a pas d'influence avec ton problème mais pour info j'utilise les drivers virtio aussi pour le sata et la mémoire.

OK, merci du retour.
Il faut que je check ma conf alors.

J'ai une VM en Win8.1 sur laquelle je joue en réseau et je n'ai pas de déconnexions en utilisant les drivers réseau virtio.

Je suis confronté à un petit soucis pour ma VM Windows 8.1, je vous explique mon soucis
Si je ne "passe" pas à ma VM le chipset sonore, je n'ai pas de son dans celle-ci
Si je passe mon chipset son à la VM, je n'ai plus de son sur l'hôte et mes vidéos sur Youtube par exemple se trouve être lues en accéléré !
Je me sers exclusivement de Virt-manager pour le moment, le son sous celui-ci est défini sur ich6

Dans ma VM Windows 8.1, je vois pourtant bien dans Contrôleurs audio, vidéo et jeu
Périphérique High Definition Audio, mais pas de son

Cherche un petit peu, mais je crois que tu peux émuler très facilement une carte son, c'est la meilleure des solution à mon avis car je ne vois pas l'intéret de "passer" ton chipset sonore en tant que tel

Tu as essayé de ne mettre aucun périphérique son dans virt-manager?
Je n'utilise que virt-manager aussi et je n'ai dans celui-ci aucun périphérique son; juste mes cartes graphique que je passe (avec la partie son bien sûr)

@adejour Dans virt-manager, j'ai bien trouvé où déclarer une carte son, le soucis, c'est qu'avec ma VM celle-ci n'est pas reconnue
Avec le ac97, Windows me détecte bien une carte son, mon seul soucis, c'est qu'il n'arrive pas à trouver de drivers

@Arcord J'ai essayé avec aucun périphérique son passé à la VM via Virt-manager, le résultat est que ma VM n'a pas de son

C'est un peu du bricolage, mais je pense avoir trouvé une solution...
Mon clavier pour ma VM Windows 8.1 est un Logitech G510, celui-ci intègre une carte son, j'ai donc branché mon casque Qpad dessus (jack)
et je me sers de la carte son de ma carte mère pour ma OS hôte.
 
C'est mieux que rien, même si je préfère avoir les sons des 2 systèmes sur mon casque, mais en attendant de trouver une solution satisfaisante celle-ci fera l'affaire

Ce topic m'ayant bien aidé dans ma config, à mon tour de partager

Le résultat :
- Hôte ubuntu 14.04, avec le kernel 3.15.0-rc7 non patché, qemu-kvm installé depuis apt
- VM Windows 7 avec une Radeon 7850 en primary passthrough
- VM FreeNAS avec le controller SAS en passthrough
- Pas de config bizarre dans Grub, juste l'activation de l'iommu
- Le tout géré depuis virt-manager

La config hardware :
- Supermicro X10SL7-F (+chipset graphique Aspeed AST2400 + LSI SAS 2308)
- Xeon 1230v3
- Radeon 7850 Sapphire

• La première étape est d'installer le kernel 3.15.0-rc2 prépackagé pour trusty, afin de pouvoir en récuperer la config comme point de départ.

• On télécharge ensuite le dernier kernel

• On copie la config du kernel rc2 et on la met à jour avec les nouveaux flags du rc7 (en sélectionnant les valeurs par défaut)

• On édite ensuite le fichier .config avec les valeurs suivantes

• Pour la compilation, il y a un bug dans kernel-package qui oblige à la lancer en root (voir ici). Un deb fixé est disponible, on va donc l'installer :

• C'est parti pour la compilation du kernel

• À ce moment là, au boot, le nouveau kernel est en deuxième position (car le kernel rc2 a une version 031500rc2 qui passe devant dans l'ordre alphabetique). Il faut donc modifier la config de grub. On en profite pour activer l'iommu. Dans /etc/default/grub :

• Avant de redémarrer, on installe lsgroup, vfio-bind, et le service qui va bien pour le lancer au démarrage

- /usr/bin/lsgroup

-  /usr/bin/vfio-bind

- /etc/init/vfio-bind.conf

- /etc/vfio-bind.cfg

- Ne pas oublier de setter les permissions

• On blackliste le module radeon (pas testé sans, ça ne mange pas de pain), et on installe virt-manager et kvm

• Afin de pouvoir utiliser libvirt avec des périphériques passés en vfio, la premiere étape est de désactiver apparmor

• Il faut ensuite donner plus de permissions à libvirt (lancement en root + accès à /dev/vfio/votre_groupe). Dans /etc/libvirt/qemu.conf :

• À ce moment là, après un reboot, vous devriez pouvoir importer (par virsh define mon_fichier.xml) la VM dotée du XML suivant. (Je n'ai pas parlé de la config réseau et des histoires de drivers vfio)

J'espère que ça pourra aider certains d'entre vous.
Avec cette méthode j'ai ma VM Windows qui tourne avec un passthrough de la CG + mon clavier passé en USB. Je n'arrive pas à passer en USB ma carte son, mais ça ira pour l'instant
À noter qu'il n'est pas possible de passer deux devices appartenant au même groupe à deux VMs différentes, ce qui m'a empêché de passer ma carte USB (elle est dans le même groupe que mon controller SAS, dont j'ai besoin pour ma VM Nas)
Et donc également une VM FreeNAS avec le controller SAS en passthrough, fonctionne également sans problème

Voilà, n'hésitez pas si vous avez des questions

Chouette retour !
J'allais te demander si tu n'avais pas de soucis avec ton chipset graphique intégré pour l'hôte vu que tu n'as pas patché ton kernel (notamment avec le patch i915), mais je vois que tu n'utilises pas une carte Intel avec ta carte mère, donc pas de problèmes. A priori le kernel 3.15 doit embarquer des améliorations pour l'ACS, donc effectivement tu n'as besoin d'aucun patch dans ton cas.
Juste une remarque par rapport à ta définition libvirt, je me suis rendu compte que si je ne spécifiais pas de topologie, dans mon cas avec 4 vCPU, Windows voyait deux sockets de deux cores (je ne voyais que deux unités dans le gestionnaire des tâches pas exemple).
J'ai donc changé en :

J'ai maintenant 4 unités dans le gestionnaire des tâches et mes performances CPU sont bien meilleures (flagrant avec le streaming Steam).

 
Oui c'est bien pour ça que je suis parti sur le 3.15, qui même en rc m'a l'air suffisamment stable. Moins il y a de bricolage mieux c'est  
Avec deux vCPU j'ai bien les deux cores dans le gestionnaire de tâches, mais effectivement, avec 4 c'est comme tu dis Merci pour le tip, je n'aurai pas remarqué

Salut, j'ai un souci avec libvirt.
Je modifie ma VM existante (virsh edit XXX) pour ajouter le bloc "qemu:commandline".
J'enregistre, mais quand j'édite la VM à nouveau, tout ce bloc a été supprimé.
Une idée du pourquoi ?

Salut,
Il faut que tu modifies la première ligne en :

Ca aussi ça disparait tout seul après avoir enregistré ...
Je me retrouve toujours avec la balise "domain type='kvm'" tout court, sans le "xmlns:qemu"...
Pourtant je peux bien changer les paramètres comme le nombre de CPU, ram, etc ... donc l'édition fonctionne...
 
Edit: Bon ça y est j'ai compris ! En fait il faut écrire tout en une seule fois.
Si j'ajoute juste le "xmlns:qemu" alors il est supprimé. Si j'ajoute juste le bloc "qemu:commandline" alors il est supprimé.
Mais si j'ajoute les 2 en même temps, ils restent tous les deux. Merci à toi !

Information intéressante pour ceux qui font du vga passthrough avec une Geforce et KVM (comme moi):
vous avez sans doute constaté que tout fonctionnait bien avec le pilote 335.23, mais qu'avec n'importe quel pilote plus récent, la carte ne fonctionne plus du tout (erreur 43 au démarrage de Windows).
 
Un membre du forum Arch a trouvé la solution:
https://bbs.archlinux.org/viewtopic [...] 4#p1421204
 
Bien que Nvidia le démente, il semble qu'ils aient ajouté volontairement un bridage dans leur driver.
Quand l'hyperviseur KVM est détecté, alors le pilote refuse de démarrer et provoque l'erreur 43.
Le workaround consiste à patcher Qemu pour supprimer ou modifier la signature de l'hyperviseur.
 
Merci Nvidia !

Driver WHQL ? Microsoft ?
 
XaT

A voir si cela fait la même chose avec HyperV... Si oui, Microsoft inside, si non, nVidia quoi

Justement, la réponse de nvidia c'est qu'ils ont apporté un correctif relatif à HyperV, que ça a cassé KVM par accident, mais vu que KVM n'est pas officiellement supporté par Nvidia, ils ne corrigeront pas le problème.
 
Sauf que, comme indiqué, il suffit de changer un tout petit peu (ou carrément supprimer) la signature de l'hyperviseur KVM pour que tout fonctionne correctement.  
Ca ressemble vraiment à un blocage volontaire de KVM.
Dans tous les cas, c'est bien Nvidia qui a introduit le problème.
 
D'ailleurs Qemu vient d'ajouter un workaround officiel:
http://git.qemu.org/?p=qemu.git;a= [...] 3f424a7dfa

MS qui a grassement payé Nvidia quoi C'est légal ?
 
XaT

Salut
Je reviens vers vous pour encore vous demander quelques conseils.
J'ai toujours mon problème de son pour mon système hôte quand je passe celui-ci à ma VM
J'ai bien tenté de régler mon soucis avec le chipset son AC97 dans Virt-manager, mais sans succès
Je suis à la recherche aujourd'hui d'une "carte son usb" pleinement compatible avec Windows 8.1
Sinon je suis curieux de savoir ... Comment faite vous avec Windows 8.1 en guest pour avoir du son en même temps sur l'host ?
Merci d'avance pour vos réponses

Salut,
 
Pour la carte son USB, je ne saurais pas trop de dire.
De mon côté, je n'utilise pas le son de l'hôte (il n'y a pas de Desktop, c'est plutôt un serveur, je m'en sers uniquement en SSH), mais ma VM utilise l'HDMI de ma Radeon, donc je passe le son par là et ma carte son intégrée serait disponible si j'en avais besoin.

Bonjour,
 
Pour ceux qui sont sous Debian, il est désormais possible d'utiliser le x-vga avec VFIO sans compiler ni patcher quoi que ce soit avec les ingrédients suivants :
- kernel 3.16-trunk-amd64 qui vient d'arriver dans experimental, qui est maintenant compilé avec les options suivantes :

- qemu 2.1 qui est dans Jessie.
Je viens de tester rapidement, aucun problème relevé chez moi.
Par contre si vous voulez utiliser un chipset Intel intégré sur votre hôte, vous aurez peut-être besoin de patchs spécifiques.
 
A noter également pour ceux que ça intéresse que la prochaine version de Proxmox (3.3) devrait permettre d'utiliser le VGA Passthrough.

up!
 
Dites, il faudra que je flash/mod ma 670 pour profiter du PT ?  
 
XaT

 
Hello,
 
Sais-tu comment on installe le patch car j'ai un chipset intel intégré ?

 
C'est seulement si tu veux utiliser ton chipset Intel sur l'hôte pour de la 3D je pense que tu as besoin de patchs (vga arbitrer).
Si c'est ton cas, le plus simple est de partir de ce qui est fourni sur le forum Archlinux (https://bbs.archlinux.org/viewtopic.php?id=162768&p=1).
Chez moi je n'ai pas d'environnement graphique sur l'hôte donc je n'en ai pas eu besoin.
 

 
Je n'ai pas de Nvidia, mais à ce que j'ai compris je ne pense pas que ce sera nécessaire. Tu auras peut-être des soucis avec les derniers drivers Nvidia, mais il existe maintenant un paramètre (kvm=off de mémoire) qui permet de contourner le problème.

Avec Xen j'ai l'impression que c'est obligatoire de la passer en Grid K2 (ce qui pourrait être cool pour le gpu share jsais plus quoi )

XaT

 
J'ai réussi à jouer avec ma carte en passthrough mais je n'ai pas compris comment s'installer le patch car le dernier bug qu'il me reste concerne le chipset intel qui se met à "déconner" sur l'hôte lorsque je lance ma vm.

Pour recompiler le kernel avec les patchs (à récupérer sur le forum Archlinux), tu peux te baser sur la méthode que j'avais donné en adaptant au 3.16 :

Merci pour ton aide, je vais essayer ça ce soir !

 
J'ai recompilé le noyau 3.16-trunk-amd64 avec le patch et ça fonctionne parfaitement
 
Maintenant il me reste un problème beaucoup moins génant ! Il s'agit du périphérique HDMI de ma carte graphique qui utilise le driver snd_hda_intel. Donc je le blacklist mais le son intégré de la carte mère ne fonctionne plus (logique)...quelqu'un a rencontré le problème ?

Plop,  
 
Quelqu'un aurait une idée de comment reproduire le fonctionnement du module pciback de xen sur la carte graphique avec du kvm et sur une arch ?  
J'entends par la avoir cet effet de carte graphique "déconnectée" de l'hôte et donc l'écran s'éteint par ce qu'il n'y a plus de signal.  
 
Je sais pas si ca vous le fait ou pas mais chez moi c'est pas le cas sur la arch et du coup ca me parait pas logique pour fait du pt par la suite avec la cg intégrée.

Bon premiers pas et premiers résultats avec la triplette qemu, kvm et arch ... ma gtx 780ti est passée comme une lettre à la poste avec les drivers 340.52.

Ca m'enlève le poids de devoir la moddé pour la faire fonctionner sous xen.

Par contre j'ai un petit soucis avec le clavier, la touche windows ne marche pas J'ai passé le controleur usb à la vm. Au début je pensais que c'était le clavier qui marchait pas bien qu'il soit allumé mais non c'est juste cette touche qui marche pas, en tous cas pour le moment.

Il semble que j'ai résolu le problème avec mon clavier. La touche windows ne marche pas quand le rétro eclairage est allumé. Si je le coupe la touche fonctionne. C'est bizarre, je me rappel pas avoir eu ca avant.

Edit: En fait, y'a plusieurs mode de retro eclairage sur le clavier et en particulier un mode multicouleurs. C'est la teuf dans le clavier Et c'est juste avec ce mode que la touche windows ne fonctionne pas. Avec le mode mono couleur, c'est bon.

Y'en a qui ont réussi a faire du passthru avec la cg intégrée intel ? Je veux dire en ayant booté dessus ?

Tu veux dire qu'on attribue la cg intégrée intel à une VM ?

Pas possible si on a déjà booté dessus, l'os garde la main dessus et voudra pas la donner
Fin je crois.

edit: Va voir topic proxmox je crois qu'ils en ont parlé récemment

XaT

oui
 
Avec du xen (au moins les versions 4.2.x 4.3.x 4.4.x), je passe sans problème la carte intégrée intel à une vm en pt. Elle est configurée comme carte principale dans le bios mais je peux me brosser si je veux passer la carte nvidia.  
 
Avec du qemu/kvm, je passe sans problème la carte nvidia en ayant booter sur la carte intégré intel mais je peux pas passer la carte intégrée. Je pensais que c'etait possible et que ca se fesait sans trop de difficultés.  
 
Me reste une chose à faire je crois. Best of both worlds
 
Edit: et la solution best of both worlds ne marche pas. Pas possible de faire tourner du xen et du kvm sur la même machine  

En train de tester la future Fedora 21 avec une VM
Je suis surpris de voir que celle-ci intègre Qemu 2.1.1, Xen 4.4.1, le protocole Spice dans Machines !
cat /boot/config-3.16.1-301.fc21.x86_64 | grep VFIO
CONFIG_VFIO_IOMMU_TYPE1=m
CONFIG_VFIO=m
CONFIG_VFIO_PCI=m
CONFIG_VFIO_PCI_VGA=y
CONFIG_KVM_VFIO=y

Attention, une mise à jour du driver Nvidia pour Windows, version 344.11, casse encore le support des cartes Geforce sous Qemu    
 
Cette fois-ci, il ne se contente pas de détecter l'hyperviseur, il détecte aussi les flags hyper-v activés par Qemu.
Dès qu'un flag hyper-v est détecté, le pilote Nvidia refuse de se charger et affiche l'erreur 43.
 
Donc, on a 2 possibilités:
- désactiver les flags hyper-v de Qemu (pas terrible pour les performances de la VM)
- ne pas mettre à jour le driver Nvidia et rester en 340.52