yahoo-eng-team team mailing list archive

[Kevin Benton <1475256@xxxxxxxxxxxxxxxxxx>]

That vif is created/deleted by nova during vif plug/unplug. It sounds
like you've discovered a case where the unplug operation is not
happening.

** Project changed: neutron => nova

-- 
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/1475256

Title:
  sriov: VFs attributes (vlan, mac address) are not cleaned up after
  port delete

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Image we create a port like this:

  $ neutron port-create  --binding:vnic_type=direct --name rjuly013 sriovtest0
  Created a new port:
  +-----------------------+-------------------------------------------------------------------------------------+
  | Field                 | Value                                                                               |
  +-----------------------+-------------------------------------------------------------------------------------+
  | admin_state_up        | True                                                                                |
  | allowed_address_pairs |                                                                                     |
  | binding:host_id       |                                                                                     |
  | binding:profile       | {}                                                                                  |
  | binding:vif_details   | {}                                                                                  |
  | binding:vif_type      | unbound                                                                             |
  | binding:vnic_type     | direct                                                                              |
  | device_id             |                                                                                     |
  | device_owner          |                                                                                     |
  | fixed_ips             | {"subnet_id": "ffa84ccf-ba49-4a23-a8ab-9295bc7d93f2", "ip_address": "166.168.0.15"} |
  | id                    | 2ec3b30e-e3cf-4a8f-a7cb-68a910a59e9a                                                |
  | mac_address           | fa:16:3e:ca:11:87                                                                   |
  | name                  | rjuly013                                                                            |
  | network_id            | 26a0f22b-42b0-41d2-9b76-41270ce9b655                                                |
  | security_groups       | b0ef012a-96b2-458f-bd28-c46306f063fa                                                |
  | status                | DOWN                                                                                |
  | tenant_id             | 2ebabf166ecd43dd8093b70a37f26be4                                                    |
  +-----------------------+-------------------------------------------------------------------------------------+
  $

  And then create a VM with this port:

  $ nova boot --image 3c3a5387-7471-4e88-a19e-09e0c9a08707 --flavor 3
  --nic port-id=2ec3b30e-e3cf-4a8f-a7cb-68a910a59e9a rjuly013

  Now we can see a VF configured:

  $ ip link|grep fa:16:3e:ca:11:87
      vf 7 MAC fa:16:3e:ca:11:87, spoof checking on, link-state auto
  $

  After deletion of VM, we can see that the VF is still configured:

  $ ip link|grep fa:16:3e:ca:11:87
      vf 7 MAC fa:16:3e:ca:11:87, spoof checking on, link-state auto
  $

  This situation could cause troubles, for example, if user would want
  to create a new port with the mac address of the removed port, and if
  a port would be allocated on the same PF, there would be 2 VFs with
  the same MAC address in result. This could cause an unexpected
  behavior, with 'ixgbe' at least.

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