Hyper-V VM Storage Migration Issue

2012 allows VM storage to exist on an SMB fileshare if you are setting up a scale-out file server cluster (SOFS).  What you describe is not an SOFS topology so this is completely normal. There is no network path so there is no reason to be in that particular space. If you have legitimately working CSVs, is there a reason you are trying to migrate storage?  Storage migration is *not* the same as VM migration in a Hyper-V cluster.

Moving VM storage from one SAN to another SAN is the reason. Under Cluster Storage in the moving VM storage option the Cluster Volumes should show up, but they do not. We have several other 2012 Hyper-V Failover Clusters that show the CSV's under the Cluster Storage options when performing a VM storage migration.

Here's an example of what it should show. The image below is from a different failover cluster in our datacenter. Same OS, same failover cluster configuration, etc. Obviously, the Cluster Shared Volumes are different (and names removed for obvious reasons).

And in cluster manager, your CSV is reporting that it is healthy?  You are attempting to start the move via cluster manager and not from Hyper-V Manager, correct?

Yes. 100% passed on validation tests. I only ran the lists disks and list available cluster disks tests for now, but both passed.

Yes, on the 2nd part as well. The move is being attempted from Failover Cluster Manager.

Some more detail...

This particular issue on this failover cluster has been a problem for a few months now in that even the existing CSV will not show when attempting a storage migration. Prior to the installation of the new SAN we had to move a VM's, but had to do them manually, e.g. offline and manual file copy.

We recently applied updates to both Hyper-V hosts in the cluster and restarted (this was 2-3 days ago). I mention this detail in the event there is a recommendation to patch and restart the server. =)

We added a new SAN, so we could move some of the VM storage over. Of course, the problem is still present, but we didn't expect it to go away just because we added a new SAN, hence additional CSV's. We just have to fix it this time around, because we can't do manual migrations of the VM storage like before due to disruptiveness with the VMs in question.

This issue presents itself on all nodes in the cluster?

Yes. 2 node cluster and the problem is the same from either node.

That leads me back to thinking this is corruption on the CSV itself. Or, far less likely, corruption of the cluster database. What's your witness situation? How are you connecting to the SAN?

iSCSI and 10GbE to SAN. Witness appears to be fine as well. Not sure what it means to have a corrupted CSV. I have about a dozen VMs running on the existing production CSV without a problem, except that I can't use it as a destination in the storage migration feature. The new CSV's (2 of them) were created yesterday. The same behavior presents with them. I can't imaging the CSV's are corrupt. Is there a process to test cluster database corruption?

CSVs are really just NTFS partitions with some added attributes for the cluster service to keep track of what is going on since NTFS itself is  a shared filesystem. I often see corruption when multiple systems were given direct access to an iSCSI LUN before the CSV was properly created. Or when multiple paths exist and MPIO is not configured. It is extremely rare for the cluster database to be corrupt, especially considering each node and the witness disk all hold a copy.

Is this 2012 or 2012 R2? What SANs are being used (you me toned migrating from an old SAN to a new one.) Are your nodes up to date on patches? There are several specific to 2012 (not R2) that address third party storage bugs. Although none are specifically the symptom you describe. And finally, have you scoured the event logs for storage related errors? Even seemingly minor warnings? I doubt this problem is happening in a void. Windows is likely logging the root cause somewhere.

2012 (not R2). Both hosts patched with all security/critical updates. Still rummaging through the event logs addressing anything related to storage, Hyper-V, iSCSI, etc. issues.

Recommended solution doesn't apply to this issue in particular, but is a common issue and would be helpful for others dealing with similar issues. The actual resolution was related to corruption of the cluster objects in AD.