Disk: Setting fslabel on multiple partitions labels all partitions the same

[ndoody]

When I use the Disk command to create multiple partitions on the same disk, all having their own fslabel setting then it seems to change the label to be the same on all partitions on each iteration.

The code used to set the disk partitions is as follows :

	WaitForDisk Disk2
    {
         DiskId = 2
         RetryIntervalSec = 60
         RetryCount = 60
    }
    Disk HVolume
    {
         DiskId = 2
         DriveLetter = "H"
		 FSLabel = "SQL"
		 Size = 9.77GB
		 FSFormat = "NTFS"
		 PartitionStyle = 'GPT'
         DependsOn = '[WaitForDisk]Disk2'
    }
	Disk RVolume
    {
         DiskId = 2
         DriveLetter = 'R'
		 FSLabel = "BACKUP"
		 Size = 117.19GB
		 FSFormat = 'NTFS'
		 PartitionStyle = 'GPT'
         DependsOn = '[Disk]HVolume'
    }
	Disk TVolume
    {
         DiskId = 2
         DriveLetter = "T"
		 FSLabel = "TEMPDB"
		 Size = 97.66GB
		 FSFormat = "NTFS"
		 PartitionStyle = 'GPT'
         DependsOn = '[WaitForDisk]Disk2'
    }
	Disk LVolume
    {
         DiskId = 2
         DriveLetter = "L"
		 FSLabel = "LOGS"
         Size = 73.24GB
		 FSFormat = "NTFS"
		 PartitionStyle = 'GPT'
         DependsOn = '[WaitForDisk]Disk2'
    }
	Disk FVolume
    {
         DiskId = 2
         DriveLetter = "F"
		 FSLabel = "DATA"
		 Size = 204.25GB
		 FSFormat = "NTFS"
		 PartitionStyle = 'GPT'
         DependsOn = '[WaitForDisk]Disk2'
    }
	Disk SVolume
	{
		 DiskId = 2
         DriveLetter = "S"
		 #Size = 204.25GB
		 FSLabel = "Software"
		 FSFormat = "NTFS"
		 PartitionStyle = 'GPT'
         DependsOn = '[WaitForDisk]Disk2'
	}

The target operating system is Windows 2016 running in Azure, using a standard 2016 installation from Microsoft.

The version is StorageDsc 4.4.0.0

[ndoody]

Strange, this kind of worked on some new machines...the labels were correct but I cannot get it to work on old machines. The only difference is I upgraded from 4.2.0.0 to 4.4.0.0 and the new machines are wiped clean with the latest modules, the old machines are just upgraded and no matter what they won't get correct labels.

However, there is a new odd behaviour...I've created 2xvolumes of 550GB and 2xvolumes of 75GB each called DATA & DATA2, and LOGS & LOGS2. Now I see that it creates the first of the 2x550GB volumes correctly, 550GB/F letter/DATA volume label but when that's finished it renames this volume to DATA2 and never creates the 2nd 550GB volume.

This is similar to what happens with the volume labels, when it gets to the last volume it renames all the volumes the same label as the last volume is created. It seemingly doesn't seperate the individual volumes properly, but rather goes back to edit volumes created.

[PlagueHO]

Hi @ndoody - thanks for raising this. Are you possibly able to post the verbose logs from running the DSC config here (minus any identifiable info)?

[ndoody]

Where do I get these logs from? This is deployed through the DSC agent installed from within the azure cloud. It has the usual operational logs for DSC, and you can trick it into running a new "update-dscconfiguration" by recompiling the config in the cloud and I can take info from "Get-DSCConfigurationStatus" this way.

[ndoody]

This was easily repeatable on a new disk and configuration. This is the end product 👎

This is the script part run

WaitForDisk Disk3
{
DiskId = 3
RetryIntervalSec = 60
RetryCount = 60
}
Disk GVolume
{
DiskId = 3
DriveLetter = 'G'
Size = 64GB
FSFormat = 'NTFS'
FSLabel = "G"
PartitionStyle = 'GPT'
DependsOn = '[WaitForDisk]Disk3'
}
Disk HVolume
{
DiskId = 3
DriveLetter = 'H'
Size = 64GB
FSFormat = 'NTFS'
FSLabel = "H"
PartitionStyle = 'GPT'
DependsOn = '[WaitForDisk]Disk3'
}
Disk IVolume
{
DiskId = 3
DriveLetter = 'I'
Size = 32GB
FSFormat = 'NTFS'
FSLabel = "I"
PartitionStyle = 'GPT'
DependsOn = '[WaitForDisk]Disk3'
}
Disk JVolume
{
DiskId = 3
DriveLetter = 'J'
Size = 32GB
FSFormat = 'NTFS'
FSLabel = "J"
PartitionStyle = 'GPT'
DependsOn = '[WaitForDisk]Disk3'
}

This is the "resourcesindesiredstate" output 👎

ConfigurationName : prodServers
DependsOn :
ModuleName : StorageDsc
ModuleVersion : 4.4.0.0
PsDscRunAsCredential :
ResourceId : [WaitForDisk]Disk3
SourceInfo : ::1136::3::WaitForDisk
DurationInSeconds : 0.047
Error :
FinalState :
InDesiredState : True
InitialState :
InstanceName : Disk3
RebootRequested : False
ResourceName : WaitForDisk
StartDate : 2/21/2019 7:38:21 PM
PSComputerName :
CimClass : root/Microsoft/Windows/DesiredStateConfiguration:MSFT_ResourceInDesiredState
CimInstanceProperties : {ConfigurationName, DependsOn, ModuleName, ModuleVersion...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties

ConfigurationName : prodServers
DependsOn : {[WaitForDisk]Disk3}
ModuleName : StorageDsc
ModuleVersion : 4.4.0.0
PsDscRunAsCredential :
ResourceId : [Disk]GVolume
SourceInfo : ::1142::9::Disk
DurationInSeconds : 8.393
Error :
FinalState :
InDesiredState : True
InitialState :
InstanceName : GVolume
RebootRequested : False
ResourceName : Disk
StartDate : 2/21/2019 7:38:21 PM
PSComputerName :
CimClass : root/Microsoft/Windows/DesiredStateConfiguration:MSFT_ResourceInDesiredState
CimInstanceProperties : {ConfigurationName, DependsOn, ModuleName, ModuleVersion...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties

ConfigurationName : prodServers
DependsOn : {[WaitForDisk]Disk3}
ModuleName : StorageDsc
ModuleVersion : 4.4.0.0
PsDscRunAsCredential :
ResourceId : [Disk]HVolume
SourceInfo : ::1152::3::Disk
DurationInSeconds : 0.687
Error :
FinalState :
InDesiredState : True
InitialState :
InstanceName : HVolume
RebootRequested : False
ResourceName : Disk
StartDate : 2/21/2019 7:38:30 PM
PSComputerName :
CimClass : root/Microsoft/Windows/DesiredStateConfiguration:MSFT_ResourceInDesiredState
CimInstanceProperties : {ConfigurationName, DependsOn, ModuleName, ModuleVersion...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties

ConfigurationName : prodServers
DependsOn : {[WaitForDisk]Disk3}
ModuleName : StorageDsc
ModuleVersion : 4.4.0.0
PsDscRunAsCredential :
ResourceId : [Disk]IVolume
SourceInfo : ::1162::3::Disk
DurationInSeconds : 5.75
Error :
FinalState :
InDesiredState : True
InitialState :
InstanceName : IVolume
RebootRequested : False
ResourceName : Disk
StartDate : 2/21/2019 7:38:30 PM
PSComputerName :
CimClass : root/Microsoft/Windows/DesiredStateConfiguration:MSFT_ResourceInDesiredState
CimInstanceProperties : {ConfigurationName, DependsOn, ModuleName, ModuleVersion...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties

ConfigurationName : prodServers
DependsOn : {[WaitForDisk]Disk3}
ModuleName : StorageDsc
ModuleVersion : 4.4.0.0
PsDscRunAsCredential :
ResourceId : [Disk]JVolume
SourceInfo : ::1172::3::Disk
DurationInSeconds : 0.391
Error :
FinalState :
InDesiredState : True
InitialState :
InstanceName : JVolume
RebootRequested : False
ResourceName : Disk
StartDate : 2/21/2019 7:38:36 PM
PSComputerName :
CimClass : root/Microsoft/Windows/DesiredStateConfiguration:MSFT_ResourceInDesiredState
CimInstanceProperties : {ConfigurationName, DependsOn, ModuleName, ModuleVersion...}
CimSystemProperties : Microsoft.Management.Infrastructure.CimSystemProperties

[PlagueHO]

Thanks @ndoody - I'm having a go at replicating this now. Hopefully I have an idea where this might occur.

[PlagueHO]

Hi @ndoody - facepalm from me - I've realized what is happening here. The issue is that each the Disk resource uses the Size to determine if it should create a new volume on an existing Disk or update an existing volume. In your case, because each volume is 32GB the resource is updating the same Volume with a new label and Drive letter.

This is a bit of a limitation of the Disk resource (a whole reason I've planned to rework the resources with #91). So what you should do is change the set the size of each volume to a different number (even just by just 1 byte). E.g.

WaitForDisk Disk3
{
DiskId = 3
RetryIntervalSec = 60
RetryCount = 60
}
Disk GVolume
{
DiskId = 3
DriveLetter = 'G'
Size = 64.0000GB
FSFormat = 'NTFS'
FSLabel = "G"
PartitionStyle = 'GPT'
DependsOn = '[WaitForDisk]Disk3'
}
Disk HVolume
{
DiskId = 3
DriveLetter = 'H'
Size = 64.0001GB
FSFormat = 'NTFS'
FSLabel = "H"
PartitionStyle = 'GPT'
DependsOn = '[WaitForDisk]Disk3'
}
Disk IVolume
{
DiskId = 3
DriveLetter = 'I'
Size = 32.0000GB
FSFormat = 'NTFS'
FSLabel = "I"
PartitionStyle = 'GPT'
DependsOn = '[WaitForDisk]Disk3'
}
Disk JVolume
{
DiskId = 3
DriveLetter = 'J'
Size = 32.0001GB
FSFormat = 'NTFS'
FSLabel = "J"
PartitionStyle = 'GPT'
DependsOn = '[WaitForDisk]Disk3'
}

Creating new more granular DiskEx, Partition and Volume resources is still my longer term plan as this would allow more precise control over the disk layout.

Does that make sense?

[PlagueHO]

Thinking about this further, I think we need some better examples and documentation of this behavior until we have a good way of resolving it.

[haodeon]

Hi,

I'm encountering a similar if not the same issue.

I am trying to format an Azure P30 managed disk into 10 partitions of 50GB each.
What I am finding is the resource detects there is a partition with the same size already and just modifying the first partition to have the drive letter and label of the next partitions.

I am currently changing the size by 0.0001GB by each parition as a dirty hack. Which appears to work.

I say appear because when I inspect the capacity of the partitions after formatting each one displays the same capacity in bytes which can only be true if the number is being rounded down. I don't know what implications this has for subsequent enforcement of state.

[calrepo]

DiskAccessPath exhibits the same behavior when creating mount points of the same size on the same disk.

[PlagueHO]

This is an unfortunate side effect of how this resource was designed.

My intention was to create a new set of resources that would allow more granular control of partitions/volumes: #91 . However, it is a reasonably large job that I haven't found time to do.

However, thinking about this a bit, I'm wondering if it would be possible to for us to add an optional PartitionNumber parameter that will allow you to implement more control over the process and not rely on the size of a partition to determine if it already exists. More investigation would be required to validate this, but in theory it could work without requiring the new resources (which I don't have time to create at the moment).

There is some risk however with this approach: It will enable configurations that are technically invalid that can never enter state
(or worse exhibit configuration flapping) if the the disk is already partitioned and the drive letters are already assigned to the wrong partitions. This is because technically the combination of PartitionNumber and DiskId should be unique across all resources, but if PartitionNumber is optional then we can't make it a Key property. But this might be worth the risk as long as the behavior is documented and appropriate examples are created.

Avoiding a breaking change here is important as well. Once I've completed this PR (#242) I can take a look further.

[jojiklmts]

Could this be related?
I have this very simple PowerShell DSC Disk config. Just trying to set a label.

Disk CVolume
{
DiskId = ‘0’
DriveLetter = ‘C’
FSLabel = ‘System’
}
However when the config is executed, DSC is trying to resize the disk for some reason. I am not telling it to touch the disk size. See below the WARNING line in bold.

VERBOSE: [server]: LCM: [ Start Resource ] [[Disk]CVolume]
VERBOSE: [server]: LCM: [ Start Test ] [[Disk]CVolume]
VERBOSE: [server]: [[Disk]CVolume] Test-TargetResource: Testing disk with Number ‘0’ status for drive letter ‘C’.
VERBOSE: [server]: [[Disk]CVolume] Test-TargetResource: Checking if disk with Number ‘0’ is initialized.
VERBOSE: [server]: [[Disk]CVolume] Perform operation ‘Query CimInstances’ with following parameters, ”queryExpression’ = SELECT BlockSize from Win32_Volume WHERE DriveLetter = ‘C:’,’queryDialect’ = WQL,’namespaceName’ = root\cimv2′.
VERBOSE: [server]: [[Disk]CVolume] Operation ‘Query CimInstances’ complete.
VERBOSE: [server]: [[Disk]CVolume] Test-TargetResource: Volume assigned to drive C label ” does not match expected label ‘System’.
VERBOSE: [server]: LCM: [ End Test ] [[Disk]CVolume] in 4.3440 seconds.
VERBOSE: [server]: LCM: [ Start Set ] [[Disk]CVolume]
VERBOSE: [server]: [[Disk]CVolume] Set-TargetResource: Setting disk with Number ‘0’ status for drive letter ‘C’.
VERBOSE: [server]: [[Disk]CVolume] Set-TargetResource: Checking disk with Number ‘0’ partition style.
VERBOSE: [server]: [[Disk]CVolume] Set-TargetResource: Disk with Number ‘0’ is already initialized with ‘GPT’.
VERBOSE: [server]: [[Disk]CVolume] Set-TargetResource: Partition ‘4’ is already assigned as drive C.
WARNING: [server]: [[Disk]CVolume] Set-TargetResource: Skipping resize of C from 106819485696 to 106820517376. AllowDestructive is not set to $true.
VERBOSE: [server]: LCM: [ End Set ] [[Disk]CVolume] in 3.0470 seconds.
VERBOSE: [server]: LCM: [ End Resource ] [[Disk]CVolume]

[PlagueHO]

Hi @jojiklmts - I'm not certain, but this might be because of trying to set the size of C: Drive. I'd assume that this is your %SYSTEMROOT% drive so it would not be a good idea to configure it using this resource. This is most likely because your boot disk usually has one or more additional partitions on it (why C: drive is partition 4).

What is the reason for applying a config to C: drive?

[jojiklmts]

I wish to use DSC as one stop shop for whole config management. It would be better if DSC was not trying to resize the partition if it was not explicitly told to do so. Just trying to contribute if I come across ignorant.

[PlagueHO]

Hi @jojiklmts - you are absolutely right to use DSC as a one stop shop for whole config management, and it is appropriate to do so.

I think though the issue you're seeing is actually the same cause as this issue. This was is caused by a bug in Get-PartitionSupportedSize (see this user voice). The Disk resource uses Get-PartitionSupportedSize to determine if the partition you're configuring is at the maximum supported size (e.g. it uses up all remaining storage on the disk). However, it misreports this value in some situations - which is leading to the DSC resource thinking that the partition needs to be resized.

Get-PartitionSupportedSize seems to report incorrect values with used on disks with more complex partition configuration - for example, when used on a partition on the boot drive. This is because Windows adds a number of supporting partitions to the disk structure:

As you can see (this is from my machine):

So, my recommendation would be to avoid using DSC Disk resource against C: Drive and/or your boot disk. Besides, if DSC did determine that something needed to be changed (for example the partition needed to be resized) then it would be a destructive action and performing that on C: drive would result in your OS being wiped.

[jojiklmts]

Thanks for your quick response. I implemented workaround. Would it anyway make sense to rewrite DSC Disk resource, not to be using Get-PartitionSupportedSize, unless the programmer wants to do something specifically with disk size?

[PlagueHO]

The challenge there is that the resource is designed so that if you don't specify a size for the partition it assumes you want to make the partition/volume consume all remaining space on the disk.

We could potentially implement a flag to force ignoring the size of the partition - if the partition already exists - that would resolve the problem I think? Could you raise that as a separate issue so I can track it outside of this issue (don't want it to get lost).

[jojiklmts]

Done #246