Hello Hari

Thank you for the reply.

Yes, it is possible to correct wrong duplicate veritas disk names. For example 
one cam remove disk.info file and
issue vxconfigd -k  to rebuild disk configuration. But it can be too late 
because of incorrect disk names errors. One of the disks suddenly gets failed 
for example. I want to keep this from happening.

With regards 
Pavel

>Hi

>When such name inconsistency occurs, you can run "vxddladm assign names" to 
>refresh the names without the need >to turn off naming persistence.

>With regards 
>Hari
-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of 
[email protected]
Sent: Friday, May 27, 2011 10:30 PM
To: [email protected]
Subject: Veritas-vx Digest, Vol 58, Issue 12

Send Veritas-vx mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Veritas-vx digest..."


Today's Topics:

   1. VMAX Auto-provisioning group devices & veritas ebn        naming
      scheme bug ([email protected])


----------------------------------------------------------------------

Message: 1
Date: Fri, 27 May 2011 16:25:57 +0400
From: <[email protected]>
Subject: [Veritas-vx] VMAX Auto-provisioning group devices & veritas
        ebn     naming scheme bug
To: <[email protected]>
Message-ID:
        <[email protected]>
Content-Type: text/plain; charset="utf-8"

 

Hello all!

 

The traditional symmaskdb technology was replaced with  Auto-provisioning 
Groups  (see Solution Enabler Symmetrix  Controls CLI 7.2)

 

Just noticed an interesting bug  when configuring veritas disks on thin devices 
combined in storage groups.   When adding a symdev A (thin device

for sample)  to the symmetrix storage group a new lun id is presented to the 
symdev A. When removing this symdev A from the storage group this lun id can be 
used by another newly added symdev B. When  giving back the symdev A to the 
storage group it is presented with the new lun id.  As a result Veritas  gets 
two identical ebn disk names which can lead to some very bad things.   There 
can be two workarounds:

1)      Using reserve lun id option for symdev on symmetrix storage group  to 
exclude any confusion about lun ids;

2)      vxddladm set namingscheme=ebn persistence=no use_avid=yes

 

I think the best option is number 2. But no sure about potential problems 
because of changing default persistence (=yes) meaning

 

Any suggestions?

 

Regards, Pavel Tsvetkov

 

P.S. about this option from man pages:

 

 

 

persistence

                         Specifies whether the names of disk dev-

                         ices  that  are displayed by VxVM remain

                         unchanged after disk hardware  has  been

                         reconfigured and/or the system rebooted.

 

               If persistence is on, the DDL assigns device names

               from  the  persistent device name database, rather

               than generating new names according to the OSN  or

               EBN naming scheme.

 

               If the naming scheme is OSN, name  persistence  is

               off by default. The generated names are not likely

               to differ from the names in  the  persistent  name

               database,  unless a change causes the OS to assign

               a new path name for a device.

 

               If the naming scheme is EBN, name  persistence  is

               on  by  default.  Certain configuration changes on

               the array side could cause the generated  name  to

               be  different from the name in the persistent name

               database. When name persistence is  on,  the  name

               from  the  persistent names repository is used for

               the DMP meta-device, unless

                the user changes it. .

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://mailman.eng.auburn.edu/pipermail/veritas-vx/attachments/20110527/1973c3cb/attachment-0001.htm
 

------------------------------

_______________________________________________
Veritas-vx maillist  -  [email protected] 
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx


End of Veritas-vx Digest, Vol 58, Issue 12
******************************************
_______________________________________________
Veritas-vx maillist  -  [email protected]
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
_______________________________________________
Veritas-vx maillist  -  [email protected]
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx

Reply via email to