Bug 1609454 - nwfilter-binding-create succeed on interface which does not exist
Summary: nwfilter-binding-create succeed on interface which does not exist
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: John Ferlan
QA Contact: yalzhang@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-28 02:41 UTC by yalzhang@redhat.com
Modified: 2019-08-06 13:14 UTC (History)
8 users (show)

Fixed In Version: libvirt-4.5.0-12.el7
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2019-08-06 13:13:56 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:2294 None None None 2019-08-06 13:14:34 UTC

Description yalzhang@redhat.com 2018-07-28 02:41:43 UTC
Description of problem:
nwfilter-binding-create succeed on interface which do not exists

Version-Release number of selected component (if applicable):
libvirt-4.5.0-4.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. ensure there is no dev called "vnet0"  on host, then prepare a xml with nwfilter-binding on vnet0:
# ip l | grep vnet0
# cat binding.xml
<filterbinding>
  <owner>
    <name>rhel</name>
    <uuid>c9543ff4-1703-40a9-abbf-7f3e0fcd66c0</uuid>
  </owner>
  <portdev name='vnet0'/>
  <mac address='52:54:00:11:6d:f0'/>
  <filterref filter='clean-traffic'>
    <parameter name='MAC' value='52:54:00:11:6d:f0'/>
  </filterref>
</filterbinding>

2. create the nwfilter-binding will succeed
# virsh nwfilter-binding-create binding.xml
Network filter binding on vnet0 created from binding.xml

# virsh nwfilter-binding-list 
 Port Dev              Filter               
------------------------------------------------------------------
 vnet0                 clean-traffic 

# ip l | grep vnet0
# virsh nwfilter-binding-dumpxml vnet0
<filterbinding>
  <owner>
    <name>rhel</name>
    <uuid>c9543ff4-1703-40a9-abbf-7f3e0fcd66c0</uuid>
  </owner>
  <portdev name='vnet0'/>
  <mac address='52:54:00:11:6d:f0'/>
  <filterref filter='clean-traffic'>
    <parameter name='MAC' value='52:54:00:11:6d:f0'/>
  </filterref>
</filterbinding>

3. but no rules here:
# ebtables -t nat -L
Bridge table: nat

Bridge chain: PREROUTING, entries: 1, policy: ACCEPT
-j PREROUTING_direct

Bridge chain: OUTPUT, entries: 1, policy: ACCEPT
-j OUTPUT_direct

Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT
-j POSTROUTING_direct

Bridge chain: PREROUTING_direct, entries: 0, policy: RETURN

Bridge chain: POSTROUTING_direct, entries: 0, policy: RETURN

Bridge chain: OUTPUT_direct, entries: 0, policy: RETURN

4. start guest will fail if the interface has target dev is vnet0,  and filterref defined
# virsh dumpxml rhel | grep /interface -B6
    <interface type='network'>
      <mac address='52:54:00:41:1b:00'/>
      <source network='default'/>
      <model type='rtl8139'/>
      <filterref filter='no-ip-spoofing'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

# virsh start rhel
error: Failed to start domain rhel
error: internal error: Filter already present for NIC vnet0

# grep error /var/log/libvirt/libvirtd.log
2018-07-26 12:30:32.398+0000: 142356: error : nwfilterBindingCreateXML:758 : internal error: Filter already present for NIC vnet0
2018-07-26 12:30:32.425+0000: 142410: error : virNetDevSendEthtoolIoctl:3072 : ethtool ioctl error: No such device
2018-07-26 12:30:32.428+0000: 142410: error : virNetDevSendEthtoolIoctl:3072 : ethtool ioctl error: No such device
2018-07-26 12:30:32.430+0000: 142410: error : virNetDevSendEthtoolIoctl:3072 : ethtool ioctl error: No such device
2018-07-26 12:30:32.432+0000: 142410: error : virNetDevSendEthtoolIoctl:3072 : ethtool ioctl error: No such device
2018-07-26 12:30:32.434+0000: 142410: error : virNetDevSendEthtoolIoctl:3072 : ethtool ioctl error: No such device
2018-07-26 12:30:32.435+0000: 142356: error : virNWFilterBindingLookupByPortDev:589 : portdev in virNWFilterBindingLookupByPortDev must not be NULL
2018-07-26 12:30:32.436+0000: 142410: error : virNetDevSendEthtoolIoctl:3072 : ethtool ioctl error: No such device
2018-07-26 12:30:32.436+0000: 142356: error : virNWFilterBindingLookupByPortDev:589 : portdev in virNWFilterBindingLookupByPortDev must not be NULL
2018-07-26 12:30:32.438+0000: 142410: error : virNetDevSendEthtoolIoctl:3072 : ethtool ioctl error: No such device
2018-07-26 12:30:32.440+0000: 142410: error : virNetDevSendEthtoolIoctl:3072 : ethtool ioctl error: No such device

Actual results:
nwfilter-binding-create can succeed even the interface is not exists, but no rules will added

Expected results:
nwfilter-binding-create should report error when the interface matched by name and mac is not exists

Additional info:

Comment 2 John Ferlan 2018-08-21 23:23:21 UTC
The "cheese moved" on this after commit id 3379193f1:

Author: Pavel Hrdina <phrdina@redhat.com>
Date:   Thu Jun 28 09:53:48 2018 +0200

    nwfilter: Remove redundant check if object exists
    
    The same check is done by virNWFilterBindingObjListAdd().  The main
    issue with the current code is that if the object already exists we
    would leak 'def' because 'obj' would be set and the cleanup code frees
    'def' only if 'obj' is NULL.
    
    Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
    Signed-off-by: Pavel Hrdina <phrdina@redhat.com>

However, the symptoms are the same:

# virsh start f18
error: Failed to start domain f18
error: operation failed: binding 'vnet0' already exists

# 

Of course, I'm not sure this usage is "intended" vis-a-vis the original implementation commit message from:

https://www.redhat.com/archives/libvir-list/2018-May/msg01165.html

e.g.:

commit 2d9318b6ce9629ac150e92b895eede4e2dbf19ac
Author: Daniel P. Berrangé <berrange@redhat.com>
Date:   Fri May 11 16:59:51 2018 +0100

    nwfilter: wire up new APIs for creating and deleting nwfilter bindings
    
    This allows the virsh commands nwfilter-binding-create and
    nwfilter-binding-delete to be used.
    
    Note using these commands lets you delete filters that were
    previously created automatically by the virt drivers, or add
    filters for VM nics that were not there before. Generally it
    is expected these new APIs will only be used by virt drivers.
    It is the admin's responsibility to not shoot themselves in
    the foot.

...

I can agree it's not well described, but I think the code is working as designed.  If you started a domain without a filter, then you could add a filter while the domain was running.  It's virtually impossible to distinguish the purpose of the filter to be created. 

At best perhaps some documentation adjustments to describe things better might be able to help. The "details" of the purpose of the virsh commands and API were left in the commit message rather than the API and virsh.pod file.

Comment 3 John Ferlan 2018-08-22 22:49:50 UTC
Although not the exact resolution hoped, I posted a patch upstream that will describe the nwfilter-binding-{create|delete} and virNWFilterBinding{CreateXML|Delete} a bit better to help 'avoid future confusion'.  I think perhaps better than just closing this as not a bug.

https://www.redhat.com/archives/libvir-list/2018-August/msg01408.html

Comment 4 John Ferlan 2018-08-22 22:50:11 UTC
Although not the exact resolution hoped, I posted a patch upstream that will describe the nwfilter-binding-{create|delete} and virNWFilterBinding{CreateXML|Delete} a bit better to help 'avoid future confusion'.  I think perhaps better than just closing this as not a bug.

https://www.redhat.com/archives/libvir-list/2018-August/msg01408.html

Comment 5 John Ferlan 2018-08-24 12:57:21 UTC
Pushed upstream:

commit b4833917f12a0ffa4b5957ef77edea737cb8ad58 (HEAD -> master, origin/master, origin/HEAD, bz1609454)
Author: John Ferlan <jferlan@redhat.com>
Date:   Wed Aug 22 18:01:41 2018 -0400

    nwfilter: Add extra verbiage for binding create/delete
    
    ...
    
    Add some cautionary words related to the create and delete
    NWFilter Binding use cases and possible issues that may result
    to the virsh nwfilter-binding-{create|delete} descriptions
    and the virNWFilterBinding{CreateXML|Delete) API descriptions.
    
    Essentially summarizing commit 2d9318b6c without using the
    shoot yourself in the foot wording.
    
    Signed-off-by: John Ferlan <jferlan@redhat.com>
    Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>

$ git describe b4833917f12a0ffa4b5957ef77edea737cb8ad58
v4.6.0-303-gb4833917f1
$

Comment 10 yalzhang@redhat.com 2019-04-10 07:45:41 UTC
Check on libvirt-4.5.0-12.el7.x86_64, the descriptiont is clear enough, move this bug to be verified.
# man virsh
...
       nwfilter-binding-create xmlfile
Associate a network port with a network filter. The network filter backend will immediately attempt to instantiate the filter rules on the port. This command may be used to associate a filter with a currently running guest that does not have a filter defined for a specific network port. Since the bindings are generally automatically managed by the hypervisor, using this command to define a filter for a network port and then starting the guest afterwards may prevent the guest from starting if it attempts to use the network port and finds a filter already defined.

       nwfilter-binding-delete port-name
Disassociate a network port from a network filter. The network filter backend will immediately tear down the filter rules that exist on the port. This command may be used to remove the network port binding for a filter currently in use for the guest while the guest is running without needing to restart the guest. Restoring the network port binding filter for the running guest would be accomplished by using nwfilter-binding-create.

Comment 12 errata-xmlrpc 2019-08-06 13:13:56 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.

https://access.redhat.com/errata/RHSA-2019:2294


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