Understanding how database interacts


In my environment I have installed a single opennebula host which coms with its sqlite database. Afterwards, I have deployed a centos7 virtual machine “vdicdb01” (using onevm command) where I have deployed a MariaDB server.

Now I’d like to deploy a new Centos7 virtual machine “vdicsunstone01” (again using onevm command) to deploy sunstone on it connected to the mariadb virtual machine “vdicdb01”.

  • physical host: vdicone01
  • mariadb vm: vdicdb01
  • susntone vm: vdicsusntone01

I’d like to understand how sqlliste database placed on physical host vdicone01 interacts with the new mariadb database installed on vdicdb01.

Thanks a lot for your clarifications!


The short answer is there is no interaction between the databases in such setup.

Please excuse me if I am not understanding your descriptions. You have one front-end installed on the physical host, which is connected to local sqlite3 database and you are using CLI there.

Here is what is not clear for me : You have a VM dedicated for the sunstone only or there is also a second front-end running to which the sunstone is connected?

I’d start with reading OpenNebula’s overview and then the ‘Cloud Architecture Design Guides’ mentioned there to get familiar with the building components and their interactions.

Kind Regards,
Anton Todorov


In my physical machine I just have node software installed (no sunstone) and I launch commands against opennebula through cli (onevm, onedatastore, etc…).

What I want is to “virtualize” sunstone and “mariadb” on opennebula hypervisor as two separate virtual machines. I want to do the same what vmware does with their virtual center appliance.

The simple question is, as the sqllite database of node still have information about infraestructure.

¿How can I manage the whole infraestructure from the new sunstone?
¿The new sunstone, will be able to manage the currently running physical node?
¿Why the node has a sqlite database?

Thanks a lot.

Just follow the Sunstone Setup guide

Yes. it is just a fancy GUI alternative to the CLI tools.

Quote from the OpenNebula’s installation guide:

… Note that by default it uses a SQLite database that is not recommended for production so, if this is not a small proof of concept, while following the Installation section, you should enable MySQL.

Hope this helps,
Anton Todorov

Yes, the sunstione setup guide assumes it is the first machine in the infraestructure. That means, in this guide is assumed first is deployed sunstone and afterwards you begin adding node hosts to the sunstone.

In my case, I have a physical host running (with its sqlite installed --> opennebula server seems to install a default sqllite service on it), later I want to deploy the sunstone and configure sunstone to manage the phisical host.

¿Why the node has a sqlite database?
Quote from the OpenNebula’s installation guide2:
–> This link does not answer my question "Why"
In the node installation there is no reference to sqlite:

Therefore, I’m not able to understand how sunstone mariadb database and the host sqlite database interacts between them or may I to migrate sqllite to the new and virtual mariadb server?

If I have to connect node to the virtual mariadb database, I will have a problem because mariadb database server is virtualized on the opennebula hypervisor.

Thanks a lot

Hi oscar!
let’s see if I can answer some of your questions.

Why the node has a sqlite database? In the node installation there is no reference to sqlite

OpenNebula architecture requires that you have a front-end where the the oned daemon and the mm_sched scheduler are running. The oned core daemon requires a database backend which, as Anton pointed, is sqlite by default though you should use a MySQL database server in production. You can edit the /etc/one/oned.conf and have a look at the DB = [ BACKEND = “sqlite” ] configuration section.

The OpenNebula server starts an XML-RPC server which listens by default on port 2633 and acts as the OpenNebula’s API.

OpenNebula’s CLI commands uses that API, that XML-RPC server to execute commands, that’s why you have a --endpoint argument to select what opennebula server you want to run commands against. By default your CLI commands try to connect to localhost:2633 assuming that you have the server in the same machine, but you can connect to remote opennebula servers/endpoints.

OpenNebula’s Sunstone is just a User Interface that runs by default as a ruby web application under a Sinatra server and that can be installed behind a reverse proxy or on a web app server like NGINX+Passenger… but in the end, Sunstone also uses the XML-RPC server that’s why you have the :one_xmlrpc: http://localhost:2633/RPC2 configuration in the /etc/one/sunstone-server.conf.

The scheduler also needs to connect to the XML-RPC server.

So it doesn’t matter if you use a CLI or Suntone, the database is only needed by the front-end where the oned service runs.

From the front-end you can manage nodes e.g KVM nodes, but those nodes don’t have a database, they don’t need one because they only execute the commands that are sent from the front-end. Those commands are run using SSH that’s why the oneadmin user account requires passwordless SSH access to nodes.

So let’s review your configuration.

  • Your physical host is a front-end as you are using your commands against it, that’s why you have a sqlite database.
  • Your physical host also is acting as a node as you’re running VMs on them using KVM/libvirt: a mariadb vm and a sunstone vm. But the sqlite database is there because your physical host runs as a front-end.

The new sunstone, will be able to manage the currently running physical node?

  • Yes, your sunstone vm could manage the whole infrastructure… you have to specify the :one_xmlrpc: http://x.x.x.x:2633/RPC2 configuration in the /etc/one/sunstone-server.conf so Sunstone can connect to the XML-RPC server that is running on your physical node… but …

Therefore, I’m not able to understand how sunstone mariadb database and the host sqlite database interacts between them

As you can see Sunstone doesn’t require a database, it’s the oned core daemon which requires one backend

may I to migrate sqllite to the new and virtual mariadb server?

You can migrate an OpenNebula’s sqlite database to a MariaDB server, there are scripts for that…

…the real problem is that you are configuring a setup where OpenNebula’s database is served by a VM managed by OpenNebula itself. What would happen if your physical host where the oned service is running is restarted? your oned would try to connect to a database server that is not available as it must be started from opennebula which cannot run as no database is present… Maybe I’m wrong but AFAIK that would be a problem.

So does that mean that you cannot use VMs to run the front-end or databases? of course you can! In the Front-end HA setup guide you can find the following:

In this guide we assume that the DB backing OpenNebula core state is also configured in an HA mode. The database service should be configured as master-master setup running in the frontend Virtual Machines (very easy to setup and recommended),

As you see you can use VM to run front-ends and/or databases… but those VMs IMHO they should not be managed itself by opennebula… you could use virsh, virt-manager, pacemaker with libvirt… to manage those VMs. Here are interesting discussions about running opennebula as virtual machines that can give you guidance:

I hope I’ve answered most of your questions.