OpenNebula doesn't need to install any additional software in the nodes. It just needs to have access passwordlessly via ssh using the <oneadmin> account.

Check that the $ONE_AUTH environment variable points to a file containing just one line, with your username and password separated by a colon.

$ cat ~/.one/one_auth oneadmin:opennebula

Also, OpenNebula commands should be run as the unix oneadmin user. Running OpenNebula as root is not recommended and has been reported to be the source of this type of problem.

Absolutely not! OpenNebula should run under the <oneadmin> account.

Probably the OpenNebula daemon is not running. You should start it using the following command:

$ one start

If the daemon is running check that the ONE_XMLRPC environment variable is correctly set.

There are several reasons for this, check:

• You have created a network with a valid bridge in the nodes of your cluster
• You have defined a NIC attribute in your VM attached to that network
• The VM is prepared to configure the interface to use a valid IP in that network. You can:
  • Configure the VM to dynamically configure the IP using its MAC address (Contextualzation)
  • Configure the VM to statically set a given IP of the network
  • Put a DHCP server attached to that network
• Also be sure that you are pinging the VM from a host with a route to the network

You may find useful the networking tutorial.

If you delete/cancel a running VM, it is assumed that you do not want to keep the VM, or that somehow it failed and needed a forced deletion. That's why the images are saved back only after a graceful shutdown.

The VM_DIR is only needed if the $ONE_LOCATION/var mountpoint shared in the front-end is different from the mountpoint in the nodes. If both locations share the same path, the VM_DIR is not needed, try uncommenting it, restarting OpenNebula and launching the VM again. One corollary and golden rule: never set VM_DIR to the same path as $ONE_LOCATION/var.

OpenNebula keeping the VMs in pending is due to the scheduler not finding available capacity in the hosts to perform the deploy. You should check:

• The hosts shown in “onehost list” are correctly monitorized (ie they are not in error state)
• The VM requirements in terms of CPU and MEMORY can be satisfied with the existing hosts. If not, try shutting down some VMs
• The VM template REQUIREMENTS section may contain an expressin impossible to satisfy with the infrastructure.

There is a compatibility problem with last versions of sinatra and rack using ruby 1.8.7.

You can fix this issue in two ways:

• Upgrading ruby to 1.9
• Downgrading rack version to 1.2.0:

<xterm> # gem uninstall rack Select gem to uninstall: 1. rack-1.0.0 2. rack-1.0.1 3. rack-1.2.1 4. All versions

4

# gem install rack –version '1.2.0' Successfully installed rack-1.2.0 1 gem installed </xterm>

No, all resources (e.g. Hosts, Virtual Networks, Virtual Machines) are stored in the DB. The running VMs monitoring will be resumed as if nothing happened.

There are several reasons why the Sunstone server may not work, or may not be reachable. Therefore it is good to check a few things:

• The server starts properly: after sunstone-server start check $ONE_LOCATION/var/sunstone.log (self-contained) or var/log/one/sunstone.log (system-wide) for any messages. One common cause for exceptions at start-up is missing ruby gems. Check the list of dependencies here.

• Ubuntu issue: If you are using an Ubuntu distribution be aware that the gems bin/ folder is not included in the PATH variable by default. This usually means a Command rackup not found when running sunstone-server start. To fix it please add the folder to the current PATH (change ruby version accordingly to your needs):

<xterm>export PATH=“/var/lib/gems/1.8/bin”:$PATH</xterm>

• Rack and Sinatra issue: There have been reports of Ruby 1.8.7 + Sinatra + rack 1.2.1/1.2.2 throwing can't convert Array into String (TypeError) exceptions. If encountered, solutions are downgrading rack to 1.2.0 or upgrading Ruby to 1.9.x.

• The server is reachable: if you are trying to reach the server from somewhere other than localhost, you need to specify the IP address on which to listen for connections with the -H option: sunstone-server -H 0.0.0.0 start should make the server reachable from everywhere.

• Firewalls in the way: Sunstone server runs by default on port 4567. Note it may be blocked by a firewall, and therefore not reachable. You can change the default listen port with the -p option.

• Browser compatible?: Sunstone supports Firefox >= 3.5 and Chrome. Using other browsers may simply not work.

That should get you to the login screen at least. Remember that you need a working installation of OpenNebula running (one start) and user credentials to go pass that point.

This is not the default behaviour of Sunstone, as (of version 2.2) it is intended to be just a replacement for the CLI. However, there is a way. Just change user_flag to -1 in line 69 of the SunstoneServer.rb file:

SunstoneServer.rb:69
68:    def get_pool(kind)
69:        user_flag = -2 <----HERE
70:        pool = case kind

If the scheduler does not deploy the pending VMs, and messages like these are found in sched.log

[HOST][E]: Exception raised: Unable to transport XML to server and
get XML response back.  HTTP response code is 404, not 200
[POOL][E]: Could not retrieve pool info from ONE

Then you need to unset the http_proxy environment variable, or set the no_proxy accordingly.

OpenNebula assumes the complete control of the infrastructure and the VMs. If you had previous VMs in your hypervisor, OpenNebula won't try to detect or import them.