Hyper-V VM Storage Migration Issue

Server 2012 Hyper-V Failover cluster. Connected a couple new CSV's to hosts in question. CSV's are accessible via local file path on hosts (e.g. C:\ClusterStorage\VolumeX). When trying to perform a storage migration of a VM in Failover Cluster Manager it is showing "The network path was not found." under the Cluster Storage list. Anyone else run into this same issue? What's interesting is that even the existing CSV where the current VMs reside doesn't show.

LVL 16
Michael OrtegaSales & Systems EngineerAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Cliff GaliherCommented:
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.
Michael OrtegaSales & Systems EngineerAuthor Commented:
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.
Michael OrtegaSales & Systems EngineerAuthor Commented:
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).

Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

Cliff GaliherCommented:
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?
Michael OrtegaSales & Systems EngineerAuthor Commented:
Yes. 100% passed on validation tests. I only ran the lists disks and list available cluster disks tests for now, but both passed.
Michael OrtegaSales & Systems EngineerAuthor Commented:
Yes, on the 2nd part as well. The move is being attempted from Failover Cluster Manager.
Michael OrtegaSales & Systems EngineerAuthor Commented:
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.
Cliff GaliherCommented:
This issue presents itself on all nodes in the cluster?
Michael OrtegaSales & Systems EngineerAuthor Commented:
Yes. 2 node cluster and the problem is the same from either node.
Cliff GaliherCommented:
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?
Michael OrtegaSales & Systems EngineerAuthor Commented:
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?
Cliff GaliherCommented:
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.
Michael OrtegaSales & Systems EngineerAuthor Commented:
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.
Cliff GaliherCommented:
Storage fixes, particularly for 3rd party, don't usually fall under critical. Some are recommended, and a couple are still "hot fix" status which means they aren't even in the recommended category on WU, if they are on WU at all. You may want to take a closer look at the available patches and don't rely on critical security as a blanket "we are up to date" assumption. I've definitely gotten called in to consult on a few cluster issues just to find there was already a KB and patch for the issue.
Michael OrtegaSales & Systems EngineerAuthor Commented:
Problem appears to be fixed now. From the cluster I had to simulate failover and then run a "repair" when it failed. Apparently, it re-registers objects in AD properly which I believe was the problem. The Cluster Volumes now show and I was able to complete my storage migration.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Michael OrtegaSales & Systems EngineerAuthor Commented:
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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Virtual Server

From novice to tech pro — start learning today.