Openstack configuration

THIS PAGE IS DEPRECATED. OSM User Guide has been moved to a new location: https://osm.etsi.org/docs/user-guide/

---

Configure openstack for OSM (basic)

1. Guarantee that Openstack API endpoints are reachable from OSM (particularly from RO container)

2. Create a management network, with DHCP enabled, reachable from OSM (particularly from VCA container)

You need to create a management network, with DHCP enabled, and guarantee that this management network is reachable from OSM. The network is used by the VCA (Juju) for configuring the VNFs once they are running. It is recommended to create a provider network, isolated from Openstack. For instance, in order to create a provider network using physical interface em1 and VLAN 500 and with CIDR 10.208.0.0/24, you should run the following commands:

neutron net-create mgmt --provider:network_type=vlan --provider:physical_network=physnet_em1 --provider:segmentation_id=500 --shared
neutron subnet-create --name subnet-mgmt mgmt 10.208.0.0/24 --allocation-pool start=10.208.0.2,end=10.208.0.254

3. Create a valid tenant/user

You need to create a tenant/user with rights to create/delete flavors. The easiest way is to create a user and assign it the role "admin". Another option is to change the general flavor management policies at file /etc/nova/policy.json to allow flavor creation per user.

4. Upload images

For the time being, it is required to upload the images of the VNFs manually at openstack, using the following command:

openstack image create --file="./cirros-0.3.4-x86_64-disk.img" --container-format=bare --disk-format=qcow2 --public cirros034

5. Modify default security group or create a new one

By default openstack apply the "default" security group that blocks any incoming traffic to the VM. However ssh access might be needed by VCA. You must modify the default security group to allow TCP port 22, or create a new security group and configure RO to use this security group when datacenter is addeed (see Add openstack to OSM )

Configure Openstack for full EPA support in OSM

Besides the instructions above for any Openstack, you should do extra configuration to configure Openstack for running VNFs which use SRIOV interfaces.

DO NOT consider this as the final configuration guide for Openstack with EPA. Please check Openstack docs and Openstack downstream distros' docs to get a further understanding and the up-to-date required configuration.

Note: The configuration shown below works with Openstack Newton, and it might not work with later versions.

• The compute nodes need to have a whitelist for the interfaces with SRIOV and passthrough enabled, and those interface need to be associated to a physical network label e.g. “physnet”. This can be done in the file /etc/nova/nova.conf :

pci_passthrough_whitelist=[{"devname": "p3p1", "physical_network": "physnet"}, {"devname": "p3p2", "physical_network": "physnet"}]

• The neutron controller needs to be updated to add “sriovnicswitch” to the mechanism_drivers. This can be done in the file “/etc/neutron/plugins/ml2/ml2_conf.ini”

mechanism_drivers =openvswitch,sriovnicswitch

• The neutron controller needs to be updated to set the vlans to be used for the defined physical network label. This can be done in the file “/etc/neutron/plugins/ml2/ml2_conf.ini”. For instance, to set the vlans from 2000 to 3000:

network_vlan_ranges =physnet:2000:3000

• The neutron controller needs to be updated to allow the supported NIC vendor’s product ID. This can be done in the file “/etc/neutron/plugins/ml2/ml2_conf.ini” to

[ml2_sriov]
supported_pci_vendor_devs = 8086:10ed

• The nova controller needs to be updated to allow proper scheduling of SR-IOV and Passthrough devices, by adding the PciPassthroughFilter filter to the list of filters. This can be done in the file “/etc/nova/nova.conf”:

scheduler_available_filters=nova.scheduler.filters.all_filters
scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,CoreFilter, PciPassthroughFilter

The previous configuration has been collected from the links below. Please check them to get more details:

• https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/network_functions_virtualization_product_guide/
• https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/network_functions_virtualization_planning_guide/
• https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/network_functions_virtualization_configuration_guide/
• https://docs.openstack.org/newton/networking-guide/config-sriov.html

Add openstack to OSM

There is a parameter called --config used to supply general configuration options. This paremeter can be used when creating the datacenter using the OSM client or when adding the datacenter directly to the RO (both at datacenter creation and datacenter attachment to openmano tenant -the latter prevails-).

The following configuration can be added:

• management_network_id, management_network_name: VIM management network id/name to use for the management VLD of NS descriptors. By default it uses same vim network name as VLD name. It can be set also at instantiation time.
• security_groups: To be used for the deployment
• availability_zone: To be used for the deployment. It can be:
  • a single availability zone (all deployments will land in that zone), e.g. 'availability_zone: controller'
  • several availability zones, which enables affinity and anti-affinity deployments, e.g. 'availability_zone: [zone1, zone2]'
• region_name: The region where the VM must be deployed.
• insecure: (By default false). When true it allows authorization over a non trusted certificate over https
• ca_cert: (incompatible with insecure). root certificate file to use for validating the openstack certificate
• use_existing_flavors: (By default false). Set to "True" to use the closer flavor with enough resources instead of creating a new flavor with the exact requirements. This option does not work for EPA (cpu pinning, huge pages, ...) where openmano still tries to create a flavor with the needed extra expects. Use this options when you do not have admin credentials (Available from future v2.0.2 version)
• vim_type: Set to "VIO" to use VMware Integrated openstack as VIM
• use_internal_endpoint: Set to True to force using internal endpoints

For openstack API v3, the following parameters are required:

• project_domain_id, project_domain_name: If not provided, "default" is used for project_domain_id
• user_domain_id, user_domain_name: If not provided, "default" is used for user_domain_id
• APIversion. Only required if the auth-url URL does not end with "v3". Set it to "v3.3" or "3" to use this openstack API version.

ADVANCED configuration:

• keypair: To be added in addition to the keypair allocated on the VNF descriptor. Provide the name of an openstack keypair
• dataplane_physical_net: The physical network label used in Openstack both to identify SRIOV and passthrough interfaces (nova configuration) and also to specify the VLAN ranges used by SR-IOV interfaces (neutron configuration). In case of VMware Integrated Openstack (VIO) provide moref ID of distributed virtual switch.
• use_floating_ip: (By default false). When boolean true, a management interface of a VNFD is automatically assigned a floating_ip -if possible-. If there is not any floating ip avalialble, it tries to get one if there is only one pool. You can use a string "pool_id" (public network id) instead of boolean true, to indicate the pool to use in case there are several. Note that deployment is not aborted if failing to asign a floating ip. The prefered method instead of this is to use a provider network
• dataplane_net_vlan_range: In case of VMware Integrated Openstack (VIO) provide vlan ranges for the SRIOV (binding direct) networks in format ['start_ID - end_ID']
• microversion: This is an Openstack-only parameter that allows to specify a specific microversion to be used in nova. When using 'microversion: 2.32', it enables the use of Virtual Device Role Tagging, which allows to identify each VM interface with a tag (the tag will be the name of the interface in the VNFD) and convey that information to the VM as metadata. This implementation approach is due to the warning message in https://developer.openstack.org/api-guide/compute/microversions.html where it is stated that microversion backwards compatibility is not guaranteed and clients should always require a specific microversion. This functionality was introduced would not work with Openstack versions previous to Newton.
• no_port_security_extension: Use for those openstack that do not have the port_security_extension. This property allows neutron to disable the port security. If this option is set, port security will never be disabled regardless of the descriptor indication.
• disable_network_port_security: Use for those openstack that do not support port security enabled at network level (although port_security_extension is present). This property allows neutron to disable the port security by default at the time of network creation for all ports created on the created networks.

The content of config is a yaml format text. The recomendation is to use a comma separated list between curly brackets {} and quotes. For instance, the following config is used to add a VMware Integrated Openstack where floating IP addresses will be assigned to VNF mgmt interfaces, all deployments must land in the availability_zone "controller", and the vlan ranges for the SRIOV networks will be 1-5 and 7-10:

--config='{use_floating_ip: True, availability_zone: zone1, dataplane_net_vlan_range: ["1-5" , "7-10"]}}'

Using the OSM client

osm vim-create --name openstack-site --user admin --password userpwd --auth_url http://10.10.10.11:5000/v2.0 --tenant admin --account_type openstack --config='{security_groups: default, keypair: mykey}'