Re: [Veritas-vx] Solaris-SFS / MPxIO / VxVM failover issue
dmp_fast_recovery is a mechanism by which we bypass the sd/scsi stack and send path inquiry/status CDBs directly from the HBA in order to bypass long SCSI queues and recover paths faster. With a TPD (third-party driver) such as MPxIO, bypassing the stack means we bypass the TPD completely, and interactions such as this can happen. The vxesd (event-source daemon) is another 5.0/MP2 backport addition that's moot in the presence of a TPD. From your modinfo, you're not actually running MP3. This technote (http://seer.entsupport.symantec.com/docs/327057.htm) isn't exactly your scenario, but looking for partially-installed pkgs is a good start to getting your server correctly installed, then the tuneable should work -- very early 5.0 versions had a differently-named tuneable I can't find in my mail archive ATM. Cheers, Jf -Original Message- From: veritas-vx-boun...@mailman.eng.auburn.edu [mailto:veritas-vx-boun...@mailman.eng.auburn.edu] On Behalf Of Sebastien DAUBIGNE Sent: Thursday, September 16, 2010 7:41 AM To: Veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] Solaris-SFS / MPxIO / VxVM failover issue Thank you Victor and William, it seems to be a very good lead. Unfortunately, this tunable seems not to be supported in the VxVM version installed on my system : vxdmpadm gettune dmp_fast_recovery VxVM vxdmpadm ERROR V-5-1-12015 Incorrect tunable vxdmpadm gettune [tunable name] Note - Tunable name can be dmp_failed_io_threshold, dmp_retry_count, dmp_pathswitch_blks_shift, dmp_queue_depth, dmp_cache_open, dmp_daemon_count, dmp_scsi_timeout, dmp_delayq_interval, dmp_path_age, or dmp_stat_interval Something odd because my version is 5.0 MP3 Solaris SPARC, and according to http://seer.entsupport.symantec.com/docs/316981.htm this tunable should be available. modinfo | grep -i vx 38 7846a000 3800e 288 1 vxdmp (VxVM 5.0-2006-05-11a: DMP Drive) 40 784a4000 334c40 289 1 vxio (VxVM 5.0-2006-05-11a I/O driver) 42 783ec71ddf8 290 1 vxspec (VxVM 5.0-2006-05-11a control/st) 296 78cfb0a2c6b 291 1 vxportal (VxFS 5.0_REV-5.0A55_sol portal ) 297 78d6c000 1b9d4f 8 1 vxfs (VxFS 5.0_REV-5.0A55_sol SunOS 5) 298 78f18000 a270 292 1 fdd (VxQIO 5.0_REV-5.0A55_sol Quick ) Le 16/09/2010 12:15, Victor Engle a écrit : Which version of veritas? Version 4/2MP2 and version 5.x introduced a feature called DMP fast recovery. It was probably supposed to be called DMP fast fail but recovery sounds better. It is supposed to fail suspect paths more aggressively to speed up failover. But when you only have one vxvm DMP path, as is the case with MPxIO, and fast-recovery fails that path, then you're in trouble. In version 5.x, it is possible to disable this feature. Google DMP fast recovery. http://seer.entsupport.symantec.com/docs/307959.htm I can imagine there must have been some internal fights at symantec between product management and QA to get that feature released. Vic On Thu, Sep 16, 2010 at 6:03 AM, Sebastien DAUBIGNE sebastien.daubi...@atosorigin.com wrote: Dear Vx-addicts, We encountered a failover issue on this configuration : - Solaris 9 HW 9/05 - SUN SAN (SFS) 4.4.15 - Emulex with SUN generic driver (emlx) - VxVM 5.0-2006-05-11a - storage on HP SAN (XP 24K). Multipathing is managed by MPxIO (not VxDMP) because the SAN team and HP support imposed the Solaris native solution for multipathing : VxVM == VxDMP == MPxIO == FCP ... We have 2 paths to the switch, linked to 2 paths to the storage, so the LUNs have 4 paths, with active/active support. Failover operation has been tested successfully by offlining each port successively on the SAN. We regulary have transient I/O errors (scsi timeout, I/O error retries with Unit attention), due to SAN-side issues. Usually these errors are transparently managed by MPxIO/VxVM without impact on the applications. Now for the incident we encountered : One of the SAN port was reset , consequently there were some transient I/O error. The other SAN port was OK, so the MPxIO multipathing layer should have failover the I/O on the other path, without transmiting the error to the VxDMP layer. For some reason, it did not failover the I/O before VxVM caught it as unrecoverable I/O error, disabling the subdisk and consequently the filesystem. Note the giving up message from scsi layer at 06:23:03 : Sep 1 06:18:54 myserver vxdmp: [ID 917986 kern.notice] NOTICE: VxVM vxdmp V-5-0-112 disabled path 118/0x558 belonging to the dmpnode 288/0x60 Sep 1 06:18:54 myserver vxdmp: [ID 824220 kern.notice] NOTICE: VxVM vxdmp V-5-0-111 disabled dmpnode 288/0x60 Sep 1 06:18:54 myserver vxdmp: [ID 917986 kern.notice] NOTICE: VxVM vxdmp V-5-0-112 disabled path 118/0x538 belonging to the dmpnode 288/0x20 Sep 1 06:18:54 myserver vxdmp: [ID 917986 kern.notice] NOTICE: VxVM vxdmp V-5-0-112 disabled path 118/0x550 belonging to the dmpnode 288/0x18 Sep 1 06:18:54
Re: [Veritas-vx] Relayout volume from 2 to 4 columns
Striping across Enterprise LUNs allows you to use more SCSI queues/transaction, and follow the template of setting the number of read/write threads to the number of stripe cols, and have it work efficiently, amongst other arguments for the config. Not everyone needs this configuration, but it's the difference between made and missed SLAs for a lot of configurations. Cheers, Jf -- Sent using BlackBerry From: veritas-vx-boun...@mailman.eng.auburn.edu veritas-vx-boun...@mailman.eng.auburn.edu To: veritas-vx@mailman.eng.auburn.edu veritas-vx@mailman.eng.auburn.edu Sent: Wed Jan 06 10:19:56 2010 Subject: Re: [Veritas-vx] Relayout volume from 2 to 4 columns the ISP feature of VM would allow you to drill down to individual spindles and place subdisks on each spindle. Individual spindles of the RAID group? Doesn't that defeat the purpose of the RAID group? Striping across LUNs gets ...interesting; we usually just use them concat. Of course that's with a real SAN array such as Hitachi 99x0 or Sun 61x0. I'm not sure I see the point of striping LUNs. If you are having performance problems from the array, fix the layout of the RAID group on the array: that's why you pay the big bucks to Hitachi for their hardware. I not sure I want to know about the load that could flatline a RAID-6 array of 6 15K RPM Fiber channel disks backed by a multigigabyte RAM cache. I have certainly seen bad storage layout on the host cause hot spots. That's when people make ridiculous numbers of small (gigabyte or so) volumes scattered all over the place -- another argument against the old way of doing things with databases and raw volumes (if you're going to use raw volumes at least use decent size ones not 2GB each ). While old ( 10) Solaris AIO did indeed suck dead bunnies thorugh a straw for performance, that's no longer a problem in Solaris 10 ZFS if you use it natively (using branded zones to run Solaris 8 and 9 puts the old AIO interface in front) nor would I expect it to be a problem with VxFS. From: veritas-vx-boun...@mailman.eng.auburn.edu [mailto:veritas-vx-boun...@mailman.eng.auburn.edu] On Behalf Of William Havey Sent: Wednesday, January 06, 2010 12:00 PM To: przemol...@poczta.fm Cc: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] Relayout volume from 2 to 4 columns VM views the two raid groups as single LUNs. It needn't be concerned with the layout of each raid group. To change from 2 columns to 4 columns use the relayout option to vxassist and also specify the two new LUNs on which to place the two new columns. That being said, the ISP feature of VM would allow you to drill down to individual spindles and place subdisks on each spindle. Bill On Wed, Jan 6, 2010 at 6:36 AM, przemol...@poczta.fm wrote: Hello, we are using VSF 5.0 MP3 on Solaris 10 attached to SAN-based hardware array. On this array we have created 2 raid groups and on each RG we have created a few LUNs: raid group: RG1RG2 LUN1 LUN7 LUN2 LUN8 LUN3 LUN9 LUN4 LUN10 LUN5 LUN11 LUN6 LUN12 For performance reason some of our volumes are striped between the two raid groups (using two columns ncol=2) e.g.: pl name vol ENABLED ACTIVE 419256320 STRIPE 2/128 RW In this configuration IOs involves two raid groups. It seems that in the future in certain cases performance might be not as expected so we would like to add two additional LUNs (taken from two additional raid groups) and relayout the whole volume from 2-col to 4-cols e.g.: raid group: RG1RG2RG3RG4 LUN1 LUN7 LUN13 LUN19 LUN2 LUN8 LUN14 LUN20 LUN3 LUN9 LUN15 LUN21 LUN4 LUN10 LUN16 LUN22 LUN5 LUN11 LUN17 LUN23 LUN6 LUN12 LUN18 LUN24 Is it possible to order relayout of existings volumes to spread it over all four RGs ? Can I point somehow that it should relayout using these particular LUNs ? Regards Przemyslaw Bak (przemol) -- http://przemol.blogspot.com/
Re: [Veritas-vx] Relayout volume from 2 to 4 columns
So, assume your queue depth is 10, and you need a 1TB volume. You can present a 1TB LUN, and your whole SCSI queue for that volume is 10. If you present 2 500GB LUNs, your combined SCSI queue is 20 - one SCSI mailbox per LUN. If you present 10 100GB LUNs, you get a combined queue of 100. If you're doing small-block Oracle, with 95-98% cache read rates on the array (not unheard of), you can process more I/Os in-flight at any given point in time. You do make the valid point that making changes such as this can move the bottleneck from being storage-bound to being cpu-bound, and that's a not-uncommon result of this tuning on under-provisioned hardware. When I do this exercise with my customers, we probably run into that problem ~half the time. As to stripe vs. concat specifically -- using a more artificial example, imagine you're putting together a 100GB volume. If you concatenate it as 2 50GB LUNs, you'll use one of the SCSI queues only, until you've filled up the first 50GB, then you'll start using both queues (mostly - this is an example). If you made the volume from, say, 10 10GB LUNs, you have a greater mathematical chance of any in-flight I/Os sorting across multiple queues, thus raising your overall I/O the application can request at any given time. Again, I want to stress that this does not mean this is *always* the right way to go, YMMV, please consult your local tuning professional or BOFH, etc. This is just an argument for why you'd ever _want_ to do it, using artificial examples. Most applications at most entities do not need this level of storage discipline. Those that do need it often stop falling over every night, by a simple storage change (or learn they need more box to meet SLAs, empirically). ZFS masks the gory details, but ZFS == VxFS + VxVM, there are just different features in each product suite. Underneath the filesystem, it is still a RAID volume created on the host, that's managed by software - even if it's just one LUN. ZFS has features SF doesn't, and vice-versa, and we also have a CLI front-end that removes most of the complexity of the product for simple setups. My personal opinion is they fill different niches, ultimately, and neither is better, just better at some tasks. As to the Oracle issue, that's what the ODM API from Oracle solves, amongst other solutions . This article (http://blogs.sun.com/bobs/entry/one_i_o_two_i ) explains the benefits of concurrent, unbuffered I/O for Oracle better than I am able to. Cheers, jf As always, anything sent to this list are my own thoughts, and I speak only for myself. From: veritas-vx-boun...@mailman.eng.auburn.edu [mailto:veritas-vx-boun...@mailman.eng.auburn.edu] On Behalf Of Hudes, Dana Sent: Wednesday, January 06, 2010 11:10 AM To: William Havey Cc: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] Relayout volume from 2 to 4 columns So indeed this feature turns your $$$ Hitachi 9990V into a JBOD. Wow. I guess there are products that need this sort of thing. And enterprises where the people running the SAN array can't manage it properly so the server administrators have need of bypassing them. The other question of SCSI queues one per column as a benefit of striping is interesting. Doesn't this just generate extra disk i/o? The array is already doing RAID with 2 parity stripes. Now what? Yet this is effectively what ZFS does so there must be a performance gain. Hmm. Multiple SCSI queues actually might possibly make sense if you have a large number of CPUs (like the Sun 4v architecture esp. 5240 with 128 cores or 5440 with 256, or a 4+ board domain on the SunFire 25K which gives you 32 cores) all of which are running threads that do disk i/o. This benefit seems more practicaly in the ZFS approach where you have one volume-equivalent (the zpool is both disk group and VM volume in that it has storage layout) and many filesystems so you would likely have multiple processes doing independent disk i/o. In the VxVM one volume one filesstem model your e.g. Oracle table space is in one filesystem as one huge file (possibly other databases are files in other filesystems). Even if you have multiple listeners doing their thing ultimately there's one file they're working on...of course Oracle has row locking and other paralleization hmm. From: William Havey [mailto:bbha...@gmail.com] Sent: Wednesday, January 06, 2010 12:30 PM To: Hudes, Dana Cc: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] Relayout volume from 2 to 4 columns Yes, it certainly does. And that is why Symantec put the feature in the VM product; to use host-based software to construct and control storage from host to physical disk. This would help eliminate multi-vendor chaos in the storage aspects of the data center. On Wed, Jan 6, 2010 at 12:19 PM, Hudes, Dana hud...@hra.nyc.gov wrote:
Re: [Veritas-vx] changing vxdmp iopolicy on live volumes
Using vxdmpadm disable ctlr=cX to disable one path administratively (or other individual disable syntax as-needed) is the best-practice for doing SAN work. Iopolicy can be set on the fly -- are you sure you have the correct ASL/APM packages for NetAPP storage for your version? Having the wrong/missing APM (Array Policy Module) can cause problems during administrative path work. Cheers, jf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Romeo Theriault Sent: Friday, November 21, 2008 4:11 PM To: veritas-vx@mailman.eng.auburn.edu Subject: [Veritas-vx] changing vxdmp iopolicy on live volumes I was under the impression that changing vxdmp's iopolicy on the fly was supported. I recently changed a live Solaris 9 hosts vxdmp iopolicy from round-robin to singleactive and a handful of it's FCP SAN volumes went offline with read/write errors. I quickly switched the iopolicy back to round-robin and was able to get the offlined volumes back online with some fsck's, etc All of the volumes have two paths through different FCP cards and switches. So was I wrong, is changing the iopolicy on vxdmp not a safe thing to do? Should I have done something differently? This is what I did: vxdmpadm setattr enclosure FAS30500 iopolicy=singleactive On a related topic, the person whom I've replaced didn't leave the FCP switch passwords behind so we need to reboot the switches to their bootprom to reset the passwords. I was really hoping that I'd be able to change the iopolicy on the Solaris/Veritas machines to singleactive and then change their primary controller for a time being so I could reboot the FCP switches one at a time to reset their passwords, thus removing the need to shutdown all of the machines. Is this possible? Thanks for any hints and help on the matter, -- Romeo Theriault System Administrator Information Technology Services ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] VxVM Serial Split Brain
From an internal technote, so no link, sorry: Background: The Serial Split Brain condition arises because VERITAS Volume Manager (tm) increments the serial ID in the disk media record of each imported disk in all the disk group configurations on those disks. A new serial (SSB) ID has been included as part of the new disk group version=110 in Volume Manager 4 to assist with recovery of the disk group from this condition. The value that is stored in the configuration database represents the serial ID that the disk group expects a disk to have. The serial ID that is stored in a disk's private region is considered to be its actual value. If some disks went missing from the disk group (due to physical disconnection or power failure), the serial IDs for the disks in their copies of the configuration database, and also in each disk's private region, are updated separately on that host. When the disks are subsequently re-imported into the original shared disk group, the actual serial IDs on the disks do not agree with the expected values from the configuration copies on other disks in the disk group. It then goes into the splitlines routine, and the same basic information that exists in public technotes on the topic. Cheers, jf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Bishop Sent: Thursday, July 24, 2008 7:59 AM To: veritas-vx@mailman.eng.auburn.edu Subject: [Veritas-vx] VxVM Serial Split Brain Hi all, I'm using VxVM 4.1 MP2 on Solaris 9 and have a strange problem. I'm trying to add some disks to a diskgroup and I get the following error: # /usr/lib/vxvm/bin/vxdisksetup -fi c2t216000C0FF892131d10 # /usr/lib/vxvm/bin/vxdisksetup -fi c2t216000C0FF892131d11 # vxdg -g TeachFS-DG adddisk TeachFS-DGa01=c2t216000C0FF892131d10s2 TeachFS-DGa02=c2t216000C0FF892131d11s2 VxVM vxdg ERROR V-5-1-10127 associating disk-media TeachFS-DGa01 with c2t216000C0FF892131d10s2: Serial Split Brain detected. Run vxsplitlines The reason I'm doing this is because we had an array failure which took out half of our mirror. The disks I'm trying to add back are on the failed array, but the problem appears to be with the part that didn't fail (DGa01 and DGa02 are the failed ones, DGb01 and DGb02 the good ones): # /usr/lib/vxvm/bin/vxsplitlines -g TeachFS-DG [ ## ] VxVM vxsplitlines NOTICE V-5-2-2708 There are 1 pools. The Following are the disks in each pool. Each disk in the same pool has config copies that are similar. VxVM vxsplitlines INFO V-5-2-2707 Pool 0. c2t216000C0FF808C08d10s2 TeachFS-DGb01 To see the configuration copy from this disk issue /etc/vx/diag.d/vxprivutil dumpconfig /dev/vx/dmp/c2t216000C0FF808C08d10s2 To import the diskgroup with config copy from this disk use the following command /usr/sbin/vxdg -o selectcp=1128803667.95.qetesh import TeachFS-DG The following are the disks whose ssb ids don't match in this config copy TeachFS-DGb01 TeachFS-DGb02 So I checked the ssb ids on the disks themselves: # vxdisk list c2t216000C0FF808C08d10s2 | grep ssb ssb: actual_seqno=0.0 # vxdisk list c2t216000C0FF808C08d11s2 | grep ssb ssb: actual_seqno=0.0 And then in the config on the disks: # /etc/vx/diag.d/vxprivutil dumpconfig /dev/vx/dmp/c2t216000C0FF808C08d10s2 | grep ssb ssbid=0.2 ssbid=0.2 # /etc/vx/diag.d/vxprivutil dumpconfig /dev/vx/dmp/c2t216000C0FF808C08d11s2 | grep ssb ssbid=0.2 ssbid=0.2 So the problem looks fairly obvious. I expect deporting and reimporting will fix it (the configs on the disks are otherwise identical). But I'm curious how this came about in the first place. This volume has, as far as I'm aware, not been unmounted during the problems. And I added disks to the group not that long ago. So my question is, does anyone have any idea why this might occur? Thanks, Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 ___ 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 x86 Storage Foundation MP1
5.0MP1 has not been released for x64 Solaris. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Glanzmann Sent: Tuesday, July 08, 2008 9:52 AM To: veritas-vx@mailman.eng.auburn.edu Subject: [Veritas-vx] Solaris 10 x86 Storage Foundation MP1 Hello, is there a Storage Foundation 5MP1 Update available for Solaris 10 _x86_? I downloaded ,,sxrt5.0MP1.dvd1.tar.gz'' which seems to include the updates for Linux, Windows, HPUX, Aix, Solaris Sparc, but not Solaris x86. Is there a different distribution for Sparc x86 or is SF5MP1 not available for Solaris 10 x86? Thomas ___ 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] Upgrading Veritas 5.0
RPs are cumulative, so only installing the latest RP would cut down some time, but not a lot. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Kaiser Sent: Tuesday, July 08, 2008 2:59 PM To: Chuck Sedlacko; veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] Upgrading Veritas 5.0 Have you considered Solaris LiveUpgrade and the VxVM LU support script that came with 5.0? Not a good fit if you have data volumes on an encapsulated boot disk, but otherwise should simplify. The installer does have a tendency to overrecommend reboots, I know that one unnecessary reboot was ID'd a while back (post-5.0GA) perhaps it is yours but you'd need to check with support. We plan to fix that in a future release (and do our best to reduce/eliminate upgrade reboots generally). Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chuck Sedlacko Sent: Tuesday, July 08, 2008 6:44 AM To: veritas-vx@mailman.eng.auburn.edu Subject: [Veritas-vx] Upgrading Veritas 5.0 I want to upgrade Solaris 9 servers running Storage Foundation 4.0 MP2 (just volume manager and file system) to Veritas 5.0 with the lated MP and RP patches. The procedure I've been following below takes about 3 hours and 4 reboots. Can any of these steps be combined/streamlined to eliminate 1 or more reboots? For example, do I really need a reboot between the installer script and running the installer -configure script ? What exactly does the installer -configure script do? Can I run this script in single user mode? And if so, can I add the patches say either immediately after running the installer or the installer -configure scripts? Here's the procedure I've been following from the Veritas Storage Foundation Installation Guide, pages 83-84 1) Boot the server in single user mode (15 minutes) 2) Mount the installation packages 3) Run the installer script which prompts me to upgrade my storage foundation sofware. (40 minutes) After the installer script completes I get this message. At least one package will require a reboot prior to configuration. Please reboot and run installer -configure on the following systems after reboot has completed: So I need to do a reboot at this point and run the installer -configure option? It doesn't say if I need to bring the server all the way up to multi-user mode or if just single user mode is sufficient. I know I've had issues with the GUI until I run this script, so for my initial upgrades, I brought the server all the way up to multi-user mode. 4) reboot the server to multi-user mode (15 minutes) 5) remount the installation packages 6) run the installer -configure script (5-10 minutes) At this point, I still can't use the GUI (even though all my file systems are available) until I reboot. I also have to add the latest patches so I once again reboot to single user mode... 7) reboot the server to single user mode (10 minutes) 8) Mount the patch directory 9) run the installmp script to install MP1 (25 minutes) 10) Apply the relative patches from RP1, RP2, RP3, RP4 (10 minutes) 11) Reboot the server to multi-user mode (15 minutes). I'd like to minimize my downtime. Any help/suggestions/comments are appreciated. Thanks, Chuck -- |Chuck Sedlacko | Golf is 20 percent mechanics and technique. |LEXIS-NEXIS | The other 80 percent is philosophy, humor, |P.O. Box 933 | tragedy, romance, melodrama, companionship, |Dayton, Ohio 45401 | camaraderie, cussedness, and conversation. |937-865-1781 | -- Grantland Rice ___ 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] VFS snapshots as a way to undo changes?
Yeah, I inverted the two in my mind when I first sent that. Sorry I haven't responded with a correction -- travel in the Midwest is all-consuming this time of year. :) Cheers, jf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Kaiser Sent: Tuesday, February 26, 2008 12:15 PM To: A Darren Dunham; Veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] VFS snapshots as a way to undo changes? Checkpoints can be mounted r/w, I don't think snapshots can be. Try # fsckptadm create ckpt1 /data # mount -F vxfs -orw,ckpt=ckpt1 /dev/vx/dsk/datadg/datavol:ckpt1 /ckpt1 Regards, Scott -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A Darren Dunham Sent: Sunday, February 24, 2008 10:12 PM To: Veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] VFS snapshots as a way to undo changes? On Fri, Feb 22, 2008 at 03:13:36PM -0700, Joshua Fielden wrote: You can mount snapshots r/w. Does that require a particular version? $ mount -F vxfs -o rw,snapof=/mnt /dev/vx/dsk/testdg/test2 /mnt2 vxfs mount: conflicting suboptions: ro and rw. vxfs mount: Usage: [blah...] $ mount -F vxfs -o snapof=/mnt /dev/vx/dsk/testdg/test2 /mnt2 $ mount | grep /mnt2 /mnt2 on /dev/vx/dsk/testdg/test2 read only/setuid/snapof=/mnt/nolargefiles/dev=1b5b969 on Sun Feb 24 22:17:11 2008 -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOShttp://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area This line left intentionally blank to confuse you. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] You can be lucky
Also, for the future: usedisk Profile Keyword usedisk disk_name ... By default, the JumpStart program uses all of the operational disks on the system when you specify partitioning default. The usedisk profile keyword designates one or more disks that you want the JumpStart program to use. You must specify disk_name in the form cxtydz or cydz, for example, c0t0d0 or c0d0s0. If you specify usedisk in a profile, the JumpStart program uses only the disks that you specify after the usedisk keyword. :) jf -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hudes, Dana Sent: Tuesday, February 26, 2008 1:06 PM To: Robinson, Greg; veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] You can be lucky You really ought to go to version 5 of SF on Solaris 10. Make sure to install not only the Master Patches but the Rolling Patches as well. Also make sure to not only run Solaris 10 update 4 but also that you are using Update Connection to keep your system reasonably up-to-date. Mirror your root with SVM. Veritas has some claim to advantage for SAN LUNs over using ZFS, due to the Array Support Libraries that they claim give extra performance. If you have an application that demands every ounce of I/O from the SAN and you have a 4 Gbit FC SAN (you mentioned iSCSI, is that what you're using for your SAN? OMG...hope it's at least running gigabit speed...the 5120 has the capacity to have 10G Ethernet, I might do iSCSI on that but not on 100baseT) OR you're doing something ...interesting...like VVR but otherwise? Sure, if you're running Oracle you've got SFORA. = 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 Robinson, Greg Sent: Tuesday, February 26, 2008 2:38 AM To: veritas-vx@mailman.eng.auburn.edu Subject: [Veritas-vx] You can be lucky Hi all, We had a server crash today (a T2000 - Solaris 10, vxvm 4.1 with some patches). The root disk did not survive, and so we had to rebuild the server. It wasn't mirrored either - long story involving iSCSI The server was still zoned to the SAN disks (about 56) of them, and we jump started it. Jumpstart selected the root disk, as per our jumpstart configuration, but the root disk that it chose was a SAN disk! :-( Subsequently, one of our plexes was overwritten (Important safety tip there!): DEVICE TYPEDISK GROUPSTATUS Disk_0 auto:none --online invalid EVA3_0 auto:cdsdiskProjects05 Projects online EVA3_1 auto:cdsdiskProjects04 Projects online EVA3_2 auto:none --online invalid EVA3_3 auto:cdsdiskProjects01 Projects online EVA3_4 auto:cdsdisksystem01 system online EVA3_5 auto:cdsdiskProjects06 Projects online -- Projects02 Projects failed was:EVA3_0 So, I removed the failed disk and re-initialised it and then replaced it. Now, this disk was used by 3 volumes. 2 of them have been recovered but the 3rd has not: Disk group: Projects TY NAME ASSOCKSTATE LENGTH PLOFFS STATETUTIL0 PUTIL0 dg Projects Projects ----- - dm Projects01 EVA3_3 -524252928 - -- - dm Projects02 EVA3_2 -1048540928 - -- - dm Projects04 EVA3_1 -1048540928 - -- - dm Projects05 EVA3_0 -1048540928 - -- - dm Projects06 EVA3_5 -1300166400 - -- - v Model fsgenDISABLED 1048576000 - ACTIVE - - pl Model-02 Model DISABLED 1048576000 - RECOVER - - sd Projects02-01 Model-02 ENABLED 209715200 0-- - sd Projects04-01 Model-02 ENABLED 838860800 209715200 - - - Even though it says RECOVER, a full fsck has failed. A full fsck on the other 2 has brought them back to life. My questions: 1. Can I be confident in the other 2 volumes? The install of solaris only lasted for about 45 seconds and only installed about 2 GB. 2. Should I restore from backup all 3 affected volumes just to be sure? 3. Why did a re-initialise of this LUN not lose the data? Was it only the header that was initialised and not the data on the rest of the disk? Thankx, Greg. IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx ___
Re: [Veritas-vx] [Veritas-ha] problem setting up I/O fencing
Are they less than 21MB in size? -Original Message- From: Zhisong Jason Jin [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 07:44 AM US Mountain Standard Time To: [EMAIL PROTECTED]; veritas-vx Subject:Re: [Veritas-ha] problem setting up I/O fencing Hi, gurus: I'm trying to setup I/O fencing for a newly build cluster running: Solaris 9, VCS 3.5 GA and VXVM 3.5, that connected to EMC CX700. we use this older verison to testing upgrade to 4.x. a few LUNS were carve out from EMC and are seeing on the host. and I'm try to use the 3 LUNS to setup the coordinator disk. the three LUN(disk) I need to use are c3t5006016110205AADd2 c3t5006016110205AADd3 c3t5006016110205AADd4 each are showing up in format with 4 paths: # echo | format | grep ADd2 14. c2t5006016910205AADd2 DGC-RAID5-0219 cyl 254 alt 2 hd 1 sec 16 15. c2t5006016010205AADd2 DGC-RAID5-0219 cyl 254 alt 2 hd 1 sec 16 26. c3t5006016810205AADd2 DGC-RAID5-0219 cyl 254 alt 2 hd 1 sec 16 27. c3t5006016110205AADd2 DGC-RAID5-0219 cyl 254 alt 2 hd 1 sec 16 however # vxdg init vxfencoorddg c3t5006016110205AADd2 c3t5006016110205AADd3 c3t5006016110205AADd4 vxvm:vxdg: ERROR: Device c3t5006016110205AADd2 not found in configuration vxvm:vxdg: ERROR: Device c3t5006016110205AADd3 not found in configuration # vxdisk list c2t5006016910205AADd4 vxvm:vxdisk: ERROR: Disk c2t5006016910205AADd4: Disk not in the configuration # vxdisk list DEVICE TYPE DISK GROUPSTATUS EMC_CLARiiON0_0 sliced--error EMC_CLARiiON0_1 sliced--error EMC_CLARiiON0_2 sliced--error c1t0d0s2 sliced--error c1t0d0s6 simplerootdisk rootdg online # vxdisk -e list DEVICE TYPE DISK GROUPSTATUS c#t#d#_NAME EMC_CLARiiON0_0 slicedEMC_CLARiiON0_0 oraproddgonline c2t5006016910205AADd5s2 EMC_CLARiiON0_1 slicedEMC_CLARiiON0_1 oraproddgonline c2t5006016910205AADd1s2 EMC_CLARiiON0_2 slicedEMC_CLARiiON0_2 oraproddgonline c2t5006016910205AADd0s2 c1t0d0s2 sliced--error c1t0d0s2 c1t0d0s6 simplerootdisk rootdg online what's wrong? your comments or advice is much appreciated. Thanks. Jason ___ Veritas-ha maillist - [EMAIL PROTECTED] http://mailman.eng.auburn.edu/mailman/listinfo/veritas-ha ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] [Veritas-ha] problem setting up I/O fencing
The RAC docuentation specifies 20MB or greater, but I concede that the standard CVM/VCS docs probably don't. The interop issue is in 5x73 EMC firmware, the 'gatekeeper bit' was changed to mean 'gatekeeper, or high LUN address' as part of supporting LUNs numbered higher than 8k (if memory serves, possibly just LUNs higher than 'ff'). There is code in some versions of VolMgr to look for that bit set, AND LUN size less than (or possibly equal to -- still going from memory here) 20MB, and assume the device is a gatekeeper if those two facts intersect. There is a hotfix, or just grow the LUNs to 21MB. jf -- All above statements are my own, and come with no endorsement or warranty, etc. -Original Message- From: Ceri Davies [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 31, 2007 11:22 AM US Mountain Standard Time To: Joshua Fielden Cc: Zhisong Jason Jin; [EMAIL PROTECTED]; veritas-vx Subject:Re: [Veritas-vx] [Veritas-ha] problem setting up I/O fencing On Tue, Jul 31, 2007 at 09:12:44AM -0700, Joshua Fielden wrote: Are they less than 21MB in size? Is that likely to cause a problem? The VCS documentation for I/O fencing specifically says that: Symantec recommends using the smallest possible LUNs for coordinator disks. and: Any disks that support SCSI-3 Persistent Reservation can be coordinator disks. Best practice is to select the smallest possible LUNs for use as coordinator disks. If that means LUNs over 21MB then it should say that (which is not to say that this isn't a requirement, just that the VCS documentation implies that it isn't). Ceri -- That must be wonderful! I don't understand it at all. -- Moliere ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
