Automated deployment may fail due to a variety of reasons, including:
- A lost connection to the cloud account.
- Cancellation of the clone task in the cloud account.
- A momentary interruption to the host server.
- Changes to the infrastructure that affect the deployment destination.
- A mismatch between the requested public cloud instance type and the source image.
- The specified key pair or network configuration can't be found.
- A public cloud limit has been reached, such as an instance or memory limit for the project or region. When a public cloud vendor issues an error related to a limit reached, Commander precedes the error with the vendor name.
- The VM or virtual service naming convention doesn't match the cloud account's naming rules.
If the automated deployment of one component in a multi-component service fails, Commander attempts to deploy the next component. Likewise, if automated deployment of one service in a multi-service request fails, Commander attempts to deploy the next service in the request.
Notification about automated deployment issues
After automated deployment has been set up, if infrastructure changes that affect the deployment destination occur, Commander notifies administrators by email that changes have occurred and that the automated deployment process for a new service request will fail. See also Configuring Email Notification for Service Requests.
To address problems with a deployment destination, go to Configuration > Self-Service > Provisioning, select the deployment destination and click Edit.
To adjust the datastore threshold (applicable to vCenter and SCVMM only), go to Configuration > Self-Service > Provisioning and select a new value from Datastore Threshold. Then, manually deploy failed components as explained below.
Requests for VMs with no explicit storage tier
When a user requests a VM that has with no explicit storage tier set, automated deployment uses the default storage tier specified by the cost model applied to the deployment destination. If the deployment destination for the service request doesn't target a datastore for this storage tier, the automated deployment will fail. For example, if a highly available datastore isn't assigned to the default storage tier for a VM configured to be highly available, automated deployment will fail. Always configure the default storage tier to be backed by datastores for vCenter, SCVMM highly available storage, and SCVMM non-HA storage. If this configuration isn't possible due to the way you use storage, create a case through the Snow Support Portal to look into other configuration options.
Manually deploying a failed component
You can attempt manual deployment for a component whose automated deployment failed.
Don't attempt manual deployment when automated deployment is still in progress.
- Go to Views > Service Requests.
All service requests are listed. Look at the State column to quickly see the state of the request.
- Double-click the request to view request details.
The request tree provides details for each part of the request, with icons to show you where your attention is needed.
- Click a failed component in the request tree.
- On the Details tab, click Deploy.
- On the first page of the deployment wizard, from the Placement Options menu choose Automated Deployment.
If it's impossible for Commander to deploy to the same location as the successfully deployed components (because the deployment destination was deleted, for example), the component will be deployed in another location.
For vCenter, if you are manually deploying a VM component that was configured as part of a virtual service, selecting Automated Deployment ensures that Commander will automatically select the virtual service.
- Continue through the wizard.
For details on the fields in the wizard, click the help buttons on each wizard page.
