Hi Jeffrey,
we had the same problem in multihomed environments if we forgot to configure the NetRestrict NetInfo files before starting the server. i used that procedure several times .. on modern hardware it takes less than 5 sec to finish. i wouldn't name that really outage and no user every complained about it.
May be there are smarter ways to do so, but it fixes the Problem for me and it's very quick.
I agree that if the NetInfo NetRestict isn't configured correctly and the ip still exists on the Server this wouldn't fix the Problem in long terms, but after he fixed his configuration, my procedure would clean his volume still exists problem ...
Sven
-------------------------------------------------------------------------------------------------------------------------
Dept. A141, TG/SSG EMEA AIS Strategy and Architecture
Development Leader Stonehenge
IBM intranet ---> http://w3.ais.mainz.de.ibm.com/stonehenge/
internet ---> http://www-5.ibm.com/services/de/its/filestore.html
Phone (+49)-6131-84-3151
Fax (+49)-6131-84-6708
Mobil (+49)-171-970-6664
E-Mail : [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote on 12/12/2004 01:16:30:
> On Saturday, December 11, 2004 03:00:16 -0500 Kenneth J Baker
> <[EMAIL PROTECTED]> wrote:
>
> > If I try to remove either of them I get the following error:
>
> You don't want to do that. What you're asking the vlserver to do is to
> remove the entire server, which it can't do because it knows about volumes
> on that server -- and which isn't what you want anyway.
>
> What you need to do is to get the fileserver to register the correct set of
> addresses. The fileserver registers its addresses on startup, based on the
> interfaces present and the contents of the NetInfo and NetRestrict files.
>
> If you want the 172.17 addresses to go away, you need to either make those
> interfaces go away (configuring them down may not be enough), or add those
> addresses to the NetRestrict files on the fileservers.
>
> > I investigated and it appears that the file servers themselves are using
> > only the correct interface: Sat Dec 11 02:37:00 2004 Getting FileServer
> > name...
> > Sat Dec 11 02:37:00 2004 FileServer host name is 'deedee'
> > Sat Dec 11 02:37:00 2004 Getting FileServer address...
> > Sat Dec 11 02:37:00 2004 FileServer deedee has address 66.92.68.189
> > (0xbd445c42 or 0x425c44bd in host byte order) Sat Dec 11 02:37:00 2004
> > File Server started Sat Dec 11 02:37:00 2004 ** **
> > Sat Dec 11 01:51:19 2004 Getting FileServer name...
> > Sat Dec 11 01:51:19 2004 FileServer host name is 'dharma'
> > Sat Dec 11 01:51:19 2004 Getting FileServer address...
> > Sat Dec 11 01:51:19 2004 FileServer dharma has address 66.205.64.240
> > (0xf040cd42 or 0x42cd40f0 in host byte order) Sat Dec 11 01:51:19 2004
> > File Server started Sat Dec 11 01:51:19 2004
>
> No; that's not what that means. The "Fileserver... has address" message
> tells you what the fileserver's primary address is; it does not indicate
> that no other addresses have been registered with the VLDB.
>
>
> Sven Oehme wrote:
> > just do the following per server :
> >
> > vos delentry -server 172.17.193.x
> > vos syncvldb servername
> > vos syncserv servername
> >
> > now the vos changeaddr 172.17.193.2 -remove -local should work ...
>
> No, don't do that. Not only will it result in a service outage during the
> time when you remove every volume on that server from the VLDB and the time
> when vos syncvldb puts them back, it also won't make your problem go away.
> As the output from 'vos listaddrs -printuuid' indicates, each server has
> both addresses. Removing and re-adding the volumes won't change the set of
> addresses associated with the server, and won't split the one server into
> two.
>
>
> -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]>
> Sr. Research Systems Programmer
> School of Computer Science - Research Computing Facility
> Carnegie Mellon University - Pittsburgh, PA
>
>
>
>
> _______________________________________________
> OpenAFS-info mailing list
> [EMAIL PROTECTED]
> https://lists.openafs.org/mailman/listinfo/openafs-info
