I screwed-up swapping a disk

[Mark Greene_1]

and so far I cannot unscrew it.

I was swapping a 18.2gig drive for a 36.4gig in an SC10 array. I did the lvreduce for each lvol on the disk. I *did not* do the vgreduce before pulling out the drive (oops!). Going into Sam to verify I pulled the correct drive, it hung (on the looking for swap of all things, which is just on the internal drives). Considering I was on the console and the system is not on the network, I cntrl-B'd to the gsp console and did RS to restart the system, which was probably a dumb thing to do.

Nevertheless, the system came back-up ok. I am left with the /dev/dsk/c7c13d0 drive still being in /etc/lvmtab and therefore cannot do either the vgcfgrestore or the pvcreate/vgextend to get the disk back in the logical volumes as a mirror.

I tried doing vgscan -v to rebuild the /etc/lvmtab file, but all that succeeded in doing was dropping the entire volume group completely. I did, however, have a copy of lvmtab which I moved back into place.

Beyond rebuilding the volume group and restoring the data from backup, what options do I have left?

Thanks,
mark

[Duncan Edmonstone]

Do you still have the 18GB disk? Why not pop it back in? It should still have its VGRA intact if you haven't used it somewhere else...

HTH

Duncan

[S.K. Chan]

You should be able to force the removal of missing PV with ..
# vgreduce -f vgXX

Did you try that ?

[Martin Johnson]

A vgexport (make sure you use the -m mapfile option) will remove the entries from the /etc/lvmtab. You can try a vgimport using the mapfile to get it back after editing the map file to delete the problem disk. You can use vgextend to put it back later.

[Mark Greene_1]

Thanks for the suggestions, here's what I've done:

- did the vgreduce with the -f option; got the error "couldn't query physical volume" and "the specified path does not correspond to physical volume attached to this volume group"

- put the 18 gig drive back in and repeated the vgreduce, same results.

- did "pvcreate" with the -f option (thinking that I could then do the vgextend), but got the error "the physical volume is already recorded in the /ect/lvmtab file"

- did lvmextend just to see what errors it would return, got "couldn't query all of the physical volumes" (this despite the 18 gig drive being back in and the /dev/dsk/cxxx and /dev/rdsk/cxxxx files still in place) and also got "can not match the alternate PV link with a primary link Failure possibly caused by strict allocation policy"

I tried redoing the vgscan -v to get the dsk reference removed from the /etc/lvmtab file, and it would not do it. I tried this with both the 18gig drive in and with it removed. I was hoping if it did take it out (and would possibly drop all of the drives in the vg) that I could do a vgcfgrestore to pick everything back-up. but, I couldn't get that far.

Any other suggestions?

mark

[James R. Ferguson]

Hi Mark:

When you attempted to rebuild your /etc/lvmtab file, did you *first* rename the old one?

# mv /etc/lvmtab /etc/lvmtab.old
# vgscan -av

If the *old* file is present when the 'vgscan' is done, information in it is used to construct the new one.

Regards!

...JRF...

[Sandip Ghosh]

After reboot your vg has not come up due to the quorum problem. Now do a
vgchange -q -a y /dev/vgxx
then the vg will be activated. Then put the old drive in its place and do a vgreduce fro that drive. Then remove the old drive and add the new drive and do a vgextend for that drive.

Sandip

[Mark Greene_1]

James,

Yes, that occured to me about 5 seconds after I hit "submit" :-)

I rm'd the lvmtab file (I have a copy!) and did the vgscan. The new lvmtab file dropped *all* of the disks for the vg, and the vg.

I then tried to do vgimport from the mapfile I created earlier, but I get the error messsage "volume group is still active". How can this be?!?! vgdisplay does not show the volume group at all, and vgcfgrestore failed, of course, because the volume group is not in /etc/lvmtab. I went into SAM, which also does not show the vg, and selecting "activate", does not show the vg as available to activate. I don't want to have to recreate the vg and lvol info from scratch because then I'd lose another day redoing the data restore.

I cannot believe that this situation is all that different from losing a disk due to hardware failure and the system crashing and then coming back-up without the drive.

For what Sandip suggested, I am confused. The VG came-up active. If I move my old copy of /etc/lvmtab back and do the vgchange to deactivate the volume group, and then do it again to reactive it, will I be able to do the vgreduce and have it work?

mark

[Dave Wherry · Accepted solution]

I did the same type of thing just this past Sunday. I pretty much tried all the suggestions listed here. Martin's suggestion of the vgexport/vgimport is what worked for me.
The mapfile really only tells vgimport about the logical volumes in the group. You should not have to edit it. For that matter I did not use the mapfile.
vgexport -p -v -m /tmp/vg.mapfile
Just in case, it's good to have the map file.

vgchange -a n /dev/vg??
vgexport -v /dev/vg??


vgimport -v /dev/vg?? /dev/dsk/c?t?d0 /dev/dsk/c?t?d?.....
vgchange -a y /dev/vg??

Do the vgimport with only the disks you want to be in the volume group. Leave out the disk that you physically removed. This will bring in all the logical volumes in a sequential order, 1 - ?. You can mount each of these individually and see what is on it. Then umount it and change the name of the device files:
mv /dev/vg??/lvol1 /dev/vg??/lvolwhat you want to call it
mv /dev/vg??/rlvol1 /dev/vg??/rlvolwhat you want to call it

Do both the lvol and rlvol files. Then you can mount it again just as it was before. You could probably use the mapfile and have the lvol names come in correctly. The method I described is how HP led me through it and it worked just fine.

[Mark Greene_1]

Dave,

I had already started rebuilding the vg so I could not try your solution, but it definetly looked to be the thing to do. I will save it for furture reference.

my thanks to all those who replied.

mark

[Martin Johnson]

Dave,

Thanks for the vote of confidence on my suggestion. However, I noticed Mark gave me only 5 points with he gave you 8!!! :-)



Marty

[Mark Greene_1]

had I gotten to the point where I could have done the vgimport, the map file would have helped. not being able to get there (but I think Dave's solution would have done it) made the information nice to know, but not an immediate help.

mark