Acceso a Dispositivos Serie desde Máquinas Virtuales

Sí, con la misma regla que rige cualquier uso compartido entre varios clientes: use una conexión de servidor Raw en el host, que acepta varias VM cliente, y cada VM recibe una copia de la salida del dispositivo. En el modo Telnet (RFC 2217) la conexión es punto a punto — una VM a la vez — porque el control remoto del puerto no se puede compartir entre clientes.

Así que la compensación es Raw (muchas VM, pero sin negociación remota de velocidad/señales — configure el puerto en el host) frente a Telnet (una VM, control total del puerto). Y la advertencia sobre escritura también se aplica aquí: varias VM pueden leer de forma segura un dispositivo, pero si varias VM envían comandos a un único dispositivo de comando/respuesta, sus bytes se intercalarán en el único puerto físico. Para eso, designe una VM controladora o serialice los comandos a nivel de la aplicación.

Respondido por Nikolai Svarachevsky · Desarrollador principal

Sí — esto es, en efecto, un null-modem en red entre dos máquinas virtuales invitadas, y es un uso limpio de SEC. Cree un puerto COM virtual en cada VM y conéctelos a través de SEC (un lado como servidor y el otro como cliente, ya que los dos tipos de conexión son intercambiables). Cada programa abre su puerto COM virtual local como si hubiera un cable serie entre las dos máquinas, y SEC transporta los bytes a través de la red virtual intermedia. No interviene en absoluto ningún hardware serie físico.

Esta es una forma común de vincular dos aplicaciones que solo saben comunicarse a través de un puerto COM cuando ahora residen en máquinas virtuales separadas. Se aplica la orientación habitual: para un protocolo estricto de solicitud/respuesta entre ellas, manténgalo como un enlace simple de dos partes (peer-to-peer) en lugar de intentar distribuir un puerto compartido a varios extremos, y si alguno de los programas depende de una temporización ajustada de las líneas de señal, pruébelo — el salto de red entre las máquinas invitadas no es un cable de latencia cero.

Respondido por Nikolai Svarachevsky · Desarrollador principal

La conexión se restablece en lugar de reanudarse instantáneamente, y la rapidez depende en gran medida de usted: SEC tiene un intervalo de reconexión configurable que establece con qué frecuencia vuelve a intentar una conexión caída. Cuando una VM se pausa o se guarda, el sistema invitado se congela con un socket TCP abierto; al reanudarse, ese socket queda obsoleto, por lo que SEC lo cierra y se vuelve a conectar en el siguiente reintento. Si establece un intervalo corto, la recuperación será rápida — normalmente en cuestión de segundos después de que la red vuelva a estar activa en el sistema invitado —, aunque durante esa breve ventana la aplicación que mantiene el puerto COM virtual puede ver que el puerto se desconecta o genera un error antes de volver.

Dos notas prácticas. Históricamente, SEC ha sido sensible a la suspensión/reanudación y al Inicio rápido de Windows, así que trate la reanudación del sistema invitado como un evento de reconexión y asegúrese de que su aplicación tolere una breve interrupción del puerto. Y cualquier dato que un dispositivo de transmisión continua haya emitido mientras la VM estaba en pausa no se almacena en búfer para entregarse después — se pierde — porque SEC reenvía en vivo, no almacena ni reproduce.

Respondido por Bohdan Miniv · Ingeniería de QA

Junto con la licencia individual estándar, SEC ofrece una Licencia Individual para Máquina Virtual. Existe porque el escenario de VM implica endpoints de SEC que se ejecutan dentro de instancias invitadas, y la licencia de VM cubre ese modelo de uso en lugar de una única instalación física. Si va a implementar SEC en máquinas virtuales, este es el tipo de licencia con el que debe dimensionar su compra.

Debido a que los términos de la licencia y la cobertura exacta pueden cambiar y dependen de cuántos endpoints de VM esté ejecutando, confirme los detalles actuales en la página de precios o con el equipo de ventas antes de comprar a gran escala; de ese modo, se le asignará la licencia correcta para su implementación en lugar de descubrir una incompatibilidad más adelante.

Respondido por Bohdan Miniv · Ingeniería de QA

Ese es el comportamiento esperado, no un error. Cuando la opción Create as virtual port está marcada, la configuración predeterminada del puerto aparece en gris a propósito: para un puerto virtual, los parámetros (baud rate, paridad, bits de datos/parada) los define la aplicación que abre el puerto, no quedan fijos en SEC. La aplicación solicita el modo que quiere al conectarse, y el puerto virtual lo adopta.

Este es el modelo correcto para un puerto virtual porque la configuración de un dispositivo serie real solo importa en el extremo físico. Si está haciendo un puente hacia un puerto real y quiere fijar sus parámetros, configúrelos en el lado del puerto real; el lado virtual sigue a la aplicación. Si esperaba establecer de forma fija la velocidad del puerto virtual independientemente de la aplicación, simplemente no es así como funcionan los puertos virtuales, y forzarlo no ayudaría, ya que el modo solicitado por la aplicación es lo que realmente gobierna la sesión.

Respondido por Nikolai Svarachevsky · Desarrollador principal