OpenNebula User Guide
Elaborado por: aDi
Versión: 2.0 — 27/02/2026
| DOCUMENT CONTROL | ||||||||||
| Title | OpenNebula User Guide | |||||||||
| Document code | ||||||||||
| Classification | Public use | |||||||||
| Version | 2.0 | |||||||||
| Elaborated by | aDi | |||||||||
| REVISION HISTORY | ||||||||||
|
||||||||||
Contenido
- Service Overview
- Request & Provisioning Process
- Customer Access and Initial OpenNebula Environment Setup.
- Initial Access to the aDi Cloud Portal
- SSH Access to the OpenNebula frontend
- Initial Access to the OpenNebula Sunstone web interface
- Multi-Tenant Management: user roles, group/VDC, quotas, access policies.
- Network, VM & Storage Operations
- Monitoring & Support: How to monitor
1. Service Overview
OpenNebula is an open-source software tool for deploying and operating cloud and edge environments. OpenNebula offers elasticity, automatic provisioning and multi-user capabilities on distributed infrastructures, enabling the deployment of private, hybrid and edge environments that combine resources from proprietary data centres or public cloud providers.
The OpenNebula instance offered by aDi enables organisations to enjoy the benefits of a modern private cloud—flexible, secure, and high-performance—while delegating the management of the physical infrastructure, focusing their efforts on the administration and optimisation of their virtual environment.
Based on OpenNebula technology, each customer has an exclusive *OpenNebula instance ensuring operational independence and full autonomy in the management of virtual resources.
The platform is supported by high-performance bare-metal servers, suitable for any type of environment, laboratories, production, with high-performance local storage providing an optimal balance between performance, scalability and resilience.
What you can expect once this service is implemented?:
- Elasticity and control: rapid deployment of virtual machines and services, adaptable to the needs of each organisation.
- Advanced virtual networks: creation and management of private or public topologies, with support for traffic segmentation and isolation.
- Flexible and secure storage: high-performance local datastores.
- Multi-tenant governance: Although your OpenNebula instance is already exclusive, the platform supports the creation of Virtual Data Centres (VDCs) to divide allocated resources into independent environments, useful for separating projects, departments or development phases.
- Integrated monitoring: continuous visibility into resource usage, performance metrics, and configurable alerts.
*The OpenNebula instance is fully administered, configured, and maintained by the customer. aDi is responsible only for the underlying infrastructure, including the VM, bare-metal server, network, and storage. Internal configuration of the OpenNebula environment, as well as backups of the database and virtual machine disks, remain the responsibility of the customer.
1.1 Hardware Specification and Architecture
The detailed hardware specifications of the high performance level setup are:
| COMPONENT | SPECIFICATIONS |
|---|---|
| CPU | 1 x AMD Genoa 9654 (2.4GHz / 96 Cores / 384MB / 360W) CPU Module (CTO&BTO) |
| RAM | 256 GB DDR5 — 64GB 2Rx4 DDR5-5600B (CAS-46-45-45) SAMSUNG & HYNIX RDIMM Memory Module(CTO&BTO) |
| STORAGE |
2 X 480GB 6Gb/s SATA 3.5in RI SSD UCC Generic Module (CMCTO) RAID-1 Operating System 10 X 3.84TB 6Gb/s SATA 3.5in RI SSD UCC Generic Module (CMCTO) (*up to 30 TB — RAID-5 storage capacity) |
| NETWORK | 1 x 2-Port 25Gb/s PCIe3.0 X8 SFP28 Fiber Interface ETH640F OCP3.0 Ethernet Adapter (Mellanox CX4-LX)(CTO&BTO) |
The deployment of an OpenNebula instance consists of 2 machines;
Frontend (Virtual Machine)
The Front-end server (VM) executes and interacts with components such as daemons, services and interfaces to provide deployment, management, orchestration and monitoring of infrastructure resources. It persists the state of the cloud on a designated SQL database.
It provides the layers of interaction with end-users and administrators through;
- Sunstone web interface
- API CLI, services such as OneFlow (orchestration) and OneGate (communications from VMs)
Backend (Dedicated Bare-Metal Server)
The backend server (bare-metal) is responsible for the provisioning of resources and virtual machines. This server is the hypervisor node (KVM) where the VMs defined by the users from the frontend are instantiated.
It is connected to the frontend via a private internal network and both share access to local storage.
2. Request & Provisioning Process
The process of requesting and provisioning an OpenNebula instance is very simple. What do you need to do?
As a first step, organizations interested in having a dedicated OpenNebula instance should complete the request form available on our website;
https://adi-dc.com/opennebula/
Our sales team will contact you and, once the request has been validated, the provisioning process will begin.
3. Customer Access and Initial OpenNebula Environment Setup.
To ensure platform security and the isolation of each environment, access to the OpenNebula instance is via VPN. This additional layer of protection ensures that only authorized users can interact with the management system.
3.1 Prerequisites
- Windows, or Linux computer with Internet connectivity.
- VPN client installed (FortiClient).
- VPN Access credentials provided by aDi.
- * Your SSH public key (To access the Frontend server from which the exclusive Opennebula instance is deployed).The client must provide their SSH public key, preferably an Ed25519 key (id_ed25519.pub). RSA keys (id_rsa.pub) are also accepted if required for compatibility.Please provide your SSH public key to opennebulaservicerequest@adi-dc.com
3.1.1 VPN Client Installation
Download the VPN client from here;
https://www.fortinet.com/support/product-downloads
Select «FortiClient VPN-only»
Please follow the SSL VPN configuration manual you have received to complete the process and connect to the VPN; «VPN SSL CONNECTION USER GUIDE»
4. Initial Access to the aDi Cloud Portal
aDi Cloud Portal acts as the entry point to the customer’s cloud environment. From the aDi Cloud Portal, the customer can view the resources that have been assigned and prepared for their service. The customer will be able to connect via SSH to an instance that will have been previously provisioned by the IT department in aDi. The deployed instance consists of a virtual server that acts as the OpenNebula frontend and will serve as the central point of administration for the customer’s environment. The physical infrastructure supporting the service is operated and managed by aDi as part of the underlying platform and is therefore not directly exposed through aDi Cloud Portal, physical hosts are not exposed.
While aDi Cloud Portal serves as the entry point to the service, Sunstone provides the main web administration interface for the customer’s dedicated OpenNebula environment.
aDi Cloud Portal access URL;
Initial view of the customer tenant;
Basic functionalities include, viewing the resources assigned to their service, accessing the provisioned OpenNebula frontend instance, connecting to the instance through the available SSH console.
aDi Cloud Portal SSH Console View;
5. SSH Access to the OpenNebula frontend
Although aDi Cloud Portal may provide an embedded SSH console for basic access, the recommended operational method is to connect to the frontend using the customer’s own SSH client, such as:
- OpenSSH
- PuTTY
- MobaXterm
- Windows Terminal
Using an external SSH client provides a better user experience, including:
- copy and paste support,
- local key management,
- terminal history,
- and improved day-to-day administration capabilities.
The oneadmin account is the main administrative account within OpenNebula. On the frontend server, the OpenNebula CLI is typically executed from the Linux oneadmin user environment, which is configured to interact with the OpenNebula frontend.
*Now we strongly recommend consulting the official OpenNebula Documentation site:
https://docs.opennebula.io/7.0/quick_start/understand_opennebula/
6. Initial Access to the OpenNebula Sunstone web interface
Next you can connect to the Sunstone UI on the Front-end. On any machine with connectivity to the Front-end node, open your web browser and navigate to the IP address of your instance e.g., http://10.101.102.11:2616/fireedge/sunstone/dashboard You should be greeted with the Sunstone login screen:
You can log in as user «oneadmin» and password «oneadmin»
*Please change your default password as soon as possible.
7. Multi-Tenant Management: user roles, group/VDC, quotas, access policies.
OpenNebula provides a comprehensive multi-tenant management system that allows administrators to configure isolated environments for different clients, departments, or projects within the same platform.
- Users and roles with different privilege levels (global administrator, group administrator, standard user).
- Groups (tenants), which represent the basic unit of isolation, where users and resources are grouped together.
- Virtual Data Centres (VDCs), which allow physical or virtual resources (hosts, networks, datastores) to be assigned to one or more groups, ensuring separation and control of use.
- Quotas and access policies (ACLs), which limit and regulate resource consumption and permissions.
Thanks to these features, OpenNebula ensures that multiple tenants can operate independently and securely, while maintaining centralised control by the global cloud administrator.
7.1 Security Groups
Security Groups define firewall rules to be applied to Virtual Machines. They prevent accidental exposure of internal services (DB, LDAP, Redis, etc.), protect internal VMs even if you have a single public IP, they are part of the Least Privilege model.
By default, the ‘default’ security group allows all incoming and outgoing traffic.
OpenNebula automatically creates and manages firewall rules (iptables) based on Security Groups, on the KVM host, not on the vRouter.
8. Network, VM & Storage Operations
8.1 Network Model
The deployed OpenNebula instance includes two predefined basic networks. On these networks, you can implement simple environments (a single VM) as well as more advanced architectures (several VMs behind your own router/firewall).
Available networks;
Public Network (Internet access) [named vxlan — bridge in the networks section]
This network provides outbound Internet connectivity and is intended primarily for controlled external access. Allows VMs to access the Internet (updates, access to external services, etc…).
Recommended use:
- This network should be used primarily by the vRouter.
- If required, it may also be used by a specifically designed bastion VM providing controlled administrative access to internal virtual machines.
By default, outgoing traffic is allowed (from VMs to the Internet).
The Virtual Router (vRouter) connects its WAN interface to this external network and its LAN interface to the internal network (e.g., 172.16.50.0/24) where the internal VMs reside.
*The service includes a dedicated public IP address assigned to the vRouter. The specific value is provided separately as part of the customer handover documentation.
*Access from the Internet to VMs is not automatically enabled; it must be published in a controlled manner (see Virtual Router section).
Internal Private Network [named internal in the networks section]
Internal communication between your VMs (backends, databases, internal services, etc…).
It is the recommended network for hosting most of your application VMs, databases, etc.
Features:
- This network is not directly accessible from the Internet. External access is via a Virtual Router (vRouter).
8.2 Virtual Router
A virtual router provides routing across virtual networks. As an administrator, you can easily connect virtual networks from Sunstone and the CLI. The routing itself will be implemented with a virtual machine appliance available through the Marketplace.
Features:
- Setup NAT between public and private VNETs.
- Setup static port-forwarding between public and private VNETs.
- Setup static and dynamic load-balancing with either IPVS/LVS or HAProxy.
- Provide a DNS forwarder for isolated VNETs.
- Provide a simple OpenNebula-compatible DHCP4 server.
aDi provides the vRouter template with minimal configuration that enables the following services;
NAT4; Allows private networks (internal VNETs) to access the Internet.
How it works: Implements Source NAT (SNAT), i.e., translates the private IP addresses of the VMs to the public IP of the Virtual Router for outgoing traffic.
You can enable other services such as HAPROXY, LVS/Keepalived, DHCP4, DNS, LB, and SDNAT4.
There are three different layers;
- Virtual Router Template
- Virtual Router Object
- Virtual Router VM
The Virtual Router is instantiated from a Virtual Router Template. During instantiation, you define the network interfaces that will be attached to the router. The resulting Virtual Router object then manages one or more Virtual Router VMs. Network services such as NAT, HAProxy, or LVS are configured through the Virtual Router VM/template context.
8.2.1 How To Publish From External Services
You can publish your own external services by editing the context of the vRouter virtual machine.
Instances → VMs → vRouter → Configuration → Update VM Configuration → Context → Custom Variables:
In this example, SSH access is exposed to one of the internal virtual machines through the vRouter using vRouter HAProxy;
ONEAPP_VNF_HAPROXY_ENABLED="YES" ONEAPP_VNF_HAPROXY_INTERFACES="eth0" ONEAPP_VNF_HAPROXY_LB0_IP = 10.101.101.2 # Service ip ONEAPP_VNF_HAPROXY_LB0_PORT = 20000 # Service port ONEAPP_VNF_HAPROXY_LB0_SERVER0_HOST = 172.16.10.50 # Backend host ONEAPP_VNF_HAPROXY_LB0_SERVER0_PORT = 22 # Backend port
In this example, SSH access is exposed to one of the internal virtual machines through the vRouter using vRouter LVS/IPVS;
ONEAPP_VNF_LB_ENABLED = "YES" ONEAPP_VNF_LB_INTERFACES = "eth0" ONEAPP_VNF_LB0_IP = "10.101.101.2" ONEAPP_VNF_LB0_PORT = "20000" ONEAPP_VNF_LB0_PROTOCOL = "TCP" ONEAPP_VNF_LB0_METHOD = "NAT" ONEAPP_VNF_LB0_SCHEDULER = "rr" ONEAPP_VNF_LB0_SERVER0_HOST = "172.16.10.50" ONEAPP_VNF_LB0_SERVER0_PORT = "22"
In OpenNebula’s Virtual Router, both the HAProxy module and the Keepalived/LVS module operate at Layer 4. The HAProxy module acts as a simple TCP proxy/load balancer, while the LVS/IPVS module provides lower-level Layer 4 switching and forwarding options such as NAT/DR and scheduler-based distribution.
Each time you modify the context of the running VM, the corresponding entries are automatically generated in the haproxy service running within the vRouter.
The key difference is the following:
With HAProxy TCP, the backend does not normally see the original client IP address. When HAProxy proxies a TCP connection, it establishes the connection to the backend using its own source IP address unless additional mechanisms such as the PROXY protocol or transparent proxying are specifically implemented.
With LVS in NAT mode, the real server processes the request and returns the response through the LVS router, which performs NAT on the return traffic. In this model, the real server can still see the original client IP address, while the private IP address of the backend remains hidden from the client.
As a result, firewalling and logging behavior inside the backend VM differ depending on the publication method used:
| Aspect | With LVS (NAT) / SDNAT-DNAT | With HAProxy TCP |
|---|---|---|
| Firewall / iptables inside the VM | The VM sees the real client IP address | The VM sees the vRouter / proxy IP address |
| Security Groups / filtering on the VM NIC | Rules can be evaluated against the real client IP address | Rules will only see the vRouter / proxy IP address |
| SSH logs inside the VM | The real client IP address is recorded | The vRouter / proxy IP address is recorded |
*This difference has a direct impact on VM-level firewall rules, Security Groups, and SSH logging, because the source IP address seen by the backend VM depends on whether the service is exposed through LVS/NAT or through HAProxy TCP.
Examples of HAProxy and Keepalived configuration files;
8.2.2 Regenerating the Virtual Router from the Template
If the Virtual Router needs to be recreated, a new instance can be deployed directly from the Virtual Routers Template;
Add the interfaces. The first one eth0, corresponds to the public interface with Internet access. Normally for security reasons, do not expose SSH through this interface. Select Force IPv4 and configure the vRouter using the IP address 10.101.101.2
The second interface, eth1, corresponds to the internal network interface. It acts as the gateway for the internal virtual machines. Select Force IPv4 and configure the vRouter using the IP address 172.16.10.1
On the internal network, a single-address IP pool is configured and assigned to the vRouter as the gateway for the internal virtual machines;
Consult the official documentation to implement your own vRouter.
- https://docs.opennebula.io/7.0/product/virtual_machines_operation/virtual_machines_networking/vrouter/
- https://github.com/OpenNebula/one-apps/wiki/vr_intro
- https://github.com/OpenNebula/one-apps/wiki/vr_balancing
- https://github.com/OpenNebula/one-apps/wiki/vr_keepalive
8.3 How to Deploy VMs
The OpenNebula Marketplace is a centralised catalogue of virtual appliances, images, and ISOs ready to run directly on an OpenNebula cloud. Its aim is to simplify the deployment of operating systems and applications, preventing administrators from having to build images from scratch.
Marketplace ISOs allow manual installations, they do not have credentials. They require SSH keys for the first access.
By default, all virtual machines created with SSH access enabled will automatically have SSH access enabled with the user oneadmin from the frontend server. You can verify this as follows:
Access your account in Sunstone.
In the settings section, locate the SSH Key section.
From this point on, every time you instantiate a virtual machine and select Inject user public key in the Context tab, OpenNebula will automatically insert the key into the VM’s ~/.ssh/authorised_keys file.
Besides SSH key injection, the username and password parameters can also be specified in the VM context.
- First, you can import the desired image into the datastore.
In this example, we download the Alpine Linux 3.20 image.
- Now we are going to create a virtual machine from the downloaded Alpine template. A Debian virtual machine already exists in the screenshoot.
Click Instantiate to start the creation wizard and configure basic VM parameters:
- Name or identifying prefix.
- Define the number of vCPUs and RAM
- Adjust disk size
- Select the virtual network (VNet) to which the VM will be connected
- Finish and start creating the machine
You can now access the newly created machine using VNC or via SSH.
8.4 Storage Configuration
In the deployed infrastructure, three main datastores have been defined for each OpenNebula instance:
- System (ID 0, sys): Contains the discs and files of the VMs running on the host. You can view with command
onevm list.
- Default (ID 1, img): Contains the images (disc templates) that you can view with the command
oneimage list.
- Files (ID 2): Contains auxiliary files (CD-ROM, kernels, scripts, etc.).
9. Monitoring & Support: How to monitor
The Sunstone main panel provides a simplified view of the environment:
- General status of virtual machines (powered on, stopped, suspended).
- Summary of resources consumed versus allocated quotas (CPU, memory, storage).
- Lists of hosts, networks, and datastores with basic usage information.
For more detailed metrics (CPU usage per host, real-time memory consumption, network traffic, etc.), OpenNebula has a monitoring subsystem that collects data using monitoring probes. These metrics can be queried via the command line interface (CLI) or integrated into external observability solutions.
Please refer to the official documentation for more information;
