[Info-vax] %CNXMAN, Using local access method for quorum disk every QDSKINTERVAL seconds (emulated Alpha V7.3-2)

[Scott Snadow]

On Saturday, October 28, 2023 at 8:06:24 AM UTC-5, Stephen Hoffman wrote:
> On 2023-10-25 16:48:11 +0000, Scott Snadow said: 
> 
> > Trying to replicate an old production system, hence the reason that I'm 
> > messing around with V7.3-2. 
> > 
> > I'm running on a Windows 10 laptop... 
> > ...using VMware Workstation Player version 16 with six virtual cores... 
> > ......running Windows 11... 
> > .........running FreeAXP version 679... 
> > ............running a freshly-installed V7.3-2 
> > 
> > I created a quorum disk and made it $1$DKA600; initialized it, mounted 
> > it, ran SYS$MANAGER:CLUSTER_CONFIG.COM to point to it. 
> > 
> > Rebooted the emulated Alpha a couple of times and it boots fine, goes 
> > through the expected "remote access" for the quorum disk, then changes 
> > to local, and all is well. The disk is mounted during the startup. 
> > But before the startup completes, I start getting that local access 
> > message across OPA0: every QDSKINTERVAL seconds FOREVER. Originally it 
> > was every 3 seconds since that's the default, then I increased it to 
> > 10, and now I get the message every 10 seconds.
> Absent—maybe—fibre channel, I don't know of any emulators that even 
> have any shared-access storage I/O paths to local or 
> directly-accessible non-served storage. OpenVMS would need much better 
> SMB support deeply integrated for the most common case, there. 
> 
> Absent VSI hardware configuration rules for quorum disks for 
> virtualized x86-64—and not that I've gone looking for that—I'd avoid 
> quorum disk usage with virtualized x86-64, and also with emulated 
> configurations. 
> 
> Absent a directly-accessible and shareable I/O path into storage, there 
> is no added benefit and there is added slowness running a quorum disk. 
> Assign the votes to the host(s). 

Finally solved the problem myself; reluctantly admitting that I'd missed a documented detail that's easily overlooked when you've done this before a long time ago (that's my excuse, and I'm sticking to it!)

A quorum disk on a SCSI controller, whether physical or emulated, must support TCQ (tagged command queueing.)  It says so in the "Guidelines for OpenVMS Cluster Configurations", at least as far back as OpenVMS Alpha V7.3-2:

"OpenVMS Cluster systems also place one restriction on the SCSI quorum disk, whether the disk is located on a single-host SCSI bus or a multihost SCSI bus. The SCSI quorum disk must support tagged command queuing (TCQ). This is required because of the special handling that quorum I/O receives in the OpenVMS SCSI drivers."

The FreeAXP emulator's implementation of SCSI disks lets you enable TCQ, but it's not the default setting.  And so now I know what happens if that setting isn't right!  [Another setting that's important to get correct for VMSclusters is write_share.]

Cheers,
Scott