removing Symmetrix disks from HP9000 K570

[John Knapp]

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 ????

[Martin Johnson]

Sounds good to me.


HTH
Marty

[James R. Ferguson]

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...

[A. Clay Stephenson]

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.

[John Knapp]

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 ????

[A. Clay Stephenson · Accepted solution]

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

[John Knapp]

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.

[Steve Faidley]

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.

[John Knapp]

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

[James R. Ferguson]

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...