Journal KVM/QEMU/libvirt démo

L'article : http://www.phoronix.com/vr.php?view=9066

L'article montre l'installation, les doigts dans le nez, de FC5, FC4, Ubuntu 6.10, Mandrake 9.2, Windows XP, Windows Server 2003, Windows Vista sur F7 test 2 (test : c'est une béta, il y a des bugs, ça peut bouffer les jambes des bébés ou un chat, et c'est normal, vous êtes prévenus) en utilisant KVM/QEMU. KVM est dispo sur Linux en upstream depuis 2.6.20.

Windows Vista et Ubuntu 6.10 n'ont pu être installé. Pour Ubuntu c'est probablement un bug de F7 test 2 ou Ubuntu. On a l'assurance que ça va être corrigé ou qu'au moins ce n'est pas intentionnel. Pour Vista, on tombe sur un "blue screen of death". On peut se demander si MS ne le fait pas exprès. Pure supposition de ma part, d'accord, mais je n'ai pas oublié que MS a refusé que Xen continue de bosser sur une version modifiée de Windows qui permet d'utiliser la paravirtualisation (typiquement pour faire tourner Windows sur Linux). De plus MS l'interdit (dans le cas de la paravirtualisation).

NB : je n'ai pas utilisé KVM, mon cpu ne le permet pas et je suis limite niveau RAM (seulement 512 Mo, mais satisfaisant pour un OS). Je n'aime pas changer de matos quand qu'il marche bien, mais je commence à crever d'envi de m'acheter un CPU avec VT :-)

En parcourant l'article on voit que libvirt offre une facilité déconcertante.

Libvirt a été à l'origine développé par Red Hat (introduit dans FC5). Il est disponible et ouvert à toute contribution :
http://www.libvirt.org/ Licence : GPL

Dès l'origine libvirt a été développé pour supporter plusieurs solutions de virtualisation. Ce domaine étant récent, il bouge beaucoup.

XEN

Désamour entre Red Hat et Xen ? Peut-être. Fedora 7 n'aura peut-être pas Xen. Le dernier noyau de développement n'a pas Xen. En tout cas, F7 sera la dernière Fedora avec Xen.
Plus qu'à demi-mot, les développeurs noyaux de Red Hat (et pas seulement eux) ont dit que c'était une peine terrible de maintenir Xen dans Linux. Mais ne crachons pas dans la soupe surtout que beaucoup de machines n'ont pas la technologie VT.

Compatibilité

La compatibilité est une contrainte en développement logiciel. Comment faire évoluer quelque chose quand en même temps les exigences de compatibilité demandent de ne rien changer ? On sait ce qu'en pense Linus Torvalds et bon nombre de développeurs noyau.

Windows a une longue pratique d'offrir la compatibilité ascendante (source et binaire) même si pour Vista ça sucks un peu. Ça a fait en partit son succès. C'est une exigence légitime des entreprises pour qui un sou est un sou.
GNU/Linux (l'OS, pas seulement le noyau) n'est pas en reste, mais se contraint moins sur ce point et est plus exigent envers les développeurs d'applications qui doivent de temps à autre porter leur application vers la dernière version.

Globalement le libre (sa communauté de développeurs) n'est pas très pointilleux sur la compatibilité. Je comprend ça parfaitement.

Mais les entreprises le sont. Ainsi il y a des distributions pour entreprise. La tâche d'offrir la compatibilité est si "ingrate" que ce sont des développeurs payés qui le font. Ces distributions offrent une stabilité de l'API (binaire et source) sur plusieurs années (7 ans pour Red Hat, 9 ans (?) pour Novell). Mais ça ne conserne qu'une version de la distribution. Un programme qui tourne sur RHEL version n peut ne pas marcher sur RHEL version n+1 (ni Red Hat ni Novell le garantit).

Sans transition, Red Hat a sorti en beta RHEL 4.5 ("service pack" 5 de RHEL 4 en terminologie Windows). Ces mises à jours ne sont pas des corrections de bug ou de sécurité, qui sont faites en permanence, mais ajoutent des fonctionnalités. La mise à jour 5 ajoute entre autre la possibilité de faire tourner RHEL 4 en invité (guest) sur la prochaine RHEL 5 via la paravirtualisation de Xen.
RHEL 4 utilise un 2.6.9 et uniquement un 2.6.9 (afin de conserver la compatibilité source ou binaire). J'imagine que la tâche n'a pas dû être aisée pour backporter Xen 3 sur un 2.6.9 (RHEL 5 utilise Xen 3).

Mais je m'égare :-)
La virtualisation va répondre à l'"impossibilité" de concilier le développement en upstream par la communauté (peu soucieuse de compatibilité) et l'exigence légitime des entreprises d'avoir une API stable. Du moins il faut que les changements d'API soit peu coûteux aux entreprises. Mais en même temps les entreprises veulent les dernières évolutions (plus de possibilité, plus d'opportunité, etc).

Avec RHEL 4.5 et 5, on voit déjà ce qui se dessine. je n'ai pas besoin de vous faire un dessin :-)
Avec la technologie VT, ça se fait tout seul (ou presque). Mais vu l'effort déployé Red Hat pour fournir RHEL 4.5 (afin que ce soit utilisable sur les CPU sans VT ; peut-être la majorité des bécanes qui utilisent RHEL 4) on sent qu'il y a une grosse demande ici.

J'enfonce des portes ouvertes, depuis longtemps on sait que la virtualisation va "bouleverser" l'informatique.
Je me réjouis que la virtualisation se marie bien avec le libre. Alors que le libre est de plus en plus développé par des entreprises (soucieuses de leurs clients, de compatibilité, etc), avec la virtualisation le style de développement du libre n'y perdra peut-être pas son "âme".

Retard de RHEL 5

Un paragraphe avant que les questions arrivent.
Il est facile d'avoir des infos sur Fedora (calendier, plan, etc), il est moins aisé d'en obtenir avec RHEL.
En général Red Hat ne donne pas de date de sorti ou reste très évasif. Peut-être sous la pression de SLES 10 qui fournit Xen (version 2 ?), Red Hat a annoncé la sortie de RHEL 5 pour fin 2006. Bizarrement c'est en décembre 2006 que Red Hat a annoncé que la sortie était repoussée pour le 28 février 2007 (finalement RHEL 5 doit sortir en mars).
J'ai du mal à croire que le retard de dernière minute soit lié uniquement à des bugs à corriger, sinon Red Hat aura fait l'annonce plus tôt. On l'a déjà vu pour Fedora, lorsqu'un retard est pris, il est annoncé très tôt. FC6 a été retardé de deux semaines (pour ne pas dire une semaine, car la sortie doit se faire un jour précis de la semaine pour respecter les exigences des administrateurs de mirroirs) à la fin de son développement à cause de bugs (1 voire 2 semaines, ce n'est pas 2 mois). Technologiquement une RHEL 5 est principalement une FC6 et ne part pas à l'aventure.

J'imagine que Red Hat a changé son plan pour RHEL 5 au dernier moment (ou que Red Hat avait fait une erreur dans son plan initiale). La paravirtualisation pour RHEL 4 n'avait peut-être pas été prévue (d'où cette annonce de beta tardive) et je pense que Red Hat ne voulais pas sortir RHEL 5 sans RHEL 4.5 dans son nouveau plan.
Il se dit aussi, "dans les milieux qui s'autorisent à penser", que Red Hat veut proposer une nouvelle solution de sauvegarde pour RHEL 5.

Quand Fedora ne sort pas une fonctionnalité importante, ce n'est pas grave. C'est repoussé de 6 ou 8 mois. Pour RHEL c'est grave, c'est repoussé d'au moins 18 mois, ce sont des clients de perdu durant 18 mois au moins.

Red Hat n'a pas une grande urgence à sortir RHEL 5. Red Hat vend du support. Tous ceux qui sont inscrit sur rhn auront accès à RHEL 5 (pas d'entrée de pognon pour Red Hat). RHEL 5 c'est principalement pour obtenir des nouveaux clients séduits par les nouvelles fonctionnalités.

M'enfin, je pense que Red Hat a sous estimé la tâche de livrer Xen.