topic Re: Disconnecting LUN from SQL Server Cluster in Data Protection

Disconnecting LUN from SQL Server Cluster

JCASON — Thu, 05 Jun 2025 06:09:43 GMT

We have an existing SQL Server cluster that was using 2 LUNs attached via iSCSI. We want to deprovision these LUNs as they are no longer needed.

We have removed the SQL dependency from both LUNs. At this point, can we disconnect these LUNs via snapdrive? Or do we need to fully remove them from the cluster service first?

Re: Disconnecting LUN from SQL Server Cluster

spat — Wed, 20 Feb 2013 17:17:40 GMT

You should disconnect the LUNs thru snapdrive.

Re: Disconnecting LUN from SQL Server Cluster

JCASON — Wed, 20 Feb 2013 17:25:07 GMT

We will be disconnecting the LUNs via snapdrive...I'm wondering if we can do it safely at this point.

I know with the SQL dependency in place we can't disconnect the disk. Once the SQL dependency has been removed, are we OK to disconnect the disk now? Or do we need to fully remove it from the cluster service first.

Re: Disconnecting LUN from SQL Server Cluster

spat — Wed, 20 Feb 2013 17:27:57 GMT

Snapdrive should communicate to the cluster and remove that from cluster resource as long as there are no dependency.

Re: Disconnecting LUN from SQL Server Cluster

KENNETHKOZEL — Thu, 21 Feb 2013 00:33:11 GMT

Its all achievable via the cli. lun show and unmap commands pretty much cover it. Snapdrive does not always work. Especially when used on Windows clusters.

Re: Disconnecting LUN from SQL Server Cluster

JCASON — Sat, 02 Mar 2013 14:56:22 GMT

The removal was successful, however I notice a message in the logs during this operation. It was the same or very similar to:

The Transaction (UOW=%1, Description='%3') was unable to be committed, and instead rolled back; this was due to an error message returned by CLFS while attempting to write a Prepare or Commit record for the Transaction. The CLFS error returned was: %4.

I also note that I see this message when attaching a LUN to the SQL instance via SnapDrive as well, so I'm not sure this is directly related to the removal. Is this expected when adding or removing disks via SnapDrive in a SQL server cluster? I don't believe I've seen this before, but I may have just not dived deeply enough to find it.