Bug 523915

Summary:	Ifdown one of both tap devices in guest will cause the other down as well
Product:	Red Hat Enterprise Linux 5	Reporter:	Yolkfull Chow <yzhou>
Component:	kvm	Assignee:	Eduardo Habkost <ehabkost>
Status:	CLOSED WONTFIX	QA Contact:	Lawrence Lim <llim>
Severity:	medium	Docs Contact:
Priority:	low
Version:	5.4	CC:	tburke, tools-bugs, virt-maint, ykaul
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:	2009-10-29 22:46:55 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 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.