Attention à la version de Qemu

• [^]Re: Attention à la version de Qemu

  Posté par Ontologia (page perso, ) le 31/03/2006 à 14:52. (lien). É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.

  • [^]Re: Attention à la version de Qemu

    Posté par rahan () le 31/03/2006 à 15:02. (lien). É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 Ontologia (page perso, ) le 03/04/2006 à 16:53. (lien). É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.

      • [^]Re: Attention à la version de Qemu

        Posté par Ontologia (page perso, ) le 03/04/2006 à 19:22. (lien). É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

      • [^]Re: Attention à la version de Qemu

        Posté par Colin D. (Jabber id, page perso, ) le 03/04/2006 à 20:41. (lien). É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 lordcow () le 31/03/2006 à 15:03. (lien). É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.

    --
    Je est un autre.

Pourquoi propriétaire?

• [^]Re: Pourquoi propriétaire?

  Posté par Cali_Mero () le 31/03/2006 à 15:01. (lien). É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) !

  --
  #define MAGIC 0xdefaced /* I should've patented this number -cliph */

• [^]Re: Pourquoi propriétaire?

  Posté par chaperon () le 01/04/2006 à 14:07. (lien). É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).

  --
  man man, man !

  • [^]Re: Pourquoi propriétaire?

    Posté par √λιi () le 02/04/2006 à 08:27. (lien). É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 Sytoka Modon (page perso, ) le 02/04/2006 à 11:00. (lien). É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 Thomas Douillard () le 02/04/2006 à 12:04. (lien). É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

demande d'explications

• [^]Re: demande d'explications

  Posté par Sytoka Modon (page perso, ) le 01/04/2006 à 06:56. (lien). É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 Pascal Terjan (Jabber id, page perso, ) le 01/04/2006 à 13:56. (lien). É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 Sytoka Modon (page perso, ) le 01/04/2006 à 19:19. (lien). É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 poil () le 01/04/2006 à 07:24. (lien). É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 Ph Husson (page perso, ) le 01/04/2006 à 19:43. (lien). É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 dark_moule () le 01/04/2006 à 10:13. (lien). É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

• [^]Re: Non libre

  Posté par djibb (Jabber id, page perso, ) le 01/04/2006 à 08:29. (lien). É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 HappyPeng () le 01/04/2006 à 08:36. (lien). É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 snt () le 02/04/2006 à 08:30. (lien). É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 HappyPeng () le 02/04/2006 à 10:19. (lien). Évalué à 3.

    Le principe des valeurs n'est pas de les sacrifier dans le but de l'efficacité.

• [^]Re: Non libre

  Posté par Laurent Pointal (page perso, ) le 02/04/2006 à 19:51. (lien). É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.

  --
  (pub: Livres à prix réduit sur http://www.sollire.com/ - la boutique de mes petites soeurs)

Fonctions supplémentaires, un jour, qui sait

• [^]Re: Fonctions supplémentaires, un jour, qui sait

  Posté par Matthieu C () le 01/04/2006 à 12:36. (lien). É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 Leroy Frederic (page perso, ) le 01/04/2006 à 12:59. (lien). É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é

• [^]Re: CVS : Ce n'est pas précisé

  Posté par Yann Souchon (page perso, ) le 02/04/2006 à 10:44. (lien). É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 Pascal Terjan (Jabber id, page perso, ) le 02/04/2006 à 11:03. (lien). É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 Yann Souchon (page perso, ) le 02/04/2006 à 11:21. (lien). É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 Yannick (page perso, ) le 02/04/2006 à 20:08. (lien). É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 Cali_Mero () le 03/04/2006 à 10:43. (lien). É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.

      --
      #define MAGIC 0xdefaced /* I should've patented this number -cliph */

      • [^]Re: CVS : Ce n'est pas précisé

        Posté par Yannick (page perso, ) le 04/04/2006 à 14:00. (lien). É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 Sytoka Modon (page perso, ) le 04/04/2006 à 15:30. (lien). É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 Sytoka Modon (page perso, ) le 02/04/2006 à 10:51. (lien). É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 Yaz () le 02/04/2006 à 15:09. (lien). Évalué à 1.

  Ca compile pas avec GCC 4.0 par contre....

  • [^]Re: CVS : Ce n'est pas précisé

    Posté par djibb (Jabber id, page perso, ) le 02/04/2006 à 17:23. (lien). É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.

    • [^]Re: CVS : Ce n'est pas précisé

      Posté par shinobufan (page perso, ) le 03/04/2006 à 18:55. (lien). Évalué à 5.

      Ou sinon, faire le configure avec un ./configure --cc=gcc-3.4 ou ./configure --cc=gcc-3.3 , ce qui évite de jouer avec les liens ;)

Accès matériel ?