You deliver Software components by placing them on top of supported machine components when you assemble blueprints.

To support Software components, the machine blueprint you select must contain a machine component based on a template, snapshot, or Amazon machine image that contains the guest agent and the Software bootstrap agent, and it must use a supported provisioning method.

Because the Software agents do not support Internet Protocol version 6 (IPv6), use IPv4 settings.


Software components must have an ordered dependency in the blueprint. Unordered software components can cause blueprint provisioning to fail. If there is no actual order dependency for the software components, you can satisfy the blueprint ordering requirement by adding a faux dependency between the software components.

If you are designing blueprints to be scalable, it is a best practice to create single layer blueprints that do not reuse other blueprints. Normally, the update processes that are used during scale operations are triggered by implicit dependencies such as property bindings. However, implicit dependencies in a nested blueprint do not always trigger update processes.

While IaaS architects, application architects, and software architects can all assemble blueprints, only IaaS architects can configure machine components. If you are not an IaaS architect, you cannot configure your own machine components, but you can reuse machine blueprints that your IaaS architect created and published.

To successfully add software components to the design canvas, you must also have business group member, business group administrator, or tenant administrator role access to the target catalog.

If you need to use nested blueprints in a scalable blueprint, you can manually draw dependencies between components in your nested blueprint to create explicit dependencies that always trigger an update.

When you publish a blueprint, software component data is treated like a snapshot. If you later make changes to the software component's properties, only new properties are recognized by the blueprint in which the software component exists. Updates to properties that existed in the software component at the time you published the blueprint are not updated in the blueprint. Only properties that are added after you have published the blueprint are inherited by the blueprint. However, you can make changes to instances of the software component in blueprints in which the software component resides to change that particular blueprint.
Table 1. Provisioning Methods that Support Software

Machine Type

Provisioning Method




Linked Clone

vCloud Director


vCloud Air


Amazon AWS

Amazon Machine Image