it in and importing the volume group (vgimport).

Typically I name my OS volume groups "CentOS" and give
semi-descriptive names to my external array volume groups, such
as "Exch-SQL" or "VM_Guests".

You could also have a hot server activate the volume group via
heartbeat if the first server goes down if your storage
allows multiple initiators to attach to it.

> We are still checking with the vendor for a solution to move
> back to the 512 sectors rather than the 2k ones. Hopefully
> they come up with something.

I wish you luck here, but in my experience once an array is
created with a set sector size or chunk size, changing these
usually involves re-creating the array.

LVM might be able to handle the sector size though, no need to
create any partition on the disk, but future migration
compatibility could be questionable.

To create a VG out of it:

pvcreate /dev/sdb

then,

vgcreate "VG_Name" /dev/sdb

then,

lvcreate -L 4T -n "LV_Name" "VG_Name"

If you get a new external array say it's /dev/sdc and want to
move all data from the old one to the new one online and then
remove the old one.

pvcreate /dev/sdc

vgextend "VG_Name" /dev/sdc

pvmove /dev/sdb /dev/sdc

vgreduce "VG_Name" /dev/sdb

pvremove /dev/sdb

Then take /dev/sdb offline.

-Ross

PS You might want to remove any existing MBR/GPT stuff off of
/dev/sdb before you pvcreate it, with:

dd if=/dev/zero of=/dev/sdb bs=512 count=63

That will wipe the first track which should do it.