Bug 591756

Summary:	After destroy a guest vm, the network of host will hang.
Product:	Red Hat Enterprise Linux 6	Reporter:	Kirby Zhou <kirbyzhou>
Component:	qemu-kvm	Assignee:	Michael S. Tsirkin <mst>
Status:	CLOSED DUPLICATE	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	low
Version:	6.0	CC:	gyue, quintela, virt-maint
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-05-24 14:58:42 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kirby Zhou 2010-05-13 02:03:16 UTC

After destroy a guest vm, the network of host will hang.

I operate the host through ssh, it hangs after destroying a guest, and recovered after I ping something else from the keyboard console.


Steps:

through ssh
]# virsh start kirby-dev
]# virsh destroy kirby-dev
then network hang, can not ping nor ssh the host.

through keyboard
]# ping somehost
then network recovered, can ssh and ping the host

Comment 2 RHEL Program Management 2010-05-13 04:17:17 UTC

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Kirby Zhou 2010-05-13 15:07:30 UTC

Some more details:

ping from botn the same LAN and other LAN droped packages.

10.227]# ping 10.12.18.97
64 bytes from 10.12.18.97: icmp_seq=25 ttl=63 time=0.170 ms
64 bytes from 10.12.18.97: icmp_seq=26 ttl=63 time=0.146 ms
64 bytes from 10.12.18.97: icmp_seq=83 ttl=63 time=0.180 ms
64 bytes from 10.12.18.97: icmp_seq=84 ttl=63 time=0.156 ms

18.94]# ping 10.12.18.97
64 bytes from 10.12.18.97: icmp_seq=28 ttl=64 time=0.074 ms
64 bytes from 10.12.18.97: icmp_seq=29 ttl=64 time=0.064 ms
64 bytes from 10.12.18.97: icmp_seq=77 ttl=64 time=1.16 ms
64 bytes from 10.12.18.97: icmp_seq=78 ttl=64 time=0.068 ms


But if someone (18.96) else in the same LAN of 18.97 do a new ping 18.97 when 18.97 is already hang, everything is recovered very quickly. For example:

64 bytes from 10.12.18.97: icmp_seq=228 ttl=64 time=0.070 ms
64 bytes from 10.12.18.97: icmp_seq=234 ttl=64 time=0.081 ms
 


Below is the network configuration of host.

]# tail *eth[01]* *vbr* -n20
==> ifcfg-eth0 <==
# Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet
DEVICE=eth0
BOOTPROTO=static
DEFROUTE=yes
DHCPCLASS=
DNS1=192.168.132.1
GATEWAY=10.12.19.254
HWADDR=E4:1F:13:30:78:68
IPADDR=10.12.18.97
NETMASK=255.255.252.0
ONBOOT=yes
OPTIONS=layer2=1
PREFIX=22
TYPE=Ethernet
UUID=5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03

BRIDGE=vbr0

==> ifcfg-eth1 <==
# Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet
DEVICE=eth1
HWADDR=E4:1F:13:30:78:6A
BOOTPROTO=static
ONBOOT=yes
IPADDR=10.14.18.97
NETMASK=255.255.252.0
TYPE=Ethernet

BRIDGE=vbr1

==> ifcfg-vbr0 <==
# Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet
DEVICE=vbr0
BOOTPROTO=static
DEFROUTE=yes
DHCPCLASS=
DNS1=192.168.132.1
GATEWAY=10.12.19.254
HWADDR=E4:1F:13:30:78:68
IPADDR=10.12.18.97
NETMASK=255.255.252.0
ONBOOT=yes
OPTIONS=layer2=1
PREFIX=22
TYPE=Bridge

==> ifcfg-vbr1 <==
# Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet
DEVICE=vbr1
HWADDR=E4:1F:13:30:78:6A
ONBOOT=yes
IPADDR=10.14.18.97
NETMASK=255.255.252.0
TYPE=Bridge

==> route-vbr1 <==
10.14.0.0/24 via 10.14.19.254
default via 10.14.19.254 table eth1_table

==> rule-vbr1 <==
from 10.14.0.0/16 to 10.14.0.0/16 lookup main priority 10000
from 10.14.0.0/16 to 10.14.0.0/16 lookup default priority 10001
from 10.14.0.0/16 table eth1_table priority 10002

]# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=djt-18-97
GATEWAY=10.12.19.254

]# cat /etc/iproute2/rt_tables 
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
200     eth1_table

]# brctl  show
bridge name     bridge id               STP enabled     interfaces
vbr0            8000.76c4d2c1c0fd       no              eth0
                                                        vnet0
vbr1            8000.cebade399f21       no              eth1
                                                        vnet1
virbr0          8000.000000000000       yes

Comment 4 Michael S. Tsirkin 2010-05-24 14:58:42 UTC


*** This bug has been marked as a duplicate of bug 584428 ***