(See What is a Stemcell? for an introduction to stemcells.)

To build a stemcell tarball for a supported IaaS-OS combination follow instructions in the bosh-linux-stemcell-builder’s README.

Stemcell tarballs are currently specific to an IaaS-OS/CPI because they may:

In the future, BOSH team will investigate how to best consolidate stemcells into a single OS image. In the meantime, if you’re developing a CPI for a new IaaS, you may consider reusing one of the officially generated stemcells, or making changes to the following projects:

Tarball Structure

Note that tarball structure is subject to change without notice.

$ tar tvf light-bosh-stemcell-3033-aws-xen-hvm-ubuntu-trusty-go_agent.tgz

-rw-rw-r--  0 ubuntu ubuntu      0 Aug  4 09:45 image
-rw-rw-r--  0 ubuntu ubuntu    710 Aug  4 10:06 stemcell.MF
-rw-r--r--  0 ubuntu ubuntu  50594 Aug  4 09:23 packages.txt
-rw-r--r--  0 ubuntu ubuntu  12543 Aug  4 09:22 dev_tools_file_list.txt
  • image: OS image in a format (raw, qcow, ova, etc.) understood by the CPI/IaaS.
  • stemcell.MF: YAML file with stemcell metadata.
  • packages.txt: Text file that includes list of packages installed. (Used to be included as stemcell_dpkg_l.txt)
  • dev_tools_file_list.txt: Text file that includes list of files removed by the agent if Agent’s remove_dev_tools feature is enabled.


Note that content of `stemcell.MF` is subject to change without notice.

  • name [String, required]: A unique name used to identify stemcell series.
  • operating_system [String, required]: Operating system in the stemcell. Example: ubuntu-trusty.
  • version [String, required]: Version of the stemcell. Example: 3033.
  • sha1 [String, required]: The SHA1 of the image file included in the stemcell tarball.
  • bosh_protocol [Integer, optional]: Deprecated.
  • cloud_properties [Hash, required]: Describes any IaaS-specific properties needed to import OS image. These properties will be passed in to the create_stemcell CPI call.

Name, operating system and version values will be visible via bosh stemcells command once a stemcell is imported into the Director.


$ tar -Oxzf light-bosh-stemcell-3033-aws-xen-hvm-ubuntu-trusty-go_agent.tgz stemcell.MF
name: bosh-aws-xen-hvm-ubuntu-trusty-go_agent
operating_system: ubuntu-trusty
version: '3033'
sha1: c13273b00b762c5aa29240ea62e1b9b5a03ae02c
bosh_protocol: 1
  name: bosh-aws-xen-hvm-ubuntu-trusty-go_agent
  version: '3033'
  infrastructure: aws
  hypervisor: xen
  root_device_name: /dev/sda1
    us-east-1: ami-3dc56656
    us-west-1: ami-db9a659f
    us-west-2: ami-dd5850ed

Light Stemcells

Some IaaSes (or how they are configured) limit how OS images can be imported. Here are couple of examples:

  • AWS only allows creation of AMIs from running VMs on AWS
  • OpenStack can be configured to disallow Glance image upload
  • an IaaS may take long time to import an image making it beneficial to reuse existing images

In such cases CPI must use already imported OS image and that’s where light stemcells come in. Light stemcell tarballs include additional details about already imported OS images in the cloud_properties section. For example light stemcells for AWS have ami key in the cloud_properties section (as shown above), that contains region-to-AMI-ID mappings. When AWS CPI’s create_stemcell call is made, it will return matching AMI ID without doing any IaaS API calls.


There are two test suites each stemcell is expected to pass before it’s considered to be production-ready:

  • shared Stemcell Tests which verify that proper packages and configurations are installed
  • shared BOSH Acceptance Tests (BATS) (provided by the BOSH team) which verify high level Director behavior with the stemcell being used

Back to Table of Contents

Previous: Agent-CPI interactions

Contribute changes to this page