Data model¶
What the portal works with, who defines it and where it lives: the infrastructure records, tenant resources and how they are stored in OpenNebula.
1. Sources of data¶
| Data | Defined by | Lives in |
|---|---|---|
| Infrastructure | resource managers and support engineers, in the portal | portal records (sites, profiles, hosts, storage, networks, platforms, clusters). Loaded once from the old inventory files; edited only in the portal since |
| Secrets | the same people | portal records, encrypted (Infrastructure → Secrets); records refer to them by key |
| Organizations, tenants, orders, resource records, addresses | customers and staff, through the portal | the portal database (desired state) |
| What OpenNebula holds | the platforms | collected read-only every 15 minutes (actual state) |
| The old system | its operators | imported read-only during adoption |
2. Principles¶
- One place to edit. Every infrastructure object is a record edited in a dialog of its list; no file is read at run time. A record that others refer to (a volume under a datastore, a network under a platform network, a host in a cluster) cannot be deleted.
- Names are unique where OpenNebula needs it. Objects created in OpenNebula (clusters, datastores, networks) carry the site in their name,
payload1-vms01_dc1, so federated zones never clash. - Sizes are in GiB.
- States: planned (not installed), active, retired (removed, kept until taken down).
- Desired vs actual. The database is the desired state; tenant records are versioned (append-only), tenants are blocked or archived, not removed.
3. Infrastructure records¶
server profile ─┐
site ───────────┼── host ───────────────┐
│ │ │
├── storage (nfs / iscsi / local) ── volume ──┐
├── network (core / ix / evpn / storage) │
│ ├── ranges │
│ └── BGP peer groups (rrs, igw, egw) ─ secrets
└── platform (kind, front end, mode) │
├── datastore (vms / images / files / backups) ─ volume
├── network (vlan / bridge) ─ site network + ranges
└── cluster (kind) ─ hosts, datastores, networks
4. Site resources¶
Site¶
Code (name), site code (number, fixed once set, part of the AS numbers), country, city, time zone, NTP (up to 4), DNS (up to 3), green-field DNS (up to 2), IPMI settings, management hosts and ports, jump hosts.
Server profile¶
| Field | Meaning |
|---|---|
| chassis | vendor, model, IPMI type |
| CPU | vendor, model, sockets, cores per socket, MHz — physical cores feed the capacity view |
| RAM | total GB, DIMM details |
| boot | boot device and its volumes (name, size, file system, mount path) |
| NICs | cards: vendor, model, type (media), speed, number of ports and their OS names; bonds |
| GPU | model, count, VRAM |
| reference host, check | the host the profile was made from; the last consistency check of every host of the profile |
Host¶
Name (the hostname), IP for ssh, IPMI address and type, IPMI user (a secret), state, server profile (optional: detected from the hardware when added; a new profile is made when none matches), hardware facts as reported by the OS and IPMI.
Storage and volumes¶
| Type | Storage | Volume |
|---|---|---|
| NFS | one target address, fstab parameters | name, export, size GiB, clients |
| iSCSI | several target addresses, port, fstab parameters | device (as in lsblk), size GiB, initiator IQNs |
| local | the host | device (as in lsblk), size GiB |
Network¶
Name, type (core, ix, evpn, storage), interface, VLAN, MTU, subnet, gateway, state; ranges (name, start, length); BGP: local AS, delegated subnets (ix), remote AS (ix), and the peer groups rrs (addresses), igw and egw (addresses and subnets), each with the range its hosts came from and a password set from Secrets. Defaults: an ix network gets ranges ext-gws .0/30 and rrs .240/30, an evpn network rrs .240/30.
5. Platforms¶
| Record | Fields |
|---|---|
| Platform | name, kind (mgmt, shared, dedicated, portal), state, provider, super admins (secret), front end: mode (single, local, primary, secondary → primary), VIP, nodes, OpenNebula credentials (secret); operations mode and network function image |
| Datastore | name, type (vms, images, files, backups), the storage volume, path |
| Network | name, type (vlan: an 802.1Q network on a site network; bridge: an existing bridge), the site network, the ranges to create |
| Cluster | name, kind (mgmt, shared, dedicated, platform, edge, portal), state, hosts, datastores and networks of the platform. The quota code is kept for existing tenants and not shown. |
6. Secrets¶
Every secret is a record with a key, kind, user, the encrypted value and what is not secret (a database name, public keys, jump host addresses). Kinds: OpenNebula front end (linux user and oneadmin passwords), password, ssh key, BGP password set (rrs, igw, and egw for exchange networks), IPMI, database (name, user, password), jump hosts. New passwords follow the password policy. Retired secrets are kept for the record; values are shown only on purpose and every view is logged.
7. Checks¶
- a secondary front end has a primary; a host belongs to one site and its clusters to one platform;
- object names created in OpenNebula end with
_<site>; - shared front ends are separate: no exchange network and no host may be used by two of them;
- BGP peer hosts: route reflectors addresses only, igw and egw addresses or subnets, all inside the network;
- Check on a server profile compares the hardware of every host with the profile.
8. Tenant resource records¶
A tenant has one record per cluster (quota code) on each site where it has resources; tenant + site + quota code is unique. Records are append-only versions with an effective date.
| Field | Level | Meaning |
|---|---|---|
| cpu, ram_gb, gpu | cluster | vCPU, RAM GB, GPUs (fixed slices of the server profile) |
| disk_gb, images_gb, files_gb | cluster | storage: one number for VM disks, images and files and the image and file parts of it, see storage quotas |
| backups_gb | site (sum) | backup datastore space; records of one site are added up |
| connection types | site | routed connections inet, corpnet (both possible), none when only L2; see the network page |
| igw_type, inet_mbps, inet_main_prefix, inet_public_prefixes | site | internet: gateway type (vyos, onevr, custom), bandwidth, main and additional prefix lengths |
| corpnet_prefixes | site | corporate network prefix lengths |
| l2_vlans, l2_vnets | site | external L2 channels: VLANs (entered by support) and the tenant VNets they connect to |
| date_created | cluster | first day the resources are available |
| date_review | — | end of the current paused/suspended period; database only |
9. Storage quotas¶
- One storage number covers VM disks, images and files. Tenant admins split it on the tenant page without approval; by default above 100 GB 20 GB go to images and 1 GB to files, VM disks the rest.
- The first 1 GB of files is free. Backups are a separate number, 0 by default.
- Old tenants are converted to the one number (files default 1, images default 10).
10. Tenant status¶
| Status | Account | VMs | Connectivity | Resources |
|---|---|---|---|---|
| ok | active | running | working | kept |
| paused | blocked in OpenNebula (portal login works) | running | blocked | kept |
| suspended | blocked | powered off | blocked | kept |
| archived | deleted, portal login blocked | deleted | — | one full backup of every VM is kept |
ok ──► paused ──(2 weeks)──► suspended ──(1 month)──► archived
▲ │ │
└─────────┴──────────────────────┘
date_review is the day the current status ends (paused + 2 weeks, suspended + 1 month); until then the tenant can return to ok. archived is final. The database row itself is never deleted.
11. Storage in the OpenNebula group¶
The group of a tenant (its tenant ID: _t_<org>_<tenant>, or tenant-<name> for old tenants) carries an emergency copy of the tenant's current state as vector attributes; upper-case names, string values, empty fields omitted.
TENANT—STATUS,DATE_CREATED; plus the sales rep email and organization info.QUOTA_<SITE>— per site: summedFILES_GB,BACKUPS_GBand the site's connectivity, including the assigned subnets (INET_MAIN_SUBNET,INET_PUBLIC_SUBNETS,CORPNET_SUBNETS).QUOTA_<SITE>_<CODE>— per record:CPU,RAM_GB,GPU,DISK_GB(VMs + images),DATE_CREATED.
TENANT = [ STATUS = "ok", DATE_CREATED = "2026-02-10" ]
QUOTA_DC1 = [
FILES_GB = "1", BACKUPS_GB = "500",
CONNECTION_TYPE = "corpnet inet",
IGW_TYPE = "vyos", INET_MBPS = "100", INET_MAIN_PREFIX = "31", INET_MAIN_SUBNET = "203.0.113.28",
CORPNET_PREFIXES = "28", CORPNET_SUBNETS = "198.51.100.64"
]
QUOTA_DC1_CI1 = [ CPU = "10", RAM_GB = "20", DISK_GB = "100", DATE_CREATED = "2026-02-10" ]
Pending and archived tenants exist only in the database. The portal compares this copy with its own records and shows differences on the tenant page.
12. Portal database¶
| Area | Main tables |
|---|---|
| People | users (staff and customers, roles, 2FA), invitations, audit log |
| Customers | organizations (type, IIN/BIN, short name, sales rep, KAM, contacts), tenants (type, stage, approval, status, order, tenant ID), memberships, join requests, balance confirmations |
| Resources | quota records and connectivity (append-only versions), prefix assignments (address registry) |
| Infrastructure | sites, server profiles, hosts, storage and volumes, networks with ranges and BGP peer groups, delegated subnets, platforms with datastores, networks and clusters; secrets; templates; platform endpoints; the stored inventory revisions of the one-time load |
| Adoption | imports from the old system, observations and live statistics of OpenNebula |