kqemu devient libre, qemu 0.9.0

Posté par (page perso) . Modéré par Nÿco.
0
6
fév.
2007
Virtualisation
Fabrice Bellard, auteur (entre autres) de QEMU et KQEMU, vient de libérer KQEMU et de publier la version 1.3.0pre10 sous licence GPLv2 simultanément à la sortie de la version 0.9.0 de l'émulateur.

QEMU est un émulateur portable, permettant d'émuler de nombreuses plateformes (x86, x86_64, PPC, ARM, MIPS...) sur de nombreux systèmes. KQEMU est un module permettant d'exécuter nativement le code x86 sur x86, en se contentant de transformer ou d'intercepter les instructions qui auraient dû être privilégiées, permettant ainsi une amélioration importante de la performance par rapport à de l'émulation pure. Il s'agit d'une approche similaire à ce que fait VMware, produit propriétaire.

NdM : comme le précisait la dépêche DLFP au moment de la sortie, Fabrice Bellard avait promis de publier du code de KQEMU si une entreprise acceptait de le rétribuer financièrement.

NdM : Merci à Sytoka Modon pour avoir également proposé l'info. Contrairement à KVM, qui vient d'être intégré dans le noyau 2.6.20, QEMU & KQEMU ne nécessitent pas de support matériel particulier. De plus, KQEMU existe pour plusieurs système : Linux, Windows, FreeBSD, Solaris.

Fidèle à son habitude, Fabrice Bellard a fourni une documentation technique détaillée sur le fonctionnement interne de KQEMU.

Les changelogs sont également disponibles pour QEMU & KQEMU ; on notera les nouveautés principales suivantes :
  • qemu : entrées/sorties asynchrones ; concrètement, lorsque le système émulé fait des I/Os, son exécution continuera pendant que l'émulateur cherche les données correspondantes (utile par exemple si l'image disque est distante)
  • QEMU : gros travail sur l'émulation MIPS, notamment introduction d'une émulation de la plateforme "Malta"
  • QEMU : "Userspace emulation" pour Darwin et pour m68k (émulation des appels systèmes, sans émulation d'un système complet)
  • QEMU : support du boot PXE, pratique pour faire des tests de distributions démarrant sur le réseau
  • KQEMU : passage en GPLv2
  • KQEMU : support complet x86_64
  • # Vive l'open source !

    Posté par . Évalué à 10.

    Magnifique nouvelle. Merci Fabrice !!! Vraiment.
    • [^] # Re: Vive l'open source !

      Posté par (page perso) . Évalué à 10.

      Pas mieux. Merci Fabrice d'avoir honoré ta promesse et merci pour ce cadeau.
      • [^] # Re: Vive l'open source !

        Posté par . Évalué à 10.

        Au risque de paraître fort peu original: merci fabrice !
        • [^] # Re: Vive l'open source !

          Posté par (page perso) . Évalué à 10.

          C'est pas pour en remettre une couche mais j'utilise tellement souvent QEmu pour mon travail que cette nouvelle double (la sortie d'une nouvelle version et surtout la libération de kqemu) ne peut que me réjouir !
          Il n'est sûrement pas nécessaire de faire l'apologie de ce que cet acte apporte au monde libre mais soulignons quand même son importance !

          C'est vraiment un outil d'une très grande qualité, qui a des performances assez époustouflantes et qui n'a vraiment plus rien à envier à qui que ce soit !

          Encore merci Fabrice !
  • # Sponsor ou pas ?

    Posté par . Évalué à 10.

    Vu que ce n'est indiqué nulle part, y a-t-il eu un sponsor finalement ou pas ?
  • # Noyau Linux 2.6.20 et KVM

    Posté par (page perso) . Évalué à 10.

    On peut noter que l'architecture kvm qui vient d'être intégré dans le noyau 2.6.20 est basé sur une variation de qemu.

    Bref, sans gros tapage médiatique, qemu fait son bout de chemin et devient à chaque version de plus en plus incontournable.
    • [^] # Re: Noyau Linux 2.6.20 et KVM

      Posté par . Évalué à 3.

      C'est clair !!! Cette solution est géniale !

      Cependant, le principal inconvénient que je lui trouve est que la carte graphique émulée est une cirrus logic (= pas de 3D). Idem pour tous les autres composants qui sont vus par l'OS guest comme des composants virtuels QEmu et pas comme les vrais composants de la machine (ce qui signifie un overhead pour émuler le comportement de ces composants, alors que l'idéal serait d'exploiter le vrai matériel au plus près). En clair, j'aimerais bien jouer à Sim City 4 dans le windows émulé sous mon Linux !

      Dans la doc technique QEmu, il est dit
      "The commercial PC Virtualizers (VMWare [9], VirtualPC [10], TwoOStwo [11]) are faster than QEMU, but they all need specific, proprietary and potentially unsafe host drivers"
      Justement, je me demandais (pour avoir le meilleur des 2 mondes) s'il ne serait pas possible d'écrire le pilote (libre) pour windows d'une carte graphique 3D virtuelle qui se contenterait de relayer les appels GDI/OpenGL à QEmu... Je n'ai pas les connaissances requises pour écrire ça mais ça devrait bien être faisable, non ? Idem pour tous les autres composants (l'idée étant de paravirtualiser au maximum les drivers, comme Xen le fait pour Linux, BSD... mais pas windows).
      • [^] # Re: Noyau Linux 2.6.20 et KVM

        Posté par (page perso) . Évalué à 4.

        > ce qui signifie un overhead pour émuler le comportement de ces composants, alors que l'idéal serait d'exploiter le vrai matériel au plus près

        Non, à partir du moment où tu dois émuler, tu n'as (quasiment) aucun interêt à suivre ce qu'il y dessous.

        Une approche intéressante pour ce genre de problème est que l'émulateur fournisse un accès direct au matériel sous jacent. Cela est faisable en USB (qemu le fait, vmware également); cependant, en PCI, cela pose des problèmes de mapping mémoire et imposerait au mieux des drivers plus ou moins prévu pour (et c'est p-e même impossible dans certains cas). Je ne sais pas si les extensions VT & SVM apportent qqchose à ce niveau là (proxy de périphériques), mais je n'ai rien vu, donc je suis sceptique.

        Pour le cas de l'opengl, un patch était passé sur la mailing list : http://lists.gnu.org/archive/html/qemu-devel/2006-11/msg0014(...) . En gros, il s'agit d'un proxy opengl, qui fait passer les requêtes à l'host. Cela nécessite un support soft dans le client; je n'ai rien vu passer pour windows. Je crois que vmware le permet par contre.

        Quand à écrire des pilotes pour, c'est effectivement pratique comme approche, mais manifestement ça n'a intéressé personne suffisament :) p-e voir ce qu'il y a dans virtualbox. Cependant et comme tu le fais remarquer, à partir du moment où c'est pour un OS libre, vaut mieux tout adapter pour faire de la paravirtualisation (à la xen donc). Cela dit, pour le cas de l'affichage, ça reste problèmatique, vu que tu as très peu de marge sur ce que tu peux faire pour des questions de performance.
  • # www.VirtualBox.org

    Posté par . Évalué à 5.

    J'utilise VirtualBox qui est libre lui aussi, faut-il que je changes pour qemu maintenant ?
    • [^] # Re: www.VirtualBox.org

      Posté par . Évalué à 10.

      Un des avantages du libre ici, c'est que tu peux essayer les deux :-)
    • [^] # Re: www.VirtualBox.org

      Posté par (page perso) . Évalué à 2.

      J'ai testé aussi virtualbox, c'est très rapide, mais il plante quasiment à chaque fois que j'essaie de restaurer un "snapshot".
      Parfois il provoque même eu un reboot brutal de mon pc.

      La dernière fois que j'ai testé qemu (sans kqemu) c'était lent, mais ça plantait pas.
      • [^] # Re: www.VirtualBox.org

        Posté par (page perso) . Évalué à 1.

        Bizzare, j'utilise cette fonctionnalité sans arrêt tous les jours, et ça n'a jamais planté (d'ailleurs virtualbox n'a encore jamais planté pour ma part, et je l'utilise tous les jours depuis sa libération).
        • [^] # Re: www.VirtualBox.org

          Posté par . Évalué à 2.

          moi c'est pas virtualbox qui plante, c'est les os qui plantent dans virtualbox.

          J'ai testé openbsd 4.0, l'OS s'installe mais kernel panic au reboot
          ubuntu server (dapper LTS) plante à l'installation

          problèmes que je n'ai jamais eu ni avec vmware, ni qemu. Donc pour moi virtualbox est loin d'être mature.
  • # Vivement l'intégration dans Xen

    Posté par . Évalué à 4.

    Xen utilise un dérivé de qemu et ne permet actuellement l'exécution d'OS non modifiés que sur des architectures qui gèrent la virtualisation au niveau matériel. Je rêve d'un "Xen 4.0" intégrant un qemu 0.9 voire 1.0 et permettant enfin de faire tourner des OS non modifiés sans recourir nécessairement à des CPU super récents. Pour du recyclage de serveurs récents "mais pas assez pour gérer la virtualisation en hard", ce serait top...
  • # Parlons de performances

    Posté par . Évalué à 9.

    J'utilise surtout la virtualisation pour faire tourner un système propriétaire trop connu. Je voudrais donc savoir ce que vaut le couple qemu+kqemu par rapport à vmware, que j'utilise jusqu'à maintenant et qui me donne satisfaction (des performances honorables et une excellente ergonomie de l'interface utilisateur, modulo un module noyau propriétaire) dans l'objectif de faire tourner plusieurs versions de windows (sur du x86) donc.

    Maintenant que kqemu est libre, on pourra l'avoir par défaut dans les systèmes de paquetage des distributions sans avoir à s'embêter, et c'est très bien. Car qemu seul ne répondait pas à mon besoin.

    - Peut-on paramétrer finement les ressources mobilisées sur le système hôte ?
    - Y a t-il une compatibilité au niveau des fichiers entre les deux applications, pour permettre d'utiliser facilement une machine virtuelle de l'un sur l'autre ?
    - Enfin, pour ceux qui ont testé, windows (et quelles versions ?) se comporte t-il bien ainsi virtualisé (je pense notamment à la reconnaissance des périphériques virtuels tels que la carte graphique, ainsi qu'aux restrictions qui peuvent en découler pour les applications, telles que les jeux DirectX ? VMware commençant à offrir un support DirectX au stade expérimental...).

    Merci.
    • [^] # Re: Parlons de performances

      Posté par . Évalué à 7.

    • [^] # Re: Parlons de performances

      Posté par (page perso) . Évalué à 5.

      > Maintenant que kqemu est libre, on pourra l'avoir par défaut dans les
      > systèmes de paquetage des distributions sans avoir à s'embêter, et c'est très
      > bien.

      Il y avait deja des paquets pour certaines distributions.

      Par exemple, je me souvient que ça fait un an que le plf ( http://plf.zarb.org ) distribue un paquet dkms-kqemu dans le dépot non-free pour mandriva, ce qui a permis une intégration trés rapide dans cooker ( ie, j'ai la joie de découvrir que le paquet est déja ce matin dans contribs )
  • # émulation ? virtualisation ?

    Posté par . Évalué à 2.

    quelqu'un sait si ce genre de logiciel permet de faire tourner un windows existant (Win XP en double boot) dans une fenêtre sous linux ?
    • [^] # Re: émulation ? virtualisation ?

      Posté par (page perso) . Évalué à 6.

      sachant que qemu expose des périphériques virtuels différents de ceux de ta machine, windows risque de pas trop comprendre au démarrage quand il va voir que tous ses periphs ont changé. Mais techniquement oui c'est possible, bien que je ne te le conseille pas.
    • [^] # Re: émulation ? virtualisation ?

      Posté par (page perso) . Évalué à 4.

      ce genre d'approche existe avec Parallels sur Mac OS X

      en effet Parallels permet de faire tourner un Windows virtualisé dans Mac OS mais il est également possible de faire tourner un Windows directement avec BootCamp.

      Il est même possible que le système qui tourne avec Parallels soit sur la partition Windows qui peut alors soit démarrer avec BootCamp... soit dans Mac OS avec Parallels...


      bon je vois que je ne suis pas clair...

      http://www.macgeneration.com/mgnews/depeche.php?aIdDepeche=1(...)
      • [^] # Re: émulation ? virtualisation ?

        Posté par . Évalué à 2.

        Il est même possible que le système qui tourne avec Parallels soit sur la partition Windows qui peut alors soit démarrer avec BootCamp... soit dans Mac OS avec Parallels...


        bon je vois que je ne suis pas clair...


        si, si, c'est très clair, c'est exactement ce que je souhaiterais faire. (mais pas sous Mac ^^)
    • [^] # Re: émulation ? virtualisation ?

      Posté par . Évalué à 2.

      Je l'ai déja fait avec un linux en système invité, ça doit donc être faisable avec un Windows sans trop de problèmes.
      Juste un conseil : fait attention à ne pas laisser les partitions utilisées par windows montées sous linux ...
  • # gcc 4

    Posté par . Évalué à 6.

    Je sait qu'il y avait des problème de compilation avec gcc 4 quand est il avec cette nouvelle version ? Parce que avoir qemu compilé avec gcc 3 et kqemu avec gcc 4 j'avais nettement l'impression que ça tournais beaucoup moins vite que qemu et kqemu en gcc3 d'où mon passage a vmware.
  • # interface graphique comme VirtualBox

    Posté par . Évalué à 3.

    Existe-t-il une interface graphique aussi simple à utiliser que celle de VirtualBox pour Qemu?

    Et au fait outre le nombre de plateforme emulé, quelles sont les principales différences avec VirtualBox?
    • [^] # Re: interface graphique comme VirtualBox

      Posté par . Évalué à 1.

      Sur Windows y'a QemuManager qu'est excellent...
      Pour linux je crois que c'est Kqemu (Kde Qemu), il est moins convivial mais devrait s'améliorer avec le temps
      • [^] # Re: interface graphique comme VirtualBox

        Posté par . Évalué à 3.

        pas bien malin d'avoir choisi kqemu pour ce projet kde... même si en toute logique on rajoute des k partout, vu que le module kqemu a le même nom...

        pour qemu, est-ce qu'il est possible d'utiliser des images vmware sans les convertir complètement (par exemple pour passer de l'un à l'autre), et enfin est-ce qu'il est possible d'avoir une gestion simple du réseau ?

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: interface graphique comme VirtualBox

          Posté par (page perso) . Évalué à 4.

          L'interface KDE existait avant le module de même nom.

          Pour ce qui est des images vmware, oui qemu sait les utiliser.

          Pour ce qui est du réseau, ca dépend de tes besoins. Si tu veux que tes OS puissent faire du tcp/ip, ca marche tout seul. Si tu veux un vrai réseau, et que par exemple le ping passe, il va falloir configurer à la main (ou utiliser une interface le proposant, ou récupérer un script). Tu peux assez facilement par exemple bridger tes qemu comme ca ils prennent leur propre IP et si t'as un serveur DHCP sur ton réseau ca marche tout seul. Tu peux aussi faire du NAT ou n'importe quoi d'autre que Linux te permet de faire (je suppose que tu lances qemu sous linux :) ).
        • [^] # Re: interface graphique comme VirtualBox

          Posté par (page perso) . Évalué à 1.

          Pour la gestion simple du reseau je recommande VDE

          http://sourceforge.net/projects/vde/
    • [^] # Re: interface graphique comme VirtualBox

      Posté par . Évalué à 3.

      Sous OS X, il y a l'excellent Q (http://www.kju-app.org/kju/ ). Faudrait voir ce qu'il y a dedans, mais un portage pourrait peut-être s'envisager (genre via GNUstep si c'est du Cocoa "propre").
    • [^] # Re: interface graphique comme VirtualBox

      Posté par . Évalué à 2.

      y'a qemoon qui fonctionne pour windows et linux.
      c'est un projet encore en alpha mais ça suffit pour configurer et lancer une vm.
      c'est développé en java (eclipse rcp).
  • # whooooohohohoho !!!!

    Posté par . Évalué à -7.

    whooooohohohoho !!!! il a enfin finit par le lacher !!! :-D
    Depuis le temps !
    On va enfin pouvoir avoir un système d'emulation performant dans les distrib linux sans se retaper la compilation de module.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.