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.