OpenNebula Sunstone: The Cloud Operations Center 3.4
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 $> sudo ./install_novnc.sh
The script will download and copy the noVNC files into the right place. It will also configure the Sunstone server accordingly. For self-conained installations, just run the script with
oneadmin making sure your
$ONE_LOCATION is defined. If you run into problems, you can checkout the related section down below.
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
|: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|
|:vnc_proxy_path||Full path to the websockets proxy file. Set by the VNC installation script. Check vnc console for more details|
|: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.
|:vnc_proxy_support_wss||“yes”, “no”, “only”. If enabled, the proxy will be set up with a certificate and a key to use secure websockets. If set to “only” the proxy will only accept encrypted connections, otherwise it will accept both encrypted or unencrypted ones.|
|:vnc_proxy_cert||Full path to certificate file for wss connections.|
|:vnc_proxy_key||Full path to key file. Not necessary if key is included in certificate.|
localhostyou need to set the server's public IP in the
:hostoption. Otherwise it will not be reachable from the outside.
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.
Sunstone users can configure several options from the configuration tab:
This options are saved in the user template. If not defined, defaults from
sunstone-server.conf are taken.
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.
There can be multiple reasons that may prevent noVNC from correctly connecting to the machines. Here's a checklist of common problems:
occi-server.confif using Self-Service) and see if the
websockifypath is set correctly (
sunstone.logwill record the proxy start command and any errors. You can use the command to fire the proxy manually and make tests.
GRAPHICSsection in the VM template enabling VNC, as stated in the documentation. Make sure the attribute
IPis set correctly (
0.0.0.0to allow connections from everywhere), otherwise, no connections will be allowed from the outside.
VNC_PROXY_BASE_PORT + VNC_PORT– to the
VNCport stated in the template. The value of the base port is defined in
occi-server.conffor Self-Service UI.
vncviewerto test if the VNC direct connection to the VM actually works.
https://sunstone.server.address:vnc_proxy_port. The browser will warn that the certificate is not secure and prompt you to manually trust it.
From Sunstone 3.4, image file upload to the server via the client browser is possible with the help of a vendor library. The process is as follow:
Note that when file sizes become big (normally over 1GB), and depending on your hardware, it may take long to complete the copying in step 3. Since the upload request needs to stay pending until copying is sucessful (so it can delete the temp file safely), there might be Ajax timeouts and/or lack of response from the server. This may cause errors, or trigger re-uploads (which reinitiate the loading progress bar). As of Firefox 11 and previous versions, uploads seem to be limited to 2GB. Chrome seems to work well with images > 4 GB.
Make sure that your ruby gems (Sinatra, thin, rack) are updated to their latest versions.
This applies to SelfService UI as well.
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
Using this method the credentials included in the header will be sent to the OpenNebula core and the authentication will be delegated to the OpenNebula auth system, using the specified driver for that user. Therefore any OpenNebula auth driver can be used through this method to authenticate the user (i.e: LDAP)
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).
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|
sunstone-server.confpoints to the right place where OpenNebula frontend is running, You can also leave it undefined and export
/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" => 9869 ) ) ) #### 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:9869
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 9869, satisfied (hopefully), encrypted again and then passed back to the client.