Re-registering a vCloud virtual machine in vCenter

There may be a time when you need to re-register a vCloud virtual machine in vCenter.  This may happen because a VM was un-registered on accident or during troubleshooting.
The VM that I’ll use in this example is named “unregister (0e68e734-ce66-4f29-87d6-15ca99dfc228)”
If we search the vCloud database, we can see the moref of this VM is vm-1946.  You will find this moref under the following tables:
  • computevm
  • licensing_vm_data
  • networked_vm
  • property_map
  • vapp_vm
  • vc_task_mapping
  • vm
  • vm_inv

select id, name,vc_id ,moref, cloud_uuid,instance_uuid from vm where name like ‘%unregister%’
select vm_inv_id, name,moref ,vc_id, cloud_uuid,instance_uuid from vm_inv where name like ‘%unregister%’

reregisteringvcloudvms-1

In the VM’s vmx file, we find the following UUIDs

uuid.bios = “42 2a f3 a0 9e 77 01 bd-52 17 99 78 64 8f f3 9d”
vc.uuid = “50 2a 53 a7 38 91 b1 06-a2 97 48 27 92 c7 a4 09”
cloud.uuid = “a8108db8-0778-43a7-bd4c-98ca588afa0d”
If you un-register and re-register the VM, the VM will keep the vc.uuid (instance_uuid in the database) and the cloud.uuid.  However, it will get a new moref.
After you re-register the VM, you may see two entries in the vCloud databases’s vm table.  Once the vCloud VC inventory services runs or you re-connect vCenter through vCloud, the old entry (moref vm-1939) will disappear.

reregisteringvcloudvms2

If you try to start the VM in vCloud, you will receive the following error

reregisteringvcloudvms3

Error: Could not find object with moref “vm-1939” and VC ID “e7d06012-3e60-4b3d-b6c8-22a9a2cff4d1” in inventory category “VirtualMachine”.If you search the vCloud database for this moref, you will find it under the following tables.

select * from computevm where vmmoref = ‘vm-1939’
select * from networked_vm  where moref = ‘vm-1939’

reregisteringvcloudvms5

We can resolve the issue by replacing the old moref in these tables with the new moref.  Find the new moref with the following query:

select moref from vm where name = ‘unregister (0e68e734-ce66-4f29-87d6-15ca99dfc228)’ > vm-1946

Update the tables with the new moref

update computevm set vmmoref = ‘vm-1946’ where vmmoref = ‘vm-1939’
update networked_vm set moref = ‘vm-1946’ where moref = ‘vm-1939’

At this point you were will be able to power on the VM, but there are other steps to take.  If you look vCenter, you will see that the VM looks like this:

reregisteringvcloudvms7

Notice that there is no solutions indicator.  We need to refresh vCenter through vCloud so that vCloud will mark the VMs that is it manages.

reregisteringvcloudvms6

Now the VM should look like

reregisteringvcloudvms8and the VM will show up as being managed by the vCloud solution.
Advertisements

Scheduling vCO workflows with curl and the REST API

There is an issue with vCenter Orchestrator 5.1.0 not running scheduled workflows (http://kb.vmware.com/kb/2041733). The KB says it’s resolved n 5.1.0 but it appears that it’s not. Until the issue is resolved, this post will show you how to schedule vCO workflow runs.

Say you have a workflow named BackupProviderVMs that you want to run every Sunday. First you need to find the workflow’s itemHref value. You can get this by running the following and replacing the vCO URL, credentials and your workflow name:

curl -i -k -H “accept:application/xml” -H “content-type:application/xml;charset=UTF-8” -u vcoadmin:password -X GET https://vco.example.com:8281/api/workflows?conditions=name=BackupProviderVMs

In my example the value of itemHref was https://vco.example.com:8281/api/workflows/A780808080808080808080808080808064B6808001326285598060aebf2a6a5a5/

itemHref will be used in the remaining command as such:

curl -i -k -H “accept:application/xml” -H “content-type:application/xml;charset=UTF-8” -u vcoadmin:password -X GET itemHref/…

You can view existing runs for the workflow by running:

curl -i -k -H “accept:application/xml” -H “content-type:application/xml;charset=UTF-8” -u vcoadmin:password -X GET https://vco.example.com:8281/api/workflows/A780808080808080808080808080808064B6808001326285598060aebf2a6a5a5/executions

The workflow can be ran with:

curl -i -k -H “accept:application/xml” -H “content-type:application/xml;charset=UTF-8” -u vcoadmin:password -X POST https://vco.example.com:8281/api/workflows/A780808080808080808080808080808064B6808001326285598060aebf2a6a5a5/executions -d @relocate-response

Where relocate-response is a file with the contents of:

<execution-context xmlns=”http://www.vmware.com/vco”&gt;
<parameters>
</parameters>
</execution-context>

The workflow can be scheduled to run by creating a crontab entry on the vCO server as such:

05 02 * * 0 /usr/bin/curl -i -k -H “accept:application/xml” -H “content-type:application/xml;charset=UTF-8” -u vcoadmin:password -X POST https://vco.example.com:8281/api/workflows/A780808080808080808080808080808064B6808001326285598060aebf2a6a5a5/executions -d @/usr/local/src/relocate-response