When creating a VM template, if you want to add a data disk, you have to precreate the datadisk and load it into the library. If you want it Fixed, you have to take the time to precreate a Fixed VHDX and import it. Also if you want to add multiple data disks you must have unique entries in the library, they cannot be reused inside the same vm template. I propose allowing blank virtual hard disk templates of Fixed type of a specified size to be described in the template, and have scvmm create the disk on demand during provisioning as described without needed the disk in the library to copy.

Currently, VMM will place a Parent Disk on the specified "Parent Disk" volume set on the cluster or host.

However, if the Parent Disk VHDX is changed in some way, but does not have its file name updated, the next time a VM is being created, it will fully copy the "new" Parent Disk to the next volume sorted alphabetically instead of appending a "-1" or "Copy 1" onto the file name.

For example:

TESTVM has a single hard disk that is set to differencing:

TESTVM-HDD-01.vhdx --> TESTVM-HDD-01-diff.vhdx

When TESTVM is created for the first time, TESTVM-HDD-01.vhdx is copied to the specified PARENT DISK location in the host's Placement Path settings.

Then let's say that changes are made to the original VM and it is re-created and stored in the Library. If the file name of the VHDX did not change, the next time the VM is created, the VHDX files are now different and VMM needs to re-copy the "new" Parent Disk.

VMM (rightfully so) will not overwrite the original file, but instead copies it to a completely different storage volume, typically the next alphabetical one.

I feel it should simply append a suffix to the new Parent Disk's file name and place it on the specified Parent Disk volume.

Users may have storage tiers setup for better IO performance that this could negatively impact.

When you manage an S2D storage pool in VMM, the "Storage available" value that appears in the console (from the RemainingManagedSpace property of the SPACES_StoragePool object) does not account for resiliency. For example, if the storage pool is a two-way mirror with 400 GB physical storage, the VMM console shows 385 GB available. However, the largest volume you can create on the storage pool is really only 190 GB.

In this scenario, if you attempt to create an S2D volume using New-SCStorageVolume, and you specify a size (-SizeInBytes) that exceeds the actual storage pool capacity, you receive the following job error:

"Error (26561)
Creating volume new <volume_name> on storage pool <pool_name> failed with error code 1 [SM_RC_NOT_SUPPORTED]. The storage pool does not have sufficient eligible resources for the creation of the specified virtual disk."

The job error is valid. The problem is the VMM user has no way to know the actual storage pool capacity. It would be great if New-SCStorageVolume could replicate the -UseMaximumSize parameter that's available in the New-Volume cmdlet.

Otherwise, the user must remote or create the volume directly on the cluster and then rescan the storage in VMM. This defeats the purpose of using VMM to managed the storage.

Example PowerShell script to work around this limitation:

##########################################
$poolName = "S2D on MyCluster"
$newVolumeName = $poolName + " - LUN 1"

$storageProvider = ((Get-SCStoragePool -Name $poolName).StorageArray).StorageProvider
$providerFQDN = $storageProvider.NetworkAddress
$providerName = $storageProvider.Name

$cimSession = New-CimSession -ComputerName $providerFQDN

New-Volume -CimSession $cimSession -StoragePoolFriendlyName $poolName -FriendlyName $newVolumeName -FileSystem "CSVFS_ReFS" -UseMaximumSize

Get-SCStorageProvider -Name $providerName | Read-SCStorageProvider -Force
##########################################

The above works, but the user shouldn't have to create a separate CIM session and run a non-VMM cmdlet to create the volume.

After building a S2D cluster in SCVMM 2016 with UR 3 I tried to add another node to the cluster. The job failed with the error in the cluster log "An error occurred while executing the test. One or more errors occurred. ERROR CODE: 0X80131500; Native ERROR CODE:1. The I/O operation has been aborted because of either a thread exit or an application request. I tried it multiple times with the same result. But I ran a test-scvmhostcluster PS command with the new node and it succeeded. It ended up that I couldn't add the node via SCVMM but I was able to add the node via Failover Cluster Manager and it was added to the cluster successfully. Then it showed up in SCVMM as being a member of the clustere