The Filesystem Datastore 3.4
The Filesystem datastore lets you store VM images in a file form. The datastore is format agnostic, so you can store any file-type depending on the target hypervisor. The use of file-based disk images presents several benefits over deviced backed disks (e.g. easily backup images, or use of shared FS) although it may less performing in some cases.
Usually it is a good idea to have multiple filesystem datastores to:
There are no special requirements or software dependencies to use the filesystem datastore. The drivers make use of standard filesystem utils (cp, ln, mv, tar, mkfs…) that should be installed in your system.
Filesystem datastores can work with a system datastore that uses either the shared or the SSH transfer drivers, note that:
See more details on the System Datastore Guide
The first step to create a filesystem datastore is to set up a template file for it. In the following table you can see the valid configuration attributes for a filesystem datastore. The datastore type is set by its drivers, in this case be sure to add
The other important attribute to configure the datastore is the transfer drivers. These drivers determine how the images are accessed in the hosts. The Filesystem datastore can use shared, ssh and qcow2. See below for more details.
| ||The name of the datastore|
| || The DS type, use
| || Transfer drivers for the datastore:
| ||Paths that can not be used to register images. A space separated list of paths.|
| ||If you need to un-block a directory under one of the RESTRICTED_DIRS. A space separated list of paths.|
| || Default mask for the files created in the datastore. Defaults to
For example, the following illustrates the creation of a filesystem datastore using the shared transfer drivers.
> cat ds.conf NAME = production DS_MAD = fs TM_MAD = shared > onedatastore create ds.conf ID: 100 > onedatastore list ID NAME CLUSTER IMAGES TYPE TM 0 system none 0 fs shared 1 default none 3 fs shared 100 production none 0 fs shared
You can check more details of the datastore by issuing the
onedatastore show command.
Finally, you have to prepare the storage for the datastore and configure the hosts to access it. This depends on the transfer mechanism you have chosen for your datastore.
The shared transfer driver assumes that the datastore is mounted in all the hosts of the cluster. When a VM is created, its disks (the
disk.i files) are copied or linked in the corresponding directory of the system datastore. These file operations are always performed remotely on the target host.
If the VM uses a persistent image, a symbolic link to the datastore is created in the corresponding directory of the system datastore. Non-persistent images are copied instead. For persistent images, this allows an immediate deployment, and no extra time is needed to save the disk back to the datastore when the VM is shut down.
On the other hand, the original file is used directly, and if for some reason the VM fails and the image data is corrupted or lost, there is no way to cancel the persistence.
Finally images created using the 'onevm saveas' command will be moved to the datastore only after the VM is successfully shut down. This means that the VM has to be shutdown using the 'onevm shutdown' command, and not 'onevm delete'. Suspending or stopping a running VM won't copy the disk file to the datastore either.
Each host has to mount the datastore under
$DATASTORE_LOCATION/<datastore_id>. The value of the
DATASTORE_LOCATION variable is the same for all the hosts and can be defined in oned.conf file. By default,
DATASTORE_LOCATION points to
You also have to mount the datastore in the front-end in
In this case the datastore is only directly accessed by the front-end. VM images are copied from/to the datastore using the SSH protocol. This may impose high VM deployment times depending on your infrastructure network connectivity.
In either case (persistent and non-persistent) images are always copied from the datastore to the corresponding directory of the system datastore in the target host.
If an image is persistent (or for the matter of fact, created with the 'onevm saveas' command), it is transferred back to the Datastore only after the VM is successfully shut down. This means that the VM has to be shut down using the 'onevm shutdown' command, and not 'onevm delete'. Note that no modification to the image registered in the datastore occurs till that moment. Suspending or stopping a running VM won't copy/modify the disk file registered in the datastore either.
There is no special configuration for the hosts in this case. Just make sure that there is enough space under
$DATASTORE_LOCATION to hold the images of the VMs running in that host.
The qcow2 drivers are a specialization of the shared drivers to work with the qcow2 format for disk images. The same features/restrictions and configuration applies so be sure to read the shared driver section.
The following list details the differences:
qemu-imgcommand using the original image as backing file
qemu-img convertcommand is used instead of a direct copy
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: