Bug 1460099 - Transferring data via spapr-vty from host to guest was abnormal
Transferring data via spapr-vty from host to guest was abnormal
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.4
ppc64le Unspecified
low Severity low
: rc
: ---
Assigned To: David Gibson
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-09 02:26 EDT by Min Deng
Modified: 2017-06-13 04:34 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-13 04:34:21 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Min Deng 2017-06-09 02:26:49 EDT
Description of problem:
Transferring data via spapr-vty was abnormal from host to guest.

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.9.0-9.el7.ppc64le
kernel-3.10.0-675.el7.ppc64le
SLOF-20170303-4.git66d250e.el7.noarch

How reproducible:
4 times

Steps to Reproduce:
1.boot up guest with 
  "/usr/libexec/qemu-kvm -name avocado-vt-vm1 -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1,server,nowait -mon chardev=qmp_id_qmpmonitor1,mode=control -sandbox on -machine pseries-rhel7.4.0 -nodefaults -vga std -chardev socket,id=serial_id_serial0,host=127.0.0.1,port=12345,server,nowait -device spapr-vty,chardev=serial_id_serial0 -device nec-usb-xhci,id=usb1,bus=pci.0,addr=0x3 -device usb-kbd,id=input0 -device usb-mouse,id=input1 -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=rhel74-ppc64-virtio-scsi.qcow2 -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x4 -device spapr-vlan,mac=9a:93:94:95:96:97,id=idpWdRJ9,netdev=idkTBKmY -netdev tap,id=idkTBKmY,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-down,id=hostnet1 -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x6 -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=4 -vnc :11 -rtc base=utc,clock=host -boot order=cdn,once=d,menu=off,strict=off -enable-kvm -monitor stdio -monitor unix:/tmp/monitor3,server,nowait -qmp tcp:0:4444,server,nowait -m 8G,slots=32,maxmem=80G -realtime mlock=on"

2.Log in guest and did listener 
 #cat /dev/hvc0

3.Send data from host to guest
echo "helloworldsdkfjskldfjskldfjlsdkfjlsdkjfsldkfjskldjfslkdjflksdjfl787897897979797912312312" |nc 127.0.0.1 12345   - listener cannot get the data in guest
echo "helloworldsdkfjskldfjskldfjlsdkfjlsdkjfsldkfjskldjfslkdjflksdjfl787897897979797912312312" |nc 127.0.0.1 12345   - listener get the data finally in guest

Actual results:
Only send the data twice or more than that from host to guest,the listener side can get the data.

Expected results:
The data can be sent to guest successfully according to *current test plan* just once.

Additional info:
TCP&UNIX option of socket can help to reproduce the issue.
Comment 2 Laurent Vivier 2017-06-12 09:29:22 EDT
I think you should check no one is already using the port with something like:

    lsof|grep /dev/hvc0

as /dev/hvc0 is normally used by agetty to manage serial console login.
Comment 3 Laurent Vivier 2017-06-12 10:12:42 EDT
If needed, you can stop the daemon with:

    systemctl stop serial-getty@hvc0.service
Comment 4 Min Deng 2017-06-13 03:47:21 EDT
Tried the bug with the following cli,
CLI,/usr/libexec/qemu-kvm -name avocado-vt-vm1 -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1,server,nowait -mon chardev=qmp_id_qmpmonitor1,mode=control -sandbox on -machine pseries-rhel7.4.0 -nodefaults -vga std -chardev socket,id=serial_id_serial0,host=127.0.0.1,port=12345,server,nowait -device spapr-vty,chardev=serial_id_serial0 -device nec-usb-xhci,id=usb1,bus=pci.0,addr=0x3 -device usb-kbd,id=input0 -device usb-mouse,id=input1 -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=rhel74-ppc64-virtio-scsi.qcow2 -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x4 -device spapr-vlan,mac=9a:93:94:95:96:97,id=idpWdRJ9,netdev=idkTBKmY -netdev tap,id=idkTBKmY,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-down,id=hostnet1 -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x6 -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=4 -vnc :11 -rtc base=utc,clock=host -boot order=cdn,once=d,menu=off,strict=off -enable-kvm -monitor stdio -monitor unix:/tmp/monitor3,server,nowait -qmp tcp:0:4444,server,nowait -m 8G,slots=32,maxmem=80G -realtime mlock=on -chardev socket,id=serial_id_serial1,host=127.0.0.1,port=12346,server,nowait -device spapr-vty,chardev=serial_id_serial1

In total,there are two spapr-vty within the guests in order to make a contrast.
for the first,according to comment 2,stop the service it works well,so the transferring was influenced by serial-getty demon.
for the second,it still works well.
Comment 5 David Gibson 2017-06-13 04:34:21 EDT
Looks like expected behaviour.

Good catch, Thomas.

A similar problem would exist on x86 if transferring over a serial port which is in use by a getty process.

Note You need to log in before you can comment on or make changes to this bug.