When creating a linked clone or clone blueprint, machine or templates are missing. Using your shared clone blueprint to request machines fails to provision machines.

Problem

When working with clone or linked clone blueprints, you might encounter one of the following problems:

  • When you create a linked clone blueprint, no machines appear in the list to clone, or the machine you want to clone does not appear.

  • When you create a clone blueprint, no templates appear in the list of templates to clone, or the template you want does not appear.

  • When machines are requested by using your shared clone blueprint, provisioning fails.

  • Because of data collection timing, a template that has been removed is still visible to users as they create or edit linked clone blueprints.

There are multiple possible causes for common clone and linked clone blueprint problems.

For related information about the Clone from and Clone from snapshot with Use current snapshot options that are available when you create blueprints, see vSphere Machine Component Settings.

Table 1. Causes for Common Clone and Linked Clone Blueprints Problems

Problem

Cause

Solution

Machines missing

You can only create linked clone blueprints by using machines you manage as a tenant administrator or business group manager.

A user in your tenant or business group must request a vSphere machine. If you have the appropriate roles, you can do this yourself.

You can also see unmanaged machines in this dialog.

Managed machines may have been imported. There is no requirement that machines be provisioned from vRealize Automation to be visible in this dialog.

Templates missing

Data collection has failed on a given endpoint or no endpoints are available for the component's platform.

  • If your endpoints are clustered and contain multiple compute resources, verify that your IaaS administrator added the cluster containing the templates to your fabric group.

  • For new templates, verify that IT placed the templates on the same cluster included in your fabric group.

Provisioning failure with a shared blueprint

For blueprints, no validation is available to ensure that the template you select exists in the reservation used to provision a machine from your shared clone blueprint.

Consider using entitlements to restrict the blueprint to users who have a reservation on the compute resource where the template exists.

Provisioning failure with a guest agent

The virtual machine might be rebooting immediately after the guest operating system customization is completed, but before the guest agent work items are completed, causing provisioning to fail. You can use the custom property VirtualMachine.Admin.CustomizeGuestOSDelay to increase the time delay.

Verify that you have added the custom property VirtualMachine.Admin.CustomizeGuestOSDelay. The value must be in HH:MM:SS format. If the value is not set, the default value is one minute (00:01:00).

Linked clone provisioning fails when using SDRS

When using linked clone provisioning and SDRS, the new machine must reside on the same cluster. A provisioning error occurs if the source machine's disks are on one cluster and you request to provision a machine on a different cluster.

When using SDRS and linked clone provisioning, provision machines to the same cluster as the linked clone source. Do not provision to a different cluster.

Clone or linked clone blueprint provisioning fails because the template on which the clone is based cannot be found

It is not possible to provision machines from a blueprint that is cloned from a template that no longer exists.

vRealize Automation runs data collection periodically, default every 24 hours. If a template is removed, the change is not reflected until the next data collection and so it is possible to create a blueprint based on a non-existent template.

Redefine the blueprint using an existing template and then request provisioning.

As a precaution and as applicable, you can run data collection before defining the clone or linked clone blueprint.