topic Re: removing Symmetrix disks from HP9000 K570 in Operating System - HP-UX

removing Symmetrix disks from HP9000 K570

John Knapp — Tue, 09 Jul 2002 18:22:17 GMT

Just wanting to bounce my list of tasks of you folks regarding the removal of external EMC Symmetrix disks from our K570 production server running HP/UX v10.20 (I am 100% migrated to new disk array):

vgexport all VGs associated with the older Symm disks
rmsf -H 8/0 (one SCSI chain of disks)
rmsf -H 8/4 (other SCSI chain of disks)
shutdown/power of the server
disconnect old SCSI cables (2) from server
boot back up
run ioscan

done ????

Re: removing Symmetrix disks from HP9000 K570

Martin Johnson — Tue, 09 Jul 2002 18:23:24 GMT

Sounds good to me.

HTH
Marty

Re: removing Symmetrix disks from HP9000 K570

James R. Ferguson — Tue, 09 Jul 2002 18:26:16 GMT

Hi John:

That works. You can do a simple 'rm' of the device files or use 'rmsf'. Don't forget to to both raw and cooked device files ('rdsk' and 'dsk'). There is no need to run 'ioscan' other than to verify to your own satisfaction that you have cleaned up your configuration.

Regards!

...JRF...

Re: removing Symmetrix disks from HP9000 K570

A. Clay Stephenson — Tue, 09 Jul 2002 18:28:18 GMT

The ioscan is optional; unless these were raw disks you may need to delete/modify filesystem entries in /etc/fstab. I assume these were not MS/Service Guard VG's; otherwise, you will need to do some cluster configuration and possibly edit /etc/lvmrc.

Re: removing Symmetrix disks from HP9000 K570

John Knapp — Tue, 09 Jul 2002 19:35:20 GMT

Clay ... yes you are right ... we are not using MC/Service Guard. My concern was whether or not to use vgremove or vgexport ... vgremove looks like you have to reduce the volume group down to a single drive and then you can remove it from the system .... that seems to be counter productive ????

Re: removing Symmetrix disks from HP9000 K570

A. Clay Stephenson — Tue, 09 Jul 2002 19:38:19 GMT

Absolutely vgexport is the way to go and it also removes the /dev/vgxx/ nodes.

Re: removing Symmetrix disks from HP9000 K570

John Knapp — Tue, 09 Jul 2002 19:52:39 GMT

Once again ... all you folks are great ! ITRC Forums are the best resource for us AIX administrators who occationally support/work on HP/UX & Solaris

Thanks plenty.

Re: removing Symmetrix disks from HP9000 K570

Steve Faidley — Wed, 10 Jul 2002 16:01:07 GMT

You concern over whether to use vgexport or vgreduce/vgremove is a valid one. If you only do a vgexport then when the next person goes to use the disks they will have to do a pvcreate -f to force create.
It always makes me nervous when I have to do that. Did they really give me the right PV's? Am I going to step on someones data?
Also they could "dd" the vgid off of the disks and vgimport them to see the data.

Re: removing Symmetrix disks from HP9000 K570

John Knapp — Wed, 10 Jul 2002 16:56:50 GMT

steve ... the disks associated with the volume groups on the older Symmetrix 5500 disk array will no longer be needed ... in fact, EMC will be rolling the box out the door after some other NT clients migrate their data too.

My over all concern now that I have 100% of my non-vg00 data in a singe volume group on a newer Symmetrix 3930 disk array is to properly "discard" any remains of the logical definitions of the Symm5500.

I was just surprised that vgremove required you to vgreduce down to a single disk drive before "removing". Seems kinda clumsy to me. In the AIX world ... all you need to do is run the exportvg Volume_Group_Name command and everything is erase from the ODM ... but you could still importvg if need.

I didn't want to assume that what was true for exportvg in AIX is the same as vgexport in HP/UX 10.20

Re: removing Symmetrix disks from HP9000 K570

James R. Ferguson — Wed, 10 Jul 2002 17:11:24 GMT

Hi John:

HP-UX 'vgexport' *is* the fast way to clean up the device files in /dev/vgXX/*, '/etc/lvmtab', and '/etc/lvmpvg' (if you are using physical volume groups).

You are correct in that the other proper way to destroy LVM information is to 'lvremove' logicaql vlumes; 'vgreduce' all but one volume in a volume group; 'vgremove' the last physical volume from the group; manually delete '/dev/vgXX/' files; etc.

The idea, in this case, is that 'vgexport' handles all this in one step. Of course, the VGID (Volume Group Identification) is left on the physical disk and thus a subsequent 'vgimport' could be used to reclaim the physical volume, but in this case, you don't care.

In cases where I am destroying a volume group and its associated logical volumes, I use the 'vgexport' because its fast. I *do* immediately follow this with a 'pvcreate -f' against the physical disk volumes that constituted the just-destroyed volume group. I do this to erase the VGID from the physical disk so that when I later 'pvcreate' the disk for reuse, I don't expect to be "told" that the disk appears to belong to a volume group. If I do a 'pvcreate' and I obtain that message, I *really* look at what I might be doing, because if I've followed my own rules the warning is because I've chosen the wrong disk!

Regards!

...JRF...