SIMPLVM DeploymentGuide OpenStack

CONFIDENTIAL
SIMPL VM Deployment
Guide (OpenStack)
SIMPL-001_OpenStack - Version 6.11.0 - Issue 1-1451
October 2022
A Microsoft Company
SIMPL VM Deployment Guide (OpenStack) (V6.11.0) CONFIDENTIAL
Notices
Copyright © 2020-2022 Microsoft. All rights reserved.
This manual is issued on a controlled basis to a specific person on the understanding that no part of
the product code or documentation (including this manual) will be copied or distributed without prior
agreement in writing from Metaswitch Networks and Microsoft.
Metaswitch Networks and Microsoft reserve the right to, without notice, modify or revise all or part of
this document and/or change product features or specifications and shall not be responsible for any
loss, cost, or damage, including consequential damage, caused by reliance on these materials.
Metaswitch and the Metaswitch logo are trademarks of Metaswitch Networks. Other brands and
products referenced herein are the trademarks or registered trademarks of their respective holders.
CONFIDENTIAL SIMPL VM Deployment Guide (OpenStack) (V6.11.0)
Contents
1 Introduction to the SIMPL VM.............................................................................. 4

2 Planning your SIMPL VM deployment................................................................. 9
2.1 VM specification.................................................................................................................... 9
2.2 Firewall configuration and connectivity............................................................................... 10
2.3 OpenStack requirements.....................................................................................................13
2.4 Monitoring with SIMon or Fluentd....................................................................................... 14
2.5 Syslog audit logging............................................................................................................ 15
2.6 User access.........................................................................................................................16
3 Deploying the SIMPL VM.................................................................................... 18
3.1 Configuring OpenStack for the SIMPL VM......................................................................... 18
3.2 Deploying SIMPL (OpenStack)........................................................................................... 19
3.2.1 Preparing for deployment (OpenStack)................................................................. 19
3.2.2 Deploying the SIMPL VM (OpenStack)................................................................. 23
3.3 Initial configuration...............................................................................................................29
3.4 Change SSH timeout according to security policy..............................................................31
3.5 Configuring syslog support over TLS..................................................................................32
4 Managing the SIMPL VM..................................................................................... 35
4.1 Upgrading, updating or recovering the SIMPL VM (OpenStack)........................................ 35
4.2 Using the screen command for long running actions..........................................................42
4.3 Destroying the SIMPL VM.................................................................................................. 42
5 Managing multiple sites...................................................................................... 44
6 Troubleshooting the SIMPL VM..........................................................................45
7 Appendix: Command reference..........................................................................47
7.1 CSAR commands................................................................................................................ 47
7.2 Solution-bundle commands................................................................................................. 49
7.3 Other commands................................................................................................................. 50
1 Introduction to the SIMPL VM
Metaswitch's ServiceIQ Management Platform VM (SIMPL VM) is a VM that simplifies the

management of other Metaswitch VMs. SIMPL provides a unified and consistent way to deploy,
commission, and update Metaswitch products on VMware vSphere, VMware vCloud, OpenStack, and
Azure.
What is the SIMPL VM?

The ServiceIQ Management Platform (SIMPL) VM interacts with your virtual infrastructure manager
(VIM) to manage the lifecycle procedures for your Metaswitch products deployed as virtual machines:
installing, updating, upgrading, healing and destroying VMs. SIMPL reduces the number of
touchpoints for operators because operations are performed solely through SIMPL rather than
needing direct access.
Figure 1: SIMPL VM overview
SIMPL supports vSphere, vCloud, OpenStack and Azure VIMs. See Supported products for what can
be deployed on your VIM and Deploying the SIMPL VM (OpenStack, VMware or Azure) for required
configuration.
The SIMPL VM is a long-lived VM that you continue to use to manage updates and upgrades
throughout your deployment's lifetime. SIMPL VM may also be used as a short-lived VM to speed up
the commissioning process that you remove from your deployment after initial commissioning
The SIMPL VM is intended to be the first Metaswitch VM created in your network and provides:
• VPN access (if permitted) for base commissioning and validation.

• Tooling to deploy VMs.
4 1 Introduction to the SIMPL VM

• Tooling to interact with the VMs and apply base 'day one' configuration.
• Deployment validation scripts to check VMs are correctly commissioned and working.
• Tooling to update product configuration and upgrade the software once initial VM deployment is
complete.
SIMPL relies on two key artifacts:
• SDF - The Solution Definition File is a single, declarative YAML file that encapsulates all the
information necessary to set up a specific Metaswitch deployment. Note SDFs, unlike CSARs, are
a Metaswich proprietary format.
• CSARs - Cloud Service Archives are an open standard for shipping product images together with
metadata describing the configuration they require, validation tests, and day one scripts. The
SIMPL VM creates deployments using CSARs, typically using one CSAR for each VM type. SIMPL
VM supports deploying Metaswitch CSARs, not CSARs from other vendors.
SIMPL VM also separates secret configuration, such as the passwords and private keys, from non-
sensitive configuration. The SDF does not contain secret values; instead, it contains identifiers that
are used to reference a secret value. The secret values are managed in a secure secret store hosted
on SIMPL VM. This allows SDFs to be safely shared between your engineers and Metaswitch support
without any risk of leaking secrets.
Deployment via the SIMPL VM

The SIMPL VM deploys Metaswitch products using a combination of the SDF and CSARs:
• The SIMPL VM is installed (as an OVA on VMware, via Heat on OpenStack, or as a VHD via ARM
on Azure) and, optionally, the VPN software is started.
• CSARs are downloaded onto the SIMPL VM and stored on a detachable volume.
• The SDF is written, and then copied onto the SIMPL VM. Your support representative will usually
write the SDF.
• Secrets are added to the secret store using the SIMPL VM CLI.
• The SIMPL VM validates the SDF, including:
• all syntax is correct

• all mandatory fields are filled out
• all IP address are in the right subnet
• no IP addresses clash
• Environment Readiness Testing - any referenced resources (such as subnets) are available.
• The SIMPL VM needs the relevant permissions to speak to your VIM. We recommend, where
possible creating Metaswitch VMs in an isolated tenant on your VIM, or, on platforms such as
vSphere where this is not possible, we provide detailed instructions on the minimum permissions
necessary, so that SIMPL VM can interact with Metaswitch VMs only. SIMPL VM validates that
it can contact the VIM, and that permissions are configured appropriately, before all deploy
operations.
1 Introduction to the SIMPL VM 5

• Once you are ready to deploy, the SIMPL VM uploads the software image from the CSAR, checks
that it has all the required secrets it needs to deploy the target VMs, deploys your Metaswitch VMs
as specified in the SDF, and applies initial configuration.
• The SIMPL VM then checks that the VMs are running and are healthy.
This allows Metaswitch deployments to be spun up very quickly. If something goes wrong, you
can redeploy by running a few commands on the SIMPL VM. Similarly, if you need to replicate the
deployment at another location, you only need to make minor changes to the SDF and run a few
commands. Manual steps that previously took days now take a matter of minutes.
Updates and upgrades via the SIMPL VM

Metaswitch products fall into two categories:
• Products for which applying software updates are done by redeploying the VM:
• This is called the rolling upgrade model.

• In addition to changing software versions via redeploying up-level, these products also expect
'base' configuration, such as NTP servers and DNS to be updated via a redeploy.
• SIMPL provides a single update command that can be used to either update configuration
(including secrets) or upgrade to a new software version.
• SIMPL automates the upgrade procedure to make it as simple as downloading a CSAR for the
new software version, updating the SDF to reference the new version, and then running the
update command. For a configuration update, any changes to the SDF are applied with the
same command but using the existing CSAR.
• SIMPL contains all the logic to co-ordinate the upgrade or update across a cluster of VMs
providing the same service. This includes automating previously manual steps such as health
checks before and after each update, quiescing, deleting VMs and redeploying them using up-
level software, and detaching and reattaching persistent volumes. This ensures that service is
maintained throughout the procedure.
• Rolling upgrade is supported on OpenStack, VMware, and Azure.
• Products for which applying software updates is done via updating the software in-place, without
redeploying the VM:
• This is called the in-place upgrade model

• The VM is not destroyed and SIMPL updates the existing VM. In-place upgrade can be used to
automate upgrade of the software version, but cannot be used to update configuration of these
products.
• In-place upgrade is supported on OpenStack and VMware.
Other lifecycle operations

SIMPL also supports other lifecycle operations:
• Heal: SIMPL supports 'healing' some products. This means redeploying VMs and reattaching
any persistent disks. This is useful to recover from some errors, such as memory leaks. Products

which do not support heal have other recovery mechanisms, such as Software Protection Switches
(SPS).
• Redeploy: This includes deleting and then deploying all VMs. All resources SIMPL has created,
including disks and VMs, are destroyed in this process.
• Delete: SIMPL can delete resources it has created, such as VMs, VNFs or even entire
deployments.
• Scale Out: In some limited cases SIMPL supports scaling-out. This means adding new VMs to a
cluster to provide more capacity for that service. Scale in (reducing capacity) is not yet supported.
SIMPL VM technology
The SIMPL VM uses the following underlying technologies.
• Terraform - Terraform is a tool used for deploying infrastructure, which is used on the SIMPL VM
to deploy VMs on vSphere and vCloud.
• Heat - Heat is the standard OpenStack tool used for deploying stacks (containing associated VMs,
ports, security groups etc.).
• Ansible - Ansible is an industry standard tool used to interact with network elements over SSH
and automate tasks.
• ARM - ARM is the standard tool used for deploying Azure resources (VMs, disks, NICs etc.).
Terminology
The following terminology is used within the document.
Term Meaning
VNF Virtualized Network Function. A network function running in the

cloud (Azure, vSphere, vCloud or OpenStack).
VNFC VNF Component. A logical subset of a VNF, performing a distinct

function.
VNFCI VNF Component Instance. A specific VM of a given VNFC.
Service Group A group of VNFCIs. Used for targeted deployment or upgrade. For
example, if you had a VNFC with 6 VNFCIs, you could separate
them into two Service Groups of 3, to allow deploy or upgrade of
one Service Group at a time.
VNFD VNF Descriptor. Information about how to instantiate a VNF - for

example, a Heat template.
CSAR Cloud Service Archive. A zipfile containing product images and

associated metadata.
1 Introduction to the SIMPL VM 7

Term Meaning
Solution Bundle Similar to CSARs without software images, these provide additional
metadata, configuration scripts, and validation tests for VNFs when
they are deployed as part of a known solution, for example the
Metaswitch VoLTE solution.
Day zero configuration Configuration required to get the VM to boot on the management
network.
Day one configuration Configuration that falls between "day zero" and "service"
configuration. Varies between VM types, but may include e.g.
passwords or timeouts.
Service configuration Configuration consumed by an virtualized application (sometimes

also referred to as "day two" configuration).
Upgrade Either upgrading your SIMPL VM to a new version of software, or

a csar update operation that updates the version of a deployed
VNF/VNFC.
In-place update (also known The existing VNFC updates the software on itself without any impact
as in-place upgrade) on the underlying VM. Configuration changes are not possible.
Updates apply to the whole VNFC rather than individual VMs. In-
place updates are always in-service. This means there is no loss of
service or GR-redundancy over the update.
Rolling in-service update (also Existing VMs are deleted one at a time, and replaced with one
known as rolling in-service at the uplevel version. This method also allows updating of any
upgrade) configuration. Rolling updates can either be in-service or out-of-
service. Out-of-service updates involve a loss of service for the GR-
site being updated.
Out-of-service update (also All existing VMs within a site are deleted at the same time, and
known as out-of-service replaced with instances at the uplevel version. This method also
upgrade) allows updating of any configuration. Out-of-service updates involve
a loss of service for the GR-site being updated.
Update Updating of a VNFC for any reason. This could mean an upgrade,
or it could mean a configuration change, or both. Possible updates
depend on the VNF type.

2 Planning your SIMPL VM deployment

If your deployment consists of distinct sites, you have two options for deploying SIMPL VM:
• A single SIMPL VM which manages all VMs in all sites. You will need connectivity between the
SIMPL VM and the VMs in each site.
• You can optionally have backup SIMPL VMs in one or more of the other sites; see Managing
multiple sites on page 44.
• A SIMPL VM in each site which solely manages the VMs within that site. This is only
recommended if the connectivity requirements for the first option cannot be met.
For both options, you must configure firewalls that protect your network from unauthorized traffic while
allowing SIMPL VM connections to the managed sites.
Before deploying the SIMPL VM, see:
• VM specification on page 9
• Firewall configuration and connectivity on page 10
• OpenStack requirements on page 13
• Syslog audit logging on page 15
• User access on page 16.
2.1 VM specification
The SIMPL VM is available as a QCOW2 for OpenStack, and the tooling available on it assumes the
presence of an OpenStack rig.
The SIMPL VM is deployed with an extra disk to allow recovery from failures without losing state
(see Upgrading, updating or recovering the SIMPL VM (OpenStack) on page 35). This disk, called
volume storage, is 60GB in size by default.
The volume storage size is configurable at deploy time if the default is not sufficient. If SIMPL VM
is not used for lifecycle management, the default storage should be enough. For ongoing lifecycle
management with SIMPL VM, the recommended disk size is at least 100GB. As resizing the volume
storage is not supported once the SIMPL VM is deployed, please ensure that the required volume
storage size is correctly determined before deploying the SIMPL VM. For more details on the required
volume storage, please consult your Metaswitch Professional Services Engineer.
2 Planning your SIMPL VM deployment 9

Table 1: Hardware requirements for a single SIMPL VM
VM vCPUs RAM Boot Boot Volume Volume NICs

(MB) Device storage storage storage
size speed (GB) speed
(GB) (iops) (iops)
ServiceIQ Management 2 8192 20 50 minimum 50 1

Platform (SIMPL) 60
2.2 Firewall configuration and connectivity
Attention:
If the SIMPL VM is managing multiple sites, then it must have the connectivity listed below to each
of those sites.
Note:
If you are using rsyslog, you need ports open to the rsylog server. This is typically port 514, but can
be configured as something else when setting up rsyslog for SIMPL VM - see Syslog audit logging
on page 15.
Table 2: Firewall Permissions and Connectivity
Port Transport Security Destination Direction Purpose
22 TCP Public/ Metaswitch VPN ingress/ Metaswitch VPN

private key servers (1) egress
22 TCP Public/ Metaswitch VMs IP (2) ingress/ Configuring VMs after

private key egress instantiation
443 TCP TLS dl.metaswitch.com (3) ingress/ Optional to download

egress CSARs directly from
Metaswitch instead of
manually copying them to
the SIMPL VM.
514 UDP - Remote syslog server egress Optional to allow remote

syslog over UDP
514 TCP TLS Remote syslog server egress Optional to allow remote
syslog over TLS
80 TCP HTTPS SAS VMs in egress HTTP traffic out to SAS

deployment instances
10 2 Planning your SIMPL VM deployment

3000 TCP HTTP Supported VMs (4) egress HTTP traffic out to QS
ready endpoints
4000 TCP HTTPS MDM VMs in egress HTTPS traffic out to MDM
deployment APIs
9042 TCP CQL Rhino VMs in egress CQL traffic out to Rhino
deployment VMs
9100 TCP HTTP SIMon VMs in ingress Allow SIMon to scrape

deployment node exporter metrics from
SIMPL VM
9200 TCP HTTP SIMon VMs in egress Allow SIMPL VM to send

deployment logs to SIMon
You will also require the following OpenStack-specific connectivity:
Table 3: Additional Firewall Permissions and Connectivity for OpenStack
67 UDP - 255.255.255.255 egress DHCP broadcast requests
67 UDP - Openstack ingress DHCP responses

DHCP agent for
management network
8774 TCP - OpenStack compute egress Provisioning of OpenStack

(nova) API endpoint compute instances via
HTTP
13774 TCP TLS OpenStack compute egress Provisioning of OpenStack

(nova) API endpoint compute instances via
HTTPS
8776 TCP - OpenStack block egress Provisioning of OpenStack

storage (cinder) API volumes via HTTP
endpoint
13776 TCP TLS OpenStack block egress Provisioning of OpenStack

storage (cinder) API volumes via HTTPS
endpoint
5000 TCP - OpenStack identity egress Authentication with

service (keystone) API OpenStack rig via HTTP
endpoint

13000 TCP TLS OpenStack identity egress Authentication with

service (keystone) API OpenStack rig via HTTPS
endpoint
9292 TCP - OpenStack image egress OpenStack compute image

service (glance) API repository via HTTP
endpoint
13292 TCP SSL OpenStack image egress OpenStack compute image

service (glance) API repository via HTTPS
endpoint
9696 TCP - OpenStack egress Provisioning of OpenStack

networking (neutron) networking via HTTP
API endpoint
13696 TCP TLS OpenStack egress Provisioning of OpenStack

networking (neutron) networking via HTTPS
API endpoint
8004 TCP - OpenStack egress OpenStack API for

orchestration (heat) orchestrating servers via
API endpoint HTTP
13004 TCP TLS OpenStack egress OpenStack API for

orchestration (heat) orchestrating servers via
API endpoint HTTPS
These firewall settings are automatically set up by the SIMPL VM as security-groups on OpenStack.
Note that traffic is two-way in most cases (not just one-way as "destination" implies).
1. Metaswitch's VPN servers (nexus(01-03).metaswitch.com) have the following IP addresses:
• 192.91.191.13
• 205.196.118.7
• 198.147.226.4
2. This is the management IP addresses of all of the Metaswitch nodes in the network. This
is needed for doing base commissioning and validation of the nodes once they have been
instantiated.
3. This is Metaswitch's external Artifactory repository. Access is only needed while downloading
CSARs; therefore, the pinhole may only need to be open for 2-3 hours. The current IP address is
198.147.226.33. You can check this using:
• on Linux: dig dl.metaswitch.com

• on Windows nslookup dl.metaswitch.com

4. Products which expose a health checking API on port 3000, such as MDM, SDE and QCall. See
the relevant product documentation to see if it exposes this API.
Adding additional networks

If there isn't a single network available that can connect to all the destinations above, then you will
need to add additional NICs to the SIMPL VM and configure them with standard Linux commands.
2.3 OpenStack requirements

• Version
• The SIMPL VM has been tested on OpenStack versions as far back as Newton. Regular testing
is performed on Rocky, Stein and Train. The SIMPL VM is expected to work on all versions
of OpenStack from Newton onwards. Earlier versions are likely to work but are untested and
unsupported. Heat-based instantiation is not available pre-Newton.
• Permissions
• You will need to have access to the relevant tenant. See Configuring OpenStack for the SIMPL
VM on page 18 for full details of the permissions required.
• Authentication
• Authentication details for the OpenStack user used by the SIMPL VM must be available to put
in the SDF file on the SIMPL VM (including authentication URL, project ID/tenant name, user
name, password). See Creating and editing an SDF in the SIMPL VM Product Deployment and
Management Guide.
• Within the SDF:
• When configured, allow-insecure: true allows the VIM client to connect to the VIM
without TLS, while allow-insecure: false prevents the VIM client from connecting to
the VIM without TLS.
Attention:
Unless your deployment requires this configuration, we strongly recommend that you do
not configure allow-insecure: true. Unnecessarily configuring allow-insecure:
true introduces security vulnerabilities to your deployment (for example, person-in-the-
middle attacks).
• When configured, auth-url-certificate-chain-id takes a secret identifier. This

secret can then be used to authenticate against the Openstack deployment without
configuring allow-insecure: true. The secret used must contain at least the
certificate_chain and trusted_ca_root_certs fields. For more information
on secrets and the secret store, see Adding secrets to the secret store in the SIMPL VM
Product Deployment and Management Guide.
• Keys

• You must add an SSH private key (either an existing key or a new one) to the SIMPL VM, and
the corresponding public key to your OpenStack rig. The private key must be in PEM format
and not have a passphrase.
• To generate a key run openssl genrsa -out key.pem 4096.
• Networks and access
• You must provide a way for your support representative to put CSAR files on to your SIMPL
VM. This could be done over VPN, internet access or local SCP.
• The SIMPL VM must be able to access the OpenStack APIs on the OpenStack rig. Therefore
there must be an external network that can access those APIs.
• Flavors
• Create OpenStack flavors for each product, and for the SIMPL VM. Eg. For the SIMPL VM: Run
openstack flavor create --ram 8192 --disk 20 --vcpus 1 FlavorName. This
requires OpenStack admin permissions.
• See the VM resource specification tables in the Metaswitch Products OpenStack Deployment
Design Guide to determine the resources required for each flavor.
2.4 Monitoring with SIMon or Fluentd

SIMPL is integrated with ServiceIQ Monitoring (SIMon) to provide logs, metrics and alerts, along
with dashboards and tools to monitor them across your Metaswitch solution. Alternatively, you can
integrate with an external Fluentd service for use with a third-party monitoring platform.
Metaswitch solutions are typically provided with monitoring configuration files to cover all of the
components in the solution. However, you can also use the default configuration files (which only
cover SIMPL) provided with the SIMPL VM image. If you need help implementing monitoring for your
deployment, contact your support representative.
For more information about using SIMon to monitor your deployment, see the ServiceIQ Monitoring
Deployment Guide.
Logs
SIMPL can send container and CSAR operation logs to either SIMon or an external Fluentd log
collector.
• To enable logging to SIMon, you must provide the management IP address that is or will be used
for the primary SIMon VM in the same site as the SIMPL VM.
• To enable logging to an external Fluentd log collector, you must provide the IP address for the
Fluentd server.
Attention:
You can only change the logging destination when installing or upgrading SIMPL.

Metrics
SIMon can scrape metrics from SIMPL. SIMPL exposes node_exporter (CPU/memory/disk/
networking) and fluentd metrics on ports 9100 and 24231 respectively.
SIMPL only supports manual scrape target configuration. You cannot monitor SIMPL's metrics and
alerts in a deployment that uses automatic scrape target discovery.
Metaswitch provides default metrics configuration files with the SIMPL VM image, and your
Metaswitch solution may also be provided with metrics configuration that includes SIMPL.
To enable metrics, see Manually configure scrape targets in the ServiceIQ Monitoring Deployment
Guide. No SIMPL configuration changes are required.
Alerts
SIMon can raise alerts on the basis of metrics generated by SIMPL. Metaswitch provides a default
alerting rules file with the SIMPL VM image, and your Metaswitch solution may also be provided with
alerting rules that include SIMPL.
To enable alerts, see Configure alerting rules in the ServiceIQ Monitoring Deployment Guide. No
SIMPL configuration changes are required.
Dashboards
Metaswitch provides a default Grafana dashboard file with the SIMPL VM image, and your Metaswitch
solution may also be provided with Grafana and/or Kibana dashboards that include SIMPL. You can
also create your own dashboards. Refer to your solution documentation for details.
2.5 Syslog audit logging

SIMPL VM supports sending audit logs to a remote syslog server over UDP and TLS. When enabled,
this sends all audit logs generated by the Linux audit framework (such as authentication attempts and
command line activity) to your remote syslog server over UDP or TLS (not provided by Metaswitch).
We recommend configuring syslog over TLS if supported by your remote syslog server.
Configuring syslog over TLS support for Openstack

We recommend configuring syslog over TLS if your remote syslog server supports TLS.
To enable syslog over TLS support, set the following fields in the OpenStack environment file:
• remote_syslog_server_address : the FQDN of the remote syslog server, for example

myhost.example.co.uk
• remote_syslog_server_port : the port number of the remote syslog server. Defaults to 514.
Attention:

Using an IP address for remote_syslog_server_address will result in an error for syslog over
TLS. You must use an FQDN.
Note that these fields can be configured when the SIMPL VM is initially deployed following Deploying
SIMPL (OpenStack) on page 19, or by updating configuration on an existing SIMPL VM following
Upgrading, updating or recovering the SIMPL VM (OpenStack) on page 35.
Run the procedure in Configuring syslog support over TLS on page 32 once SIMPL VM has
finished installing to finish configuring syslog over TLS.
Configuring syslog over UDP support for OpenStack

To enable syslog over UDP support, set the following fields in the OpenStack environment file:
• remote_syslog_server_address : the IP address of the remote syslog server

• remote_syslog_server_port : the port number of the remote syslog server. Defaults to 514.
These fields can be configured when the SIMPL VM is initially deployed following Deploying SIMPL
(OpenStack) on page 19, or by updating configuration on an existing SIMPL VM following
Upgrading, updating or recovering the SIMPL VM (OpenStack) on page 35.
Syslog interoperability requirements

SIMPL requires that the remote server:
• has firewalls configured to allow traffic on the relevant syslog ports

• is running a syslog service
• has the correct configuration to forward received logs to the desired files.
2.6 User access

The SIMPL VM is a privileged system with considerable power to alter your deployment. There is a
risk that a user may accidentally run a command that could delete or damage your deployment. The
SIMPL VM reduces this risk by restricting the commands available to logged-in users. The SIMPL VM
supports three users: admin, lifecycle-mgmt and secrets-mgmt. Each user has access to a different
set of commands.
This feature is designed to reduce the risk of a user accidentally damaging the deployment in the
course of their day-to-day operations. It is not designed to be proof against a determined, malicious
attacker. The SIMPL VM is a privileged system and, as such, all logins must be kept safe and secure
in a modern credential management system.
• The admin user allows access to all SIMPL VM CLI commands. It also has root permissions for
the SIMPL VM's operating system.
• The lifecycle-mgmt user restricts CLI commands to those that perform lifecycle operations or
display diagnostic information about your deployment. The lifecycle-mgmt user is not permitted
to use csar commands that modify any secret information in the SIMPL VM secret store, but the

user is not prevented from bypassing those commands and interacting with the secret store's API
directly.
• The secrets-mgmt user restricts CLI commands to those that manage secret information in the
SIMPL VM secret store or display diagnostic information about your deployment. The secrets-
mgmt user is not permitted to use csar commands that modify the state of the VNFs in your
deployment, but the user is not prevented from bypassing those commands to interact with the
underlying functionality directly.
Attention:
All of these users have considerable power to retrieve secret information about your deployment,
alter its state, or both. You must keep the passwords for these users secure.
User Lifecycle Secrets Diagnostics Root

operations permissions
admin Yes Yes Yes Yes
lifecycle-mgmt Yes No Yes No
secrets-mgmt No Yes Yes No
The SIMPL VM also supports integration with a RADIUS server. You can configure users on your
RADIUS server to map to the admin, lifecycle-mgmt, and secrets-mgmt users on SIMPL VM. To
enable RADIUS, see Initial configuration on page 29.

3 Deploying the SIMPL VM

To deploy the SIMPL VM, perform the following steps:
1. Ensure you have the appropriate configuration: Configuring OpenStack for the SIMPL VM on page
18
2. Deploy the SIMPL VM: Deploying SIMPL (OpenStack) on page 19
3. Perform initial configuration of the SIMPL VM: Initial configuration on page 29.
3.1 Configuring OpenStack for the SIMPL VM

OpenStack provides the identity service keystone for client authentication and granting access to
OpenStack services for individual users. Depending on the keystone version of your OpenStack
rig, the collection of permissions is called a tenant (keystone v2) or a project (keystone v3). All
required credentials for either a tenant or a project are referred to as the keystone credentials. You
can download them from the OpenStack GUI (from the menu "API Access").
You need different permissions for deploying the SIMPL VM and using the SIMPL VM to deploy other
products. You must have an appropriately configured tenant or project for each purpose. You must
also provide the keystone credentials for the account that the SIMPL VM uses so that the SIMPL
VM can connect to that tenant.
Deploying the SIMPL VM

To deploy the SIMPL VM on OpenStack and to create flavors for any other products you want to
deploy with the SIMPL VM, you will need an Admin user with permissions to:
• create an image
• create a flavor
• create key pairs.
Attention:
We strongly recommend ensuring this user has no more permissions than those described above
and in particular no permissions on tenants / projects for which the SIMPL VM will not manage
infrastructure.
Using the SIMPL VM

To deploy Metaswitch VNFs you need to create an appropriate account for the SIMPL VM using an
OpenStack admin account. The SIMPL VM needs an account with the following permissions:
• API access - SIMPL VM must be able to access the OpenStack APIs on the OpenStack rig. The
required ports to have open are listed in Firewall configuration and connectivity on page 10.
• Images - SIMPL VM needs to create and upload new, public images.
18 3 Deploying the SIMPL VM

• Resources - SIMPL VM needs to be able to list available CPU, RAM, disk (cinder), ephemeral
disk (nova) for validation.
• VMs - SIMPL VM needs to be able to create and delete VMs (within the tenant/project).
• Security Groups - SIMPL VM needs to be able to create new security groups.
• Ports - SIMPL VM needs to create new ports in network.
• Port security - In the unusual situation where disabling port security is required on the ports the
SIMPL VM creates, the OpenStack Neutron policy defined on the hosts on which ports will be
created needs to allow the SIMPL VM to configure the port_security_enabled attribute when
creating ports.
• Volumes - SIMPL VM needs to create and delete data volumes.
• Server Groups - SIMPL VM needs to be able to create and delete server groups.
• Software / Cloud config - SIMPL VM needs to be able to create and delete software config or
cloud config.
3.2 Deploying SIMPL (OpenStack)

To deploy the SIMPL VM in OpenStack, follow:
1. Preparing for deployment (OpenStack) on page 19

2. Deploying the SIMPL VM (OpenStack) on page 23.
3.2.1 Preparing for deployment (OpenStack)
Before you begin
1. Obtain the following information:
• Management IP address
• ID of the management network configured on OpenStack
• Run openstack network list and record the value of the ID parameter for the desired
network
• Management DNS servers and default search domain, if used
• Remote syslog server FQDN or IP address and port, if used.
• If you want to use an existing key pair for SSH access to the SIMPL VM, the name of the key
pair
• Run openstack keypair list to list all key pairs on your Openstack server.
2. Download the latest image from dashboard.metaswitch.com.
• Download the SIMPL-VM-OpenStack-Version.zip zip file containing the QCOW2 image,

Heat templates and environment files.
• Extract the following files from the zip file:
• QCOW2 image simpl_vm_Version.qcow2

• simpl_heat_files_Version.zip file, containing the SIMPL VM Heat templates.
3 Deploying the SIMPL VM 19

3. Make sure that the version of this documentation matches the image version you have
downloaded.
4. Ensure you have completed any appropriate configuration in Configuring OpenStack for the SIMPL
VM on page 18.
About this task
This task creates the Glance image, Openstack flavor and security groups and completes the
environment files required to deploy a SIMPL VM instance.
These steps use the OpenStack Command Line Interface (CLI).
This task does not require a maintenance window.
Create OpenStack objects
Create Glance image
1. Log in to your OpenStack client server - the server or device you use to administrate your
OpenStack deployment, running the OpenStack command line clients - and load your OpenStack
environment settings.
2. Copy simpl_vm_Version.qcow2 to any directory on your OpenStack client server and navigate
to that directory.
3. Create the Glance image. The ImageName can be any alphanumeric string, e.g.
msw_simpl_vm_Version. Make a note of the ImageName to use in the environment files later in
this procedure.
openstack image create --private --disk-format qcow2

--file simpl_vm_Version.qcow2 --container-format bare ImageName
where Version is replaced by the appropriate version e.g. 1.3.0.
This may take several minutes. If the image is created successfully, you will see a table with its
parameters and status active. Otherwise, you will see an error.
Create Openstack flavor
1. Create an OpenStack flavor using the hardware requirements detailed in VM specification on page
9. The FlavorName can be any string. Make a note of the FlavorName to use in the environment
files later in this procedure.
openstack flavor create --ram ram --disk Boot-GB --

vcpus CPUs FlavorName
For example:
openstack flavor create --ram 8192 --disk 20 --vcpus 2 msw_simpl_vm
If the flavor is created successfully, you will see a table with its parameters. Otherwise, you will see
an error.

2. Update this flavor with the following OpenStack platform settings. You can use multiple --
property flags to provide all settings in a single line. (This example includes line breaks for
readability.)
openstack flavor set

--property hw:cpu_policy=dedicated
--property hw:cpu_thread_policy=prefer
--property hw:numa_nodes=1
--property hw:watchdog_action=reset
--property hw:thick_provisioning_support=true
FlavorName
3. Check that the flavor properties were successfully updated:
openstack flavor show FlavorName
You should see the same table from the openstack flavor create command but with the
properties section now containing the platform settings.
Create security groups
Deploying the SIMPL VM automatically creates the security group that includes individual rules
to allow or block specific types of traffic. The types of traffic that are enabled are listed in Firewall
configuration and connectivity on page 10.
Create OpenStack key pair
Keys are needed for:
• SSH access to the SIMPL VM, and

• SSH access to product VMs instantiated by the SIMPL VM.
You can use the same key for both purposes. These keys must be uploaded to OpenStack and stored
locally. There are three options:
• If you have an existing key pair on your OpenStack server that you want to use, note its name for
use when filling the environment files. To view all key pairs:
openstack keypair list
• Create the Openstack key pairs using the CLI:
openstack keypair create KeypairName > KeypairName.pem
with KeypairName replaced by the name for the key pair. This creates the private key file
KeypairName.pem. Make a copy of this file, as you will need it for SSH access to the SIMPL VM.
• Alternatively, use the GUI to create a new key or load an existing key by navigating in the
OpenStack GUI to Project > Compute > Key Pairs, then selecting either Create Key Pair
or Import Public Key.
Optionally create one or more additional key pairs
These additional keys are needed for lifecycle-mgmt and the secrets-mgmt SSH access to the SIMPL
VM. These keys must be uploaded to OpenStack and stored locally.

Note:
We suggest using key pair names that are meaningful and easily recognized to avoid confusion
between them.
For each key pair:
1. Using OpenSSH, generate a new RSA public/private key pair. The following command generates a
PEM formatted 4096 bit RSA key. The key pair name can be any alphanumeric string.
ssh-keygen -t rsa -m pem -C "keypair-name" -b 4096
2. When be prompted to provide a passphrase press enter twice to generate a private key without a
passphrase. SIMPL does not support the use of private keys with passphrases.
3. Save the keys that the command generates: the private key keyfilename and the corresponding
public key keyfilename.pub.
Determining volume storage size
The SIMPL VM is deployed with an extra disk called volume storage, which has a default size
of 60GB. If you are using SIMPL for ongoing lifecycle management, this might not be sufficient.
Determine your necessary volume storage size as described in VM specification on page 9
Attention:
The volume storage size cannot be changed once the SIMPL VM has been deployed. Please
ensure you have determined the correct size before deploying.
Complete the environment files
1. Edit the simpl_instance.env environment file in a text editor and fill out the values as
described below. The env file is in YAML format and requires a whitespace character after the
colon. For example, the node_name parameter would appear as follows:
node_name: example-simpl-vm-name
• node_name: A node name of your choice for the SIMPL VM
• image: The name of the image you uploaded previously (e.g. msw_simpl_vm_Version)
• management_ip: The management IP you chose for the SIMPL VM
• management_net_id: The ID of the management network configured on OpenStack
• management_gateway_ip: The gateway IP address for the management network. Optional,
will default to the gateway configured in Openstack on the relevant subnet of the management
network
• timezone: An IANA time zone (e.g. Etc/UTC). Deprecated timezones (e.g. US/Central) are not
supported.
• ssh_keypair_name: Name of the admin SSH key pair you created earlier.
• secrets_mgmt_simpl_logon_public_key: Public key of the secrets-mgmt SSH key pair you
created earlier.

• lifecycle_mgmt_simpl_logon_public_key: Public key of the lifecycle-mgmt SSH key pair you

created earlier.
• flavor: The name of the flavor you created earlier (e.g. msw_simpl_vm)
• dns_search_domain: If you use a DNS search domain, fill it in here, otherwise leave blank
• dns_servers: A comma-delimited list of DNS servers the SIMPL VM should use
• csar_volume_id: Leave this blank for now. Later in this procedure, you will be instructed to fill
in the correct value
• install_vpn: A Boolean specifying whether to install the Metaswitch VPN on the SIMPL VM. It
defaults to 'true'. Please discuss Metaswitch support access with your support representative if
you decide to set this to 'false'.
• remote_syslog_server_address: The FQDN or IP address of the remote syslog server.
Optional, but required for remote syslog support. See Syslog audit logging on page 15.
• remote_syslog_server_port: The port of the remote syslog server. Optional, but required for
remote syslog support.
• simon_mgmt_ip: The management IP address of the SIMon VM to be used to monitor SIMPL
VM. Optional, but required for monitoring SIMPL VM using SIMon.
• fluentd_server_addresses: A comma-delimited list of IP addresses for Fluentd to stream logs
to. Optional, but required for streaming logs to a remote Fluentd collector.
2. Edit the simpl_volumes.env environment file in a text editor and fill out the keys as follows:
• node_name: The node name of the SIMPL VM, which needs to be the same as in
simpl_instance.env
• simpl_volume_size: The size of the volume storage in GBs, which you have determined in
Determining volume storage size on page 22
3. Copy the Heat templates (.yaml) and environment files (.env) to a directory you can use the
OpenStack CLI from.
4. Ensure you take a backup of all of the installation files. You will need these to recover from failure.
Results
Your SIMPL VM installation files, OpenStack flavor and Glance image should now be ready to use to
install the SIMPL VM.
What to do next
Go to Deploying the SIMPL VM (OpenStack) on page 23
3.2.2 Deploying the SIMPL VM (OpenStack)
Before you begin
Ensure you have completed Preparing for deployment (OpenStack) on page 19. Specifically:
• You have copied all of the following files to your OpenStack client server: the server or device you
use to administrate your OpenStack deployment, running the OpenStack command line clients.
• simpl_instance_template.yaml

• simpl_volumes_template.yaml
• You have completed the environment files simpl_instance.env and simpl_volumes.env
and copied simpl_volumes.env to your OpenStack client server. You will copy
simpl_instance.env as part of the procedure.
• You have a copy of the private SSH key that matches the public SSH key required in the
environment file.
• You have created the OpenStack flavor.
• You have created the Glance image.
• You have created a security group.
You must also make sure that
• You know the values of the following information:
• OPENSTACK USER
• OPENSTACK PASSWORD
• OPENSTACK AUTH URL
• OPENSTACK AUTH URL CERTIFICATE CHAIN
• OPENSTACK PROJECT NAME
• OPENSTACK PROJECT ID
• OPENSTACK REGION
• OPENSTACK USER DOMAIN NAME
• OPENSTACK PROJECT DOMAIN NAME
• You have decided on secret identifiers for OPENSTACK PASSWORD and OPENSTACK AUTH URL
CERTIFICATE CHAIN. These secret identifiers are alphanumeric strings that will replace the
values of OPENSTACK PASSWORD and OPENSTACK AUTH URL CERTIFICATE CHAIN in the
SDF. The secret values will be added to the secret store as part of this procedure.
About this task
This task deploys a SIMPL VM on Openstack and checks it has installed correctly. It then checks
SIMPL-VM connectivity to Openstack. It does not require a maintenance window.
Expected time to run this procedure: 30 minutes
Expected time to revert this procedure: 5 minutes
The SIMPL VM comprises two Heat orchestration stacks, a volume stack for the external disk and an
instance stack for the virtual machine instance (the server) itself. Once created, the volume stack has:
• a name, which you should choose when creating it, e.g. simpl_volume_stack, referred to as
VolumeStackName
• an output called Volume ID. The value of this is referred to as VolumeID and is used to attach the
volume to the instance.
The virtual machine instance (or server) has:
• a name for the instance itself, specified by the node_name in the simpl_instance.env file

• a name for the instance stack, which you should choose when creating it, e.g.
simpl_instance_stack, referred to as InstanceStackName
Create the VM
1. Create the volume stack:
openstack stack create -t simpl_volumes_template.yaml -e

simpl_volumes.env VolumeStackName
replacing VolumeStackName with the name to use for your volume stack.
2. Get the Volume ID output from your stack:
openstack stack show VolumeStackName
and noting the output_value corresponding to the Volume ID. This will be used when deploying
the server, referred to as VolumeID. (Be careful not to confuse Volume ID with the value of the
stack id. This is not used in this procedure).
3. Edit the simpl_instance.env environment file in a text editor and fill out the csar_volume_id
parameter with the VolumeID value. Copy this file to your OpenStack client server.
4. Create the instance stack:
openstack stack create -t simpl_instance_template.yaml -e

simpl_instance.env InstanceStackName
replacing InstanceStackName with the name to use for your instance stack.
5. Ensure you take a backup of all of the installation files and record the InstanceStackName. You
will need these to recover from failure, and for tightening the SIMPL VM's security group once
installed.

Verify the SIMPL-VM has installed correctly
1. Wait a few minutes to allow the installation to complete.

2. On the OpenStack client server, check the stack creation was successful:
openstack stack show InstanceStackName
Check that:
• The stack_status is CREATE_COMPLETE

• The stack_status_reason is Stack CREATE completed successfully.
Note:
The setup process may still be running after OpenStack reports Stack CREATE completed
successfully. If any further verification steps fail, try waiting another 5-10 minutes before
repeating the verification step.
If errors persist for any verification steps, refer to Backout on page 29.
3. Using your private key, log in to the SIMPL VM over SSH as the admin user. Confirm the
command prompt is available.
For details on how to do this see Initial configuration on page 29.

4. Run simpl-setup-complete and confirm that it reports that first time install is complete.
5. Check that the csar --help command executes successfully.
6. Run csar secrets check-backend-connectivity and confirm that it reports success. It
may take a few minutes for secret store setup to complete. If csar secrets check-backend-
connectivity does not succeed on the first attempt, wait five minutes and retry.
Verify SIMPL-VM can connect to Openstack
1. Using your private key, log in to the SIMPL VM over SSH as the admin user.
2. Check the setup on OpenStack platform:
a. Edit the ~/minimal_sdfs/sdf-minimal-openstack.yaml template file and replace the

OpenStack connection information with the details for the OpenStack platform the SIMPL VM
will deploy to. You will need to replace the following information:
• <OPENSTACK USER>
• <OPENSTACK PASSWORD IDENTIFIER>
• <OPENSTACK AUTH URL>
• <OPENSTACK AUTH URL CERTIFICATE CHAIN IDENTIFIER>
• <OPENSTACK PROJECT NAME>
• <OPENSTACK PROJECT ID>
• <OPENSTACK REGION>
• <OPENSTACK USER DOMAIN NAME>
• <OPENSTACK PROJECT DOMAIN NAME>

b. Run csar secrets create-input-file --sdf ~/minimal_sdfs/sdf-minimal-

openstack.yaml
to generate a templated input file for the <OPENSTACK PASSWORD IDENTIFIER> and
<OPENSTACK AUTH URL CERTIFICATE CHAIN IDENTIFIER>.
c. Add the OPENSTACK PASSWORD to the generated input file.
d. Create two files on SIMPL VM, one containing the PEM encoded certificate chain and one
containing the PEM encoded trusted root CA certificate for the OPENSTACK AUTH URL
CERTIFICATE CHAIN. Add the paths to these files to the generated secret input file.
e. Run csar secrets add secret_input_file.yaml.
f. Check that running csar deploy --dry-run --sdf ~/minimal_sdfs/sdf-minimal-
openstack.yaml does not report any errors.
Troubleshooting
If you have any problems, the first recommendation is to Backout on page 29 and start again.
However, here are a few troubleshooting suggestions. Before doing so, ensure that you understand
the concepts in About this task on page 24.
OpenStack CLI output levels
The OpenStack CLI ERROR output gives useful information in the case where your environment files
have errors in them. For example:
ERROR: Property error: :

resources.management_port.properties.fixed_ips[0].ip_address:
: Error validating value '10.254.88.2442': Invalid IP address
or:
ERROR: Property error: :

resources.server.properties.block_device_mapping_v2[0].volume_id:
: Error validating value 'e13df703-2c1e-4171-af88-23ecec27fba': The
Volume
(e13df703-2c1e-4171-af88-23ecec27fba) could not be found.
You may see the following error if either simpl_instance.env or simpl_volumes.env contain
invalid YAML:
ERROR: Internal Error

END return value: 1
If this happens, use a text editor with a YAML plugin to validate that the files are syntactically valid and
repeat the failing operation.
If this information is not sufficient, you can add the --verbose flag for more information or the --
debug option for full debug logging.
Viewing the stacks and volume
To view the stacks, use the OpenStack commands:



If successfully deployed, the volume is mounted to the SIMPL VM and accessible via the cdcsars
command on the SIMPL VM. If you think there is a problem with the volume, the command, see
information regarding the volume created for SIMPL:
openstack volume show csar_volume_id
For example:
openstack volume show e13df703-2c1e-4171-af88-23ecec27fba6
In the above example, the attachments field value shows no attachments, indicating that the
volume is not attached to a server. A healthy volume attachment would show the server attachment
(formatted here for readability):
You can also check that the server created is the one attached. The two following commands should
show the same output:
openstack server show node_name
openstack server show server_id

server_id is found from the attachments on the volume.
Backout
Deploying the SIMPL VM should not require any backout. If the procedure needs to be stopped for
any reason, this can be done at any stage.
If there is the need to delete the VM to retry its install, you can do so by destroying the instance and
volume stacks:
1. On your OpenStack client server, destroy the stack:

openstack stack delete InstanceStackName
You will be prompted to enter y to confirm.
2. Wait one minute, then check the delete was successful:
The command should return Stack not found.
3. On your OpenStack client server, destroy the volume stack:
openstack stack delete VolumeStackName
Attention:
Do not delete the SIMPL VM once you have started creating and managing deployments with it, as
it stores important running state which must not be lost.
Results
You have deployed the SIMPL VM.
What to do next
Go to Initial configuration on page 29.
3.3 Initial configuration

Once you have installed the SIMPL VM, you must perform some initial configuration.
Log in to the SIMPL VM with user credentials

Open an SSH connection to the management IP address of your SIMPL VM and log in as the admin
user.

Log in to the SIMPL VM with RADIUS

If you have a RADIUS server, you can use RADIUS authentication for additional users by providing
the RADIUS server details at any time after you have deployed your SIMPL VM. You will also need
to configure your RADIUS server to operate with your Metaswitch VMs - see Configuring central
authorization for externally authenticated users in the Metaswitch Knowledge Base. For background
information on RADIUS, see RADIUS technology overview.
In order to enable RADIUS based authentication on your SIMPL VM, please first log in as the admin
user as shown in the Log in to the SIMPL VM with user credentials section.
Run the following command: sudo enable_radius PAM_RADIUS_SERVER=<IP of your

RADIUS server> PAM_RADIUS_SERVER_SECRET=<Authentication string set up
on your RADIUS server> PAM_RADIUS_ROLE_VENDOR_TYPE=<Vendor type you have
configured on your RADIUS server> PAM_RADIUS_LOCAL_USERS="admin,lifecycle-
mgmt,secrets-mgmt"
The variables attached to the command are explained below:
• PAM_RADIUS_SERVER - The IP address of your RADIUS authentication server

• PAM_RADIUS_SERVER_SECRET - The secret authentication string used to authenticate your
RADIUS server against the SIMPL VM. This will be configured on your RADIUS server.
• PAM_RADIUS_ROLE_VENDOR_TYPE - This number is the vendor type that you configure to
reference the SIMPL VM user role on the RADIUS server.
• PAM_RADIUS_LOCAL_USERS - This is the list of user roles present on the SIMPL VM.
In order to disable RADIUS authentication, simply run the following command: sudo
enable_radius
Add SSH keys for lifecycle-mgmt and secrets-mgmt
Attention:
The SIMPL VM has powerful credentials to access your virtual infrastructure. These credentials
could be retrieved by SSH access.
The SIMPL VM has three users with different levels of permissions: admin, lifecycle-mgmt, and
secrets-mgmt. You can skip this step if you have already created an SSH key pair for all three user
types during deployment.
If you did not create the optional key pairs during deployment, you can now configure SSH keys for
lifecycle-mgmt, and secrets-mgmt users.
• To configure keys for the lifecycle-mgmt user:
1. Log into the SIMPL VM as the admin user.

2. Open /home/lifecycle-mgmt/.ssh/authorized_keys as the superuser.
3. Edit the file by entering one or more lifecycle-mgmt users' public keys and saving the
change.

4. Log out of the SIMPL VM.

5. Verify you can open an SSH connection to the SIMPL VM, using each of the lifecycle-
mgmt users' private key.
• To configure keys for the secrets-mgmt user:
1. Log into the SIMPL VM as the admin user.

2. Open /home/secrets-mgmt/.ssh/authorized_keys as the superuser.
3. Edit the file by entering the one or more secrets-mgmt users' public keys and saving the
change.
4. Log out of the SIMPL VM.
5. Verify you can open an SSH connection to the SIMPL VM, using each of the secrets-mgmt
users' private key.
Agree with your Metaswitch Commissioning Engineer which users they require access to and securely
share the relevant keys with them. See User access on page 16 for further information on these
users.
Install tools
When the VM is first booted it installs several tools, which takes a few minutes.
You can check the installation status by running simpl-setup-complete.
• You can check the progress in more detail by running sudo journalctl -u simpl_startup
VPN
Create a VPN connection with the Metaswitch VPN server. This provides a way for your support
representative to access the SIMPL VM. It is only possible if the VPN service has been installed on
the SIMPL VM (which is true by default).
1. Run sdc.
2. Register the VPN using the Register VPN craft menu item. This registers your SIMPL VM VPN
service with Metaswitch's servers. You will be prompted to confirm this task before it is carried out.
3. Start the VPN with the Start VPN craft menu item.
4. Check the VPN status with the VPN Status craft menu item. The Status should be VPN Active.
If this is not the case, please contact your support representative.
3.4 Change SSH timeout according to security policy

By default, the SSH connection to a SIMPL VM times out after 5 minutes of inactivity, which is
implemented as a default best security practice. If this is not in accordance with your security policy,
you can manually change the timeout.
Note that some commands run on the SIMPL VM can run for several minutes, where the duration
increases with the number of VNFs you are interacting with. If commands run longer than the SSH
timeout, your connection will be terminated. To prevent this from happening you can increase the SSH

connection timeout to a conveniently high value, if your security policy allows this. Additionally, the
SIMPL VM uses the Linux screen tool (as described in Using the screen command for long running
actions on page 42) to allow commands to continue running if your connection is terminated.
Using your private key, log in to the SIMPL VM over SSH as the admin user.
To change the SSH timeout run set-ssh-timeout <timeout in seconds>, where you need to
provide a timeout larger or equal to 60 seconds.
3.5 Configuring syslog support over TLS
Note:
The following configuration does not persist over upgrade and will need to be re-applied after each
upgrade.
The following steps configure SIMPL VM to use syslog over TLS. We recommend configuring syslog
over TLS if your remote syslog server supports it.
If you configured the rsyslog server without TLS during installation, you can follow this procedure to
reconfigure it.
SIMPL VM also supports syslog over UDP - see Syslog audit logging on page 15.
This procedure is expected to take 10 minutes and does not need to be done during a maintenance
window.
Configure syslog
2. Append the following to /etc/vm_config.yaml below all existing configuration.
remote_syslog should not be indented. If the file does not exist, create it with just the following
configuration:
remote_syslog:
address: "address"
port: "port"
filters:
- "$programname == 'audispd'"
- "$syslogfacility-text == 'authpriv'"
tls_ca_cert: "/etc/certs-agent/upload/syslog_server_ca.pem"
tls_client_cert: "/etc/certs-agent/upload/syslog_client_cert.pem"
tls_client_key: "/etc/certs-agent/upload/syslog_client_key.pem"
• address is the management FQDN address as a string of the remote syslog server
and must be provided to use rsyslog. This will have already been set if you filled in the
remote_syslog_server_address field when deploying the SIMPL VM.
Attention:

Using an IP address for address will result in an error for syslog over TLS. You must use an
FQDN.
• port is the port of the rsyslog server as a string, it defaults to 514 and must be a valid port
(number from 0->65535). The rsyslog server must expect traffic on this port. This will have
already been set if you filled in the remote_syslog_server_port field when deploying the
SIMPL VM.
• tls_ca_cert is only required if TLS-encrypted TCP is to be used. The certificate must specify
the FQDN of the remote syslog server, either in its SAN DNS names or CN. Create a new file
containing the key at the specified path. You may need to create the directories for this path. If
you are not using TLS-encryped TCP, remove this line.
• tls_client_cert and tls_client_key are only required for mutual TLS (and should both be
provided or neither). If they are not provided, server-only authentication will be used. These
can only be provided if tls_ca_cert is. If providing the certificate and key, new files should be
created at the paths you specified in vm_config.yaml containing the certificate and key. If
you are not using mutual TLS, remove these lines.
• filters are required and it is not expected they are required to be changed. Please check with
your support representative before changing these.
3. Generate the configuration file:
sudo generate_config --templates /etc/templates/etc/rsyslog.d/ --
settings /etc/vm_config.yaml --destination /etc/rsyslog.d/
4. Add audit logging to the syslog configuration:
sudo /usr/sbin/set_audit_rules --enable-syslog admin secrets-mgmt
lifecycle-mgmt
• If you have specified a DNS server when deploying SIMPL, verify that the FQDN resolves to the
IP address of the remote syslog server by running the following:
nslookup syslog_fqdn_address
This should print out the IP address of the remote syslog server. If the server could not find the
address, the FQDN needs to be added to the DNS server's records.
• If you do not have a DNS server, open the hosts file at the path /etc/hosts (requires sudo
access) and add the following line to the end of the file:
syslog_ip_address syslog_fqdn_address
where syslog_ip_address is the IP address of your syslog server and syslog_fqdn_address
is the FQDN for the syslog server that appears in /etc/vm_config.yaml . This will allow you
to resolve the address without a DNS server.
5. Restart the rsyslog service to pick up the configuration changes:
sudo service rsyslog restart
Verification
• Check the rsyslog has started successfully:
sudo systemctl status rsyslog.service

The output should include Active: active (running).

• Check that rsyslog is picking up the logs and commands being run on the VM as expected.
Backout process
• Remove the remote_syslog section you added to /etc/vm_config.yaml , or delete the file if
remote_syslog is the only configuration in the file.
• Run sudo rm /etc/rsyslog.d/remote_syslog.conf
• Run sudo /usr/sbin/set_audit_rules admin
• Run sudo service rsyslog restart

4 Managing the SIMPL VM

For information on managing your SIMPL VM, see:
• Upgrading, updating or recovering the SIMPL VM (OpenStack) on page 35

• Using the screen command for long running actions on page 42
• Destroying the SIMPL VM on page 42.
4.1 Upgrading, updating or recovering the SIMPL VM (OpenStack)
Before you begin

1. Obtain the following information:
• The Heat templates (.yaml) and environment (.env) files used to deploy the SIMPL VM.
• The SIMPL VM's instance name and stack name.
• To find the instance name (referred to as InstanceName), use one of these two methods:
• Open your original simpl_instance.env environment file and find the value of the
node_name parameter
• Run openstack server list and find the SIMPL VM in the Name column.
• To find the instance stack name (referred to as InstanceStackName), run openstack
stack list to find the stack name, then ensure this is the correct stack by running
openstack stack show InstanceStackName and check that the node_name
matches InstanceName.
2. If upgrading: Download the latest image from dashboard.metaswitch.com.
• Download the SIMPL-VM-OpenStack-Version.zip zip file containing the QCOW2 image,

Heat templates and environment files.
• Extract the following files from the zip file:
• QCOW2 image simpl_vm_Version.qcow2

• simpl_heat_files_Version.zip file, containing the SIMPL VM Heat templates.
3. Make sure that the version of this documentation matches the image version used by the new
SIMPL VM you are deploying using this procedure.
4. If you want to change any of the configuration in the instance environment file
(simpl_instance.env), identify the relevant parameters before starting this procedure. Do not
change the csar_volume_id parameter.
Check CSAR compatibility (upgrade only)
If you are upgrading to a new SIMPL VM version, you must confirm your downlevel CSARs are
compatible with the uplevel SIMPL VM.
4 Managing the SIMPL VM 35

Run simpl-version to get a list of your CSAR versions. Ask your support representative if these
are compatible with the uplevel SIMPL VM.
Note:
A SIMPL VM on version A.B.C supports CSARs from version A.0.0 to A.B.X. In particular that
means that it does not support a CSAR on version A.B+1.X.
For example: A SIMPL VM on version 1.2.3 supports CSARs 1.0.0, 1.0.15, 1.1.0, 1.2.999. It does
not support 0.9.9, 1.3.0 or 2.0.0.
If all your CSARs are incompatible with the uplevel SIMPL VM, then there is no reason to follow
this procedure, as the CSARs stored on the separate volume are not useful and will need to be
replaced. You should just delete your old SIMPL VM and start again, replacing it with a new SIMPL
VM following Deploying SIMPL (OpenStack) on page 19.
About this task

This task upgrades a SIMPL VM on OpenStack to a new version by reinstalling it. You can also use
this task to change configuration on the SIMPL VM (without upgrading) or restore the SIMPL VM after
a failure.
The SIMPL VM holds some state about the products it manages (such as CSARs and VNFDs). This
state is stored on a separate volume, so you can recover it after reinstallation.
This task does not require a maintenance window, however, you should not use the SIMPL VM to
perform any operations on your deployment until it is complete.
Expected time to revert this procedure: 10 minutes
Prepare for SIMPL VM upgrade or recovery (Openstack)
Create Glance image (upgrade only)
1. Copy simpl_vm_Version.qcow2 to any directory on your OpenStack client server and navigate
to that directory.
2. Create a new image of the version you plan to upgrade to. The ImageName can be any
alphanumeric string, e.g. msw_simpl_vm_Version. Make a note of the ImageName to use in the
environment file later in this procedure.
openstack image create --private --disk-format qcow2

--file simpl_vm_Version.qcow2 --container-format bare ImageName
This may take several minutes. If the image is created successfully, you will see a table with its
parameters and status active. Otherwise, you will see an error.
Create OpenStack key pair (upgrade only)
From SIMPL V6.10.0, keys are needed for:
36 4 Managing the SIMPL VM

• SSH access to the SIMPL VM

• SSH access to product VMs instantiated by the SIMPL VM.
Attention:
You must add an SSH key for access to the SIMPL VM if you have not already done so. Password
access is not supported from SIMPL V6.10.0.
You can use the same key for both purposes. These keys must be uploaded to OpenStack and stored
locally. There are three options:
• If you have an existing key pair on your OpenStack server that you want to use, note its name for
use when filling the environment files. To view all key pairs:
openstack keypair list
• Create the Openstack key pairs using the CLI:
openstack keypair create KeypairName > KeypairName.pem
with KeypairName replaced by the name for the key pair. This creates the private key file
KeypairName.pem. Make a copy of this file, as you will need it for SSH access to the SIMPL VM.
• Alternatively, use the GUI to create a new key or load an existing key by navigating in the
OpenStack GUI to Project > Compute > Key Pairs, then selecting either Create Key Pair
or Import Public Key.
Optionally create one or more additional key pairs
These additional keys are needed for lifecycle-mgmt and the secrets-mgmt SSH access to the SIMPL
VM. These keys must be uploaded to OpenStack and stored locally.
Note:
We suggest using key pair names that are meaningful and easily recognized to avoid confusion
between them.
For each key pair:
1. Using OpenSSH, generate a new RSA public/private key pair. The following command generates a
PEM formatted 4096 bit RSA key. The key pair name can be any alphanumeric string.
ssh-keygen -t rsa -m pem -C "keypair-name" -b 4096
2. When be prompted to provide a passphrase press enter twice to generate a private key without a
passphrase. SIMPL does not support the use of private keys with passphrases.
3. Save the keys that the command generates: the private key keyfilename and the corresponding
public key keyfilename.pub.
Complete the environment file
1. Fill in the simpl_instance.env file downloaded alongside the new image, using the previous
version of this file as your starting point.

• If you are not upgrading the SIMPL VM or changing any configuration, skip this step and use
the files gathered in Before you begin on page 35.
• (Upgrade only) Set the image parameter to the ImageName you specified above.
• (Upgrade only) Add the SSH keys you created earlier:
• ssh_keypair_name: Name of the admin SSH key pair.

• secrets_mgmt_simpl_logon_public_key: Public key of the secrets-mgmt SSH key pair.
• lifecycle_mgmt_simpl_logon_public_key: Public key of the lifecycle-mgmt SSH key pair.
• Set new values for any other parameters identified during Before you begin on page 35.
• Copy all other values from the previous version of the environment file.
2. Copy the instance Heat template (simpl_instance_template.yaml) and instance
environment file (simpl_instance.env) to a directory you can use the OpenStack CLI from.
You do not need the volume Heat template and environment file for this procedure.
Take backup copies of files
Any resources in /home/admin/ not in the ~/sdfs or ~/persistent_dir directories will not be
retained through upgrade. If you need these resources, manually back them up by copying them to an
external location.
The contents of the secret store are retained while you update the SIMPL VM. However, we
recommend taking a backup of the secret store by following Taking a backup of the secret store in
the SIMPL VM Product Deployment and Management Guide. This will allow you to restore the secret
store to its pre-update state in the rare case of a failure.
Note:
• Unpacked CSARs (including the output of CSAR commands), and copies of SDFs that have been
used via csar tooling will be transferred to the new VM during the update.
• Any resources that are stored in the ~/sdfs or ~/persistent_dir directories (including those
referenced by file path in the SDF (e.g. DCM tokens)) are retained when you update the SIMPL
VM.
Gather diagnostics from old VM
SSH into the SIMPL VM, run csar gather-diags, wait for the process to complete, then retrieve
the diagnostics package from the SIMPL VM before you begin. See Troubleshooting the SIMPL VM
on page 45.
Upgrade or recover the SIMPL VM (OpenStack)

1. SSH into the SIMPL VM and run csar list. Confirm that this command completes successfully
and outputs the expected list of CSARs. Take a copy of this list to compare with during verification
of this procedure.
Run csar secrets status. Confirm that this command completes successfully and outputs
the expected list of secrets. Take a copy of this list to compare with during verification of this
procedure.

2. Stop the SIMPL VM, specifying its name:
openstack server stop InstanceName
3. Delete the SIMPL VM instance stack. Do not delete the volume stack:
Confirm the deletion when prompted.

4. Create a new SIMPL VM instance stack. This will use the existing csar_volume_id specified in
the simpl_instance.env file, so the new instance will attach to the existing volume. If you want
to use a different InstanceStackName to the previous SIMPL VM instance, you can do so:
openstack stack create -t simpl_instance_template.yaml -e

simpl_instance.env
InstanceStackName
Verification
1. Wait a few minutes to allow the stack creation to complete.
2. On the OpenStack client server, check the stack creation was successful:
Check that:
• The stack_status is CREATE_COMPLETE

• The stack_status_reason is Stack CREATE completed successfully.
Note:
The setup process may still be running after OpenStack reports Stack CREATE completed
successfully. If any further verification steps fail, try waiting another 5-10 minutes before
repeating the verification step.
If errors persist for any verification steps, refer to Backout on page 41.
Confirm the command prompt is available.

4. Run simpl-setup-complete and confirm that the new SIMPL VM has completed its setup
process.
5. Run csar list and confirm that the all CSARs stored on the previous SIMPL VM are listed.
6. Run csar secrets status and confirm that all the secrets stored on the previous SIMPL VM
are listed. The secret store may take a few minutes to start up after upgrade; if the command does
not succeed on the first attempt, wait five minutes and retry.
Troubleshooting
See Managing deployment secrets in the SIMPL VM Product Deployment and Management Guide
for instructions on restoring a backup of the secret store or adding secrets using the CSAR CLI if any
secrets are missing after upgrading or restoring your SIMPL VM.

Note:
Restoring secret store backups from SIMPL VM pre-V6.9.0 on post-V6.9.0 versions of SIMPL VM
is not supported using csar secrets restore. Contact your support representative to restore
the secrets.
Post-verification steps
Restore backup copies of files
1. If you want to reuse any saved SDFs, copy them from ~/.local/share/csar/latest_sdfs/
to your working directory.
Note:
A copy of your SDF is saved off to the SIMPL VM's external disk every time you run csar
deploy, csar update, csar heal, or csar import.
To retrieve an SDF, run cdcsars to go to your CSAR home directory, then run cd
archived_sdfs. SDFs are saved off under the directory matching the date when one of the
SDF-saving CSAR commands was run. The filename is appended with the time when the SDF-
saving command was run, represented as an integer.
2. If you manually backed up resources that are referenced in the SDF by file path, copy these files
into the same directory as your restored SDFs.
3. Restore any further files that you manually backed up.
The following are preserved over SIMPL VM updates and do not need to be restored (except in the
rare case of a failure):
• Unpacked CSARs (including the output of CSAR commands)

• The secret store.
Attention:
Restoring secret store backups from SIMPL VM pre-V6.9.0 on post-V6.9.0 versions of SIMPL VM
is not supported using csar secrets restore. Backups taken on a V6.8 SIMPL VM before
upgrading to V6.9.0+ must only be used to restore the secret store after backing out the upgrade.
If you need to restore a pre-V6.9.0 backup file on a post-V6.9.0 SIMPL VM, contact your support
representative.
Re-register your VPN
Create a VPN connection with the Metaswitch VPN servers:
1. Create an SSH connection to the new SIMPL VM as the admin user and run sdc to enter the Craft
menu.
2. Register and start the VPN using the Craft menu commands.

3. Inform your Metaswitch support representative that this has been done so that the far end of the
VPN can be configured.
Update your CSARs and SDF where necessary
• Transfer your SDF to the new SIMPL VM (you can find it in the diags package if you did not take a
copy).
• If you have upgraded, run simpl-version to see if your CSARs are still compatible with the
uplevel SIMPL VM. For any that are not, use csar remove to remove the old CSARs and follow
Downloading CSARs in the SIMPL VM Product Deployment and Management Guide again to
download new versions.
• If you have upgraded SIMPL VM or updated your CSARs, you may need to update your SDF to
match the YAML schema for the new versions. Check the SIMPL VM release note for your target
release or ask your support representative if this is required. If it is, follow Upgrading an SDF in the
SIMPL VM Product Deployment and Management Guide.
Set SSH timeout
The SSH connection timeout is not preserved over upgrade and will be reset to the default of 5
minutes. If you want to change it, follow the instructions at Change SSH timeout according to security
policy on page 31.
Backout
If you encountered any errors, you must backout the procedure by deleting the new VM and re-
deploying the old VM.
1. Power off the new instance: openstack server stop InstanceName

2. Delete the new stack: openstack stack delete InstanceStackName
3. Recreate the old stack, using the old Heat template and environment file gathered at the
beginning of this procedure:
openstack stack create -t old_simpl_instance_template.yaml -e
old_simpl_instance.env --parameter
csar_volume_id=VolumeID InstanceStackName
4. Verify the health of the SIMPL VM (per Verification on page 39).
• If csar secrets status is not listing the expected secrets, restore the secrets backup file
taken at the beginning of the upgrade process. For instructions, see Restoring a backup of the
secret store in the SIMPL VM Product Deployment and Management Guide.
• Run csar secrets status again and confirm that all the secrets stored on the previous
SIMPL VM are listed.
5. Restore backed up copies of files (see Restore backup copies of files on page 40).
Results
You have upgraded, recovered or updated configuration on the SIMPL VM.

4.2 Using the screen command for long running actions

screen is a standard Linux utility that can be used to run processes in the background and bring
them back to the foreground.
For security, the SIMPL VM has an SSH timeout of 5 minutes. It automatically uses the screen utility
to ensure any csar or solution-bundle command is not terminated (by keeping it running in the
background) if your connection expires or goes down for any other reason.
Reattaching to an existing screen session

If your connection to the SIMPL VM is lost, whether intentionally or not, while running a csar or
solution-bundle command, you can reattach to the session to continue monitoring the output of
the command as follows:
2. The names of any disconnected sessions will be automatically listed on login. Each session name
consists of the command and subcommand being run in that session, together with a timestamp
of when the command was executed. For convenience, the full command (with all the parameters
specified) is also provided. For example:
Disconnected sessions:
- csar-deploy-2021-09-28-16-07-56 (command: csar deploy --sdf sdf-
sas.yaml)
- csar-deploy-2021-09-28-16-07-27 (command: csar deploy --sdf sdf-
eas.yaml)
3. To reconnect to a session, run screen -r Session Name

4. The screen session will automatically terminate once the command being run completes, unless
you reconnected after it completed, in which case type exit to terminate it. You can then continue
to use the CLI as normal.
Scrolling in a reattached screen session

Once reconnected to a screen session, you may need to scroll to view older output logged to the
terminal by the SIMPL VM. You can do this as follows:
• Press ctrl+a. Release the keys.

• Press Escape.
• Use the arrow keys to navigate up and down.
• When finished, press q or Escape to navigate back to the most recently logged text.
4.3 Destroying the SIMPL VM
About this task

This task destroys a SIMPL VM and all data associated with it.

Attention:
You cannot revert this operation: if you destroy the VM in error, you will need to recreate it (see
Deploying SIMPL (OpenStack) on page 19).
Attention:
Do not delete the SIMPL VM once you have started creating and managing deployments with it, as
it stores important running state which must not be lost
Destroy a SIMPL VM (OpenStack)

1. On your OpenStack client server, destroy the instance stack:
3. Repeat the above steps for the volume stack.
Results
You have destroyed the specified SIMPL VM.

5 Managing multiple sites

SIMPL VM can manage VNFs in multiple sites in two ways:
• You can include multiple sites in the SDF and manage your deployment from a single SIMPL VM
(with optional backup SIMPL VMs for disaster recovery). Deploy, update and import commands
can be run on a particular site by specifying a sites parameter (see the documentation of each
individual command for details. A csar command reference can be found in CSAR commands on
page 47).
• Alternatively, you can choose to use an SDF per-site. A SIMPL VM can only use one SDF; this
method requires you to deploy a SIMPL VM in each site. Deploy, update and import commands
can then be run against a single site by running the csar command on the SIMPL VM in that site.
Your customer support representative can help you split your deployment wide SDF into multiple
site-specific SDFs.
Some solutions, such as clustered CFS, use SIMPL to manage deployment-wide operations. In these
solutions the SDF must contain all sites in the deployment. Please see your solution documentation
or ask your customer support representative to help you decide if your solution requires a single,
deployment-wide SDF.
Multiple SIMPL VMs for site-wide disaster recovery

You can optionally deploy backup SIMPL VMs in one or more sites to support disaster recovery.
If you have a deployment spanning multiple sites then you may have up to one SIMPL VM in each
site. One of these SIMPL VMs must be designated as the primary; the others will all be backups. In
normal usage all the commands must be run on the primary SIMPL VM, and the backups must not be
used.
Attention:
You must backup the SDF from the primary SIMPL VM to another secure location.
In the case of a site-wide disaster where the primary SIMPL VM is not recoverable, one of the
backups may be promoted to primary. (If the SIMPL VM is recoverable, you should instead follow
Managing the SIMPL VM on page 35 to recover it.) To do this:
1. Copy the up-to-date SDF (which must have been stored securely off the primary SIMPL VM) on to
the new primary SIMPL VM.
2. Download any missing CSARs required: Downloading CSARs in the SIMPL VM Product
Deployment and Management Guide.
You may then continue to use the new primary SIMPL VM as normal. If the old primary SIMPL VM is
then recovered it becomes a backup and must not be used for running commands.
44 5 Managing multiple sites

6 Troubleshooting the SIMPL VM
Gather diagnostics
If you need to raise a ticket with your support representative, you can gather diagnostics from the
SIMPL VM by performing the following steps:
2. Run csar gather-diags to gather all relevant files and diagnostics into one package.
3. Once complete, the command will output the path to the generated package in the /var/
diags-package-manager/package/ directory. Retrieve this file and send it to your support
representative.
Failures during CSAR operations

If you experience failures while running csar deploy, csar update or csar validate:
• determine the identity of the VNFC that's not behaving as expected - which should be clear from
the output to screen and applicable logs,
• investigate that instance, to better understand the cause of the failure; this may require application-
specific troubleshooting advice, but checking that the VM exists with the right software image, and
has management IP connectivity, is likely a good starting point,
• once understood and resolved, re-run the operation, or follow the relevant Backout section if the
problem is unclear and demands further investigation.
A list of common errors is included below for further information.
Deploying or redeploying a subset of VMs

You can deploy or redeploy individual VMs by name (see Redeploying individual VMs in Deploying
a VNF from a CSAR in the SIMPL VM Product Deployment and Management Guide). You can also
deploy or redeploy larger subsets of VMs. It is not possible to destroy a subset of VMs within a service
group.
Attention:
Please heed any warnings shown when running the commands in this section. If in any doubt, the
cleanest way to fix up a faulty new deployment is to follow Redeploying or deleting all VMs in a
VNF in Deploying a VNF from a CSAR in the SIMPL VM Product Deployment and Management
Guide.
6 Troubleshooting the SIMPL VM 45

Identify the VNF from the CSAR name. Identify the site, service group and index of the VMs to be
redeployed or deployed by finding the VNF in your SDF. These are referred to as VNF, SiteName,
ServiceGroupName and IndexRange in the instructions below.
The VM will be listed under the site and service group it is a part of, and will be referenced by name:
sites:
- name: my-site-name
vnfcs:
- type: my-vnfc
name: my-vnfc-group
cluster-configuration:
count: 2
instances:
- name: my-vm-name
- name: my-other-vm-name
In the above example, the site is my-site-name and the service group is mv-vnfc-group. The
index of the VM will be determined by which element of the instances list it is, with indexes starting
at 0. my-vm-name will have index 0 and my-other-vm-name will have index 1.
Note:
If your service group does not have an instances section, the index of your VM will be included in
the name of your VM. In this case, VM names will be made up of the service group name with the
index appended, for example my-vnfc-group-0.
Commands that you can run are:
• csar deploy --sdf PathToSDF --vnf VNF --sites SiteName --service-group

ServiceGroup --index-range IndexRange to retry deploying a range of instances that
failed to deploy. The IndexRange parameter must be a comma delimited list. Indexes start from
0.
• The same command with csar redeploy instead of csar deploy to destroy and deploy
multiple instances that succeeded. Note that an alternative to doing this is csar heal --sdf
PathToSDF --vm VMName which also runs healthchecks on healed VMs. However, not all
CSARs support healing their VMs. If healing is not supported, the csar heal command will return
an error explaining this, and will not do anything. See Healing a VM in the SIMPL VM Product
Deployment and Management Guide.
46 6 Troubleshooting the SIMPL VM

7 Appendix: Command reference
7.1 CSAR commands
Attention:
Note that some csar commands should be run by Commissioning Engineers only - and are not
documented below. Please do not run these commands without discussing with your Metaswitch
Customer Care contact.
Most of these commands have various options for acting on multiple CSARs / VNFs. This does not
contain every combination of arguments. However, the command help provides additional details for
each command.
Get command help:

csar --help
Get help for a specific command:
csar command --help
Get a CSAR onto the SIMPL VM from an HTTP server (e.g. Artifactory), and unpack it:
csar get CSARLocationAddress
Check CSAR and solution-bundle compatibility:
csar compatibility
Unpack a CSAR that you have put on the SIMPL VM in some other way. This command can be used
with a list of CSARs and/or wildcard statements:
csar unpack PathToCSAR1 PathToCSAR2 PathToCSARDir/*.zip
List installed/unpacked CSARs:
csar list
Generate an SDF help file:
csar sdf-help
Create DNS entries from templates in the product CSARs and solution bundle:
csar create-dns-entries --vnf VNF --solution Solution> --domain Domain> --
dns-ip DNS_IP --sdf PathToSDF
Note:
Here VNF is e.g. cfs, obs, etc.
Test a deploy command without creating any VMs. This allows you to check that the command you
enter will have the intended effect. It proceeds to:
• Validate the SDF
7 Appendix: Command reference 47

• Check that the user defined in the SDF has all the required VIM privileges
• Check that there is connectivity to the VIM hosts for image upload
• Print out which VMs would have been deployed.
You can check this output to verify whether the desired VMs would have been deployed:
csar deploy --dry-run --vnf VNF [--sites SiteName ...] --sdf PathToSDF
Deploy a CSAR (creates the VMs):
csar deploy --vnf VNF [--sites SiteName ...] --sdf PathToSDF
Destroy a VNF that has been deployed (or clean up after failed deploy):
csar delete --vnf VNF --sdf PathToSDF
Redeploy a CSAR (normally if it failed the first time - uses the same VNF descriptor):
csar redeploy --vnf VNF --sdf PathToSDF
Run the day one Ansible scripts for a VNF:
csar run-day-one --vnf VNF --sdf PathToSDF
Run the validation tests for a VNF:
csar validate --vnf VNF [--vnf VNF]] --sdf PathToSDF
Delete vSphere or vCloud templates or OpenStack images:
csar delete-images --sdf PathToSDF
Output ne_details.txt files with access information for each VNF:
csar create-ne-details --sdf PathToSDF
Remove one or more installed/unpacked CSARs:
csar remove VNF
Test that an update command will act on the intended target. This will not execute the update.
Instead, it will report the VNFs and VNFCs that would have been updated if had --dry-run not been
supplied. To trigger the full update workflow, rerun the csar update command without --dry-run.
csar update --dry-run --vnf VNF --sdf PathToSDF [--sites Site1
--sites Site2 ... [--service-group ServiceGroupName [--index-
range IndexRange]]]
Update or upgrade a deployed VNF:
csar update --vnf VNF --sdf PathToSDF [--sites Site1 --sites Site2 ... [--
service-group ServiceGroupName [--index-range IndexRange]]]
Test that a heal command will act on the intended target. This will not execute the heal. Instead, it will
report the VM that would have been healed if --dry-run not been supplied. To trigger the full heal
workflow, rerun the csar heal command without --dry-run.
csar heal --sdf PathToSDF --dry-run --vm VMName
Heal a single instance of a deployed VNF:
csar heal --sdf PathToSDF --vm VMName
Gather a diagnostics package:
csar gather-diags
48 7 Appendix: Command reference

Generate a template file containing secret identifiers required for a set of VNFs, sites, and/or service
groups in the SDF. The template file has placeholder fields for the secret values. The secret values
need to be entered into the template file before the secrets can be added to the secret store.
csar secrets create-input-file --sdf PathToSDF --vnf VNF[ --sites Site1 --
sites Site2 ... [--service-group ServiceGroupName]]
Add secrets to the secret store:
csar secrets add PathToInputFile
Delete secrets from the secret store:
csar secrets delete secret_id1 secret_id2
Create a backup of the secret store:
csar secrets backup
Restore a backup of the secret store:
csar secrets restore PathToBackup PathToDecryptionKey
List all the secret identifiers in the secret store:
csar secrets status
Check whether all secrets needed for an SDF are in the secret store:
csar secrets status --sdf PathToSDF [--vnf VNF --sites Site1 --service-
group Sg1]
Check whether a specific secret is in the secret store:
csar secrets status --secret-id SecretId
Check connectivity to the secret store:
csar secrets check-backend-connectivity
Show the status of all VMs in your deployment:

csar status --sdf PathToSDF [--sites SiteName --vnf VNF --service-
group ServiceGroupName]
7.2 Solution-bundle commands

Most of these commands have various options for acting on multiple solution-bundles or VNFs. This
does not contain every combination of arguments. However, the command help provides additional
details for each command.
Get command help:

solution-bundle --help
Get specific command help:
solution-bundle Command --help e.g. solution-bundle run-configuration --
help
Check CSAR and solution-bundle compatibility (does the same as csar compatibility):
7 Appendix: Command reference 49

solution-bundle compatibility
Unpack a solution-bundle that you have put on the SIMPL VM in some other way. This command can
be used with a list of solution-bundles and/or wildcard statements:
solution-bundle unpack PathToSolutionBundle PathToSolutionBundleDir/*.zip
List installed solution-bundles:
solution-bundle list
Run the solution-specific day one ansible scripts for a VNF:
solution-bundle run-configuration --solution Solution --vnf VNF --
sdf PathToSDF
Run the solution-specific validation tests for a VNF:
solution-bundle run-validation --solution Solution --vnf VNF --
sdf PathToSDF
Remove one or more solution-bundles for a solution:
solution-bundle remove Solution
7.3 Other commands

Change to the CSARs directory:
cdcsars
Change to the solution-bundles directory:
cdbundles
Change to the logs directory:
cdtrc
Display the SIMPL VM version:
simpl-version
Check whether the SIMPL VM has finished setting up on first install:
simpl-setup-complete
Run the VPN Craft menu on the SIMPL VM:
sdc
50 7 Appendix: Command reference

SIMPLVM DeploymentGuide OpenStack

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SIMPLVM DeploymentGuide OpenStack

Uploaded by

Copyright:

Available Formats

CONFIDENTIAL

SIMPL-001_OpenStack - Version 6.11.0 - Issue 1-1451

1 Introduction to the SIMPL VM.............................................................................. 4

1 Introduction to the SIMPL VM

Metaswitch's ServiceIQ Management Platform VM (SIMPL VM) is a VM that simplifies the

What is the SIMPL VM?

Figure 1: SIMPL VM overview

• VPN access (if permitted) for base commissioning and validation.

4 1 Introduction to the SIMPL VM

SIMPL relies on two key artifacts:

Deployment via the SIMPL VM

• all syntax is correct

1 Introduction to the SIMPL VM 5

Updates and upgrades via the SIMPL VM

• This is called the rolling upgrade model.

• This is called the in-place upgrade model

Other lifecycle operations

6 1 Introduction to the SIMPL VM

VNF Virtualized Network Function. A network function running in the

VNFC VNF Component. A logical subset of a VNF, performing a distinct

VNFCI VNF Component Instance. A specific VM of a given VNFC.

VNFD VNF Descriptor. Information about how to instantiate a VNF - for

CSAR Cloud Service Archive. A zipfile containing product images and

1 Introduction to the SIMPL VM 7

Service configuration Configuration consumed by an virtualized application (sometimes

Upgrade Either upgrading your SIMPL VM to a new version of software, or

8 1 Introduction to the SIMPL VM

2 Planning your SIMPL VM deployment

Before deploying the SIMPL VM, see:

2 Planning your SIMPL VM deployment 9

Table 1: Hardware requirements for a single SIMPL VM

VM vCPUs RAM Boot Boot Volume Volume NICs

ServiceIQ Management 2 8192 20 50 minimum 50 1

2.2 Firewall configuration and connectivity

Table 2: Firewall Permissions and Connectivity

Port Transport Security Destination Direction Purpose

22 TCP Public/ Metaswitch VPN ingress/ Metaswitch VPN

22 TCP Public/ Metaswitch VMs IP (2) ingress/ Configuring VMs after

443 TCP TLS dl.metaswitch.com (3) ingress/ Optional to download

514 UDP - Remote syslog server egress Optional to allow remote

80 TCP HTTPS SAS VMs in egress HTTP traffic out to SAS

10 2 Planning your SIMPL VM deployment

Port Transport Security Destination Direction Purpose

9100 TCP HTTP SIMon VMs in ingress Allow SIMon to scrape

9200 TCP HTTP SIMon VMs in egress Allow SIMPL VM to send

You will also require the following OpenStack-specific connectivity:

Table 3: Additional Firewall Permissions and Connectivity for OpenStack

Port Transport Security Destination Direction Purpose

67 UDP - 255.255.255.255 egress DHCP broadcast requests

67 UDP - Openstack ingress DHCP responses

8774 TCP - OpenStack compute egress Provisioning of OpenStack

13774 TCP TLS OpenStack compute egress Provisioning of OpenStack

8776 TCP - OpenStack block egress Provisioning of OpenStack

13776 TCP TLS OpenStack block egress Provisioning of OpenStack

5000 TCP - OpenStack identity egress Authentication with

2 Planning your SIMPL VM deployment 11

Port Transport Security Destination Direction Purpose

13000 TCP TLS OpenStack identity egress Authentication with

9292 TCP - OpenStack image egress OpenStack compute image

13292 TCP SSL OpenStack image egress OpenStack compute image

9696 TCP - OpenStack egress Provisioning of OpenStack

13696 TCP TLS OpenStack egress Provisioning of OpenStack

8004 TCP - OpenStack egress OpenStack API for