I can confirm this error.
Precondition:

• Jenkins is connected to a vCenter instance
• Two templates (or VMs) available on the vCenter instance

Steps:

• Add a vSphere cloud
• Verify the connection by clicking "Test Connection" --> "Success"
• Register first VM by adding Template A name, and verify by "Check Template" --> "Success"
• Register a second Template A (or Template B) by adding anoter "Add vSphere Template"
• Verify by "Check Template"
  • --> Leads to error attached in text file: "Problem validating org.jenkinsci.plugins.vsphere.tools.VSphereException: com.vmware.vim25.InvalidLogin: Cannot complete login due to an incorrect user name or password."

Expected:

• Should lead to "Success"

Attached:
ErrorSTackTrace_SecondvSPhereTemplate.txt

We found a workaround, and probably the cause of the bug:

You have to go the template settings of your last added template (one above the one you see the validation exception), and change the "Launch Method" to "...via SSH". Then a credential window appears. Make sure to change to the credentials, which actually have access to your vcenter instance (in the screenshot: "jenkins_control").
Then press "Check Template" and it should work.

Hi Michael,

the workaround you provided didn't worked for me. I changed the Launch Method the SSH and select the credentials which i already select for the Vsphere host, instead the one i have to use really for SSH connection. But i get the same error before.

Hi Jan,
did you press apply after changing to the vsphere user? Maybe the change was not persisted.
After checking the template connection successfully you can change back to JNLP or whatever you had as a setting, and go on.

Hi,

yes saved the settings, but same results. Currently i worked around this bug with a second Cloud Instance.

Are you sure you set the first section in the config dialog also right?

------
General config
vSphere Cloud
Name of this Cloud Help for feature: Name of this Cloud
vSphere Host Help for feature: vSphere Host
Credentials: user which can control vsphere

Template 1
set the agent credetnail temporarly to vpshere user (as described )
—
Template 2

Are your vsphere user credentials really working? e.g. Template 1 check is successful?

Hi Michel,

now i got it. I only change the SSH User for template 2 instead of changing it on template one for validation.

Thanks for help.

So hope this workaround helps to find the bug.

I am noticing the same error as well though i am not using SSH authentication! I will try to find out where the bug is.

Is there any progress on this bug? The workaround doesn't work for me – rather, I have created a new vSphere host for every template, which is a bit annoying. It would be nice to have a proper fix for this issue.

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.