Here i my use case: I am working on a multi-machine SQL Always On Cluster deployment.
What is causing me grief is the getting the names and machineId for all the VMs that were deployed as part of the process, as early in the process as possible. The number of nodes is dynamic and I am using "vSphere__vCenter__Machine_1" as the primary node that will create the shared disks ect.
I have a workflow that takes the vCAC:VirtualMachine and from that gets the vCACCAFE:CatalogResource and from the resource I am able to get all the VM's that were deployed. This was working great when I was testing it but the testing happened once the deployment was finished and complete. Once I inserted this into the build the CatalogResource returns null so I am going to assume that is not presented until the deployment has completely finished both deploy and software components so I am back to square one.
Can anyone point me in the right direction to be able to gather the names and IDs of all the machines deployed with a blueprint as early in the process as possible everything that needs to be done can be done before the software installation kicks in.
Thanks
Steve
I actually had this same conversation with a colleague the other day. Unless something has changed in the 7.4 or 7.5 release, this has actually been a real problem. As I'm informed, as of vRA 7.x, VMware seems to have removed the ability to get a deployment and its constituents early on the process to be used through EBS. This mechanism was present in the 6.x days but was since removed. I don't know all of the nitty gritty details, so if someone else can pipe up and provide them, it would be nice to know for myself.
Oh no say it isn't so Well then i guess dynamic configuration element might be the next best thing
Hoping to revive this thread. I'm looking at automating SQL Always On Clusters and Availability Groups, and banging my head on the same things discussed here. I came here hoping to find a way to leverage a "Deployment-level payload" that contains all information about all blueprint components deployed that could be passed into a post-machine-build workflow that automates the cluster configuration and related things that need to be automated.
Am I reading that such Deployment-level Payload does not exist? Did anyone find a good solution here? Dynamic Configuration Elements?!? Yuck! (but maybe...?)
sbeaver jadelzein GrantOrchardVMware stvkpln
(hope you guys don't mind the tags -- anyone know of a good KB, blog post, or other doc that discusses managing information about multiple machines in a multi-machine blueprint?
Hi
This is one of the gotchas with vRA 7.x - The Catalog system deals in manageable resources where the IaaS system deals in single nodes (I actually think this is pretty logical since they are separate systems and it's useful to have that separation even if it makes things awkward. I *DO* think that the Catalog system should perhaps introduce the notion of a draft or pending resource for deployments in provisioning. They don't have to be manageable, just reported.... )
Anyway, we have had this problem before and have found a couple of ways to work with it
1. Used XaaS wrap the deployment request so we could do the following
i. Get the CatalogRequest JSON and detect each node instance to be provisioned
ii. Generate a new unique hostname for each node and apply it to the request definition (from a list or by scanning inventory)
iii. Create a CSV list of the peer node names and put it into a custom property on each node
iv. During IAAS phase for the master node, locate entities for each peer in the list (& wait for them to exist if needed - IaaS is all async!). You can manage the order using provisioning dependencies if you need to
v. Master node can now do all he needs to do
OR
2. There *should* be a property on each node for the following
__Cafe.Root.Request.Id
This used to be the ID of the Deployment request so all child nodes had this property (v7.2 I think but have not checked if it's still there in later versions). If you can cleanly identify the peers you are good to go.
Another alternative for this approach is to set a unique value for this property on the Deployment at request time
_deploymentName
This will have the same effect but you need to manage uniqueness of this value for each deployment.
-Eoin