Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
Firstly,hot-unplug virtio serial pci from guest and then hot-plug virtio-serial-pci and ports again.All operation are permitted at least there wasn't any alert message.
Version-Release number of selected component (if applicable):
kernel-3.10.0-53.el7.x86_64
qemu-kvm-rhev-1.5.3-19.el7.x86_64
virtio-win 1.6.7-2
How reproducible:
4 times
Steps to Reproduce:
1.boot up guest
/usr/libexec/qemu-kvm -M pc -cpu host -enable-kvm -m 4G -smp 2 -name win2k8-64-nerkvm -rtc base=localtime,clock=host,driftfix=slew -uuid 816c2e3d-e84f-4de9-b919-7d1cfd226b6d -monitor stdio -drive file=win8-32.qcow3,if=none,id=drive-data-disk2,format=qcow2,cache=none,werror=stop,rerror=stop -device virtio-blk-pci,drive=drive-data-disk2,id=systemos -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -netdev tap,sndbuf=0,id=hostnet0,script=/etc/qemu-ifup,downscript=no -device e1000,netdev=hostnet0,mac=00:32:52:41:31:31,id=net1 -cdrom /usr/share/virtio-win/virtio-win-1.6.7.iso -vga cirrus -chardev socket,id=abc,path=/tmp/monitor-win8-64-scsi-73,server,nowait -mon chardev=abc,mode=readline -device virtio-serial-pci,id=virtio-serial0,max_ports=16 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm2,bus=virtio-serial0.0,id=port2 -device virtio-balloon-pci,id=balloon0 -vnc :1
2.execute transfer scripts
1st :data was from host to guest
2nd :data was from guest to host
3.device_del virtio-serial0
4.check info qtree,it removed successfully.
5.
device_add virtio-serial-pci,id=virtio-serial0,max_ports=31
device_add virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1
device_add virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm2,bus=virtio-serial0.0,id=port2
Actual results:The ports didn't work any more even if rebooting guest
Expected results:The ports still work or don't allow such operation.
Additional info:
Please explain what does it mean when you write "ports didn't work"?
1. Is it exist in the qtree?
2. Is the port exists inside the Window guest?
3. Data it not received from the host? (bz#1027181)?
(In reply to Gal Hammer from comment #1)
> Please explain what does it mean when you write "ports didn't work"?
>
> 1. Is it exist in the qtree?
> 2. Is the port exists inside the Window guest?
> 3. Data it not received from the host? (bz#1027181)?
For 3,the data could not transfer any longer via those ports.
(In reply to dengmin from comment #2)
> (In reply to Gal Hammer from comment #1)
> > Please explain what does it mean when you write "ports didn't work"?
> >
> > 1. Is it exist in the qtree?
> > 2. Is the port exists inside the Window guest?
> > 3. Data it not received from the host? (bz#1027181)?
> For 3,the data could not transfer any longer via those ports.
Both guest-to-host and host-to-guest?
(In reply to Gal Hammer from comment #3)
> (In reply to dengmin from comment #2)
> > (In reply to Gal Hammer from comment #1)
> > > Please explain what does it mean when you write "ports didn't work"?
> > >
> > > 1. Is it exist in the qtree?
> > > 2. Is the port exists inside the Window guest?
> > > 3. Data it not received from the host? (bz#1027181)?
> > For 3,the data could not transfer any longer via those ports.
>
> Both guest-to-host and host-to-guest?
For 1,it existed in qtree after re-hotplug.
For 2,yes,the ports were found inside guest.
Both guest-to-host and host-to-guest cannot work.it still didn't work even if rebooting guest.
win2k8r2 hit the same issue when run transfer scripts as following,ports don't work after re-hotplug:
for ((i=1;i<=1000;i++));
do
python serial-host-receive.py /tmp/helloworld1;
done
But both ports work well if I add "sleep 1" in the transfer scripts as:
for ((i=1;i<=1000;i++));
do
python serial-host-receive.py /tmp/helloworld2;
sleep 1;
done
I'm unable to reproduce with build 122, windows 8.1 and qemu 2.6.
Can you please re-test it and see if you can reproduce it with current/updated components versions? Thanks.
(In reply to lijin from comment #22)
> Hi damchen,
>
> Could you please help to handle comment#21?
I have re-test it. The problem is not to reproduce with build 122, windows 8.1 and qemu 2.6.
(In reply to damchen from comment #23)
>
> (In reply to lijin from comment #22)
> > Hi damchen,
> >
> > Could you please help to handle comment#21?
>
> I have re-test it. The problem is not to reproduce with build 122, windows
> 8.1 and qemu 2.6.
Thanks for the confirmation.