2011-02-11 13 views
7

Estamos intentando conectar dos máquinas virtuales Hyper-V a través de un puerto en serie. Hyper-V expone el puerto serie como una tubería con nombre al sistema host, e implementa el extremo del servidor de la tubería con nombre. En consecuencia, para conectarlos, necesitamos escribir un cliente de canalización con nombre que se conecte a ambas máquinas virtuales y copie los datos hacia adelante y hacia atrás.Hyper-V: la conexión de máquinas virtuales a través de un conducto con nombre pierde los datos

We have written such an application. Desafortunadamente, esta aplicación pierde datos.

Si conectamos dos hyperterms y hacemos que intercambien datos, la transmisión a veces tiene éxito, pero en muchos casos, el extremo receptor informa errores, o la transmisión simplemente bloquea. Del mismo modo, si utilizamos el enlace para ejecutar un depurador de kernel, también parece colgarse con frecuencia.

¿Cuál podría ser la causa de la pérdida de datos? ¿Qué precauciones se deben tomar al conectar los tubos con nombre de esa manera?

Editar: Hemos trabajado todo el problema, utilizando kdsrv.exe. El puerto COM del depurador sigue estando expuesto a través de un conducto con nombre, sin embargo, el extremo del depurador se comunica con kdserv a través de TCP.

Respuesta

1

La pérdida de datos no se debe a los conductos nombrados. De hecho, los puertos COM (emulados y físicos) pueden perder datos, ya que funcionan con un pequeño buffer en el UART.

La tubería con nombre recibe todos los datos que se escriben en el puerto COM. Su programa lee datos de la tubería con nombre y lo escribe en otra tubería con nombre. Aquí es donde puede originarse la pérdida de datos si escribe demasiado rápido que el UART del puerto COM que lo recibe puede desbordarse y provocar la pérdida de datos.

Es posible que tenga que agregar un poco de retraso para evitar exceder la velocidad en baudios esperada por el lado receptor.

Además, le faltan ResetEvent() llamadas en su programa.

Para sus problemas de KD, es posible que necesite agregar resets=0 a la cadena de conexión.

+0

Gracias por la sugerencia. Estrangular el reenvío ayuda un poco; un simple "copy foo.txt COM1:" ahora puede transmitir con éxito todos los datos. Desafortunadamente, HyperTerm sigue bloqueándose en la comunicación zmodem, por lo que aún debe haber pérdida de datos en alguna parte. En cuanto a ResetEvent: ¿dónde falta específicamente? Async IO se define para reiniciar los eventos correctamente en ReadFile y WriteFile. Se restablecerá la prueba = 0 mañana. –

+0

Mi misteake. No hay necesidad de ResetEvent. – John

+0

Esta respuesta no resuelve completamente el problema, solo parcialmente. Aún así, es la mejor respuesta que tenemos, así que le estoy otorgando la recompensa. Ver mi edición de cómo trabajamos alrededor del problema. –

0

No intenté conectar VM a través de Serial, pero conecté VM y Host a través del usb (a través de la red) y funciona. Si su software requiere una conexión en serie, intente realizar la prueba a través de emuladores en serie con trabajo a través de tcp \ ip.

+0

Gracias por la propuesta. Desafortunadamente, la aplicación real es el depurador de núcleo aquí, que no funcionará con ningún tipo de red en la máquina invitada. –

0

Creo que la sugerencia de John es correcta: si está utilizando una CPU lenta para emular DOS máquinas virtuales, los controladores del sistema operativo invitado para el puerto serie se alejan mucho de la versión de alta velocidad. Entonces, la sugerencia de John es establecer el lado de entrada/salida del enlace en serie a la velocidad más lenta posible. Es decir, no puede usar una velocidad en baudios alta para la comunicación serie entre máquinas virtuales. En su lugar, tiene que usar la velocidad más lenta posible, y para que el controlador invitado de VM tome esa referencia y use la versión más lenta del controlador. Pero su máquina física debe tener suficiente velocidad de CPU para ejecutar dos máquinas virtuales al mismo tiempo, para evitar la "deriva de emulación" del controlador serie.

Bueno, sólo mi suposición, pero hay una versión de VirtualBox de su problema, aparentemente no hay problemas de ejecutarlo:

http://bodocsi.net/2011/02/how-setup-serial-port-link-in-virtualbox-between-two-guest-virtual-machine-in-linux/

Pero el siguiente billete de errores para VirtualBox Cómo describe muchas similitudes con su problema:

https://www.virtualbox.org/ticket/1548

Y la lectura final al parecer indicar que la solución tiene que ver con el código fuente interna de VirtualBox. Quizás es el problema de Hyper-V?

Cuestiones relacionadas