Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Missing avid based naming feature in SF5.1 SP1

Created: 07 Jun 2011 • Updated: 21 Jun 2011 | 1 comment
This issue has been solved. See solution.

Hello Everybody,

I'm missing a feature which was thrown out in Veritas Storage Foundation 5.1 SP1. As stated in the "Veritas Storage Foundation Release Notes":

Changes to DMP coexistence with native multi-pathing

The following limitations apply when using DMP with native multi-pathing:

■ DMP does not display extended attributes for devices under the control of the

native multi-pathing driver, MPxIO. Extended attributes include the AVID,

TP, TP_RECLAIM, SSD, RAID levels, snapshots, and hardware mirrors.

Where the missing AVID is hitting us pretty hard. This means for our Systems were we have up to 260 mapped luns that there is no more human readable sense in the Veritas disknames.

Before that Version we had names like MCH-usp0_2040 where "2040" is CU:ldev of HDS and therefor unique and easy to match with the underlying device. With SF 5.1 SP1 we have names like MCH-usp0_12 where "12" is just a counted number based on the serial number of the lun (which is the SAME number as the avid btw).

Also because of this we allready hit bug e2295359 which caused a massive data corruption. Quite sure this would not have been a problem if avid usage would still be there.

My question to Symantec:

When will this option come back to SF? Or are you serious to take this feature out if MPxIO is underlying device driver? It looks pretty much that this is done because of the ended partnership with Sun / Oracle.

If this feature will not com back into SF 5.1 we really have to think about NOT upgrading multiple systmes with sf enterprise to 5.1.

I'm looking forward for a solution on that.

 

Regards

Christoph

Comments 1 CommentJump to latest comment

Chad Bersche's picture

The device discovery within DMP provides a cross-platform, cross-array method to discover available LUN attributes.  When DMP is in complete control of the communications with the devices, we can be confident that another layer did not block or obfuscate our communications.  When additional layers are involved, interoperability is not guaranteed, and results in a more extensive component test matrix, most of which are not within Symantec’s control. 

As a result, it was determined that it best to not display these attributes where DMP was on top of the native pathing solutions.  It’s best not to provide data which we cannot guarantee, end-to-end, is 100% accurate.  This change was not made exclusively on Solaris, and our commitment to the platform remains unchanged. 

Additionally, as part of the 5.1SP1 release, DMP support for native volume manager and file systems was introduced, so visibility of the extended LUN attributes is possible by using DMP as the base multipathing driver.  DMP provides support for over 50 array families and 1000+ array models, and has a number of flexible and tunable I/O policies for differing workloads.

SOLUTION