[New Resource] xDiskEx, xPartition and xVolume

[PlagueHO]

trafficstars

The current xDisk resource is limited to creating only simple disk/partition/volume layouts. Fixing these limitations will require the functionality of the xDisk resource to be broken into smaller "single function" resources. This has been covered in several issues over the past year.

This problem is described quite well in this article written by @rchaganti .

To resolve this I am proposing creating the following three resources that could be used in place of xDisk. The resource MOF files are proposed only (not final) - they will require refinement:

• xDiskEx:

[ClassVersion("1.0.0.0"), FriendlyName("xDiskEx")]
class MSFT_xDiskEx : OMI_BaseResource
{
    [Key, Description("Specifies the disk identifier for the disk to modify.")] String DiskId;
    [Write, Description("Specifies the identifier type the DiskId contains. Defaults to Number."), ValueMap{"Number","UniqueId"}, Values{"Number","UniqueId"}] String DiskIdType;
    [Write, Description("Specifies the partition style to of the disk. Defaults to GPT."), ValueMap{"MBR","GPT","RAW"}, Values{"MBR","GPT","RAW"}] String PartitionStyle;
    [Write, Description("Operational Status of the disk. Defaults to Online."), ValueMap{"Online","Offline"}, Values{"Online","Offline"}] String OperationalStatus;
    [Write, Description("Specifies if the disk is read only. Defaults to false.")] boolean IsReadOnly;
    [Write, Description("Allow the disk to be be destructively changed.")] boolean AllowDestructive;
};

Note: Operational Status is included to provide better support for clustered disks.

• xPartition

[ClassVersion("1.0.0.0"), FriendlyName("xPartition")]
class MSFT_xPartition : OMI_BaseResource
{
    [Key, Description("Specifies the disk identifier for the disk to modify.")] String DiskId;
    [Write, Description("Specifies the identifier type the DiskId contains. Defaults to Number."), ValueMap{"Number","UniqueId"}, Values{"Number","UniqueId"}] String DiskIdType;
    [Key, Description("Partition Number.")] UInt32 PartitionNumber;
    [Write, Description("Specifies the size of the partition. If omitted will use the entire disk.")] Uint64 Size;
    [Write, Description("Allow the partition to be destructively changed if required.")] boolean AllowDestructive;
};

• xVolume

[ClassVersion("1.0.0.0"), FriendlyName("xVolume")]
class MSFT_xVolume : OMI_BaseResource
{
    [Key, Description("Specifies the disk identifier for the disk to modify.")] String DiskId;
    [Write, Description("Specifies the identifier type the DiskId contains. Defaults to Number."), ValueMap{"Number","UniqueId"}, Values{"Number","UniqueId"}] String DiskIdType;
    [Key, Description("Partition Number.")] UInt32 PartitionNumber;
    [Key, Description("Volume Number.")] UInt32 VolumeNumber;
    [Write, Description("Specifies the size of the volume. If omitted will use the entire partition.")] Uint64 Size;
    [Write, Description("Specifies the file system format of the volume."), ValueMap{"NTFS","ReFS"}, Values{"NTFS","ReFS"}] String FSFormat;
    [Write, Description("Define volume label if required.")] String FSLabel;
    [Write, Description("Specifies the allocation unit size to use when formatting the volume.")] Uint32 AllocationUnitSize;
    [Write, Description("Specifies the disk letter to assign to the volume.")] String DriveLetter;
    [Write, Description("Specifies the access path folder to the assign the to the volume.")] String AccessPath;
    [Write, Description("Allow the volume to be destructively changed if required.")] boolean AllowDestructive;
};

All discussion welcome! I'd like to begin working on this over the next month (unless someone else volunteers :grin:).

[PlagueHO]

Tagging @Zuldan and @johlju for feedback as they have mentioned these problems in passed issues.

[PlagueHO]

Also tagging @bgelens for feedback.

[bgelens]

A user story I have: With Azure IaaS deployments, one can define a custom OS disk size during deployment by specifying diskSizeGB property. The disk will be created and have the size of what the user specified. However, the volume on the disk needs to be resized to accumulate the entire disk. It would be nice if a DSC resource would exists that monitors for disk free space and resize the volume if free space exists.

[johlju]

@PlagueHO Sorry for not responding earlier. This looks good to me. These cover all my needs as I see it now. A question is if we need to keep Number as a type of DiskId? Although don't hurt.

@bgelens If Size is omitted and AllowDesctructive is set to $true then that could potentially be done automatically. But only if it is the only volume on the partition, and that the partition is the only partition on the disk? Otherwise two volumes could fight over the space (or the first volume in the configuration would take the space). Or I'm I thinking of this wrong?

[bgelens]

@johlju In my scenario I'm talking about the OS volume, so destructive wouldn't be good in that sense ;) I think more of specifying xVolume for the OS Disk with an expand on resize operation (maybe exposed as additional parameter?)

[Zuldan]

@PlagueHO everything looks good. I really like @bgelens idea on automatically resizing if free space is found. This would be a very handy feature and save us a lot of time.

@johlju I think DiskId Number should be kept. It's a bit of a hassle trying to map Uniuque IDs with DSC configuration data especially if you're using multiple controllers in VM (using VMware) because there is no programmatic way to work out what guest disk matches what ESXi vmdk. Many people have tried but as soon as multiple controllers are involved, all logic goes out the door. So I'm our environment most servers use DidkId Numbers and some servers use DiskId Unique ID (when absolutely nessary).

@PlagueHO I have an idea (which might be an overkill) for another resource to add to this storage suite. What about one that controlled the file systems behaviour. Have a look in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem. One example is we don't like people using NTFS compression on our file servers so we disable it. Another example is when you have very large ReFS backup repositories you almost always have to define the settings described here https://support.microsoft.com/en-us/help/4016173/fix-heavy-memory-usage-in-refs-on-windows-server-2016-and-windows-10.

[mrhockeymonkey]

Did this ever get close to being implemented? Would be really helpful for me.

[PlagueHO]

HI @mrhockeymonkey - unfortunately not yet. I don't have much time these days so hoped someone else would pick it up. But if not, it is still on the long backlog!

[mrhockeymonkey]

Not to worry i know that feeling. Is there a branch with any first drafts around or is it just the design spec at the top so far? Perhaps If I manage to find some time I can work on one of the proposed resources.