Journal VirtualBox 2.0 is out !

Posté par (page perso) .
Tags : aucun
23
5
sept.
2008
Cher journal,

Je t'écris pour la première fois, pour t'annoncer un petite nouvelle dans le monde de la virtualisation: Quelques jours après celle de VirtualBox 1.6.6, la version 2.0 est disponible (depuis hier en fait), avec enfin un support des guest 64bits (avec un hôte 64bits), une meilleure intégration à Mac OS X, passage en Qt4 de la GUI et pas mal de petites autres choses.
Le changelog : http://www.virtualbox.org/wiki/Changelog
Pour rappel, Innotek (qui développe VirtualBox) à été racheté par SUN début 2008. Il existe 2 versions, dont une sous licence GPL.
Perso j'utilise VirtualBox pour virtualiser un Windows XP (oui, ca peut servir pour des tests !), et ca tourne nickel (le mode seamless, permettant d'integrer les applis guest sur l'hote est très utile ! -voir par exemple http://www.korben.info/virtualbox-15-et-la-virtualisation-se(...) pour plus d'infos). Les OS supportés : http://www.virtualbox.org/wiki/Guest_OSes (pas forcement très à jour je pense).
  • # VirtualBox closed-source Features

    Posté par . Évalué à 9.

    Virtualbox, c'est pas aussi libre qu'on le croit. C'est bien pour s'amuser la premiere fois avec de la virtualisation avec la version libre. En quelques clics, on a un OS virtualise.

    Mais des qu'on veut aller un peu plus loin...
    - lancement d'un OS invite en tache de fond : impossible car l'interface graphique via RDP est proprietaire

    - acces aux peripheriques USB : proprietaire

    - support un peu complexe des disques : proprietaire (iSCSI ou SATA)

    C'est ecrit la : http://www.virtualbox.org/wiki/Editions, en bas.
    Sun aime le libre, mais a quand meme mis plus de 10 ans a liberer java !

    Rien a voir : Redhat vient d'acheter Qumranet, la societe qui bosse sur KVM.

    Le bonjour chez vous,
    Yves
  • # Réouverture des dêpots officels deb

    Posté par . Évalué à 6.

    Quand sun avait racheté innotek, les dépôts de packages deb n' étaient plus mis à jours. Ce qui était vraiment très gênant (obliger d' aller sur le site de sun, choisir, et télécharger un fichier).

    Heureusement, les dépôts deb de Virtualbox sont dorénavant accessibles et mis à jour.
  • # pas de 3D

    Posté par . Évalué à 3.

    Il n'y a toujours pas de support de l'accélération 3D. Dommage. Pas possible de jouer à de vieux jeux Windows non supportés sous Wine.
    Évidemment, autant le support de l'accélération OpenGL est "relativement" aisé à intégrer (il y a déjà des travaux sur lesquels se baser comme VMGL, http://www.cs.toronto.edu/~andreslc/xen-gl/ ), autant le support de DirectX risque d'être plus chaud, même si un tel driver devrait pouvoir se baser sur Wine.

    Ça serait déjà sympa qu'ils intégrent l'accélération OpenGL, au moins sous un Linux virtualisé. Ça permettrait de tester des distribs avec les effets graphiques activés. J'ai cru comprendre qu'ils avaient commencé à intégrer cela mais que cela n'était pas très stable et désactivé par défaut.
    • [^] # Re: pas de 3D

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

      Ils y avaient sortie un petit texte explicatif pour expliquer la difficulté d'intégrer la 3D, en concluant clairement sur "Si vous avez besoin de la 3D, utiliser VMware".
      • [^] # Re: pas de 3D

        Posté par . Évalué à 4.

        Certes. Ce sujet est abordé sur le forum du site de Virtualbox, où ils expliquent que ça serait bien mais que c'est complexe, surtout pour DirectX. Je ne dis pas le contraire. N'empêche que ça serait très intéressant.

        Surtout que la concurrence commence à le faire (VMWare mais pas seulement). Du coup ça serait dommage que VirtualBox, qui est par ailleurs un très bon logiciel que pour mon usage je préfère largement à VMWare (et pas uniquement parce qu'il est libre), prenne trop de retard sur ce sujet par rapport à la concurrence.

        On peut donc espérer voir arriver un jour un tel support.
        Ça pourrait même être déjà le cas pour OpenGL sous Linux (que VMWare ne supporte d'ailleurs pas sauf via VMGL).
    • [^] # Re: pas de 3D

      Posté par . Évalué à 4.

      Pour avoir la 3D sous un Windows virtualisé, c'est facile, il suffit de donner un accès direct à la carte graphique à l'OS invité.
      Ce qui peut se faire avec le VT-d d'Intel, par exemple.
  • # VirtualBox me sauve la vie

    Posté par . Évalué à 6.

    VirtualBox me sauve la vie pour ne pas avoir à faire un multiboot pour 2/3 logiciels à la con de mon entreprise ne tournant que sous Windows.
    • [^] # Re: VirtualBox me sauve la vie

      Posté par . Évalué à 4.

      idem pour moi, surtout pour se connecter via une usine à gaz de logiciel .net fourni par alcatel pour gérer un PABX sous... Linux !

      VirtualBox est vraiment très pratique, léger et simple à mettre en place (beaucoup plus que Vmware)

      Cela me sert beaucoup pour tester d'autres distributions et des OS plus exotiques...

      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: VirtualBox me sauve la vie

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

        idem pour moi, surtout pour se connecter via une usine à gaz de logiciel .net fourni par alcatel pour gérer un PABX sous... Linux !

        euh rien a voir avec le sujet... mais t'as pas une interface web (en java) pour gérer ton pabx?
        Parce que pour le coup oui effectivement, c'est ennuyeux.
        • [^] # Re: VirtualBox me sauve la vie

          Posté par . Évalué à 3.

          non, visiblement pas, je leur ai demandé, et c'est uniquement cela. Les techniciens peuvent également se connecter en cas d'urgence via un terminal série branché sur la machine, mais c'est tout.

          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: VirtualBox me sauve la vie

            Posté par . Évalué à 1.

            Sur les OmniPCX Office je ne sais pas, mais sur le OmniPCX Enterprise, c'est possible, c'est certain. Cela ressemble beaucoup à la 4760, sauf que biensûr tu ne gères qu'un seul équipement à la fois, et que tu n'es pas obligé de payer une licence d'utilisation :)
            • [^] # Re: VirtualBox me sauve la vie

              Posté par . Évalué à 1.

              Bon, après vérification, j'ai dit une conn... : l'interface web se connecte au serveur 4760 ; elle ne permet pas de s'en passer.
      • [^] # Re: VirtualBox me sauve la vie

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

        Salut,

        Comment ? un linuxien qui n'aime pas la ligne de commande ? ;) Par défaut, les OmniPCX sont accessibles via Telnet, je crois...

        Pour ce qui est de l'OmniVista 4760 (outil de supervision), la partie serveur est en C++ avec un SGBD Sybase, et ne s'installe que sur du Microsoft. La partie cliente est développée en Java, donc devrait pouvoir tourner sur n'importe quelle machine, malheureusement ils ne fournissent un installeur que pour Windows... Mais il y a peut-être une interface Web également, à vérifier.

        Pour info, la précédente génération de PABX Alcatel tournait sur du Windows NT, tandis que la génération actuelle tourne sur la base d'une Mandrake (ça remonte déjà à quelques années, en effet) avec un kernel patché. Je ne suis pas sûr qu'ils respectent la GPL, d'ailleurs...
        • [^] # Re: VirtualBox me sauve la vie

          Posté par . Évalué à 1.

          La génération actuelle tourne sur la base d'une Mandrake (ça remonte déjà à quelques années, en effet) avec un kernel patché. Je ne suis pas sûr qu'ils respectent la GPL, d'ailleurs...

          Là où je travaille nous avons effectivement des OXE qui utilisent Mandrake (7.2 de mémoire). Cependant j'ai lu sur le net que les derniers OXE utilisent Red Hat.
          Je pense qu'ils ne sont pas très propres vis-à-vis de la GPL. J'avais posté un journal sur le sujet : je n'ai pas réussi à avoir le code source, mais je ne sais pas si cela a bloqué côté Alcatel ou dans l'entreprise où je travaille.
  • # Un peu pénible

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

    Bon, mon utilisation est peut être marginale, mais je me sers de VM sur mon portable, pour travailler tranquillement quelque soit mon environnement sur une "copie" à peu près conforme à la production, tranquillement. Du coup, je fonctionne souvent avec KVM et quelques "-redir" histoire de faire du port forwarding sur ssh, http, etc.

    Bon, avec KVM, c'est nickel, mais j'apprécie l'idée de virtualbox et de son relative portabilité histoire de faire tourner mes instances à d'autres personnes sous mac ou windows. Pratique. Du coup, ce matin, j'installe vbox 2.0 sur une debian. Je monte un guest debian dedans :
    - pas d'interface, mais une (en fait 3) lignes de commande, voire une édition de fichier XML pour placer les redirections
    - bug au chargement du kernel (sans trace dans les logs)
    - si pas de bug (aléatoirement), pas de port forwarding, même si tout a l'air OK

    Un peu pénible.
    /me grognon.
    • [^] # Re: Un peu pénible

      Posté par . Évalué à 4.

      Portabilité, mouais, c'est sûr...

      ... maintenant, la pérennité des images...



      Virtualbox-OSE, je l'ai laissé tombé après deux fois où, à une mise à jour, il m'a sorti que le format d'image avait changé, et que le nouveau n'était plus compatible avec l'ancien...

      ... du coup, depuis, c'est qemu+qemulator+kqemu/kvm (selon ce dont la machine est capable)... et depuis, pas de souci.
      • [^] # Re: Un peu pénible

        Posté par . Évalué à 2.

        du coup, depuis, c'est qemu+qemulator+kqemu/kvm (selon ce dont la machine est capable).

        qemu...qemulator...kqemu/kvm là ou une seule occurence VirtualBox™ suffit!

        Je sais que qemu est le "backend" mais quand tu balances tout ça de cette façon, ben on a l'arrière goût "linux-bordélique" qui remonte.
        • [^] # Re: Un peu pénible

          Posté par . Évalué à 3.

          Ouais, enfin, à ce compte, c'est virtualbox-ose+virtualbox-ose-modules, hein...

          Sans compter les virtualbox-ose-guest-utils, pour faire du partage entre hôte et invité, là où le partage de partoche, voire le montage d'une clé USB se fait sans problème avec qemu tout seul...
        • [^] # Re: Un peu pénible

          Posté par . Évalué à 2.

          Et au niveau USB, il s'en sort comment qemu ?
          De mon experience propre l'USB est supporté mais seulement en USB 1 qui est très très lent. D'autres part je ne peux pas utiliser certains appareils qui ne veulent entendre parler que d'USB2 (comme les nouveaux iPod).

          Je n'ai pas non plus la chance d'avoir un CPU kvm donc j'en suis réduit à kqemu.
          qemu + kqemu est vraiment plus lent que virtualbox.

          J'aimerais tellement remplacer Vbox par qemu ... Vous aussi vous avez cette déception ?
          • [^] # Re: Un peu pénible

            Posté par . Évalué à 4.

            Ils viennent de merger le support pour les transferts USB asynchrone (émul ohci je crois). Les testeurs disent que même les webcams sont censées fonctionner désormais. Contrairement à Virtualbox, c'est libre.
            • [^] # Re: Un peu pénible

              Posté par . Évalué à 1.

              OHCI = USB 1.1
              Tu voulais dire EHCI ? Tu as trouvé cette info où, sur la ML ? J'aimerai bien aller voir où ils en sont ...
              • [^] # Re: Un peu pénible

                Posté par . Évalué à 2.

                > Tu voulais dire EHCI ?

                Les patchs offrant le support EHCI vient d'être proposés.

                > Tu as trouvé cette info où, sur la ML ? J'aimerai bien aller voir où ils en sont ...

                Sur la mailing-list de qemu : cherche les mails envoyés par Max Krasnyansky en août et septembre.
          • [^] # Re: Un peu pénible

            Posté par . Évalué à 1.

            > qemu + kqemu est vraiment plus lent que virtualbox

            Il y a aussi que, par défaut, qemu n'alloue que 128MB de RAM à la machine virtuelle, là où, par défaut également, virtualbox en alloue 256MB... et ça change tout...

            ... en passant qemu à 256MB de RAM pour la VM, en ayant comparé l'install de Debian customisée via simple-cdd sur un pentium-m 1,7GHz (donc, sans accélération matérielle), la différence entre les deux, elle est bien moindre.
          • [^] # Re: Un peu pénible

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

            J'aimerais tellement remplacer Vbox par qemu
            Pour ma part j'aimerais remplacer vmware par qemu ou KVM en environnement de production. Nous avons actuellement une quarantaine de machines virtuelles, rien que du Windows. Avec vmware ça fonctionne presque très bien. Les performances sont excellentes (meilleures qu'avec Windows bare metal, sauf en calcul pur mais nous n'en faisons pas), la stabilité, rien à redire. Le seul point négatif c'est que la configuration de vmware est mal faite, mal documentée pour les paramètres pointus, et que des choses basiques remettent en place les paramètres par défaut (c'est probablement leur manière d'éviter que certains incompétents se plaignent).

            Pourquoi qemu ou KVM alors que vmware fonctionne très bien (et gratuitement) ? Par préférence "libertaire". Et je pense que c'est également plus facile à gérer via des outils maison.
            • [^] # Re: Un peu pénible

              Posté par . Évalué à 2.

              avec un peu de chance ca va se faire sans douleur

              il y a une seule condition à ma connaissance, le disk vmware doit etre en un seul morceau pour pouvoir etre convertit en disque pour qemu/kvm

              ensuite j'avais trouvé sur internet (mais pas testé) une commande pour convertir la VM en Kvm
              • [^] # Re: Un peu pénible

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

                La conversion ne me pose pas de problème. Ce qui me pose des problèmes c'est que jusqu'à présent je n'ai vu nulle part de témoignages d'entreprises utilisant qemu et/ou KVM en production massive. Que ce soit utilisé par des développeurs ou par l'équipe système pour faire des tests, ok, mais je n'ai rien vu en production. Soit c'est un secret :-) soit il n'y en a quasiment pas.
                • [^] # Re: Un peu pénible

                  Posté par . Évalué à 3.

                  porablement parce que c'est tres recent

                  mon equipe de QA commence à passer sous KVM car sous VMware on constate des decalages d'horloges (ennuyeux pour du monitoring ou de la synchro de serveur)

                  j'envisage moi meme de passer mes serveurs emails sous kvm
                  • [^] # Re: Un peu pénible

                    Posté par . Évalué à 2.

                    Le décalage d'horloge sur vmware est un problème hyper connu. C'est dommage de migrer pour ça.
                    Dis à tes admins de fouiller sur google ou sur le site vmware, il faut juste modifier un param du kernel et au pire installer ntp.

                    Un lien parmi d'autres : http://kb.vmware.com/selfservice/microsites/search.do?langua(...)
                    • [^] # Re: Un peu pénible

                      Posté par . Évalué à 3.

                      l'admin, ... c'est moi
                      pas vraiment le temps de me pencher sur les 50 vm sous gentoo
                      alors que nos services migrent un par un sous ubuntu.

                      j'ai bien trouvé une astuce qui consiste à installer les tools dans le guest, puis à activer une variable à true dans le fichier de config de la VM.

                      mais :
                      1°) les tools sur une gentoo de 2007-08, ca le fait pas sans modifier tout le systeme
                      2°) meme avec des ubuntu ca marche pas toujours.
                      3°) recompiler le kernel d'un serveur qui heberge 20 machines virtuelles, vaut vraiment pas se louper


                      je ferais un essaie avec ton lien qui est plus precis que ceux que j'avais trouvés precedemment.

                      et sinon, KVM c'est libre quand VMware Server est juste gratuit...
                      ce qui en soit est deja mieux pour ma boite.
                      • [^] # Re: Un peu pénible

                        Posté par . Évalué à 2.

                        Lis la doc ... c'est pas forcement recompiler le kernel mais ajouter très simplement un param passé au kernel au boot (ie dans grub.conf ou lilo.conf)

                        Moins coûteux qu'une migration si tu as déjà les licences vmware.

                        Mais comme tu le dis ... c'est toi l'admin :)
  • # eaux troubles

    Posté par . Évalué à -1.

    Bon allez, c'est vendredi!

    J'ai jamais réussi à trouver d'intéret à virtualbox...

    D'un point de vue philosophique: la position d'Innotek (ou Sun maintenant) n'a jamais été très claire vis à vis du libre... en règle général je n'aime pas ce modèle économique qui consiste à libérer du code qui a déjà son équivalent, et à conserver les fonctionalités intérressantes planquées derrière des licences propriétaires...

    D'un point de vue technique: je trouve les interfaces graphiques USELESS dans le cadre de la virtualisation à petite échelle: les scripts sont tellement plus souples et performants! Quand tu dois déployer des dizaines et des dizaines de machines virtuelles, gérer des migrations de hosts ou faire du cloud computing... c'est une autre histoire.

    D'un point de vue des perfs: bah que dire? ca vaut un qemu+kqemu à peu près....
    On est loin des performances que l'on peu atteindre avec un xen ou un esx (vous remarquerez le double lancement de troll!)
    • [^] # Re: eaux troubles

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

      D'un point de vue technique: je trouve les interfaces graphiques USELESS dans le cadre de la virtualisation à petite échelle

      Alors là, pour le coup, je ne peux que plussoyer. Pour pouvoir simplement tester une installation de système d'exploitation et des captures d'écran, j'ai essayé plusieurs logiciels de virtualisation. Qemu m'a bien plu, Bochs m'a semblé une bonne usine à gaz, et VirtualBox un affreux cliquodrome. Bref, depuis, c'est Qemu ou KVM, qui sont simples à utiliser, au moins.
    • [^] # Re: eaux troubles

      Posté par . Évalué à 4.

      Alors moi j'ai eu un problème vraiment tordu, qui me force à utiliser virtualbox.
      C'est pour lire les DVDs des archives du new yorker, il y a un logiciel fermé qui tourne sous windows pour les lire. Il ne tourne pas avec wine, donc utilisation de qemu avec un vieux windows de derrière les fagots, et là rien à faire il ne reconnaît pas le DVD, il demande de l'insérer dans le lecteur, qu'il soit en ISO et émulé, ou en réel directement via le périphérique.
      J'ai essayé avec virtualbox, et c'est pareil, sauf qu'il y a une option « Activer le mode direct », qui sauve la situation !

      Je ne sais pas exactement ce qui se planque derrière tout ça, probablement une sécurité bien crade, mais j'aimerai bien savoir comment régler ça sous qemu...

      Yth.
    • [^] # Re: eaux troubles

      Posté par . Évalué à 10.

      D'un point de vue technique: je trouve les interfaces graphiques USELESS dans le cadre de la virtualisation à petite échelle

      D'un point de vue linguistique: qu'est-ce qui t'empêchait de dire INUTILES ici???

      INUTILES, FUTILES, SUPERFLUES, VAINES, SANS INTÉRÊT, DISPENSABLES,... et j'en passe certainement.
    • [^] # Re: eaux troubles

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

      Pour moi, le fait que vitualbox(-ose) soit disponible dans debian, ça a beaucoup clarifié la situation...

      J'étais un utilisateur de qemu+kqemu, et ça répondait bien à mon besoin, mais les perfs étaient assez moyennes sur ma machine (T5500 2 Go Ram pourtant)...
      Du coup, j'ai testé virtualbox, et j'ai constaté des perfs très supérieures...

      Mon cpu n'a hélas pas les extensions VT pour pouvoir tester kvm...

      Sinon, l'interface graphique de virtualbox n'a rien de "génante", moi je la démarre via un script "de démarrage" dans un vnc. Et on peut tout controler (démarrage/arrêt d'une vm, montage d'un cdrom, ajout d'un disque) via la commande vboxmanage.

      Une dernière remarque : les scripts pour créer les interfaces réseaux virtuelles et les relier à un bridge me semblent plus simples et mieux foutus que ce qu'il y avait pour qemu il y a environ 2 ans (ce qui a peut-être changé maintenant).

      Bref, plutôt que troller, je trouve très bien qu'il y ait plusieurs bonnes solutions de virtualisation libres...
  • # Question pas si innocente

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

    Et vous qui faites tourner Windows dans un environnement virtualisé à la maison, vous achetez la licence de Windows ?

    Pour ma part je ne le fais pas, car sur ma machine ne tourne presque que du logiciel libre, et y faire tourner Windows me débecte, mais je comprends surtout l'utilisation en milieu professionel (cf message sur le pabx ci-dessus).
    • [^] # Re: Question pas si innocente

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

      Est-ce à dire que tu utilises Windows sans licence ? C'est ce qui a l'air de ressortir de ton message…
      • [^] # Re: Question pas si innocente

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

        Et puis, qu'est-ce que c'est que cette question, d'ailleurs ? Si je comprends bien, tu es en train de demander aux utilisateurs de Windows virtualisés s'ils l'ont acheté ou craqué ?
        • [^] # Re: Question pas si innocente

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

          je n'utilise pas du tout windows. donc je n'ai pas de licence. et vice versa.

          sinon oui, c'est le sens de ma question. les seules fois ou j'ai vu un windows tournant dans une machine virtuelle sous linux (je parle hors du monde professionnel, où en général on paie les logiciels payants qu'on utilise), c'était une "copie". Cela choque le défenseur du logiciel libre que je suis, et qui serine autour de moi : "tu veux un logiciel payant ? tu le paies. Ou alors tu prends l'équivalent libre."

          je voulais connaître votre position sur cette question ; désolé si elle n'était pas très claire ;-)

          et oui, je sais, il y a des périphériques qui ne fonctionnent que sous windows, mais je vais au bout de mon raisonnement, et il y en a 2 qu'on m'a offert et qui prennent la poussière chez moi. sinon y'a de très bonnes bases de données de matériel qui fonctionne sous Linux, à utiliser avant tout achat (l'excellent http://hardware4linux.info pour n'en citer qu'un).

          Quant aux jeux, je ne joue qu'aux jeux libres. oui je sais, c'est un peu ayatollah comme position ;-)
          • [^] # Re: Question pas si innocente

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

            Dans ce cas, je suis d'accord avec toi. Violer des licences, que ce soit la GPL ou l'EULA de Microsoft, c'est mal, et je suis choqué par le nombre de de gens qui les enfreignent malgré tout, à commencer par les grands distributeurs d'ordinateurs.
          • [^] # Re: Question pas si innocente

            Posté par . Évalué à 2.

            Moi, ce qui choque le défenseur du logiciel libre que je suis, c'est les phrases : "tu veux un logiciel payant ? tu le paies. Ou alors tu prends l'équivalent libre."

            libre ne veut pas dire gratuit.
    • [^] # Re: Question pas si innocente

      Posté par . Évalué à 5.

      Personnellement, je n'ai jamais eu à pirater Windows, car je l'achète - que je le veuille ou non - avec chaque nouveau PC.

      En fait, c'est la vente liée qui m'empêche de sombrer dans la délinquance !
  • # virt-manager

    Posté par . Évalué à 8.

    Marrant de voir que dans ce journal jamais virt-manager n'est cité...

    virt-manager a été initialement developpé par Red Hat. Ubuntu l'utilise (et Novell/SuSE aussi ?).
    C'est ultra simple d'utilisation. Ça peut-être cliquodrome, ou en "shell". Virt-manager utilise libvirt (qui gère Xen, KVM/qemu, etc).
    C'est aussi intégré à Policy-kit, donc pas besoin d'être super-utilisateur.
    Bref, que du bonheur (même s'il reste quelques bugs).

    Virt-manger :
    http://www.virt-manager.org/
    Libvirt :
    http://www.libvirt.org/

    C'est que du libre, pas de modules proprios, etc.

    En passant, ovirt :
    http://www.ovirt.org/
    • [^] # Re: virt-manager

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

      Merci pour cette contribution car je ne connaissais pas et ca a l'air en effet simple a installer (via aptitude su hardy), simple a prendre en main via l'interface graphique (cf screenshots sur le site), complet (support de Xen et kqemu/kvm) et scriptable en ligne de commande.
    • [^] # Re: virt-manager

      Posté par . Évalué à 2.

      oui tu fais bien de souligner ca! mais plus que virt-manager c'est l'existance de libvirt qui est intéressante!
      Ainsi des projets qui l'utilisent (comme l'excellent enomalism) peuvent/pourraient manager différentes techno de virtualisation... vive la standardisation!
    • [^] # Re: virt-manager

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

      Un seul problème, les fichiers de configuration au format XML ! C'est clairement orienté clickodrome ce truc là.

      Moi, je veux des fichiers de conf fait pour les humains comme ceux de Xen à la base. D'ailleurs, Xen les transforme ensuite à un format parent du XML puisqu'ils sont en un dialecte du LISP.

      Bref, virt c'est bien mais SVP, pas de XML sous /etc.
      • [^] # Re: virt-manager

        Posté par . Évalué à -4.

        Les fichiers textes c'est bien pour faire des petites configurations à la mimime et peu nombreuses. Mais si l'on a une multitude de domaines à gèrer avec des particularités de configuration, écrire un générateur xml s'avérera bien plus rapide/facile qu'un générateur de fichiers de configuration. Au lieu de dire XML c'est orienté clickodrome, je dirais que c'est orienté Enterpraise.

        Sinon, comme dit plus haut, un des grands intérêts de virt-manager, c'est la libvirt, ses bindings (python,perl,ruby & ocaml (-: ) et ses outils CLI associers. C'est une très bonne idée d'essayer de fédérer l'usage et l'administration de machines virtuelles autour d'une API unique. Et cela, ce n'est clairement pas orienté clickodrome, même si cela favorise l'émergence de GUIs sophistiquées et inter-opérables ;-)
        • [^] # Re: virt-manager

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

          > je dirais que c'est orienté Enterpraise

          Les fichiers de configuration sous UNIX sont depuis des années loin d'être en XML et UNIX est loin de ne pas être orienté entreprise !

          Les fichiers de conf en XML proviennent de toute la tringlerie insupportable du java avec Tomcat et autres. On sais très bien faire des fichiers de conf lisible par l'homme et par la machine, par exemple le YAML. Pour information, l'ensemble de la cohérence des milliers de module (classe pour la plupart) du CPAN de Perl sont pilotés par de simple fichier YAML. Tu ne va pas me dire que la gestion des tes machines virtuelles est un problème plus complexe et doit être plus professionelle que celui du CPAN !

          Faire cela sous XML, c'est effectivement pour simplifier les outils de plus haut niveau qui manipule alors ce genre de fichier facilement avec l'aide des bibliothèques toute faites pour le XML. Enfin, pour la quantité et le type d'information que l'on y retrouve, on fait tout aussi bien en YAML...

          Ecrire un générateur, cela revient en pratique à lire et à écrire dans un fichier une structure d'arbre. C'est assez facile, pas besoin encore de se focaliser sur le XML.

          Bref, sous des arguments que je considère comme fallacieux : "il me faut des méta outils qui puisse me générer mes fichiers de conf", on va finir par se retrouver avec un /etc imbittable et être obliger d'avoir des clickodromes pour gérer ses machines Linux (voir une base de registre !).

          Je gère mes serveurs sans X-Windows, j'ai des dizaines de machines virtuelles et le tout est cohérent avec le tout génial cfengine qui n'a pas une ligne de ce truc imbittable pour l'homme qu'est le XML.

          Désolé, je n'ai pas envie de gérer mes serveurs Linux comme des serveurs Windows... Et je vois de plus en plus de personne venant installer des prologiciels sous Linux qui viennent du monde Windows et qui amènent et appliquent les mauvaises méthodes de Windows sous Linux.

          Un programme de type service système ne devrait pas avoir une application graphique comme dépendances nécessaires pour l'installation et la maintenance (ce qui ne veut pas dire qu'il n'en faut pas du tout). Cela me semble un défaut de conception à la source. Surtout que comme je l'ai dis en début de réponse, il y a des alternatives au XML qui font le même boulot en pas plus de ligne et qui sont humainement acceptable.

          Bref, je ne sais pas si c'est Red-Hat qui pousse à cela mais libvirt, heartbeat2... Moi, cette voie du XML, cela commence à me gonfler sérieusement. D'ailleurs, pour cette raison, j'évite toute application en java sur mes serveurs dans mon laboratoire et pour le moment, aucune ne me manque.
          • [^] # Re: virt-manager

            Posté par . Évalué à -2.

            Mouaif...
            XML c'est un standard, il y a des outils pour les manipuler.

            Le but n'est pas de tout faire avec vi. Mais d'avoir des outils de haut niveau.

            De tout manière, c'est un débât dépassé. Il y aura de plus en plus de fichier de configuration en XML. Pour les choses compliquées ça présente trop d'intérêt pour s'en passer (sans compter qu'on n'a pas à ce faire chier a écrire un parser etc).

            > Bref, je ne sais pas si c'est Red-Hat qui pousse à cela mais libvirt

            Pour libvirt, le choix de XML a été fait dès le début (donc par Red Hat).
            • [^] # Re: virt-manager

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

              Les fichiers .INI, c'est un standard, il y a des outils pour les manipuler. Les fichiers YAML, c'est un standard, il y a des outils pour les manipuler. ...

              Le XML est un standard récent qui est bien pour certain truc, notament dans les pipelines de type AxKit. Pour charger une configuration, c'est lourdingue et inutilement compliqué.

              Sais tu que charger une configuration en YAML dans un programme se fait en deux lignes, une pour charger la bibliothèque et une pour charger la configuration. Sais tu aussi que le YAML est multiplateforme et multilangage, tout comme les fichiers .ini, tout comme...

              Non tu es dans ton petit monde du HTML et du XHTML et donc il faut en mettre partout. Et puis c'est ce que veulent les entreprises alors suivont comme un mouton... Ce n'est pas dans ma philosopie ni celle qui m'a fait adoré Linux depuis des années et des années.

              Bref, tu ne me donnes aucun argument qui tienne la route. Donne moi vraiment un truc compliqué parce que la configuration de machine virtuelle, c'est un truc que je trouve assez simple.

              Ce que j'en pense, avec des logiciels libre ayant des fichiers de configuration en XML, il faut se tapper absolument une interface graphique de configuration. Or écrire ce genre de programme est super chiant, c'est pas si facile à faire, surtout sans bogue. Les boites comme Red-Hat ont peut être tout intérêt à vendre du support la dessus. En tout cas, c'est par exemple un peu la stratégie de XenSource (Citrix) que de vendre l'IHM de configuration.

              Bref, c'est peut être une stratégie commercialle mais certainement pas technique.

              Petit exercice pour finir : vous mes traduisez en XML un fichier de configuration conséquent des serveurs apache2 et exim4. Faites de même avec samba. Comparez et tirez en la conclusion qui s'impose.
              • [^] # Re: virt-manager

                Posté par . Évalué à 2.

                > il faut se tapper absolument une interface graphique de configuration.

                Bin non juste un editeur XML digne de ce nom, si le schema a été bien pensé. Bonus tu as la complétion et la validation de ton fichier à la volée. Pas besoin de cycle test/correction

                Après je suis pas fan non plus des fichiers de conf en XML. Par contre entre tomcat et apache, la conf du premier est vachement mieux foutue (en dehors de la verbosité).

                Le truc, c'est qu'en général on a pas envie de se faire chier à inventer encore un nouveau format, avec encore un nouveau parser, avec encore de nouveaux modes pour chaque éditeur. Alors on prend un truc qu'on a sous la main. Et XML est de loin le truc le plus disséminé en ce moment...
                • [^] # Re: virt-manager

                  Posté par . Évalué à 1.

                  Très juste.

                  > Le truc, c'est qu'en général on a pas envie de se faire chier à inventer encore un nouveau format

                  Chaque fichier .ini a son propre format qui n'est pas décrit (sauf dans la doc)...

                  Je ne dis pas que l'XML doit être foutu partout. Mais aujourd'hui on ne peut plus demander à l'utilisateur de prendre un éditeur de texte pour change une configuration. Aujourd'hui la grande grande grande majorité des fichiers de configuration sont modifiés via un programme (qui n'est évidemment pas un éditeur de texte). XML est excellent dans ce domaine.

                  Libvirt a-t-il besoin de fichier de configuration en XML ?
                  Je ne donne pas la réponse. Mais c'est très cool avec virt-manager de créer et modifier une machine virtuelle est quelques cliques au-lieu de se bouffer la doc et utiliser un éditeur de texte (avec tous les risques d'erreur que ça implique). En majorité XML (ou autre) c'est mieux pour l'utilisateur, c'est aussi beaucoup mieux pour les développeurs.

                  Voyons ces projets :
                  http://cft.et.redhat.com/
                  http://augeas.net/
                  https://fedorahosted.org/func

                  Si tout était en XML, leurs vies seraient grandement simplifiées (avec contrôle et tout ; par exemple ils détecteraient automatique qu'une modification n'est pas encore supportée avec telle version d'apache).
                  • [^] # Re: virt-manager

                    Posté par . Évalué à 8.

                    Chaque fichier .ini a son propre format qui n'est pas décrit (sauf dans la doc)...
                    Mouaif...
                    s/ini/xml/ et ça marche aussi.

                    Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.

              • [^] # Re: virt-manager

                Posté par . Évalué à -1.

                > Les fichiers .INI, c'est un standard

                Et comment tu décris le contenu d'un fichier .INI ?
                Il y a des dtd pour fichiers .INI ?
                Il y a l'équivalent de XPath pour les fichiers .INI ?

                > Le XML est un standard récent

                Mouaif...

                > Les fichiers YAML, c'est un standard, il y a des outils pour les manipuler. .

                Tu veux bien des fichiers YAML, mais pas des fichiers XML...
                Va savoir pourquoi...

                > Et puis c'est ce que veulent les entreprises alors suivont comme un mouton...

                Soit rebelle.



                > Bref, tu ne me donnes aucun argument qui tienne la route.

                Et quel est ton argument ?
                Ton argument c'est "XML poua, car c'est à la mode ; je veux un truc qui n'est pas à la mode".
                Ben ça ne va pas loins.

                > Les boites comme Red-Hat ont peut être tout intérêt à vendre du support la dessus.

                C'est du libre. Fock libvirt. C'est beaucoup plus fort que de critiqué ce qui est fait pour et par le communauté.
                N'utilises pas libvirt, n'utilises pas Gnome, n'utilises pas Firefox, etc. T'es libre.

                > Petit exercice pour finir : vous mes traduisez en XML un fichier de configuration conséquent des serveurs apache2

                Ben un fichier de conf d'apache a des ressemblances avec XML. Si c'était en XML, copier programmatiquement la configuration d'un site vers un autre site serait trivial. Mais actuellement il faut faire une usine à gaz pour y arriver.
                • [^] # Re: virt-manager

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

                  Tu veux bien des fichiers YAML, mais pas des fichiers XML...
                  Va savoir pourquoi...


                  Parce que c'est lisible, je pense.

                  XML :
                  <moduleList>
                    <module name="toto">
                      <paramList>
                        <param name="titi">tata</param>
                        <param name="files">
                          <file name="/foo/bar"/>
                          <file name="/baz"/>
                        </param>
                        ...
                      </paramList>
                    </module>
                  </moduleList


                  YAML :
                  modules :
                  - toto :
                    titi : tata
                    files :
                    - /foo/bar
                    - /baz


                  Ou encore :
                  modules :
                  - toto :
                  titi : tata
                  files : [/foo/bar, /baz]


                  Franchement, entre le XML et le YAML, il n'y a même pas à hésiter, pour faire des configurations humaines. Parce qu'un fichier de configuration, c'est avant tout fait pour être lu, compris et correct. XML échoue dans les trois cas :
                  - c'est illisible par un être humain normal,
                  - c'est encore moins compréhensible sans passer longtemps à déchiffrer,
                  - si ce n'est pas correct, va trouver l'erreur au milieu de cette syntaxe verbomitive.
                  • [^] # Re: virt-manager

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

                    > Franchement, entre le XML et le YAML, il n'y a même pas à hésiter

                    Pour les configurations humaines, et les autres, sans hésiter, je prends des S-Exprs... Et en plus, comme je code en Scheme, je peux les parser directement et efficacement !

                    (modules (toto (titi tata) (files "foo/bar" "/baz")))

                    Et tu peux même en faire un programme à part entière et générant dynamiquement le parseur, et toussaquelisppermet !
                  • [^] # Re: virt-manager

                    Posté par . Évalué à 3.

                    Je vois que le XML bashing à toujours la cote ici, mais proposer du yaml à la place, c'est un peu stupide (c'est la même chose en plus ambigu/contraignant*)... Par contre, proposer un truc de plus simple, moins contraignant tel que les s-exps comme l'a fait Axioplase ne l'aurait pas été. D'ailleurs, il faudra que tu nous explique en quoi son exemple n'est pas lisible !

                    Tant que tu y es, tu vas nous expliquer comment tu génère/modifie/parse la configuration YAML de ton parc de 100 serveurs virtualisés. J'espère que tu ne compte pas le faire à la main...

                    Bref, YAML ça pue encore plus que le XML. À quoi bon ?

                    *: - niveaux d'indentation déterminants: beurk, vive le copier-coller !
                    - peu supporté, pas la peine de me sortir le nom d'une bibliothèque YAML, ce truc est 1000 fois moins supporté que le XML.
                    - comment fait-on pour valider ton yaml avec un schéma ? (même problème pour les s-expr). Cette tâche doit maintenant être faite par le programme lui-même (charger des nouvelle donnée et regarder si "ça passe")...
                    - avec XML, les noms d'attributs et les noms de tags décrivent généralement ce qu'ils contiennent. Peut-on en dire autant de ton exemple YAML ? Et les S-Exps ? ah bon, c'est pareil ;-)
                    • [^] # Re: virt-manager

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

                      Les s-exps, pour moi, ce n'est pas très lisible, mais c'est peut-être par habitude. Trop de parenthèses, je trouve. De même qu'XML a un peu trop de chevrons à mon goût.

                      Pour gérer une configuration YAML, bah, avec Perl/Python/Ruby/Java, n'importe quoi enfin.

                      Niveau d'indentations déterminant : un bon éditeur de texte permet d'augmenter ou de diminuer facilement le niveau d'indentation de tout un bloc.

                      Peu pris en charge : tu vois un langage courant pour lequel il n'existe pas de parseur YAML ?

                      Validation : c'est nouveau, cette manie de vouloir valider des fichiers de configuration ? Mon main.cf, c'est Postfix lui-même qui le lit et me dit si quelque chose ne va pas dedans. Pareil pour smb.conf et tout. Après tout, c'est le programme qui sait de quoi il a besoin.

                      Noms d'attributs et de balises : en YAML ou en JSON, on peut tout à fait utiliser des dictionnaires ou tables de hachage, donc des noms significatifs.
                    • [^] # Re: virt-manager

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

                      > Bref, YAML ça pue encore plus que le XML. À quoi bon ?

                      Dis donc, t'es pas sympa avec le XML. Même moi, je n'ai pas dis cela ;-)

                      Un truc qui m'amuse sur le YAML, les pro XML déteste et parmi ces personnes, il y en a plein qui adore python. Or comme python, YAML est basé sur l'indentation...

                      Personnellement, je ne suis pas fanat de python et de l'indentation. J'ai pris l'exemple du YAML car c'est ultra simple a utiliser dans un programme, que c'est facile à lire, que cela commence a être connu et que ca gère une bonne partie du CPAN... Donc, on ne peut pas dire que c'est un truc d'amateur qui ne passe pas la mise à l'echelle.

                      Mais en fait, je n'ai aucune action chez YAML et je suis ouvert à tout format qui soit humainement conçu. Encore une fois, il faut choisir le bon langage pour le bon usage.

                      Sinon, effectivement, il y a plein d'outil qui ont été fait autour du XML. Si le dixième de cet énergie avait été mis sur un truc humainement lisible, on aurait aujourd'hui quelque chose de vraiment bien. Quand je vois le nombre d'heure année qui ont été passé pour qu'on utilise le XML à tour de bras et lorsque tu vois le nombre d'heure mis, par exemple sur le YAML (zut, encore lui), tu te dis que le XML, en lui même, est un truc complètement pas rentable...

                      D'un autre coté, le XML a permis de développer tout un tas de technologie annexe, comme la recherche dans un arbre avec XPath... Mais cela, tu pourrais très bien l'appliquer sur un arbre YAML (Ah non, je ne veux plus en entendre parler !) ou sur un format binaire comme HDF.

                      D'ailleurs, à mon sens, un gros part de ce qui a été fait sur XML aurait du être fait autour d'HDF ou un équivalent. Quitte à avoir des outils de haut niveau pour manipuler l'arbre de données, autant avoir un format binaire optimisé.

                      Mon pronostic : le HTML quitte peu à peu le web utilisateur puisque celui-ci rédige de plus en plus avec des syntaxes de type wiki. Très peu d'utilisateur pondent encore du HTML directement. Pour le XML, cela va faire pareil. Cela va devenir une technologie que se déroulera en arrière plan de l'utilisteur et il configurera son outil de configuration de sa titanesque application avec un bête fichier .ini ;-)
                      • [^] # Re: virt-manager

                        Posté par . Évalué à 2.

                        Bof, mon pronostique à moi c'est surtout qu'on va vers des éditeurs html wysiwyg type google doc question documents web.
                  • [^] # Re: virt-manager

                    Posté par . Évalué à 1.

                    s/faire des configurations humaines/faire des configuration avec un éditeur de texte comme couteau suisse.


                    Le XML a d'autres atouts, genre plein d'outil pour l'édition, l'écriture, la validation. Voire la génération d'interface de configuration à partir d'un schéma, ce genre de chose.

                    Après, un fichier de configuration c'est surtout fait pour stocker la configuration d'un logiciel. Et pour manager la configuration d'un logiciel, il y a parfois plus efficace que de taper direct dans un fichier de config, avec toutes les erreurs que ça peut induire.
                    • [^] # Re: virt-manager

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

                      Ah ben ça c'est sûr, si la configuration est en XML, je vais en faire, des erreurs, en l'éditant directement.

                      Expérience vécue : je veux activer SSL dans un hôte virtuel servi par Sun Java application server. Réflexe : il est où, le fichier de configuration ? Voyons son manuel… Échec, tout simplement : s'il y a un unique fichier de configuration, il est bien caché, et pas franchement lisible.

                      La solution, en fait, c'était de fouiller dans l'interface Web d'administration. De quoi sortir dégoûté par ce logiciel.
                      • [^] # Re: virt-manager

                        Posté par . Évalué à 2.

                        Euh, dûr ...


                        Pour te paraphraser, le logiciel sais très bien ce dont il a besoin ;)
                      • [^] # Re: virt-managerœ

                        Posté par . Évalué à 1.

                        La conf des services HTTP se fait par domain, donc tout logiquement tu configures ca dans domain/mondomain/config/domain.xml.

                        Alors la tu as deux solutions. Tu connais un minimum glassfish, tu as un editeur xml potable (ou tu sais lire une doc et une DTD) et tu rajoutes un beau http-listener à ton domaine et tu oublies pas de l'ajouter aux serveurs adéquat. Ca donne un truc comme ca:


                        <http-listener acceptor-threads="1" address="0.0.0.0" blocking-enabled="false" default-virtual-server="server" enabled="true" family="inet" id="https" port="443" redirect-port="443" security-enabled="true" server-name="xxxx.com" xpowered-by="true">
                        <ssl cert-nickname="s1as" client-auth-enabled="false" ssl2-enabled="false" ssl3-enabled="true" tls-enabled="true" tls-rollback-enabled="true"/>
                        </http-listener>


                        Tu peux aller voir la DTD http://fisheye5.cenqua.com/browse/glassfish/admin-core/confi(...) (dispo dans ton install dans lib/dtd/sun-domain_1_x)

                        Si tu veux pas te faire chier tu fais un bete create-ssl, http://docs.sun.com/app/docs/doc/820-4497/create-ssl-1?l=en&(...) . C'est l'avantage du xml tu peux faire des outils faciles pour manipuler les fichiers de conf.


                        Si tu sais pas faire, ni lire la doc bin tu cliques dans la console d'admin ca va 10x plus vite et t'es sur de pas faire d'erreur...

                        Ici on se moque souvent des admins windows mais la c'est un peu pareil... Si tu ne connais meme pas l'existance du domain.xml alors le problème c'est toi... A ta décharge on a fait de meilleures doc que celles de glassfish. La conf de tomcat est aussi mieux foutue.
                        • [^] # Re: virt-managerœ

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

                          C'est sur que ton domin.xml, sans editeur potable, cela ne donne pas du tout envie ;-)

                          Bon maintenant, tu as un editeur potable qui marche sans X11 ?
                          • [^] # Re: virt-managerœ

                            Posté par . Évalué à 1.

                            Aller une version fait main qui à exactement le même comportement (j'avais foutu les valeurs par défaut en dur)

                            <http-listener
                            id="https"
                            address="0.0.0.0"
                            default-virtual-server="server"
                            port="443"
                            security-enabled="true"
                            server-name="xxxx.com">
                            <ssl cert-nickname="s1as">
                            </http-listener>


                            Compare avec une config apache et explique moi ce qui te choque. Tu ferais comment toi ?

                            Pour le sans X11 j'édite mes fichiers en remote...

                            PS: tu peux nous coller des bouts d'exim.cf ou voir de sendmail qu'on rigole un coup :-)
                            • [^] # Re: virt-managerœ

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

                              J'avais bien vu que templeet t'avait bouffé la mise en page ;-)

                              Un bout d'exim, du coté d'un routeur (vocabulaire exim), en espérant que templeet ne me le mange pas trop (il mange quand même un bout de l'indentation). C'est presque comme du XML avec des <> et des guillemets "" en moins. C'est tout de suite plus léger pour le regards.


                              dnslookup:
                              debug_print = "R: dnslookup for $local_part@$domain"
                              driver = dnslookup
                              domains = ! +local_domains
                              transport = remote_smtp
                              same_domain_copy_routing = yes
                              # ignore private rfc1918 and APIPA addresses
                              ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 : 192.168.0.0/16 :\
                              172.16.0.0/12 : 10.0.0.0/8 : 169.254.0.0/16 :\
                              255.255.255.255
                              no_more


                              Pour l'edition en remote, j'aime pouvoir travailler en local au cas ou. Et puis en local ou en remote, de toute manière, je suis dans un terminal...
                    • [^] # Re: virt-manager

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

                      Qu'est ce que vous utilisez comme logiciel pour éditer vos XML qui soit libre, génial, convivial... Je n'ai pas fait le tour de la question depuis quelques temps mais à l'époque, c'était pas terrible.

                      J'aimerais bien voir l'interface de configuration d'un serveur comme exim fait via un schéma ?

                      Je sens que dans ce débat, il y a les pros XML qui m'ont l'air pour les IHM graphique de configuration et les autres. Pour moi, une IHM graphique pour configurer exim me semble une voie glissante vers le clickodrome Windows ou finalement, tu ne comprends pas grand chose de ce que tu fais. Comment répares-tu ce genre d'usine à gaz, bien tu ré-installe comme tout le monde car c'est quasiment pas réparable sauf par un spécialiste quasi inexistant.

                      Exemple pris sur un logiciel qui n'est pas un serveur : thunderbird. Je ne sais pas vous mais moi, lorsqu'un de mes utilisateurs a un profile qui pars en sucette (et cela arrive parfois malheureusement), je suis incapable de réparé cette usine à gaz et je repars sur un nouveau profile. L'utilisateur est content mais en réalité, je suis d'une grande incompétence.

                      Je voudrais éviter d'avoir à faire cela sur mes serveurs de mails, mes apaches, mes machines virtuelles, ma haute disponibilité... Je ne me considère pas comme un très bon administrateur système et pourtant, comme des milliers d'autres, j'arrive à réparer des configurations foireuses si celle-ci ne sont pas noyés dans des IHM graphiques et des fichiers de configurations obscurs.

                      Au final, je me fiche pas mal que le XML ait un schéma qui me permette de valider ma configuration. C'est comme un formulaire web, ce n'est pas au javascript de valider les données mais toujours au serveur. Idem pour un fichier de configuration, le serveur ne doit pas prendre le fichier de configuration pour argent comptant. Tant mieux s'il est juste.

                      Je préfère que le serveur ait un mode ou il charge le fichier de configuration et me disent lui-même ce qu'il en pense. Normalement, un serveur programmé correctement devrait avoir un mode comme cela. Qu'en interne, celui-ci transforme mon fichier de configuration en XML et lance un validateur de schéma, c'est le choix du programmeur et je le respecte entièrement.

                      > Après, un fichier de configuration c'est surtout fait pour stocker la
                      > configuration d'un logiciel

                      J'ai l'impression qu'il y a peut être là un mélange mais je me trompe peut être. On a l'impression que tu parles de l'état du logiciel. Que le logiciel stocke sont état sous un fomat quelconque pour se relancer plus vite et dans le même état ensuite me convient parfaitement. Dans ce cas là, autant avoir un format binaire type HDF par exemple mais toutes les solutions peuvent être bonne en fonction du contexte. Mais il ne s'agit plus vraiment de configuration (donc de /etc) mais plutôt de données donc dans /var ou /data
                      • [^] # Re: virt-manager

                        Posté par . Évalué à 1.

                        Tu mélanges plusieurs choses. Le fait qu'un logiciel gère sa configuration n'importe comment et le langage qu'il utilise pour la décrire.

                        Tu critiques les logiciels que tu ne comprends pas ou qui ont un horrible fichier de conf qui n'est plus ou moins qu'un dump mémoire. Pour ceux que tu ne comprends pas il te suffit de lire la doc. Typiquement la conf d'exim est tout sauf simple mais tu as passé beaucoup de temps pour l'appréhender. Pour les logiques moisies, quel que soit le langage utilisé ca restera moisi.

                        On peut faire des choses très correctes en les décrivant en XML. La conf de tomcat est simple et bien foutue. Lis les 50 premieres pages de Professional Apache Tomcat et tu seras capable de presque tout faire. C'est pas plus compliqué qu'apache ou exim. Et c'est tout aussi robuste et maintenable.

                        Après les technos autour d'xml comme la sérialisation automatique poussent certains à la paresse... Pour moi la paresse s'arrête à laisser au parseur toute la validation (validité, type, restriction). Définir un bon fichier de config prend du temps XML, YAML ou ce que tu veux.

                        Un bon éditeur XML "léger" libre est un gros manque. Pour les devs tu as eclipse/netbeans mais qui font chier avec la gestion de projet et pas adapté aux administrateurs. Autrement tu as quelques bon outils proprio...

                        > Idem pour un fichier de configuration, le serveur ne doit pas prendre le fichier de configuration pour argent comptant. Tant mieux s'il est juste.

                        La complétion/validation coté éditeur c'est pour aider l'utilisateur ! En éditant ton fichier tu as accès à la doc en ligne, ton éditeur te propose toutes les options possibles automatiquement, les mots cles/valeures/contraintes d'intégrité sont vérifiées. Bref c'est super pratique, plus de typo ou de trou de mémoire. Et évidement le serveur fait sa propre validation !
                • [^] # Re: virt-manager

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

                  Soit rebelle.

                  Sois.

                  Ben ça ne va pas loins.

                  Loin.

                  C'est du libre. Fock libvirt.

                  Forke ?

                  C'est beaucoup plus fort que de critiqué

                  Critiquer.

                  N'utilises pas libvirt, n'utilises pas Gnome, n'utilises pas Firefox, etc.

                  Utilise.
          • [^] # Re: virt-manager

            Posté par . Évalué à 2.

            L'argument fallacieux est, selon moi, que tu dises : xml implique java implique gui. gni ??

            Ensuite dire que les fichiers textes sont entreprise car Unix l'est et les utilise; c'est tout aussi bof. (Unix qui date d'une époque, où XML n'existait pas/ne pouvait pas exister dans sa forme actuelle). The cfengine project was started in 1993 as a reaction to the complexity and non-portability of shell scripting for Unix configuration management, and continues today. (wikipedia), ça m'a l'air toujours très "enterprise" comme truc les fichiers de conf.

            Ensuite dire: des arguments que je considère comme fallacieux : "il me faut des méta outils qui puisse me générer mes fichiers de conf"; alors que tu dis exactement la même chose...

            Du beau grand troll.
  • # sous macosX, c'est vraiment pas mal

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

    Bon, je viens d'installer le bouzin. J'avais au préalable une version de paralell qui fait un peu la même chose. Mais payant...

    Ben... le moins qu'on puisse dire, c'est que virtualbox est plus véloce, plus réactif. Je viens d'installer un vieil xp qui trainait à la maison : rien à dire, ça déroule.
    J'ai également installé une mandriva spring2008. super.


    pour répondre à "quel intérêt ce genre de chose?", j'en vois immédiatement au moins un.
    Quand tu fais le webmunster comme moi, avec quelques sites en production, il est intéressant de voir en direct, l'évolution de ta page et des modifs que tu fais sous différentes architectures, leur rendu.
    là je viens de voir, par exemple que mon site principal merdouille un peu sous kde.

    Et j'ai pas eu besoin d'allumer 36 ordi pour le voir.


    Adopté chez moi, en tout cas...
    • [^] # Re: sous macosX, c'est vraiment pas mal

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

      quel intérêt ce genre de chose?
      Il y a beaucoup de besoins différents. Dans notre entreprise, j'ai décidé de virtualiser pour que les serveurs Windows fonctionnent plus rapidement (oui oui, plus rapidement en passant par vmware, no comments). Notre seconde grosse raison est la sauvegarde et remise en route: nous copions simplement les images virtuelles. Ca redémarre sur n'importe quel ordinateur (ayant vmware tout de même) et les sauvegardes sont garanties complettes à 200% puisque c'est une bête copie du disque virtuel. Nous avons maintenant une troisième raison: mettre plusieurs serveurs Windows sur une seule machine physique.
      • [^] # Re: sous macosX, c'est vraiment pas mal

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

        tiens une petite question de béotien, alors pour toi.

        imaginons un PC sous winxp. je lance une virualbox avec une mandriva dedans. dans cette mandriva je lance un serveur http avec php-hétoussa.

        Depuis windows, puis-accéder à ce serveur via un navigateur?
        • [^] # Re: sous macosX, c'est vraiment pas mal

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

          imaginons un PC sous winxp
          Même pas en rêve :-)

          Ta machine virtuelle est un ordinateur comme n'importe quel autre ordinateur. Si tu sais faire fonctionner ton serveur http sur une machine physique, c'est la même chose sur la machine virtuelle.

          La différence est que la machine hôte controle les accès disque, réseau, la mémoire etc, ce qui permet de mettre en place des commutateur réseau virtuels par exemple. Tu peux ainsi "brancher" ta machine virtuelle sur un réseau virtuel qui ne peut pas sortir de ta machine physique. Ou tu peux brancher ta machine virtuelle sur la même chose que ta machine physique. Tu peux faire un peu tout ce que tu veux pour filter les paquets, limiter les débits, rediriger les flux.
        • [^] # Re: sous macosX, c'est vraiment pas mal

          Posté par . Évalué à 2.

          "dans le temps avec coLinux" (...) l'une des méthodes était d'utiliser des adresses locales du genre 192.168.0.123 définies dans le /etc/network/interfaces de la machine virtuelle

          du coup ensuite c'était http://192.168.0.123 ou bien on rajoutait une entrée 192.168.0.123 pouetpouet dans C:\Windows\system32\drivers\etc\hosts pour avoir ensuite http://pouetpouet ...

Suivre le flux des commentaires

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