Unable to deploy VM using OVF template - OVF Deployment Stalls at 0% and Fails with Timedout and DvsApplyOperationFault
search cancel

Unable to deploy VM using OVF template - OVF Deployment Stalls at 0% and Fails with Timedout and DvsApplyOperationFault

book

Article ID: 436656

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

When deploying an OVF template (e.g., "Prod UAP") to a VMware Cloud Foundation (VCF) or VMware vSphere Foundation (VVF) managed ESXi cluster, the deployment task remains stuck at 0% and eventually fails with a timeout. The vSphere Client UI may not provide an option to bypass the network selection by choosing "None".

The vCenter Server vpxd logs display an invalid property fault referencing a missing source network object, followed by distributed virtual port allocation failures, and concluding with a task timeout and Network File Copy (NFC) lease expiration:

yyyy-mm-ddThh:mm:ss.276Z error vpxd[<REDACTED_ID>] [Originator@6#76 sub=Default opID=e#####-#9] [VpxLRO] -- ERROR lro-##### -- propertyCollector -- vmodl.query.PropertyCollector.retrievePropertiesEx: :vmodl.query.InvalidProperty
-->             obj = 'vim.Network:network-####',  

yyyy-mm-ddThh:mm:ss.654Z error vpxd[<REDACTED_ID>] [Originator@6#76 sub=hostMethod] Host call [applyDVPort] for host [[vim.HostSystem:<REDACTED_HOSTNAME>]] failed with exception [Fault cause: vim.fault.DvsApplyOperationFault
--> ] 

 yyyy-mm-ddThh:mm:ss.972Z error vpxd[<REDACTED_ID>] [Originator@6#76 sub=Default opID=2#####] [VpxLRO] -- ERROR lro-##### -- vim.HttpNfcLease.progress: :vim.fault.Timedout
--> Result:
--> (vim.fault.Timedout) {
-->    faultCause = (vmodl.MethodFault) null,
-->    faultMessage = <unset>
-->    msg = ""
--> }

Environment

VMware vCenter

VMware ESXi  

Cause

The OVF descriptor (.ovf file) contains a malformed configuration that prevents instantiation on the destination environment. Specifically, the file contains a hardcoded legacy network reference (e.g., vim.Network:network-8443) that vCenter Server cannot validate, which prevents the allocation of required Distributed Virtual Switch (vDS) ports. Additionally, the descriptor contains mismatched VMDK file names within the <References> section.

With virtual machine instantiation blocked by the invalid network mapping and mismatched disk references, the data payload transfer over the NFC connection stalls. Once the idle NFC session exceeds the maximum wait threshold, vCenter terminates the operation with a vim.fault.Timedout exception.

Resolution

 

  1. Extract the OVF package using a standard archiving tool (e.g., tar, 7-Zip).

  2. Open the .ovf descriptor file in a plain text editor.

  3. Locate the <References> section and modify the VMDK file names to ensure they exactly match the physical .vmdk files included in the extracted package directory.

  4. Locate the <NetworkSection> and update the network definitions and corresponding virtual hardware <Connection> tags to reflect a valid, existing VCF-backed vDS portgroup or NSX logical segment.

  5. Save the changes and close the .ovf file.

  6. Delete the .mf (manifest) file from the package directory. This is a mandatory step to prevent cryptographic checksum validation failures resulting from the manual edits to the descriptor file.

  7. Initiate a new deployment via the vSphere Client UI, selecting the modified .ovf file and the associated .vmdk files.

 

Additional Information

For more information regarding OVF descriptor modifications and the symptoms described above, refer to the following Broadcom Knowledge Base articles:

Powered by Wolken Software