vRealize Automation 7 – Fabric GroupsJanuary 19, 2016
In the last post we setup an vCenter endpoint that defines how our vRealize Automation solution will talk to our vSphere environment. Now we must create a fabric group. Fabric Groups are a way of segmenting our endpoints into different types of resources or to separate them by intent. These groups are mandatory before you can build anything so don’t think that since you don’t need to segment your resources, that you can get away with not creating one.
To add a Fabric Group, login to your vRealize Automation tenant as a IaaS Administrator account which we setup in a previous post. Now go to the Infrastructure Tab –> Endpoints –> Fabric Groups. Click the “New Fabric Group” button to create a new group. Once the “New Fabric Group” screen opens, you should first check to see if there are any resources in the “Compute resources:” section. If there are no resources, check to make sure that all of your endpoint connections are correct and the credentials are working. If you need to dig into this more deeply, you can check the vRealize Automation logs to make sure the endpoints are being discovered properly.
I should note here that if you just setup your endpoints, go grab a cup of coffee before setting up the Fabric Group. The resources take a little bit to discover, but trust me on this. Version 7’s discover works MUCH faster that in previous version. My lab vCenter was discovered in under 5 minutes.
Now, once your compute resources have been discovered, enter a name for the fabric group, a description and some fabric administrators who will be able to modify the resources and reservations that we’ll create in our next post. Lastly, and most importantly, select the compute resources (Clusters in a vCenter) that will be used to deploy vRealize Automation workloads.
Fabric Groups are a necessary piece of a vRA7 installation and can be used to separate fabric administrators or simply to limit which compute resources in your endpoint can be used. In this post we added all of our vCenter resources, but we could just have easily selected only the “WorkloadCluster” and prevented vRA from ever deploying to the Management Cluster.