Deployment Guide for Cloud Execution Environment (CEE)

Virtual Multimedia Resource Function

1 About This Document

This document describes vMRF deployment on a Cloud Execution Environment (CEE) cloud service. CEE is based on OpenStack, with additional features that expand its flexibility of use and meet the needs of telecommunication service providers.

The following user roles are distinguished in this document:

Cloud Administrator		The cloud administrator is the cloud service provider who delivers the cloud service to the end user. The cloud administrator must fulfill certain prerequisites before the end user can start deploying vMRF.

End User		The end user is the vMRF operator and deployment responsible, who is assumed to be a cloud service consumer on a CEE cloud service. The end user is also referred to as a tenant.

2 vMRF Deployment Principles for CEE

If the hardware and software requirements are met, and after the needed configurations in CEE are done, vMRF is instantiated.

vMRF can contain one or more Virtual Network Functions (VNF), for example, one or more Virtual Multimedia Resource Functions.

A single VNF contains multiple Virtual Machines (VMs). See Figure 1 for an example overview of vMRF deployment with two vMRF VNFs.

Figure 1 vMRF Deployment

3 vMRF Deployment Process for CEE

The vMRF deployment process consists of preparations and basic configuration of the cloud environment, and the actual instantiation of one or more VNF instances.

Figure 2 vMRF Deployment Process

Prepare the cloud environment to run vMRF

This set of steps is done by the cloud administrator.
1. Prepare and configure cloud hardware and software
  
  This step involves checking that the necessary hardware exists, and making hardware-related configuration in CEE, in the hypervisor and in the host Operating System so that the requirements listed in Prerequisites for vMRF Deployment are fulfilled.
2. Create a flavor
  
  Flavors in OpenStack are virtual resource templates that define RAM size, disk size, number of CPU cores, and so on, for running VNFs. For vMRF, a flavor must be used or created that has at least the minimum requirements.
3. Create the network topology
  
  This step involves ensuring that the required networks to which the VNF connects are in place.

Deploy and check vMRF

This set of steps is done by the end user.

Download and extract the vMRF software delivery package

The vMRF software delivery package contains the Virtual Machine Disk (VMDK) image file and the Heat Orchestration Template (HOT) files. The vMRF software delivery package must be extracted to a place where the files can be accessed from CEE.

Upload the vMRF image

The extracted VMDK image file must be uploaded using OpenStack Glance.

Note:

When using Cinder block storage, the Cinder volume is created from the Glance image during VNF stack creation. The Glance image is not to be deleted during VNF lifetime, as it is used for Cinder volume creation for VMs during scaling.

Prepare Initial Configuration Data

Initial configuration data means the data needed for vMRF to start processing traffic. If you are importing this initial configuration data during deployment, you must prepare it so that it matches your environment. For other options, see Initial Configuration Guide.
Prepare Deployment Parameters

The correct values of the deployment HOT template parameters must be specified in the example_environment.yaml file provided in the vMRF software delivery package.

Instantiate and Check vMRF with One VM

The vMRF instantiation is done by creating a stack in OpenStack Heat. This step is repeated for each VNF instance that needs to be created.

During instantiation, initial configuration data can also be imported into the VNF. This makes it possible for the VNF to have all necessary configuration for processing traffic right after being created.

Note:

If initial configuration data is not imported during instantiation, it must be performed after deployment. This is also recommended when deploying the VNF for the first time. For more information, see the Initial Configuration Guide.

Check vMRF status

It is recommended to run a status check on the newly deployed vMRF.
Scale Out to Full VNF Size

After the VNF is verified with one VM, you can scale out to the full size of the VNF by updating the vMRF stack.

4 Prerequisites for vMRF Deployment

Before the end user can deploy and use vMRF, the cloud administrator must ensure that the environment fulfills hardware, software, and network requirements. The main requirements are listed in vMRF Infrastructure Requirements.

4.1 Download and Extract vMRF Software Delivery Package

Before the deployment, the end user must download and extract the vMRF software delivery package. Both the end user and the cloud administrator must have access to the proper example files in the package.

Steps

Download the vMRF software delivery package to a computer from which the OpenStack clients are reachable.
Extract the vMRF software delivery package.

Check that the following files exist after extracting the vMRF software delivery package:

vMRF image (vmrf-image-corei7-mrsv.vmdk)
Deployment HOT file (vmrf.yaml file)
Example files, including an example environment yaml file

Note:

The yaml files included in the examples folder of the software delivery package serve as examples for a possible network configuration. They can be modified to match your network environment.

If Cinder block storage is used, vmrf.yaml and scaling_group.yaml must be edited to boot from volume. These HOT files contain sections for booting from image and volume. For booting from volume, the image booting sections must be commented out, and volume booting sections must be uncommented.

For deployment with the platform automatic IP address configuration option, use the HOT and yaml files from the cee folder of the software delivery package. Using this method, IP addresses are assigned by the virtualization infrastructure.

Ensure that all the extracted files are in the same folder.

5 vMRF Deployment Preparations for the Cloud Administrator

The procedures for vMRF deployment preparation must be performed by the cloud administrator to prepare the cloud environment for running vMRF. The procedures described in this section serve as examples only to demonstrate how to fulfill the vMRF requirements.

5.1 Cloud Hardware and Software Preparation and Configuration

Preparation for vMRF deployment starts by checking that the necessary hardware exists, and making hardware-related configurations in the VIM, in the hypervisor, and in the host Operating System.

5.1.1 Define an Availability Zone for vMRF

This procedure describes how to define an availability zone for vMRF in OpenStack. The created vMRF availability zone is input for the vMRF deployment, as the deployment file contains a corresponding parameter. The procedure uses an example scenario of creating a host aggregate with an availability zone for vMRF, called MRSv-zone, and adding two hosts to it, called node-1 and node-2. The aggregate also gets metadata so that the aggregate can be bound to the vMRF flavor as described in Create Flavor.

The procedure uses the OpenStack Nova command-line client. For information on managing host aggregates in the OpenStack dashboard, see the OpenStack Admin User Guide.

Steps

Create a new host aggregate called MRSv with an availability zone called MRSv-zone using the following command:
nova aggregate-create MRSv MRSv-zone
Add the nodes to be used for vMRF to the MRSv host aggregate using the following command:
nova aggregate-add-host MRSv node-1 nova aggregate-add-host MRSv node-2
Using the following command, specify metadata for the MRSv host aggregate so that it can be bound to a flavor:
nova aggregate-set-metadata MRSv key=999

5.1.2 Configure CPU Core Isolation for the vMRF Compute Hosts

Configure core isolation so that host OS processes are excluded from those cores that are used by vMRF. This is required to ensure good and predictable performance.

Note:

This procedure is only needed if core isolation for the compute hosts is not already configured in CEE. Proceed only if the isolcpus option is not visible in the output of the following command: cat /proc/cmdline | grep isolcpus.

Steps

Do the following on each node added to the MRSv host aggregate:

Check the number of cores and sockets on the compute host with the following command:
lscpu -p

Based on the command printout, identify the first two physical CPU cores from the same Non-Uniform Memory Access (NUMA) node as the virtual switch.

As an example, consider a single-socket compute host, with a 10-core CPU. Hyperthreading is enabled, so each physical core runs two threads, giving in total 20 logical processors. Suppose that these 20 logical processors are distributed in the following way:

NUMA node	Logical processors in the `lscpu -p` printout
0	0–9, 10–19

Suppose that the virtual switch uses NUMA node 0. This means that the first two physical cores (first four logical processors) on NUMA node 0 can be identified as follows: 0, 1, 10, 11.

Isolate all CPUs other than the ones identified on the NUMA node. To do this, add the isolcpus option to the GRUB_CMDLINE_LINUX_DEFAULT parameter in the /etc/default/grub file. If the file does not exist, create it.
Example
Example of an existing file before adding the isolcpus option:
```
cat /etc/default/grub
GRUB_TIMEOUT=10 GRUB_CMDLINE_LINUX_DEFAULT="nomdmonddf nomdmonisw"
```
Example
Example of an existing file after adding the isolcpus option:
```
cat /etc/default/grub
GRUB_TIMEOUT=10 GRUB_CMDLINE_LINUX_DEFAULT="nomdmonddf nomdmonisw isolcpus=2-9,12-19"
```
Example
Example of a newly created file with the isolcpus option:
```
cat /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="isolcpus=2-9,12-19"
```
Run the update-grub command.
Reboot the compute host.

Check that the isolcpus option is visible in the /proc/cmdline file:

Example

cat /proc/cmdline | grep isolcpus
BOOT_IMAGE=/vmlinuz-3.13.0-79-generic root=/dev/mapper/os-root ro console=tty0 net.ifnames=0 biosdevname=0 rootdelay=90 nomodeset root=UUID=201cf72b-dcb7-4721-9e63-b9f83cd022fb isolcpus=2-9,12-19

5.1.3 Configure CPU Settings for the vMRF Compute Hosts

This procedure describes how to configure CPU settings for vMRF that ensure the best possible computing environment for media stream processing.

For more information on the configuration options in the procedure, see the OpenStack configuration overview.

Note:

This procedure is only needed if CPU settings for the compute hosts are not already configured in CEE.

Do the following on each node added to the MRSv host aggregate:

Steps

Set the following in the /etc/nova/nova.conf file:
cpu_allocation_ratio = 1.0

Note: Make sure that cpu_allocation_ratio = 1.0 is included in the Default section of the file.

cpu_mode=host-passthrough
Restart the Nova Compute service using the following command:
initctl restart nova-compute

5.1.4 Configure CPU Frequency Scaling for the vMRF Compute Hosts

This procedure describes how to configure the CPU frequency scaling governor on compute hosts for higher performance. It is recommended to use the setting below for about 20–30% additional capacity for transcoding.

Steps

Set the CPU frequency governor to performance on each node added to the MRSv host aggregate:
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor >/dev/null

5.1.5 Configure NTP Servers

This procedure describes how to specify the external NTP servers for vMRF. External NTP servers are needed to keep the vMRF VMs synchronized, which ensures that quality of service expectations are met.

The following procedure must be performed on each node added to the MRSv host aggregate.

Note:

This procedure is only needed if NTP servers are not already configured in CEE.

Prerequisites

One or more NTP servers are available and you know their IP address or host name.

Steps

Add the following line in the /etc/ntp.conf file for each NTP server that vMRF uses:

server <NTP_server_IP_address_or_host_name>

Example

$ cat /etc/ntp.conf
# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
 
driftfile /var/lib/ntp/ntp.drift
 
 
# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/
 
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
 
# Specify one or more NTP servers.
server 198.51.100.0
server time1.example.com
server time2.example.com

Reboot the compute host, and ensure that the ntp service is running.

5.1.6 Configure Project and Users

This procedure describes how to create a new project for vMRF and how to add members. The procedure uses the OpenStack dashboard.

Steps

In the Identity tab, create a new project and add the member users.
Select Identity > Projects > Manage Members for the new project.
In the Project Members list, add the admin user to the list, and add the admin role for the admin user.
Inform the end user of the name of the new project.

5.2 Create Flavor

This procedure describes how to create a flavor, that is, a virtual hardware template, used for vMRF VMs. The procedure describes how to use the OpenStack Nova command-line client to create a minimum size flavor for vMRF based on the minimum system requirements.

Flavors can also be created using the OpenStack dashboard, as described in the OpenStack Admin User Guide.

Note:

To deploy without hyperthreading, CEE version R.6.3.1 or higher is required.

Steps

Use the following command to create the flavor named MRSv_flavor with the ID auto, with 6144 MB of memory, 6 GB root disk space, and eight virtual CPUs:

nova flavor-create MRSv_flavor auto 6144 6 8

Note:

In the case of deployment with hyperthreading, it is recommended to specify an even number of vCPUs in a flavor. The maximum number of vCPUs per a vMRF VM is 34.

If using Cinder block storage, specify 0 GB of root disk space in the flavor. Volume size is defined at the creation of Cinder volume in vmrf.yaml and scaling_group.yaml.

Use the following command to set the memory page size:
nova flavor-key MRSv_flavor set hw:mem_page_size=1048576
Use the following command to set the number of CPU sockets for the flavor:
nova flavor-key MRSv_flavor set hw:cpu_sockets=1

Note: This setting is needed to ensure that vCPUs correspond to physical CPUs of the same socket.
Use the following command to set CPU pinning for the flavor:
nova flavor-key MRSv_flavor set hw:cpu_policy=dedicated
Set CPU thread policy for the flavor:
- In the case of deployment with hyperthreading, use the following command:
  
  nova flavor-key MRSv_flavor set hw:cpu_thread_policy=prefer
- In the case of deployment without hyperthreading, use the following command:
  
  nova flavor-key MRSv_flavor set hw:cpu_thread_policy=isolate
Use the following command to bind the flavor to the host aggregate by adding the defined key:
nova flavor-key MRSv_flavor set aggregate_instance_extra_specs:key=999
Configure watchdog action as follows:
- In the case of deployment with watchdog action set to hard reset, use the following command:
  
  nova flavor-key MRSv_flavor set hw:watchdog_action=reset
  
  Note: The watchdog_enable deployment parameter must be set to 1 in the example_environment.yaml file.
- In the case of deployment without configured watchdog action, continue with the next step.

Inform the personnel who are doing the vMRF instantiation of the name of the flavor.

Note:

The reason for this step is that the name of the flavor is a parameter in the environment HOT file that is used for the instantiation.

5.3 Create Network Topology

The vMRF VNF instance connects to networks. The networks listed in Table 1 must be created already before the VNF instance can be deployed, since the HOT template uses them as input parameters.

Table 1 vMRF Networks
Network Type
O&M
H.248 signaling towards SGCs
User plane towards media networks

Steps

Using the network plan, create the required networks listed above, if they do not exist.

To create networks by launching Heat stacks, use the yaml files provided in the vMRF software delivery package. The vMRF software delivery package is available for the end user after download, in the folder where it was extracted to. To create networks by launching Heat stacks, do the following:

Change the example yaml files provided in the vMRF software delivery package to match your network environment.

Note:

The yaml files included in the examples folder of the software delivery package serve as examples for a possible network configuration. They can be modified to match your network environment.

Note:

Due to dashboard limitations, the CLI must be used in this procedure. For the movable IP address feature to be set up properly, the O&M network stack must be created as the administrator inside the vMRF project.

Create the network stacks using the following commands:
heat stack-create <O&M_network_stack_name> -e example_environment.yaml -f management_network.yaml

heat stack-create <signaling, user plane, and reserved network stack name> -e example_environment.yaml -f traffic_signaling_networks_admin.yaml
Check that the stacks got created successfully using the following command:
heat stack-list
Check that the networks got created successfully using the following command:
neutron net-list

Inform the personnel who are doing the vMRF instantiation of the names of all the networks created in the previous step.

Note:

The reason for this step is that the names of the networks are parameters in the environment HOT file that is used for the instantiation.

6 vMRF Deployment for the End User

After the deployment preparations are completed by the cloud administrator, the end user can start vMRF deployment.

6.1 Set Up Command-Line Access and Security

Command-line access is mandatory for some of the vMRF deployment activities due to dashboard limitations.

To be able to log in to the vMRF instance after it is instantiated, the proper access and security configurations must be in place.

6.1.1 Set Up the OpenStack Heat Command-Line Client

Each OpenStack component provides a command-line client, which enables access to the component API through commands. For example, the Heat component provides a heat command-line client.

Steps

Install the OpenStack Heat command-line client according to the OpenStack End User Guide.
Set up CLI access according to the OpenStack End User Guide.

6.1.2 Set Up Access and Security for Instances

To be able to connect to your cloud instances using SSH, the proper access and security configurations must be in place.

Steps

Log in to the dashboard.
Configure the security group for the project. Since the default security group does not allow any ingress connections, either modify the default security group, or create a new one. The rules must allow ingress connections for all the vMRF protocols and ports listed in vMRF Security Management. For information on managing security groups, see the OpenStack End User Guide.

Follow the instructions to add or import a key pair in the OpenStack End User Guide.

The name of the SSH key that you added or imported is needed at VNF instantiation.

Note:

SSH host keys for the VMs of the VNF cluster are generated automatically by the first VM during the deployment process, and copied to all other VMs.

The fingerprints of generated SSH host keys are visible on the Stack Overview page of the OpenStack dashboard after the deployment of vMRF.

6.2 Define Anti-Affinity Policy

By default, HOT files specify an anti-affinity policy for all the VMs in the VNF. The anti-affinity policy defines the placement of VMs on the compute hosts of the cloud environment. It is recommended to place only one media plane VM on the same compute host, unless dimensioning with the Ericsson dimensioning tool shows that multiple VMs can be allocated on the same host for the specific traffic profile (as described in vMRF Infrastructure Requirements).

If several VMs are allocated to the same host, scheduler_hints row from the scaling_group.yaml needs to be commented out, as seen in the following example.

scaled_vm:
    type: OS::Nova::Server
    properties:
      name: { get_param: scaled_vm_name }
      image: { get_param: mrf_image }
      flavor: { get_param: mrf_flavor }
      networks:
        - port: { get_resource: internal_port }
        - port: { get_resource: management_port }
        - port: { get_resource: signaling_port }
        - port: { get_resource: media_port }
      availability_zone: { get_param: availability_zone }
      config_drive: True
      user_data_format: RAW
      user_data: { get_resource: pl_init }
      metadata: { "ha-policy": "managed-on-host" }
      scheduler_hints:
#        group: { get_param: server_group }

6.3 Create Subnets

Subnets must be created within the networks created by the cloud administrator. The example_environment.yaml file provided in the vMRF software delivery package must match your network environment. Heat stack creation must be done in the CLI due to dashboard limitations.

Steps

In the CLI, do the following:

Change the example yaml files provided in the vMRF software delivery package to match your network environment.

Note:

The yaml files included in the examples folder of the software delivery package serve as examples for a possible network configuration. They can be modified to match your network environment.

Create the subnets as a Heat stack using the following command:
heat stack-create <subnet_stack_name> -e example_environment.yaml -f traffic_signaling_subnets.yaml
Check that the stack got created successfully using the following command:
heat stack-list
Check that the subnets got created successfully using the following command:
neutron subnet-list

As an alternative, log in to the dashboard and check that the subnets are visible in the Network Topology view.

6.4 Prepare Deployment Parameters

Ensure that the correct values of the following deployment HOT template parameters are specified in the example_environment.yaml file provided in the vMRF software delivery package:

HOT Parameter Name	Description
admin_username	The user name, password, and SSH key of the emergency user. The default password must be changed by supplying a new password hash in this parameter.⁽¹⁾
admin_password_hash
admin_authorized_key
mrf_flavor	Virtual hardware template used by VMs of the cluster.
external_net_name	Internal and external networks used by the VNF.
management_net_name
signaling_net_name
media_net_name
mrf_image	The VNF image file name.
payload_instance_count	The number of VMs to be created.
mrf_config	If you are importing initial configuration data during deployment, you must give a value to this parameter. The parameter contains the content of the tar.gz file that contains the vMRF configuration that will be imported during system startup, in Base64 encoding. The input can be generated with the following command: `base64 -w 0 <file_path>` If no value is provided, initial configuration must be provided after instantiation either manually or from an exported configuration file.
shared_storage_server_username⁽²⁾	User name for the external shared storage server.
shared_storage_ssh_private_key⁽²⁾	The SSH private key for external shared storage in one line. The input can be generated by replacing the end of line characters with the string "\n" and including the key data string between single quotation mark (') characters with the following command: `echo "'$(ssh-keyscan -p <server_port> <server_ip_address> \|awk 'BEGIN{ORS="\\n"} {print $0}')'"`.
shared_storage_server_path⁽²⁾	The external shared storage POSIX path pointing to a directory on the shared storage server.
shared_storage_server_ip⁽²⁾	The shared storage server IP address.
shared_storage_server_port⁽²⁾	The shared storage server port.
shared_storage_server_fingerprint⁽²⁾	The shared storage server fingerprint in one line. The fingerprint can be created with the following command: `ssh-keyscan -p <server_port> <server_host>` The input can be generated by replacing the end of line characters with the string "\n".
announcement_storage_server_username⁽³⁾	User name for the external announcement storage server. The default value is announcements.
announcement_storage_ssh_private_key⁽³⁾	The SSH private key for external announcement storage in one line. The input can be generated by replacing the end of line characters with the string "\n" and including the key data string between single quotation mark (') characters with the following command: `echo "'$(ssh-keyscan -p <server_port> <server_ip_address> \|awk 'BEGIN{ORS="\\n"} {print $0}')'"`.
announcement_storage_server_path⁽³⁾	The external announcement storage POSIX path pointing to a directory on the announcement storage server. The default path is announcement_storage.
announcement_storage_server_ip⁽³⁾	The announcement storage server IP address.
announcement_storage_server_port⁽³⁾	The announcement storage server port. The default port number is 22.
announcement_storage_server_fingerprint⁽³⁾	The announcement storage server fingerprint in one line. The fingerprint can be created with the following command: `ssh-keyscan -p <server_port> <server_host>` The input can be generated by replacing the end of line characters with the string "\n".
pm_data_monitoring_hosts_ip_address	Optional parameter. IP address of PM data monitoring host.
pm_data_monitoring_hosts_ip_address	Optional parameter. Listening port of PM data monitoring on host.
availability_zone	Availability zone to use for vMRF instances. Default is the OpenStack 'nova' zone which consists of all compute nodes.
watchdog_interval	Watchdog ping interval in seconds. Min.: 1, Max.: 58. Default: 1.
watchdog_enable	Parameter for enabling watchdog. Min.: 0 (Watchdog feature disabled), Max.: 1 (Watchdog feature enabled). Default: 0.
ntp_server_1	Parameter for configuring NTP server IP address on the guest OS side VNF.⁽⁴⁾
ntp_server_2

(1) Password change for the emergency user is supported only during deployment.

(2) This parameter needs to be defined only if the optional shared storage or the optional announcement storage is used. Leave it blank otherwise. For more information on the shared storage feature, see vMRF Overview.

(3) This parameter needs to be defined only if the optional announcement storage server is used. For local storage of announcement files, leave it blank. In this case the vMRF VMs will start up configured for local storage of announcement files. For more information on the shared storage feature, see vMRF Overview.

(4) NtpServer MO is not used by vMRF.

Add any missing deployment parameters and their default values to the example_environment.yaml file.

To generate a new password hash for the parameter admin_password_hash, run the following command: mkpasswd -m sha-512 <new_emergency_user_password>.

The following is an example of the additional parameters that can be appended to the file. Comments are included for guidance.

Example

#Examples for additional deployment parameters, change values according to your environment
  mrsv_image: "MRSv1_1"
#Include the following line only if the emergency user is not "mrsv-admin"
  admin_username: "mymrsv-admin"
#Replace the password hash on the following line with the actual password hash for the emergency user
  admin_password_hash: "$6$asYHS3nJ8$6dwcdDEoTM029FfOe4Ejxa4HKKSoLkzhAdGPLLoQ..."
  admin_authorized_key: "mykey"
#Replace the value on the following line with the base64 command output on the path to the tar.gz file
  mrsv_config: "H4sICCipGFcC/2JhY2t1cF8xODA0MTZfNC50YXIA7V1bc+I4Fs5zV+1/oPp1F..."
  shared_storage_server_username: "myuser"
  shared_storage_ssh_private_key: "myprivkey"
  shared_storage_server_path: "/home/myuser/mrsv"
  shared_storage_server_ip: "192.0.2.7"
  shared_storage_server_port: "22"
  shared_storage_server_fingerprint: "12:f8:7e:78:61:b4:bf:e2:de:24:15:96:4e:d4:72:53"
  announcement_storage_server_username: "announcement_user"
  announcement_storage_ssh_private_key: "announcementStoragePrivKey"
  announcement_storage_server_path: "/home/myuser/announcement_storage"
  announcement_storage_server_ip: "192.0.2.9"
  announcement_storage_server_port: "22"
  announcement_storage_server_fingerprint: "12:f8:7f:78:61:b4:bf:e2:de:44:15:96:4e:d4:72:99"
  pm_data_monitoring_hosts_ip_address: "192.0.2.8"
  pm_data_monitoring_hosts_port: "8000"
#Include the following line only if the availability zone is not "nova"
  availability_zone: "mymrsvzone"

If importing initial configuration data during deployment:

Ensure that the initial configuration data matches your environment.

6.5 Upload the vMRF Image

This procedure describes how to upload the vMRF image to the CEE cloud, using the vMRF image file.

Steps

Create the vMRF image.
In the CLI, use the following command:

glance image-create --name vMRF-<product_revision> --visibility=public --disk-format vmdk --container-format bare --file vmrf-image-corei7-mrsv.vmdk

In the dashboard, follow the OpenStack End User Guide, and fill the image properties according to Table 2.

Table 2 vMRF Image Properties for OpenStack Dashboard
Parameter	Description
Name	Enter a name for the image. It is recommended to include the vMRF product version in the name.
Description	Enter a brief description of the image.
Image Source	Choose Image File.
Image File or Image Location	Browse for the vMRF image file on your file system and add it.
Format	Choose VMDK.
Architecture	Enter `x86_64`.
Minimum Disk (GB) and Minimum RAM (MB)	Leave these fields empty.
Public	Select this check box, so that the image is public to all users with access to the current project.
Protected	Do not select this check box.

Check that the image exists using the following command:
glance image-list --name vMRF-<product_revision>

6.6 Instantiate and Check vMRF with One VM

This procedure describes how to instantiate a vMRF VNF instance in the OpenStack cloud, using the OpenStack Glance image and the HOT files. Instantiate the VNF with one VM and verify that VM before scaling out to the full size of the VNF.

The VNF instance must be created in the CLI due to dashboard limitations.

Prerequisites

The vMRF VMs to be scaled-out are configured as MRFP (Media Resource Function Processor) nodes in the MTAS.

A vMRF VM identifies itself to the MTAS with a Message Id (MId) that contains the vMRF VM signaling IP address and SCTP port. Typically, the whole range of signaling IP addresses, that is, the signaling subnet, that has been configured in the OpenStack for the vMRF VNF, is configured as MRFP nodes in the MTAS.

For more information on adding an MRFP node in MTAS, refer to section Add MRFP in MTAS Media Control Management Guide, Reference [1].

Steps

Instantiate vMRF by creating the vMRF stack in Heat using the heat stack-create command. The following is an example of the heat stack-create command when all parameters have been added to the example_environment.yaml file:

heat stack-create <stack_name> -f vmrf.yaml -e example_environment.yaml -P payload_instance_count=1

Note:

Ensure that you do not use dots (".") in the stack name. The stack name must not be longer than 52 characters.

Check that the stack exists using the following command:
heat stack-show <stack_name>

As an alternative, log in to the dashboard and check that the VM belonging to the VNF is visible in the Network Topology view.
In the OpenStack dashboard Stack Overview page, check the outputs section for the vMRF VNF O&M IP address.
Open an SSH connection to the O&M IP address of the vMRF VNF instance using the following command:
ssh -A -i <admin_username>@<O&M_IP_address>
Run the following command:
verify_vmrf_cluster_status.py

Check that all components are in the correct state. The following is an example output from a VNF that is operating correctly:

Example

$ verify_vmrf_node_status.py
Running command: "verify_vmrf_node_status.py" on host: 192.168.0.3 (fi2-vmrf)
                 eth0: OK
                 eth1: OK
                 eth2: OK
              SC role: ACTIVE
             RED role: ACTIVE
               CoreMW: OK
                  COM: OK, RUNNING
          MrfDirector: OK, RUNNING
            CliDaemon: OK
           IpPipeline: OK
               TC-MPD: OK
             MrfAgent: OK
            CloudInit: OK
         ConfigImport: OK
             SEC-CERT: OK
   neighbourdetection: OK
                   LM: OK

Note:

The MrfDirector and COM components are in the OK state only for the VM whose SC role is ACTIVE, that is, the active System Controller (SC) VM. In all other VMs, these components are in the OK, NOT RUNNING state, which is normal behavior.

6.7 Provide Initial Configuration

For the VNF to start handling traffic, configuration data must be provided. This procedure describes how to provide initial configuration data for the VNF if it was not already injected using the mrf_config HOT parameter during instantiation.

Steps

Provide configuration data for the VNF.
- If this is the first deployment of the VNF, or configuration data is not available at this point, perform initial configuration, as described in section Manual Configuration of the Initial Configuration Guide.
- If configuration data is available, either from a backup of an older VNF, or prepared by Ericsson, import configuration data, as described in section Importing Configuration Data from NETCONF Template of the Initial Configuration Guide.

6.8 Check vMRF Status

This procedure describes how to verify the vMRF deployment. The status check involves running a vMRF command.

Steps

In the OpenStack dashboard Stack Overview page, check the outputs section for the vMRF VNF O&M IP address.
Open an SSH connection to the O&M IP address of the vMRF VNF instance using the following command:
ssh -A -i <private key .pem file> <user ID>@<O&M IP address>
Run the following command to check the status of VMs in the cluster:
verify_vmrf_cluster_status.py
- If the VMs are operating correctly, the OK status is displayed in the command printout. You can exit this procedure.
- If there are VMs with faulty components, a list of faulty VMs and detailed component information of the cluster is displayed. Continue with the next step.

Check all components with erroneous state. For specific trouble cases and remedies, refer to the vMRF Troubleshooting Guideline.

Note:

6.9 Scale Out to Full VNF Size

This procedure describes how to scale out to the full size of the VNF by updating the vMRF stack.

Steps

Log in to the OpenStack CLI.
Use the heat stack-update command to increase the size of the VNF.

heat stack-update <stack_name> -x -P payload_instance_count=<new_number_of_VMs>

Note: This command only updates the payload_instance_count parameter, it is not required to specify the environment file.
Log in to the dashboard and check that the VMs belonging to the VNF are visible in the Network Topology view.

1 Reference List

[1]	MTAS Media Control Management Guide, 19/1553-AVA 901 29/9

Copyright	© Ericsson AB 2016–2019. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.
Disclaimer	The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
Trademarks	All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.