Hide Forgot
Description of problem: guest's pty channel lose at least 50% data when use vport send data to host Version-Release number of selected component (if applicable): libvirt-0.9.4-23.el6.x86_64 kernel 2.6.32-215.el6.x86_64 How reproducible: 100% Steps to Reproduce: 1.Add the following XML into<devices> tag for a domain: <controller type='virtio-serial' index='0'/> <channel type='pty'> <target type='virtio' name='org.linux-kvm.port.1'/> </channel> 2.Start the guest, using "virsh dumpxml $domain-name" to determine the which pty the domain use, like the the example, the pty is /dev/pts/6 in the host. # virsh dumpxml rhel6 <channel type='pty'> <source path='/dev/pts/6'/> <target type='virtio' name='org.linux-kvm.port.1'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='0'/> </channel> 3. In the host to receive the data: # cat /dev/pts/6 In the guest, send data: # for i in {1..1000} ; do echo $i > /dev/vport0p0 ; sleep 1 ; done Actual results: There is more than 50% data lost Expected results: no data lost
Libvirt is not involved in the data transfer - it is purely QEMU level, so re-assigning the bug.
(In reply to comment #0) > Description of problem: > guest's pty channel lose at least 50% data when use vport send data to host > <channel type='pty'> > <source path='/dev/pts/6'/> > <target type='virtio' name='org.linux-kvm.port.1'/> > <alias name='channel0'/> > <address type='virtio-serial' controller='0' bus='0' port='0'/> > </channel> Why are you using port number 0? That is reserved for console usage. Use a number greater than 0 and let us know if it still reproduces.
(In reply to comment #3) > Why are you using port number 0? That is reserved for console usage. Use a > number greater than 0 and let us know if it still reproduces. I used port 1 and i tested for more than 10000 times.It passed. The xml is: <channel type='pty'> <source path='/dev/pts/3'/> <target type='virtio' name='org.linux-kvm.port.1'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> But i found a new problem: Scene 1(first echo, then cat): 1.reboot the host and guest make sure the environment is clean. 2.in guest run: # echo test1 > /dev/vport0p1 in host run: # cat /dev/pts/3 (you will get nothing) --->result is not expected 3.Ctrl+C to interrupt "cat" in Step 2 4.swap steps: in host run: # cat /dev/pts/3 in guest run: # echo test2 > /dev/vport0p1 in host you will get nothing --->result is not expected Scene 2(first cat, then echo): 1.reboot the host and guest make sure the environment is clean. 2.in host run: # cat /dev/pts/3 in guest run: # echo test1 > /dev/vport0p1 you can see "test1" in host 3.Ctrl+C to interrupt "cat" in Step 2 4.swap steps: in guest run: # echo test2 > /dev/vport0p1 in host run: # cat /dev/pts/3 you can see "test2" in host So, I think the step2 and step4 of scene1 should be ok like step4 of scene2.
Above comment 5 removed NEEDINFO.
(In reply to comment #5) > (In reply to comment #3) > > Why are you using port number 0? That is reserved for console usage. Use a > > number greater than 0 and let us know if it still reproduces. > > I used port 1 and i tested for more than 10000 times.It passed. > The xml is: > <channel type='pty'> > <source path='/dev/pts/3'/> > <target type='virtio' name='org.linux-kvm.port.1'/> > <alias name='channel0'/> > <address type='virtio-serial' controller='0' bus='0' port='1'/> > </channel> > > But i found a new problem: > > Scene 1(first echo, then cat): > 1.reboot the host and guest make sure the environment is clean. > 2.in guest run: > # echo test1 > /dev/vport0p1 > in host run: > # cat /dev/pts/3 (you will get nothing) --->result is not expected > 3.Ctrl+C to interrupt "cat" in Step 2 > 4.swap steps: > in host run: > # cat /dev/pts/3 > in guest run: > # echo test2 > /dev/vport0p1 > in host you will get nothing --->result is not expected > > Scene 2(first cat, then echo): > 1.reboot the host and guest make sure the environment is clean. > 2.in host run: > # cat /dev/pts/3 > in guest run: > # echo test1 > /dev/vport0p1 > you can see "test1" in host > 3.Ctrl+C to interrupt "cat" in Step 2 > 4.swap steps: > in guest run: > # echo test2 > /dev/vport0p1 > in host run: > # cat /dev/pts/3 > you can see "test2" in host > > So, I think the step2 and step4 of scene1 should be ok like step4 of scene2. BTW,I also have a try your scenario1 and scenario2 using 1 instead of 0.works well. -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=kvm. BTW,if you use kvm directly.if you boot guest with port o.guest can not be booted with the following messages.any mistake,please correct me. qemu-kvm: -device virtserialport,bus=virtio-serial0.0,nr=0,chardev=charchannel0,id=channel0,name=kvm: Port number 0 on virtio-serial devices reserved for virtconsole devices for backward compatibility. qemu-kvm: -device virtserialport,bus=virtio-serial0.0,nr=0,chardev=charchannel0,id=channel0,name=kvm: Device 'virtserialport' could not be initialized #/usr/libexec/qemu-kvm -M rhel6.2.0 -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name win7sp1-64 -uuid 5d371368-1570-4966-925f-6a58262e7df4 -nodefconfig -rtc base=localtime,driftfix=slew -no-shutdown -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x4 -drive file=/root/rhel6.2-64.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,serial=32-b475-8f3486219435,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,id=hostnet0,vhost=on -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:42:0b:27,bus=pci.0,addr=0x3 -chardev pty,id=charchannel0,path=/dev/pts/6 -device virtserialport,bus=virtio-serial0.0,nr=0,chardev=charchannel0,id=channel0,name=kvm -usb -device usb-tablet,id=input0 -vnc :10 -monitor stdio -smbios type=1,manufacturer="Dell Inc.111111",product="Precision T1600",version=0.1,serial=34W753X,uuid=4C4C4544-0034-5710-8037-B3C04F353358,sku="Not Specified",family="Not Specified" -boot menu=on char device redirected to /dev/pts/3 qemu-kvm: -device virtserialport,bus=virtio-serial0.0,nr=0,chardev=charchannel0,id=channel0,name=kvm: Port number 0 on virtio-serial devices reserved for virtconsole devices for backward compatibility. qemu-kvm: -device virtserialport,bus=virtio-serial0.0,nr=0,chardev=charchannel0,id=channel0,name=kvm: Device 'virtserialport' could not be initialized
(In reply to comment #7) > BTW,if you use kvm directly.if you boot guest with port o.guest can not be > booted with the following messages.any mistake,please correct me. > qemu-kvm: -device > virtserialport,bus=virtio-serial0.0,nr=0,chardev=charchannel0,id=channel0,name=kvm: > Port number 0 on virtio-serial devices reserved for virtconsole devices for > backward compatibility. That's right, we made sure in recent versions of qemu-kvm that such mistakes of using port 0 with serial ports are not made. That was done in bug 700511.
(In reply to comment #5) > (In reply to comment #3) > > Why are you using port number 0? That is reserved for console usage. Use a > > number greater than 0 and let us know if it still reproduces. > > I used port 1 and i tested for more than 10000 times.It passed. Good. > But i found a new problem: [snip] > So, I think the step2 and step4 of scene1 should be ok like step4 of scene2. As Junyi suggested, can you try the same with a different backend, instead of pty? Are you sure no other process is using the pty channels you are using? It would be best to test with unix or tcp sockets.
I test unix socket with comment #5 's step. Whatever echo or cat first , it works well.
(In reply to comment #10) > I test unix socket with comment #5 's step. > Whatever echo or cat first , it works well. Thanks; perhaps the pty was being used by some other host process in the first case.