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 (runn, suspended, stopped, done). Check the Managing Virtual Machines guide for more information on the VM life-cycle.

Stop OpenNebula and any other related services you may have running: EC2, OCCI, and Sunstone.

<xterm> $ sunstone-server stop $ econe-server stop $ occi-server stop $ one stop </xterm>

Backup the configuration files located in /etc/one. You don't need to do a manual backup of your database, the onedb command will perform one automatically.

Follow the Installation guide, taking into account that you will already have configured the passwordless ssh access for oneadmin.

In case of conflict, merge the configuration files. You will have new attributes and additional parameters for drivers, check the oned.conf reference for 3.0 and 3.2 versions.

If you are upgrading from OpenNebula 2.X, read the 3.0 upgrade guide for specific notes.

The database schema and contents are incompatible between versions. The OpenNebula daemon checks the existing DB version, and will fail to start if the version found is not the one expected, with the message 'Database version mismatch'.

You can upgrade the existing DB with the 'onedb' command. You can specify any Sqlite or MySQL database. Check the man page for more information.

After you install the latest OpenNebula, and fix any possible conflicts in oned.conf, you can issue the 'onedb upgrade -v' command. In previous versions onedb read the connection parameters from oned.conf. Now these parameters have to be supplied with the command line options, see the onedb manpage for more information. Some examples:

<xterm> $ onedb upgrade -v –sqlite /var/lib/one/one.db </xterm>

<xterm> $ onedb upgrade -v -S localhost -u oneadmin -p oneadmin -d opennebula </xterm>

Some clarifications about the upgrade process:

• Driver name (x509, ssh, ldap): In OpenNebula 3.2 users have a new AUTH_DRIVER attribute. If you didn't configure the AUTH_MAD attribute in your 3.0 oned.conf you can just press enter to use the default user-password authentication for all users.
• New user 'serveradmin' created…: This new system user is required by the Sunstone, OCCI and EC2 servers to interact with OpenNebula. You will also find three new configuration files in /var/lib/one/.one/ with the credentials for this system user. For most installations, this will be ready to work without further configuration. You should be concerned only if you had enabled x509 access to your 3.0 Sunstone. For more information, read the External Auth. and Cloud Services Authentication documentation.
• Driver name (802.1Q, dummy, ebtables, ovswitch): The networking isolation hooks for OpenNebula 3.0 have been redesigned as Host drivers, and a new VN_MAD attribute has to be added to each Host. Read more about this feature in the Networking Subsystem documentation. If you are unsure about this, just press enter to use the default dummy networking driver for all hosts.

If everything goes well, you should get an output similar to this one:

<xterm> $ onedb upgrade -v --sqlite /var/lib/one/one.db Version read: 3.0.0 : OpenNebula 3.0.0 daemon bootstrap Sqlite database backup stored in /var/lib/one/one.db.bck Use 'onedb restore' or copy the file back to restore the DB. > Running migrator /usr/lib/one/ruby/onedb/3.0.0_to_3.1.0.rb > Users need to have an authentication driver defined. If you have AUTH_MAD uncommented in oned.conf, enter the driver name, or press enter to use the default value. Driver name (x509, ssh, ldap): > New user 'serveradmin' created for Sunstone and public servers operation. You have three new authentication files in /var/lib/one/.one. For more information, visit http://opennebula.org/documentation:rel3.2:upgrade > Done > Running migrator /usr/lib/one/ruby/onedb/3.1.0_to_3.1.80.rb > Networking isolation hooks have been moved to Host drivers. If you were using a networking hook, enter its name, or press enter to use the default dummy vn_mad driver. Driver name (802.1Q, dummy, ebtables, ovswitch): > Done Database migrated from 3.0.0 to 3.1.80 (OpenNebula 3.1.80) by onedb command. </xterm>

Make sure you keep the backup file. If you face any issues, the onedb command can restore this backup, but it won't downgrade databases to previous versions.

You should be able now to start OpenNebula as usual, running 'one start' as oneadmin. 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 a' commands. Try also using the show subcommand for some resources.

If for any reason you need to restore your previous OpenNebula, follow these steps:

• With OpenNebula 3.2 still installed, restore the DB backup using 'onedb restore -f'
• Uninstall OpenNebula 3.2, and install again your previous version.
• Copy back the backup of /etc/one you did to restore your configuration.

Although it is possible to have more than one authentication drivers in use, onedb assumes you have users with the internal plain password method, and at most one external driver.

You should check the new AUTH column of oneuser list and change the authentication driver with the oneuser chauth command.

If you get this error message: <xterm>

  > Trying to create user 'serveradmin' for Sunstone and public servers operation;
    but a user with that name already exists. You will need to create manually a new user...

</xterm>

It means that you already had a user with the serveradmin name. Without this system user, the Sunstone, OCCI and EC2 servers won't be able to interact with OpenNebula. You need to create this system user with the following commands:

<xterm> $ oneuser create new_user pass ID: 2

$ echo “new_user:pass” > /var/lib/one/.one/ec2_auth $ echo “new_user:pass” > /var/lib/one/.one/occi_auth $ echo “new_user:pass” > /var/lib/one/.one/sunstone_auth

$ chmod 600 /var/lib/one/.one/* </xterm>

Please note that 'serveradmin' is just a name for the special user, in the same way that 'oneadmin' is not really the user with that name, but rather the user with ID 0.

If the MySQL database password contains specials characters, such as @ or #, the onedb command will fail to connect to it.

The workaround is to temporarily change the oneadmin's password to an ASCII string. The set password statement can be used for this:

<xterm> $ mysql -u oneadmin -p

mysql> SET PASSWORD = PASSWORD('newpass'); </xterm>