The requirement is to lease fully loaded VMs( Application stack like Tomcat) to developers. The developers need access to these VMs right away. To provision a new VM won't be instantaneous so thought of creating few VMs in a pool( managed by VCO workflow) and lease them on request.. The users request through ASD service where user requests a required application and sets lease duration. Then VCO workflow chooses a vm from the pool and changes the owner from system a/c to user a/c and sets lease duration. When the lease expires the vm goes back into the pool. Let me know if there is better way to accomplish the requirement.
I am not able to change the owner of the vm successfully. The "Reconfigure" action fired from VCO workflow on a machine with new owner only changes owner in IaaS but not in VCAC Portal. When the requester logs into the portal the machine is not visible to the user. On VCAC portal items>Machine details> still shows old owner. I tried Use vCO to change Virtual Machine Owner which did not change the owner.Let me know your thoughts.
Any help appreciated.
Use option 2 here... provided to me by GSS.
I attached the workflow at the bottom that gets the User ID.
I think what you are doing is a pretty interesting idea. Others have allowed for creating templates of machines and then select the template on build. With that model, you wouldn't need to keep a running VM pool and you would still maintain a fully loaded VM.
Hi Sean, Thanks for the response.
Option 2: I have tried option 2 which basically calls "Reconfigure" on the VM. The end result is only owner gets changed in IaaS and not in VRA as show in the attached picture. So because of this new owner does not see the VM.
Option 1: This option did not work. The values are populated in the database( workflowopertions and workflowoperationarguments table) and they disappear...I think workflow is gets executed. It did not change anything.
1. vRA Version? I am on 6.2.1
2. If you run Reconfigure through the GUI, does it change the owner?
3. Are you sending in the User ID and not the User?
What you are saying doesn't make a lot of sense because when you run the Reconfigure option supplying the values... you are going through the front end call of the Reconfigure like the GUI uses. It changes the owner quite fine.
(edit: Updated Image to show more complete info.)
We are on VRA 6.2.
I am trying to change owner of a VM-ut00009 from "R" user to 'vclouduser" in the "Enterprise" business group.
As shown below vclouduser user is in "Enterprise" business group with "user" role.
Now need to change the owner of ut00009 from user "R" to "vclouduser"
. The ownership of a vm is in two places one is VRA and other in IaaS. Both of these show "R" as the owner as show in the following screen shot
Executing "Reconfigure" action from GUI....changing owner to "vclouduser"
The request executes successfully but changes owner only in IaaS as shown below
The net effect is when the "vclouduser" logs into the portal the machine is not visible.
What happens if you move the user to the Support User role and perform the reconfigure?
Nonetheless, Reconfigure with Change Owner is supposed to Change the Owner. Not "just in IaaS", but completely! It does so in my three environments without issue. If Reconfigure with Change Owner doesn't work for you, then you should open up a GSS support ticket. We do not use the "user" role at all, so when I perform that action... it is done leveraging Support Users. However, change machine item ownership should work for all BG Roles. If you find it works for Support Users, but not Users in your environment... that isn't ideal and VMware should provide a fix.
### I would also wonder about some timer setting that performs inventory refresh. My reconfigure for change ownership is pretty fast, but we did tweak some of the timer jobs on both IAAS and VCAC. (probably unrelated, a support ticket is a better approach).
there was an error in Infrastructure>Workflow History> UpdateMachineOwnerRequest has the following error on dem worker "DEM-W-labvXXXX02"
' Workflow failed with the following exception: The HTTP request is unauthorized with client authentication scheme "Anonymous". The authentication header received from the server was "Negotiate,NTLM".'
Rebooted the env that resolved the issue