Le provider VSS Microsoft n’est pas en bonne santé ?

Je souhaitais vous faire part d’un petit soucis que j’ai rencontré chez un client. Ce post me permettra aussi de pousser mon coup de gueule, ce que je ne fais jamais sur mon blog …

 

Un client me téléphone en me racontant la chose suivante:

Bonjour M. Lachari, comment allez-vous ? Je me permets de vous appeler car nous souhaitons mettre une solution de backup pour Hyper-v et nous nous sommes orientés vers Acronis.

Notre prestataire me remonte un problème sur le service VSS Microsoft et ne peut pas mettre en place la solution de sauvegarde. Il tente de réaliser un snapshot du volume C:\ mais cela génère une erreur. Il faudrait alors que vous voyiez ce qui se passe et que vous répariez le service VSS …

 

Je prends donc la parole et lui dit la chose suivante:

Comment est-ce que le service provider VSS Microsoft natif à l’OS peut ne pas fonctionner sur les hôtes ? Quels tests exactement votre prestataire souhaitent réaliser ?

 

Et là le prestataire me répond:

Bonjour, pour mettre en place la solution, Acronis nous demande, via une KB, de tester VSS Microsoft avec diskshadow. Tout est expliqué sur le site Internet de l’éditeur. Nous avons remonté le problème au support 3 et ils nous disent qu’il faut voir cela avec un expert Hyper-v. Le soucis vient de Microsoft …

 

 

En tant que professionnel, je demande donc à avoir cette fameuse KB afin de voir ces fameux tests préalables au bon fonctionnement du produit. Je reçois alors le lien suivant: kb.acronis.com/content/45472.

 

Etant donné qu’il s’agit quand même d’un éditeur reconnu mondialement, je suis la procédure et m’aperçois que j’obtiens bien une erreur ! Bizarre …  Je tente de voir si je n’me suis pas trompé dans les lignes de commande mais encore une fois je me trouve face à l’erreur. Je pense donc à réaliser l’opération sur des CSVs et là les résultats sont positifs.

 

Comment peut-on dire que le service VSS de Microsoft est défectueux ? Il s’en suit alors une discussion houleuse entre le prestataire et moi-même sur le sujet. Il me dit de ne pas prendre le support N3 d’Acronis pour des abrutis, chose que je n’ai absolument pas dite ! Je raccroche alors afin d’en finir avec ce prestataire borné et irrespectueux.

 

Le lendemain, je rappelle mon client, sans la présence du prestataire, afin de me connecter en remote sur l’infra et tenter d’analyser cette situation. Je reprends la KB Acronis pour analyser les commandes :

C:\Users\administrator> DISKSHADOW
permet d’appeler l’outil vérifiant le service VSS

DISKSHADOW> set context persistent
permet de spécifier que la copie “fantôme” continue après un reset …

DISKSHADOW> set verbose on
permet d’obtenir des informations pendant la copie

DISKSHADOW> begin backup
permet de commencer la sauvegarde

DISKSHADOW> add volume C: alias VolumeC
permet d’ajouter le volume système dans la sauvegarde

DISKSHADOW> add volume C: alias VolumeC provider {b5946137-7b9f-4925-af80-51abd60b20d5}
permet de spécifier le provider VSS Microsoft lors de l’opération

 

Pour avoir l’ID du provider VSS Microsoft, il vous suffit de taper la commande:

C:\> vssadmin list providers

providers

 

DISKSHADOW> writer verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
permet de spécifier le writer du service Hyper-v pour les VM

 

Pour avoir l’ID du writer Hyper-v Virtual Machines, il suffit de taper la commande:

C:\> vssadmin list writers

writers2

 

 

DISKSHADOW> create
permet de créer le snapshot sur le volume C:\

 

 

J’obtiens toujours l’erreur. Je retape la commande pour avoir l’ID du writer Hyper-v Virtual Machine et là je m’aperçois qu’il est en erreur. Nous inquiétez pas: c’est un phénomène normal quand vous faites un test de snapshot avec ce writer.

 

Je redémarre donc le service Hyper-v Virtual Machine Management pour remettre en “bonne santé” le writer en question. Et là, je m’aperçois de l’erreur énorme et inadmissible fournie sur la KB d’Acronis et approuvée par le prestataire. En effet, à chaque fois que vous redémarrez le service Hyper-v Virtual Machine Management, l’ID du writer est modifié. Il ne peut donc pas être continuellement celui donné sur la KB: {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}. De plus, il faut prendre l’ID de l’instance du writer et non l’ID du writer. Par conséquent, le prestataire pouvait continuer à vérifier le service VSS il aurait toujours eu l’erreur.

 

J’ai donc retapé toutes les commandes citées ci-dessus avec le bon ID et là : tout fonctionne correctement et le snapshot du volume C:\ s’opère avec succès.

 

issue

 

 

Mon coup de gueule est donc pour Acronis car faire une erreur aussi flagrante et spécifier que le support N3 est sûre que l’erreur vienne de Microsoft c’est juste faire preuve de non professionnalisme et d’incompétence. Mais mon plus gros coup de gueule est à l’attention du prestataire, dont je ne citerai pas le nom, qui a affirmé avoir raison et qui m’a manqué de respect. Par conséquent, Monsieur D., je vous invite à réfléchir avec votre tête et non comme un âne …

 

 

 

David LACHARI – Le savoir ne vaut que s’il est partagé …

becloud

Passionné par la virtualisation, David est MVP Virtual Machine depuis 2010. Il intervient quotidiennement auprès de grands comptes afin de définir et déployer des architectures virtuelles. David est le fondateur de la société VSTART, spécialisée dans le conseil et l’expertise des solutions de virtualisation Microsoft.
Non classé

becloud

Passionné par la virtualisation, David est MVP Virtual Machine depuis 2010. Il intervient quotidiennement auprès de grands comptes afin de définir et déployer des architectures virtuelles. David est le fondateur de la société VSTART, spécialisée dans le conseil et l’expertise des solutions de virtualisation Microsoft.

Laisser un commentaire

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