Frequently Asked Questions

General

What is OSM?

Open Source MANO (OSM) is an ETSI-hosted open source community delivering a production-quality MANO stack for NFV. It is capable of consuming openly published information models, available to everyone, suitable for all VNFs, operationally significant, and VIM-independent. OSM is aligned to NFV ISG information models while providing first-hand feedback based on its implementation experience.

What features make ETSI OSM unique compared to other orchestration tools?

OSM provides a unified, multi-layer multi-cloud orchestration platform. Unlike general-purpose tools, it seamlessly integrates the management of cloud infrastructure, virtualised resources, and containerised applications (Cloud-Native) across multi-vendor environments. Key unique features include:

  • Application Modelling — A standardised way to simplify onboarding and reuse of Kubernetes blueprints (OKA).

  • Profiles — A feature allowing the “single-click” deployment of identical services across hundreds of diverse clusters.

  • Declarative GitOps Engine — A “desired state” model where the system automatically reconciles the current state with the configuration stored in Git.

What does OSM provide in addition to Kubernetes? Why can’t we do this with Kubernetes alone?

Kubernetes is an orchestrator for containers, but a Telco service (like a 5G Core) often spans across multiple clusters, legacy virtual machines, and physical network functions:

  • Multi-Cluster Management — While Kubernetes manages one cluster, OSM can manage the lifecycle of services across many clusters simultaneously.

  • Multi-Cloud Abstraction — Kubernetes clusters are created differently on each cloud infrastructure (OpenStack, AWS, Azure). OSM abstracts this complexity so operators can manage clusters without worrying about cloud-specific mechanics.

  • Application Modelling — OSM provides a way to model complex applications, their dependencies, and their synchronisation layers (e.g., guaranteeing cluster add-ons are deployed before applications).

  • North-Bound Interface — OSM provides a single REST-based API entry point that integrates multi-cloud, multi-cluster, multi-site capabilities with external tools.

What does OSM provide in addition to Helm Charts? Why can’t we do this with Helm Charts alone?

Helm is a package manager for Kubernetes applications, but it lacks the “State Awareness” and “Global View” required for Telco operations:

  • Automatic Reconciliation — While Helm installs a package, OSM’s declarative engine continuously monitors the state. If configuration drifts, OSM automatically reconciles it to the desired state defined in Git.

  • Dynamic Relocation — OSM supports the dynamic relocation of Kubernetes Deployment Units (KDUs) within clusters based on demand (e.g., moving a CDN closer to the edge).

  • Cross-Domain Orchestration — A Helm chart cannot configure a physical firewall or a private cloud’s networking. OSM coordinates the Helm deployment in tandem with the broader network environment.

What is an LTS release? How often does OSM release?

OSM follows a cadence of two releases per year:

  • Long-Term Support (LTS) releases receive 2 years of bug fixes and security patches (e.g., Release EIGHTEEN, Release SIXTEEN).

  • Standard releases receive 6 months of support.

When in doubt, use the latest LTS release for production deployments.

Operators and Industry

What specific benefits does OSM provide to an operator?

OSM delivers three primary value pillars:

  • Reduced Operational Silos — It replaces multiple fragmented tools with a single workflow (e.g., from cluster creation to 5G core deployment).

  • Accelerated Time-to-Market — By using reusable Kubernetes Resource Modelling (KRM), processes that used to take months can now be completed in weeks.

  • Agility and Resilience — Integrated GitOps allows for version-controlled changes and easy rollbacks, reducing the risk of manual configuration errors.

How does OSM ensure the resilience and problem-solving capabilities required for production?

  • Resilience via GitOps — By treating the network as code, operators gain a built-in safety net. If an upgrade fails, the system can revert to a known stable state via a simple Git commit.

  • Security & Compliance — OSM includes enhanced password encryption (even in GitOps mode) and comprehensive audit logs, allowing operators to mitigate risks and meet regulatory requirements.

  • Scalability for Multi-Site — The “Profiles” feature ensures consistency across large-scale rollouts (e.g., nationwide 5G), eliminating the manual configuration drift that often causes outages in large-scale industrial deployments.

Research

How can OSM be used to advance experimental studies?

For researchers, OSM serves as a highly flexible, standards-based laboratory for Cloud-Native and Edge Computing research:

  • KRM Blueprints — Researchers can use Kubernetes Resource Modelling to experiment with new network architectures.

  • Edge Innovation — The ability to shift workloads dynamically (KDU relocation) provides a foundation for researching low-latency applications and AI-driven traffic steering.

  • Multi-Cloud Interoperability — It provides a consistent environment to test how 5G components behave across different public and private cloud providers without changing the underlying code.

Installation

What are the hardware requirements for OSM?

The recommended minimum for a standalone OSM installation is:

  • 4 CPUs, 16 GB RAM, 80 GB disk

  • A single network interface with Internet access

  • Base image: Ubuntu 24.04 LTS

How do I install OSM?

wget https://osm-download.etsi.org/ftp/osm-19.0-nineteen/install_osm.sh
chmod +x install_osm.sh
./install_osm.sh 2>&1 | tee osm_install_log.txt

This installs a standalone Kubernetes on a single host and OSM on top of it. For detailed options, see Installing OSM.

How do I check the status of my OSM installation?

kubectl get all -n osm
kubectl get ingress -n osm

Access the UI at http://<YOUR_IP>.nip.io (user: admin, password: admin). You can find the ingress endpoint with:

export OSM_GUI_URL=$(kubectl get -n osm -o jsonpath="{.spec.rules[0].host}" ingress ngui-ingress)
echo "OSM UI: $OSM_GUI_URL"

How do I check the logs of an OSM component?

kubectl logs -n osm deployments/lcm      # LCM
kubectl logs -n osm deployments/nbi      # NBI
kubectl logs -n osm deployments/ro       # RO
kubectl logs -n osm deployments/ng-ui    # NG-UI

How do I configure the OSM client?

export OSM_HOSTNAME=$(kubectl get -n osm -o jsonpath="{.spec.rules[0].host}" ingress nbi-ingress)
osm --help

VIM and Cloud

Which VIM types does OSM support?

OSM supports:

  • OpenStack — The primary open-source cloud platform

  • Microsoft Azure — Public cloud (also for managed Kubernetes clusters)

  • Amazon Web Services (AWS) — Public cloud

  • Google Cloud Platform (GCP) — Public cloud

  • VMware vCloud Director — Commercial VIM

  • OpenVIM — Reference VIM included with OSM for testing

How do I add a VIM account?

osm vim-create --name openstack-site --user admin --password userpwd \
    --auth_url http://10.10.10.11:5000/v2.0 --tenant admin --account_type openstack

For specific VIM configurations, see Managing VIM Accounts.

Network Services

What is the difference between Day-0, Day-1, and Day-2 operations?

  • Day-0 — Initial deployment: creating virtual machines, virtual links, and configuring the underlying infrastructure.

  • Day-1 — Initial configuration: running configuration scripts or Juju charms on the deployed VNFs to bring them to a working state.

  • Day-2 — Ongoing operations: scaling, healing, upgrading, and monitoring the Network Service during its active lifetime.

How does auto-scaling work in OSM?

OSM supports KPI-based scaling using Prometheus metrics. You define scaling descriptors in your VNF/NS packages that specify scaling groups, triggers (metric thresholds), and cooldown periods. When a threshold is exceeded, OSM automatically scales the affected VDU. See Scaling Network Services.

How does auto-healing work in OSM?

OSM monitors the status of deployed VMs. When a VDU goes down and remains down for a configurable period, Prometheus fires an alert that triggers an Airflow workflow. This workflow checks the auto-healing rules in MongoDB and publishes a heal operation to LCM, which performs the healing action (e.g., REDEPLOY_ONLY). See Healing Network Services.

Kubernetes and Declarative Framework

What is the declarative framework in OSM?

The declarative framework (introduced in Release SIXTEEN) allows OSM to manage Kubernetes clusters, applications, and their configurations following a GitOps model. All operations are committed to Git repositories; FluxCD continuously synchronises the actual cluster state with the desired state in Git. See Core Concepts.

What is an OKA?

An OKA (OSM Kubernetes Application) is a reusable blueprint for a Kubernetes application. It packages base manifests (or Helm charts) together with Flux Kustomization overlays. OKAs are instantiated as KSUs when deployed to a cluster.

What is a KSU?

A KSU (Kubernetes Software Unit) is the minimal unit of desired state committed to the fleet-osm Git repository for a specific cluster. A KSU is created by instantiating an OKA with specific parameters and committing the resulting manifests.

What is a Profile?

A Profile groups a set of KSUs to be deployed uniformly to a fleet of Kubernetes clusters. It is the mechanism for “single-click” deployment of identical software stacks across many clusters.

How do I create a Kubernetes cluster with OSM?

osm cluster-create --name my-cluster --vim azure-site \
    --k8s_version 1.28 --node_count 3

See Advanced Cluster Management for full details.

Troubleshooting

How do I check the version of my OSM installation?

See Troubleshooting.

Where can I get help with OSM?