We are in the process of migrating from vRA 7.6 to vRA 8.5. One of our migrated blueprints / cloud templates is failing to deploy. Looking at the Infrastructure -> Activity -> Requests log, it boils down to this error:
It DID select the right host, and it does the list the desired datastore. What I don't understand, nor do I see described anywhere, are what the "matched storage profiles" are. Based on my basic understanding of capability tags, I THINK they are right. But I sure wish I could see a list of matched storage profiles (we only have 2 in the system...) to understand what it filtered based on.
Is that information listed somewhere that I am missing?
I sort of got it to work, but only as a temporary thing.
Basically, we have two storage profiles that relate to each of the vSAN data stores of our two backing vSphere clusters. One of the clusters is kind of general purpose, the other is special purpose.
The general purpose storage profile is set as the "default for the region". With that configuration, it fails. However, if I set the other profile as the default, THEN it succeeds. But our cloud templates for general purpose then start throwing the error...
That suggests to me this has nothing to do with tags/capabilities that are matching things like I initially thought.
We struggle with storage profiles as well (8.4.1 currently). In fact I just added a storage profile for a new cluster we're testing and got the same error as you. It's frustrating as this isn't well documented and the request details don't really show you what's going on.
You can export the request details as json - Infrastructure->Requests->your request->Export. It's really hard to follow what's going on but searching for things like "SelectedStorageProfile" or "selectedStorageItemId" might help track down which storage profile was selected.
Maybe they changed the format for some reason? But not terribly surprised with the inconsistencies and disappointed that 8.5 doesn't include more visual troubleshooting for placement errors.
I am not sure if this will be helpful, but recently had an SR about storage profiles and placement in general. I don't know if this exactly how it works, but this is how it was described to us.
A storage profile can also be chose by its tags if a storage constraint tag is supplied in the cloud template. But they key, for us at least, is that only one matching storage profile is expected and it should contain any datastores/datastores clusters expected for the compute that will be chosen.
Again, not sure how accurate that is or whether it is helpful for you, but thought I would share.
This works perfectly: Select Storage policy and leave the datastore empty. You can verify the selection beforehand with Infrastructure > Cloud Zones > Simulate feature. Very handy. I got it from http://www.justait.net/2019/07/cas-placement.html
Thank you for sharing. I deleted my storage profile and added constraint tags to the storage objects individually. The 'test' function worked, so I recreated my storage profile, putting my storage properties in for both datastores. My deployment performed successfully.
The issue we are seeing is that we have some vCenters where there are multiple clusters that serve the same purpose yet each has their own datastores. In vRA 7.6 the storage was selected for each reservation which was bound by cluster so provisioning was fine. What we are seeing now is that any of the storage profile is selectedby placement yet then the cluster that is selected by placement is independant and if they don't line up we get a failure. @emacintosh your breakdown of the process posted last year helps point out why we are getting the problem. Is it any different in 8.9 or 8.10?
@RebeccaW we have been on 8.4.2 for an extremely long time, so at the moment i'm not sure. But we are migrating to the SaaS offering as we speak, so can probably confirm. That said, configuring the storage profiles in the cloud as we have them on-prem seem to be working as expected. So I'm guessing it does work the same.
That said, if you can add your datastores to a storage policy in vCenter, then use that storage policy in your storage profile, I think that should work for you. Because then when vRA chooses the cluster, any datastore for that cluster would be in that policy and therefore in the storage profile and therefore should allow for vRA to find it successfully.
So in our case, we tag our datastores in vcenter, then use that tag to create a policy and then use that policy in our storage profiles. If a new cluster or more datastores are added, then we just need to tag the datastores and we're set. We do also tag the storage profiles because we do need some different settings for some of them. But we have the means to know which tag to use and put that logic in our cloud templates so that only one is selected, and it's the right one.
@emacintosh thanks for this. This advice came in handy.
Had created Storage Polices for each datastore and tagged them so each would line up to the storage constraints in the cloud template and result in only the correct datastore. However while the constraints are shown in the placement json only the default storage policy for the region would ever get selected. Couldn't see where the tags were ever being evaluated. Tried the tags on the datastore (within vRA) instead of the the storage policy and still no.
Wound up using your advice with a storage policy with blank datastore and using the vCenter storage policy. Luckily in this case it all lines up in vCenter for clusters and data centers. That seems to be selecting the right datastore.
@eswoodford - Just to clarify: You have the datastores tagged and your Storage Profile is blank for Storage Policy and for Datastore? Sounds like also the Storage Profile has the same tags used on data stores themselves. Going to try this way in my DEV environment to test if it will solve an issue.
I ask because I have some newer vCenters where setting the Storage Policy with blank Datastore is working no matter which cluster the compute is on. However, there are a few older vCenters where each cluster has their own datastores with various names and there are no Storage Policies far as vRA can tell. Even having the Storage Profile for the current '1st place' cluster as default it still sometimes picks another and fails the build due to a mismatch between the storage selected and the cluster selected.