# Understanding how database interacts **URL:** \ **Category:** Product Support\ **Created:** [December 21, 2016, 3:58pm UTC](https://forum.opennebula.io/t/understanding-how-database-interacts/3470 "2016-12-21T15:58:14Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![mcabrerizo](https://yyz1.discourse-cdn.com/flex031/user_avatar/forum.opennebula.io/mcabrerizo/32/4829_2.png) [@mcabrerizo](https://forum.opennebula.io/u/mcabrerizo)\ **Post date:** [December 22, 2016, 5:00pm UTC](https://forum.opennebula.io/t/understanding-how-database-interacts/3470/6 "2016-12-22T17:00:33Z")
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](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](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](http://docs.opennebula.org/5.2/advanced_components/ha/frontend_ha_setup.html) 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: - [Running opennebula as VM](https://forum.opennebula.io/t/running-opennebula-as-vm/975) - [Running opennebula as VM and import it afterwards in itself - #9 by gandalf](https://forum.opennebula.io/t/running-opennebula-as-vm-and-import-it-afterwards-in-itself/1057/9) I hope I’ve answered most of your questions. Cheers! --- _[View the full topic](https://forum.opennebula.io/t/understanding-how-database-interacts/3470)._