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
