How to Export Running VM from vCloud Director

In the past I have wrote how to import running VM to vCloud Director: here and here. Today, I will describe how to export running VM.

Let us first discuss why you would do it. There are several use cases:

• you want to manage the VM by a different Cloud Management Platform (for example vRealize Automation)
• you want to migrate (utilizing cross VC vMotion) to a different vCloud Director
• you want to move the VM to a different Org VDC

Currently (as of vCloud Director 8.20) there is no direct way to export running VM. So the procedure I will describe below is kind of a workaround. But let me first describe, what it means for a VM to be managed by vCloud Director.

• VM is ‘marked’ at vSphere level with Custom Attributes and ManagedBy extension.
• VM has its cloud_uuid stored in its configuration parameters
• VM has assigned CPU/RAM reservations and limits depending on its Org VDC allocation model
• VM is running in resource pool and folder based on its Org VDC/vApp
• VM has a name that includes its UUID
• vCloud Director is tracking the VM in vSphere inventory even if it changes its name, location and MoRef ID.
• vCloud Director is reserving VMs IP and MAC addresses in its IPAM.
• vCloud Director is counting VMs resources to its Org VDC allocation.

In order to remove the VM from vCloud Director management we must take care of all these points.

Here comes the procedure I came up with. It can obviously be automated with vSphere and vCloud APIs if needed for export of large amount of VMs.

First we clean up VM at vSphere level in vCenter Server:

1. Move VM outside the vCloud Director managed Resource Pool (this is to avoid auto-import of the VM)
2. If necessary reconnect VM to network not managed by vCloud Director (this is for situations where the vApp or Org VDC network is going to be deleted later). Obviously as the VM is running, the new network should provide equivalent connectivity as the original one (either with L2 bridging or routing).
3. Remove cloud-uuid from the VM configuration parameters. This can be done on running VM with PowerCLI:
   (Get-AdvancedSetting -entity $vm -Name cloud.uuid)|Remove-AdvancedSetting
   
4. Remove vCloud Director related Custom Attribute values (in my case VCD_fojta_01). Do not remove the whole Custom Attribute, just the value.
   
5. Remove ManagedBy extension from the VM. The easiest to do is leveraging PowerCLI script attached to KB 2032366. You will see the VM icon has changed after the extension has been removed.
   \ManagedBy.ps1 -Cmd Clear -VMs $vm
6. Remove VM resource reservation and limits (if applicable).
   
7. Rename VM (to get rid of UUID in the name).
   Now we need to take care of removing VM in vCloud Director, however even though we removed its cloud-uuid vCloud Director still sees the VM through its vCenter MoRef ID. And we cannot change MoRef ID of running VM. So here comes the workaround:
8. Temporarily remove access to the VM for vCloud Director service account (account configured in vCloud Director for the particular vCenter Server). To do so, you assign No Access role permission on the VM object for the service account user.
   
9. Now the VM has become invisible for vCloud Director and we can clean it up in vCloud Director. First Force-Stop its vApp.
   
10. Now Delete the vApp. Ignore the error.
    
11. Purge the vApp from stranded items with Force Delete.
12. Now we can remove the temporary no access role permission from step #8.
13. Clean up the vApp folder in vCenter Server if it was not removed.

Quite lengthy and not pretty procedure, however we did not do anything unsupported (like editing vCloud database) and the VM has been properly removed from vCloud Director inventory.

Last comment is about VM MAC addresses. If the VM was created in vCloud Director it will have MAC addresses from the vCloud Director range based on VCD installation ID. Have that in mind when moving VM around as duplicate MACs could be generated.