Add DISK_IDS as part of the VM backup configuration so backups can target a
subset of eligible VM disks. The configuration parser now normalizes and
validates the list against the VM and resets the incremental chain when the
selected disk set changes.
co-authored-by: Pavel Czerny <pczerny@opennebula.io>
(cherry picked from commit 59c2cac474de545eddd642e03e3caac8fb47c1cc)
This PR adds Group VLAN authorization rules for Virtual Network self-provisioning
through VN Template instantiation and VNET updates derived from a VN Template.
The feature lets administrators define VLAN usage policies at group level. These policies are
evaluated when users instantiate VN Templates or update VNETs that were instantiated from a VN
Template. Direct VNET allocation is not treated as the tenant self-provisioning path; the intended
multi-tenant model is to expose network creation through reservations and VN Template
instantiation, while direct VNET allocation remains an admin-controlled operation.
Group VLAN rules are stored under `VLAN_RULES` as `RULE` vector attributes.
Rule format:
```txt
RULE = [
ID = "5,6,100-200",
SCOPE = "CVLAN",
VNTEMPLATE = "10,20-30"
]
Fields:
- ID: VLAN values allowed by the rule. Supports single values and ranges, comma-separated.
- Examples: "5", "5,6,100-200"
- SCOPE: VLAN attribute scope controlled by the rule.
- Supported scopes: VLAN_ID, OUTER_VLAN_ID, CVLAN, VLAN_TAGGED_ID, ANY
- VNTEMPLATE: optional VN Template IDs where the rule applies.
- Supports single values and ranges, comma-separated.
- -1 or missing value means the rule applies to any VN Template.
Examples:
RULE = [
ID = "100-200",
SCOPE = "VLAN_ID",
VNTEMPLATE = "10"
]
Allows VLAN_ID values from 100 to 200 when instantiating or updating VNETs derived from VN Template
10.
RULE = [
ID = "300,400-450",
SCOPE = "ANY",
VNTEMPLATE = "-1"
]
Allows the listed VLAN IDs/ranges for any supported VLAN scope and any VN Template.
Rules are parsed into an internal structured representation when group VLAN data is loaded or
updated. Each rule is normalized into:
- scope
- VLAN ID ranges
- VN Template ID ranges
This avoids reparsing raw template attributes during authorization checks.
Validation is applied to these input scopes:
- VLAN_ID
- OUTER_VLAN_ID
- CVLAN
- VLAN_TAGGED_ID
VLAN_ID and OUTER_VLAN_ID are validated as single integer values. CVLAN and VLAN_TAGGED_ID accept
range expressions such as 5,6-10.
For each requested VLAN value or range:
1. The input is parsed into one or more test ranges.
2. Rules are scanned for matching scope, including ANY.
3. Rules are filtered by VN Template ID:
- empty/-1 VNTEMPLATE matches all templates
- explicit ranges match only included template IDs
4. A requested range is accepted only if it is fully covered by a single rule range.
5. The check passes when all requested ranges are covered.
Automatic VLAN selection is rejected when the user belongs to a group with VLAN rules matching the
target VN Template, including global rules. This avoids bypassing explicit group VLAN policy
through automatic allocation.
VNETs instantiated from VN Templates now preserve the source VN Template ID as a first-class VNET
attribute:
<VNET>
...
<TEMPLATE_ID>...</TEMPLATE_ID>
...
</VNET>
TEMPLATE_ID = -1 means the VNET was created directly and was not instantiated from a VN Template.
This ID is immutable from user template updates:
- it is removed from the VNET template body on insert/update
- it is serialized as a top-level VNET attribute
- update operations use the stored value to validate VLAN authorization
A database migrator moves legacy TEMPLATE/TEMPLATE_ID values to top-level VNET/TEMPLATE_ID.
The tenant self-provisioning model for VNETs is based on controlled entry points:
- VNET reservations
- VN Template instantiation
Group VLAN authorization is enforced on VN Template instantiation and on updates to VNETs that were
instantiated from a VN Template.
Direct VNET allocation is not considered the tenant-facing self-provisioning path. It should remain
admin-controlled, as unrestricted VNET creation can expose other sensitive network attributes such
as PHYDEV, BRIDGE, and driver-specific configuration in addition to VLAN IDs.
Existing VNETs created from VN Templates may have the source template ID stored inside TEMPLATE/
TEMPLATE_ID. The migration step moves that value to top-level VNET/TEMPLATE_ID and removes it from
the template body.
This PR also updates the AR operations (add/del/update) so tenants can easily managed the VNET instantiations.
Existing directly-created VNETs will have no source VN Template and are treated as TEMPLATE_ID =
-1.
Existing group objects without VLAN rules are initialized with an empty VLAN_RULES section,
preserving current behavior until rules are explicitly configured.
Configuration compatibility:
- VLAN_ID, CVLANS, and AR/VLAN_ID are no longer expected to be handled through generic VNET
restricted attributes for the VN Template instantiation flow.
- OneCfg migration/update handling for configuration files will be addressed separately before
release.
co-authored-by: Pavel Czerny <pczerny@opennebula.io>
co-authored-by: Miguel E. Ruiz <mruiz@opennebula.io>
co-authored-by: dcarracedo <dcarracedo@opennebula.io>
This commit introduces a new backup driver based on an "interactive" server. The purpose is to ease the integration of third-party backup systems so they are able to pull backups/increments from the hypervisors:
- New backup driver
- New OpenNebula Backup Exporter (OneBEX). The REST API supports: status,
export, exporters, blocks, data and finish.
- Initial support for file based virtual disks (incrementals only support CBT)
- Refactor backup_qcow2 to accomodate the new logic
- New restore logic to directly write images to the datastore from the backup service.
Co-authored-by: Ruben S. Montero <rsmontero@opennebula.org>
- Configure Open vSwitch VF representor ports
- Apply VLAN, QinQ, and trunk tagging to representors
- Clear OVS port tags when VLAN_ID is empty on update
- Update monitoring components for the new network support
- Fix non string message driver logging
- #7707, fix update VLAN IDs
co-authored-by: Ruben S. Montero <rsmontero@opennebula.org>
New configuration attribue MAC_GLOBAL_SPACE in oned.conf to enable the global
MAC address space generation mode.
MAC addresses are generated from a global pool preventing collisions across
VNETs. This does not apply to IP networks and limits the number of VNETs to
2^20, with a max of 2^20 leases per VNET.
This commit also implementes:
* A round-robin assignment of addresses. (jukka.jokiniva@qt.io)
* Optimizes the storing of the BitMap - do not store leading zeros
co-authored-by: Pavel Czerny <pczerny@opennebula.io>
co-authored-by: Jukka Jokiniva <jukka.jokiniva@qt.io>
Extend the FireEdge log fix to oned, oneflow, oneform, onegate and
onehem so they share the same rotation behavior:
- Add compress / compressoptions -9 / delaycompress to the logrotate
configs. With copytruncate, delaycompress avoids gzipping the
freshly-rotated file in the same pass and keeps service restarts
fast even when ExecStartPre runs logrotate -f.
- Drop the synchronous gzip ExecStartPre loops from each unit. The
glob (e.g. oneflow*.log) does not match files rotated with
dateformat -%Y%m%d-%s, so the loop was ineffective, and running
gzip without backgrounding blocked startup.
- Ship a logrotate config for oneform; the unit was pointing at
/etc/logrotate.d/opennebula-form but no such file existed, so
oneform.log was never rotated.
- src/hem/bin/onehem-server: use >> instead of > so restarts via the
shell wrapper do not truncate the log, matching oneflow / onegate /
oneform / fireedge wrappers (originally fixed in #6034).
Signed-off-by: Mikalai Kutouski <mkutouski@opennebula.io>
Co-authored-by: Jan Orel <jorel@opennebula.io>
Add load_opennebula_paths stub to the CLI gem and include the missing
opennebula/lib/ files in the OCA gem so both gems work when installed
standalone via RubyGems.
OpenNebula Document Server (ODS) is a lightweight Sinatra-based server that
provides a foundation for building API servers within the OpenNebula ecosystem
which work with Documents. It can be used as a base class for custom services,
making it easier to maintain consistency across different OpenNebula
servers.
Features
========
- Provides a configurable base server class that can be inherited.
- Centralized logging setup with `LogConfig`.
- Supports modular route registration via `AppRoutes`.
- Easy configuration through `ConfigLoader`.
- Preconfigured error handling and exception management.
NAME = test_ds
DS_MAD = virtiofs
TM_MAD = local
TYPE = IMAGE_DS
DISK_TYPE = FILESYSTEM
oneadmin@ubuntu2204-kvm-ssh-7-0-f4a9-0:~$ cat img.txt
NAME="test_fs"
TYPE="FILESYSTEM"
PATH="/var/tmp/sharedfs_test"
PERSISTENT="YES"
PERSISTENT_TYPE="SHAREABLE"
DISK=[
IMAGE_ID="21" ]
Notes:
* Same FS image cannot be used twice in the same VirtualMachine, nor the
same tag twice
* OpenNebula will generate a MOUNT_POINT = /mnt/one-fs-<image_id> and a
MOUNT_TAG = one-tag-<image_id>. Both can be overwritten at DISK level.
* When using Hugepages in the VM that will be used for virtiofs and
memory access will default to shared. Do not use
MEMORY_ACCESS='private'
* If not using hugepages the VM will use memfd as memoryBacking source
if it includes a filesystem.
* OpenNebula will map FS access (UID/GID) to a given user that can be
configured per host, cluster or globally in vmm_exec_kvm.conf. By
default all access is mapped to oneadmin account.
* Datastore monitorization will report 0 free/used/total size. Images,
representing the FS folder, reports size as the result of a du -sb
command.
* Most of the disk operations do not apply to filesystem disks: resize, snapshots,
save-as, backup.
co-authored-by: MarioRobres <mrobres@opennebula.io>
co-authored-by: Marco Mancini <mmancini@opennebula.io>
Signed-off-by: MarioRobres <mrobres@opennebula.io>
Signed-off-by: Marco Mancini <mmancini@opennebula.io>
Add new attribute to prevent migrations on unsopported drivers. Add
migrator to add it to DS templates
coauthored-by: Guillermo Ramos <gramos@opennebula.io>
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
Jan Orel