Xen sous lenny et noyau 2.6.32 de squeeze

Bonsoir,

J'ai un dom0 xen (3.2.1) lenny amd64 (noyau 2.6.26-2).

Pour faire tourner quelques domU avec squeeze, j'ai mis
ça "à la main" en plus du 2.6.26 dans le /boot/ du dom0 :
# ls -al *32*
-rw-r--r-- 1 root root 106724 déc 1 17:24 config-2.6.32-5-xen-amd64
-rw-r--r-- 1 root root 9073101 déc 1 17:24 initrd.img-2.6.32-5-xen-amd64
-rw-r--r-- 1 root root 1693529 déc 1 17:24 System.map-2.6.32-5-xen-amd64
-rw-r--r-- 1 root root 2472320 déc 1 17:24 vmlinuz-2.6.32-5-xen-amd64

Pour l'instant les domU squeeze (et lucid aussi) fonctionnent bien.

Le truc c'est que lors d'une mise à jour du dom0, un update-grub
me prend en compte ce noyau 2.6.32 et me le met comme noyau de
boot par defaut (dans le menu.lst) du dom0 ! Et là le dom0 ne
boote pas ...
Y a t-il une méthode propre pour éviter ce comportement et continuer
à booter le dom0 sur le 2.6.26 ?

Bonsoir,

J'ai un dom0 xen (3.2.1) lenny amd64 (noyau 2.6.26-2).

Pour faire tourner quelques domU avec squeeze, j'ai mis
ça "à la main" en plus du 2.6.26 dans le /boot/ du dom0 :
# ls -al *32*
-rw-r--r-- 1 root root 106724 déc 1 17:24 config-2.6.32-5-xen-amd64
-rw-r--r-- 1 root root 9073101 déc 1 17:24 initrd.img-2.6.32-5-xen-amd64
-rw-r--r-- 1 root root 1693529 déc 1 17:24 System.map-2.6.32-5-xen-amd64
-rw-r--r-- 1 root root 2472320 déc 1 17:24 vmlinuz-2.6.32-5-xen-amd64

Pour l'instant les domU squeeze (et lucid aussi) fonctionnent bien.

Le truc c'est que lors d'une mise à jour du dom0, un update-grub
me prend en compte ce noyau 2.6.32 et me le met comme noyau de
boot par defaut (dans le menu.lst) du dom0 ! Et là le dom0 ne
boote pas ...
Y a t-il une méthode propre pour éviter ce comportement et continuer
à booter le dom0 sur le 2.6.26 ?

Merci.

Il suffit de le mettre ailleurs, par exemple dans /boot/xen et d'adapte r
la configuration des VM en conséquence.

Le 01/12/2010 20:47, Jean Baptiste FAVRE a écrit :

Il suffit de le mettre ailleurs, par exemple dans /boot/xen et d'adapter
la configuration des VM en conséquence.

Merci beaucoup Jean Baptiste, c'est ce que je viens de faire et ça le
fait bien !

Question au passage, comment gérez vous les upgrades de kernel
(2.6.26) du dom0 (lenny)
et de tous les domU (lenny et squeeze) lorsqu'on a la possibilité de
migrer les machines
virtuelles sur un dom0-backup de secours (qui accède au même disque en
LV) ?

Est-ce que cet ordre est ok :
1 . upgrade du dom0-backup et reboot
2 . migration des VMs du dom0 vers dom0-backup
3 . upgrade dom0 et reboot
4 . migration des VMs du dom0-backup vers le dom0

Concernant la mise à jour des noyaux du dom0, pas de secret, il faut
rebooter. La seule exception pourrait être d'utiliser des outils comm e
ksplice, mais je ne suis pas sûr qu'ils supportent un noyau "xenifié " (à
vérifier sur le site).

Pour les domU en revanche, le noyau étant mappé en mémoire, il fa udra
rebooter le domU pour autant que je sache. Je ne suis pas sûr que des
outils comme KSplice gère le cas des domU en paravirtualisation.
La migration peut être tentée après l'upgrade du noyau domU sur l e dom0,
si les bouts de noyau modifiés ne sont pas utilisés par le domU, ma is
j'ai quand même un gros doute sur la faisabilité du truc.
Perso, je n'ai jamais cherché à jouer avec ça: soit la VM est vit ale (et
donc doublée), soit elle ne l'est pas et je reboote.

Pour les domU en revanche, le noyau étant mappé en mémoire, il faudra
rebooter le domU pour autant que je sache. Je ne suis pas sûr que des
outils comme KSplice gère le cas des domU en paravirtualisation.
La migration peut être tentée après l'upgrade du noyau domU sur le dom0,
si les bouts de noyau modifiés ne sont pas utilisés par le domU, mais
j'ai quand même un gros doute sur la faisabilité du truc.
Perso, je n'ai jamais cherché à jouer avec ça: soit la VM est vitale (et
donc doublée), soit elle ne l'est pas et je reboote.

Ok.
Chez moi les domU bootent en quelques secondes (la plupart du temps moins
de 10 secondes). Par contre, mes dom0 (en boot on SAN) mettent au moins
5 minutes à rebooter. C'est pour cette dizaine de minutes nécessaire à
la màj + reboot que j'envisage la procédure évoquée. Je l'ai testée
hier au
soir sur un Dom0 et ça a plutôt bien marché, même si sur certains domU
j'ai eu
le problème du Time went backwards. Je met en place le workaround #3
http://wiki.debian.org/Xen#A.27clocksource.2BAC8-0.3ATimewentbackwards.27
On verra bien lors de la prochaine màj de noyau.