snapshot : comparaison Wmware <-> HyperV

Bonjour,
je viens d'avoir un problème avec une VM hébergeant un ERP (base de données)
un snapshot a été réalisé avant une opération sur l'ERP.
mais lors des opérations de mise à jour de la base de données sur l'ERP la VM a planté.
Après analyse le disque de l'hôte s'est trouvé saturé par le fichier de différence : image de la VM et fichier différence du snapshot sur le même disque physique de l'hôte.

Je ne suis pas un spécialiste infra et je délègue souvent cette partie.
j'ai déjà réalisé plusieurs fois des opérations sur des ERP hébergés par des VM Vmware
Je n'ai JAMAIS eu de soucis avec les snapshot et là avec un hyper V c'est la catastrophe.

Questions :
-Pouvez vous me décrire la différence de fonctionnement s'il en a sur les snapshot vmware et hyperV ?
-je suppose que le cout de Vmware induit le choix par defaut d'HyperV pour certaines PME ?


Merci

Quand tu fais un snapshot, chaque bloc modifié du fichier de base est enregistré dans le fichier de snapshot, qui correspond donc au delta des modifs effectués par rapport au fichier de base. Ce fichier va donc grossir au fur et à mesure des modifications faites. C'est le même principe sous VMWare ou Hyper-V. C'est un problème classique, car en gros tu fais du surbooking d’espace disque.

Citation:

---

je suppose que le cout de Vmware induit le choix par defaut d'HyperV pour certaines PME ?

---

Pas forcément. Tu as une version gratuite de VMWare : ESXi. Je ne connais pas bien Hyper-V, mais si tu es en environnement complètement Windows, tu auras peut-être plus d'outils (comme la migration à chaud) qu'avec la version gratuite de VMWare.

Le paramétrage est il plus aisé sur Wmare (le fichier delta peut il être mis n'importe où?) ou faut également laisser le fichier delta à côté du fichier image de la VM ?
Et enfin ci c'est un problème classique pourquoi le vendeur du serveur ne nous a pas alerté en préconisant un disque plus gros ou en tout cas en refusant de faire un snapshoot qui allait forcément planter ?

Citation:

---

Le paramétrage est il plus aisé sur Wmare (le fichier delta peut il être mis n'importe où?)

---

Il est d'usage de laisser le fichier Delta au même endroit que le fichier de base, c'est même le comportement par défaut, mais il est tou à fait possible de le mettre ailleurs. De mémoire sur VMWARE, il n'y a pas d'option depuis l'interface graphique, il faut le faire en ligne de commande, sur Hyper-V je ne sais pas.

Citation:

---

Et enfin ci c'est un problème classique pourquoi le vendeur du serveur ne nous a pas alerté en préconisant un disque plus gros ou en tout cas en refusant de faire un snapshoot qui allait forcément planter ?

---

Le vendeur de quoi ? de ton serveur ? de ton ERP ? C'est du système, pas de l'applicatif, ni un problème matériel. Quand tu fais un snapshot tu es sensé savoir ce que tu fais, et savoir que ça bouffe de la place. Et un snapshot n'a pas lieu de perdurer. Dans ton cas l’intérêt était à mon avis de pouvoir revenir en arrière rapidement en cas de prob avec une manip, pour ensuite supprimer le snapshot ce qui intègre les données du delta dans le fichier de base et valide donc toute les modifs stockés dans le fichier delta dans le fichier prinicpal, ou de revenir à l'état avant snapshot, ce qui supprime le fichier delta et et donc fait perdre les modifs. Pour intégrer un snapshot à son fichier de base, il faut encore une fois de la place supplémentaire.

Calculer la taille nécessaire à un snapshot peut être compliqué. Il faut avoir une idée des modifs qui vont être effectuées, et donc compter large.

et un snasphot n'est pas une sauvegarde.

Citation:

---

Le vendeur de quoi ? de ton serveur ?

---

Pas le vendeur mais le prestataire responsable de le maintenance de l'infrastructure

Citation:

---

Dans ton cas l’intérêt était à mon avis de pouvoir revenir en arrière rapidement en cas de prob avec une manip

---

Oui l'opération consistait a changer une partie de la structure (ajout de champs, de nouvelles tables) d'une base de données => nouvelle version de l'ERP

L'idée étant de pouvoir revenir à la version précédente en cas de problème de démarrage.
Le prestataire ayant privilégié le snapshoot pour la rapidité de reprise le lundi matin alors qu'une copie de VM nécessitait une intervention le dimanche soir.

Citation:

---

donc compter large.

---

J'ai contacté plusieurs personnes de mon reseau sur ce point j'ai constaté que la place libre sur l'hôte était souvent plus importante que les 10% sur mon infra.
J'ai même eu une réponse avec 50% de libre : disque sur l'hôte 7o To et 3 To pour le fichier de la VM. Mais c'est dans un gros SAN, le client ayant des moyens :)
et j'ai eu aussi un passage de Vmware a Hyper V pour soit disant un problème avec Vmware pour gérer les gros disques.

En tout cas merci pour toutes ces infos

Citation:

---

Le prestataire ayant privilégié le snapshoot pour la rapidité de reprise le lundi matin alors qu'une copie de VM nécessitait une intervention le dimanche soir.

---

c'est le but du truc mais là du coup comme ça a foiré, nécessité de remonter un backup.

Citation:

---

J'ai contacté plusieurs personnes de mon reseau sur ce point j'ai constaté que la place libre sur l'hôte était souvent plus importante que les 10% sur mon infra.

---

Oui, 10% ça me parait juste pour faire un snapshot, d'autant plusavec modif d'une base de données. Après si la base fait 1 Go ..

Citation:

---

et j'ai eu aussi un passage de Vmware a Hyper V pour soit disant un problème avec Vmware pour gérer les gros disques.

---

A mon avis, c'est surtout une question de version de VSphere et de VMFS. Mais j'en fais pas assez pour pouvoir l'affirmer.