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.
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
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
Le 29 juil. 2010 à 10:02, Olivier Bonvalet a écrit :
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
Je n'ai vraiment pas eu les mêmes soucis, pourtant mes vm sont en stable aussi. Si un depmod lancé sur chaque vm suffit, pourquoi ne pas l'automatiser au moment où tu traites ta vm pour lui mettre les nouveaux modules, un chroot dans son montage et la commande est lancée?
-- Pierre-Henry Muller
-
Olivier Bonvalet -
Pierre-Henry Muller