VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide

[Jon Pinkley]

Ok, now that solution I was looking for has been disclosed, any comments are welcome from anyone, including the people I talked to about the method at bootcamp. In fact, I would welcome any feedback if you have thought of any additional potential problems.

If there aren't any, then I would suggest that the technique at least be mentioned in the upcoming update to the Volume Shadowing manual, as I do think it could be useful, especially for people that do not have controllers with snapshot/snapclone/split_mirror capability.

Jon

[Uwe Zessin]

> If you have an EVA and use it to snapshot a Windows disk,
> you won't be able to mount that disk on the same system
> without using a utility to change the signature
> (as far as I know it, this utility isn't part of stock
> windows server, just like DISKBLOCK isn't part of stock VMS.)

In Windows 2003, the re-signature is automatically done by "PartMgr" (see attachment). Whether new disks are automatically assigned a drive letter and mounted can be controlled with:
- mountvol /e|/n
- diskpart> automount enable|disable

[Wim Van den Wyngaert]

After the test I found that show dev d/bit on the my test node still marked the disk as having an active bitmap. This while operator log indicated "successful completion". This on VMS 7.3 with shadowing V2 (yes I know, not latest version).

It's not in 7.3 help but "delete/bit [bitmapid]" removes it.

So I checked all my nodes for active bitmaps.
1 node that 100% sure never had any /poli in dismounts commands had problems with it. The process and node went into hang. I crashed it and checked the dump. A lot of processes went into mutex. Well my fault (because not following the patches).

I also checked all com files for volnam : don't install'/upgrade stuff while doing this operation.

Wim

[Wim Van den Wyngaert]

Jon,

May be it would be a better idea if you could play with label id's of a disk without having to mount it and without losing the shadowing info. Admit that the solution you found is not "evident".

Wim

[labadie_1]

Jon

Thanks for the two nice teasers !

Gérard

[Jan van den Ende]

Jon,

>>>
But if it were possible to override the volume label, how could VMS protect itself from someone mounting the same disk via two different paths,
<<<

Well, that makes me curious.
I can not test this, but would this be possible, and have just THIS effect?


--
Shadowset
Change label
mount /sys (or /clus)

or just
mount/sys

and now effectively have uncoordinated doubly mounted drives?

At least the volume-label derived LNM will not be able to recognise that it should be prevented.

Yes, it is a constructed scenario, but I can envision unsufficiently trained sysmgrs in complicated situations doing things that amount to something like it.... :-(

Again, just curious (and perhaps over-cautious)

Proost.

Have one on me.

jpe

[Jon Pinkley]

Jan,

You must be going through a bad case of VMS withdraw. You need to load up Personal Alpha or another emulator so you can get a fix.

Your example is a bit too ambiguous for me to parse in a single way. Can you please add specific labels and device names in the example, so I can follow it in the way you are thinking of?

Shadow generation numbers and volume labels should be sufficient to protect as long as a member isn't modified with tools that allow the bladeguards to be removed (for example restoring an SCB after modifying the disk). If you mount a member of a shadowset without /nowrite, it will not be write enabled.

For example:

OT$ mou/sys $1$dga3584 data1_t1
%MOUNT-W-VOLSHDWMEM, mounting a shadow set member volume; volume write locked
%MOUNT-I-MOUNTED, DATA1_T1 mounted on _$1$DGA3584: (OMEGA)
OT$ sho dev disk$data1_t1

Device Device Error Volume Free Trans Mnt
Name Status Count Label Blocks Count Cnt
$1$DGA3584: (OMEGA) Mounted wrtlck 0 DATA1_T1 836416 1 1
OT$

Jon

[Jan van den Ende]

Jon

Shadowset DSA1 with members DKA1, 2, 3 mounted on SYSA & SYSB; label LAB1

SYSA> SET VOL DSA1 /LAB=KABOOM

SYSB> MOUN/SYS/OVER=SHAD DKA3: KABOOM

Note: DKA3: was __NOT__ dismounted!!

Can this (errenuously) be done, or will it generate an error?
ie, does the lock for LAB1 still block DKA3 from mounting systemwide with label KABOOM, or does this effectively achieve non-coordinated two-source access?

( of course, DK n is just a placeholder, I know real DK drives have 3-digit unit nrs)

Proost.

Have one on me.

jpe

[Wim Van den Wyngaert]

Jan,

Can not be done. Will say device already mounted.

Wim

[Wim Van den Wyngaert]

But what can be done :
on A :
set vol dsa0/lab=wim

on B :
dism disk2/pol=min=opt
mount/sys disk2 wim /nowr

So, the dismounted disk gets the label of node A, not node B (where it still is DISK1).

As the label is on the disk, I don't understand why the label must be set on each node. Jo(h)n ?

Wim