Hi James,

> does anyone know why vxvm won't recognize the different 
> cXtYdZ name, does it have a limit on the length of the Y?

You are correct, in vxvm the total name length can't exceed 32
characters. The Solaris leadville names can be longer than that and the
basic protection for vxvm was to use enclosure based naming whenever we
detected leadville names.

In SxRT 4.1 MP2 and 5.0 MP1, we are refining things a bit so that you
will be forced into enclosure based naming only if the cXtYdZ name of
that device actually is longer than 32 characters. Since there are many
situations where the name is 28 characters long or so, you would keep OS
based naming for these.

Thomas

 

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of James Zhao
> Sent: Friday, January 26, 2007 1:46 PM
> To: Darren Dunham; Veritas-vx@mailman.eng.auburn.edu
> Subject: Re: [Veritas-vx] Emulex lpfc driver to Sun emulxs 
> drivermigration and
> 
> Going a little bit further, I ran into problems initializing 
> vxvm disks under this situation, the cXtYdZ device (with the 
> Y as the backend FC WWN) name is rejected by vxvm, I  have to 
> change the naming method to use enclosure based names for the 
> disks and using the <enclosure
> name>_<disk_no>.
> 
> does anyone know why vxvm won't recognize the different 
> cXtYdZ name, does it have a limit on the length of the Y?
> 
> James Zhao
> [EMAIL PROTECTED]
> 
> 
> ----- Original Message -----
> From: "Darren Dunham" <[EMAIL PROTECTED]>
> To: <Veritas-vx@mailman.eng.auburn.edu>
> Sent: Friday, January 26, 2007 4:16 PM
> Subject: Re: [Veritas-vx] Emulex lpfc driver to Sun emulxs 
> driver migration and
> 
> 
> > > Our plan is to do a fresh install of Solaris 10 U3 and 
> VxVM 5.0 on the
> > > box and then import all the other disk groups when the 
> new system is up.
> > > Since Solaris 10 includes emulxs driver support for the 
> Emulex HBA's and
> > > it would change the disk names to the long naming format 
> (something like
> > > c1t5006048ACCD24CC0d86s2). I am wondering how this would 
> affect VxVM,
> > > and what would be the best way to proceed with the 
> changes? If anybody
> > > could point me to any documents that describes such situation, I'd
> > > appreciate it!
> >
> > In general, VxVM is immune to any sort of controller/drive 
> renumbering.
> >
> > As long as VxVM can "see" all relevant paths, it will discover the
> > storage on them, and understand their proper place within 
> the diskgroup.
> >
> > -- 
> > Darren Dunham                                           
> [EMAIL PROTECTED]
> > Senior Technical Consultant         TAOS            
> http://www.taos.com/
> > Got some Dr Pepper?                           San 
> Francisco, CA bay area
> >          < This line left intentionally blank to confuse you. >
> > _______________________________________________
> > Veritas-vx maillist  -  Veritas-vx@mailman.eng.auburn.edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
> >
> >
> > -- 
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.410 / Virus Database: 268.17.12/653 - Release 
> Date: 1/26/2007
> >
> >
> 
> _______________________________________________
> Veritas-vx maillist  -  Veritas-vx@mailman.eng.auburn.edu
> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
> 

_______________________________________________
Veritas-vx maillist  -  Veritas-vx@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx

Reply via email to