Hari Vemuri
2011-05-28 06:21:47 UTC
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: veritas-vx-***@mailman.eng.auburn.edu [mailto:veritas-vx-***@mailman.eng.auburn.edu] On Behalf Of veritas-vx-***@mailman.eng.auburn.edu
Sent: Friday, May 27, 2011 10:30 PM
To: veritas-***@mailman.eng.auburn.edu
Subject: Veritas-vx Digest, Vol 58, Issue 12
Send Veritas-vx mailing list submissions to
veritas-***@mailman.eng.auburn.edu
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
veritas-vx-***@mailman.eng.auburn.edu
You can reach the person managing the list at
veritas-vx-***@mailman.eng.auburn.edu
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 (***@inform.gazprom.ru)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 May 2011 16:25:57 +0400
From: <***@inform.gazprom.ru>
Subject: [Veritas-vx] VMAX Auto-provisioning group devices & veritas
ebn naming scheme bug
To: <veritas-***@mailman.eng.auburn.edu>
Message-ID:
<***@MAIL.adm.gazprom.ru>
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 - Veritas-***@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
End of Veritas-vx Digest, Vol 58, Issue 12
******************************************
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: veritas-vx-***@mailman.eng.auburn.edu [mailto:veritas-vx-***@mailman.eng.auburn.edu] On Behalf Of veritas-vx-***@mailman.eng.auburn.edu
Sent: Friday, May 27, 2011 10:30 PM
To: veritas-***@mailman.eng.auburn.edu
Subject: Veritas-vx Digest, Vol 58, Issue 12
Send Veritas-vx mailing list submissions to
veritas-***@mailman.eng.auburn.edu
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
veritas-vx-***@mailman.eng.auburn.edu
You can reach the person managing the list at
veritas-vx-***@mailman.eng.auburn.edu
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 (***@inform.gazprom.ru)
----------------------------------------------------------------------
Message: 1
Date: Fri, 27 May 2011 16:25:57 +0400
From: <***@inform.gazprom.ru>
Subject: [Veritas-vx] VMAX Auto-provisioning group devices & veritas
ebn naming scheme bug
To: <veritas-***@mailman.eng.auburn.edu>
Message-ID:
<***@MAIL.adm.gazprom.ru>
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 - Veritas-***@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
End of Veritas-vx Digest, Vol 58, Issue 12
******************************************