| Summary: | [virtio-win][netkvm]win8.1 guest network can not resume automatically after stop for a long time | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jun Li <juli> |
| Component: | virtio-win | Assignee: | Vlad Yasevich <vyasevic> |
| Status: | CLOSED WORKSFORME | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 7.0 | CC: | dfleytma, ghammer, hhuang, jasowang, juzhang, knoel, lijin, michen, mst, qiguo, rbalakri, virt-maint, vyasevic, wyu, xfu |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-12-07 15:10:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
Probably need to eject disconnect\connect of a network link so the described behaviour will work. 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 deferring to 7.3. 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 Can we close this bug as QE cannot reproduce this issue with the old and latest netkvm driver? Sure. Closing the bug as not reproducible. |
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.