Sponsored Content
Operating Systems Solaris Veritas VxVm 3.2 - Cannot unrelocate subdisk due to overlap with existing subdisks Post 302487249 by rajan_g4 on Tuesday 11th of January 2011 08:08:14 PM
Old 01-11-2011
Veritas VxVm 3.2 - Cannot unrelocate subdisk due to overlap with existing subdisks

Hi all,

New to this forum as well as the world of Veritas Volume Manager. My client is using VxVM 3.2. We just changed one of the disk which is under veritas control. I used the appropriate options in vxdiskadm to replace this failed disk. Now when I am trying to unrelocate subdisks back to the original disk, its giving me the following error:

Code:
Error: vxunreloc Subdisk globald05-01 can not be unrelocated to globald08 because it would overlap with the existing subdisks


My vxdiskadm o/p ( after I select option 14 to unrelocate subdisk ) is as follows:

Code:
Move hot-relocated subdisks back to a disk
Menu: VolumeManager/Disk/UnrelocateDisk 
 
Use this operation to move subdisks which were hot-relocated back onto the original disk that has been replaced due to a disk failure. 
This operation takes, as input, the original disk name. If the failed drive was replaced with a disk using a different name, this operation also provides an option to specify the new name.
 
Enter the original disk name [<disk>,list,q,?] list
 
globald01
globald07
globald08
 
Enter the original disk name [<disk>,list,q,?]


Please help !!

Cheers

Raj

Last edited by pludi; 01-12-2011 at 03:47 AM..
 

10 More Discussions You Might Find Interesting

1. UNIX for Advanced & Expert Users

WARNING: VxVM vxio V-5-0-2 Subdisk disk04-28 block 6654400: Uncorrectable read error

Hi , i am new to the veritas volume manager.i saw some message in /var/ad/messages like " WARNING: VxVM vxio V-5-0-2 Subdisk disk04-28 block 6654400: Uncorrectable read error".the disk04 is c2t4d0s2. i have issued some commands iostat,vxdisk list,vxprint -ht .In vxprint -ht i got a message... (1 Reply)
Discussion started by: rjay.com
1 Replies

2. UNIX for Advanced & Expert Users

Veritas VxVM & Vxfs to SVM and UFS

Hi, I have 2 hosts with Veritas VxVM and VxFS (5.0 MP3_RP2). I need to use the application filesystem's luns from these 2 hosts and mount it on another 2 hosts that are running Solaris 9 09/05 and SVM. Is there resources online or has someone tried this? (0 Replies)
Discussion started by: xor
0 Replies

3. Solaris

Veritas VxVM & Vxfs to SVM and UFS

Hi, I have 2 hosts with Veritas VxVM and VxFS (5.0 MP3_RP2). I need to use the application filesystem's luns from these 2 hosts and mount it on another 2 hosts that are running Solaris 9 09/05 and SVM. Is there resources online or has someone tried this? (4 Replies)
Discussion started by: xor
4 Replies

4. Solaris

Symantec/Veritas Volume Manager - subdisk * not in configuration

Hello, There once was a disk. Veritas thought it wasn't happy, but it really was. The disk was all alone on a plex. There was another plex, in the same volume, that was fine and happy with its own single disk. I removed the plex with the unhappy disk. Then I went into vxdiskadm, removed... (2 Replies)
Discussion started by: kity1kity
2 Replies

5. Red Hat

Partition Overlap

I have just purchased a new server running RHELS R6 from a well known supplier. The OS came pre-installed so I (as a previous almost identical server) just finished off the install. I have just been extending one of the partitions and noticed an overlap. Filesystem Size Used Avail... (5 Replies)
Discussion started by: zetex
5 Replies

6. Solaris

Urgent !! SVM, subdisks "UNEXPEXTED INCONSITENCY; RUN fsck MANUALLY

Hi, I am getting this error while server booting up, not sure how to fix this. Unable to mount these file systems /dev/md/rdsk/d51: No such device or address Can't open /dev/md/rdsk/d51: No such device or address /dev/md/rdsk/d51: CAN'T CHECK FILE SYSTEM. /dev/md/rdsk/d51: UNEXPECTED... (1 Reply)
Discussion started by: bobby320
1 Replies

7. Solaris

suncluster co-existing with Veritas Cluster

have a pair of sun servers, wanting to test drive a 2-node cluster using both software.. would like disable one of these cluster software while the othe is running.. Is it feasible at all ?? (2 Replies)
Discussion started by: ppchu99
2 Replies

8. Solaris

VCS Crashing due to inconsistency in opt (managed by VxvM)

We have a Sun Server running Solaris 10 and Veritas Cluster Server. The RAID Volumes in the Server (/ , swap, opt, var, usr) are managed by VxVm and UFS is grown on all these volumes. Lately the system has been crashing due to an inconsistency in the opt filesystem. Upon reboot we did a fsck on... (1 Reply)
Discussion started by: aji1729
1 Replies

9. Shell Programming and Scripting

Finding the Overlap

Hi Help, I am trying to find a overlap zone by compraing th etwo files which is printed below. File-1 is --- 1011 234 2967 787 235 900 435 654 File 2 is --- 1211 456 595 678 546 678 2967 787 I would like to have a o/p which just read 2967 787,'comm' doesn't seem to do the... (5 Replies)
Discussion started by: Indra2011
5 Replies

10. UNIX for Beginners Questions & Answers

How to extend a disk in veritas volume manager in veritas cluster?

Hi Experts, I wanted to extend a veritas file system which is running on veritas cluster and mounted on node2 system. #hastatus -sum -- System State Frozen A node1 running 0 A node2 running 0 -- Group State -- Group System Probed ... (1 Reply)
Discussion started by: Skmanojkum
1 Replies
vxsparecheck(1M)														  vxsparecheck(1M)

NAME
vxsparecheck - monitor Veritas Volume Manager for failure events and replace failed disks SYNOPSIS
/etc/vx/bin/vxsparecheck [mail-address...] DESCRIPTION
The vxsparecheck command monitors Veritas Volume Manager (VxVM) by analyzing the output of the vxnotify command, waiting for failures to occur. It then sends mail via mailx to the logins specified on the command line, or (by default) to root. It then replaces any failed disks. After an attempt at replacement is complete, mail will be sent indicating the status of each disk replacement. The mail notification that is sent when a failure is detected follows this format: Failures have been detected by the Veritas Volume Manager: failed disks: medianame ... failed plexes: plexname ... failed subdisks: subdiskname ... failed volumes: volumename ... The Volume Manager will attempt to find hot-spare disks to replace any failed disks and attempt to reconstruct any data in volumes that have storage on the failed disk. The medianame list specifies disks that appear to have completely failed. The plexname list show plexes of mirrored volumes that have been detached due to I/O failures experienced while attempting to do I/O to subdisks they contain. The subdiskname list specifies subdisks in RAID-5 volumes that have been detached due to I/O errors. The volumename list shows non-RAID-5 volumes that have become unusable because disks in all of their plexes have failed (and are listed in the ``failed disks'' list) and shows those RAID-5 volumes that have become unusable because of multiple failures. If any volumes appear to have failed, the following paragraph will be included in the mail: The data in the failed volumes listed above is no longer available. It will need to be restored from backup. Replacement Procedure After mail has been sent, vxsparecheck finds a hot spare replacement for any disks that appear to have failed (that is, those listed in the medianame list). This involves finding an appropriate replacement for those eligible hot spares in the same disk group as the failed disk. A disk is eligible as a replacement if it is a valid Veritas Volume Manager disk (VM disk), has been marked as a hot-spare disk and con- tains enough space to hold the data contained in all the subdisks on the failed disk. To determine which disk from among the eligible hot spares to use, vxsparecheck first checks the file /etc/vx/sparelist (see Sparelist File below). If this file does not exist or lists no eligible hot spares for the failed disk, the disk that is ``closest'' to the failed disk is chosen. The value of ``closeness'' depends on the controller, target and disk number of the failed disk. A disk on the same controller as the failed disk is closer than a disk on a different controller; and a disk under the same target as the failed disk is closer than one under a different target. If no hot spare disk can be found, the following mail is sent: No hot spare could be found for disk medianame in diskgroup. No replacement has been made and the disk is still unusable. The mail then explains the disposition of volumes that had storage on the failed disk. The following message lists disks that had storage on the failed disk, but are still usable: The following volumes have storage on medianame: volumename These volumes are still usable, but the redundancy of those volumes is reduced. Any RAID-5 volumes with storage on the failed disk may become unusable in the face of further failures. If any non-RAID-5 volumes were made unusable due to the failure of the disk, the following message is included: The following volumes: volumename have data on medianame but have no other usable mirrors on other disks. These volumes are now unusable and the data on them is unavailable. If any RAID-5 volumes were made unavailable due to the disk failure, the following message is included The following RAID-5 volumes: volumename had storage on medianame and have experienced other failures. These RAID-5 volumes are now unusable and data on them is unavailable. If a hot-spare disk was found, a hot-spare replacement is attempted. This involves associating the device marked as a hot spare with the media record that was associated with the failed disk. If this is successful, the vxrecover(1M) command is used in the background to recover the contents of any data in volumes that had storage on the disk. If the hot-spare replacement fails, the following message is sent: Replacement of disk medianame in group diskgroup failed. The error is: error message If any volumes (RAID-5 or otherwise) are rendered unusable due to the failure, the following message is included: The following volumes: volumename occupy space on the failed disk and have no other available mirrors or have experienced other failures. These volumes are unusable, and the data they contain is unavailable. If the hot-spare replacement procedure completed successfully and recovery is under way, a final mail message is sent: Replacement of disk medianame in group diskgroup with disk device sparedevice has successfully completed and recovery is under way. If any non-RAID-5 volumes were rendered unusable by the failure despite the successful hot-spare procedure, the following message is included in the mail: The following volumes: volumename occupy spare on the replaced disk, but have no other enabled mirrors on other disks from which to perform recovery. These volumes must have their data restored. If any RAID-5 volumes were rendered unusable by the failure despite the successful hot-spare procedure, the following message is included in the mail: The following RAID-5 volumes: volumename have subdisks on the replaced disk and have experienced other failures that prevent recovery. These RAID-5 volumes must have their data restored. If any volumes (RAID-5 or otherwise) were rendered unusable, the following message is also included: To restore the contents of any volumes listed above, the volume should be started with the command: vxvol -f start volumename and the data restored from backup. Sparelist File The sparelist file is a text file that specifies an ordered list of disks to be used as hot spares when a specific disk fails. The system- wide sparelist file is located in /etc/vx/sparelist. Each line in the sparelist file specifies a list of spares for one disk. Lines beginning with the pound (#) character and empty lines are ignored. The format for a line in the sparelist file is: [ diskgroup:] diskname : spare1 [ spare2 ... ] The diskgroup field, if present, specifies the disk group within which the disk and designated spares reside. If this field is not speci- fied, the default disk group is determined using the rules given in the vxdg(1M) manual page. The diskname specifies the disk for which spares are being designated. The spare list after the colon lists the disks to be used as hot spares. The list is order dependent; in case of failure of diskname, the spares are tried in order. A spare will be used only if it is a valid hot spare (see above). If the list is exhausted without finding any spares, the default policy of using the closest disk is used. FILES
/etc/vx/sparelist Specifies a list of disks to serve as hot spares for a disk. NOTES
The sparelist file is not checked in any way for correctness until a disk failure occurs. It is possible to inadvertently specify a non- existent disk or inappropriate disk or disk group. Malformed lines are also ignored. SEE ALSO
mailx(1), vxintro(1M), vxnotify(1M), vxrecover(1M), vxrelocd(1M), vxunreloc(1M) VxVM 5.0.31.1 24 Mar 2008 vxsparecheck(1M)
All times are GMT -4. The time now is 05:58 PM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy