- New attribute VIDEO, that includes
- TYPE: Custom video device (none, vga, cirrus, virtio)
 - IOMMU: Enable IOMMU for the video device
 - ATS: Enable ATS (Address Translation Services) for the video device
 - VRAM: VRAM allocated to the video device (Megabytes)
 - RESOLUTION: Video resolution, in format like: 1280x720 or 1920x1080
- Support for onevm CLI command
- Updated VM xsd file.
* Set priority on Backup Job create
* Fix a bug when running backup jobs in sequential mode
* Change the update semantics to support replace mode
* Update Ruby, Golang and Java API accordingly
* F #6063: Adress PR comments
The connection to an external scheduler module is configured in sched.conf:
EXTERNAL_SCHEDULER = [
SERVER = "http://localhost:4567",
PROXY = "",
TIMEOUT = 10
]
The API post on '/' the list of VMs, their pre-selected list of
candidate hosts based on REQUIREMENTS along with the VM information
(CAPACITY, TEMPLATE and USER_TEMPLATE).
Example:
{
"VMS": [
{
"CAPACITY": {
"CPU": 1.5,
"DISK_SIZE": 1024,
"MEMORY": 131072
},
"HOST_IDS": [
3,
4,
5
],
"ID": 32,
"STATE": "PENDING",
"TEMPLATE": {
"AUTOMATIC_DS_REQUIREMENTS": "(\"CLUSTERS/ID\" @> 0)",
"AUTOMATIC_NIC_REQUIREMENTS": "(\"CLUSTERS/ID\" @> 0)",
"AUTOMATIC_REQUIREMENTS": "(CLUSTER_ID = 0) & !(PUBLIC_CLOUD = YES) & !(PIN_POLICY = PINNED)",
"CPU": "1.5",
"MEMORY": "128",
...
},
"USER_TEMPLATE": {}
},
{
"CAPACITY": {
"CPU": 1.5,
"DISK_SIZE": 1024,
"MEMORY": 131072
},
"HOST_IDS": [
3,
4,
5
],
"ID": 33,
"STATE": "PENDING",
"TEMPLATE": {
...
},
"USER_TEMPLATE": {}
}
]
}
The scheduler needs to respond to this post action with a simple list of
the allocation for each VM:
{
"VMS": [
{
"ID": 32,
"HOST_ID": 2
},
{
"ID": 33,
"HOST_ID": 0
}
]
}
This commits vendorize Vendorize nlohmann-json (MIT license)
* Schedule Action Manager executes only on RAFT leader in HA configurations.
* Relative time for Scheduled Action Backup Jobs returns error.
* Store Backup Job ID to VM and associated backup Image.
* VM can be only in one Backup Job at a time.
* Deny single Backup if the VM is already part of BackupJob to prevent
inconsistent backup states.
Other fixes:
- Fix crash on scheduled backup for VM in pending state
- Fix error messages for Scheduled Actions
- Remove SCHED_ACTION from Backup Job template on update
co-authored-by: Pavel Czerný <pczerny@opennebula.io>
- Add suport for delete snapshots in the middle of the chain in qcow2
(ALLOW_ORPHANS=NO). Example, snapshot 2 below:
0 <- 1 <- 2 <- 3
- It supports removing the last snapshot and active (blockpull) and
first one (snapshot 0). The first snapshot cannot be deleted in
persistent images because of the underlying link setting.
- Snapshots are deleted by blockcommit. For example to delete 2, 3 is
committed into 2:
0 <- 1 <- 2: (2+3)
A new file 3.current is created in the filesystem to look for the
actual file name supporting snapshot 3.
- qcow2/shared operations snap_delete, snap_revert and cpds
(disk-saveas) has been updated to react to the .current files
- The kvm/deploy action has been updated to resolve links in source file
attributes. This is needed so the <backingStore> of the libvirt domain
does not contain the sysmlinks that changes on the revert/create
operations.
- The kvm/migrate action also includes a minor modification to resolv
the VM disk
- Snapshots with more than 1 child (or their relatives) cannot be deleted to not
break backing chains.
- It has been found that the snap-delete operation in suspend state is
insecure as the guest caches may not be updated accordingly. The
operation is now not allowed in this state.
- The associated state has been removed from oned. It needs to be
removed in CLI/Sunstone and APIs
- The changes are for VM disk-snapshots. A similar update can be made
for images in the datastore/fs snap_delete action. This operation is
not implemented in this commit.
Note: Output of xmllint may or may not include new lines when multiple matches
of an xpath expression occurs. Parsing of xmllint output adds additional new lines
to deal with different versions.
Includes the following changes:
- xml-schema for Backup Job and Scheduled Actions
- GO, Java api
- Deprecate onevm update-chart, delete-chart
* The commands are replaced by sched-update and sched-delete
* Refactor method deprecate_command, it's still possible to run the
command
* Delete 'shutdown' and 'delete' commands deprecated years ago
* Fix --verbose option for sched-update and sched-delete
- Re-implementation of scheduled actions, now are managed and executed
by oned
- Backup Job objects, API, and CLI commands
* Add Sched actions and sg (de)attach to VM_*_OPERATION
* Add Backup cancel action
* For consistency add poweroff migrate, alias (de)attach and nic update to set_auth_ops
VM topology can be defined:
- To use a NUMA node and huge pages. Example:
TOPOLOGY = [ NODE_AFFINITY = 0, HUGEPAGE_SIZE = 2 ]
- To use huge pages without specifying the NUMA node. Example:
TOPOLOGY = [ HUGEPAGE_SIZE = 2 ]
In any case OpenNebula will:
- look (or check) for a NUMA node with enough free huge pages
- will pick the NUMA node with more free pages (if no NUMA node is specified)
- configure the VM with CPU affinity to the selected NUMA node
(cherry picked from commit 1b3b88ed4e)
* NODE_AFFINITY can be used to pin a VM to all the CPUs of a NUMA node.
The attribute is part of the TOPOLOGY definition.
* A default virtual topology is defined when no other is set. This
allows to set only the affinity:
TOPOLOGY = [ NODE_AFFINITY = 1 ]
* NODE_AFFINITY can only be set for not-pinned VMs to not conflict with
core allocations for pin VMs. VMs with NODE_AFFINITY set will be
allocated to regular hosts (i.e. PIN_POLICY = NONE)
(cherry picked from commit fc15d6ebc9)
Extending the BACKUP state may lead to unneed wait times to perform VM
management operations
Fixes reset of backup chains for poweroff state
(cherry picked from commit 377db9653e)
Some backup drivers may not allow delete (forget) operations while an
active backup is being performed. This commits fails the
one.image.delete API call in that case.
A new configuration attribute to describe the related driver behavior has been
added CONCURRENT_FORGET for DS_MAD_CONF.
(cherry picked from commit 940c1d7d63)
* Introduce support to follow KEEP_LAST for incremental backups.
- New increment_flatten action added for backup datastores.
- increment_flatten will consolidate KEEP_LAST increments into the
current first increment in the chain.
- increment_flatten MUST return the new chain (inc1:source1,...) and size
of the new first increment (FULL) in the chain.
* Downloader logic for restore has been extracted from downloader.sh to
reuse the increment flatten logic. A new command restic_downloader.rb
process restic:// pseudo-urls.
* Restore process uses two new attributes to customize the restore
process:
- NAME to be used as base name for images and VM Template
- INCREMENT_ID to restore disks from a given increment (not always the
last one)
* Common logic has been added to BackupImage class (backup.rb)
* Includes the following fixes:
- Fix when increment includes blocks larger than max qemu-io request size
- Fix IMAGE counter for quotas on backup images
- Fix rsync restore NO_IP / NO_NIC attributes
TODO:
* Mimic increment_flatten logic and restore images on the backup server
* Suntone restore options
co-authored-by:Michal Opala <mopala@opennebula.io>
Add support for block context CD's. System Datastore can include
CONTEXT_DISK_TYPE to specify the type (FILER or BLOCK) of the context
CD's
co-authored-by: Victor Palma
- Qemu will terminate VMs with system snapshots and checkpoints, example:
libvirtd[7446]: internal error: qemu unexpectedly closed the monitor: 2022-12-07T16:06:59.603678Z qemu-kvm-one: Device has active dirty bitmaps.
- Also disk snapshots may render inconsistent bitmaps, example:
'virsh --connect qemu:///system checkpoint-delete 45d76e5f-25fa-416a-97fd-1624380d5e02 one-191-0': error: Failed to delete checkpoint one-191-0 error: internal error: unable to execute QEMU command 'query-named-block-nodes': Bitmap '' doesn't satisfy the constraints Error preparing disk files
This commits prevents snapshot operations when increment backups are configured, and vice versa.
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
- Adds new configuration attribute MODE: FULL or INCREMENTAL for
BACKUP_CONFIG. FULL backups uses a differen backup image.
- INCREMENTAL backup information is together with the backup image.
Example:
<BACKUP_INCREMENTS>
<INCREMENT>
<DATE><![CDATA[1667770552]]></DATE>
<ID><![CDATA[0]]></ID>
<PARENT_ID><![CDATA[-1]]></PARENT_ID>
<SIZE><![CDATA[172]]></SIZE>
<SOURCE><![CDATA[bb828060]]></SOURCE>
<TYPE><![CDATA[FULL]]></TYPE>
</INCREMENT>
<INCREMENT>
<DATE><![CDATA[1667770604]]></DATE>
<ID><![CDATA[1]]></ID>
<PARENT_ID><![CDATA[0]]></PARENT_ID>
<SIZE><![CDATA[1]]></SIZE>
<SOURCE><![CDATA[ca0de5f6]]></SOURCE>
<TYPE><![CDATA[INCREMENT]]></TYPE>
</INCREMENT>
<INCREMENT>
<DATE><![CDATA[1667770700]]></DATE>
<ID><![CDATA[2]]></ID>
<PARENT_ID><![CDATA[1]]></PARENT_ID>
<SIZE><![CDATA[39]]></SIZE>
<SOURCE><![CDATA[e9897d6a]]></SOURCE>
<TYPE><![CDATA[INCREMENT]]></TYPE>
</INCREMENT>
</BACKUP_INCREMENTS>
This information only appears on incremental backups
- Internal BACKUP_CONFIG data includes information about the current
active backup and the last increment id.
- Backup operation includes a new parameter: reset. This "closes" the
current active incremental chain and creates a new FULL backup.
- Backup drivers store backups with increment index (0 = FULL) e.g.
disk.0.0.
- Incremental backups are only allowed for VMs using all disks in qcow2
format.
- Backup configuration cannot be changed while doing a VM backup.
- Downloader strings includes backup chains <inc_id>:<backup_ref>,...
- Restic downloader has been updated to support backup chains. Disk
images are rebased across increments.
Tino Vázquez