Upgrading from Previous Versions 3.6
This guide describes the installation procedure for systems that are already running a 2.x or 3.x OpenNebula. The upgrade will preserve all current users, hosts, resources and configurations; for both Sqlite and MySQL backends.
Read the Compatibility Guide and Relase Notes to know what is new in OpenNebula 3.6.
This guide is concerned with OpenNebula core mainly, but there is also a section for the oZones server DB.
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 $ oneacctd 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.
It is highly recommended not to keep your current oned.conf
, and update the oned.conf
file shipped with OpenNebula 3.6 to your setup. If for any reason you plan to preserve your current oned.conf
file, read the Compatibility Guide and the complete oned.conf reference for 3.4 and 3.6 versions.
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>
If everything goes well, you should get an output similar to this one:
<xterm> $ onedb upgrade -v -S localhost -u oneadmin -p oneadmin -d opennebula Version read: 3.4.1 : Database migrated from 3.2.0 to 3.4.1 (OpenNebula 3.4.1) by onedb command. 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 > Running migrator /usr/lib/one/ruby/onedb/3.4.1_to_3.5.80.rb > Done Database migrated from 3.4.1 to 3.5.80 (OpenNebula 3.5.80) by onedb command. </xterm>
Previous versions had an oneacctd
daemon that monitored the resources and stored data in a separate database to be viewed with the oneacct
command. This command has been revamped in 3.6, and does not require any external database. You can give it a try and get the accounting information of your infrastructure, even if you didn't use oneacctd
before:
<xterm> $ oneacct -s '05/01/2012' </xterm>
OpenNebula 3.6 also comes with integrated usage quotas. To manage the usage limits, OpenNebula keeps track of the resource consumption at all times. Try the oneuser
and onegroup
show commands with any user different from oneadmin.
<xterm> $ oneuser show 2 </xterm>
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 commands. Try also using the show subcommand for some resources.
If for any reason you need to restore your previous OpenNebula, follow these steps:
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>
The oZones server DB underwent a heavy change between 3.4 and 3.6 versions, changing the datamapper
ORM mechanism to sequel
. For this reason, the DB structure suffered slight changes, that can be corrected with the onezonedb
command:
OPTION | MEANING | VALUE | COMPULSORY |
---|---|---|---|
h | show help | none | no |
t | DB Type | mysql or sqlite | yes |
s | DB Server | FQDN of the mysql server | yes for mysql |
s | DB Username | Username of mysql user | yes for mysql |
p | DB Password | Password of mysql user | yes for mysql |
l | DB Path | Path to sqlite DB | yes for mysql |