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.
Stopping a guest, especially for a long time does not make sense. Watchdogs and timeout will eventually expire when the "hardware" is dead.
Still, the test is interesting, since we can sometimes harden the system.
For now, deferring to 7.1
Try to reproduce this issue on virtio-win-1.6.7-2.el7.noarch and virtio-win-prewhql-111
Steps as comment#0
Actual result:
guest network works well(even stop the guest the more than 12h) and can ping $host_ip correctly.
Version-Release number of selected component (if applicable):
virtio-win-1.6.7-2.el7.noarch/ virtio-win-prewhql-111
qemu-kvm-rhev-2.3.0-31.el7.x86_64
kernel-3.10.0-327.el7.x86_64
Description of problem: win8.1 guest network can not resume automatically after stop via HMP for more than 20 minutes. Version-Release number of selected component (if applicable): # rpm -qa|grep virtio && rpm -qa|grep qemu-kvm virtio-win-1.6.7-2.el7.noarch qemu-kvm-rhev-1.5.3-13.el7.x86_64 3.10.0-42.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.Boot guest with virtio-net-pci. # /usr/libexec/qemu-kvm -S -M pc-i440fx-rhel7.0.SandyBridge -enable-kvm -m 4G -smp 4,sockets=2,cores=2,threads=1 -name juli -uuid 355a2475-4e03-4cdd-bf7b-5d6a59edaa68 -rtc base=localtime,clock=host,driftfix=slew -device virtio-scsi-pci,bus=pci.0,id=scsi0 \ -drive file=gluster://10.66.4.216:24007/gv0/win8.1-juli.raw,if=none,id=drive-scsi0-0-0,media=disk,cache=none,format=raw,werror=stop,rerror=stop,aio=native,discard=on -device scsi-hd,drive=drive-scsi0-0-0,bus=scsi0.0,scsi-id=0,lun=0,id=juli,bootindex=0 \ -drive file=/home/ISO/en_windows_8.1_preview_x86_dvd_2358833.iso,if=none,media=cdrom,format=raw,aio=native,id=drive-ide1-0-0 -device ide-drive,drive=drive-ide1-0-0,id=ide1-0-0,bus=ide.0,unit=0,bootindex=4 \ -device virtio-balloon-pci,id=ballooning -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 \ -netdev tap,id=tap1,vhost=on,queues=4,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -device virtio-net-pci,netdev=tap1,id=nic1,mq=on,vectors=17,status=off,mac=1a:59:0a:4b:5b:94 \ -k en-us -boot menu=on,reboot-timeout=-1,strict=on -qmp tcp:0:4455,server,nowait -serial unix:/tmp/ttyS0,server,nowait -vnc :1 -spice port=5931,disable-ticketing -vga qxl -monitor stdio -monitor tcp:0:7455,server,nowait -monitor unix:/tmp/monitor1,server,nowait -drive file=/usr/share/virtio-win/virtio-win-1.6.7.iso,if=none,media=cdrom,format=raw,aio=native,id=drive-ide1-0-2 -device ide-drive,drive=drive-ide1-0-2,id=ide1-0-2,bus=ide.0,unit=1 2.Run netperf TCP_STREAM protocol test in guest. # netperf -H 10.66.106.4 -l 600 -- -b 10 -D 3.During run netperf, do stop via HMP. (qemu)stop 4.After stop 20 minutes, run "cont" inside HMP. (qemu)cont 5.Check the guest network. Actual results: after step 5, guest network failed. C:\Users\andrew>ping 10.66.106.4 Pinging 10.66.106.4 with 32 bytes of data: PING: transmit failed. General failure. PING: transmit failed. General failure. PING: transmit failed. General failure. PING: transmit failed. General failure. Ping statistics for 10.66.106.4: Packets: Sent = 4, Received = 0, Lost = 4 <100% loss> Expected results: after step 5, guest network will works well. Can ping $host_ip correctly. Additional info: After step 5, wait for more than 5 minutes, guest network failed still. Network will works well after disable/enable guest physical network card of the guest.