Local Storage Datastore

This storage configuration uses the local storage area of each Host to run VMs. Additionally you’ll need a storage area for the VM disk image repository. Disk images are transferred from the repository to the hosts using the SSH protocol.

Front-end Setup

The Front-end needs to prepare the storage area for:

  • Image Datastores, to store the image repository.

  • System Datastores, will hold temporary disks and files for VMs stopped and undeployed.

Simply make sure that there is enough space under /var/lib/one/datastores to store Images and the disks of the stopped and undeployed Virtual Machines. Note that /var/lib/one/datastores can be mounted from any NAS/SAN server in your network.

Host Setup

Just make sure that there is enough space under /var/lib/one/datastores to store the disks of running VMs on that Host.


Make sure all the Hosts, including the Front-end, can SSH to any other host (including themselves), otherwise migrations will not work.

OpenNebula Configuration

Once the Hosts and Front-end storage is setup, the OpenNebula configuration comprises the creation of an Image and System Datastores.

Create System Datastore

To create a new System Datastore, you need to set following (template) parameters:




Name of datastore





This can be done either in Sunstone or through the CLI; for example, to create a local System Datastore simply enter:

cat systemds.txt
NAME    = local_system
TM_MAD  = ssh
onedatastore create systemds.txt
ID: 101


When different System Datastores are available the TM_MAD_SYSTEM attribute will be set after picking the Datastore.

Create Image Datastore

To create a new Image Datastore, you need to set the following (template) parameters:




Name of datastore






yes (default) or no. Change Image format to DRIVER

For example, the following illustrates the creation of a Local Datastore:

cat ds.conf
NAME   = local_images
DS_MAD = fs
TM_MAD = ssh
onedatastore create ds.conf
ID: 100

Also note that there are additional attributes that can be set. Check the datastore template attributes.


Be sure to use the same TM_MAD for both the System and Image datastore. When combining different transfer modes, check the section below.

Additional Configuration

  • QCOW2_OPTIONS: Custom options for the qemu-img clone action. Images are created through the qemu-img command using the original image as a backing file. Custom options can be sent to qemu-img clone action through the variable QCOW2_OPTIONS in /etc/one/tmrc.

  • DD_BLOCK_SIZE: Block size for dd operations (default: 64kB) could be set in /var/lib/one/remotes/etc/datastore/fs/fs.conf.

  • SUPPORTED_FS: Comma-separated list with every filesystem supported for creating formatted datablocks. Can be set in /var/lib/one/remotes/etc/datastore/datastore.conf.

  • FS_OPTS_<FS>: Options for creating the filesystem for formatted datablocks. Can be set in /var/lib/one/remotes/etc/datastore/datastore.conf for each filesystem type.

  • SPARSE: If set to NO the images created in the Datastore wont be sparsed.

  • QCOW2_STANDALONE: If set to YES the standalone qcow2 disk is created during CLONE operation (default: QCOW2_STANDALONE=”NO”). Unlike previous options, this one is defined in image datastore template and inherited by the disks.


Before adding a new filesystem to the SUPPORTED_FS list make sure that the corresponding mkfs.<fs_name> command is available in the Front-end and hypervisor Hosts. If an unsupported FS is used by the user the default one will be used.


When using a Local Storage Datastore the QCOW2_OPTIONS attribute is ignored since the cloning script uses the tar command instead of qemu-img.

Datastore Internals

Images are saved into the corresponding Datastore directory (/var/lib/one/datastores/<DATASTORE ID>). Also, for each running Virtual Machine there is a directory (named after the VM ID) in the corresponding System Datastore. These directories contain the VM disks and additional files, e.g. checkpoint or snapshots.

For example, a system with an Image Datastore (1) with three images and three Virtual Machines (VM 0 and 2 running, and VM 7 stopped) running from System Datastore 0 would present the following layout:

|-- 0/
|   |-- 0/
|   |   |-- disk.0
|   |   `-- disk.1
|   |-- 2/
|   |   `-- disk.0
|   `-- 7/
|       |-- checkpoint
|       `-- disk.0
`-- 1
    |-- 05a38ae85311b9dbb4eb15a2010f11ce
    |-- 2bbec245b382fd833be35b0b0683ed09
    `-- d0e0df1fb8cfa88311ea54dfbcfc4b0c


The canonical path for /var/lib/one/datastores can be changed in /etc/one/oned.conf with the DATASTORE_LOCATION configuration attribute

In this case, the System Datastore is distributed among the Hosts. The ssh transfer driver uses the Hosts’ local storage to place the images of running Virtual Machines. All the operations are then performed locally but images have to always be copied to the Hosts, which in turn can be a very resource-demanding operation.