Xen sous lenny et noyau 2.6.32 de squeeze

Le
Guy Roussin
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-amd=
64
-rw-r--r-- 1 root root 1693529 déc 1 17:24 System.map-2.6.32-5-xen-amd=
64
-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.

--
Guy

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/4CF67CFA.50502@teledetection.fr
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Monsieur Mastock
Le #22870701
Le mercredi 01 décembre 2010 à 17:51 +0100, Guy Roussin a écrit :
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,

un truc du genre GRUB_DISABLE_OS_PROBER=true dans /etc/default/grub?


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Jean Baptiste FAVRE
Le #22871451
Il suffit de le mettre ailleurs, par exemple dans /boot/xen et d'adapter
la configuration des VM en conséquence.

Cordialement,
JB

Le 01/12/2010 17:51, Guy Roussin a écrit :
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.




--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Guy Roussin
Le #22872311
Le 01/12/2010 20:47, Jean Baptiste FAVRE a écrit :
Il suffit de le mettre ailleurs, par exemple dans /boot/xen et d'adapte r
la configuration des VM en conséquence.


Merci beaucoup Jean Baptiste, c'est ce que je viens de faire et ça le f ait 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 mi grer les machines
virtuelles sur un dom0-backup de secours (qui accède au même disque e n 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

Merci.

Guy

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Jean Baptiste Favre
Le #22872841
Le 01/12/2010 23:33, Guy Roussin a écrit :
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


Bonjour,
Concernant la mise à jour des noyaux du dom0, pas de secret, il faut
rebooter. La seule exception pourrait être d'utiliser des outils comme
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 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.

Cordialement,
JB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Guy Roussin
Le #22875271
Bonjour,
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).


Ok

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.


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.

Merci encore.

--
Guy Roussin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Jean Baptiste Favre
Le #22877131
Bonjour,
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.


J'ai posé la question à la liste xen-users sur ce sujet. La réponse qui
m'a été donnée est la suivante:
Le noyau étant totalement mappé en mémoire, la migration ne devrait pas
poser de problème. En revanche, il faudra toujours rebooter pour que la
mise à jour soit prise en compte.

Du coup, ta solution devrait être viable :)

Cordialement,
JB

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Publicité
Poster une réponse
Anonyme