VT-CloudCaps:BestPractices

This page details the dos and don'ts of image creation when it comes to leveraging various cloud capabilities and achieving multi-platform compatibility.

Platform-specific practices

OpenNebula

If you want to leverage some platform-specific features provided by OpenNebula and use workflows endorsed by its community, you should follow a few recommendations regarding image creation. This is especially important for users coming to OpenNebula from other cloud platforms, such as OpenStack. In order to understand these recommendations, you first have to understand how OpenNebula works with block storage, images and virtual machines in general.

Images

When you upload a file containing the file system of a virtual machine (image of a single partition or the whole disk, it doesn't matter at this point) to OpenNebula and register it as an IMAGE, it becomes attachable but not resizeable. This means you will be able to create a virtual machine using this IMAGE but you won't be able to change its size during instantiation or expand its file system to fill a bigger IMAGE.

The only way to add more block storage to a virtual machine is to create a special empty IMAGE using type DATABLOCK and attach it as a new block device. This means that storage space can be added only to a new mount point inside the virtual machine.

Virtual machine templates

Virtual machine TEMPLATE in OpenNebula is a connecting point for all virtualized resources used by the virtual machine instance launched from this TEMPLATE. It's the place where you can specify the number of CPU cores, amount of RAM, images that should be connected to this virtual machine and much more ... Here lies the difference between OpenNebula and other cloud platforms, such as OpenStack. There is no way to specify IMAGE size for existing images, they will be simply copied from the image repository as they are and attached to the virtual machine instance before the boot process begins. Hence the amount of block storage cannot be specified upon instantiation and it is tied to the size of existing images in the image repository that will be connected to the virtual machine instance.

Since this would be a massive drawback for the usability of OpenNebula, there is a way to create block storage "on-the-fly" upon instantiation of the virtual machine (or, in fact, during its runtime). You can simply specify that, in addition to all the existing images, you want to also attach empty block storage devices of the chosen size and file system type. These block devices will appear in the virtual machine as regular block devices and will have to be mounted to specific mount points before use. See VT-CloudCaps:BestPractices#Examples for some examples of this functionality.

Examples

• Example #1

I have a raw disk image containing an MBR and a single partition
with the root file system of an arbitrary Linux distribution.

This image has the following attributes:
 -- 4 GB of space in total
 -- 2 GB taken by the OS installation
 -- no fs encryption, no LVM, no swap
 -- credentials for root access are already included
 -- everything is stored in a single file my_cloud_vm.img

Once I upload and register this file as an IMAGE in OpenNebula, it
becomes available as IMAGE_ID = 1 and I will use it to instantiate
a virtual machine.

After a successful login into the running virtual machine, I realize
that there is _NOT_ enough space to install the software or copy the
data I need to run my computing job.

The only way to solve this problem /without expanding, uploading
and registering a new (and bigger) IMAGE/ is to attach a DATABLOCK
and mount it inside the virtual machine as a new mount point.

There is no way to expand the existing root file system or IMAGE
itself once it is registered in OpenNebula.

So I create an empty DATABLOCK, attach it to the virtual machine
instance, mount the resulting block device to /data and install
my software/copy my data to this location without taking up space
in the root file system.

• Example #2

I have a qcow2 disk image containing an MBR and a single partition
with the root file system of an arbitrary Linux distribution.

This image has the following attributes:
 -- 20 GB of space in total
 -- 2 GB taken by the OS installation
 -- no fs encryption, no LVM, no swap
 -- credentials for root access are already included
 -- everything is stored in a single file my_cloud_vm.qcow2 taking
    up only 2GB of disk space

Once I upload and register this file as a persistent IMAGE in OpenNebula, it
becomes available as IMAGE_ID = 2 and I will use it to instantiate
a virtual machine.

After a successful login into the running virtual machine, I realize
that there is enough space to install the software and copy the
data I need to run my computing job.

Since this image is persistent, it will be automatically overwritten in the
image repository once I shut down the virtual machine.

The next virtual machine instance using this image I launch will take forever
to deploy, since the image has already expanded to its full physical capacity
of 20 GB.

This is not the right way to use cloud capabilities in OpenNebula!