| 1 | Introduction |
| 1.1 | Prerequisites |
2 | Scenario for Recovery |
3 | Recovery Procedure |
4 | Problem Reporting |
| 4.1 | Problem Solved |
| 4.2 | Consult Next Level of Support |
1 Introduction
This document describes the emergency recovery procedure to be performed on the Virtualized Network Function (VNF).
Typically, an emergency recovery procedure is required for conditions where it is required to restore the VNF. Emergency in this document refers to the situation described in Section 2 Scenario for Recovery.
Since this document is a recovery instruction, the system is assumed to have been in a fully working state before the problems started. Therefore no troubleshooting steps that are related to faulty configuration or incorrect software version or hardware version, or both, are explained.
1.1 Prerequisites
This section states the prerequisites for performing the emergency recovery procedure.
1.1.1 Hardware and Software Required
The following hardware and software is required:
- A working Ericsson Cloud Solution environment (or equivalent)
- A working OpenStack environment (or equivalent)
- An Open Virtualization Format (OVF) file with a corresponding Heat Orchestration Template (HOT) to implement the VNF
- A recent backup of the VNF, if available
1.1.2 Documents
This instruction references the following documents:
1.1.3 Conditions
Before starting this procedure, ensure that the following condition is met:
- The underlying hardware and environment, for example, Ericsson Cloud Solution, and an OpenStack or equivalent environment, have already been restored.
2 Scenario for Recovery
It is assumed that the VNF must be reinstalled for some reason, for example, as a result of a failure in the underlying Cloud infrastructure. This, in turn, could be because of a major hardware failure, an extensive power loss, flood, or fire.
3 Recovery Procedure
To restore the VNF:
- Deploy the VNF, refer to Deployment Guide.
- Restore the latest known working backup, if possible; refer to Restore Backup and View Progress Report.
- Restore the VNF to its original size, refer to Configure Scale-Out.
- Is the problem solved?
Yes: Proceed with Section 4.1 Problem Solved.
No: proceed with Section 4.2 Consult Next Level of Support.
4 Problem Reporting
All recovery situations must be seen as abnormal, and must be reported to the next level of support or according to other documented procedure. This applies even if the recovery has been successful. Often a Customer Service Request (CSR) is written to a responsible support organization.
If the situation has affected the In-Service Performance (ISP), it must be reported as such according to documented procedure.
It is often required to perform a Root Cause Analysis (RCA) later to determine the source of the problem. It is therefore important to document the problematic situation and all the recovery steps that have been taken. Several log files in the system must be saved or copied to prevent them from being overwritten with newer information. It is important that these logs are available for any future RCA.
4.1 Problem Solved
Keep the site and the affected functions under extra observation for a while to ensure that the fault does not reoccur. Record the incident according to local procedures using a log book or similar.
4.2 Consult Next Level of Support
Provide the receiving support organization with the following information:
- Site name
- Location
- Operator
- Contact information
- VNF node name, version loaded, including any upgrade packages and correction packages
- VNF configuration, for example, the HOT template
- Problem description
- Procedures followed, including document number
- Information about activities done before, during, and after the incident
- Logs
For information on how to collect data and log files, refer to Data Collection Guideline.

Contents