Storage Profiles are defined, organized, and configured in vSphere layer. All of the Storage Profiles created in vSphere layer will be available and presented to vCloud Director, depend on your choice. However *(Any) Storage Profile is neither created nor defined in vSphere, but yet it’s present in vCloud Director. The *(Any) Storage Profile is a unique object in a way, as this doesn’t exist anywhere else other than vCloud Director. The *(Any) Storage Profile encompasses all of the storage resources that are presented and available to the hosts used in vCloud Director. This will also includes local storage (if any).
Yes you heard it right, it will include local storage as well if connected to the hosts.
Now if you want to learn more about *(Any) Storage Profile then I would suggest to read Rawlinson’s Post.
This post is to educate all of the VMware vCloud Service Provider or any one one for that matter, who is running VMware vCloud Director 1.5 and planning to upgrade it to 5.1.
So let me tell you what happens when you upgrade your vCloud Director from 1.5 to 5.1 and what should you do to prevent/rectify it.
vCloud Director 1.5 did not have Storage Profile concept and indeed the *(Any) Storage Profile is not there as well. Now let me take an example. Lets say if you are running 2 pVDC and 4 OrgVDC each onto those two with vCD 1.5, once you upgrade your vCD Cell to 5.1, *(Any) Storage Profile will automatically get propagated to all of them.
Yes, you heard it right. It will get propagated to all of your pVDC, OrgVDC, vApps, VMs, Templates, Media etc.
So, that means all of your local datastore also will get inherited into vCD layer. Of course this is not something you want right?
Now let me tell you, this is our feature by design, irrelevant to what I think of it. It can create problem if you have local Datastore connected to your hosts, as it will inherit that as well. Do you really want your Cloud VMs to be deployed in your local datastore, of course not right?
But, provisioning inside vCloud environment has a different logic and it may pick up a local datastore as well. So, your task should be to prevent it as soon as you upgrade your environment.
It may take a lot of time depend on the size of your environment.
This could have been a relative big problem for those customers/SPs using multiple pVDCs per cluster (and with different LUNs associated to different pVDCs). In this case the *(Any) could create relatively big problem. However this is against our best practice right?
1) Best practice is 1 Cluster mapped to 1 pVDC not multiple.
In environments where best practice is maintained (ie all datastores assigned to 1 cluster = 1 pVDC), you should disable the local datastore, after the upgrade and they would be omitted from VM placement.
Now you may ask me, what about every other situation where our best practice was not followed.
Well, in those situations, you should do these steps:
1. Disable Local Datastore immediately after you upgrade the vCD Cell from 1.5 to 5.1
2. Create Storage Profiles at the vSphere layer and include the disks you need to include
3. When they surface in vCD you can then move your VMs to those Storage Profiles
4. When you are done the *(Any) should be no longer in use and can then be removed from the OrgVDC.
Remember all of your VMs, Templates and Media has to be moved to the newly created Storage Profile before you can delete the *(Any). If any object still has access to the *(Any) then you may face this problem as below:
Error is clear: “Storage Profile “*” cannot be deleted since it is currently is use.”
Please note: You (provider) can easily change the storage profile of any VM without powering it off. It can be done from GUI if you go to VM general properties. Changing Storage Profile from *(Any) to the newly created does not do any vCenter operation, however changing to a different (Gold>Silver) initiates svMotion.