Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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
(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);
+ }
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"
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
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