Bug 1100656
| Summary: | guest network can not resume after stop 3 minutes via hmp when vhost is off | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jun Li <juli> |
| Component: | qemu-kvm | Assignee: | jason wang <jasowang> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.0 | CC: | hhuang, huding, jasowang, juzhang, knoel, michen, mst, qiguo, qzhang, rbalakri, virt-bugs, virt-maint, 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-08-11 03:28:31 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: | |
| Embargoed: | |||
|
Comment 2
Jun Li
2014-05-26 06:50:22 UTC
(In reply to Jun Li from comment #2) > Update command line in comment0 step 1. > # /usr/libexec/qemu-kvm -m 2G -cpu host -smp 2 -qmp tcp::5555,server,nowait > -monitor stdio -M pc -spice port=5931,disable-ticketing -drive > file=/home/RHEL-Server-6.6-32.qcow2,if=none,id=img -device > virtio-blk-pci,drive=img,id=sys-img -device > virtio-net-pci,ctrl_mac_addr=on,netdev=dev1,vectors=10,mq=on,mac=04:7d:7b:fc: > 99:66,id=net1 11<>/dev/tap11 12<>/dev/tap11 13<>/dev/tap11 14<>/dev/tap11 > -netdev tap,id=dev1,vhost=on,fds=11:12:13:14 Please ignore comment #2. The correctly command line in comment #0 is as followings: # /usr/libexec/qemu-kvm -m 2G -cpu host -smp 2 -qmp tcp::5555,server,nowait -monitor stdio -M pc -spice port=5931,disable-ticketing -drive file=/home/RHEL-Server-6.6-32.qcow2,if=none,id=img -device virtio-blk-pci,drive=img,id=sys-img -device virtio-net-pci,ctrl_mac_addr=on,netdev=dev1,vectors=10,mq=on,mac=04:7d:7b:fc:99:66,id=net1 11<>/dev/tap11 12<>/dev/tap11 13<>/dev/tap11 14<>/dev/tap11 -netdev tap,id=dev1,vhost=off,fds=11:12:13:14 ---- Do more test with the same command line(as above show) as followings: 1, Retest with rhel7 guest, hit this issue, too. 2, Test with vhost=on, no this issue. 3, Test with qemu-kvm-1.5.3-40.el7.x86_64, hit this issue, too. --- Based on above testing, in one word, this issue related with vhost=off, this issue exists on qemu-kvm-1.5.3-40.el7.x86_64, too. So it is not a regression bz. Any further testing needed, free to update it in the bz. Best Regards, Jun Li Since we usually run with vhost=on, and stopping for 3 minutes is not a production scenario, "cond nack capacity" for now. mst, do we support such case? I am surprised that the guest did not fire watchdogs due to "non-responsive hardware". Jun, can you recover guest network by restarting network? (In reply to Amos Kong from comment #7) > Jun, can you recover guest network by restarting network? Retest this bz. Version of components: qemu-kvm-rhev-2.1.2-13.el7.x86_64 cli: # /usr/libexec/qemu-kvm -m 2G -cpu host -smp 2 -qmp tcp::5555,server,nowait -monitor stdio -M pc -spice port=5931,disable-ticketing -drive file=/media/linux_img/RHEL-Server-6.6-32-virtio.qcow2,if=none,id=img,snapshot=on -device virtio-blk-pci,drive=img,id=sys-img -device virtio-net-pci,ctrl_mac_addr=on,netdev=dev1,vectors=10,mq=on,mac=22:54:08:62:94:89,id=net1 11<>/dev/tap5 12<>/dev/tap6 13<>/dev/tap7 14<>/dev/tap8 -netdev tap,id=dev1,vhost=off,fds=11:12:13:14 steps as comment 0, after step 5, guest network works well. Can be accessed successfully. No hit this issue. (In reply to Jun Li from comment #8) > (In reply to Amos Kong from comment #7) > > Jun, can you recover guest network by restarting network? > > Retest this bz. > > Version of components: > qemu-kvm-rhev-2.1.2-13.el7.x86_64 > > cli: > # /usr/libexec/qemu-kvm -m 2G -cpu host -smp 2 -qmp tcp::5555,server,nowait > -monitor stdio -M pc -spice port=5931,disable-ticketing -drive > file=/media/linux_img/RHEL-Server-6.6-32-virtio.qcow2,if=none,id=img, > snapshot=on -device virtio-blk-pci,drive=img,id=sys-img -device > virtio-net-pci,ctrl_mac_addr=on,netdev=dev1,vectors=10,mq=on,mac=22:54:08:62: > 94:89,id=net1 11<>/dev/tap5 12<>/dev/tap6 13<>/dev/tap7 14<>/dev/tap8 > -netdev tap,id=dev1,vhost=off,fds=11:12:13:14 > > steps as comment 0, after step 5, guest network works well. Can be accessed > successfully. No hit this issue. Good to know it. The bug was reported for qemu-kvm-1.5.3-60.el7_0.2.x86_64, can you test with latest qemu-kvm? (In reply to Amos Kong from comment #9) > (In reply to Jun Li from comment #8) > > (In reply to Amos Kong from comment #7) > > > Jun, can you recover guest network by restarting network? > > > > Retest this bz. > > > > Version of components: > > qemu-kvm-rhev-2.1.2-13.el7.x86_64 > > > > cli: > > # /usr/libexec/qemu-kvm -m 2G -cpu host -smp 2 -qmp tcp::5555,server,nowait > > -monitor stdio -M pc -spice port=5931,disable-ticketing -drive > > file=/media/linux_img/RHEL-Server-6.6-32-virtio.qcow2,if=none,id=img, > > snapshot=on -device virtio-blk-pci,drive=img,id=sys-img -device > > virtio-net-pci,ctrl_mac_addr=on,netdev=dev1,vectors=10,mq=on,mac=22:54:08:62: > > 94:89,id=net1 11<>/dev/tap5 12<>/dev/tap6 13<>/dev/tap7 14<>/dev/tap8 > > -netdev tap,id=dev1,vhost=off,fds=11:12:13:14 > > > > steps as comment 0, after step 5, guest network works well. Can be accessed > > successfully. No hit this issue. > > Good to know it. > The bug was reported for qemu-kvm-1.5.3-60.el7_0.2.x86_64, can you test with > latest qemu-kvm? Just retest this bz. The first time, can not reproduce this bz, the second time hit this bz. Version of components: qemu-kvm-1.5.3-84.el7.x86_64 cli: /usr/libexec/qemu-kvm -m 2G -cpu host -smp 2 -qmp tcp::5555,server,nowait -monitor stdio -M pc -spice port=5931,disable-ticketing -drive file=/mnt/linux_img/RHEL-Server-6.6-32-virtio.qcow2,if=none,id=img,snapshot=on -device virtio-blk-pci,drive=img,id=sys-img -device virtio-net-pci,ctrl_mac_addr=on,netdev=dev1,vectors=10,mq=on,mac=ee:57:4a:f8:7d:7b,id=net1 11<>/dev/tap9 12<>/dev/tap10 13<>/dev/tap11 14<>/dev/tap12 -netdev tap,id=dev1,vhost=off,fds=11:12:13:14 steps as comment 0, after step 5, guest network can not access. After restarting guest network, can not recover guest network. Seems guest can not got IP address after restart guest network. execute "# dhclient eth1" inside guest, can not got IP address still. (qemu) info network net1: index=0,type=nic,model=virtio-net-pci,macaddr=ee:57:4a:f8:7d:7b \ dev1: index=0,type=tap,fd=11 net1: index=1,type=nic, \ dev1: index=1,type=tap,fd=12 net1: index=2,type=nic, \ dev1: index=2,type=tap,fd=13 net1: index=3,type=nic, \ dev1: index=3,type=tap,fd=14 The priority and severity were lowered. We usually run with vhost=on, and stopping for 3 minutes is not a production scenario (e.g. stopping for 3 mins might cause disk requests to timeout). So it works well on qemu-kvm-rhev-2.1.2-13.el7.x86_64 but not qemu-kvm-1.5.3-40.el7.x86_64. So please do 1) check whether or not qemu.git tag 1.5 works 2) check whether or not qemu.git tag 2.1 works 3) if 1 does not work but 2 works, please bisect between those commits in qemu.git and report the commit that fixes this issue. Thanks Any updates on the bz? Hi Qiguo, Could you have a test and update the result in the bz? Best Regards, Junyi (In reply to juzhang from comment #16) > Hi Qiguo, > > Could you have a test and update the result in the bz? > > Best Regards, > Junyi Need time, since the priory is low, will delay it once got enough time. keep the needinfo left first. any update on this? |