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/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 at 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 dmpapg 1A/PG Not-Active dmpapg dmpapg 1A/PG-C Not-Active dmpjboddmpjbod1Disk Active dmpjboddmpjbod1APdisk Active dmpCLARiiONdmpCLARiiON1CLR-A/P Not-Active dmpCLARiiONdmpCLARiiON1CLR
Re: [Veritas-vx] ASL, APM and EMC Clariions (oh my...)
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 at 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=Ameyablogmessag e.id=2 Happy reading, Thomas PS: For other Storage Foundation whitepapers: http://www.symantec.com/enterprise/products/whitepapers.jsp?pcid=1020pv 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 at 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
Re: [Veritas-vx] removing devices
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 at 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
Re: [Veritas-vx] Minimum 5.0 install
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 at 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 at 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
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 at 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. 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
[Veritas-vx] 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 at nwdc.net ___ Veritas-vx maillist - [EMAIL PROTECTED] http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] fsadm: reorg ioctl returned errno 61441
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 at 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] recovering lost vxvm private data from vxprint -hvtand vxprint -htg outputs
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 at 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
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 at 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:23
Re: [Veritas-vx] Volume Corrupted
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 at 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] mailto:[EMAIL PROTECTED] # mount /backup UX:vxfs mount: ERROR: V-3-21268: /dev/vx/dsk/localdg/localdg_vol01 is corrupted. needs checking [EMAIL PROTECTED] mailto:[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)
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 at 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
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 any device and see that, from the VM perspective, things are working properly. Something like this: Multipathing information: numpaths: 4 c2t5006016139A02131d5s2 state=enabled type=primary c3t5006016839A02131d5s2 state=enabled type=secondary c2t5006016939A02131d5s2 state=enabled type=secondary c3t5006016039A02131d5s2 state=enabled type=primary Hope that helps -- and I hope it's your problem. I know this took a few minutes to understand when we moved from parallel disconnected SAN's for redundancy to interconnected like this, but it's the right thing to do. (I think...) Cheers, - Mike.Myers at 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:cdsdisk
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
Re: [Veritas-vx] VG Size
Something like this would total up the sizes of all disks:
vxprint -g dgname| 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 at 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] vxvm: Unable to read Disk Geometry
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 at 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
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 at 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
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 at 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
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 at 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 at 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
[Veritas-vx] Veritas flag meanings?
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 at nwdc.net ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
