http://www.chicoree.fr/w/Machine_virtuelle_UML_et_fichiers_COWhttp://www.chicoree.fr/w/Machine_virtuelle_UML_et_fichiers_COW#AvantagesLes avantages d'un mécanisme de Copy On Write sont multiples. Le plus évident est d'éviter de dupliquer l'original pour chaque instance. C'est particulièrement judicieux dans le cas d'un système de virtualisation, puisque les fichiers image utilisés par différentes machines virtuelles sont pour l'essentiel identiques. Et d'une machine virtuelle à l'autre, la majorité des fichiers reste inchangée.

]]>http://www.chicoree.fr/w/Machine_virtuelle_UML_et_fichiers_COW#En_pratiquePour associer un fichier COW à une instance de machine virtuelle UML, il suffit de l'indiquer dans le paramètre qui désigne l'image disque à charger. Comme vous le verrez dans l'exemple ci-dessous, le fichier COW est indiqué juste avant le fichier image original, et les deux sont séparés par une virgule:

]]>http://www.chicoree.fr/w/Machine_virtuelle_UML_et_fichiers_COW#AvertissementBon, je n'ai plus grand chose à dire sur ce sujet. Si ce n'est un important avertissement: pour fonctionner normalement, les fichiers COW nécessitent que l'original ne soit plus modifié. Plus jamais. Autrement dit, par exemple, pas question de vouloir faire une mise à jour sur l'original en espérant mettre à jour toutes les machines virtuelles. Ça serait certes pratique. Mais ça ne marcherait pas. La seule solution ici serait de mettre à jour individuellement chaque machine virtuelle – et donc de faire grossir chaque fichier COW en dupliquant des données – et par là même perdre une partie des bénéfices liés à ce mécanisme...

]]>http://www.chicoree.fr/w/Machine_virtuelle_UML_et_fichiers_COW#ConclusionJe ne vais pas trop m'éterniser: vous l'avez compris, les fichiers COW, c'est vachement bien. Donc, inutile de s'en priver, surtout si vous souhaitez faire coexister plusieurs instances de machines virtuelles basées sur la même image disque.

]]>http://www.chicoree.fr/w/Machine_virtuelle_UML_et_fichiers_COW#R.C3.A9f.C3.A9rence