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.
Bug 591756 - After destroy a guest vm, the network of host will hang.
Summary: After destroy a guest vm, the network of host will hang.
Keywords:
Status: CLOSED DUPLICATE of bug 584428
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Michael S. Tsirkin
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-13 02:03 UTC by Kirby Zhou
Modified: 2010-11-11 19:30 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-24 14:58:42 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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 ***
Note You need to log in before you can comment on or make changes to this bug.