[Info-vax] "cloning" disks initially, after upgrades, after patches

[Phillip Helbig---undress to reply]

I asked a similar question somewhat more briefly here a while back but
got surprisingly little response.  There must be many other folks with 
multiple system disks who want to save time and effort.

For about 10 years now, I've had a cluster consisting of an ALPHA and 
two VAXes.  Since VAX software is relatively, err, stable, I didn't 
worry about the extra work of patching two system disks whenever there 
were new patches.  I originally created one disk as a copy of the other, 
also about 10 years ago, then "changed the node name".  I think I did 
only one upgrade after that, to 7.3, and did it to both system disks 
separately.

Soon, I hope to replace the VAXes with ALPHAs.  This will mean more
frequent upgrades and patches (assuming I can somehow get access to
patches in the future) and also creating new system disks as a copy of
the existing ALPHA system disk.  (I don't want to do a fresh 8.3
install, since that is much more work installing LPs etc.  I also want
to go to a 3-node 7.3-2 cluster first, since I am familiar with that,
then upgrade to 8.3 later, rather than upgrading first then replacing
the VAXes with ALPHAs.) 

So, we have 3 situations: 

   A  create a new system disk as a modified copy of an old one

   B  propagate an upgrade from one disk to another

   C  propagate patches from one disk to another.  

I see 3 possibilities for saving time (the zeroth possibility would be
to create each disk from scratch and also upgrade and patch each disk
individually) in each of these situations: 

   1  copy the modified disk and "change the node name"

   2  have all SYS$SPECIFIC trees for all nodes on all disks and keep
      them in sync; after modification, just bring them back to sync
      and boot each system from its appropriate root

   3  copy files resulting from the upgrade/patch or just the highest
      version of each file from the modified disk to the other disks
      (the former is more logical but it might be difficult to determine
      the affected files; neither strategy will delete any files)

So, we have nine scenarios.

A1 has been discussed here over the years and is probably described in a 
FAQ somewhere.  I'll have a look.

A2 is related to stuff which SYS$MANAGER:CLUSTER_CONFIG.COM can do:

   3. CHANGE a cluster member's characteristics.
   4. CREATE a duplicate system disk for GLADIA.
   5. MAKE a directory structure for a new root on a system disk.

However, I suspect that this doesn't cover everything (e.g. TCPIP).  (Of
course, the idea here is to first set up the new root then copy the 
entire disk.)  Also, there is the warning:

    WARNING: This option is for advanced users who have manual procedures
    for completing operations that are not performed by this option.

so one can't just use it out of the box anyway.

A3 is really equivalent to A1 since it would copy all files. 

So, for A, A1 is the only practical option, as far as I can tell.

If A1 works, then so will B1 and C1, but B1 and C1 seem like overkill to 
me.

If we assume that the difference between B and C is primarily 
quantitative and not qualitative, then it is enough to discuss just one, 
say B.

B2 looks to me like it should work for traditional VMS stuff.  After
all, it is no problem to boot more than one node from a given disk 
(either directly or as a satellite), so booting it from a copy of the 
same disk on another node shouldn't make any difference.  However, I am 
worried that this won't work out of the box with respect to TCPIP.  On 
the other hand, I have a satellite which boots from the same disk as its 
boot server, and each has its own personality, including TCPIP.  Can 
anyone shed some light on this?  The only disadvantage to this scheme is 
the necessity of keeping all roots on all disks in sync.

B3 is essentially what one does when upgrading software which is not 
from DEC/Compaq/HP and not on the system disk: just update the 
executable and shareable images, install the latter if necessary and one 
is ready to go.  However, it is probably non-trivial to generate a list 
of affected files, and copying the highest version of each file would be 
overkill.  Either would involve less copying than B2, though.

How do folks here deal with A, B and C?

In any case, of course, one needs to make sure before starting any 
copying that stuff is in SYS$SPECIFIC or SYS$COMMON, as appropriate, 
since both will work on a one-node disk.

It looks to me like the best path to take would be A1 for initially
cloning then modifying the disk, then B2/C2, assuming that this would
work for TCPIP etc.  I'm pretty sure that C2 would not affect SYS$
SPECIFIC (thus there would be no node-specific results); what about B2?

I seem to recall that the node name is somewhere in the PCSI database, 
though no PCSI stuff seems to be in SYS$SPECIFIC.