From EGIWiki
Jump to: navigation, search
Main Roadmap and Innovation Technology For Users For Resource Providers Media

Workbenches: Open issues
Scenario 1
VM Management
Scenario 2
Data Management
Scenario 3
Information Systems
Scenario 4
Scenario 5
Scenario 6
Scenario 7
Federated AAI
Scenario 8
VM Image Management
Scenario 9
Scenario 10
Scenario 11


Leader: Enol Fernandez


This workgroup deals with the VM contextualization open issues, namely being able to pass user-defined data to the VM.


  • Evaluate mechanisms available in the cloud middleware to provide user-defined data
  • Evaluate possible OCCI extensions to pass user-defined data
  • Evaluate CIMI as alternative API (already includes user-data features)
  • Track implementation of OCCI extensions/CIMI on the cloud middleware


Contextualization is the process of installing, configuring and preparing software upon boot time on a pre-defined virtual machine image (e.g. setting the hostname, IP addresses, SSH aithorized keys, starting services, installing applications, etc.). We have identified as a requirement to contextualize images the possibility of passing user provided data to the VM when they are instantiated. Hence there are two things to be defined:

  • how to pass data upon VM creation (the exact type and format of the data should not be relevant, it should be up to the user)
  • how to retrieve those data from the running VM

For passing the data we have proposed the use of a new OCCI mixin that has an attribute to hold the data to pass to the image. The second part, related to retrieving the data, is more dependent of the back-end implementation. There are different methods in the systems in place in FedCloud, but tools like cloud-init handle those possible differences in a transparent way for the users.

OCCI support

FedCloud has agreed on two mixins for pushing user defined data into the VM instances:

  • Category: user_data; scheme="http://schemas.openstack.org/compute/instance#"; class="mixin", and
  • Category: public_key; scheme="http://schemas.openstack.org/instance/credentials#"; class="mixin"

The user_data mixin has an attribute org.openstack.compute.user_data where the use can specify the base64 encoded data that wants to be available at the VM upon instantiation.

In the case of the public_key mixin, there are two attributes to be specified:

  • org.openstack.credentials.publickey.name with a name for the public key, and
  • org.openstack.credentials.publickey.data with the public key itself.

These are specified as headers in the HTTP request for creating a VM. A sample curl request could look like this (credential managing is missing):

curl -H 'Category: compute;scheme="http://schemas.ogf.org/occi/infrastructure#";class="kind"' \
     -H 'Category: myVM;scheme="http://my.occi.service/occi/infrastructure/os_tpl#";class="mixin"' \
     -H 'Category: public_key;scheme="http://schemas.openstack.org/instance/credentials#";class="mixin"' \
     -H 'Category: user_data;scheme="http://schemas.openstack.org/compute/instance#";class="mixin"' \
     -H 'X-OCCI-Attribute: org.openstack.credentials.publickey.name="my_key"' \ 
     -H 'X-OCCI-Attribute: org.openstack.credentials.publickey.data="ssh-rsa BAA...zxe ==user@host" \
     -H 'X-OCCI-Attribute: org.openstack.compute.user_data="VGhpcyBpcyBhIHNpbXBsZSB0ZXN0IQ=="' \

rOCCI client

rOCCI client includes support for both extensions via the -T/--context command line argument. The client does not need to previously b64encode the data. The curl command above could be translated into the following

occi -e https://your.endpoint.com:1234 --action create --resource compute \
     --attribute occi.core.title='ContextVM' --mixin os_tpl#myVM 
     --context user_data='This is just a test!' --context public_key='ssh-rsa BAA...zxe ==user@host'

the user data and public keys can be specified as files:

--context user_data="file:///path/to/file" --context public_key="file:///path/to/publickey"

OCCI-OS (OpenStack)

OCCI-OS supports the extensions for pushing user data and keys for the stable/folsom and stable/havana versions.

rOCCI-server (OpenNebula and others)

rOCCI-server also supports the extensions since version 4.0.0 of rOCCI framework.


Synnefo also supports the extension in the latests versions.

Using the data at the instances

The proposed mixin does not impose any format on the data, thus the VM image creators are free to use this blob as it suites their needs. For most use cases, cloud-init is the best way to avoid dealing with the details that each middleware has for providing the data in the VM instance.


This task force recommends the use of cloud-init for the contextualization of VMs. Cloud-init frees the user from managing the specific ways for handling the contextualization information and it's widely available in most OS versions and IaaS cloud platforms. The latest versions support OpenNebula contextualization mechanisms. OpenStack and Synnefo contextualization are supported in most cloud-init versions (datasources are EC2 and NoCloud).

When creating a VM that is meant to run in different cloud middlewares leave the <cloud>datasource_list</cloud> undefined (so it will try all the available ones), or set at least the following:

[ NoCloud, OpenNebula, Ec2, None ]

By default cloud-init will:

- put the ssh-key into the ~/.ssh/authorized_keys of root user (or equivalent)

- if the user provided data is a script, it will be executed upon instantiation. More complex use-cases are supported, check cloud-init documentation for examples.

cloud-init and OpenNebula

The rOCCI server pushes into the OpenNebula context the base64 encoded user data provided by the client, however the default cloud-init is expecting clear text. This is fixed for the upcoming 0.7.5 version of cloud-init, in the meantime while it's released you can use the fedcloud packages (see below):


Custom FedCloud packages for some distributions are available at EGI's AppDB FedCloud cloud-init. These packages already manage the user data correctly for OpenNebula.

Contextualizing without cloudinit


OpenStack provides the user provided data at the meta-data server available at for every instance. With the EC2 API, user data is available at, it can be fetched with curl:


OpenStack API provides the same data at

Public keys are available at for EC2 API or

For getting OpenSSH key with EC2:

ssh-rsa  [...]==  xxx@host

OpenStack API returns a json dictionary with a "public_keys" dictionary inside, where the available keys are stored:
{... "public_keys": {"enolkey": "ssh-rsa [...]== xxx@host\n"}...}

See http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AESDG-chapter-instancedata.html and http://docs.openstack.org/user-guide/content/user-data.html for more info.


OpenNebula provides contextualization information through an ISO image that is available in the VM instance. The contents of the ISO image include a context.sh file where a set of variables are defined according to the VM template.

The iso filesystem is normally available at /dev/sr0 where a context.sh file contains all the context variables declared in the OpenNebula template.

The USER_DATA variable contains a base64 enconded blob (can be decoded with base64 -d) with the data provided by the user with the OCCI client. The SSH_PUBLIC_KEYS variable contain the user public keys.

For using this context just mount the filesystem and source the context file:

$ mount -o ro /dev/sr0 /mnt/
$ cat /mnt/context.sh  
# Context variables generated by OpenNebula
SSH_PUBLIC_KEY='ssh-rsa [...]== xxx@cloud'
$ . /mnt/context.sh
ssh-rsa [...]== xxx@host
$ echo $USER_DATA | base64 -d
This is my user data

See http://opennebula.org/documentation:archives:rel3.8:cong for more information.


Synnefo provides context data in a cloud-init NoCloud compatible format.

Two files are injected into the VMs: /var/lib/cloud/seed/nocloud-net/meta-data, which is a yaml file that contains the user provided public keys:

public-keys: ssh-rsa [...]== xxx@host

And /var/lib/cloud/seed/nocloud-net/user-data, which contains a blob with the data provided by the user with the OCCI client.

Setting up the middleware for contextualization


Default OpenStack installations do not require any additional steps for providing contextualization.


Cloud-init documentation includes information on the OpenNebula configuration. Check also OpenNebula contextualization overview for more information.

Windows Contextualization

Windows VM also support contextualization of the machine on machine boot using cloudbase-init software. This software similarly to the cloud-init available for linux machines uses the available meta-data and user-data and executes a set of plugins to configure the virtual machine.

Cloudbase-init supports OpenStack meta-data and there is work in progress to support other cloud management frameworks, including OpenNebula.


Cloudbase-init is distributed with a MSI installer build after every commit in the repo:

During the installation, you can configure:

  • Name of a user that will be created and upon boot up (if it is an already existing user, cloudbase-init will only change its password)
  • Network adapter / serial ports to use (defaults should be safe)

Normally is not needed to execute sysprep on the image after the installation of cloudbase-init

Once installed the machine can be uploaded/snapshoted to be started by the users.


The features of cloudbase-init are not as extensive as the Linux cloud-init, but it can still perform the actions described below. For an up-to-date list and documentation, check the Plugin documentation of cloudbase-init, there is also documentation available at cloudbaseinit wiki

User configuration

cloudbase-init by default will configure the user account configured during contextualization. Take into account that the configured group must exist before rebooting the machine.

Specifying the user password via OCCI

Cloudbase-init can set the user password if specified in the context of the VM. OpenStack does automatically generate a random password on machine creation but this is not available to the OCCI interface. We have created a new mixin that allows to specify the password you want the user to have as follows:

Category: admin_pwd; scheme="http://schemas.openstack.org/compute/instance#"; class="mixin"

And the password is specified with the attribute:


For using this mixin on VM creation, you can use a command line similar to this:

occi -e $OCCI_ENDPOINT -x $X509_USER_PROXY -X -n x509 \
     -a  create -r compute \
     -M $OS_TPL -M $RES_TPL \
     -t occi.core.title="$VM_TITLE" \
     -T user_data="$USER_DATA" \
     -M http://schemas.openstack.org/compute/instance#admin_pwd \
     -t org.openstack.credentials.admin_pwd="<secret>"


cloudbase-init will try to execute as a script whatever is passed in the user-data. It uses the first line of the file to determine which kind of script is passed for execution:

  • For Windows batch, the first line of the file must be
rem cmd
  • For Powershell, the first line must be:

or for a x86 PowerShell

  • For Bash (it must be preinstalled on the VM!), the first line must begin with

for example, it can be


The script will be executed with admin privileges. Take into account that the file must have DOS format, so if you are editing them on a UNIX-based machine you should make sure that the endline terminators are in the correct format.

Forcing re-execution of contextualization

cloudbase-init will execute the plugins only on the first time the image is booted. If you need to re-execute them you should remove in the Windows registry the following key:

HKEY_LOCAL_MACHINE\Software\Cloudbase Solutions\Cloudbase-Init

on 64 bit versions of Windows, the key is:

HKEY_LOCAL_MACHINE\Software\Wow6432Node\Cloudbase Solutions\Cloudbase-Init

The next time cloudbase-init is executed (due to a reboot or by restarting the service), it will execute the plugins again.