Re: [Veritas-vx] Linux: lvm versus Veritas VxVM?
Jon Price wrote: Hi, How does Linux lvm compare with Veritas VxVM for Linux? Or pointers to existing comparisons or helpful docs about this? Not so well in terms of features, but better in terms of widespread use. * in vxvm lets you do everything from raid-0 to raid-6. lvm doesn't do mirror. * in vxvm you can relayout a volume efficiently on the fly, and it's easy. * with vxvm/vxfs you can grow and shrink volumes dynamically. Most linux filesystems only allow you to grow. the concepts for the volume managers are somewhat similar.. You divide a disk into chunks (subdisks in vxvm) and you group these together to form a volume. In VXVM there is an intervening stage called a plex which is a grouping of chunks, usually into a raid set, then the volume can be one or more of these. There are lots of other features you can add on to vxvm fairly easily too, features for database snapshotting, dirty region logging for fast resynch, remote site replication for DR, clustering, etc. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] add column disk on striping volume
Thomas Graham wrote: Dear All, I want to perform adding column disk to existing 500GB x 2 striping volume, here is the questions: 1. if they are stripping, do I need to add it in one pair? 2. what is the steps before apply vxassist -g diskgroup relayout volume ncol=+2 ? 3. how could VxVM knows which two column disks should be add to existing volume diskgroup? You want the vxassist relayout command, and you can explicitly tell it where to put the two new columns by using the disk names (that you have already initialized with vxdisksetup or the like) ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Can I increse /opt partition under veritas
Hudes, Dana wrote: having /opt as a separate filesystem isn't supported by Solaris. You can have stuff under /opt (e.g. /opt/coolstack) as a separate filesystem but putting /opt separate will cause problems. This isn't theoretical. I tried the same thing and it worked for awhile then it didn't and the system was in single user mode for agonizing time while I frantically remounted /opt as /a and moved it's contents back to the root filesystem. /var as a separate filesystem is well-supported. There was a bug for awhile but it's fixed. I had a trick that fixed this a long while ago.. I did have /opt as a vxvm partition, but to avoid the catch-22, I mirrored all the /opt/VRTS stuff to the root partition underneath it. It's hackish, but it worked. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] vxresize - but df(1) doesn't see new space ... ?
Wilkinson, Alex wrote: Hi all, I have a LUN that I need to expand via vxresize #df -h . FilesystemSize Used Avail Use% Mounted on /dev/vx/dsk/RDL_DG/VOL01 17T 8.7G 16T 1% /export I found the exact free space available via: #vxdg -g RDL_DG free And then successfully did a resize via: #/etc/vx/bin/vxresize -g RDL_DG -F vxfs VOL01 +12502704 All looked good (from vxresize's prespective). However, parted(1) can see the expanded space but the partition table will not allow me change its label: #parted /dev/sda GNU Parted 1.8.1 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: DGC RAID 5 (scsi) Disk /dev/sda: 23.6TB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End SizeFile system Name Flags 1 131kB 33.8MB 33.7MB 2 33.8MB 17.7TB 17.7TB (parted) resize 2 17.7tb 23.6tb Error: Could not detect file system (parted) As you can see parted(1) does detect that /dev/sda is 23.6TB. df(1) does not see the new expanded 23.6TB but rather the old 17.7TB. Can anyone suggest why a vxresize would work perfectly fine yet tools such as df(1) cannot see the new space on the expanded LUN ? I have also tried a partprobe /dev/sda which had no effect. As well as rebooted. OS is Centos 5.3 x86_64. Thanks! you might explicitly try doing fsadm -b to grow the filesystem to the size of the volume and see if that works... (I assume you're using vxfs for the filesystem?) ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] RHEL 16TB LUN Limit and VxFS ?
-Original Message- From: veritas-vx-boun...@mailman.eng.auburn.edu [mailto:veritas-vx-boun...@mailman.eng.auburn.edu] On Behalf Of Jon Stanley Sent: Monday, May 04, 2009 3:51 PM To: Wilkinson, Alex Cc: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] RHEL 16TB LUN Limit and VxFS ? On Mon, May 4, 2009 at 6:01 AM, Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au wrote: Can anyone tell me if this limit is for the out-of-the-box filesystems such as ext3, xfs, jfs etc ? And if this is the case would it be possibe to use VxFS on a LUN larger than 16TB on RHEL ? Yeah, RHEL support 16TB native filesystems (ext3), it's not a limitation on LUN size, but rather what the filesystem can do. VxFS is capable of more, obviously. However, the sanity of such a large filesystem I'll leave for another conversation.. vx FWIW - zfs supports very large filesystems without breaking a sweat. We use it in production, but it scares some. The replication and checkpointing facilities are nice. We have 40+TB filesystems (only because that's how many disks will fit in the box vs any other reason). There is no FSCK in zfs, for better or for worse. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Query 1
i man wrote: All, I plan to decomission one node which has a VCS and some disks assigned to VXFS. The node has to be removed from VCS and then reinstall the OS on the system. VXFS has some disks coming from EMC SAN. Do I need to remove the disks from the VXFS before I reinstall the OS so as to not create any problems on the SAN side. I have switched off all the service groups and removed the node from the VCS cluster already. Also would it be wise to uninstall the VXFS from the node ? you don't need to do anything special for the reinstall. During that process, you can explicitly designate which disks get the OS installed on them. Removing VxFS is unnecessary. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Fwd: vxunreloc for veritas 2.4
following the top posting.. to use vxsd mv, you must first make the subdisk on the destination by hand using vxmake. something like vxmake -g tooldwnld-dg sd disk24-01 dm_name=disk24 dm_offset=0 len = 17678493 vxsd -o rm mv d012-01 disk24-01 (this last operation will take a long time) Check vxmake man pages for proper details on names and usage for vxmake. Robinson, Greg wrote: Hi James, not sure about 2.4, but 3.5 and above has option 14 in the vxdiskadm menu which sounds right up your alley. failing that, the vxassist move option might do the same. So, at a guess, something like: vxassist -g tooldwnld-dg move tooldwnld \!d012 disk24 (please dont use that command without further investigation and testing) It also looks like vxsd mv option can also move subdisks. That one looks simplier to understand than my vxassist command. I'd be more confortable with option 14 from vxdiskadm though. Hope this helps, Greg. *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *James Chavez *Sent:* Monday, 20 October 2008 8:47 AM *To:* veritas-vx@mailman.eng.auburn.edu *Subject:* [Veritas-vx] Fwd: vxunreloc for veritas 2.4 Doug, From an address without the confidentiality trailer. Hello, I have a question for the list regarding vxunreloc or something similar for veritas volume manager 2.4. I have a volume as shown below that is mirrored on 2 arrays c0 and c2, with 1 plex on each array. I had a failed disk, disk24 (c2t15)and hot relocation replaced it with d012 shown below as c0t1d2. This is not good because c0t1d2 is on the on the wrong array. So the plex is not properly mirrored since now if the c0 array goes down, the volume will have no valid plex. I replaced the failed disk which was disk24 (c2t1d5) and veritas now sees it again. I do not believe there is a vxunreloc available for vxvm 2.4. So my question is how can I relocate the stripe now contained on d012 (c0t1d2) back to disk24 (c2t1d5) so I can have all the stripes for this plex on the same array? Also do I have to take the volume offline to do this first? I would not think so since the plex on c0 will not be modified. Thank you James v tooldwnldfsgenENABLED ACTIVE 7000 SELECT- pl tooldwnload-01 tooldwnld ENABLED ACTIVE 70713981 STRIPE4/32 RW sd disk29-01tooldwnload-01 disk29 017678493 0/0 c0t2d3 ENA sd disk30-01tooldwnload-01 disk30 017678493 1/0 c0t2d4 ENA sd disk42-01tooldwnload-01 disk42 017678493 2/0 c0t3d2 ENA sd disk43-01tooldwnload-01 disk43 017678493 3/0 c0t3d3 ENA pl tooldwnld-02 tooldwnldENABLED ACTIVE 70713981 STRIPE4/32 RW sd d211-01 tooldwnld-02 d211 017678493 0/0 c2t1d1 ENA sd disk35-01tooldwnld-02 disk35 017678493 1/0 c2t2d2 ENA sd d012-01 tooldwnld-02 d012 017678493 2/0 c0t1d2 ENA -- used to be disk 24, c2t1d5 sd disk37-01tooldwnld-02 disk37 017678493 3/0 c2t2d4 ENA ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Grow a filesystem on an existing volume
Balu manyam wrote: As David said, fsadm is the direct way. Another way is to use vxresize to resize the volume and the filesystem at once. (it calls fsadm under the hood). you'll probably like vxresize when you need to change things as it simplifies your life and is easier to remember than fsadm. also - is vxresize intelligent to call growfs automatically for UFS ? yes (says so in the man page) ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Grow a filesystem on an existing volume
Hazel, Geoff wrote: This has got to be simple but in all the years I've worked with Veritas I've never done it. Never needed to until now. I have two systems that are twins to each other. The vxprint -ht outputs are identical. They both have volumes configured to 10gb. One of them has a filesystem on the volume that fills it up, at 10gb. The other one is just 1.4 gb filesystem, with 8.5 gb hanging around doing nothing. I want to expand the 1.4 gb filesystem to fill the volume like the other one does. I know this has to be simple (at least I hope it is) but I don't know how to do it. As David said, fsadm is the direct way. Another way is to use vxresize to resize the volume and the filesystem at once. (it calls fsadm under the hood). you'll probably like vxresize when you need to change things as it simplifies your life and is easier to remember than fsadm. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] rename vm objects
Munish Dhawan wrote:
Hi Friends,
is there any short quick way except vxedit command to rename the VM
obects ? basically why iam concerned for this is if i have no of VM
objects which i want to rename, is there a way i can edit the vxvm
conf file and dump that configuration so that new names are in effect.
why not use vxprint and awk, sed, or other regular expression to
generate a new name from old names and then just run it through vxedit?
Let's say the old object name is LUN and the new name is bob
vxprint -vpsdt -g diskgroup | nawk $2 ~ /LUN/ '{newobj=$2;
gsub(LUN, bob, newobj); print vxedit rename $2newobj}'
If the output looks the way you want, you can pipe it into a shell
command to execute.
___
Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Reattach a detached plex question.
Chavez, James R. wrote: Hello Doug and list. I have a rather easy one for you guys. Solaris 5.5.1 Sun Enterprise Volume Manager 2.5. Here is the volume in question. Plex db2-02 is detached due to an io failure for sub disk may05-d3-01 or c5t48d0. The messages log hasn't had any errors since September regarding this physical disk. So I want to reattach this plex db2-02 to this volume db2 to see if it will resynchronize. If it fails or gives any errors I will have the disk replaced and resync at that time. My questions.. 1) What is the correct command to use to reattach db2-02 to db2 in the situation below without taking the db2 volume offline? I am thinking vxplex att db2 db2-02. 2)Will I have to use vxmend to place the plex in the stale state first? Not sure of the exact steps. Thank you James v db2 fsgenENABLED ACTIVE 8704 SELECTdb2-01 pl db2-01 db2 ENABLED ACTIVE 88392861 STRIPE5/128 RW sd a4f1-01 db2-01 a4f1 017678493 0/0 c4t1d0 ENA sd a4f2-01 db2-01 a4f2 017678493 1/0 c4t2d0 ENA sd a4f3-01 db2-01 a4f3 017678493 2/0 c4t3d0 ENA sd a4f4-01 db2-01 a4f4 017678493 3/0 c4t4d0 ENA sd may05-d2-01 db2-01 may05-d2 017678493 4/0 c4t22d0 ENA pl db2-02 db2 DETACHED IOFAIL 88392861 STRIPE5/128 RW sd disk06-01db2-02 disk06 017678493 0/0 c5t33d0 ENA sd disk07-01db2-02 disk07 017678493 1/0 c5t34d0 ENA sd disk08-01db2-02 disk08 017678493 2/0 c5t35d0 ENA sd disk09-01db2-02 disk09 017678493 3/0 c5t36d0 ENA sd may05-d3-01 db2-02 may05-d3 017678493 4/0 c5t48d0 ENA Thank you James You probably will have to use vxmend to fix the plex first and then the vxplex typed should function fine as well. Worst case, you can destroy the plex (and only the plex) and then recreate it and reattach the subdisks to it using vxsd and then reattach it to the volume using vxplex, but it shouldn't come to that. The point is, it's recoverable. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Help reading vxprint output - beginners questions
Aleksandr Nepomnyashchiy wrote: Dear Guru's, Couple of questions about the striped-mirror volume below: 1. Why the volume size ( 20971520 ) doesn't match the size of any of the plexes ( 20974356 and 20977888 ) ? 2. Why the sizes of 2 plexes don't match ( 20974356 and 20977888 ) ? 3. Why the sizes of subdisks are different between plexes (6991380 and 6992608 ) for the same layout and column size? 4. Why the total size of 3 subdisks is less than the plex size ? Plex HUB2_DB_DATA04-01 : 3*6991380 = 20974140 less than 20974356 (difference is 216) Plex HUB2_DB_DATA04-02 : 3*6992608 = 20977824 less than 20977888 (difference is 64) So you don't paste the disk information, but I suspect that the disks for the subdisks of the first part are different model than the disks of the subdisk of the second part and thus have different perceived cylinder sizes. Now, in the modern world these sizes don't matter and are largely imaginary (a lot of under-the-hood virtualization is going on), but long ago cylinder sizes were important and meaningful. Veritas still tries to make things line up on cylinder boundaries, and that is what you are seeing. The sum of the subdisks becomes the plex size which can be different among different models of disks. Roughly, the volume will try to line up on boundaries of blocks and will be less than or equal to the smallest plex component and line up on the greatest common block size. The amount of space lost as a result is infinitessimal. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] vxfs filesystem full - can not expand.
Sengor wrote: Hi colleagues, Recently we've had a situation where a mounted vxfs filesystem was @ 100% usage (no free space) on Solaris 9, SF5. So we thought great we'll go and increase the volume the filesystem and be done with it. To our unpleasant surprise fsadm returned error saying filesystem can not be expanded due to it being full (even though volume has been expanded already). We tried deleting some files from the affected fs, to no avail. As root, even rm trying to zero out some of the files simply refused to work due to the filesystem being full. Now from what I understand there's no such thing as minfree root reserved space for vxfs, which would allow the fs to be expanded once it's full. I'm quite disappointed to see vxfs not reserve any space on the side for it's own administrative purposes, since fs being @ 100% is when you need to expand the filesystem the most, out of any other case scenarios. How do people go about resolving or avoiding the issue of not being able to expand the filesystem once it's full? Are there any precautions/safeguards to consider when the fs is being created initially? Perhaps some means of reserving administrative fs space (without quotas) ? Thank you. You can still expand it, just pick a small number.. a block or two.. that gives you some space to expand it slightly more, and then slightly more, and so in. It's not ideal, but it's a known issue and it works. grow by a few bytes and then double and double and double until you get where you want it to be. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Q About DRL Log Recovery
Paul Liong wrote: Hi Doug Hughes, Thanks for your update. However, I just wonder if we could change the log plex state using 'vxmend' to perform the recovery. Thanks Regards Paul I don't think so, but it's been a while. you can do the remove and re-add totally online without taking the volume offline -- quickly and easily -- while access is happening to the filesystem. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] VVR - inconsistent cant_sync fail
Ganesh Persaud/SYS/NYTIMES wrote: Hi All, VVR secondary host lost storage connectivity causing VVR primary host replication to fail. see the flags below. The question is does this need a full resync? flags:write enabled attached inconsistent cant_sync fail connected asynchronous did you have SRL enabled? DCM? If SRL is enabled and DCM is not, you have to do a full resync. If DCM is enabled, you can likely do it without a full resync. I strongly suggest opening up a symantec support ticket because recovery from weird failures and issueing the wrong command can make the difference between full and partial resync. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Help replacing disks and resyncing plexes.
Chavez, James R. wrote: Hello all, Thank you in advance for your help. OS = Solaris 5.5 Volume manager version = 2.5 I have a question regarding the below volume. I have a 5 column striped volume. There are 2 plexes with one being perfectly fine and one having 2 failed disks. I don't want the plex to try and resync before I can run the vxdiskadm commands to replace the disks. My question is before shutting down and replacing the disks what commands do I run to prepare the plex? Do I run a vxplex det db2-01? Or do I run a vxmend off db2-01? Also before I remove the disks for replacement. The disks are already failed, so do I need to select option 4 remove a disk for replacement from vxdiskadm? Or can I just shutdown the box replace the failed disks, boot up and select option 5 Replace a failed or removed disk And finally to get the plex online after the disks are replaced. Do I need to run a vxmend fix db2 stale then vxrecover -s db2 to resync the volumes? Not sure what commands to use to resync the failed plex with the good plex. Thank You much James -- a4r4 rootdg failed failing was:c4t20d0s2 -- a4f1 rootdg failed failing was:c4t1d0s2 -- a4f2 rootdg failed failing was:c4t2d0s2 v db2 fsgenENABLED NEEDSYNC 8704 SELECTdb2-02 pl db2-01 db2 DISABLED NODEVICE 88392861 STRIPE5/128 RW sd a4f1-01 db2-01 a4f1 017678493 0/0 - NDEV sd a4f2-01 db2-01 a4f2 017678493 1/0 - NDEV sd a4f3-01 db2-01 a4f3 017678493 2/0 c4t3d0 ENA sd a4f4-01 db2-01 a4f4 017678493 3/0 c4t4d0 ENA sd may05-d2-01 db2-01 may05-d2 017678493 4/0 c4t22d0 ENA pl db2-02 db2 ENABLED ACTIVE 88392861 STRIPE5/128 RW sd disk06-01db2-02 disk06 017678493 0/0 c5t33d0 ENA sd disk07-01db2-02 disk07 017678493 1/0 c5t34d0 ENA sd disk08-01db2-02 disk08 017678493 2/0 c5t35d0 ENA sd disk09-01db2-02 disk09 017678493 3/0 c5t36d0 ENA sd may05-d3-01 db2-02 may05-d3 017678493 4/0 c5t48d0 ENA you do not need to shutdown, the replacement of the two disks can be done live using vxdiskadm because you have a mirror. vxvm will not try to resync the plexes until the bad plex is clean. I can't remember if this is automatic when vxdiskadm finds that you have fixed all the subdisks in the plex or if it's manual in that old version of vxvm, but it will certainly be fixed at the next volume start, if nothing else, or you can fix it with vxmend/vxrecover. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Error trying to import rootdg due to stale root plexes.
Chavez, James R. wrote: Hello, I have a problem that I hope the group can help me with. Here is a refresher for my original problem. First both fibre channels went out on my arrays causing both root plexes to be stale. I also must mention that the controller WWN changed on the array so I had to rebuild the device links in /dev/rdsk and /dev/dsk with a reconfig reboot after cleaning the stale ones out. After this I can see all disks from format and they have the same device address such as c0t0d0s0 for example. Now since there are 2 root plexes stale I need to boot from the disk slices instead of veritas volumes. Also I am able to boot from both veritas root disks using the slices after changing vfstab. So I received a doc from a group member that had a procedure to fix this very stale plex problem. Great doc but I am having a bit of trouble. When I follow the steps below from the doc I get an error. Here are the steps I am takingNote that I did not need to restore because I am able to boot from the original root disks.(step 2) 1. Boot from net or cdrom. Partition the primary bootdisk base on its original partition table before first time encapsulation. 2. Restore from Tape or any other media to the new primary rootdisk 3. Upon finished restoring, You could disable Volume manager from starting up during next reboot. - Edit /etc/system. Comment out the vx parameter as follow: *rootdev:/pseudo/[EMAIL PROTECTED]:0 *set vxio:vol_rootdev_is_volume=1 - cd /etc/vx/reconfig.d/state.d/ - rm *. This should remove root-done - touch install-db - cp -p /etc/vfstab /etc/vfstab. - cp -p /etc/vfstab.prevm /etc/vfstab - init 6 4. Manual start the Volume Manager service - vxiod set 10 - ps -ef |grep vxconfigd. If vxconfigd is not running, then run /usr/sbin/vxconfigd -m disable - vxdctl mode. Should see it is in disabled mode. - vxdctl init - vxdctl enable Here is where I get the problem..I receive.. vxvm:vxconfigd: ERROR: enable failed: Error in disk group configuration copies No valid disk found containing disk group; transactions are disabled. vxvm:vxdctl: ERROR: enable failed: Error in disk group configuration copies. I know that these disks are valid...they are all the same. Can you guys help me to take the next step? Will a vxinstall help? Also Warning Forceload drv/ses failed comes up when booting...but I see the arrays through ssaadm and format. For those i emailed directly I apologize..I am in a bind here. I eagerly await the wisdom of the group. Sincerely James Chavez 602-768-2455 CONFIDENTIALITY This e-mail message and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail message, you are hereby notified that any dissemination, distribution or copying of this e-mail message, and any attachments thereto, is strictly prohibited. If you have received this e-mail message in error, please immediately notify the sender and permanently delete the original and any copies of this email and any prints thereof. ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform Electronic Transactions Act or the applicability of any other law of similar substance and effect, absent an express statement to the contrary hereinabove, this e-mail message its contents, and any attachments hereto are not intended to represent an offer or acceptance to enter into a contract and are not otherwise intended to bind the sender, Sanmina-SCI Corporation (or any of its subsidiaries), or any other person or entity. ___ have you tried something slightly simpler? pull one of the root disk mirrors and then try to boot as-is (without the changed /etc/vfstab or /etc/system) If that doesn't work, try the other one and pull the opposite one. did you end up booting from net or from cdrom and is the version of vxvm that it contains the one that you have on the host? ___ 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
Robinson, Greg wrote: 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? 1) can you be confident of the integrity of the filesystem? yes can you be confident it has all of your files? possibly.. How long did the fsck take? How many unusual things did it do? Have you checked in lost+found? vxdiskinit only writes a tiny portion of the disk, the private region. The public region and data are still intact. If you have another copy of the disk layout you can restore this and the data is still there totally uneffected. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Multiple rootdisks?
Craig Simpson wrote: Has anyone used more then just 2 disks to mirror rootdg? Because I have to do some odd migration stuff, I want to have 3 rootdisks. rootdisk, rootmirror, and rootraidmirror. Just wondering if rootdg should only be mirrored by 2 disks, or if more then that is OK. more than 2 is plenty fine. it is N-way capable. A reference paper was even written on the subject more than 6 years ago. ___ 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?
Ray Arachelian wrote: I wonder if it's possible to use snapshots to undo changes to a file system without having to copy everything back? I'm not too familiar with what snapshots can do in VXFS, so that's why I'm asking... in VxFS, you can use the 'checkpoint' capability to do exactly this. There's even a text based admin tool that allows you to rollback to a previous version. *NOTE: if you mount a checkpoint r/w and make changes, the automatic rollback facility becomes disabled (if I recall correctly), but there are still ways to accomplish it. Rolling back to a checkpoint in VxFS is fairly easy. (There's also a version of the Database Edition for Oracle, Sybase, etc that allows you to rollback the filesystem containing the database to a previous checkpoint without having to recover the database) We have a procedure we run a few times a year (Disaster Recovery test) where we take a cold backup of our Oracle server's data files (i.e. shut down oracle, tar up the dbf and related files), do our DR test and then roll back by shutting down Oracle and restoring the backup. I'm sure that very few records are touched, but of course the dbf files themselves are huge... you should ask about Database Edition, it makes this rollback capability very, very easy. you can run the vxdba command, choose which checkpoint you want to rollback to, and it will do it. (see above caveat). additional caveat: If you have filesystem level corruption event, your checkpoint is most likely also corrupted. So I think I can get rid of a lot of time and effort by using a VFS snapshot. checkpoint in this case, but yes, a whole lot of time. The only twist is that I want to keep the normal filesystem the same. Is there a way to do this while avoiding copying the data out of the snap and over to the live mountpoint to undo all of the changes? a. that's a major twist.. You could do this with a mirror though. Break off your mirorr plex, rollback your filesystem on your current plex, test our oracle, then stop oracle, disable the volume, destroy the volume (yes, you read this correctly), remake the volume attached to the detached mirror plex from step 1, then start the volume and re-mirror. I suppose I could hack something up with rsync, but that would probably be almost as time consuming as just copying the snap volume data back to the main volume. you can do it all without any copies, just let vxvm resync the mirrors. (slow, but in the background) ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Realigning sub-disks
Denton, Sam wrote: Doug Hughes wrote: Denton, Sam wrote: Disk Group: datadg Volume: db1 Plex: db1-01 Sub-disk: c6t0d69-01 (16gb, leave alone) Sub-disk: c6t0d70-01 (8gb, expand to 16gb) Volume: db3 Plex: db3-01 Sub-disk: c6t0d70-02 (8gb, remove this) Sub-disk: c6t0d199-01 (8gb, leave alone) Sub-disk: c6t0d200-01 (8gb, leave alone) My initial plan was to just add the new disks to datadg, then vxevac altair-emc09, however I can't see how to control where the sub-disks wind up. if you want fine granularity you can use vxmake to make the new subdisk of exactly the same size at the new location (or bigger, is actually fine). then you can use vxsd -o rm mv c6t0d70-02 targetsubdisk I'm putting together the list of commands that will be used, and I'm wondering if I can grow a subdisk that's at the head of a plex, as is the case with the second volume. I suspect that I'll need two new subdisks, one the same size as c6t0d70-02, and one to add to the end of the plex. Is this correct? that's the easiest way, yes. Then you can do vxsd join. BTW, here's my command list so far. It assumes that the disks are c6t0d901 and c6t0d903. The actual numbers will have to be determined. Enter the following to add all newly added devices: # vxdiskadd c6t0d901 c6t0d903 (Many questions to answer here.) Enter the following to create new subdisks (16gb and 32gb): # vxmake -g datadg sd c6t0d901-01 altair-emc11,0,3552 # vxmake -g datadg sd c6t0d903-01 altair-emc13,0,7104 Note: The lengths shown are approximate, the exact value will have to be determined via the vxprint command. Enter the following to migrate all data from the old sub-disks: # vxsd -o rm mv c6t0d70-01 c6t0d901-01 # vxsd -o rm mv c6t0d70-02 c6t0d903-01 Enter the following to create one more sub-disk on the evacuated device: # vxmake -g datadg sd c6t0d70-01 altair-emc09,0,3552 Enter the following to associate the subdisk to the appropriate plex: # vxsd assoc db1-01 c6t0d70-01 A.G. Edwards outgoing and incoming e-mails are electronically archived and subject to review and/or disclosure to someone other than the recipient. A.G. Edwards is a division of Wachovia Securities, LLC. I'm not used to the above vxmake syntax. Perhaps it is new or I haven't been paying attention. I'm used to vxmake -g datagd sd c6t0d901-01 disk=altair-emc11 offset=0 length=3552 if it's part of a stripe, you'll also need to include the strip position information in vxsd. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] replace encapsulated root disk
Neil Swallow wrote: Hello, Having lost an encapsulated root disk (called rootdisk) running vxvm 3.5 on solaris 2.6, and kept the server running on the mirror (normal vx initialized disk) I can't now use vxdiskadm to replace the disk. When I go to replace it, it insists that the public region is too small. Looking at the old vtoc, this is true. VM wants to initialize a disk that I want layed out as though it had been encapsulated.I've tried things like `vxdisksetup -i disk old_layout` but again this tries to initialize to the standard 2 slice layout where the original had a public region of the entire disk with the private and original slices sat inside this in whatever magical manner VM manages to carry that out. Is there anyway I can lay the disk out as I want and then just tell VM to trust me that it's initialized/encapsulated and let me go on and re-mirror or will the sync ignore the old slices anyway as it splats the data back on? If there's no way forward I'm looking to have to remove the mirror totally, add the replacement disk as a new one and mirror back, losing the ability to boot from the underlying devices (unless I start looking at vxmksdpart which looks a bit daunting). Any suggestions greatfully received you can use vxdisksetup by hand and there's an option in there (though I can't remember what it is exactly) to use old layout, then you can use vxassist to mirror the volumes over one at a time and vxsdmkpart to put the partition labels onto the disk from the volume location. Much like the procedure for deencapsulating a root disk at http://www.eng.auburn.edu/~doug/howtos/vxdocs.html at step 11 ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Realigning sub-disks
Denton, Sam wrote: We've noticed that some of the storage for one of our servers is not configured according to our site's best practices. Specifically, two different logical volumes (db1 and db3) are sharing one VM disk (altair-emc09, aka /dev/dsk/c6t0d30s2). Would it be possible to remove that device from db3? We are preparing to add stoage to each volume, doubling their current size. VM Disk: altair-emc03 Sub-disk: c6t0d199-01 (8gb, leave alone) VM Disk: altair-emc04 Sub-disk: c6t0d200-01 (8gb, leave alone) VM Disk: altair-emc08 Sub-disk: c6t0d69-01 (16gb, leave alone) VM Disk: altair-emc09 Sub-disk: c6t0d70-01 (8gb, expand to 16gb) Sub-disk: c6t0d70-02 (8gb, remove this) VM Disk: altair-emc11 (new 16gb device) VM Disk: altair-emc12 (new 32gb device) Disk Group: datadg Volume: db1 Plex: db1-01 Sub-disk: c6t0d69-01 (16gb, leave alone) Sub-disk: c6t0d70-01 (8gb, expand to 16gb) Volume: db3 Plex: db3-01 Sub-disk: c6t0d70-02 (8gb, remove this) Sub-disk: c6t0d199-01 (8gb, leave alone) Sub-disk: c6t0d200-01 (8gb, leave alone) My initial plan was to just add the new disks to datadg, then vxevac altair-emc09, however I can't see how to control where the sub-disks wind up. Can anyone help? Thanks! if you want fine granularity you can use vxmake to make the new subdisk of exactly the same size at the new location (or bigger, is actually fine). then you can use vxsd -o rm mv c6t0d70-02 targetsubdisk ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Both Root plexes off line cannot boot.
Chavez, James R. wrote: Hello all, I have what I consider a dire problem. Perhaps you can help me out. The hardware layout is An enterprise 3000 Sun server connected to 2 SSA114 arrays through Fiber Channels. The situation is that the fiber channels both failed and went offline at the same time while the system was booted thus leaving both root plexes in an unclean state. The faulty hardware has since been replaced. However the system will not boot and complains that it cannot find any clean root plexes, fails to start volume manager, and goes back to the OK prompt. The root disks are encapsulated and contain the rootvol, swapvol, and usr volumes. I know that the disks are good I just do not know how to get the system to boot while the plexes are not clean. I need to get it back to a clean state. Can you please help me to fix the root plexes so I can boot. I would be appreciative for any help and guidance. Thank You James have you tried doing a boot -s with one of the disks removed? There's still a chance this might be recoverable without having to restore from backup and going through the hassles of fixing /etc/system, /etc/vfstab, and reencapsulating things. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] VxVM 4.1, mirroring issue
Rajinder Bhalla wrote: Hi Gurus, I have a small problem for which I need your help. My requirement is to copy data from one server A to a new server B but I have to do it only through Veritas VxVM mirroring. The disks from server B are dual zoned with server A. I have mirrored the plexes on Server A with the disks from server B but don have any idea how to mount them back on server B. Can someone please advice me with the steps on how can I do this. The OS I am using here is Solaris 8 do the disks stay in the same diskgroup on the two hosts or do you have two different disk groups? (seems unlikely you'd have one disk group with some volumes on one host and some on the other *without* having a cluster volume manager and filesystem, but thought I'd check) with 2 hosts and 2 diskgroups, you'd normally do vxdg deport diskgroup on the host exporting it (after unmounting the filesystem of course), and then vxdg import diskgroup on the other one. If you are moving a volume/filesystem between diskgroups you'd want the flashsnap license which makes this much, much easier. The manual way is difficult and, frankly, a bit scary to most people. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] query
bharat rohera wrote: Hi , Steps for breaking rootdg mirroring. needs to install patch so wants to break mirror and after completion of activies remirror the same Regards Bharat Rohera recommended solution: pull the disk.. yes, don't do anything before hand, just physically pull the mirror disk. If you break the mirror, you'll have a dickens of a time booting from it if your patching goes awry. If you leave the mirror alone and pull it (simulating a failure), booting from the pulled spare is trivial (just remove the other one) It's possible to do it with breaking the mirror in software, but quite tricky and time consuming. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Stripe volume question
Amit Srivastava wrote: Hi, 1) Perhaps ur all the 13disks are utilised in forming that single plex that's why u thre is no space showing in the dg . 2) To resize ur volume u need to add the same number of disks equal to ur number of columns this means u have to add 13disks for that and if u try to resize such a stripe volume by using only one disk then the temorary volumes would occupy the space of ur newly added disk .. hence no such space would be reflected in ur volume. kindly send the output of ur vxprint . re: 2) This used to be the only way to resize a volume back in VxVM 3.0, but since then a 'relayout' option has been added whereby you can turn a 13 disk stripe into a 14 disk stripe (or similar). Of course, a simple stripe has no redundancy and thus increases your risk of having to restore from tape, but you can grow things more incrementally. (Corrollary: if you have a mirror, you need at least 2 disks to relayout and increase volume size) ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Stripe volume question
Munish Dhawan wrote: Hi Friends, I have one DG having one volume which is a stripe of 13 disks ( single plex). Now vxassist -g dgname maxsize says No volume can't be made from these constraints. vxdg -g dgname free shows in length column of all 13 disks of value 128 blocks 1) my question is why vxassist maxsize is not showing any free space in DG ? Perhaps your volume is already allocated all space on those disks? It would be easy to see in vxprint -ht volume 128 blocks is like 64k. basically nothing.. 2) if I have to increase the volume. what is the minimum no of disks I have to add to the DG ? what would be the easiest and wisest way for doing this ? theoretically one disk using vxassist relayout, but in practice you also need a little scratch space in order for the relayout to do its thing. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Increase filesystem size
Jaehne, Richard S wrote: Actually, our layout is RAID 0+1. All we want to is add the extra capacity of 2 disks per mirror by growing the filesystem. There is only one filesystem on the RAID. Thanks, In that case, (as long as you aren't adding in a hidden layer of LUN redirection in hardware underneath) you just need to use relayout. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Veritas File System
[EMAIL PROTECTED] wrote: On Wed, Jul 11, 2007 at 09:21:54AM +0800, [EMAIL PROTECTED] wrote: Hi , Could any one advise me, what are parameters should recommended for oracle DB VxFs filesystems in order to achieve best performance? I asked similar question last year. Look into archive: http://mailman.eng.auburn.edu/pipermail/veritas-vx/2006-October/012363.html For best performance, I would recommend installing the Database Edition (DBED aka Veritas Foundation for Oracle) and enabling ODM. Also, tune your Oracle cluster size to be about the size of your stripe unit if possible. To be honest, though, the bulk of the performance improvements can be had by tuning the application and indexes. Different indexes can help a huge amount. (table organized or whatever - depending upon application). ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Veritas File System
Paul Hunter wrote: How do you know if a volume is under Veritas Filesystem control? run the fstyp (no e) utility on the device. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Resize problem
Khurram Tariq wrote: Hi All, I have a 201GB volume which is composed of two LUNs (40GB 200GB). Now I want to free up the 40GB LUN from that volume by shrinking the volume to 198GB but vxresize is giving me the following error: UX:vxfs fsadm: ERROR: V-3-20343: cannot shrink /dev/vx/rdsk/some-dg/volumea - blocks are currently in use. VxVM vxresize ERROR V-5-1-7514 Problem running fsadm command for volume volumea, in diskgroup some-dg The current utilization on the volume is 103GB leaving 92GB free space. I'm running Solaris 9 and VxVM 5.0MP1. Regards, Khurram sometimes you can get around this by doing a defrag operation first (fsadm -d -e) and then shrinking the filesystem (and try shrinking in littler bits instead of the entire big chunk, though it shouldn't really make any difference.) -- Doug - http://lopsa.org/SysadminDays ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] un-encapsulate VxVM
Paul Hunter wrote: Is it possible/recommended to un-encapsulate boot drives in Solaris? Can it be done without data loss? yes, and yes. it has been a practice for many years. (You do have to reboot though) see: http://www.sun.com/blueprints/0800/vxvmref.pdf ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Mirroring storage
indeed. to summarize: if you have veritas foundation enterprise you should have a VVR license, and if not, it's an extra add-on. (from memory) robertinoau wrote: Since you got VM, use Veritas Volume Replicator. You might need to get a license key to enable it though. --- [EMAIL PROTECTED] wrote: -- Doug - http://lopsa.org/SysadminDays ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] How to setup 500gb as one file system in solaris 9
milind phanse wrote: Hi All, I have solaris 9 server with Veritas file system.The server is having external EMC storage( DMX 300 ) with 500gb space. I want to have 500gb to be set up as one file system. Can you help me doing this. It's very easy, really. Create the Logical unit on the EMC (LUN), make sure your Solaris9 box can see it in 'format', (may require a reconfigure reboot, depending what stage you are at), create a volume using your new logical unit, and create a filesystem using the new volume. The last two steps look something like (but differ in details) vxassist -g emcdg create volume newvol 500g /usr/lib/fs/vxfs/mkfs -F vxfs -o largefiles /dev/vx/rdsk/emcdg/newvol (or you can use the web GUI) ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Encapsulated Boot Disk Question
Fred Butler wrote:
Experts,
I ran into the following error this past weekend after performing an
upgrade. Here is what I did:
1)I had to upgrade a system from Solaris 9 to Solaris 10 Update 2
(06/06 Relaese)
2)The root disk was encapsulated and mirrored so I pulled the
mirror drive, for safe keeping after I verified it was bootable.
3)Next I unencapsulated the rootdisk and proceeded with my Solaris
10 Upgrade, OS Patching, Veritas Upgrade (3.5 to 4.1) and EMC
PowerPath Upgrade. (Note: All went well!)
4)After completing my upgrade I placed the mirror disk back in the
system and attempted to boot off of it one more time to make sure I
can fail back it all is not OK.
5)The mirror disk booted just fine with the previous OS (Solaris
9) and all the applications started. (Test Passed!)
6)Now, before turning the system back over to the application team
to perform testing I attempted to boot the machine from the primary
disk which was upgraded.
7)Upon doing so I received the error below:
NOTICE: VxVM vxdmp V-5-0-34 added disk array 720841, datype = EMC
NOTICE: VxVM vxdmp V-5-0-34 added disk array DISKS, datype = Disk
Apr 14 06:58:37 vxvm:vxconfigd: V-5-1-554 *Disk c1t0d0s2 names group
rootdg, but group ID differs*
Apr 14 06:58:38 vxvm:vxconfigd: V-5-1-1049 System boot disk does not
have a valid rootvol plex
Apr 14 06:58:38 vxvm:vxconfigd: Please boot from one of the following
disks:
Apr 14 06:58:38 vxvm:vxconfigd:
Apr 14 06:58:38 vxvm:vxconfigd: DISK MEDIA
DEVICE BOOT COMMAND
Apr 14 06:58:38 vxvm:vxconfigd:
Apr 14 06:58:38 vxvm:vxconfigd: rootmirror
c1t1d0s2boot vx-rootmirror
Apr 14 06:58:38 vxvm:vxconfigd:
Apr 14 06:58:38 vxvm:vxconfigd: V-5-1-8259 System startup failed
syncing file systems... done
Program terminated
{0} ok
8)The way that I resolved this issue was to remove the mirror
drive and boot off the primary again. This worked.
The question I have for the team is can someone explain what happened
here? Also, it appears to me that Veritas keeps a record somewhere
(Private Region?) of the rootdg Group ID it last successfully booted
from. Is this a correct assumption?
Regards,
Fred Butler
I believe the problem here is you have a disk you removed from the
system.. so on the remaining disk, that plex is marked as bad.. Then you
stuck it back in without removing the other one. So when vxvm starts up,
sees it has 2 disks, both have rootvol, but one is marked as bad on the
other one. It doesn't like that. If you physically pull a disk (the
right thing to do in this situation to preserve bootability), you must
never have both disks in at the same time during a subsequent boot. you
can put it back in *after* boot and reinitialize it after everything is
good, but it will
be forever tainted in a dual boot situation, without further action.
In summary, once you physically pull your root mirror, only have one in
or the other one, but never both for a boot.
___
Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] resizing a device
Jarkko Airaksinen wrote: Summary! In case someone else is fighting with the same problems I thought I'd share my conclusion with you. I've decided not to resize the LUNS / file systems at all as Solaris 8 is quite restrictive with LUN resizing. I've overcome the need for resizing them with a bit of thinking. Given the variables (Sol8, EVA, VVM5, Oracle9i, Tape / EVA backups and most importantly, our needs) I've come to a conclusion that: 1. If we need more space for the growing data I'll just create another file systems to their own groups, for example DATA01 and DATA02 to data01dg and data02dg etc. Also for some reason distributing data / arch / redo files to separate file systems a bit improves the performance of our application. 2. With the practice mentioned above I only need to resize (shrink) a disk when the data doesn't grow anymore and this happens only once a year when the year is closed. I can do this by calculating the space needed for the data and creating a new file system for it, move the data on the new disk and destroy the old one. Wouldn't it be easier just to allocate the new disks/luns (as needed) and just move and resize the volume on the new space? There's really no need to create a new filesystem as long as you have the unused space someplace. You can do moves on the fly within the same diskgroup without anyone being the wiser and with no user impact. As simple as that. No need to fiddle with temporary disks and the one-lun-per-diskgroup is safe (no concat file systems). The only single point of failure is the SAN and with its three-level internal data protection the only reasonable threat is the complete destruction of it. ___ Veritas-vx maillist - [EMAIL PROTECTED] http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Move a single volume to another diskgroup
Gummadidala, Ramu (GE, Corporate, consultant) wrote: Ronald - I guess 'vxdg mv' requires an additional licenses ? It requires FlashSnap. (which adds another kind of log to keep track of detached mirrors to enable fast resynch, as well as enabling moving of disks between diskgroups) ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] getting SAN disks online for solaris
On Fri, 2006-12-22 at 09:26 -0800, Ed S. Peschko wrote: hey all, We are having a great difficulty getting veritas disks online here, and I was hoping that some of you might have good pointers. First of all, is there a FAQ out there for vxfs and veritas in general? I searched the archives of this mailing list and couldn't find a current link. I fear that we have done half the steps to put the disks online and are missing something, and we just now . once they are presented and accessible by the OS, all you have to do is run vxdctl enable, then you can add them using something like vxdiskadm (or vxdisksetup or similar). vxdiskadm also has the capability to rescan the device tree (equivalent of vxdctl enable) For some luns prevented from some devices, you may need to run format and make sure the device has a label prior to vxdctl enable. Second, is there a step-by-step guide on adding disk space from a SAN and seeing it mounted on a solaris server? We've added space in the past and have had no issues. The SAN is a storagetek D-178.. Depends on the SAN device. How you get it presented to the OS can be very dependent on the SAN device you are presenting from. Once the OS can see if and it has a label, vxdctl enable followed by vxdiskadm is easy way to get them under veritas control. VxFS is independent of that. Third, is there a simple way to see all unallocated but available space that veritas could provide to the system? I was trying: vxdisk -q list vxdg free to get a list of raw device names, and: vxdisk -q list raw_device_name to get attributes for those devices, but that does not seem to be complete. It does not, for example, show some of the vxfs entries that I get from 'df -k'. df -k shows you filesystems. vxdisk list shows you raw disk devices. it goes something like this. raw disk (or LUN) gets turned into a vmdisk (vxdisk list) vmdisks get carved up and turned into volumes filesystems get created on volumes and show up in df -k Anyways, I guess I'm looking for some starting points. I'm starting from ground zero here, so some basic level advice would be nice. (I'd read the FAQ, but there seems to be no FAQ!) the administrator's guide covers the relationship between volumes, disks, plexes, subdisks, and diskgroups pretty well. Thanks much, Ed ___ 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] getting SAN disks online for solaris
On Fri, 2006-12-22 at 10:33 -0800, Ed S. Peschko wrote: df -k shows you filesystems. vxdisk list shows you raw disk devices. it goes something like this. raw disk (or LUN) gets turned into a vmdisk (vxdisk list) vmdisks get carved up and turned into volumes filesystems get created on volumes and show up in df -k First of all, thanks for the response. I did so happen to miss an extra layer of abstraction, or three... A few followups: do you happen to know the corresponding commands showing these layers? eg: Raw disk unallocated to the box == (I'm assuming this is an ASM question, but I'm putting it here for completentess ) well, there's the disk that is on your SAN that your OS can't see. The only way to get this amount is via tools that can detect luns and their zones. You sort of have to know what is here (often easier from the device attached to the san). Then there's the stuff that is presented to the OS that veritas doesn't recognize yet. You can usually see these by doing vxdisk list and seeing those VM disks with an 'error' state. Disk groups == vxdg Raw disk devices: vxdisk list volumes: ??? filesystems: df (or vxdf equivalent?) Also, is there a way to show if free space has been allocated in error to veritas? I'm noticing that when I say: vxdisk list some of the entries are showing up as invalid, or in error. For example: vxdisk -q list c10t0d0s2 Device:c1t0d0s2 devicetag: c1t0d0 type: sliced flags: online error private autoconfig errno: Disk is not usable Multipathing information: numpaths: 1 c1t0d0s2state=enabled It means that they probably haven't been initialized under vxvm control yet. Is there a way to get more detail on the errors that are here, at a more descriptive level? It just means the disk isn't under vxvm control. That can boil down to two reasons (in the general case). 1) the device was under vxvm control but has failed 2) the device is newly added and addressed by the OS but has not been initialized by VxVM yet. And finally, should I be needing to touch /etc/mnttab at all? no. that's a dynamic hook into the kernel via a special filesystem. (like procfs or swap) I notice that all the successful filesystems for veritas have corresponding entries in mnttab, but don't see any of the intended filesystems there.. Could it be as simple a matter as someone forgetting to put entries there? /etc/vfstab is where one puts entries of things that should be mounted persistently at boot. mnttab is updated automatically when things are mounted and unmounted. It is read-only. the administrator's guide covers the relationship between volumes, disks, plexes, subdisks, and diskgroups pretty well. unfortunately, I don't have access to the administrator's guide (unless its available somewhere online in PDF format). it is. support.veritas.com Its still a bit fuzzy on how all this fits together, ie: how the SAN allocation software handshakes with the OS and the veritas software, but I'm a quick learner (well, I've got to be. I've got to get this done today!) disk storage systems present logical units (LUNs) to the SAN in a Zone. The host machine looks for devices in a zone on the SAN and format shows them. (assuming you have some sort of reasonable driver that will automatically detect things on the SAN without a reboot - otherwise you need to do a reboot -- -r) Once you see them in format and have apply a label, vxdctl tells veritas to rescan the tree and they show up in vxdisk list. Then you can run vxdiskadm and initialize the new 'disks'. Thanks much for any help, Ed ___ 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] ?????? Re: Layered volume: 2 sub-volumes of 3 are disabled, why the volume(STRIPE) is still enabled and active ???
On Thu, 2006-12-21 at 15:30 +0800, kaiyi wang wrote: Hi Doug, Thanks for your reply... Still I have one question How do you know the volume is unusable already??? In other words, if it's unusable, why it is enabled and active in the output of vxprint Thanks Regards Wang Kaiyi that is the top-level volume that doesn't stricly have any errored disk components, even though the subvolumes are unusable. Layered volumes are a bit weird in that respect. If/When you try to mount it, it certainly won'twork though. And arguably, it should probably be disabled if one of the subvolumes is broken. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
[Veritas-vx] spam to list
I've eliminated last week's and today's spam from archives and put some extra filters on the lists to help prevent. The spammers managed to either 1) impersonate legit people on the list or 2) get their spam bots to figure out how to subscribe to lists, verify the subscription, and then make posts. (truly evil) 3) both (looks like this may be the truest one given that toppills is an unusual username) ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] encapsulation if there is no free space
On Fri, 2006-12-01 at 16:22 +0200, Asiye Yiğit wrote: Hi All, we are using EMC as a storage. The size of data is very huge. It is approximately 4TB. We will implement SF HA in our environment. we are using disks as block devices. I mean they are not under the control of VxVM. However, for VCS implementation, I need to take disks under the VxVM control. The HW are completely different. One of them is Sun Fire E6900 and SF V890. There are some requirements to encapsulate the disks. At least 2048 sectors must be free at the beginning of the disk or at the end of the disk and it must not belong any slices.Besides this, there must be two free partitions. The customer use all disk size in one partition. The customer does not want to destroy the disk layout due to the production data. So, is there any way to encapsulate such a disk without spoiling the disk layout? Personally, I always eschew encapsulation where possible. But, to answer your question, no, you cannot encapsulate without free cylinders and 2 free slices on the disk. It sounds like you have the latter but not the former. If it's vxfs, you can shrink it. If it's not, you have to dump/restore or get it in by some other means. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] encapsulation if there is no free space
On Fri, 2006-12-01 at 09:42 -0800, Schipper, Mark wrote: AlrightI would not recommend trying this (yet), but I want to float this by this list for feedback. You *may* be able to: - install Solaris Volume Manager (used to be called DiskSuite) - create some state database replicas on other disks - create a disk device that is larger than your existing data device - make sure the new device contains a slice with the same geometry as the existing device - reserve space and slices on the new device for future encapsulation - mirror existing device to new (larger) device with disksuite, using same-sized slice on destination drive - break your old device off and reclaim that storage - at that point you could revert back to a non-SVM environment and encapsulate the new larger device with VXVM - proceed with the usual VXVM and VCS build It's a convoluted solution but it beats a 4TB restore or 2 months worth of rsync. Any holes in there? if it's smaller number of larger files, a copy to a new filesystem ought to only take a day at a relatively modest 40MB/sec. doing disksuite would spread the time out and result in smaller downtime, but would also require at least one reboot to effect. (maint window) ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] growing a VVR volume
On Mon, 2006-10-23 at 10:11 -0400, Paul Keating wrote: Just installed a bunch of extra disks in a pair of my V880s. Currently replicating a volume with VVR, and would like to extend thevolume. Currently a 68 gig volume on a pair of 72Gig disks on the primarybackplane, as well as a 20Gig SRL on another pair of 72s on the samebackplane. Just installed a new backplane and a pair of 146Gig drives. The current volume's layout is mirrored/concatenated, though it's onlya single mirrored pair. I would like to extend the volume and FS, onto the newly installed146Gig drives, asnd if possible, change the layout the mirrored/striped. Extending the volume/fs is fairly simple on a standalone system, but I'mwondering about any pitfalls that VVR throws into the mix. Can I just extend the VVR target, then the source? or do I need to pauseor even stop replication, then extend both volumes and resume/resync? Any advice appreciated. In VVR there is only one way to extend and that is using vradmin resizevol. You can't use vxresize or vassist to grow your volume when it is under VVR control. You can, however, do things like simple conversions from 0+1 to 1+0 without difficulties, and I usually recommend having a 0+1 before growing as in older version of VxVM growing a 1+0 could result in some difficult to understands (though redundant) results in vxprint. * this may be better in 4.0, I haven't checked. VxSF and VVR are both 4.0. Paul La version française suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank ofCanada does not waive any related rights. Any distribution, use, or copying of thisemail or the information it contains by other than the intended recipient isunauthorized. If you received this email in error please delete it immediately fromyour 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 unepersonne autre que le ou les destinataires désignés est interdite. Si vous recevezce 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 votreordinateur toute copie du courriel reçu. ___ 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] Please help me understanding vxprint output
On Wed, 2006-10-04 at 07:38 +0100, Veritas Manager wrote: Hi Doug, Thanks..One related question.In Mirror volume ,pls consider the case ,that mirror volume is made of say four disks.One plex of two disks and one plex of another two disks. Now one of the disk goes bad ,and the volume come to DISABLE and the Plex to RLOC.My question ,when the volume was a mirror ,why it went to DISABLE and also what does RLOC means ? When I replaced the disk in A1000 box ,I had to recover the volume by stoping and starting it. A mirror volume can never go to DISABLE if one disk fails. If it did, it wasn't properly mirrored in the first place. RLOC means it's trying to run a relocation of the failed disk. What kind of logical unit did you create in the A1000? TIA Regards New Bie Doug Hughes [EMAIL PROTECTED] wrote: On Sun, 2006-10-01 at 08:02 +0100, Veritas Manager wrote: Hi Experts, Please help me in understanding How to find out from the vxprint -htcommand output that a particulart volume is either Mirror , or Simple Concate or Raid 5 . this is a 0+1 volume (striped and then mirrored). Notice it is made of 2 plexes and the size of the volume is the same as the size of the constituent plexes. (a mirror can also be mirror of 'concat' instead of mirror of stripe)v r5minarc oss_rvg ENABLED ACTIVE 1795686400 SELECT - fsgen pl r5minarc-01 r5minarc ENABLED ACTIVE 1795686400 STRIPE 2/1280 RW sd Jstor2_0-01 r5minarc-01 Jstor2_0 0897843200 0/0 c3t1d0 ENA sd Jstor2_1-01 r5minarc-01 Jstor2_1 0897843200 1/0 c3t1d1 ENA pl r5minarc-02 r5minarc ENABLED ACTIVE 1795686400 STRIPE 2/1280 RW sd Jstor1_0-01 r5minarc-02 Jstor1_0 0897843200 0/0 c2t0d0 ENA sd Jstor1_1-01 r5minarc-02 Jstor1_1 0897843200 1/0 c2t0d1 ENA this is a concat. Notice that the size of the volume is the sum of the sizes of the constituent plexes. Also notice there is only one plex.v tvol1 ! -ENABLED ACTIVE 409600 SELECT- fsgen pl tvol1-01 tvol1ENABLED ACTIVE 410238 CONCAT- RW sd v880-0-06tvol1-01 v880-0 13585942 205119 0 c1t0d0s7 ENA sd v880-2-02tvol1-01 v880-2 62916642 205119 205119c1t2d0 ENA A raid volume will clearly say RAID under usetype. They are easy to tell from everything else.___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that ICICI Bank or its subsidiaries and associated companies, (collectively ICICI Group), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of ICICI Group.Before opening any attachments please check them for viruses and defects. __ Find out what India is talking about on - Yahoo! Answers India Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] Please help me understanding vxprint output
On Sun, 2006-10-01 at 08:02 +0100, Veritas Manager wrote: Hi Experts, Please help me in understanding How to find out from the vxprint -ht command output that a particulart volume is either Mirror , or Simple Concate or Raid 5 . this is a 0+1 volume (striped and then mirrored). Notice it is made of 2 plexes and the size of the volume is the same as the size of the constituent plexes. (a mirror can also be mirror of 'concat' instead of mirror of stripe) v r5minarc oss_rvg ENABLED ACTIVE 1795686400 SELECT - fsgen pl r5minarc-01 r5minarc ENABLED ACTIVE 1795686400 STRIPE 2/1280 RW sd Jstor2_0-01 r5minarc-01 Jstor2_0 0897843200 0/0 c3t1d0 ENA sd Jstor2_1-01 r5minarc-01 Jstor2_1 0897843200 1/0 c3t1d1 ENA pl r5minarc-02 r5minarc ENABLED ACTIVE 1795686400 STRIPE 2/1280 RW sd Jstor1_0-01 r5minarc-02 Jstor1_0 0897843200 0/0 c2t0d0 ENA sd Jstor1_1-01 r5minarc-02 Jstor1_1 0897843200 1/0 c2t0d1 ENA this is a concat. Notice that the size of the volume is the sum of the sizes of the constituent plexes. Also notice there is only one plex. v tvol1-ENABLED ACTIVE 409600 SELECT- fsgen pl tvol1-01 tvol1ENABLED ACTIVE 410238 CONCAT- RW sd v880-0-06tvol1-01 v880-0 13585942 205119 0 c1t0d0s7 ENA sd v880-2-02tvol1-01 v880-2 62916642 205119 205119c1t2d0 ENA A raid volume will clearly say RAID under usetype. They are easy to tell from everything else. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
Re: [Veritas-vx] completely removing a disk from VxVM control ?
On Mon, 2006-09-25 at 12:11 +0200, Pascal Grostabussiat wrote: Hi, I have a sun V440 with 4 internal disks and connected to a disk-array. Now I want to mirror c1t0d0 and c1t1d0. The V440 have a hardware RAID controller that I want to use. Unfortunately the Solaris raidctl utility cannot mirror those disks as long as VxVM has its hands on them. I ran vxdisk rm c1t0d0 c1t1d0 to remove those disks from VxVM. But the raidctl still returns the same error: bash-3.00# raidctl -c c1t0d0 c1t1d0 config_change_state: Error 0 It appears that VxVM still has its hand on those disks !? If I run a cfgadm -c unconfigure ... I get the following: bash-3.00# cfgadm -c unconfigure c1::dsk/c1t1d0 cfgadm: Component system is busy, try again: failed to offline: Resource Information -- - /dev/dsk/c1t1d0s2 Device being used by VxVM bash-3.00# I rebooted the machine but the disks came back in vxdisk list. I tried vxdisk destroy ... then rm ... but it did not help. My question is: how do I tell VxVM to completely remove its hands off those disks ? everything shows up in vxdisk list whether it's under vxvm control or not, so that's ok (they just show up different, usually in 'error' state or the like if not under vxvm control). You can run vxdiskunsetup on the disks to remove the VxVM private region stuff. ___ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
