You know, there seems to be a similar issue with filespace naming with the new Netware cluster aware client. We're awaiting a server upgrade to pursue it further. Seems as it the 'getservername' API call is at the heart of this.
David Rigaudiere wrote: > Yes, i have exactly the same problem with Windows & Double-Take, > i would like change the way that TSM nam the the filespacing naming > process. > > -- > David Rigaudiere -+- Administration TSM + NT > Paris -+- 40, rue de Courcelles -+- 4e �tage -+- > [EMAIL PROTECTED] -+- 01.5621.7802 > > |---------+---------------------------> > | | Peter Bjoern | > | | <pebjn@WMDATASDC| > | | .DK> | > | | Sent by: "ADSM: | > | | Dist Stor | > | | Manager" | > | | <[EMAIL PROTECTED]| > | | T.EDU> | > | | | > | | | > | | 11/12/2002 12:45| > | | Please respond | > | | to "ADSM: Dist | > | | Stor Manager" | > | | | > |---------+---------------------------> > >>--------------------------------------------------------------------------------------------------------------------------------| > | > | > | To: [EMAIL PROTECTED] > | > | cc: > | > | Subject: Question about Veritas Cluster and filespace name > | > >>--------------------------------------------------------------------------------------------------------------------------------| > > Hi > > We have a situation with a Veritas cluster installed on two Win2000 > servers. > The physical servers are called J2P-CLUSTER101 and J2P-CLUSTER102. > There is a virtual server defined with the name WEB1. > > Each physical server has it's own C: drive which is backed up via a > schedule > that specifies 'C:' and 'systemobject' on the domain statement in the > option file. > The C: filespaces are given the names \\J2P-CLUSTER101\C$ and > \\J2P-CLUSTER102\C$ respectively. This is all OK. > > There is a shared drive X: which is associated with the WEB1 resource and > moves with WEB1 between the two physical servers so that it is available > either on J2P-CLUSTER101 or J2P-CLUSTER102. > > X: is backed up from a virtual node defined in TSM called WEB1 and via a > separate TSM scheduler > service with an option file that specifies X: on the domain statement. > > If this had been a Microsoft Cluster installation, we would have specified > 'CLUSTERNODE YES' in the optionfiles to make TSM name the X: filespace > with the virtual clustername (WEB1) so that it would have been named > \\WEB1\X$ regardless of which physical server it was backed up from. > > However, CLUSTERNODE does not work with a Veritas cluster, so the result is > that we get two parallel filespaces named \\J2P-CLUSTER101\X$ and > \\J2P-CLUSTER101\X$ because X: sometimes resides on J2P-CLUSTER101 > and some times on J2P-CLUSTER102. > > From previous postings on this list I get the impression that there is > nothing > we can do to solve this, but I just want to be sure if this is true.... > > How are other people who are running Veritas clusters and TSM solving this > ? > > This is a bad situation and one could fear (from a TSM person point of > view) that > it could pave the way for the introduction of Veritas backup software at > the site. > > If CLUSTERNODE cannot easily be enhanced to support Veritas clusters as > well, all we would need would be a new statement in the option file, > perhaps called > MACHINENAME or so, where we could specify 'MACHINENAME WEB1' in the > optionfile and then have TSM use this name is the filespacing naming > process. > > Regards > > Peter > > --------------------------------------------------------------------------- > This message (including any attachments) is confidential and may be > privileged. If you have received it by mistake please notify the sender by > return e-mail and delete this message from your system. Any unauthorised > use or dissemination of this message in whole or in part is strictly > prohibited. Please note that e-mails are susceptible to change. > ABN AMRO Bank N.V. (including its group companies) shall not be liable for > the improper or incomplete transmission of the information contained in > this communication nor for any delay in its receipt or damage to your > system. ABN AMRO Bank N.V. (or its group companies) does not guarantee that > the integrity of this communication has been maintained nor that this > communication is free of viruses, interceptions or interference. > --------------------------------------------------------------------------- > > Le pr�sent message (y compris tous les �l�ments attach�s) est confidentiel > et est destin� aux seules personnes qu'il vise. Si vous l'avez re�u par > erreur, merci de l'indiquer � son exp�diteur par retour et de proc�der � sa > destruction dans vos syst�mes. Toute utilisation ou diffusion non autoris�e > de son contenu, dans sa totalit� ou en partie, est strictement interdite. > Merci de noter que les e-mails sont susceptibles d'�tre alt�r�s. ABN AMRO > Bank N.V. (et les entit�s membres du Groupe ABN AMRO) ne saurait �tre tenu > pour responsable ni de la transmission erron�e ou incompl�te des > informations contenues dans ce message, ni des d�lais de r�ception ou des > dommages caus�s � votre syst�me. ABN AMRO Bank N.V. (et les entit�s membres > du Groupe ABN AMRO) ne garantit ni que l'int�grit� de la communication ait > �t� maintenue ni que cette transmission soit exempte de virus, > d'interceptions ou d'interf�rences. -- Jim Kirkman AIS - Systems UNC-Chapel Hill 966-5884
