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>
* Fix range wrapping in multi-leases ranges (i.e. not use 8,9,0)
* Skip reservations and shared AR's in fsck.
* Do not reserve MAC addresses on VNET reservations
* Release MAC ID's on virtual network drop (with existing AR's)
* NEXT_INDEX is an internal attribute (cannot be set by user)
* Check size on update
- vmm,vnm: unify OVS DPDK vhost socket handling
- Use a shared /var/lib/one/vhost-sockets path for OVS DPDK interfaces in the KVM and Open vSwitch drivers, and create the directory when needed.
- Also fix DPDK NIC attach/detach to use the vhostuser device XML.
BRIDGE_TYPE can be now a comma separated list "openvswitch,
openvswitch_dpdk". When created a VNET any value from the list for that
driver can be set.
NOTE: This commit includes oned.conf changes
(cherry picked from commit aa33731c288ca928c9d13c18e1ca5a67ff692262)
add oned.conf
This commit adds support for sharing IPs among several VMs. When a AR is
marked as shared several VMs can request the same IP address either
through a NIC or NIC_ALIAS.
- Shared AR's cannot assign IP address automatically, an specific IP
needs to be requested.
- Shared AR's have some restrictions:
- Shared AR cannot use external IPAM
- Shared AR can only be of type IP4 or IP6_STATIC
- Shared AR cannot update IPAM or SHARED attribute
- Shared AR cannot make reservations
- Shared AR cannot hold by mac
- NICs / NIC_ALIAS using Shared IP will include SHARED=YES
co-authored-by: Jorge Miguel Lobo Escalona <jlobo@opennebula.io>
co-authored-by: MarioRobres <mrobres@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>
co-authored-by: Pavel Czerný <pczerny@opennebula.systems>
co-authored-by: Frederick Borges <fborges@opennebula.io>
co-authored-by: Christian González <cgonzalez@opennebula.io>
* VNET updates trigger a driver action on running VMs with NICs in the
network.
* VNET includes a sets with VM status: updated, outdated, error and
updating. With VMs in each state.
* VNET flags error situations with a new state UPDATE_FAILURE.
* The same procedure is applied when an AR is updated (only VMs in that
AR are updated).
* A new options in the one.vn.recover API call enable to recover or
retry this VM update operations.
* The following attributes can be live-updated per VNET driver:
- PHYDEV (novlan, vlan, ovs driver)
- MTU (vlan, ovs driver)
- VLAN_ID (vlan, ovs driver)
- QINQ_TYPE (ovs driver)
- CVLANS (ovs driver)
- VLAN_TAGGED_ID (ovs driver)
- OUTER_VLAN_ID (ovs driver)
- INBOUND_AVG_BW (SG, ovs driver + KVM)
- INBOUND_PEAK_BW (SG, ovs driver + KVM)
- INBOUND_PEAK_KB (SG, ovs driver + KVM)
- OUTBOUND_AVG_BW (SG, ovs driver + KVM)
- OUTBOUND_PEAK_BW (SG, ovs driver + KVM)
- OUTBOUND_PEAK_KB (SG, ovs driver + KVM)
* New API call one.vm.updatenic, allows to update individual NICs
without the need of detach/attach (only QoS supported).
* Update operations for: 802.1Q, bridge, fw, ovswitch, ovswitch_vxlan
and vxlan network drivers.
* VNET attributes (old values) stored in VNET_UPDATE to allow
implementation of update operations. The attribute is removed after a
successful update.
* Updates to CLI onevnet (--retry option) / onevm (nicupdate command)
* XSD files updated to reflect the new data model
* Ruby and JAVA bindings updated: new VNET state and recover option, new
VM API call.
* Suntone and Fireedge implementation (lease status, recover option, new
states)
TODO: Virtual Functions does not support this functionality
iii
* VNETs include state to flag their configuration status
(READY/ERROR/LOCK)
* Hooks can be program based on VNET state transitions
* Include Java/Go/Ruby bindings
* New vCenter network drivers
* Place-holder to customize actions (create/delete) for other netowrk drivers
* Sunstone integration
* OneFlow syncs flow creation on VNET status
* Remove deprecated vcenter hooks and autoregistration
co-authored-by: Frederick Ernesto Borges Noronha <fborges@opennebula.io>
co-authored-by: Alejandro Huertas <ahuertas@opennebula.io>
co-authored-by: Pavel Czerny <pczerny@opennebula.systems>
* There are encrypted attributes for VMs, Hosts and VNets
* For VMs the user template is also encrypted
* For VNets its address ranges attributes are also encrypted
Co-authored-by: Alejandro Huertas <ahuertas@opennebula.systems>
Daniel Clavijo Coca