Upgrading from Previous Versions 3.4
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.4 .
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.
It is highly recommended not to keep your current oned.conf
, and update the oned.conf
file shipped with OpenNebula 3.4 to your setup. If for any reason you plan to preserve your current oned.conf
file, note that:
IMAGE_MAD
is no longer needed. You have to include DATASTORE_MAD
, cheek the datastore driver section of oned.conf.VM_DIR
is no longer supported. You may find useful the description of DARTASTORE_LOCATION.TM_MAD
has been improved in 3.4, now just one TM_MAD driver is needed that includes all the storage plugins.RESTRICTED_ATTR
, you can now define which template attributes can only be used by oneadmin group.Check the complete oned.conf reference for 3.2 and 3.4 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 --sqlite /var/lib/one/one.db Version read: 3.2.1 : OpenNebula 3.2.1 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.2.1_to_3.3.0.rb > Done > Running migrator /usr/lib/one/ruby/onedb/3.3.0_to_3.3.80.rb > Done Database migrated from 3.2.1 to 3.3.80 (OpenNebula 3.3.80) by onedb command. </xterm>
There is an important infrastructure change in the OpenNebula installation from version 3.2 to 3.4. The 3.2 Image Repository has been replaced with the new Datastores in 3.4. During the upgrade process onedb will change each existing Image's SOURCE.
This is how a 3.2 Image Repository looks like:
<xterm> $ oneimage list
ID USER GROUP NAME SIZE TYPE REGTIME PER STAT RVMS 0 oneadmin oneadmin 50_mkfs 50M DB 03/27 15:46:24 No rdy 0 2 oneadmin oneadmin test_img 50M OS 03/27 15:50:19 No rdy 0
$ oneimage show 2 IMAGE 2 INFORMATION ID : 2 NAME : test_img […] SOURCE : /var/lib/one/images/dc9888856dbff7c7b83751ef60652f41
$ tree /var/lib/one/images/ /var/lib/one/images/
`– dc9888856dbff7c7b83751ef60652f41 </xterm>
After the upgrade process, all Images will be registered in the default Datastore. The Datastore directory is /var/lib/one/datastores/1
, and that is where new Images will be copied to.
You will find the SOURCE attribute for 3.2 Images updated. The files are not moved though, only linked. This is how the system looks like after an upgrade to 3.4:
<xterm> $ tree /var/lib/one/datastores/ /var/lib/one/datastores/
`– 1
|-- d0c99363008498ffa18e129b660d74a5 -> /var/lib/one/images/d0c99363008498ffa18e129b660d74a5 `-- dc9888856dbff7c7b83751ef60652f41 -> /var/lib/one/images/dc9888856dbff7c7b83751ef60652f41
$ onedatastore list
ID NAME CLUSTER IMAGES TYPE TM 0 system - 0 - shared 1 default - 2 fs shared
$ oneimage show 2 IMAGE 2 INFORMATION ID : 2 NAME : test_img […] DATASTORE : default SOURCE : /var/lib/one/datastores/1/dc9888856dbff7c7b83751ef60652f41 </xterm>
You must manually move all the image files to their final destination in /var/lib/one/datastores/1
. Otherwise, the deployments will likely succeed, but you will have problems when the images are deleted, since only the symbolic link and not the actual file will be removed.
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:
@
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>