Public bug reported:
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. ** Affects: nova Importance: High Assignee: sean mooney (sean-k-mooney) Status: Confirmed ** Tags: libvirt sriov -- 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): Confirmed 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
