Bug 1468425 - Openstack Vm network port changes after deletion/addition & reboot
Openstack Vm network port changes after deletion/addition & reboot
Status: CLOSED NOTABUG
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
8.0 (Liberty)
Unspecified Unspecified
high Severity high
: ---
: ---
Assigned To: Eoghan Glynn
Joe H. Rahme
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-07 00:18 EDT by Anil Dhingra
Modified: 2017-12-24 21:52 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-12 11:36:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Anil Dhingra 2017-07-07 00:18:06 EDT
Description of problem:

NFV project that using Cisco ESC to create instance (VNF).
When ESC updates VM’s port, ESC takes the following steps.
1. delete os-interface
2. delete port
3. create port
4. create os-interface
5. reboot VM for VM itself to recognize port update
Version-Release number of selected component (if applicable):

From Linux KVM XML perspective, the above steps can be seen like below:
 
Step0. Before update operation; Assume there are three ports on a VNF
 
    <interface type='bridge'>
      <mac address='fa:16:3e:c0:04:f4'/>
      <source bridge='qbr0ad360c3-0b'/>
      <target dev='tap0ad360c3-0b'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <interface type='bridge'>
      <mac address='fa:16:3e:27:81:56'/>
      <source bridge='qbr4915dde1-a6'/>
      <target dev='tap4915dde1-a6'/>
      <model type='virtio'/>
      <alias name='net1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </interface>
    <interface type='bridge'>
      <mac address='fa:16:3e:c8:19:5f'/>
      <source bridge='qbrfa3b674c-8b'/>
      <target dev='tapfa3b674c-8b'/>
      <model type='virtio'/>
      <alias name='net2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </interface>
 
Step1. Remove a port; Second interface is removed
 
    <interface type='bridge'>
      <mac address='fa:16:3e:c0:04:f4'/>
      <source bridge='qbr0ad360c3-0b'/>
      <target dev='tap0ad360c3-0b'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>

====> REMOVED net1 <====

    <interface type='bridge'>
      <mac address='fa:16:3e:c8:19:5f'/>
      <source bridge='qbrfa3b674c-8b'/>
      <target dev='tapfa3b674c-8b'/>
      <model type='virtio'/>
      <alias name='net2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </interface>
 
Step2. Add a port; Add a port on bottom position with removed “alias name” and “slot” values
 
    <interface type='bridge'>
      <mac address='fa:16:3e:c0:04:f4'/>
      <source bridge='qbr0ad360c3-0b'/>
      <target dev='tap0ad360c3-0b'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <interface type='bridge'>
      <mac address='fa:16:3e:c8:19:5f'/>
      <source bridge='qbrfa3b674c-8b'/>
      <target dev='tapfa3b674c-8b'/>
      <model type='virtio'/>
      <alias name='net2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </interface>
    <interface type='bridge'>
      <mac address='fa:16:3e:2d:bd:ca'/>
      <source bridge='qbra95ba80b-ca'/>
      <target dev='tapa95ba80b-ca'/>
      <model type='virtio'/>
      <alias name='net1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </interface>
 
Step3. Reboot a VNF; Stop and Start a VNF with OpenStack API; “alias name” and “slot” values are updated
 
    <interface type='bridge'>
      <mac address='fa:16:3e:c0:04:f4'/>
      <source bridge='qbr0ad360c3-0b'/>
      <target dev='tap0ad360c3-0b'/>
      <model type='virtio'/>
      <alias name='net0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <interface type='bridge'>
      <mac address='fa:16:3e:c8:19:5f'/>
      <source bridge='qbrfa3b674c-8b'/>
      <target dev='tapfa3b674c-8b'/>
      <model type='virtio'/>
      <alias name='net1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </interface>
    <interface type='bridge'>
      <mac address='fa:16:3e:2d:bd:ca'/>
      <source bridge='qbra95ba80b-ca'/>
      <target dev='tapa95ba80b-ca'/>
      <model type='virtio'/>
      <alias name='net2'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </interface>
 

how to make the new network port become net1 again or why did?

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
how to make the new network port become net1 again or why did it changes net/mac address did openstack store this info in database & during reboot create xml file again , isi t expected behavior
Comment 2 Sahid Ferdjaoui 2017-07-12 03:40:13 EDT
That looks to be duplicated of 

https://bugzilla.redhat.com/show_bug.cgi?id=1293499
https://bugzilla.redhat.com/show_bug.cgi?id=1233920

Can you confirm that?
Comment 3 Anil Dhingra 2017-07-12 06:51:15 EDT
Looks some how similar but here just normal port depletion from 1 network & adding another port from other network changes port order 

 Cisco ESC is doing it whats the best way to handle this scenario .Its OSP 8 so tagging cant be used
Comment 4 Artom Lifshitz 2017-07-12 11:36:57 EDT
> how to make the new network port become net1 again or why did it changes
> net/mac address did openstack store this info in database & during reboot
> create xml file again , isi t expected behavior

I agree that it's frustrating, but network interface ordering and/or naming was never guaranteed to be preserved, especially through reboots. This is working as designed, and the solution would be to use device tagging in OSP10. Earlier than OSP10 nothing much can be done, unfortunately. If the customer is sticking with OSP8 in the long term, perhaps something can be changed about how Ciso ESC handles updating ports in order to keep the interface attached and avoid this issue altogether.
Comment 5 Artom Lifshitz 2017-07-12 11:46:24 EDT
I should add that while OSP10 has device tagging at instance boot time (ie, booting an instance with a tagged network interface), *attaching* a network interface with tags will only ship in OSP12, and even then in an unsupported state because it missed our internal deadline.
Comment 9 awaugama 2017-08-30 13:53:26 EDT
WONTFIX/NOTABUG therefore QE Won't automate

Note You need to log in before you can comment on or make changes to this bug.