VM network interfaces - VDU connection points

KLuka commented 8 years ago

There are two problems with attaching network interfaces to VMs.

When more "connection_points" are defined we get one additional interface. See eth0 to eth4 in case bellow. This makes network configuration very hard to do in VM.
It would be very useful if interface order can be preserved in VMs. Like when booting VMs with Nova. This is needed so more networks can be used without the complicated logic in orchestration scripts. For example this would enable easy mappings like:
- NIC1 -> eth0 -> mgmt-network
- NIC2 -> eth1 -> service-network

What do you guys think?

Sample VNFD:

        ...
        "connection_point": [
                {
                        "virtual_link_reference": "lkra-mgmt-1"
                },
                {
                        "virtual_link_reference": "lkra-mgmt-2"
                },
                {
                        "virtual_link_reference": "lkra-mgmt-3"
                },
                {
                        "virtual_link_reference": "lkra-mgmt-4"
                }
        ]
        ...

Acctual status of interfaces on deployed VM:

ci-info: +--------+-------+---------------+---------------+-------------------+
ci-info: | Device |   Up  |    Address    |      Mask     |     Hw-Address    |
ci-info: +--------+-------+---------------+---------------+-------------------+
ci-info: |   lo   |  True |   127.0.0.1   |   255.0.0.0   |         .         |
ci-info: |  eth4  | False |       .       |       .       | fa:16:3e:94:96:e2 |
ci-info: |  eth3  | False |       .       |       .       | fa:16:3e:91:a0:88 |
ci-info: |  eth2  | False |       .       |       .       | fa:16:3e:b6:20:91 |
ci-info: |  eth1  | False |       .       |       .       | fa:16:3e:b1:bb:02 |
ci-info: |  eth0  |  True | 192.168.104.6 | 255.255.255.0 | fa:16:3e:dc:02:97 |
ci-info: +--------+-------+---------------+---------------+-------------------+

eth0: lkra-mgmt-4
eth1: lkra-mgmt-1
eth2: lkra-mgmt-1
eth3: lkra-mgmt-3
eth4: lkra-mgmt-2

Database:

mysql> select * from vnfdconnection_point;
+--------------------------------------+------+---------+-------------+------------------------+
| id                                   | type | version | floating_ip | virtual_link_reference |
+--------------------------------------+------+---------+-------------+------------------------+
| 151ad370-2698-4ad4-af3c-433a9dabe535 | NULL |       0 | NULL        | lkra-mgmt-2            |
| 2588d9ed-9b82-4c30-ba6b-a0dc5ebf48e5 | NULL |       0 | NULL        | lkra-mgmt-4            |
| 833ab552-7d32-4228-a5c7-5c8af7455ab4 | NULL |       0 | NULL        | lkra-mgmt-1            |
| 851dbf95-764f-4a56-ad6c-e2709110a33b | NULL |       0 | random      | lkra-mgmt-1            |
| a87aad89-b69e-4a31-9090-ffb015eb541b | NULL |       0 | NULL        | lkra-mgmt-3            |
+--------------------------------------+------+---------+-------------+------------------------+

gc4rella commented 8 years ago

Hi @KLuka, preserving order in which interfaces are allocated to the VMs was not possible using the openstack APIs some time ago. We had the same issues for some of our VNFs. Let me collect the latest information we have, and we'll let you know.

KLuka commented 8 years ago

@gc4rella thanks for the answer.

I was not aware of this. We are using Mirantis OpenStack - Liberty and from our tests we assumed that order is preserved by default. Tests were made with Nova boot command, Horizon dashboard and HEAT module (see this example: https://gist.github.com/KLuka/a23c1490d49e3fa23f858f510a6e5c94).

I found some bug reports, but I think that they solved the ordering issues: https://bugs.launchpad.net/mos/+bug/1501430

Anyway I hope it will be possible to achieve this with OpenBaton...

What about additional interface issue, did you guys maybe noticed it? Currently I am not able to reproduce it, but I noticed that OpenBaton sometimes creates extra networks (and subnets) even if names of existing networks are provided as "virtual_link_reference". For example:

lkra-mgmt + lkra-mgmt-1-sub - precreated in Horizon
lkra-mgmt-1_subnet - created by OpenBaton

Also created networks (and subnets) don't get deleted after I delete NSR.

lkra@ubuntu-lkra:~$ neutron --insecure net-list | grep lkra-mgmt-
| 7d429ec2-d0ad-45d1-a93f-3b38f31ac305 | lkra-mgmt-1        |                                                       |
| cfc0fcbb-f7fd-42c8-99b0-7d96c857a814 | lkra-mgmt-2        | 4dfcbdb6-6de7-49c0-ad94-8e7d5c2d2929 192.168.138.0/24 |
| a4a7d573-7aaf-4c8c-9d2d-4ffdd52ef8d3 | lkra-mgmt-1        | 1be16fc2-0e54-4cca-9608-7368e6193f51 192.168.224.0/24 |
| ac0fd183-5ac1-48a4-a6a2-be7929905c3b | lkra-mgmt-4        | 103f90ef-b684-4a00-b223-59aa7305aba6 192.168.104.0/24 |
| 7c2a8443-2828-44da-89c9-8a95e8b00ebd | lkra-mgmt-1        | fec6a334-6967-43c1-83a4-fc1d5023c79c 192.168.101.0/24 |
| 5b1ab51b-cd1f-41ce-98d1-3ca8bb3abe16 | lkra-mgmt-2        | a83c8a0b-c4c8-47ee-bce8-774c3e6a651f 192.168.203.0/24 |
| bdcfce6b-162c-4409-b5c7-f3eeded7c5ff | lkra-mgmt-3        | 97d0dae2-4c57-49d7-a096-e3ec14b58276 192.168.187.0/24 |
| 2cdb8597-5cfb-43b7-b4bd-e08a5a75a69d | lkra-mgmt-3        | 55baf2c7-64d9-469e-8bad-bca573543d92 192.168.108.0/24 |
| a003ddc9-b157-454b-afc1-bd4a42078ace | lkra-mgmt-3        | 3248a7ae-f5e2-4a64-be97-dbf27af0282f 192.168.103.0/24 |
lkra@ubuntu-lkra:~$ neutron --insecure subnet-list | grep lkra-mgmt-
| 4dfcbdb6-6de7-49c0-ad94-8e7d5c2d2929 | lkra-mgmt-2-sub            | 192.168.138.0/24 | {"start": "192.168.138.2", "end": "192.168.138.254"} |
| 2b322443-3309-4d82-ac84-f80286fce800 | lkra-mgmt-sub              | 192.168.118.0/24 | {"start": "192.168.118.2", "end": "192.168.118.254"} |
| 103f90ef-b684-4a00-b223-59aa7305aba6 | lkra-mgmt-4-sub            | 192.168.104.0/24 | {"start": "192.168.104.2", "end": "192.168.104.254"} |
| 97d0dae2-4c57-49d7-a096-e3ec14b58276 | lkra-mgmt-3_subnet         | 192.168.187.0/24 | {"start": "192.168.187.2", "end": "192.168.187.254"} |
| a83c8a0b-c4c8-47ee-bce8-774c3e6a651f | lkra-mgmt-2_subnet         | 192.168.203.0/24 | {"start": "192.168.203.2", "end": "192.168.203.254"} |
| 1be16fc2-0e54-4cca-9608-7368e6193f51 | lkra-mgmt-1_subnet         | 192.168.224.0/24 | {"start": "192.168.224.2", "end": "192.168.224.254"} |
| 55baf2c7-64d9-469e-8bad-bca573543d92 | lkra-mgmt-3_subnet         | 192.168.108.0/24 | {"start": "192.168.108.2", "end": "192.168.108.254"} |
| fec6a334-6967-43c1-83a4-fc1d5023c79c | lkra-mgmt-1-sub            | 192.168.101.0/24 | {"start": "192.168.101.2", "end": "192.168.101.254"} |
| 3248a7ae-f5e2-4a64-be97-dbf27af0282f | lkra-mgmt-3-sub            | 192.168.103.0/24 | {"start": "192.168.103.2", "end": "192.168.103.254"} |

Urban123 commented 8 years ago

Hi,

I tried to solve the issue and with a little help I can create a PR. The issue of adding the same multiple networks is also solved jclouds https://issues.apache.org/jira/browse/JCLOUDS-1129#

But I'm having trouble maintaining the order of connection_points. I changed the implementation from Set to List and added order column to the table vnfdconnection_point in the database. So when I upload a vnfd the order is filled with correct order numbers. The problem that I have, when I press launch, the NSR is created and connection points are copied without the order column and numbers and the order is lost.

How can I copy order number, so that also NSR will contain it. Can you point to, where in code that happens...

Regards, Urban

mpauls commented 7 years ago

Feature introduced by commit 27ee85e

openbaton / NFVO

VM network interfaces - VDU connection points #15