This is a distilled summary. For more information, you are advised to have a look at the official OpenNebula documentation pages:
Contextualization in OpenNebula refers to:
In summary, OpenNebula provides out-of-the-box facilities to tell a VM about:
nicon the VM must be configured (e.g.: IP addresses, network masks…)
The way this information is provided to your VM is by means of a virtual CD-ROM (or contextualization CD-ROM). OpenNebula builds an
image (that you do NOT get to see on the UI) for each VM for which you have enabled contextualization, and it makes it available via the IDE driver so that you can mount it in your operating system.
Pre-packaged .deb and .rpm packages are available on the releases directory of the OpenNebula/addon-context-linux project in GitHub.
Some very useful standard (read .deb and .rpm) packages are also delivered by the OpenNebula developers, that you can install in your VM. These packages set the booting sequence of the VM up in such a way that the context information is used to configure the VM even before the operating system will prompt for normal login. The packages mount the context CD-ROM, then process the files found there to configure the root user to require a private-public key pair to SSH into the VM. They also configure the network according to the context, which is very handy because your VM must use the MAC and IP addresses that the HPC Cloud grants them (otherwise, the VM will have no network connectivity).
OpenNebula is ready to deliver a context to your VMs. You define in your
templatewhat you would like to include in this context. Standard context information includes SSH keys and network information. The VM can read the context as a CD-ROM.
You must adapt your VM to benefit from this context: your VM needs to actively read and interpret the context, or otherwise it will ignore the context.
In general, VMs made from AppMarket appliances are set up to use contextualization.
On Debian-based operating systems (e.g.: Ubuntu, Mint), you can install the standard .deb contextualization package.
dpkg -i <package_name.deb>
On RedHat-based operating systems (e.g.: CentOS, Fedora), you can install the standard .rpm contextualization package.
yum install <package_name.rpm>
You can let your VM require the root user to log in only with a valid SSH key. This option is the preferred way in the usual AppMarket appliances.
To enable SSH key contextualization, before you create your VM, on your
template, on the template-editing screen, under the Context tab, in the Network & SSH subsection, make sure that the checkbox Add SSH contextualization is checked.
Then, if you paste your public key on the Public Key field, that one will be set. Otherwise, the public key from your user profile will be set.
You can let your VM configure its
nics from the context. This option is the preferred way in the usual AppMarket appliances.
To enable network contextualization, before you create your VM, on your
template, on the template-editing screen, under the Context tab, in the Network & SSH subsection, make sure that the checkbox Add Network contextualization is checked.
You can have one (or more) scripts configure other aspects of your VM upon OS boot. For example, you can run a script that will check whether a given non-root user exists, and if it does not, then have the script create one for you.
For that, you first need to create an (or several)
Init File(s) on the Files & Kernels section of the UI. Then, before you create your VM, on your
template, on the template-editing screen, under the Context tab, in the Files subsection, you can refer to that (those)
Init File(s) on the Init scripts field (to include several of them, just type their names in the order you want them, separated by spaces).
OpenNebula only delivers contextualisation upon VM startup (from the external point of view). Therefore, any modification of the
files that you make while the VM is running, will not be visible to that running VM. Further, even when you add
nics to a running VM, these will not be contextualised.
Aside from OpenNebula’s contextualisation scripts, an alternative de-facto standard is emerging called cloud-init.
OpenNebula’s notes on cloud-init are available in their documentation for an older version of OpenNebula (4.14)
It looks like cloud-init’s scripts may suffer from having Python3 as the default Python interpreter. If you need to install Python3, you are using cloud-init and you notice that your VM suddenly fails to be properly contextualised, you may want to have an alternate Python2 installation and have the init scripts use this instead.
As a practical case, in Ubuntu, using all default Python2 and Python3 packages, a user reports having solved his problem by doing the following: