Release notes

These release notes provide product information about the F5 VNF Manager support for version

User documentation

You can find the user documentation on:

Platform support requirements

This section provides system requirements for VNFM and additional platform components.

VNF Manager

F5 VNF Manager version 2.0.0 requires the following system requirements:

Platform name Platform ID System Requirements
F5 VNF Manager All versions
  • vCPUs: 4 minimum, 8 recommended
  • RAM: 8GB minimum, 16GB recommended
  • Root Disk Storage: 160GB minimum
  • Storage: 5GB minimum, 64GB recommended
  • 64-bit host: with RHEL/CentOS 7.4
  • Private network: dedicated for communicating with other VNFM components, including cluster members

VNFM Sizing guidelines

The following table includes some guidelines and insights for determining VNF Manager sizing.

VNFM Component Sizing guideline
Tenants Define a maximum of 1000 tenants in a VNF Manager
Users Currently, no limit to the number of users you can define in the system; however, the maximum, concurrent users interacting with VNFM is 200.
Blueprints Allocate 50GB of storage to the VNF Manager. Currently, no limit to the number of blueprints, as the average blueprint storage requires less than 1M of disk space and database space.
Plugins Plugins are stored in the VNF Manager hard drive. Typically, plugins can consume approximately 5M to 20M of storage.
Deployments A single VNFM can maintain up to 500K of deployed nodes. Typical deployment size consumes 10K maximum of disk size and very few entries in the database
Workflows A VNFM can operate up to 100 concurrent workflows; a default limit enforced by the system. However, you can modify this threshold.
Secrets No limit to the number of secrets.
Agents A maximum of 2000 agents deployed per a single VNFM.
UI/CLI/API requests/second Although the REST API performance varies depending on multiple factors, typically VNF Manager can support a maximum of 10 requests/second.
Events The system can process a maximum of 100 events/second.
Logs, events, and metrics Define enough storage to store the logs, events, and metrics sent from the hosts, configuring log rotation to minimize the amount of storage space required.

Additional platforms

The following table provides system requirements for the additional components.

Platform name Platform ID System Requirements
BIG-IP Virtual Edition (VE) Version 13.1.X
Version and later
BIG-IQ Version 6.0.1 BIG-IQ 6.0.1 Release Notes
CentOS-7-x86_64-GenericCloud-1503 GenericCloud-1503 Release Notes

Virtual Infrastructure Manager (VIM) compatibility

F5 VNF Manager and VIM compatibility matrix:

VNF Manager ID VIM Platform ID VIM System Requirements
F5 VNF Manager 1.1.X OpenStack Newton Version 10 Environment requirements
F5 VNF Manager 1.2.0 VMware vSphere ESXi Version 6.5 Requirements and patch notices
F5 VNF Manager 1.2.1 VMware vSphere ESXi Version 6.5
OpenStack Newton Version 10
See previous links for requirements information.
F5 VNF Manager 1.3.0 OpenStack Newton Version 10 and Queens Version 13
VMware vSphere ESXi Version 6.5
Newton Version 10 Environment requirements
Queens Version 13 Environment requirements
vSphere ESXi Version 6.5 Requirements and patch notices
F5 VNF Manager 1.3.1 OpenStack Newton Version 10 and Queens Version 13
VMware vSphere ESXi Version 6.5
See previous links for compatible platform requirements.
F5 VNF Manager 1.4.0 OpenStack Newton Version 10 and Queens Version 13
VMware vSphere ESXi Version 6.5
See the previous links for compatible other platform requirements.
F5 VNF Manager 2.0.0 OpenStack Newton Version 10 and Queens Version 13
VMware vSphere ESXi Version 6.5 and VIO version 5.1
See VMware Integrated OpenStack (VIO), and the previous links for other compatible platform requirements.


To verify supported versions of OpenStack compatibility for all versions of VNFM, F5 used Red Hat and VIO infrastructures; however, F5 is confident that VNFM is compatible with supported versions of OpenStack in other infrastructures.

Open source components

F5 VNF Manager is built with the following open-source components.

Component Description

Nginx is a high-performing Web server. In F5 VNF Manager, it serves two purposes:

  • A proxy for the F5 VNFM REST service and F5 VNFM Console
  • A file server to host F5 VNFM-specific resources, agent packages, and blueprint resources.

File server

The file server served by Nginx, while tied to Nginx by default, is not logically bound to it. Although currently it is accessed directly frequently (via disk rather than via network), we will be working towards having it decoupled from the management environment so that it can be deployed anywhere. The file server served by Nginx, is available at https://{manager_ip}:53333/resources, which is mapped to the /opt/manager/resources/ directory. You must authenticate in order to access the file server. To access subdirectories that include tenant names in their path, you must have privileges on that tenant. These subdirectories include:

  • blueprints
  • uploaded-blueprints
  • deployments
  • tenant-resources

The directories that are stored in snapshots include:

  • blueprints
  • uploaded-blueprints
  • deployments
  • tenant-resources
  • plugins
  • global-resources

Note: The tenant-resources and global-resources directories are not used by F5 VNF Manager; therefore, users can create these directories for storing custom resources.

Gunicorn and Flask Gunicorn is a Web server gateway interface HTTP server. Flask is a Web framework. Together, Gunicorn and Flask provide the F5 VNFM REST service. The REST service is written using Flask, and Gunicorn is the server. Nginx, is the proxy to that server. The F5 VNFM’s REST service is the integrator of all parts of the F5 VNFM environment.

PostgreSQL is an object-relational database that can handle workloads ranging from small single-machine applications to large Internet-facing applications. In F5 VNF Manager, PostgreSQL serves two purposes:

  • Provides the main database that stores the application’s model (for example, blueprints, deployments, runtime properties)
  • Provides indexing, and logs’ and events’ storage

Recommended system requirements include:

  • vCPUs: 2
  • RAM: 16GB
  • Storage: 64GB

These recommended specifications consider the average use of 1000-2000 workflows per hour and certified for 1 million deployments. To increase this scaling volume, increase your hardware specification; for example, the equivalent AWS instance is r5.large.

Logstash Logstash is a data handler. It can push/pull messages using inputs, and apply filters and output to different outputs. Logstash is used by F5 VNFM to pull log and event messages from RabbitMQ and index them in PostGresSQL.

RabbitMQ is a queue-based messaging platform. RabbitMQ is used by F5 VNFM as a message queue for different purposes:

  • Queueing deployment tasks
  • Queueing logs and events
  • Queueing metrics

Recommended system requirements include:

  • vCPUs: 2
  • RAM: 4GB
  • Storage: 32GB

These recommended specifications consider the average use of 1000-2000 workflows per hour and certified for 1 million deployments. To increase this scaling volume, increase your hardware specification; for example, the equivalent AWS instance is c5.large.


Pika is a pure-Python implementation of the AMQP 0-9-1 protocol. The VNF management worker and the host agents are using pika to communicate with RabbitMQ.

Management worker (or agent)

Both the Workflow Executor and the Task Broker that appear in the diagram are part of the F5 VNFM Management Worker.

  • The Workflow Executor receives workflow execution requests, creates the tasks specified by the workflow, submits the tasks for execution by host agents and the Task Broker, and manages workflow state.
  • The Task Broker executes API calls to IaaS providers to create deployment resources, and executes other tasks specified in central_deployment_agent plugins.

Note: All agents (the management worker, and agents deployed on application hosts) are using the same implementation.


Feature Name Description
Install/Uninstall Installs the target deployment, lifecycle operations, and starts all instances. Uninstalls target deployment, frees resources allocated during install, performs uninstall lifecycle operations, stops/deletes deployments and additional blueprints created during install.
Scale out Adds and installs BIG-IP Virtual Editions (VEs) and VNF instances on demand as your network needs resources based on configurable parameters.
Scale in Removes and uninstalls BIG-IP Virtual Editions on demand as your network reduces its need for resources based on configurable parameters.
Heal VEs and layers Creates a new copy of any BIG-IP VEs, layers, and related objects on demand as your network reports dysfunctional instances.
Purge VEs and layers Uninstalls and removes dysfunctional VEs, VNF layer instance(s), and related objects, which you start manually after heal layer workflow runs and problem investigation is complete.
Upgrade Initiates the upgrade process and sets new software reference data. Disables VEs with lower revision numbers. Scaled and healed VEs are installed using the new software reference data.
Update NSD Updates AS3 declaration pushed to the VE as a part of NSD definition.
High Availability (HA) Due to changes in a third-party application, the three-cluster VNFM HA solution in VNFM no longer works as designed. Refer to the Cloudify 5.0.5 HA Guide for configuration information.
REST API Provides all VNFM functionality using a REST-based API.

What’s new

The following table describes new functionality added in VNF Manager in the designated version release:

Feature Description
Support deployment to multiple VIMs (multi-VIM or -hypervisor) You can use one VNFM manager cluster provisioned in a VMware/OpenStack hypervisor that deploys solutions to other VMware or OpenStack hypervisors. This setup requires a new datacenter input defined for all blueprint solutions. Regardless of which VIM you use, you will now see blueprints for both OpenStack and VMware on the VNFM dashboard. Consult the mixed-VIM setup for complete system requirements.
VNF-BIG-IQ prepare support for VMware Integrated OpenStack (VIO) Updated the BIG-IQ blueprint solution in preparation for the support of a VMware Integrated OpenStack (VIO) environment. If the OpenStack/VIO API does not set the MTU value for your management network, then VNF Manager will use 1400 as the default value for VNF-BIG-IQ blueprint deployments ONLY.
F5-VNF-Service-Layer-CGNAT-Offering blueprint solution New blueprint solution used to implement CGNAT VNFs that are directly connected to the PGW and PDN networks. The CGNAT Offering solutions does not have masters or slaves, but instead deploys just CGNAT VNFs in a single-scale group.
Updated f5-ric-plugin Updated the Resource Information Collector plugin to generate usage reporting for the F5-VNF-Service-Layer-CGNAT-Offering blueprint.
New syslog_config input Added new syslog_config input that attaches an additional BIG-IP VE syslog configuration file. Define this input when using ANY VNF blueprint solution (EXCEPT the VNF Base solution).
Logs menu Logs menu enables you to analyse events/logs produced by your deployments. Provides several event log and resource filtering options.
CLI documentation Documentation for using the Server Maintenance and Orchestration commands.
Update as 3 workflow renamed The workflow named, Update AS 3, is renamed to Update declaration. Run this workflow after editing and uploading changed Telemetry declaration, the AS 3 declaration, or the syslog configuration in your NSD definition for VNF_NSD, NSD_DNS, and NSD_SEC_DNS deployment types. For complete information, see the Workflow User Guide.
Telemetry declaration A telemetry_nsd_payload dictionary used for F5 Telemetry Streaming declaration (JSON format) that defines the service configuration of the VNF instances. This declaration is used with all blueprint solutions except Base.
Site management widget New Site Management widget enables grouping of deployments by location, providing visibility into installations in your data centers, branches, or edge sites.
Input validator PREVIEW for auto-validating inputs, and enabling input value restrictions. For example, when deploying a blueprint, you will receive feedback if an input does NOT meet valid criteria; like, predefined port ranges or formatting patterns.
Workflow actions

Applicable workflows will now include the following new actions effecting the execution of that workflow:

  • Dry Run - PREVIEW for executing and logging workflows without actual side effects.
  • Queue - running workflows automatically at the next possible opportunity.
  • Schedule - running workflows at a defined date and time (required format, YYY:MM:DD:HH:mm).
Update deployment PREVIEW for updating/changing blueprints, input values, and workflow actions for already deployed nodes in real-time.
VNFM license management validation You must enter your VNFM license into the new VNFM License Management popup window.

Known issues

The following table lists known issues in the designated version release:

Platform name Description
F5 VNF Manager Version 2.0.0
  • If deploying the F5-VNF-BIG-IQ blueprint from a VMware vSphere ESXi VIM, you must NOT use and IP addresses on the same network the F5 VNF Manager is connected, until AFTER you deploy the BIG-IQ blueprint and the BIG-IQ HA pair is online. Once the BIG-IQ HA pair is online, those IP addresses become available.

  • In VMware vSphere ESXi, when using the VNFM REST API, you must set up your networks to use unique port group names, regardless of the directories in which they reside.

  • OpenStack v10 (Newton) has an issue with privileges and connecting devices residing outside the OpenStack environment with those residing inside the OpenStack environment, including F5 VNF Managers. To work around this issue, you must add the VNF Manager to the admin project, or upgrade to OpenStack v13 (Queens).

  • You will receive a 404 Error message when trying to deploy any blueprint on vSphere VIM with a setting of switch_distributed=False.

  • Zooming the map view in the new Site Management widget is not working properly.

  • Device configuration groups do not sync with the master node after executing a Scale Out workflow for a vnf_layer deployment.

  • When upgrading your BIG-IP VEs, you will encounter an error while executing the Upgrade Start workflow for a VNF Group. This is caused by a typo in the workflow script.

  • The telemetry as3 declaration is not propagated after executing sync-to-device group.

  • Even though you selected one type of declaration (AS3, Telemetry Streaming, or Syslog), all three are triggered during an update breaking the configuration services on the VNFs.

  • New deployments created during a scale_out workflow or a heal workflow are created with the original configuration taken from the original inputs file, and NOT from any updated inputs file.

  • The Heal workflow returns an error on the vnf_layer for Gi LAN blueprint deployments.

  • Nagios can fail during installation.

  • The Upgrade workflow automatically admin-disables the old layer. This is not expected behavior, as this step should occur, manually.

  • The Update declaration workflow is not synchronizing across all VEs in the VNF layer; therefore, you must manually push the changes using a curl command similar to the following example:

       curl --location --request POST 'https://<master IP address>:443/mgmt/tm/cm' \
       --header 'Tenant: default_tenant' \
       --header 'Content-Type: application/json' \
       --header 'X-F5-Auth-Token: DM3JNEUCX2Z2LZFFKAKZ3YNKEQ' \
       -d '{
           "command": "run",
           "utilCmdArgs": "config-sync to-group Sync"
    The VEs will receive the declaration changes, and synchronize with the primary node.
  • For GiLAN or Gi Firewall + CGNAT deployments, you cannot make any changes to the CGNAT configuration, post deployment.

  • When restoring a snapshot, you will encounter the following error, preventing snapshot restoration: Restoring snapshot from version 0.0.0 is not supported.

  • When instantiating the VNFM image in your VIM, the image at boot-up requires proper networking. If not, then your user accounts are not created correctly, and login to the OS VM is not possible. Additionally, services do not start and there is no access to the VNF Manager UI. This prohibits logging into VNFM and adding the required networking. Workaround depends upon your VIM:

BIG-IP or Virtual Edition 13.1.X Issues list or Issues list (earlier versions are NOT supported)
BIG-IQ 6.0.1 Issues list
CentOS-7-GenericCloud-1503 Issues list
OpenStack Newton Issues list for v10 and Issues list for v13
VMware vSphere ESXi 6.5 and VIO v5.1 Issues list and documents for VMware Integrated OpenStack (VIO)

Fixed issues

The following table lists issues that were fixed in the designated version release:

Platform name Fixed in version Description
F5 VNF Manager 2.0.0
  • On failover, connections are no longer reset, and are now smoothly transitioned. So application connections do not drop and no longer need resetting by the application.
  • All vSphere secrets have been renamed using the _default suffix for multi- and mixed- VIM purposes.
  • Secrets validation feature for all blueprints is now complete.
  • MAC address assignment in VIO v5.1. now synchronizes with the NIC assignment order no longer blocking traffic and BGP sessions.
  • The NTP server now automatically runs and synchronizes with BIG-IP on VNF Manager once you address the NTP server using the address of your VNFM.
BIG-IP Virtual Edition or 13.1.X Issues list or Issues list
BIG-IQ 6.0.1 Issues list
CentOS-7-x86_64 GenericCloud-1503 Issues list
OpenStack 10.0 and 13.0 Issues list for v10 and Issues list for v13
VMware vSphere ESXi and VIO 6.5 and 5.1 Issues list and documents for VMware Integrated OpenStack (VIO)

Installation overview

To install F5 VNF Manager, use the link provided in the email, and use the key provided in the email as customer identification, when obtaining customer support. Additionally, you will need the following F5 product license keys:

Platform name Product license
BIG-IP or Virtual Edition F5-BIG-MSP-LOADV12-LIC
CentOS-7-x86_64-GenericCloud-1503 NA

Upgrade overview

You can upgrade HA clusters two ways:

  • Upgrade on new hosts (recommended method).

  • In-place upgrade (prevents ability to rollback).


    This method works only if you leave the IP, AMQP credentials and certificates unchanged.

What’s Next?

Set up VNFM