Register vRA embedded vCO as vCenter Server extension?

[5mall5nail5]

Hi all - I have a dev vRA environment that I'd like to leverage the embedded vCO/vRO of in order to expose some workflows from within vCenter.

I've tried the process under "Register Orchestrator as a vCenter Server Extension" in documentation for vRO but not entirely sure what the URL would be considering it's an embedded vCO in vRA.

Any help?

I guess I could install a standalone vRO, register it to vCenter, register vCenter to it, and then still manage the vCenter from the embedded vCO but that gets messy and confusing.

Thanks!

[daphnissov]

You might be able to do that but honestly I wouldn't recommend it. Provision a separate vRO appliance and use it for your vCenter interaction and things will be cleaner and simpler.

[5mall5nail5]

Yeah I am leaning that way - no special considerations regarding vCenter registrations?  The vCO/vRO won't fight, will they?  I have workflows setup in vCO embedded and don't really feel like moving them

[iiliev]

vRO instance embedded in vRA is accessible on port 443 instead of port 8281 for standalone vRO appliance.

However, even if you register the embedded vRO as vCenter server extension, you won't be able to use it to launch vRO workflows from vSphere Web client UI. The reason is simple - embedded vRO is configured with vRA authentication, and vSphere Web client calls vRO REST API using SAML tokens (vCenter SSO) for authentication. As vRA authentication and vCenter SSO authentication are incompatible, REST calls made by vSphere Web client to vRO REST API will fail.

In short, to use vRO integration with vSphere Web client, you need to have a standalone vRO appliance configured with vSphere authentication against the same vCenter SSO instance used by Web client. Not very convenient for customers who want to leverage single vRO instance for both vSphere and vRA use cases, but that's the current situation.

[5mall5nail5]

Thanks for that!  That's useful and makes sense.

So I guess I have two final questions - can I have two vRO registered to a vCenter without issue?  I don't mind deploying a standalone vRO but want to make sure I can register vCenter to it and then also use the extension for vCenter without stepping on my vRA vCO setup.

Additionally, do you know whether or not vRO (7.4, but I can try any version) has a valid extension for the vCenter 6.5 web client (flex is fine)?  Been testing in a lab and haven't had a lot of success getting the extension to register.

Thanks!

[iiliev]

On the first question - yes, you can have two or more vRO instances registered as extension to a same vCenter instance. There will be a single extension com.vmware.vco, with different vROs having their URLs in client and server array properties within the extension

On the second question - yes, vRO 7.4 should work just fine with vSphere 6.5 Flex-based Web client. It has a known issue with vSphere 6.7 Web client, but there is another build available at https://communities.vmware.com/docs/DOC-35002 that is compatible with vSphere 6.7

What kind of problems do you have with vSphere 6.5? Is is that the workflow fails, or after you register the extension you don't see vRO workflows in the vSphere Web client UI?

[5mall5nail5]

Excellent info.

My issue is that I had a /etc/vmware/vsphere-client/vc-packages/vsphere-client-serenity/com.vmware.vco-7.5.0 or something similar that I deleted per the link you sent (I had found that a bit ago).

I set my vRO up for vSphere authentication, it works.  I open the Orchestrator Client (java) and run the register workflow and then register extension workflow to this VCSA and I do not see anything come back into the vsphere-client-serenity folder on the VCSA and no extension in web client.

I can browse the VCSA from with Orchestrator Client, so that part is working at least but not registration within vCenter.

root@kcloud1vcsa1 [ /etc/vmware/vsphere-client/vc-packages/vsphere-client-serenity ]# ls

com.vmware.nsx.ui.h5-6.4.0.7564187    com.vmware.vsan.health-6.7.0.11000

com.vmware.nsx.ui.h5-6.4.1.8599035    com.vmware.vShieldManager-6.4.0.7564187

com.vmware.vcHms-6.5.1.656014425      com.vmware.vShieldManager-6.4.1.8599035

com.vmware.vrops.install-6.7.0.11000  com.vmware.vsphere.client.h5vsan-6.7.0.11000

com.vmware.vsan.health-6.6.1.13000

Thanks for the insight!

[iiliev]

Usually, if vRO integration plug-in does not appear in Web client UI after following the update steps, this means that there was some error during file download/deploy.

By default, the workflow that registers vCenter extension will register one extension record per every network interface available on vRO machine - for its IPv4 address, IPv6 address, and possible more. When vSphere Web client enumerates extensions and tries to download the plug-in, it may pick up first an extension record which URL does not work for some reason; for example, in my lab it is not uncommon for IPv6 address to not work due to some network configuration issues. In this case, what I usually do is to unregister the vCenter extension (using the corresponding workflow) and the register it again, but this time providing a single URL in the registration workflow (IPv4 address always works for me).

To troubleshoot such issues, you can check vSphere Web client log files, especially /storage/log/vmware/vsphere-client/logs/vsphere_client_virgo.log and look for errors related to vRO plug-in download/deploy during vSphere Web client service startup.