The important point to take away from this post is that a new host is added to the Cluster via Failover Cluster Manager before presenting the shared storage to the new Hyper-V host!
The Lab Setup
We have a Failover Cluster called HYPERVCLUSTER with two nodes - HV01 and HV02:
A 20 GB Quorum disk
A 40 GB Cluster Shared Volume
The iSCSI shared storage is provided by a HP P4000 VSA
Note 1: In Explorer, only the Quorum disk will appear as a disk drive, and only on the cluster node owning the Quorum
Note 2: In Disk Management, the disks (Quorum and CSVs) appear with a status of ‘Reserved’
Here, we are going to add a new node - HV03 - to the Failover Cluster.
The server is initially configured similarly to HV01 and HV02 - networking, Hyper-V role installed, VM networks configured similarly.
iSCSI network adapters are configured but the shared storage is not presented to the new host HV03.
The Failover Clustering feature is installed.
Adding the Node via Failover Cluster Manager
i: Failover Cluster Manager > HYPERVCLUSTER.ace.priv (the cluster name) > Select Add Node …
ii: Add Node Wizard - Select Servers: Select the new node to be added > Next
iii: Add Node Wizard - Validation Warning: If require support from Microsoft, the cluster must be verified!
iv: Add Node Wizard - Confirmation!
Connecting the Shared Storage to the New Node
The new node - HV03 - is now in the cluster, but has no access to shared storage (including the Quorum.) This is resolved by:
i: Using the Storage Management Software to present the shared storage to the new node:
ii: Configuring the iSCSI initiator appropriately:
Q: Why is the Storage Connected After Adding the New Node to the Failover Cluster?
A: If you try to add the already clustered storage volumes to a new out-of-clustered node, the new node doesn’t understand the storage it is connecting to. As an example; the un-clustered node might prompt to format the clustered volumes! An un-clustered node does not understand what a reserved disk is.