Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disk: Test-Resource throws exception on Azure VMSS instances #248

Open
ianwalkeruk opened this issue Oct 13, 2020 · 2 comments
Open

Disk: Test-Resource throws exception on Azure VMSS instances #248

ianwalkeruk opened this issue Oct 13, 2020 · 2 comments
Labels
help wanted The issue is up for grabs for anyone in the community.

Comments

@ianwalkeruk
Copy link

Details of the scenario you tried and the problem that is occurring

Applying a DSC configuration to an Azure VM Scale Set (VMSS) instance which contains a Disk resource will fail, due to Test-Resource throwing an exception.

The inner exception is cause by the call to Get-PartitionSupportedSize. Further testing shows that this cmdlet always throws an error on SF instances, so it's not a problem intrinsic to the DSC, however it does make it unusable.

Verbose logs showing the problem

(resource testing)

WARNING: [sf_instance]:                            [] The TEST operation will be carried against a pending
configuration since the latest configuration has not converged yet.
WARNING: [sf_instance]:                            [[xPendingReboot]FinalReboot] Unable to query
CCM_ClientUtilities: Invalid namespace
Invalid Parameter
Activity ID: {95744767-6b97-4fcc-bdda-e61d95834095}
    + CategoryInfo          : InvalidArgument: (StorageWMI:) [], CimException
    + FullyQualifiedErrorId : StorageWMI 5,Get-PartitionSupportedSize
    + PSComputerName        : localhost

The PowerShell DSC resource '[Disk]GVolume' with SourceInfo '::24::9::Disk' threw one or more non-terminating errors
while running the Test-TargetResource functionality. These errors are logged to the ETW channel called
Microsoft-Windows-DSC/Operational. Refer to this channel for more details.
    + CategoryInfo          : InvalidOperation: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : NonTerminatingErrorFromProvider
    + PSComputerName        : localhost

(out-of-resource testing)

[sf_instance]: PS C:\> $partition = Get-Partition -DriveLetter 'G' | Select-Object -First 1
[sf_instance]: PS C:\> $partition | Get-PartitionSupportedSize
Get-PartitionSupportedSize : Invalid Parameter
Activity ID: {7d5b1145-d650-4ab5-9fc8-173faf34cbf0}
At line:1 char:14
+ $partition | Get-PartitionSupportedSize
+              ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (StorageWMI:ROOT/Microsoft/.../MSFT_Partition) [Get-PartitionSupportedS
   ize], CimException
    + FullyQualifiedErrorId : StorageWMI 5,Get-PartitionSupportedSize


SizeMin SizeMax
------- -------

Suggested solution to the issue

The problem is partially due to Test-DscResource ALWAYS calleding Get-PartitionSupportedSize. The current flow is:

if ($Size has not been specified)
set $Size to the maximum size (calling Get-PartititionSupportedSize)

if ($Size has been specified) ## always happens, since we've just set it in the previous block
test the size of the partition

The solution could be to only call Get-PartitionSupportedSize in Test-DscResource if the Size property has been specified:

if ($Size has been specified)
discover the maximum size
test the size of the partition

This should be okay, since $Size is not used anywhere outside of those two blocks.

I could make the changes myself, but note that @PlagueHO is already working on #246 which is likely a rework of the same code,

The DSC configuration that is used to reproduce the issue (as detailed as possible)

      Node $NodeName {
        WaitforDisk Disk2 {
            DiskId = 2;
            RetryIntervalSec = 60;
            RetryCount = 60;
        };
      
        Disk GVolume {
            DiskId = 2;
            DriveLetter = 'G';
            FSLabel = 'Data';
            DependsOn = '[WaitForDisk]Disk2';
        };

The operating system the target node is running

OsName : Microsoft Windows Server 2016 Datacenter
OsOperatingSystemSKU : DatacenterServerEdition
OsArchitecture : 64-bit
WindowsBuildLabEx : 14393.3930.amd64fre.rs1_release.200901-1914
OsLanguage : en-US
OsMuiLanguages : {en-US}

Azure VM scale set instance, part of an Azure Service Fabric cluster

Version and build of PowerShell the target node is running

PSVersion 5.1.14393.3866
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.14393.3866
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

Version of the DSC module that was used ('dev' if using current dev branch)

Tested with 4.8.0.0 and 5.0.1

@PlagueHO PlagueHO added the help wanted The issue is up for grabs for anyone in the community. label Oct 13, 2020
@PlagueHO
Copy link
Member

Hi @ianwalkeruk - thanks for raising this. I do indeed need to complete #246 - I ran into some unexpected behavior indicated in the issue didn't line up with what the code did. So I needed to gather some more information but got sidetracked.

Regarding this issue Get-PartitionSupportedSize needs to be called when Size is not specified because this value is used to determine if the partition is actually the correct size - which is the maximum partition size for that partition. So, if we don't get this value then we can't properly detect if the partition needs to be changed or not.

Perhaps we could catch this exception and handle it with a warning and assume that in this condition if the partition exists it is the correct size? I'd definitely add a warning to the logs here though.

Sidenote: you should use PendingReboot from ComputerManagementDsc rather than xPendingReboot. xPendingReboot is deprecated.

@ianwalkeruk
Copy link
Author

Thanks @PlagueHO - noted on the xPendingReboot!

Just done some more testing on my VMSS instance. The exception thrown by Get-PartitionSupportedSize appears to be uncatchable by PowerShell (I even tried a trap).

I'd propose as a workaround, to have a wrapper function around Get-PartitionSupportedSize, which calls it with -ErrorAction SilentlyContinute and then checks the output to see if SizeMin/SizeMax are $null; if so then throw out own exception.

I'd question whether (Size=$null; AllowDestructive=$false) should really mean 'the maximum possible size is the correct size' - there are plenty of situations where the partition might have been pre-created, and we just want to test that it's available and online before use?

As an additional feature, what about having a MinimumSize property as an alternative to Size, for those situations?

I'm happy to work on the wrapper for now, since that will be useful in all cases

ianwalkeruk added a commit to ianwalkeruk/StorageDsc that referenced this issue Oct 15, 2020
Added a test for the behaviour seen in certain circumstances where the
underlying CIM resource emits an exception when GetPartitionSupportedSize
is called but the Get-PartitionSupportedSize cmdlet does not handle
that error and instead returns both the exception and a null result to
the pipeline.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted The issue is up for grabs for anyone in the community.
Projects
None yet
Development

No branches or pull requests

2 participants