Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
WRONGVU, device is already a member of another virtual unit
116 views
Skip to first unread message
Phillip Helbig (undress to reply)
Dec 5, 2015, 6:47:41 AM12/5/15
to
I replaced a member of a shadow set (plan ist to use DDS and DVE to
increase the size) and got this error when a satellite tried to mount
the disk during boot. Interactive mounts also threw the same error.
Probably expected:
> 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.
No, that's not it.
> 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.
No, that can't be it either, since the copy had already started.
> 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.
I guess this is it. I usually initialize a new disk before adding it to
a shadow set (and do some basic tests to see if it is OK), but in this
case I forgot to disable a recurring MOUNT procedure (just to make sure
that any disks which get dismounted due to unexpected circumstances get
remounted) and it mounted it for me.
However, even the copy is still not complete, on ALL THREE NODES IN THE
CLUSTER (each node has one member locally mounted) the standard MOUNT
command now works. Is this expected, i.e. that the behaviour changes
during the copy? If so, presumably I could boot the satellite now.
increase the size) and got this error when a satellite tried to mount
the disk during boot. Interactive mounts also threw the same error.
Probably expected:
> 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.
No, that's not it.
> 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.
No, that can't be it either, since the copy had already started.
> 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.
I guess this is it. I usually initialize a new disk before adding it to
a shadow set (and do some basic tests to see if it is OK), but in this
case I forgot to disable a recurring MOUNT procedure (just to make sure
that any disks which get dismounted due to unexpected circumstances get
remounted) and it mounted it for me.
However, even the copy is still not complete, on ALL THREE NODES IN THE
CLUSTER (each node has one member locally mounted) the standard MOUNT
command now works. Is this expected, i.e. that the behaviour changes
during the copy? If so, presumably I could boot the satellite now.
Hans Vlems
Dec 5, 2015, 6:53:17 PM12/5/15
to
What was the command that produced this error?
Stephen Hoffman
Dec 5, 2015, 7:10:34 PM12/5/15
to
On 2015-12-05 23:53:09 +0000, Hans Vlems said:
> What was the command that produced this error?
Previous discussions:
> What was the command that produced this error?
https://groups.google.com/d/msg/comp.os.vms/sGIlWnxA8Pc/KNIYwMToA4EJ
https://groups.google.com/d/msg/comp.os.vms/CNb44Zcx3Fg/X0SBv2GARt4J
From the documentation, see the HELP/MESSAGE WRONGVU error messages and
recovery text,
and determine whether one of the usual triggers for that error is in play here.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
Dec 5, 2015, 7:13:42 PM12/5/15
to
On 2015-12-05 23:53:09 +0000, Hans Vlems said:
> What was the command that produced this error?
Or the shorter version: initialize the volume before adding it, and let
the shadow copy complete. Then MOUNT it elsewhere. See AG's answer
from the previous URLs.
Phillip Helbig (undress to reply)
Dec 6, 2015, 3:43:46 AM12/6/15
to
Phillip Helbig (undress to reply)
Dec 6, 2015, 3:44:34 AM12/6/15
to
In article <n3vu95$h7g$1...@dont-email.me>, Stephen Hoffman
why this error occurred but then stopped occurring before the shadow
copy was complete.
<seao...@hoffmanlabs.invalid> writes:
> https://groups.google.com/d/msg/comp.os.vms/sGIlWnxA8Pc/KNIYwMToA4EJ
> https://groups.google.com/d/msg/comp.os.vms/CNb44Zcx3Fg/X0SBv2GARt4J
>
> From the documentation, see the HELP/MESSAGE WRONGVU error messages and
> recovery text,
> and determine whether one of the usual triggers for that error is in play here.
As I mentioned, it appears to have been the third one. The question is
> https://groups.google.com/d/msg/comp.os.vms/sGIlWnxA8Pc/KNIYwMToA4EJ
> https://groups.google.com/d/msg/comp.os.vms/CNb44Zcx3Fg/X0SBv2GARt4J
>
> From the documentation, see the HELP/MESSAGE WRONGVU error messages and
> recovery text,
> and determine whether one of the usual triggers for that error is in play here.
why this error occurred but then stopped occurring before the shadow
copy was complete.
Michael Moroney
Dec 7, 2015, 1:38:25 PM12/7/15
to
Once the copy completed to the point where it overwrote the bogus SCB and
pointers to it, the MOUNT completed correctly.
0 new messages