Port série Hyper-V - Guide pas à pas

Comment accéder au port série dans Hyper-V

Lorsque vous devez accéder au port série dans Hyper-V, vous pouvez utiliser notre guide simple. Voici un guide vidéo sur l'accès COM dans Hyper-V avec Serial to Ethernet Connector:

Didacticiel vidéo:

Comment connecter du matériel série à une machine virtuelle avec PipeDream

Pour les utilisateurs de machines virtuelles qui souhaitent ajouter un port COM aux ports série Hyper-V, PipeDream est une option idéale. Ce port série dans l'outil Hyper-V s'exécute via le même serveur hébergeant Hyper-V (qui est un hôte de virtualisation), comblant le fossé entre les machines virtuelles et les ports série.

PipeDream fonctionne en transmettant les données reçues du matériel série (tout ce qui est branché sur le port COM) et aide la machine virtuelle à le reconnaître et à y accéder (et vice versa.)

De plus, PipeDream n'a pas besoin d'un élément côté client pour s'exécuter sur un serveur, ce qui rend la prise en charge série Hyper-V encore plus pratique. PipeDream ne nécessite aucune installation (périphérique, logiciel ou autre) sur la ou les machines virtuelles participantes, maximisant ainsi la compatibilité des systèmes d'exploitation/logiciels hérités et une prise en charge fiable des systèmes d'exploitation XP (et antérieurs).

PipeDream permet aux machines virtuelles invitées de contrôler les ports série sur l'hôte de virtualisation (ou d'autres machines. Cet outil fonctionne grâce à la prise en charge du canal nommé d'Hyper-V, ce qui signifie qu'une connexion réseau n'est pas nécessaire pour la communication. Créez simplement un nom de canal dans Hyper-V , et PipeDream se connectera au périphérique série de la machine virtuelle invitée une fois que vous aurez démarré le programme PipeDream.

Avis de non-responsabilité : Le port série PipeDream du logiciel Hyper-V est compatible avec Hyper-V de Microsoft, mais il s'agit d'un outil tiers sans affiliation à Microsoft. Notre utilisation du terme « Hyper-V » ne vise pas à approuver ou à être affilié à Microsoft Corporation.

Mais il n'y a pas de ports COM pour les machines virtuelles Gen 2, n'est-ce pas... ?

Franchement, la réponse est un mélange de oui et de non (avec le « non » principalement centré sur les capacités de passthrough du port série Hyper-V par défaut.) La bonne nouvelle est que c'est réglable !

Les captures d'écran ci-dessous proviennent d'une machine virtuelle Windows 8 (utilisant spécifiquement le support créé dans la section précédente où le pilote pour le clavier logiciel a été ajouté.)

Dans l'exemple ci-dessous, vous verrez que les paramètres d'une machine virtuelle de base gen-2 manquent d'options de port COM.

La raison en est que, que les ports série soient disponibles ou non, Gen-2 Hyper-V Manager n'affiche jamais les ports COM.

Ci-dessous, nous allons jeter un œil à ce que PowerShell a à dire :

Remarquez comment PowerShell affiche deux ports COM disponibles ? Cependant, si vous ouvrez le gestionnaire de périphériques de la machine invitée, aucun port COM ne sera répertorié pour la machine virtuelle.

Consultez l'exemple ci-dessous (à l'aide de COM1) pour configurer un chemin de canal pour les ports COM lorsqu'une machine virtuelle est en cours d'exécution :

Comme mentionné précédemment, lors de la vérification du gestionnaire de périphériques de la machine invitée, COM1 ne s'affiche pas, mais une fois la machine virtuelle arrêtée et redémarrée, le port COM souhaité sera désormais disponible dans la liste (voir ci-dessous).

Pour ceux qui ont l'expérience du débogage du noyau, le processus restant est assez simple et direct, avec une seule exception mineure spécifique aux machines virtuelles Gen-2 (encore plus spécifiquement les ordinateurs basés sur UEFI utilisant Secure Boot.)

Via msconfig, nous avons activé le débogage du noyau pour la VM sur COM1. Cependant, une fois que nous avons cliqué sur OK, le message d'erreur suivant apparaît :

Pourquoi ? Parce que la politique de Windows indique que le démarrage sécurisé et le débogage du noyau ne sont pas compatibles. Cela signifie que les utilisateurs doivent désactiver la machine virtuelle, puis désactiver le démarrage sécurisé à partir des paramètres du micrologiciel.