Add node to hyper-v server failover clustering environment

Run the cluster validation wizard on the new node. It'll do all the necessary checks, and if all pass, give you the opportunity to add the node to the cluster. Then the cluster manager will bring the storage into the fold gracefully. By trying to do it manually, you are breaking the storage layer.

Check below article. Hope this will help you :
http://insidevirtualization.com/hyperv/adding-a-node-to-existing-hyper-v-cluster/

I did find that article and was using it along with another MS How-To. The last step in the articles "pre" list is "Ensure SAN disks are visible in Disk Management of the new server. Just check, Don’t try to make it online".

That is the challenge I am having when I do make the LUN/SAN Disk available the server is bringing it online.

Create new LUN (for testing purpose) and attach to New Hyper-V host. Check if  it is also coming online on Hyper-V.

I created a new LUN and presented only to the new server. After rescan it is there offline and unallocated.

The issue seems to be specifically to existing CSV disks in use by clustering on the existing servers.

There really is no issue. This is expected behavior.  NTFS is, at its core, still a single-access filesystem. Shared access is simply not supported. Microsoft creatively got around the issue by introducing CSVs.  But all CSVs really do is allow nodes to write data directly to a disk without interacting with the filesystem at all.  But for that to work, each node must know about the files in the filesystem in advance, and any changes to the filesystem need to be run through a single node. This is known as the CSV Coordinator node.  So a Hyper-V host can write to an existing VHD because it knows where the VHD blocks are, what the ACLs are, and similar. But any event that changes the VHD, such as a resize, still goes through the coordinator node.  

As such, you can't simply add an existing LUN to a new machine before making that machine part of the cluster.  That'll break because you now have two machines trying to manage the NTFS tables. And you get the freezing you describe.  If you go through the wizard and validate your cluster then add the node, it'll gracefully introduce the node to the existing storage and the node will be aware of the CSV coordinator, thus it won't try to handle the NTFS stuff.

So as I said above, simply run the validation wizard and add the node.  Any guidance that suggests doing otherwise is simply bad advice.  CSVs are not true shared-everything storage and trying to treat them as such will cause problems.

I guess I'm getting clustering resources confused with CSV's. I was thinking a CSV was the same as a clustered resource and therefore needed to be presented to any node that would be accessing it. So are you saying only one node needs the LUN/Disk presented to it and then that becomes the coordinator node for that CSV? The other nodes know about it and access it when it is added as a CSV?

Sorry for all the questions I just want to fully understand what is happening.

When you add the node, you'll be presented with storage already in the cluster that you can add. The wizard takes care of properly informing the cluster of the change and getting the new node access. Same goes for adding a new CSV. Yes, the cluster will select one node to act as coordinator. Not necessarily the node that originally had the LUN access. That depends on availability and workloads, etc.

So I present one node with the LUN/Disk and then create a CSV from that. All of the other nodes are really accessing the CSV through the one node that has the LUN presented to it or I should say the coordinator node? If I take the node down that the CSV is created from does that make that CSV inaccessible to the other nodes seeing as the LUN/Disk is no longer available?

Can you tell me whether the csv will be taken offline to run validation against them?

Validation is usually non-intrusive.