Erreur 156 NetBackup/Vmware – ALL_LOCAL_DRIVES is not frozen – Failed to quiesce the virtual machine

Hello tout le monde !

Petit tuto pour réparer une erreur que vous risquez peut-être de rencontrer si vous avez des serveurs windows avec plusieurs disques attachés sous Vmware.

En effet, si comme moi vous avez 9 disques (.vmdk) attachés à votre serveur de fichiers, vous risquez de rencontrer une erreur lorsqu’un snapshot via une application externe (dans mon cas NetBackup) est demandé avec le paramètre “Virtual Machine Quiesce”. Ce paramètre permet de mettre au repos le système de fichiers et ainsi obtenir une sauvegarde cohérente avec la fiabilité de sauvegarder les fichiers ouverts.

Sur votre vsphere client vous observez les messages suivants :

erreur_vmware_1

Une erreur est survenue lors du repos de la machine virtuelle. Voir le journal es événements de la machine virtuelle pour plus de détails.

erreur_vmware_2

XXX com.symantec.netbackup.create.snapshot.failure.category not found XXX

Sur NetBackup vous risquez d’obtenir les messages suivants :

Critical	2289	Backup	from client SRV_FILES.domain.lan: FTL - VMware_freeze: VIXAPI freeze (VMware snapshot) failed with -1: Unrecognized error
Critical	2289	Backup	from client SRV_FILES.domain.lan: FTL - VMware error received: Une erreur est survenue lors du repos de la machine virtuelle. Voir le journal des événements de la machine virtuelle pour plus de détails.
Critical	2289	Backup	from client SRV_FILES.domain.lan: FTL - vfm_freeze: method: VMware_v2, type: FIM, function: VMware_v2_freeze
Critical	2289	Backup	from client SRV_FILES.domain.lan: FTL -
Critical	2289	Backup	from client SRV_FILES.domain.lan: FTL - vfm_freeze: method: VMware_v2, type: FIM, function: VMware_v2_freeze
Critical	2289	Backup	from client SRV_FILES.domain.lan: FTL -
Critical	2289	Backup	from client SRV_FILES.domain.lan: FTL - snapshot processing failed, status 156
Critical	2289	Backup	from client SRV_FILES.domain.lan: FTL - snapshot creation failed, status 156
Warning	        2289	Backup	from client SRV_FILES.domain.lan: WRN - ALL_LOCAL_DRIVES is not frozen
Critical	2289	General	from client SRV_FILES.domain.lan: cannot open C:\Program Files\Veritas\NetBackup\online_util\fi_cntl\bpfis.fim.SRV_FILES.domain.lan_1429706089.1.0
Info	        2289	Backup Status	snapshot error encountered
Error	        2289	Backup	backup of client SRV_FILES.domain.lan exited with status 156 (snapshot error encountered)

Vous obtenez donc un code erreur 156 qui est d’ailleurs referencé chez Symantec ici : https://support.symantec.com/en_US/article.TECH160314.html

Leur solution n’étant pas suffisante et pas du tout aboutissante, on doit analyser les logs !

Pour cela, connectez-vous en ssh sur votre esx. Ensuite déplacez vous vers le dossier de votre VM.

cd /vmfs/volumes/Datastore1/SRV_FILES/

Ensuite consultez votre fichier vmware.log avec un simple :

cat vmware.log

Le résultat devrait être quelque chose comme ça :

2015-04-23T06:41:23.026Z| vmx| I120: DISKLIB-VMFS  : "/vmfs/volumes/551e5863-50739278-6ca8-0017a4770836/SRV_FILES/SRV_FILES_8-flat.vmdk" : open successful (65557) size = 536870912000, hd = 0. Type 3
2015-04-23T06:41:23.026Z| vmx| I120: DISKLIB-VMFS  : "/vmfs/volumes/551e5863-50739278-6ca8-0017a4770836/SRV_FILES/SRV_FILES_8-flat.vmdk" : closed.
2015-04-23T06:41:23.027Z| vmx| I120: ToolsBackup: not enough empty nodes (needed 9, found 6)
2015-04-23T06:41:23.027Z| vmx| I120: ToolsBackup: changing quiesce state: IDLE -> DONE
2015-04-23T06:41:23.027Z| vmx| I120: SnapshotVMXTakeSnapshotComplete: done with snapshot 'NBU_SNAPSHOT SRV_BACKUP.domain.lan 1429771067': 0
2015-04-23T06:41:23.027Z| vmx| I120: SnapshotVMXTakeSnapshotComplete: Snapshot 0 failed: Failed to quiesce the virtual machine (40).

Si vous voulez l’identifier tout de suite, vous pouvez trier votre affichage:

cat vmware.log | grep ToolsBackup

Comme vous pouvez le voir ci-dessus en rouge, vmware nous dis qu’il n’y a pas assez de noeuds. Il a en besoin de 9 et il en trouve que 6 de libre.

Qu’est-ce que ça veut dire ??

Pour comprendre, il faut connaitre un peu le concept des controleurs SCSI.

Le standard SCSI (Small Computer System Interface) est une interface permettant la connexion de plusieurs périphériques de types différents sur un ordinateur par l’intermédiaire d’une carte, appelée adaptateur SCSI ou contrôleur SCSI (connecté généralement par l’intermédiaire d’un connecteur PCI).

Le nombre de périphériques pouvant être branchés dépend de la largeur du bus SCSI. En effet, avec un bus 8 bits il est possible de connecter 8 unités physiques, contre 16 pour un bus 16 bits. Le contrôleur SCSI représentant une unité physique à part entière, le bus peut donc accepter 7 (8 – 1) ou 15 (16 – 1) périphériques.

source : http://www.commentcamarche.net/contents/767-scsi

En effet, nous sommes limités à 15 périphériques par controleur SCSI (virtuel ou physique). Sachant que j’avais attaché 9 disques sur le même controleur et que vmware a besoin d’autants de noeuds disponibles sur le même controleur pour faire un snapshot avec le système de fichiers au repos (‘quiesced snapshot’), ceci échoue !

La solution est d’ailleurs expliquée par vmware ici http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2015181

Il faut donc détacher au moins 2 disques(dans mon cas) du controleur numéro 0 et les attacher sur le controleur suivant.

/!\ Attention /!\ J’ai également trouvé une autre source de problème concernant le même message d’erreur.

Ceci peut venir d’un backup qui a échoué et qui a pas nettoyé correctement la VM (snapshots et fichiers).

Si votre backup ne tourne plus et que vous avez toujours un snapshot identifié par NetBackup, supprimez-le !

Ensuite rendez vous dans le dossier de votre VM et regardez si vous avez des fichiers ….-ctk.vmdk. Ces fichiers sont créés pour l’option « Enable block-level incremental backup » de NetBackup.

NetBackup s’appuye donc sur vmware et le CBT qui permet de tracer les blocs qui ont été changés. Ceci permet d’améliorer grandement les temps de sauvegarde !

Pour réinitialiser le CBT sur la VM :

  1. Eteindre la VM
  2. Editez les paramètres de la VM soit via le fichier .vmx soit via vsphere-client (Effectuer un clic droit sur la VM, cliquez sur « Edit settings », ouvrez l’onglet « Options », puis cliquez sur « Configuration Parameters »)
  3. Trouvez la valeur ctkEnabled et scsiY:X.ctkEnabled où Y correspond au numéro de controleur SCSI et X le numéro du neoud (ex: scsi0:2.ctkEnabled). Passez ces valeurs à ‘false’ ainsi que pour tous les disques de la VM.
  4. Allez dans le dossier de la VM et supprimez tous les fichiers …..-ctk.vmdk.
  5. Démarrez la VM et une fois qu’elle a fini de démarrer, éteignez-la !
  6. Basculez les valeurs que vous avez modifié précédemment à ‘true’.
  7. Allumez votre VM
  8. Relancez la tâche de sauvegarde pour réactiver le CBT.

Voilà ! J’espère que ceci vous a été utile et n’hésitez à laisser vos commentaires et partager votre expérience.

_____________________

A bientôt sur bidouilleit.com !

– Bruno Sousa –

Partagez...Share on FacebookTweet about this on TwitterShare on Google+Email this to someoneDigg thisShare on StumbleUponShare on LinkedInPin on PinterestPrint this page

2 réponses

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *