> [ Rick Cochran had written regarding vldb strangeness... ]
>
> Hm. Our AFS db servers (umich.edu production cell) don't even *have*
> a /usr/afs/local/sysid file. I can't find any mention of such a file
> in our copy of the AFS source either. What's in it? Any idea what uses
> it? What version of AFS are you running anyways? What version of AIX?
That's a 3.4-ism, created to help support multi-homed fileservers. The
idea is that each server registers all it's IP addresses with the VLserver,
which can then pass that info on to clients so they know about multi-homed
servers. The problem he had, probably, was that he changed a machine's
name and IP address, but didn't remove the sysid file (thus forcing it to
reregister itself). As a result, things got confused. I don't understand
all the mechanics, but I can see how this might be a problem.
> If I were doing such a move, there are about two possibilities:
>
> (1) the 530 & C20 are running the same revision of the OS, and can
> understand the same physical filesystem.
>
> In this case, what I'd do would be to
> configure the C20 as a "blank" fileserver/db server.
> all fileserver binaries, empty db files.
> shut the 530 down
> attach & configure the drive to the C20
> configure the C20 to the same IP address
> as the 530
> bring it up. The db files should be automatically
> propogated to the C20 from other DB servers,
> and the fileserver should be happy.
> The win here is that by reusing the same drive & physical
> files, the whole process could be quite quick.
> Based on your experience, of course, I'd wonder if this was
> entirely right. Perhaps there's something strnage
> in those "uuid"s in the latest vldb format that isn't
> quite kosher.
It should be possible to do exactly this, assuming the filesystems
are compatible. Of course, if they really can run the same OS,
then this becomes even simpler - just move the system disk along
with server partitions. However, I suspect he didn't do this;
probably he did something similar to your option 2.1:
> (2) the 530 & C20 aren't filesystem compatible. Two options here.
>
> Option 1. (if you have a spare disk)
> shut the 530 down.
> use "vos changeaddr" to change the IP address
> of the 530 in the vldb to something temporary.
> change the 530's IP address, & restart it.
> configure the C20 as a "blank" fileserver/db server.
> all fileserver binaries, empty db files.
> install a new empty disk on the C20
> give the C20 the the DB IP address.
> bring the C20 up.
> db files will propagate from the other servers.
> Use "vos move" to move everything from the
> 530 to the C20.
> shut the 530 down.
The variation I usually use is something like:
- bring up the new machine as an ordinary fileserver
- move all the volumes
- decomission the old dbserver/fileserver
- change the new machine's name/address
- when it comes up, it will get up-to-date DB files automatically
- Use 'vos syncvldb' and, if necessary, 'vos syncserv' to clean up.
Your method seems to be rather cleaner, though.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
Systems Programmer, CMU SCS Research Facility
Please send requests and problem reports to [EMAIL PROTECTED]
