Allow PCI requests to select an available VF using PF_IFNAME or
PF_ADDRESS. Reserve fixed PCI addresses before PF and generic selectors
to keep availability checks and allocation consistent.
Monitor PF/VF relationships and eswitch mode, refresh PCI network
metadata, and prevent passthrough of PFs with enabled VFs. Preserve
compatibility with older probes.
Expose PF interface selection and VF availability in Sunstone, preserve
selectors when editing templates, and update the host XML schema.
co-authored-by: Victor Hansson <vhansson@opennebula.io>
co-authored-by: Daniel Clavijo Coca <dclavijo@opennebula.io>
* Cache VNC reservation BitMap
* Optimize xpath - no need to create vector<string> as we always use the
first value
* Optimize VectorAttribute::replace
* Use string_view in Attribute and Template
* Avoid temporary stream in escape_xml
* Optimize logging of ddebug and dddebug messages. Lazy stream builder: Avoid composing of expensive long strings, if the
message is discardad because of log level
Adds new oned.conf parameter to configure oned IP allocation mode.
REUSE_ADDRESS: Reuse the first available address instead of assigning
addresses in round-robin order for internal address ranges.
- if possible use vector<unique_ptr<Attribute>> as argument for Template::remove for automatic cleanup
- if possible use 'VectorAttributeinstead ofAttributeforTemplate::remove- theremovemethod has dynamic cast to correct type and deletes attributes, which can't be casted. So no need to add loop with casting after theremove` method
- At few places added checks for empty vector to avoid very rare crashes on malformed Templates
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>
* 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
* Skip global MAC ID release for reservation ARs because the parent AR owns the bitmap entry.
* Reject global MAC address ranges whose SIZE crosses the reserved 20-bit host block.
* Release reserved global MAC IDs when AR initialization fails after MAC assignment.
* Treat shared ARs as having no global MAC ID so bitmap release paths ignore them.
* Wrap multi-lease range scans correctly so allocation can find ranges starting at index 0.
* Keep IP6 in expanded security-group rules by removing allocator-only NEXT_INDEX from copied AR fields.
* Remove the leftover VNC bitmap debug dump from onedb fsck.
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>
Add support for per-VM migration flags (--auto-converge and --compressed)
controlled by VM template attributes:
- MIGRATE_AUTO_CONVERGE: Initial CPU throttling rate/increment (ranges: 0-100).
Format: <initial>[,<increment>]
- MIGRATE_COMPRESSED: Enable migration compression (YES/NO). Default: NO
This commit also adds a FEATURES parser and use it during VM creation and updateconf.
The parser normalizes boolean FEATURES values, validates GIC and MIGRATE_AUTO_CONVERG.
Since FEATURES are normalized in oned, the commit removes some redundant checks.
updateconf allow updates GIC, RAS, MIGRATE_* options
See also https://libvirt.org/manpages/virsh.html#migrate
Author: Guillermo Ramos <gramos@opennebula.io>
co-authored-by: Guillermo Ramos <gramos@opennebula.io>
co-authored-by: Ruben S. Montero <rsmontero@opennebula.org>
Signed-off-by: Guillermo Ramos <gramos@opennebula.io>
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>
- 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.
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>
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
The following TM's now support storage live migrations:
- File system based (local and shared variants)
- LVM based (pure LVM, and LVM thin)
The LVM TM's does not support migrating a VM with disk snapshots.
co-authored-by: Guillermo Ramos <gramos@opennebula.io>
co-authored-by: josepselga <jselga@opennebula.io>
Author: Guillermo Ramos <gramos@opennebula.io>
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>
* Remove unneeded breaks, support Enum as slices
* use cassert instead of GPR_ASSERT
* Use pkg-config for grpc dependencies
* Make Client destructor virtual
Pavel Czerný