Get Started!

0

LittleCMDB (An Orchestrator and WaveMaker project) – Part 3

By
Christian Strijbos
– July 20, 2012Posted in: Call Workflows from outside, Database, Examples, Get Started!, Integrate vCO, vCO Use-Cases, Wavemaker

Table of Content

In Part1 we start with the SQL DB Plugin and create the required database for our need.

In Part2 we start with the development of our Workflow. We will start with a few elements.

In Part3 we  finish the  collection of the VM information.

In Part4 we insert our data into the database and test our created workflow

In Part5 we create our webview to get a look on our Data in the SQL Database

In Part6 we will make our Workflow smarter to update the DB with actual VM information

In Part7 problems with vAPP located virtual machines are fixed


Part3

Here we go with the Part3 of our LittleCMDB……

To get forward with out CMDB with need more Elements. We insert the following elements and workflows into the Schema.

  • A scripting element

  • a decision

  • the Workflow element “Extract virtual machine information”

  • a second scripting element

  • a third scripting element

  • a second decision

We can place the elements on the left side of our Schema.

After placement it have to look like this screen shot

 

Next we have to insert values in the different elements. Lets start with the first Scriptable task.

We set the name of the element t o”Countdown VMs” and insert a good description (we want to countdown the “AllVMs” Array…). Next we need the in and output’s for the element. Following variables are required:

Local Parameter Variable Name Module Direction Type
NumberVMs NumberVMs Countdown Vms in Number
allVMs allVMs Countdown Vms in Array/VC:VirtualMachine
SQLVID SQLVID Countdown Vms in String
NumberVMs NumberVMs Countdown Vms out Number
VmtoGet VmtoGet Countdown Vms out VC:VirtualMachine
SkipVM SkipVM Countdown Vms out Boolean
VMName VMName Countdown Vms out String
V_ID V_ID Countdown Vms out String

After we have created the values we start with our scripting. In our Scripting, we have to check different states of the connected virtual machines. Some states could lead to errors in our scripting, so we have to avoid them and skip the VM. In the Scripting Tab we have to insert this commands.


// set Variable SkipVM to false

SkipVM == false;

// We take the last VM in our Array

VmtoGet = allVMs.pop();

// some virtual machines are in the API but not connected. We must exclude them, otherwise we become errors

if (VmtoGet.summary.runtime.connectionState == VcVirtualMachineConnectionState.orphaned) {

SkipVM = true;

System.debug("OrphanedVM: " + VmtoGet);

}

if (VmtoGet.summary.config.template == true) {

SkipVM = true;

System.debug("Template: " + VmtoGet);

}

if (VmtoGet.summary.runtime.connectionState == VcVirtualMachineConnectionState.disconnected) {

SkipVM = true;

System.debug("VM Disconnected: " + VmtoGet);

}

if (VmtoGet.summary.runtime.connectionState == VcVirtualMachineConnectionState.inaccessible) {

SkipVM = true;

System.debug("VM Inaccessible: " + VmtoGet);

}

// Get the virtual machine name

VMName = VmtoGet.summary.config.name;

// create a unique UUID for the database (It is also possible to do so in the SQL DB....here I use the JavaScript )

V_ID = System.nextUUID();

// decrease the Variable NumberVMs

NumberVMs = NumberVMs -1;

Next we go to the decision. Here we have to insert a speaking name and a description. I use “SkipVM” as name. After that, we have to fill in the Decision condition.

 

For that, we click on “Not Set (NULL)” and choose the Skip VM variable

 

Then we have to set the parameter to “is false”

 

Then we are already finished with this module.

Now we have to deal with the “Extract virtual machine Information” Workflow. This workflow has one Input and a lot of Output variables.

Local Parameter Variable Name Module Direction Type
vm VmtoGet Extract virtual Machine in VC:VirtualMachine
folderName folderName Extract virtual Machine out String
folderID folderID Extract virtual Machine out String
runningHostName runningHostName Extract virtual Machine out String
runningHostID runningHostID Extract virtual Machine out String
resourcePoolName resourcePoolName Extract virtual Machine out String
rescourcePoolID rescourcePoolID Extract virtual Machine out String
clusterName clusterName Extract virtual Machine out String
clusterID clusterID Extract virtual Machine out String
computeResourceId computeResourceId Extract virtual Machine out String
datastoreName datastoreName Extract virtual Machine out Array/string
datastoreId datastoreId Extract virtual Machine out Array/string
diskSize diskSize Extract virtual Machine out Array/number
cpuCount cpuCount Extract virtual Machine out number
memoryMB memoryMB Extract virtual Machine out number
ipAddresses ipAddresses Extract virtual Machine out Array/string
networks networks Extract virtual Machine out Array/string
folder folder Extract virtual Machine out VC:VmFolder
host host Extract virtual Machine out VC:HostSystem
resourcePool resourcePool Extract virtual Machine out VC:ResourcePool
cluster cluster Extract virtual Machine out VC:ClusterComputeResource
computeResource computeResource Extract virtual Machine out VC:ComputeResource
datastores datastores Extract virtual Machine out Array/VC:Datastore

The output Variables must all be attributes….when your are finished your “Visual Bindings” have a whole bunch of connections…

 

That’s all for the module. Know we have to deal with the second scripting element. When you have a deeper look at the “Extract virtual machine Information” module, you will see that some information about virtual machines are missing. One of these information is the virtual machine UUID. This UUID is always unique for a VM. The name of the VM could be changed but the UUID with not be changed. So to be able to identify a VM we need this UUID. In this scripting element, we want extract this information.

First we give a name and a description for the module. I use the name “GetVMUUID”. Then we need one Input parameter and a output parameter.

Local Parameter Variable Name Module Direction Type
VmtoGet VmtoGet GetVMUUID in VC:VirtualMachine
VMUUID VMUUID GetVMUUID out String

In the scripting tab we insert the following:

VMUUID = VmtoGet.summary.config.uuid;

With this, we get the UUID of the virtual Machine.

Now it is time to configure the third scriptable task. In this module, we will check if the VM is already in our DB. For that, we do some custom SQL scripting. We will not use a “predefined” SQL Statement, which we created earlier because we only need two columns for our decision.

First, lets name the module and insert a description. I name the module “GetVMfromDB”

Let’s see what Input and Output parameter we need:

Local Parameter Variable Name Module Direction Type
isUnique isUnique GetVMfromDB in Boolean (true)
VMUUID VMUUID GetVMfromDB in String
V_ID V_ID GetVMfromDB in String
VMInfo_Table VMInfo GetVMfromDB in SQL:Table
VMInfoRead_Result VMInfoReadResult GetVMfromDB in SQL:ActiveRecord
VMName VMName GetVMfromDB in String
VminDB VminDB GetVMfromDB out Boolean

The VMInfo_Table must be chosen. You can pick the right Table during the configuration of the Variable







The VMInfoRead_result is reading data out of the database and to work with this data.




After we have created all variables, we can start with the Scripting.


The script we need has to read the VM information out of the db (if the VM exist in the database). If the VM exist it generates a log entry and sets the Variables “VMinDB” to true. Otherwise to false. We use the Variable “VMinDB” for the control of our Workflow.



// We check the DB for the VM. The check is based on VMName and UUID

var columns = {
UUID : VMUUID,
VMName : VMName,

};
VMInfoRead_result = VMInfo_Table.readRecords(columns);

// Some local variables here. We have to split the DB Information
var SplitArraytoString = VMInfoRead_result.toString();
var UUIDString = SplitArraytoString.search(VMUUID);
var VMNameString = SplitArraytoString.search(VMName);

if ((UUIDString >= 0) && (VMNameString >=0))
{
VMinDB = true;
System.log("VM: " + VMName + " already in DB.")
}
else
{
VMinDB = false;
System.log("VM: " + VMName + " not in DB.")
};




At last we have to deal with the next Decision. I use the Name “VM in DB”for that decision. Here we check if the VM is already in the DB.


 




 After we have chosen the Variable, we set the Boolean Value to “false”


 


After we have finished all the Elements, we are starting to connect these. We start with the “Countdown VMs”. We need a connection from “NumberofVMs” to there. And from “Countdown VMs” we will make a connection to “SkipVM”


 


Next we need a connection from “SkipVM” to “Extract virtual machine Information” and a “Error Connection to “NumberofVMs”.


 


All Other Elements will be connected to the following element.


 


From “VM in DB” we connect the error connection to “NumberofVMs”. When the VM is already in our Database, we go further with the next virtual machine.


 


At least for this part, we create a End under “NumberofVMs”. This End will be reached, If the number of VMs is “0”.


 That’s all for Part3. In Part4 we will start to insert the Data into the SQL Server, so stay tuned 😉






De Vcoportal Part3





De Vcoportal Part3

de.vcoportal_Part3.package








119.8 KiB

Details...












0
LittleCMDB (An Orchestrator and WaveMaker project) – Part 2




By 
Christian Strijbos


 – July 19, 2012Posted in: Call Workflows from outside, Database, Examples, Get Started!, Integrate vCO, vCO Use-Cases, Wavemaker

 


Table of Content



In Part1 we start with the SQL DB Plugin and create the required database for our need.



In Part2 we start with the development of our Workflow. We will start with a few elements.



In Part3 we  finish the  collection of the VM information.



In Part4 we insert our data into the database and test our created workflow



In Part5 we create our webview to get a look on our Data in the SQL Database



In Part6 we will make our Workflow smarter to update the DB with actual VM information



In Part7 problems with vAPP located virtual machines are fixed








Part2


Here we go with Part2 of the “Little CMDB” Project. Enjoy the Post 😉


After the SQL Database is ready, it is time to start with the Workflow development. As first task, let’s start and create a new workflow. I will name my as GetVMConfig.




Insert a good description for the Workflow, change the Version Number and then lets go to the schema tab.




 The first thing we need, is a action element to get a list of all virtual machines. Just drag the action element into the window.


 


Just insert „getAll“ into the filter field. As second step choose the “getAllVMs” Workflow.




After we have insert the workflow we change to the „General“ Tab and drag a „Scriptable Task“ and a „Custom Decision“ into the Schema




Now we insert a name for the „Scriptable task“, I choose CalculateVMNumber and a Description.




After that, we are changing the name the of the “Decision” to “NumberofVMs” and insert a description.


 


After we have complete this naming and description for the workflows, we have to create some Variables.


There are two ways to create the variables. The first one is, to drag and drop from the workflows and actions over the Visual Binding tab. The second is to create the variables on the general tab. I will use the first choice.


For all other, here is a sheet with the required variables and there value to create them on the General tab:













Local Parameter
Variable Name
Module
Direction
Type




actionResult
allVMs
GetAllVMs
out
Array/VC:VirtualMachine




allVMs
allVMs
CalculateVMNumber
in
Array/VC:VirtualMachine




NumberVMs
NumberVMs
CalculateVMNumber
out
Number




NumberVMs
NumberVMs
NumberofVMs
in
Number






Lets start with the “getAllVMs” Action




I recommend to give a variables a “speaking” name and a description




When your are finished, your “Out” tab must look like this:




The next thing we have to configure, is the “CalculateVMNumber”. Here we have to insert the “allVMs” variable over the “IN” Tab




You can insert the Variable over the “Plus” symbol.


At the moment we have only one possible value so we choose the “allVMs”.




Next we go to the “Out” tab. Here we have to export the “NumberVMs” Variable. You can insert the variable over the “Plus” Sign. If you don’t have created the Variable jet, you can do so over the link above.




After we have created the variable (don’t forget we need a “number” as type 😉 ) we go to the script tab.


Here we do our first scripting. We wont to get the length of the array. We can to that with this small script:




NumberVMs = allVMs.length;



You don’t have to literally type the variables. The bound variables for the Workflow are shown on top of the “Scripting” tab. You can simple click on them and there are used in the scripting field.


At last (for the moment) we go to the “NumberofVMs” Decision. There we insert the “NumberVMs” Variable on the in field and insert this script in the scripting tab.




Now, we have to connect the different modules. We can use the connector by clicking on the “connector symbol” and drag-and-drop between the different modules.


After you are finished, just click on the “Validate” button and lets see if we have any error in our workflow.




At the moment we have two errors, which are logical (we don’t have finished our CMDB jet…).


Save the Workflow and then we will in Part3 we will go one with our LittleCMDB so stay tuned 😉






De Vcoportal Part2





De Vcoportal Part2

de.vcoportal_Part2.package








110.7 KiB

Details...












0
LittleCMDB (An Orchestrator and WaveMaker project) – Part 1




By 
Christian Strijbos


 – July 18, 2012Posted in: Call Workflows from outside, Database, Examples, Get Started!, Integrate vCO, Plugins, vCO Use-Cases, Wavemaker

 


Table of Content



In Part1 we start with the SQL DB Plugin and create the required database for our need.



In Part2 we start with the development of our Workflow. We will start with a few elements.



In Part3 we  finish the  collection of the VM information.



In Part4 we insert our data into the database and test our created workflow



In Part5 we create our webview to get a look on our Data in the SQL Database



In Part6 we will make our Workflow smarter to update the DB with actual VM information



In Part7 problems with vAPP located virtual machines are fixed






Part1


Today I want to start with a series of posts for an example how to to create an Orchestrator and Wavemaker project. This project came from a “real-world” situation. The customer wants his VM configuration saved outside the virtual environment into a SQL Database. During the talks with the customer, the idea for a little CMDB was born. The actual customer project is much bigger than the example in this article series, but you will become a good insight view on all relevant topics and themes.


When we think about a CMDB we have to choose which data we want to save in our database. Here are some things I included in my database:


    

  • 

    Unified Identifier (VMID) (The primary key for the VM)
    

    • 

  • 

    VM UUID (the second key for the VM)
    

    • 

  • 

    VM name
    

    • 

  • 

    CPU Configuration
    

    • 

  • 

    Memory Configuration
    

    • 

  • 

    Cluster
    

    • 

  • 

    Host
    

    • 

  • 

    Folder
    

    • 

  • 

    Resource Pools
    

    • 

  • 

    Network
    

    • 

  • 

    IP Address
    

    • 

  • 

    Datastore(s)
    

    • 

  • 

    Disk Size
    

    • 



Surely there are more things which could be integrated but in this post I will focus these values. These identified values bring us to a database schema. Also there are not so many values; I prefer to save the data in different tables. On every table I choose the Unified Identifier with the name VMID as primary key. As second key I select the VMUUID with should be unique for every virtual machine within a vCenter Server. I also split the different information for the VMs in different tables for maybe future grow.


I create the following tables with these values:


VM_Info







 





Name




Data Type




IsNull




Comments








VMID




varchar(100)




False




PrimaryKey








VMUUID




varchar(100)




False









VMName




varchar(100)




False









CPUConfig




Numeric(18)




False









MemConfig




Numeric(18)




False









VM_Host







 





Name




Data Type




Is Null Allowed




Comments








VMID




varchar(100)




False




PrimaryKey








VMUUID




varchar(100)




False









Cluster




varchar(100)




True









Host




varchar(100)




False









ResourcePool




varchar(100)




True









Folder




varchar(100)




True









VM_Network







 





Name




Data Type




Is Null Allowed




Information








VMID




varchar(100)




False




PrimaryKey








VMUUID




varchar(100)




False









Network




varchar(100)




True




Multiple Values Possible








IPAddress




varchar(500)




true




Multiple Values Possible








VM_Datastore







 





Name




Data Type




Is Null Allowed




Information








VMID




varchar(100)




False




PrimaryKey








VMUUID




varchar(100)




False









DiskSize




varchar(100)




True




Multiple Values Possible








Datastore




varchar(500)




true




Multiple Values Possible








I am not a database Admin and I cannot say if this is a good DB schema, but it fits my needs and I can grow with additional tables.


As Database a use a MS-SQL Server. My DB is named LittleCMDB. Here is the Script to create the DB on an MS-SQL or MS-SQL Express DB.


USE [LittleCMDB]
GO
/****** Object:  Table [dbo].[VM_Network]    Script Date: 07/13/2012 15:33:09 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[VM_Network](
[VMID] [varchar](100) NOT NULL,
[VMUUID] [varchar](100) NOT NULL,
[Network] [varchar](100) NULL,
[IPAddress] [varchar](500) NULL,
CONSTRAINT [PK_VM_Network] PRIMARY KEY CLUSTERED
(
[VMID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
/****** Object:  Table [dbo].[VM_Info]    Script Date: 07/13/2012 15:33:09 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[VM_Info](
[VMID] [varchar](100) NOT NULL,
[VMUUID] [varchar](100) NOT NULL,
[VMName] [varchar](100) NOT NULL,
[CPUConfig] [numeric](18, 0) NOT NULL,
[MemConfig] [numeric](18, 0) NOT NULL,
CONSTRAINT [PK_VM_Info_1] PRIMARY KEY CLUSTERED
(
[VMID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
/****** Object:  Table [dbo].[VM_Host]    Script Date: 07/13/2012 15:33:09 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[VM_Host](
[VMID] [varchar](100) NOT NULL,
[VMUUID] [varchar](100) NOT NULL,
[Cluster] [varchar](100) NULL,
[Host] [varchar](100) NULL,
[ResourcePool] [varchar](100) NULL,
[Folder] [varchar](100) NULL,
CONSTRAINT [PK_VM_Host] PRIMARY KEY CLUSTERED
(
[VMID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
/****** Object:  Table [dbo].[VM_Datastore]    Script Date: 07/13/2012 15:33:09 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[VM_Datastore](
[VMID] [varchar](100) NOT NULL,
[VMUUID] [varchar](100) NOT NULL,
[DiskSize] [varchar](100) NULL,
[Datastore] [varchar](500) NULL,
CONSTRAINT [PK_VM_Datastore] PRIMARY KEY CLUSTERED
(
[VMID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO




For the usage of a DB in Orchestrator, you can use the SQL-Plugin. The Plug in could be get from the VMware Website (https://my.vmware.com/web/vmware/details?downloadGroup=VCO_SQL_PLUGIN_10&productId=229)


The Installation is done over the Orchestrator Configuration site (http://ORCHESTRATOR_IP:8282). I will not describe the installation. If you are not familiar with the plug in installation then RTFM in the official documentation here http://pubs.vmware.com/orchestrator-plugins/index.jsp?topic=/com.vmware.using.sql.plugin.doc_10/GUID-66110FFD-EB0F-484A-937B-8C131C8DFFB2.html


After you finished the installation of the SQL Plug in, it is time to integrate the SQL Server and the required Database tables.


You can add your database with the vCO Client  Workflows  Library  SQL  “Add a database”




There you have to define your SQL Connection Details. In my case, that are the required parameter for the SQL connection. In my case that are:


    

  • 

    A name for the connection
    

    • 

  • 

    The SQL Server IP with Port and database name (for details look in the screen shot..)
    

    • 

  • 

    A username with permissions on the DB
    

    • 

  • 

    And the password for the user
    

    • 





After the database is successfully added, we have to integrate the preconfigured tables. This is done with the workflow “Add tables to a database”


 


After the start of the workflow we first have to choose the database




In the opening window we take our DB (LittleCMDB in my case…)


 


Then we have to integrate our tables


 


You can add tables by clicking in the “Tables” field


 


there you have to insert all fields beginning with VM_*. Add the end the your Array of String has to look like this:


 


After you have „Accept“ your choice you can „Submit“ the Workflow.


 


Before I start to generate the SQL Statements, I create a Folder in which I will place my SQL-Statements. For that I have created a folder “vcoportal.de” there a sub folder “LittleCMDB”. In the “LittleCMDB” Folder a also created a Subfolder with the name “SQL-Statements”.




Feel free to change your names and folders, i prefer this structure.


To generate your SQL-Statements we have to browse to the Workflow “Generate CRUD workflows for a table”




This Workflow must be executed for every table we want to use.


For that, you have to provide the following inputs:


    

  • 

    The table
    

    • 

  • 

    The destination directory
    

    • 

  • 

    If you want to overwrite existing workflows
    

    • 

  • 

    And the read-only columns
    

    • 



 


Here is a example for one of my tables:


 


When you are ready for your tables, take a look into your destination folder. For every table, there must be a record to “Insert, Update, Read and Delete” values in your tables.




The preparation of the SQL Server statements is done. Know we can start to build up our workflow to feed the SQL Database…..


So, that’s all for Part1. Stay tuned for Part2. Then we will start to create the Workflow…..






SQL Script





SQL Script

LittleCMDB_SQL.zip








622.0 B

Details...












0
Introducing: The LittleCMDB (a vCenter Orchestrator & WaveMaker Demo-Project)




By 
Joerg Lew


 – July 17, 2012Posted in: Call Workflows from outside, Database, Examples, Get Started!, Integrate vCO, vCO Use-Cases, Wavemaker

 


It is a pleasure for me to write these lines as an introduction to a full series of articles, posted on vcoportal over the next couple of days:


Christian Strijbos (you remember his posts about WaveMaker and vs. LDAP a couple of weeks ago!?) put together a comprehensive project involving vCenter Orchestrator (and its SQL Plugin) and WaveMaker:


***…drumroll…***


The LittleCMDB


***…drumroll…***


Features


The LittleCMDB is a Workflow-driven Database Application which stores information of Virtual Machine configurations in a SQL database. The user can see the configuration via a web-based UI. It’s even possible to file a Request to change the configuration of a VM via the Web-Frontend, it will automatically processed and the settings of the VM will be adjusted.


In short, you can…:


    

  • Show the current Virtual Machine configuration in a Web-Frontend
    • 

  • Initialize the Database automatically
    • 

  • Refresh the Database when the configuration of a Virtual Machine changes
    • 

  • Let the users change the Virtual Machine configuration via a Web-Frontend
    • 



Architecture


LittleCMDB uses Orchestrator Workflows to implement the “business logic” of the application. For that it leverages the SQL-Plugin for vCO, so you don’t have to write a single line of SQL Statements.


There will be some backend Workflows which gather information from vCenter and store them into the Database.


The web-based frontend is built with VMware WaveMaker.




What you get:


We will publish a full guide how-to build the LittleCMDB from scratch, separated in different parts over the next couple of days (see the picture above also as a “Table of Content”).


We will also provide the Workflow Packages and the WaveMaker project to download.


Our main goal is to give you…


    

  • examples and “hands-on” guides to develop workflows in vCO
    • 

  • same for WaveMaker
    • 

  • an example how easy it is to create such a “CMDB application” using vCO Plugins
    • 

  • ideas to use vCO and WaveMaker for your own use-cases
    • 



So: Even if the downloadable workflows should  run quite out-of-the-box, do NOT use them for production!

The complete project is for educational purposes only.

(If you like the idea, and want something like that for your company, engage Christian for a project!  8-))


Now, get your vCO Lab ready and look forward to Part 1…


…tomorrow in this Theater :mrgreen:!


Here we go:


Part 1:

http://www.vcoportal.de/2012/07/little-cmdb-part1/


Part 2:

http://www.vcoportal.de/2012/07/littlecmdb-an-orchestrator-and-wavemaker-project-part-2/


Part 3:

http://www.vcoportal.de/2012/07/little-cmdb-part3/


Part 4:

http://www.vcoportal.de/2012/07/little-cmdb-part4/


Part 5:

http://www.vcoportal.de/2012/07/littlecmdb-part-5/


Part 6:

http://www.vcoportal.de/2012/08/littlecmdb-an-orchestrator-and-wavemaker-project-part-6/


Part 7:

http://www.vcoportal.de/2012/08/littlecmdb-an-orchestrator-and-wavemaker-project-part-7/







0
Using Onyx to speed-up Workflow development




By 
Joerg Lew


 – May 10, 2012Posted in: Examples, Get Started!, Tools

 


In the VMTN Community Forums for Orchestrator recently one question came up:


“…how to use orchestrator to change the Video Card Setting of a VM to “Auto-detect settings” the next time the VM reboots?” (read the full thread here: http://communities.vmware.com/message/2040860#2040860)


That is a typical task for a workflow developer: Automate something you can easily click in vSphere Client, but it maybe hard to figure out, how to automate it.



ONYX to the rescue!


See this video how to get to the solution in less than 15 minutes  :-D… (You can download the resulting workflow below, but that shouldn’t be necessary anymore 😛 !)




It’s a quick shot screencast, so no audio….


If you like the style, drop me a comment, and I will create more videos (with explanations  😎 ) in future!




Change VM Video Settings Workflow





Change VM Video Settings Workflow

Change-VM-settings-to-auto-detect-video-memory.workflow








2.1 KiB

Details...