Bonjour,
 
Suite a la sauvegarde via veeam des vms, on a un problème récurrent et cette fois ci je n'arrive pas a m'en sortir.
 
On utilise ESX 4.1
On a une vm sur un datastore de 840Go. La vm est en thinprovisionning 1.3To. (il n'y a qu'une vm sur ce datastore)
 
La vm fait environs 600Go. Le problème se produit car en même temps que la sauvegarde, il y a un transfert de 100Go sur cette vm qui est la restauration d'une BDD.
 
Le probleme est donc :
 
La sauvegarde de la vm ne se fait pas car le datastore se retrouve plein.
Actuellement la vm refuse donc de démarrer car il n'y a plus d'espace.
J'ai un fichier XXX_1-000001.vmdk et XXX_1-000002 qui font 200Go environs a eux seul et je n'arrive pas a consolider le snapshot.  
Sur l'interface graphique, les options sont grisés.
 
J'ai essayer en power cli grace a  
vim-cmd vmsvc/getallvms
vim-cmd vmsvc/snapshot.get 80 (ou 80 est ma vm)
vim-cmd vmsvc/snapshot.removeall 80
ca me dit Remove all Snapshot mais quand je reliste, ils sont toujours la :
 
 
drwxr-xr-x    1 root     root               5600 Aug 17 07:11 .
drwxr-xr-t    1 root     root               1260 Aug  6 10:52 ..
-rw-------    1 root     root             126976 Aug 17 06:31 XXX-000001-delta.vmdk
-rw-------    1 root     root            3932672 Aug  2 02:14 XXX-000002-ctk.vmdk
-rw-------    1 root     root           16904192 Aug  6 10:42 XXX-000002-delta.vmdk
-rw-------    1 root     root                425 Aug  2 02:14 XXX-000002.vmdk
-rw-------    1 root     root              30074 Aug 17 06:31 XXX-Snapshot67.vmsn
-rw-------    1 root     root              30026 Aug 17 06:39 XXX-Snapshot68.vmsn
-rw-------    1 root     root              30026 Aug 17 06:43 XXX-Snapshot69.vmsn
-rw-------    1 root     root              30074 Aug 17 06:48 XXX-Snapshot70.vmsn
-rw-r--r--    1 root     root                 13 Aug 17 06:31 XXX-aux.xml
-rw-------    1 root     root            3932672 Aug  2 02:16 XXX-ctk.vmdk
-rw-------    1 root     root        68719476736 Aug 17 07:11 XXX-ef6718b1.vswp
-rw-------    1 root     root        64424509440 Aug  2 02:16 XXX-flat.vmdk
-rw-------    1 root     root               8684 Jul 16 13:01 XXX.nvram
-rw-------    1 root     root                589 Aug 22  2013 XXX.vmdk
-rw-r--r--    1 root     root                 78 Jul  6 07:32 XXX.vmsd
-rwxr-xr-x    1 root     root               3244 Aug 17 07:15 XXX.vmx
-rw-r--r--    1 root     root               1605 Aug 17 07:15 XXX.vmxf
-rw-------    1 root     root            8192512 Aug  1 23:32 XXX_1-000001-ctk.vmdk
-rw-------    1 root     root       151717392384 Aug  2 02:14 XXX_1-000001-delta.vmdk
-rw-------    1 root     root                409 Aug  1 23:32 XXX_1-000001.vmdk
-rw-------    1 root     root            8192512 Aug 17 06:48 XXX_1-000002-ctk.vmdk
-rw-------    1 root     root        76840677376 Aug  6 10:42 XXX_1-000002-delta.vmdk
-rw-------    1 root     root                439 Aug  2 02:14 XXX_1-000002.vmdk
-rw-------    1 root     root            8192512 Aug  2 03:13 XXX_1-ctk.vmdk
-rw-------    1 root     root       536870912000 Aug  2 03:13 XXX_1-flat.vmdk
-rw-------    1 root     root                595 Apr 22 05:54 XXX_1.vmdk
-rw-r--r--    1 root     root             152370 Aug 17 06:00 vmware-22.log
-rw-r--r--    1 root     root              70658 Aug 17 06:05 vmware-23.log
-rw-r--r--    1 root     root              51355 Aug 17 06:36 vmware-24.log
-rw-r--r--    1 root     root              32305 Aug 17 06:37 vmware-25.log
-rw-r--r--    1 root     root              32055 Aug 17 06:39 vmware-26.log
-rw-r--r--    1 root     root              71006 Aug 17 06:49 vmware-27.log
-rw-r--r--    1 root     root             141786 Aug 17 07:15 vmware.log
-rw-r--r--    1 root     root            5734240 Aug 17 07:10 vmware64-core0.gz
-rw-r--r--    1 root     root            5289076 Aug 17 07:10 vmware64-core1.gz
-rw-r--r--    1 root     root            5290225 Aug 17 07:10 vmware64-core2.gz
-rw-r--r--    1 root     root            5293382 Aug 17 07:10 vmware64-core3.gz
-rw-r--r--    1 root     root            5111808 Aug 17 07:11 vmware64-core4.gz
 
Je ne sais pas quoi faire du tout la....
 
Et autour de moi, je trouve pas de serveur avec un espace disque de 900Go pouvant faire office d'espace NFS pour faire du svmotion et que la sauvegarde se termine.
 
 

Il va te falloir trouver de l'espace disque pour supprimer les snapshots, tu as peut-être des nas de disponibles ?

j'ai un nas mais pas assez d'espace...

Je suis en train d'eparpiller les vms que j'ai sur un datastore sur d'autre pour pouvoir y placer celle ci.
Une fois que je l'ai migrer sur ce datastore, faut que je fasse quoi ?
Parce qu'il n'y aura quand meme pas la place de faire un snapshot je pense.... (puisque actuellement 840Go et je déplace sur un DS de 1To) je peux pas plus.

J'ai aussi un serveur 2008 avec 1.2 To d'espace disque dispo mais je peux pas installer le service NFS j'ai des erreurs... bref la classe et cette vm c'est notre intranet qu'il y a dedans + de quoi faire travailler l'equipe de dev :s
et bien evidement j'ai appris qu'on avait plus de support technique vmware ni veeam la grande classe ^^

C'est veeam 5 au fait

Quand tu auras l'espace, tu pourras supprimer les snapshots.
Par contre cela peut-être long.
Ce serait bien tu passes Veeam vers la V8.

Be je veux bien les supprimer mais comment ? Puisque ils n apparaissent pas dans la gui.
J ai lu que le mieux était de refaire un snapshot puis supprimer tout sauf que le snapshot pourra pas se faire avec seulement un peu plus de 100go de libre
Ça apporte quoi la 8 c était prévu dans un projet la migration mais repousse et je doute que la 8 soit possible avec la licence 6...

Bref il y a des choix que je comprends pas trop parce que la on a un gros pépin on est maron puisque de toute l équipe info c est moi le plus apte à gerer les soucis VMware et je suis très loin d être expert.

diminue ta rétention directement dans le job
au prochain job, veeam supprimera proprement les snapshots et tu regagneras de l'espace disque

je comprends pas tres bien.
 
La retention, c'est bien le nombre de fichier backup conservés ? Parce que je suis a 5 actuellement.
Et le probleme c'est que la veeam ne peut rien faire car il n'a plus du tout d'espace.
 
J'ai essayer de faire du svmotion mais ca plante pendant (perte de connexion de l'esx on dirait et vu que c'est un datastore local...).
 
J'ai tenté un clone la.
Bref, c'est vraiment la mouise et le plus urgent c'est qu'on puisse démarrer cette vm, le problème de snapshot pourra etre regle dans la semaine.

Alors le clone s'est bien passé ce matin quand je suis arrivé il avait terminé.
Il a consolider les snapshot on dirait en faisant un clone sur un autre datastore car je n'ai plus de snapshot et j'ai bien la vm avec les dernieres modifications effectué.
C'est bien un résultat normal lorsqu'on clone la consolidation ?
 
En tous cas, ca a l'air bon pour moi de ce cote la.
 
Par contre, il faut que je trouve comment supprimer les quelques residus que j'ai qui traine car quand je vais sur la banque de donnée et que j'essaye de supprimer certains fichier je ne peux pas j'ai un message d'erreur.

Oui un clone créer une vm sans snapshot (s'il y en a sur la source, ils sont fusionné sur la destination)
 
pour le svmotion : il vérifie avant l’opération si c'est possible donc si ca plante c'est autre chose (fichiers corrompu ?)
 
-----
 
Après j'ai envie de dire que tu joues avec le feu :
- esx 4.1 n'est plus maintenu de puis longtemps
- thin provisionning c'est le mal
- pas assez d'espace sur les datastore = mauvaise estimation de l'infra
- dump/traitement  de ta bdd en même temps que les backups  
 
le dernier point peut être modifié facilement. pour le reste faut revoir asap l'infra. En faisant appel à un professionnel de la virtu (architecte..)
 
voit le bon coté des choses : ces galères débloqueront peut être les budgets pour évoluer
 
 
Bonne chance +
 

Je te remercie grandement pour ton message.

De mon côté ça fait quelque temps que je répète qu il faut investir un peu dans du stockage sachant que cette vm on voit bien qu elle a un rôle important dans l infra et qu elle est sur un ds local .... No coment ! Peut être que ce problème va permettre de se pencher la dessus. Pour les autres datastores on est à 58% d utilisation max ce qui je pense est normal.

L esx doit être migre d ici la fin de l année en 5.5 de ce que j ai compris
Thinprovisionning à été mis en place lors de la création de la vm donc il doit y avoir au moins 5 ans je suis la depuis 6 mois sinon ouais en prof tout en thick pour être tranquille normalement le semblait bien
Pour les backup en même temps que le traitement bdd la c est dur de faire différemment sans impacter la prof... Il y a un traitement tous les jours donc même samedi et dimanche à 1 h du mat et 5h du mat sur la bdd qui prennent une heure chacun et la vm à besoin de pas mal de temps pour être sauvegardé. Ils sont en train de changer de méthode pour ne plus avoir à restaurer la base.
De ce que j ai compris car j ai pas trop de notion bdd actuellement ils ont une base de test à j-1 c est une des opérations et l autre opération doit être un commit des opérations de la journée précédente ? Puisque aucun report n est dispo pendant cette période.
La migration prévoit d avoir la base de test autant à jour que la base de prod. J entends des mots comme fonctionnel et datawerehouse si jamais c est peut être en lien.

Un datastore local à l'hôte physique n'est pas un critère d'évaluation pour juger de la stabilité ou non.
 
C'est un cas de figure très nettement préférable à une infra avec un SAN/NAS aux perfs réduites, non monitoré, et un réseau local non redondé.
Tout cela créant nettement plus de SPOF que l'infra avec le datastore local.

Sauf que si l hote tombe ? À be mince plus de vm .... Pas de ft possible car elle a 8 vcpu
Après la partie monitoring m intéresse justement .
C est quoi pour toi ? Se connecter au vcenter voir que tout va bien ? Faire de la supervision ? De quoi ?
Côté réseau je crois que c est bien redondé au niveau serveur par contre niveau utilisateur un seul switcj final donc si il tombe un service est impacte mais ça c est pas envisageable différemment pour l instant .
La preuve on a 3 switcj dont les ventilos sont hs plus de garantie et on attend que ça claque pour les remplacer avec le feu au fesse ce jour la

 
Le FT a évolué avec vSphere 6 et tu peux désormais en faire entre deux hôtes physiques avec datastore locaux.
Quoi qu'il en soit, si ta VM dépasse les maximas pour du FT, que tu sois en SAN/NAS ou non, cela ne change rien.
A partir de là, il faut partir sur d'autres solutions comme du cluster applicatif, du Double Take, etc.
 
Mais si tu veux du FT avec ce que cela implique en terme de coût, alors ton besoin doit être suffisant pour du SAN redondé avec réseau dédié redondé.
 
Maintenant, sur des infras plus légères, on se contente de réplications asynchrones ou de HA. Voir de repartir sur la sauvegarde.
Dans ce cas là, à mon sens, on est mieux protégé avec deux hôtes physiques et datastores locaux qu'avec 2 hôtes physiques et un SAN.
En plus, on aura surement de meilleures perfs (pour peu que ce soit utile) que sur une baie SAN bas de gamme connectée en ETHERNET.

Hein ? je suis pas du tout d'accord avec toi la non...
Oui je sais que tu peux faire du FT local c'est la raison pour laquelle j'ai précisé 8 vcpu qui eux font qu'on peut pas faire de FT.
 
De plus, on passera pas en V6 c'est pas prévu.
 
Enfin, bien sur que si ca change que je sois en local ou san/nas. Si je suis en san/nas si mon hote tombe, elle redémarre sur un autre hote... Fonctionnalité HA fin je pense que j'ai du mal comprendre la remarque tellement la réponse me semble évidente.
 
Cluster applicatif je suis tout a fait d'accord, et pour faire simple, c'est inexistant à l'heure actuelle, et etant donnée que c'est un serveur ou il y a des BDD, et que de ce que j'ai compris, personne a les compétences de le mettre en cluster.... bé l'implementation est pas du tout prévu. De plus, ca correspondrait quand meme pas au problème d'origine qui est le manque d'espace disque à la base.
 
Ce que je comprends pas c'est qu'on a des vm comme celle de supervision ou celle de sccm qui ne sont pas critiques car peu utilisées, et qu'elles auraient leur place sur un DS local.
 
le FT coute ? j'avais pas cru comprendre que ca coutait, c'est juste une vm en double quelque part sur un autre hote. Nous n'avons qu'une seule baie donc pas de HA a ce niveau la
 
on est pas sur une grande infra.... si on avait 8 esx sur un meme site je pense que ce serait plus interessant de ce cote la ^^
nous on a pas de réplication aujourd'hui si un fichier vmdk est corrompu, on recupere la sauvegarde du mois d'avant pour restaurer la vm et si jamais les données que contiennent le serveur sont sauvegardees on les restaure.
Nous avons un N3000 aujourd'hui, je sais pas si ca te parle ? j'ai aucune notion de stockage donc moi je sais pas ce que ca vaut xD
je sais qu'on a 3 LUN dessus qui correspondent a 3 datastores.
Et dans notre cas, c'est juste pas possible de penser mettre 10 vm sur un datastore local par exemple... Si ton hote a la carte mere qui crache tu payes les gens a rien faire le temps de restaurer ce que tu peux sur l'autre hote  ? fin c'est impensable pour moi en 2015 d'avoir un fonctionnement ocmme ca quand tu dépasse 10 vm grand mini...

 
Oui le FT coute ... une licence
 
Et c'est pas parce que tu as UN hôte physique avec datastore local que tu ne peux pas en avoir un DEUXIEME, voir TROIS, enfin ainsi de suite.
Et faire de la réplication synchrone ou asynchrone entre tous ces beaux serveurs.
 
C'est toujours mieux qu'une infra avec un SAN naze qui peut péter aussi (et oui) et délivre des perfs merdiques (j'en croise régulièrement).
 
Bien sûr le mieux est d'avoir le super SAN en redondé avec le réseau FC redondé aussi.
mais c'est comme le FT : ca coûte !

Attends je comprends pas le ft coûte une licence ? Une licence de quoi ?
En plus de la licence VMware entreprise plus par exemple faut que tu payés une licence par vm ou tu fais du ft ?
Parce que je suppose que vu que c est un système actif passif au niveau Microsoft une licence pour les deux suffit.
 
Oui d accord pour la réplication OK juste je parlais par rapport à mon cas depuis tout à l heure et donc avec deux hote ça veut dire qu il nous faudrait 4to par hote environs.
Donc quand tu fais de la repli syncrone ça veut dire que si un hote pète tu démarré à la main toutes les autres vm je suppose.
Dans notre cas c est vrai que si x est la baie qui pète on se retrouve foutu.
Obligé de tout restaurer au mois prexedzbt.
 
Il existe des solutions mais ça suppose de pas utiliser notre version de veeam parce qu aujourd'hui il nous faut 24h pour sauvegarder toute l infra sur la dernière version c est peut être plus rapide

La licence FT est hors de prix pour une PME, c'est vraiment pour les grands groupes.
Sans compter le matériel qui va avec.
Je ne connais pas les licences en v6 mais en V5, il te fallait une version entreprise ou entreprise plus.
 
La réplication de veeam est une bonne solution, elle sera plus économique.
peut-être que ton serveur de sauvegarde ne soit pas assez puissant.
Tu as pu voir pour mettre Veeam à jour ?

Oui be chez nous on a une entreprise de mémoire donc pas besoin de licence en plus de ça si ?
Voilà pourquoi je comprenais pas . je pensais que il fallait une licence pour chaque vm sur laquelle tu voulais faire du ft avec ce que disais shongall

Malheureusement tout ce qui est modification d infra comme ça c est sous traité et je crois que x est pas à l ordre du jour pour veeam alors que les esx oui

A mon avis tu as une licence essentials ou essentials plus.

En effet tu as raison
Vcenter 4 essentiel et esx 4 essentiel plus.
À quoi ça sert d avoir deux version differentre entre l hote et le vcenter ?
C est la vcenter qui prime je suppode

Ca change rien, c'est la licence pour l'esx qui est plus importante car elle te permet d'utiliser le HA et le vmotion.

Maintenant sur vSphere 6, tu as FT jusqu'à 2vCPU sur la version standard (et 4vCPU sur l'entreprise plus).
Avant il fallait l'entreprise pour FT.

Mais même en standard, ca coûte cher de licencier tout ses cores physiques.
Du coup, sauf à vouloir d'autres fonctions que propose cette version, oui FT ca coûte cher.

Sans compter que pour du Windows, il faut licencier toutes les VMs, y compris les réplicas.
Mais bon ça c'est pareil pour toutes les réplications.

Aussi, en PME, on voit beaucoup plus d’éditions Essentials Plus.

FT, pour moi, c'est réservé à des grosses boites ou des PME avec une vrai criticité.
Car en plus de la licence, il faut l'infra pour :
- soit une infra SAN totalement redondée (ca ne sert à rien de faire du FT si le stockage est un SPOF).
- soit depuis la V6 deux hôtes physiques mais avec des gros prérequis (comme un lien 10Gb).

Merci shon pour toutes ces explications .
 
Nous n avons qu un cpu physique par hote donc ça aurait été envisageable mais le responsable veut migrer en 5.5 car pas assez de recul sur la 6 pour me moment.
Concernant windows aucun problème de licence on a 2 datacenter  
La aujourd'hui notre point critique c est le stockage ça c est sur ...
Une seule baie et aucune réplication des vm en stockage local !
Niveau réseau on a pas de multipathing je crois donc si un port ethernet pète plus de liaison avec la baie ...
Je pense que ce sont deux gros problème quand même ..
 
 
C est possible de profiter de ce topic pour poser quelque question sur VMware ?