Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

Plugin Information

View VMware Lab Manager Slaves on the plugin site for more information.

The current version of this plugin may not be safe to use. Please review the following warnings before use:

Add VMware Lab Manager support to Jenkins


This plugin add to Jenkins CI a way to control Virtual Machines hosted on VMware Lab Manager. You can configure a Jenkins Slave, selecting a virtual machine from a Organization / Workspace / Configuration triplet, in this way, when you need to build a Job on a specific Slave, this VM will be startup up and shutdown or suspended again after the build process.


To rebuild the WSDL2Java created files you will need to install Axis2 and use the wsdl2java program. All runtime requirements are included.


Lab Manager cloud

The first step is to configure Hudson to know what configuration in Lab Manager you will be using. To do this you need to add a new "Cloud" in the Hudson "Configure System" menu.

The required parameters to setup are:

  • LabManager Host: The base URI of the Lab Manager host, e.g. https://example.server/
  • Brief description of this overall configuration: A textual description of this "cloud" that will be used when choosing Virtual Machines for slaves
  • LabManager Organization: The Organization name in Lab Manager where the virtual machines reside.
  • LabManager Configuration: The Configuration name in Lab Manager where the virtual machines reside.
  • Username: username to use to connect with Lab Manager
  • Password: the password for this account

If you need some other particular settings, you can click on the Advanced button to change the default parameters.

  • LabManager Workspace: The Workspace name in Lab Manager where the virtual machines reside. If not listed the default of "main" will be used.
  • Max number of slaves online: A limit on the number of VMs in this cloud that can be on at any given time.

To verify all you parameters you can click on Test button and check the output reported.


Now you can setup your nodes in hudson and use them to build your projects.
On the creation page you just simply select the correct radio button to configure a slave that runs inside of Lab Manager.

Going ahead with configuration you can see a page that looks like the normal node creation page, with three combo box added. The first one where you have to select the Lab Manager instance (the brief description provided in the configuration section). In the second one you pick the name of the Virtual Machine in Lab Manager configuration that you are using. In the third drop down you select the action to be taken when the VM is idle (it is recommended to pick shutdown over suspend due to overhead in Lab Manager).

If you then select the option to have the slave be taken on or offline based on demand. Note that if you select Shutdown or Shutdown and Revert for an idle behavior the slave will not be available immediately. It will however come online once demand is polled a second time. Next, if using a JNLP slave (ie for Windows), you must check the Force VM launch option. Doing this along with the normal best practices to have a Windows slave turn on and auto-start the JNLP client is all that is required specially for Windows. Finally, you can set the delay between telling Lab Manger to get the VM online and Jenkins attempting to connect to it as a slave. This value is in seconds. All slaves must have the VMware Tools installed in order for it to be cleanly managed.

Change Log

Version 0.2.8 (Aug 05, 2011)
  • Update my email address.
Version 0.2.7 (Jul 18, 2011)
  • Fix SCM location in pom.xml (caused 0.2.6 to be non-existent)
  • Fix a problem with displaying the boot delay number
Version 0.2.5 (Jul 8, 2011)
  • Fix the problem of non-Lab Manager Plugin slaves failing to launch.
Version 0.2.4 (Jul 7, 2011)
  • Add an optional limit on number of VMs per cloud that can be online at once.
  • Add an option to the slaves for delay between asking Lab Manager to bring a VM online and attempting to connect to it.
  • WARNING Breaks non-Lab Manager Plugin controlled slaves
Version 0.2.2, 0.2.3 (Jan 24, 2011)
  • pom.xml changes for new infrastructure, no code changes (and 0.2.1 was unavailable via update center).
Version 0.2.1 (Jan 22, 2011)
  • Compute the list of Virtual Machines in the configuration each time we need it so that we will catch changes.
  • Fix a problem with Windows slaves and the "Force VM launch" option not working.
Version 0.2.0 (Dec 14, 2010)
  • Fix a thinko in handling the 'Shutdown' idle action.
Version 0.1.9 (Dec 13,2010)
  • Fix the dropdown menu for selecting Virtual Machines after performing a configure.
  • Fix a problem with non-Lab Manager slaves having problems picking their launcher.
Version 0.1.8 (Dec 08, 2010)
  • Add "Shutdown and Revert" as an option for idle VMs.
Version 0.1.7 (Dec 07, 2010)
  • First version published.


  1. Unknown User (casetaintor)

    I'm curious what configuration you used to connect to the slave computer. I have it working so that it starts up and shuts down VMs in Lab Manager, but I'm unable to get it to actually start the Hudson slave process on these machines. Do you start it via SSH? Have you tried this on Windows? JNLP? Any help would be greatly appreciated.

    1. Unknown User (mbaker000)

      From what I can gather, if it's a Windows slave you'll need to follow the instructions described on this page.  You have a couple options:

      1. If your job doesn't need access to any kind of GUI, you can allow it to connect using the Remote Management Service.
      2. If your job needs access to the GUI, I recommend creating a startup.bat script that calls the JNLP link and drop a shortcut to it into the startup folder.  I usually put this script in the Jenkins root directory.  Then, in a Run... box type control userpasswords2 and make it so that it will log in to the machine automatically.  Then, all you have to do is start up the VM and it will boot up, log in, and connect to Jenkins as a node.

      Unfortunately it doesn't look like it's so streamlined as to allow Jenkins nodes to be created and destroyed automagically (and allow driving by Labels only), so each Lab Manager node will need to be added to Jenkins manually and connect/disconnect as the same node each time.  However, with some Jenkins CLI magic you might be able to accomplish this when the slave goes to start up.

      Hope this helps!

  2. Unknown User (trbaker)

    It isn't clear to me how/if the plugin is deploying the vm.  The cloud part for getting the instance and vm name is working, but I seem to have to deploy the vm via lab manager manually to get the ip address, which I then need to use in the secondary launch ssh configuration.  I had hoped that the plugin would log into lab manager, start a vm given the specified paramaters, and return a variable containing the IP that I could use in the secondary launch.

    My company has strict lease policies on vms, and I have hoped to skirt that via this plugin's ability to start/stop depoy/undeploy.  Can you clarify, and thanks for your efforts!