Please feel free to add and/or update questions in the following list. This is a collaborative effort between all the members of the community, please share your experiences installing, configuring and using OpenNebula.
Currently answered questions:
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 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:
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:
# 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
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:
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.
bin/folder is not included in the PATH variable by default. This usually means a
Command rackup not foundwhen running
sunstone-server start. To fix it please add the folder to the current PATH (change ruby version accordingly to your needs):
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.
localhost, you need to specify the IP address on which to listen for connections with the
sunstone-server -H 0.0.0.0 startshould make the server reachable from everywhere.
4567. Note it may be blocked by a firewall, and therefore not reachable. You can change the default listen port with the
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
-1 in line 69 of the
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
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.
Please check the VNC troubleshooting section of the Sunstone documentation.
Command line interface gets information from OpenNebula sing XML. The default XML library that comes with ruby is a bit slow and while it is ok for small installations it can be a big overhead with a certain amount of VMs are registered. To speedup your installation you need to install
nokogiri gem. This can be done with one of this options:
sudo gem install nokogiri
After the installation of this library OpenNebula will automatically use of it.