yahoo-eng-team team mailing list archive

[OpenStack Infra <1808252@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/624842
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=9e77c3d3bbd47863c0f60e4499396429bb46582c
Submitter: Zuul
Branch:    master

commit 9e77c3d3bbd47863c0f60e4499396429bb46582c
Author: Sean Mooney <work@xxxxxxxxxxxxxxx>
Date:   Thu Dec 13 00:56:44 2018 +0000

    Libvirt: do not set MAC when unplugging macvtap VF
    
    - This change updates unplug_hw_veb to reset the
      VF MAC when unplugging macvtap SR-IOV vifs.
      Doing this will prevent a network partition to
      be formed as the VM's MAC is no longer retained on
      the VF after the vif has been unplugged, allowing
      traffic with the VFs former MAC to be transmitted
      on the PF in case it is reused in another host.
    
    - This change corrects an outdated comment to reflect
      that network drivers allow setting a VF's MAC to zero
      via ip tool.
      It should be noted that setting the VF's netdev MAC to zero
      is not allowed and thus ip tool return code in this scenario
      is ignored in linux_utils.set_vf_interface_vlan().
      We also leave a TODO to futher clean up this code later in Stein.
    
    Change-Id: I4f78f3cc412d7ec59456aea915a1ebfc8b27681f
    Closes-Bug: #1808252


** Changed in: nova
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1808252

Title:
  libvirt: unplug_hw_veb incorrectly set vm mac on vf

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  
  as part of resolving https://bugs.launchpad.net/nova/+bug/1370348
  https://github.com/openstack/nova/commit/386e38198d63cf2dc45507ca7e4dc82f0bcd9bb9
  incorrectly asserted that 

  # The ip utility doesn't accept the MAC 00:00:00:00:00:00.
  # Therefore, keep the MAC unchanged.  Later operations on
  # the same VF will not be affected by the existing MAC.

  while it may have beent true that at one point the ip utility did
  not support setting MAC 00:00:00:00:00:00 i has supported it for some
  time. That however is not the issue. setting the mac of the vf back to the
  the vm mac was never correct as it introduce a new bug.

  By configuring a mac on a vf, in this case the vm mac the mac filter on the 
  PF will nologer allow a packet with the vm mac as a destiation to leave the host.
  This is part of the PF loop prevention mechanium and create a possible network partition.

  if for example the vm is deleted on host A and the neutron port is
  reused to spawn a new vm on a different host B, packet on host A will
  be able to be transmitted to the vm on Host b.

  This also means if the vm is cold/live migrated or resized the same partitioning will occur
  between the source and dest node.

  in the event of a converged deployment where the pf is used by ovs if that first host
  ran the neutron l3 or dhcp agent then it would futher degread connectivity as any unicast packet that was transmisted to the removte vm either in responce to a dhcp request or as a result of floating-ip/snat translation or routing will be dropped.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1808252/+subscriptions