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 [email protected] En cas de soucis, contactez EN ANGLAIS [email protected] Archive: http://lists.debian.org/[email protected]
