Stanislas Quastana's blog on TechNet

Windows Server, Windows Client, Cloud Computing, DirectAccess, sécurité des Systèmes d Information

Windows Server 2012 - dépanner Hyper-V Replica

Windows Server 2012 - dépanner Hyper-V Replica

  • Comments 1
  • Likes

Hyper-V Replica est une des grosses nouveautés disponible dans Hyper-V édition Windows Server 2012. Et comme toute technologie, il faut parfois mettre les mains dans le cambouis et se remuer un peu les méninges pour dépanner une configuration ne voulant pas ou plus fonctionner.

 

Cet article a pour objectif de vous donner les trucs et astuces pour dépanner Hyper-V Replica et le tout illustré avec un cas réel sur lequel j’ai un peu transpiré.

Petit rappel préalable : A quoi sert Hyper-V Replica ?

A créer un réplica de machine virtuelle sur un second serveur Hyper-V (ou cluster Hyper-V). Ce réplica pouvant servir lors de l’application d’un Plan de Reprise d’Activité (PRA) pour redémarrer un ou des services.

Informations complémentaires sur Hyper-V Replica ici.

Méthodologie de dépannage par l’exemple

Dans le cas qui m’a concerné, la réplication Hyper-V après avoir parfaitement opérationnelle pendant des semaines s’est mise à ne plus fonctionner.

A chaque tentative de création d’un réplica de machine virtuelle j���obtenais le message d’erreur suivant dès que je cliquais sur le bouton Finish à la fin de l’assistant de création.

Hyper-V failed to enable replication.

Hyper-V Cannot connect to the Replica Server.

Bon là le message est plutôt clair : un problème de connexion au serveur Hyper-V destiné à héberger le réplica d’une machine virtuelle.

Un message compléter par quelques détails assez intéressants :

The Operation timed out (0x00002EE2). Verify that the specified server is enabled as a Replica Server, allows inbound connection on port ‘80’, and support the same authentication scheme.

Nous avons donc ici un message très explicite qui donne déjà des bonnes pistes.

Sur le serveur Hyper-V de Réplica, aller dans la console du gestionnaire Hyper-V et dans les paramètres Hyper-V

et aller dans la partie Replication Configuration

Là il faut vérifier :

1- La partie authentification : en fonction du choix retenu, les ports à ouvrir ne sont pas les mêmes. Par défaut authentification Kerberos (Hyper-V dans le même domaine) = port TCP 80. Par défaut authentification par certificat (Hyper-V du serveur de Replica en workgroup ou dans un domaine non approuvé) = TCP 443.

Bien noter le port nécessaire (pour la suite)

2- Dans la partie Authorization and Storage, vérifier que le serveur Hyper-V source (celui sur lequel tourne la VM dont on veut créer un réplica) est autorisé pour la réplication. Par défaut dans un mode Kerberos, tous les ordinateurs authentifiés dans un domaine sont acceptés.

Dans mon cas, ces paramètres étaient bons (= cela fonctionnait avant le “drame”) ce qui était confirmé lors de l’utilisation de l’assistant de création d’un réplica de machine virtuelle (qui récupère ces informations depuis le serveur de Réplica)

Ensuite, vérifier que la règle de pare-feu autorisant les flux entrant Hyper-V Replica est bien active. Ouvrir la console avancée de gestion du pare-feu du serveur Hyper-V Replica.

Il existe 2 règles de flux entrant :

  • Hyper-V Replica HTTP Listener (TCP-In): ça c’est pour l’authentification Kerberos et utilisation de HTTP (TCP 80)
  • Hyper-V Replication HTTPS Listener (TCP-In): ça c’est pour l’authentification avec certificat et utilisation de HTTPS (TCP 443)

Là encore dans mon cas ces règles étaient bien activées. Dans le doute et pour le test ultime, il est toujours possible de désactiver intégralement le pare-feu (à réactiver en post-résolution du problème).

Restent les tests classiques réseaux :

  • La résolution de nom du serveur Hyper-V Replica par le serveur Hyper-V source.
  • Le classique ping / traceroute

Là encore dans mon cas tout fonctionnait bien :-/

Ayant donc épuisé la majorité des documentations en ligne sur le sujet, je décide d’ouvrir les journaux d’évènements à la recherche d’informations complémentaires.

Pas de change, je retombe sur des messages similaires :

Could not replicate change for virtual machine ‘XXXXX’ as the Replica Server HyperStan3.w2k12-demo.net on port ‘80’ is not reachable. The Operation timed out. EventID 29292.

Hors j’avais déjà vérifié ce point au préalable (cf. règle de pare-feu activée voire désactivation complète du pare-feu).

Ne trouvant pas de solution, j’ai laissé ce problème en attente (il faut parfois aussi se sortir la tête du guidon) et fait d’autres opérations sur le serveur Hyper-V hébergeant mes VM.

Parmi ces opérations, j’ai voulu ajouter des ordinateurs supplémentaires à gérer depuis le gestionnaire de serveur et là surprise toutes les machines apparaissaient comme non administrables avec le message :

Online - Verify WinRM 3.0 is installed, running and required firewall ports are open 

Là encore, je vérifie sur le serveur Hyper-V Replica (HyperStan3) que WinRM est activé et exécuté et je re-désactive le pare-feu --> même résultat. Plus étrange : le phénomène semble se reproduire sur d’autres serveurs distants dont des contrôleurs de domaine (DC01, DC02). En utilisant le gestionnaire de serveur d’une autre machine, je n’obtiens pas ces erreurs

Désormais le problème semble dont être localisé non pas sur le serveur Hyper-V de Replica (HyperStan3) mais sur le serveur Hyper-V d’origine (HyperStan2)

Petite tentative en PowerShell d’ouverture de session distante en WinRM histoire d’avoir un message d’erreur plus explicite.

Grrrrr encore un message d’erreur indiquant de vérifier l’état du pare-feu sur la machine distante (que celle-ci ait ou pas un pare-feu activé).

Et là la pièce manquante du puzzle m’est apparue : HTTP(S)

En effet, WinRM s’appuie sur le protocole HTTP comme méthode de transport pour le protocole WS-Management.

Hors nous l’avons vu précédemment : Hyper-V Replica s’appuie aussi sur HTTP(S).

Et dans Windows quel composant dans la couche réseau traite HTTP ?  WinHTTP

 

Plus d’informations sur WinHTTP : http://blogs.technet.com/b/askperf/archive/2007/09/07/under-the-hood-winhttp.aspx

Du coup je me suis intéressé à la configuration de WinHTTP et plus particulièrement à la présence ou pas d’un proxy (car historiquement c’est surtout dans partie paramètres proxy de WinHTTP que je trainais Winking smile).

Ici sur le serveur HyperStan2, un proxy était paramétré pour WinHTTP. Ainsi toute les communications basées sur des Web Services passaient par ce serveur proxy y compris celles pour WinRM, Hyper-V Replica… Et devinez quoi : ce proxy avait été supprimé de mon infrastructure mais était toujours présent dans le paramétrage d’HyperStan2.

Ainsi, tous les communications basées sur des Web Services émises par mon serveur partaient en time out, le serveur proxy n’existant plus.

J’ai donc réinitialisé WinHTTP en mode accès direct

Et tout s’est remis à fonctionner correctement : Hyper-V Replica, la console de gestion des serveurs Smile

Comme quoi parfois les problèmes ont des origines lointaines et hors du périmètre proche du problème !

En espérant que ce petit article de dépannage pourra vous aider en cas de soucis avec Hyper-V Replica !!!

Pour tester Windows Server 2012, vous pouvez télécharger gratuitement la version d’évaluation disponible sous la forme :
- d'une image ISO :
http://aka.ms/jeveuxwindows2012

- d'un fichier VHD avec un système préinstallé : http://aka.ms/jeveuxwindows2012

 
-
Stanislas Quastana -

Comments
  • J'ai eu la même sur une infra DirectAccess il y a quelque semaines... Ce paramètre bien caché et de plus en plus souvent problématique je trouve...

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment