[JIRA] (JENKINS-54521) vSphere plugin fails to recognise its own VMs

[pjdar...@gmail.com (JIRA)]

Title: Message Title

pjdarton created an issue   Jenkins / JENKINS-54521 vSphere plugin fails to recognise its own VMs Issue Type: Bug Assignee: Unassigned Components: vsphere-cloud-plugin Created: 2018-11-07 17:03 Priority: Trivial Reporter: pjdarton The vSphere plugin doesn't tell Jenkins about nodes until after vSphere has created them. If Jenkins gets rebooted after it's asked vSphere to create some new VMs but before vSphere has finished creating those VMs, the VMs will exist in vSphere but not in Jenkins. That can then result in naming collisions, where Jenkins asks for "node-1" but a VM called "node-1" already exists. vSphereCloudSlaveTemplate contains code (findWhichJenkinsThisVMBelongsTo(final VSphere vSphere, String cloneName)) which was intended to be able to recognize VMs that it had lost track of and "seamlessly" reconnect with them ... but this seems not to work. In my own setup, I've determined that the code final VirtualMachineConfigInfo config = vm.getConfig(); if (config == null) { return null; } is returning null. This causes the provision method to log a severe message "VM {0} name clashes with one we wanted to use, but it wasn't started by this plugin." where {0} is replaced by the name of the VM. To fix this bug, it'd be necessary to figure out how to successfully read back the VSphereGuestInfoProperty named "vSphereCloudSlaveTemplate.jenkinsUrl" (which was put there by the calculateExtraConfigParameters method) and amend the findWhichJenkinsThisVMBelongsTo code accordingly. Add Comment   This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.