IsNotGood a écrit 5009 commentaires

> Pour les fonctionnalités sparse et overlay, il faut en effet que le kernel le gère

Ils le gèrent quasiment tous aujourd'hui. Ça existe depuis si longtemps...

> mais je les mentionne parce que la page de man de Qemu en parle, et ça me semblait important de les mettre en avant.

Il semble que qemu a effectivement un format qui lui est propre (qcow2). Il est là pour les systèmes qui ne supportnt pas "sparse file" (typiquement Windows). Sous Linux, on n'en a pas besoin.

Erreur grave.
Casser sa distribution et la réparée est le meilleur moyen pour devenir un "guru" et sur toute les distributions (ben oui, toutes les distributions sont "cassables").

> J'ai survolé le libre blanc et me suis attardé sur quelques points.

J'ai maintenant tout lu :-)

> J'ai l'impression que le livre blanc avait un certain type de "petites entreprises" en tête.

Du livre :

Le chapitre suivant sera consacré à l’étude des besoins d’une PME spécialisée dans l’hébergement de sites web en matière de virtualisation.

[...]

Dans ce livre blanc, nous nous limiterons aux solutions de virtualisation utilisables pour une PME ayant comme principale activité l’hébergement d’applications Web.

Bref, des entreprises très spécialisées. Pas pour toutes les petites entreprises comme je l'ai cru au début.


Du livre :

Gestion des images systèmes
En ce qui concerne les images systèmes, QEMU se base sur des images disques complètes, avec son propre format de stockage (QCOW — QEMU Copy On Write).
[...]
Les images au format QCOW sont « creuses », c’est à dire qu’à la création du fichier, il n’occupe que quelques octets.

Je crois que ce n'est pas un "format" Qemu. C'est seulement une fonctionnalité qu'on trouve dans vfs du noyau. En tout cas ext3 le supporte, c'est la fonctionnalité "sparse file". Les images Qemu sont "bêtement" des images sans rien de particulier.

Exemple (utilisant un fichier "creu" créé par libvirt (et non qemu, mais peut être utilisé par qemu)) :
[root@one ~]# ll system_test.img ; du system_test.img
-rwxr-xr-x 1 root root 5242880001 jan 13 03:29 system_test.img
20 system_test.img
[root@one ~]# mke2fs -j system_test.img
[...]
[root@one ~]# mkdir mount_point
[root@one ~]# mount -o loop system_test.img mount_point
[root@one ~]# df mount_point/
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/root/system_test.img
5039616 141216 4642400 3% /root/mount_point
[root@one ~]# du system_test.img
213392 system_test.img
[root@one ~]# dd if=/dev/zero of=mount_point/zero bs=1M count=1000
1000+0 enregistrements lus
1000+0 enregistrements écrits
1048576000 bytes (1,0 GB) copied, 7,31288 s, 143 MB/s
[root@one ~]# du system_test.img
1239160 system_test.img

Notons bien que c'est spécifique au système de fichier. Si on copie le fichier sans prendre de précaution, il fera 5 Go (mais on peut le copier avec cp --sparse=... pour ne pas qu'il "grossisse", mais le système de fichier de destination doit supporter "sparse file").


Du livre :

L’attitude de la société XenSource vis à vis de la communauté est résumée par la phrase suivante, affichée de manière très visible sur leur site web :

« XenSource is totally committed to the Xen community and the open source process. (XenSource est entièrement impliquée dans la communauté Xen et dans le processus open source.) »
Ian P RATT, leader du projet Xen

MMOOUUAAIIFFF...
Heureusement qu'il n'y a pas Linux dans la phrase...

En passant, Red Hat (qui n'est *jamais* cité parmis les contributeurs à la virtualisation dans ce livre blanc alors que lwn.net a démontré plus d'une fois que c'était le plus gros contributeur à linux...) en a marre d'avoir à toujours porter Xen sur les différentes versions de Linux et surtout marre que Xen refuse de prendre en compte ce boulot (XenSource reste à Linux 2.6.16) :
http://berrange.com/personal/diary/2007/11/plan-for-xen-kern(...)
Faut lire entre ligne :

For a long time we ported their 2.6.16 tree to 2.6.18. Now we do ports of their 2.6.18 tree to 2.6.21/22/23, etc.
[...]
We simply cannot spend more time forward porting Xen kernels.

Bien que Xen soit la meilleur solution actuelle, ça ne va pas empêcher Red Hat de s'en désengager car ce n'est plus tenable (Red Hat continura de maintenir/porter certaines parties de Xen pour compatibilité avec RHEL5 comme le sous-entend le lien précédent).

Notons bien XenSource est toujours à la version 2.6.16 de Linux ! (ou alors ça a récemment changé).

> Un autre aspect négatif du projet Xen est le fait qu’il est externe au projet Linux.

Et ne fait pas grand chose pour se synchroniser avec Linux...
Tout ceci peut être compréhensible depuis le rachat par Citrix qui va se concentrer sur Windows, l'embarqué, etc...
A terme, au moins pour les serveurs ou machines de développement, Qemu/KVM va remplacer Xen sur Linux et ça ne semble pas déranger Citrix.

Du livre :

Une fonctionnalité complémentaire au mode snapshot est le mode overlay (surcouche). Avec ce mode de fonctionnement, très similaire au snapshot, les modifications apportées aux fichiers sont stockées dans un fichier supplémentaire, qui ne conserve donc que les éléments différents du fichier image original.

C'est device-mapper/lvm2 qui fournit la fonctionnalité je crois. Donc on peut le faire avec n'importe quoi. Qemu doit le proposer, je n'ai pas vérifié.

Du livre :

Le projet KVM dispose quant à lui de bien moins de solutions de supervision. Il y a toutefois un projet qui mérite d’être mentionné : Virtual Machine Manager.

Libvirt (qui fournit virsh, virt-manager étant une interface graphique au-dessus de libvirt) peut gérer Qemu/Kvm et Xen. Un support OpenVz a été réalisé récemment je crois. Notons que RHEL (ou Centos...) utilise libvirt au-dessus de Xen. Donc ce n'est pas spécifique à Qemu/KVM.

> Sinon, amha, le type se tire une balle dans le pied. :)

Refuser de façon butée la virtualisation, c'est aussi se tirer une balle dans le pied.
Ce n'est pas car il y a des mauvais usages de la virtualisation (comme pour tout) qu'il faut en conclure que la virtualisation est sans intérêt.
On pourrait facilement donner pleins de cas où 10 machines physique sont utilisées alors que 4 ou 5 suffiraient sans problème (même sans utiliser de virtualisation).
Trop de virtualisation c'est nul. Trop de machine physique aussi.

J'utilise actuellement la virtualisation. Je dois faire un site web qui va tourner sur un serveur dédié (virtuel ou réel, qu'importe). Le développement va se faire sur ma station de travail. Elle a une distribution communautaire et donc un support dans le temps trop limité. Il me faut une distribution avec un long support pour ce site web.
Que faire ?
Acheter une nouvelle bécane ?
Non, c'est ridicule.
Installer l'autre distribution en multi-boot et booter dessus lorsque je veux/dois bosser sur le site ?
Trop chiant, je perds tout mon environnement.
Etc...

La solution pour mon cas (et que ce cas) est d'installer une machine virtuelle avec le distribution qui sera utilisée pour le site web. Et voila. C'est facile, c'est rapide, ça marche très bien. C'est se tirer une balle dans le pied que de ne pas le faire.

J'ai survolé le libre blanc et me suis attardé sur quelques points.

Premièrement, et c'est à ne pas à oublier lors de la lecture de la suite du commentaire, c'est un très bon et important travaille. J'en conseille la lecture pour ceux qui veulent se familiariser avec la virtualisation et plus.
Effectivement, comme certains le disent plus haut il y a toujours à redire. La virtualisation proposent plein de solutions et souvent compliquées. Chaqu'une à ses atouts. Normal de faire quelques erreurs.

Ce qui m'a "choqué", c'est que le livre blanc est consacré aux "petites entreprises". Ce n'est pas "petites" qui me posse problème, c'est "entreprise".

Une entreprise (la majorité en tout cas) va prendre une offre complète. Pas un programme/projet où elle doit patcher X ou Y pour que ça marche ni être obligé d'être abonné aux mailing list des développeurs (bien que ça ne soit pas une mauvaise idée).
J'ai l'impression que le livre blanc avait un certain type de "petites entreprises" en tête.

Quelles sont les offres ?
Vmware, Xensource évidemment.
Il doit aussi y avoir Novell (mais je ne me suis pas documenté).
Il a aussi Red Hat qui en fait sa première priorité depuis 2 ans (ce qui devrait durer encore de nombreux mois).

Le problème pour une majorité d'entreprises n'est pas Xen vs Qemu/KVM vs OpenVz. Le problème c'est l'offre (packaging, facilité d'utilisation, support, formation, applis certifiées pour l'environnement virtuelle, etc).
Xen "nu" ou Qemu/KVM ou autre ne sont pas satisfaisant pour une entreprise (il y a toujours des exceptions pour confirmer la règle). Le livre blanc le dit.

C'est sous cet angle que je pensais le livre blanc serait fait.

Un exemple d'offre de virtualisation très intéressant et un peu particulier (Amazon EC2) :
http://www.amazon.com/b/ref=sc_fe_l_2?ie=UTF8&node=20159(...)

On peut choisir des images publics, en acheter, les stocker, les "instancier", etc. On peut choisir sa machine virtuelle parmis 3, on paie à l'heure, etc. On trouve des images spécialisées pour Alfresco, etc. Une boite c'est spécialisé dans le support EC2 : http://info.rightscale.com/
Et qu'importe qu'EC2 utilise Xen ou KVM (pour info, c'est Xen actuellement).

Il est claire que l'analyse de ses offres est très très compliqué.



En passant, "Virtual Machine Manager" est virt-manager :
http://www.virt-manager.org/
Virt-manager n'est que la partie visible et qu'une application. Le plus important (du moins techniquement) est libvirt :
http://www.libvirt.org/

> Il est donc tout à fait envisageable à l’heure actuelle d’utiliser une architecture
complète de virtualisation constituée uniquement de logiciels libres.

Pub : http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/(...)
C'est "une architecture complète de virtualisation constituée uniquement de logiciels libres" et ça utilise libvirt/virt-manager (pas seulement). Mieux, c'est supporté, il y a des formations, pleins de fournisseurs de logiciels (libre et proprio) qui certifient/supportent, etc...

On n'est pas dans l'"envisageable". C'est du concrêt (sorti début 2007, grosse mise à jour vers novembre 2007).


Quand à l'avenir de KVM et pour confirmer l'impression de l'auteur du libre blanc, il faut noter que Red Hat va "abandonner" Xen pour se consacrer quasi exclusivement à Qemu/KVM/paravirt_ops (c'est comme ça pour Fedora qui est la base de RHEL).
Je pense que les solutions de cloisonnement ont aussi un bel avenir.



Très bon document avec de très bonnes informations. La cible a été un peu ratée :-)
Pour les solutions 100 % libre pouvant intéresser une majorité d'entreprise, ça se comprend facilement. L'offre est actuellement peu étoffée et manifestement peu visible (vu que le plus gros distributeur "entreprise" est passé inaperçu).
C'est un domaine en pleine évolution qui méritera un nouveau livre blanc dans quelques mois. Une mise à jour de ce livre blanc ?

Présice quand tu ne parles que de KDE. Merci.

> Les kdegames

Pour les jeux je trouve ça justifiable (relire ce que j'ai écris).
Plus globalement, j'ai dis que KDE 4, au moins pour les applis, est plus cohérent que KDE 3 et ça se voit (me relire encore, et voir les copies d'écran que j'ai donné). Étant un utilisateur (occasionnel) d'applis KDE, les applis KDE 4 vont probablement plus me plaire que les applis KDE 3. Aussi bien au niveau esthétique que ergonomie. Précisons le "plus me plaire", les applis KDE 4 (de ce que j'ai vu) me plaisent. Oui, ça ne me dérange pas de faire tourner des applis KDE sur mon bureau Gnome.

Ce que je n'aime pas, c'est le panel. Alors mets sur "les goûts et les couleurs" et basta.

> Non, non et non. C'est uniquement sur la surface de jeu que ça a été fait comme ça.

Rires.

> Pour moi ça ne suffit pas, en effet. La présence d'un compte anonyme je n'aime pas du tout, c'est la seule chose que je disais.

Ben n'aimes toutes connections au réseau etc...
Avec bittorrent (ou n'importe quoi) tu n'es pas à l'ablis "d'élevation de privilège qui peuvent exister, Ou les déni de service en provoquant un petit kernel panic, ou ce genre de choses..."

> Quant à ta propagande pro fedora, j'en ai strictement rien à battre (et tu peux te la carrer où je pense).

Alors casse toi avec ta petite vision.
D'autres "fans" d'autres distributions sont moins cons. Ils vont se dire que c'est intéressant et le mettre dans leur distribution. C'est toute l'intention de mon journal. Faut être très cons pour refuser les bonnes idées des autres.

> pour que ça ne recommence pas non ?

J'hésite.

> douloureux

C-à-d ?
Les faits sont faits. Les cacher ne les rend pas moins douloureux.

> Ben non

Ben oui.

À une époque kde c'était limite du n'importe quoi. Si on le disait on se faisait descendre. Maintenant c'est moins le cas. Tant mieux. KDE a fait un HIG et l'applique. Et globalement ça se voit et c'est un plus.

> Ben non, ils dessinent juste des "boutons" sur la surface de jeu qui vont avec le look du jeu pour que ça fasse mieux.

Comme on voit/voyait ça avec les lecteurs multimédias, etc...
Si tout le monde fait comme ça et que tout le monde trouve ça normal...
Chaqu'un ses widgets parce que pour son application toute seule c'est mieux...

Ce principe MERDE.

La faiblesse de mes exemples est que ça concerne des jeux. Souvent les jeux veulent immerger le joueur. Lui mettre les "références" du standard du bureau n'est pas pertinent. Ce qui n'a pas forcément grand chose à voir avec l'esthétique ni l'ergonomie.

Laisse tomber, son raisonnement est complètement bidon.
Il demande si ça protêge lorsque les systèmes de protection sont contournés.
Que dire à part que lorsque les systèmes de protection sont contournés, ça ne protège plus.... Par définition.

C'est comme ça pour tous les systèmes.
M'enfin xguest est actuellement implémenté sous Fedora. Et Fedora est probablement l'une des distributions les mieux dotées en protection (SeLinux de base ! et beaucoup plus) :
http://www.awe.com/mark/blog/200801070918.html

Puisque ça ne lui suffit pas, ben qu'il passe sa bécane au boyeur.

http://www.deadbabylon.de/blog/2008/01/11/livecd-for-rawhide(...)

La listes des paquets :
http://fedoraproject.org/wiki/SebastianVahl/CurrentPackageLi(...)

C'est un instantanné de Rawhide (branche de développement de la futur F9) donc avec plus de bugs que d'habitude.

Notons (et on le voit déjà avec ce cd-live) que Fedora veut faire de KDE 4.0 le KDE par défaut. On voit déjà que l'ancien kdebase a été renommé kdebase3 et kdebase est kdebase-4.0.0. C'est clair ?

Le copie d'écran sont enfin intéressantes :
http://www.deadbabylon.de/blog/bilder/kde4/
Globalement ce n'est pas ma tasse de thée. Le thème des widgets est globalement bon. Sombre et lisible, voire moderne. Au pif l'ergonomie et la cohérence des applies semblent globalement nettement plus travaillée que KDE3. Avoir du text avec les icones est un plus.
C'est le reste qui cloche. Le panel par exemple. C'est quoi ce truc ? Et cette grosse montre ? Et ce fond noir...
Comme on fait pour savoir quelle est la fenêtre qui a le focus ?

Regardons ça :
http://www.deadbabylon.de/blog/wp-content/myfotos/kde4/rawhi(...)
Les deux jeux de gauche ont des widgets à leur propre sauce.

"Révolution", on peut mettre le bouton "démarrer" sur le bureau :
http://www.deadbabylon.de/blog/wp-content/myfotos/kde4/rawhi(...)
Ce genre de truc est de la bêtise aujourd'hui.
Soyons gentil, on dira que qui peut le plus peu le moins...

> C'est quand même vrai que Gnome aura du mal à s'en remettre.

Je suis un pro-Gnome et répondre me démange.
M'enfin, on en tire sur une ambulance.

> Outre le fait que j'imagine que cela ne fonctionne que pour GNOME

Ça pourrait marcher avec KDE ou autre sans trop de boulot. Mais actuellement c'est que Gnome. Tout patch est le bienvenu.

> quelle est la différence avec le vénérable et bien plus ancien KDE kiosktool ?

Je crois que tu confonds kiosktool et sabayon.
xguest (le projet décrit dans ce journal) peut aussi profiter à KDE. L'administrateur utilisera alors kiosktool.

Relis attentivement :
http://danwalsh.livejournal.com/13376.html?thread=100672

> Je me fiche de savoir que des grands noms du noyau Linux l'ont employé un jour.

Même les grands noms disent des conneries.
Et tu as raison de préciser "un jour".

Sinon +1000 pour ton commentaire.

> Et elles arriveront quand, alors, ces intefaces utilisateurs "next-gen" ?

Quand tes enfants seront grands.

J'ai utilise nouveau et nv.
Je n'ai pas utilisé les drivers proprios, donc je ne sais pas si le driver nouveau est aussi rapide que le driver nvidia.

Sinon j'ai dit à deux reprises que le driver nv est "satisfaisant" au niveau performance et que le driver nouveau est (beaucoup) plus rapide. À toi voir.

http://www.thecodingstudio.com/opensource/linux/screenshots/(...)

Mouaif. Il y a un côté "on veut être post-moderne" et un côté jouet.

> "KHTML was also the first engine to pass the famous Acid 2 test."

Comme IE8 :
http://blogs.msdn.com/ie/archive/2007/12/19/internet-explore(...)

Il est très bien. Pas de problème.
J'étais mal luné. C'est tout.

Installe KDE to be free :
http://kde.org/

> En revanche, pour le journal, s'il te plaît IsNotGood, relis-toi !

Pour la petite histoire.
J'allais me relis évidemment. Mais le correcteur orthographique a changé et il souligne en petit pointillé rouge les mots douteux. Esthétiquement c'est mieux. Mais c'est peu visible et ça m'a gonflé. J'ai "donc" validé le journal sans le relire.

> _UNE_ perle (parmis d'autres)

Sans perle, ce n'est plus un journal IsNotGood.

Zut, j'ai oublié de dire un truc.
Je n'utilise pas eclipse pour le débuggage. J'utilise ddd sous Linux et Visual C++ sous Windows.

En passant, j'utilise IcedTea pour eclipse sous Linux et la vm de Sun sous Windows.
J'utilise eclipse avec subclipse (marche très très bien maintenant) et mylin (gestion de projet, bugzilla, etc).