WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-fr

Re: [Xen-fr] mode snapshot pour HVM

Ce que vous demandez est possible mais c'est plus complexe que ça ...

En fait le problème est que quand une VM utilise une image Copy On Write, elle fait une "copie privée" de certaines parties de l'image, à chaque fois qu'elle a besoin d'écrire, mettre en cache ou swapper de la mémoire ...

Pour formuler votre problème: vous avez une image maîtraisse et des image "esclaves" Copy On Write. Chaque VM utiliserait une image "esclave". Vous voulez faire vos mises à jour au niveau de l'image maîtraisse et vous assurer que c'est déployé sur les "esclaves"

Le problème est que si vous mettez à jour l'image maîtraisse directement, les "copies privées" faites par chaque VM ne seront pas mises à jour. Vous aurez pour le système esclave un disque incohérent. Ceci dit, avec de la chance ça peut passer de façon transparente si vous modifiez que des parties de l'image qu'aucune VM "esclave" n'a pas copié en privé.

Votre solution dépend : 1) de votre infrastructure, 2) du temps d'indisponiblité que vous pouvez vous permettre.

Si vous avez un stockage partagé (toutes les VM sur le même serveur physique, stockage SAN ou NFS ...) Les solutions pour ce que vous dites reviennent souvent à avoir dans vos VM "esclaves" deux disques virtuels : un pour le système, l'autre pour les "données". Celui pour le système est un snapshot du maître qui est remis à Zero après chaque mise à jour ...

Sinon, vous pouvez regarder du côté de la technologie linux-vserver si vous serveurs sont en linux, c'est de la virtualisation plus légère et surtout a un support de dossier "partagés" qui peut être utile pour les mises à jour ...

Voila voila,
J'espère que c'est assez claire ...

Slts,

2008/9/29 Dominique Jeannerod <dominique.jeannerod@xxxxxxxxxx>
En fait c'est juste une réflexion pour moi pour l'instant. Le but serait
d'automatiser des mises à jour de machines virtuelles dans un contexte
d'hébergement, et optimiser l'espace disque consommé, sachant qu'on aurait
bien sûr les mêmes versions d'OS, de Apache, etc. Donc réflexion sur la
pertinence de CoW, qui permettrait si j'ai bien compris de mettre à jour
toutes les images CoW en mettant à jour l'original. Mécanisme intéressant,
et aussi quelque peu dangereux (mise à jour "brutale" et simultanée de
toutes les machines virtuelles, manque de souplesse), mais qui permettrai de
bien industrialiser.

Quelqu'un aurait un retour d'expérience, un avis sur ce type de besoin ?

-----Message d'origine-----
[mailto:xen-fr-bounces@xxxxxxxxxxxxxxxxxxx] De la part de Yves-Gaël Chény
Envoyé : lundi 29 septembre 2008 12:03
Objet : Re: [Xen-fr] mode snapshot pour HVM

Bonjour à tous,
Il peut être judicieux pour des choses comme cela d'utiliser unionfs et de
répercuter un diff sur tous les serveurs, non ?

a+
yves
Omar BENHAMID a écrit :
> Cette mise à jour est non seulement "répercutée" mais extrèmement
> dangereuse. En résumé, on fois qu'on a une image en CoW sur un
> fichier, il ne faut apporter aucune modification directement au
> fichier d'origine.
> C'est vrai que c'est un peu déroutant et ça ne rassemble pas aux
> snapshots à la LVM ...
>
> En fonction de votre besoin, vous avez plusieurs approches de solution
> : par exemple utiliser des partitions LVM à la place images qcow qemu,
> ça a quelques limitations (et des drawback de perf !)  mais une fois
> un snapshot réalisé, vous pouvez modifier en toute sécurité la
> partition de base.
>
> Quel était votre besoin : vous voulez que le snapshot ne soit pas
> modifié ou vous voulez effectivement mettre à jour le "snapshot" ?
>
>
> 2008/9/29 Dominique Jeannerod <dominique.jeannerod@xxxxxxxxxxxxx
> <mailto:dominique.jeannerod@xxxxxxxxxxxxx>>
>
>     Bonjour,
>
>     question par rapport à la gestion d'une telle architecture avec
>     CoW : comment gérez vous les mises à jour ?
>     Par exemple, si on utilise CoW pour cloner des images de serveur
>     Web, est-il possible de mettre à jour Apache uniquement sur
>     l'image "source" ?
>     Cette mise à jour est-elle répercutée sur les copies ?
>
>
------------------------------------------------------------------------
>     *De :* xen-fr-bounces@xxxxxxxxxxxxxxxxxxx
>     <mailto:xen-fr-bounces@xxxxxxxxxxxxxxxxxxx>
>     [mailto:xen-fr-bounces@xxxxxxxxxxxxxxxxxxx
>     <mailto:xen-fr-bounces@xxxxxxxxxxxxxxxxxxx>] *De la part de* Omar
>     BENHAMID
>     *Envoyé :* mardi 16 septembre 2008 17:59
>     *À :* xen-fr@xxxxxxxxxxxxxxxxxxx <mailto:xen-fr@xxxxxxxxxxxxxxxxxxx>
>     *Objet :* Re: [Xen-fr] mode snapshot pour HVM
>
>     Bonjour Pierre,
>
>         J'ai du mal à cerner la mise en oeuvre de ce système. Où
>         alors, je crois
>         que je ne comprend pas trop la différence avec ce que je fais.
>
>     En fait la différence avec la copie (cp) est qcow-create crée un
>     image en Copy On Write (COW) ne prend que quelques centièmes de
>     secondes et ne consomme quaisment pas d'espace disque au départ.
>     Il crée en fait un fichier "quasiment" vide.
>     Les blocs ne sont copiés depuis de la partition ou le fichier
>     d'origine vers le l'image COW que quand la VM tente d'écrire. Ne
>     sont alors copiées que les zones qui sont modifiées par la VM. Il
>     s'agit d'une sorte de snapshot (à l'envers).
>
>         pour ne pas avoir à subir le temps de la copie du fichier quand tu
>         relance la machine vierge ?
>
>     Exact, et cela consomme moins d'espace disque
>
>
>
>         > Vous pouvez automatiser tout cela dans un script shell qui
>         le fait avant
>         > de lancer le device model (qemu-dm) et utiliser ce script
>         comme device
>         > model à la place de qemu-dm dans votre configuration de vm
>         xen. Je peux
>         > vous en donner plus de détails si ça vous intéresse.
>
>
>         Je veux bien :-)
>
>     Je tenterai de rédiger un petit mot dessus dès que j'ai quelques
>     minutes pour ça ! Je vous tiens au courant.
>
>     Slts,
>     --
>     Omar
>
>     _______________________________________________
>     Xen-fr mailing list
>     Xen-fr@xxxxxxxxxxxxxxxxxxx <mailto:Xen-fr@xxxxxxxxxxxxxxxxxxx>
>     http://lists.xensource.com/xen-fr
>
>
>
>
> --
> Omar BENHAMID
> Email: o.benhamid@xxxxxxxxx <mailto:o.benhamid@xxxxxxxxx>
> Tel: +33 6 09 31 60 60
> http://www.bewigo.fr
> ----------------------------------------------------------------------
> --
>
> _______________________________________________
> Xen-fr mailing list
> Xen-fr@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-fr

--
------------------------------------
|Yves-Gaël Chény...................|
|email.:.yves@xxxxxxxxxxxxxxxxxxxxx|
|site.:.www.antredugeek.fr.........|
------------------------------------


_______________________________________________
Xen-fr mailing list
Xen-fr@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-fr


_______________________________________________
Xen-fr mailing list
Xen-fr@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-fr



--
Omar BENHAMID
Email: o.benhamid@xxxxxxxxx
Tel: +33 6 09 31 60 60
http://www.bewigo.fr
_______________________________________________
Xen-fr mailing list
Xen-fr@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-fr
<Prev in Thread] Current Thread [Next in Thread>