← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 2121530] Re: [SR-IOV] Trusted VF port MAC address can be changed from inside the VM

 

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/958877
Committed: https://opendev.org/openstack/neutron/commit/b5e625fa3a313de3666a048f5a8ec79ca6bced71
Submitter: "Zuul (22348)"
Branch:    master

commit b5e625fa3a313de3666a048f5a8ec79ca6bced71
Author: Rodolfo Alonso Hernandez <ralonsoh@xxxxxxxxxx>
Date:   Fri Aug 29 13:16:38 2025 +0000

    [SR-IOV] Document the trusted virtual functions feature
    
    It is also document what happens, when using a trusted VF, the
    MAC address is changed.
    
    Closes-Bug: #2121530
    Signed-off-by: Rodolfo Alonso Hernandez <ralonsoh@xxxxxxxxxx>
    Change-Id: Iff01b2196d8c0f990155225fce69eab318cce753


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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2121530

Title:
  [SR-IOV] Trusted VF port MAC address can be changed from inside the VM

Status in neutron:
  Fix Released

Bug description:
  With some drivers (vendors), if from inside the VM the port MAC is
  change, the VF MAC will be changed accordingly. That is only possible
  if the port VF is trusted.

  That represents an issue for the SR-IOV agent, that tries to locate the ports using the tuple (PCI, MAC). If the MAC does match the Neutron DB port MAC:
  * The agent will print a warning message:
      LOG.warning(device pci mismatch: %(device_mac)s - %(pci_slot)s, ...)
  * It will also resync the whole cache. That will request to the Neutron API the list of port information. The RPC call will change the ports status to BUILD [1]. Then, if the port will be set at UP by the agent and the status will change to ACTIVE.

  That triggers a loop of port status flapping from BUILD to ACTIVE,
  that is repeated each SR-IOV agent loop (2 seconds by default).

  The goal of this bug is to determine if we can skip this resync and
  only write a warning message in the logs in case the (PCI, MAC) tuple
  doesn't match.

  [1]https://github.com/openstack/neutron/blob/f9067a719084710ee4f46fa31edb6a938e0dbbb0/neutron/plugins/ml2/rpc.py#L130-L137

  Jira ticket: https://issues.redhat.com/browse/OSPRH-19321

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



References