Removing a Mount Point Disk from a Cluster Group

Removing a Mount Point Disk from a Cluster Group

  • Comments 7
  • Likes

Hello everyone. Today’s post is going to cover the steps needed to follow should you ever have to remove a ‘Physical Disk’ resource from a clustered service or application where that disk is configured as a mount point. Removing a disk from a group may be needed if the application no longer requires the storage and there’s a need to utilize the disk in some other group or decommission it entirely.

First, I wanted to talk a little about dependencies and their function. Resource dependencies are created between one or more resources in a cluster group in order to determine the order in which resources in the group are taken online/offline. Take for instance a SQL Server resource that’s dependent on the ‘Physical Disk’ resources where SQL’s data is stored. A dependency should be established so that the SQL Server resource is dependent on the disk resource. This dependency will make sure the disk comes online first, and then SQL Server. Same thing when taking those things offline, except in reverse. The SQL Server resource will come offline before the disk comes offline. Obviously, we would not want to have SQL Server attempt to start until all the disks it was using was online first.

Once resources in a cluster group are linked with dependencies, you have to be careful when deleting resources out of a group. If you don’t remove dependencies properly, you may end up inadvertently removing other resources as well.

In this example, I have two resources in a cluster group, Resource A and Resource B. I establish dependencies between them so that Resource B is dependent on Resource B.

clip_image001

This means that when the group is brought online, Resource B will not be brought online until Resource A is online.

Here is what the dependency report looks like.

clip_image002

Now that these two resources are linked, you have to be careful when deleting these resources. If I were to delete Resource A from the group without first removing the dependency, BOTH resources will get removed.

clip_image003

At this point, a pop-up will appear warning that a removal of this resource could affect applications using this resource.

clip_image004

If you click ‘Yes’, both resources get removed.

clip_image005

Lesson learned. If the resource you are deleting is dependent on any other resources, remove the dependency first.

Now, we get to the main point of this post. The above process is fine for deleting resources from a cluster group unless the resource you are deleting is configured as a “Physical Disk’ resource, and it a mount point disk. The process differs slightly and you must follow this process or you could find yourself unintentionally moving every resource in the group into ‘Available Storage’.

First, lets cover proper way to remove a mount point disk from a cluster group. In this example, I have a plain File Server group with a Network Name, IP Address, File Server, and three disks. A root disk (Disk X:) and two mount points using folders on the root of X: called X:\MountPointA and X:\MountPointB.

clip_image006

Since I don’t have any shares located on X:\MountPointB, I want to remove that disk so I can use it in some other application. The FIRST thing I need to do is take the resource offline.

clip_image007

Then I can right-click the resource and click ‘Remove from GroupName’

clip_image008

When you remove a ‘Physical Disk’ resource from a cluster group, it doesn’t actually remove the cluster resource altogether, it moves the disk resource into the ‘Available Storage’ group.  This is so that you can reallocate the resource to another group if needed.

As you can see, the resource now shows in ‘Available Storage’

clip_image009

At this point, you can remove the mount point configuration, or change it to a lettered drive so you can use for some other application.

Now let’s go over what can happen if you don’t take the mount point offline before removing it. The main reason in going over this is to show you how to recover so that there’s no adverse impact to the Cluster.

In this example, I am removing the same resource from the File Server group following the same process above WITHOUT taking it offline first. First, I verified there were no dependencies on the ‘DiskX:\MountPointB’ resource.

clip_image010

Now here’s where it gets fun. After I attempted to remove the mount point, ALL of my resources disappear from the group. ??????

clip_image011

Time to panic? No, all is not lost. What happened is that because we had a mount point configured, and a mount point is not usable unless there’s a root disk, ALL of the resources moved to ‘Available Storage’ because the rest of the resources DO have dependencies.

It may appear all of the resources disappeared. Because in the UI, we only show ‘Physical Disk’ resources, if any other resources get put in that group, they don’t show up in the UI. However, if we run a command line to display all resources and their groups, we can see that the resources are still there.

clip_image012

To get the resources back into the right group, just move the disks back to the original File Server group. Right click the disk, More actions, and select Move this resource to another service or application. The same dependency tree will cause the resources to move back.

clip_image013

Now we have all our resources back and we can follow the correct process of taking the mount point disk offline BEFORE removing it.

Cheers!

Jeff Hughes
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Great Post. I was confronted with the same issue.

    All the resources [IP Address, Network Name. SQL Server] were moved to Available Storage. In my case, the resources couldn't be moved via GUI.

    The solution was to move the resources via cluster.exe. "cluster res "Resource Name" /moveto:"

  • I think there is a typo at the end of the third paragraph.  

    It says "I establish dependencies between them so that Resource B is dependent on Resource B" and I think that it should say  " I establish dependencies between them so that Resource B is dependent on Resource A."

    By the way, great post as always.

  • I experienced this as well and used the command line to move everything back to the correct group, same as Alex M.

    My question is this:  Is this by design or is this a known bug in MS Clustering?

    In my case, I also received the below error when trying to move a mounted disk (with no dependencies) to available storage from SQL Group:

    The operation has failed

    Failure removing storage resource

    Details: Error code 0x800700b7

    Cannot create a file when that file already exists

  • Thank You so much. Save my day.

  • Nice article, but the images are not displaying. Any chance of getting them restored?

  • We encountered this exact issue on a SQL Server 2008R2 failover cluster instance on Win2k8 and this article was a lifesaver. We were able to bring the disks back into the group through the GUI but only after using the FailoverClusters PowerShell cmdlets to offline every resource associated with the group that was now in Available Storage.

    For reference, the PowerShell cmdlets to get the

    import-failoverclusters
    get-clustergroup "available storage" | get-clusterresource

    Use Stop-ClusterResource to offline each resource as needed.

    Great post - thank you so much for sharing John!!

  • @dj
    we are aware of the issues with the images and is a problem through out the TechNet blog sites. Our internal people are working on it, but no eta.