7

We are trying to connect two Hyper-V VMs through a serial port. Hyper-V exposes the serial port as a named pipe to the host system, and implements the server end of the named pipe. Consequentially, to connect them, we need to write a named-pipe client which connects to both VMs, and copies the data back and forth.

We have written such an application. Unfortunately, this application loses data.

If we connect two hyperterms, and have them exchange data, the transmission sometimes succeeds, but in many cases, the receiving end reports errors, or the transmission just deadlocks. Likewise, if we use the link to run a kernel debugger, it also seems to hang often.

What could be the cause of the data loss? What precautions must be taken when connecting named pipes in such a manner?

Edit: We have worked around the problem, using kdsrv.exe. The COM port of the debuggee continues to be exposed through a named pipe, however, the debugger end talks to kdserv via TCP.

Martin v. Löwis
  • 124,830
  • 17
  • 198
  • 235

3 Answers3

2

The data loss is not due to the named pipes. It is infact the COM ports (emulated and physical) that may lose data since they operate with a small buffer in the UART.

The named pipe receives all the data that is written to the COM port. Your program reads data from the named pipe and writes it to another named pipe. This is where data loss can originate if you write too fast the receiveing COM port's UART can overflow leading to data loss.

You may need to add some delay to avoid exceeding the baud rate expected by the receiving side.

In addition, you are missing ResetEvent() calls in your program.

For your KD issues, you may need to add resets=0 to the connection string.

John
  • 5,561
  • 1
  • 23
  • 39
  • Thanks for the suggestion. Throttling the forwarding helps a little; a plain "copy foo.txt COM1:" can now successfully transmit all data. Unfortunately, HyperTerm still deadlocks in zmodem communication, so there still must be data loss somewhere. As for ResetEvent: where specifically is it missing? Async IO is defined to reset the events properly in ReadFile and WriteFile. Will test resets=0 tomorrow. – Martin v. Löwis Feb 15 '11 at 16:49
  • My misteake. There is no need for ResetEvent. – John Feb 15 '11 at 17:30
  • This answer doesn't fully resolve the problem, only partially. Still, it's the best answer we got, so I'm awarding it the bounty. See my edit for how we worked around the problem. – Martin v. Löwis Feb 19 '11 at 19:54
0

I did not try to connect VM via Serial but I connected VM and Host via usb (through network) and it works. If it is required for your software to establish serial connection try to test via serial emulators with work through tcp\ip.

TheNIK
  • 67
  • 1
  • 8
  • Thanks for the proposal. Unfortunately, the real application is the kernel debugger here, which won't work with any kind of networking in the guest machine. – Martin v. Löwis Feb 11 '11 at 21:49
0

I think John's suggestion is correct - if u are using a slow CPU to emulate TWO VM, then the guest OS's drivers for serial port is highly drifted away from the high speed version. So John's suggestion is to set the input/output side of the serial link to the slowest possible speed. Ie, you cannot use high baud rate for the inter-VM serial communication. Instead u have to use the slowest possible speed, and so that the VM guest driver will take that cue and use the slower version of the driver. But your physical machine must have sufficient CPU speed to run two VM concurrently, to avoid the "emulation drift" of the the serial driver.

Well, just my guess, but there is a VirtualBox version of your problem, seemingly no issues running it:

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

But the following bug ticket for VirtualBox does describe many similarities to your problem:

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

And reading the end seemingly indicate the solution has to do with VirtualBox's internal source code. Perhaps it is Hyper-V's problem?

Peter Teoh
  • 6,337
  • 4
  • 42
  • 58