Accès à des périphériques série depuis des machines virtuelles

Oui, avec la même règle qui régit tout partage multi-client : utilisez une connexion de serveur Raw sur l’hôte, qui accepte plusieurs VM clientes, et chaque VM reçoit une copie de la sortie du périphérique. En mode Telnet (RFC 2217), la connexion est de pair à pair — une VM à la fois — car le contrôle de port à distance ne peut pas être partagé entre clients.

Le compromis est donc le suivant : Raw (plusieurs VM, mais pas de négociation à distance du débit/des signaux — configurez le port sur l’hôte) contre Telnet (une VM, contrôle complet du port). Et la mise en garde concernant l’écriture s’applique ici aussi : plusieurs VM peuvent lire en toute sécurité un même périphérique, mais si plusieurs VM envoient des commandes à un seul périphérique à commandes/réponses, leurs octets s’entrelaceront sur l’unique port physique. Dans ce cas, désignez une VM de contrôle unique ou sérialisez les commandes au niveau de l’application.

Réponse de Nikolai Svarachevsky · Développeur principal

Oui — il s’agit effectivement d’un null-modem en réseau entre deux invités, et c’est une utilisation propre de SEC. Créez un port COM virtuel dans chaque VM et connectez-les via SEC (un côté comme serveur, l’autre comme client, puisque les deux types de connexion sont interchangeables). Chaque programme ouvre son port COM virtuel local comme si un câble série reliait les deux machines, et SEC transporte les octets à travers le réseau virtuel intermédiaire. Aucun matériel série physique n’est impliqué.

C’est une manière courante de relier deux applications qui ne savent communiquer que via un port COM alors qu’elles résident désormais dans des VM distinctes. Les recommandations habituelles s’appliquent : pour une poignée de main stricte de type requête/réponse entre elles, conservez une liaison simple à deux parties (pair à pair) plutôt que d’essayer de répartir un port partagé entre plusieurs points de terminaison, et si l’un des programmes dépend d’une synchronisation très précise des lignes de signal, testez-le — le saut réseau entre invités n’est pas un fil à latence nulle.

Réponse de Nikolai Svarachevsky · Développeur principal

La connexion se rétablit plutôt que de reprendre instantanément, et sa rapidité dépend en grande partie de vous : SEC dispose d’un intervalle de reconnexion configurable qui détermine à quelle fréquence il réessaie après une liaison interrompue. Lorsqu’une VM est mise en pause ou enregistrée, le système invité se fige avec un socket TCP ouvert ; lors de la reprise, ce socket est périmé, donc SEC le ferme et se reconnecte à la tentative suivante. Définissez un intervalle court et la récupération sera rapide — généralement en quelques secondes après le rétablissement du réseau dans le système invité — tandis que pendant cette brève période, l’application qui utilise le port COM virtuel peut voir le port se déconnecter ou générer une erreur avant son retour.

Deux remarques pratiques. SEC a historiquement été sensible à la mise en veille/reprise et au démarrage rapide de Windows, considérez donc la reprise du système invité comme un événement de reconnexion et assurez-vous que votre application tolère une brève interruption du port. Et toutes les données qu’un appareil diffusant en continu a émises pendant que la VM était en pause ne sont pas mises en mémoire tampon pour être livrées plus tard — elles sont perdues — car SEC transmet en direct, il ne stocke pas et ne rejoue pas.

Réponse de Bohdan Miniv · Ingénierie QA

En plus de la licence unique standard, SEC propose une licence unique dédiée pour machine virtuelle. Elle existe parce que le scénario VM implique des points de terminaison SEC exécutés à l’intérieur d’instances invitées, et la licence VM couvre ce modèle d’utilisation plutôt qu’une seule installation physique. Si vous déployez SEC dans des machines virtuelles, c’est le type de licence sur lequel dimensionner votre achat.

Comme les conditions de licence et la couverture exacte peuvent changer et dépendent du nombre de points de terminaison VM que vous exécutez, confirmez les détails actuels sur la page des tarifs ou auprès de l’équipe commerciale avant d’acheter à grande échelle — ainsi, vous serez associé à la licence adaptée à votre déploiement au lieu de découvrir plus tard une incompatibilité.

Réponse de Bohdan Miniv · Ingénierie QA

C’est le comportement attendu, pas un bug. Lorsque l’option Create as virtual port est cochée, les paramètres par défaut du port sont grisés volontairement : pour un port virtuel, les paramètres (débit en bauds, parité, bits de données/d’arrêt) sont définis par l’application qui ouvre le port, et non fixés dans SEC. L’application demande le mode qu’elle souhaite lors de la connexion, et le port virtuel l’adopte.

C’est le bon modèle pour un port virtuel, car les paramètres d’un véritable périphérique série n’ont d’importance qu’à l’extrémité physique. Si vous créez un pont vers un port réel et souhaitez fixer ses paramètres, configurez-les du côté du port réel ; le côté virtuel suit l’application. Si vous pensiez pouvoir définir manuellement le débit du port virtuel indépendamment de l’application, ce n’est tout simplement pas ainsi que fonctionnent les ports virtuels — et l’imposer n’aiderait pas, puisque c’est le mode demandé par l’application qui régit réellement la session.

Réponse de Nikolai Svarachevsky · Développeur principal