VxVM won't play with replaced SCSI disk
Created: 26 Jan 2012 | 9 comments
Hi, sure seems I'm missing something(s) easy and/or obvious, but I have tried a lot of stuff and am getting nowhere...
Platform is a very legacy Sun E2900 with dual SCSI internal disks and FC to an external array, with Veritas VM in charge of all the disk. Problem is with the internals, which are/were configured as a mirrored rootdg pair. One of the disks died and was pysically replaced, and seems to be fine (green light is now on, and cfgadm -a says connected and configured). Nothing was done with Veritas up to this point (and maybe that's the cause of the trouble?!).
The new drive seems functional, can do format and prtvtoc operations, dd data from it and all, but none of the vx commands will deal, claiming it doesn't exist:
# vxdisksetup c1t1d0 format=sliced
prtvtoc: /dev/vx/rdmp/c1t1d0s2: No such device or address
and the state according to vxdisk list is just "error":
# vxdisk list c1t1d0
Device: c1t1d0s2
devicetag: c1t1d0
type: auto
flags: online error private autoconfig
errno: Device path not valid
Multipathing information:
numpaths: 1
c1t1d0s2 state=enabled
Have tried removing the device files in /dev/vx/rdmp, followed up with "vxdctl initdmp", and a bunch of other stuff found on fora like this one, but to no avail. Thanks for any bread crumbs in advance!
Discussion Filed Under:
Comments
Can you please try following
Can you please try following commands:
devfsadm -Cv
vxdctl enable
Then try initializing the disk once again. If this does not help, please let us know following command outputs:
vxdisk -o alldgs -e list
vxprint -qhtrg rootdg
modinfo | grep -i vx
uname -a
Also checkout if you have stale device file entries in your system, if so a device tree clean up may be suggested.
Regards,
Dev
Consulting Storage Foundation, VCS, VVR and CVM/CFS on Unix. If this post has helped you, please "Vote" or "Mark as Solution" as appropriate.
Hello, please mention OS
Hello,
please mention OS version & VxVM version as well..
In case you are using VxVM 4.x ,I would suggest you to have device tree cleanup (main step to remove disk.info file)
you can refer to below article:
http://www.symantec.com/docs/TECH76780
From the above article, you can skip the emc powerpath related activities as the issue lies with internal disk...
Once you execute above steps, I would expect the new disk to be visible in "vxdisk list" output with a state of "online invalid"..
G
PS: If you are happy with the answer provided, please mark the post as solution. You can do so by clicking link "Mark as Solution" below the answer provided.
Please paste below commands
Please paste below commands outputs.
- modinfo | grep vx
- vxdisk -o alldgs -e list
- prtvtoc
~Anoop
Wow thanks for all the quick
Wow thanks for all the quick replies. Sorry, OS is Solaris 5.9 and VxVM appears to be 4.0. Tried the device cleanup procedure, but no change. Here are the outputs that were requested. Tx again.
Open A Support Case
Your best bet at this point is to open a Support Case, and have a Symantec Support Engineer guide you through the steps to get the new disk working with VxVM and synced with the remaining mirror.
It would have been a fairly easy process had you used the vxdiskadm utility to do all the work for you. If I remember correctly, you use an option in vxdiskadm to tell VxVM that you're going to replace the failed disk. Then you physically replace it. Then you use another option in vxdiskadm to perform all the steps to sync the new disk up with the remaining mirror. It does everything for you. But I think its going to be several manual steps now. Best to work with Support.
Open a support case?
Thanks, good idea but, I'm sure any support contract we may have had expired years ago. Purely desperation time here...
No more support in any case
No more support in any case for 4.0....
Lets try again to cleanup the device tree. This TN says to also cleanup the /dev/dsk and /dev/rdsk (except for c0t0 or whatever your current boot disk is...)
http://www.symantec.com/docs/TECH57018
I also found in old case notes reference to darecs file in /etc/vx that apparently existed in 4.x...
So, add that when you rename files in /etc/vx/.
Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows.
Handy NBU links
One more issue I see over
One more issue I see over here is duplicate devices:
PS: If you are happy with the answer provided, please mark the post as solution. You can do so by clicking link "Mark as Solution" below the answer provided.
I have a two node Veritas CFS
I have a two node Veritas CFS cluster. DR is provided by a remote standalone node that only runs VXVM and VXFS. For the purposes of DR, it does currently serve its purpose. However, There is a mismatch in the s/w versions. I do realise these versions have been superseeded. However, I want to get the DR system at exactly the same revision(s)..prior to planning an upg...
What is the recommended upg path/patch set ?? Many thanks..
From MP1_RP4 to MP3_RP2
Many thanks
Production
29 13a6958 3eea0 291 1 vxdmp (VxVM 5.0MP3RP2: DMP Driver)
31 7be00000 20bbf0 292 1 vxio (VxVM 5.0MP3RP2 I/O driver)
33 7bfeb508 c78 293 1 vxspec (VxVM 5.0MP3RP2 control/status d)
215 7af88000 521d8 290 1 vxfen (VRTS Fence 5.0MP3RP2)
216 7af874d8 cb0 294 1 vxportal (VxFS 5.0_REV-5.0MP3RP2f_sol por)
217 7a600000 1dcc00 21 1 vxfs (VxFS 5.0_REV-5.0MP3RP2f_sol Sun)
218 7afba000 21ec0 296 1 vxglm (VxGLM 5.0MP3 (SunOS 5.10))
236 7a7cc000 ab30 295 1 fdd (VxQIO 5.0_REV-5.0MP3RP2f_sol Qu)
DR Has :
STANDALONE DR CLUSTER
29 13a6958 3aed8 291 1 vxdmp (VxVM 5.0_MP1_RP4_HF10: DMP Driv)
31 7c002000 3409c8 292 1 vxio (VxVM 5.0_MP1_RP4_HF10 I/O drive)
33 13dd9a0 d48 293 1 vxspec (VxVM 5.0_MP1_RP4_HF10 control/s)
183 7be77300 c38 294 1 vxportal (VxFS 5.0_REV-5.0MP1RP3a3_sol po)
184 7ae00000 1bd048 21 1 vxfs (VxFS 5.0_REV-5.0MP1RP3a3_sol Su)
230 7beea000 4fe28 290 1 vxfen (VRTS Fence 5.0MP1)
247 7ab58000 a2c8 295 1 fdd (VxQIO 5.0_REV-5.0MP1RP3a3_sol Q)
Would you like to reply?
Login or Register to post your comment.