[Veritas-vx] ASL, APM and EMC Clariions (oh my...)

[Myers, Mike]

So I've been doing some research on a few systems of ours that didn't
handle an EMC Clariion firmware update gracefully (path loss was passed
up to the VxFS layer before DMP kicked in and failed over -- oops).  We
think the problem might be related to the ASL being quite old so I've
been doing a lot of digging into this area of Veritas which I've not
delved into much before.  It doesn't appear to be a very well documented
area of the software.

So a few specific questions if anyone can assist:

* What's the difference between an Array Support Library and a Array
Policy Module?  The Veritas support article on EMC Clariions point to a
tar ball that includes both (CLR-APM and DGC-Clar)

* Is there a command in Veritas to answer the question, "What ASL is
"controlling" device X?"  The closest I've been able to find is to run
"vxdmpadm getsubpaths ctlr=X" on one of the devices:

NAMESTATE[A]   PATH-TYPE[M] DMPNODENAME
ENCLR-TYPE   ENCLR-NAME  ATTRS


c5t50060163306036AFd2s2 ENABLED(A) PRIMARY  EMC_CLARiiON0_0
EMC_CLARiiON EMC_CLARiiON0   -
c5t50060163306036AFd1s2 ENABLED(A) SECONDARYEMC_CLARiiON0_1
EMC_CLARiiON EMC_CLARiiON0   -

* Why would the Clariion APM appear NOT to be in use? (maybe the answer
to my first question will make this question moot):

$ vxdmpadm listapm all
Module NameAPM Name   APM Version  Array Types
State


dmpaa  dmpaa  1A/A
Active
dmpap  dmpap  1A/P
Active
dmpap  dmpap  1A/P-C
Active
dmpapf dmpapf 1A/PF-VERITAS
Not-Active
dmpapf dmpapf 1A/PF-T3PLUS
Not-Active
dmpapg dmpapg 1A/PG
Not-Active
dmpapg dmpapg 1A/PG-C
Not-Active
dmpjboddmpjbod1Disk
Active
dmpjboddmpjbod1APdisk
Active
dmpCLARiiONdmpCLARiiON1CLR-A/P
Not-Active
dmpCLARiiONdmpCLARiiON1CLR-A/PF
Not-Active

* Veritas seems very confident in their documentation that an ASL may be
removed (and replaced) without impacting the controlled devices.  Has
anyone on here done that to production systems?

The ASL seems like a fairly integral piece of DMP to be removed while
I/O is traversing the DMP device.  That said, my little bit of testing
seems to indicate that this is true.  Is the ASL only consulted once per
boot (or when vxdctl enable is run)?  I guess I'm leading to the
question of what does an ASL actually do?  I'm looking for something
beyond, "It tells DMP which paths to use" -- it's obviously not involved
in the minute-to-minute I/O operations.  What sorts of things does it
tell the DMP layer?  How can you tell if it's working correctly (short
of an invasive test like pulling a fiber)...

Thanks in advance for any info folks can provide!  If there is useful
information sent off-list, I'll post a summary.

Cheers,
 - Mike Myers, mike.myers  nwdc.net

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

Re: [Veritas-vx] ASL, APM and EMC Clariions (oh my...)

[Myers, Mike]

Thomas,
Thank you for the answers, this helped clarify the ASL and APM roles for
me a great deal.

A support person at Sun also dug up this document which has an excellent
summary of their roles as well:

http://eval.symantec.com/mktginfo/products/White_Papers/Storage_Server_M
anagement/sf_dmp_field_guide.doc

It's certainly unclear to my why this is filed under marketing info but
oh well...at least it exists!

Cheers,
 - Mike Myers, mike.myers  nwdc.net

-Original Message-
From: Thomas Cornely [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 30, 2007 12:06 PM
To: Myers, Mike; veritas-vx@mailman.eng.auburn.edu
Subject: RE: [Veritas-vx] ASL, APM and EMC Clariions (oh my...)

Hi Mike,

With the right ASL/APM, you indeed shouldn't have issues with Clariion
NDU.
Please see inline below for more details.

Thanks,

Thomas

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Myers, Mike
> Sent: Wednesday, March 28, 2007 9:09 PM
> To: veritas-vx@mailman.eng.auburn.edu
> Subject: [Veritas-vx] ASL, APM and EMC Clariions (oh my...)
> 
> So I've been doing some research on a few systems of ours 
> that didn't handle an EMC Clariion firmware update gracefully 
> (path loss was passed up to the VxFS layer before DMP kicked 
> in and failed over -- oops).  We think the problem might be 
> related to the ASL being quite old so I've been doing a lot 
> of digging into this area of Veritas which I've not delved 
> into much before.  It doesn't appear to be a very well 
> documented area of the software.
> 
> So a few specific questions if anyone can assist:
> 
> * What's the difference between an Array Support Library and 
> a Array Policy Module?  The Veritas support article on EMC 
> Clariions point to a tar ball that includes both (CLR-APM and 
> DGC-Clar)

[Thomas] ASL stands for 'Array Support Libray'. They allow DMP to
properly claim a device, identify what type of array it sits in and
basically tell DMP which sets of procedures to use to manage the paths
to that device.

APM stands for 'Array Policy Module'. These are dynamically loaded
kernel modules that implement the sets of procedures and commands that
DMP must issue to an array to manage the paths to it. The base DMP code
comes with a set of default APMs for Active/Active arrays or
Active/Passive arrays. These APMs are "generic" in nature. For arrays
that are require specific handling (and the Clariion is a perfect
example of that), DMP relies on array specific APMs that implement
procedures and commands that are specific to that array.

> 
> * Is there a command in Veritas to answer the question, "What 
> ASL is "controlling" device X?"  The closest I've been able 
> to find is to run "vxdmpadm getsubpaths ctlr=X" on one of the devices:
> 
> NAMESTATE[A]   PATH-TYPE[M] DMPNODENAME
> ENCLR-TYPE   ENCLR-NAME  ATTRS
> ==
> ==
> 
> c5t50060163306036AFd2s2 ENABLED(A) PRIMARY  EMC_CLARiiON0_0
> EMC_CLARiiON EMC_CLARiiON0   -
> c5t50060163306036AFd1s2 ENABLED(A) SECONDARYEMC_CLARiiON0_1
> EMC_CLARiiON EMC_CLARiiON0   -
> 

I think a better command to issue here would be: 'vxdmpadm listenclosure
all' because that will show which enclosures DMP has identified and how
it claimed them (from the array_type column). Here's an example:
---
$ vxdmpadm listenclosure all
ENCLR_NAMEENCLR_TYPE ENCLR_SNO  STATUS   ARRAY_TYPE


EMC0  EMC940159   CONNECTEDA/A
Disk  Disk   DISKSCONNECTEDDisk
EMC_CLARiiON0 EMC_CLARiiON   APM00054800086   CONNECTED
CLR-A/PF
---

CLR-A/PF tells you that the Clariion was claimed with 'explicit failover
mode' (Clariion Failovermode 1).
A Clariion configured to Failovermode 2 would get claimed with
array_type 'CLR-A/P'. 

> * Why would the Clariion APM appear NOT to be in use? (maybe 
> the answer to my first question will make this question moot):
> 
> $ vxdmpadm listapm all
> Module NameAPM Name   APM Version  Array Types
> State
> ==
> ==
> 
> dmpaa  dmpaa  1A/A
> Active
> dmpap  dmpap  1A/P
> Active
> dmpap  dmpap  1A/P-C
> Active
> dmpapf dmpapf 1A/PF-VERITAS
> Not-Active
> dmpapf dmpapf 1A/PF-T3PLUS
> Not-Active
> dmpapg d

Re: [Veritas-vx] VX Error after 4.1.1 Installation reboot --

[Myers, Mike]

Try this:
Before rebooting, edit the file /usr/lib/vxvm/bin/vxroot.  Around line
138 you'll see code like this:

if [ $? -eq 0 -a -n $bus_drivers ] ; 

Add quotes around $bus_drivers so it looks like this:

if [ $? -eq 0 -a -n "$bus_drivers" ] ;

We were stung by this on a couple of T2000.  It's fixed in version 5.0
(though the problem dates back to at least 3.5) but I haven't see a fix
published for 4.x.

To recover from this (if this is the problem) without reinstalling you
can either boot to network or media and add these lines to /etc/system:

rootdev:/pseudo/[EMAIL PROTECTED]:0
set vxio:vol_rootdev_is_volume=1

(you can fix it from single user mode too, but it's a fair piece more
complex to get the root drive mounted read/write)

Cheers,
 - Mike Myers, mike.myers  nwdc.net

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 7:45 AM
To: Jim Senicka
Cc: Darren Dunham; [EMAIL PROTECTED]; Ronald
Karr; Veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] VX Error after 4.1.1 Installation reboot --


Hello All, 

Our two of the servers didn't reboot after VX installation 4.1.1 (BTW we
build around 70 +T2K runnibng solaris 10 without any issue) 

Any thought? 

Rebooting with command: boot 
Boot device: disk  File and args: 
SunOS Release 5.10 Version Generic_118833-36 64-bit 
Copyright 1983-2006 Sun Microsystems, Inc.  All rights reserved. 
Use is subject to license terms. 
Hostname: test2 
NOTICE: VxVM vxdmp V-5-0-34 added disk array DISKS, datype = Disk 

ERROR: svc:/system/filesystem/usr:default failed to mount /  (see 'svcs
-x' for details) 
Apr  2 15:35:20 svc.startd[7]: svc:/system/filesystem/usr:default:
Method "/lib/svc/method/fs-usr" failed with exit status 95. 
[ system/filesystem/usr:default failed fatally (see 'svcs -x' for
details) ] 
Requesting System Maintenance Mode 
(See /lib/svc/share/README for more information.) 
Console login service(s) cannot run 

Root password for system maintenance (control-d to bypass): 


Best Regards,

Malahat Qureshi Ph.D. (MIS)
Sr. Consultant, Support  Systems,  
HTSN-- eBusiness Infrastructure
O:- (847) 291-2284 C: -  (847) 309-0090
Email: [EMAIL PROTECTED]

***" I've learned That the less time I have to work with, the more
things I get done."***
_ 



**
This E-mail is confidential. It may also be legally privileged. If
you are not the addressee you may not copy, forward, disclose or
use any part of it. If you have received this message in error,
please delete it and all copies from your system and notify the
sender immediately by return E-mail.

Internet communications cannot be guaranteed to be timely, secure,
error or virus-free. The sender does not accept liability for any
errors or omissions.
**
SAVE PAPER - THINK BEFORE YOU PRINT! 


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

Re: [Veritas-vx] ASL, APM and EMC Clariions (oh my...)

[Myers, Mike]

Wow, the blog entry says pretty explicitly what I wish EMC or Sun would
have told us months ago:

"The APM, analogous to user land counterpart ASL, was tailored to handle
array specific problems such as initiating failover and supporting array
specific technologies such as NDU (Non-Disruptive Upgrade) from EMC."

I read that to say, without an APM loaded, NDU is NOT supported (NDU is
EMC's way of doing firmware updates while the system is up).

Thanks a lot for these excellent references!
 - Mike Myers, mike.myers  nwdc.net

-Original Message-
From: Thomas Cornely [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 04, 2007 9:01 PM
To: Myers, Mike; veritas-vx@mailman.eng.auburn.edu
Subject: RE: [Veritas-vx] ASL, APM and EMC Clariions (oh my...)

Hi Mike,

Interesting... I had no idea this doc was there. :)

Another good document if you're looking for insights on DMP is the "DMP
3.5/4.x whitepaper". It's a great doc on DMP's design pre-5.0 and
pre-DMP Backport (4.0 MP4 on AIX, 4.1 MP2 on Solaris and 4.1 MP4 on
Linux). You can get it at:
http://eval.symantec.com/mktginfo/products/White_Papers/Storage_Server_M
anagement/sf_dmp_wp.pdf

Finally, you may want to check out the following URL for blogs and
forums on Symantec products. There currently is one blog on DMP, and I
know Ameya has a few more in the pipe, with a focus on ASL, APMs:
http://www.symantec.com/enterprise/stn/index.jsp
https://forums.symantec.com/syment/blog/article?blog.id=Ameyablog&messag
e.id=2

Happy reading,

Thomas

PS: For other Storage Foundation whitepapers:
http://www.symantec.com/enterprise/products/whitepapers.jsp?pcid=1020&pv
id=203_1 


> -Original Message-
> From: Myers, Mike [mailto:[EMAIL PROTECTED] 
> Sent: Monday, April 02, 2007 10:25 AM
> To: Thomas Cornely; veritas-vx@mailman.eng.auburn.edu
> Subject: RE: [Veritas-vx] ASL, APM and EMC Clariions (oh my...)
> 
> Thomas,
> Thank you for the answers, this helped clarify the ASL and 
> APM roles for me a great deal.
> 
> A support person at Sun also dug up this document which has 
> an excellent summary of their roles as well:
> 
> http://eval.symantec.com/mktginfo/products/White_Papers/Storag
> e_Server_M
> anagement/sf_dmp_field_guide.doc
> 
> It's certainly unclear to my why this is filed under 
> marketing info but oh well...at least it exists!
> 
> Cheers,
>  - Mike Myers, mike.myers  nwdc.net
> 
> -----Original Message-
> From: Thomas Cornely [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 30, 2007 12:06 PM
> To: Myers, Mike; veritas-vx@mailman.eng.auburn.edu
> Subject: RE: [Veritas-vx] ASL, APM and EMC Clariions (oh my...)
> 
> Hi Mike,
> 
> With the right ASL/APM, you indeed shouldn't have issues with 
> Clariion NDU.
> Please see inline below for more details.
> 
> Thanks,
> 
> Thomas
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On 
> Behalf Of Myers, 
> > Mike
> > Sent: Wednesday, March 28, 2007 9:09 PM
> > To: veritas-vx@mailman.eng.auburn.edu
> > Subject: [Veritas-vx] ASL, APM and EMC Clariions (oh my...)
> > 
> > So I've been doing some research on a few systems of ours 
> that didn't 
> > handle an EMC Clariion firmware update gracefully (path loss was 
> > passed up to the VxFS layer before DMP kicked in and failed over -- 
> > oops).  We think the problem might be related to the ASL 
> being quite 
> > old so I've been doing a lot of digging into this area of Veritas 
> > which I've not delved into much before.  It doesn't appear to be a 
> > very well documented area of the software.
> > 
> > So a few specific questions if anyone can assist:
> > 
> > * What's the difference between an Array Support Library 
> and a Array 
> > Policy Module?  The Veritas support article on EMC 
> Clariions point to 
> > a tar ball that includes both (CLR-APM and
> > DGC-Clar)
> 
> [Thomas] ASL stands for 'Array Support Libray'. They allow 
> DMP to properly claim a device, identify what type of array 
> it sits in and basically tell DMP which sets of procedures to 
> use to manage the paths to that device.
> 
> APM stands for 'Array Policy Module'. These are dynamically 
> loaded kernel modules that implement the sets of procedures 
> and commands that DMP must issue to an array to manage the 
> paths to it. The base DMP code comes with a set of default 
> APMs for Active/Active arrays or Active/Passive arrays. These 
> APMs are "generic" in nature. For arrays that are require 
> specific handling (and the Clariion is a perfect example of 
> that), DMP relies on

Re: [Veritas-vx] removing devices

[Myers, Mike]

So if you run /etc/vx/diag.d/vxdmpinq  /dev/rdsk/c3t50001FE15005E90Ad6s2 what 
do you get?  It certainly looks like the disks are still visible...

Cheers,
 - Mike Myers, mike.myers  nwdc.net

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jarkko Airaksinen
Sent: Wednesday, April 11, 2007 9:21 AM
To: Veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] removing devices

Hello,

 

I've removed some disks from the server but they keep on coming back for 
example after "vxdisk scandisks':

 

# vxdisk list

DEVICE   TYPEDISK GROUPSTATUS

EVA8_1   auto:cdsdiskpt_dwhdg146_01  pt_dwhdg146  online nohotuse

EVA8_3   auto:cdsdiskpt_dwhdg146_02  pt_dwhdg146  online nohotuse

EVA8_4   auto:cdsdiskpt_dwhdg250_01  pt_dwhdg250  online nohotuse

EVA8_5   auto:cdsdiskpt_dwhdg250_02  pt_dwhdg250  online nohotuse

EVA8_7   auto:cdsdiskpt_dwhdg146_03  pt_dwhdg146  online nohotuse

EVA8_8   auto--error

EVA8_9   auto:cdsdiskpt_dwhdg146_04  pt_dwhdg146  online nohotuse

EVA8_10  auto--error

EVA8_11  auto:cdsdiskpt_dwhdg250_04  pt_dwhdg250  online nohotuse

EVA8_12  auto--error

EVA8_13  auto:cdsdiskpt_dwhdg250_06  pt_dwhdg250  online nohotuse

EVA8_14  auto:cdsdiskpt_dwhdg250_05  pt_dwhdg250  online nohotuse

EVA8_15  auto--error

c0t0d0s2 auto:sliced rootdg01 rootdg   online nohotuse

c1t0d0s2 auto:sliced rootdg02 rootdg   online nohotuse

 

I suppose this is because the device paths don't get cleaned even with devfsadm 
-C. For example these are the paths to EVA8_8:

 

# ls -la /dev/dsk/*d6s2

lrwxrwxrwx   1 root root  69 Feb 26 16:31 c3t50001FE15005E90Ad6s2 
-> ./../devices/[EMAIL PROTECTED],2000/SUNW,[EMAIL PROTECTED]/[EMAIL 
PROTECTED],0/[EMAIL PROTECTED],6:c

lrwxrwxrwx   1 root root  69 Feb 26 17:39 c3t50001FE15005E90Bd6s2 
-> ./../devices/[EMAIL PROTECTED],2000/SUNW,[EMAIL PROTECTED]/[EMAIL 
PROTECTED],0/[EMAIL PROTECTED],6:c

lrwxrwxrwx   1 root root  69 Feb 26 17:39 c3t50001FE15005E90Cd6s2 
-> ./../devices/[EMAIL PROTECTED],2000/SUNW,[EMAIL PROTECTED]/[EMAIL 
PROTECTED],0/[EMAIL PROTECTED],6:c

lrwxrwxrwx   1 root root  69 Feb 26 16:31 c3t50001FE15005E90Dd6s2 
-> ./../devices/[EMAIL PROTECTED],2000/SUNW,[EMAIL PROTECTED]/[EMAIL 
PROTECTED],0/[EMAIL PROTECTED],6:c

lrwxrwxrwx   1 root root  69 Feb 26 16:31 c5t50001FE15005E908d6s2 
-> ./../devices/[EMAIL PROTECTED],2000/SUNW,[EMAIL PROTECTED]/[EMAIL 
PROTECTED],0/[EMAIL PROTECTED],6:c

lrwxrwxrwx   1 root root  69 Feb 26 16:31 c5t50001FE15005E909d6s2 
-> ./../devices/[EMAIL PROTECTED],2000/SUNW,[EMAIL PROTECTED]/[EMAIL 
PROTECTED],0/[EMAIL PROTECTED],6:c

lrwxrwxrwx   1 root root  69 Mar  1 13:47 c5t50001FE15005E90Ed6s2 
-> ./../devices/[EMAIL PROTECTED],2000/SUNW,[EMAIL PROTECTED]/[EMAIL 
PROTECTED],0/[EMAIL PROTECTED],6:c

lrwxrwxrwx   1 root root  69 Feb 26 21:57 c5t50001FE15005E90Fd6s2 
-> ../../devices/[EMAIL PROTECTED],2000/SUNW,[EMAIL PROTECTED]/[EMAIL 
PROTECTED],0/[EMAIL PROTECTED],6:c

 

However the devices definitely don't exist anymore. I've deleted the disk from 
the SAN long time ago.

 

How would you remove the dangling device entries (without rebooting) if 
devfsadm -C doesn't clear them? The server has Sol8 + VxVM5.0.

 

-j-



___

 

La información incluida en el presente correo electrónico es CONFIDENCIAL, 
siendo para el uso exclusivo del/os destinatario/s arriba mencionado/s. Si 
usted recibe y lee este correo electrónico y no es el destinatario señalado, el 
empleado o el agente responsable de entregar el mensaje al destinatario, o ha 
recibido esta comunicación por error, le informamos que está totalmente 
prohibida cualquier divulgación, distribución, uso o reproducción del mismo, y 
le rogamos que nos lo notifique inmediatamente respondiendo al mensaje original 
a la dirección arriba mencionada y eliminando el mensaje a continuación.

 The information contained in this e-mail is CONFIDENTIAL and is intended only 
for the use of the addressee named above. If the reader of this message is not 
the intended recipient or the employee or agent responsible for delivering the 
message to the intended recipient, or you have received this communication in 
error, please be aware that any diffusion, distribution or duplication of this 
communication is strictly forbidden, and please notify us immediately by return 
to the original message at the address above eliminating it afterwards.



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

[Veritas-vx] Minimum 5.0 install

[Myers, Mike]

Folks,
We've been looking at the 5.0 foundation suite for Solaris and wondered
what people's thoughts are on the number of packages that come with it
(43!).  I'm not even sure what the majority of those bits DO (Symantec
Private Branch Exchange?  I thought a PBX was a phone switch!)

We have a pretty technically competent group of admins who document
processes in detail and are all comfortable working at the command line.
As a result, the majority (possibly all) of the "add on" pieces never
get used.

I'm toying around with the idea of just installing VRTSvlic, VRTSvxvm
and VRTSvxfs and being done with it.

What are folks thoughts on this?  I see the following:

PROS:
Faster installation
Faster upgrades
Smaller disk footprint
Fewer patches to track/install

CONS:
Junior admins have to learn command line (humm, is that really a con?)
Small additional learning curve for new admins who are used to using the
GUI
Complex disk layouts are more difficult (we do very little of this in
our environment)
Possibly support issues (though I'd think even support would want to get
as "close" to the problem as possible)

What am I missing?  What's the killer app that these extra pieces buy
us?

Cheers, 
 - Mike Myers, mike.myers  nwdc.net


___
Veritas-vx maillist  -  [EMAIL PROTECTED]
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx

Re: [Veritas-vx] Minimum 5.0 install

[Myers, Mike]

I've gotten some info from Veritas sales on that as well.  My first
thought too was, "I need to look into that."  But then I starting
thinking about it...

If I have new storage to build or a data migration on a server, I'm just
going to go log into that server to do it.  Even a multi terabyte build
goes pretty damm fast in Veritas.  Why introduce a level of indirection
(and all the possible problems it may introduce itself)?  While we do
storage changes on a pretty regular basis, it doesn't consume a huge
amount of time (heck, I spend more time on change request approvals...).

And if there were an actual problem I was working on, I certainly don't
want a layer between me and what's broken -- problem diagnosis is
difficult enough as is, why introduce another level?

The one place I see this may play is in license management which
historically has been a really big pain, but with Veritas now off of
node locked licenses this has gotten MUCH easier.

Thus, I've decided to not take the Veritas nap, err, presentation as
well...though they do often have nice polo shirts :)

If I'm missing something concrete, I'd LOVE to hear it.  Perhaps the
blinders of my environment are too narrow.

Cheers,
 - Mike Myers, mike.myers  nwdc.net

P.S. As Michael Warnock pointed out, to the base packages, one should
add the man pages...

-Original Message-
From: Rich Whiffen [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 12, 2007 11:44 AM
To: Myers, Mike
Cc: [EMAIL PROTECTED]
Subject: Re: [Veritas-vx] Minimum 5.0 install

One ring to rule them all...

The packages allow you to hook into Veritas Storage Foundation
Management Server
http://www.symantec.com/enterprise/theme.jsp?themeid=sfms

I've only seen the vendor group nap, err I mean power point
presentation of it and haven't played with it yet, but if you wanted a
'single pane of glass' view of your vxvm setup, you could get it.
Free, apparently.   It's on my list of "yeah, I need to look into
that" things.  That's the first thing that comes to my mind.

>From the site:

Key Features
* Centralized management of diverse application, servers and storage
across  different operating systems, servers and storage arrays. (See
the dashboard.)
* Centralized reporting and alert notification across data center
infrastructure.
* Over 250 guided operations available to enable repeatable
administrator  processes.
* Centralized volume mirroring and replication administration and
reporting  for a single view of protected applications.

Key Benefits
* A single view of data center infrastructure from applications to
storage.
* Transparency across data center infrastructure with consolidated
reporting  on state of storage resources.
* Rapid problem resolution with quick discovery of the origin of
faults and  the ability to proactively take corrective action.
* Improved operational efficiencies for diverse application, server
and  storage environments.

Cheers,
Rich


On 4/12/07, Myers, Mike <[EMAIL PROTECTED]> wrote:
> Folks,
> We've been looking at the 5.0 foundation suite for Solaris and
wondered
> what people's thoughts are on the number of packages that come with it
> (43!).  I'm not even sure what the majority of those bits DO (Symantec
> Private Branch Exchange?  I thought a PBX was a phone switch!)
>
> We have a pretty technically competent group of admins who document
> processes in detail and are all comfortable working at the command
line.
> As a result, the majority (possibly all) of the "add on" pieces never
> get used.
>
> I'm toying around with the idea of just installing VRTSvlic, VRTSvxvm
> and VRTSvxfs and being done with it.
>
> What are folks thoughts on this?  I see the following:
>
> PROS:
> Faster installation
> Faster upgrades
> Smaller disk footprint
> Fewer patches to track/install
>
> CONS:
> Junior admins have to learn command line (humm, is that really a con?)
> Small additional learning curve for new admins who are used to using
the
> GUI
> Complex disk layouts are more difficult (we do very little of this in
> our environment)
> Possibly support issues (though I'd think even support would want to
get
> as "close" to the problem as possible)
>
> What am I missing?  What's the killer app that these extra pieces buy
> us?
>
> Cheers,
>  - Mike Myers, mike.myers  nwdc.net
>
>
> ___
> 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

Re: [Veritas-vx] Minimum 5.0 install

[Myers, Mike]

This is great information and some I wish were available from an
official source.  While at least Veritas/Symantec still supports using
pkgadd to put individual packages on, there's this heavy focus on using
their installer script which means there is less focus on what the
packages are, why you might wants packages A, B and C, but not D, etc. 

If there were a short (5 pages max) summary of what each package does
and how it relates to the other packages I know I at least would
appreciate it.

Cheers,
 - Mike Myers, mike.myers  nwdc.net

P.S. I think it's excellent that so many Veritas people do contribute to
this list and with such in depth information.  It's a wonderful
resource!

-Original Message-
From: Scott Kaiser [mailto:[EMAIL PROTECTED] 
Sent: Thursday, April 12, 2007 1:15 PM
To: Rich Whiffen; Myers, Mike
Cc: [EMAIL PROTECTED]
Subject: RE: [Veritas-vx] Minimum 5.0 install

This is not going to be an official or comprehensive post, so caveat
reador...

In addition to VRTSvxvm, vxfs, and vlic, there are a number of other
packages that are not GUI nor SFMS related, but you may find useful. I
don't have a comprehensive list, but here are some examples (skipping
the VRTS prefix):

spt - a collection of useful utilities for support in case you hit a
problem. Having this pre-installed saves time, possibly very important
time depending on the problem.
odm - used for Oracle ODM support (faster performance)
glm - needed if you ever want to turn on the cluster file system.
alloc - a command line utility not widely used, but very powerful
vxmsa - libraries used to provide mapping from files to volumes to LUNs
to physical spindles
vxfen - module for I/O fencing, a data integrity solution used in
failover and a/a clusters
fspro - provides GUI support for vxfs, but also contains CLIs for
Dynamic Storage Tiering, the ability to move files among different
volumes online.

For the above, the descriptions hopefully suffice to make a decision.
The others I don't know off the top of my head, but dbac, gms, and cavf
may be unrelated to the GUI, or may have both GUI and non-GUI
capabilities.

Regards,
Scott
 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Rich Whiffen
> Sent: Thursday, April 12, 2007 11:44 AM
> To: Myers, Mike
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Veritas-vx] Minimum 5.0 install
> 
> One ring to rule them all...
> 
> The packages allow you to hook into Veritas Storage 
> Foundation Management Server 
> http://www.symantec.com/enterprise/theme.jsp?themeid=sfms
> 
> I've only seen the vendor group nap, err I mean power point 
> presentation of it and haven't played with it yet, but if you 
> wanted a 'single pane of glass' view of your vxvm setup, you 
> could get it.
> Free, apparently.   It's on my list of "yeah, I need to look into
> that" things.  That's the first thing that comes to my mind.
> 
> >From the site:
> 
> Key Features
> * Centralized management of diverse application, servers and 
> storage across  different operating systems, servers and 
> storage arrays. (See the dashboard.)
> * Centralized reporting and alert notification across data 
> center infrastructure.
> * Over 250 guided operations available to enable repeatable 
> administrator  processes.
> * Centralized volume mirroring and replication administration 
> and reporting  for a single view of protected applications.
> 
> Key Benefits
> * A single view of data center infrastructure from 
> applications to storage.
> * Transparency across data center infrastructure with 
> consolidated reporting  on state of storage resources.
> * Rapid problem resolution with quick discovery of the origin 
> of faults and  the ability to proactively take corrective action.
> * Improved operational efficiencies for diverse application, 
> server and  storage environments.
> 
> Cheers,
> Rich
> 
> 
> On 4/12/07, Myers, Mike <[EMAIL PROTECTED]> wrote:
> > Folks,
> > We've been looking at the 5.0 foundation suite for Solaris and 
> > wondered what people's thoughts are on the number of packages that 
> > come with it (43!).  I'm not even sure what the majority of 
> those bits 
> > DO (Symantec Private Branch Exchange?  I thought a PBX was a phone 
> > switch!)
> >
> > We have a pretty technically competent group of admins who document 
> > processes in detail and are all comfortable working at the 
> command line.
> > As a result, the majority (possibly all) of the "add on" 
> pieces never 
> > get used.
> >
> > I'm toying around with the idea of just installing 
> VRTSvlic, VRTSvxvm 
> > and VRTSvxfs and being done with it.
> >
>

[Veritas-vx] Veritas File system 5.0 patches for Solaris?

[Myers, Mike]

Folks,
We were checking on patches for foundation suite on Solaris and found a
bunch but we seem to be missing a patch for VxFS on Solaris 10...

I see patch 123200 for VxFS on Solaris 8, 123201 for VxFS on Solaris 9
but nothing for 10.  From the progression I'd guess it would be 123202
but no such patch exists on Sunsolve...

Anyone have any ideas?  These patches are pretty new (April 5th) so it
may just be a case that the 10 patches are delayed...

I've tried opening a case with Sun but I'm getting a serious
run-around...

TIA! 
 - Mike Myers, mike.myers  nwdc.net

___
Veritas-vx maillist  -  [EMAIL PROTECTED]
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx

Re: [Veritas-vx] Veritas File system 5.0 patches for Solaris?

[Myers, Mike]

So Sun finally confirmed that, as I suspected, the patch will be 123202
but that it's held up for the moment.  As one might expect, they are
reluctant to promise when it might be available.

Cheers,
 - Mike Myers, mike.myers  nwdc.net

-Original Message-
From: Myers, Mike 
Sent: Thursday, April 12, 2007 4:09 PM
To: veritas-vx@mailman.eng.auburn.edu
Subject: Veritas File system 5.0 patches for Solaris?

Folks,
We were checking on patches for foundation suite on Solaris and found a
bunch but we seem to be missing a patch for VxFS on Solaris 10...

I see patch 123200 for VxFS on Solaris 8, 123201 for VxFS on Solaris 9
but nothing for 10.  From the progression I'd guess it would be 123202
but no such patch exists on Sunsolve...

Anyone have any ideas?  These patches are pretty new (April 5th) so it
may just be a case that the 10 patches are delayed...

I've tried opening a case with Sun but I'm getting a serious
run-around...

TIA! 
 - Mike Myers, mike.myers  nwdc.net

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

Re: [Veritas-vx] fsadm: "reorg ioctl returned errno 61441"

[Myers, Mike]

Searching on "61441" and "fsadm" yields pretty much only hits on this
Veritas bug on HP-UX:

PHKL_22121: ( SR: 8606135462 CR: JAGad04596 )
VxFS 3.3 write(2) may return incorrect error value 61441
to
applications on error.

As it says, this is not a real error return code value.

Cheers,
 - Mike Myers, mike.myers  nwdc.net

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Leon
Koll
Sent: Sunday, April 22, 2007 8:05 AM
To: veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] fsadm: "reorg ioctl returned errno 61441"

Hello,

what does errno 61441 mean ? I am getting it during the fsadm reorg run
:

# fsadm -v -e -d -p 2 /myfs
UX:vxfs fsadm: INFO: V-3-20287: using device
/dev/rdsk/c2t001738010155000Cd0s0
UX:vxfs fsadm: INFO: V-3-20223: directory reorganization complete
UX:vxfs fsadm: INFO: V-3-20261: extent reorg pass 1

choosing exclusion zones for AUs:
aun 3758  tfree  24637  sfree  5
fset  999  scanning ino0
fset  999  scanning ino   10
<...>
fset  999  scanning ino  140
fset  999  scanning ino  150
UX:vxfs fsadm: ERROR: V-3-24364: reorg failed for fset 999 ino 1536248
UX:vxfs fsadm: ERROR: V-3-20274: reorg ioctl returned errno 61441
UX:vxfs fsadm: ERROR: V-3-24364: reorg failed for fset 999 ino 1571979
UX:vxfs fsadm: ERROR: V-3-20274: reorg ioctl returned errno 61441
fset  999  scanning ino  160
fset  999  scanning ino  170
UX:vxfs fsadm: ERROR: V-3-24364: reorg failed for fset 999 ino 1721286
UX:vxfs fsadm: ERROR: V-3-20274: reorg ioctl returned errno 61441
fset  999  scanning ino  180
fset  999  scanning ino  190
<...>

Thanks,
-- Leon
___
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] remount & add parameters

[Myers, Mike]

Try it this way:

mount -F vxfs -o remount,convosync=direct
/dev/vx/dsk/cd_testdg01/cd_testvol01 /data2/cd_test

Cheers,
 - Mike Myers, mike.myers  nwdc.net

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jarkko
Airaksinen
Sent: Wednesday, April 25, 2007 8:57 AM
To: Veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] remount & add parameters

Hello all Gurus out there,

 

Is there any way to add specific options when remounting a mounted file
system? Looks like I can remove them but not add.

 

For example I mount a file system with convosync=direct:

# mount -F vxfs -o convosync=direct /dev/vx/dsk/cd_testdg01/cd_testvol01
/data2/cd_test

# mount | grep test

/data2/cd_test on /dev/vx/dsk/cd_testdg01/cd_testvol01
read/write/setuid/convosync=direct/delaylog/largefiles/ioerror=mwdisable
/dev=3cc2af8 on Wed Apr 25 17:47:32 2007

 

Then I remount the already mounted file system without the convosync:

# mount -F vxfs -o remount /dev/vx/dsk/cd_testdg01/cd_testvol01
/data2/cd_test

# mount | grep test

/data2/cd_test on /dev/vx/dsk/cd_testdg01/cd_testvol01
read/write/setuid/delaylog/largefiles/ioerror=mwdisable/dev=3cc2af8 on

 

This works. However it doesn't seem to work the other way:

# mount -F vxfs -o remount -o convosync=direct
/dev/vx/dsk/cd_testdg01/cd_testvol01 /data2/cd_test

UX:vxfs mount: ERROR: V-3-21264: /dev/vx/dsk/cd_testdg01/cd_testvol01 is
already mounted, /data2/cd_test is busy,

allowable number of mount points exceeded

 

If I change the order of the specific_options (-o) it doesn't give
errors but neither does the convosync get added:

# mount -F vxfs -o convosync=direct -o remount
/dev/vx/dsk/cd_testdg01/cd_testvol01 /data2/cd_test

# mount |grep test

/data2/cd_test on /dev/vx/dsk/cd_testdg01/cd_testvol01
read/write/setuid/delaylog/largefiles/ioerror=mwdisable/dev=3cc2af8 on
Wed Apr 25 17:50:38 2007

 

Is there any way to add/change specific options with the remount option?
I'd like to avoid shutting down the databases for umount / mount.

 

-j-


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

Re: [Veritas-vx] recovering lost vxvm private data from vxprint -hvtand vxprint -htg outputs

[Myers, Mike]

You can't recover the private area directly, but if you rebuild logical
volumes that are on the exact same boundaries, the file systems inside
there will still be intact (presuming nothing wrote to those areas of
the disk during the disaster).

Probably the best instructions on doing something like this is the
rebuilding of EMC BCV volumes so that they get a new disk group ID --
searching on "Veritas" and "BCV" should find the procedures.  They
usually depend on a specific format of "vxprint" having been saved
beforehand so you may have to adjust the procedures to fit what data you
have.

Essentially it'll be a series of "vxmake" commands specifying the
device, offset and lengths of the originals from the saved output for
the subdisks, then building those into plexed and finally volumes.

Best of luck!

Cheers,
 - Mike Myers, mike.myers  nwdc.net

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Arjun
koneru
Sent: Thursday, May 17, 2007 9:40 AM
To: Veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] recovering lost vxvm private data from vxprint
-hvtand vxprint -htg outputs

Hi folks -- I lost my vxvm(3.5)  metadata  on my encapsulated root disk
and hence have booted the system(Solaris 9) without vxvm loaded and the
Filesystems in OS slices as opossed to VxVM objects.(by making
appropriate changes to /etc/system and /etc/vfstab) 


Is there any way I can retrieve the lost private data from the saved
outputs(prioir to the disaster struck) of vxprint -htg rootdg ? 

Thanks for any hint/help you may offer!

Arjun


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

Re: [Veritas-vx] Resize problem

[Myers, Mike]

It's been out experience that fsadm will not reorganize extents of files
that are open by an application.  Thus, if you have even one extent of a
file in the area you wish to reclaim and that file is open, you must
shut down your application (or otherwise get it to close the file) to do
the fsadm -e command.  In this case "fuser -c" and "lsof" are your
friends.

It would be really nice if Veritas included commands to assist with
identification of the file and/or if the fsadm told you all this.  It
doesn't seem like it should be TOO difficult a utility to write...

Cheers,
 - Mike.Myers  nwdc.net 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Khurram
Tariq
Sent: Friday, June 29, 2007 5:01 AM
To: veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] Resize problem

Upgraded the dg version, ran defrag again (used fsadm --F vxfs -d -e
/filesystem) and still the result of fsadm -D /filesystem is the same as
before (see below) & vxresize does not work:


  Directory Fragmentation Report
 DirsTotal  ImmedImmeds   Dirs to   Blocks
to
 SearchedBlocks Dirs to Add   ReduceReduce
  total   427 30113   1992129
604


Now I'm out of ideas, so gentlemen...please help.



On 6/29/07, Robinson, Greg <[EMAIL PROTECTED]> wrote:

Could you try upgrading the version of the filesystem to the
maximum supported by your volume manager version?
 
Greg.



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Khurram
Tariq
Sent: Friday, 29 June 2007 2:24 PM

To: veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] Resize problem



After the evacuation I'm left with 2 x 200GB disks in the
volume. Disk_160 is 79% used & Disk_161 is 20% used and the volume still
refuses to shrink giving me the same error as before. I've started
defrag again in the hopes that it will this time allow me to shrink the
volume. Ideas & suggestions are most welcome. 


On 6/28/07, Khurram Tariq <[EMAIL PROTECTED]> wrote: 

Gentlemen,

I've started the evacuation to Disk_161. Like Robert
said Disk_1 is the first disk of the volume. This way I'll be making
either Disk_161 the first disk (hopefully) & will be able to take
Disk_160 or 161 out of the volume leaving one 200GB disk in there. 

Lets see how it goes.

Khurram


On 6/28/07, Smedley, Jeremy P < [EMAIL PROTECTED]>
wrote: 



It could be that the file system is too busy for
the fsadm section of the command (which has the problem) to complete its
move of certain blocks. This is more likely due to the fact that the
majority of the data in the volume is on the first subdisk. 

You could try the following approach if it is
feasible in your environment.

Take the application offline which is accessing
data on this volume (user impact can not be avoided)

Repeat the defrag whilst the volume is quiesced.
Repeat the vxresize request whilst the volume is
quiesced.. 



From: [EMAIL PROTECTED]
on behalf of Khurram Tariq 
Sent: Thu 6/28/2007 2:44 PM 

To: veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] Resize problem






I had thought of it but the size of the volume
is slightly larger than the capacity of Disk_161 so mirroring wont be
possible. Size of the volume visible in VEA is 200.970GB & Disk_161 is
199.980GB.




On 6/28/07, Weber, Klaus <[EMAIL PROTECTED]>
wrote: 

possible solution could be
Create a mirror using disk_161
remove both disk_1 and disk_160 from
mirror
shrink volume  to desired size
attach mirror consisting of disk_160
remove disk_161 from mirror
all this should be possible whilst
the volume is started
 
Klaus



Von:
[EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] Im Auftrag von Khurram Tariq
Gesendet: Donnerstag, 28. Juni 2007
15:

Re: [Veritas-vx] Resize problem

[Myers, Mike]

Hey, inside information, great stuff :)

Do you know at what level this was addressed?  It would make a great
incentive to upgrade :)

Cheers,
 - Mike.Myers  nwdc.net 
-Original Message-
From: James Slater [mailto:[EMAIL PROTECTED] 
Sent: Friday, June 29, 2007 9:43 AM
To: Myers, Mike; Khurram Tariq; veritas-vx@mailman.eng.auburn.edu
Subject: RE: [Veritas-vx] Resize problem

Hi Mike,

This is what I was trying to allude to in my mail earlier. In the older
versions of SF it was sometimes not possible to move certain application
files due to them being memory mapped (Oracle in particular). However,
this has been fixed for the later releases of storage foundation.
Rearranging the volume layout will not help - this is purely at a file
system level.

Regards,

James.

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

Re: [Veritas-vx] Volume Corrupted

[Myers, Mike]

You don't really have a choice unless you happen to have a file system
guru on staff who enjoys playing with fsdb :)

Generally speaking fsck will recover things well though like in all
complex systems there are spectacular exceptions.  Judging on small
number of errors it's showing in the output below I'd say you chances of
a good clean fsck are excellent.

If the system is absolutely critical and going to backups is an option,
you may want to consider that.  You should also investigate the source
of the corruption and address that.

Cheers,
 - Mike.Myers  nwdc.net 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ketan
Patel
Sent: Tuesday, July 24, 2007 10:08 AM
To: veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] Volume Corrupted

Gurus,
 
Fsck on a corrupted volume displays following message:
 
[EMAIL PROTECTED]   # mount /backup
UX:vxfs mount: ERROR: V-3-21268: /dev/vx/dsk/localdg/localdg_vol01 is
corrupted. needs checking 
[EMAIL PROTECTED]   # fsck -F vxfs -n
/dev/vx/rdsk/localdg/localdg_vol01
pass0 - checking structural files 
pass1 - checking inode sanity and blocks
pass2 - checking directory linkage
pass3 - checking reference counts
pass4 - checking resource maps
au 7572 emap incorrect - fix? (ynq)n
au 7572 summary incorrect - fix? (ynq)n 
fileset 1 iau 0 summary incorrect - fix? (ynq)n
OK to clear log? (ynq)n
sanity checks/updates have not been completed - restart? (ynq)n
 
Shall I go ahead with fsck? Will it cause me lose my data?
 
Ketan
 
 

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

Re: [Veritas-vx] T2000 Box with Solaris 10 & Veritas4.1(Encapsulation issue)

[Myers, Mike]

If folks are interested, the actual bug in this case is a pair of
missing quotes in the /usr/lib/vxvm/bin/vxroot script:

<   if [ $? -eq 0 -a -n "$bus_drivers" ] ;
---
>   if [ $? -eq 0 -a -n $bus_drivers ] ;

We put a fixed version onto our servers when they jumpstart so that we
can encapsulate before patching (actually, we did this before the patch
was available...)

Cheers,
 - Mike.Myers  nwdc.net 
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Biju
Krishnan
Sent: Friday, August 17, 2007 4:04 AM
To: Gowthaman N
Cc: veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] T2000 Box with Solaris 10 &
Veritas4.1(Encapsulation issue)

Hi Gowtham,
 
This seems to be a common issue.
 
Refer the following technote
 
http://seer.support.veritas.com/docs/282808.htm
 
The bottomline is MP1 patch or the workaround mentioned in the doc.
 
Regards,
PP BIJU KRISHNAN

 
On 8/17/07, Gowthaman N <[EMAIL PROTECTED]> wrote: 

Hi,
 
I m doing encapusulation on a T2000 server with Veritas 4.1 and
during the second reboot of the server, it goes to
maintenance mode
 
Below is the error message from console.  Any solutions
 
Hostname:  

WARNING:
/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL 
PROTECTED],2/SUNW,[EMAIL PROTECTED]/[EMAIL PROTECTED],0/[EMAIL PROTECTED],

1 (ssd10):

offline

WARNING:
/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL 
PROTECTED],2/SUNW,[EMAIL PROTECTED]/[EMAIL PROTECTED],0/[EMAIL PROTECTED],

2 (ssd9):

offline

WARNING:
/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL 
PROTECTED],2/SUNW,[EMAIL PROTECTED]/[EMAIL PROTECTED],0/[EMAIL PROTECTED],

0 (ssd11):

offline

WARNING:
/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL 
PROTECTED],2/SUNW,[EMAIL PROTECTED],1/[EMAIL PROTECTED],0/[EMAIL PROTECTED]

3,1 (ssd4):

offline

WARNING:
/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL 
PROTECTED],2/SUNW,[EMAIL PROTECTED],1/[EMAIL PROTECTED],0/[EMAIL PROTECTED]

3,2 (ssd3):

offline

WARNING:
/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL 
PROTECTED],2/SUNW,[EMAIL PROTECTED],1/[EMAIL PROTECTED],0/[EMAIL PROTECTED]

3,0 (ssd5):

offline

NOTICE: VxVM vxdmp V-5-0-34 added disk array DISKS, datype =
Disk

ERROR: svc:/system/filesystem/usr:default failed to mount / (see
'svcs -x' for

details)

Aug 16 10:40:46 svc.startd[7]:
svc:/system/filesystem/usr:default: Method "/lib/

svc/method/fs-usr" failed with exit status 95.

Aug 16 10:40:46 svc.startd[7]: system/filesystem/usr:default
failed fatally: tra

nsitioned to maintenance (see 'svcs -xv' for details)

Requesting System Maintenance Mode

(See /lib/svc/share/README for more information.)

Console login service(s) cannot run

Root password for system maintenance (control-d to bypass):

single-user privilege assigned to /dev/console.

Entering System Maintenance Mode

 


 
Thanks & Regards,

N. Gowthaman 



___
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] Drive type unknown Solaris 10

[Myers, Mike]

I don't know the Hitachi array, but I'll bet it's active/passive with "explicit 
failover" (or something similarly named from Hitachi).

We have this "issue" with our Clariion's.  We connect them thus:

SP = "Service Processor"
SW = fiber switch (actually "director")
HBA = host bus adaptor

SPA   SPB
| \   / |
|  \ /  |
|   \   |
|  / \  |
| /   \ |
SW1   SW2
|   |
|   |
HBA1 HBA2

The individual LUN's are presented to one SP as "primary" and the other as 
"fail over", thus if you have a LUN that's been assigned to SPA as primary and 
SPB as the failover, you end up with the following paths to the same LUN:

HBA1 -> SW1 -> SPA (primary)
HBA1 -> SW1 -> SPB (failover)
HBA2 -> SW2 -> SPA (primary)
HBA2 -> SW2 -> SPB (failover)

In explicit failover mode you can do some "base" operations to the LUN on the 
failover interface (such as answer a SCSI INQUIRY command) but more complex 
operations (such as real I/O) will fail until a special "bring it over here" 
command is sent (this would be an explicit request to failover the LUN -- thus 
"explicit failover").  The volume manager will issue such as request when it 
has no remaining primary I/O paths to the device.

So the short answer is: if you have your ASL's and/or APM's installed for this 
model of array, you should be able to do something like "vxdisk list  nwdc.net
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Kelty
Sent: Tuesday, September 04, 2007 1:26 PM
To: veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] Drive type unknown Solaris 10

Hey there,

I'm running Veritas Storage Foundation HA Standard, v4.1 on Solaris 10 (x64), 
and I'm having a bit of an issue with 'drive type unknown' coming up on the 
Solaris format command.

I have two Qlogic QLE220 (PCI Express 4Gb HBA) hooked up to an HDS WMS100 with 
the latest ASL/APM installed.

bash-3.00# pkginfo | grep VRTS
system  VRTSHDS-DF600-apmArray Policy Module for HITACHI 
DF600(9500 and AMS-WMS) Arrays.
system  VRTSHDS-DF600-aslArray Support Library for HITACHI 
DF600(9500 and AMS-WMS) Arrays.

vxddladm is showing the supported share object:
bash-3.00# vxddladm listsupport | grep vxhdsasl
libvxhdsasl.so   HITACHIDF600, DF600-V, DF600F

vxdmpadm is showing the two active paths I would expect to see:
bash-3.00# vxdmpadm getdmpnode enclosure=AMS_WMS0
NAME STATE ENCLR-TYPE   PATHS  ENBL  DSBL  ENCLR-NAME
=
c4t0d5s2 ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d2s2 ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d6s2 ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d1s2 ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d4s2 ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d7s2 ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d0s2 ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d3s2 ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d8s2 ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d11s2ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d10s2ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d9s2 ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d12s2ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d13s2ENABLED  AMS_WMS  2  2 0 AMS_WMS0
c4t0d14s2ENABLED  AMS_WMS  2  2 0 AMS_WMS0

vxdisk show the disks as online in the correct group (the last three are the 
I/O fencing disks):
bash-3.00# vxdisk list
DEVICE   TYPEDISK GROUPSTATUS
c2t0d0s2 auto:none   --online invalid
c3t0d0s2 auto:none   --online invalid
c4t0d0s2 auto:cdsdiskd400 mucho_grponline
c4t0d1s2 auto:cdsdiskd401 mucho_grponline
c4t0d2s2 auto:cdsdiskd402 mucho_grponline
c4t0d3s2 auto:cdsdiskd403 mucho_grponline
c4t0d4s2 auto:cdsdiskd404 mucho_grponline
c4t0d5s2 auto:cdsdiskd405 mucho_grponline
c4t0d6s2 auto:cdsdiskd406 mucho_grponline
c4t0d7s2 auto:cdsdiskd407 mucho_grponline
c4t0d8s2 auto:cdsdiskd408 mucho_grponline
c4t0d9s2 auto:cdsdiskd409 mucho_grponline
c4t0d10s2auto:cdsdiskd410 mucho_grponline
c4t0d11s2auto:cdsdiskd411 mucho_grponline
c4t0d12s2auto:cdsdisk--online
c4t0d13s2auto:cdsdisk--online
c4t0d14s2auto:cdsdisk--online


I'm not having any I/O issues to the drives so

Re: [Veritas-vx] Drive type unknown Solaris 10

[Myers, Mike]

I appreciate the summary of how HDS works -- it's nice to have a little 
background on other vendors stuff, you never know what you'll be working with 
tomorrow...

Just to return the favor a bit, EMC Clariions can act just as you've stated 
here (LUN affinity); it's a selectable mode.  The model I described (explicit) 
is recommended by EMC when Veritas or PowerPath are in use because of exactly 
the issues you mentioned -- the I/O simply cannot work on the other path so the 
LUN's don't end up bouncing back and forth (at, as you said, a huge performance 
penalty).

We've seen lots of problems with this on HP-UX using the native logical volume 
manager -- particularly using the "pvmove" command...that can bring an entire 
array to it's knees with a massive trespass storm.  The only solution we've 
found is to purchase PowerPath from EMC and set the system to explicit mode 
(though I suppose buying Veritas for HP-UX might work as well since it has the 
ASL/APM pieces that understand the array).

Cheers!
 - Mike.Myers  nwdc.net
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Keating
Sent: Wednesday, September 05, 2007 6:28 AM
To: Darren Dunham; Veritas-vx@mailman.eng.auburn.edu
Subject: Re: [Veritas-vx] Drive type unknown Solaris 10


The OP indicated he's using WMS100. HDS modular arrays will allow the
disk to be seen from either controller(service processor).
>From what I've read in this thread, the Clariion requires a host request
via the failover path to "switch" the LUN ownership, which would explain
why the secondary controller would advertise the disk to the host as
"unknown".

I don't know the Clariion well, so excuse me if it behaves the same as
below and the result seen is merely a function of VxVM.
The HDS arrays aren't quite the same, in that they are not purely
"active/passive", but rather "active/active **with LUN affinity**".

What this means is that while the primary controller has exclusive
control of the LUN, any request for the disk can been serviced via
either controller, at any time, and the disks are FULLY
visiable/available to the host via either controller at anytime.

However, if you access the disk via the secondary controller, the
secondary controller acts as a proxy and passes the IO over to the
primary controller via the array's backplane (this is known an a LUN
trespass) to service the request. The primary controller then returns
the response to the secondary controller to forward back to the host. If
the host maintains constant IO to a LUN via the LUN's non-owning
controller for a dterminate amount of time, the array will transfer
ownership of the LUN to the seoncadry controller.

There is a HUGE performance penalty associated with operating in this
state, particularly if the LUN belongs to a RAIDset where all the other
LUNs on that RAIDset are owned by the other controller.

This causes no end of grief with multipath management software that
doesn't explicitly understand HDS' "LUN affinity" model.
HDS tags "disks" with the appropriate metadata so that the multipath
software can interpret which device is the proper one to communicate
with. This is probably handled by the VRTSHDS-DF600-apm &
VRTSHDS-DF600-asl packages the OP posted.

Soall this to say that if the disks are showing up as "unknown",
then this must be a specific "obscurity" laid over the disks by VxVM,
since the HDS array will advertise the disk properly via ALL available
paths.

Paul


--


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Darren Dunham
> Sent: September 4, 2007 5:59 PM
> To: Veritas-vx@mailman.eng.auburn.edu
> Subject: Re: [Veritas-vx] Drive type unknown Solaris 10
>
>
> > Does this make the 'format' command output more of an
> aesthetic 'issue'. A red herring, in other words?
>
> The 'format' command is trying to read the disk label to present the
> information in it to you in the list.
>
> If the label can't be read, you'll get the 'drive type unknown'
> messages.  'format' is trying to read every path, valid or not.
> 'vxdisk' will instead understand the topology and only try to read
> through primary paths unless a failure is detected.
>
> --
> 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
>


La version française suit le texte anglais.



This email may contain privileged and/or confidential information, and the Bank 
of
Canada does not waive any related rights. Any di

Re: [Veritas-vx] does fsadm defragmentation require additional storage to run?

[Myers, Mike]

I'm not sure of the answer to your questions, but I would add this to the 
discussion:

There have been at least two instances where Veritas File System has had a bug 
that disabled the file system when an fsadm was run against it with the file 
system 100% full (I believe the bug in 4.1 was only very recently addressed).  
As such, we wrapper the command with a check that the file system is <90% full 
before running.  Anything above that we leave alone.

Cheers,
 - Mike.Myers  nwdc.net
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Svoboda, Michael 
Steven
Sent: Wednesday, September 05, 2007 9:03 AM
To: veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] does fsadm defragmentation require additional storage to 
run?

We are looking at implementing fsadm to perform extent and directory
defragmentation across our VxFS file systems.  During the
defragmentation process, does fsadm require extra space in the
filesystem to perform its work?  Is data copied to RAM instead while the
extent reorganization is being executed?

I know fsadm will actually reduce the filesystem size after its run; but
what happens during the run?

What we are concerned about is if a file system is at, say, 89.9%, fsadm
runs and pushes it to 90%, we don't want our monitoring software to
report on that full filesystem; if after the call-out the space is
reduced to say 87% and doesn't require intervention.

It appears to run successfully on 100% filesystems with 0k free.  The
only reason why I ask this question is that the VxFS 5.0 Administrators
Guide has the following text:

Reorganizing a file system
  You can reorganize or compact a fragmented file system
using fsadm, even while
  the file system is mounted. This may help shrink a file
system that could not
  previously be decreased.

  Note: If a file system is full or busy, the reorg
operation may fail.

99% run
# df -h .
Filesystem size   used  avail capacity  Mounted on
/dev/vx/dsk/testdg/vol1
   100M99M   1.0M99%/testdg/vol1

# /usr/lib/fs/vxfs/fsadm -v -e -d /testdg/vol1/
UX:vxfs fsadm: INFO: V-3-20287: using device /dev/vx/rdsk/testdg/vol1
UX:vxfs fsadm: INFO: V-3-20223: directory reorganization complete
UX:vxfs fsadm: INFO: V-3-20261: extent reorg pass 1
AU: aun =   2, tfree =  16641, sfree =  9
AU: aun =   0, tfree = 36, sfree = 36
UX:vxfs fsadm: INFO: V-3-20262: extent reorg complete

100% run with 9k free.
# df -k .
Filesystemkbytesused   avail capacity  Mounted on
/dev/vx/dsk/testdg/vol1
  102400  102391   9   100%/testdg/vol1

# /usr/lib/fs/vxfs/fsadm -v -e -d /testdg/vol1/
UX:vxfs fsadm: INFO: V-3-20287: using device /dev/vx/rdsk/testdg/vol1
UX:vxfs fsadm: INFO: V-3-20223: directory reorganization complete
UX:vxfs fsadm: INFO: V-3-20261: extent reorg pass 1
AU: aun =   2, tfree =  16641, sfree =  9
AU: aun =   0, tfree = 36, sfree = 36
UX:vxfs fsadm: INFO: V-3-20262: extent reorg complete

After the defrag, it gave me 16k free.

# df -k .
Filesystemkbytesused   avail capacity  Mounted on
/dev/vx/dsk/testdg/vol1
  102400  102384  16   100%/testdg/vol1


# mkfile 16k all-used-up

# df -k .
Filesystemkbytesused   avail capacity  Mounted on
/dev/vx/dsk/testdg/vol1
  102400  102400   0   100%/testdg/vol1


# /usr/lib/fs/vxfs/fsadm -v -e -d /testdg/vol1/
UX:vxfs fsadm: INFO: V-3-20287: using device /dev/vx/rdsk/testdg/vol1
UX:vxfs fsadm: INFO: V-3-20223: directory reorganization complete
UX:vxfs fsadm: INFO: V-3-20261: extent reorg pass 1
AU: aun =   2, tfree =  16641, sfree =  9
AU: aun =   0, tfree = 36, sfree = 36
UX:vxfs fsadm: INFO: V-3-20262: extent reorg complete

# df -k .
Filesystemkbytesused   avail capacity  Mounted on
/dev/vx/dsk/testdg/vol1
  102400  102400   0   100%/testdg/vol1


Thanks!

Mike




___
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] change disk from simple to cdsdisk

[Myers, Mike]

Try:

vxdisksetup -i sdr format=cdsdisk
vxdg -g sundg adddisk sunlun5=sdr

Cheers,
 - Mike.Myers  nwdc.net
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrey Dmitriev
Sent: Thursday, September 06, 2007 10:55 AM
To: veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] change disk from simple to cdsdisk

I haven't done this in so long, I forgot.

Could someone point me in the right direction?

/usr/lib/vxvm/bin/vxdisksetup sdr
vxdisk online sdr
vxdisk init sdr
vxdg -g sundg adddisk sunlun5=/dev/sdr

VxVM vxdg ERROR V-5-1-6478 Device sdr cannot be added to a CDS disk
group


[EMAIL PROTECTED] ~]# vxdisk list
DEVICE   TYPEDISK GROUPSTATUS
sda  auto:none   --online invalid
sde  auto:cdsdisksundg01  sundgonline nohotuse
sdf  auto:cdsdisk--online
sdg  auto:cdsdisk--online
sdq  auto:cdsdisk--online
sdr  auto:simple --online


___
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] VG Size

[Myers, Mike]

Something like this would total up the sizes of all disks:

vxprint -g | awk '/^dm/ {T+=$5} END {print T}'

Is that what you're looking for?  The result will be in sectors (512 bytes per 
sector on Solaris, 1k on some other platforms) though you can adjust the awk 
program to fix that is desired.

Cheers,
 - Mike.Myers  nwdc.net

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Artur Baruchi
> Sent: Monday, October 01, 2007 8:19 AM
> To: Veritas-vx@mailman.eng.auburn.edu
> Subject: [Veritas-vx] VG Size
>
> Hi,
>
> How can I discover the size of a VG (in MB or GB) ?
>
> Thanks
>
> Att.
> Artur Baruchi
> ___
> 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] io issues with EMC CX500 + vxfs_thread

[Myers, Mike]

You didn't say what OS (which might be important -- AIX?) but I'd look closely 
at the mount options passed for these file systems.  Your response times look 
good which would generally indicate the storage probably isn't a problem (could 
I qualify that more? :)

Cheers,
 - Mike.Myers  nwdc.net

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Andrey Dmitriev
> Sent: Tuesday, October 09, 2007 9:11 AM
> To: veritas-vx@mailman.eng.auburn.edu
> Subject: [Veritas-vx] io issues with EMC CX500 + vxfs_thread
>
> We are seeing what seems to be IO issues with one of the file systems.
> Oracle with ODM is running on top of it.
>
>
> avg-cpu:  %user   %nice%sys %iowait   %idle
>   26.420.00   15.670.00   57.92
>
> Device:rrqm/s wrqm/s   r/s   w/s  rsec/s   wsec/s  rkB/s
>wkB/savgrq-sz avgqu-sz  await  svctm  %util
> sdb  0.00   0.00 923.75 59.53 7392.64  541.81
> 3696.32   270.90   8.07 3.06  3.12   1.02   99.93
>
> Notice, combined  read/write is under 10megs per second.
>
> Another system with an identically configured LUN (16disk RAID 10)
>
> avg-cpu:  %user   %nice%sys %iowait   %idle
>   24.100.006.010.25   69.64
>
> Device:rrqm/s wrqm/s r/s w/srsec/swsec/s
> rkB/swkB/s   avgrq-sz avgqu-sz  await  svctm  %util
> sdd  0.00   0.00 316.05  62.54  187429.10 948.49
> 93714.55 474.25  497.57   1.41  3.72   1.90   71.9
> sdd  0.00   0.00 1330.23 300.33 118990.03 2931.89
> 59495.02 1465.95 74.774.05  2.49   0.59   95.45
>
> I also see vxfs_thread rising to the top whenever there is high load
> (which seems to be related to io)
>
> I looked at Storage Processors, and they're about 10-20% utilized. Any
> clue?
>
> -andrey
>
>
> ___
> 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] vxvm: Unable to read Disk Geometry

[Myers, Mike]

I don't think this is a Veritas error per-se.  Once you can get format to talk 
to the drives, you should be a long way to solving your problem.  Look at the 
array's error log because ASC 0x3a == medium not present.

If you had system power fails, you probably had array ones as well and 
something must have gotten screwed up there.

Cheers,
 - Mike.Myers  nwdc.net

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Rumbidzayi Gadhula
> Sent: Saturday, January 19, 2008 12:35 AM
> To: veritas-vx@mailman.eng.auburn.edu
> Subject: [Veritas-vx] vxvm: Unable to read Disk Geometry
>
>
>
> am unable to initialize my disk array under VVM 4.0
> (StorageTek D173). When I select  initialize disk veritas
> says it is unable to read the disk geometry.
>
>
>
> Trying to label the disk fails with Disk unformatted. Trying
> to format results in a Read error (failing to read VTOC) with
> an error code ASC 0x3a.
>
> If I run a prtvtoc it shows me the disk partitions.
>
>
>
> The background is as follows.
>
>
>
> Due to some repeated power cuts the system failed to mount
> the array on the assigned file system. This is when all the
> above problems began. I then decided to rebuild the system in
> order to eliminate some of the things I previously thought
> had gone wrong. I also changed the version of VVM( from v3.4
> to v4.0 ) that had previously been installed because we could
> no longer locate the license information.
>
>
>
> I am still getting the same problems. Can you please assist
> me on what steps to follow to make the array usable
>
>
>
> Regards,
>
>
>
> Rumbi
>
>

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

Re: [Veritas-vx] QUESTIONS : Veritas Volume Manager from 3.5 to 5.0 data migration in Solaris 8/10

[Myers, Mike]

This procedure should work without any problems and you should be able to move 
back to 3.5 as long as you don't upgrade the volume group version.

And of course you left out step 0 because we know it's required:
0. Take a full backup of "stanley".  Just in case.

Cheers,
 - Mike.Myers  nwdc.net

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of Bill Mackler
> Sent: Sunday, January 20, 2008 1:41 PM
> To: veritas-vx@mailman.eng.auburn.edu
> Subject: [Veritas-vx] QUESTIONS : Veritas Volume Manager from
> 3.5 to 5.0 data migration in Solaris 8/10
>
> Hi,
>
>
> Our current server "stanley" is running Solaris 8 and Veritas
> Foundation Suite for Oracle (VxVM/VxFS) 3.5-mp3.  All the disk groups
> in the associated storage has version 90 as below :
>
>
> "stanley" will be replaced by a new server with the same name running
> Solaris 10 and Veritas Storage Foundation 5.0-mp1.  Our plan is to
> attach all existing disk groups (version 90) from "stanley"
> to the new
> replacement server with Solaris 10 and latest Veritas Storage
> Foundation 5.0-mp1.  Please advise me the procedure to disconnect all
> existing disk groups from the "stanley" and reconnect them to new
> replacement without going thru the upgrade of existing disk groups of
> version 90.   Our goal is to run Veritas 5.0 in the new "stanley"
> while accessing all original version 90 data in the disk group
> hds9585dg.  We plan to just perform the steps -> 1.#deport hds9585dg
> 2. physical SAN disconnection of "stanley" and reconnection to new
> replacement server 3. #import hds9585dgPlease let us know if they
> are correct and if there is anything we are missing.
>
>
> Also, say we need to fall back to the old "stanely" serer running
> 3.5.  Is it possible to reverse the above steps after physically
> switch the SAN connection and  deport/import  from "version 90 disk
> group in Veritas 5.0" to "version 90 disk group in Veritas 3.5" ?  I
> want to make sure that there's no issue performing the steps in
> reverse.
>
>
> Thanks for your assistance,   Bill
>
>
> stanley# vxdg list hds9585dg
> Group: hds9585dg
> dgid:  1097031500.6964.stanley
> import-id: 0.11605
> flags:
> version:   90
> detach-policy: global
> copies:nconfig=default nlog=default
> config:seqno=0.2252 permlen=28130 free=27921 templen=132
> loglen=4262
> :
> :
>
>
> stanley# pkginfo -l VRTSvxvm
>   PKGINST:  VRTSvxvm
>  NAME:  VERITAS Volume Manager, Binaries
>  CATEGORY:  system
>  ARCH:  sparc
>   VERSION:  3.5,REV=06.21.2002.23.14
>
>
>

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

Re: [Veritas-vx] Solaris 10 - Unable to encapsulate the root drives

[Myers, Mike]

Is this a T1000/2000 by chance?

If so, you might be running into a bug in the "vxroot" script.  It's easy to 
check -- on line 138 is the variable $bus_drivers quoted or not?  If it's NOT 
quoted, then you might have this bug affecting you.  The fix it is as simple as 
putting quotes around it like this:

138c138
<   if [ $? -eq 0 -a -n $bus_drivers ] ;
---
>   if [ $? -eq 0 -a -n "$bus_drivers" ] ;

I'm sure there's an official Veritas patch somewhere (I know this was fixed in 
the 5.0 release) but I find this a quicker fix.

Cheers,
 - Mike.Myers  nwdc.net
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Asim Zuberi
Sent: Wednesday, April 16, 2008 7:32 PM
To: veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] Solaris 10 - Unable to encapsulate the root drives



Hi All --

We're unable to encapsulate the root-drives on the Systems running Solaris
10 upgrade 4 with Veritas VM 4.1 MP2
patches. All the required OS patches are installed on the system. Every time
an encapsulation attempt is made using
"vxdiskadm" it appears all is getting configured properly. But on the second
reboot during the
encapsulation cycle, the system couldn't just come-up.

Just wondering, if anyone has encountered the same issues? Any pointers will
be a great help!


thanks!
--Asim;

___
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] Solaris 10 - Unable to encapsulate the root drives

[Myers, Mike]

Darn, that would have the easy fix.  I haven't seen a problem like this on our 
T2000's.

When you say on the second reboot "the system couldn't just come up" what 
exactly does it do at that point?

If you boot the system to CD or network and inspect the drives, how much of the 
encapsulation is done (eg. Are the drives partitioned?  Is the /etc/vfstab 
changed, is /etc/system changed?)

Cheers,
 - Mike.Myers  nwdc.net
-Original Message-
From: Asim Zuberi [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 17, 2008 8:50 AM
To: Myers, Mike; veritas-vx@mailman.eng.auburn.edu
Subject: RE: [Veritas-vx] Solaris 10 - Unable to encapsulate the root drives


Thanks Mike for your quick response. Yes, the systems are T2000s.
I checked the "/etc/vx/bin/vxroot"  script, and it already has the quotes
around the "$bus_drivers".

Sample Output:

vxroot:bus_drivers=`modinfo | grep "PCI Bus nexus driver" \
vxroot: if [ $? -eq 0 -a -n "$bus_drivers" ] ;
vxroot: for i in $bus_drivers
vxroot: if [ "$drv" = "pci" -a "$flag" = "no" -a -n "$bus_drivers" ]
vxroot: for i in $bus_drivers


What else do I need to look out for?

Some more details

usilsunvirtual06# pkginfo -l VRTSvxvm
   PKGINST:  VRTSvxvm
  NAME:  VERITAS Volume Manager, Binaries
  CATEGORY:  system
  ARCH:  sparc
   VERSION:  4.1,REV=02.17.2005.21.28
   BASEDIR:  /
VENDOR:  VERITAS Software
  DESC:  Virtual Disk Subsystem
PSTAMP:  VERITAS-4.1MP2.14:2007-02-21
  INSTDATE:  Apr 06 2007 07:55
   HOTLINE:  800-342-0652
 EMAIL:  [EMAIL PROTECTED]
STATUS:  completely installed
 FILES:  845 installed pathnames
  23 shared pathnames
  18 linked files
  98 directories
 410 executables
  300751 blocks used (approx)


usilsunvirtual06# cat /etc/*release*
   Solaris 10 8/07 s10s_u4wos_12b SPARC
   Copyright 2007 Sun Microsystems, Inc.  All Rights Reserved.
Use is subject to license terms.
Assembled 16 August 2007

usilsunvirtual06# uname -a
SunOS usilsunvirtual06 5.10 Generic_127111-11 sun4v sparc SUNW,Sun-Fire-T200








=]  -Original Message-
=]  From: Myers, Mike [mailto:[EMAIL PROTECTED]
=]  Sent: Thursday, April 17, 2008 9:56 AM
=]  To: 'Asim Zuberi'; veritas-vx@mailman.eng.auburn.edu
=]  Subject: RE: [Veritas-vx] Solaris 10 - Unable to
=]  encapsulate the root drives
=]
=]  Is this a T1000/2000 by chance?
=]
=]  If so, you might be running into a bug in the "vxroot"
=]  script.  It's easy to check -- on line 138 is the variable
=]  $bus_drivers quoted or not?  If it's NOT quoted, then you
=]  might have this bug affecting you.  The fix it is as simple
=]  as putting quotes around it like this:
=]
=]  138c138
=]  <   if [ $? -eq 0 -a -n $bus_drivers ] ;
=]  ---
=]  >   if [ $? -eq 0 -a -n "$bus_drivers" ] ;
=]
=]  I'm sure there's an official Veritas patch somewhere (I
=]  know this was fixed in the 5.0 release) but I find this a
=]  quicker fix.
=]
=]  Cheers,
=]   - Mike.Myers  nwdc.net
=]  -Original Message-
=]  From: [EMAIL PROTECTED]
=]  [mailto:[EMAIL PROTECTED] On
=]  Behalf Of Asim Zuberi
=]  Sent: Wednesday, April 16, 2008 7:32 PM
=]  To: veritas-vx@mailman.eng.auburn.edu
=]  Subject: [Veritas-vx] Solaris 10 - Unable to encapsulate
=]  the root drives
=]
=]
=]
=]  Hi All --
=]
=]  We're unable to encapsulate the root-drives on the Systems
=]  running Solaris 10 upgrade 4 with Veritas VM 4.1 MP2
=]  patches. All the required OS patches are installed on the
=]  system. Every time an encapsulation attempt is made using
=]  "vxdiskadm" it appears all is getting configured properly.
=]  But on the second reboot during the encapsulation cycle,
=]  the system couldn't just come-up.
=]
=]  Just wondering, if anyone has encountered the same issues?
=]  Any pointers will be a great help!
=]
=]
=]  thanks!
=]  --Asim;
=]
=]  ___
=]  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] SF 5.0 MP1 patches install via Solaris jumpstart process!

[Myers, Mike]

I'd suspect you have some post-jumpstart scripts that run that install Veritas 
and as I recall the patching that jumpstart does is executed before those 
scripts run ("finish" scripts).  Thus, your error about no Veritas packages 
being installed.

To solve this you could add a patching step to the Veritas install script or 
just do what you described and do the patches by hand after the install.

If you have any other packages which get installed by the Finish scripts which 
may have patches from Sun, you might be better off patching the system after 
the finish scripts to avoid this situation.

Cheers,
 - Mike.Myers  nwdc.net
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Asim Zuberi
Sent: Monday, May 12, 2008 9:42 AM
To: veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] SF 5.0 MP1 patches install via Solaris jumpstart process!


Hi All --

Please advise on how to install  the SF 5.0 MP1 patches as part of the
Solaris jumpstart. During the jumpstart, after the installation of the
VRTS  (SF 5.0) pkgs, the Solaris command  "patchadd" cycles through each and
every patch and reports back there are no
packages installed  for the patch to be applied.

However, if I run the same code to install the patches once the server is
online after the jumpstart is completed, it installs MP1 patches
successfully.

Question is, am I missing something or is it a normal behavior for VRTS MP1
patches install?

thanks!
--Asim;






___
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] Veritas flag meanings?

[Myers, Mike]

Folks,
We've starting (probably with VxFS 5.0) seeing that newly created Veritas file 
systems (eg. just ran "mkfs -F vxfs /dev/vx/rdsk/rootdg/junk2") have a "flag" 
bit set:

# vxassist make junk 1g
# mkfs -F vxfs /dev/vx/rdsk/rootdg/junk
version 7 layout
2097152 sectors, 1048576 blocks of size 1024, log size 16384 blocks
largefiles supported
# mount -F vxfs /dev/vx/dsk/rootdg/junk /junk
# echo "8192B.p S" | fsdb -F vxfs /dev/vx/rdsk/rootdg/junk | grep flags
flags 4000 mod 0 clean 3c

Previously we would find our file systems with no flag bits set.  It must not 
be a terribly important flag since it doesn't trigger a normal fsck to clear it:

# umount /junk
# fsck -F vxfs /dev/vx/dsk/rootdg/junk
file system is clean - log replay is not required
# echo "8192B.p S" | fsdb -F vxfs /dev/vx/rdsk/rootdg/junk | grep fl>
flags 4000 mod 0 clean 5a

That said, if you pass the "-o full" option it does clear it:

# fsck -F vxfs -o full /dev/vx/dsk/rootdg/junk
log replay in progress
pass0 - checking structural files
pass1 - checking inode sanity and blocks
pass2 - checking directory linkage
pass3 - checking reference counts
pass4 - checking resource maps
OK to clear log? (ynq)y
flush fileset headers? (ynq)y
set state to CLEAN? (ynq)y
# mount -F vxfs /dev/vx/dsk/rootdg/junk /junk
# echo "8192B.p S" | fsdb -F vxfs /dev/vx/rdsk/rootdg/junk | grep fl>
flags 0 mod 0 clean 3c

So...does anyone know what flag 4000 means?  That would be the 14th bit (0100 
  ).  I've looked through the #include files in both the VRTSvxfs 
and VRTSfssdk packages but haven't found a definition of this flag...

And before anyone asks...We have a scanner that picks up file system with 
non-zero flags because we had a situation once where a running file system had 
been marked for a fullfsck because of an underlying I/O problem (which wasn't 
detected till the system rebooted and all the file systems get full fscked).

It's probably nothing...maybe we just watch our systems too closely :)

Cheers,
 - Mike.Myers  nwdc.net

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

Re: [Veritas-vx] Can't deport

[Myers, Mike]

I don't know if this can happen with Veritas (never had to me), but when I run 
into such strangeness with files I usually look to see if there's a control 
character of some type embedded in the name.

Put the "vxdisk list" output (or "vxdg list") to a file and open it in vi and 
see if there's something funny about the name.

Cheers,
 - Mike.Myers  nwdc.net
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrey Dmitriev
Sent: Friday, August 22, 2008 10:12 AM
To: veritas-vx@mailman.eng.auburn.edu
Subject: [Veritas-vx] Can't deport

Any clue?



[EMAIL PROTECTED] ~]# vxdisk list
DEVICE   TYPEDISK GROUPSTATUS
sda  auto:none   --online invalid
sdb  auto:cdsdisk--online
sdc  auto:cdsdisktest_sun_dg01  test_sun_dg online nohotuse
[EMAIL PROTECTED] ~]# vxdg destroy test_sun_dg
VxVM vxdg ERROR V-5-1-581 Disk group test_sun_dg: No such disk group is imported
[EMAIL PROTECTED] ~]# vxdisk list sdc
Device:sdc
devicetag: sdc
type:  auto
hostid:neptune
disk:  name=test_sun_dg01 id=1219345252.12.neptune
group: name=test_sun_dg id=1219345253.14.neptune
info:  format=cdsdisk,privoffset=256,pubslice=3,privslice=3
flags: online ready private autoconfig nohotuse autoimport imported
pubpaths:  block=/dev/vx/dmp/sdc3 char=/dev/vx/rdmp/sdc3
guid:  {79cf7e86-1dd2-11b2-8bc6-92153326667f}
udid:  DGC%5FDISK%5FAPM00052400387%5F60060160624815006291E473F66ADD11
site:  -
version:   3.1
iosize:min=512 (bytes) max=65535 (blocks)
public:slice=3 offset=65792 len=69137408 disk_offset=0
private:   slice=3 offset=256 len=65536 disk_offset=0
update:time=1219420121 seqno=0.9
ssb:   actual_seqno=0.0
headers:   0 240
configs:   count=1 len=51360
logs:  count=1 len=4096
Defined regions:
 config   priv 48-000239[000192]: copy=01 offset=00 enabled
 config   priv 000256-051423[051168]: copy=01 offset=000192 enabled
 log  priv 051424-055519[004096]: copy=01 offset=00 enabled
 lockrgn  priv 055520-055663[000144]: part=00 offset=00
Multipathing information:
numpaths:   3
sde state=enabled   type=primary
sdc state=enabled   type=secondary
sdg state=enabled   type=secondary


[EMAIL PROTECTED] ~]# fdisk /dev/sdc

Unable to read /dev/sdc
[EMAIL PROTECTED] ~]# fdisk /dev/sdg

Unable to read /dev/sdg
[EMAIL PROTECTED] ~]# fdisk /dev/sde

Command (m for help):
[EMAIL PROTECTED] ~]# fdisk -l /dev/sde

Disk /dev/sde (Sun disk label): 128 heads, 11 sectors, 49150 cylinders
Units = cylinders of 1408 * 512 bytes

   Device FlagStart   EndBlocks   Id  System
/dev/sde3  u  0 49150  346016005  Whole disk

___
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