Error: "No operating system was found" on VM boot after deploying OVA/OVF in UI
search cancel

Error: "No operating system was found" on VM boot after deploying OVA/OVF in UI

book

Article ID: 432080

calendar_today

Updated On:

Products

VMware Cloud Director

Issue/Introduction

  • When attempting to deploy a VM using “Add vApp from OVF” in VMware Cloud Director, the operation may appear successful, but the VM fails to boot the operating system.
  • The issue is commonly reported in context of “Cannot import ovf correctly” during deployment workflows.
  • The VM console displays BIOS/PXE boot and/or:

    “No operating system was found…”

  • The same OVA/OVF may deploy and boot successfully when deployed directly in vCenter, but fails when deployed via VCD.

  • In VCD logs, the following error may be observed in:

    /opt/vmware/vcloud-director/logs/vcloud-container-debug.log

    Example:

    2026-02-09 10:04:25,651 | DEBUG | vim-proxy-activity-pool-518 | ImportVAppFromOvfActivity | status: 413, response: <html>
    <head><title>413 Request Entity Too Large</title></head>
    <body>
    <center><h1>413 Request Entity Too Large</h1></center>
    <hr><center>nginx/1.18.0 (Ubuntu)</center>
    </body>
    </html>

    This indicates that the VMDK upload process during OVF import is being interrupted or rejected.
    As a result, the VM is created and powered on, but the disk content is incomplete, leading to OS boot failure.

     

Environment

VMware Cloud Director 10.6.x

Cause

This issue can occur when VCD is unable to successfully stream the VM disk (VMDK) to the ESXi NFC upload endpoint during OVF/OVA instantiation, even though the VCD task may appear to complete.

Resolution

Follow the steps below to validate the upload path between VMware Cloud Director and ESXi and confirm whether an intermediary device is impacting OVF/OVA disk transfer.

  1. Validate direct connectivity from VCD cells to ESXi NFC endpoint

    Ensure that VCD cells can communicate directly with ESXi management/NFC endpoints without any intermediate HTTP devices.

    There should be no reverse proxy / WAF / load balancer between:

    • VCD cells

    • ESXi management interfaces (used for NFC uploads)

  2. Test upload path from VCD transfer share to ESXi

    From a VCD cell, test uploading a VMDK directly to an ESXi datastore using the following command:

    curl -i -k -u 'root' -X PUT "https://<esxi_fqdn>/folder/<path on datastore>/<vmname>.vmdk?dsName=<datastore name>" -F "file=@<vmname>-flat.vmdk"

    Expected result:

    Upload proceeds successfully without HTTP errors

    If the issue is present:

    The command may return:

    HTTP/1.1 413 Request Entity Too Large

    Response headers indicating a proxy (e.g. nginx)

    This confirms that an intermediate device is rejecting the upload, not VCD or ESXi.

  3. Review network infrastructure

    Verify whether any of the following exist in the path between VCD cells and ESXi:

    • Reverse proxies

    • Web Application Firewalls (WAF)

    • Load balancers performing HTTP inspection

      If present, ensure they are configured to support:

      • Large file uploads (multi-GB VMDK transfers)

      • Long-lived HTTP sessions

      • No request size limits (or appropriately increased limits)

      • No content inspection or modification of upload streams 

  4.  Retest OVF/OVA deployment

    After network changes:

    • Deploy the OVA/OVF again using “Add vApp from OVF”

      Confirm:

      • No HTTP errors occur during upload

      • VM boots successfully with the operating system

Powered by Wolken Software