How configuring storage with Volume GUID works in Failover clustering

There is couple of new features and architectural changes in failover clustering and I am going to talk about new functionality of using Volume GUIDs instead of drive letters in this talk. You are recommended to apply this patch for this increased functionality.

951308 Increased functionality and virtual machine control in the Windows Server 2008 Failover Cluster Management console for the Hyper-V role [This is not required for server 2008 R2]

http://support.microsoft.com/default.aspx?scid=kb;EN-US;951308

Let’s see how this works behind the scene, so let’s dig in to find out what happens in the background. I have a 2 node Hyper-v cluster with Node and file share majority as the quorum model. To investigate this Guid behavior I presented new storage disk to my cluster and noticed the view in disk management, Failover cluster admin console, {HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices} mounted devices registry key and mountvol.exe output. Node 1 is the current owner of this disk. On Node 1, we can observe that the newly presented disk shows up as disk 4 in disk management.msc with drive letter H:\ but in failover cluster admin console it appears as cluster disk 5, so there is no co-relation between two and we should not be confused about it. (See fig 1)


On node 2 the disk got the next available drive letter which is F:\ and got its own unique Volume GUID. So we see both nodes have got different local Volume GUIDs for same disk .Till now it is all expected as every machine should have its own GUID for a disk and they picked the next available drive letter on node 2 so all looks good so far (see fig 2)

FIG 1

                                                                 FIG 2

Now I went ahead and removed the drive letter so that we can use this disk with GUID (see fig 3)

FIG 3

This is what I observed (see fig 4) in failover cluster admin console…its displaying Cluster Volume GUID for the disk which is same as the disk’s Local Volume GUID of node 1 (remember node 1 owns the disk). On node 1 in mountvol.exe output we see a fresh new entry with modifier “no mount points” which was not there earlier. This shows that this disk is not using a drive letter now. On node 2 we don’t see any change on either mountvol.exe output or mounted devices registry key as seen in fig 5.

FIG 5

Now I opened Hyper-V console on Node 1 and created a virtual machine named “Guid behavior” as shown in fig 6. Here we provide the path using Volume GUID. As I am going to create a highly available Virtual machine later on, I will use the Volume GUID displayed in Failover cluster admin console for cluster disk 5 which is the recommended way of creating a highly available VM. (We will come to know why this is recommended way later in the blog)

FIG 6

However the question arises that the Volume GUID displayed in failover cluster admin console is same as local Volume GUID on node 1 however we have no reference of this Volume GUID on node 2. So when this highly available VM will move or failover to node 2 what will happen? How will it come online as node 2 has no idea of this Volume GUID showing up in failover cluster admin console…let’s see what happen.

I created a highly available virtual machine service and this is what I observe on node 1 and failover cluster admin console (see fig 7) which is all expected.
 

FIG 7

Now lets see what do we see on node 2 . we still see the exact same information (see fig 8) in mounted devices registry key and mountvol.exe output as seen before. No changes till now. So lets try to move this VM from node 1 to node 2 and lets see what happens….we see that in mounted devices registry key we now see 2 GUIDs for disk with signature 6fd2cfff, one is Local volume GUID which was orginally present on the node 2 before moving VM and other one is Cluster Volume GUID (Cluster replicated actually) which is being displayed in failover cluster admin console and is also the Local Volume GUID of disk with signature 6fd2cfff on node 1. (see fig 9).

So whoever node owns the disk before it was used as highly available disk in cluster will replicate the Volume GUID to all the remaining nodes and then that volume GUID is used by cluster and is known as cluster volume GUID. We will still see the Local Volume GUID on all the nodes along with cluster Volume GUID. You can distinguish between Local Volume GUID and Cluster Volume GUID easily by seeing the Mountvol.exe output as the Cluster Volume GUID will not show up on Node 2 mountvol.exe output however it does show up on node 1.

FIG 8

FIG 9

Well, this completes our discussion for the day and we now know how we can use GUIDs instead of drive letters for configuring storage and how cluster replicates these Volume GUIDs. There is one more word of caution that I have noticed and I will like to share. We can place virtual machine either via Hyper-V or system center virtual machine manager. Now using system center virtual machine manager I placed newly created virtual machine “Guid behavior” on node 1. While creating this virtual machine we have to provide storage for placing .vhd file and as you can see in fig 10, SCVMM picks the Volume GUID information automatically. There are scenarios when it may pick the local volume GUID instead of Cluster Volume GUID and that’s why we recommend that if you are creating highly available VM, make sure that you confirm the GUID used, is the GUID displayed in failover cluster administrator console.

                                                                FIG 10

This ends our discussion for today and I hope that you enjoyed reading the blog. Please come back on our  blog where we try to share information and Thanks for your valuable time. There is already a very nice blog written by Chuck Timon on this matter and I strongly advise you to read that too.

Configuring Storage Using Volume GUIDs in Hyper-V

http://blogs.technet.com/askcore/archive/2008/10/29/configuring-storage-using-volume-guids-in-hyper-v.aspx

GAURAV ANAND