Run workflow as different user - slow workflow

[jonathanvh]

We use Orchestrator 4.2.1 build 555

We have created a few Worklows for letting users create snapshots for VMs that they manage. (The option is disabled in vCenter)

The users will have to go to a portal where they can request a snapshot for their VM.

On the portal they have to fill out a form with their username + password for vCenter.

This portal uses the API of Orchestrator to start a Workflow.

This Workflow will start a "Search-VM" workflow with the users credentials.

So that this workflows only sees the VMs that the user manages.

But the execution time (+- 1min) of this Workflow is really slow.

This is because Orchestrator needs to log in to vCenter with this account.

If I open the Orchestrator Client and run the same Workflow it only runs for 1-2 seconds, because it uses my existing connection and will not need to log in to vCenter again.

Is there an alternative solution for this problem?

[qc4vmware]

If you do anything in orchestrator with a domain account that is not in the vcoadmin group it has been my experience you will get horrible (unusable) performance if your directory is of any substantial size.  Maybe this is not your issue but you might want to just test logging in as a different use and see what happens.

[mcfadyenj]

I like to do this kind of stuff in perspectives.

Publish a workflow to a list of known users via AD group. Then execute in VCO context, you can use AMQP as an intermediary step to allow approval email workflows if required.

[mcfadyenj]

actually as you are just using VC you probably dont even need AMQP in the picture for email approval.

[jonathanvh]

Even with users in the vcoadmin groups have bad performance when running the workflow as a different user.

[iiliev]

Having an user from admin group helps only in cases when you make a lot of calls to vCO API. For non-admins, each call involves check whether the groups the user belongs to have enough access rights/permissions (which is slow for complex LDAP trees with many nested groups). For admins, most of these checks are skipped.

In your particular case it seems the slowness is caused by a single login operation to VC taking too much time. Unfortunately, there is very little we can do here - you pass username/password to a single API call, and vCO has somehow to authenticate this user. If this step is slow, the entire workflow execution will be slow.