Ah, this is the same issue as I've just reported in JENKINS-46712.  I'll close that one and reference this one (as this one got here first) but I've identified the underlying cause.

nre_ableton FYI you don't need a new host for every template - the problem is purely cosmetic - you can't "Test" any template except the first but they'll all still work when Jenkins uses them "for real".

The latest code (2.16) makes it easier to drag their order around so you can now work around this just by dragging the one you want to test to the top of the list, but I agree that this is far from ideal.

Downgrading to "minor" as this is only a cosmetic bug (it doesn't affect actual plugin operation, it just looks bad on the GUI).

This is kind of weird: I checked against the plugin's minimal Jenkins version (1.625.3) by running from the sources and could successfully validate a first and a second template. After upgrading the Jenkins base version to <jenkins.version>2.60.3</jenkins.version> in the plugin sources and upgrading plugins in the running Jenkins instance, I could reproduce the problem described above: only the first template could be verified.

When vSphereCloudSlaveTemplate.DescriptorImpl#doTestCloneParameters is called on the first template, the query parameter credentialsId is correctly populated with its value from src\main\resources\org\jenkinsci\plugins\vsphere\VSphereConnectionConfig\config.groovy.

When it is called on the second template, credentialsId is passed as an empty string.

Strangely enough, the boolean value allowUntrustedCertificate, which is located at the same scope as credentialsId, is passed correctly in both cases.

So the behaviour is influenced by dependency changes.

Hint for anybody who wants to track down this issue: No VMware product is needed to debug this. It all burns down to the question whether a valid credentialsId is passed to the validation handler for the second template, which can be examined with dummy data like this:

1. create dummy global credentials
2. in /configure, add a cloud (no values required), choose the dummy credentials
3. add two templates (no values required)
4. save
5. set a breakpoint on org.jenkinsci.plugins.vSphereCloudSlaveTemplate.DescriptorImpl#doTestCloneParameters
6. click Advanced..., then Check Template on the second template
7. check the value of the credentialsId method parameter. It should be a valid ID, e.g. "1ccb2925-0076-4ccb-9d69-7c2f24d65303". In the failing case, it is empty.

I found a szenario where success or failure only depends on the installed version of the SSH Slaves plugin. The vSphere plugin declares 1.11, current at time of writing is 1.26.

I used the Jenkins base version 2.60.3 because it is the last LTS version that has a war-for-test and I don't know how to use more recent versions in plugin development.

1. Set the Maven property <jenkins.version>2.60.3</jenkins.version> in pom.xml
2. mvn hpi:run
3. do not install any plugins
4. update all plugins except SSH Slaves, restart Jenkins
5. create dummy credentials, a cloud and two templates as described in my previous post. save.
6. check validation of the second template. It should succeed (valid ID being passed)
7. Upgrade SSH Slaves (from 1.11 to 1.26 at time of writing). restart Jenkins
8. check validation of the second template. It should fail (empty ID being passed)
9. restore SSH Slaves to its previous version (1.11), restart Jenkins
10. check validation of the second template. It should succeed again.