It seems this is also a permission issue. Access to the port group is not enough. You need 'read' to datacenter root or something else. Maybe because of this method that I suspect crawls to the pgGroup from bottom-up. closing this issue

getVsphere().getDistributedVirtualPortGroupByName(getVM(), expandedDistributedPortGroup);

user must have suficient permissons to change port groups. This might include permissions to the datacenter root. Permission to the port group is not enough

I have the same issue and i think it is not solved because the user has administrator privileges. i have tried with pipeline and graphically. same result. this is the code in pipeline

step([$class: 'VSphereBuildStepContainer', buildStep: [$class: 'Reconfigure', reconfigureSteps: [[$class: 'ReconfigureNetworkAdapters', deviceAction: 'ADD', deviceLabel: '', distributedSwitch: false, macAddress: env.MAC, portGroup: 'vlan2223', standardSwitch: true]], vm: 'env.VMCLONED'], serverName: 'myserver'])

does the virtual machine name accept variables?

and the error

[vSphere] Performing vSphere build step: "Reconfigure VM"
[vSphere] Attempting to use server configuration: "myserver"
[vSphere] Reconfiguring VM "env.VMCLONED". Please wait ...
[vSphere] Preparing reconfigure: Add Network Adapter ""
[vSphere] Reconfiguring MAC Address -> 00:20:56:00:32:04
[vSphere] Reconfiguring Network Port Group -> vlan2223
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: java.lang.NullPointerException
Finished: FAILURE

w.r.t. the original NullPointerException, I've taken a look at the code:

    public DistributedVirtualSwitch getDistributedVirtualSwitchByPortGroup(
            DistributedVirtualPortgroup distributedVirtualPortgroup) throws VSphereException
    {
        try
        {
            ManagedObjectReference managedObjectReference = new ManagedObjectReference();
            managedObjectReference.setType("DistributedVirtualSwitch");
            managedObjectReference.setVal(distributedVirtualPortgroup.getConfig().getDistributedVirtualSwitch().getVal());
            return new DistributedVirtualSwitch(getServiceInstance().getServerConnection(), managedObjectReference);
        }
        catch (Exception e)
        {
            throw new VSphereException(e);
        }
    }

...and the exception that was originally reported is coming from

distributedVirtualPortgroup.getConfig().getDistributedVirtualSwitch().getVal()

I don't think it would be possible to prevent an exception at this point, but I guess it would be possible to make the exception a lot more friendly and return some form of "you don't have permission to do that" exception if getConfig() or getDistributedVirtualSwitch() returns null.

As for accepting variable names:  As I understand it, when using pipelines, all the pipeline code is groovy, so you are free to calculate the VM name into a variable and pass that in - as far as the vSphere-plugin code is concerned, it will be being passed a string so it can't tell that the string value was calculated.  It's only if you're using the configuration WebUI for the job that you're limited to the vSphere plugin's own internal functionality.

My guess is that your VM name of "env.VMCLONED" is not, in fact, the name of a VM, causing the code to fail to find the VM and suffer an exception at that point as a result.  My guess is that you intended to use the value of an environment variable named "VMCLONED", but you've not used the correct syntax for that (I'm not familiar with pipelines so I can't tell you what the correct syntax is, but I'm pretty sure that isn't it).

While the exception handling could be improved (y'all free to submit a PR for that...) this was user-error.