I have a script which automates and clones templates and then changes mac addresses, create portgroups and then assigns the server network adapter to the correct portgroup.
The script worked perfectly fine - however last Friday the cluster has the 6.7u2 installed and now set-networkadapter just returns a "value cannot be null" error when changing used to change the portgroup. The Mac Address can still be changed without issue and from various tests other set-networkadapter option work as well but when the -Portgroup is specified it immediately gives the value cannot be null error.
I have tried - manually connecting to the server and running:
get-vm serv-name | get-networkadapter "Network adapter 1" | set-networkadapter -portgroup name-pg
In terms of code in the script this is it:
## Set Network Adapter 1 PortGroup ##
$Network_Adapter = Get-NetworkAdapter -VM $server -name "Network adapter 1"
$task = Set-NetworkAdapter -NetworkAdapter $Network_Adapter -portgroup $portgroup -confirm:$false -RunAsync
wait-task -Task $task
Anyway it worked without issue prior to the 6.7u2 and it broke afterwards - this is in Powershell 6.2 with the latest PowerCli (11.3.0)
So does anyone have any ideas why this would of broke with 6.7u2?
Cheers
Not sure what you have in $portgroup (a string or a PG object), but does this produce the same error?
Set-NetworkAdapter -Portgroup (Get-VirtualPortGroup -Name name-pg)
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Thanks for that - but unfortunately that makes no difference - that throws up another error: outputs:
PS > Get-VM srv099 | Get-NetworkAdapter "Network adapter 1"| Set-NetworkAdapter -Portgroup (Get-VirtualNetwork -name "PG-Slot099-Trunk")
Set-NetworkAdapter : Cannot bind parameter 'Portgroup'. Cannot convert the "PG-Slot099-Trunk" value of type "VMware.VimAutomation.ViCore.Impl.V1.Network.DistributedNetworkImpl" to type "VMware.VimAutomation.ViCore.Types.V1.Host.Networking.VirtualPortGroupBase".
At line:1 char:87
+ ... tworkAdapter -Portgroup (Get-VirtualNetwork -name "PG-Slot099-Trunk")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Set-NetworkAdapter], ParameterBindingException
+ FullyQualifiedErrorId : CannotConvertArgumentNoMessage,VMware.VimAutomation.ViCore.Cmdlets.Commands.VirtualDevice.SetNetworkAdapter
I also tried it writing the Get-networkadapter and get-virtualnetwork to variables and it throws back the exact same thing . . .
I wondering if some SDK linkage on vCenter has been screwed up in the upgrade, as I mentioned in the initial post the set-networkadapter seems to work fine for any option other than Portgroup, also I cannot anyone suffering with this issue (value cannot be null) recently, I found a few from years ago but they were related to code releases (Powershell/Powercli) which should not be the case here.
Most odd.
Just tried the same, and I can't replicate your issue.
Only difference is that my ESXi are on build 13981272, which is ESXi 6.7 EP 10.
I ran this on Ubuntu (PS 6.2.2 - PowerCLI 11.3.0) and Windows 10 (PS 6.2.0 - PowerCLI 11.3.0).
I assume you already tried a stop/start of your PS session?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Thanks for trying - yes tried a total restart ps and all - doesn't work.
I think however it's possibly related to some fat fingering by the person who has added a new couple of new nodes to the vCenter cluster, in passing last night he mentioned "problems with the vswitch", not something has been mentioned through his fat fingered attempts of updating things so far!
I'll see if we can get upto EP10 and see if it goes away.
Perhaps it might be useful, before upgrading, to create a new VDS with a test portgroup, and check if using that portgroup causes the same error.
If at all possible of course.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Good idea - i’ll try that shortly.
Thanks
well haven't had chance to look at this due to having to rebuild things - without a fully working script! :smileyconfused:
The fat fingering by the other people I believe is over and things are stable again so I'll take a further look this afternoon and see what can be done.