VMware Cloud Community
ohaya
Contributor
Contributor
Jump to solution

Help (going crazy!)! Create workflow to clone template?

Hi,

Sorry  that this is going to sound like a little strange problem Smiley Sad....

I've been setting up Orchestrator 5.5 to learn about it and it seemed like I got it kind of working late last night.  I had an ESXi, VCenter server and Orcheastrator machines.  On the ESXi, I have a basic Windows 2008 machine that is set as a template, and I can see that in ESXi, in VSphere client, and in Orchestrator.

Somehow (I don't know how) I was able to start creating a workflow, apparently in the Orchestrator GUI, where I was able to select the template and start a workflow for cloning that.

I even have screenshots of that, but then I went to bed (it was late, like 04:30 or something) and I intended to continue when I woke up.

So, now, I'm up again, and can log into the Orchestrator GUI as "vcoadmin", but I just cannot seem to get back to where I was.

I was taking screenshots as I went along, and this is the first one I took.  I think I can start a workflow now, that I can get to this point, BUT, when I get to this place, I don't have the buttons on the bottom (circled in red).  Also, there isn't the "Select (VC:VirtualMachine)" in the upper left, so I think I was doing something different last night vs. now.

So, I have NO IDEA how I got to this below?

So I was wondering if someone who's more familiar with Orchestrator 5.5 tell me how I got to the point where I was making a workflow to clone a template and was selecting the template like below?

Thanks,

Jim

orchestrator-workflow.jpg

0 Kudos
1 Solution

Accepted Solutions
iiliev
VMware Employee
VMware Employee
Jump to solution

The fact that you are seeing "admin @ 192.168.0.133" in the window caption and are able to login with vcoadmin/vcoadmin is an indication that your current vCO authentication mode is set to embedded LDAP.

My hypothesis is that when you first deployed the vCO from OVA and went through vCO configuration, you did configure some authentication mode eg. SSO or external LDAP, and when you shutdown the systems and brought them back up them, for whatever reason the vCO authentication mode got reverted to the default embedded LDAP. Sounds feasible?

Now, I'm not quite sure what could have possible caused this authentication mode reversal. One option is to reconfigure vCO again, and the other option is continue to work in embedded LDAP authentication mode using vcoadmin/vcoadmin credentials.

View solution in original post

0 Kudos
6 Replies
ohaya
Contributor
Contributor
Jump to solution

Sorry - I forgot to mention that the screenshots I have are all like the one I posted, i.e., they don't show the URL I was at or anything else.

0 Kudos
ohaya
Contributor
Contributor
Jump to solution

Sorry again, but I thought it might be helpful to post an example of what I'm seeing today vs. the earlier screenshot, which was from last night.  I've circled some of the areas that are different, e.g., today, there's that small green "Run" button whereas in the screenshot from last night that wasn't there.

Is this because maybe I was logged into Orchestrator as a difrerent user or something?

Thanks,

Jim

orchestrator-workflow-NOW-WRONG.jpg

0 Kudos
iiliev
VMware Employee
VMware Employee
Jump to solution

Rest assured Jim, you are not going crazy Smiley Happy

What is shown on the first screenshot (the one that has Cancel/Select buttons at bottom right) is so called object selector (or object chooser). If you have a workflow that has an input parameter of some object type eg. VC:VirtualMachine, when you start the workflow you will be able to open an object selector in the workflow presentation showing object inventory tree and browse/select the virtual machine to be used as workflow input.

What is shown on the second screenshot is the inventory tree in the vCO Java client. In this case, you are just browsing inventory tree; you are not starting a workflow and so you don't have to select an input parameter for a workflow, hence there are no Cancel/Select buttons.

The small green Run button allows you to start workflows bound to the currently selected object in the inventory tree. It is the same command available if you right-click on the selected object and choose "Run workflow" context menu.

To get to the point where you can create/modify/start your workflow, you need to go to "Workflows" tab. Look again at the second screenshot - there you are on "Inventory" tab. Just hover over with the mouse over the 6 icons at the top left; the workflows tab is the blue rectangle. Click on it and you will see the workflow hierarchy tree where you should be able to find your workflow or create a new one, and run it.

0 Kudos
ohaya
Contributor
Contributor
Jump to solution

Hi,

Sorry if this is really going to confuse you (including myself), I think that the screenshots I posted were kind of "red herrings" (== "false leads"). 

I'll caveat this repeating that I have no, like zero, familiarity with Orchestrator and Vcenter....  Let me try to explain what happened...

I have in mind a workflow that does something simple, like take a template and clone it to create a new guest in the ESXi.

So, while waiting for responses, I decided to try to blow away my Vcenter and Orchestrator instances and start again.  So I did that, and installed first Vcenter and checked as best I could that that was working.  Then, I redeployed the Orchestrator from the OVA, and then went through the Orchestrator configuration, and I was able to get back to where I thought I was before, where I was able to create a workflow to deploy (clone and sysprep) a template.  I wish I had taken more screenshots of that, but I guess I was just happy that I seemed to be getting somewhere, but here're the two that I did make:

vco_pallete.jpg

and:

vco_workflow.jpg

Like I said, I wish I took more shots, but those are the two I have.

Anyway, it was late (again), so I shutdown all the guests in the test configuration and then, this morning, I start them all up again, and I simply cannot get back to where I was last night!! 

It seems like when I shut down all of the systems and then brought them back up again, something is different.

The one thing I did notice is that today/now, when I'm in that screen in that second screenshot above, it appears that the user information at the top of the page is different. 

As you can see, in the screenshot above it says "vCO Administrator @ 192.168.0.133" (from last night) whereas this morning, after restarting the systems, it just says "admin @ 192.168.0.133".

That may be another "red herring", but is are there two different users, the "vCO Administrator" and "admin" users, in Orchestrator? 


I've tried logging into Orchestrator using all the users (and passwords) that I can recall using during the installation, and the only one that works today is "vcoadmin"/"vcoadmin", so I don't know which other user I could've been logging in as last night to get the "vCO Administrator" to show up in that screenshot above.

Anyway, sorry about the really imprecise information that I might be providing.  I don't know what I'll do at this point, but have a feeling that I might try to re-do everything again, but, at this point, I have a feeling that the same thing will happen, i.e., I'll get to the point it is working again, but then when I bounce the machines, I'll be back to this point again Smiley Sad...

Thanks for listening Smiley Happy....

Jim

0 Kudos
iiliev
VMware Employee
VMware Employee
Jump to solution

The fact that you are seeing "admin @ 192.168.0.133" in the window caption and are able to login with vcoadmin/vcoadmin is an indication that your current vCO authentication mode is set to embedded LDAP.

My hypothesis is that when you first deployed the vCO from OVA and went through vCO configuration, you did configure some authentication mode eg. SSO or external LDAP, and when you shutdown the systems and brought them back up them, for whatever reason the vCO authentication mode got reverted to the default embedded LDAP. Sounds feasible?

Now, I'm not quite sure what could have possible caused this authentication mode reversal. One option is to reconfigure vCO again, and the other option is continue to work in embedded LDAP authentication mode using vcoadmin/vcoadmin credentials.

0 Kudos
ohaya
Contributor
Contributor
Jump to solution

Hi,

I think that you are right.  I re-installed the Orchestrator OVA but this time, did just minimal configuration (just the Vcenter part) and now it seems to be back to where it was.  I've rebooted everything several times and so far seems to stay the same.

Thanks for your help and again, sorry for the rather strange questions Smiley Happy!!

Jim

P.S.  BTW, pretty good "detective work" based on just a few hints Smiley Happy!!

0 Kudos