VMSwitch: DSC resource does not work when VSwitch type is switched

[sathya-bhat]

Test:

1. Create a Configuration for xVMSwitch and create an Type= External switch, Ensure='Present'
2. Using HyperV Manager, change the switch type to Internal.
3. Run the configuration again. I am seeing MSFT_xVMSwitch failure. I have to manually delete the VMSwitch using 'Remove-VMSwitch'

Configuration

xVMSwitch $VSwitchName { Name = $VSwitchName Type = $Type AllowManagementOS = $AllowManagementOS Ensure = 'Present' NetAdapterName = $NetAdapterName }

Output

VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = SendConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'. VERBOSE: An LCM method call arrived from computer UCS-044 with user sid .... VERBOSE: [UCS-044]: LCM: [ Start Set ] VERBOSE: [UCS-044]: LCM: [ Start Resource ] [[xVMSwitch]vm-network-b] VERBOSE: [UCS-044]: LCM: [ Start Test ] [[xVMSwitch]vm-network-b] VERBOSE: [UCS-044]: [[xVMSwitch]vm-network-b] Checking if Switch vm-network-b is Absent ... VERBOSE: [UCS-044]: LCM: [ End Test ] [[xVMSwitch]vm-network-b] in 0.5000 seconds. The PowerShell DSC resource C:\Program Files\WindowsPowerShell\Modules\xHyper-V\3.6.0.0\DscResources\MSFT_xVMSwitch returned results in a format that is not valid. The results from running Test-TargetResou must be the boolean value True or False. + CategoryInfo : InvalidResult: (:) [], CimException + FullyQualifiedErrorId : TestTargetResourceInvalidResultFormat + PSComputerName : localhost

VERBOSE: [UCS-044]: LCM: [ End Set ] The SendConfigurationApply function did not succeed. + CategoryInfo : NotImplemented: (root/Microsoft/...gurationManager:String) [], CimException + FullyQualifiedErrorId : MI RESULT 7 + PSComputerName : localhost

VERBOSE: Operation 'Invoke CimMethod' complete.

[DexterPOSH]

@sathya-bhat I gave this a shot in my setup and indeed this fails if the switch type is changed as you mentioned. The interesting thing which I noticed is that if I added the missing else block to Test-TargetResource to return $false in case the VMSwitch is not present [Fix present in my fork] . The Set-TargetResource will create yet another VMSwitch with that name and a different type this time ( this is by design).

Below is how the Test/Set targetresource function determine if the resource is present or not (As per the schema both Name and SwitchType are key params).

$switch = (Get-VMSwitch -Name $Name -SwitchType $Type -ErrorAction SilentlyContinue)

Below is the test configuration used .

configuration test
{
    # One can evaluate expressions to get the node list
    # E.g: $AllNodes.Where("Role -eq Web").NodeName
    Import-DscResource -ModuleName xHyper-V
    node 'localhost'
    {
        # Call Resource Provider
        # E.g: WindowsFeature, File
        
        xVMSwitch 'ManagementVSwitch'
        {
        Name = 'Mgmtnet'
        Type = 'External'
        AllowManagementOS = $true
        Ensure = 'Present'
        NetAdapterName = 'Ethernet'
        }     
    }
}

Below is the DSC configuration run output, after I had manually changed the type of the 'MgmtNet' VMSwitch to be of type internal, Notice at the end there are two VMSwitch created with the same name.

Another alternative which does not feel right here could be that, if only the VMSwitch Name is defined as the key in the schema, then the existing VMSwitch will be discovered and a Set-VMSwitch can be called to set the switch type.

[iainbrighton]

@sathya-bhat Yeah - I ran into this one in Lability. Unfortunately, the current schema does not allow the changing of the switch type of an existing switch because, as @DexterPOSH points out, the switch's type is part of the resource's composite key.

If we were to change the schema by making the Type property just a Write property, we would not break existing configurations - unless they have different switches with the same name, but of differing types. I'm not sure why you would do that, but the schema does currently allow people to do this.

Any other change to the schema would be a breaking change that we should try and avoid wherever possible. Therefore, I think there are two realistic options:

1. We leave the resource schema as-is accepting you can't rename virtual switches.
2. We change the Type property to Write and possibly break one or two configurations.

Thoughts?

[DexterPOSH]

I would vote for the second one, since I have hardly seen VMSwitches with same name and different switch type being used.

Also the idea of DSC fixing the configuration drift in this specific case is simply unjust, as it creates another VMSwitch with the correct type rather than fixing the VMSwitch whose configuration was drifted.

Let's see what @sathya-bhat has to say on this.

[sathya-bhat]

I agree with DexterPOSH and believe second one is reasonable solution. Thanks!