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 OptionValue named "vSphereCloudSlaveTemplate.jenkinsUrl" (which was defined by the calculateExtraConfigParameters method) and amend the findWhichJenkinsThisVMBelongsTo code accordingly.