Vous êtes ici: Dépannage > Problèmes liés aux machines virtuelles de secours > Echecs des jobs Virtual Standby liés à des erreurs internes

Echecs des jobs Virtual Standby liés à des erreurs internes

Applicable aux systèmes d'exploitation Windows

Symptôme 1:

Les jobs Virtual Standby échouent. Un des messages suivants s'affiche dans le journal d'activité :

Echec de conversion du disque virtuel

Une erreur interne s'est produite, contactez le support technique.

En outre, VDDK émet le message d'erreur suivant :

Erreur inconnue

Solution 1:

Pour remédier à ce problème, envisagez les solutions suivantes :

Les opérations de conversion peuvent échouer lorsque l'espace libre sur le disque est insuffisant dans le référentiel de données spécifié dans la stratégie Virtual Standby. VDDK renvoie ce message, car l'API de VDDK ne prend actuellement pas en charge la fonctionnalité de détection d'espace disponible du référentiel de données. Pour corriger ce problème, libérez l'espace disque dans le référentiel de données d'origine nécessaire pour terminer l'opération, puis resoumettez le job.

Le dérangement du réseau et le trafic réseau élevé peuvent provoquer l'échec des opérations de conversion. Pour corriger ce problème, vérifiez que le noeud source et les système ESX Server ou vCenter Server peuvent communiquer l'un avec l'autre sur le réseau, puis relancez le job.
Plusieurs connexions simultanées (notamment des connexions SDK vSphere via le client VMware vSphere) incluant des jobs de récupération ou de sauvegarde de machines virtuelles sur le système ESX Server ou sur le système vCenter Server peuvent provoquer l'échec de ces jobs. Pour corriger ce problème, fermez toutes les connexions inutiles, puis relancez le job.
Ce problème est le résultat d'une limitation de connexion de VMware VDDK. Les limites du protocole Network File Copy (NFC) suivantes s'appliquent :

ESXi 5 : limité par un tampon de transfert pour toutes les connexions NFC établies par l'hôte. La somme de tous les tampons de connexion NFC à un hôte ESXi ne doit pas dépasser 32 Mo. 52 connexions à travers vCenter Server incluant la limite par hôte.

Remarque : Les connexions ne peuvent pas être partagées entre les disques. Les valeurs de connexions maximales ne s'appliquent pas aux connections SAN et HOTADD. Si un échec de la fermeture du client NFC se produit, les connexions peuvent rester ouvertes pendant dix minutes.

Consultez les sections Tâches et événements du journal du client vSphere de VMware pour détecter les erreurs internes d'une machine virtuelle spécifique. Corrigez les erreurs internes, puis relancez le job.
Exemple : Une autre application ou opération utilise le fichier VMDK. Pour corriger ce problème, libérez le fichier, puis relancez le job.

Symptôme 2:

Les jobs Virtual Standby échouent. Un des messages suivants s'affiche dans le journal d'activité :

Echec de conversion du disque virtuel

Une erreur interne s'est produite, contactez le support technique.

En outre, VDDK émet le message d'erreur suivant :

L'ouverture de vmdk a échoué avec l'erreur Fichier introuvable.

Solution 2:

Ce problème peut se produire dans les cas suivants :

VDDK n'a pas traité un cliché correctement.
VDDK n'a pas supprimé un cliché manuellement ou interne à la machine virtuelle.

Pour corriger ce problème, relancez le job. En cas de nouvel échec du job, supprimez la machine virtuelle récupérée et relancez le job.

Symptôme 3:

Les jobs Virtual Standby échouent. Un des messages suivants s'affiche dans le journal d'activité :

Impossible d'appliquer <nom_plan> au noeud <nom_noeud>. Le service Web de l'agent Arcserve UDP sur le convertisseur <nom_convertisseur> est occupé. Réessayez plus tard.

En outre, le message d'erreur suivant est consigné dans le fichier journal de la console UDP (ARCApp.log) :

[ERREUR] deployVsbTask : Impossible d'appeler l'API de service Web D2D - Délai expiré. javax.xml.ws.WebServiceException : java.net.SocketTimeoutException : Expiration du délai de lecture

Solution 3 :

Ce problème peut être dû à une expiration du délai. Pour le résoudre, procédez comme suit :

Connectez-vous à la console UDP avec les informations d'identification appropriées.
Ouvrez l'interface de ligne de commande et exécutez la commande ci-dessous :
regedit
Le registre s'ouvre.
Accédez au dossier \SOFTWARE\Arcserve\Unified Data Protection\Engine\WebService.
Vérifiez que la clé timeoutValue existe. Si elle n'existe pas, créez-la manuellement.
Ajoutez/Modifiez la clé comme ci-dessous :
- Nom de la clé : timeoutValue
1. Valeur : <entrez la valeur en minutes>. Par exemple, si vous souhaitez définir la valeur du délai d'expiration sur 20 minutes, saisissez 20 comme valeur.
Quittez regedit.
Accédez au dossier d'installation de la console UDP. Par exemple, C:\Program Files\Arcserve\Unified Data Protection\Management\Configuration.
Ouvrez le fichier ConsoleConfiguration.xml dans le bloc-notes.
Recherchez le texte ci-dessous, sous la section <TimeoutConf> :
<webServiceRequestTimeout>600</webServiceRequestTimeout>
Modifiez la valeur de webServiceRequestTimeout en secondes. Par exemple, si vous souhaitez définir la valeur du délai d'expiration sur 20 minutes, saisissez 1200 comme valeur.
Enregistrez le fichier et quittez.
Redémarrez le service de gestion de la console UDP afin que les paramètres prennent effet.
Redéployez le plan et vérifiez le résultat.