As a follow up to my recent workshop at the Austin OpenStack Summit, here is some of the information from this session:

When it comes to instance personalization on OpenStack, there are currently four primary types of metadata (these often show up on other cloud platforms as well): Meta-Data, User-Data, Vendor-Data, and Network-Data (


Meta-Data is typically an instance-id, account-id, random seed, hostname, etc. It is found in the meta_data.json file residing on ConfigDrive or the Neutron Metadata Service via

"admin_pass": "Amgkg8aehSeZ",
"availability_zone": "nova",
"hostname": "hi.novalocal",
"launch_index": 0,
"name": "hi",
"project_id": "b884b287309140b495821eb8f0f9e30d",
"random_seed": "FZHvd6YUHwDZUk4KYkVZkYrWHt61L1gGdbeoeefseeUUhmXvqCj9RfzKt9/RdD0DY2Fn48aAOVovSh6I6VtsRScV6ASjC+mpweJX1Jjmh73cjQnEfuN5YwUNknMYHZWDhWcKEjgRYpgM1BnaWYCt/wDVFC/Y0esLODy4156V94Sm8VhotDUawkoXT7BlCeLD+3bpAV1iprJn26CcM6Ob0ODKT3/qRVaSqxGD7qYi69RAelsneDOVn41xDJiQeIUqBCRzzahgDUoJ8HjFNuawFAqfez0Z3TqVsWuNHP03FhmNOG9Tqw7GevsMhLmzYY65ZHoCaJb/Ew64mDt57XyU+SZOeJDV9El9ENRQtO9vBmXttMpX5MIlsNsy/eeDTmfMZWxKsubmenMmtT7AUEO+PdPhTa/UMfnxCUX+ehFjUaPfTxTJJ8zBPyPoSMFpE5yA04z0G2U20Yt1Nisb4tt2UBKHJeDERjf1Ta7lE0Uc5HFBjg9U2LxZy1DKG18py7LajbsbCHfMyJtMM2RrhR/910VarUgscYhRo++EQzEAZfBwf+e3UFbmOCFrMP8ndq/jyyhGeGuPa7Rusd42Y70JZxnZTRfPQN9w2kSPxCu0l7RJ1+Ry/+rp77NDlhOHXZMf6a7CG8MbEbDslwtMMrFpCjcgTcY1ZETVvFFaqSg6uNM=",
"uuid": "f8b406c4-7da1-4d20-8c44-a93dc42308e2"

For security reasons, the admin_pass value is not typically used during most OpenStack deployments. One can create a customized cloud-init python module to fetch this admin_pass value and set it as root password. One can also choose to have libvirt mount the image and inject the password prior to boot.

  • random_seed is taken from the compute host's /dev/urandom.
  • launch_index is the number assigned to an instance when booting multiple servers via one api call or cli command, i.e.
nova boot --flavor 1 --image ubuntu --max-count 3 myinstance

myinstance-1 = launch_index: 0
myinstance-2 = launch_index: 1
myinstance-3 = launch_index: 2


The user passes user-data at boot via the --user-data flag. It is found in the user_data file residing on ConfigDrive or the Neutron Metadata Service via User-data is typically cloud-config syntax. cloud-config is interepreted by cloud-init and provides an abstraction that is distro agnostic.


package_update: true
package_upgrade: true

- path: /etc/hosts
  permissions: '0644'
  content: | server2 server3 server4 server5

  - vim
  - git

Each one of these directives (package_update/upgrade, write_files, packages, etc.) is directly related to a python module found in the cloud-init application ( Cloud-init is typically found on any cloud image you boot, whether on Amazon, Rackspace, Google Cloud Platform, Azure, Digital Ocean, etc.

Cloud-init can also run a variety of other scripts (as long as the intereprter exists on the image). Examples include #!/bin/sh, #!/usr/bin/python, #!/usr/bin/perl, #!/usr/bin/awk.

User-Data is typically limited to 16K so you can also to the following to fetch the script and overcome the limitation:



Vendor-Data is a way for a vendor to provide site specific information. This can be information on local mirrors, a local proxy, or a one-time registration code. It is found in the vendor_data.json file residing on ConfigDrive or the Neutron Metadata Service via By default, Cloud-Init executes the Vendor-Data on every boot.

When running OpenStack, one can setup Vendor Data by adding the following lines to nova-api's /etc/nova/nova.conf:


The vendordata.json file can be any cloud-init readable data in json format. Example:

"cloud-init": "#cloud-config\nfinal_message: This is Vendor Data for the Austin OpenStack Summit Workshop by Rackspace Training"


Network-Data is network information found on ConfigDrive. It resides in the network_data.json file. Nova retrieves this info from Neutron. It includes fixed ip addresses, MAC addresses, port-id's, network-id's, subnet-id's, DNS name-servers, etc.

Consider a scenario where DHCP is disabled in the cloud. One could create a basic script or cloud-init module to assign static IP address found in this data to eth0. Or perhaps DHCP is enabled and ones to statically assign eth1 and eth2.

"links": [
        "ethernet_mac_address": "fa:16:3e:9c:bf:3d",
        "id": "tapcd9f6d46-4a",
        "mtu": null,
        "type": "bridge",
        "vif_id": "cd9f6d46-4a3a-43ab-a466-994af9db96fc"
"networks": [
        "id": "network0",
        "link": "tapcd9f6d46-4a",
        "network_id": "99e88329-f20d-4741-9593-25bf07847b16",
        "type": "ipv4_dhcp"
"services": [
        "address": "",
        "type": "dns"


comments powered by Disqus