Today’s blog post discusses how the OpenStack metadata service works, and it was written by Michael Crane, the OpenStack Lead in VMware’s Global Support Services(GSS).

OpenStack provides a metadata service for cloud instances. This metadata is useful for accessing instance-specific information from within the instance. The primary purpose of this capability is to apply customizations to the instance during boot time if cloud-init or cloudbase-init is configured on your Linux or Windows image, respectively. However, instance metadata can be accessed at any time after the instance boots by the user or by applications running on the instance. In this article, we will describe how the metadata service is implemented in VIO, how to access the metadata from instances, and how to leverage the metadata for in-guest customization.

Metadata Service in VIO

The metadata service is implemented by the nova-api service on each controller node:

Figure 1 – OpenStack Management Network Layout

Instances can access the metadata via HTTP at the link-local IP address of 169.254.169.254. To manually access the metadata, use curl or wget to make a request and see the content that is available:

#curl http://169.254.169.254/openstack/latest 
meta_data.json
user_data
password
vendor_data.json

VIO Deployment Details

In VMware Integrated OpenStack, we deploy two NSX Edge Routers, known as metadata proxy routers, in a load-balanced configuration to serve as a proxy for metadata service requests:

Figure 2 – VMware NSX Edge routers assigned to the Metadata Service

Each metadata proxy router is visible to administrative users within OpenStack:

Figure 3 – Metadata Service Routers in the OpenStack Horizon Dashboard

Within OpenStack, an inter-edge network with subnet 169.254.128.0/17 is created and each metadata proxy router is connected to this network:

Figure 4 – Metadata Service Network

Routing of Metadata

When an instance accesses the metadata service, the request is routed as follows:

1. An HTTP request to 169.259.169.254 is received by a metadata proxy router
2. The request is forwarded over the inter-edge-net network to metadata proxy edge
3. The request is then sent to the Nova API service to fetch the desired metadata and then to return the metadata to the instance that requested it.

Figure 5 – Metadata Service Request Flow

Exploring the Metadata

Within the instance you may want to access the metadata for use in custom scripts. The metadata is provided in JSON format, and it can be accessed with a HTTP GET request to 169.254.169.254:

Figure 6 – Instance metadata output

As an example, if you launched the instance with a key pair, the public key is available via the metadata and can be imported into the instance by a custom script that consumes the metadata API. This is how cloud-init injects the public key to allow SSH login via private key.

Michael Crane is a Solutions Architect with Global Support Services and the Global Technical Lead for VMware Integrated OpenStack. He joined VMware in 2009 as a TSE with the Infrastructure support team (Storage, Fault, Networking). He later became an Escalation Engineer for Storage, SRM, and vSphere Replication and was the Global Technical Lead for SRM.