1) start /usr/libexec/qemu-kvm -drive if=none,id=hd,file=$HOME/f25-64.qcow2 -device virtio-blk,drive=hd -m 256 --enable-kvm -serial pty -monitor stdio

2) start cat for pty opened by first QEMU instance, e.g. "cat /dev/pts/5" if it prints
     char device redirected to /dev/pts/5 (label serial0)

3) start /usr/libexec/qemu-kvm -drive if=none,id=hd,file=$HOME/f25-64.qcow2 -device virtio-blk,drive=hd -m 256 --enable-kvm -serial pty -monitor stdio -incoming tcp:localhost:12345

4) start cat for pty opened by second QEMU instance

6) type "yes > /dev/ttyS0", endless stream of "y" comes out of cat instance #1

7) type ^Z to stop cat instance #1

8) start migration:
      migrate_set_speed 1G
      migrate tcp:localhost:12345

9) endless stream of "y" should come out of cat instance #2

Thanks for Paolo's comment, refer to your comment, now I can reproduce this bug as following:
Bug reproduction:
Host:
3.10.0-671.el7.x86_64
qemu-kvm-rhev-2.9.0-8.el7.x86_64

3.10.0-648.el7.x86_64

steps:
1)On src host,boot a guest as following qemu cli:
/usr/libexec/qemu-kvm \
    -name 'vm1'  \
    -sandbox off  \
    -machine pc-i440fx-rhel7.4.0 \
    -nodefaults  \
    -device virtio-serial-pci,id=virtio_serial_pci0,bus=pci.0,addr=04 \
    -chardev socket,path=/tmp/virtio_port-vs-20170207-030401-FfusAC1v,nowait,id=idQdLRHP,server \
    -device virtserialport,id=idBu8FQH,name=vs,bus=virtio_serial_pci0.0,chardev=idQdLRHP \
    -device nec-usb-xhci,id=usb1,bus=pci.0,addr=06 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=09 \
    -drive id=drive_image1,if=none,snapshot=off,aio=threads,cache=none,format=qcow2,file=/root/rhel74-64-virtio.qcow2 \
    -device virtio-blk-pci,id=image1,drive=drive_image1,bus=pci.0,bootindex=0 \
    -device virtio-net-pci,mac=9a:4f:50:51:52:53,id=id9HRc5V,vectors=4,netdev=idjlQN53,bus=pci.0  \
    -netdev tap,id=idjlQN53,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
    -m 4096 \
    -smp 4,maxcpus=4,cores=2,threads=1,sockets=2 \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -device usb-mouse,id=input1,bus=usb1.0,port=2 \
    -device usb-kbd,id=input2,bus=usb1.0,port=3 \
    -serial pty \
    -vnc :1 \
    -incoming tcp:0:5801 \
    -qmp tcp:0:8881,server,nowait \
    -vga std \
    -monitor stdio \
    -rtc base=utc,clock=host  \
    -boot order=cdn,once=c,menu=on,strict=off  \
    -enable-kvm  \
[root@dhcp-10-122 ~]# sh boot.sh 
QEMU 2.9.0 monitor - type 'help' for more information
(qemu) qemu-kvm: -serial pty: char device redirected to /dev/pts/1 (label serial0)
2)on src host,start cat for pty opened by src host QEMU instance:
[root@dhcp-10-122 ~]# cat /dev/pts/1

3)On dst host, launch listening mode, the qemu cli is same with above appending "incoming tcp:0:5801" 
[root@dhcp-10-208 ~]# sh boot.sh 
QEMU 2.9.0 monitor - type 'help' for more information
(qemu) qemu-kvm: -serial pty: char device redirected to /dev/pts/4 (label serial0)
4)On dst host, start cat for pty opened by dst host QEMU instance:
[root@dhcp-10-208 ~]# cat /dev/pts/4

5)In guest, type "yes > /dev/ttyS0",endless stream of "y" comes out of cat instance on src host;
6)On src host, do migration
(qemu) migrate -d tcp:10.66.10.208:5801
7)After migration completed, "y" stopped coming out of on src host, and endless stream of "y" changes to comes out of cat instance on dst host
in src host cat instance:
y
y
ycat: /dev/pts/4: Input/output error
in dst host cat instance:
y
y
y
y
...

Note that you tested qemu-kvm-rhev, the bug is fixed there.

On qemu-kvm, you'll see no "y" on the destination host unless you have the patch.

Needs v2.

Fix included in qemu-kvm-1.5.3-141.el7

This bug is verified pass for qemu-kvm-1.5.3-141.el7.x86_64
Bug verify:
Host:
3.10.0-679.el7.x86_64
qemu-kvm-1.5.3-141.el7.x86_64

Guest:
3.10.0-679.el7.x86_64

steps:
1)On src host,boot a guest as following qemu cli:
/usr/libexec/qemu-kvm \
    -name 'avocado-vt-vm1'  \
    -sandbox off  \
    -machine pc  \
    -nodefaults  \
    -vga std  \
    -device virtio-serial-pci,id=virtio_serial_pci0,bus=pci.0,addr=03 \
    -device nec-usb-xhci,id=usb1,bus=pci.0 \
    -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=05 \
    -drive id=drive_image1,if=none,snapshot=off,format=qcow2,snapshot=off,file=/root/rhel74-64-virtio-scsi.qcow2 \
    -device scsi-hd,id=image1,drive=drive_image1,bus=virtio_scsi_pci0.0 \
    -device virtio-net-pci,mac=9a:7b:7c:7d:7e:72,id=id9HRc5V,vectors=4,netdev=idjlQN53,bus=pci.0,addr=10 \
    -netdev tap,id=idjlQN53,vhost=off,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \
    -m 4G  \
    -smp 4  \
    -name debug-threads=on \
    -serial pty \
    -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1  \
    -device usb-kbd,bus=usb1.0,port=2 \
    -device usb-mouse,bus=usb1.0,port=3 \
    -vnc :1 \
    -incoming tcp:0:5801 \
    -rtc base=localtime,clock=vm,driftfix=slew  \
    -boot order=cdn,once=c,menu=off,strict=off \
    -monitor stdio \
    -enable-kvm
[root@dhcp-10-122 ~]# sh boot_linux.sh 
QEMU 1.5.3 monitor - type 'help' for more information
(qemu) char device redirected to /dev/pts/2 (label serial0)

2)on src host,start cat for pty opened by src host QEMU instance:
[root@dhcp-10-122 ~]# cat /dev/pts/2

3)On dst host, launch listening mode, the qemu cli is same with above appending "incoming tcp:0:5801" 
[root@dhcp-10-208 ~]# sh boot_linux.sh 
QEMU 1.5.3 monitor - type 'help' for more information
(qemu) char device redirected to /dev/pts/3 (label serial0)

4)On dst host, start cat for pty opened by dst host QEMU instance:
[root@dhcp-10-208 ~]# cat /dev/pts/3

5)In guest, type "yes > /dev/ttyS0",endless stream of "y" comes out of cat instance on src host;
6)On src host, do migration
(qemu) migrate -d tcp:10.66.10.208:5801
7)After migration completed, "y" stopped coming out of on src host, and endless stream of "y" changes to comes out of cat instance on dst host
in src host cat instance:
y
y
y


in dst host cat instance:
y
y
y
y
...

So, this bug is verified pass for qemu-kvm-1.5.3-141.el7.x86_64

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:1856