• The command onedb in previous versions read the connection parameters from oned.conf. Now these parameters have to be supplied with the command line options. E.g. “onedb version -v –sqlite /var/lib/one/one.db”.
• The scheduler now has a configuration file, /etc/one/sched.conf. Use the new sched.conf interface to globally define policies for the VMs. Oneadmin group can use custom policies (RANKs) on a VM-basis.
• The networking hooks have been redesigned as Host drivers. This new set of drivers allows Virtual Network isolation. Administrators can manage which Virtual Networks must be isolated with the new VLAN attribute. Read more in the Networking Subsystem documentation.
• The ACL rules now have a smaller set of operations: USE, MANAGE, ADMIN and CREATE.
• VMware drivers fully integrated
  • /etc/one/vmwarerc is in yaml format
  • No need to setup sudo permission for oneadmin
  • Support for vMotion and CONTEXT

• Users have a new attribute, AUTH_DRIVER. It can be changed with the new oneuser chauth command.
• The character ':' is now allowed in passwords
• oned.conf has a new attribute, SESSION_EXPIRATION_TIME: Time in seconds to keep an authenticated token as valid. It is used to avoid calling the authentication drivers for each call.
• There is a new administrative OpenNebula user, named 'serveradmin'. It is created by the core at bootstrap, or by the onedb upgrade command. This user is used by the Sunstone, OCCI and EC2 servers to interact with OpenNebula. You will also find three new configuration files in /var/lib/one/.one/. For more information, read the External Auth. and Cloud Services Authentication documentation.
• Users now have a TEMPLATE to hold any arbitrary data. This User metadata can be used in the CONTEXT section of VMs, see the User management documentation for more information.
• Users with 'public' driver

• There are new permissions associated to each resources of type VM, NET, IMAGE or TEMPLATE. These permissions allow the same rights as the ACL rules: USE, MANAGE, ADMIN for the owner, group, and others. These permissions can be updated with the new chmod command.
• Sharing with others is enabled by default. You can restrict your users to be able to set only permissions for the owner and group using the new oned.conf attribute, ENABLE_OTHER_PERMISSIONS.
• There are restricted attributes for Virtual Machines, available only for users in the 'oneadmin' group:
  • CONTEXT/FILES
  • DISK/SOURCE
  • NIC/MAC
  • NIC/VLAN_ID
  • RANK
• There is a new reboot action for Virtual Machines.
• You can now set a list of restricted and safe directories to use as the SOURCE path of new Images. Read more in the Image Repository configuration.
• The name of resources has been limited to a maximum of 128 characters.
• Users can reference Images and Networks by name in VM templates. This is the syntax to use:

# use image with ID 23
DISK = [ IMAGE_ID     = 23 ]
 
# use the Image named ubuntu, owned by the user named oneadmin.
DISK = [ IMAGE        = "Ubuntu",
         IMAGE_UNAME  = "oneadmin" ]
 
# use the ubuntu Image owned by user with ID 7.
DISK = [ IMAGE        = "Ubuntu",
         IMAGE_UID    = 7 ]
 
# use the ubuntu Image owned by the user instantiating the VM.
DISK = [ IMAGE        = "Ubuntu" ]

• Leases of Virtual Networks can be put “on hold”, temporarily setting them as “used” by no particular VM. Read more about the onevnet hold/release commands here.
• The RANGED type Virtual Networks can be defined in a more flexible way. The definition files for OpenNebula 3.0 are compatible. For example, CIDR notation is supported:

NETWORK_ADDRESS = 192.168.30.0/28

• The PUBLIC flag is no longer used. Instead, objects have owner,group and other permissions, which can be updated with the chmod command. A small example:

<xterm> $ onetemplate show 8 TEMPLATE 8 INFORMATION […]

PERMISSIONS OWNER : um- GROUP : — OTHER : —

$ onetemplate chmod 8 640

$ onetemplate show 8 TEMPLATE 8 INFORMATION […]

PERMISSIONS OWNER : um- GROUP : u– OTHER : — </xterm>

• There are new CLI commands:
  • oneimage chtype
  • oneuser update
  • oneuser chauth
  • onevnet update
  • onevnet hold/release
  • onetemplate/oneimage/onevnet/onevm chmod
  • onevm reboot
• You can now use the –type option in the onevm saveas command
• publish/unpublish commands for oneimage, onevnet and onetemplate are deprecated. Although functional, users are advise to move to the new permission system. Note that publish is equivalent to grant USE permissions to the group.

• The occi server network configuration is done in a separate configuration file. The file occi-server.conf has some new configuration options for the new OpenNebula Self-Service portal.
• All the cloud services, Sunstone, OCCI, Self-Service portal and EC2, now list by default all the resources that the logged-in user has USE rights. In OpenNebula 3.0, only the resources in their group were retrieved. This means that users can list and use resources prepared by an administrator and shared with the new permissions or ACL rules.
• User access can be restricted to public servers with the public driver .

• The following xml-rpc methods have been modified:
  • one.user.allocate requires a new String parameter, the authentication driver.
  • one.vm.savedisk requires a new String parameter, the Image type.
  • one.vm.action now accepts a new action, reboot.
  • one.host.allocate requires a new String parameter, the networking driver.
  • one.acl.allocate
• New xml-rpc methods:
  • one.user.chauth
  • one.user.update
  • one.image.chtype
  • one.vn.update
  • one.vn.hold
  • one.vn.release
  • one.template/image/net/vm.chmod
• Deleted xml-rpc methods:
  • one.*.publish
• In previous versions, XML-RPC clients had to hash the password read from the ONE_AUTH file. OpenNebula 3.2 expects the contents of the auth. file untouched. This is only relevant to people using the XML-RPC interface directly, applications using the Ruby or Java OCA don't require any change. This also applies to the one.user.passwd method, it now expects the original password instead of the sha1 hash.
• Users with an authentication driver named 'server*', like the default serveradmin user, must use a special authentication token.
• Users with 'public' driver