virtio-serial devices in qemu-kvm break when guests write on channel with host side closed

There is a problem in Ubuntu 16.04 when using virtio-serial devices in qemu-kvm where writing to a channel from the guest side when the host side has been closed will result in the host subsequently not being able to read any data after the host side has been reopened. Here are the steps to describe the problem in more detail:

1. Using virt-manager or some other means, install you favorite Linux distribution that has virtio-serial support in the kernel.
2. Add the following to the libvirt XML for the guest that you created:

    <channel type='pty'>
      <target type='virtio' name='test'/>
      <address type='virtio-serial' controller='0' bus='0' port='3'/>
    </channel>

3. Start up the guest and while it is booting do a virsh dumpxml to determine the /dev/pty/? device attached to the host side of the channel.
4. In a terminal on the host, execute the command "cat /dev/pty/?" to capture output.
5. In a terminal on the guest, execute the command "echo test1 > /dev/virtio-ports/test".
6. Observe that the message "test1" is displayed on the host side.
7. Press CTRL-C in the terminal on the host to kill the "cat" command.
8. In the terminal on the guest, execute the command "echo test2 > /dev/virtio-ports/test".
9. In a terminal on the host, execute the command "cat /dev/pty/?" to capture output again.
10. Observe that "test2" is not displayed in the output on the host side.
11. In the terminal on the guest, execute the command "echo test3 > /dev/virtio-ports/test".
12. Observe that "test3" is also not displayed in the output on the host side.

If you skip the step where "test2" is sent when the host side is closed then you will see "test3" displayed successfully. It seems that if any write occurs on the guest side while the host side has been closed, then it breaks the virtio-serial channel in a manner that nothing else can ever be read again. The only way to get it working again is to completely shutdown the guest and restart it. The operating system running inside the guest does not appear to matter as this happens with Ubuntu, Windows, CentOS, etc, so this seems to be a problem with qemu-kvm.