Salut,
J'ai été confronté à ce soucis de mise à jour de kernel et synchro des libs y a quelques semaines. Pour simplifier Xen3 en stable me suffisait mais en changeant une dedibox pro par les nouvelles le kernel minimum pour le matériel est 2.6.32 alors que Xen en stable est de mémoire en 2.6.26.
Du coup ce que je regardais sur l'évolution de xen et notamment la version 4, j'ai du l'appliquer rapidement sur le nouveau serveur. J'ai fait une installation de xen 4 à partir de testing et le kernel backport qui va bien avec. Je ne suis pas fan du mix de versions de paquets mais c'est maintenable facilement vu que le dom0 ne fait que du xen et firewall.
Comme toi j'ai mis à jour les lib des vm en les montant en local et en copiant le répertoire /lib/modules qui va bien et mise à jour du fichier de conf de la vm et surtout un petit update et dist-upgrade après le boot. C'est clairement la méthode montré un peu partout quand on parle d'upgrade de xen.
Par contre en réinstallant les autres serveurs et en passant de xen 3 vers xen 4 je n'ai pas rencontré ton problème de depmod. C'est sans doute du au fait que j'ai complètement réinstallé le dom0 plutôt que de faire une mise à jour. J'ai juste déplacé mes vm avant de faire la maintenance. Quel impact as tu constaté lors de ta mise à jour?
Le 28 juil. 2010 à 22:08, Olivier Bonvalet a écrit :
Hello la liste,
suite à quelques déboires avec depmod qui a évolué entre Lenny et Squeeze, je me demande si ma méthode de propagation des kernels sur les VM est judicieuse. Il arrivera fatalement un moment où le Dom0 et le DomU ne seront pas "compatibles". De plus, si au passage je peux automatiser un peu plus ou améliorer le process, c'est pas plus mal.
Le contexte : le kernel utilisé dans la VM est fourni par l'host, mais il faut aussi propager les modules du kernel dans la VM. Actuellement j'utilise un script sur le Dom0 qui coupe la VM, monte son système en local, balance les dossiers de /lib/modules/, mets à jour la version du kernel indiquée dans le fichier ".cfg" et enfin redémarre la VM. Rudimentaire, mais fonctionnel.
Problèmes :
- le Dom0 doit donc avoir une version de /lib/modules/ compatible avec ce qu'attend le DomU (d'où mon soucis Lenny/Squeeze)
- la mise à jour du kernel est donc déclenchée à l'initiative du Dom0... donc pas d'autonomie de ce coté pour le client
Solution 1 : déplacer le kernel dans la VM. Cela implique l'utilisation de pygrub (sécurité ?), et d'avoir un outil de propagation simple du kernel sur chaque VM, si possible sans avoir à trop intervenir. On gagne en souplesse, mais pour l'industrialisation c'est un peu rapé.
Solution 2 : compiler les modules en statique, et toujours utiliser le même nom de kernel (ou faire pointer un lien symbolique). Ainsi à chaque reboot la VM prend automatiquement la dernière version du kernel qu'on lui propose. J'utilise déjà cette technique dans le cadre d'un projet spécifique, mais manque de bol ici j'ai besoin de l'aspect modulaire de mes kernels.
Solution 3 : déployer le kernel et ses modules dans 2 packets Debian adéquat, à fournir pour toutes les distribs utilisées (y compris dérivés Debian), ajouter le repository en question sur chaque VM, et synchroniser comme il faut les mises à jour de paquet Dom0 & DomU... C'est la solution utilisée par défaut avec ce que propose Debian, mais ça ne me semble pas vraiment jouable ici.
Solution 4 : utiliser un lien symbolique pour pointer sur le dernier kernel dans le fichier de conf Xen (cf solution 2), et utiliser un système de fichier spécifique pour propager automatiquement mon dossier /lib/modules/ dans la VM. NFS, ou une partition spécifique en read-only commune à toutes les VM et à ajouter dans le fstab de chacune d'elles. Ca me semble tordu comme montage, mais ormis l'aspect bricolage ça semble répondre à tous mes problèmes.
Solution 5 : faire comme certains hébergeurs et ne mettre à jour le kernel que tous les 5 ans. Un petit coucou en passant à mon hébergeur préféré qui me fourni un joli 2.6.16 sur ses Xen ;)
Et vous, vous faites comment pour déployer vos kernels sur les VM ? Ai-je loupé une solution plus simple / rapide / propre ?
Olivier B. _______________________________________________ FRsaG mailing list FRsaG@frsag.org http://www.frsag.org/mailman/listinfo/frsag
-- Pierre-Henry Muller