[Info-vax] Expected votes Was: troubles with quorum disk

[David Froble]

Tom Linden wrote:
> On Mon, 07 Jan 2013 09:01:29 -0800, Stephen Hoffman 
> <seaohveh at hoffmanlabs.invalid> wrote:
> 
>> On 2013-01-07 16:45:35 +0000, Pierre said:
>>
>>> VAXCLUSTER                      2          1          0          2
>>> Coded-value
>>> EXPECTED_VOTES                  3          1          1        127
>>> Votes
>>> VOTES                           1          1          0        127
>>> Votes
>>> DISK_QUORUM     "$1$DGA4         "    "    "     "    "     "ZZZZ"
>>> Ascii
>>> QDSKVOTES                       2          1          0        127
>>> Votes
>>> ...
>>>  81518640  TLSAXV  0001000B      3      1     local   member,qf_same
>>> 8167FE80  TLSAXY  0001000D      3      1     open   
>>> member,qf_same,qf_watcher,qf_active
>>> ...
>>> I get no error in the autogen, i rebooter the whole cluster but I 
>>> still have QDSKVOTES that differ from the quorum disk vote as seen by 
>>> SDA.
>>
>> If you have two one-vote voting nodes and a two-vote quorum disk in a 
>> two-node cluster, then your EXPECTED_VOTES setting should be four.  
>> Not three.
>>
>> If you're aiming to survive the loss of one host (as I'd suspect), 
>> then set the quorum disk to three votes, and set the EXPECTED_VOTES to 
>> five on both hosts.
>>
>> Or acquire a third (voting) host or emulator for the cluster, and then 
>> consider removing the quorum disk entirely, or possibly reducing the 
>> QDSKVOTES quorum disk votes to two.
>>
>> That does mean you'll need the quorum disk around at all times, and 
>> you'll encounter the slowdown inherently involved with counting the 
>> votes from the quorum disk when either node leaves the cluster.  I'll 
>> also presume that Fibre Channel disk is RAID, etc.  But it'll work.
>>
>> As for the error you're reporting, it's possible that the changes 
>> didn't expunge MODPARAMS.DAT of other existing references?  That's 
>> pretty easy to do, as older systems tend to find that MODPARAMS file 
>> filled with all manner of cruft and duplicate entries.  Check the 
>> AUTOGEN summary report(s) in SYS$SYSTEM:AGEN$PARAMS.REPORT, and see 
>> what values are listed.  Also confirm that the new (correct) entries 
>> are in BOTH files or (if you have a common disk) consider using the 
>> AUTOGEN "include file" syntax for the core cluster settings.  And 
>> confirm that the AUTOGEN went as far as SETPARAMS or REBOOT, of course.
>>
>>
> Related question.  A while ago we had a power outage that lasted longer 
> than the
> UPS batteries.  The cluster did not come back up automatically.  The 
> licenses had not
> been updated on one of the nodes, an oversight.  On closer exam I noted 
> that expected_votes
> in the 4 node cluster was set at 3 on the other 3 nodes and 7 on the 
> errant node.   The cluster
> was once 7 nodes but have reduced it.  I tried setting expected votes to 
> 4 in SYSGEN and did a
> WRITE CURRENT  but it did not change it.  What do I need to do?
> 
> 

Did you have SYSPRV priv ?

I normally advise that except for testing that most parameters be 
adjusted in MODPARAMS.