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 feature auto mounts NFS volumes for datastores. The behavior can be controlled with the following template attributes:
- ANFS_ENABLE: YES/NO to enable the automatic NFS management
- ANFS_HOST: hostname/IP of the NFS server
- ANFS_PATH: of the NFS share for this datastore
- ANFS_OPTS: Comma separated options (fstab-like) used for mounting the NFS shares
The shared drivers also performs a "garbage-collector" like to unmount NFS volumes on the hypervisors when the datastores are deleted. This operation is performed in a "lazy" way, when VMs are deployed on the hypervisor.
* oneimage create: mount/umount DS on demand
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* Move sh mount/umount logic to libfs.sh
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* oneimage delete: mount/umount DS on demand
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* Limit NFS mount/umount from SH code to 30s
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* oneimage clone: mount/umount DS on demand
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* onevm deploy: mount DS on demand
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* Temporal mount only when needed
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* onevm deploy: mount DS on demand (persisten)
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* Linter
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* onevm deploy: umount unneeded DS
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* Allow mount/umount/sed from sudoers
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* Temporal mount: use NFS_AUTO_OPTS
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* Do AutoNFS cleanup even during non-related ops
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* Final refactor and improvements
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* ro values for Datastore object
* Wording for AutoNFS RO attributes
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* NFS_AUTO_ENABLE: change 'true' to 'yes'
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* sudoers: merge everythng into ONE_NFS
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* Quote NFS_AUTO_OPTS
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* Fix difference between sudoers specs
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* Touch .automounted in AutoNFS mounts
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
* Update sudoers.rb
* Update rm
* Quote bash variable expansion
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
---------
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
Co-authored-by: Ruben S. Montero <rsmontero@opennebula.org>
