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.

The emulated Alpha isn't doing anything at this point, it's just booted with no other processing going on.

Am I forgetting something easy to fix this?

REASON WHY I'M DOING IT: Eventually I want to get a second emulated AlphaServer in the configuration too, and I need a quorum disk so that I can run with only one AlphaServer if necessary.

What's bugging me the most is that I *think* that I had this working a year ago, but then abandoned it and came back to it recently. Perhaps I'm just virtualizing too many levels deep and my laptop can't keep up with the load?

Thanks,
Scott

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).

--
Pure Personal Opinion | HoffmanLabs LLC

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

Stephen Hoffman schrieb am 28.10.2023 um 15:06:
> 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. [...]

Well, Scott already posted the solution for FreeAXP, CHARON-AXP supports
local container files as shared SCSI disks as well, and so does AVTware...

> OpenVMS would need much better SMB support deeply integrated for the most common case, there.

OpenVMS does not need SMB for using a quorum disk, but you know that...

Hans.

In the actual xdelta documentation you'll find the following:

Example

7FFE1600/'R0/ Linefeed Linefeed'

The ASCII string “R0/ LINEFEED LINEFEED” is stored at address 7FFE1600.
This string, if subsequently
executed with the ;E command, examines the contents of general register
0 (the command
R0/), then examines two subsequent registers (using two LINEFEED commands).

But as soon as I type in "7ffe1600/" xdelta prints out the famous "eh?".

So what do I do wrong?????

Eberhard

On 2023-12-12, vaxinf@gmail.com <vaxinf@googlemail.com> wrote:
> In the actual xdelta documentation you'll find the following:
>
> Example
>
> 7FFE1600/'R0/ Linefeed Linefeed'
>
> The ASCII string ?R0/ LINEFEED LINEFEED? is stored at address 7FFE1600.
> This string, if subsequently
> executed with the ;E command, examines the contents of general register
> 0 (the command
> R0/), then examines two subsequent registers (using two LINEFEED commands).
>
> But as soon as I type in "7ffe1600/" xdelta prints out the famous "eh?".
>
> So what do I do wrong?????
>

I don't suppose it's case sensitive by any chance is it ?

Also, what architecture is this (in case it matters) ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Simon Clubley schrieb am Dienstag, 12. Dezember 2023 um 14:21:08 UTC+1:
> On 2023-12-12, vax...@gmail.com <vax...@googlemail.com> wrote:
> > In the actual xdelta documentation you'll find the following:
> >
> > Example
> >
> > 7FFE1600/'R0/ Linefeed Linefeed'
> >
> > The ASCII string ?R0/ LINEFEED LINEFEED? is stored at address 7FFE1600.
> > This string, if subsequently
> > executed with the ;E command, examines the contents of general register
> > 0 (the command
> > R0/), then examines two subsequent registers (using two LINEFEED commands).
> >
> > But as soon as I type in "7ffe1600/" xdelta prints out the famous "eh?".
> >
> > So what do I do wrong?????
> >
> I don't suppose it's case sensitive by any chance is it ?
>
> Also, what architecture is this (in case it matters) ?
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Walking destinations on a map are further away than they appear.

simh VAX/VMS V7.3