TeamCity VMware vSphere plugin

Julia Alexandrova

TeamCity always aims at giving your team more build power, and for those of you taking advantage of local cloud capabilities with VMware vSphere, the new TeamCity VMware vSphere plugin will surely be an asset. With this plugin, TeamCity can start and stop TeamCity agents installed on VMware virtual machines on demand, similarly to integrations with Amazon EC2 and Azure .

TeamCity-VMware cloud agent integration requires:

  • the TeamCity VMware vSphere Cloud plugin (compatible with TeamCity 8.1+) installed on the TeamCity server;
  • a configured virtual machine with an installed TeamCity agent in your cloud set up to start the TeamCity agent on boot,
  • a configured cloud profile on the TeamCity server.

Let’s go step-by-step and set up the integration.

Install the plugin and configure the virtual machine

Since the plugin is not bundled with TeamCity, we need to install it on the TeamCity server. Next we need to create a virtual machine where our builds will run.

The virtual machine with the TeamCity agent needs to be prepared as described in our documentation; when configuring the TeamCity build agent, be sure to specify the valid TeamCity server URL in the build agent properties.

After you start the build agent, it connects to the server, and you need to authorize it in the TeamCity Web UI so that the builds can run on the agent. Please ensure that the agent that connected to the server can actually run the builds you want it to run later.

When configuration and testing is complete, power off the virtual machine. If we want TeamCity to clone this virtual machine for us, we need to create a snapshot of this virtual machine.

You can also use the machine you created to make a template, see more information in the VMware vSphere documentation.

Configure the TeamCity VMware profile

Next we need to create an agent cloud profile in TeamCity on the Administration | Agent Cloud page selecting VMware vSphere as the cloud type.

A profile name is required; it is also recommended to configure the Terminate Instance Idle Time setting which will save you the resources: it specifies the period of time for the virtual machine to run without builds after which TeamCity will stop it. You also need to provide the cloud access information, including the vCenter SDK URL and your user credentials.

You can verify your credentials using the Test connection / Fetch options button, which also refreshes the information on the virtual machines, snapshots and resources available in your cloud.
Now we can add images and specify the virtual machines or templates we want TeamCity to use.

The VMware vSphere plugin can either start and stop an existing virtual machine, or clone virtual machines from snapshots deleting the clone after the machine is stopped. For templates only the clone behavior is supported.

Click Add Images and select the virtual machine and the desired behavior. For the clone behavior, select the snapshot to use, the folder for clones and the resource pool where your machine will be allocated. The maximum number of instances will limit the clones created.

In this test set up we are using the clone behavior with 2 being the maximum number of instances: TeamCity will clone a machine from the specified snapshot and will delete the cloned machine after it is stopped:

When the images are added and the profile is saved, a clone is created from the snapshot. It connects to TeamCity and TeamCity processes build configurations-to-agents compatibility.

As with all cloud integrations, you can view and manually start/stop the cloud agents on the dedicated Agents| Cloud page in the Teamcity Web UI:


Our integration is configured. Now when distributing queued builds, TeamCity will start a compatible agent in vSphere if required.

The agent will be authorized automatically and will start running builds. The Agents page will display the builds running on the cloned machines:


Try the plugin and don’t hesitate to share your feedback with us!

Happy building!

Comments below can no longer be edited.

7 Responses to TeamCity VMware vSphere plugin

  1. Ryan says:

    December 8, 2014

    I was wondering why this plugin requires “resource pool” support. Right now we operate on an Essential Plus license and it has the features we need and it is a big cost difference to go to Enterprise or Enterprise Plus licenses. Can “resource pool” support be made optional?

    If this is not the best format for this feedback please let me know where to go.



  2. Nadav says:

    December 11, 2014

    is the VMs that team city starts must be connected to the net?
    i want the agents to be without any network connection available during build.

    • Sergey Pak says:

      December 15, 2014

      It is our general requirement that there must be a bi-directional connection between server and agent, no matter whether the VM is started by TC or by a user.
      If VM is not connected to the network, agent will not be able to connect to the server and grab a build to run.

  3. Jeff McIntosh says:

    December 23, 2014

    What are the Team City Build Agent licensing requirements for the VMs that are spun up by the vSphere plug-in?

    We already have a small farm of VMs in vSphere. What’s the value-add for this plug-in? If not licensing, then all I see is the ability to power down agents that aren’t in use. What else am I missing?

    • Pavel Sher says:

      December 30, 2014


      Nothing changes from the licensing point of view. You still need a license for each authorized agent.

      If you’re already running agents on vSphere then you probably manage them manually or you have to write custom scripts to do that. This plugin simplifies agent management process.

      First TeamCity will start agents based on current demand, thus leaving more resources to other virtual machines on vSphere.

      Secondly, since VM instances are started/stopped/authorized automatically, if you need to update software all you need to do is update image and tell TeamCity which snapshot to use. If you do that manually, you’ll have to restart instances in vSphere one by one (and do not forget to check whether a build is running there). This is tedious and not easy to do even if you automate this task.

      If you have 10 agents, this plugin probably does not add much value. But for 100 agents and more, plugin value becomes more apparent.

  4. Kiran says:

    February 4, 2017

    Nice Article.
    Cloud you explain the common issues we face regularly in VMware Vsphere administration?
    VMware Geek


Subscribe for updates