This guide is aimed at OpenNebula 6.2.x users and administrators who want to upgrade to the latest version. The following sections summarize the new features and usage changes that should be taken into account, or are prone to cause confusion. You can check the upgrade process in the corresponding section. If upgrading from previous versions, please make sure you read all the intermediate versions’ Compatibility Guides for possible pitfalls.
Virtual Machine. VM now includes
SNAPSHOT/SYSTEM_DISK_SIZEto count system DS disk usage occupied by VM snapshot. The size is used to count
SYSTEM_DISK_SIZEquota. This attributes applies only for newly created VM snapshots.
Virtual Network. VNet now includes state (
STATE), this is automatically managed by the upgrade process. However if you have any custom integration that create a network and afterwards create VMs in the network you may need some synchronization (state
READY), even for dummy creation/delete actions. . When a network operation
onevnet deletefails the VN state will end in
ERROR, a description of the error will be added to the VNET template in an
There are four new states in services. Now after
PENDING the service goes to
DEPLOYING_NETS and after
UNDEPLOYING the service goes to
Cgroups version is obtained by the monitor probes. The
sharesassigned to each VM is computed based on this version and the
CPUparameter. If you are using cgroups version 2 hosts, after you upgrade the new VMs will use a base priority of
100. This may lead to inconsistent resource distribution between new and old VMs, it is recommend to reboot existing VMs to use the new values.
Now by default, the KVM driver executes multiple actions per host.
Distributed Edge Provisioning¶
The following providers has been disabled by default:
Vultr (Metal & virtual)
If you want to use them, please check their specific documentation section.
This version introduces a change in the deploy ID used to identify vCenter VMs. Its purpose is to avoid the collision of the Managed Object References in different vCenter instances, since their uniqueness is not guaranteed. Due to its sensitivity, we recommend first backing up the database and configuration files so you can restore your previous version if needed.
Debian front-ends are no longer certified over VMware. We advise OpenNebula users managing vCenter-based infrastructures with Debian front-ends to switch to any of the other supported platforms.
OpenNebula now creates and deletes Virtual Networks in vCenter using the new OpenNebula networking drivers, the previous hooks for vnet creation/deletion will be automatically deregistered by the migrators.