A Datastore is any storage medium used to store disk images for VMs, previous versions of OpenNebula refer to this concept as Image Repository. Typically, a datastore will be backed by SAN/NAS servers.

An OpenNebula installation can have multiple datastores of several types to store disk images. OpenNebula also uses a special datastore, the system datastore, to hold images of running VMs.

OpenNebula is shipped with 4 different datastore types:

• System, to hold images for running VMs, depending on the storage technology used these temporal images can be complete copies of the original image, qcow deltas or simple filesystem links.

• File-system, to store disk images in a file form. The files are stored in a directory mounted from a SAN/NAS server.

• iSCSI/LVM, to store disk images in a block device form. Images are presented to the hosts as iSCSI targets.

• VMware, a datastore specialized for the VMware hypervisor that handles the vmdk format.

As usual in OpenNebula the system has been architected to be highly modular, so you can easily adapt the base types to your deployment.

The Disk images registered in a datastore are transferred to the hosts by the transfer manager (TM) drivers. These drivers are specialized pieces of software that perform low-level storage operations (e.g. setting up iSCSI targets or file movements).

Since OpenNebula 3.4 the transfer mechanism is defined for each datastore. In this way a single host can simultaneously access multiple datastores that uses different transfer drivers. Note that the hosts must be configured to properly access each data-store type (e.g. mount FS shares).

OpenNebula includes 4 different ways to distribute datastore images to the hosts:

• shared, the datastore is exported in a shared filesystem to the hosts.
• ssh, datastore images are copied to the remote hosts using the ssh protocol
• iscsi, hosts access datastore targets opening and closing sessions dynamically
• vmware, image copies are done using the vmdfk filesystem tools
• qcow, a driver specialized to handle qemu-qcow format and take advantage of its snapshoting capabilities

Previous versions of OpenNebula define the transfer drivers in a per host basis. Since OpenNebula 3.4 you have to define how the images of a datastore are transferred to the hosts, and so set the transfer driver for each datastore.

You can take advantage of the multiple datastore features of OpenNebula to better scale the storage for your VMs, in particular:

• Balancing I/O operations between storage servers
• Different VM types or users can use datastores with different performance features
• Different SLA policies (e.g. backup) can be applied to different VM types or users
• Easily add new storage to the cloud

There are some limitations and features depending on the transfer mechanism you choose for your system and image datastores (check each datastore guide for more information). The following table summarizes the valid combinations of Datastore and transfer drivers:

Datastore	Transfer Manager Drivers
	shared	ssh	iscsi	qcow	vmware
System
File-System
iSCSI
VMware

Drivers can be easily customized please refer to the specific guide for each datastore driver or to the Storage substystem developer's guide.

However you may find the files you need to modify here:

• /var/lib/one/remotes/datastore/<DS_DRIVER>
• /var/lib/one/remotes/tm/<TM_DRIVER>