Thelemanu
Contributor
Contributor

Install a software management agent

Hello,

We have to install an agent on newly deployed VMs, via vRA. Ideally we'd like to have the agent stored in the vRO resources.

We were thinking using Extensibility to trigger a flow that will "copy the file from vCO to guest", then use "Run program in guest" to achieve the agent installation. But that means storing the agent inside the vRO container.

  • Is there a simple way to achieve this?
  • Where can find documentation/examples on how to use the flows "copy the file from vCO to guest" and "Run program in guest" ?

Note: At the moment we doing this with cloud-init. But we really would like to do everything with VMware only.

Tks

We are using vSphere 7 and vRA 8.3

We install this agent on Windows and Linux (SLES/RHEL)

0 Kudos
1 Reply
eoinbyrne
Expert
Expert

I think you should be able to store the file as a vRO ResourceElement depending on the size of it. You'd have some wrangling to do to extract the content to a file on the appliance so the Copy file from vCO to guest workflow can operate (it requires a local file IIRC). The content of a ResourceElement is accessible as a MimeAttachment which can be written to a File on the local filesystem. Look at the File object in the API explorer which operates a lot like a java.io.File object. In terms of exactly *where* on the filesystem it will be created I'm not sure about as all the containers may have different roots & mounts. 

Realistically, you'd have to try this out to see how it would work. 

I have stored content of the order of 1-2MB as vRO ResourceElements in the past without any problems but can't say if there are challenges with larger items. In the end, whatever you store there is being written to a BLOB in a database somewhere in one of the containers I suspect.

In relation to the use of the GSM workflows for stuff like this, I like the package a lot & I've found it works quite well in general but I (at least) found it difficult to debug when it goes sideways due to the spread of the logging (workflows calling workflows calling workflows means lots of hopping about in the client - I suspect this is even more the case in the HTML client now which I find quite 'click-heavy' anyway).