Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

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

 
SOLVED
Go to solution
Jon Pinkley
Honored Contributor

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

VMS Puzzle #2: Using HBVS to allow read-only snapshot to be used system wide without preventing a minicopy when the removed member is reintroduced into the shadow virtual unit.

This is a VMS brainteaser, similar in spirit to the one I posted on Christmas, Dec 25, 2007 08:45:03 GMT (not a real problem, since I know the answer).

Problem: You want to make a static snapshot of a disk prior to some testing that will modify a small portion of the shadowset virtual unit (DSA) disk. You want to be able to mount the snapshot (removed SSM) /system /nowrite so it can be used as a reference copy of the state prior to the test. You have a shadowing license and available disks, and want to use HBVS to remove a member for the static copy. Since only a small portion of the shadowset virtual unit disk will be changing, you want to be able to use minicopy to return the snapshot member to the virtual unit, thus avoiding a full shadowcopy operation to bring the member back to synchronization with the shadow virtual unit.

Summary: A shadowset member (SSM) is removed, and then without dismounting the original shadow virtual unit (DSAxxx:), how can the removed SSM be mounted /system while still allowing the removed member to be returned to the shadowset with a minicopy instead of a full copy?

I will award points when the solution has been disclosed. I will post a logfile showing an example of the method.

P.S. I suggest you try any solution before you post it, as if a proposed solution does not work, I will post a log showing any errors encountered. The method I discovered should work with any version of shadowing supporting the minicopy operation (I have tested with 7.3-2 with the HBMM patch, but it should not rely on enhancements in that patch).

Perhaps someone else has discovered the method, but I have never seen or heard of it. I talked with three VMS engineers at bootcamp that have worked on the HBVS, and they were not aware of the technique either.

If I discussed this with you at bootcamp, please don't disclose the answer, so others will have a chance.
it depends
28 REPLIES 28
Jan van den Ende
Honored Contributor

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

Jon,

having NO system available at the moment, this will be only a mental operation. What I would do, is take out one member, make a (physocal) backup thereoff, rejoin the talen out member. Then mount the backup copy privately, change its volume label, and mount it system (cluster-) wide,
And I would spend some time in setting up the concealed devices to make the (relevant parts of) the snapshot transparantly available.

There may well be a more elegant/quicker solution, in which case I am curious & interested!

Proost.

Have one on me.

jpe
Don't rust yours pelled jacker to fine doll missed aches.
Uwe Zessin
Honored Contributor

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

I don't have a system available, either, but I would change the volume label and clear the shadow generation number, too.

If I remember correctly, this is all located in the storage control block. So you might even be able to mount the volume /FOREIGN, save the block with a simple DCL READ, update with a WRITE - I assume you know the SCB layout, of course ;-).

That should give the disk a new identity which allows a system-wide MOUNT/NOWRITE.

When you want to put the disk back into the shadow-set, dismount it, restore the SCB and MOUNT/...
.
Jon Pinkley
Honored Contributor

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

-----------------------
RE: Physical backup of removed member.

Yes, that would work and allow the removed member to be returned to the shadowset without a full copy. But it still requires a lot of I/O to make the physical backup, if the device is large. That's not the answer I was looking for.
-----------------------
RE: Saving and restoring the SCB.

The disk label is stored in the HOMEBLOCK, what is stored in the SCB is the volume lock name which normally is the same as the label.

It is possible to do something close to what Uwe suggested, but there is a much easier and less error prone way.

If you are interested is how that can be done, I have attached a logfile doing this using the freeware DISKBLOCK program, but it is not supported, and there is an easier way that doesn't do anything in an unsupported manner.

This isn't the method I am referring to. My method is much easier and uses fully supported operations that don't involve lying to the VMS shadowing software, which is essentially what restoring the SCB is doing (it is telling the shadowing software that nothing has changed on the volume, when in fact it has).
-----------------------
Ok, ready for round two. (As stated before, I will award points when I close the issue).

Jon
it depends
Wim Van den Wyngaert
Honored Contributor
Solution

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

Tested it and it works but your system may not depend on a fixed label :

set env/clu
do set vol dsa1/lab=wim

dism disk1/poli=min=opt

set env/clu
do set vol dsa1/lab=disk1

mount disk1 wim/sys/nowr

dism disk1

set env/clu
do set vol dsa1/lab=wim

mount dsa1 wim/sys/shadow=disk1

set env/clu
do set vol dsa1/lab=disk1

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

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

Here is the full log in enclosure.

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

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

BTW : it would be a nice improvement for VMS (probably in a version I will never use) if one could mount the disk whatever the label. Just like when you do when mounting a disk without /sys.

Wim
Wim
Robert Brooks_1
Honored Contributor

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

BTW : it would be a nice improvement for VMS (probably in a version I will never use) if one could mount the disk whatever the label.

--

$ MOUNT /OVER = ID

tends to work rather well for me . . .


-- Rob
Jon Pinkley
Honored Contributor

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

Wim,

Yes, that is the method, assuming the original volume label in your example (May 26, 2008 14:50:46 GMT) was disk1 to begin with.

As Wim described, the "trick" is to change the volume label of the shadowset VU BEFORE the member is removed, then remove the member with /policy=minicopy, then change the label of the DSA Virtual Unit (VU) back to its original label. Now the removed SSM can be mounted /system (or /cluster) and since its SCB knows it was a shadow set member, the member is automatically mounted software write locked. When it is time to return the member to the shadow set, the VU's label must be changed back to the label it was when the member was removed. Otherwise, the minicopy bitmap won't be used. So there are two short periods of time when the volume label in the shadowset's HOMEBLOCK will be different than its original value, but these can be short windows of time, and very few things rely on the volume label. The logical name created by mount, f$getdvi(disk,"LOGVOLNAM"), does not change when the disk volume label is changed, so only things paying attention to f$getdvi(disk,"VOLNAM") would see the changed volume name. It is not necessary to wait for the minicopy to complete before changing the label back to its original value, so the duration of the changed label can be quite small. However, if you do have software that is looking at the actual label, it is possible that it will see the value of the label during the short period when it was changed. And if the system crashes during that window, the mount commands using the old labels will fail.

Other than the original label changing for these two short durations, I am not aware of any downsides to this method. If you absolutely can't change the volume label on the VU, then I am not aware of any supported way to get the removed member back into the shadowset without a full copy. In my previous attachment, I show a way this can be done (as an academic example), but it involves restoring the SCB, and that should be avoided if your data is important.

Since you can have up to six minicopy bitmaps per VU, and minicopy bitmaps are currently single mastership, you can have multiple snapshots active at the same time, each taken at different times. So you could for example have periodic rotating snapshots, where each member would be brought back into the shadowset with a minicopy before being removed again.

I am attaching notes I made in January, 2008.

If anyone is interested, I can attach some additional log files giving more details about why this method works, and show more details from SDA, DISKBLOCK and LDDRIVER traces. But if you really want to understand how it works, there is no substitute for doing some experiments yourself. LD devices are great for this, as they don't need to be big, and if you have to do a full copy, it still won't take a long time.

If you do the experiments, I suggest looking at the SCB and homeblock before and after a set volume/label and before and after removing a shadowset member. Grab the DISKBLOCK utility off the freeware. As long as you use

DISKBLOCK> select/nowrite device_name

then it should be reasonably safe. And before using it, read the help. DISKBLOCK knows how to format the SCB and how to find it, so it is reasonably easy to use for that purpose. See my previous attachment for some examples.

The SCB in the removed member still has the original volume lock name, but since this is a read only volume, the volume lock name in the SCB is never updated. Changing the label in the homeblock is sufficient to have mount create a new volume lock name

Would anyone be interested in a VMS Technical Journal article showing how this works, the SCB fields involved, that HOMEBLOCK fields involved, etc.?

I would be interested in hearing any downsides to doing this. Specifically what problems can changing the Shadow VU's volume label cause?

Note: if your purpose is just for backup and not for an online reference copy, you probably don't want to use this method, since the label has been changed. The backup process can just mount the removed member privately, so there shouldn't be a problem if it has the original label.

Jon
it depends
Jon Pinkley
Honored Contributor

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

Hi Rob,

It was nice meeting you face to face at bootcamp.

Concerning Wim's comment about the label, I am quite sure he meant it would be nice if you could mount/system any disk you can mount privately. I.e. I think he would like to be able to mount multiple shared volumes with the same label without getting a %MOUNT-F-VOLALRMNT error.

Wim,

What problem are you trying to solve by allowing multiple shared volumes to have the same label? Windows write "signatures" to the disks to prevement multiple instances from being mounted at the same time, and this is in my opinion, at least as restrictive as what VMS does. At least VMS allows you to easily change the label. 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.)

Allowing multiple shared volumes with the same label to be mounted in the cluster would require a redesign of the way things work, i.e. there isn't an easy general solution I can think of. VMS needs something unique that can be used as the volume lock name, and in the case of a shared volume, there are many reasons that this something needs to come from the media. and that something is the volume label. In the case of a read-only volume mounted privately, VMS creates a volume lock name from the SCSNODE name and S0 (system) address of the device's UCB, a combination that is guaranteed to be unique for the node/device. I suppose it would be possible to provide a way to specify a volume lock name for $MOUNT to use, and have that be what got loaded into the VCB. 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, for instance when allocation classes are configured incorrectly? Allowing it for read-only access may be safe, but this is just off the top of my head, so I am probably overlooking many other issues.

Jon
it depends
Jon Pinkley
Honored Contributor

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

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
it depends
Uwe Zessin
Honored Contributor

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

> 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
Honored Contributor

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

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
Wim Van den Wyngaert
Honored Contributor

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

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

Wim
labadie_1
Honored Contributor

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

Jon

Thanks for the two nice teasers !

Gérard
Jan van den Ende
Honored Contributor

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

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
Don't rust yours pelled jacker to fine doll missed aches.
Jon Pinkley
Honored Contributor

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

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
it depends
Jan van den Ende
Honored Contributor

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

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
Don't rust yours pelled jacker to fine doll missed aches.
Wim Van den Wyngaert
Honored Contributor

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

Jan,

Can not be done. Will say device already mounted.

Wim
Wim
Wim Van den Wyngaert
Honored Contributor

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

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
Wim
Wim Van den Wyngaert
Honored Contributor

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

Mmmm. So the disk got mounted under WIM. But then I put it back into the shadow set with label DISK1 witout any options. It was accepted !!! The disk had not been mounted write since the dismount but still a full copy was started (no mini). But again, on my old 7.3 node.

Detail : the shadow_server doing the copy was on the node that did the mount.

Wim
Wim
Ian Miller.
Honored Contributor

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

The VTJ editor is always looking for material so do contact her about this possible article.
____________________
Purely Personal Opinion
Jon Pinkley
Honored Contributor

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

Uwe,

Thanks for the info, I am not the Windows admin. I know it was a problem when we first started using the EVA, and we had to find a work around. We now have Windows Server 2003, so our admin is probably aware of the new functionality, but I will make sure he is.

Wim,

No time for details now, but here is my current understanding (I need to do more testing and research to know for sure, so be warned that this is my guess).

The label is changed in the HOMEBLOCK when the set volume/label is executed. The VCB (Volume Control Block) is an in memory copy of volume related info, and it is created at mount time and the values in it come from the HOMEBLOCK (and probably the SCB). My guess is that the VCB is the source of info that $GETDVI uses (and where show device gets its info). When you do a set volume, the VCB on the node where the command is executed is updated with the new value, but evidently there is no "cluster" updating done. The same is true for things like volume retention times, and logical volume size.

That does bring up a question about where the shadow server gets the volume label for its comparison with the write bitmaps, since the copy operation doesn't have to occur on the node that originally mastered the minicopy bitmap.

For the tests I did, I was using a test cluster with a single node. I will put another node in and do some additional tests, but I have to do some other things first, since I was at Nashua for two weeks.

I also used mount /policy=minicopy to ensure the copy was in fact a minicopy. That is supposed to ensure that the minicopy is used, or the mount will fail. And that's how I determined that the labels have to match for the minicopy to happen.

Jon
it depends
Wim Van den Wyngaert
Honored Contributor

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

Jon,

Could you do on your test system :
dsa0=disk1, disk2 label "D1"
dsa1=disk3 label "D2"

set vol dsa0 /lab=WIM
dism/pol=min=opt disk2
set vol dsa0 /lab=D1

set vol dsa1 /lab=WIM
mount dsa1/sys /shad=disk2

I wonder if it will get accepted and if it will do the minicopy but can't test that on my system due to lack of disks.

Wim

Wim
Wim Van den Wyngaert
Honored Contributor

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

I did the test myself and found that the disk is accepted witout any /over. Without minicopy.

I dismounted it again and could add it to the original dsa witout any /over. Without minicopy.

Wim
Wim