Livre : Livre blanc Bearstech sur la virtualisation en logiciel libre
Posté par Lucas Bonnet (). Modéré le 12 janvier 2008.
Dans ce livre blanc vous trouverez une description des différents systèmes de virtualisation existants et des préconisations d'utilisation dépendant de l'usage que l'on veut en faire.
Pour terminer, ce livre blanc décrit les projets disponibles (KVM, Xen, VServer, etc.) avec un comparatif des différentes technologies utilisées.
Cet ouvrage très didactique ne nécessite pas de connaissances préalables sur le sujet. Il peut donc intéresser tous ceux qui veulent en savoir un peu plus sur la virtualisation.
Ce document est diffusé sous la licence CC By-NC-SA 2.0
![[fr]](../images/fr.png)
Lien vers l'article (1811 hits)-
Livre blanc (PDF) (4290 hits)
-
Autre livre blanc sur la virtualisation par Smile (1039 hits)
> Lire la dépêche (49 commentaires, moyenne: 1,8).
Vous avez demandé le commentaire #895858.
Cette page a été générée par Templeet en 0.0593s (dont 0.0056 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Pour les petites entreprises !?!
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 ?
[^]Re: Pour les petites entreprises !?!
> 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 :
Bref, des entreprises très spécialisées. Pas pour toutes les petites entreprises comme je l'ai cru au début.
Du livre :
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 :
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 :
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 :
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 :
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.
[^]Re: Pour les petites entreprises !?!
La définition de la « cible » n'était peut être pas explicite dès l'intro, c'est pas évident de s'en rendre compte quand on a le nez dedans :)
Pour les fonctionnalités sparse et overlay, il faut en effet que le kernel le gère, mais je les mentionne parce que la page de man de Qemu en parle, et ça me semblait important de les mettre en avant.
[^]Re: Pour les petites entreprises !?!
> 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.
[^]Re: Pour les petites entreprises !?!
Ooops.
Qemu a effectivement qcow et qcow2 comme format (qui ajoutent les fonctionnalités "compressés", cryptés, snapshot, etc et qui sont gérées par qemu). Mais comme j'ai toujours vu ça fait avec dm/lvm2, je n'avais pas imaginé que qemu avait un format spécifique.
Sous Linux c'est d'un intérêt très limité, mais qemu en tourne pas que sous Linux.
[^]Re: Pour les petites entreprises !?!
> Notons bien XenSource est toujours à la version 2.6.16 de Linux ! (ou alors ça a récemment changé).
2.6.18 et depuis deja quelques temps.
[^]Re: Pour les petites entreprises !?!
Salut,
2.6.20 pour ma part sous Gentoo/Linux 2007.0
@+,
Guile.
[^]Re: Pour les petites entreprises !?!
oui et non ;-)
Le kernel "officiel" xen est un 2.6.18
Par contre, certaines distributions telles que redhat, gentoo et surement d'autres "xenifient" elles-même leurs kernel.
Je crois que c'est une des raisons (le fait de devoir tout le temps xenifier les nouveaux noyaux alors que xensource ne le fait pas) pour lesquelles Redhat souhaite abandonner xen.
[^]Re: Pour les petites entreprises !?!
> 2.6.20 pour ma part sous Gentoo/Linux 2007.0
Pour info, 2.6.21 sous F8. Notons que le noyau sans Xen est un 2.6.23, que F8 va bientot passer à 2.6.24 et le noyau xen rester à 2.6.21. Bref, il y a un problème.
[^]Re: Pour les petites entreprises !?!
> 2.6.18 et depuis deja quelques temps.
Et le 2.6.18 est sorti depuis bien longtemps. Et entre temps le 2.6.19, .20, .21, .22, .23 sont sortis...
Bref, ça ne change pas grand chose au problème.
Merci d'avoir corrigé mon commentaire.
[^]Re: Pour les petites entreprises !?!
Comme je le soulignais, je voulais juste dire que le xen officiel est un 2.6.18.
Comme precise plus haut, oui, depuis d'autres versions sont sorties et Xen serait gentil de patcher tout seul au lieu d'attendre que d'autres le fassent, on parle quand meme de leur projet. Je rejoins le coup de gueule de RedHat ici, faut pas prendre les libristes pour des cruches.