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.

In our setup a Hyper-V cluster does have it's own SOFS cluster, we have several of those clusters. So a one-to-one relationship is established between a Hyper-V Cluster and a SOFS Cluster.
SCVMM 2016 does not allow for VM's to be live-migrated between Hyper- V clusters while this was possible using SCVMM2012R2. This functionality disappeared magically in 2016. We really need this since we migrate VMs regularly between clusters.
For example; we do have local clusters and stretched clusters, we need to live migrate VMs between those for distributing load and SLA levels. The loss of this functionality is documented nowhere and we really need this!

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

VMM Allows you to create shares that are hidden by adding a $ to the end of the name. It works fine and allows you to use them.

However, if you remove one of these shares (ie, retire it) all of the hidden shares disappear. This is because the discovery gets run and it incorrectly assumes anything with a $ at the end is special and needs to be filtered out.

At this point, all of your VMs on these shares go into an unsupported state and you lose the ability to manage VMs using VMM.

Please allow VMM to utilize hidden shares (why wouldn't you? Hyper-v and Failover Cluster Manager have no problems with them!) or prevent the user from creating them in the first place!

When using VMM with SelfService Users (SSU) the SSU can only see the virtual machine status (VMS) – the user is not able to see the host status itself. I.e. when the host is “host not responding” the SSU will see Status: Running and Virtual Machine Status: Running.

(screenshot 1)

VMM hides the host status and keeps the last known VMS. It’s the same story for Admins and Delegated Admins with one difference – the user is able to see the host status:

(screenshot 2)

It’s possible that a not responding host does not lead to an outage of the vm itself. But from a VMM perspective this is “unknown”. VMM does not know the status of the VM. It just keeps the last “known” virtual machine status.
This should be changed. When the Host is not responding, the virtual machine status should be “unknown” or “needs attention”. This will allow the SSO user to be aware that the VM is either running or not. Otherwise the VM is showed as “running” but it’s not available anyway (more or less schrodingers cat).

As discussed in the following forum topic:
https://social.technet.microsoft.com/Forums/systemcenter/en-US/917c90d5-f7f4-454c-825b-fe0f28592978/cannot-create-vm-from-gen2-template?forum=virtualmachingmgrhyperv

I am not able to fix whatever causes error 23352 to be thrown after
- Creating a new generation 2 Virtual machine
- Booting, installing and configuring the machine
- shutting down the machine
- Creating a VM template from the VM
- Enabling "Create a differencing disk using the specified disk as parent"
- Trying to create new virtual machines from the template.

After the VHDX was deployed to the host(s) and differencing disks are to be created, error 23352 ("VMM cannot find the device or this device is not valid for a boot device") is thrown.

KB2955362 suggests to manually set the boot device to the disk which contains the OS. I use that command, but it did not fix the issue.

There is no hint on what exactly may be the cause of this error.

Sometimes it helps to create a new VM template after changing the name of the VHDX file of the original VM. But sometimes this does not help.
In the forum topic mentioned above it was posted that this issue still occurs in SCVMM 2016.