Latest Headlines
0

Change the password for vcoadmin on vCO Appliance

UPDATE 14. Mar. 2012: Christophe from @vcoteam posted a great article about how to “Pimp Your vCenter Orchestrator Appliance”, including a ready-to-run workflow package for all that stuff below (and much more useful info!). No need to get your keyboard dirty with the console :mrgreen:
http://www.vcoteam.info/learn-vco/pimp-my-vcenter-orchestrator-virtual-appliance.html

Original Post:

You all know VMware vCenter Orchestrator Appliance as the quickest way to get started with vCO.

You all have learned (maybe the hard way) that the vCO Appliance uses 4 (in words: FOUR) different credentials…

The vCO Appliance user credentials

  • One for the root-user Appliance it self: This is used if you select the “Login”-Button on the console of the appliance (or via SSH, if you enabled SSH login for root (google for “ssh PermitRootLogin”)) and for the webbased  “Appliance Configuration” (on port 5480) . Change it with the passwd command on the console.
  • One for the “Orchestrator Configuration” webpage (port 8283). It can be changed using the “Change Password”-Tab in the General-section of the configurator (username is always vmware):

  • And finally, the (ldap-based) users to login with the vCO Smart Client or the weboperator (port 8281). Default: vcoadmin with password vcoadmin and vcouser with password vcouser. This article shows how to change their credentials…

Typically the default webpage asks you for new passwords for the appliance’s root-user and the vmware-user of the configuration when you click  on the links for the first time.

Change the default passwords for vcoadmin and vcouser:

For the vcoadmin & vcouser it’s not that easy: Because they are users defined in the local OpenLDAP-installation of the appliance, you have to use some ldap tools for this…

1. Login to the appliance on the console (or via SSH if PermitRootLogin is enabled)

2. Type following command:

ldappasswd -D “cn=vcoadmin,ou=vco,dc=appliance” -W -S

3. Type in the NEW Password for the vcoadmin-user (twice), and the OLD one once (when being asked for LDAP password)

(optionally: repeat the steps for cn=vcouser,ou=vco,dc=appliance”)

4. Because you changed the password of the vcoadmin, you have to reconfigure all settings which are using this password:
The password to browse the ldap-directory (in LDAP)

The password for user vcoadmin which is used to install Plugins in PLUGINS)

5. RESTART THE vCO SERVICE!
(It took me for a complete cup of coffee to troubleshoot that I forgot that step)

6. Voila: Test the new passwords in LDAP / “Test Login”-Tab and just by logging in with the vCO Client.

References

0

The Philosopher’s Stone of vCO: Workflow Reflection

Don’t fear anything, it’s not necessary to live in a barrel to understand this topic! You just have to go a bit beyond the obvious…

In computer science, reflection is the process by which a computer program can observe (do type introspection) and modify its own structure and behavior at runtime.says Wikipedia.

The Orchestrator also provides a kind of reflection for workflows: Using the keyword “workflow” in a JavaScript Element a workflow can access its current runtime state. This article explains the basic understanding about Workflows and WorkflowToken, script examples and common use-cases for that.

The Basics

An important conecpt of vCO is to create a so called Workflow Token for every single time a workflow gets executed. Only so it’s possible to keep track of multiple in-parallel runs of the same workflow, what’s absolutely possible. (Currently supported in vCO 4.2: 150 concurrent running workflows).

In the vCO Smart Client you can see all the workflow token (=past executions) in the Workflow library, as leafs under the workflow itself:

If you are familiar with object-oriented programming, consider the Workflow as a class (description), the WorkflowToken is an actual instance of this class.

When you select a workflow token in the tree, you can see its details in the main window, most important:

  • the state (e.g. running, failed, completed, waiting)
  • the current vlaues of the workflow attributes
  • the log output (done via System.log() or System.debug())
  • (if there is one:) the error message at the bottom of the Variables-Tab

<Additional Technical Background>: All information about the state of a workflow token is stored in vCO’s database (the state, the attributes, the current element,…). So it’s possible for vCO to continue the workflow even after a crash of the server (Checkpointing).
For a quick & (really!) dirty ( & completly unsupported!) monitoring you could do SQL-cram against the vCO database like that:

ALTER trigger [dbo].[monitor] on [dbo].[VMO_WorkflowToken]
AFTER UPDATE
AS
SET NOCOUNT ON
IF EXISTS ( SELECT * FROM Inserted I WHERE I.globalState = 'failed')
BEGIN
/* ***DEMO ONLY:** */ Insert into dbo.fails VALUES ('adsf'); # send a mail, wake somebody up...
END

</Additional Technical Background>

How to…

Back to topic: You can also access the runtime information about the current workflow execution “from inside”, by using the keyword “workflow” (small-caps, remember: JavaScript is case-sensitive!) in a scriptable element.
This keyword returns an object of type WorkflowToken.  This object now represents the current instance of the workflow. This object provides some attributes, see the script below for examples…

Important: If you want to access the Workflow-object (the (class/description/definition), you have to use the rootWorkflow-Attribute of the WorkflowToken (eg. “var theWorkflow = workflow.rootWorkflow”; theWorkflow will be of type Workflow). (Yeah, that’s what I meant with “beyond the obvious”)

The following script examples shows all that stuff: First we get some information about the current instance (you got it, the WorkflowToken). Starting in line 10 we access the Workflow, the last part from line 23 uses the WorkflowToken again.

//get the current workflow token /"instance"
 var token = workflow;
 System.debug(token);

//get some details about the current workflow token/execution/instance
 System.debug("startDate: " + token.startDate);
 System.debug("businessState: " + token.businessState);

//get the Workflow-"Class" of the current token
 var rootWorkflow = workflow.rootWorkflow;
 System.debug(rootWorkflow);

// get "declaraction": Array of Input Parameters of the workflow in general
 var inParams = rootWorkflow.inParameters;
 System.debug("inParams: " + inParams);
 //loop through array and print out details for each parameter
 for (var i in inParams) {
 loopParam = inParams[i];
 //print out in type:::name:::description
 System.debug(loopParam.type + ":::"+ loopParam.name + ":::" + loopParam.description);
 }

// get the current token's inParameters (they include the values, and are returned as Properties
 //(key : values tuples)
 var curInParams = token.getInputParameters();
 System.debug("curInParams: " + curInParams);
 //crawl through the Properties
 var keys = curInParams.keys;
 for (var i in keys) {
 var curKey = keys[i];
 //print out properties in format key :::: value
 var curValue = curInParams.get(curKey)
 System.debug(curKey + " :::: " + curValue );
 }

All that happens just in the script, there are no workflow attributes bound to this scriptable element. The Workflow you can download below has one INPUT Parameter, just to see something in the logs :-). It’s not used anywhere.

The script produces output like this:

Use-Cases

Now, what to use all that stuff for?

  • Obviously, if you need some of the information, like the startDate, later in the workflow
  • If your workflow has an User Interaction element, you can send an URL to answer it via email (there is a complete example in Library / Mail)
  • It’s possible to change the User context the workflow runs, using the changeCredential()-Method
  • If you are working with the Business State field of workflow elements, you eventually want to read this in script.

Not really related to the “Reflection”, but useful anyway:
The same objects are used when you access past workflow tokens not of the current workflow, but of other workflows. This can be used for instance to create Healthcheck Workflows which monitor the vCO Server for failed or canceled workflow runs (a much cleaner & more reliable ( & supported) way to replace the SQL-cram mentioned above!).
Insider Tip
: See the Actions provided by the module “com.vmware.web.webview” for a lot of useful scripts! They have many more use-cases than only within webviews…

Now, finally:

Download the example!

It should just run out of the box…

Workflow Reflection example
Workflow Reflection example
WorkflowReflection.workflow
1.8 KiB
Details...
0

vCO integration with VMware View

Just that you do not miss it: @cloudnutz postet a great example how to leverage the Powershell plugin to call VMware View PowerCLI cmdlets from vCO Workflows:

http://communities.vmware.com/docs/DOC-18638

Find the original post also on http://cloudnutz.com/2012/03/07/using-vmware-vco-to-manage-vmware-view/

And don’t miss some (unofficial, but don’t blame me (this time 😳 ) 😛 ) additional PowerCLI cmdlets for VMware View: http://velemental.com/2012/02/04/unofficial-advanced-vmware-view-powershell-cmdlets/

And Dear VMware View Team: Please give us a full (and documented) (and official) API!

Or even better: What about a View-Plugin for vCO?
I know a lot of customer having use-cases for it (and a lot of people having to use workarounds like this for now). Desktop-as-a-Service and Cloud Desktops need Orchestration (just to add the buzzwords for the robots 😈 )

0

Quick one: Trace out object attributes in JavaScript

I just strumbled (once again) over some scripting objects in vCenter Orchestrator where the documentation in the API Explorer is, eeeh, just missing. So I had to figure out the attributes of the object manually. To do this, you can leverage the JavaScripts’s characteristic that objects are represented as enumerations of their attributes.

So it’s possible to loop through all the attributes even if you don’t know their identifier (yet). Following example in Javascript does exactly that, to trace out all attributes of a VM-Object (Type: VcVirtualMachine) and its Datastores. (you can download the full example below)

The script

//print out properties of a VM-object

//loop through all properties (leverage Javascript's
// "object is an associative array" characteristic)
for (var i in vm) { (//vm is an input parameter of Type VcVirtualMachine
	//we have to catch some 'not defined' errors if object has
	//an attribute of type "dynamic property")
	try {
	//print out in form "propertyname:::value"
		System.debug(i + ":::" + vm[i]);
	} catch (ex) {
		//just ignore error and continue with next iteration(=property)
		continue;
	}
}

//other example: For a datastore
System.debug("================================");
System.debug("====NOW FOR THE DATASTORE===");
System.debug("================================");
var vmsDatastores = vm.datastore;
System.debug("VM's Datastore(-object): " + vmsDatastores);
//vm.datastore return an ARRAY OF DATASTORES itself, so we have
//wrap it in another loop
for (var k in vmsDatastores) {
	var curDatastore = vmsDatastores[k];
	System.debug("******** NEXT DATASTORE: *****");
	System.debug("curDatastore: " + curDatastore);

//same loop as above for each datastore
//play it again, Sam!
for (var j in curDatastore) {
	try{
		System.debug(j + ":::" + curDatastore[j]);
	} catch (ex) {
		continue;
	}
}
//end same loop as above :-)

} //end loop through Datastore-Array

The results

The output looks like this:

To interpret the results, an example line of the output:

[2012-03-06 09:45:23.844] [D] resourcePool:::DynamicWrapper (Instance) : \\
    [VcResourcePool]-[class com.vmware.vmo.plugin.vi4.model.VimResourcePool] \\
    -- VALUE : ResourcePool<resgroup-98>

The first part resourcePool is the name of the attribute.
After the ::: separator you get the object type [VcResourcePool] of this attribute, the providing class in the vCenter-Plugin of vCO,
and finally after the separator you get the value of the attribute, in this case it’s with ResourcePool<resgroup-98> a Moref (Managed Object Reference) to the resource pool the VM is located in.

Now you can use the .-Operator in JavaScript to access the attributes, as in line 21 in the script where we do the cram again for all Datastores the VM is related to.

Only caveat: Just from the System.debug()-Output it’s NOT possible to see if an attribute is just a single object or an Array!
(read carefully the example again: vm.datastore (line 21) returns and Array of VcDatastores, but you cannot see this just from the output of line 22)

Conclusion:

Always have the vSphere API Reference open in background when working with vCenter objects in vCO!

Download the example:

Workflow: Trace Out Object Properties
Workflow: Trace Out Object Properties
trace out object properties.workflow
2.3 KiB
Details...
0

Let your vCO Workflow text you! Yes, via SMS!

Working on another blogpost on some design best-practices for workflows (stay tuned…) a promising idea came into my mind:

What about sending text messages to my mobile from workflows?

I guessed there are many SMS-Gateway-Services out there which provide any kind of SOAP or REST-API… (I want to leverage an existing plugin for vCO for quick results). So google came up with this nice discussion:

http://stackoverflow.com/questions/2383542/recommendations-for-sms-gateways-with-api-support

I decided to give https://www.clickatell.com a try, because they

  • provide interational service
  • provide multiple kinds of API
  • seem to be reliable and widely used
  • don’t force you in a contract/monthly plan for my limited test usage

What you need to reproduce this example:

  • a clickatell account (I think it will work with most of the other SMS-Gateway services in a comparable fashion)
  • the REST-Plugin for vCO installed in your Orchestrator environment (see details here: http://www.vmware.com/support/pubs/vco_plugins_pubs.html (Select HTTP-REST for the plugin-download and a bunch of examples)

Step-by-step…

I quickly signed-up for an account, used the web-form to send a test message to German) mobile number, and prepaid for some credits to be able to send via the API.

After that, I created a new access for the “HTTP”-API of clickatell (no special settings):

(You may open clickatell’s API Documentation now in background if you’re a read-first-try-then kind of guy.)
For myself I just started my vCO client and ran the “Add a REST host”-Workflow from the library, providing just a name and http://api.clickatell.com as URL:

The workflow finished sucessfully, I confirmed the new host in the Inventory:

Now I called the “Add a REST operation”-Workflow to invoke the API-Call to clickatell (based on their example given when creating the API account):

(instead of hardcoding my credentials I used the generic {parameter}-notation of the REST-plugin for all the necessary parameters like username, password, API-Id, …, so that I can re-use the  operation later flexibly). The full “Template URL” value is:


/http/sendmsg?user={username}&password={password}&api_id={apiid}&to={tonr}&text={message}

When the operation was created (again: Confirm in Inventory-Tree) I started the “Invoke a REST operation” workflow providing all the input parameters:

aaand voila,  😎 seconds later the text messgae arrived on my mobile!   :mrgreen:

Now, the real-world use-case:

Well, sending generic messages to a mobile from a vCO workflow is cool|geeky, but what for? For a realistic example I used the Workflow-Generation of the REST-Plugin to let vCO generate my very own “Invoke ‘send a text message'”-Workflow in my very own Workflow folder for easy re-usage:

So I was able to re-use the created workflow in my Snapshot-Hunter-Workflow… (you know the pain with backup software which accidentally forgets to cleanup the VM snapshots! :evil:)

(The first element to find these workflows leverages the xpath-filter of the VcPlugin.getAllSnapshots()-Method, see the discussion here: http://communities.vmware.com/thread/342686 and http://communities.vmware.com/message/1673575 )

At the end: After scheduling the workflow as Scheduled Task in vCO, starting from tomorrow I will get waked-up by my mobile receiving an text message from vCO when there are leftover snapshots from the nightly backups!

Summary

  • Don’t fear any tasks integrating vCenter Orchestrator! When the external system provides an API, chances are that you get in run in a few minutes…
  • Remember: less and simple workflow inputs make it easy to use, many and generic workflow inputs make it easy to re-use! (referencing the “Workflow Development Best Practices”-session as a shameless plug :mrgreen:)
  • Sometimes it IS good to be creative|distracted when drafting a blog-post (expect the post I actually was working on soon…)
  • Turn off your mobile when you want to sleep in!
  • …and thank god I’m too tired to think about other use-cases for this…
    (I will not make an Orchestrator & Ringtone joke!
    I do not plan to provide a monthly subscription for my content, just text a SMS with “vCO Rockz!” to …..
    And I better not search for an API for Asterisk (“If you want to execute workflow XYZ, press 1; for all other requests press 2” 8-O)

Download the example

SnapshotHunter Package
SnapshotHunter Package
de.vcoportal.snapshothunter.package
23.3 KiB
Details...

Be aware that it will NOT run out-of-the-box, because you have to add the REST-Host and the Operation in your environment! And: Don’t forget to set the necessary values for username, password, mobilenr, … in the configuration elements.You know that blogpost whith a great description of Configuration Elements, don’t you! 😛