Disk Enclosures
1751738 Members
5738 Online
108781 Solutions
New Discussion

Re: CAPI/VDS/VSS problems

 
TadasK
Occasional Contributor

CAPI/VDS/VSS problems

Sorry, if this sounds noobish but Im in a bit confused...

 

We have a failover cluster running and wanted to use hardware VSS but are stuck trying to make it work...

 

We're using P2000 iSCSI MSA. LUNs are mapped identicaly to both cluster hosts: 0 is Quorum, 1, 2 are CSVs, and 3 is Cluster DTC. We installed the CAPI proxy, VDS, and then VSS on both hosts. Now, the problem is that one of the hosts can use hardware VSS while the other fails. VSS works on the host which owns the Quorum disk. If we move the Quorum disk to the other host - VSS works on it... Seems that CAPI proxy checks the first LUN, and if its state is reserved, it fails... Is there a step we're missing?

 

CAPI proxy logs on the failing host are full of such entries:

Jun 20, 2012 17:28:33.809 [7000]: Initialization Complete.

Jun 20, 2012 17:28:33.809 [7000]: InitializeCAPI: controller 0, handle=0x009ecbd4 0x009ecbd4 0x009ecbd4 0x009ecbd4 
Jun 20, 2012 17:28:33.809 [7000]: sn=00C0FF10F4F0 \\.\PhysicalDrive2(4.0.0.0) isPartner 0 responds 0 id 1
Jun 20, 2012 17:28:33.809 [7000]: InitializeCAPI: controller 1, handle=0x009ecbd4 0x00ae697c 0x009ecbd4 0x009ecbd4 
Jun 20, 2012 17:28:33.809 [7000]: sn=00C0FF131C06 \\.\PhysicalDrive2(4.0.0.0) isPartner 1 responds 0 id 1
Jun 20, 2012 17:28:33.809 [7000]: InitializeCAPI: controller 2, handle=0x00be0724 0x00be0724 0x00be0724 0x00be0724 
Jun 20, 2012 17:28:33.809 [7000]: sn= \\.\PhysicalDrive2(4.0.0.0) isPartner 0 responds 1 id 1
Jun 20, 2012 17:28:33.809 [7000]: configSequenceNumber = 0
Jun 20, 2012 17:28:33.810 [7000]: sendScsiCommand: \\.\PhysicalDrive2, (0.0.0), pDataBuffer=0x1796B570, dataLength=80 commandType=3 (WrtBuf)
Jun 20, 2012 17:28:33.855 [7000]: IOCTL_SCSI_PASS_THROUGH_PATH_DIRECT succeeded (\\.\PhysicalDrive2)
Jun 20, 2012 17:28:33.855 [7000]: ERROR: DeviceIoControl call failed with bad SCSI status
Jun 20, 2012 17:28:33.855 [7000]: SCSI status: 18h = RESERVATION CONFLICT
Jun 20, 2012 17:28:33.855 [7000]: Sense Key 0 = No Sense 
Jun 20, 2012 17:28:33.855 [7000]: Addl Sense = 0
Jun 20, 2012 17:28:33.855 [7000]: Addl Sense Qual = 0
Jun 20, 2012 17:28:33.855 [7000]: Sense Info -- consult SCSI spec for details
Jun 20, 2012 17:28:33.855 [7000]: -------------------------------------------
Jun 20, 2012 17:28:33.855 [7000]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Jun 20, 2012 17:28:33.855 [7000]: 
Jun 20, 2012 17:28:33.855 [7000]: SCSI32LMX_SendAndReceivePacket: 'comm error' sendWriteBuf retrying; retry cnt 1
Jun 20, 2012 17:28:33.855 [7000]: sendScsiCommand: \\.\PhysicalDrive2, (0.0.0), pDataBuffer=0x1796B570, dataLength=80 commandType=3 (WrtBuf)
Jun 20, 2012 17:28:33.906 [7000]: IOCTL_SCSI_PASS_THROUGH_PATH_DIRECT succeeded (\\.\PhysicalDrive2)
Jun 20, 2012 17:28:33.906 [7000]: ERROR: DeviceIoControl call failed with bad SCSI status
Jun 20, 2012 17:28:33.906 [7000]: SCSI status: 18h = RESERVATION CONFLICT
Jun 20, 2012 17:28:33.906 [7000]: Sense Key 0 = No Sense 
Jun 20, 2012 17:28:33.906 [7000]: Addl Sense = 0
Jun 20, 2012 17:28:33.906 [7000]: Addl Sense Qual = 0
Jun 20, 2012 17:28:33.906 [7000]: Sense Info -- consult SCSI spec for details

1 REPLY 1
Manfri
Frequent Advisor

Re: CAPI/VDS/VSS problems

i didn't have a solution but  merging info from http://h30499.www3.hp.com/t5/Disk-Array/Issues-with-VSS-and-VDS-on-Win-2008-R2-SP1-cluster-MSA2324i/m-p/5737973#.UA-pR7Q0OSp and this http://h30499.www3.hp.com/t5/Disk-Array/CAPI-VDS-VSS-problems/td-p/5695987 I concluded that:

 

The capi ( wich is used by vss and vds to communicate with the san ) get info from the first lun about the san capabilities.

if the lun is owned by the node ok, otherwise if it is reserved by another node fail.

 

the thing that pointed me to this was the combination of this from the first thread

 

Jul 24, 2012 14:00:54.661: discoverRaidControllers() returning 0x00000000

Jul 24, 2012 14:00:54.661: capiGetHbaWwpnList(): returning 0x00000000

Jul 24, 2012 14:00:54.768: StartingLun = 1

Jul 24, 2012 14:00:54.768: StandardVolumesAreSupported = 2

Jul 24, 2012 14:00:54.768: m_deviceIdDescriptor.m_cIdentifiers=2

 

and the the second thread quoted

 

in the second thread  thread quoted above the quorum is ther first lun mapped  and i suspect that for the second thread  the first lun was owned by the node who is able to do hw snapshot.

 

i'had the same problem but none was unable to fix it ( even HP support ) but the mix of this two thread, a new p2000 install and a sleepless night i think sheds new light on the problem.

 

the first test in my environment ( moving the cluster resorce to the second node ) made the storage for manager show lun info in the second node, but i'm sure that is not a real solution.

in my next test i think i will map a dedicated ( non clustered ) lun as first lun on every node and i believe that work around fix somewhat the problem.

 

I understand that it's not a even a solution especially  if you have lot's on node on a iscsi msa2000 (pleas read this even if maybe it's resolved on newer firmware ) http://www.hyper-v.nu/archives/hvredevoort/2011/01/array-firmware-as-a-limiting-factor-in-r2-clusters/ but if this workaround works maybe we are able to contact HP support with a clear problem and something that we can claim is a bug to be fixed

 

may the force be with us


@TadasK wrote:

Sorry, if this sounds noobish but Im in a bit confused...

 

We have a failover cluster running and wanted to use hardware VSS but are stuck trying to make it work...

 

We're using P2000 iSCSI MSA. LUNs are mapped identicaly to both cluster hosts: 0 is Quorum, 1, 2 are CSVs, and 3 is Cluster DTC. We installed the CAPI proxy, VDS, and then VSS on both hosts. Now, the problem is that one of the hosts can use hardware VSS while the other fails. VSS works on the host which owns the Quorum disk. If we move the Quorum disk to the other host - VSS works on it... Seems that CAPI proxy checks the first LUN, and if its state is reserved, it fails... Is there a step we're missing?

 

CAPI proxy logs on the failing host are full of such entries:

Jun 20, 2012 17:28:33.809 [7000]: Initialization Complete.

Jun 20, 2012 17:28:33.809 [7000]: InitializeCAPI: controller 0, handle=0x009ecbd4 0x009ecbd4 0x009ecbd4 0x009ecbd4 
Jun 20, 2012 17:28:33.809 [7000]: sn=00C0FF10F4F0 \\.\PhysicalDrive2(4.0.0.0) isPartner 0 responds 0 id 1
Jun 20, 2012 17:28:33.809 [7000]: InitializeCAPI: controller 1, handle=0x009ecbd4 0x00ae697c 0x009ecbd4 0x009ecbd4 
Jun 20, 2012 17:28:33.809 [7000]: sn=00C0FF131C06 \\.\PhysicalDrive2(4.0.0.0) isPartner 1 responds 0 id 1
Jun 20, 2012 17:28:33.809 [7000]: InitializeCAPI: controller 2, handle=0x00be0724 0x00be0724 0x00be0724 0x00be0724 
Jun 20, 2012 17:28:33.809 [7000]: sn= \\.\PhysicalDrive2(4.0.0.0) isPartner 0 responds 1 id 1
Jun 20, 2012 17:28:33.809 [7000]: configSequenceNumber = 0
Jun 20, 2012 17:28:33.810 [7000]: sendScsiCommand: \\.\PhysicalDrive2, (0.0.0), pDataBuffer=0x1796B570, dataLength=80 commandType=3 (WrtBuf)
Jun 20, 2012 17:28:33.855 [7000]: IOCTL_SCSI_PASS_THROUGH_PATH_DIRECT succeeded (\\.\PhysicalDrive2)
Jun 20, 2012 17:28:33.855 [7000]: ERROR: DeviceIoControl call failed with bad SCSI status
Jun 20, 2012 17:28:33.855 [7000]: SCSI status: 18h = RESERVATION CONFLICT
Jun 20, 2012 17:28:33.855 [7000]: Sense Key 0 = No Sense 
Jun 20, 2012 17:28:33.855 [7000]: Addl Sense = 0
Jun 20, 2012 17:28:33.855 [7000]: Addl Sense Qual = 0
Jun 20, 2012 17:28:33.855 [7000]: Sense Info -- consult SCSI spec for details
Jun 20, 2012 17:28:33.855 [7000]: -------------------------------------------
Jun 20, 2012 17:28:33.855 [7000]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Jun 20, 2012 17:28:33.855 [7000]: 
Jun 20, 2012 17:28:33.855 [7000]: SCSI32LMX_SendAndReceivePacket: 'comm error' sendWriteBuf retrying; retry cnt 1
Jun 20, 2012 17:28:33.855 [7000]: sendScsiCommand: \\.\PhysicalDrive2, (0.0.0), pDataBuffer=0x1796B570, dataLength=80 commandType=3 (WrtBuf)
Jun 20, 2012 17:28:33.906 [7000]: IOCTL_SCSI_PASS_THROUGH_PATH_DIRECT succeeded (\\.\PhysicalDrive2)
Jun 20, 2012 17:28:33.906 [7000]: ERROR: DeviceIoControl call failed with bad SCSI status
Jun 20, 2012 17:28:33.906 [7000]: SCSI status: 18h = RESERVATION CONFLICT
Jun 20, 2012 17:28:33.906 [7000]: Sense Key 0 = No Sense 
Jun 20, 2012 17:28:33.906 [7000]: Addl Sense = 0
Jun 20, 2012 17:28:33.906 [7000]: Addl Sense Qual = 0
Jun 20, 2012 17:28:33.906 [7000]: Sense Info -- consult SCSI spec for details



@TadasK wrote:

Sorry, if this sounds noobish but Im in a bit confused...

 

We have a failover cluster running and wanted to use hardware VSS but are stuck trying to make it work...

 

We're using P2000 iSCSI MSA. LUNs are mapped identicaly to both cluster hosts: 0 is Quorum, 1, 2 are CSVs, and 3 is Cluster DTC. We installed the CAPI proxy, VDS, and then VSS on both hosts. Now, the problem is that one of the hosts can use hardware VSS while the other fails. VSS works on the host which owns the Quorum disk. If we move the Quorum disk to the other host - VSS works on it... Seems that CAPI proxy checks the first LUN, and if its state is reserved, it fails... Is there a step we're missing?

 

CAPI proxy logs on the failing host are full of such entries:

Jun 20, 2012 17:28:33.809 [7000]: Initialization Complete.

Jun 20, 2012 17:28:33.809 [7000]: InitializeCAPI: controller 0, handle=0x009ecbd4 0x009ecbd4 0x009ecbd4 0x009ecbd4 
Jun 20, 2012 17:28:33.809 [7000]: sn=00C0FF10F4F0 \\.\PhysicalDrive2(4.0.0.0) isPartner 0 responds 0 id 1
Jun 20, 2012 17:28:33.809 [7000]: InitializeCAPI: controller 1, handle=0x009ecbd4 0x00ae697c 0x009ecbd4 0x009ecbd4 
Jun 20, 2012 17:28:33.809 [7000]: sn=00C0FF131C06 \\.\PhysicalDrive2(4.0.0.0) isPartner 1 responds 0 id 1
Jun 20, 2012 17:28:33.809 [7000]: InitializeCAPI: controller 2, handle=0x00be0724 0x00be0724 0x00be0724 0x00be0724 
Jun 20, 2012 17:28:33.809 [7000]: sn= \\.\PhysicalDrive2(4.0.0.0) isPartner 0 responds 1 id 1
Jun 20, 2012 17:28:33.809 [7000]: configSequenceNumber = 0
Jun 20, 2012 17:28:33.810 [7000]: sendScsiCommand: \\.\PhysicalDrive2, (0.0.0), pDataBuffer=0x1796B570, dataLength=80 commandType=3 (WrtBuf)
Jun 20, 2012 17:28:33.855 [7000]: IOCTL_SCSI_PASS_THROUGH_PATH_DIRECT succeeded (\\.\PhysicalDrive2)
Jun 20, 2012 17:28:33.855 [7000]: ERROR: DeviceIoControl call failed with bad SCSI status
Jun 20, 2012 17:28:33.855 [7000]: SCSI status: 18h = RESERVATION CONFLICT
Jun 20, 2012 17:28:33.855 [7000]: Sense Key 0 = No Sense 
Jun 20, 2012 17:28:33.855 [7000]: Addl Sense = 0
Jun 20, 2012 17:28:33.855 [7000]: Addl Sense Qual = 0
Jun 20, 2012 17:28:33.855 [7000]: Sense Info -- consult SCSI spec for details
Jun 20, 2012 17:28:33.855 [7000]: -------------------------------------------
Jun 20, 2012 17:28:33.855 [7000]: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
Jun 20, 2012 17:28:33.855 [7000]: 
Jun 20, 2012 17:28:33.855 [7000]: SCSI32LMX_SendAndReceivePacket: 'comm error' sendWriteBuf retrying; retry cnt 1
Jun 20, 2012 17:28:33.855 [7000]: sendScsiCommand: \\.\PhysicalDrive2, (0.0.0), pDataBuffer=0x1796B570, dataLength=80 commandType=3 (WrtBuf)
Jun 20, 2012 17:28:33.906 [7000]: IOCTL_SCSI_PASS_THROUGH_PATH_DIRECT succeeded (\\.\PhysicalDrive2)
Jun 20, 2012 17:28:33.906 [7000]: ERROR: DeviceIoControl call failed with bad SCSI status
Jun 20, 2012 17:28:33.906 [7000]: SCSI status: 18h = RESERVATION CONFLICT
Jun 20, 2012 17:28:33.906 [7000]: Sense Key 0 = No Sense 
Jun 20, 2012 17:28:33.906 [7000]: Addl Sense = 0
Jun 20, 2012 17:28:33.906 [7000]: Addl Sense Qual = 0
Jun 20, 2012 17:28:33.906 [7000]: Sense Info -- consult SCSI spec for details