vCloud Director 8.20: VM Auto-import

While the biggest new feature of vCloud Director 8.20 is the access for tenants to NSX advanced services on Edge Gateways and distributed firewall, service providers will love automatic import of vCenter virtual machines.

Import of vCenter VMs under vCloud Director management was around for long time, but the VM had to be in powered off state. In vCloud Director 8.10, the possibility of running VM import was introduced (vCloud API only feature). However, vCloud Director 8.20 simplifies this even more:

The system administrator can just drag any vCenter VM into Org VDC resource pool and vCloud Director will automatically discover such VM and import it. The VM can be even in running state. This enables migration use cases, or allows service providers to easily offer self service access to their fully managed vSphere only environments by simply connecting them to vCloud Director.

In the picture below you can see Org VDC Resource Pool (ACME_PAYG) in vCenter hierarchy with two regular vCenter VMs that were dragged there. VM_C1 was running, while VM_P2 was powered-off.


The next picture shows automatically created vApps for these two imported VMs with the prefix Discovered.


While these vApps resemble regular vApps they are not real vCloud Director vApps until they are adopted. The adoption happens when the VM inside the vApp is somehow reconfigured.

By default VM discovery is enabled for every Organization in vCloud Director. It can be disabled in General Settings (UI or API)


or with CMT command on VCD cell:

cell-management-tool manage-config -n managed-vapp.discovery.activated -v false

This behavior can be overridden at Org VDC level with API element <VmDiscoveryEnabled>.

Here are the differences between Discovered and Adopted vApp:

Discovered vApp

  • Looks like a regular vApp
  • Can have only one VM per discovered vApp
  • vApp contains API element <autoNature>true</autoNature>
  • When imported VM is deleted in VC or VCD, its vApp object will get automatically purged
  • Is owned by system
  • Is not subject to Org lease settings

Adopted vApp

  • Regular vCloud Director vApp
  • Can contain multiple VMs, vApp networks, etc.
  • Discovered vApp will get adopted when it is reconfigured (other than changing its name or description)

Other Considerations

  • Discovery process runs in the background every 3 mins
  • Failed VM import is retried after 60 mins. This can be changed with CMT command (example for 25 seconds):
    cell-management-tool manage-config -n managed-vapp.discovery.retry-delay-sec -v 25
  • The following VMs cannot be imported: Fault Tolerant VMs, VMs with creation/upload process in VC, templates, VCD shell VMs
  • VM must be connected to Org VDC network.
  • VM can be running or powered off.
  • VM does not need to use Org VDC storage policy. If it resides on unknown storage policy, it is automatically relocated to the default Org VDC storage policy during the adoption however the VM must be in powered off state.
  • VM with IDE controller must be in powered off state.
  • VM CPU/RAM resources are changed based on Org VDC allocation type.
  • VM resources are not subject to Org VDC allocation restrictions, but are charged against it.
  • VM name in VC remains intact until it is adopted and renamed
  • New vSphere 6.5 guest operating systems are not recognized and are imported as Other (32-bit) OS.

Update 4/24/2017

  • By default there is minimal VM age configured to 1 hour. It means VMs that were freshly reconfigured will be skipped for the import. This is to ‘settle’ the VMs first. The interval can however be changed with CMT command (age set to 60 seconds):
    cell-management-tool manage-config -n VM_DISCOVERY_MIN_AGE_SEC -v 60
  • Related to the minimal age, it is important that all cells and vCloud database are using the same time configuration. Not only the time must be correct but also the time zone must be configured identically.

28 thoughts on “vCloud Director 8.20: VM Auto-import

  1. Hey Tom!

    Does this now allow support for the import of large VMs that span multiple underlying datastores but share the same storage policy? I would think that it would, seeing that vCloud supports multi-tier storage policies per VM now.


  2. Hello Tomas

    Thanks for this. I’m not sure I understand “VM resources are not subject to Org VDC allocation restrictions, but are charged against it”. Could you please illustrate with an example?


    1. My understanding was that VM can be imported even if it breaches Org VDC allocation limits (as it is system admin driven action). However, from my brief testing that is not the case and I was not able import VM if it would breach resource quota.

  3. Hello Tomas,

    Is there any API URL using which we can force manual discovery of VM moved to resource pool backing VDC. Somehow i am not getting predictable result with VM auto discovery feature. As you mentioned auto discovery run after 3 minutes but sometimes its taking lot many hours to show VM as discovered. i tried looking for clues in logs to determine if its failing but cant trace anything to get the clue. Also i find limited documentation with respect to this feature in vCloud Director admin guide

  4. Hi Tom, I echo vBahubali’s comment above. It took over 2 hours for my vCD instance to pick it up.

    1. Check if your cells and vCloud DB server have proper time set (including same time zone). Also you can open ticket with GSS who have special tool that helps troubleshooting the reason why VMs fail to import.

  5. Tom, I have a separate question on this subject. Here’s some context first:

    I am evaluating the Rubrik appliance. Rubrik does not have a vCD integration at this time, but I need to overcome that limitation. I used the Rubrik platform to perform a snapshot of a vCD-managed VM via its vCenter integration. I performed a “Instant Recovery” of that VM using the Rubrik platform. The original vCD vApp (single VM) is stopped and the original vCenter VM was renamed by Rubrik. The recovered VM is a new VM object and shows up as a vCD-managed object in vCenter (expected), and vCD has no knowledge of this new VM (expected). So here’s the question…

    I moved the recovered VM into the vCenter resource pool corresponding to the vCD OVDC of the original vApp. The recovered VM is not discovered by vCD. I suspect it’s because it appears in vCenter as “managed” by vCD. Can you confirm this is exepcted behavior in regards to this new vCD feature? FYI, a non-vCD-managed is discovered successfully.


  6. Correction on the last sentence of the last post:
    FYI, a non-vCD-managed VM is discovered successfully.

    1. VCD tracks cloud.uuid stored in the vmx file of the VM. If you restored the original VM and the cloud.uuid is identical VCD is confused as it sees the same VM twice. If you delete the original VM from VC (but not from VCD) and then restore it with Rubric, VCD should correctly discover it.

  7. Hi Tomas,
    as per the comments from others, the information from VMware in the Admin guide is very limited. While affinity and ant-affinity is shown on YouTube and is easily understood the vCenter adoption is no where to be found.
    Assuming a service provider has a dedicated vCenter for management and a dedicated vCenter specific for vCD virtual data centers. I will assume the process to “adopt a vCenter” is to add the new or client vCenter to vCD in the System, Home tab via the “add another vCenter” option?
    Could you please describe what happens at this point to the resources managed by the adopted vCenter (host, storage, networks, VMs, resource pools, etc) from the changes seen in vCD (how are the resources displayed and managed) and to the resources themselves?
    Would be very useful for VMware to display the adoption process fully on YouTube.

    1. Adopt VC consists of the following steps:
      1. Add VC under VCD management.
      2. Create new Provider VDC using resources from the added VC
      3. Organize workloads into resource pools
      4. Adopt RP to a new Org VDC (

      Note that in step 4 you need to define Org VDC properties, networks and storage policies and point to the RP within one single API call. This might be quite difficult and for example you cannot create Edge Gateways. So as an alternative, you can create Org VDC manually (with all networks, storage polices, etc) and then use the approach described in this blog post article by moving workloads into the RP created by the Org VDC. The workloads must use resources of the Org VDC (correct storage and networks).

      I find the second approach easier, that is why I did not spend time describing the adopt RP option.

      1. Thanks Tom, that clears a lot up for me. The ability is game changing for Service Providers and VMware should be prioritizing the marketing of this functionality.

        Finally around network migration. What happens when we adopt a vCenter that is connected to standard vswitches and we have a vCD backed by NSX, therefore vDS. Noting that we have are talking about the current versions as of this month for all VMware products. Assuming we adopt a vCenter successfully into a new PvDC, Org, vDC and new resource pools and the VMs are running. What is the process to change the VM networking to the vDS (NSX backed) networking? Is this simply changing the network connection or is there a migrate feature? Also is there an outage to change the networking?

  8. Tom,

    I don’t understand this log entry when I drag a powered on VM from a RP to an an RP corresponding to Org vDC within same cluster:

    2017-04-23 07:54:16,993 | WARN | VC-54bbe339-7851-4753-bc77-78c695d4e78dListener (861) | ComputeFabricImpl | Resource-Pool change of VM [vcId=54bbe339-7851-4753-bc77-78c695d4e78d, moref=vm-301] from [vcId=54bbe339-7851-4753-bc77-78c695d4e78d, moref=resgroup-42] to [vcId=54bbe339-7851-4753-bc77-78c695d4e78d, moref=resgroup-285] in VC is not supported because the source and destination resource pools are not part of same elastic PVDC |

    Does this mean the cluster has to be dedicated to the PDVC (I map PVDC to a RP, not a cluster) or VM should be dragged from another cluster?


  9. Hello Tomas,

    Hope you are doing fine. Reason for asking regarding which operation to use to adopt is provided below.

    VMware vCloud Director 8.20 admin guide states below:

    “You can adopt a discovered vApp by invoking an operation that modifies it in any way other than a change to its name or description”

    First something about autoNature parameter from REST API Guide:

    “When retrieved with a vCloud API request, the autoNature element in a discovered vApp has a value of true. This value changes to false when the vApp is adopted”

    My understanding from above statement is if this parameter change from True to false a vApp should be considered adopted

    Now my observation from my LAB

    Auto discovery completed for virtual machine. I used REST API to determine autoNature Paramter value which was true


    For a discovered vApp i just modified name of vApp and then again verified autoNature parameter to see if it changes and it changed to false


    Here is my confusion. VMware admin guide document suggest that change in name should not lead to adoption of vApp, however after name update parameter autoNature change to false.

    Would you be able to suggest if this is intended behaviour and admin guide statement requires update or my observation regarding adoption is not correct. Any feedback would be helpful in this regard

      1. Hello Tomas,
        Thank you for your reply! vApp Name modification i did from UI. Right Click Discovered vApp -> Properties. Changes vApp Name from Discovered – – to other name.

        I used below mentioned API URL to retrieve information for vApp immediately after discovery and after name modification to determine change for autoNature Parameter

        Method: GET
        URL: https:// /api/vApp/

        vCloud Director Version

  10. FYI – The AutoImport Logs can be found in “/opt/vmware/vcloud-director/logs/vcloud-container-info.log” if you are looking for why the import has failed.

  11. Hi,

    Thanks for this article.
    I also used this usefull command for troubleshooting : /cell-management-tool debug-auto-import

  12. Quick Question concerning vCloud Director 9.0 when performing a live import of a VM when looking in vCenter it creates a clone of the running VM before performing the import is the default behavior. It removes the other VM after the import is complete. This takes sometime longer to complete why not just perform a import like importing a VM from a LUN into vCenter. It seems as if its really not importing a live VM its importing the clone which is initially powered off until the import is complete then the other VM is powered off and deleted. Please correct me if I’m wrong

    1. That is not correct. Auto discovered VM is imported without any cloning operations. All you will see in VC are reconfigure operations on the VM done by VCD to change its resources, apply custom field, and add vCloud UUID.

  13. Hi Tom

    There is a statement: The following VMs cannot be imported: Fault Tolerant VMs, VMs with creation/upload process in VC, templates, VCD shell VMs

    What a vCD shell VM is ?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.