4. Setup of Virtual Infrastructure Managers (VIMs)
4.1. OpenStack
4.1.1. Preparing your OpenStack to be used by OSM
This sections enumerates the steps to make an OpenStack accessible for its use from OSM.
4.1.1.1. 1. Guarantee that OpenStack API endpoints are reachable from OSM
(particularly, it should be reachable from RO container)
4.1.1.2. 2. Create a management network, with DHCP enabled, reachable from OSM
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
4.1.1.3. 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 (usually at config file /etc/nova/policy.json) to allow flavor creation per user.
4.1.1.4. 4. Modify default security group or create a new one
By default OpenStack applies the default security group that blocks any incoming traffic to the VM. However, ssh access might be needed by VCA.
Therefore, you will need to modify the default security group to allow TCP port 22, or create a new security group and configure OSM to use this security group when the VIM target is addeed (see below Adding an OpenStack VIM target to OSM).
4.1.1.5. 5. Remember to upload any images required (optional)
For the time being, it is required to upload the images of the VNFs to your VIMs, so that they are available before an instantiation.
This can happen anytime, and it is an optional step during the preparation phase, but you should always make sure that all the images that are required for a given NS/NSI are available in the VIM target before instantiation (otherwise, OSM will throw the corresponding error message).
In the case of OpenStack, you would typically use a variant of the following command to upload an image:
openstack image create --file="./cirros-0.3.4-x86_64-disk.img" --container-format=bare --disk-format=qcow2 --public cirros034
4.1.2. Adding an OpenStack VIM target to OSM
Here is an example on how to use the OSM Client to add an OpenStack VIM:
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}'
As it can be seen above, there is a parameter called --config used to supply general configuration options, which can be used when creating the VIM target using the OSM client.
A number of configuration options are supported:
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 deploymentavailability_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: controllerseveral availability zones, which enables affinity and anti-affinity deployments, e.g.
availability_zone: [zone1, zone2]
neutron_availability_zone_hints: To be used for the deployment. It can be:a single availability zone, e.g.
neutron_availability_zone_hints: controllerseveral availability zones, e.g.
neutron_availability_zone_hints: [zone1, zone2]
region_name: The region where the VM will be deployed.insecure: (By default false). When true it allows authorization over a non trusted certificate over httpsca_cert: (incompatible with insecure). root certificate file to use for validating the OpenStack certificateuse_existing_flavors: (By default,False). Set toTrueto 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 RO 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 VIMuse_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,defaultis used forproject_domain_iduser_domain_id,user_domain_name: If not provided,defaultis used foruser_domain_idAPIversion. Only required if the auth-url URL does not end withv3. 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 keypairdataplane_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 Openstack, this is typically configured innetwork_vlan_rangesparam as part of neutron ML2 configuration. In case of VMware Integrated Openstack (VIO), it is the ID of the 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 stringpool_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 preferred method instead of this is to use a provider networkdataplane_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 usingmicroversion: 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 VIMs 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 the config is a text formatted in yaml. The recommendation is to use a comma separated list between curly brackets {} and quotes "".
4.1.2.1. Adding a VMware Integrated OpenStack (VIO) as VIM target
Although VIO works as a regular OpenStack in practice, additional options may be needed to add a VIO VIM to OSM, so that OSM has all the credentials that it needs.
For instance, you can use the following command, which includes some extra parameters, to add a VIM target with VIO (e.g. site name: openstack-site-vio4, IP address: 10.10.10.12, VIM tenant: admin, user: admin, password: passwd)
osm vim-create --name VIO --user admin --password passwd --auth_url https://10.10.10.12:5000/v3 --tenant admin \
--account_type openstack --config '{use_floating_ip: True, insecure: true, vim_type: VIO, APIversion: v3.3,
dataplane_physical_net: dvs-46, "use_internal_endpoint":true,"dataplane_net_vlan_range":["31-35","37-39"]}'
With respect to a regular Openstack, these additional configuration parameteres are added:
vim_type: Set toVIOto use VMware Integrated openstack as VIM.use_internal_endpoint: Whentrueit allows use of private API endpoints.dataplane_physical_net: The ID of the distributed virtual switch e.g ‘dvs-46’ in above configuration.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'].vrops_site: URI of vRealize Operations (vROPS) endpoint used by OSM to get infrastructure metrics.vrops_user: user of vRealize Operations (vROPS) used by OSM to authenticate against vROPS to read infrastructure metrics.vrops_password: password of vRealize Operations (vROPS) used by OSM to authenticate against vROPS to read infrastructure metrics.
For common options, you may refer to the general OpenStack Setup Guide.
4.2. OpenVIM
4.2.1. Setting up an OpenVIM environment
A full step-by step guide for installing an OpenVIM environment from scratch can be found in a specific chapter.
4.2.2. Adding OpenVIM as VIM target to OSM
To add and OpenVIM account as VIM target, you shoulld execute the following command, using the appropriate parameters (e.g. site name: openvim-site, IP address: 10.10.10.10, VIM tenant: osm)
osm vim-create --name openvim-site --auth_url http://10.10.10.10:9080/openvim --account_type openvim \
--description "Openvim site" --tenant osm --user dummy --password dummy
4.3. VMware’s vCloud Director
4.3.1. Preparing your vCloud Director to be used by OSM
In order to get the
vim-tenant_namefrom vCloud Director and/or the tenant UUID, you should execute:
./vmwarecli.py -u admin -p 12345 -c vcloud_host_name -U Administrator -P 123456 -o test list vdc
+--------------------------------------+----------+
| vdc uuid | vdc name |
+--------------------------------------+----------+
| 605ad9e8-04c5-402d-a3b7-0b6c1bacda75 | test |
| a5056f85-418c-4bfd-8041-adb0f48be9d9 | TEF |
+--------------------------------------+----------+
In this example two VDC (tenants) are available for organization
testCreate default network by either using Web UI of vCloud director or
vmwarecli.py
./vmwarecli.py -u admin -p 123456 -c vcloud_host_name -U Administrator -P 123456 -o test -v TEF create network test
Crated new network test and uuid: bac9f9c6-6d1b-4af2-8211-b6258659dfb1
View organization/dataceter.
./vmwarecli.py -u admin -p 123456 -c vcloud_host_name -U Administrator -P 123456 -o test view org test
+--------------------------------------+----------+
| vdc uuid | vdc name |
+--------------------------------------+----------+
| 605ad9e8-04c5-402d-a3b7-0b6c1bacda75 | test |
| a5056f85-418c-4bfd-8041-adb0f48be9d9 | TEF |
+--------------------------------------+----------+
+--------------------------------------+-------------------------------------------+
| network uuid | network name |
+--------------------------------------+-------------------------------------------+
| f2e8a499-c3c4-411f-9cb5-38c0df7ccf8e | default |
| 0730eb83-bfda-43f9-bcbc-d3650a247015 | test |
+--------------------------------------+-------------------------------------------+
+--------------------------------------+--------------+
| catalog uuid | catalog name |
+--------------------------------------+--------------+
| 811d67dd-dd48-4e79-bb90-9ba2199fb340 | cirros |
| 147492d7-d25b-465c-8eb1-b181779f6f4c | ubuntuserver |
+--------------------------------------+--------------+
4.3.1.1. Image preparation for VMware
If a user needs on-board image that is not a VMware compatible disk image format such as qcow. User need to convert qcow image to an OVF.
The first step is convert qcow disk image to vmdk.
qemu-img convert -f qcow2 cirros-disk.img -O vmdk cirros-0.3.4-x86_64-disk.vmdk
Second step.
Click “New in VMware Fusion , Vmware workstation or vCenter and create a VM from VMDK file created in step one.
Third step
Adjust hardware setting for VM. For example, if target VMs should have only one vNIC delete all vNIC.
OSM will set up and attach vNIC based on VNF file.
Make sure hardware version for VM set to 11 or below.
Export VM as OVF and upload file to OSM.
Example of folder structure inside VNF directory. Each exported image placed inside ovfs directory.
drwxr-xr-x 2 spyroot staff 68 Oct 4 19:31 cirros
-rw-r--r-- 1 spyroot staff 13287936 May 7 2015 cirros-0.3.4-x86_64-disk.img
-rw-r--r-- 1 spyroot staff 21757952 Oct 4 19:38 cirros-0.3.4-x86_64-disk.vmdk
-rwxr-xr-x 1 spyroot staff 57 Oct 4 18:58 convert.sh
drwxr-xr-x 10 spyroot staff 340 Oct 4 07:24 examples
drwxr-xr-x 3 spyroot staff 102 Oct 4 19:41 ovfs
-rw-r--r-- 1 spyroot staff 11251 Oct 4 07:24 vnf-template-2vm.yaml
-rw-r--r-- 1 spyroot staff 5931 Oct 4 07:24 vnf-template.yaml
bash$ ls -l ovfs/cirros/
total 25360
-rw-r--r-- 1 spyroot staff 12968960 Oct 4 19:41 cirros-disk1.vmdk
-rw-r--r-- 1 spyroot staff 125 Oct 4 19:41 cirros.mf
-rw-r--r-- 1 spyroot staff 5770 Oct 4 19:41 cirros.ovf
Note: You should create OVF image only once if all images of same VNF/OS share same hardware specs. The VM image used as reference VM in vCloud director. Each VM that OSM instantiates will use that image as reference.
VNF preparation step.
If image is uploaded at vCloud, reference it using the image name at VNFD descriptor.
If not, use a path of an existing image at host where OSM is running
4.3.2. Adding vCD as VIM target to OSM
osm vim-create --name vmware-site --user osm --password osm4u --auth_url https://10.10.10.12 --tenant vmware-tenant --account_type vmware --config '{admin_username: user, admin_password: passwd, orgname: organization, nsx_manager: "http://10.10.10.12", nsx_user: user, nsx_password: userpwd,"vcenter_port": port, "vcenter_user":user, "vcenter_password":password, "vcenter_ip": 10.10.10.14}'
There is a parameter called --config used to suply additional configuration:
orgname: (Optional) Organization name where tenant belong to. Can be ignored if –vim-tenant-name uses <orgname: tenant>admin_username: (Mandatory)Admin useradmin_password: (Mandatory) Admin passwordnsx_manager: (Mandatory). NSX manager host namensx_user: (Mandatory). nsx_usernsx_password: (Mandatory). nsx_passwordvcenter_port: (Mandatory).vCenter portvcenter_user: (Mandatory) vCenter usernamevcenter_password: (Mandatory). vCenter passwordvcenter_ip: (Mandatory). vCenter IPmanagement_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.
The content of config is a yaml format text. The recommendation is to use a comma separated list between curly brackets {} and quotes "", e.g.:
--config '{nsx_manager: https://10.10.10.12, nsx_user: user, nsx_password: pasword}'
4.4. Amazon Web Services (AWS)
4.4.1. Preparation for using AWS in OSM
4.4.1.1. 1. Get AWS_ACCESS_KEY_ID and AWS_SECRET_KEY for your AWS account
Check https://aws.amazon.com/
AWS User-ID/Secret-key will be required at the time of creation of the data-center. These credentials need not to be updated after creation of the data-center.
4.4.1.2. 2. Create/get key-pairs from your AWS management console
These key-pairs will be required later for deploying a NS.
SSH key-pairs need to be specified in the VNF descriptors. This update can be done via OSM CLI as well as OSM UI. SSH key-pars can only be created using the AWS mgmt console. OSM will get updated of any changes that occur in AWS console. OSM user is required to keep record of these key-pairs, for use in later cases.
4.4.1.3. 3. Create a management network using AWS management console
If the user does not specify any default mgmt interface, OSM will create a default network that will be used for managing AWS instances.
Once the NS is deployed it will require a management interface (subnet) to apply configurations on the instances. User can manually create this mgmt interface using AWS console or leave it for OSM connector. The procedure of creating the interface from AWS is to create a subnet by specifying the appropriate CIDR block. This subnet is required to have DHCP enabled. AWS being a public cloud is accessible from OSM. The network is used by the VCA for configuring the VNFs once they are running.
4.4.1.4. 4. Create a valid user
Default user in AWS has the rights to perform all operations of AWS instances, subnets, VPCs, key-pairs, etc. In case, you want to create a secondary user with limited set of rights, you can use AWS mgmt console. NOTE: Each user in AWS has a separate access-Key/secret-key which must be kept secure else new credentials must be generated. The preferred way is to create a user and assign it the role “admin”. Another option is ensure that the user has all the rights required to operate in AWS environment.
4.4.1.5. 5. Find and select images
AWS has a repository with many images available to be used for instances. In case you require to create a custom image, you can use AWS console and create your own images. In case you decide to use a pre-built image you will need to specify full mage path in VNF descriptor.
4.4.1.6. 6. Security group
AWS provides a default security_group defining a set of rules that allow connection access to the instances that have this security_group. In case, you require a new security_group you can create a new group defining the conditions that are required by your use case.
Default security_group doesn’t allow user to SSH into the instances. This behavior is not recommended by OSM, as VCA requires a path to interact with instances. Hence, it is recommended that you create a new group that contains the rules/conditions required to SSH into the instances deployed by this NS. You can also modify the default security group to allow TCP port 22 or, however, creation of a custom security_group is recommended.
4.4.2. Adding AWS as VIM target to OSM
You will need to specify some options at VIM target creation/association by using the --config parameter. For instance:
osm vim-create --name aws-site --account_type aws \
--auth_url https://aws.amazon.com \
--user MyUser --password MyPassword --tenant admin \
--description "AWS site, with your user" \
--config '{region_name: eu-central-1, flavor_info: "{t2.nano: {cpus: 1, disk: 100, ram: 512}, t2.micro: {cpus: 1, disk: 100, ram: 1024}, t2.small: {cpus: 1, disk: 100, ram: 2048}}"}'
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.region_name: Region to be used for the deploymentvpc_cidr_block: Default CIDR block for VPCsecurity_groups: Default security group for newly created instances
ADVANCED configuration:
key_pair: Key_pair specified here will be used default key_pair for newly created instancesflavor_info: AWS doesn’t provide a mechanism to extract information regarding supported flavors. In order to get flavor information, user must specify a YAML file with the path such as: “@/usr/data/flavour_info.yaml” or user can specify a dictionary containing details of flavors to be used.
For specification of flavor info at time of datacenter creation use a parameter at --config called e.g. flavor_info:. The content must be a string. It can be a file starting with ‘@’ that contains the info in YAML format, or directly the yaml content.
NOTE: Details on AWS flavors/instance types can be found at Amazon Web Services docs (https://aws.amazon.com/ec2/instance-types/). Flavors/instance types in AWS vary depending on the region of AWS account. Above mentioned link provides details on all possible instance types. However to get details on the instance types available for your region, use your AWS management console.
4.5. Microsoft Azure
4.5.1. Preparation for using Azure in OSM
4.5.1.1. 1. Obtain Azure credentials and tenant from Microsoft Azure
In order to use a VIM target based on Azure, the following information needs to be gathered:
Azure
subscription Id.The
tenant Id, to be created or obtained in the Microsoft portal.Access credentials:
client_id: This attribute corresponds to theapplication Idof a service principal with the right permissions. Regular Azure users currently are not supported.The
authentication Key.
Resource Group: All Azure resources for a VIM target will be created into the same
resource_group. Said resource group could exist before or, in case it did not exist, OSM would try to create it upon the creation of the VIM target (the latter would require that your user/service principal had sufficient privileges in the subscription - check with your administrator).
The above data can be learned through the Azure portal or the Azure CLI. For instance, once logged in, the command az account list returns, among other information, the application Id, the tenant Id, and the subscription Id.
4.5.1.2. 2. Create Microsoft Azure Virtual Network
The virtual networks created for the Azure VIM will all be created as subnets from a base virtual network vnet_name. This base virtual network should be created before adding the VIM target and will also be provided as a configuration parameter.
It is also recommended to create a management subnet in that virtual network for the VIM network services, and both vnet and subnet can be created in a single step. For example, this command creates in osmRG resource group (must exist) the osm_vnet virtual network and the internal management subnet which uses 10.0.0.0/24 address prefix:
az network vnet create --resource-group osmRG --name osm_net --subnet-name internal --subnet-prefixes "10.0.0.0/24"
4.5.2. Adding Microsoft Azure as VIM target in OSM
To sum up, in order to defice a VIM target with Azure, the following command and options should be used:
osm vim-create --name azure --account_type azure --auth_url http://www.azure.com --tenant "tenant_id"
--user "client_id" --password "client_secret" --description "Azure site"
--config "{region_name: westeurope, resource_group: 'osmRG', subscription_id: 'subscription_id',
vnet_name: 'osm_vnet', flavors_pattern: 'flavors_regex'}"
where:
client_id: Corresponds to the service principal’sapplication id.client secret: Authentication key.subscription_id: Azuresubscription Idtenant: Azuretenant Id
Additional required configuration:
region_name: Region to be used for the deploymentresource_group: Resource group to be used as base for all resources created for this VIMvnet_name: Virtual name used as a base for this VIM subnets
Additional optional configuration:
flavors_pattern: Regular expression to be used during flavor selection. This allows to select the desired virtual machine tier. Microsoft Azure has a number of pre-created flavors available that cannot be changed. Hence, OSM will determine the flavor to be used based of the VDU requirements in the package, in terms of number of CPUs, RAM and disk. In the Azure portal there are also different virtual machine tiers available, intended for different purposes: e.g cheaper machine serieBasicwith no guaranteed throughput or more expensive machines with guaranteed throughput. For that reason, OSM allows to specificy such machine tiers in the VIM target definition by using theflavors_patternparameter. For example, aBasiccheaper tier can be selected when defining the VIM target of a development environment, and specify a more advanced tier for the VIM target of the production environment.
NOTE for VNF Onboarding: You need to make sure that your VNF packages include a reference to an appropriate alternative image in Microsoft Azure’s image repository. In case you are creating a VNF Package from scratch, please note you should use the full Azure image name: publisher:offer:sku:version (e.g. Canonical:UbuntuServer:18.04-LTS:18.04.201809110).
4.6. Google Cloud Platform
4.6.1. Preparation for using GCP in OSM
4.6.1.1. 1. Obtain GCP credentials and project from Google GCP
In order to use a VIM target based on Google Cloud, the following information needs to be gathered:
Access credentials file (
creds): the JSON key file corresponding to a GCP service account. If no service account is available, a new service account will have to be created underIAM > Service accounts. Then, once created, you can go toService accounts > Keysand create a new key in JSON format for the service account. The JSON key file will be automatically downloaded.The
project, the name of the Google Cloud project to be used to deploy IaaS resources (VM, nets, etc.).The
regionto be used to deploy IaaS resources (VM, nets, etc.).
The project and region can be obtained through the GCP portal or the GCP CLI. For instance, the command gcloud config list returns all properties of the active configuration, including the account used to authorize access to the GCP, the project and the region.
4.6.1.2. 2. Create Google GCP Virtual Network
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, these commands creates the osm_vnet virtual network and the internal management subnet which uses 10.10.0.0/24 address prefix:
gcloud compute networks create osm-net --subnet-mode=custom
gcloud compute networks subnets create internal --network=osm-net --range=10.10.0.0/24 --region=region_id
4.6.2. Adding GCP as VIM target in OSM
To sum up, in order to register a GCP VIM target in OSM, the following command and options should be used:
osm vim-create --name gcp --account_type gcp --project "<project>" --description "Google Cloud"
--config "{region_name: <region>, use_floating_ip: True}"
--creds <credential_json_file>
where:
project: corresponds to the project name.region: corresponds to the region name.credentials_json_file: Service account JSON file.use_floatinp_ipis set to True in order to allow automatic public IP addresses in all the interfaces connected to the management network of a NS.
NOTE for VNF Onboarding: You need to make sure that your VNF packages include a reference to an appropriate alternative image in Google Cloud’s image repository. In Google Cloud there are a set of public preconfigured images grouped in image projects. In case you are creating a VNF Package from scratch, please note you should use the following naming conventions to get the Google Cloud image:
<image_project>:image-family:<family>: to get the latest version of the images of the family<family>in the project<image_project>(e.g.ubuntu-os-cloud:image-family:ubuntu-1804-lts)<image_project>:image:<image>: to get a specific image<image>in the project<image_project>(e.g.ubuntu-os-cloud:image:ubuntu-1804-bionic-v20210928)<image_project>:<image>: equivalent to<image_project>:image:<image>(e.g.ubuntu-os-cloud:ubuntu-1804-bionic-v20210928)
4.7. Eclipse fog05
Eclipse fog05 (can be read as fog-O-five or fog-O-S) is a different kind of VIM, designed to manage a fog/edge environment, thus it is completely distributed (no controller/master node) and pluggable, and available as FOSS from Eclipse: https://github.com/eclipse-fog05
It stores information in a distributed key-value store that then is able to provide location transparency to the user, and all the state information are stored in it.
4.7.1. Upload Images
Image registration can be done by using the python rest API. First generate the descriptor of your image:
{
"name": "example-image",
"uri": "lxd://alpine/edge",
"checksum": "<sha256sum of image file",
"format": "<image format eg. qcow2, iso, tar.gz>"
}
the using the python api the upload of the image can be done:
>>>api.image.add(img_descriptor)
4.7.2. Adding Eclipse fog05 as VIM target of OSM
Alike the rest of VIM types, you should provide the appropiate paramenters in --config when creating the VIM target.
osm vim-create --name fos --auth_url <zenoh server ip>:7447 --account_type fos --tenant osm --user dummy --password dummy --config '{hypervisor: LXD}'
The following configuration can be added:
arch: cpu architecture used when creating the VDUs for this VIM account eg. x86_64, aarch64, default is x86_64.hypervisor: hypervisor supported by this VIM account, can be one of: LXD, KVM, BARE, DOCKER, ROS2, at least one node of the system as to be able to manage the selected hypervisor, default and supported is LXD.
4.7.2.1. VLAN configuration (optional)
If you want your fog05 installation to be able to use VLANs for virtual networks instead of overlay VxLANs you need to change the configuration on all nodes. You need to update the configuration file /etc/fos/plugins/linuxbridge/linuxbridge_plugin.json.
{
"name": "linuxbridge",
"version": 1,
"uuid": "d42b4163-af35-423a-acb4-a228290cf0be",
"type": "network",
"requirements": [
"jinja2"
],
"description": "linux Bridge network plugin",
"configuration": {
"ylocator": "tcp/<your zenoh ip>:7447",
"nodeid": "<your node id>",
"dataplane_interface": "<interface for overlay networks>",
"use_vlan": true,
"vlan_interface": "<interface for vlans>",
"vlan_range": [
<start vlan id>,
<end vlan id>
]
}
}
After that you have to restart the fog05 network and runtime plugins in the nodes.
4.7.2.2. Example NS
Here you can find and example of network service that can be instantiated to the Eclipse fog05 VIM using OSM. The network service is composed by a single VNF based on an Alpine Linux LXD image.
alpine-vnfd.yaml:
vnfd:vnfd-catalog:
vnfd:
- id: alpine_vnfd
name: alpine_vnf
short-name: alpine_vnf
description: Simple VNF example with a Alpine
vendor: OSM
version: '1.0'
logo: alpine.jpg
connection-point:
- name: eth0
type: VPORT
vdu:
- id: alpine_vnfd-LXD
name: alpine_vnfd-LXD
description: alpine_vnfd-LXD
count: 1
vm-flavor:
vcpu-count: 1
memory-mb: 256
storage-gb: 1
image: alpine-lxd
interface:
- name: eth0
type: EXTERNAL
virtual-interface:
type: VIRTIO
bandwidth: '0'
vpci: 0000:00:0a.0
external-connection-point-ref: eth0
mgmt-interface:
cp: eth0
alpine-ns.yaml:
nsd:nsd-catalog:
nsd:
- id: alpine_nsd
name: alpine_ns
short-name: alpine_ns
description: Generated by OSM pacakage generator
vendor: OSM
version: '1.0'
constituent-vnfd:
- member-vnf-index: 1
vnfd-id-ref: alpine_vnfd
vld:
### Networks for the VNFs
- id: alpine_nsd_vld1
name: alpine_nsd_vld1
short-name: alpine_nsd_vld1
type: ELAN
mgmt-network: 'true'
vnfd-connection-point-ref:
- member-vnf-index-ref: 1
vnfd-id-ref: alpine_vnfd
vnfd-connection-point-ref: eth0
4.8. What if I do not have a VIM at hand? Use of sandboxes
Sometimes, casual testers of OSM may not have a fully fledged VIM at hand, either on premises or in a public cloud. In those cases, it is also possible using a VIM sandbox which, although limited and hence not appropriate for production services, it can be an option good enough for beginners.
In the coming sections, a few options are described in detail.
4.8.1. ETSI OSM VNF Onboarding Sandbox for VNF Providers
ETSI OSM can provide to their members/participants a VNF Onboarding Sandbox for VNF Providers, based on its own testing infrastructure.
In practive, it will work as an account in a fully fledged VIM, so this alternative presents the advantage that it does not present the functional limitations that local sandboxes usually have.
More details about this option are in ellaboration and will be shared soon.
4.8.2. DevStack
DevStack is a series of extensible scripts used to quickly bring up a complete OpenStack environment based on the latest versions of everything from git master. It is used interactively as a development environment and as the basis for much of the OpenStack project’s functional testing.
The OpenStack Community provides fairly detailed documentation on DevStack and its different configurations.
Due to its simplicity, a configuration particularly interesting for running a sandbox with limited resources (e.g. in a laptop) is the All-In-One Single Machine installation.
4.8.2.1. Known limitations of DevStack
TODO: Under elaboration.
4.8.3. MicroStack
MicroStack is a single-machine OpenStack cloud sandbox, developed by Canonical, and deployable with a single snap packages. Currently provided OpenStack services are: Nova, Keystone, Glance, Horizon, and Neutron, which should suffice for any basic OSM testing.
Detailed documentation is available at https://snapcraft.io/microstack and https://opendev.org/x/microstack.
4.9. Advanced setups for high I/O performance: EPA and SDN Assist
4.9.1. Overview
OSM supports EPA (Enhanced Platform Awareness) since Rel ZERO (May 2016). EPA features like use of hugepages memory, CPU pinning, NUMA pinning, and the use of passthrough and SR-IOV interfaces, can be used in OSM’s VNF descriptors since then.
If your VIM supports EPA, then you don’t need to do anything extra to use it from OSM. VIM connectors in OSM take advantage of EPA capabilities if the VIM supports it. All you need to do is build your descriptors and deploy.
However, ot all VIMs support EPA necessarily. To overcome this limitation, OSM has added the following two features:
Since OSM Release ONE (October 2016), OSM includes OpenVIM as a reference VIM, with full support of EPA. You can follow the instructions in this link to install and use OpenVIM.
Since OSM Release TWO (April 2017), OSM includes a new capability in the Resource Orchestrator called SDN Assist. Through this capability, OSM can manage the dataplane underlay conectivity through an external SDN controller. The only requirement for the VIM is that it must able to use SR-IOV and/or passthrough interfaces, and expose the assigned interfaces so that the RO can use them to create the underlay connectivity. By default, the SDN Assist capability is disabled when a datacenter or VIM is added to OSM, but you can instruct OSM to enable it per VIM target.
4.9.2. SDN Assist
4.9.2.1. Why SDN Assist
SDN Assist works as follows to overcome the limitations of the VIM with respect to the underlay:
OSM deploys the VMs of a NS in the requested VIM target with Passthrough and/or SRIOV interfaces.
Then it retrieves from the VIM the information about the compute node where the VM was deployed and the physical interfaces assigned to the VM (identified by their PCI addressess).
Then, OSM maps those interfaces to the appropriate ports in the switch making use of the mapping that you should have introduced in the system.
Finally OSM creates the dataplane networks by instructing the SDN controller and connecting the appropriate ports to the same network.
The module in charge of this worflow OSM’s RO (Resource Orchestrator), which is provided transparently to the user. It uses an internal library to manage the underlay connectivity via SDN. The current library includes plugins for FloodLight, ONOS and OpenDayLight.
4.9.2.2. General requirements
The general requirements are:
A dataplane switch (until Release SIX, with Openflow capabilities) that will connect the physical interfaces of the VIM compute nodes.
An external SDN controller controlling the previous dataplane switch.
The mapping between the switch ports (identified by name) and the compute node interfaces (identified by host-id and PCI address)
Some VIMs as Openstack requires admin credentials in order to be able to get the physical place of the SRIOV/passthrough VM interfaces
In addition to the general requirements, every VIM will have to be properly configured.
4.9.2.3. VIM configuration for SDN Assist
You should do extra configuration to configure your VIM for running VNFs which use SR-IOV or passthrough interfaces.
You can find a thorough configuration guide for OpenStack VIMs with EPA later in this same chapter. For other types of VIMs, this guide can be also taken as model to understand the EPA properties that might be expected.
4.9.3. Using SDN Assist
4.9.3.1. Adding a SDN controller to OSM
This is done through CLI.
Add to OSM the SDN controller, provide credentials.
osm sdnc-create --name sdn-name --type arista \
--url https://10.95.134.225:443 --user osm --password osm4u \
--config '{mapping_not_needed: True, switch_id: ID}'
# The config section is optional.
# list sdn controllers with:
osm sdnc-list
# get details with:
osm sdnc-show sdn-name
# delete with
osm sdnc-delete sdn-name
Note that at SDN creation, connectivity and credentials are not checked.
Available SDN controller plugins (--type option) are onos_vpls, onosof, floodlightof, , dynpac; and comming odlof, arista, ietfl2vpn.
Depending on the pluging, the SDN controller needs to be fed with the mapping between the VIM compute node interfaces and the switch ports. In case this is not needed use the --config '{mapping_not_needed: True}'.
4.9.3.2. Associate the SDN controller to a VIM
To associate the SDN controller to a concrete VIM, the VIM must be updated. In this step the compute-node/swith-port mapping is provided:
osm vim-update vim-name --sdn_controller sdn-name --sdn_port_mapping port-mapping-file.yaml
This is an example of the port-mapping-file.yaml content:
- compute_node: nfv54
ports:
- pci: "0000:5d:00.1"
switch_id: Leaf1
switch_port: "Ethernet13/1"
- pci: "0000:5d:0a.0"
switch_id: Leaf1
switch_port: "Ethernet13/1"
- pci: "0000:5d:0a.1"
switch_id: Leaf1
switch_port: "Ethernet13/1"
- pci: "0000:5d:00.0"
switch_id: Leaf2
switch_port: "Ethernet13/2"
- pci: "0000:5d:02.0"
switch_id: Leaf2
switch_port: "Ethernet13/2"
- pci: "0000:5d:02.1"
switch_id: Leaf2
switch_port: "Ethernet13/2"
- compute_node: nfv55
# ...
NOTE: several PCI addresses can be connected to the same switch port. This is because a physical interface has several SR-IOV virtual interfaces, each one with different PCI address.
NOTE: The optional switch_id provided at --config is taken as a default if missing in the port-mapping file. This is useful if there is only one switch.
To overwrite the port mapping the same instruction can be used after modifying the port-mapping file.
You can check the associated SDN controller by:
osm vim-show vim-name
+-----------------+-----------------------------------------------------------------+
| key | attribute |
+-----------------+-----------------------------------------------------------------+
| _id | "bf900941-a6d3-4eba-9017-0cec657b9490" |
| name | "sdn-name" |
| vim_type | "openstack" |
| description | "some description" |
| vim_url | "https://192.168.1.1:5000/v3" |
| vim_user | "osm" |
| vim_password | "********" |
| vim_tenant_name | "osm" |
| config | { |
| | "insecure": true, |
| | "sdn-controller": "82b067c8-cb9a-481d-b311-59f68b75acae", |
| | "sdn-port-mapping": [ |
| | { |
| | "compute_node": "compute-66e153a8-c45", |
| | "ports": [ |
| | { |
| | "pci": "002f-0000:83:00.0-000", |
| | "switch_id": "Leaf1", |
| | "switch_port": "Ethernet52/1" |
You can disassociatede SDN controller from a VIM by:
osm vim-update vim-name --sdn_controller '' # attach an empty string
Note: detaching a SDN controller from the VIM is mandatory before deleting the SDN controller
4.9.4. 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 SR-IOV 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
sriovnicswitchto themechanism_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.inito
[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 taken as a reference the documents in the links below. Please check them in case your needed more details:
4.10. Distributed VCA
You can configure the VIM to use a Distributed VCA instead of using the default one. This section explains the details on how to set everything up.