Compatibility Guide 3.0

This guide is aimed at OpenNebula 2.0 or 2.2 users and administrators who want to upgrade to the latest 3.0 version. The following sections summarize the new features and usage changes that should be taken into account, or prone to cause confusion.

OpenNebula Administrators

  • If you upgrade OpenNebula form a 2.x version, it won't start until you upgrade also the existing DB. Make sure to follow the Upgrading from Previous Versions guide.
  • The columns format for one* list commands can be customized by editing the /etc/one/cli/* files. You can change the size and name of the columns and define the columns to be shown in the default section. You can also copy this set of files to your home directory ($HOME/.one/cli) if you want to customize them individually for each user.
  • The default filter flag for one* list commands is group. Administrators should take this into account and use one* list a instead to monitor all the existing resources.
  • You should familiarize yourself with the new Groups and ACL authorization features to manage how much access to your cloud your users have. By default, Users have similar permissions as in previous 2.x versions.
  • OpenNebula Users have some new functionality reserved before only for oneadmin: any user can now see his own information, and change his password.
  • Clusters don't exist anymore. Because clusters were basically a tagging system for Hosts, this functionality is extended by the possibility to store any arbitrary data in the Host templates, by using the onehost update command. Existing cluster names are added to the previously assigned Hosts' templates by the onedb command, so your existing placement REQUIREMENTS in VM templates will keep working as expected.
  • The Transfer Manager driver tm_nfs has been renamed to tm_shared. The onedb upgrade process will rename the transfer driver of your existing hosts, but pay attention to this if you create new hosts.
  • If you expose the EC2 interface, please make sure to read the new EC2 Service Configuration guide and take into account the following changes:
    • In the small.erb file, the Network is defined by ID instead of name; i.e. NETWORK_ID = <id> instead of NETWORK = <name>.
    • The Network must belong to the same Group as the users, and must be public.
    • The EC2_ACCESS_KEY and EC2_SECRET_KEY environment variables and CLI parameters now refer to the OpenNebula hashed password instead of the plain one. This way it follows the same model used in the rest of the EC2 tools (ec2-*, euca-*). The ONE_AUTH file still keeps the user:password format for the econe tools.

OpenNebula Users

There are two main differences in the way that users interact with OpenNebula:

1. New Template Resources

VM Templates now have to be registered and then instantiated. If you had a VM template file, say my_vm.one, this how you created a VM from it in 2.x:

<xterm> $ onevm create my_vm.one </xterm>

And this is how it is done in OpenNebula 3.0: <xterm> $ onetemplate create my_vm.one ID: 0

$ onetemplate instantiate 0 VM ID: 1

$ onevm show 1 </xterm>

Think of the new Templates as the VM definitions available in OpenNebula, and the objects shown in onevm as the instances of those Templates.

2. Use IDs instead of Names

Resources have to be referenced by its ID in VM Templates. The following VM Template, valid for 2.x versions, will return an error:

<xterm> $ cat old.vm NAME = my_vm DISK = [ IMAGE = img_one ]

$ onetemplate create old.vm ID: 1

$ onetemplate instantiate 1 [TemplateInstantiate] Error allocating a new virtual machine. IMAGE is not supported for DISK. Use IMAGE_ID instead. </xterm>

Instead, you must use the IMAGE_ID and NETWORK_ID in your Templates:

<xterm> $ cat new.vm NAME = my_vm DISK = [ IMAGE_ID = 0 ]

$ onetemplate create new.vm ID: 2

$ onetemplate instantiate 2 VM ID: 2 </xterm>

:!: Note that you can still continue using the resource names in the CLI, e.g. 'oneimage show img_one' or 'onevm shutdown my_vm'.

The following list describes other features and different commands usage that you should be aware of:

  • When a resource is created, the ID is returned even without the –verbose (-v) option.
  • You can customize the columns format for 'one* list' commands, see the above section.
  • The range format for operations that allow multiple resource IDs is now in the form '1,3,8..11'.
  • Options have to be defined after the sub-command:
    • WRONG: $ onevm -x list
    • RIGHT: $ onevm list -x
  • The default filter flag for 'one* list' commands is group, which shows resources in your group. Use 'one* list m' to see only yours.
  • The public flag for resources has a new scope: public resources can be seen and used by other users in your group, but they are unreachable for other users in the system.
  • You can use 'oneuser show' to find out your user ID.
  • VMware users won't no longer have to use the 'onevmware' command to register images. Instead, the normal 'oneimage' command can handle VMware disks in OpenNebula 3.0.

Developers and Integrators

  • OpenNebula uses a completely new DB schema that stores objects in XML. If your application had direct access to the DB, you may be interested in the Database Schema for Accounting & Monitoring guide.
  • Developers using the Ruby or Java OCA should check the updated documentation. Not only new classes have been added for the new functionality (Templates, ACL, Groups, etc); but also some of the existing methods use different arguments.
  • If you use the XML-RPC API directly, then check the differences between the 2.2 and 3.0 XML-RPC API documentation. There are new methods, as well as some changes in the number of required arguments for some of the methods.
  • The authentication token is the same as in previous versions: “user:password”. The core expects the string “user:sha1(password)”. But if you activate the external Authentication drivers, then the authentication token generated with the oneuser login command looks like “user:protocol:password”. In this case, the unmodified token must be sent in the xml-rpc call. This can be better understood in the ruby OCA Client class.
  • Until OpenNebula 2.2, the file copy or creation for Image allocation had to be performed by the oneimage command or the client application. Since 3.0, the file management is done entirely by the OpenNebula core. Take a look at the Image Manager Driver documentation for more info.
  • The XML objects returned by OpenNebula have changed to accommodate the new features. Download the XML Schemas (XSD) for 2.2 and 3.0 versions to compare them (3.0 XSD will be available soon).