Bug 884590

Summary: ovs-ifup affect but ovs-ifdown not affect when run a guest with a wrong netdriver(e.g. ... -device virtio-pci-net,...)
Product: Red Hat Enterprise Linux 6 Reporter: Qian Guo <qiguo>
Component: qemu-kvmAssignee: Amos Kong <akong>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.4CC: acathrow, ailan, akong, areis, bsarathy, chayang, juzhang, lnovich, mkenneth, rhod, sradvan, virt-maint, xfu
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-0.12.1.2-2.361.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 05:58:30 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:

Description Qian Guo 2012-12-06 10:56:42 UTC
Description of problem:
when using openvswitch 
I run a guest with a wrong cli(... -device virtio-pci-net,... ), the tap0 could not be delete from the ovs0

Version-Release number of selected component (if applicable):
host#rpm -qa \*openvswitch\*
openvswitch-controller-1.7.1-7.el6.x86_64
openvswitch-debuginfo-1.7.1-7.el6.x86_64
openvswitch-1.7.1-7.el6.x86_64

host# rpm -qa \*qemu\*
qemu-kvm-debuginfo-0.12.1.2-2.337.el6.x86_64
gpxe-roms-qemu-0.9.7-6.9.el6.noarch
qemu-img-0.12.1.2-2.337.el6.x86_64
qemu-kvm-0.12.1.2-2.337.el6.x86_64
qemu-kvm-tools-0.12.1.2-2.337.el6.x86_64
qemu-guest-agent-0.12.1.2-2.337.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.run guest like this 
<qemu-kvm cmdline>...-netdev tap,id=hostnet0,vhost=on,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -device virtio-pci-net,netdev=hostnet0,id=virt-net0,mac=54:52:1a:32:b4:01 ...

which virtio-pci-net is  a wrong discription

then qemu quit like this
qemu-kvm: -device virtio-pci-net,netdev=hostnet0,id=virt-net0,mac=54:52:1a:32:b4:01: Parameter 'driver' expects a driver name
Try with argument '?' for a list.

2.in host do 
host#ovs-vsctl show
Bridge "ovs0"
        Port "ovs0"
            Interface "ovs0"
                type: internal
        Port "tap0"
            Interface "tap0"
        Port "eth0"
            Interface "eth0"
    ovs_version: "1.7.1"

  
Actual results:
tap0 is still in the openvswitch  "ovs0". ovs-ifup affect and ovs-ifdown not affect

Expected results:
ovs-ifdown should affect and delete tap0 from ovs0

Additional info:
host#cat /etc/ovs-ifup
#!/bin/sh
switch=ovs0
/sbin/ifconfig $1 0.0.0.0 up
ovs-vsctl add-port ${switch} $1

host#cat /etc/ovs-ifdown
#!/bin/sh
switch=ovs0
/sbin/ifconfig $1 0.0.0.0 down
ovs-vsctl del-port ${switch} $1

Comment 2 Qian Guo 2012-12-07 13:26:02 UTC
Additional info:

This bug could be reproduced 100% when kill the qemu-kvm process e.g.
#kill -9 $pid of qemu-kvm

Comment 3 Amos Kong 2012-12-11 04:29:05 UTC
Close this bug according to comment #2.

Comment 4 Amos Kong 2012-12-11 04:30:46 UTC
Sorry, I made a mistake. Please ignore comment #3

Comment 5 Amos Kong 2012-12-11 05:46:05 UTC
(In reply to comment #2)
> Additional info:
> 
> This bug could be reproduced 100% when kill the qemu-kvm process e.g.
> #kill -9 $pid of qemu-kvm

downscript could not be executed if you use 'SIGKILL' to kill qemu process.
downscript can be executed to cleanup tap if you kill by default signal of kill

# kill $qemu-pid

However, the problem in comment #1 is a real bug.

====

tap device would be created when net_init_clients() is called.
'device' option is parsed after calling net_init_clients().
we should call net_cleanup() when device parse fails.


I did a quick fix, the tap device should be removed in the situation of comment #1.
But there are many "exit(1)" after calling net_init_clients() in vl.c, it's ugly to call net_cleanup() before each exit.
Not sure if we have some exit(1) in other sub functions, which is also called after calling net_init_clients().

@@ -3882,8 +3889,11 @@ int main(int argc, char **argv, char **envp)
     }

     /* init generic devices */
-    if (qemu_opts_foreach(qemu_find_opts("device"), device_init_func, NULL, 1) != 0)
+    if (qemu_opts_foreach(qemu_find_opts("device"), device_init_func,
+                          NULL, 1) != 0) {
+        net_cleanup();
         exit(1);
+    }

Comment 7 Amos Kong 2012-12-18 10:10:17 UTC
Posted patch to upstream:
http://lists.nongnu.org/archive/html/qemu-devel/2012-12/msg01348.html

Comment 17 Qian Guo 2013-07-04 03:23:44 UTC
1.Reproduced this bug with qemu-kvm-0.12.1.2-2.335.el6.x86_64
steps:
1.run guest like this 
<qemu-kvm cmdline>...-netdev tap,id=hostnet0,vhost=on,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -device virtio-pci-net,netdev=hostnet0,id=virt-net0,mac=54:52:1a:32:b4:01 ...

which virtio-pci-net is  a wrong discription

Then qemu-kvm quit w/ following messages:
qemu-kvm: -device virtio-pci-net,netdev=hostnet0,id=virt-net0,mac=54:52:1a:32:b4:01: Parameter 'driver' expects a driver name
Try with argument '?' for a list.

Result:tap0 is still in the ovs bridge, So, base on above testing, this bug is reproduced

# ovs-vsctl show
83f619a3-afd0-47ce-8ac7-c716daa4f662
    Bridge "ovs0"
        Port "eth0"
            Interface "eth0"
        Port "ovs0"
            Interface "ovs0"
                type: internal
        Port "tap0"
            Interface "tap0"
    ovs_version: "1.9.0"


Verify this bug w/ qemu-kvm-0.12.1.2-2.377.el6.x86_64:
Steps:
1.run guest like this 
<qemu-kvm cmdline>...-netdev tap,id=hostnet0,vhost=on,script=/etc/ovs-ifup,downscript=/etc/ovs-ifdown -device virtio-pci-net,netdev=hostnet0,id=virt-net0,mac=54:52:1a:32:b4:01 ...

which virtio-pci-net is  a wrong discription

Then qemu-kvm quit w/ following messages:
qemu-kvm: -device virtio-pci-net,netdev=hostnet0,id=virt-net0,mac=54:52:1a:32:b4:01: Parameter 'driver' expects a driver name
Try with argument '?' for a list.

Result:There's no tap device in the ovs bridge, so base on above testing, this bug is verified by qemu-kvm-0.12.1.2-2.377.el6.x86_64 .
# ovs-vsctl show
83f619a3-afd0-47ce-8ac7-c716daa4f662
    Bridge "ovs0"
        Port "eth0"
            Interface "eth0"
        Port "ovs0"
            Interface "ovs0"
                type: internal
    ovs_version: "1.9.0"

Comment 19 errata-xmlrpc 2013-11-21 05:58:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-1553.html