RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 702611 - Some files were not integrated after transferring four files from host to guest
Summary: Some files were not integrated after transferring four files from host to guest
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.1
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 6.2
Assignee: Amit Shah
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 712015 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-06 10:56 UTC by Min Deng
Modified: 2013-05-24 11:20 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-24 11:20:30 UTC
Target Upstream Version:
Embargoed:
xfu: needinfo-

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 909059 0 medium CLOSED Switch to upstream solution for chardev flow control 2021-02-22 00:41:40 UTC

Internal Links: 909059

Description Min Deng 2011-05-06 10:56:08 UTC 
Description of problem:
Some files were not integrated after transferring four files from Host to guest

Version-Release number of selected component (if applicable):
kvm version -
0.12.1.2-2.159.el6

Guests
rhel 5.7 32 bits with kernel 2.6.18-259.el5

How reproducible:
Steps to Reproduce:
1.boot guest with the following command
  /usr/libexec/qemu-kvm -m 2G -smp 6 -drive file=/home/rhel6.1-64.qcow2,media=disk,if=none,id=drive-virtio0-0-0,format=qcow2,werror=stop,rerror=stop,cache=none -device virtio-blk-pci,drive=drive-virtio0-0-0,id=virti0-0-0 -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:94:a3:8b -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=4,bus=pci.0 -chardev socket,id=channel0,path=/var/lib/libvirt/qemu/rhel6.channel0,server,nowait -device virtserialport,chardev=channel0,name=org.linux-kvm.port.0,bus=virtio-serial0.0,id=port0 -chardev socket,id=channel1,path=/var/lib/libvirt/qemu/rhel6.channel1,server,nowait  -device virtserialport,chardev=channel1,name=org.linux-kvm.port.1,bus=virtio-serial0.0,id=port1 -device virtio-serial-pci,id=virtio-serial1,max_ports=16,vectors=4,bus=pci.0 -chardev socket,id=channel2,path=/var/lib/libvirt/qemu/rhel6.channel2,server,nowait -device virtserialport,chardev=channel2,name=org.linux-kvm.port.2,bus=virtio-serial1.0,id=port2 -chardev socket,id=channel3,path=/var/lib/libvirt/qemu/rhel6.channel3,server,nowait -device virtserialport,chardev=channel3,name=org.linux-kvm.port.3,bus=virtio-serial1.0,id=port3 -vnc :3 -monitor stdio
2.please prepare four large files with the same size on host (1G) and transfer them to guest
  #cat p1 | nc -U /var/lib/libvirt/qemu/rhel6.channel0
  #cat p2 | nc -U /var/lib/libvirt/qemu/rhel6.channel1
  #cat p3 | nc -U /var/lib/libvirt/qemu/rhel6.channel2
  #cat p4 | nc -U /var/lib/libvirt/qemu/rhel6.channel3
  
  From Guest side, 
  
  #cat /dev/vport0p1 >/home/1
  #cat /dev/vport0p2 >/home/2
  #cat /dev/vport1p1 >/home/3
  #cat /dev/vport1p2 >/home/4


Actual results:
 It seemed that the four files were transferred successfully but after checking the their sizes,we will find that their size became smaller.perhaps,you will get different results every time, but you will never transfer the four files together successfully.

Expected results:
The four files can be transferred together and their sizes are the same with the original.


Additional info:
Not reproduce the issue while transferring single file.
Comment 1 Min Deng 2011-05-09 03:37:03 UTC 
Re-test it on 6.1 guest

Check files via MD5 

Results from host -
[root@dengmin-amd qemu]# md5sum p1
2a2db9cd91620aa69a38a2e922897a12  p1
[root@dengmin-amd qemu]# md5sum p2
2a2db9cd91620aa69a38a2e922897a12  p2
[root@dengmin-amd qemu]# md5sum p3
2a2db9cd91620aa69a38a2e922897a12  p3
[root@dengmin-amd qemu]# md5sum p4
2a2db9cd91620aa69a38a2e922897a12  p4

Results from guest
[root@dhcp-66-83-158 Desktop]# md5sum 1
2a2db9cd91620aa69a38a2e922897a12  1
[root@dhcp-66-83-158 Desktop]# md5sum 2
d41d8cd98f00b204e9800998ecf8427e  2
[root@dhcp-66-83-158 Desktop]# md5sum 3
2a2db9cd91620aa69a38a2e922897a12  3
[root@dhcp-66-83-158 Desktop]# md5sum 4
2a2db9cd91620aa69a38a2e922897a12  4
Comment 2 Min Deng 2011-05-09 03:38:51 UTC 
6.1 guest info
uname -a
2.6.32-128.el6.x86_64
Comment 5 Don Dutile (Red Hat) 2011-06-08 04:50:33 UTC 
pls retest & report back results with final 6.1 kernel & -160 qemu-kvm.
Comment 6 FuXiangChun 2011-06-08 07:49:39 UTC 
(In reply to comment #5)
> pls retest & report back results with final 6.1 kernel & -160 qemu-kvm.

can not reproduce this bug in final 6.1 kernel & -160 qemu-kvm. below four files were transfered successfully

test steps:

1. host info
  # uname -r
  2.6.32-131.0.15.el6.x86_64
  #rpm -qa|grep kvm
  qemu-kvm-0.12.1.2-2.160.el6.x86_64

2. start vm with below command line
/usr/libexec/qemu-kvm -m 2G -smp 6 -drive file=rhel57-2.qcow2,media=disk,if=none,id=drive-virtio0-0-0,format=qcow2,werror=stop,rerror=stop,cache=none -device virtio-blk-pci,drive=drive-virtio0-0-0,id=virti0-0-0 -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:94:a3:8b -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=4,bus=pci.0 -chardev socket,id=channel0,path=/var/lib/libvirt/qemu/rhel6.channel0,server,nowait -device virtserialport,chardev=channel0,name=org.linux-kvm.port.0,bus=virtio-serial0.0,id=port0 -chardev socket,id=channel1,path=/var/lib/libvirt/qemu/rhel6.channel1,server,nowait -device virtserialport,chardev=channel1,name=org.linux-kvm.port.1,bus=virtio-serial0.0,id=port1 -device virtio-serial-pci,id=virtio-serial1,max_ports=16,vectors=4,bus=pci.0 -chardev socket,id=channel2,path=/var/lib/libvirt/qemu/rhel6.channel2,server,nowait -device virtserialport,chardev=channel2,name=org.linux-kvm.port.2,bus=virtio-serial1.0,id=port2 -chardev socket,id=channel3,path=/var/lib/libvirt/qemu/rhel6.channel3,server,nowait -device virtserialport,chardev=channel3,name=org.linux-kvm.port.3,bus=virtio-serial1.0,id=port3 -vnc :3 -monitor stdio

3. copy four files each file size is 1.9G
    
prepare four files with the same size on host (1.9G) and use below script to transfer concurrently them to guest

cat transfiles.sh 
cat data1 | nc -U /var/lib/libvirt/qemu/rhel6.channel0 &
cat data2 | nc -U /var/lib/libvirt/qemu/rhel6.channel1 &
cat data3 | nc -U /var/lib/libvirt/qemu/rhel6.channel2 &
cat data4 | nc -U /var/lib/libvirt/qemu/rhel6.channel3 &

4. guest receive data1...data4 from host with below script

 # cat receive.sh

cat /dev/vport0p1 >/root/data1 &
cat /dev/vport0p2 >/root/data2 &
cat /dev/vport1p1 >/root/data3 &
cat /dev/vport1p2 >/root/data4 &

5. use md5sum command to verified guest received data1...data4
Comment 7 FuXiangChun 2011-06-08 08:09:03 UTC 
additional info: 
i transferred 3 times from host to guest with above steps. each time four files were transferred successfully.
Comment 8 Amit Shah 2011-06-08 11:25:00 UTC 
Thanks for re-testing.
Comment 9 Sibiao Luo 2011-07-28 05:17:02 UTC 
Tried both qemu-kvm-0.12.1.2-2.172.el6.x86_64 and
qemu-kvm-0.12.1.2-2.172.el6.bz677886.x86_64, all of them can reproduce this
issue.

steps:
1.start vm with below command line
# /usr/libexec/qemu-kvm -m 2G -smp 6 -drive file=/home/RHEL-Server-5.7-64.qcow2,media=disk,if=none,id=drive-virtio0-0-0,format=qcow2,werror=stop,rerror=stop,cache=none -device virtio-blk-pci,drive=drive-virtio0-0-0,id=virti0-0-0 -netdev tap,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:94:65:17 -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=4,bus=pci.0 -chardev socket,id=channel0,path=/var/lib/libvirt/qemu/rhel6.channel0,server,nowait -device virtserialport,chardev=channel0,name=org.linux-kvm.port.0,bus=virtio-serial0.0,id=port0 -chardev socket,id=channel1,path=/var/lib/libvirt/qemu/rhel6.channel1,server,nowait -device virtserialport,chardev=channel1,name=org.linux-kvm.port.1,bus=virtio-serial0.0,id=port1 -device virtio-serial-pci,id=virtio-serial1,max_ports=16,vectors=4,bus=pci.0 -chardev socket,id=channel2,path=/var/lib/libvirt/qemu/rhel6.channel2,server,nowait -device virtserialport,chardev=channel2,name=org.linux-kvm.port.2,bus=virtio-serial1.0,id=port2 -chardev socket,id=channel3,path=/var/lib/libvirt/qemu/rhel6.channel3,server,nowait -device virtserialport,chardev=channel3,name=org.linux-kvm.port.3,bus=virtio-serial1.0,id=port3 -vnc :88 -monitor stdio

2.copy four files each file size is 1.1G
prepare four files with the same size (1.1G) on host and use below script to
transfer concurrently them to guest

# cat transfiles.sh
cat /home/test1 | nc -U /var/lib/libvirt/qemu/rhel6.channel0 &
cat /home/test2 | nc -U /var/lib/libvirt/qemu/rhel6.channel1 &
cat /home/test3 | nc -U /var/lib/libvirt/qemu/rhel6.channel2 &
cat /home/test4 | nc -U /var/lib/libvirt/qemu/rhel6.channel3 &

3.guest receive data1...data4 from host with below script

# cat receive.sh 
cat /dev/vport0p1 > /home/data1 &
cat /dev/vport0p2 > /home/data2 &
cat /dev/vport1p1 > /home/data3 &
cat /dev/vport1p2 > /home/data4 &

4.use md5sum and cksum commands to verified guest received data1...data4


Actual results:
the four files were transferred successfully but after checking
the their sizes,we will find that their size became smaller.
both qemu-kvm-0.12.1.2-2.172.el6.x86_64 and
qemu-kvm-0.12.1.2-2.172.el6.bz677886.x86_64 can reproduce this issue.
Comment 10 Mike Cao 2011-08-01 03:07:50 UTC 
Base on comment #9 ,reopen this bug 
BTW ,QE also tried -device virtio-serial-pci flow_control=0

Also hit the issue.
Comment 11 Amit Shah 2011-09-02 13:50:55 UTC 
I'll try again to reproduce this.  While starting his chardev rewrite, Anthony mentoined some race in the existing flow control patches but since this was reproduced even with the ',flow_control=0' parameter, doesn't look like it's related to flow control.
Comment 13 Mike Cao 2011-12-26 09:16:06 UTC 
*** Bug 712015 has been marked as a duplicate of this bug. ***
Comment 16 Amit Shah 2013-05-21 12:53:48 UTC 
Chardevs changed a lot in RHEL6.5.  Can you try this again on the latest qemu build?
Comment 17 Min Deng 2013-05-24 10:19:04 UTC 
(In reply to Amit Shah from comment #16)
> Chardevs changed a lot in RHEL6.5.  Can you try this again on the latest
> qemu build?

Hi Amit,
   I re-test the bug via the following packages
   qemu-kvm-0.12.1.2-2.370.el6.x86_64
   kernel-2.6.32-381.el6.x86_64
   I didn't hit the issue any more,both original file on host and target files on guest have the same md5 size.(every file is more than 1G). Any issues please let me know.thanks.

Best Regards,
Min
Comment 18 Amit Shah 2013-05-24 11:20:30 UTC 
Thanks a lot, and it's a big relief!

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