Virtualisation complète avec kqemu

Posté par  (site web personnel) . Modéré par Jaimé Ragnagna.
0
31
mar.
2006
Noyau
Fabrice Bellard a encore frappé, lundi 27 mars est sortie une nouvelle version de kqemu, le module noyau d'accélération de qemu.

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

  • # Attention à la version de Qemu

    Posté par  (site web personnel) . Évalué à 7.

    Cette version de Kqemu semble ne fonctionner qu'avec la version 0.8.1 de Qemu. Ceci correspond en fait à la version CVS.

    Attention donc :)

    Bon Download, bons essais, et bravo Fabrice.
    • [^] # Re: Attention à la version de Qemu

      Posté par  (site web personnel) . Évalué à 2.

      Cela ne marche effectivement qu'avec la version CVS : New version with full virtualization support - use only with the current QEMU CVS (documentation)
      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  . Évalué à 7.

        Pas la peine de recompiler le noyau si tu as les entêtes de présente, tu n'as que le module à compiler par un :
        ./configure
        make
        • [^] # Re: Attention à la version de Qemu

          Posté par  (site web personnel) . Évalué à 2.

          Alors j'ai essayé, en utilisant le make instal (donc le install.sh) sur ma mandriva 2006. Je récolte :
          [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  (site web personnel) . Évalué à 2.

            J'ai eu un problème avec gcc semble t-il : il a utilisé la mauvaise version. En le forçant, tout est rentré dans l'ordre

            « 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  . Évalué à 1.

            Tu essayes de charger un modules compilé avec une version de gcc différente de celle utilisée pour compiler le noyau donc ça coince.
            Pour en savoir un peu plus, regarde les derniers messages de log avec : dmesg
      • [^] # Re: Attention à la version de Qemu

        Posté par  . Évalué à 5.

        Non, en fait il faut juste installer les bons headers aux bon endroit sur la redhat 9.

        Sinon, tu installe les kernel-header de ta dstrib et ca marche.
  • # Pourquoi propriétaire?

    Posté par  . Évalué à 9.

    Rappelons avant que le troll gronde trop fort que Fabrice innove encore une fois en inventant un nouveau business model pour le LL.

    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 Bellard has stated his willingness to open-source the kqemu QEMU Accelerator module in case a company steps up to sponsor it. This has thus far not happened, and kqemu remains proprietary. It is free to use, but one is not allowed to distribute it to other people without an explicit authorisation. Distributors wishing to include the QEMU accelerator on CDs, ISO images or packages must contact the author to know the exact terms.


    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  . Évalué à 10.

      D'un autre côté on est bien obligés de lui faire confiance... C'est toute la magie du propriétaire (même jusqu'à nouvel ordre) !
    • [^] # Re: Pourquoi propriétaire?

      Posté par  . Évalué à 3.

      Ce buisness-model m'a l'air bien, du moins de la façon dont je le comprends.

      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  . Évalué à 4.

        Oui mais tant que le code n'est pas libre, il peut être racheté ... Peut être que Fabrice a prévu de libérer le code s'il recoit suffisament de sponsoring, et c'est une bonne chose, mais peut être qu'il recevera des propositions qui pourraient lui faire revoir sa position.

        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  (site web personnel) . Évalué à 5.

          Un des problèmes est que Fabrice n'est pas très clair. A une époque, il parlait d'une certaine somme d'argent pour libérer le code. Combien ?

          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  . Évalué à 2.

          Oui mais tant que le code n'est pas libre, il peut être racheté


          Chippotage : après aussi, mais ce qui a déja été diffusé en libre le reste.
  • # Les vieux OS

    Posté par  . Évalué à 4.

    Pour un os comme NT, qui ne supporte pas le matériel récent. Seul le mode émulé est possible? Je suppose qu'il est difficile d'isoler le code pouvant tourner librement sur l'os et celui devant tourner sur l'hôte virtuel.
  • # demande d'explications

    Posté par  . Évalué à 7.

    houla je ne suis pas un adepte de la virtualisation et je suis assez perdu.

    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  (site web personnel) . Évalué à 10.

      Qemu et Xen n'ont aucun rapport en tant que projet.

      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  (site web personnel) . Évalué à 3.

        Qemu et Xen n'ont aucun rapport en tant que projet.
        Oui enfin il y a quand même des bouts de qemu qui servent à xen :-)
        • [^] # Re: demande d'explications

          Posté par  (site web personnel) . Évalué à 4.

          De même qu'il y a des bouts de boch dans qemu (au niveau du driver de la carte reseau et de la carte vga si mes souvenirs sont bons). Il serait idiot de ne pas reprendre du code qui marche bien et de ne pas en profiter pour l'améliorer au passage.

          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  . Évalué à 10.

      Tiens, quelqu'un a déjà répondu pendant que j'étais en train de taper... Tant pis, je poste quand même =)

      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  (site web personnel) . Évalué à 3.

        Enfin une explication claire!
        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  . Évalué à 5.

      Merci pour vos 2 réponses très complètes. Je comprend même maintenant la différence entre émulation et virtualisation !
  • # Non libre

    Posté par  . Évalué à 4.

    Moi je ne suis pas un adepte de son "business model"... On en revient presque à l'époque du shareware, c'est un peu triste.

    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  (site web personnel) . Évalué à 2.

      Le chantage n'est absolument pas financier :
      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  . Évalué à 10.

        Laisser du propriétaire se faire piquer par du propriétaire...

        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  . Évalué à -1.

      Je suis tout à fait d'accord avec toi : je n'utilise d'ailleurs pas le module non libre à cause de sa licence. Et je brule d'impatience que tu aies terminé ton travail sur un module libre equivalent et que tu le fournisses à la communauté.
      • [^] # Re: Non libre

        Posté par  . Évalué à 3.

        Le principe des valeurs n'est pas de les sacrifier dans le but de l'efficacité.
    • [^] # Re: Non libre

      Posté par  (site web personnel) . Évalué à 4.

      Mais, si tu n'es pas d'accord avec la façon dont il le diffuse, tu n'es pas obligé de l'utiliser. Il en est l'auteur, et il le diffuse sous la forme qu'il veut.

      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  . Évalué à 3.

    Moi j'attends avec impatience le jour où sera proposée une fonction supplémentaire, en ajout à qemu, cad le transfert facile de documents entre l'OS virtualisé et le vrai OS faisant tourner qemu.

    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  . Évalué à 2.

      Pour la partition il suffit de creer une partition partagée sur un reseau du type NFS, samba, CIFS et tu devrais etre comblé...
    • [^] # Re: Fonctions supplémentaires, un jour, qui sait

      Posté par  (site web personnel) . Évalué à 6.

      Tu peux déjà faire des transferts sans trop de problèmes et sans réseau.

      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  (site web personnel) . Évalué à 2.

    Comme le CVS n'est pas indiqué sur le site de free et dans la news, je me permet de mettre ici ce qu'il faut pour y acceder :

    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  . Évalué à 1.

      Est-ce que quelqu'un a réussi à compiler cette nouvelle version correctement ?

      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  (site web personnel) . Évalué à 2.

        L'option n'apparait pas dans -h actuellement, mais elle marche chez moi.
        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  . Évalué à 2.

          En effet, c'est bien ça. Merci pour ton aide.

          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  (site web personnel) . Évalué à 1.

        Moi, je n'ai eu aucun problème a compiler le snapshot 20060331 de qemu sur ma debian testing, mais pour kqemu, y'a pas moyen. Et je ne vois pas comment faire... Visiblement, il ne trouve pas les headers alors qu'ils sont bien là, et l'emplacement bien précisé au lancment de make...
        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  . Évalué à 3.

          J'ai eu le même problème que toi. On m'a répondu sur IRC que sur certaines distributions, notamment celles basées sur Debian (dont ubuntu), quelquechose (j'ai oublié quoi exactement) empêche la compilation de kqemu avec les headers du noyau seuls. Il te faut les sources complètes du noyau pour y arriver et donc le recompiler.

          Hope this helps.
          • [^] # Re: CVS : Ce n'est pas précisé

            Posté par  (site web personnel) . Évalué à 1.

            J'ai retenté. Résultat : Il semble effectivement qu'il faille des fichiers intermediaires de la compilation du noyau pour que ça marche (A ma première tentative, j'avait les .c et .h brut de tar.gz). J'ai enfin pu compiler le module.
            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  (site web personnel) . Évalué à 2.

              Pour l'avoir enfin essayer avec XP sous Linux+qemu+kernelkqemu..., je peux dire que XP est BEAUCOUP plus reactif avec cette nouvelle version. Je ne vois quasiment pas la différence avec un Windows natif.

              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  (site web personnel) . Évalué à 4.

      Personnellement, je récupère qemu sur

      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  . Évalué à 1.

      Ca compile pas avec GCC 4.0 par contre....
      • [^] # Re: CVS : Ce n'est pas précisé

        Posté par  (site web personnel) . Évalué à 2.

        non, il faut gcc 3 pour compiler qemu.

        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.
  • # Accès matériel ?

    Posté par  . Évalué à 2.

    Tiens, une question:

    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.