VCAP study notes – 8.2 VMware Orchestrator
Automation is becoming increasingly popular and important, and VMware’s Orchestrator is another automation/scripting product but with loftier aims – to provide an extendable orchestration platform to enable a dynamic infrastructure. To date it seems to have gained very little traction or attention (most blog and twitter articles cover PowerCLI) but VMware obviously want to promote it – hence it’s inclusion in the VCAP-DCA blueprint.
- Identify vCenter Orchestrator requirements
- Identify default Orchestrator plug‐ins
Skills and Abilities
- Install and Configure vCenter Orchestrator
- Configure vCenter Orchestrator database
- Configure vCenter Orchestrator LDAP connection
- Configure vCenter Orchestrator vCenter server connections
- Run a Workflow
- Administer Actions, Tasks, Workflows and Policies
- Administer Packages
- Identify appropriate Workflow for a given management activity
Tools & learning resources
- Product documentation
- vCenter Orchestrator Installation and Configuration Guide
- vCenter Orchestrator Administration Guide
- vCenter Orchestrator Web Configuration
- vCenter Orchestrator Client
- vCenter Orchestrator homepage
- vCenter Orchestrator team blog, especially their Learn vCO series
- Communities roundtable podcast #91
- An Introduction to VMware Orchestrator (VM5361, VMworld ’09)
- MA8030 Saving Time with VMware Orchestrator (VMworld ’10 session, sign in required)
- vCO APIs Powerpoint presentation (from @heyitspablo)
- The vCO posts at the ‘mighty virtualisation’ blog
vCO is an automation platform which integrates with vCenter, an LDAP directory (for delegation of permissions) and offers a plugin architecture to facilitate automation over a wider ecosystem. It consists of a client, a server, and database components and comes with some plugins ready to go;
- Included with vCentre Standard (Foundation & Essentials plus are read only workflows)
- Recommended – 4GB RAM, 2 vCPUs, 5GB disk. vCO server and database should be on separate servers.
- Windows 2003 (x64 only) or Windows 2008 (x32 or x64) – VMware compatibility matrix (p17-18)
- Database support: SQL 2005 (32 bit), SQL 2008 (64 bit), Oracle 10gR2 (SQL Express not supported but works). vCO v4.1 supports Oracle 11g.
- LDAP support: Active Directory 2003+, Novell eDirectory, Java Directory Server Enterprise Edition
- There are two clients – one bundled automatically when you install vCenter and the standalone client
- The bundled client (both v4.0 and v4.1) won’t run on Windows 2003 32bit. Not an issue for 4.1 as vCentre requires 64 bit, but could be issue if your v4.0 vCentre server is already 32bit. Check this post in VMware communities.
- The standalone client will only run on x32 Windows.
- Check compatibility matrix (page 19); http://www.vmware.com/pdf/vsphere4/r40/vsp_compatibility_matrix.pdf
- NOTE: End users (rather than Orchestrator administrators) access Orchestrator through a webclient, so browser compatibility is all that’s required (IE7+, FF 3+)
- Orchestrator (client and server) are installed automatically with vCentre but are NOT preconfigured.
- A 4.1 vCO can run against an older v4.0 vCentre but 4.1 specific workflows may not work
- 10 – vCenter servers per vCO
- 300 – ESX/ESXi hosts per vCO
- 15000 – connected VMs
- 150 – simultaneous workflows
- Works OK with vCenter Linked mode
Install and configure Orchestrator
- Create Orchestrator database (step 1 of 2)
- Check dynamic port setting (1190 if using out of the box vCentre setup)
- Create new database
- Start VMware Orchestrator Configuration service (set to Manual)
- Login to webpage (http://server:8282) using default vmware/vmware credentials
- Configure networking
- IP Address (leave ports on defaults)
- Import SSL certificate from integration services (vCentre, LDAP). This ensures that vCO uses secure communication when talking to these services.
- Configure LDAP
- Define DCs
- Base LDAP path for Users
- Base LDAP path for Groups
- LDAP path to vCO Administrators group
- Test Login
- Configure database connection then create database tables (step 2 of 2)
- Configure DB type (SQL or Oracle)
- Port (SQL default 1433, vCenter default 1190)
- Username/password (domain credentials)
- Database name
- SQL Instance
- Windows domain
- Create database tables – click on ‘Install the Database’
- Configure certificate services for the vCO server itself (used to sign packages for third parties etc)
- Create self signed certificate (if you don’t already have one)
- Licence the server
- Can use vCenter licence (specify host, username/password)
- Add plugins
- Enter credentials (need to be member of vCO Admin group)
- Configure mail services (to allow user notifications etc)
- Enter domain username (user@domain format)
- Restart the vCO configuration server (under startup options)
- Configure integration with Virtual Center
- Login and go to the Virtual Center tab
- Add your vCentre host (credentials DON’T user @domain.com)
- Use ‘share a single session’ – this is recommended best practice (vCO team blog).Determines how many connections are made from the vCO ser ver to vCenter.
- Install vCO as a service
- Start vCO
- Best practice is to now backup the configuration
C:\Program Files\VMware\Infrastructure\Orchestrator install path
vCenter_Orchestrator_InstallLog.log Install logfile (created in above path)
VMware vCenter Orchestrator server new service created during config
The default plugins can be seen via the vCO configuration webpage on the Plugins tab (and also on the architecture diagram at the start of these notes). Each plugin populates vCO with predefined workflows as described below;
- Common enumerated types
- SSH – allow you to issue remote command and file transfer sessions using either passwords or PKI
- Net – provides FTP, POP3 and Telnet functionality.
- Database – provides JDBC connectivity to a wide range of databases
- vCO WebOperator – adds a default webview for end users
- vCO Library – workflows to automate vCO itself (create workflow, create task etc)
- Mail – send and receive SMTP emails in your workflows
- XML – an XML parser to you can use XML import/export in your workflows
- vCenter Server – access to the vCenter API allowing you to automate your virtual infrastructure
- VMware Lifecycle manager is implemented as a plugin for vCO. It’s contains workflows for managing VM lifecycle.
- VMware’s new Cloud Director is built on top of vCO
- Netapp are working on various plugins to automate storage provisioning with Cloud Director.
- The VMware VIX API has also been exposed via a plugin. See the VMware Labs for details.
- There is a Microsoft plugin which allows use of WMI and querying AD.
NOTE: Some plugins require licences (although the built-in ones do not). These licences can be installed via the Plugins tab.
Administer Actions, Tasks, Workflows and Policies
This is a tricky objective – understanding how to create workflows, actions and policies is really a development task and beyond the scope of most administrators (according to VMware) so presumably you only need to know how to use the existing ones. The vCO team blog has a worked example for creating a provisioning portal (which was used at the blueprint for the Orchestrator lab at VMworld 2010) so I’ve based my studies on the functionality covered in those tutorials.
Actions (discrete steps such as creating a folder, delete a file etc)
- Create, Duplicate, Export, Import, Move. If you move an Action to a different module you may have to use the ‘Find Elements that Use This Element’ function to avoid breaking existing functionality.
Workflows (a series of actions and decisions which run sequentially until they reach an endpoint)
- User Permissions – View, Inspect (see schema and scripts), Execute, Edit, Admin. Cumulative.
- Credentials – For the full client or webviews the workflow runs under the context of the user who runs the workflow (Admin guide, p30). Nested workflows run under the context of the calling workflow. A scheduled workflow can be set to run as an alternative user. Doesn’t this mean you have to give all end users access to vCenter? What username shows up in vCenter?
- Attributes – static data or dynamically generated data used within the workflow (doesn’t involve the end user)
- Parameters – data passed into or out of a workflow. Typically user defined but can be passed in via another workflow
- Orchestrator comes with a built-in set of workflows which you can use ‘as is’ or as a base for your own custom workflows. These built-in workflows are read only – you have to duplicate and then modify if required.
- Workflows can be nested.
- There’s no mention of tasks in either the install or admin guides, so I guess this refers to scheduled Workflows?
- Event triggers based on activity of the system.
- There are no policies or policy templates by default
- NOTE: Policies are deprecated as of vCO v4.1.
When using the Visual Binding tab, how can you delete an assigned mapping?
- Workflows can be run in various ways – via the vCO client (either interactively or via the scheduler) or via a webview (again interactively or via a schedule).
- ‘weboperator’ is the default webview. Not enabled by default (right click, Publish)
- You may need to specify input values (depending on the workflow)
- NOTE: You can only run VMware workflows once the vCenter plugin is enabled.
You can check progress of a Workflow via the Schema tab or the Events tab for a given workflow.
- Packages contain workflows, policies, web views, resources and actions.
- Export packages to migrate content to another Orchestrator server.
- Import packages from third parties to extend the functionality of Orchestrator. For example there are no built in workflows to manipulate virtual switches, but you can use downloadable workflows on the Orchestrator communities page to add this functionality.
- You can apply DRM to packages to dictate what others can do with the contents.
Identify appropriate Workflow for a given management activity
You can search existing Workflows by name using the Orchestrator API search (Tools -> API Explorer)
There in a workflow for exporting Orchestrator logs for diagnostic purposes