OpenNebula Sunstone: The Cloud Operations Center 3.2
OpenNebula Sunstone is the OpenNebula Cloud Operations Center, a Graphical User Interface (GUI) intended for regular users and administrators that simplifies the typical management operations in private and hybrid cloud infrastructures. OpenNebula Sunstone allows to easily manage all OpenNebula resources and perform typical operations on them.
From OpenNebula 3.0, Sunstone can be adapted to different user roles. For example, it will only show the resources the users have access to. Its behaviour can be customized and extended via plugins.
You must have an OpenNebula site properly configured and running to use OpenNebula Sunstone, be sure to check the OpenNebula Installation and Configuration Guides to set up your private cloud first. This guide also assumes that you are familiar with the configuration and use of OpenNebula.
OpenNebula Sunstone was installed during the OpenNebula installation. If you followed the installation guide then you already have all ruby gem requirements. Otherwise, run the
install_gem script as root:
# /usr/share/one/install_gems sunstone
The Sunstone Operation Center offers the possibility of starting a VNC session to a Virtual Machine. This is done by using a VNC websocket-based client (noVNC) on the client side and a VNC proxy translating and redirecting the connections on the server-side.
It is quite straightforward to set up the VNC console, as the
install_novnc.sh script does most of the job. However, be aware that this feature is sustained over the following extra requirements:
noVNC: websocket-based VNC client. It includes a VNC proxy (see noVNC Installation).
Phyton >= 2.5: Required by the VNC proxy (included with noVNC). This proxy is used to connect the server to the hosts and make the translation between websockets and regular sockets. The proxy does not work with older versions of
Websockets-enabled browser(optional): Firefox and Chrome support websockets. In some versions of Firefox manual activation is required. If websockets are not enabled, flash emulation will be used.
OpenNebula Sunstone supports Firefox (> 3.5) and Chrome browsers. Internet Explorer, Opera and others are not supported and may not work well.
noVNC is not included by default within Sunstone, and its installation is completely optional. In order to install it, please run the
install_novnc.sh script. For system-wide installations:
$> cd /usr/share/one $> ./install_novnc.sh
The script will download and copy the noVNC files into the right place. It will also configure the Sunstone server accordingly. If you run into problems, you can checkout the related community FAQ question.
Sunstone configuration file can be found at
/etc/one/sunstone-server.conf. It uses YAML syntax to define some options:
Available options are:
|:one_xmlrpc:||OpenNebula daemon host and port|
|:host:||IP address on which the server will listen on.
|:port:||Port on which the server will listen.
|:auth:|| Authentication driver for incoming requests. Possible values are
|:core_auth:|| Authentication driver to communicate with OpenNebula core. Possible values are
|:vnc_proxy_base_port:||Local base port for the VNC proxy. The final port for the proxy is calculated adding the base port and the VNC port of the host.
|:novnc_path:||Path to the folder of noVNC. Set by the VNC installation script. Check vnc console for more details|
|:lang:||Default language for the Sunstone interface. This is the default language that will be used if user has not defined a variable LANG with a different valid value its user template|
localhostyou need to set the server's public IP in the
:host:option. Otherwise it will not be reachable from the outside.
:one_xmlrpcvariable in the configuration and to copy the
/var/lib/one/.one/sunstone_authfile with the right credentials from the frontend to the Sunstone server host.
From Sunstone 3.0, graphical monitoring information has been included in the dashboard and in the extended information of
virtual machines. In order to visualize the plots, it is necessary to run the
oneacctd daemon as oneadmin:
$ oneacctd start
oneacctdrequires additional setup and gems. Make sure you read the monitoring daemon documentation first.
To start Sunstone just issue the following command as oneadmin
$ sunstone-server start
You can find the Sunstone server log file in
To stop the Sunstone service:
$ sunstone-server stop
If you want to interact with Sunstone you have to open a new browser and go to the url where your Sunstone server is deployed. You will find the login screen where the username and password correspond to the OpenNebula credentials.
If you login as
oneadmin (user with uid=0), or any other user belonging to the
oneadmin group, you will have access to all resources and operations, including list and creation of users, groups, chown and chgrp operations. Regular users (belonging to the default group
users) have a limited view according to the default ACLs. Special groups and ACLs may require additional Plugins Configuration.
In order to use this feature, make sure that:
GRAPHICSsection defined, that the
TYPEattribute in it is set to
If the VM supports VNC and is
running, then the VNC icon on the Virtual Machines view should be enabled and clickable. Otherwise it just looks gray:
When clicking the VNC icon, the process of starting a session begins:
noVNCweb client in a dialog.
Flash. Websockets are supported from Firefox 4.0 (manual activation required in this version) and Chrome.
In order to close the VNC session just close the console dialog. The proxy will be then shutdown by Sunstone server.
Sunstone supports two authentication methods in order to log in. The method can be set in the sunstone-server.conf, as explained above. These two methods are:
In the basic mode, username and password are matched to those in OpenNebula's database in order to authorize the user at the time of login. Rack cookie-based sessions are then used to authenticate and authorize the requests.
To enable this login method, set the
:auth: option of
This method performs the login to OpenNebula based on a x509 certificate DN (Distinguished Name). The DN is extracted from the certificate and matched to the password value in the user database (remember, spaces are removed from DNs).
The user password has to be changed running one of the following commands
oneuser chauth new_user x509 "/C=ES/O=ONE/OU=DEV/CN=clouduser" oneuser chauth new_user --x509 --cert /tmp/my_cert.pemor create a new user:
oneuser create new_user "/C=ES/O=ONE/OU=DEV/CN=clouduser" --driver x509 oneuser create new_user --x509 --cert /tmp/my_cert.pem
To enable this login method, set the
:auth: option of
The login screen will not display the username and password fields anymore, as all information is fetched from the user certificate:
Note that OpenNebula will not verify that the user is holding a valid certificate at the time of login: this is expected to be done by the external container of the Sunstone server (normally Apache), whose job is to tell the user's browser that the site requires a user certificate and to check that the certificate is consistently signed by the chosen Certificate Authority (CA).
Users with 'public' driver
By default the Sunstone server is configured to run in the frontend, but you are able to install the Sunstone server in a machine different from the frontend.
# ./install.sh -s
|ONE_LOCATION||If OpenNebula was installed in self-contained mode, this variable must be set to <destination_folder>. Otherwise, in system wide mode, this variable must be unset. More info on installation modes can be found here|
|ONE_XMLRPC||The endpoint where the OpenNebula core is waiting for the XMLRPC requests|
/var/lib/one/.one/sunstone_auth. If you changed the serveradmin password please check the following section
$ cat /var/lib/one/.one/sunstone_auth serveradmin:1612b78a4843647a4b541346f678f9e1b43bbcf9
Using this setup the VirtualMachine logs will not be available. If you need to retrieve this information you must deploy the server in the frontend
OpenNebula Sunstone runs natively just on normal HTTP connections. If the extra security provided by SSL is needed, a proxy can be set up to handle the SSL connection that forwards the petition to the Sunstone server and takes back the answer to the client.
This set up needs:
If you want to try out the SSL setup easily, you can find in the following lines an example to set a self-signed certificate to be used by a lighttpd configured to act as an HTTP proxy to a correctly configured OpenNebula Sunstone.
Let's assume the server were the lighttpd proxy is going to be started is called
cloudserver.org. Therefore, the steps are:
We are going to generate a snakeoil certificate. If using an Ubuntu system follow the next steps (otherwise your milleage may vary, but not a lot):
$ sudo apt-get install ssl-cert
$ sudo /usr/sbin/make-ssl-cert generate-default-snakeoil
$ sudo cat /etc/ssl/private/ssl-cert-snakeoil.key /etc/ssl/certs/ssl-cert-snakeoil.pem > /etc/lighttpd/server.pem
You will need to edit the
/etc/lighttpd/lighttpd.conf configuration file and
server.port = 8443
#### proxy module ## read proxy.txt for more info proxy.server = ( "" => ("" => ( "host" => "127.0.0.1", "port" => 4567 ) ) ) #### SSL engine ssl.engine = "enable" ssl.pemfile = "/etc/lighttpd/server.pem"
The host must be the server hostname of the computer running the Sunstone server, and the port the one that the Sunstone Server is running on.
Start the Sunstone server using the default values, this way the server will be listening at localhost:4567
Once the lighttpd server is started, OpenNebula Sunstone requests using HTTPS URIs can be directed to
https://cloudserver.org:8443, that will then be unencrypted, passed to localhost, port 4567, satisfied (hopefully), encrypted again and then passed back to the client.