1822741 Members
4019 Online
109644 Solutions
New Discussion юеВ

Self Terminating Cable

 
SOLVED
Go to solution
Craig Rants
Honored Contributor

Self Terminating Cable

All S/G gurus a second of your time...

I am testing a service guard implementation on a small jbod. I don't have problem setting up the vg on one disk then vgimporting in the other.

But when I try to run the initial cmquerycl to create the ascii file, both syslogs go nuts with scsi lbolts and the like, the only thing I can think is that the scsi cables are not self terminating.

Do you concur, or should I look for something else. I am pretty sure that my disks are good.

Any help would be appreciated.

Also has anyone seen the message "can't stat /etc/cmcluster/cmclconfig" before?

Thanks,
Craig
"In theory, there is no difference between theory and practice. But, in practice, there is. " Jan L.A. van de Snepscheut
8 REPLIES 8
Helen French
Honored Contributor

Re: Self Terminating Cable

I have seen lot of lbolt error messages from MC/SG environment just becuase of patches. Are you sure you have all patches loaded in the system?
Life is a promise, fulfill it!
Sridhar Bhaskarla
Honored Contributor
Solution

Re: Self Terminating Cable

Hi Craig,

What kind of systems do you have?. You may have to change the scsi ID of your HBAs to set them different on each box. Do an ioscan on both the boxes and observe the scsi id of the target. They should not be equal.

-Sri
You may be disappointed if you fail, but you are doomed if you don't try
Craig Rants
Honored Contributor

Re: Self Terminating Cable

Thought about the patches, I'll double check.

The hba could be it, forgot to check that.

I'll let ya know.

Craig
"In theory, there is no difference between theory and practice. But, in practice, there is. " Jan L.A. van de Snepscheut
Eugeny Brychkov
Honored Contributor

Re: Self Terminating Cable

You will need self-terminating (inline-terminated) cables only in case you'll need to replace SCSI card without bringing cluster down. In normal conditions all shared SCSI busses should be terminated from both ends, like ordinary SCSI busses. All devices should have different SCSI Ids (including SCSI HBAs - usually 7 and down).
These cables should be connected to the last devices in the chain (from both ends), with terminated connector towards end of the bus. This connector has terminator built into it. If you disconnect this connector from the device, bus remains terminated - as soon as terminator is in the cable. But in this case you have to check and turn off internal SCSI card's termination to not over-terminate bus
Eugeny
A. Clay Stephenson
Acclaimed Contributor

Re: Self Terminating Cable

I'm assuming this is a two-node cluster. Typically the termination is done on the host disk controllers and they are on the opposite ends of the scsi bus. Depending upon the host/HBA type you need to make sure that the resistor packs are installed on the cards or the termination is enable via firmware.

You only need in-line terminators when you break the bus and need to replace a controller. You also need to check that at least one device is supplying termination power.

If it ain't broke, I can fix that.
A. Clay Stephenson
Acclaimed Contributor

Re: Self Terminating Cable

Hi again:

Don't overlook the obviuos: One controller is set to ID 7 and the other 6 and there are no device conflicts?
If it ain't broke, I can fix that.
Craig Rants
Honored Contributor

Re: Self Terminating Cable

The HBA was it, at least for the scsi lbolts, had to actually set a toggle switch on the card (a little old).

Still getting the "can't stat error" on my cmcheckconf command however.

Any thoughts
"In theory, there is no difference between theory and practice. But, in practice, there is. " Jan L.A. van de Snepscheut
IT Response
Esteemed Contributor

Re: Self Terminating Cable

Question: Could an old binary file be hanging around? If so run:

cmdeleteconf,

then cmquerycl.