vCloud director – running MAC OS X and Windows VM in same vApp.

Recently we installed in Mac Pro 6,1 hardware and provided MAC OS X virtual machines to our vCloud director environment.

This was configured in a separate cluster in vCenter server which provides all the regular capabilities like HA, DRS and vMotion which is great. Also created a separate storage cluster and assigned a new MAC storage profile to this cluster which was made available within vCD.

MAC OS X templates was created and added to catalog with storage set to pre-provision on default storage profile create for MAC cluster.

Problem: 

In vCloud director a new Provider VDC was created and linked to the new vCenter server cluster.
Within the existing Organizations we created an additional virtual datacenter with MAC provider VDC selected.  This created new resource pool in the cluster.

The users where now able to deploy MAC OS templates to this VDC, however a request came back quickly that users need to deploy both MAC OS X and Windows VM within the same vApp.

Troubleshooting: 

The configuration as explained above obviously does not allow for this situation since during deployment of vApp you can only select a single VDC to deploy too as well for adding a VM you can only specify a single storage Policy, which will also be the one assigned to vApp’s VDC .  So all the VMs would need to run on the Apple hardware cluster which is not idea.

Solution:

Solution was pretty simple and can be accomplished by merging your provider VDC’s which was introduced in vCloud director 5.1.1.

  1. Login to vCloud director as system admin.
  2. Select Manage & Monitor
  3. Under Cloud resources select Provider VDCs
  4. Right click the MAC provider VDC and select Merge
  5. Select the Provider VDC that you want this merge with.
  6. After completion you will now see your Provider VDC has  additional resource pool, datastores and ORG VDCs
  7. I then went ahead and deleted the VDC I initially created for the MAC deployments since only need the original VDC.
Now when you deploy a vApp select the existing VDC which contains the MAC Provider VDC and storage profile.  Same can be accomplish for deploying VM within a vApp.

vCloud 5.5.1: Create new storage policy, add storage, migrate vApps.

We recently purchased new storage so the new datastores had to be added to vCloud director, and all the vApps migrated over.  There are many ways to go about doing this but the best solution I found was to create a new storage cluster and put all datastores in it and also create a new storage policy and profile.  I have been told it is also possible to just perform a storage vmotion on the VM’s but i had mixed results with this approach.  Here is my information which I hope might be useful to someone.

In Vcenter server:
  1. Create tag category (I called mine “storage policies” to keep it simple”, but description can also be used to describe the function)
  2. Create tag and add to category
  3. Open VM storage policies
    1. Create new VM storage policy
    2. Select vCenter
    3. Enter a policy name
    4. Provide description
    5. Add tag-based rule and assign newly create tag from tag category.
  4. I ALWAYS FORGET to enable the policy so here is not to you doing the same 🙂
    1. select the new policy name
    2. 2nd icon from left is “Enable VM storage policies per compute resource.
  1. Assign the newly created tag to datastore cluster
  2. Assign the newly created tag to each datastore within the cluster.

In vCloud director:
  1. Under Manage & Monitor tab select vCenters from vSphere resources.
  2. Right click the vCenter server name and select  “refresh storage policies
After you get the storage profile to show in storage policies you have to assign it:
  1. Go to Provider VDC and open it
  2. Select storage policies tab
  3. Add new storage policy! 
  4. There is a BUG in 5.5.1 which does not refresh or show the storage policy and an outage is actually necessary to clean up the database with a script (not very nice but works)
  1. Go to Organizations and open the one which will be using the new storage
  2. Select Virtual datacenter tab
  3. Select Storage policies tab
  4. Add the new storage policy
  5. If you want the new policy to be the default – Right click the new storage policy and select “Set as default”

Migrating vAPPS to new storage profile:

  • The best method I found was to shutdown the vAPP and right click select “move to” and then each individual VM select the new storage policy.
  • You can also do this with a powered on VM and go to properties and change the storage polic

vCloud Director: Error on provider VDC "No datastores accessible to VDC "

This normally happens when a new datastore is added to the storage cluster which is associate to a storage policy for the vCloud Director Organization.  The rule-set (storage capability) was not properly set to the datastore before it was added to the datastore cluster.

All the datastores, datastore clusters and policies disappear and you get the following errors:

Error on provider VDC:
No datastores accessible to VDC

On Provider VDC storage policies tab:
This storage policy is not backed by any usable datastores accessible from this VDC.
There is no usable datastore accessible from this VDC that supports this storage policy. Ensure that this storage policy is backed by at least one datastore in vCenter Server, this datastore is enabled in vCloud Director, and the datastore(s) are accessible by the hosts in the clusters used by this VDC.

Solution:

Verified that all the datastores in the datastore cluster have the storage capability (Tag) assigned which is associated to the provider VDC.

Check Compliance of the VM Storage profile in vSphere Web client

  • On Home page, select Vm Storage Policies.
  • Right click the storage policy and select “Check compliance”
  • Select the VM Storage Policy
  • Verify everything compliant
  • Select Monitor tab
  • Select Matching Resources
  • Verify that the datastore cluster is showing up as well as all the datastores
Refresh storage policies for vCenter on vCloud Director System.

  • In vCloud Director, under vSphere Resources select vCenters.
  • Right click on the vCenter name and select “Refresh Storage Policies”

vCloud director 5.5: Catalogs problem #3 – Assigning catalog media files to different VDC within an ORG?

We have a public catalog which is shared to all ORGs within vCloud.  This also contains some ISO media files for users to mount to cdrom of virtual machines.
However in order for a user to make use of a media file from a public catalog, that media file firstly needs to be copy to the local catalog of that ORG.

Within this ORG we have multiple vDCs.  This is where things get interesting.

Scenario:

When a vAPP is deployed from catalog you assign this vAPP to a specific vDC.
When you then try to mount an ISO from the local catalog media files, you are unable to do so since this media file is associate to a different vDC…mmm

Troubleshooting:

I believe the problem lies with how the Catalogs are done in 5.5.  When creating or copying files into a Catalog, there is no method to accurately control where the item will be stored. This is more critical when there are multiple Org vDCs, and a file could be placed in an Org vDC to which the file is not intended for.

This is a departure from vCloud Director 5.1, where importing media allowed you to select a specific Organization vDC. Even when you could select a vDC, you still needed to have the ISO image in the vDC where the VM resides to be allowed to insert it.

I had a lot remote sessions and discussions with support on this issue since we could not find a way to assign a media file to specific VDC.

Workarounds:

Option 1 –  Temporarily disable storage profiles before doing an ISO import. This would eliminate certain vDCs as an option, and force the selection process to go to the remaining vDC.  this would be my recommendation.

Option 2 – Set the catalog to use a specific Storage Profile, from the desired Organization vDC and import the media again. This should send the imported files to the correct ORG vDC. You will need to import Media files multiple times to accomplish this.  This only possible if you have multiple storage profiles which I currently do not have.

Option 3 – Have a catalog specific to an individual ORG vDC, name the catalog relative to the ORG vDC, and select the Storage Class/Profile from the same ORG vDC. This means that any ISOs will be sent up to the correct vDC when you import to a given catalog.  On this option here are the steps to setup more catalog for more than one vDC:
1. Create a “master” catalog in the ORG on the Storage Profile vDC A
2. Publish the Catalog created in Step 1 externally
3. Create a “slave” catalog in the ORG on the Storage Profile vDC B, and have this catalog sync from the catalog created in step 1.
4. Repeat this to have Catalog C on Storage Profile C, and sync to Catalog A.
5. Whenever you add a new ISO image to the Master Catalog, it will automatically update the others in 24 hours or when a sync is requested.

vCloud director 5.5: Catalogs problem #2 – Error mounting catalog media ISO files to CDROM – "This media type is incorrect. Media type ISO was expected." (known issue)

Catalogs has had quiet a big revamp in vCloud 5.5 with some enhancements.
This can be read in the “whats’s new” pdf:
http://www.vmware.com/files/pdf/products/vCloud/Whats-New-VMware-vCloud-Director-55-Technical-Whitepaper.pdf

We have a public catalog which is shared to all ORGs within vCloud.  This also contains some ISO media files for users to mount to cdrom of virtual machines.
However in order for a user to make use of a media file from a public catalog, that media file firstly needs to be copy to the local catalog of that ORG.

Problem:

A users copies the media ISO file to local catalog however the file is not copied over correctly.
When users tries to attach the newly copied file from media to CDROM, the following error is observed:
“This media type is incorrect. Media type ISO was expected.”
Troubleshooting:

The original media file for public catalog I am able to mount to CDROM on all VM’s within that catalog.
Once that same media file is copied to local catalog I experienced the problem.
When I uploaded the same media ISO file directly to users catalog I was able to mount the file.
Solution:
No solution as of yet but workaround is to update the tables directly in database.
I just went ahead and uploaded the needed ISO files directly to the local ORGs catalog media files.
I was also able to locate the knowledge base article for the issue mounting ISOs after copying them between catalogs. This article includes the required process on the Database side to correct the ISO/Media bits for the catalog items.

vCloud director 5.5: Catalogs problem #1 – browser crashes on "copy to catalog" (resolved)

Catalogs has had quiet a big revamp in vCloud 5.5 with some enhancements.
This can be read in the “whats’s new” pdf:
http://www.vmware.com/files/pdf/products/vCloud/Whats-New-VMware-vCloud-Director-55-Technical-Whitepaper.pdf

We have a public catalog which is shared to all ORGs within vCloud.  This also contains some ISO media files for users to mount to cdrom of virtual machines.
However in order for a user to make use of a media file from a public catalog, that media file firstly needs to be copy to the local catalog of that ORG.

Problem:

When a user log in directly to their respective ORG
Select the public catalog and go to media tab
Right click on media file select to “copy to catalog”
The browser crashes and restarts without any error messages.

Troubleshoot:

This was tested on MAC and Windows with each of the following browsers including Chrome, Firefox and Internet explorer.
Same problem appears when logged in as ORG or system admin.

However it works fine when I login as system admin to main vCloud Director login page.  Only seems to crash browser when logged in direclty to any ORG site.

Solution:

Do not share the catalog with the radio button “all organizations”, but rather select all the ORGs individually from the list.

I do not experience the same results as listed the following KB but same solution solves both problems:
http://kb.vmware.com/kb/2063431

vCloud Director 5.5 – Replace current self-signed certificates with signed certificates

Initially I had very little time to get vCloud Director up and and running and just created self signed certificates.
After upgrading from vCloud 5.1 to 5.5, we found a known problem with VMware where MAC desktops cannot access VM console when using self-signed certificates.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058496

This provided the perfect opportunity to replacing initial self signed certificates with newly created signed certificates. (internal root CA server)

Prerequisites:
SSH to vCloud director:

  • verify ip addresses used for vcloud  (ifconfig -a)
  • run “nslookup ” to identify the FQDN for both http and consoleproxy IP address.  This will also verify that reverse lookup is working correct.

Example:
10.30.15.100 (http)                      vcloud.company.corp
10.30.15.101 (console proxy)       vcloudcp.company.corp

Some considerations before creating new certificates:

  • I already have a Java keystore file /certs/certificates.ks which is currently configured for the self signed certificates. I decided to create a new Java keystore file called “sslcertificates.ks”.  This is not necessary but I wanted to keep the files easily distinguishable.
  • The new Java keystore file i moved to a new folder called /sslcerts/.  This again is not necessary can can keep in original folder or create different one.
  • You can create the new certificates and CSR while vCloud services are running.  You however need to shutdown the vCloud services before you run the configuration script.  Outage required during this short period.


Steps:

  1. SSH to vcloud director (we currently run vcloud on RHEL)
  2. Change folder /opt/vmware/vcloud-director/jre/bin/
  3. Run command to create new keystore file for HTTP:
    • # keytool -keystore sslcertificates.ks -storetype JCEKS -storepass ******* -genkey -keyalg RSA -alias http
      • Keytool utility will prompt for responses to several question. Replace the example input in italics with the information relevant to your environment:
      • What is your first and last name? [Unknown]:                         vcloud.airwatch.corp
      • What is the name of your organizational unit? [Unknown]:       vCloud
      • What is the name of your organization? [Unknown]:                Company
      • What is the name of your City or Locality? [Unknown]:            City
      • What is the name of your State or Province? [Unknown]:         State
      • What is the two-letter country code for this unit? [Unknown]:   US
      • Enter password for http or select option for same password as in command
  4. Run command to obtain CSR for HTTP service:
    • # keytool –keystore sslcertificates.ks –storetype JCEKS –storepass ******* –certreq –alias http –file http.csr
      • This creates a file called the http.csr
  5. Run command to create new keystore file for Console Proxy:
    • # keytool –keystore sslcertificates.ks –storetype JCEKS –storepass ******* –genkey –keyalg RSA –alias consoleproxy
      • Keytool utility will prompt for responses to several question. Replace the example input in italics with the information relevant to your environment:
      • What is your first and last name? [Unknown]:                         vcloudcp.airwatch.corp
      • What is the name of your organizational unit? [Unknown]:       vCloud
      • What is the name of your organization? [Unknown]:                Company
      • What is the name of your City or Locality? [Unknown]:            City
      • What is the name of your State or Province? [Unknown]:         State
      • What is the two-letter country code for this unit? [Unknown]:   US
      • Enter password for http or select option for same password as in command
  6. Run command to obtain CSR for Console Proxy service:
    • # keytool –keystore sslcertificates.ks –storetype JCEKS –storepass ******* –certreq –alias consoleproxy –file consoleproxy.csr
      • This creates a file called the consoleproxy.csr
  7. Copy the http.csr and consoleproxy.csr files that were just create to your local machine. I use an appliciation called WinSCP.
  8. Go to Windows CA certificate server website “https:///certsrv/” and perform following tasks for both the http and consoleproxy CSRs:
    • request certificate
    • advanced certificate request
    • Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
    • Open the csr file and copy/paste the text into field.
    • Select certificate template = “Web Server”
    • Submit
    • Select “Base 64 encoded”
    • Download certificate, which will provide a certnew.cer file.
    • Rename the file to be specific for example “_certnew.cer”
  9. Lastly download the root CA certificate.
  10. Copy all 3 certificates to vcloud server and import them into the keystore with following commands:
    • Import the root certificate:
      • # keytool -storetype JCEKS -storepass ******* -keystore sslcertificates.ks -import -alias root -file root_certnew.cer
    • Import the http service certificate:
      • # keytool -storetype JCEKS -storepass ******* -keystore sslcertificates.ks -import -alias http -file http_certnew.cer
    • Import the console proxy service certificate:
      • # keytool -storetype JCEKS -storepass ******* -keystore sslcertificates.ks -import -alias consoleproxy -file console_certnew.cer
  11. To verify that all the certificates are imported, list the contents of the keystore file.
    • # keytool -storetype JCEKS -storepass ******* -keystore sslcertificates.ks -list
  12. Move the certifcate.ks file to new folder:  /sslcerts/sslcertificates.ks
    • “mv /opt/vmware/vcloud-director/jre/bin/sslcertificates.ks /sslcerts/”
  13. Now configure vCloud Director to use the new SSL certificates:
    1. Stop vcloud services “service vmware-vcd stop”
    2. Run following command:
      1. # opt/vmware/vcloud-director/bin/configure
        1. Provide the path to the keystore file  /sslcerts/sslcertificates.ks
        2. Enter passwords
        3. Yes to start the vCloud services.

Now your vCloud should be using newly created certificates.

vCloud Director upgrade from 5.1 to 5.5

Current Version:

5.1.2 Build 1068441 vmware-vcloud-director-5.1.2-1968441.bin

New Version:

5.5.0 Build 1323688  vmware-vcloud-director-5.5.0-1323688.bin

I run a RHEL virtual machine with vcloud director installed, so before starting the upgrade I fully patch the RHEL environment.

PRE-CHECKLIST:

vCloud director 5.5 release notes:
https://www.vmware.com/support/vcd/doc/rel_notes_vcloud_director_55.html#sysreqs
Pre upgrade checklist for potential edge gateway problems:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2058977
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2060065

Upgrading vCloud director documentation from VMware which I recommend reading:
http://pubs.vmware.com/vcd-55/index.jsp?topic=%2Fcom.vmware.vcloud.install.doc_55%2FGUID-CEF834DA-1FF5-4819-9D24-88DE6F005C78.html

  1. As always, first off start with BACKUPS
    • Create snapshot of vCloud Director virtual machine.
    • Stop the vcloud services
    • backup the vCloud database.  We have a SQL server were the database resides.
    • Create another 3de party backup.  In my case i made use of Commvault to take a snapshot backup of the VM as well.
  2. Copy the downloaded bin file to vcloud director server.  I place the file in /tmp folder.
  3. Verify the MD5 checksum-value of file
  4. chmod u+x to make it executable.
  5. Stop the vcloud director services on server.
  6. Run the file installation file by typing “./”
  7. Respond to the upgrade prompts.
  8. Once completed DO NO start the vcloud services, firstly upgrade the vcloud database.
  9. Run /opt/vmware/vcloud-director/bin/upgrade
  10. Respond to upgrade prompts.  I did receive an error here which i explain at bottom of this blog!
  11. Once completed vCloud service should now be started.
  12. Upgrade vShield.
  13. From the vShield Manager Inventory panel, click Settings & Reports.
  14. Click the Updates tab.
  15. Click Upload Upgrade Bundle.
  16. Click Browse and select the VMware-vShield-Manager-upgrade-bundle-maintenance-5.1.2-997359.tar.gz file.
  17. Click Open.
  18. Click Upload File.
  19. Click Install to begin the upgrade process.
  20. Click Confirm Install. The upgrade process reboots vShield Manager, so you might lose connectivity to the vShield Manager. None of the other vShield components are rebooted.
  21. Verify the maintenance update has been applied

After you have upgraded vShield manager, you must upgrade all vCenter servers and hosts before you upgrade the vShield Edge appliances that the upgraded vShield Manager manages.

To upgrade ESXi host to 5.5 as well as upgrade the vCloud agent, perform the following steps in conjunction with vCloud director:

  1. From vCloud Director right click host and select disable the host
  2. Right click same host and select “Redeploy all VMs 
  3. On vCenter Server put the ESXi host into maintenance mode
  4. Attach host upgrade and patch baseline to ESXi server.
  5. Remediate host
  6. Once complete from vCloud director right click host and select “Upgrade host agent”
  7. Take host out of maintenance mode and wait for vSphere HA agent install to complete
  8. Within vCloud Director you can enable the host again.
To upgrade the vShield Edges:
  1. Login to vshield
  2. Select the datacenter for which you want to upgrade.
  3. Select network virtualization tab
  4. Select Edges
  5. Select the edge and click on actions -> Upgrade.
  6. I did find that after the edge upgrades the users was not able to get connection through the vCloud Edge gateway.  To resolve this i redeployed the Edge gateway with following steps:
    • Login to vCloud
    • Select organization
    • Select VDC
    • Select Edge Gateway tab
    • Right click edge gateway and select Re-Deploy.  
    • This will recreate the edge gateway but will not loose any settings configured on it.

Upgrade problems experienced:

During step 9 of database upgrade I received the following error message:
Error:   Unable to update database statistics. Database user has insufficient privileges to update database statistics. To complete this step manually, run ‘EXEC sp_updatestats’ as the DBO or a member of the sysadmin fixed server role.
Fix:   On the database server (SQL) provide the vCloud user account with sysadmin server role.  Run the command as provided in error against the database.

Error:  http error 500  after upgrade when opening the vCloud director login page
Fix:       Add the text“login.jsp” to the end of the vcloud page URL so you could use a local login.  Then disabled SSO under federation services within vCloud director if you are not using it.  I my case we make use of windows authentication and not SSO.

Setup ORG VDC within vCloud Director


I have put some bullet points together for myself to setup a new Organization with Org VDC.  Might be useful to someone else. Nothing advances and if you are a beginner i would probably view another blog or VMware documentation for assistance.
1.      Vsphere client:
a.      Setup ESXi hosts
b.      Setup new Datacenter.
c.      Setup new cluster
d.      Setup two different vDSs, one for management/vmotion and one for external & VCDNI    networks.  If setting up VXLAN, I would recommend setting up a separate vDS for this.
e.      Create port groups for external networks within 2nd vDS which was configured.
f.       IF VXLAN used, prepare the new vDS for VXLAN
                                                    i.     http://blogs.vmware.com/vcloud/2012/10/vcloud-director-5-1-vxlan-configuration.html
g.      Create storage profile.
                                                    i.     Create Storage capabilities.
                                                   ii.     Create Storage profile and assign storage capabilities to profile.
                                                  iii.     Assign Storage capabilities to datastores within created cluster
                                                  iv.     Make sure to enable the storage profile! (very often overlooked)
2.      vCloud director:
a.      Create Provider VDC
                                                    i.     Select previously created cluster
                                                   ii.     Select storage profile.
                                                  iii.     Select host to prepare.
                                                  iv.     Done
b.      Setup new Organization
                                                    i.     Simple setup wizard and very easy to follow and understand
c.      Setup network pool for virtual switch.
                                                    i.     Select network pool type ( I pick network isolation-backed for simplicity)
                                                   ii.     Specify VLAN and max VCDNI networks.
                                                  iii.     Select vDS created before.
d.      Setup external network and link to port groups created for external networks.
e.      Create ORG VDC
                                                    i.     Select organization
                                                   ii.     Select Provider VDC
                                                  iii.     Select allocation model.
                                                  iv.     Configure model. (for our QA/DEV labs I prefer pay-as-you-go)
                                                   v.     Allocate storage
                                                  vi.     Select network pool
                                                vii.     Configure Edge Gateway
                                               viii.     Select external network
                                                  ix.     Set IP addresses
                                                   x.     Sub-allocate IP Pools
                                                  xi.     Create ORG VDC network
                                                xii.     Name ORG

vCloud Director – Migration of storage to new storage profile

Scenario:
Migration from local direct attached storage on single ESXi host to more flexible environment with multiple ESXi host with new shared storage profile.
Some considerations:
  • The migration will create full clone VMs on new storage profile so please take the storage usage into consideration before starting the move.  Look at thin provisioning on VMs hard disk.
  • Can you afford to shut down the VMs or not for migration, this will affect your effort.
  • Just not vAPPs needs to be moved, also remember your vAPP templates and media.  I would start with the vAPPs and media first.

Within vSphere client:
Go to VM storage profiles (normally accessible from the main home screen on both regular and web client.
Select “Manage storage capabilities”
Create a new storage capability and provide name
Done
Select “Create VM storage profile”
Provide name
Select the storage capability just created before
Done
Create storage cluster within the datacenter which is assigned to your Provider VDC.
Add the shared storage datastores to the cluster.
Verify that all the datastores are seen by the ESXi hosts.
Very important, and i have forgotten this which will cause users to be unable to deploy vAPPS:

  • Within Vcenter client select the datastore, right click and select “Assign User-defined storage     capabilities” 
  • From drop down select the previously created storage capability.
These datastores should now be visible within vCloud director.
Within vCloud director:
There are a few ways to migrate your vAPPS over to the new storage profile, which is really refreshing to see multiple options and this certainly did become very useful for us since there is a bug in vcloud 5.1.2.1068441 for making use of the “move to” feature and your IP/Mac addresses are not retained. 
(Previous post describes the symptoms and workaround)
Taking the above bug into consideration for retaining MAC/IP, and the different workload involved with each here are the ways to migrate over.
Method 1:
Take into consider that in my version 5.1.2.1068441 when you perform this task it will not retain the MAC/IP source addresses and if you have NAT’s configured for VM’s on the Edge gateway this will not work anymore and you have to recreate these with new ORG ip assigned to VM.  Subsequent version will probably have this resolved so not an issue. Run a test before moving production vAPPs!
1. Shut down your vAPP, right click and select “move to”.
2. Next to each VM, click drop down box and change the storage profile to the newly created.
3. Perform this for each VM and select OK
4. Done, and super easy!
5. The same steps can be used for vAPP templates and media.
Method 2:
This method requires a lot more effort but also find that you can do perform a hot storage vmotion, which means you don’t have to shut down the VM.  It will also retain the MAC/IP address of ORG VDC network. 
1. Open the vAPP.
2. Select the VM properties.
3. Under General tab scroll down to bottom and select from drop down the new storage profile
4. This will perform a storage vMotion on the backend which can be observed from vSphere client.
5. Perform this task on each VM.
This will however only move over the VM’s… the vSE (vShield Edge) VM which serves the network for the vAPP does not get moved over, so you have to do this manually through the vsphere client with storage vmotion.  ( NOTE: I perform this task with the supervision of VMware support and they do require that you have the latest versions of ESXi and Vcenter server installed. Perform at own risk and I take no responsibility but this worked perfect for me without any problems.  Versions I currently have installed:
a. vCenter server 5.1.0 1123961
b. vCloud director 5.1.2.1068441
c. ESXi 5.1.0 1157734
Interesting result and resolution:
After I moved all my vAPPS, vAPP templates I reviewed the old datastores with Lctree application tool and it showed no VM’s anymore on the datastore, BUT when i go to vsphere client and look at datastore it shows a bunch of VM’s still associate to the storage..wow what is going on?
After some debugging I found that it is only the media files which are still linked to the VM as an ISO.  Just eject the CD/floppy from virtual machine by right click on VM within vCloud director.  
Resources:

A great tool to use to view the linked clones and any VM’s still on old storage profile datastores.