Re: [Veritas-vx] /etc/vx/disk.info file

[Thomas Cornely]

Hi John,

In general, the best practice when it comes to name persistency depends
on the namingscheme you are using. If you use EBN (Enclosure Based
Naming), then it is typically recommended to have persistency on. If you
use OSN (OS Based Naming) on the other hand, you're better off turning
persistency off.

Setting the naming scheme to OSN with no persistence can be done
through:
vxddladm set namingcheme=osn persistence=no 

Thanks,

Thomas

 
Thomas Cornely
Sr. Product Manager - Dynamic Multi-Pathing (DMP)
Veritas Storage Foundation for UNIX & Linux
Data Center Management Group (DCMG)
Symantec Corporation
www.symantec.com


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of John Kennedy
> Sent: Friday, October 12, 2007 3:00 AM
> To: Veritas-vx@mailman.eng.auburn.edu
> Subject: [Veritas-vx] /etc/vx/disk.info file
> 
> I have a customer using VxVM on SLES9 SP3. They have the following
> question:
> 
> Feasibility/Desirability of disabling to prevent Veritas disk 
> permanence?
> 
> For preventing Veritas disk permanence, I am referring to the 
> /etc/vx/disk.info file, which will make a disk always show up 
> in vxdisk -o alldgs list (ie, vx config) as same device name, 
> even if, say on Egenera, you re-order the disks. This makes 
> it difficult to track the physical disks, because you have to 
> remember to compare vxdisk -e -o alldgs list OS_NATIVE column.
> 
> 
> My concern is: Is there any valid reason for us to have this "feature"
> supported in our OS's? Is there any gain to offset problems 
> caused by re-ordering of devices resulting in difficulty 
> tracking devices?
> 
> I have a feeling I know the answer to this (that 
> /etc/vx/disk.info MUST exist and they can delete and recreate 
> with vxconfigd -kr reset) but I want to be sure.
> 
> Thanks,
> John Kennedy
> --
> Regards,
> John Kennedy
> Dedicated Support Engineer
> [EMAIL PROTECTED]
> UK - +44 (0) 1344 326 054
> UK Mobile - +44 (0) 7802 357 030
> US - 1 801 861 5340
> 
> Novell, Inc.
> SuSE Linux Enterprise 10
> Your Linux is ready
> http://www.novell.com/linux
> 
> 
> ___
> 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

Re: [Veritas-vx] DMP question

[Thomas Cornely]

Sengor, Ajay,

There's an updated version of the DMP whitepaper (covering the latest 5.0 
enhancements) at:
http://eval.symantec.com/mktginfo/enterprise/white_papers/ent-whitepaper_vsf_5.0_dynamic_multi-pathing_05-2007.en-us.pdf

As far as load balancing is concerned, DMP has historically outperformed PP. 
The names of the PP algorithms really is more marketing than anything else. If 
you have a chance, try out DMP 5.0's Minimum Queue algorithm and compare.

Thomas
 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Sengor .
> Sent: Wednesday, October 31, 2007 9:10 PM
> To: robertinoau
> Cc: ajay raghuraj; veritas-vx@mailman.eng.auburn.edu
> Subject: Re: [Veritas-vx] DMP question
> 
> VxDMP and PP can co-exist on the same server:
> 
> http://eval.veritas.com/mktginfo/products/White_Papers/Storage
> _Server_Management/sf_dmp_wp.pdf
> 
> PP has EMC specific load balancing algorithms specific to 
> their arrays. I believe ASL's for EMC arrays do not have 
> array specific optimised versions of load balancing.
> 
> On 11/1/07, robertinoau <[EMAIL PROTECTED]> wrote:
> >
> > You are running PowerPath, therefore what you are seeing is 
> 100% correct.
> >
> > Remove powerpath and install the ASL for you array if you want DMP.
> >
> >
> > - Original Message 
> > From: ajay raghuraj <[EMAIL PROTECTED]>
> > To: veritas-vx@mailman.eng.auburn.edu
> > Sent: Wednesday, 31 October, 2007 9:59:17 PM
> > Subject: [Veritas-vx] DMP question
> >
> >
> > Hi,
> >
> > It looks like multipathing is missing . But I am not sure 
> where it is 
> > enabled . Is it in veritas / powerpath / native as this is 
> Sol 10. On 
> > Sol 10 how do we check multipathing as been enabled or not ? Is it 
> > some option with stmsboot ?
> >
> > Secondly if I have to enable it in veritas , how do i do it 
> ? and how 
> > do I verify ?
> >
> > vxdmpadm listctlr all
> >
> > CTLR-NAME   ENCLR-TYPE  STATE  ENCLR-NAME
> > =
> > emcpEMC ENABLED  EMC0
> > c4  EMC DISABLED EMC0
> > c3  EMC DISABLED EMC0
> > c1  DiskENABLED  Disk
> > c4  EMC ENABLED  EMC1
> > c3  EMC ENABLED  EMC1
> >
> > vxdisk -g mifd_prd_oradg list emcpower18s2
> >
> > Multipathing information:
> > numpaths:   1
> > emcpower18c state=enabled
> > vxdisk -o alldgs list
> > .
> > .
> > .
> > EMC1_17  auto--error
> > EMC1_17  auto--error
> > EMC1_17  auto--error
> > .
> > .
> > emcpowerXX
> > emcpowerxy
> > emcpowerxz
> >
> > Regards,
> > Ajay
> >
> >
> >  
> >  Feel safe with award winning spam protection on Yahoo!7 Mail. Find 
> > out more.
> > ___
> > Veritas-vx maillist  -  Veritas-vx@mailman.eng.auburn.edu 
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
> >
> >
> 
> 
> --
> _/ sengork.blogspot.com /
> 
> ___
> 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

Re: [Veritas-vx] Remove rootmirror disk to patch solaris os ?

[Hudes, Dana]

While you could do a root mirror break-off, I'd rather use Live Upgrade
with Solaris. That way you build up the new boot environment and then
boot onto it. If you want to patch, you use LU and the same OS level on
both sides. Then you patch the inactive boot environment from the active
BE, then activate the other BE and reboot onto it. 

 

=

Dana Hudes

UNIX and Imaging group

NYC-HRA MIS

+1 718 510 8586

Nextel:  172*26*16684

=

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Romeo
Theriault
Sent: Thursday, November 01, 2007 3:21 PM
To: veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] Remove rootmirror disk to patch solaris os ?

 

Hello, I've read a few places on the internet that a fairly easy and
straight forward way to safetly break your rootdisk  mirroring for
purposes of patching the Solaris OS, is to turn off your machine and
remove your root-mirror drive from the machine. Boot off of your
rootdisk, do your patching and if everything goes ok, put your
rootmirror drive back in the machine, vxattach it back into the mirror.
If the patching fails for some reason power down the machine, remove the
rootdisk drive put in the rootmirror drive and boot then put the
rootdisk drive and have it resync off of the rootmirror disk.

Is this a supported way of rolling back from patching?  Is there any
documentation that thoroughly describes the process?

It certainly seems much easier than the documenation I've read from
Symantec that explains how to remove the rootmirror entirely from a
software level.

Thank you for any pointers in this matter.

Romeo

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

[Veritas-vx] Remove rootmirror disk to patch solaris os ?

[Romeo Theriault]

Hello, I've read a few places on the internet that a fairly easy and
straight forward way to safetly break your rootdisk  mirroring for purposes
of patching the Solaris OS, is to turn off your machine and remove your
root-mirror drive from the machine. Boot off of your rootdisk, do your
patching and if everything goes ok, put your rootmirror drive back in the
machine, vxattach it back into the mirror. If the patching fails for some
reason power down the machine, remove the rootdisk drive put in the
rootmirror drive and boot then put the rootdisk drive and have it resync off
of the rootmirror disk.

Is this a supported way of rolling back from patching?  Is there any
documentation that thoroughly describes the process?

It certainly seems much easier than the documenation I've read from Symantec
that explains how to remove the rootmirror entirely from a software level.

Thank you for any pointers in this matter.

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

Re: [Veritas-vx] Remove rootmirror disk to patch solaris os ?

[A Darren Dunham]

On Thu, Nov 01, 2007 at 03:21:01PM -0400, Romeo Theriault wrote:
> Hello, I've read a few places on the internet that a fairly easy and
> straight forward way to safetly break your rootdisk  mirroring for purposes
> of patching the Solaris OS, is to turn off your machine and remove your
> root-mirror drive from the machine. Boot off of your rootdisk, do your
> patching and if everything goes ok, put your rootmirror drive back in the
> machine, vxattach it back into the mirror. If the patching fails for some
> reason power down the machine, remove the rootdisk drive put in the
> rootmirror drive and boot then put the rootdisk drive and have it resync off
> of the rootmirror disk.
> 
> Is this a supported way of rolling back from patching?

Hmm.  Supported by who?

I'd have to guess that Veritas/Symantec "supports" what VxVM does when
you lose a disk (which is what it looks like if you pull a disk while
the power is off).

> Is there any
> documentation that thoroughly describes the process?

No one document that I'm aware of.

The fact that you happen to be patching or otherwise modifying the data
on the machine during the period is irrelevant to VxVM.  It's just
managing a machine that has suddenly lost a disk.

> It certainly seems much easier than the documenation I've read from Symantec
> that explains how to remove the rootmirror entirely from a software level.

Yes, because you're not removing the rootmirror.  It remains in the
configuration.  In fact, you're explictly causing a "split-brain"
condition in some sense, because you have two copies of the DG database
that are inconsistent.  But because you only have one disk in the
machine at a time (until you're ready to sync up), this isn't noticed.

This is very difficult to accomplish with some hardware due to the
difficulty of removing or powering off a single disk.  

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://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

Re: [Veritas-vx] Remove rootmirror disk to patch solaris os ?

[A Darren Dunham]

On Thu, Nov 01, 2007 at 03:47:25PM -0400, Hudes, Dana wrote:
> While you could do a root mirror break-off, I'd rather use Live Upgrade
> with Solaris. That way you build up the new boot environment and then
> boot onto it. If you want to patch, you use LU and the same OS level on
> both sides. Then you patch the inactive boot environment from the active
> BE, then activate the other BE and reboot onto it. 

While LU is cool, I didn't think it understood VxVM root encapsulated
disks in any useful way.

And if the OP doesn't have VxVM root, then this technique isn't
applicable anyway.

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://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

Re: [Veritas-vx] Remove rootmirror disk to patch solaris os ?

[Hudes, Dana]

LU and VxVM root encapsulation is something I haven't tried. What you
definitely lose is the mirror if that's what you're trying to use as
your alternate BE since Live Upgrade does the duplication of your source
BE itself. I'll have to experiment and see what I find.

=
Dana Hudes
UNIX and Imaging group
NYC-HRA MIS
+1 718 510 8586
Nextel:  172*26*16684
=

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of A Darren
Dunham
Sent: Thursday, November 01, 2007 5:24 PM
To: Veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] Remove rootmirror disk to patch solaris os ?

On Thu, Nov 01, 2007 at 03:47:25PM -0400, Hudes, Dana wrote:
> While you could do a root mirror break-off, I'd rather use Live
Upgrade
> with Solaris. That way you build up the new boot environment and then
> boot onto it. If you want to patch, you use LU and the same OS level
on
> both sides. Then you patch the inactive boot environment from the
active
> BE, then activate the other BE and reboot onto it. 

While LU is cool, I didn't think it understood VxVM root encapsulated
disks in any useful way.

And if the OP doesn't have VxVM root, then this technique isn't
applicable anyway.

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://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

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

Re: [Veritas-vx] Remove rootmirror disk to patch solaris os ?

[Myers, Mike]

I'm sure LU is always changing, but last I worked with it LU understood 
encapsulation enough to undo it, but not redo it (no great surprise there) so 
your new BE would be just on the disk slices and you'd have to run a 
reencapsulation step once you were happy with the results.  I doubt that will 
ever change since it would require LU to "do" Veritas stuff.

We've used it for OS upgrades (where the unencapsulation is pretty handy since 
we're upgrading the Veritas software as well), but for patching there's too 
much post-patch work that's "hard" (eg. not easily automated).  We just do 
flash archives of the system before patching and offer a restore from that to 
the system owner if there's problems.  Mostly it's less painful to figure out 
the issue and fix it on the application side than to go back (knowing that 
you'll have to move forward on patching eventually anyways).

Cheers,
 - Mike.Myers  nwdc.net

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Hudes, Dana
> Sent: Thursday, November 01, 2007 2:40 PM
> To: A Darren Dunham; Veritas-vx@mailman.eng.auburn.edu
> Subject: Re: [Veritas-vx] Remove rootmirror disk to patch solaris os ?
>
> LU and VxVM root encapsulation is something I haven't tried. What you
> definitely lose is the mirror if that's what you're trying to use as
> your alternate BE since Live Upgrade does the duplication of
> your source
> BE itself. I'll have to experiment and see what I find.
>
> =
> Dana Hudes
> UNIX and Imaging group
> NYC-HRA MIS
> +1 718 510 8586
> Nextel:  172*26*16684
> =
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of A Darren
> Dunham
> Sent: Thursday, November 01, 2007 5:24 PM
> To: Veritas-vx@mailman.eng.auburn.edu
> Subject: Re: [Veritas-vx] Remove rootmirror disk to patch solaris os ?
>
> On Thu, Nov 01, 2007 at 03:47:25PM -0400, Hudes, Dana wrote:
> > While you could do a root mirror break-off, I'd rather use Live
> Upgrade
> > with Solaris. That way you build up the new boot
> environment and then
> > boot onto it. If you want to patch, you use LU and the same OS level
> on
> > both sides. Then you patch the inactive boot environment from the
> active
> > BE, then activate the other BE and reboot onto it.
>
> While LU is cool, I didn't think it understood VxVM root encapsulated
> disks in any useful way.
>
> And if the OP doesn't have VxVM root, then this technique isn't
> applicable anyway.
>
> --
> 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
>
> ___
> 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

Re: [Veritas-vx] DMP question

[Sengor .]

Thanks Thomas,

I've seen the new WP on VxDMP, only the old one seems to discuss VxDMP
& PP specifics. One of our clients has both VxDMP and PP installed on
the same (large) set of servers connected up to EMC DMX arrays.

I've never understood the reason nor result of having both VxDMP 5.0
and PP 4.5 together. Normally only one'd be sufficient for load
balancing & failover. The older WP seems to be the only one which
touches on this coexistence subject (nothing on powerlink either which
I could find).


On 11/2/07, Thomas Cornely <[EMAIL PROTECTED]> wrote:
> Sengor, Ajay,
>
> There's an updated version of the DMP whitepaper (covering the latest 5.0 
> enhancements) at:
> http://eval.symantec.com/mktginfo/enterprise/white_papers/ent-whitepaper_vsf_5.0_dynamic_multi-pathing_05-2007.en-us.pdf
>
> As far as load balancing is concerned, DMP has historically outperformed PP. 
> The names of the PP algorithms really is more marketing than anything else. 
> If you have a chance, try out DMP 5.0's Minimum Queue algorithm and compare.
>
> Thomas
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf
> > Of Sengor .
> > Sent: Wednesday, October 31, 2007 9:10 PM
> > To: robertinoau
> > Cc: ajay raghuraj; veritas-vx@mailman.eng.auburn.edu
> > Subject: Re: [Veritas-vx] DMP question
> >
> > VxDMP and PP can co-exist on the same server:
> >
> > http://eval.veritas.com/mktginfo/products/White_Papers/Storage
> > _Server_Management/sf_dmp_wp.pdf
> >
> > PP has EMC specific load balancing algorithms specific to
> > their arrays. I believe ASL's for EMC arrays do not have
> > array specific optimised versions of load balancing.
> >
> > On 11/1/07, robertinoau <[EMAIL PROTECTED]> wrote:
> > >
> > > You are running PowerPath, therefore what you are seeing is
> > 100% correct.
> > >
> > > Remove powerpath and install the ASL for you array if you want DMP.
> > >
> > >
> > > - Original Message 
> > > From: ajay raghuraj <[EMAIL PROTECTED]>
> > > To: veritas-vx@mailman.eng.auburn.edu
> > > Sent: Wednesday, 31 October, 2007 9:59:17 PM
> > > Subject: [Veritas-vx] DMP question
> > >
> > >
> > > Hi,
> > >
> > > It looks like multipathing is missing . But I am not sure
> > where it is
> > > enabled . Is it in veritas / powerpath / native as this is
> > Sol 10. On
> > > Sol 10 how do we check multipathing as been enabled or not ? Is it
> > > some option with stmsboot ?
> > >
> > > Secondly if I have to enable it in veritas , how do i do it
> > ? and how
> > > do I verify ?
> > >
> > > vxdmpadm listctlr all
> > >
> > > CTLR-NAME   ENCLR-TYPE  STATE  ENCLR-NAME
> > > =
> > > emcpEMC ENABLED  EMC0
> > > c4  EMC DISABLED EMC0
> > > c3  EMC DISABLED EMC0
> > > c1  DiskENABLED  Disk
> > > c4  EMC ENABLED  EMC1
> > > c3  EMC ENABLED  EMC1
> > >
> > > vxdisk -g mifd_prd_oradg list emcpower18s2
> > >
> > > Multipathing information:
> > > numpaths:   1
> > > emcpower18c state=enabled
> > > vxdisk -o alldgs list
> > > .
> > > .
> > > .
> > > EMC1_17  auto--error
> > > EMC1_17  auto--error
> > > EMC1_17  auto--error
> > > .
> > > .
> > > emcpowerXX
> > > emcpowerxy
> > > emcpowerxz
> > >
> > > Regards,
> > > Ajay
> > >
> > >
> > >  
> > >  Feel safe with award winning spam protection on Yahoo!7 Mail. Find
> > > out more.
> > > ___
> > > Veritas-vx maillist  -  Veritas-vx@mailman.eng.auburn.edu
> > > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
> > >
> > >
> >
> >
> > --
> > _/ sengork.blogspot.com /
> >
> > ___
> > Veritas-vx maillist  -  Veritas-vx@mailman.eng.auburn.edu
> > http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
> >
>


-- 
_/ sengork.blogspot.com /

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

Re: [Veritas-vx] Remove rootmirror disk to patch solaris os ?

[A Darren Dunham]

On Thu, Nov 01, 2007 at 02:54:27PM -0700, Myers, Mike wrote:
> We've used it for OS upgrades (where the unencapsulation is pretty
handy since we're upgrading the Veritas software as well), but for
patching there's too much post-patch work that's "hard" (eg. not easily
automated).  We just do flash archives of the system before patching and
offer a restore from that to the system owner if there's problems.
Mostly it's less painful to figure out the issue and fix it on the
application side than to go back (knowing that you'll have to move
forward on patching eventually anyways).

That works as well.  I've used the "pull-a-disk" method quite a bit, but
I originally didn't do it for patching per se.

I had an E1 with 5 domains on it.  We were doing SAN configuration
changes and the first 4 went great.  The last one was horrible.  The
changes didn't actually "fail", but it caused the machine to take about
75 minutes to boot in some cases.  So backing out the changes in
reasonable time meant rebooting to an alternate environment.

In addition, the machine had no CD-rom, and at the time you couldn't
successfully jumpstart from a 'ge' interface (fixed later).  So it was
painful to boot from anything other than the installed root.  The
"pull-a-disk" meant I could have two separate boot environments via a
VxVM root mirror, syncing occasionally and being able to back out of
changes rapidly.  Worked very well for that.

I generally use it when I have a VxVM root mirror, I can pull the disk
easily, I expect that things will go well, but I have a tight window for
downtime.  If things fail, I know I'm back up very rapidly and we can
think about why we had problems later.  Not having to do any
configuration changes on VxVM to execute a backout makes the method
fast and in some ways, less error prone.  It's certainly not without its
dangers though.  Backups are always recommended to reduce the gremlin
playfield. 

-- 
Darren Dunham   [EMAIL PROTECTED]
Senior Technical Consultant TAOShttp://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

Re: [Veritas-vx] Remove rootmirror disk to patch solaris os ?

[Vikram Khare]

On Nov 1, 2007, at 5:54 PM, Myers, Mike wrote:

> I'm sure LU is always changing, but last I worked with it LU  
> understood encapsulation enough to undo it, but not redo it (no  
> great surprise there) so your new BE would be just on the disk  
> slices and you'd have to run a reencapsulation step once you were  
> happy with the results.  I doubt that will ever change since it  
> would require LU to "do" Veritas stuff.

Yes.  I've sen references to converting VxVM slices to SVM slices  
within an OS upgrade with LU but never actually splitting the  
mirrored drives the way it will with SVM.  More than likely they're  
more focused on getting LU to support ZFS pools for ZFS boot.

I found two utils on the VSF5 DVD that helped with live upgrade -  
vxlustart & vxlufinish.  vxlustart & vxlufinish are also mentioned in  
the Admin guide so I'm assuming Veritas does in fact support them  
during upgrades.

There's also a technote on seer which I can't find anymore that  
outlines Symantec's steps for splitting a mirrored boot drive.

-Vikram


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

[Veritas-vx] New Veritas Utility

[Scott Kaiser]

Just a brief note to let everyone know about our new web-based utility
to simplify installation and upgrades
 
https://sfprep.symantec.com  
 
You can automatically or manually upload information about your
server(s), and get reports that list -

*   system and storage Hardware Compatibility Lists (HCLs) 
*   Customized reports giving configuration recommendations prior to
install or upgrade, such as Veritas or OS patches 
*   Relevant reference material: technotes, array support libraries,
Maintenance Pack information, support tips, and third party links to
required updates.

The site is in beta, so some functionality is still being built out:
Solaris patch lists directly link to SunSolve, while AIX patch lists do
not (yet) directly link to IBM. After using it there's a form to leave
feedback, or you can email [EMAIL PROTECTED]
  
 
Regards,
Scott
___
Veritas-vx maillist  -  Veritas-vx@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx