Skip to content
This repository has been archived by the owner on Sep 12, 2024. It is now read-only.

Latest commit

 

History

History
107 lines (72 loc) · 7.01 KB

contextualization.markdown

File metadata and controls

107 lines (72 loc) · 7.01 KB
Raw
layout
default

NOTE:

This is a distilled summary. For more information, you are advised to have a look at the official OpenNebula documentation pages:

Contextualization explained

Contextualization in OpenNebula refers to:

  • the act and effect of OpenNebula making information from the environment available meant for a VM to configure itself. This information is called the context.
  • the system that enables the former

In summary, OpenNebula provides out-of-the-box facilities to tell a VM about:

  • SSH authentication: what certificates or passwords should the VM recognise to allow SSH access to it
  • Network configuration: how each nic on the VM must be configured (e.g.: IP addresses, network masks...)
  • Other variables: the VM receives a file with a list of ⟨key, value⟩ pairs that you specify in the template
  • Init scripts: what programs the VM must run upon start-up (e.g.: auto-configuration scripts)
  • Other files: you can provide files to your VM for your own purposes

External point of view

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.

Internal point of view

NOTE:

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).

In short:

  • OpenNebula is ready to deliver a context to your VMs. You define in your template what 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.

Contextualization in practice

Standard packages for your VM

On Debian-based operating systems (e.g.: Ubuntu, Mint), you can install the standard .deb contextualization package.

  1. Download the .deb file from https://github.com/OpenNebula/addon-context-linux/releases/latest.
  2. Bring the .deb to your VM
  3. Install the .deb by running (change the <package_name.deb> placeholder by the right file and path):
dpkg -i <package_name.deb>

On RedHat-based operating systems (e.g.: CentOS, Fedora), you can install the standard .rpm contextualization package.

  1. Download the .rpm file from https://github.com/OpenNebula/addon-context-linux/releases/latest.
  2. Bring the .rpm to your VM
  3. Install the .rpm by running (change the <package_name.rpm> placeholder by the right file and path):
yum install <package_name.rpm>

SSH key for root

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.

Network configuration

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.

Init scripts

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).

NOTE:

OpenNebula only delivers contextualisation upon VM startup (from the external point of view). Therefore, any modification of the template or 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.

Scripts caveats; cloud-init

Aside from OpenNebula's contextualisation scripts, an alternative de-facto standard is emerging called cloud-init.

NOTE:

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:

  1. Open the file /usr/bin/cloud-init for editing.
  2. Change the shebang line to use the Python2 installation, like: #!/usr/bin/python2.7
  3. Reboot the OS so that the changes take effect.