Passant directement de la version 0.7.2 à la version 1.3.0pre5, alors que la version officielle de qemu est la 0.8.0, ce module nous propose rien que moins que la virtualisation complète d'un OS (système d'exploitation).
Petit rappel : qemu est un émulateur qui fonctionne sous deux modes : émulation d'un système complet ou émulation sous Linux d'un programme conçu pour un autre CPU (par exemple, cela permet de faire tourner wine sous PowerPC sans avoir à installer une machine virtuelle).
La nouvelle version du module d'extension non libre kqemu nous propose deux modes :
- le mode normal où les applications utilisateurs sont transmises telles quelles au CPU d'où un gain très appréciable de temps, le noyau de l'OS virtuel étant émulé dans la machine qemu
- le nouveau mode de virtualisation complète (full virtualization mode). Dans ce mode, les applications utilisateurs mais aussi l'OS de la machine virtuelle sont directement exécutés par le CPU !
Les gains de temps à espérer de ce dernier mode vont faire du couple qemu+kqemu un outil indispensable (s'il ne l'était déjà). D'après Fabrice Bellard, cette virtualisation ne fait courir aucun risque à la machine hôte. Cependant, tous les OS ne peuvent pas forcément fonctionner sous ce mode. Linux, Windows 2000 et XP ont déjà été validés.
Avec qemu au coté de Xen, la virtualisation des systèmes d'exploitation devient chaque jour une réalité à la portée de tous.
NdM : Qemu est libre et sous licence GPL, mais le module d'accélération est propriétaire, voir license.html.
Aller plus loin
- Annonce sur le site de qemu (38 clics)
- Documentation du module kqemu (83 clics)
- Téléchargement du module kqemu (257 clics)
- Site de Xen (13 clics)
# Attention à la version de Qemu
Posté par djibb (site web personnel) . Évalué à 7.
Attention donc :)
Bon Download, bons essais, et bravo Fabrice.
[^] # Re: Attention à la version de Qemu
Posté par Ontologia (site web personnel) . Évalué à 2.
http://fabrice.bellard.free.fr/qemu/download.html
On apprend là http://fabrice.bellard.free.fr/qemu/kqemu1-doc.html qu'il faut recompiler le noyau, c'est personnelement, ce qui me bloque. Pas envie de repartir dans les galères.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Attention à la version de Qemu
Posté par rahan . Évalué à 7.
./configure
make
[^] # Re: Attention à la version de Qemu
Posté par Ontologia (site web personnel) . Évalué à 2.
[root@localhost kqemu-1.3.0pre5]# /sbin/modprobe kqemu
FATAL: Error inserting kqemu (/lib/modules/2.6.12-12mdk/misc/kqemu.ko): Invalid module format
J'ai pourtant bien compilé avec le gcc utilisé pour compiler le noyau (le noyau obèse standard de la distrib), j'ai laissé les sources telles que fournies...
Je comprend pas.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Attention à la version de Qemu
Posté par Ontologia (site web personnel) . Évalué à 2.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Attention à la version de Qemu
Posté par ErrTu . Évalué à 1.
Pour en savoir un peu plus, regarde les derniers messages de log avec : dmesg
[^] # Re: Attention à la version de Qemu
Posté par Pierre . Évalué à 5.
Sinon, tu installe les kernel-header de ta dstrib et ca marche.
# Pourquoi propriétaire?
Posté par Pierre . Évalué à 9.
kqemu est propriétaire jusqu'à ce qu'il trouve des sponsors assez importants pour lui permettre d'etre sur d'en vivre.
source wikipedia:
Fabrice, on te fait confiance pour ne pas être trop gourmand, et pour refuser les propositions de VMWare pour racheter son code afin de le tuer..
[^] # Re: Pourquoi propriétaire?
Posté par Cali_Mero . Évalué à 10.
[^] # Re: Pourquoi propriétaire?
Posté par chaperon . Évalué à 3.
D'après ce que je comprends, il ne vendra le code (ou le droit de l'utiliser) à personne. Il veut récolter une certaine somme, à partir de laquelle il libèrera le code.
Donc, d'après ce que je comprends (et je peux comprendre de travers), si VMWare sponsorise kqemu, kqemu deviendra libre, et non pas propriété de VMWare.
Si c'est bien ce que j'ai compris, alors je trouve le modèle très réglo, surtout que le module proprio est gratuit (ce qui n'est pas rien).
[^] # Re: Pourquoi propriétaire?
Posté par Anonyme . Évalué à 4.
Son travail vaut facillement une bonne centaine de milliers d'euros, s'il vend le code et cède tous les droits (enfin c'est évalué à la louche, comme n'importe quel code :) , mais personnellement je viserais pas plus bas si j'avais pondu un truc pareil - à bon entendeur, fabrice :) - ), ca laisse à réfléchir.
Le libre protège les utilisateurs, mais aussi l'auteur de ses propres états d'ames, et c'est ce qui fait que ca marche si bien : les mauvaises surprises très très rares.
[^] # Re: Pourquoi propriétaire?
Posté par Sytoka Modon (site web personnel) . Évalué à 5.
Si on ne sais pas la somme qu'il souhaite, ni le valeur du compteur à un instant t, qui irait donner de l'argent. Le module se développant, la somme souhaité augmente...
Bref, on n'a aucun moyen de savoir où on en est, et ce point là est effectivement génant.
Surtout que j'ai lu hier que le module libre qvm86 pouvait aller aussi vite que l'ancien module kqemu dans certain cas, il est donc un peu bête que ce module ne soit pas intégré en standard dans qemu. On arrive à la limite de la logique du semi-libre où un module non libre est privilégié devant un module libre, du seul fait du principal (et génial) développeur.
[^] # Re: Pourquoi propriétaire?
Posté par Thomas Douillard . Évalué à 2.
Chippotage : après aussi, mais ce qui a déja été diffusé en libre le reste.
# Les vieux OS
Posté par salvaire . Évalué à 4.
# demande d'explications
Posté par dark_moule . Évalué à 7.
quelles sont les relations entre qemu, kqemu et xen ?
kqemu semble faire partie de qemu mais je ne sais pas si xen est un projet différent ou non. L'article indique "Avec qemu au coté de Xen" ce qui me laisse penser que les deux sont liés mais je n'ai pas trouvé d'info sur les sites donnés.
bref, est ce qu'une personne charitable pourrait m'éclairer sur ce point. Et si c'est possible, m'indiquer les avantages/inconvénients de qemu et xen.
[^] # Re: demande d'explications
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Qemu était (et est toujours) un émulateur, au même titre que boch. Qemu tourne en espace utilisateur (c'est une application standard). Cependant, depuis quelque temps, il y a un module noyau, kqemu, qui permet d'accélérer le code qui tourne en espace utilisateur dans la machine virtuelle (il y en a même un autre qvm86 si mes souvenirs sont bons qui est libre mais moins performant). Conclusion, jusqu'a il y a peu, avec qemu+kqemu, on lancait une machine virtuelle et tout le code des applications dans la machine virtuelle était directement envoyé au CPU de la machine réelle, seul le code du noyau virtuel était émulé (donc aussi tous les appels systèmes que l'on trouve dans une application).
Xen virtualise un système. Ce n'est pas un émulateur. Donc avec Xen, on lance des machines virtuelles et Xen se charge de la répartition des ressources physiques, notament du CPU, pour chacune des machines virtuelles. Dans Xen, le code noyau ainsi que les applications des machines virtuelles sont directement exécutés par le CPU de la machine réelle. En pratique, avec Xen, les applications tournent quasiment aussi vite dans une machine virtuelle que si elles étaient directement exécutés sur une machine normale. Au niveau des serveurs, c'est très intéressant, il vaut bien mieux virtualiser. C'est bien plus souple dans ces conditions.
Maintenant, avec la dernière version de kqemu, on peux faire de la virtualisation complète, même du code noyau ! Donc qemu marche un peu sur les plate-bande de Xen. D'où ma remarque finale et le lien entre les deux projets.
Cependant, il ne faut pas se tromper. En production, avec des machines virtuelles, il faut être capable d'attribuer des ressources aux différentes machines, de superviser en temps réel. Je ne suis pas sur que les deux projets soit comparable de ce point de vue là aujourd'hui.
[^] # Re: demande d'explications
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
Oui enfin il y a quand même des bouts de qemu qui servent à xen :-)
[^] # Re: demande d'explications
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Je ne sais pas comment Fabrice Bellard à mis en place la virtualisation dans kqemu mais je ne serais pas étonné qu'il se soit inspiré des idées implémentées dans Xen.
[^] # Re: demande d'explications
Posté par poil . Évalué à 10.
Je vais essayer de répondre... Que quelqu'un me corrige si je dis une connerie !
ring 0 : mode noyau. Tout est permis. Si on fait des conneries en ring 0, on doit rebooter en gros =)
ring 1 : on permet un peu moins de choses.
ring 3 : mode utilisateur. On permet beaucoup moins de choses : par exemple, si une appli en ring 3 veut écrire à un emplacement mémoire où elle a pas le droit => L'OS l'interrompt (ça segfault =). Et comme ça seule l'appli plante, pas tout le système.
(Qemu+kqemu) et Xen sont 2 solutions différentes de virtualisation.
Le but de la virtualisation est de pouvoir exécuter directement (ou avec quelques modifications) le code des OS invités sur le processeur de l'OS hôte (c'est-à-dire sans passer par une émulation).
Fonctionnement de Xen :
Xen est en ring 0 et les noyaux des OS invités sont en ring 1. C'est donc Xen qui attribue les ressources aux OS invités. Cela fait qu'il faut modifier les OS que l'on veut faire tourner sur un Xen. (Et ça pose problème avec Windows parce qu'il faudrait modifier son code source...)
Fonctionnement de Qemu+keqmu avant :
On ne modifie pas les OS invités. On va juste transformer le code qui pose problème (le code en ring 0 notamment) en un code équivalent qui pourra tourner en ring 3. Et on rappelle ce bloc de code recompilé dynamiquement à chaque fois à la place du code qui a posé problème.(Et il y a aussi un superviseur qui gère la mémoire, les interruptions de l'OS invité, ainsi que le passage en mode exécution directe ou recompilation dynamique...). La même chose que VMWare en gros.
Fonctionnement de Qemu+kqemu maintenant (à vue de nez) :
On y va en bourrin. On ne transforme plus le code qui pose problème et on croise les doigts pour que ça marche. Ça fait que si un OS (ou un driver) utilise une instruction asm qui renvoie un résultat différent en ring 0 et en ring 3, ça va bugger :/
Mais de toute façon, beaucoup de choses vont changer d'ici peu de temps avec l'apparition de la virtualisation matérielle dans le processeur (technologies Vanderpool chez Intel et Pacifica chez AMD). Là, le processur virtuel est directement dans le processeur physique. Ça fait que pour Xen, on ne devrait plus avoir à faire de modifs dans le code des OS invités. (Y aura juste un driver dans la machine hôte et voilà). Et pour UML (User Mode Linux), on pourrait faire tourner un UML en ring 0 et le voir comme un processus sur la machine hôte...
[^] # Re: demande d'explications
Posté par Ph Husson (site web personnel) . Évalué à 3.
Merci
(Nan parce que bon parler de virtualisation ici est pour moi idiot)
En fait qemu fonctionne maintenant comme VMware c'est bien ca (j'avais lu qu'ils avaient trouvé une astuce pour rester au meme niveau en permanence)?
[^] # Re: demande d'explications
Posté par dark_moule . Évalué à 5.
# Non libre
Posté par HappyPeng . Évalué à 4.
Passez-moi le discours sur "les développeurs ont besoin de vivre", "il a le droit d'être rémunéré pour son travail" et tout ce qui a déjà été dit pour les chanteurs et autres.
Je parle du concept même de logiciel libre : la liberté ne se soumet à aucun chantage financier selon moi.
[^] # Re: Non libre
Posté par djibb (site web personnel) . Évalué à 2.
The QEMU Accelerator Module is a proprietary product. It is available without charge. Commercial use of the QEMU Accelerator Module is allowed.
Donc, le fait n'est pas là, ce n'est pas un problème financier. Je pense plutôt que c'est une sorte de protection, à savoir que si ça doit tomber entre des mains, ce sera pas du proprio, car ils ne peuvent pas savoir ce qu'il y a dedans. Si Fabrice Bellard pense que ce projet peut avoir des potentialités importantes en terme de $$ et bien il a raison.
La liberté du logiciel est un peu écornée, et on rentre dans le domaine du freeware (pas du shareware). Mais si des industriels passent pas là, ils sauront ce que kqemu peut apporter et en l'occurence, faire des efforts de participation au projet.
Tout est logique. Le libre pour le libre est intéressant, très éthique. Mais, laisser une possiblité de virtualisation (importante en milieu industriel) de se faire piquer (voir les sites de violation pour GPL) est au moins aussi dérangeant.
Moi, pauvre utilisateur, je suis content : Qemu + Kqemu font tourner mon XP pour mon logiciel de notes. Il est pas libre ???? pas grave, il le sera un jour, c'est prévu.
[^] # Re: Non libre
Posté par HappyPeng . Évalué à 10.
Parce qu'en poursuivant ton raisonnement on en arrive à penser qu'il faudrait mettre sous des licences propriétaires les "joyaux" du logiciel libre pour les protéger ou pour en garder l'exclusivité... ce qui revient à penser que les licences propriétaires protègent l'innovation en protégeant le secret, en quelque sorte.
Ca n'est pas ma conception du logiciel libre.
[^] # Re: Non libre
Posté par snt . Évalué à -1.
[^] # Re: Non libre
Posté par HappyPeng . Évalué à 3.
[^] # Re: Non libre
Posté par lolop (site web personnel) . Évalué à 4.
Je comprend très bien que qq'un qui a développé qq chose qui pourrait lui rapporter se protège pour ne pas la perdre.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Fonctions supplémentaires, un jour, qui sait
Posté par Sabinou . Évalué à 3.
Imaginez que vous fassiez parfaitement tourner avec qemu un logiciel non-émulable par wine, ou dédié à un OS autre que windows. Vous avez accès en lecture/écriture sur, disons, une vraie partition fat32 où il y a les documents de travail. Vous faites aussi des copier-coller, et l'OS hôte met dans son presse-papiers le contenu du presse-papiers de qemu, afin de faciliter les transferts de données...
Cela ce sera dans un futur lointain je pense, mais ça serait vraiment utile, je trouve ^^ Cela viendra peut-être un jour ^^
[^] # Re: Fonctions supplémentaires, un jour, qui sait
Posté par M . Évalué à 2.
[^] # Re: Fonctions supplémentaires, un jour, qui sait
Posté par Leroy Frederic (site web personnel) . Évalué à 6.
Depuis la version 8.0 tu peux utiliser l'option -hdx fat:/path/to/directory pour pouvoir accèder à tes documents.
Et si je ne me trompe pas depuis la 8.1 tu peux utiliser -hdx fat:rw;/path/to/directory pour avoir l'accès en lecture/ecriture.
J'ai déjà essayé, ça marche malgrès des plantages assez fréquents sur ma machine, mais je ne sais pas si c'est dû à l'os emulé (w95), à la plateforme (ppc) où à qemu.
# CVS : Ce n'est pas précisé
Posté par Michel Petit (site web personnel) . Évalué à 2.
cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/qemu co qemu
Site ici : http://savannah.nongnu.org/cvs/?group=qemu
voila, bonne compil' à tou(te)s !
[^] # Re: CVS : Ce n'est pas précisé
Posté par matrox . Évalué à 1.
Je viens de récupérer la version CVS. Mais apparemment, c'est toujours la version 0.8.0, et non pas la version 0.8.1 :
$ cat /usr/local/src/qemu/VERSION
0.8.0
J'ai quand même essayé de compiler tout cela après avoir compilé et installé correctement KQEMU 1.3.0pre5, mais je n'ai pas cette fameuse nouvelle option (-kernel-kqemu) :
$ dmesg
qemu: module license 'Proprietary' taints kernel.
QEMU Accelerator Module version 1.3.0, Copyright (c) 2005-2006 Fabrice Bellard
This is a proprietary product. Read the LICENSE file for more information
Redistribution of this module is prohibited without authorization
KQEMU installed, max_locked_mem=514308kB.
$ qemu -h | grep kqemu
-no-kqemu disable KQEMU kernel module usage
Si quelqu'un a réussi, je serais intéressé...
[^] # Re: CVS : Ce n'est pas précisé
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
Passes dans la console de qemu après le lancement (Ctrl+Alt+2) et tapes info kqemu.
Ca te dira un trucs genre "acceleration enabled for user mode" sans -kernel-kqemu et ca ajoutera "and kernel" si tu as l'option.
[^] # Re: CVS : Ce n'est pas précisé
Posté par matrox . Évalué à 2.
Si ça peut motiver d'autres personnes à tester cette nouvelle version, voici un petit test avec Windows XP Professionel :
- Sans -kernel-kqemu, le boot prend environ 1 minute.
- Avec -kernel-kqemu, le boot prend environ 20 secondes.
C'est assez incroyable !
Encore bravo à Fabrice pour son travail !
[^] # Re: CVS : Ce n'est pas précisé
Posté par Yannick (site web personnel) . Évalué à 1.
C'est à cause de ce genre d'enm..de que je n'utilise pas vraiment qemu. C'est dommage.
Note pour d'autres commentaires : Pour utiliser gcc 3, j'ai seulement modifié les variables positionnées à "gcc" en "gcc-3.4" dans le fichier configure.
[^] # Re: CVS : Ce n'est pas précisé
Posté par Cali_Mero . Évalué à 3.
Hope this helps.
[^] # Re: CVS : Ce n'est pas précisé
Posté par Yannick (site web personnel) . Évalué à 1.
Aprés avoir compris qu'il ne faut pas lancer qemu dans une console (ALT+F1) mais dans un terminal sous X (désolé), et une bidouille de contrôle dans les sources de qemu, j'ai constaté, pour un boot de windows 2000 (P3-900MHz):
- Sans kqemu : 4m
- Avec qemu : 3m50s
- Avec kqemu et l'option -kernel-kqemu (que j'avait oublié sur le coup) moins de 1m30s.
Je commence a comprendre pourquoi j'avait jamais constaté de différence avec et sans kqemu dans les versions précédentes...
Eh, mais c'est que je vais enfin pouvoir l'utiliser !
En tout cas, merci pour le tuyau.
[^] # Re: CVS : Ce n'est pas précisé
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Tout cela est bien subjectif mais heureusement, il n'y pas pas que les chiffres pour nous guider.
[^] # Re: CVS : Ce n'est pas précisé
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
http://www.dad-answers.com/qemu/
Il y a une image réalisée quasiment toutes les nuits. Par exemple
qemu-snapshot-2006-03-30_23.tar.bz2
[^] # Re: CVS : Ce n'est pas précisé
Posté par Yaz . Évalué à 1.
[^] # Re: CVS : Ce n'est pas précisé
Posté par djibb (site web personnel) . Évalué à 2.
ln -sf /usr/bin/gcc-3.3.6 /usr/bin/gcc
tu compiles Qemu
Puis :
ln -sf /usr/bin/gcc-4.0.3 /usr/bin/gcc
et la, tu compiles Kqemu.
Ca te permet d'avoir un GCC qui es tle meme que celui avec lequel tu as compilé ton noyau (sinon... ca peut merdouiller)
NB : bien sur, les version de GCC, c'est chez moi faut faire avec les tiennes ;)
NB2 : J'ai essayer cette nouvelle version -> Quansiement aucun ralentissement par rapport au XP de base. Le seul truc qui manque c'est l'acceleration 3D.
[^] # Re: CVS : Ce n'est pas précisé
Posté par shinobufan (site web personnel) . Évalué à 5.
# Accès matériel ?
Posté par THE_ALF_ . Évalué à 2.
ces techniques de virtualisations ont-elles du coup accès direct au matériel, et ainsi permettre d'utiliser les drivers de l'OS virtualisé pour faire tourner un matériel non supporté par l'OS hôte ? J'imagines bien sur que même dans ce cas, seules les applications de l'OS virtualisé auront accès à ce matos (à moins qu'il y ait moyen de faire communiquer les différentes applis entre elles ?).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.