Bug 523915 - Ifdown one of both tap devices in guest will cause the other down as well
Summary: Ifdown one of both tap devices in guest will cause the other down as well
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Eduardo Habkost
QA Contact: Lawrence Lim
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-17 07:46 UTC by Yolkfull Chow
Modified: 2014-03-26 01:01 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-29 22:46:55 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Yolkfull Chow 2009-09-17 07:46:42 UTC
Description of problem:
Boot the guest with multiple tap devices which contains at least a virtio tap device, and then ifdown one NIC card will cause another NIC card down as well.

Version-Release number of selected component (if applicable):
105-4.3

How reproducible:
Everytime

Steps to Reproduce:
1. boot the guest with two NIC devices which contains a virtio NIC card
2. after the guest booted up, ifdown one NIC card
3. another NIC devices is down as well which means the network broken
  
Actual results:
Both tap devices down if only ifdown one of them in guest

Expected results:
The other tap device should survive after ifdown one

Additional info:

Reference bug #505232 comment #6

Comment 1 Dor Laor 2009-10-29 22:45:24 UTC
What's the qemu cmdline? It is weird that the tap state was changed.

Comment 2 RHEL Program Management 2009-10-29 22:46:55 UTC
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request.

Comment 3 Yolkfull Chow 2009-11-12 07:11:41 UTC
(In reply to comment #1)
> What's the qemu cmdline? It is weird that the tap state was changed.  

Hi Dor,
Sorry for the late reply. As referred in this bug description, the FULL command line could be found in bug #505232, and I also would paste it here:

#/usr/libexec/qemu-kvm -name 'vm1' -drive
file=/tmp/kvm_autotest_root/images/RHEL-Server-5.3-64-virtio.qcow2,media=disk,if=virtio,cache=off,boot=on
-uuid 4b66fdbe-b86d-42f3-8efd-76db26aaedb6 -net
nic,vlan=0,macaddr=00:11:22:33:aa:bc,model=virtio -net
tap,vlan=0,ifname=test1,script=/etc/qemu-ifup-switch,downscript=no -net
nic,vlan=1,macaddr=00:cc:22:33:aa:bc,model=e1000 -net
tap,vlan=1,ifname=test2,script=/etc/qemu-ifup-switch,downscript=no -net
nic,vlan=2,macaddr=00:11:22:33:aa:be,model=rtl8139 -net
tap,vlan=2,ifname=test3,script=/etc/qemu-ifup-switch,downscript=no -m 2048 -smp
2 -vnc :0

Seems this problem still exists but I'm not sure. Yeah it's weird and important for keep guest's network stable I think. Do you think we need to reopen it?

Comment 4 Dor Laor 2009-11-15 15:14:31 UTC
Are you running STP on the bridge? It might be the cause. We use stp off by default.


Note You need to log in before you can comment on or make changes to this bug.