Introduction to Automation via vCenter Orchestrator – Yes you can!


Automation is something that was started in the industrial revolution. It introduces processes to automate repeating tasks so that quality is maintained or even better (by designing, testing and debugging the process), and minimal or nil human intervention is needed. If you can repeat it, automate it. Well not all, don’t repeat failures, issues and such ;-).
This creates efficient infrastructures, and more important efficient IT departments that can focus on other tasks then repeating that same boring task list all day long.

Automation in the VMware product suites can be done with several products, like vCenter Automation Center for cloud, puppet, scripts, third parties products and the like; but with your vCenter infrastructure there is already a component you can leverage vCenter Orchestrator or vCO for short. With vCO, the VMware administrator can create, using a drag and drop interface, a workflow to for example provision new servers. With steps like deploying a template, customizing the system and installing applications. With plugins additional tasks as creating an Active Directory object, or adding a change request to the IT management system to create the storage needed for you VM’s can be added as well. The prebuild workflows library already has hundreds of out-of-the-box workflows to start using immediately

And the best part, when you installed a licensed vCenter server system, you already have it. Start using it!


vCenter Orchestrator can be installed next to vCenter on a Windows system via the vCenter installer (it will by default), or via the vCenter Orchestrator appliance. With the vCenter Server Appliance you don’t have vCO components, you will have to add vCO on a Windows server or add the vCO appliance next to the VCSA. When installing on a Window system use the vCenter server installer to install orchestrator as a component, or do it on a complete separate system. But then prepare your environment by installing a SQL database and starting the vCenterOrchestrator.exe from the vCenter-Server/vCO directory on the install media. Installing the orchestrator appliance is downloading and deploying the OVF. When receiving an IP address the rest of the configuration can be done via a supported web browser.

Orchestrator is composed of three distinct layers: an orchestration platform that provides the common features required for an orchestration tool, a plug-in architecture to integrate control of subsystems, and a library of workflows accessed from the client application (addon to vSphere web client). Other components are the directory services or SSO, the database, and web services for browser access and REST/SOAP API.


Orchestrator is an open platform that can be extended with new plug-ins and libraries, and can be integrated into larger architectures through a SOAP or REST API. In my opinion this is the strength of automation tools to leverage the ability to integrate in the infrastructure architecture and not having the orchestration focus on the primary product architecture. With the plugins architecture automation via vCO is reaching beyond the VMware infrastructure, with plugins for AWS, SQL, Active Directory or leveraging SOAP/REST and such.

Release / License

With the release of vSphere 5.5, vCO is at 5.5 as well (well 5.5.1 for the appliance). You can download the integrated installer or the appliance from your MyVMware vSphere 5.5 entitlements.

Orchestration is licensed from the vCenter license. vCO will run either in Player mode: allowing you to run but not edit workflows. Or in Server mode; allows you to run and edit workflows.
Player mode comes with the vCenter Essential and vCenter Foundation licenses, and server mode is leveraged with the standard and higher licenses.


The plug-in architecture, you can automate tasks across both VMware and third-party applications.

Plugins can be developed specifically for your needs, by partners. You can find already created plug ins at VMware Solution Exchange. Just log in and search for vCO.



Going further?

Yes, definitely. But I will follow up in more blog posts.


VMware launches Horizon 6 – a change was needed….and so it happened

Maybe a little late as the announcement was a couple of days ago, but I wanted to write about the VMware Horizon 6 launch as I think some of the news is a real changer on the part of VMware.
VMware Horizon with the 6 version goes from a VDI perspective to a VDI and published shared resources (aka server Based Computing aka server based desktop aka session hosts) perspective. And speaking on behalf of the customers I do consulting for and several head-to-head comparison talks; published desktops and published application are a, or the, great part of the requirements of organizations. Before version 6 this was a key kick out criteria for a lot of organizations not to be matched with only VDI and VMware Horizon. Yes, you could do some form web application publishing in Workspace but very limited, and yes you could do terminal services by leveraging Remote Desktop Services Session hosts (RDSH), but only on the RDP protocol and not via client PCoIP.

A change was needed…..And so it happened…

On April 9th VMware unveiled VMware Horizon 6. VMware Horizon 6 is an update to the suite of end-user computing (EUC) solutions from VMware. The suite is designed to deliver desktop and applications through a single platform to any cloud (public, hybrid or private) in a uniform and seamless workspace for the end user no matter what the endpoint device is.

A few highlights of some the new capabilities in VMware Horizon 6:

  • Published applications and virtual desktops delivered through a single platform; Starting with on of the biggest part of the announcement. Horizon offers application (Hosted apps) and desktop virtualization delivered from a single solution. Published and shared desktop based on RDSH with full view integration (PCoIP). Supporting one-to-one desktop OS (the VDI part what View was doing all along) and now the one-to-many server OS (published desktop and/or applications). Key feature of this version!
  • Storage optimization using VMware Virtual SAN aka VSAN. Virtual SAN Desktop is the shared virtual storage for Horizon Desktop virtual machines. Cuts costs. And more important from user experience point of view provides the Horizon workloads their IO right where it’s needed (on or close to the host without traversing a storage infrastructure) and is simpler for IT operations. Deliver desktop services without the need for traditional storage. Was around already in the previous release, but now even tighter marketed and in my opinion Virtual SAN is a perfect match for desktop workloads.
  • A unified workspace for simplified access; provides one place for IT administrators to provision, and users to access applications and desktops resources. Saas, Office 365, published applications, published desktops, virtual desktops, local ThinApp’s or XenApp integration. Highly customable to included your own company branding.
  • Central Image Management; Offers central image management of physical (what we were used to with Mirage), virtual (yes check, and physical to virtual image management is great for DR of the oops I forgot my device and have to work stat on my latest versions – employees) and delivering secure containers to employee-owned BYO PC scenario’s (Will have to see about this one.) with latest updates to VMware Mirage.
  • Hybrid cloud delivery; Gives the ability to deploy Horizon 6 in a hybrid cloud through a single integrated Horizon client that seamlessly connects to virtual applications and desktops.
  • Cloud Pod architecture improvements; Scale the View Horizon infrastructure over multiple data centers to 20000 desktops.
  • Operations and resource management/planning and automation; Leveraging VMware Operations for View for operations management and view of your virtual infrastructure, and using vCloud Automation Center or vCenter Orchestrator (with added plugin for desktops) to help automate this environment.


(picture taken from the website)

There is even more changes as the naming of components in the suite have also changed.


Have we all learned to pronounce the Horizon part with some of the components (did we really?), is it changed back again…..;-)

Editions / Licensing.

Three editions of VMware Horizon will be available:

  • Horizon View Standard Edition: Deliver simple, high-performance, VDI-based virtual desktops.
  • Horizon Advanced Edition: The needed solution to published and virtual applications and desktops using VMware Virtual SAN, central image management and a unified workspace for managing and delivering all applications and desktops.
  • Horizon Enterprise Edition: Advanced with additional automation and management capabilities for hybrid cloud flexibility.

Horizon 6 has the same licensing options as with the Horizon Suite; with Named User or Concurrent User licenses. Prices start at $250 (Note; reference purposes only, real price to be determined).

When when when?

VMware Horizon 6 is expected to be available in Q2 2014, and according to the license KB upgrades will be around in July.

When you already have the Horizon Suite, you will automatically be upgraded to the Horizon Enterprise Edition at no charge. Those eligible will automatically receive the upgrade to the Horizon Enterprise Edition in July, they will receive new license keys in My VMware.


vSphere Auto deploy TFTP on Citrix PVS

I occasionally do a deployment of Citrix on vSphere. When using Citrix a returning component is Provisioning Services (PVS) for automated deployment of Citrix session servers or VD images. When using a management cluster (to prioritize and separate control layer or infrastructure components) an option is to use auto deploy for the session images hypervisor hosts (depending on the edition, depending on the cluster requirements).
One of the components to use in auto deploy is TFTP for the boot image. This can be leveraged for PVS as well, as PVS also needs a type of boot image to start up the VM’s. With PVS this is also a TFTP service (or boot image, but we leave this out for this posting) that is installed at the PVS server.

Why not use this TFTP service as vSphere Auto Deploy does not include one?

What is Auto Deploy?

vSphere Auto Deploy facilitates a infrastructure for automatic server provisioning and network deployment (streaming) of the ESXi hypervisor image. It uses a central managed image, administrators just need to manage the central image and the host profiles. The deployment can be on local storage, state full on HDD, SD or USB or stateless to the hosts ram. It works in conjunction with:

– vCenter,
– host profiles,
– TFTP server,
– Auto Deploy server and Image Builder,
– a PXE boot infrastructure with a DHCP service.

These services can be installed on the vCenter host or hosted/integrated on specific services. When using the stateless host option be sure to have a high available Auto Deploy infrastructure. For example load balancing the TFTP and auto deploy services.

Auto Deploy and host profiles are available from the Enterprise plus Edition. Okay, not always will a virtual desktop cluster be set up with Enterprise Plus, but we can also do this in the management cluster as long as we prioritize the right machines.

What is PVS?

Provisioning Services infrastructure is also based on software-streaming technology. This technology allows computers to be provisioned and re-provisioned in real-time from a single shared-disk image. In doing so, administrators can completely eliminate the need to manage and patch individual systems. Instead, all image management is done on the master image.

PVS works with:

– PVS vDisk store for the master image,
– PVS Console for setting up farm, device collections and managing updates and assignments,
– PVS Streaming service,
– PVS Citrix Shared components, such as MSSQL data store, License server,
– PVS Network services DHCP, PXE and TFTP.

Boot image

A boot image or boot strap file is a small kernel used to start up the machine, connect to the network and receive it’s image via network. The boot file must be configured so that it contains the information needed to communicate with the streaming services, Auto Deploy or PVS.

Putting it all together

As the list above we have some components that are used on both the infrastructures, DHCP, TFTP and PXE. The DHCP is used to provide a bootp image server and image name to the PXE clients (options 66 to the PXE/TFTP on the PVS server and 67 for the boot image name). The PXE infrastructure is a networking zone where client connect to. These clients are configured to boot from network (change the VM bios boot order for example). This can be a separate network, a logical separated network (vLAN) or just a one in all network (policies are advisable to guarantee some networking bandwidth to different types) depending on the requirements of the organization. We will be using a DHCP scope already set up on Microsoft DHCP and TFTP service on the PVS server (why set up more than one).

We can setup the DHCP options on scopes (if logical separate networks) or on leases (DHCP reservations for the smallest amount of host. If we have less ESXi hosts than streaming VM’s we put a scope option to the common image and use DHCP reservations to the other image). We will use to same TFTP service (66), but depending on the sort of machine (VM or ESXi host) we use a different boot image name.

First we get the Auto deploy TFTP image from the vCenter service and put it in the PVS image locations. We connect to the vCenter services via the Web client and browse to vCenter, vCenter server name, manage and auto deploy. Here we have the option to download the TFTP boot zip.


The boot zip is a collection of vSphere boot straps with the correct IP of your auto deploy service (it is created on installation).


Next we connect to the PVS server and go to the PVS TFTP image location. This is in C:ProgramDataCitrixProvisioning ServicesTFTPboot.


Here we place the Auto Deploy images from the boot zip.


Next up we change the DHCP options accordant, I used the DHCP scope options for the PVS image and used a reservation for the ESXi hosts (as these are just three hosts). Citrix is using the ARDBP32.bin image from the lab PVS server.


And VMware is setup to use the undionly.kpxe.vmw-hardwired image from the same lab PVS server.


Let’s boot the machines up. First the ESXi host. It receives the correct VMware image and starts to boot the base image from auto deploy.


Next up start a VM to use the PVS stream image:

imageIt boot’s up to connect to the PVS server. Unfortunately I apparently forgot to add an entry for this device (auto create is off as well), no vDisk in this example. But if we add a vDisk this will load as well.


Alternatively we can setup a TFTP service in on a other host if we want to separate this service from the PVS service and do the same for the Citrix boot image. Just follow the same procedure and add the Citrix images as well.

High Available

Standard the TFTP service is not high available, and when using multiple dependent services the need to increase availability is even higher. Set up a High available PVS, auto Deploy service by for example leveraging a Netscaler (or other LB with service check technique) to load balance the TFTP services and streaming services.

vExpert 2014 Announcement

Last year I started to get more involved in the social community and starting to write blog posts to share the knowledge for this community and for my co-workers.

It’s a great honour to be awarded and to be added to this years list of vExperts. I’m glad to be a part of the community and a big thank you is in order to be selected in this list.

The Listing continues

I am currently part of a list of 754 vExperts around there. The full listing can be found over here:

Not yet on the list, are active and want to be included? Well go ahead and apply for the Q2 round. You can do that here:


Congratulations to all the 2014 vExperts, new and returning! Keep up the good work, I will try to do so myself.