[Info-vax] WRONGVU

[Phillip Helbig undress to reply]

%MOUNT-F-WRONGVU, device is already a member of another virtual unit

A shadow-set member failed, so I got I new disk, initialized it and 
mounted it to make sure it was OK, then issued the appropriate MOUNT 
command to start a full copy.  This works as expected.  However, I now 
get WRONGVU when trying to mount it.  (Yes, it is already mounted, but I 
have a procedure which mounts all the shadow sets.  Its main purpose is 
to run during the startup, but of course one should be able to run it at 
any time, and this was always possible in the past.)

HELP says:

 WRONGVU,  device is already a member of another virtual unit

  Facility:     MOUNT, Mount Utility

  Explanation:  This message can occur under any of the following conditions:

                o A shadow set member (identified in an accompanying
                  SHADOWFAIL message) is already mounted on another node
                  in the cluster as a member of a different shadow set.

                o The device is the target of a shadow set copy operation,
                  and the copy operation has not yet started. In this case,
                  the storage control block (SCB) of the copy target is not
                  in the same location as it is on the master node. This
                  causes MOUNT to read the wrong SCB and fail with this
                  error.

                o The target of the shadow set copy operation is a new,
                  uninitialized disk. This failure is commonly seen when a
                  MOUNT/CLUSTER command is issued and one or more of the
                  members is a new disk. The set is mounted successfully
                  on the local node, but all of the remote nodes report a
                  WRONGVU error.


  User Action:

                o For the first condition, specify a different member for the
                  shadow set you are mounting, or specify the correct virtual
                  unit for the member that is already mounted elsewhere.

                o For the second condition, wait for the copy operation
                  to proceed before attempting to remount this device, or
                  initialize the copy target disk so that the SCB is in the
                  same location as it is on the master member.

                o For the third condition, OpenVMS recommends that all new
                  disks be initialized prior to mounting them into a shadow
                  set.

It's pretty clear that the third condition applies here.  However, I get 
the same message on the node where the original MOUNT command was 
running.  (The two members are on different nodes.)

Why haven't I seen this before?

The only thing which is different from similar situations in the past is
that one of the members, the new one, is a) on a different node and b)
at a different SCSI address than the failed member.  (I probably could 
have kept things as they were, but I thought that I had a controller 
problem on the node where the member failed, which is why the 
replacement is on another node.)

Presumably a cluster reboot would fix things, but that seems rather 
drastic.

What about dismounting it then remounting it, either one node at a time 
or first dismounting on all nodes then mounting on all nodes (after the 
copy has completed, of course)?