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.
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
Simply make sure that there is enough space under
/var/lib/one/datastores to store Images and the disks of the
undeployed Virtual Machines. Note that
/var/lib/one/datastores can be mounted from any NAS/SAN server in your network.
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.
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 TYPE = SYSTEM_DS 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|
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.
QCOW2_OPTIONS: Custom options for the
qemu-imgclone action. Images are created through the
qemu-imgcommand using the original image as a backing file. Custom options can be sent to
qemu-imgclone action through the variable
DD_BLOCK_SIZE: Block size for dd operations (default: 64kB) could be set in
SUPPORTED_FS: Comma-separated list with every filesystem supported for creating formatted datablocks. Can be set in
FS_OPTS_<FS>: Options for creating the filesystem for formatted datablocks. Can be set in
/var/lib/one/remotes/etc/datastore/datastore.conffor each filesystem type.
SPARSE: If set to
NOthe images created in the Datastore wont be sparsed.
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.
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:
/var/lib/one/datastores |-- 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 the 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.