Reprise du message précédent :
Ça fonctionne très bien Qemu et c'est assez facile d'accès je trouve.
Sinon, si Virtualbox est plus performant que qemu-kvm + kvm-amd, c'est intéressant, mais, là, c'est déjà très bon.
 
edit : mouais, pas terriblement friendly je trouve (en plus, niveau gestion usb, ça me paraît moyen). De plus, il semble y avoir pas mal d'extensions à rajouter, bref, ça semble un peu loin du tout compris via qemu-kvm (et -h donne les bonnes indications). Il reste à voir les performances certes.
 
Des liens intéressants (et récents) :
-Raw disk I/O benchmark - qemu-kvm vs vbox
-qemu-kvm ou virtualbox ?

-Qemu + KVM is the future of open source virtualization

J'ai testé Virtuabox (4.1.8) en parallèle : c'est plus rapide (et très facile) d'installation et plus réactif du point de vue graphique (accélération 2D/3D activée, ce qui explique ceci).
Sinon, du point de vue processeur, je pense que Qemu-kvm est un peu au dessus.
À propos de l'usb2, c'est toujours le même souci, apparemment, c'est assez récent comme erreur.
Cf : VirtualBox Win Guest access iPhone, app-emulation/virtualbox-4.0.12 - Windows guest has USB disk woes.

 
Module VirtualBox :

 
Module kvm :

ça a l'air d'être le topic unique de qemu, donc je pose ma question,
 
je suis sous  archlinux 64 bits, ma version de qemu est la 2.1.0,
 
j'utilise une des fonctionnalités de "spice" pour avoir le copier-coller entre l'OS host et l'OS guest :
 
https://wiki.archlinux.org/index.ph [...] _and_paste
 
ça fonctionne, mais si je redémarre la machine virtuelle ( menu "reboot" dans l'OS guest ) alors qemu fait systématiquement un segfault, et cela uniquement si je fais un reboot de l'OS guest ( une extinction de l'OS guest n’entraîne pas de segfault ) :
 

 
si je n'utilise pas la fonctionnalité de copier-coller de spice ( qui consiste à créer un virtserialport ) alors je n'ai pas de plantage au reboot, on dirait un bug ( ou une feature comme dirait l'autre ),
 
ça le fait quelque soit l'OS guest ( windows ou linux ),
 
avez-vous le même problème ?
 
le script qemu que j'utilise pour lancer archlinux 32 bits :
 

 
 
je me permets de parler de GNOME Boxes, une interface graphique Gtk pour interagir avec Qemu https://wiki.gnome.org/Apps/Boxes
l'outil devrait être disponible dans la plupart des distributions.
 
une alternative à virtu**** ?

Pourquoi pas KVM/Qemu/libvirt/virt-manager? C'est du tout graphique et ça tourne plutôt bien.

l'habitude des outils gnome/gtk

quel genre de VM gères tu?

Étant donné ma configuration très basique, ne tournent que la dernière Ubuntu 32 bits et parfois Windows

perso j'utilise aucune interface graphique, je passe par un script pour appeler qemu avec les bonnes options, c'est souvent beaucoup plus simple et plus fiable que l'interface graphique, qui peut être boguée, ou non mis à jour par rapport aux nouvelles options de qemu

je fais exactement pareil.  mais c'est toujours bien de savoir qu'une UI existe

 
Je plussoie. J'ai utilisé libvirt/virt-manager pendant un an pour mon projet d'alternance quand j'étais en DUT, et rien à redire.

l'interface graphique c'est peut-être pour ceux qui sont habitués à virtualbox, ou vmware,

mais en pratique si les propriétés de la machine virtuelle ne bougent jamais (taille du disque dur virtuel, cpu) alors un bête script texte devrait suffire, avec un raccourci sur le bureau ou dans la barre des tâches, et ça permet plus tard d'affiner plus facilement la machine virtuelle en changeant les options avec un éditeur de texte

 
non

 
Je viens de récupérer les droits d'ecriture de la FP, je vais pouvoir attaquer sa reconstruction.  
J'ai pensé à ses points suivants:

• petite présentation en quelque mots  
• ses killer features
• ou se le procurer
• les différentes GUIs qui peuvent intéragir avec Qemu
• quelques examples génériques en ligne de commande (si possible)
• liens utiles
• historique des versions

Si vous avez d'autres idées, n'hésitez pas!  
 
PS: Encore un grand merci aux modos!
 
 

Un grand merci à toi surtout de reprendre le topic
 
Je ne vois rien à ajouter pour l'instant, impec

Bonne reprise du topic Frenchieisverige

Comme il y a des utilisateurs de qemu sous linux ici :

- avez-vous déjà essayé d'installer windows 10 (iso téléchargeable gratuitement sur le site de microsoft) dans qemu, avec une distribution linux comme OS host ?
J'ai essayé il y a quelques mois, avec la build d'octobre 2018, avec archlinux comme OS host, et j'ai trouvé les performances très inférieures à une machine virtuelle windows 7, un démarrage lent, le disque dur qui rame

le script que j'utilise pour lancer cette machine virtuelle windows 10 avec qemu :

le PC utilisé est ancien mais encore assez rapide pour les usages de 2019 : cpu intel core 2 quad core Q9650 (3 Ghz), 8 Go de ram, carte mère socket 775, chipset intel P35,
certains affirment qu'utiliser un SSD pour héberger la machine virtuelle permet de résoudre en partie la lenteur de virtualisation de windows 10, car ce dernier fait beaucoup d'opérations I/O sur le disque, ce qui pénalise la virtualisation si un disque dur classique est utilisé.

Si vous connaissez des options qemu permettant d'améliorer la virtualisation de windows 10 alors je suis preneur.

Ici dans le script j'utilise "virtio", avec l'iso "virtio-win-0.1.141.iso" permettant (en théorie) de booster un peu les performances de virtualisation d'un OS guest windows, en installant des pilotes de périphériques optimisés pour la virtualisation sous qemu/kvm :
https://docs.fedoraproject.org/en-U [...] index.html
https://github.com/virtio-win/kvm-guest-drivers-windows

En refaisant cette FP, cela me permet de découvrir un logiciel libre de virtualisation. J'espère à terme pouvoir "animer" ce topic et pas rester un simple scribe de FP

Absolument.
Ce n'était pas cette iso mais une de msdn, mais je doute que ca change grand chose.
C'était aussi super lent mais entre des options btrfs et des options sur la VM c'est devenu tres acceptable.
Enfin c'etait juste pour vite fait lancer des logiciels non disponibles sous Linux et qui ne tournent pas sous Wine, je n'ai pas testé les performances.

moi j'ai une question.
est il possible de demarrer une VM sur une installation (Win10 ou autre) déja existante sur un disque physique?
en gros j'ai un disque #1 avec Linux dessus et j'ai un disque #2 sur lequel est installer Win10. Je voudrais utiliser
l'installation Linux comme host et démarrer win10 du disque #2

du coup je viens de tomber la dessus  

mais il y a un mais

c'est quoi le genre de risques?

Je l'ai déjà fait, mais du moins a l'époque il fallait créer un MBR avec dd ou truc du genre.

Entre autres, le fait que, dans la VM, Windows ne reconnaîtra plus sa configuration matérielle (carte-mère, surtout) et que ça fera sauter son activation.

j'ai un numero officiel au cul du pc pour le reactiver (à condition d'avoir du resau à travers l'host).
sinon, il est pas actif pendant 30jours et je peux l'utiliser régulièrement comme ça? et je le réactive lors d'un redémarrage normal ou bien ça va vraiment le planter et que je devrais faire une reinstall

Dans tous les cas je ferrai un backup
Faire joujou avec une machine que l'on utilise quotidiennement et/ou avec des données sensibles c'est se créer des problèmes pour rien.
 
Il me semble que tu peux utiliser normalement windows 10 pendant 30 jpurs, et aprés certaines fonctionnalités ne sont plus accessibles ou paramétrables. Ce que je te conseille pas de faire, car hors charte d'utilisation W10.

Il est interdit d’utiliser un Windows non activé (c’est marqué dans le CLUF). Le « délai de grâce » n’est en aucun cas une période d’essai (ça n’existe pas, pour Windows), mais juste un délai pour procéder à l’activation si, d’aventure, le programme d’installation ne parvenait pas à faire l’activation lui-même. C’est sa seule finalité.
 
Et tu n’as droit qu’à 10 activations en tout par Internet avec une même clef. Au-delà, il faut passer par un appel téléphonique pour obtenir le droit de réactiver.
 
Enfin, 1 licence = 1 seule installation à la fois (sur machine physique ou virtuelle, mais pas les deux en même temps car il faudrait une deuxième licence pour ça).

en fait :
1- je ne l'utilise pas quotidiennement
2- c'est pour un logiciel 'artisan' que je n'ai pas réussi à faire fonctionner jusqu'au bout sous wine+.NET  
3- ça m'arrrangerait de pouvoir le booter depuis linux sans gacher 250Go d'une VM avec image

Avec KVM/Qemu le fichier "disque dur" ne fait que la taille réellement utilisée. J'ai des VM avec 25Go de place avec un fichier de quelque Go seulement.

le disque dur (250go) physique en question est une install de win10 d'origine du pc.
JE ne vois pas comment je pourrais créer une image plus petite avec un dd de /dev/sda sans aucune perte. Ou alors un truc m'échappe.  
lors d'une virtualisation/migration, il faut bien créer une img de la meme taille que la source. sinon tu es sur que ça va merder à la recopy.
je connais la notion de partition variable dans les VM mais il faut une reinstall dans l'image dans laquelle tu définis le minimum

si ton logiciel est en 32 bits alors tente un coup avec la version alpha (donc très instable) de ReactOS, qui se veut une implémentation open-source de win32, j'avais tenté le coup il y a quelques mois avec qemu :

https://forum.hardware.fr/forum2.ph [...] 0#t1436709

ça peut dépanner si ton logiciel est très simple et n'utilise pas des fonctionnalités multimédias (son, vidéo), ni des versions récentes de .Net,

l'avantage d'une machine virtuelle ReactOs c'est qu'elle est très légère (500 Mo une fois installée), démarre en un éclair et consomme peu de mémoire, l'inconvénient c'est qu'il y a encore beaucoup de bugs et ne convient que pour les applications très basiques

le logiciel en question demarre très bien son interface sous wine. Je peux l'utiliser correctement... seulement au nivau projet.
Mais des qu'il faut faire une recherche de port série sous usb et donc finaliser le boulot (+ecriture ou pilotage dans une eprom)
il ne trouve rien alors que j'ai bien fait la passerelle /dev/ttyUSB0 :com1
donc je dois repasser sous win pour boucler le projet "en dur"; en débranchant  mon ssd linux et passer sur le ssd win.  
d'où l'idée de booter directement win10 dans un bios qemu depuis son propre disque, cela me permettrait d'eviter de mettre les mains dans la tour c'est un gain de temps non négligeable

La configuration du port série, usb et parallèle n'est pas évidente avec wine, il faut retenter le coup, en trouvant un tutoriel wine qui explique mieux comment donner l'accès à ces ports aux programmes tournant sous wine,

j'avais galéré la dernière fois pour que mon vieux programme windows sous wine puisse utiliser le port parrallèle, mais en insistant ça a fini par fonctionner, de mémoire il a fallu créer un script bash pour lancer wine et le programme avec certains droits pour que le port parallèle puisse être accessible,

essaie ce tutoriel :
https://www.scivision.dev/wine-serial-port-links/

 
il suffit d'aller dans dosdevice et declarer un ln -s avec le bon port com. j'ai meme edité le regedit correspondant. et vraiment je n'ai trouvé aucune autre doc au sujet des serials...
j'ai plusieurs logiciels win de diag qui tournent sous wine qui font très bien le lien avec le bon serial...  (sur la meme machine)
 
c'est un peu HS, mais ma seule solution est d'aller sous win10 et la .NET (pour le moment) alors que je travaille beaucoup plus rapidement avec Linux pour tout le reste. (factures, prog, gestion)

ah je me souviens maintenant, c'était un programme windows pour controler un oscilloscope via le port parallèle, ce programme nécessitait un accès "raw" (des zones mémoires) au port parallèle (chose délicate sous linux), et la seule manière d'y arriver avec wine c'était de le lancer via un "wrapper" afin de donner temporairement (le temps de l'exécution) à wine cet accès spécial,

il a fallu compiler ce programme (qui sert de "wrapper" pour lancer à la fois wine et le programme windows avec les bons droits d'accès au port parallèle), et mettre dans le code source le chemin de wine et du programme windows, ainsi que la plage d'adresse mémoire utilisée par le port  :

regarde si c'est pas ce genre de problème avec ton port série, si ton programme windows veut y accéder d'une certaine manière (et qui nécessite une dérogation pour y arriver sous linux), regarde aussi les fichiers logs (dmesg, la sortie console de wine, pour voir s'il y a un message d'erreur quand ton programme windows scanne le port série)

sous wine, il ne le scanne meme pas. il faudrait déjà que je puisse écrire le chemin du port com dans les préferences du soft et c'est bien ça qui marche pas.
bon c'est vraiment un soft particulier pour une activité particulière. Mais le fait d'avoir une petite centaine de clients réguliers sur ce marché
me pousse encore à retourner sous win pour ce type de tache.  
mais il est vrai qu'à la minute où ce soft tourne jusqu'au bout sous wine, c'est plusieurs heures de gagnées par mois.

 
Voila un premier jet de la nouvelle FP. J'attends vos retours, je suis ouvert à toute critique!
 
Edit: je vois déjà de potentielles améliorations: La section téléchargement plus clair, l'intégration de virtuo pour booster les perfs de win10.

Elle est très bien cette première page .

Dîtes, entre jouer sous Linux à des jeux Windows via Wine et la possibilité de faire un MV win10 (car vous avez un faible GPU pour le Host), vous choisiriez quelle solution ?
 
J'ai la chance d'avoir une Rx560 pour le Host et Rx580 pour la MV et j'arrive pas à me décider.

tu n'as pas tenté de passthrough?

Bah c'est ce que je pourrais faire mais j'hésite à le faire...
Vu que je joue très peu, je ne sais pas si ça vaut le coup de le faire ou rester sur Wine

dans l'ordre je ferai ceci :

- chercher une version linux du jeu, ou un jeu linux dont la thématique est proche (un clone, une adaptation), il y a un topic unique sur les jeux linux et des sites dédiés
- si aucun clone n'existe : faire tourner le jeu sous wine
- en dernier recours : utiliser une machine virtuelle avec les trucs de type passthrough, mais risque d'usine à gaz et obligation d'avoir un PC performant

la plupart des éditeurs de jeux utilisent des frameworks pour coder leurs jeux (gain de temps et d'argent, éviter de réinventer la roue), ces frameworks sont souvent multiplateformes, et permettent de compiler une version du jeu pour chaque OS et console, ce qui fait que la dépendance à un OS n'est plus obligatoire,
https://fr.wikipedia.org/wiki/Liste_de_moteurs_de_jeu

lire aussi ces articles :
https://fr.wikipedia.org/wiki/Jeux_vid%C3%A9o_Linux
https://fr.wikipedia.org/wiki/Liste_de_jeux_Linux