OVF deployment process fails with Throwable proxy error at 95% using remote URL
search cancel

OVF deployment process fails with Throwable proxy error at 95% using remote URL

book

Article ID: 387041

calendar_today

Updated On:

Products

VMware vCenter Server VMware vCenter Server 7.0 VMware vCenter Server 8.0 VMware vSphere ESXi VMware vSphere ESXi 7.0 VMware vSphere ESXi 8.0

Issue/Introduction

  • Trying to deploy ovf from the remote repository it is failing intermittently.
  • If we deploy the VM locally from the ESXI host client, the deployment works fine.

cls.log (Problematic VC Node)

YYYY-MM-DDTHH:MM:SSZ | DEBUG    | ########-#######-auto-#####-h5:########-##-## | cls-simple-activity-9     | VcTaskService                  | Setting progress for task ########-####-####-####-############ (ManagedObjectReference: type = Task, value = task-######, serverGuid = ########-####-####-####-############) from 0 to 0
YYYY-MM-DDTHH:MM:SSZ | DEBUG    | ########-#######-auto-#####-h5:########-##-## | cls-simple-activity-9     | ImportSessionActivity          | Got probe result on nfc lease ManagedObjectReference: type = HttpNfcLease, value = session[########-####-####-####-############] ########-####-####-####-############, serverGuid = ########-####-####-####-############: [(vim.ProbeResult) {
   dynamicType = null,
   dynamicProperty = null,
   serverAccessible = true
}]


cls.log (Working VC Node)

YYYY-MM-DDTHH:MM:SSZ | DEBUG    | ########-#######-auto-#####-h5:########-##-## | cls-simple-activity-16    | VcTaskService                  | Setting progress for task ########-####-####-####-############ (ManagedObjectReference: type = Task, value = task-2107770, serverGuid = ########-####-####-####-############) from 0 to 0
YYYY-MM-DDTHH:MM:SSZ | DEBUG    | ########-#######-auto-#####-h5:########-##-## | cls-simple-activity-16    | ImportSessionActivity          | Got probe result on nfc lease ManagedObjectReference: type = HttpNfcLease, value = session[########-####-####-####-############] ########-####-####-####-############, serverGuid = ########-####-####-####-############: [(vim.ProbeResult) {
   dynamicType = null,
   dynamicProperty = null,
   serverAccessible = false
}]

Environment

VMware vCenter Server 7.x

VMware vCenter Server 8.x

VMware ESXi Host 7.x

VMware ESXi Host 8.x

Cause

The ESXi host takes a lead role in the OVF deployment process by utilizing the "VApp.PullFromUrls" privilege if ESXi host has access to the deployment URL and it fails only for the OVF disk sized >= 2TB on the ESXi host by design.


The deployment fails when serverAccessible=true due to a storage or size restriction, likely tied to the platform's limitation on VM or disk size during deployment.

  • When serverAccessible=false, OVF deployment is successful.
  • When serverAccessible=true, the deployment fails due to the 2TB size limitation on ESXi host.

Resolution

Solution Recommendations:

  1. Use Content Library for OVF Deployment:
    • Recommendation: We recommend using the content library as the primary method for storing and distributing OVF templates. This approach was successfully tested and addresses the 2TB disk size limitation and URL access issues.
    • Benefit: Provides a more controlled and reliable method for managing OVF templates and ensures smoother deployments.
  2. Block URL Access on ESXi Host (If Content Library Is Not Feasible):
    • Recommendation: If the content library cannot be used, block URL access on the ESXi host. This will ensure that all OVF deployment operations are managed by the vCenter Server, bypassing direct URL access complications.
    • Benefit: Avoids issues related to direct URL access, ensuring smoother OVF deployment processes.
  3. Disable "VApp.PullFromUrls" Privilege (Temporary Workaround):
    • Recommendation: Temporarily disable the "VApp.PullFromUrls" privilege for the user role. This prevents the ESXi host from pulling OVF templates directly from the URL, which can resolve deployment issues caused by URL access problems.
    • Benefit: Acts as a workaround to allow URL-based deployment to succeed when direct access issues arise.