Erreurs VDDK avec un visage humain

La beauté et l'horreur des erreurs VDDK est que, d'une part, il est absolument clair où elle s'est cassée, et d'autre part, il est complètement incompréhensible pourquoi et comment le réparer maintenant. C'est comme si la fonction d'appel RPC avait échoué dans le monde Windows.



Bien que tout ne soit pas si terrible, bien sûr. Certaines erreurs ont des causes et des traitements très spécifiques. Et certains - une longue liste connue des causes les plus courantes et des options pour les corriger.



Notre support technique Veeam, bien sûr, accumule ces connaissances, et aujourd'hui nous allons jeter un œil à leurs entrées. Par conséquent, c'est avec grand plaisir que je vous présente les erreurs VDDK les plus courantes et les méthodes pour les éliminer.

 

Erreurs VDDK. Qu'est-ce que c'est et comment sont-ils obtenus?

 Comme vous pouvez le deviner d'après son nom, il s'agit d'une sorte de problèmes au niveau du VDDK Api (Virtual Disk Development Kit) - le meilleur moyen d'interagir avec l'infrastructure vSphere. Peu importe qu'il s'agisse d'un hôte ESXi séparé ou d'un vCenter tentaculaire, mais si nous devons écrire ou lire quelque chose à partir de notre infrastructure, la meilleure façon de le faire est le VDDK gratuit.



Pour simplifier au maximum, cette interaction ressemble à ceci: le serveur Veeam veut, par exemple, lire quelque chose de l'hôte (ou écrire) et lui envoie une requête. Un appel de lecture est créé indiquant à partir de quel disque, combien vous voulez lire, à partir de quel offset et vers quel tampon en mémoire. Ou écrivez, de la même manière, à partir du tampon spécifié. C'est simple.



Mais c'est dans un monde parfait. 



Dans la vraie vie, des erreurs se produisent parfois le long du chemin de cet algorithme simple, en raison desquelles il est impossible de compléter la demande. Et au lieu de la réponse attendue, un numéro d'erreur nous parvient, qui est soigneusement enregistré dans les journaux.



 Aujourd'hui, nous allons parler des erreurs les plus courantes.

 

Avertissement important!

 

Pas sûr - ne le faites pas! N'appuyez pas et ne touchez rien du tout! Il est toujours préférable d'appeler ou d'écrire au support Veeam plutôt que d'expérimenter votre produit. Heureusement, notre soutien est russophone et extrêmement technique.



Au moindre doute, appelez et demandez: "J'ai un tel problème, j'ai trouvé cette solution sur le réseau, cela m'aidera-t-il à le résoudre?" - normal et correct. Ce qui n'est ni normal ni juste, c'est que vous n'êtes pas sûr de vos actions, faites beaucoup de choses, puis demandez à tout restaurer des ruines en cinq minutes, et pour que rien ne soit perdu.



Oui, nous allons bien sûr aider dans ce cas, mais la meilleure bataille est celle qui n’existait pas. Par conséquent, essayez toujours d'évaluer de manière critique vos actions et tout le temps de fonctionnement important.

 

Erreur 1 VDDK: erreur inconnue

En fait, nous avons tout un article HF sur cette erreur . Et, comme il est dit, le plus souvent, cette erreur se produit si vous avez trop de compteurs de performance installés - et téléchargez un correctif de VMware qui réparera tout pour vous.



D'une part, il n'y a même rien à commenter. Voici le problème, voici une description (même si ce n'est pas très clair) et, surtout, voici un lien vers le médicament. Cependant, pas si simple. Selon nos observations, cette erreur peut survenir non seulement à cause d'un problème ennuyeux avec les compteurs, mais aussi à cause de:

1. VMDK . , , . — — . , . , , .
   
   
2. datastore. . , .
   
   
3. HBA . , . . ? 
   
   
4. , : ESXi vCenter.
   
   

 Eh bien, eh bien, je l’ai rattrapé, dites-vous. Et maintenant quoi? Comment comprendre qu'il est temps de courir de toute urgence pour de nouveaux disques - ou suffit-il de mettre un patch et d'expirer?



Et je vais vous répondre - gardez une série de tests simples qui vous aideront à prendre la bonne décision si quelque chose se produit.

• Nous lançons Storage vMotion ou clonons simplement une machine suspecte vers une autre banque de données, puis essayons de démarrer une sauvegarde. Si le clonage échoue, il y a certainement un problème quelque part dans le sous-système de disque. Mode paranoïa au maximum - et vérifiez tout, des disques aux contrôleurs.
  
  
  
  S'il a été cloné et enregistré avec succès, cela signifie que le VMDK a été endommagé, car pendant le clonage, VMware recrée son contenu, et maintenant il n'y a définitivement aucune erreur.   
  
  
• , . , . « — » .
  
  
• , , , — VMware.
  
  
• , . , . 
  
  

VDDK error 2: Value: 0x0000000000000002 

Presque toujours va de pair avec l'erreur VDDK 1. Selon nos statistiques, l'apparition d'une erreur est généralement associée à certaines versions du bundle vCenter / ESXi, le meilleur conseil ici est donc de passer au moins à la version 6.7. Et mieux et 7.0.



Si cela ne résout pas



le problème , passez au plan B.  L'erreur elle-même apparaît lorsque l'hôte ESXi manque de mémoire allouée au tampon de lecture NFC. Par défaut, Veeam fonctionne en mode de lecture asynchrone NBD / NFC, ce qui dans des conditions normales peut nécessiter l'extension de ce tampon. Mais cela ne se produit pas toujours. Par conséquent, pour désactiver ce mode, il existe une touche spéciale:

Name: VMwareDisableAsyncIo
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Type: REG_DWORD
Value: 1

Après l'avoir créé, vous devez redémarrer Veeam Backup Service et vous préparer à des performances qui ont chuté d'environ 10%.



Une autre option consiste à se connecter du côté hôte et à redémarrer les agents de gestion:

/etc/init.d/hostd restart
/etc/init.d/vpxa restart

La procédure est décrite en détail dans la base de connaissances de VMware , nous ne la réécrirons donc pas.



Et un ensemble standard d'options qu'il ne sera pas superflu de régler pendant le processus de diagnostic:

• Migrez les machines avec des erreurs vers un autre hôte.
• Essayez un autre mode de transport - HotAdd avec proxy virtuel ou DirectSAN.

Erreur VDDK 3: l'un des paramètres n'est pas valide

 Une erreur qui se produit presque toujours lors de l'utilisation du mode Virtual Appliance (aka mode HotAdd).



Il n'y a rien de spécial à dire ici, je vais juste donner des liens vers nos deux KBs, où de nombreuses options sont décrites, et même si vous venez immédiatement au support, il vous sera demandé de faire tout ce qui y est écrit.



KB1218 - Description générale des problèmes possibles et des méthodes de leur élimination.



KB1332 - Si votre serveur Veeam agit comme un proxy pour le mode HotAdd

 

Erreur VDDK 13: vous n'avez pas les droits d'accès à ce fichier

Et pour ce cas, nous avons KB2008 . Oui, il existe de nombreuses options pour éliminer ce problème, mais une telle erreur. Il est presque impossible de dire sans équivoque ce qui s'est passé exactement dans votre cas, vous devez donc parcourir et parcourir toute la liste. 



Ce que je voudrais dire en plus Soyez très prudent avec la section Dépannage supplémentaire. Oui, il y a des écrits, peut-être trop évidents pour beaucoup de choses. Mais même de telles platitudes échappent aux professionnels les plus professionnels. Il y a souvent des cas où, après une semaine, essayant de tout résoudre par eux-mêmes, ils viennent au support uniquement pour découvrir qu'ils n'ont pas lu attentivement la liste des exigences techniques, ou quelque chose du genre. Et c'est dommage et dommage pour le temps passé.



Et deux conseils pour tous les temps:

• Veeam proxy , UUID . - , . , , . 
• ( — ), , VDDK .

 

 VDDK error 18000: Cannot connect to the host 

Dans la plupart des cas, la faute de cette erreur réside dans un bogue dans le VDDK lui-même. Plus précisément, la bibliothèque gvmomi.dll est à blâmer. Et il ne se montre que sous une lourde charge. Par exemple, lorsque de nombreuses machines sont sauvegardées en parallèle, l'une des fonctions devient 0 et la bibliothèque peut s'effondrer. Et puis tout le reste tombe.



Telle est la triste histoire. 



Mais le pire dans cette histoire est qu'il est impossible de reproduire avec précision les conditions du bogue. C'est ce que les testeurs appellent des bogues flottants. Il est donc impossible de dire exactement combien de machines parallèles sont à l'origine du crash.



Cependant, selon les notes de publication officiellesce bogue a été complètement corrigé. La bonne solution est donc de mettre à jour votre hôte. Mais si pour une raison quelconque, il est impossible de le faire, la seule façon dont nous pouvons vous aider est de vous conseiller de réduire le nombre de machines traitées simultanément.



Pas d'autre chemin.



 

Erreur VDDK 14008: le serveur spécifié n'a pas pu être contacté

 Donc, si ce problème vous arrive, la première chose à faire est de vérifier le réseau. Très probablement, la communication entre vCenter et le proxy Veeam est interrompue. Vérifiez si tous les ports sont ouverts et accessibles, si tous les noms DNS sont correctement résolus aux adresses IP attendues. De plus, vous devez vérifier le proxy spécifique impliqué dans le travail échoué, et non celui qui se trouve à côté exactement de la même manière (il y a des cas).

95% des cas avec cette erreur sont fermés avec la marque «Problème avec DNS / ports dans l'infrastructure client».



Par conséquent, une fois encore, je vous exhorte à vérifier très attentivement si le serveur DNS correct est indiqué partout, s'il y a des ports fermés et dans quelle adresse IP les noms FQDN sont résolus.



 Dans les anciennes versions de VDDK, une erreur similaire se produisait lors de l'utilisation d'un port autre que celui par défaut pour travailler avec vCenter, qui représentait les 5% restants, mais maintenant VMware a masqué la base de connaissances avec sa description, ce qui signifie probablement que la base de connaissances n'est plus pertinente. Mais vous pouvez le rechercher dans les archives Internet à 2108658 (la sauvegarde échoue lorsqu'un port autre que celui par défaut est spécifié pour VMware vCenter Server).

 

Erreur VDDK 14009: le serveur a refusé la connexion

 Et la dernière erreur dans notre top d'aujourd'hui est Le serveur a refusé la connexion. Tout est absolument banal ici: quelque chose empêche la connexion entre l'hôte et le proxy. Dans la plupart des cas, le pare-feu est à blâmer. Mais - le point subtil - pas à cause des ports fermés, mais à cause des retards introduits. Donc, tout d'abord, nous vérifions l'ouverture du port 443, puis nous examinons les délais d'attente.

Si les deux options n'ont rien donné, allez au support. Nous devrons vérifier l'hôte lui-même. Peut-être qu'il est simplement trop occupé et n'a pas le temps de répondre à temps, et peut-être autre chose.

 

Et enfin, quelques liens utiles:

• Portail de notre support technique primé.
• Base de connaissances du support Veeam