Upgrading Single Front-End

If you are upgrading from a 7.0.x installation you only need to follow a reduced set of steps. If you are running a 6.10.x version or older, please check these set of steps (some additional ones may apply, please review them at the end of the section).

Upgrading from 7.0.x

This section describes the installation procedure for systems that are already running a 7.0.x OpenNebula. The upgrade to OpenNebula 7.0 can be done directly following this section, you don’t need to perform intermediate version upgrades. The upgrade will preserve all current users, hosts, resources and configurations.

When performing a minor upgrade OpenNebula adheres to the following convention to ease the process:

  • No changes are made to the configuration files, so no configuration file will be changed during the upgrade.
  • Database versions are preserved, so no upgrade of the database schema is needed.

When a critical bug requires an exception to the previous rules it will be explicitly noted in this guide.

Step 1. Stop OpenNebula Services

Before proceeding, make sure you don’t have any VMs in a transient state (prolog, migr, epil, save). Wait until these VMs get to a final state (run, suspended, stopped, done). Check the Managing Virtual Machines guide for more information on the VM life-cycle.

Now you are ready to stop OpenNebula and any other related services you may have running, e.g. Sunstone or OneFlow. It’s preferable to use the system tools, like systemctl or service as root in order to stop the services.

Step 2. Upgrade Front-end to the New Version

Upgrade the OpenNebula software using the package manager of your OS. Refer to the Single Front-end Installation guide for a complete list of the OpenNebula packages installed on your system. Package repos need to be pointing to the latest version (7.0).

For example, in CentOS/RHEL simply execute:

yum upgrade opennebula

For Debian/Ubuntu use:

apt-get update
apt-get install --only-upgrade opennebula

Step 3. Upgrade Hypervisors to the New Version

Upgrade the OpenNebula node KVM or LXC packages, using the package manager of your OS.

For example, in a rpm-based Linux distribution simply execute:

yum upgrade opennebula-node-kvm

For deb-based distros use:

apt-get update
apt-get install --only-upgrade opennebula-node-kvm

Step 4. Update the Drivers

You should now be able to start OpenNebula as usual, running service opennebula start as root. At this point, as oneadmin user, execute onehost sync to update the new drivers in the Hosts.

Testing

OpenNebula will continue the monitoring and management of your previous Hosts and VMs.

As a measure of caution, look for any error messages in oned.log, and check that all drivers are loaded successfully. After that, keep an eye on oned.log while you issue the onevm, onevnet, oneimage, oneuser, onehost list commands. Try also using the show subcommand for some resources.

Restoring the Previous Version

If for any reason you need to restore your previous OpenNebula, simply uninstall OpenNebula 7.0, and install again your previous version. After that, update the drivers if needed, as outlined in the Step 12 below.

Upgrading from 6.x and higher

Step 1. Check Virtual Machine Status

Before proceeding, make sure you don’t have any VMs in a transient state (prolog, migrate, epilog, save). Wait until these VMs get to a final state (running, suspended, stopped, done). (For more information on the life cycle of Virtual Machines, please see Virtual Machine Instances.)

Step 2. Set All Hosts to Disable Mode

Set all Hosts to disable mode to stop all monitoring processes.

onehost disable <host_id>

Step 3. Stop OpenNebula

Stop OpenNebula and any other related services you may have running: OneFlow, OneGate and FireEdge. To stop OpenNebula, it’s preferable to use the system tools, like systemctl or service running as user root. For example (note that opennebula-scheduler is no longer used in 7.0 or newer):

systemctl stop opennebula opennebula-flow.service opennebula-gate.service opennebula-hem.service opennebula-scheduler.service opennebula-fireedge.service

Then make sure every OpenNebula process is stopped. For example:

systemctl is-active opennebula opennebula-flow.service opennebula-gate.service opennebula-hem.service opennebula-scheduler.service opennebula-fireedge.service

Step 4. Back up OpenNebula Configuration

Back up the configuration files located in /etc/one and /var/lib/one/remotes/etc. You don’t need to do a manual backup of your database; the onedb command will perform one automatically.

cp -ra /etc/one /etc/one.$(date +'%Y-%m-%d')

cp -ra /var/lib/one/remotes/etc /var/lib/one/remotes/etc.$(date +'%Y-%m-%d')

onedb backup

Step 5. Upgrade OpenNebula Packages Repository

In order to be able to retrieve the packages for the latest version, you need to update the OpenNebula packages repository. The instructions for doing this are detailed here.

Step 6. Upgrade to the New Version

Ubuntu/Debian

apt-get update
apt-get install --only-upgrade opennebula opennebula-gate opennebula-flow opennebula-fireedge opennebula-migration python3-pyone

RHEL

yum upgrade opennebula opennebula-gate opennebula-flow opennebula-fireedge opennebula-migration python3-pyone

Step 7. Update Configuration Files

In High Availability (HA) setups, you must replace the default value auto of the MONITOR_ADDRESS parameter in /etc/one/monitord.conf with the virtual IP address used in the RAFT_LEADER_HOOK and RAFT_FOLLOWER_HOOK settings in /etc/one/oned.conf.

Before upgrading OpenNebula, ensure that the configuration state is clean, with no pending migrations from previous or outdated configurations. To verify this, run onecfg status. A clean state should produce output similar to:

$ onecfg status
--- Versions ------------------------------
OpenNebula:  7.0.0
Config:      6.10.0

--- Backup to Process ---------------------
Snapshot:    /var/lib/one/backups/config/2025-06-27_11:05:47-v6.10.0
(will be used as one-shot source for next update)

--- Available Configuration Updates -------
New config:  7.0.0
- from 6.10.0 to 6.10.2 (YAML, Ruby)
- from 6.10.2 to 7.0.0 (YAML, Ruby)

After confirming the configuration state, in most cases you can proceed with the following command, which uses OpenNebula’s internal version tracking to apply the appropriate configuration updates:

# onecfg upgrade
ANY   : Found backed up configuration to process!
ANY   : Snapshot to update from '/var/lib/one/backups/config/2025-06-27_11:05:47-v6.10.0'
ANY   : Backup stored in '/var/lib/one/backups/config/2025-06-27_11:39:36_30392'
ANY   : Configuration updated to 7.0.0

If you get conflicts when running the onecfg upgrade, refer to the onecfg upgrade basic usage documentation on how to upgrade and troubleshoot the configurations, in particular the onecfg upgrade doc and the Troubleshooting section.

Finally, check the configuration state via onecfg status. There should be no errors and no new updates available. Your configuration should be up to date for the currently installed OpenNebula version. For example:

--- Versions ------------------------------
OpenNebula:  7.0.0
Config:      7.0.0

--- Available Configuration Updates -------
No updates available.

Step 8. Upgrade the Database Version

Simply run the onedb upgrade -v command. The connection parameters are automatically retrieved from /etc/one/oned.conf. Example:

$ onedb upgrade -v
Version read:
Shared tables 6.10.0 : OpenNebula 6.10.0 (5d6b8571) daemon bootstrap
Local tables  6.10.0 : OpenNebula 6.10.0 (5d6b8571) daemon bootstrap

Sqlite database backup stored in /var/lib/one/one.db_2025-6-27_11:45:51.bck
Use 'onedb restore' to restore the DB.

>>> Running migrators for shared tables
  > Running migrator /usr/lib/one/ruby/onedb/shared/6.10.0_to_7.0.0.rb
  > Done in 0.00s

Database migrated from 6.10.0 to 7.0.0 (OpenNebula 7.0.0) by onedb command.

>>> Running migrators for local tables
  > Running migrator /usr/lib/one/ruby/onedb/local/6.10.0_to_7.0.0.rb
  > Done in 0.08s

Database migrated from 6.10.0 to 7.0.0 (OpenNebula 7.0.0) by onedb command.

Total time: 0.12s

Step 9. Check DB Consistency

First, move the 7.0 backup file created by the upgrade command to a safe place. If you face any issues the onedb command can restore this backup, but it won’t downgrade databases to previous versions. Then, execute the onedb fsck command:

$ onedb fsck
MySQL dump stored in /var/lib/one/mysql_localhost_opennebula.sql
Use 'onedb restore' or restore the DB using the mysql command:
mysql -u user -h server -P port db_name < backup_file

Total errors found: 0

Step 10. Start OpenNebula

Start OpenNebula and any other related services: OneFlow, OneGate and FireEdge. First reload the new systemd unit files:

systemctl daemon-reload

Then restart the services:

systemctl start opennebula opennebula-flow.service opennebula-gate.service opennebula-hem.service opennebula-fireedge.service

Step 11. Restore Custom Probes

If you have any custom monitoring probes, follow these instructions to update them to the new monitoring system

Step 12. Update the Hypervisors

Log in to your hypervisor Hosts and update the opennebula-node packages. NOTE: you may need to upgrade the software repository as described above.

Ubuntu/Debian

apt-get update
apt-get install --only-upgrade opennebula-node-<hypervisor>

RHEL

yum upgrade opennebula-node-<hypervisor>

Then update the virtualization, storage, and networking drivers. As the oneadmin user, execute:

onehost sync

Step 13. Enable Hosts

Enable all Hosts, disabled in step 2:

onehost enable <host_id>

If upgrading from a version earlier than 6.0, please see Upgrading from Previous Versions.

Testing

OpenNebula will continue the monitoring and management of your previous Hosts and VMs.

As a measure of caution, look for any error messages in oned.log, and check that all drivers are loaded successfully. You may also try some show subcommand for some resources to check everything is working (e.g., onehost show or onevm show).

Restoring the Previous Version

If for any reason you need to restore your previous OpenNebula, simply uninstall OpenNebula 7.0 and reinstall your previous version. After that, update the drivers if needed, as outlined in Step 12.