• [^] # Re: Pour les petites entreprises !?!

    Posté par . En réponse à la dépêche Livre blanc Bearstech sur la virtualisation en logiciel libre. Évalué à 2.

    > 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.