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)

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.

26 thoughts on “vCloud Director 8.20: VM Auto-import”

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.

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.

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

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.

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.

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.

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.

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.

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?

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?

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

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.