Bonjour,
en fait j'ai justement commencé à passer mes Dom0 en Squeeze, car la
version backport de Xen de Lenny me posait pas mal de soucis (je ne
saurais dire lesquels, je ne me souviens plus). Toutefois les VM sont
toujours en Lenny, pour la plupart.
Mon problème vient plutôt de la maintenance régulière des kernels des
VM, j'utilise un 2.6.32 "vanilla", que je mets à jour au gré des
nouvelles sorties. Ces kernels pvops sont encore jeunes, et quasiment à
chaque mise à jour il y a des correctifs Xen.
Pour ce qui est de mes problèmes de compatibilité, depuis Squeeze le
fichier modules.dep contient des chemins relatifs alors qu'en Lenny ce
sont des chemins absolus. Résultat, une Lenny avec un fichier
modules.dep généré depuis une Squeeze est incapable de charger un
module. Il "suffit" de lancer un "depmod -a" dans chaque VM concernée,
mais ça n'est pas vraiment pratique non plus.
C'est donc pour ça que je réfléchis à faire évoluer tout ça.
Olivier
Le 29/07/2010 09:41, Pierre-Henry Muller a écrit :
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
_______________________________________________
FRsaG mailing list
FRsaG@frsag.org
http://www.frsag.org/mailman/listinfo/frsag
_______________________________________________
FRsaG mailing list
FRsaG@frsag.org
http://www.frsag.org/mailman/listinfo/frsag
