VMSwitch DSC resource throws "Impossible to convert« System.String[] » into « System.String

[lovilak]

Hello,
I've this message when I try to create a new Vswitch with this params :

Name: 'NEW_SWITCH'
Type: 'External'
Ensure: 'Present'
NetAdapterName: 'MY_TEAM'

I've this message : "Impossible de convertir « System.String[] » en type « System.String », requis par le paramètre « NetAdapterName ». La méthode spécifiée n'est pas prise en charge. La ressource DSC PowerShell [xVMSwitch]DirectResourceAccess avec SourceInfo a levé une ou plusieurs erreurs sans fin d'exécution lors du lancement de la fonctionnalité Set-TargetResource. Ces erreurs sont enregistrées dans le canal ETW appelé Microsoft-Windows-DSC/Operational"

Thanks for your help

[johlju]

@lovilak Could you provide the verbose output when you run this? Obfuscate any sensitive information.

[stale]

This issue has been automatically marked as stale because it has not had activity from the community in the last 30 days. It will be closed if no further activity occurs within 10 days. If the issue is labelled with any of the work labels (e.g bug, enhancement, documentation, or tests) then the issue will not auto-close.

[lovilak]

Hello,
From another module I still have this error with an ansible task :

win_dsc:
resource_name: "xVHD"
Path: "D:\file.vhdx"
MaximumSizeBytes: 2GB
Generation: 'vhdx'
Ensure: 'present'
Type : 'Dynamic'

I get : failed to cast property MaximumSizeBytes from '2GB' of type System.String to type System.UInt64, the DSC engine may ignore this property with an invalid cast

[johlju]

@lovilak It doesn't look like this is the same issue. '2GB' must be interpreted as a string, and was not converted to the correct value 2147483648 by the Ansible task?

2GB normally gets converted to 2147483648.

(2GB).GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Int64                                    System.ValueType

If you change the property to 2147483648 it should work.

[lovilak]

Ok, I will test again this 2 points in few days and I comeback to you with some results. ThankYou for your support.

[jrdnr]

I’ve run into this issue as well.
I’ll try to fill in missing details.
DSC block:
xVMSwitch HVSwitch { Name = 'HVSwitch' Type = 'External' AllowManagementOS = $true NetAdapterName = 'HVTeam' Ensure = 'Present' DependsOn = "[xNetworkTeam]HVTeam" }�

When run verbos I get the following:
`
[[xVMSwitch]HVSwitch] Checking if Switch 'HVSwitch' is 'Present'
...
VERBOSE: [DSC-HVTEST]:
[[xVMSwitch]HVSwitch] Switch 'HVSwitch' is Absent
VERBOSE: [DSC-HVTEST]: LCM: [ End Test ]
[[xVMSwitch]HVSwitch] in 0.4220 seconds.
VERBOSE: [DSC-HVTEST]: LCM: [ Start Set ]
[[xVMSwitch]HVSwitch]
VERBOSE: [DSC-HVTEST]:
[[xVMSwitch]HVSwitch] Switch 'HVSwitch' is not 'Present'.
VERBOSE: [DSC-HVTEST]:
[[xVMSwitch]HVSwitch] Creating Switch ...Checking
Cannot convert 'System.String[]' to the type 'System.String' required by parameter 'NetAdapterName'. Specified method
is not supported.
+ CategoryInfo : InvalidArgument: (:) [], CimException
+ FullyQualifiedErrorId : CannotConvertArgument,Microsoft.HyperV.PowerShell.Commands.NewVMSwitchCommand
+ PSComputerName : localhost

VERBOSE: [DSC-HVTEST]:
[[xVMSwitch]HVSwitch] Switch 'HVSwitch' is now 'Present'.
VERBOSE: [DSC-HVTEST]: LCM: [ End Set ]
[[xVMSwitch]HVSwitch] in 0.2190 seconds.
The PowerShell DSC resource '[xVMSwitch]HVSwitch' with SourceInfo 'C:\DSC\HV-DSC.ps1::93::9::xVMSwitch' threw one or
more non-terminating errors while running the Set-TargetResource functionality. These errors are logged to the ETW
channel called Microsoft-Windows-DSC/Operational. Refer to this channel for more details.
+ CategoryInfo : InvalidOperation: (:) [], CimException
+ FullyQualifiedErrorId : NonTerminatingErrorFromProvider
+ PSComputerName : localhost

VERBOSE: [DSC-HVTEST]: LCM: [ End Set ]
The SendConfigurationApply function did not succeed.
+ CategoryInfo : NotSpecified: (root/Microsoft/...gurationManager:String) [], CimException
+ FullyQualifiedErrorId : MI RESULT 1
+ PSComputerName : localhost

VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 5.971 seconds
`

Using Enable-DscDebug -BreakAll I stepped through and it appears as though the issue is that in the DSC resource the $NetAdapterName initialized as a System.System[] but New-VMSwitch Only accepts System.String.

I’m guessing the easiest fix would be to preprocess $NetAdapterName down to a System.String befor calling New-VMSwitch.

[johlju]

So this was added in this PR #96 because of issue #95 which added a the parameter EnableEmbeddedTeaming. So maybe when $EnableEmbeddedTeaming is $false we cast the $NetAdapterName to System:String instead?

If so this seems to be needed here

https://github.com/PowerShell/xHyper-V/blob/528678479e6f82f421e0622554ecc8719da211e6/DSCResources/MSFT_xVMSwitch/MSFT_xVMSwitch.psm1#L270-L273

and here.

https://github.com/PowerShell/xHyper-V/blob/528678479e6f82f421e0622554ecc8719da211e6/DSCResources/MSFT_xVMSwitch/MSFT_xVMSwitch.psm1#L324-L327

[johlju]

Labeling this as a bug, and help wanted so that anyone in the community can run with it.

[TheGitHubBro]

Is this still an active bug and something that needs to be address? Hyper-V module 2.0 (Server 2016) supports String[] for New-VMSwitch, but Hyper-V module 1.1 (Server 2012) doesn't so I'm assuming this is where the issue is coming into play.

If it needs to be addressed, and $NetAdpaterName is indeed an array, how would a decision be made as to what name to pass in? Would it just blindly pass in the first element in the array? I might have some availability to pick this up. Just let me know.

[johlju]

If it is like you said, that this was extended in Windows Server 2016, then I would rather see it throws an error if it is passed a string array when the module is v1.1. Or, rather it checks if the parameter type of the New-VMSwitch if it is only string, then throw a correct error explaining the problem that New-VMSwitch does not support an array on v.1.1.

[jrdnr]

I don't have a system to test on at the moment, but my memory was that problem is that a [string] was being formatted as a [string[]] which was being rejected by new-VMswitch even though it was a single element.

So at the very least single elements needed to be cast to [string], and the error could be improved.

[TheGitHubBro]

Yeah, so, the error is that if a user passes in a single string for $NetAdapterName it gets turned into a String[] since that's what the function/parameter now accepts.

Since HyperV 1.1 module doesn't accept String[] the New-VMSwitch cmdlet it's blowing up. I've tested this on Server 2012 R2 and a Windows 10 box.

I have availability to pick this up and have actually made a fix on the fly for some work I was doing. I'm just not sure what the community believes the best way forward would be? I would assume checking the .Count of the array and casting it to [String] if it's a single element array would be good in the case that only one element gets passed in to $NetAdapterName , but, what if a user passes in an actual array to $NetAdapterName, how do we determine which is the correct one to pass in? We can't just blindly select an element out of that array IMO.

I think that in the case where a users does pass in an array for $NetAdapterName we could check to see which module version is installed and if it's HyperV 1.1 throw an error explaining what the issue is and to only pass in a single element for the parameter.

[jrdnr]

As this is an "x" resource wouldn't it make sense to update it to only support [string] as the underlying cmdlet does? If someone has a config built for older versions it could break, but as new-vmswitch does not support it, passing an array is already broken.

[TheGitHubBro]

You have it reversed. The newer module supports an array. The older one does not.

Here's the documentation on New-VMSwitch

If having the DSC resource not be backwards compatible is fine, then it's working as expected and throwing the correct error.

[jrdnr]

Oh my bad, I misread your explanation.

I'd agree with what your proposed solution to check hyperv version and if -le 1.1 check .count and either cast to a string or throw a more meaningful error /explanation.

Is there any point in trying to guess out of an array which element to choose if there config is incompatible? Wouldn't it be a more predictable outcome to just error out and allow the operator to rebuild?