[Veritas-vx] VXVM unattended installation
Hi All, I am trying to do an unattended installation of VXVM, VXFS VSF4.1 software. It seems that we can do with a response file. Have any one done this before. Can you provide your ideas on how you achieved this in your environment. N. Goutham. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] VXVM unattended installation
On Wed, Sep 05, 2007 at 02:18:26PM +0530, Goutham N wrote: N. Goutham == Goutham N [EMAIL PROTECTED] writes: N. Goutham Hi All, I am trying to do an unattended installation N. Goutham of VXVM, VXFS VSF4.1 software. It seems that we can N. Goutham do with a response file. Have any one done this N. Goutham before. Can you provide your ideas on how you N. Goutham achieved this in your environment. Assuming that you are speaking about Solaris, see 'man pkgask' about creating a response file. You might also see 'man pkgadd' and 'man -s 4 admin' about the the admin file. -- Eric M. Boehm /\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML or RTF in mail X No proprietary word-processing Respect Open Standards / \ files in mail ___ 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
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 distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. ___ 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
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 at 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 distribution, use, or copying of this email or the
[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
Re: [Veritas-vx] VXVM unattended installation
He may be referring to VRTS installer response files. I will post in more detail a bit later today. -- John Cronin Symantec Corporation 678-480-6266 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Boehm Sent: Wednesday, September 05, 2007 7:35 AM To: Goutham N Cc: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] VXVM unattended installation On Wed, Sep 05, 2007 at 02:18:26PM +0530, Goutham N wrote: N. Goutham == Goutham N [EMAIL PROTECTED] writes: N. Goutham Hi All, I am trying to do an unattended installation N. Goutham of VXVM, VXFS VSF4.1 software. It seems that we can N. Goutham do with a response file. Have any one done this N. Goutham before. Can you provide your ideas on how you N. Goutham achieved this in your environment. Assuming that you are speaking about Solaris, see 'man pkgask' about creating a response file. You might also see 'man pkgadd' and 'man -s 4 admin' about the the admin file. -- Eric M. Boehm /\ ASCII Ribbon Campaign [EMAIL PROTECTED] \ / No HTML or RTF in mail X No proprietary word-processing Respect Open Standards / \ files in mail ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621 ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] VXVM unattended installation
The easiest way to do this is to first do a manual installation similar
to the automated installations you want to do, and then take a look at
the logs in /var/VRTS/install/logs or /opt/VRTS/install/logs (the manual
installation should tell you where the logs are). One of the files in
the directory for that particular installation should be
installer-some-random-string.response. This file will contain the
responses for that particular installation, as well as a bunch of
comments that indicate the options available for that type of
installation (eg Storage Foundation, VCS, etc).
It is fairly easy to take the response file, and modify it (with
variable substitution) to replace the things that change from one
installation to the next (such as the system's hostname). You also have
to have the media available; I typically NFS mount the binaries (from a
Solaris Jumpstart server, a Red Hat Kickstart server, an AIX NIM server,
or just a dedicated NFS share used for installing software).
For example, here is the contents of a response file for a Storage
Foundation 5.0 for Oracle installation:
#
# installer configuration values:
#
$CPI::CFG{OBC_IGNOREWARNINGS}=0;
$CPI::CFG{OBC_MODE}=STANDALONE;
$CPI::CFG{OPT}{INSTALLONLY}=1;
$CPI::CFG{OPT}{NOEXTRAPKGS}=1;
$CPI::CFG{SYSTEMS}=[ qw(friday) ];
$CPI::CFG{UPI}=SFORA;
1;
-
The commented options that come after the useful bits shown above may
also be quite useful if you want to experiment with different options -
I strongly advise looking them over at least once to get an idea what is
possible. The options listed are different for each product (eg Storage
Foundation, VCS, maintenance packs, etc). Here are some examples of
things that might be useful:
# $CPI::CFG{DONOTINSTALL} is an optional one dimensional list variable.
# This variable defines a list of optional filesets not to be installed
on the
# systems.
#
# $CPI::CFG{KEYS}{SYSTEM} is an optional two dimensional list
variable.
# This variable defines a list of license keys to be registered on the
systems
# during install.
#
# $CPI::CFG{OPT}{NOLIC} is an optional two dimensional scalar variable.
# This variable installs the product without requiring entry of a
license key
#
# $CPI::CFG{OPT}{CONFIGURE} is an optional two dimensional scalar
variable.
# This variable performs configuration and startup of a product that has
# previously been installed using the -installonly option.
It is easy enough to use a shell script to generate the config file on
the fly and then call the VRTS installer to do the work using the
response file. Unfortunately, the method of installing using response
files does not seem to be well documented - the best method seems to be
doing a manual installation similar to the automated installation you
want to do, and then using the response file that is generated to write
your own script - there may be some lab work involving the old trial
and error method.
Another big problem is likely to be licensing - if you have a site
license and a single gold key then it is easy, but otherwise this is a
more difficult problem that I leave it to the readers to solve.
By the way, this is only one way to do an automated installation - you
can also just install the appropriate packages using pkgadd (Solaris),
rpm (Linux), installp (AIX), etc, and then do the configuration
yourself, or by calling the installer to do a configure (change
INSTALLONLY in the response file above to CONFIGUREONLY, I think). You
can similarly install VCS and many other VERITAS products. See the
Install Guide for whatever product you are looking at for details - look
under the headings of Installation Script Options, Installing the
Veritas software with Jumpstart, , etc for lots of good ideas for
automated installations.
The following script to install Storage Foundation for Oracle 5.0 MP1
makes the following assumptions:
1) You have the binaries available mounted via NFS (or whatever)
2) You have licensed Storage Foundation for Oracle somehow (not my
problem), or can insert commands to do so into the script before running
the installer. HINT: you will need to install VRTSvlic (the licensing
software) before you can license the software.
3) No secure cluster, storage foundation management server, etc.
4) You will test the script and add any desired error checking before
using it in production.
WARNING: I have not tested this exact script - Use it at your own risk.
There are very likely some typographical errors in the script - as I
just said, I have not tested this exact script. This script is not
supported by me, Symantec, Veritas or anyone else I know of. Don't use
it if you don't understand what it does. Seriously. If you destroy a
production server that you haven't backed up since it was installed
several years ago, by running this script, I am not going to consider
[Veritas-vx] HBA Driver update and Veritas
I have another really quick question. If I change drivers from the Sun qlc driver for the Qlogic 2460 HBA's will that change my target device id's and will Veritas be able to handle that gracefully as far as Veritas enabled disks, and volumes across those disks? I won't have a testbed until the 12th of September (and I think I can wait until then), but I'd be interested to hear the experienced voice on this. Thanks again so much! -James Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. http://tv.yahoo.com/collections/222 ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
