[New Resource] xDiskEx, xPartition and xVolume about storagedsc HOT 9 OPEN

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

from storagedsc.

Also tagging @bgelens for feedback.

from storagedsc.

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.

from storagedsc.

@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?

from storagedsc.

@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?)

from storagedsc.

@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.

from storagedsc.

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

from storagedsc.

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!

from storagedsc.

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.

from storagedsc.