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 <[email protected]> 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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
