Ok, merci pour la clarification, le problème est votre compréhension de ce qu'est un snapshot - ce n'est pas ce que vous pensez. Disons que vous avez un disque sans snapshots, quand vous créez un snapshot tout ce qui se passe est que ce nouveau fichier est créé par l'hyperviseur avec JUSTE les changements au disque de base qui ont été faits depuis le snapshot, l'hyperviseur envoie alors seulement au système d'exploitation invité les données correctes du disque de base (si cette partie du disque n'a pas été changée depuis le snapshot) ou les données du fichier snapshot (seulement si cette partie des données a été changée depuis que le snapshot a été créé). Ainsi, l'envoi du fichier d'instantané n'inclurait que les données modifiées et serait peu ou pas utile en soi - est-ce correct ?
Cela dit, ce que vous essayez de faire est très simple : il suffit d'arrêter votre VM et de sélectionner "Save to OVF" dans le menu File, ce qui vous permettra d'enregistrer la VM dans un format indépendant de l'hyperviseur appelé OVF, que vous pourrez ensuite transférer à qui vous voulez. Cette personne pourra ensuite importer ce fichier OVF dans l'hyperviseur dont elle dispose (il ne s'agit pas nécessairement de VMWare Workstation). Ce fichier contiendra la VM sauvegardée au moment de l'arrêt. Si nécessaire, vous pourrez alors supprimer les snapshots sur votre propre machine et poursuivre votre travail.
Voici un diagramme (assez pauvre) que je viens de créer ;
Dans cet exemple, nous n'avons que quatre "blocs" de données, numérotés de 1 à 4. Comme vous pouvez le constater, chaque "bloc" contient un élément de données (un seul chiffre dans ce cas). Nous créons ensuite l'instantané numéro 1 et changeons les données dans les "blocs" 1 et 3 (en 101 et 75 dans ce cas). À ce stade, si le système d'exploitation lit le "bloc" 1, la réponse de l'hyperviseur est 101, et non 100, et 75 et non 50 pour le "bloc" 3, mais la réponse pour les "blocs" 2 et 4 reste 200 et 25. Si nous supprimons le snapshot 1, tout revient aux valeurs en jaune. Si nous créons un second instantané et écrivons le nombre 102 dans le "bloc 1", alors ce "bloc" et UNIQUEMENT ce bloc est mis à jour dans le second fichier instantané, si nous lisons le "bloc" 3, cela renvoie au premier fichier instantané pour obtenir ces données et au fichier de base si nous voulions lire les "blocs" 2 et 4. Si nous sauvegardons/exportons la VM au point "Snap 2", cela créera un seul fichier avec les blocs écrits à ce point (c'est-à-dire 102, 200, 75, 25).
Il est évident que dans toute situation où la machine virtuelle effectue des instantanés, il peut y avoir un impact sur les performances des entrées-sorties du disque, car il peut y avoir plusieurs lectures et écritures sur le disque pour réaliser ce mécanisme d'instantané. En fait, plus il y a de snapshots et plus il y a de changements par snapshot, plus la baisse de performance peut être importante. Cela dit, il arrive un moment où, si une très grande partie du disque a été écrite dans le cadre de l'instantané actuel, la dégradation des performances s'atténue car presque toutes les entrées/sorties sont destinées au fichier d'instantané, mais cela doit être évité si possible. En fait, les snapshots VM sont une mauvaise idée à long terme car le temps nécessaire à leur suppression (qui ne fait que réécrire les changements dans le fichier de base ou dans un fichier snap intermédiaire) s'allonge au fur et à mesure que des changements sont intervenus depuis le snap. En règle générale, je n'aime pas que les snap soient conservés plus de 24/48 heures, mais dans un environnement de bureau, ce délai peut être un peu plus long.
D'ailleurs, ce mécanisme est à peu près le mode de fonctionnement de toutes les méthodes d'instantanés (il peut être un peu différent dans le système de fichiers WAFL de NetApp et le ZFS, mais c'est une bonne compréhension de base au moins) dans tous les hyperviseurs.
Est-ce que c'est clair ? Si ce n'est pas le cas, jetez un coup d'œil aux manuels, ils sont assez clairs.