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.


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”

vSphere web client 5.5: Add new datastore to storage cluster with associate storage profile.

Adding a new datastore to vCloud storage profile has change just a little bit with vSphere Web client.
refer to my previous post to see the difference:

Information to know up front:
Storage policy/profile name
Storage capability (Rule-Set 1 Tag) – vSphere Web migrated the capabilities to Tags


Backend storage:

  1. This is normally handled by storage team which will provide the LUN.
  2. Since I am also the storage engineer I created the LUN from my Dynamic Pool on the Hitachi AMS 2100.

Within vCenter server web client:

  1. Right click the ESXi host from vCloud datastore
  2. Select “all vCenter actions”  from menu -> Rescan storage
  3. Only need to check the Scan for new Storage devices.
  4. Rick click the ESXi host again
  5. Select “New datastore”.
    1. Type – VFMS or NFS depending on block or file level storage.
    2. Datastore name
    3. Select version
    4. Partition size
  6. Go to vSphere web client home page.
  7. Select VM storage policies which will be associated to this datastore.
  8. Edit the VM storage policy, select Rule-set and write down the Tag name
  9. Right click the newly added datastore 
  10. Select “Assign Tag”
  11. Add the Tag to datastore for association to VM Storage policy.
  12. Now you can add the new datastore to the Datastore cluster.

Assigning Storage Profile/Policy: Difference between vSphere client and web client

The vSphere client makes use of the following terminology:
Storage profile
Storage capabilities

The vSphere web client makes use of the following terminology:
Storage policy
Rule-Set through TAGS

The main thing to take note of here is that Storage capabilities created in vSphere client is migrated over to TAGS within vSphere Web client.  These tags are then assigned to the VM Storage Policy through the rule-set.


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:

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.


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.


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.


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:

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:

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.


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.”

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.
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 #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.


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


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.


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.

Pretty Exciting news: VMware acquires AirWatch!

Being an AirWatch employee and also working with VMware products for 6 years I am very excited to be joining VMware and cannot wait to see what the future holds.  This is a great fit for both companies and a privilege to be part of this.

VMware to Acquire AirWatch for $1.54 Billion via @WSJ

AirWatch is thrilled to be joining VMware as our companies take a giant step forward in leading the Mobile-Cloud industry

VMware 5.5 error – Invalid datastore path ”. – When creating new Virtual Machine

A new problem I found in VMware 5.5 is when you try to create a new Virtual Machine.

Debugging the problem:

I have never had any issues with creating new Virtual machines from scratch.  However i had to create a new OS template and started the process but received error:  Invalid datastore path.

Looking online I did seem to find this error popping up alot but not related really to my problem.
I did test the following:
•Verify that datastore mentioned in the error is connected and accessible.
•Verify that the file exists in the datastore.

•Ensure that the file name does not contain non-Basic Latin characters.

Kind of figure the problem storage or permission from error message so  I went through my custom VM steps and under storage selection I always choose the Storage cluster and keep storage DRS enable so VMware make the recommendation of where to place the disks.  This is where the problem lies for some reason….


When you create the VM and under storage selection if you choose the storage cluster, make sure you disable Storage DRS for the VM and select the datastore manually.

This seems to have fix my issues and I was able to create the VM successfully.

Migration to host failed with error Already Disconnected (195887150)

This is the first time i ever ran into this problem after installing a new ESXi host.  Added the host to our current vDS, moved into cluster and disabled maintenance mode.
Thought might be related to our newly upgrade 5.5, however seems a lot of people ran into same problem.


Migration to host failed with error Already disconnected (195887150).
vMotion migration [169942327:1389120124781890] failed writing stream completion: Already disconnected
vMotion migration [169942327:1389120124781890] failed to flush stream buffer: Already disconnected

vMotion migration [169942327:1389120124781890] socket connected returned: Already disconnected

VMware KB found on problem:

I tried all the regular fixes:

  • vmkping to and from the vmkernel port used for vmotion
  • verify DNS
  • restart the management agent on host given error.
    • /etc/init.d/hostd restart
    • /etc/init.d/vpxa restart
  • Verified time on the both hosts
  • Turned off Enable Migration in the Advanced Settings of the host and re-enabled it.
    • vSphere web client -> Manage tab -> Settings tab -> Advanced System Settings
    • Search for “migration”
    • Find Migrate.Enabled and set to 0(disabled)
  • Unchecked vmotion on the vmkernel port and re-enabled it.
Still this did not resolve my problem.
Change the IP address of the MVkernel adapter for vMotion traffic.  This seems to fix the problem.  I then  also changed the IP back to original and problem was still resolved.
The vMotion VMkernel adpater IP address was previously used but not on this server since new server.

Cannot use vSphere Client to edit the settings of virtual machine of version 10 or higher

After upgrading to VMware 5.5.0 and you are also considering upgrade the Virtual machine compatibility from v9 to v10 I do recommend performing a snapshot or backup of the VM before hand:

You are no longer able to edit your Virtual machines through the vSphere client in v10!

If you still have users/employees connecting through the regular vSphere client, you might want to consider this or have them access the web client going forward.

Here are the hardware version features to consider: